Python component model

[Peter Wang]

Edward,

This isn't in response to any specific one of the 100+ posts on this
thread, but I justed wanted to encourage you to continue your
investigation into Python component models and maybe looking for some
common ground between them. Frequently the individual developers are
too heads-down on working on their own things to do a broad survey, so
I think this would be very useful indeed.

I wouldn't have felt it necessary to post this except for the large
number of posts along the lines of "foo.dict is introspective enough
for me!". I think you might have an easier time evangelizing the
principle of component-oriented programming (or "event-based", or
"reactive", or whatever) if you separated it from the notions of RAD UI
development. There is a very large difference between writing
components and writing objects, and it seems that most people arguing
"python doesn't need components" don't see this distinction.

For me, it's the difference between writing "live" objects and "dead"
objects. Live objects not only encapsulate implementations of an
interface with some state, but they also encapsulate handling of
events, i.e. responses to changes in their environment. Dead objects
have methods but there has to be a function somewhere that knows which
dead object to call with what parameters at exactly the right time.
(The only mechanism for managing this complexity is to create ever more
functions at ever higher levels of abstraction, or to have a
proliferation of nebulously-defined "manager" objects.) IMHO once you
cross this chasm and are able to model your problem domain with live
objects that go off and automatically respond to the runtime
environment and Do the Right Thing, it's very hard to go back to a dead
object mindset. I can understand, however, that until one makes this
leap, it might seem like an academic and useless distinction.


-peter

 

[Peter Wang]

looks interesting.
Thanks!

what about persistency?

Um... what about it?

 

[Steve Holden]

I'm not at the cutting edge here: 20j and 20k are the commands (replace
20 with another suitable amount) which help me jump around in my editor
of choice. The other commands which may be more effective just aren't
in my "working set".

You *might* find CTRL/U and CTRL/D helpful ...

regards
Steve

 

[Bruno Desthuilliers]

Peter Maas wrote: [...]

a reference implementation for web programming as part of the standard
library,

wsgiref is part of the 2.5 stdlib.

Yes, but it's not an implementation. Think of something like Tomcat for
the Java Servlet Specification.

Then I'd vote for paste.

 

[Bruno Desthuilliers]

Aw, come on. The Python web programming standardisation wars are over, for now.
There's Django, and there's TurboGears,

And there's Pylons...

 

[Fredrik Lundh]

And there's Pylons...

and a zillion other more or less interesting research projects. I don't see any traces
of the kind of ecosystems and market awareness that exist for Zope, Django, and
TurboGears (or for that matter, Rails and Mason), for any other Python web pro-
gramming tool.

</F>

 

[Paul Boddie]

You *might* find CTRL/U and CTRL/D helpful ...

Sure, even Page Up and Page Down work on decent distributions. But
there's a huge collection of other commands waiting to be discovered
too. I may never know them all, however. ;-)

Paul

 

[Paul Rubin]

and a zillion other more or less interesting research projects. I don't see any traces
of the kind of ecosystems and market awareness that exist for Zope, Django, and
TurboGears (or for that matter, Rails and Mason), for any other Python web pro-
gramming tool.

Twisted?

 

[Bruno Desthuilliers]

and a zillion other more or less interesting research projects.

I don't think Pylons qualifies as a "research project". FWIW, I
mentionned it because, while (yet) less "buzzworded" than Django and TG,
it's really in the same category - but using the wsgi stack approach
instead of the monolithic one. And MHO is that it could really become
the next big thing in Python's web programming ecosystem.

I don't see any traces
of the kind of ecosystems and market awareness that exist for Zope, Django, and
TurboGears (or for that matter, Rails and Mason), for any other Python web pro-
gramming tool.

Yes, true.

 

[val bykoski]

Edward,

This isn't in response to any specific one of the 100+ posts on this
thread, but I justed wanted to encourage you to continue your
investigation into Python component models and maybe looking for some
common ground between them. Frequently the individual developers are
too heads-down on working on their own things to do a broad survey, so
I think this would be very useful indeed.

I wouldn't have felt it necessary to post this except for the large
number of posts along the lines of "foo.dict is introspective enough
for me!". I think you might have an easier time evangelizing the
principle of component-oriented programming (or "event-based", or
"reactive", or whatever) if you separated it from the notions of RAD UI
development. There is a very large difference between writing
components and writing objects, and it seems that most people arguing
"python doesn't need components" don't see this distinction.

