Python component model

[Paul Boddie]

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