Re: Python component model
sturlamolden wrote: There is a whole generation of computer users out there scared stiff of using the keyboard. Soon, computers will not have a keyboard at all. The trend is perhaps more pronounced among managers not writing code themselves, but taking decisions about which tools to use. Is it just me, or does someone else feel that this is like using magnetic letters on a refrigerator door instead of a pen and paper. My two year old son thinks those magnetic letters are fun, but then he can't write at all. My seven year old has certainly switched to pen and paper (or computer) for 99% of his writing. Sure, they have their use--it might be more effective to write TENNIS with colorful letters across the fridge door in some situation, but most of the time, pen and paper is much more useful. You never run out of letters, and it's easy to draw lines or arrows, complement the text with a little picture etc. The cost for learning the skill to write readable letters is well compensated for... We recently released a toolkit for interfacing our systems with legacy systems, and very soon, people started using it in way we had never expected. I suppose that could be possible with a visual tool too, but it seems to me that those tools are typically fairly limited, just as computer based role-playing games are much more limited than the ones played around a table with a good flesh-and-blood game master who can respond to any idea you come up with at the spur of the moment. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
In article [EMAIL PROTECTED], Peter Wang [EMAIL PROTECTED] wrote: ... 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. I'm not disagreeing with the blessings of components reacting to events and going off Doing the Right Thing. However, there is a huge with components going off Doing the Wrong Thing. It becomes exceedingly hard to debug for several reasons. The first one is that it is difficult to trace the callbacks generated, since the point where they were registered is no longer trackable when your problem occurs. The second and most serious problem is that erroneous behaviour in two components can interact in extremely mysterious ways that are really difficult to debug. In part these problems can be reduced by much rigorous testing of each component than is the norm today, but for the really tough problems we need tools that have not been invented yet, that track the history of each callback. Since these tools have to understand the details of the calling conventions and registration mechanism for events, they have to be custom built for each component framework and should therefore be part of the framework distribution. Jacob Hallén -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
[EMAIL PROTECTED] wrote: Having never used java or .NET I'm not sure what you're looking for. There is a whole generation of computer users out there scared stiff of using the keyboard. Soon, computers will not have a keyboard at all. The trend is perhaps more pronounced among managers not writing code themselves, but taking decisions about which tools to use. The answer to these needs are so-called RAD tools like Borland Delphi, Visual Basic, Visual C# .NET, and perhaps Java's NetBeans. Instead of writing code, a programmer selects components from a menu, drags the component over a form and then drops it onto the form. A form can e.g. be a web page, a GUI window or just an invisible abstract container in case the program doesn't have a visual interface. Components can be visual GUI widgets like buttons and sliders, but also invisible objects like files and sockets. Instead of creating a file by typing open one would drag 'n drop a file component from a menu onto the form, and then type in the name in some sort of property menu for the component. If one needs a tcp socket, one don't type s = socket(...) in the code but select an socket from a menu and drop it over a form. In order to do this, a RAD tool need some sort of standardised component model. Sure, it must be able to inspect the component, but also interpret the methods and members that it finds. The RAD tool must be able to inspect the model to find out what to publish in the property menu, what event it generates, etc. Typical component standards used for this is ActiveX (in Visual Basic), .NET in Visual C#, VCL in Delphi, and JavaBeans in NetBeans. If you build a component that does not follow the standard, the RAD tool can't use it. For example in JavaBeans, every pair of method that looks like component.setSomething(...) and component.getSomething(...) is parsed by the RAD tool as the property Something and put into the property meny for the component. The programmer can change the value of this property by typing into the property menu. The most extreme RAD tool is LabView, where no code is written at all, not even event handlers which are still hand coded in the other RAD tools. In labView, everything is dragged and dropped, and the dropped components are connected by cables just like a circuit board. There are even components encapsulating for and while loops. If you need a while loop, you drop a while loop onto the form. If you need a subroutine, you drop a subroutine onto the form, etc. Nothing is typed. Does Python need a standard component model like ActiveX, VCL, .NET or JavaBeans? First, there are GUI designer's for Python. These include GLADE, QT Designer and wxGlade. We don't need a Python object model to support GUI designers. Second, are we really that scared of writing code? Some obviously are. Why is dropping a socket component preferred over typing socket? Those that want LabView or Visual Basic knows where to find it. Python already has properties. What Python don't have is events, but that can be easily implemented (and is implemented in all GUI toolkits) e.g. using exceptions and references to functions. En event can be raised by raising an exception. Perhaps we should define an standard event interface just to shut them up? Then we have a component model. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Terry Reedy wrote: Ilias Lazaridis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I share the infrastructure which I use: http://dev.lazaridis.com/base 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 . -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Wang wrote: Ilias Lazaridis wrote: looks interesting. Thanks! what about persistency? 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 . -- http://lazaridis.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Ilias Lazaridis wrote: Peter Wang wrote: Ilias Lazaridis wrote: what about persistency? 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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Wang wrote: Ilias Lazaridis wrote: Peter Wang wrote: Ilias Lazaridis wrote: what about persistency? 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 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. . -- http://case.lazaridis.com/wiki/Stack -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
val bykoski wrote: Peter Wang wrote: 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Wang wrote: Edward Diener wrote: 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. 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. Already subscribed. Thanks ! 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Kay Schluehr wrote: val bykoski wrote: Peter Wang wrote: 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Edward Diener No Spam wrote: Kay Schluehr wrote: val bykoski wrote: Peter Wang wrote: 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. 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. 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 -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
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 -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Maas wrote:
Bruno Desthuilliers wrote:
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
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh wrote:
Paul Boddie wrote:
Meanwhile, the Web programming standardisation scene remains
stagnant.
Aw, come on. The Python web programming standardisation wars are over, for
now.
There's Django, and there's TurboGears,
And there's Pylons...
and there's Zope 2/3, all with slightly different
approaches, and slightly different target audiences. Unless you're doing
really odd things,
one of these will be more than good enough for your application.
(as for WSGI, it's plumbing. You can of course build fun things from spare
parts and
plumbing, and there are really interesting things going on in certain
research labs, as usual,
but if you want turn-key stuff, pick one of the big three.)
/F
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Bruno Desthuilliers wrote: Meanwhile, the Web programming standardisation scene remains stagnant. Aw, come on. The Python web programming standardisation wars are over, for now. There's Django, and there's TurboGears, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Steve Holden wrote: Paul Boddie wrote: 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 ... 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh [EMAIL PROTECTED] writes: 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh wrote:
Bruno Desthuilliers wrote:
Meanwhile, the Web programming standardisation scene remains
stagnant.
Aw, come on. The Python web programming standardisation wars are over, for
now.
There's Django, and there's TurboGears,
And there's Pylons...
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.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Wang wrote: 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 [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
On 10/12/06, Peter Maas [EMAIL PROTECTED] wrote: Peter Decker wrote: I think you should take a good look at Dabo and the visual tools they are creating. 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. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Ilias Lazaridis wrote: http://dabodev.com http://case.lazaridis.com/wiki/DaboAudit Who. Cares. What. You. Think? -- Erik Max Francis [EMAIL PROTECTED] http://www.alcyone.com/max/ San Jose, CA, USA 37 20 N 121 53 W AIM, Y!M erikmaxfrancis Love is, above all, the gift of oneself. -- Jean Anouilh -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Maas wrote: Paul Boddie wrote: People who bring up stuff about self and indentation are just showing their ignorance, in my opinion, since Python isn't the first language to use self in such a way, and many C++ and Java programs use this pervasively in order to make attribute scope explicit, whereas the indentation matter is only troublesome with bad editing practices. I don't think the community should spend any more time on these criticisms. How many programmers don't use Python because of the self issue? The only reason I know why self shall not be inforced is reducing the number of troll postings. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Erik Max Francis wrote: http://dabodev.com http://case.lazaridis.com/wiki/DaboAudit Who. Cares. What. You. Think? his mom? /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Ilias Lazaridis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I share the infrastructure which I use: http://dev.lazaridis.com/base But not quite yet, it appears. A public release is planned shortly -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Kay Schluehr wrote:
Peter Maas wrote:
How many programmers don't use Python because of the self issue?
The only reason I know why self shall not be inforced is reducing the
number of troll postings.
The only method that works to reduce the number of troll postings is:
spot them, then ignore them.
But some lengthy threads in c.l.p suggest that quite a few c.l.p
participants enjoy conversation with trolls or are slow at spotting :)
--
Regards/Gruesse,
Peter Maas, Aachen
E-mail 'cGV0ZXIubWFhc0B1dGlsb2cuZGU=\n'.decode('base64')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Decker wrote:
I think you should take a good look at Dabo and the visual tools they
are creating.
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.
--
Regards/Gruesse,
Peter Maas, Aachen
E-mail 'cGV0ZXIubWFhc0B1dGlsb2cuZGU=\n'.decode('base64')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Paul Boddie [EMAIL PROTECTED] wrote: People who bring up stuff about self and indentation are just showing their ignorance Ouch. That stings. Python's indentation determines scope makes it hard for me to discuss Python via mediums like IRC and instant messengers. It also makes it hard to quickly jump to the top and/or bottom of code blocks in most editors I use on a day to day basis. I guess I'm just ignorant. :( -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Ed Jensen wrote: Paul Boddie [EMAIL PROTECTED] wrote: People who bring up stuff about self and indentation are just showing their ignorance Ouch. That stings. Python's indentation determines scope makes it hard for me to discuss Python via mediums like IRC and instant messengers. True, especially with the helpful first line indentation in some messengers. It also makes it hard to quickly jump to the top and/or bottom of code blocks in most editors I use on a day to day basis. 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. I guess I'm just ignorant. :( Don't be too hard on yourself, Ed! I was really referring to people who make a big advocacy issue out of self (eg. Python isn't object-oriented - it has self parameters!) and indentation (eg. Python's just like Fortran!). You're just pointing out the issues that regrettably make communication of Python programs difficult. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Edward Diener wrote: 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. 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?) 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.) 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. Already subscribed. Thanks ! Please contribute ideas or ask conceptual questions! Oh, and disclaimer: I also work at enthought. :) -peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Ilias Lazaridis wrote: looks interesting. Thanks! what about persistency? Um... what about it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Paul Boddie wrote: 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 -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Hendrik van Rooyen wrote: Fredrik Lundh [EMAIL PROTECTED] wrote: 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. 8 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. not sure if its trivial - but agree about the generality - my meat is your poison effect operating here - and also - standards are not per se a *Good Thing* - they stifle both inventiveness and diversity... - Hendrik Culture matters. Some things exist below a certain level of visibility and are quite evident for their practitioners but hardly recognized by anyone else. http://bitworking.org/news/Why_so_many_Python_web_frameworks There is not even a name for this kind of coherent diversity and at least Python doesn't brand it in any way. Maybe Pythons obvious one way to do it credo is more harmfull to the community as a whole than not having invented RoR. Python is ironically not proofed by hype which always favours a cyclopic universe of a single true solution. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Maas wrote:
Bruno Desthuilliers schrieb:
Marc 'BlackJack' Rintsch wrote:
(snip)
Python itself is a RAD tool.
+1 QOTW
No, please stop self-assuring, self-pleasing QOTWs!
Certainly not !-)
(snip)
I for my part would be happy to see a Delphi-like RAD tool for Python,
Look for boa-constructor then.
a reference implementation for web programming as part of the standard
library,
wsgiref is part of the 2.5 stdlib.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Maas wrote: Bruno Desthuilliers schrieb: Marc 'BlackJack' Rintsch wrote: (snip) Python itself is a RAD tool. +1 QOTW No, please stop self-assuring, self-pleasing QOTWs! +1 QOTW! ;-) [Java, Ruby, JRuby, the hype] To prevent this to happen parts of the Python community should have a more critical attitude to the language. Too often I hear the same mantras being repeated over and over again (GIL, self, IDE etc.). People who bring up stuff about self and indentation are just showing their ignorance, in my opinion, since Python isn't the first language to use self in such a way, and many C++ and Java programs use this pervasively in order to make attribute scope explicit, whereas the indentation matter is only troublesome with bad editing practices. I don't think the community should spend any more time on these criticisms. However, the GIL and issues of tools and IDEs should be considered in a more sophisticated way. I'm not advocating the removal of the GIL, but there needs to be a better story for people wanting to use more than one core or CPU within a single program on a multicore/multiprocessor system. My contribution in that field has been the pprocess module [1] which lets you play in a sort of multithreaded environment, although you're actually using multiple processes whose globals are only shared in a read-only sense, and the way forward may be to make this available to Windows users by adding an os.fork implementation for them to the standard library, as I suggested previously [2]. Meanwhile, whilst not an IDE advocate myself, there really does need to be further improvements in the analysis of Python source code so that people can build improved tools to check Python programs for obvious compile-time errors and to inspect the behaviour of large amounts of code. One reads occasionally on the python-dev or python-3000 mailing lists that some proposed change or other may or may not have an impact on real world systems such as the standard library, but that no-one can really say: we need to move beyond the Python is just so dynamic meme and develop tools like PyLint and PyChecker much further. I don't say these mantras are all wrong but perhaps it would be good to remove the GIL just to stop people talking about Python's lack of multi-threading or polish Python's class syntax to stop people talking about Python's OO being bolted on etc. Programmers often choose their languages by very silly reasoning (silliest being the indentation issue) and maybe we should take the silliness into account instead of laughing about those silly folks. This kind of stuff can be tackled by providing better introductory, educational or promotional material, with the latter especially important to stop the uninformed rubbishing that advocates of certain other languages seem particularly inclined to indulge in. I for my part would be happy to see a Delphi-like RAD tool for Python, a reference implementation for web programming as part of the standard library, Jython 2.5, Python for PHP or whatever attracts new programmers. As I noted in the Python component model thread [3], tools like Qt Designer seem to go a long way towards providing RAD-like solutions, even though they aren't pure Python. Meanwhile, the Web programming standardisation scene remains stagnant. Sure, you can pretend that WSGI middleware is the future, and even I can see that layering components is an acceptable way of building Web applications, but I'm not using WSGI to do that because the whole exercise requires multiple trips to the Web technology supermarket (once for a server, again for a server adapter, again for stuff to make the WSGI API bearable, and so on, repeat when you find one or more components to be immature) and I doubt that people shopping around for an easy way to write applications are especially convinced either. But I largely agree with what you've written, and the cause of the symptoms is the excessive focus on changing the language rather than improving the libraries, the tools and the peripheral elements of the development experience. If you think the standard library is incoherent, jump into the proposal I've been writing [4] to suggest improvements and to help out, because this kind of work isn't going to happen otherwise, unfortunately. Returning to the lack of Python books, it's rather telling that a review of Python in a Nutshell that just caught my eye says the following: Considering that the Zen of Python is barely being followed as the core language has feature upon feature heaped upon it, a book like this helps poor programmers simply wanting to use the language keep up with the changes. I know that certain other languages aren't exactly unchanging (and may possibly undergo further upheaval), and that publishers like having more books to sell on the very same topic, but after a while both authors and readers become tired of having to respectively write/update or buy new
Re: Python component model
Paul Boddie wrote: Meanwhile, the Web programming standardisation scene remains stagnant. Aw, come on. The Python web programming standardisation wars are over, for now. There's Django, and there's TurboGears, and there's Zope 2/3, all with slightly different approaches, and slightly different target audiences. Unless you're doing really odd things, one of these will be more than good enough for your application. (as for WSGI, it's plumbing. You can of course build fun things from spare parts and plumbing, and there are really interesting things going on in certain research labs, as usual, but if you want turn-key stuff, pick one of the big three.) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh wrote: Paul Boddie wrote: Meanwhile, the Web programming standardisation scene remains stagnant. Aw, come on. The Python web programming standardisation wars are over, for now. Well, that's just another way of saying that the scene remains stagnant, because I don't see any winners. There's Django, and there's TurboGears, and there's Zope 2/3, all with slightly different approaches, and slightly different target audiences. Unless you're doing really odd things, one of these will be more than good enough for your application. I didn't deny that various frameworks would be good enough for various things (indeed, I didn't even mention them), and I personally think that Django seems like a decent enough solution, even though it (or its documentation) focuses on ORM+RDBMS-based applications - a focus that wouldn't suit a number of applications I've worked on. The thing is that people want a coherent message about Python and Web programming. It doesn't have to be use only this and nothing else but it should help them make a good but quick decision. For a long time people expected to get this coherent message by looking for solutions provided with the Python distribution itself - after all, the standard library has provided other useful batteries over the years - but all we had was the cgi module and some barely maintained servers. Indeed, the standard library looks pretty incoherent itself these days. But there's a huge gap between what's on offer via the standard library and the most popular full-stack frameworks, and the choice of starting with WSGI middleware or swallowing Zope development whole, for example, must be something of a demotivator for newcomers - why else do people still ask CGI-related questions on comp.lang.python? What's interesting is that one of the Django pioneers advocated better standards way back in 2003 [1], possibly indicating a preference for the rising tide floats more boats philosophy that would help Python itself become a more popular tool for Web development, rather than some framework doing a Zope and, in a few years, having its community members argue amongst themselves about why Python developers don't like them any more. It'd be interesting to hear whether the same attitude still holds sway after Django's more recent success. (as for WSGI, it's plumbing. You can of course build fun things from spare parts and plumbing, and there are really interesting things going on in certain research labs, as usual, but if you want turn-key stuff, pick one of the big three.) After seeing WSGI being elevated to non-plumbing (since plumbing is just stuff that helps other stuff to work, not something you mess with on a daily basis), I think the current strategy with respect to floating more boats is to pretend that WSGI is all you need. In which case, we might as well start looking at documentation like this instead... http://www.erlang.org/doc/doc-5.5.1/lib/inets-4.7.5/doc/html/mod_esi.html Paul [1] http://mail.python.org/pipermail/web-sig/2003-October/03.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh [EMAIL PROTECTED] writes: one, two, overflow ? or are you saying that the lack of a monopoly means market stagnation, no matter how innovative the three big ones are ? It worked for Ruby on Rails... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Paul Boddie wrote: Aw, come on. The Python web programming standardisation wars are over, for now. Well, that's just another way of saying that the scene remains stagnant, because I don't see any winners. one, two, overflow ? or are you saying that the lack of a monopoly means market stagnation, no matter how innovative the three big ones are ? For a long time people expected to get this coherent message by looking for solutions provided with the Python distribution itself - after all, the standard library has provided other useful batteries over the years - but all we had was the cgi module and some barely maintained servers. Indeed, the standard library looks pretty incoherent itself these days. the standard library has never included non-trivial applications (and the three big ones are configurable applications, not libraries). I'm not sure anyone has ever looked to the standard library for domain-specific applications or toolkits. The thing is that people want a coherent message about Python and Web programming. the message is out there, for anyone who wants to listen. and they are listening. why else do people still ask CGI-related questions on comp.lang.python? because CGI works well for simple applications where you don't want to waste any time whatsoever on hosting and deployment issues ? heck, I spent parts of last weekend hacking on a light-weight CGI-based publishing system for portions of the effbot.org site, using Python 2.2 on Solaris. loads of fun. (as for WSGI, it's plumbing. You can of course build fun things from spare parts and plumbing, and there are really interesting things going on in certain research labs, as usual, but if you want turn-key stuff, pick one of the big three.) After seeing WSGI being elevated to non-plumbing (since plumbing is just stuff that helps other stuff to work, not something you mess with on a daily basis), I think the current strategy with respect to floating more boats is to pretend that WSGI is all you need. I've never seen anyone besides Ian Bicking make that argument (and he's using WSGI plus a zillion ready-made building blocks when doing that). /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh wrote: Paul Boddie wrote: Well, that's just another way of saying that the scene remains stagnant, because I don't see any winners. one, two, overflow ? or are you saying that the lack of a monopoly means market stagnation, no matter how innovative the three big ones are ? I've never maintained that a monopoly on how Web programming is done would be a good thing. All I've ever tried to understand is why people haven't tried to improve the generic support for Web programming (and a whole load of other things) even to the level of something like the DB-API. Take another area: all the time you get people asking how they can conveniently access some Web site using a Python-based client, and loads of people are coming up against issues with urllib, urllib2, other libraries. Wouldn't it be good if the functionality were just there in the standard library in a sane form? Or is the standard library just a grab bag of demos these days? [...] the standard library has never included non-trivial applications (and the three big ones are configurable applications, not libraries). I'm not sure anyone has ever looked to the standard library for domain-specific applications or toolkits. These non-trivial applications are just libraries with icing on. My critique of the Web standardisation scene is that no-one is that interested in cooperating on the libraries. Of course, that isn't a bad thing if you choose your framework and find the facilities you need, but when this is happening at such a low level in the framework stack, you needlessly fragment the scene. TurboGears and Django have slightly different approaches, so if you're the sort of person who will buy the shiny new TurboGears book (the one with the snake holding a lightsabre, or something), you'll probably want to get the Django one as well: great news for publishers, an own-goal for the common cause. The thing is that people want a coherent message about Python and Web programming. the message is out there, for anyone who wants to listen. and they are listening. And that message is...? All I see is the JPF, the PFJ and the JPPF. why else do people still ask CGI-related questions on comp.lang.python? because CGI works well for simple applications where you don't want to waste any time whatsoever on hosting and deployment issues ? heck, I spent parts of last weekend hacking on a light-weight CGI-based publishing system for portions of the effbot.org site, using Python 2.2 on Solaris. loads of fun. Quite. But I'd also suggest that people use the cgi module and BaseHTTPServer because the former is a well-understood technology and the latter is something you can read about in a couple of pages in the library reference. Indeed, there are lots of BaseHTTPServer-related projects out there, which is not particularly good news for deployment, but then there's that big gap between the standard library and the megaprojects that I mentioned. (as for WSGI, it's plumbing. You can of course build fun things from spare parts and plumbing, and there are really interesting things going on in certain research labs, as usual, but if you want turn-key stuff, pick one of the big three.) After seeing WSGI being elevated to non-plumbing (since plumbing is just stuff that helps other stuff to work, not something you mess with on a daily basis), I think the current strategy with respect to floating more boats is to pretend that WSGI is all you need. I've never seen anyone besides Ian Bicking make that argument (and he's using WSGI plus a zillion ready-made building blocks when doing that). You should read some of the articles linked to from wsgi.org, then. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Paul Boddie wrote: I've never maintained that a monopoly on how Web programming is done would be a good thing. All I've ever tried to understand is why people haven't tried to improve the generic support for Web programming (and a whole load of other things) even to the level of something like the DB-API. Take another area: all the time you get people asking how they can conveniently access some Web site using a Python-based client, and loads of people are coming up against issues with urllib, urllib2, other libraries. Wouldn't it be good if the functionality were just there in the standard library in a sane form? Or is the standard library just a grab bag of demos these days? Paul, I do think the focus on the stdlib as it is right now is a bit misleading. The stdlib is basically the product of python-dev and the runtime developers also have maintenance responsibility. This shall and even must be splitted and shared as it is done successfully with application domains like Scientific Python. If an enterprise grows no one expects that one department is responsible for everything but here in the Python community Guido shall play Fidel Castro who cares for each module of each application developer ever written and its suitability for the stdlib and its alignment with the Python ideology. In my opinion Python shall grow up and organize the visibility of its products, its portfolio, differently with Py3K. I agree with Fredrik that any decision towards a BDFL blessed webframework is premature and Guido already showed himself not much interest in making any decision. Even if all kinds of components are available in the stdlib people are still looking for a RoR for Python and they do so not only for technical reasons but because they need a brand that can be justifed towards their team mates and project leaders. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Kay Schluehr wrote: Paul Boddie wrote: I've never maintained that a monopoly on how Web programming is done would be a good thing. All I've ever tried to understand is why people haven't tried to improve the generic support for Web programming (and a whole load of other things) even to the level of something like the DB-API. Take another area: all the time you get people asking how they can conveniently access some Web site using a Python-based client, and loads of people are coming up against issues with urllib, urllib2, other libraries. Wouldn't it be good if the functionality were just there in the standard library in a sane form? Or is the standard library just a grab bag of demos these days? Paul, I do think the focus on the stdlib as it is right now is a bit misleading. The stdlib is basically the product of python-dev and the runtime developers also have maintenance responsibility. This shall and even must be splitted and shared as it is done successfully with application domains like Scientific Python. Quite. But we're talking about supposedly well-established and widely understood technologies here: the cgi module first appeared in 1994 (1995 in the library); that relative newcomer the Cookie module appeared in 2000; BaseHTTPServer appeared in 1995; asyncore was added to the library in 1999. And unlike various scientific computing interest groups, those who use Web technologies are so broadly dispersed across all kinds of other domains that I doubt that even if GvR told everyone to take their Web modules elsewhere, there'd be enough cohesion to have such an umbrella WebPython distribution. If an enterprise grows no one expects that one department is responsible for everything but here in the Python community Guido shall play Fidel Castro who cares for each module of each application developer ever written and its suitability for the stdlib and its alignment with the Python ideology. Well, I don't want everyone's modules in the standard library, but I think it makes sense for people to work on integrating modules into the library that make it easier for them and others to then focus on other stuff. What if the cgi, BaseHTTPServer and Cookie modules hadn't been in the standard library? Whilst some people might regard the resulting dearth of Web frameworks as a benefit, I think you'd see less activity in that part of the community as a consequence. In my opinion Python shall grow up and organize the visibility of its products, its portfolio, differently with Py3K. I agree with Fredrik that any decision towards a BDFL blessed webframework is premature and Guido already showed himself not much interest in making any decision. But I don't want GvR to bless a framework. Consider his misunderstood near-blessing of Django: it's almost nonsensical. Sure, Django innovates somewhat in terms of describing the URL space, but there are numerous people who don't like the templating or the ORM, so they wonder if they just couldn't strip that stuff off and replace it, but what are you left with? The bare platform, of course, which isn't worth continually redeveloping for each megaframework, but that's what has been happening over the last five years. Even if all kinds of components are available in the stdlib people are still looking for a RoR for Python and they do so not only for technical reasons but because they need a brand that can be justifed towards their team mates and project leaders. True, and this is where a lot of the marketing Python discussion missed the point, dwelling on the corporate acceptability of Python (ie. the nod from the PHB) and ignoring the peer marketing effect (ie. some colleague you get along with shows you something with a cool label stuck to it). The Django and TurboGears projects have noticed this phenomenon, in contrast to that other supposed winner of the frameworks war (Zope), but I await the day when some other loudly advocated technology emerges to expose Python's library weaknesses and causes a similar reactive scramble amongst the interested parties of that particular domain. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Bruno Desthuilliers wrote:
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.
--
Regards/Gruesse,
Peter Maas, Aachen
E-mail 'cGV0ZXIubWFhc0B1dGlsb2cuZGU=\n'.decode('base64')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Paul Boddie wrote:
People who bring up stuff about self and indentation are just showing
their ignorance, in my opinion, since Python isn't the first language
to use self in such a way, and many C++ and Java programs use this
pervasively in order to make attribute scope explicit, whereas the
indentation matter is only troublesome with bad editing practices. I
don't think the community should spend any more time on these
criticisms.
How many programmers don't use Python because of the self issue?
I'm not for changing the semantics here but when I wrote a method with
lots of selfs recently I tried how it would look like if it would be
allowed not to write down 'self', i.e. from
def deposit(self, amount):
self.balance = self.balance + amount
to
def deposit( , amount):
.balance = .balance + amount
I see an advantage in not mentioning 'self': using shorter alternatives
like 'my' is possible but considered bad style. I find it unsatisfactory
to provide a degree of freedom and not wanting it to be used. Leaving
out 'self' is like leaving out block markers. You leave out something
that's a matter of taste (self, me, my, block marker positions) and
bring the code in minimal form. Explicit use of self could of course
still be allowed. And a favorite argument against Python would become
pointless.
However, the GIL and issues of tools and IDEs should be considered in a
more sophisticated way.
If I wouldn't read discussions about it I wouldn't probably know that it
exists. But as far as I have understood removing the GIL means a lot of
work and breaking existing code. Perhaps the GIL will die naturally with
the advent of a production ready PyPy. And the Twisted people keep telling
Repeat with me: there are no threads :)
Meanwhile, whilst not an IDE advocate myself, there really does need to
be further improvements in the analysis of Python source code so that
people can build improved tools to check Python programs for obvious
compile-time errors and to inspect the behaviour of large amounts of
code.
I agree.
One reads occasionally on the python-dev or python-3000 mailing
lists that some proposed change or other may or may not have an impact
on real world systems such as the standard library, but that no-one
can really say: we need to move beyond the Python is just so dynamic
meme and develop tools like PyLint and PyChecker much further.
I find it important that Python allows dynamic coding but I agree that it
should allow more compile time checks which would probably also help to
produce faster code.
This kind of stuff can be tackled by providing better introductory,
educational or promotional material, with the latter especially
important to stop the uninformed rubbishing that advocates of certain
other languages seem particularly inclined to indulge in.
I don't think so because advocates tend to use arguments just because they
are handy, not because they don't know better.
--
Regards/Gruesse,
Peter Maas, Aachen
E-mail 'cGV0ZXIubWFhc0B1dGlsb2cuZGU=\n'.decode('base64')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
On 10/10/06, Peter Maas [EMAIL PROTECTED] wrote: I for my part would be happy to see a Delphi-like RAD tool for Python, a reference implementation for web programming as part of the standard library, Jython 2.5, Python for PHP or whatever attracts new programmers. I think you should take a good look at Dabo and the visual tools they are creating. While I would be the first one to admit that they are not polished to the level of Delphi, they are pretty amazing for a couple of guys working in their spare time! If we could get more of the community to contribute to this project, I don't think that there would be any other RAD tool that would come close. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
self (was: Python component model)
Peter Maas wrote: Paul Boddie wrote: People who bring up stuff about self and indentation are just showing their ignorance, in my opinion, since Python isn't the first language to use self in such a way, and many C++ and Java programs use this pervasively in order to make attribute scope explicit, whereas the indentation matter is only troublesome with bad editing practices. I don't think the community should spend any more time on these criticisms. How many programmers don't use Python because of the self issue? I'm not for changing the semantics here but when I wrote a method with lots of selfs recently I tried how it would look like if it would be allowed not to write down 'self', i.e. from def deposit(self, amount): self.balance = self.balance + amount to def deposit( , amount): .balance = .balance + amount would like this. I finally liked pythons 'forced-indentation' thing, but 'self' is just terrible. def deposit(amount) .balance = .balance + amount # a little thin this dot @balance = @balance + amount # why not similar to ruby? self = do this and that # self remains available but this will have most possibly major implications (design, compatibility etc.) possibly the simplest way would be to agree on 's' (typing is very fast, faster than SHIFT-2 for @) def deposit(s, amount) s.balance = s.balance + amount so, python 2.6 = introduces agreement on 's' ? this will never happen, but everyone is of course free to use 's' instead of 'self' immedeately. There's no problem (except possibly the tiny annoyancy when reading through libraries which use 'self'). . -- http://lazaridis.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Decker wrote: On 10/10/06, Peter Maas [EMAIL PROTECTED] wrote: I for my part would be happy to see a Delphi-like RAD tool for Python, a reference implementation for web programming as part of the standard library, Jython 2.5, Python for PHP or whatever attracts new programmers. I think you should take a good look at Dabo and the visual tools they are creating. While I would be the first one to admit that they are not polished to the level of Delphi, they are pretty amazing for a couple of guys working in their spare time! If we could get more of the community to contribute to this project, I don't think that there would be any other RAD tool that would come close. -- # p.d. yes, an interesting tool. But to get more attention and developers, the project needs to be polished. really unattractive resources: http://dabodev.com http://case.lazaridis.com/wiki/DaboAudit -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
On 11 Oct 2006 18:56:30 -0700, Ilias Lazaridis [EMAIL PROTECTED] wrote: yes, an interesting tool. But to get more attention and developers, the project needs to be polished. really unattractive resources: http://dabodev.com http://case.lazaridis.com/wiki/DaboAudit Well, then, why not contribute? Or are you waiting for everyone else to do it for you? It really grinds my gears when people take something that involves hundreds if not thousands of hours of time that is offered to them for free, and then nitpicks on something completely tangential. If you want a polished website, then offer to contribute one! Don't whine about a couple of developers who are doing amazing things in their spare time while you're contributing absolutely nothing to the community. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
On Oct 10, 2006, at 1:47 PM, fumanchu wrote: 4) Custom property and component editors: A component editor can present a property editor or an editor for an entire component which the visual design-time RAD environment can use to allow the programmer end- user of the component to set or get component property values. Normally a design time environment will present default property editors for each component property type, but a component can override this. This is the hard part. I believe Dabo has done some work in this space, but this is where the tight coupling comes in between code and tool, a coupling which Python has traditionally resisted. FWIW, the Dabo design tools store the design in a basic XML file, and are completely transparent to outside editing. There is nothing that prevents you from modifying a design in the editor of your choice; the Dabo visual editing tools simply give you WYSIWYG feedback as you edit. -- Ed Leafe -- http://leafe.com -- http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
On Oct 10, 2006, at 9:59 PM, Edward Diener No Spam wrote: The Visual Studio RAD IDE environment actually modifies source code constructors, via an InitializeComponent() function called from it, in order to set properties and events in components. It does mark the function as such with comments in the source code. OTOH Borland's VCL uses the resource file technique you scorn above, linking in the code via resources and automatically updating a component's properties and events from base class components constructors. I believe Java's JVM automatically deserializes .ser files at run-time saved by a RAD designer in order to set properties and events on an object of a class. There are obviously numerous techniques, so one should theoretically work well with Python. With Dabo, we've taken what we feel is a 'best of breed' approach. The constructors for the various objects are defined in XML-formatted files, making them accessible by any editor. The code behind these objects is stored in regular .py files, with special comment lines that provide the linkage back to the original object definition. So you can edit your code in your favorite Python editor, and it all just works. -- Ed Leafe -- http://leafe.com -- http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Decker wrote: On 11 Oct 2006 18:56:30 -0700, Ilias Lazaridis [EMAIL PROTECTED] wrote: yes, an interesting tool. But to get more attention and developers, the project needs to be polished. really unattractive resources: http://dabodev.com http://case.lazaridis.com/wiki/DaboAudit Well, then, why not contribute? Or are you waiting for everyone else to do it for you? No, he's just a troll that enjoys telling everyone what to do. Don't try to get him to contribute anything useful; it won't work. -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Decker wrote: On 11 Oct 2006 18:56:30 -0700, Ilias Lazaridis [EMAIL PROTECTED] wrote: yes, an interesting tool. But to get more attention and developers, the project needs to be polished. really unattractive resources: http://dabodev.com http://case.lazaridis.com/wiki/DaboAudit Well, then, why not contribute? Or are you waiting for everyone else to do it for you? I've contributed already (my contructive criticism). It's up to the team to react. It really grinds my gears when people take something that involves hundreds if not thousands of hours of time that is offered to them for free, and then nitpicks on something completely tangential. If you project infrastructure is not tangential. It's essential want a polished website, then offer to contribute one! Terrible this open source folks. One cannot say one word without beeing asked to contribute. Don't whine about a couple of developers who are doing amazing things in their doing amazing things is not enouth to bring a language-community forward (or to create a python component model, which is the topic of this thread) spare time while you're contributing absolutely nothing to the community. I share the infrastructure which I use: http://dev.lazaridis.com/base . -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Robert Kern wrote: Peter Decker wrote: On 11 Oct 2006 18:56:30 -0700, Ilias Lazaridis [EMAIL PROTECTED] wrote: yes, an interesting tool. But to get more attention and developers, the project needs to be polished. really unattractive resources: http://dabodev.com http://case.lazaridis.com/wiki/DaboAudit Well, then, why not contribute? Or are you waiting for everyone else to do it for you? No, he's just a troll that enjoys telling everyone what to do. Don't try to get him to contribute anything useful; it won't work. Mr. Kern! Seeing you working on such a seemingly excellent product, I am really wondering about your tenor. can you please inform me (and the interested readers) about the persistency mechanism within traits: http://groups.google.com/group/comp.lang.python/msg/8e89ed163b978fe2 . -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Ilias Lazaridis [EMAIL PROTECTED] writes: Terrible this open source folks. One cannot say one word without beeing asked to contribute. +1 QOTW, in a new category for kooks. -- \ Say what you will about the Ten Commandments, you must always | `\ come back to the pleasant fact that there are only ten of | _o__) them. -- Henry L. Mencken | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
On 11 Oct 2006 20:08:12 -0700, Ilias Lazaridis [EMAIL PROTECTED] wrote: Well, then, why not contribute? Or are you waiting for everyone else to do it for you? I've contributed already (my contructive criticism). It's up to the team to react. Wow! What a contribution! Amazing that Dabo hasn't taken over the world with that sort of help pouring in! Anybody can criticize. It's easy to find fault; it's much harder to create something valuable. I saw the references to your being a troll, and thought I'd give you the benefit of the doubt. Guess I'm still too optimistic. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Ilias Lazaridis wrote: Robert Kern wrote: No, he's just a troll that enjoys telling everyone what to do. Don't try to get him to contribute anything useful; it won't work. Mr. Kern! Seeing you working on such a seemingly excellent product, I am really wondering about your tenor. I am confident that it is accurately aimed. Furthermore, I am confident that the record and the rest of this community will back me up on it. I've told you before that this community will not tolerate your bad behavior. How many times does this have to be demonstrated before you will leave? -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Robert Kern wrote: Ilias Lazaridis wrote: Robert Kern wrote: No, he's just a troll that enjoys telling everyone what to do. Don't try to get him to contribute anything useful; it won't work. Mr. Kern! Seeing you working on such a seemingly excellent product, I am really wondering about your tenor. I am confident that it is accurately aimed. Furthermore, I am confident that the record and the rest of this community will back me up on it. I've told you before that this community will not tolerate your bad behavior. How many times does this have to be demonstrated before you will leave? Please stay in-topic can you please inform me (and the interested readers) about the persistency mechanism within traits: http://groups.google.com/group/comp.lang.python/msg/8e89ed163b978fe2 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Decker wrote: On 11 Oct 2006 20:08:12 -0700, Ilias Lazaridis [EMAIL PROTECTED] wrote: Well, then, why not contribute? Or are you waiting for everyone else to do it for you? I've contributed already (my contructive criticism). It's up to the team to react. Wow! What a contribution! Amazing that Dabo hasn't taken over the world with that sort of help pouring in! Anybody can criticize. It's easy to find fault; it's much harder to create something valuable. [REQUOTE] I share the infrastructure which I use: http://dev.lazaridis.com/base [/REQUOTE] I saw the references to your being a troll, and thought I'd give you the benefit of the doubt. Guess I'm still too optimistic. No. You're just ignoring given facts in a controlled manner. Like many other people of this community. And that's the main reason why python does not move forward in the speed it could. . -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Ilias Lazaridis wrote: Robert Kern wrote: Ilias Lazaridis wrote: Robert Kern wrote: No, he's just a troll that enjoys telling everyone what to do. Don't try to get him to contribute anything useful; it won't work. Mr. Kern! Seeing you working on such a seemingly excellent product, I am really wondering about your tenor. I am confident that it is accurately aimed. Furthermore, I am confident that the record and the rest of this community will back me up on it. I've told you before that this community will not tolerate your bad behavior. How many times does this have to be demonstrated before you will leave? Please stay in-topic Asking disruptive individuals to leave is always on-topic. Now, please go away. I will happily and pleasantly converse with anyone who has questions about Traits or any of Enthought's other tools if they ask in good faith. I believe that the record shows that you do not do so. Really, I'm quite nice and helpful to other people. -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Robert Kern wrote: Ilias Lazaridis wrote: Robert Kern wrote: Ilias Lazaridis wrote: Robert Kern wrote: No, he's just a troll that enjoys telling everyone what to do. Don't try to get him to contribute anything useful; it won't work. Mr. Kern! Seeing you working on such a seemingly excellent product, I am really wondering about your tenor. I am confident that it is accurately aimed. Furthermore, I am confident that the record and the rest of this community will back me up on it. I've told you before that this community will not tolerate your bad behavior. How many times does this have to be demonstrated before you will leave? Please stay in-topic Asking disruptive individuals to leave is always on-topic. please realize: the only disruptive individual at this point is you. Now, please go away. of course I stay. I will happily and pleasantly converse with anyone who has questions about Traits or any of Enthought's other tools if they ask in good faith. I believe that the record shows that you do not do so. Really, I'm quite nice and helpful to other people. Sorry to say, but your behaviour is very ungentle. I've place a simple question. If you are really helpful to other people, then pleas just answer. Many other people follow this discussion, and many will see the question within the archives... unsanswered. looks interesting. what about persistency? http://groups.google.com/group/comp.lang.python/msg/8e89ed163b978fe2 As far as I can see, there's no persistency binding available. Is one planned? . -- http://mail.python.org/mailman/listinfo/python-list
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/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
Re: Python component model
Nick Vatamaniuc [EMAIL PROTECTED] writes: 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. -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Paul Rubin schrieb: Nick Vatamaniuc [EMAIL PROTECTED] writes: 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 -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Diez B. Roggisch wrote: Paul Rubin schrieb: Nick Vatamaniuc [EMAIL PROTECTED] writes: 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 -- http://mail.python.org/mailman/listinfo/python-list
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 '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
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=33sessionId=41confId=44 Paul -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
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
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/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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Paul Rubin wrote: Nick Vatamaniuc [EMAIL PROTECTED] writes: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Edward Diener No Spam [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Diez B. Roggisch wrote: Paul Rubin schrieb: Nick Vatamaniuc [EMAIL PROTECTED] writes: 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... 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Steve Holden wrote: 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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Edward Diener No Spam wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh wrote: 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Edward Diener No Spam wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Michael Sparks wrote: 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.) 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. 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. 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 ;-) 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) 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
Re: Python component model
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:
[EMAIL PROTECTED]:~$ 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.
class Person(object):
... 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Richard Brodie wrote: Edward Diener No Spam [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh wrote: Edward Diener No Spam wrote: 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. I agree. if you want better support for more precise hooking, post some examples. I want a design-time environment to hook up my objects in a visual way. I think it is easier than doing it manually, even in Python. 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. I did not say what others may need. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Edward Diener No Spam wrote: if you want better support for more precise hooking, post some examples. I want a design-time environment to hook up my objects in a visual way. I think it is easier than doing it manually, even in Python. what objects? what hooks? visually, in what way? 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. I did not say what others may need. I'm not sure I see the big difference between perhaps others do [have a need] and others may need, but that's me. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Diez B. Roggisch wrote: 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. Yes, I am suggesting static typing functionality for a subset of Python attributes. How this can be done I am still investigating on my own. 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. Adding a feature, such as static typing functionality for the situation of doing visual RAD programming, does not lose a _lot_ of what makes python powerful. My idea of adding static typing is not an attempt to change the language but rather to develop Python classes which encapsulate the idea of a variable and a type for the purposes of emulating component properties and component events. If a language addition is needed instead I will investigate how to propose it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh wrote: Edward Diener No Spam wrote: if you want better support for more precise hooking, post some examples. I want a design-time environment to hook up my objects in a visual way. I think it is easier than doing it manually, even in Python. what objects? what hooks? visually, in what way? 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. I did not say what others may need. I'm not sure I see the big difference between perhaps others do [have a need] and others may need, but that's me. He's wriggling anyway, as his opening post said (among other things) I believe that Python should have a common components model for all RAD development environments So unless he's the only person who's going to use these development environments it does indeed sound a little prescriptive. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Tim Chase wrote:
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:
[EMAIL PROTECTED]:~$ 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.
class Person(object):
... 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 ;)
Not all attributes are component properties in typical Visual RAD tool.
In most visual RAD tools which I have used a component property is a
publicly exposed type/name which may or may not have the backing of an
actual data member and does have a function to get the type's value if
the property is readable and does have a function associated with it to
set the type's value if the property is writable. This is very close to
the class properties in Python. The difference is that normally a type
must be associated with a property whereas in Python, as I understand
it, the type of a class property is unknown.
Furthermore by a component event I do not mean methods on the event
creator's side but rather an event source. This would look something
like a tuple of callable functions of a particular signature to which an
event sink could add an event handler so that when a particular event
occurred on the event source the event handlers added to the event
source would each be called.
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.
I realize that Python has excellent abilities in all these areas,
including serialization. But a component model for serialization must
not only have the ability of serializing and deserializing all of the
component's data, as well as any base classes, it must also have a means
of allowing the class itself to specify which data needs to be
serialized and which not, as well as allow for the class to seriliaze
all or part of its own data.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh wrote: Edward Diener No Spam wrote: 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. Well, knock me over. 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. My OP was just to query whether a component model existed for Python, like JavaBeans for Java or .Net for C#, C++/CLI etc. After that came suggestions of what I thought such a component model was about, which I thought I answered generally. Not you want details. No doubt next will come a demand for code. OK, here is my idea of what such a component model envisages as a list of items. After this, unless I get some intelligent comments from people who might be interested in what I envision, or something very similar, I will be off to investigate it myself rather than do battle with the horde of people who will just tell me that Python, being a great language, does not need what I have suggested. 1) Component property: This is a glorified attribute with a type that can either be specified in a static manner, or always be discovered dynamically, or have converters back and forth between a string and the actual value represented by the component property. A component property has a getter function to retrieve the value if it is readable and a setter function to set the value if it is writable. It must be either readable or writable or both. A component property is not any Python class attribute since a component has the right to specify only certain values as manipulatable in a design-time RAD environment. 2) Component event: This is an type which encapsulates an array, or a list of callable objects with the same function signature, along with the functionality to add and remove elements from the array, as well as cycle through the array calling the callable objects as a particular event is triggered. A component event is an event source for a particular event. Component events have to be dicoverable by the Visual RAD system so that an object's appropriate event handler, an event sink, can be hooked to the component event itself, an event source, through a design time interface which propagates the connection at run-time. 3: Component serialization: A component which has its properties and events set by a visual design-time RAD environment needs to be serialized at design time and deserialized at run-time. This can be a default serialization of all component properties and events, or the component itself can participate in the serilization effort either wholly or partly. 4) Custom property and component editors: A component editor can present a property editor or an editor for an entire component which the visual design-time RAD environment can use to allow the programmer end-user of the component to set or get component property values. Normally a design time environment will present default property editors for each component property type, but a component can override this. 5) Custom type converters: A component should be able to specify a custom converter for any property to convert, in both directions or either direction, between the property's string value as seen by a property editor and the actual value of the component property's type. This is the general gist of those things which are needed in a visual Design-time RAD environment. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Edward My OP was just to query whether a component model existed for Edward Python, like JavaBeans for Java or .Net for C#, C++/CLI Edward etc. For those of us who've never used Java, .Net or C++/CLI, a more concrete description of what you were after from the beginning would have been helpful. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Edward Diener No Spam wrote:
OK, here is my idea of what such a component model envisages as a list
of items. After this, unless I get some intelligent comments from people
who might be interested in what I envision, or something very similar, I
will be off to investigate it myself rather than do battle with the
horde of people who will just tell me that Python, being a great
language, does not need what I have suggested.
[This quote hacked up by me:]
1) Component property: This is a glorified attribute with a type that
a) can be specified in a static manner, or discovered dynamically,
b) has converters between a string and the actual value
c) has a getter function to retrieve the value if it is readable and a
setter function to set the value if it is writable.
d) be either readable or writable or both.
e) not any Python class attribute since a component has the right
to specify only certain values as manipulatable in a design-time
RAD environment.
Whenever you say glorified attribute, your first thought should be
Python descriptor (but not your last--it's not a cure-all). They are
able to do all of (a, b, c, d, e) which I marked in your text above.
For example, here's a descriptor for
attributes-you-want-to-persist-in-a-database from my ORM, Dejavu (see
http://projects.amor.org/dejavu/browser/trunk/units.py#l290):
class UnitProperty(object):
Data descriptor for Unit data which will persist in storage.
def __init__(self, type=unicode, index=False, hints=None, key=None,
default=None):
self.type = type
self.index = index
if hints is None: hints = {}
self.hints = hints
self.key = key
self.default = default
def __get__(self, unit, unitclass=None):
if unit is None:
# When calling on the class instead of an instance...
return self
else:
return unit._properties[self.key]
def __set__(self, unit, value):
if self.coerce:
value = self.coerce(unit, value)
oldvalue = unit._properties[self.key]
if oldvalue != value:
unit._properties[self.key] = value
def coerce(self, unit, value):
if value is not None and not isinstance(value, self.type):
# Try to cast the value to self.type.
try:
value = self.type(value)
except Exception, x:
x.args += (value, type(value))
raise
return value
def __delete__(self, unit):
raise AttributeError(Unit Properties may not be deleted.)
a) can be specified in a static manner, or discovered dynamically,
The component model can either scan a class for instances of
UnitProperty or keep a registry of them in the class or elsewhere (via
a metaclass + add_property functions).
b) has converters between a string and the actual value
Note the coerce function above. Something similar could be done for
serialization (which I can prove in my case because I use UnitProperty
to help produce SQL ;) but you could just as easily pickle
unit._properties and be done with it.
c) has a getter function to retrieve the value if it is readable and a
setter function to set the value if it is writable.
d) be either readable or writable or both.
Descriptors that only have __get__ are read-only; if they have __set__
they are read-write.
e) not any Python class attribute since a component has the right
to specify only certain values as manipulatable in a design-time
RAD environment.
Right. Descriptors allow the creator of a class to use normal
attributes (including functions) which don't participate in the
component model.
2) Component event: This is an type which encapsulates an array, or a
list of callable objects with the same function signature, along with
the functionality to add and remove elements from the array, as well as
cycle through the array calling the callable objects as a particular
event is triggered. A component event is an event source for a
particular event. Component events have to be dicoverable by the Visual
RAD system so that an object's appropriate event handler, an event sink,
can be hooked to the component event itself, an event source, through a
design time interface which propagates the connection at run-time.
This can be accomplished by creating a ComponentEvent descriptor whose
__get__ returns an object with a __call__ method. Here's a base class
for something similar (again, from Dejavu):
class UnitAssociation(object):
Non-data descriptor method to retrieve related Units via
attributes.
to_many = None
def __init__(self, nearKey, farClass, farKey):
# Since the keys will be used as kwarg keys, they must be
strings.
self.nearKey = str(nearKey)
self.farKey = str(farKey)
self.nearClass = None
self.farClass = farClass
def __get__(self, unit, unitclass=None):
if unit is None:
# When calling on
Re: Python component model
[EMAIL PROTECTED] wrote: Edward My OP was just to query whether a component model existed for Edward Python, like JavaBeans for Java or .Net for C#, C++/CLI Edward etc. For those of us who've never used Java, .Net or C++/CLI, a more concrete description of what you were after from the beginning would have been helpful. From vague recollections of the original Java Beans technology, the primary innovation was to have getProperty and setProperty methods, along with things like isCapability and hasProperty, if I remember correctly. None of this was really shocking to anyone using Python, mostly because Python had __getattr__ and __setattr__ even back then for customising real property/attribute access, and Python's run-time introspection capabilities were superior to Java's (and probably still are). The other innovation was the introduction of standard interfaces for listening to and dispatching events, where you implement some listener interface and respond to events in order to care about those events. I don't recall any particularly good mechanisms for connecting beans to each other in order to fire off events, although the beanbox (or whatever the graphical tool originally promoted was called) and/or the IDE is supposed to help you with that part of the work. The groovy 1990s API is actually viewable in various places; here, for example: http://www.doc.ic.ac.uk/~jpc1/linux/bdk-doc-1.0/apis.html Despite the supposedly exciting advances heralded by Java Beans, a large part of the technology was just codifying existing practices and techniques, but it could be argued that such techniques have been superseded by signal/slot mechanisms and more advanced event architectures (pioneered by frameworks like Qt and since adopted by Gtk, I believe). Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
fumanchu wrote: 4) Custom property and component editors: A component editor can present a property editor or an editor for an entire component which the visual design-time RAD environment can use to allow the programmer end-user of the component to set or get component property values. Normally a design time environment will present default property editors for each component property type, but a component can override this. This is the hard part. I believe Dabo has done some work in this space, but this is where the tight coupling comes in between code and tool, a coupling which Python has traditionally resisted. I do think it's just about presenting component properties and their types / value ranges. I do think this can be easily achieved using decorators that might also add the right kind of token for introspection purposes to the function/method attributes. Descriptors i.e. customized binding semantics might cover one aspect of componentization but as I understood Edward he asked for uniform declarative semantics. Components in this sense are just specialized objects such as TestCase classes in the PyUnit framework. What I still do not understand is the reference to many RAD tools which is completely hypothetical to me. The portability of components across different GUI designers for the same underlying toolkit is a quite speculative future requirement to say the least. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
fumanchu wrote: 4) Custom property and component editors: A component editor can present a property editor or an editor for an entire component which the visual design-time RAD environment can use to allow the programmer end-user of the component to set or get component property values. Normally a design time environment will present default property editors for each component property type, but a component can override this. This is the hard part. I believe Dabo has done some work in this space, but this is where the tight coupling comes in between code and tool, a coupling which Python has traditionally resisted. that's not that hard on a pure technical level; even a basic tool like IDLE can hook itself into an executing Python process. once you're hooked up, you can inspect and modify most about everything. for example, doing remote tweaking of live Tkinter widget trees is pretty straight-forward. coming up with a good way to capture the modifications, and use them in your actual application, is a bit harder. do you really want to replace plain old source code with some kind of more or less obscure resource files? and designing a metadata vocabulary that's powerful enough to be useful for more than just one or a few target domains might be really hard. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Diez B. Roggisch wrote:
The amazing flexibility stems from the fact that it is _runtime_. This is
_exactly_ the difference between static and dynamic typing.
Not _exactly_. You can have static typing in an interpreted language (Java)
and dynamic typing in a machine language (Basic with variants).
--
Regards/Gruesse,
Peter Maas, Aachen
E-mail 'cGV0ZXIubWFhc0B1dGlsb2cuZGU=\n'.decode('base64')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Paul Boddie wrote: [EMAIL PROTECTED] wrote: Edward My OP was just to query whether a component model existed for Edward Python, like JavaBeans for Java or .Net for C#, C++/CLI Edward etc. For those of us who've never used Java, .Net or C++/CLI, a more concrete description of what you were after from the beginning would have been helpful. From vague recollections of the original Java Beans technology, the primary innovation was to have getProperty and setProperty methods, along with things like isCapability and hasProperty, if I remember correctly. None of this was really shocking to anyone using Python, mostly because Python had __getattr__ and __setattr__ even back then for customising real property/attribute access, and Python's run-time introspection capabilities were superior to Java's (and probably still are). There is no argument on my part that Python's introspection and metadata capabilities are superior to Java, as well as its potential attribute as component property model. In the theoretical Python model I proposed, the designer of the component must have the ability to specify which of the component's attributes are properties and how this is controlled ( via __getattr__ and __setattr__ ? descriptors as someone else suggested ? other ideas ? ). Merely saying that all of an object's attributes are component properties for the purposes of a visual RAD designer can not be correct. I actually think that Java's notion of preoperties in JavaBeans, which are just getter and setter functions with a particular naming convention, determined by Java as a default, or through an associated BeanInfo class, is rather klutzy and much prefer that of .Net or Borland's VCL where a particular language construct is used for properties instead. Of course with Python's superior metadata abilities, a particular new language construct shouldn't be necessary. The other innovation was the introduction of standard interfaces for listening to and dispatching events, where you implement some listener interface and respond to events in order to care about those events. I don't recall any particularly good mechanisms for connecting beans to each other in order to fire off events, although the beanbox (or whatever the graphical tool originally promoted was called) and/or the IDE is supposed to help you with that part of the work. The beanbox did nothing to help setup events, event sources, or event listeners. It just presented a graphical example of a visual RAD tool which could tie event sources to event listeners. It is onerous in JavaBeans to connect event sources to event listeners, and takes a good deal of manual coding although doing it is easy to understand. The groovy 1990s API 1997. Again Borland's VCL or .Net have much better solutions for events but again require language constructs which Python ought not need given its strong metadata possibilities to supply a component event model. is actually viewable in various places; here, for example: http://www.doc.ic.ac.uk/~jpc1/linux/bdk-doc-1.0/apis.html The BDK is no longer supported in the latest version of Java and JavaBeans. Instead there is a Bean Builder at https://bean-builder.dev.java.net/ . Despite the supposedly exciting advances heralded by Java Beans, a large part of the technology was just codifying existing practices and techniques, but it could be argued that such techniques have been superseded by signal/slot mechanisms and more advanced event architectures (pioneered by frameworks like Qt and since adopted by Gtk, I believe). I agree and I would want to have a component event model for Python that is much superior to the JavaBeans event model in ease of use. A much better ideal for component properties and component events is presented by .Net, where there are actual language keywords which perform the magic. I would guess that Qt and Gtk also follow a better ease of use path, perhaps with macros in C++. But Python should be able to do as good or better than any of these environments. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
fumanchu wrote:
Edward Diener No Spam wrote:
OK, here is my idea of what such a component model envisages as a list
of items. After this, unless I get some intelligent comments from people
who might be interested in what I envision, or something very similar, I
will be off to investigate it myself rather than do battle with the
horde of people who will just tell me that Python, being a great
language, does not need what I have suggested.
[This quote hacked up by me:]
1) Component property: This is a glorified attribute with a type that
a) can be specified in a static manner, or discovered dynamically,
b) has converters between a string and the actual value
c) has a getter function to retrieve the value if it is readable and a
setter function to set the value if it is writable.
d) be either readable or writable or both.
e) not any Python class attribute since a component has the right
to specify only certain values as manipulatable in a design-time
RAD environment.
Whenever you say glorified attribute, your first thought should be
Python descriptor (but not your last--it's not a cure-all). They are
able to do all of (a, b, c, d, e) which I marked in your text above.
For example, here's a descriptor for
attributes-you-want-to-persist-in-a-database from my ORM, Dejavu (see
http://projects.amor.org/dejavu/browser/trunk/units.py#l290):
class UnitProperty(object):
Data descriptor for Unit data which will persist in storage.
def __init__(self, type=unicode, index=False, hints=None, key=None,
default=None):
self.type = type
self.index = index
if hints is None: hints = {}
self.hints = hints
self.key = key
self.default = default
def __get__(self, unit, unitclass=None):
if unit is None:
# When calling on the class instead of an instance...
return self
else:
return unit._properties[self.key]
def __set__(self, unit, value):
if self.coerce:
value = self.coerce(unit, value)
oldvalue = unit._properties[self.key]
if oldvalue != value:
unit._properties[self.key] = value
def coerce(self, unit, value):
if value is not None and not isinstance(value, self.type):
# Try to cast the value to self.type.
try:
value = self.type(value)
except Exception, x:
x.args += (value, type(value))
raise
return value
def __delete__(self, unit):
raise AttributeError(Unit Properties may not be deleted.)
a) can be specified in a static manner, or discovered dynamically,
The component model can either scan a class for instances of
UnitProperty or keep a registry of them in the class or elsewhere (via
a metaclass + add_property functions).
b) has converters between a string and the actual value
Note the coerce function above. Something similar could be done for
serialization (which I can prove in my case because I use UnitProperty
to help produce SQL ;) but you could just as easily pickle
unit._properties and be done with it.
c) has a getter function to retrieve the value if it is readable and a
setter function to set the value if it is writable.
d) be either readable or writable or both.
Descriptors that only have __get__ are read-only; if they have __set__
they are read-write.
e) not any Python class attribute since a component has the right
to specify only certain values as manipulatable in a design-time
RAD environment.
Right. Descriptors allow the creator of a class to use normal
attributes (including functions) which don't participate in the
component model.
2) Component event: This is an type which encapsulates an array, or a
list of callable objects with the same function signature, along with
the functionality to add and remove elements from the array, as well as
cycle through the array calling the callable objects as a particular
event is triggered. A component event is an event source for a
particular event. Component events have to be dicoverable by the Visual
RAD system so that an object's appropriate event handler, an event sink,
can be hooked to the component event itself, an event source, through a
design time interface which propagates the connection at run-time.
This can be accomplished by creating a ComponentEvent descriptor whose
__get__ returns an object with a __call__ method. Here's a base class
for something similar (again, from Dejavu):
class UnitAssociation(object):
Non-data descriptor method to retrieve related Units via
attributes.
to_many = None
def __init__(self, nearKey, farClass, farKey):
# Since the keys will be used as kwarg keys, they must be
strings.
self.nearKey = str(nearKey)
self.farKey = str(farKey)
self.nearClass = None
self.farClass =
Re: Python component model
Edward Diener No Spam wrote: I agree and I would want to have a component event model for Python that is much superior to the JavaBeans event model in ease of use. isn't that an old Perlis quote? I want a component event model in which I need only say what I wish done? /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Bruno Desthuilliers wrote: Marc 'BlackJack' Rintsch wrote: (snip) Python itself is a RAD tool. +1 QOTW Agreed. Georg -- http://mail.python.org/mailman/listinfo/python-list
