Python component model

[Nick Vatamaniuc]

Edward Diener No Spam wrote:
> Nick Vatamaniuc wrote:
> > Edward Diener No Spam wrote:
> >> Michael wrote:
> >
> > Python does not _need_ a component model just as you don't _need_ a RAD
> > IDE tool to write Python code. The reason for having a component model
> > or a RAD IDE tool is to avoid writing a lot of boiler plate code.
> > Python is terse enough that boiler plate code is not needed, just type
> > what you need into an editor. It seems that you talk about Python but
> > you are still thinking in Java or C++.
>
> A RAD IDE tool to hook up components into an application or library (
> module in Python ) has nothing to do with terseness and everything to do
> with ease of programming. All you are saying is that you don't have a
> need for this, but perhaps others do. I don't mind others saying they
> have no need or seeing no benefit. But if you have ever used a visual
> design-time environment for creating applications you might feel
> differently.
>
> "Thinking in Java or C++" as opposed to Python does not mean anything to
> me as a general statement. I am well aware of the difference between
> statically and dynamically typed languages but why this should have
> anything to do with RAD programming is beyond me. Do you care to
> elucidate this distinction ?
>
> >
> > At the same time one could claim that Python already has certain
> > policies that makes it seem as if it has a component model. Take a look
> > at the "magic methods". For example if a class has a __len__ method, it
> > is possible to use the len() function on an instance of that class. If
> > a class has the  __getitem__ then indexing can be used on that class's
> > insance. Then Python has properties (see
> > http://www.python.org/doc/2.2.3/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.

You mention properties (1), events(2) and serialization(3).

1. Python has properties. I had a link in my previous post that pointed
towards some of the features of the new classes, properties are among
them..

2. As for event models -- it seems that Python doesn't have it because
there isn't one best event model. Each application domain will have its
own "best" event model. For example an event model for a network
(distributed) application [think Twisted] will be different than an
event model of a GUI [think wxWidgets].  Implementing an observer
pattern is not that hard in Python. Events could be lists, classes or
strings or anything you desire -- it all depends on your needs. But
there isn't one best-for-all  event model out there. If there was one,
everyone would be using it by now.

3. As for serialization -- it exists in Python as well. Look up pickle,
marshaling and shelves.


The reason I said that you don't need a RAD tool in Python is because
Python itself is a RAD tool. Most of the things you mention as
necessary for RAD environment are already in Python! The ones that
aren't can just be specified by you. In other words the developers who
wrote Twisted specified a certain execution and event model and others
can write plugins for it.  What you might not have is a common and
popular visual drag-and-drop tool, but you can write it and perhaps
find others who also need it. Who knows, it might turn into a
successful project.

-N.V.