Python component model

[Guest]

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 ?

 

[Marc 'BlackJack' Rintsch]

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

 

[skip]

Edward> The definition of a component model I use below is a class which
Edward> allows properties, methods, and events in a structured way which
Edward> can be recognized, usually through some form of introspection
Edward> outside of that class. This structured way allows visual tools
Edward> to host components, and allows programmers to build applications
Edward> and libraries visually in a RAD environment.

...
Edward> I believe that Python should have a common components model for
Edward> all RAD development environments, as that would allow the Python
Edward> programmer to create a set of classes representing components
Edward> which 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

 

[Echo]

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 ?

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

 

[Guest]

Edward> The definition of a component model I use below is a class which
Edward> allows properties, methods, and events in a structured way which
Edward> can be recognized, usually through some form of introspection
Edward> outside of that class. This structured way allows visual tools
Edward> to host components, and allows programmers to build applications
Edward> and libraries visually in a RAD environment.

...
Edward> I believe that Python should have a common components model for
Edward> all RAD development environments, as that would allow the Python
Edward> programmer to create a set of classes representing components
Edward> which 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.

 

[Chaz Ginger]

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.

 

[Guest]

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.

 

[Guest]

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 ?

 

[Daniel Nogradi]

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

 

[sjdevnull]

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/

 

[Robert Kern]

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/listinfo/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

 

[goon]

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]

 

[Guest]

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/listinfo/enthought-dev

Already subscribed. Thanks !

 

[Guest]

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.

 

[Michael]

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/Examples/SimplestPresentationTool.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/screenshots/KamaeliaOpenGL.png (example
of putting components in places they don't realise)
* http://kamaelia.sourceforge.net/screenshots/AxonVisualiser.png

Regards,


Michael.

 

[Guest]

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/Examples/SimplestPresentationTool.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/screenshots/KamaeliaOpenGL.png (example
of putting components in places they don't realise)
* http://kamaelia.sourceforge.net/screenshots/AxonVisualiser.png

Thanks for all the link regarding kamaelia.

 

[Robert Kern]

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

 

[Nick Vatamaniuc]

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/Examples/SimplestPresentationTool.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/screenshots/KamaeliaOpenGL.png (example
of putting components in places they don't realise)
* http://kamaelia.sourceforge.net/screenshots/AxonVisualiser.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/whatsnew/sect-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?

 

[Paul Rubin]

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.

 

[Fredrik Lundh]

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>