The definition of a component model I use below is a class which allows
properties, methods, and events in a structured way which can be
recognized, usually through some form of introspection outside of that
class. This structured way allows visual tools to host components, and
allows programmers to build applications and libraries visually in a RAD
environment.
The Java language has JavaBeans as its component model which allows Java
applications to be built in a visual RAD way. Microsoft's .Net has a
component model built-in to its .Net class libraries as well as
supported by CLR which allows .Net applications to be built visually
using components created in any .Net supported language.
With Python things are different. There is no single component model
which allows Python developers to build components which will be used
and recognized by the various RAD Python tools on the market. Instead a
developer must create a slightly different set of Python classes for
each RAD Python tool. This is the situation despite Python's having
easily as much functionality, if not much more, as Java or .Net
languages such as C#, VB, or C++/CLI for creating components, and for
allowing visual tools to introspect the properties, methods, and events
of Python classes.
I believe that Python should have a common components model for all RAD
development environments, as that would allow the Python programmer to
create a set of classes representing components which would work in any
environment. I want to immediately point out that components do not
simply mean visual GUI components but what may be even more important,
non-visual components. Having used RAD development environments to
create applications, I have found such environments almost always much
better than coding complex interactions manually, and I believe that
visual development environments are almost a necessity in today's world
of large-scale, multi-tier, and enterprise applications.
Has there ever been, or is there presently anybody, in the Python
developer community who sees the same need and is working toward that
goal of a common component model in Python, blessed and encouraged by
those who maintain the Python language and standard modules themselves ?
122  7183 
In <W5*****************@newsread4.news.pas.earthlink. net>, Edward Diener
No Spam wrote:
I believe that Python should have a common components model for all RAD
development environments, as that would allow the Python programmer to
create a set of classes representing components which would work in any
environment. I want to immediately point out that components do not
simply mean visual GUI components but what may be even more important,
non-visual components. Having used RAD development environments to
create applications, I have found such environments almost always much
better than coding complex interactions manually, and I believe that
visual development environments are almost a necessity in today's world
of large-scale, multi-tier, and enterprise applications.
IMHO those RAD tools in other languages are in place to avoid writing much
boring boiler plate code. At least that is what those tools usually
produce: tons of code that the programmer should leave alone or the round
trip, RAD tool → code → RAD tool, does not work anymore. If you come
across such a situation while programming in Python it is almost always
easy to factor out most of it. Python itself is a RAD tool.
Ciao,
Marc 'BlackJack' Rintsch
EdwardThe definition of a component model I use below is a class which
Edwardallows properties, methods, and events in a structured way which
Edwardcan be recognized, usually through some form of introspection
Edwardoutside of that class. This structured way allows visual tools
Edwardto host components, and allows programmers to build applications
Edwardand libraries visually in a RAD environment.
...
EdwardI believe that Python should have a common components model for
Edwardall RAD development environments, as that would allow the Python
Edwardprogrammer to create a set of classes representing components
Edwardwhich would work in any environment.
Having never used java or .NET I'm not sure what you're looking for. Does
Python's current introspection not work? Is it someone too unstructured
(whatever "structured" means)? Can you give a simple example?
Skip
On 10/9/06, Edward Diener No Spam <el*******************@earthlink.netwrote:
The definition of a component model I use below is a class which allows
properties, methods, and events in a structured way which can be
recognized, usually through some form of introspection outside of that
class. This structured way allows visual tools to host components, and
allows programmers to build applications and libraries visually in a RAD
environment.
The Java language has JavaBeans as its component model which allows Java
applications to be built in a visual RAD way. Microsoft's .Net has a
component model built-in to its .Net class libraries as well as
supported by CLR which allows .Net applications to be built visually
using components created in any .Net supported language.
With Python things are different. There is no single component model
which allows Python developers to build components which will be used
and recognized by the various RAD Python tools on the market. Instead a
developer must create a slightly different set of Python classes for
each RAD Python tool. This is the situation despite Python's having
easily as much functionality, if not much more, as Java or .Net
languages such as C#, VB, or C++/CLI for creating components, and for
allowing visual tools to introspect the properties, methods, and events
of Python classes.
I believe that Python should have a common components model for all RAD
development environments, as that would allow the Python programmer to
create a set of classes representing components which would work in any
environment. I want to immediately point out that components do not
simply mean visual GUI components but what may be even more important,
non-visual components. Having used RAD development environments to
create applications, I have found such environments almost always much
better than coding complex interactions manually, and I believe that
visual development environments are almost a necessity in today's world
of large-scale, multi-tier, and enterprise applications.
Has there ever been, or is there presently anybody, in the Python
developer community who sees the same need and is working toward that
goal of a common component model in Python, blessed and encouraged by
those who maintain the Python language and standard modules themselves ?
--
http://mail.python.org/mailman/listinfo/python-list
If you are talking about about creating a GUI and having be able to
run using different GUI libraries like Tkinter, wxPython, wxgtk, ect.
You could look into Dabo( http://dabodev.com/). It is designed so that
you can design your GUI and have it run with what ever GUI library you
want(only wxPython is supported at the moment. And I think that
Tkinter works somewhat.)
--
"Now that I am a Christian I do not have moods in which the whole
thing looks very improbable: but when I was an atheist I had moods in
which Christianity looked terribly probable."
-C. S. Lewis
-Echo sk**@pobox.com wrote:
EdwardThe definition of a component model I use below is a class which
Edwardallows properties, methods, and events in a structured way which
Edwardcan be recognized, usually through some form of introspection
Edwardoutside of that class. This structured way allows visual tools
Edwardto host components, and allows programmers to build applications
Edwardand libraries visually in a RAD environment.
...
EdwardI believe that Python should have a common components model for
Edwardall RAD development environments, as that would allow the Python
Edwardprogrammer to create a set of classes representing components
Edwardwhich would work in any environment.
Having never used java or .NET I'm not sure what you're looking for. Does
Python's current introspection not work? Is it someone too unstructured
(whatever "structured" means)? Can you give a simple example?
In the typical RAD development environment, a particular component model
allows one to drop components, which are classes corresponding to a
particular inner representation which tells the development environment
what are the "properties" and "events" of that component, and
subsequently set "properties" for that component and add handlers for
its "events" visually.
Subsequently When the components are instantiated at run-time, the
particular "properties" are automagically set and the particular
"events" are automagically tied to event handlers in other classes (
usually a window, or form, although it can be in any other class which
can handle events ). How this "automagically" is done depends on the
visual development environment.
I find it very neat that I, the end-user of the component, does not have
to write the boiler-plate code to set "properties" and hook up "events"
and can do this visually. I realize that others may find this
unimportant. But in a visual environment where not only non-viusual
components are involved, but also visual GUI components are, this also
allows the visual look of a particular window ( form or screen if you
like ) to be composed automatically. At the same time hooking non-visual
components automagically at design time so that they are connected at
run-time to event handlers is also very nice.
In order to make such a system work, the visual RAD environment needs to
know what in a class makes it a component, and what in that components
specifies the "properties" and "events" for which it will automagically
setup the correct "code" which works at run-time. Without a component
model to tell it these things, it can not work to produce the
boiler-plate code necessary to set "properties" and hook event handlers
to an event.
In JavaBeans, for Java, and the System.ComponentModel namespace, as well
as properties, delegates, and events in .Net, there exists a common
component model which defines, in these environments, what a components
is so that the visual RAD development can do its magic.
I realize that many Python programmers don't see the necessity for
having a RAD visual devlopment environment doing for them what they can
do by hand in their Python code, particularly in the constructor to
classes. But there are people who have used such a RAD model,
particularly when setting up a GUI application or Web application, who
appreciate the ease of use of such a RAD visual environment, especially
in the area of dropping visual controls on a window and having that
window appear at run-time with the particular look which they have
visually setup at design time. But even beyond the more common visual
setup of a window or web page, a visual RAD environment allows the
end-user programmer to visually create boiler-plate code for setting the
"properties" and "events" of non-visual classes, which make up the
greater part of the internal logic of any given program.
More importantly a common component model, which works in any language's
visual RAD environment, enables the development and re-use of components
which are as easily used as dropping that component from a component
palette onto a visual container, usually a representation of a run-time
window, and setting it's "properties" and/or "events". The visual
manipulation of components does not preclude making manipulations at
run-time through code also if necessary, and all visual environements
allow the setting of "properties" and "events" at run-time also in the
usual way.
If one has used Borland's Delphi or C++ Builder IDEs, or Sun's NetBeans
or IBM's Eclipse for Java, or Microsoft's Visual Studio for .Net, one
knows what I mean as far as a visual RAD environment. All of these are
made possible by a common component model which different development
environments can use.
There's nothing wrong with Python's introspection. In fact Python's
facilities in this area and its support for metadata are stronger than
any of these other languages ! However there is no common component
model which specifies that X is a "property" or Y is an "event" of a
Python class which can be visually manipulated at design-time and
automagically set at run-time, so that any given Python RAD visual
environment will treat a Python class, specified as a component, in
exactly the same way. Also in these other languages, a component is
different from a class in that a component is recognized in a particular
way, often so that the component can interact if necessary with its
container and/or visual site.
OK, I have proselytized enough <g>. Python is a great language and I
truly love it and its flexibility and ease of programming use. If there
is no impetus to create a component model for re-usable components for
visual RAD environments in Python, that's fine with me. But I thought
someone from the Python development community, given the use of visual
RAD environments for other languages as mentioned above, to create GUI
and large-scale applications, would have considered it.
Edward Diener No Spam wrote:
sk**@pobox.com wrote:
> EdwardThe definition of a component model I use below is a class
which
Edwardallows properties, methods, and events in a structured way
which
Edwardcan be recognized, usually through some form of introspection
Edwardoutside of that class. This structured way allows visual
tools
Edwardto host components, and allows programmers to build
applications
Edwardand libraries visually in a RAD environment.
...
EdwardI believe that Python should have a common components
model for
Edwardall RAD development environments, as that would allow the
Python
Edwardprogrammer to create a set of classes representing components
Edwardwhich would work in any environment.
Having never used java or .NET I'm not sure what you're looking for.
Does
Python's current introspection not work? Is it someone too unstructured
(whatever "structured" means)? Can you give a simple example?
In the typical RAD development environment, a particular component model
allows one to drop components, which are classes corresponding to a
particular inner representation which tells the development environment
what are the "properties" and "events" of that component, and
subsequently set "properties" for that component and add handlers for
its "events" visually.
Subsequently When the components are instantiated at run-time, the
particular "properties" are automagically set and the particular
"events" are automagically tied to event handlers in other classes (
usually a window, or form, although it can be in any other class which
can handle events ). How this "automagically" is done depends on the
visual development environment.
I find it very neat that I, the end-user of the component, does not have
to write the boiler-plate code to set "properties" and hook up "events"
and can do this visually. I realize that others may find this
unimportant. But in a visual environment where not only non-viusual
components are involved, but also visual GUI components are, this also
allows the visual look of a particular window ( form or screen if you
like ) to be composed automatically. At the same time hooking non-visual
components automagically at design time so that they are connected at
run-time to event handlers is also very nice.
In order to make such a system work, the visual RAD environment needs to
know what in a class makes it a component, and what in that components
specifies the "properties" and "events" for which it will automagically
setup the correct "code" which works at run-time. Without a component
model to tell it these things, it can not work to produce the
boiler-plate code necessary to set "properties" and hook event handlers
to an event.
In JavaBeans, for Java, and the System.ComponentModel namespace, as well
as properties, delegates, and events in .Net, there exists a common
component model which defines, in these environments, what a components
is so that the visual RAD development can do its magic.
I realize that many Python programmers don't see the necessity for
having a RAD visual devlopment environment doing for them what they can
do by hand in their Python code, particularly in the constructor to
classes. But there are people who have used such a RAD model,
particularly when setting up a GUI application or Web application, who
appreciate the ease of use of such a RAD visual environment, especially
in the area of dropping visual controls on a window and having that
window appear at run-time with the particular look which they have
visually setup at design time. But even beyond the more common visual
setup of a window or web page, a visual RAD environment allows the
end-user programmer to visually create boiler-plate code for setting the
"properties" and "events" of non-visual classes, which make up the
greater part of the internal logic of any given program.
More importantly a common component model, which works in any language's
visual RAD environment, enables the development and re-use of components
which are as easily used as dropping that component from a component
palette onto a visual container, usually a representation of a run-time
window, and setting it's "properties" and/or "events". The visual
manipulation of components does not preclude making manipulations at
run-time through code also if necessary, and all visual environements
allow the setting of "properties" and "events" at run-time also in the
usual way.
If one has used Borland's Delphi or C++ Builder IDEs, or Sun's NetBeans
or IBM's Eclipse for Java, or Microsoft's Visual Studio for .Net, one
knows what I mean as far as a visual RAD environment. All of these are
made possible by a common component model which different development
environments can use.
There's nothing wrong with Python's introspection. In fact Python's
facilities in this area and its support for metadata are stronger than
any of these other languages ! However there is no common component
model which specifies that X is a "property" or Y is an "event" of a
Python class which can be visually manipulated at design-time and
automagically set at run-time, so that any given Python RAD visual
environment will treat a Python class, specified as a component, in
exactly the same way. Also in these other languages, a component is
different from a class in that a component is recognized in a particular
way, often so that the component can interact if necessary with its
container and/or visual site.
OK, I have proselytized enough <g>. Python is a great language and I
truly love it and its flexibility and ease of programming use. If there
is no impetus to create a component model for re-usable components for
visual RAD environments in Python, that's fine with me. But I thought
someone from the Python development community, given the use of visual
RAD environments for other languages as mentioned above, to create GUI
and large-scale applications, would have considered it.
Why not propose something. That is the easiest way to get things moving.
Chaz.
Echo wrote:
On 10/9/06, Edward Diener No Spam <el*******************@earthlink.net>
wrote:
>The definition of a component model I use below is a class which allows
properties, methods, and events in a structured way which can be
recognized, usually through some form of introspection outside of that
class. This structured way allows visual tools to host components, and
allows programmers to build applications and libraries visually in a RAD
environment.
The Java language has JavaBeans as its component model which allows Java
applications to be built in a visual RAD way. Microsoft's .Net has a
component model built-in to its .Net class libraries as well as
supported by CLR which allows .Net applications to be built visually
using components created in any .Net supported language.
With Python things are different. There is no single component model
which allows Python developers to build components which will be used
and recognized by the various RAD Python tools on the market. Instead a
developer must create a slightly different set of Python classes for
each RAD Python tool. This is the situation despite Python's having
easily as much functionality, if not much more, as Java or .Net
languages such as C#, VB, or C++/CLI for creating components, and for
allowing visual tools to introspect the properties, methods, and events
of Python classes.
I believe that Python should have a common components model for all RAD
development environments, as that would allow the Python programmer to
create a set of classes representing components which would work in any
environment. I want to immediately point out that components do not
simply mean visual GUI components but what may be even more important,
non-visual components. Having used RAD development environments to
create applications, I have found such environments almost always much
better than coding complex interactions manually, and I believe that
visual development environments are almost a necessity in today's world
of large-scale, multi-tier, and enterprise applications.
Has there ever been, or is there presently anybody, in the Python
developer community who sees the same need and is working toward that
goal of a common component model in Python, blessed and encouraged by
those who maintain the Python language and standard modules themselves ?
--
http://mail.python.org/mailman/listinfo/python-list
If you are talking about about creating a GUI and having be able to
run using different GUI libraries like Tkinter, wxPython, wxgtk, ect.
You could look into Dabo(http://dabodev.com/). It is designed so that
you can design your GUI and have it run with what ever GUI library you
want(only wxPython is supported at the moment. And I think that
Tkinter works somewhat.)
It's not just for GUI controls that a component model exists in the
other environments I mentioned. Non-GUI components are intrinsically as
important, if not more so, to a component model architecture. Also,
quite honestly, I think a component model would have to be specified by
the core Python developers instead of retrofitted against the popular
GUI environments for Python which currently exist. Also I admit I am no
fan of wx-you-name-it, whose "event" model especially I find way too
limiting and ineffective in relation to the entire area of
component-based programming and events.
Chaz Ginger wrote:
Edward Diener No Spam wrote:
>sk**@pobox.com wrote:
>> EdwardThe definition of a component model I use below is a class
which
Edwardallows properties, methods, and events in a structured way
which
Edwardcan be recognized, usually through some form of introspection
Edwardoutside of that class. This structured way allows visual
tools
Edwardto host components, and allows programmers to build
applications
Edwardand libraries visually in a RAD environment.
...
EdwardI believe that Python should have a common components
model for
Edwardall RAD development environments, as that would allow the
Python
Edwardprogrammer to create a set of classes representing components
Edwardwhich would work in any environment.
Having never used java or .NET I'm not sure what you're looking for.
Does
Python's current introspection not work? Is it someone too unstructured
(whatever "structured" means)? Can you give a simple example?
In the typical RAD development environment, a particular component model
allows one to drop components, which are classes corresponding to a
particular inner representation which tells the development environment
what are the "properties" and "events" of that component, and
subsequently set "properties" for that component and add handlers for
its "events" visually. snip...
Why not propose something. That is the easiest way to get things moving.
How does one do that ? Propose something here on this NG or is there
some other official way ?
Why not propose something. That is the easiest way to get things moving.
>
How does one do that ? Propose something here on this NG or is there
some other official way ?
I'm by no means an expert here but the usual procedure as far as I can
see is this:
1. propose something here and get people excited so that they discuss
it inside out
2. taking into account the discussion formulate a new/modified proposal
3. more discussion follows most probably
4. a more formal proposal can be sent to python-dev
5. more discusssion there
6. the result of all these discussions can be that people encourage
you to write a PEP, this is probably the most important stage, please
see http://www.python.org/dev/peps/ and http://www.python.org/dev/peps/pep-0001/
7. once you are successful in writing a PEP just submit it and wait
for acceptance/rejection
HTH,
Daniel
Edward Diener No Spam wrote:
Chaz Ginger wrote:
Why not propose something. That is the easiest way to get things moving.
How does one do that ? Propose something here on this NG or is there
some other official way ?
Come up with a specification, with examples. Ideally have working
code. Post here to get some initial feedback, if things look like
they're worth pushing forward after that then write a PEP: http://www.python.org/dev/peps/pep-0001/
Edward Diener No Spam wrote:
There's nothing wrong with Python's introspection. In fact Python's
facilities in this area and its support for metadata are stronger than
any of these other languages ! However there is no common component
model which specifies that X is a "property" or Y is an "event" of a
Python class which can be visually manipulated at design-time and
automagically set at run-time, so that any given Python RAD visual
environment will treat a Python class, specified as a component, in
exactly the same way. Also in these other languages, a component is
different from a class in that a component is recognized in a particular
way, often so that the component can interact if necessary with its
container and/or visual site.
You'll definitely want to take a look at Enthought's Traits (disclaimer: I work
for Enthought). I'm supposed to be on vacation now, so I'm not going to give you
the full rundown of Traits and Traits UI, so I'm simply going to point you to
the page we have about it: http://code.enthought.com/traits/
You can talk to the rest of the Enthought crew on the enthought-dev mailing list
if you have any questions: https://mail.enthought.com/mailman/l.../enthought-dev
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
or IBM's Eclipse for Java
Or Eclipse for Python using PyDev? [0]
Reference
[0] PyDev, 'Fabio Zadrozny, Aleks Totic, plugin allowing Python/Jython
to use Eclipse as an IDE'
<http://pydev.sourceforge.net/>
[Accessed Tuesday, 10 October 2006]
Robert Kern wrote:
Edward Diener No Spam wrote:
>There's nothing wrong with Python's introspection. In fact Python's
facilities in this area and its support for metadata are stronger than
any of these other languages ! However there is no common component
model which specifies that X is a "property" or Y is an "event" of a
Python class which can be visually manipulated at design-time and
automagically set at run-time, so that any given Python RAD visual
environment will treat a Python class, specified as a component, in
exactly the same way. Also in these other languages, a component is
different from a class in that a component is recognized in a
particular way, often so that the component can interact if necessary
with its container and/or visual site.
You'll definitely want to take a look at Enthought's Traits (disclaimer:
I work for Enthought). I'm supposed to be on vacation now, so I'm not
going to give you the full rundown of Traits and Traits UI, so I'm
simply going to point you to the page we have about it:
http://code.enthought.com/traits/
It looks as if traits is an attempt to create a "property" in the
component terminology which I originally specified. I will take a look
at it.
>
You can talk to the rest of the Enthought crew on the enthought-dev
mailing list if you have any questions:
https://mail.enthought.com/mailman/l.../enthought-dev
Already subscribed. Thanks !
goon wrote:
> or IBM's Eclipse for Java
Or Eclipse for Python using PyDev? [0]
Those are very nice features but there is no re-usable Python bean
support like there is a Java bean. That was my initial point.
Edward Diener No Spam wrote:
Has there ever been, or is there presently anybody, in the Python
developer community who sees the same need and is working toward that
goal of a common component model in Python, blessed and encouraged by
those who maintain the Python language and standard modules themselves ?
Someone aiming towards a standard to /replace/ everyone else's? That
presupposes a level of arrogance that seems unusual in the python world.
(whilst everyone's proud of their own code and they _generally_ respect
other people's even if it's not their cup of tea).
The WSGI standard could be a form of component model, and has gone through
the PEP process so that might match your criterion. As for component
models, they do exist.
Our component model on the Kamaelia project [1] is one that's heavily
designed around the idea of composition and independent execution of
components and message passing (message passing maps to events for some
sorts of message),
[1] http://kamaelia.sourceforge.net/Home
I wouldn't think of proposing it as the single standard to rule them all
though, for the simple reason every approach has its own strengths. (We do
find the approach extremely useful though)
If you want a quick example of the core ideas, a tutorial aimed around
building a massively simplified core is here: http://kamaelia.sourceforge.net/MiniAxon/
If you want to see a substantial example, you can look here:
* http://tinyurl.com/oqjfb - whiteboarding with audio where every client
is a server. The entire resulting system is also a component.
For something more simplistic:
* http://kamaelia.sourceforge.net/Exam...ationTool.html
Something halfway in terms of complexity (a PVR for transcoding everything
broadcast on digital TV):
* http://tinyurl.com/lvygq
(OK, you need to add more channels, but you'd need more CPU's too)
We also have tools for introspecting a running system, and also a visual
composition tool (called Compose) [2] for creating simple systems
graphically, and that, as you say, handles a significant chunk of
dreariness. Suggestions on improving the model and composition tool are
very welcome, code is even more welcome :)
[2] Sample system created with the newest version of Compose: http://tinyurl.com/numwk
Compose is also a Kamaelia system, and can be found here: http://tinyurl.com/p7z76
(bulk of the wiring up is in the bottom of the file - this is an
interesting example because of the use of Pygame and Tk for different
parts of the interface where appropriate)
However, off the top of my head, you should also look at Zope's component
model, Trac's component model, Twisted's model & PEAK, and any proposal
to say "this is the solution", needs to be compelling for all of these
projects.
Note, they do change where there's a benefit - twisted adopted some
interesting ideas from Zope for example - however the onus on showing the
benefit is on you. (Which if you can do, would be welcome I would expect)
One thing that would probably be very useful would be to identify a way the
various models these projects use can be made to interact better.
The reason I mention //our// model is because we're finding it useful, and
has visual composition, introspection and components have a rich amount of
meta data associated with them, this may or may not fit your criterion.
One of the most "bling" examples we've got right now though (which I
mentioned mainly because it does show reuse up quite nicely) is where we
play Dirac encoded video back onto a pygame surface and then render that
onto a texture that's on a plane spinning in 3D (in realtime):
* Code: http://tinyurl.com/oynxv
* Screenshot: http://kamaelia.sourceforge.net/t/Dirac3D.png
I've uploaded a collection of other screenshots of various kamaelia related
things here:
* http://kamaelia.sourceforge.net/screenshots/
You may find the following interesting:
* http://kamaelia.sourceforge.net/screenshots/Compose.png
* http://kamaelia.sourceforge.net/scre...eliaOpenGL.png (example
of putting components in places they don't realise)
* http://kamaelia.sourceforge.net/scre...Visualiser.png
Regards,
Michael.
--
Kamaelia Project Lead http://kamaelia.sourceforge.net/Home http://yeoldeclue.com/blog
Michael wrote:
Edward Diener No Spam wrote:
>Has there ever been, or is there presently anybody, in the Python
developer community who sees the same need and is working toward that
goal of a common component model in Python, blessed and encouraged by
those who maintain the Python language and standard modules themselves ?
Someone aiming towards a standard to /replace/ everyone else's? That
presupposes a level of arrogance that seems unusual in the python world.
(whilst everyone's proud of their own code and they _generally_ respect
other people's even if it's not their cup of tea).
The reason I would like to see a standard component model for Python is
so 3rd party developers could create their classes to conform to this
model and work in any RAD IDE environment which adapts it. That's the
way JavaBeans work, that the way Borland's VCL component model works,
and that's the way .Net works. When there are many different component
models, the 3rd party developer must adapt their components to each
model for a particular environment.
But far be it from me to want to replace everybody else's model <g>.
By your reasoning above, standardizing anything in software is an
arrogant proposition. Whereas I look at standardization, when it is well
done, as a boon to programmers.
>
The WSGI standard could be a form of component model, and has gone through
the PEP process so that might match your criterion.
I do not know what it is but I will look it up.
As for component
models, they do exist.
Our component model on the Kamaelia project [1] is one that's heavily
designed around the idea of composition and independent execution of
components and message passing (message passing maps to events for some
sorts of message),
[1] http://kamaelia.sourceforge.net/Home
I will look at kamaelia. Thanks !
>
I wouldn't think of proposing it as the single standard to rule them all
though, for the simple reason every approach has its own strengths. (We do
find the approach extremely useful though)
If you want a quick example of the core ideas, a tutorial aimed around
building a massively simplified core is here:
http://kamaelia.sourceforge.net/MiniAxon/
If you want to see a substantial example, you can look here:
* http://tinyurl.com/oqjfb - whiteboarding with audio where every client
is a server. The entire resulting system is also a component.
For something more simplistic:
* http://kamaelia.sourceforge.net/Exam...ationTool.html
Something halfway in terms of complexity (a PVR for transcoding everything
broadcast on digital TV):
* http://tinyurl.com/lvygq
(OK, you need to add more channels, but you'd need more CPU's too)
We also have tools for introspecting a running system, and also a visual
composition tool (called Compose) [2] for creating simple systems
graphically, and that, as you say, handles a significant chunk of
dreariness. Suggestions on improving the model and composition tool are
very welcome, code is even more welcome :)
[2] Sample system created with the newest version of Compose:
http://tinyurl.com/numwk
Compose is also a Kamaelia system, and can be found here:
http://tinyurl.com/p7z76
(bulk of the wiring up is in the bottom of the file - this is an
interesting example because of the use of Pygame and Tk for different
parts of the interface where appropriate)
However, off the top of my head, you should also look at Zope's component
model, Trac's component model, Twisted's model & PEAK, and any proposal
to say "this is the solution", needs to be compelling for all of these
projects.
A standard component model could be used as a base for other more
advanced needs. Most of those mentioned above seem to involve web
application frameworks whereas my idea of a component model just assumes
the paradigms of properties, methods, and events which may allow
re-usable components at a base level in any environment.
A particular implementation is certainly allowed to build a more
complicated idea of a component, through inheritance, from a base level
component, and this is in fact the way that most components work in
current component model environments I have mentioned. For instance in
..Net a control is a component with other added qualities. So while one
could build components which are not controls, it is necessary to add
functionality to the base level idea of a component in order to create a
control.
>
Note, they do change where there's a benefit - twisted adopted some
interesting ideas from Zope for example - however the onus on showing the
benefit is on you. (Which if you can do, would be welcome I would expect)
One thing that would probably be very useful would be to identify a way the
various models these projects use can be made to interact better.
The reason I mention //our// model is because we're finding it useful, and
has visual composition, introspection and components have a rich amount of
meta data associated with them, this may or may not fit your criterion.
One of the most "bling" examples we've got right now though (which I
mentioned mainly because it does show reuse up quite nicely) is where we
play Dirac encoded video back onto a pygame surface and then render that
onto a texture that's on a plane spinning in 3D (in realtime):
* Code: http://tinyurl.com/oynxv
* Screenshot: http://kamaelia.sourceforge.net/t/Dirac3D.png
I've uploaded a collection of other screenshots of various kamaelia related
things here:
* http://kamaelia.sourceforge.net/screenshots/
You may find the following interesting:
* http://kamaelia.sourceforge.net/screenshots/Compose.png
* http://kamaelia.sourceforge.net/scre...eliaOpenGL.png (example
of putting components in places they don't realise)
* http://kamaelia.sourceforge.net/scre...Visualiser.png
Thanks for all the link regarding kamaelia.
Edward Diener No Spam wrote:
Robert Kern wrote:
>Edward Diener No Spam wrote:
>>There's nothing wrong with Python's introspection. In fact Python's
facilities in this area and its support for metadata are stronger than
any of these other languages ! However there is no common component
model which specifies that X is a "property" or Y is an "event" of a
Python class which can be visually manipulated at design-time and
automagically set at run-time, so that any given Python RAD visual
environment will treat a Python class, specified as a component, in
exactly the same way. Also in these other languages, a component is
different from a class in that a component is recognized in a
particular way, often so that the component can interact if necessary
with its container and/or visual site.
You'll definitely want to take a look at Enthought's Traits (disclaimer:
I work for Enthought). I'm supposed to be on vacation now, so I'm not
going to give you the full rundown of Traits and Traits UI, so I'm
simply going to point you to the page we have about it:
http://code.enthought.com/traits/
It looks as if traits is an attempt to create a "property" in the
component terminology which I originally specified. I will take a look
at it.
It also provides an event model and a declarative UI layer as well as several
other things besides.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
Edward Diener No Spam wrote:
Michael wrote:
Edward Diener No Spam wrote:
Has there ever been, or is there presently anybody, in the Python
developer community who sees the same need and is working toward that
goal of a common component model in Python, blessed and encouraged by
those who maintain the Python language and standard modules themselves ?
Someone aiming towards a standard to /replace/ everyone else's? That
presupposes a level of arrogance that seems unusual in the python world.
(whilst everyone's proud of their own code and they _generally_ respect
other people's even if it's not their cup of tea).
The reason I would like to see a standard component model for Python is
so 3rd party developers could create their classes to conform to this
model and work in any RAD IDE environment which adapts it. That's the
way JavaBeans work, that the way Borland's VCL component model works,
and that's the way .Net works. When there are many different component
models, the 3rd party developer must adapt their components to each
model for a particular environment.
But far be it from me to want to replace everybody else's model <g>.
By your reasoning above, standardizing anything in software is an
arrogant proposition. Whereas I look at standardization, when it is well
done, as a boon to programmers.
The WSGI standard could be a form of component model, and has gone through
the PEP process so that might match your criterion.
I do not know what it is but I will look it up.
As for component
models, they do exist.
Our component model on the Kamaelia project [1] is one that's heavily
designed around the idea of composition and independent execution of
components and message passing (message passing maps to events for some
sorts of message),
[1] http://kamaelia.sourceforge.net/Home
I will look at kamaelia. Thanks !
I wouldn't think of proposing it as the single standard to rule them all
though, for the simple reason every approach has its own strengths. (We do
find the approach extremely useful though)
If you want a quick example of the core ideas, a tutorial aimed around
building a massively simplified core is here:
http://kamaelia.sourceforge.net/MiniAxon/
If you want to see a substantial example, you can look here:
* http://tinyurl.com/oqjfb - whiteboarding with audio where every client
is a server. The entire resulting system is also a component.
For something more simplistic:
* http://kamaelia.sourceforge.net/Exam...ationTool.html
Something halfway in terms of complexity (a PVR for transcoding everything
broadcast on digital TV):
* http://tinyurl.com/lvygq
(OK, you need to add more channels, but you'd need more CPU's too)
We also have tools for introspecting a running system, and also a visual
composition tool (called Compose) [2] for creating simple systems
graphically, and that, as you say, handles a significant chunk of
dreariness. Suggestions on improving the model and composition tool are
very welcome, code is even more welcome :)
[2] Sample system created with the newest version of Compose:
http://tinyurl.com/numwk
Compose is also a Kamaelia system, and can be found here:
http://tinyurl.com/p7z76
(bulk of the wiring up is in the bottom of the file - this is an
interesting example because of the use of Pygame and Tk for different
parts of the interface where appropriate)
However, off the top of my head, you should also look at Zope's component
model, Trac's component model, Twisted's model & PEAK, and any proposal
to say "this is the solution", needs to be compelling for all of these
projects.
A standard component model could be used as a base for other more
advanced needs. Most of those mentioned above seem to involve web
application frameworks whereas my idea of a component model just assumes
the paradigms of properties, methods, and events which may allow
re-usable components at a base level in any environment.
A particular implementation is certainly allowed to build a more
complicated idea of a component, through inheritance, from a base level
component, and this is in fact the way that most components work in
current component model environments I have mentioned. For instance in
.Net a control is a component with other added qualities. So while one
could build components which are not controls, it is necessary to add
functionality to the base level idea of a component in order to create a
control.
Note, they do change where there's a benefit - twisted adopted some
interesting ideas from Zope for example - however the onus on showing the
benefit is on you. (Which if you can do, would be welcome I would expect)
One thing that would probably be very useful would be to identify a way the
various models these projects use can be made to interact better.
The reason I mention //our// model is because we're finding it useful, and
has visual composition, introspection and components have a rich amount of
meta data associated with them, this may or may not fit your criterion.
One of the most "bling" examples we've got right now though (which I
mentioned mainly because it does show reuse up quite nicely) is where we
play Dirac encoded video back onto a pygame surface and then render that
onto a texture that's on a plane spinning in 3D (in realtime):
* Code: http://tinyurl.com/oynxv
* Screenshot: http://kamaelia.sourceforge.net/t/Dirac3D.png
I've uploaded a collection of other screenshots of various kamaelia related
things here:
* http://kamaelia.sourceforge.net/screenshots/
You may find the following interesting:
* http://kamaelia.sourceforge.net/screenshots/Compose.png
* http://kamaelia.sourceforge.net/scre...eliaOpenGL.png (example
of putting components in places they don't realise)
* http://kamaelia.sourceforge.net/scre...Visualiser.png
Thanks for all the link regarding kamaelia.
Python does not _need_ a component model just as you don't _need_ a RAD
IDE tool to write Python code. The reason for having a component model
or a RAD IDE tool is to avoid writing a lot of boiler plate code.
Python is terse enough that boiler plate code is not needed, just type
what you need into an editor. It seems that you talk about Python but
you are still thinking in Java or C++.
At the same time one could claim that Python already has certain
policies that makes it seem as if it has a component model. Take a look
at the "magic methods". For example if a class has a __len__ method, it
is possible to use the len() function on an instance of that class. If
a class has the __getitem__ then indexing can be used on that class's
insance. Then Python has properties (see http://www.python.org/doc/2.2.3/what...rellinks.html). Just by
inspecting the object one can tell a great deal about them (even read
the documentation if needed, by using the __doc__ attribute). What
other standards would you propose for the core language?
"Nick Vatamaniuc" <va******@gmail.comwrites:
Python does not _need_ a component model just as you don't _need_ a RAD
IDE tool to write Python code. The reason for having a component model
or a RAD IDE tool is to avoid writing a lot of boiler plate code.
It's also so that applications written in differing languages can call
each other.
Edward Diener No Spam wrote:
>Why not propose something. That is the easiest way to get things moving.
How does one do that ? Propose something here on this NG or is there
some other official way ?
the first step towards a successful Python proposal is to stop quoting
the entire thread in each post to this newsgroup.
</F>
Paul Rubin schrieb:
"Nick Vatamaniuc" <va******@gmail.comwrites:
>Python does not _need_ a component model just as you don't _need_ a RAD
IDE tool to write Python code. The reason for having a component model
or a RAD IDE tool is to avoid writing a lot of boiler plate code.
It's also so that applications written in differing languages can call
each other.
Nope. Things like CORBA and COM do have that property, but e.g. the Java
beans spec has only a meaning inside the VM. Not sure about .NET, but I
can imagine there it's the same thing.
All the languages he mentioned are statically typed, or the component
models themselves are. So the component model is basically needed (as
others also mentioned) to glue things together, to dynamize that -
whereas python is dynamic on the first hand, and actually lacks static
typing to infer component properties...
Diez
Nick Vatamaniuc wrote:
At the same time one could claim that Python already has certain
policies that makes it seem as if it has a component model.
every Python object surely qualifies as a component, for any non-myopic
definition of that word, and everything inside a Python program is an
object. so yes, Python has a component model, and Python programmers
are using that model all over the place.
what might be missing is support for publishing additional metadata
using a standardized vocabulary, and a way to access that data with-
out having to actually create the object.
implementing this using existing mechanisms is trivial (as the endless
stream of interface/component/adapter/trait implementations have shown
us); coming up with a good-enough-to-be-useful-for-enough-people
vocabulary is a lot harder.
</F>
Diez B. Roggisch wrote:
Paul Rubin schrieb:
>>"Nick Vatamaniuc" <va******@gmail.comwrites:
>>>Python does not _need_ a component model just as you don't _need_ a RAD
IDE tool to write Python code. The reason for having a component model
or a RAD IDE tool is to avoid writing a lot of boiler plate code.
It's also so that applications written in differing languages can call
each other.
Nope. Things like CORBA and COM do have that property, but e.g. the Java
beans spec has only a meaning inside the VM. Not sure about .NET, but I
can imagine there it's the same thing.
Well the .NET component model is specifically designed to be
cross-language, but that's a feature of .NET/mono rather than of the
componenet framework. You are correct about Beans, though.
All the languages he mentioned are statically typed, or the component
models themselves are. So the component model is basically needed (as
others also mentioned) to glue things together, to dynamize that -
whereas python is dynamic on the first hand, and actually lacks static
typing to infer component properties...
Just the same, one can use IronPython to call components written in
other languages. And, I believe, vice versa.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
Marc 'BlackJack' Rintsch wrote:
(snip)
Python itself is a RAD tool.
+1 QOTW
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
>Nope. Things like CORBA and COM do have that property, but e.g. the Java
>beans spec has only a meaning inside the VM. Not sure about .NET, but I
can imagine there it's the same thing.
Well the .NET component model is specifically designed to be
cross-language, but that's a feature of .NET/mono rather than of the
componenet framework. You are correct about Beans, though.
Is this cross-language in the sense jython can use beans? Or in the sense
like CORBA? I assumed the former, which isn't cross-language in my
perception (at least not in the general sense, as CORBA is)
>All the languages he mentioned are statically typed, or the component
models themselves are. So the component model is basically needed (as
others also mentioned) to glue things together, to dynamize that -
whereas python is dynamic on the first hand, and actually lacks static
typing to infer component properties...
Just the same, one can use IronPython to call components written in
other languages. And, I believe, vice versa.
Sure, as I can do it in jython. But the key point is: can your ordinary
python-object be published as a component? At least for jython I can
say "no", you will have to subclass an already existing
java-object/interface. And I have difficulties imagining that it is any
different in .NET - because I've read statements that claimed that the
structure of the VM/runtime is orientied towards single-inheritance
statically typed languages as C#/java.
Diez
Edward Diener No Spam wrote:
>
In the typical RAD development environment, a particular component model
allows one to drop components, which are classes corresponding to a
particular inner representation which tells the development environment
what are the "properties" and "events" of that component, and
subsequently set "properties" for that component and add handlers for
its "events" visually.
As others may have mentioned, Python has its own built-in support for
properties: changing the state of an object with optional side-effects.
Moreover, as you realise, Python also has capable introspection
mechanisms to reveal such properties at run-time. However, things like
event mechanisms are not generally standardised.
[...]
OK, I have proselytized enough <g>. Python is a great language and I
truly love it and its flexibility and ease of programming use. If there
is no impetus to create a component model for re-usable components for
visual RAD environments in Python, that's fine with me. But I thought
someone from the Python development community, given the use of visual
RAD environments for other languages as mentioned above, to create GUI
and large-scale applications, would have considered it.
You might want to look into environments and tools such as Qt Designer
together with PyQt. Whilst the PyQt mechanisms (really the Qt
mechanisms exposed in Python) aren't standardised as such, you get
event and property mechanisms which are actually quite powerful and
which certainly seem to demonstrate many of the RAD environment
capabilities you're interested in: you can write Python components
which can be dropped into the Designer environment and they're
responsive to introspection and interaction right there and then.
See this presentation for more details: http://indico.cern.ch/contributionDi...d=41&confId=44
Paul
Diez B. Roggisch wrote:
[...]
>>Just the same, one can use IronPython to call components written in
other languages. And, I believe, vice versa.
Sure, as I can do it in jython. But the key point is: can your ordinary
python-object be published as a component? At least for jython I can
say "no", you will have to subclass an already existing
java-object/interface. And I have difficulties imagining that it is any
different in .NET - because I've read statements that claimed that the
structure of the VM/runtime is orientied towards single-inheritance
statically typed languages as C#/java.
The answer to this question is currently beyond me. Maybe someone who
knows more about IronPython can elucidate. I do know (as you probably do
also) that Python generates code for the .NET CLR, however.
I don't think there's any *theoretical* reason why IronPython components
can't be called from other languages, but as to the practicalities
(specifically whether IronPython produces linkable assemblies) we'll
have to wait for someone who knows.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
Edward Diener No Spam wrote:
Michael wrote:
Edward Diener No Spam wrote:
Has there ever been, or is there presently anybody, in the Python
developer community who sees the same need and is working toward that
goal of a common component model in Python, blessed and encouraged by
those who maintain the Python language and standard modules themselves ?
Someone aiming towards a standard to /replace/ everyone else's? That
presupposes a level of arrogance that seems unusual in the python world.
(whilst everyone's proud of their own code and they _generally_ respect
other people's even if it's not their cup of tea).
The reason I would like to see a standard component model for Python is
so 3rd party developers could create their classes to conform to this
model and work in any RAD IDE environment which adapts it. That's the
way JavaBeans work, that the way Borland's VCL component model works,
and that's the way .Net works. When there are many different component
models, the 3rd party developer must adapt their components to each
model for a particular environment.
But far be it from me to want to replace everybody else's model <g>.
Well that's the thing you *do* want since you want the previous
paragraph ;-)
(Or at least a way to adapt component models.)
By your reasoning above, standardizing anything in software is an
arrogant proposition. Whereas I look at standardization, when it is well
done, as a boon to programmers.
OK, maybe I was being a bit strong - I was merely thinking "lots of
people have something like this already, and I've not seen anyone push
their model as THE model", (even if lots of people like *their* model
:-)
However, I was also being a bit tongue in cheek, though I should have
said unreasonable, not arrogant:
"...all progress depends on the unreasonable man." -- Bernard Shaw.
What could have some mileage though is proposing a standard way for
these component models to interoperate. What that would look like
(given the wildly different models :), is another matter and an
exercise for the interested reader ;-)
The WSGI standard could be a form of component model, and has gone through
the PEP process so that might match your criterion.
I do not know what it is but I will look it up.
NB, I'm using component model in it's loosest form there.
As for component
models, they do exist.
Our component model on the Kamaelia project [1] is one that's heavily
designed around the idea of composition and independent execution of
components and message passing (message passing maps to events for some
sorts of message),
[1] http://kamaelia.sourceforge.net/Home
I will look at kamaelia. Thanks !
You're welcome. Any deficiencies or improvements or suggestions you've
got would be very welcome (I can see some which we're planning on
addressing at some point, but fresh critical eyes are always welcome).
However, off the top of my head, you should also look at Zope's component
model, Trac's component model, Twisted's model & PEAK, and any proposal
to say "this is the solution", needs to be compelling for all of these
projects.
A standard component model could be used as a base for other more
advanced needs. Most of those mentioned above seem to involve web
application frameworks whereas my idea of a component model just assumes
the paradigms of properties, methods, and events which may allow
re-usable components at a base level in any environment.
They do, however in particular, Trac's model whilst web oriented
strikes me personally as interesting and PEAK's is applicable, as I
understand it, outside the web sphere. (Enthought was mentioned
elsewhere and is interesting (IMO) for the properties stuff)
If you're interested in event systems as well, it's probably worth
looking at the way a number of pygame applications are written since
there's an event model built into pygame that some pygame apps take
advantage of for custom events and some don't. It's a very different
problem realm to the web systems.
Twisted is worth looking at as well, since it's probably got one of the
more interesting approaches for dealing with essentially event based
systems I've seen.
A particular implementation is certainly allowed to build a more
complicated idea of a component, through inheritance, from a base level
component, and this is in fact the way that most components work in
current component model environments I have mentioned. For instance in
.Net a control is a component with other added qualities. So while one
could build components which are not controls, it is necessary to add
functionality to the base level idea of a component in order to create a
control.
You *may* also want to take a look at picolo as well then - but as far
as I'm
aware it's not actually *used* by anyone. It is in some respects more
like
the kind of component model you describe here. (I personally didn't
find much
useful about their proposal that goes beyond what python already
provides
you) However you might find that and some of the other things on the
following
link interesting: http://www2.lifl.fr/~marvie/software.html
It's worth bearing in mind though that your description above is one
approach
for component based design. A survey of different approaches which you
might find useful:
Thanks for all the link regarding kamaelia.
Probably went a bit overboard there :)
However I do agree that a visual system is something important, since
not everyone thinks the same way. (I can talk about our system till the
cows come home, show people code, but when I show them the visual
builder, everyone seems to understand).
Regards,
Michael.
--
Michael Sparks, Kamaelia Dust Puppy http://kamaelia.sf.net/ http://yeoldeclue.com/blog
Nick Vatamaniuc wrote:
Edward Diener No Spam wrote:
>Michael wrote:
Python does not _need_ a component model just as you don't _need_ a RAD
IDE tool to write Python code. The reason for having a component model
or a RAD IDE tool is to avoid writing a lot of boiler plate code.
Python is terse enough that boiler plate code is not needed, just type
what you need into an editor. It seems that you talk about Python but
you are still thinking in Java or C++.
A RAD IDE tool to hook up components into an application or library (
module in Python ) has nothing to do with terseness and everything to do
with ease of programming. All you are saying is that you don't have a
need for this, but perhaps others do. I don't mind others saying they
have no need or seeing no benefit. But if you have ever used a visual
design-time environment for creating applications you might feel
differently.
"Thinking in Java or C++" as opposed to Python does not mean anything to
me as a general statement. I am well aware of the difference between
statically and dynamically typed languages but why this should have
anything to do with RAD programming is beyond me. Do you care to
elucidate this distinction ?
>
At the same time one could claim that Python already has certain
policies that makes it seem as if it has a component model. Take a look
at the "magic methods". For example if a class has a __len__ method, it
is possible to use the len() function on an instance of that class. If
a class has the __getitem__ then indexing can be used on that class's
insance. Then Python has properties (see
http://www.python.org/doc/2.2.3/what...rellinks.html). Just by
inspecting the object one can tell a great deal about them (even read
the documentation if needed, by using the __doc__ attribute). What
other standards would you propose for the core language?
Python has great facilities for a component model, much better than the
other languages I use regularly ( C++, C#, Java ). I am not arguing
against that. A component model for RAD tools allows the tool to expose
properties and events to the end-user at design time so that at run-time
the properties and events are automatically setup once an object is
instantiated. The essence of a component model for RAD programming is
how one specifies properties and events for a class to be manipulated by
the RAD tool at design time. Another obvious part of the component model
is how one specifies that the properties and events one sets up at
design-time are serialized so that at run-time they are properly set. A
final element of a component model is the ability of a component to
interact with the environment in which it exists at design time, through
property editors, and at run-time, the latter being obviously more
important for visual controls than non-visual components.
Paul Rubin wrote:
"Nick Vatamaniuc" <va******@gmail.comwrites:
>Python does not _need_ a component model just as you don't _need_ a RAD
IDE tool to write Python code. The reason for having a component model
or a RAD IDE tool is to avoid writing a lot of boiler plate code.
It's also so that applications written in differing languages can call
each other.
That's a possible reason, but with JavaBeans and EJBs for Java there is
just a single language and I am sure there are many Java programmers who
enjoy using Eclipse, NetBeans, or JBuilder to name a few RAD IDEs which
allow them to create their applications using a design-time visual
environment.
"Edward Diener No Spam" <el*******************@earthlink.netwrote in message
news:Wv******************@newsread2.news.pas.earth link.net...
"Thinking in Java or C++" as opposed to Python does not mean anything to me as a general
statement. I am well aware of the difference between statically and dynamically typed
languages but why this should have anything to do with RAD programming is beyond me. Do
you care to elucidate this distinction ?
I think this blog entry http://osteele.com/archives/2004/11/ides
provides some insight into the point of view expressed.
Diez B. Roggisch wrote:
Paul Rubin schrieb:
>"Nick Vatamaniuc" <va******@gmail.comwrites:
>>Python does not _need_ a component model just as you don't _need_ a RAD
IDE tool to write Python code. The reason for having a component model
or a RAD IDE tool is to avoid writing a lot of boiler plate code.
It's also so that applications written in differing languages can call
each other.
Nope. Things like CORBA and COM do have that property, but e.g. the Java
beans spec has only a meaning inside the VM. Not sure about .NET, but I
can imagine there it's the same thing.
All the languages he mentioned are statically typed, or the component
models themselves are. So the component model is basically needed (as
others also mentioned) to glue things together, to dynamize that -
whereas python is dynamic on the first hand, and actually lacks static
typing to infer component properties...
While I understand dynamic typing, I still think it is possible to
create attributes in a Python component model which could tell a RAD
tool what type the attribute will encompass for the purpose of
properties and events. Obviously a "name, type" tuple, among other
possible information would have to be used. But given Python's amazingly
flexible type and introspection system, this should be possible.
Of course I am not trying to change the nature of normal Python
attributes per se at all, and one of the most important things in a
property-method-event component model is to be able to specify
properties that are distinct from just normal object data members. So
one of the most important things in a Python component model would be
the ability to tag component properties as totally distinct from normal
Python class attributes or property attributes.
Given that Python already has new-style class properties, maybe another
name for the component properties I envision is needed to avoid confusion.
Steve Holden wrote:
Diez B. Roggisch wrote:
[...]
>>Just the same, one can use IronPython to call components written in
other languages. And, I believe, vice versa.
Sure, as I can do it in jython. But the key point is: can your ordinary
python-object be published as a component? At least for jython I can
say "no", you will have to subclass an already existing
java-object/interface. And I have difficulties imagining that it is any
different in .NET - because I've read statements that claimed that the
structure of the VM/runtime is orientied towards single-inheritance
statically typed languages as C#/java.
The answer to this question is currently beyond me. Maybe someone who
knows more about IronPython can elucidate. I do know (as you probably do
also) that Python generates code for the .NET CLR, however.
I am not sure about current IronPython functionality but the end result
is that one should be able to create .Net components and classes using
Python with IronPython just as one does in C#, C++/CLI, or VB .NET.
But this is not creating a component model for Python except in the .Net
environment, which essentially means Windows unless IronPython will work
under Mono, and Microsoft does not kill Mono. I don't think all those
"ifs" is something a Python programmer wants to deal with in possible
RAD component development.
Fredrik Lundh wrote:
Nick Vatamaniuc wrote:
>At the same time one could claim that Python already has certain
policies that makes it seem as if it has a component model.
every Python object surely qualifies as a component, for any non-myopic
definition of that word, and everything inside a Python program is an
object. so yes, Python has a component model, and Python programmers
are using that model all over the place.
what might be missing is support for publishing additional metadata
using a standardized vocabulary, and a way to access that data with-
out having to actually create the object.
implementing this using existing mechanisms is trivial (as the endless
stream of interface/component/adapter/trait implementations have shown
us); coming up with a good-enough-to-be-useful-for-enough-people
vocabulary is a lot harder.
There's no doubt that Python's excellent introspection mechanism allows
an outside RAD-like tool to inspect the workings of any Python object.
But that does not make it a component model in my original use of the
term on this thread. A RAD tool needs to know what properties and events
within a class can be manipulated visually, and it needs to be able to
serialize those properties and events so that they are set at run-time
automatically once an object is created.
"Edward Diener No Spam" wrote:
A RAD IDE tool to hook up components into an application or library (
module in Python ) has nothing to do with terseness and everything to do
with ease of programming.
python already has excellent and ridiculously easy-to-program ways to hook
things up. after all, hooking things up is what python programmers tend to do,
most of their time.
if you want better support for more precise hooking, post some examples.
All you are saying is that you don't have a need for this, but perhaps others do.
handwavy references to what "other may need" is another thing you should
avoid if you want your Python change proposal to be successful.
</F>
Edward Diener No Spam wrote:
There's no doubt that Python's excellent introspection mechanism allows
an outside RAD-like tool to inspect the workings of any Python object.
But that does not make it a component model in my original use of the
term on this thread. A RAD tool needs to know what properties and events
within a class can be manipulated visually, and it needs to be able to
serialize those properties and events so that they are set at run-time
automatically once an object is created.
external serialization was not part of your original definition.
I think you have to be a *lot* more concrete here. repeatedly referring to
"some kind of hypothetical property (that isn't a property)" and "some kind
of hypothetical event (that isn't a public method)" and "some kind of hypo-
thetical RAD tool" won't get you anywhere.
</F>
Michael Sparks wrote:
Edward Diener No Spam wrote:
>Michael wrote:
>>Edward Diener No Spam wrote:
Has there ever been, or is there presently anybody, in the Python
developer community who sees the same need and is working toward that
goal of a common component model in Python, blessed and encouraged by
those who maintain the Python language and standard modules themselves ?
Someone aiming towards a standard to /replace/ everyone else's? That
presupposes a level of arrogance that seems unusual in the python world.
(whilst everyone's proud of their own code and they _generally_ respect
other people's even if it's not their cup of tea).
The reason I would like to see a standard component model for Python is
so 3rd party developers could create their classes to conform to this
model and work in any RAD IDE environment which adapts it. That's the
way JavaBeans work, that the way Borland's VCL component model works,
and that's the way .Net works. When there are many different component
models, the 3rd party developer must adapt their components to each
model for a particular environment.
But far be it from me to want to replace everybody else's model <g>.
Well that's the thing you *do* want since you want the previous
paragraph ;-)
(Or at least a way to adapt component models.)
I was being funny above. Yes I would like to establish a basic component
model for RAD development in Python. But surely it need not replace all
others but could serve at least as a base class for other derived models
for various environments. That way a developer writing a Python
component could have it work in these environments as a simple component
and more complex components, tailored to that environment could be
created as necessary through inheritance.
>
>By your reasoning above, standardizing anything in software is an
arrogant proposition. Whereas I look at standardization, when it is well
done, as a boon to programmers.
OK, maybe I was being a bit strong - I was merely thinking "lots of
people have something like this already, and I've not seen anyone push
their model as THE model", (even if lots of people like *their* model
:-)
However, I was also being a bit tongue in cheek, though I should have
said unreasonable, not arrogant:
"...all progress depends on the unreasonable man." -- Bernard Shaw.
Bravo, Shaw. Of course by unreasonable I assume Shaw meant those using
imagination and inspiration along with logic and reason.
>
What could have some mileage though is proposing a standard way for
these component models to interoperate. What that would look like
(given the wildly different models :), is another matter and an
exercise for the interested reader ;-)
>>The WSGI standard could be a form of component model, and has gone through
the PEP process so that might match your criterion.
I do not know what it is but I will look it up.
NB, I'm using component model in it's loosest form there.
>>As for component
models, they do exist.
Our component model on the Kamaelia project [1] is one that's heavily
designed around the idea of composition and independent execution of
components and message passing (message passing maps to events for some
sorts of message),
[1] http://kamaelia.sourceforge.net/Home
I will look at kamaelia. Thanks !
You're welcome. Any deficiencies or improvements or suggestions you've
got would be very welcome (I can see some which we're planning on
addressing at some point, but fresh critical eyes are always welcome).
>>However, off the top of my head, you should also look at Zope's component
model, Trac's component model, Twisted's model & PEAK, and any proposal
to say "this is the solution", needs to be compelling for all of these
projects.
A standard component model could be used as a base for other more
advanced needs. Most of those mentioned above seem to involve web
application frameworks whereas my idea of a component model just assumes
the paradigms of properties, methods, and events which may allow
re-usable components at a base level in any environment.
They do, however in particular, Trac's model whilst web oriented
strikes me personally as interesting and PEAK's is applicable, as I
understand it, outside the web sphere. (Enthought was mentioned
elsewhere and is interesting (IMO) for the properties stuff)
I do like most of Enthought's notion of properties, which they call
"traits", no doubt to also distinguish it from Python new-style class
properties. Their notion corresponds somewhat to the idea of properties
in Java and .Net.
Essentially a property-method-event component model in Python needs
component properties and component events, so investigating notions of
component properties in Python is something I want to do.
>
If you're interested in event systems as well, it's probably worth
looking at the way a number of pygame applications are written since
there's an event model built into pygame that some pygame apps take
advantage of for custom events and some don't. It's a very different
problem realm to the web systems.
Are there any URLs you know for looking at these event models ? In
general an event model for a component must be ideally very flexible,
which in my terminology means that any Python user-defined class or
function object should be able to handle any exposed class event given
the correct callable signature.
>
Twisted is worth looking at as well, since it's probably got one of the
more interesting approaches for dealing with essentially event based
systems I've seen.
>A particular implementation is certainly allowed to build a more
complicated idea of a component, through inheritance, from a base level
component, and this is in fact the way that most components work in
current component model environments I have mentioned. For instance in
.Net a control is a component with other added qualities. So while one
could build components which are not controls, it is necessary to add
functionality to the base level idea of a component in order to create a
control.
You *may* also want to take a look at picolo as well then - but as far
as I'm
aware it's not actually *used* by anyone. It is in some respects more
like
the kind of component model you describe here. (I personally didn't
find much
useful about their proposal that goes beyond what python already
provides
you) However you might find that and some of the other things on the
following
link interesting: http://www2.lifl.fr/~marvie/software.html
It's worth bearing in mind though that your description above is one
approach
for component based design. A survey of different approaches which you
might find useful:
Again, thanks for the links.
There's no doubt that Python's excellent introspection mechanism allows
an outside RAD-like tool to inspect the workings of any Python object.
But that does not make it a component model in my original use of the
term on this thread. A RAD tool needs to know what properties and events
within a class can be manipulated visually, and it needs to be able to
serialize those properties and events so that they are set at run-time
automatically once an object is created.
A little visual inspection of some objects:
tim@oblique:~$ python
Python 2.3.5 (#2, Sep 4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>class Person(object):
.... def __init__(self, name, age=None):
.... self.name = name
.... self.age = age
.... def whoami(self):
.... if self.age is not None:
.... return "%s (%i)" % (
.... self.name,
.... self.age)
.... return self.name
....
>>p = Person("Sandy")
[s for s in dir(p) if not s.startswith('_') and
callable(eval('p.%s' % s))]
['whoami']
>>[s for s in dir(p) if not s.startswith('_') and not
callable(eval('p.%s' % s))]
['age', 'name']
Thus, you have the ability to find an object's methods/events
(things that are callable()), and its properties (things that are
not callable()). Any "RAD" tool that wants can pull these
properties, just as my command-line RAD tool can ;)
As for serializing them,
>>import shelve
d = shelve.open('tmp/stuff.shlv')
d['person'] = p
p = 'hello'
p
'hello'
>>p = d['person']
p.whoami()
'Sandy'
>>p.age = 42
p.whoami()
'Sandy (42)'
>>d['person'] = p
d.close()
p = 'hello2'
p
'hello2'
>>d = shelve.open('tmp/stuff.shlv')
p = d['person']
p.whoami()
'Sandy (42)'
which seems to work fine for me. This can be used for creating
all sorts of flavors of objects at design time, storing them, and
then restoring them at runtime.
-tkc
While I understand dynamic typing, I still think it is possible to
create attributes in a Python component model which could tell a RAD
tool what type the attribute will encompass for the purpose of
properties and events. Obviously a "name, type" tuple, among other
possible information would have to be used. But given Python's amazingly
flexible type and introspection system, this should be possible.
The amazing flexibility stems from the fact that it is _runtime_. This is
_exactly_ the difference between static and dynamic typing.
If a static analysis (_not_ importing the module, which can trigger
arbitrary code being run!!!) is supposed to deliver the component
architecture, you are either introducing static typing, or get into the
danger of lose coupling between declaration and implementation, rendering
the whole thing pretty useless.
Of course, with a bit of discipline, you can create such a introspection
facility that offers its properties after a mere import, see ZOPE
interfaces for example.
But in the end, it boils down to declaring stuff for that purpose alone, and
introducing static typing, whereas other languages declare typing for their
own needs, and add the component model upon that.
And then you lose a _lot_ of what python makes powerful, for a very doubtful
benefit IMHO.
Diez
Richard Brodie wrote:
"Edward Diener No Spam" <el*******************@earthlink.netwrote in message
news:Wv******************@newsread2.news.pas.earth link.net...
>"Thinking in Java or C++" as opposed to Python does not mean anything to me as a general
statement. I am well aware of the difference between statically and dynamically typed
languages but why this should have anything to do with RAD programming is beyond me. Do
you care to elucidate this distinction ?
I think this blog entry http://osteele.com/archives/2004/11/ides
provides some insight into the point of view expressed.
I think that one can easily be both, someone who is good at using a
language and someone who is good at using a visual tool. The dichotomy
presented in the article exists only for a small number of people.
Fredrik Lundh wrote:
"Edward Diener No Spam" wrote:
>A RAD IDE tool to hook up components into an application or library (
module in Python ) has nothing to do with terseness and everything to do
with ease of programming.
python already has excellent and ridiculously easy-to-program ways to hook
things up. after all, hooking things up is what python programmers tend to do,
most of their time.
I agree.
>
if you want better support for more precise hooking, post some examples.
I want a design-time environment to hook up my objects in a visual way.
I think it is easier than doing it manually, even in Python.
>
>All you are saying is that you don't have a need for this, but perhaps others do.
handwavy references to what "other may need" is another thing you should
avoid if you want your Python change proposal to be successful.
I did not say what "others may need".
"Edward Diener No Spam" wrote:
>if you want better support for more precise hooking, post some examples.
I want a design-time environment to hook up my objects in a visual way.
I think it is easier than doing it manually, even in Python.
what objects? what hooks? visually, in what way?
>>All you are saying is that you don't have a need for this, but perhaps others do.
handwavy references to what "other may need" is another thing you should
avoid if you want your Python change proposal to be successful.
I did not say what "others may need".
I'm not sure I see the big difference between "perhaps others do [have a need]"
and "others may need", but that's me.
</F>
Diez B. Roggisch wrote:
>While I understand dynamic typing, I still think it is possible to
create attributes in a Python component model which could tell a RAD
tool what type the attribute will encompass for the purpose of
properties and events. Obviously a "name, type" tuple, among other
possible information would have to be used. But given Python's amazingly
flexible type and introspection system, this should be possible.
The amazing flexibility stems from the fact that it is _runtime_. This is
_exactly_ the difference between static and dynamic typing.
If a static analysis (_not_ importing the module, which can trigger
arbitrary code being run!!!) is supposed to deliver the component
architecture, you are either introducing static typing, or get into the
danger of lose coupling between declaration and implementation, rendering
the whole thing pretty useless.
Yes, I am suggesting static typing functionality for a subset of Python
attributes. How this can be done I am still investigating on my own.
>
Of course, with a bit of discipline, you can create such a introspection
facility that offers its properties after a mere import, see ZOPE
interfaces for example.
But in the end, it boils down to declaring stuff for that purpose alone, and
introducing static typing, whereas other languages declare typing for their
own needs, and add the component model upon that.
And then you lose a _lot_ of what python makes powerful, for a very doubtful
benefit IMHO.
Adding a feature, such as static typing functionality for the situation
of doing visual RAD programming, does not "lose a _lot_ of what makes
python powerful".
My idea of adding static typing is not an attempt to change the language
but rather to develop Python classes which encapsulate the idea of a
variable and a type for the purposes of emulating component properties
and component events. If a language addition is needed instead I will
investigate how to propose it.
Fredrik Lundh wrote:
"Edward Diener No Spam" wrote:
>>>if you want better support for more precise hooking, post some examples.
I want a design-time environment to hook up my objects in a visual way.
I think it is easier than doing it manually, even in Python.
what objects? what hooks? visually, in what way?
>>>>All you are saying is that you don't have a need for this, but perhaps others do.
handwavy references to what "other may need" is another thing you should
avoid if you want your Python change proposal to be successful.
I did not say what "others may need".
I'm not sure I see the big difference between "perhaps others do [have a need]"
and "others may need", but that's me.
He's wriggling anyway, as his opening post said (among other things) "I
believe that Python should have a common components model for all RAD
development environments ...". So unless he's the only person who's
going to use these development environments it does indeed sound a
little prescriptive.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
Tim Chase wrote:
>There's no doubt that Python's excellent introspection mechanism
allows an outside RAD-like tool to inspect the workings of any Python
object. But that does not make it a component model in my original use
of the term on this thread. A RAD tool needs to know what properties
and events within a class can be manipulated visually, and it needs to
be able to serialize those properties and events so that they are set
at run-time automatically once an object is created.
A little visual inspection of some objects:
tim@oblique:~$ python
Python 2.3.5 (#2, Sep 4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>class Person(object):
... def __init__(self, name, age=None):
... self.name = name
... self.age = age
... def whoami(self):
... if self.age is not None:
... return "%s (%i)" % (
... self.name,
... self.age)
... return self.name
...
>>p = Person("Sandy")
>>[s for s in dir(p) if not s.startswith('_') and
callable(eval('p.%s' % s))]
['whoami']
>>[s for s in dir(p) if not s.startswith('_') and not
callable(eval('p.%s' % s))]
['age', 'name']
Thus, you have the ability to find an object's methods/events (things
that are callable()), and its properties (things that are not
callable()). Any "RAD" tool that wants can pull these properties, just
as my command-line RAD tool can ;)
Not all attributes are component properties in typical Visual RAD tool.
In most visual RAD tools which I have used a component property is a
publicly exposed type/name which may or may not have the backing of an
actual data member and does have a function to get the type's value if
the property is readable and does have a function associated with it to
set the type's value if the property is writable. This is very close to
the class properties in Python. The difference is that normally a type
must be associated with a property whereas in Python, as I understand
it, the type of a class property is unknown.
Furthermore by a component event I do not mean methods on the event
creator's side but rather an event source. This would look something
like a tuple of callable functions of a particular signature to which an
event sink could add an event handler so that when a particular event
occurred on the event source the event handlers added to the event
source would each be called.
>
As for serializing them,
>>import shelve
>>d = shelve.open('tmp/stuff.shlv')
>>d['person'] = p
>>p = 'hello'
>>p
'hello'
>>p = d['person']
>>p.whoami()
'Sandy'
>>p.age = 42
>>p.whoami()
'Sandy (42)'
>>d['person'] = p
>>d.close()
>>p = 'hello2'
>>p
'hello2'
>>d = shelve.open('tmp/stuff.shlv')
>>p = d['person']
>>p.whoami()
'Sandy (42)'
which seems to work fine for me. This can be used for creating all
sorts of flavors of objects at design time, storing them, and then
restoring them at runtime.
I realize that Python has excellent abilities in all these areas,
including serialization. But a component model for serialization must
not only have the ability of serializing and deserializing all of the
component's data, as well as any base classes, it must also have a means
of allowing the class itself to specify which data needs to be
serialized and which not, as well as allow for the class to seriliaze
all or part of its own data.
Fredrik Lundh wrote:
Edward Diener No Spam wrote:
>There's no doubt that Python's excellent introspection mechanism allows
an outside RAD-like tool to inspect the workings of any Python object.
But that does not make it a component model in my original use of the
term on this thread. A RAD tool needs to know what properties and events
within a class can be manipulated visually, and it needs to be able to
serialize those properties and events so that they are set at run-time
automatically once an object is created.
external serialization was not part of your original definition.
Well, knock me over.
>
I think you have to be a *lot* more concrete here. repeatedly referring to
"some kind of hypothetical property (that isn't a property)" and "some kind
of hypothetical event (that isn't a public method)" and "some kind of hypo-
thetical RAD tool" won't get you anywhere.
My OP was just to query whether a component model existed for Python,
like JavaBeans for Java or .Net for C#, C++/CLI etc. After that came
suggestions of what I thought such a component model was about, which I
thought I answered generally. Not you want details. No doubt next will
come a demand for code.
OK, here is my idea of what such a component model envisages as a list
of items. After this, unless I get some intelligent comments from people
who might be interested in what I envision, or something very similar, I
will be off to investigate it myself rather than do battle with the
horde of people who will just tell me that Python, being a great
language, does not need what I have suggested.
1) Component property: This is a glorified attribute with a type that
can either be specified in a "static" manner, or always be discovered
dynamically, or have converters back and forth between a string and the
actual value represented by the component property. A component property
has a getter function to retrieve the value if it is readable and a
setter function to set the value if it is writable. It must be either
readable or writable or both. A component property is not any Python
class attribute since a component has the right to specify only certain
values as manipulatable in a design-time RAD environment.
2) Component event: This is an type which encapsulates an array, or a
list of callable objects with the same function signature, along with
the functionality to add and remove elements from the array, as well as
cycle through the array calling the callable objects as a particular
event is triggered. A component event is an event source for a
particular event. Component events have to be dicoverable by the Visual
RAD system so that an object's appropriate event handler, an event sink,
can be hooked to the component event itself, an event source, through a
design time interface which propagates the connection at run-time.
3: Component serialization: A component which has its properties and
events set by a visual design-time RAD environment needs to be
serialized at design time and deserialized at run-time. This can be a
default serialization of all component properties and events, or the
component itself can participate in the serilization effort either
wholly or partly.
4) Custom property and component editors: A component editor can present
a property editor or an editor for an entire component which the visual
design-time RAD environment can use to allow the programmer end-user of
the component to set or get component property values. Normally a design
time environment will present default property editors for each
component property type, but a component can override this.
5) Custom type converters: A component should be able to specify a
custom converter for any property to convert, in both directions or
either direction, between the property's string value as seen by a
property editor and the actual value of the component property's type.
This is the general gist of those things which are needed in a visual
Design-time RAD environment.
EdwardMy OP was just to query whether a component model existed for
EdwardPython, like JavaBeans for Java or .Net for C#, C++/CLI
Edwardetc.
For those of us who've never used Java, .Net or C++/CLI, a more concrete
description of what you were after from the beginning would have been
helpful.
Skip
Edward Diener No Spam wrote:
Nick Vatamaniuc wrote:
Edward Diener No Spam wrote:
Michael wrote:
Python does not _need_ a component model just as you don't _need_ a RAD
IDE tool to write Python code. The reason for having a component model
or a RAD IDE tool is to avoid writing a lot of boiler plate code.
Python is terse enough that boiler plate code is not needed, just type
what you need into an editor. It seems that you talk about Python but
you are still thinking in Java or C++.
A RAD IDE tool to hook up components into an application or library (
module in Python ) has nothing to do with terseness and everything to do
with ease of programming. All you are saying is that you don't have a
need for this, but perhaps others do. I don't mind others saying they
have no need or seeing no benefit. But if you have ever used a visual
design-time environment for creating applications you might feel
differently.
"Thinking in Java or C++" as opposed to Python does not mean anything to
me as a general statement. I am well aware of the difference between
statically and dynamically typed languages but why this should have
anything to do with RAD programming is beyond me. Do you care to
elucidate this distinction ?
At the same time one could claim that Python already has certain
policies that makes it seem as if it has a component model. Take a look
at the "magic methods". For example if a class has a __len__ method, it
is possible to use the len() function on an instance of that class. If
a class has the __getitem__ then indexing can be used on that class's
insance. Then Python has properties (see
http://www.python.org/doc/2.2.3/what...rellinks.html). Just by
inspecting the object one can tell a great deal about them (even read
the documentation if needed, by using the __doc__ attribute). What
other standards would you propose for the core language?
Python has great facilities for a component model, much better than the
other languages I use regularly ( C++, C#, Java ). I am not arguing
against that. A component model for RAD tools allows the tool to expose
properties and events to the end-user at design time so that at run-time
the properties and events are automatically setup once an object is
instantiated. The essence of a component model for RAD programming is
how one specifies properties and events for a class to be manipulated by
the RAD tool at design time. Another obvious part of the component model
is how one specifies that the properties and events one sets up at
design-time are serialized so that at run-time they are properly set. A
final element of a component model is the ability of a component to
interact with the environment in which it exists at design time, through
property editors, and at run-time, the latter being obviously more
important for visual controls than non-visual components.
You mention properties (1), events(2) and serialization(3).
1. Python has properties. I had a link in my previous post that pointed
towards some of the features of the new classes, properties are among
them..
2. As for event models -- it seems that Python doesn't have it because
there isn't one best event model. Each application domain will have its
own "best" event model. For example an event model for a network
(distributed) application [think Twisted] will be different than an
event model of a GUI [think wxWidgets]. Implementing an observer
pattern is not that hard in Python. Events could be lists, classes or
strings or anything you desire -- it all depends on your needs. But
there isn't one best-for-all event model out there. If there was one,
everyone would be using it by now.
3. As for serialization -- it exists in Python as well. Look up pickle,
marshaling and shelves.
The reason I said that you don't need a RAD tool in Python is because
Python itself is a RAD tool. Most of the things you mention as
necessary for RAD environment are already in Python! The ones that
aren't can just be specified by you. In other words the developers who
wrote Twisted specified a certain execution and event model and others
can write plugins for it. What you might not have is a common and
popular visual drag-and-drop tool, but you can write it and perhaps
find others who also need it. Who knows, it might turn into a
successful project.
-N.V.
Edward Diener No Spam wrote:
OK, here is my idea of what such a component model envisages as a list
of items. After this, unless I get some intelligent comments from people
who might be interested in what I envision, or something very similar, I
will be off to investigate it myself rather than do battle with the
horde of people who will just tell me that Python, being a great
language, does not need what I have suggested.
[This quote hacked up by me:]
1) Component property: This is a glorified attribute with a type that
a) can be specified in a "static" manner, or discovered dynamically,
b) has converters between a string and the actual value
c) has a getter function to retrieve the value if it is readable and a
setter function to set the value if it is writable.
d) be either readable or writable or both.
e) not any Python class attribute since a component has the right
to specify only certain values as manipulatable in a design-time
RAD environment.
Whenever you say "glorified attribute", your first thought should be
"Python descriptor" (but not your last--it's not a cure-all). They are
able to do all of (a, b, c, d, e) which I marked in your text above.
For example, here's a descriptor for
attributes-you-want-to-persist-in-a-database from my ORM, Dejavu (see http://projects.amor.org/dejavu/brow...nits.py#l290):
class UnitProperty(object):
"""Data descriptor for Unit data which will persist in storage."""
def __init__(self, type=unicode, index=False, hints=None, key=None,
default=None):
self.type = type
self.index = index
if hints is None: hints = {}
self.hints = hints
self.key = key
self.default = default
def __get__(self, unit, unitclass=None):
if unit is None:
# When calling on the class instead of an instance...
return self
else:
return unit._properties[self.key]
def __set__(self, unit, value):
if self.coerce:
value = self.coerce(unit, value)
oldvalue = unit._properties[self.key]
if oldvalue != value:
unit._properties[self.key] = value
def coerce(self, unit, value):
if value is not None and not isinstance(value, self.type):
# Try to cast the value to self.type.
try:
value = self.type(value)
except Exception, x:
x.args += (value, type(value))
raise
return value
def __delete__(self, unit):
raise AttributeError("Unit Properties may not be deleted.")
a) can be specified in a "static" manner, or discovered dynamically,
The "component model" can either scan a class for instances of
UnitProperty or keep a registry of them in the class or elsewhere (via
a metaclass + add_property functions).
b) has converters between a string and the actual value
Note the "coerce" function above. Something similar could be done for
serialization (which I can prove in my case because I use UnitProperty
to help produce SQL ;) but you could just as easily pickle
unit._properties and be done with it.
c) has a getter function to retrieve the value if it is readable and a
setter function to set the value if it is writable.
d) be either readable or writable or both.
Descriptors that only have __get__ are read-only; if they have __set__
they are read-write.
e) not any Python class attribute since a component has the right
to specify only certain values as manipulatable in a design-time
RAD environment.
Right. Descriptors allow the creator of a class to use "normal"
attributes (including functions) which don't participate in the
component model.
2) Component event: This is an type which encapsulates an array, or a
list of callable objects with the same function signature, along with
the functionality to add and remove elements from the array, as well as
cycle through the array calling the callable objects as a particular
event is triggered. A component event is an event source for a
particular event. Component events have to be dicoverable by the Visual
RAD system so that an object's appropriate event handler, an event sink,
can be hooked to the component event itself, an event source, through a
design time interface which propagates the connection at run-time.
This can be accomplished by creating a ComponentEvent descriptor whose
__get__ returns an object with a __call__ method. Here's a base class
for something similar (again, from Dejavu):
class UnitAssociation(object):
"""Non-data descriptor method to retrieve related Units via
attributes."""
to_many = None
def __init__(self, nearKey, farClass, farKey):
# Since the keys will be used as kwarg keys, they must be
strings.
self.nearKey = str(nearKey)
self.farKey = str(farKey)
self.nearClass = None
self.farClass = farClass
def __get__(self, unit, unitclass=None):
if unit is None:
# When calling on the class instead of an instance...
return self
else:
m = types.MethodType(self.related, unit, unitclass)
return m
def __delete__(self, unit):
raise AttributeError("Unit Associations may not be deleted.")
def related(self, unit, expr=None, **kwargs):
raise NotImplementedError
Subclasses override the "related" method, but a ComponentEvent class
could just as easily do:
def run(self, *args, **kwargs):
for sink in self.sinks:
sink(*args, **kwargs)
3: Component serialization: A component which has its properties and
events set by a visual design-time RAD environment needs to be
serialized at design time and deserialized at run-time. This can be a
default serialization of all component properties and events, or the
component itself can participate in the serilization effort either
wholly or partly.
In Dejavu, the UnitProperty class is your "component property" and the
Unit class is the component. The Unit class has a copy method:
def __copy__(self):
newUnit = self.__class__()
for key in self.properties:
if key in self.identifiers:
prop = getattr(self.__class__, key)
newUnit._properties[key] = prop.default
else:
newUnit._properties[key] = self._properties[key]
newUnit.sandbox = None
return newUnit
It wouldn't be hard to replace "newUnit._properties[key] =
self._properties[key]" with "dump(self._properties[key])".
4) Custom property and component editors: A component editor can present
a property editor or an editor for an entire component which the visual
design-time RAD environment can use to allow the programmer end-user of
the component to set or get component property values. Normally a design
time environment will present default property editors for each
component property type, but a component can override this.
This is the hard part. I believe Dabo has done some work in this space,
but this is where the tight coupling comes in between code and tool, a
coupling which Python has traditionally resisted.
5) Custom type converters: A component should be able to specify a
custom converter for any property to convert, in both directions or
either direction, between the property's string value as seen by a
property editor and the actual value of the component property's type.
A ComponentProperty descriptor could include a custom pair of methods
to get/set as string. This is often done in web frameworks which need
to coerce incoming string values to the correct type.
All of which is to say: nobody's done this yet because parts 1, 2, 3
and 5 are trivial to do with descriptors, but actually building a
visual RAD environment is too much work. ;)
Robert Brewer
System Architect
Amor Ministries fu******@amor.org sk**@pobox.com wrote:
EdwardMy OP was just to query whether a component model existed for
EdwardPython, like JavaBeans for Java or .Net for C#, C++/CLI
Edwardetc.
For those of us who've never used Java, .Net or C++/CLI, a more concrete
description of what you were after from the beginning would have been
helpful.
>From vague recollections of the original Java Beans technology, the
primary "innovation" was to have getProperty and setProperty methods,
along with things like isCapability and hasProperty, if I remember
correctly. None of this was really shocking to anyone using Python,
mostly because Python had __getattr__ and __setattr__ even back then
for customising real property/attribute access, and Python's run-time
introspection capabilities were superior to Java's (and probably still
are).
The other innovation was the introduction of standard interfaces for
listening to and dispatching events, where you implement some listener
interface and respond to events in order to "care about" those events.
I don't recall any particularly good mechanisms for connecting beans to
each other in order to fire off events, although the beanbox (or
whatever the graphical tool originally promoted was called) and/or the
IDE is supposed to help you with that part of the work.
The groovy 1990s API is actually viewable in various places; here, for
example: http://www.doc.ic.ac.uk/~jpc1/linux/...-1.0/apis.html
Despite the supposedly exciting advances heralded by Java Beans, a
large part of the technology was just codifying existing practices and
techniques, but it could be argued that such techniques have been
superseded by signal/slot mechanisms and more advanced event
architectures (pioneered by frameworks like Qt and since adopted by
Gtk, I believe).
Paul This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Chuck Spears |
last post by:
Does python have a component model?
I'm currently using delphi and C++ builder to build windows apps and I
am looking to also support linux. They seem to be waffling on their
linux support so I...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