For me, it's the difference between writing "live" objects and "dead"
objects. Live objects not only encapsulate implementations of an
interface with some state, but they also encapsulate handling of
events, i.e. responses to changes in their environment. Dead objects
have methods but there has to be a function somewhere that knows which
dead object to call with what parameters at exactly the right time.
(The only mechanism for managing this complexity is to create ever more
functions at ever higher levels of abstraction, or to have a
proliferation of nebulously-defined "manager" objects.) IMHO once you
cross this chasm and are able to model your problem domain with live
objects that go off and automatically respond to the runtime
environment and Do the Right Thing, it's very hard to go back to a dead
object mindset. I can understand, however, that until one makes this
leap, it might seem like an academic and useless distinction.

-peter

Excellent post, Peter. Thanks for great clarification. Looking from a
physicist' perspective, im always trying to compare/evaluate languages
from "the physical reality/dynamics" angle. So, the run-time
space/dynamics is the only one that matches the natural "always-runtime"
objects - atoms, molecules, EM fields, biological cells(?). It is the
*reactive* world with event/forces-driven dynamics. Seemingly, there is
nothing beyond that, including biology.

The essential feature of that runtime world is the persistence or (in
physical terms) the built-in memory/storage mechanism (soft degrees of
freedom), so that an event (and response to it) changes the object. The
persistence is obvious in biology, but also is very important in
(bio)molecular dynamics. From that physics/QM angle, a generic
("always-live") object which learns the environment (by building *and
updating* its responses) seems to be a quite adequate representation for
a real physical object. But this seems to be already available in
Python, right?

The Enthought' Traits that describes (physical) properties and their
dynamics seems to be a critically important component of that vision,
and i admire the Enthought' people vision and practical efforts. Keep
on and good luck!
run-time-ly, y'rs

Val
Air Force Research Lab
Hanscom AFB, MA
(e-mail address removed)

 

[Peter Decker]

Thanks for the hint, Peter. I've heard of Dabo and it's on my list of
things to be inspected. Perhaps my postings have been misunderstood. I don't
feel uneasy with Python. I'm using it since 4 years and know how to find
the tools I need. But I feel uneasy with an excessive readiness of some
c.l.p participants to accept Python as it is and even to react defiantly
on friendly suggestions how to make Python a more obvious choice for
newcomers. I think this is important for Python's survival.

I think that Python is a 3GL. Dabo is a 4GL version of Python, in that
its UI is part of its core API.

Dabo is written by people with visual tools backgrounds, and they are
definitely aiming toward that market. They are looking to the same
niche that Visual Basic, Visual FoxPro, Filemaker, Delphi, and other
similar products are addressing.

 

[Kay Schluehr]

Excellent post, Peter. Thanks for great clarification. Looking from a
physicist' perspective, im always trying to compare/evaluate languages
from "the physical reality/dynamics" angle. So, the run-time
space/dynamics is the only one that matches the natural "always-runtime"
objects - atoms, molecules, EM fields, biological cells(?). It is the
*reactive* world with event/forces-driven dynamics. Seemingly, there is
nothing beyond that, including biology.

A more conventional notion is that of static/dynamic properties of a
language. Component models that guarantee certain properties at compile
time are easily checked for consistency but to many programmers ( I
guess most of the programmers who attend to this list ) they are
inflexible: you might change or adapt your components according to
events, switch between entities, enable dynamic configuration etc. This
can be achieved in C++, Java etc. as well but not without pain.

BTW as a physicist you try to understand the "laws" i.e. the
mathematical structure behind all these diverse activities. Once you
understood the mathematical structure completely and fill it with
inital- or boundary value parameters ( the code ) you know everything
about its "static behaviour" i.e. nature is turned into a logical
system ( measurement problem of QM aside ) where you deduce all future
events. But this constitutes only one half of modern science. The other
one is the experimental method. As far as I can say CS sticks currently
to the pre-Galilean metaphysics of a good god ( a good programmer /
engineer ) trying to establish systems that shine within the light of
formal purity. Although this has little relevance and not much to to
with the trilllions LOC all around us and instead of adjusting their
worldview CS academics tend to ponder about the "software crisis",
critizise industry for ignoring them and dismiss programmers who use
weird languages like Python without good formal properties. As you
already guess the lack of the experimental method does not even lead to
establishing some formality ( by means of hypothetic deductions in the
sense of Popper ) within basically informal ( untyped ) systems but to
succeedingly failed attempts of pre-established harmonies.

 

