Python component model

[Diez B. Roggisch]

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

 

[Fredrik Lundh]

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>

 

[Steve Holden]

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

 

[Bruno Desthuilliers]

Marc 'BlackJack' Rintsch wrote:
(snip)
Python itself is a RAD tool.

+1 QOTW

 

[Diez B. Roggisch]

Nope. Things like CORBA and COM do have that property, but e.g. the Java

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)

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

 

[Paul Boddie]

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/contributionDisplay.py?contribId=33&sessionId=41&confId=44

Paul

 

[Steve Holden]

Diez B. Roggisch wrote:
[...]

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

 

[Michael Sparks]

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 ;-)

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).

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.

 

[Guest]

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

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.

 

[Guest]

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.

 

[Richard Brodie]

"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.

 

[Guest]

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.

 

[Guest]

Diez B. Roggisch wrote:
[...]

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.

 

[Guest]

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.

 

[Fredrik Lundh]

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>

 

[Fredrik Lundh]

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>

 

[Guest]

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.

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 ;-)

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).

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.


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.

 

[Tim Chase]

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..... 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

 

[Diez B. Roggisch]

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

 

[Guest]

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.