Python component model

[Ilias Lazaridis]

No, please stop self-assuring, self-pleasing QOTWs! This afternoon
I was in the local book warehouse and went to the computer book
department. They had banned 2-3 Python books together with some
Perl- and C/C++ stuff into the last row. At the regular place I found
a huge pile of Java books and - in comparison to Java - a small but
growing number of books about Ruby in general, Ruby on Rails and -
new to me - JRuby.

Now I don't think that Ruby is a bad language. But I think Python is
better and it started earlier. I don't know whether Ruby on Rails was
a fluke or the result of clever analysis. Since a large part of
programming is web programming it is not bad to have a good and visible
tool in place to attract programmers. It is also a good idea to hook on
Java's success but while Jython 2.2 is in alpha state since 3 years I
see an increasing number of books/articles telling how to migrate from
Java to (J)Ruby. Since I started using Python 4 years ago I hear Ruby
people announce with an amazing audacitiy that Ruby is bound to be number
one and will for sure leave Python behind.

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

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.

Peter Maas, Aachen

well said.

Based on a comment in this thread, I've just detected this one:

http://code.enthought.com/ets/

http://code.enthought.com/envisage/

BSD2 licensed, so it's very attractive as a foundation for a
joint-community-effort.

_very_ interesting stuff, i've placed in on the list for a later
review:

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

..

 

[Ilias Lazaridis]

Edward Diener No Spam wrote: ....


It also provides an event model and a declarative UI layer as well as several
other things besides.

looks interesting.

what about persistency?

..

 

[Hendrik van Rooyen]

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

 

[Kay Schluehr]

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.

 

[Bruno Desthuilliers]

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.

 

[Paul Boddie]

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 books because of relentless and seemingly frivolous changes
to a language or technology.

Paul

[1] http://www.python.org/pypi/parallel
[2]
http://groups.google.com/group/comp.lang.python/msg/c6d8f8aa2cfb8562
[3]
http://groups.google.com/group/comp.lang.python/msg/f678b500493a38f1
[4]
http://wiki.python.org/moin/CodingProjectIdeas/StandardLibrary/RestructuredStandardLibrary

 

[Fredrik Lundh]

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>

 

[Paul Boddie]

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/000003.html

 

[Fredrik Lundh]

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.

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>

 

[Paul Rubin]

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

 

[Paul Boddie]

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

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.

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

 

[Kay Schluehr]

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

 

[Paul Boddie]

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

 

[Peter Maas]

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.

 

[Peter Maas]

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.

 

[Ilias Lazaridis]

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

..

 

[Peter Decker]

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.

 

[Ed Leafe]

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

 

[Ed Leafe]

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

 

[Ilias Lazaridis]

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.

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