[Guest]

Traits is frighteningly similar to the requirements that you laid out
in your post (the example for Skip), including delegates! I would like
to point out, however, that traits is a *general* component framework
for python that facilitates implementing the observer pattern and a
higher level of introspection. It can be used to build applications
that have no visual interfaces at all, but wish to benefit from the
"reactive programming" style that componentized, event-based
programming encourages. (induces?)

Thanks for the explanation. I was too quick in seeing Traits as only a
version of properties without realizing that it included much more.

Traits UI, which Robert only alluded to, is actually very much the sort
of RAD environment you have described. It builds upon the component
model, and uses introspection to automagically create nice widgets for
your model, but adds mechanisms for specifying controllers, customizing
behavior, and generically composing complicated forms from simpler
ones. There is even a visual "builder" tool for it called VET that
closely resembles Delphi/C++ Builder. (The VET itself is, of course,
written using Traits UI.)

I have downloaded both Traits and Traits UI and will look at both.

Envisage, the plugin application framework, can use the traits
component models and the TraitsUI interfaces to roll out very dynamic
applications, whose underlying models are all live components that can
be scripted, twiddled with from an embedded Python shell, etc.


Please contribute ideas or ask conceptual questions!

It would be easier for me if you could get an NG somewhere for
Enthought, perhaps on GMane, since I always find mailing lists much more
clunky than a good NG. But that is up to Enthought.

Oh, and disclaimer: I also work at enthought.

That's fine. It is the ideas about a PME component model for Python in
which I was interested, no matter where it originates. Thanks for the
encouraging reply.

 

[Guest]

A more conventional notion is that of static/dynamic properties of a
language. Component models that guarantee certain properties at compile
time are easily checked for consistency but to many programmers ( I
guess most of the programmers who attend to this list ) they are
inflexible: you might change or adapt your components according to
events, switch between entities, enable dynamic configuration etc. This
can be achieved in C++, Java etc. as well but not without pain.

Having "static" properties and events is necessary for visual RAD
programming environments, where connections are being setup between
events and event handlers, and properties are being initialized, at
design time. This does not preclude the normal "dynamic" attributes of
Python. However if Python programmers reject such visual RAD programming
environments as having any value, then they probably won't be interested
in a common component model for them.

 

[Steve Holden]

Having "static" properties and events is necessary for visual RAD
programming environments, where connections are being setup between
events and event handlers, and properties are being initialized, at
design time. This does not preclude the normal "dynamic" attributes of
Python. However if Python programmers reject such visual RAD programming
environments as having any value, then they probably won't be interested
in a common component model for them.

Such a model would definitely have value (particularly if all tool
builders subscribed to it: that was how Beans achieved ubiquity).

But there is no such model at the moment. A project to create one might
receive support or it might not. There's one way to find out ...

regards
Steve

 

[Roel Schroeven]

Edward Diener No Spam schreef:

It would be easier for me if you could get an NG somewhere for
Enthought, perhaps on GMane, since I always find mailing lists much more
clunky than a good NG. But that is up to Enthought.

FYI: you don't necessarily depend on Enthought for that; anyone can ask
Gmane to add a mailing list to their gateway via the form at
http://gmane.org/subscribe.php

 

[Ilias Lazaridis]

But not quite yet, it appears. "A public release is planned shortly"

Thank you for you comment.

You are right.

I've not yet selected the license yet (this case is quite complex):

http://case.lazaridis.com/wiki/License

But I've placed a BSD2 license to the existent files:

http://dev.lazaridis.com/base/browser/infra

..

 

[Ilias Lazaridis]

Um... what about it?

"
As far as I can see, there's no persistency binding available.

Is one planned?
"
http://groups.google.com/group/comp.lang.python/msg/dbdaedc68eee653a

..

 

[Peter Wang]

"
As far as I can see, there's no persistency binding available.

Is one planned?
"
http://groups.google.com/group/comp.lang.python/msg/dbdaedc68eee653a

This thread was just some name-calling between you and Robert Kern, but
didn't really provide any details.

I guess I'm too dumb to understand the question... Does pickle not work
for you? What is a "persistency binding"?

-peter

 

[Ilias Lazaridis]

This thread was just some name-calling between you and Robert Kern, but
didn't really provide any details.

I've just asked about persistency.

No names called from my side.

I guess I'm too dumb to understand the question... Does pickle not work
for you? What is a "persistency binding"?

I think I got my answer.

Thank's for your responses.

..