Python component model

[Edward Diener No Spam]

Re: Python component model

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.

[Robert Kern]

Re: Python component model

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
>>automagical ly 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

[Nick Vatamaniuc]

Re: Python component model


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?

[Paul Rubin]

Re: Python component model

"Nick Vatamaniuc" <vatamane@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.

[Fredrik Lundh]

Re: Python component model

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>

[Diez B. Roggisch]

Re: Python component model

Paul Rubin schrieb:

"Nick Vatamaniuc" <vatamane@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

[Fredrik Lundh]

Re: Python component model

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>

[Steve Holden]

Re: Python component model

Diez B. Roggisch wrote:

Paul Rubin schrieb:
>

>>"Nick Vatamaniuc" <vatamane@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

[Bruno Desthuilliers]

Re: Python component model

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 'onurb@xiludom. gro'.split('@')])"

[Diez B. Roggisch]

Re: Python component model

>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

[Paul Boddie]

Re: Python component model

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

Paul

[Steve Holden]

Re: Python component model

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

[Michael Sparks]

Re: Python component model

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

[Edward Diener No Spam]

Re: Python component model

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.

[Edward Diener No Spam]

Re: Python component model

Paul Rubin wrote:

"Nick Vatamaniuc" <vatamane@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.