python gaining popularity according to a study

[ccdetail]

http://www.tiobe.com/index.htm?tiobe_index

Python is the 7th most commonly used language, up from 8th.
The only one gaining ground besides VB in the top 10.

We're glad, our app is written in python.
It's free at http://pnk.com and it is a web timesheet for project
accounting

[bearophileHUGS]

cc******@gmail.com:

Python is the 7th most commonly used language, up from 8th.
The only one gaining ground besides VB in the top 10.

It also shows that Ruby is gaining even more, and D is (gladly) growing
too.

Bye,
bearophile

[robert]

cc******@gmail.com wrote:

http://www.tiobe.com/index.htm?tiobe_index

Python is the 7th most commonly used language, up from 8th.
The only one gaining ground besides VB in the top 10.

We're glad, our app is written in python.
It's free at http://pnk.com and it is a web timesheet for project
accounting

The real comparision is vs. Ruby. Seems, Ruby has won an important race because of this Rails thing.
Both, the Ruby language and this thing are weak compared to Python side in almost any aspect (just better than dull LAMP).
But they have managed to raise a single-minded marketing and focus.

When a LAMP programmer comes to Python, there are so many different confusing things.
It starts with a 'non-documented' cgi module - a 'High-Level-Interface', that cannot even iterate over the form items.
A name ZOPE in focus which reveals to be a monster system with 2-year learning-curve, ready for running an article editorial system for TOP-10 newspaper companies, but unable to make simple things simple.
A handful of different Djangos - choose one for each weekday and programmer ...
And Ruby made it with this single-known simple URL-to-method-router (And possibly when coming from PHP & Perl one recognizes ::@$_$%§§%/&... and the old namespace dirt)
If there would have been a good cgi-system and a somewhat comfortable advanced URL-to-OO-router (beyond the socket wrapper HTTPServer) well exposed in the Python standard lib, the numbers would be probably very different today ...

Flat Web/DB programming is one major field where programmer masses are born.
The other big one is RAD-GUI/DB programming. This field is probably still wide open. Best tooled Borland RAD systems are going down meanwhile because of the stiff compiler language. Programmers look around for the next language & toolset. Python is the language - but with Python there is again a similar confusion around IDE's and GUI-libs. There is no really good IDE (but fat ones). And the major gui libs there are not Python, but are fat sickening layers upon layers upon other OO-langs. ==VB went up.
Maybe Borland should go towards a Python GUI/IDE system ...

Python is probably (still) the best _language_ within that top 20 for most purposes. Richest set of libraries probably.
It would be by far the best language for Web and Gui programming as well.
But the Python community has missed to create focus regarding a few must-be-sharp knifes.

The only area with appropriate Python success is probably sci programming.
And there is 2nd-level network programming and some glueing, where Python gathers numbers mostly because of merely the superior language itself.

Python is undersold und the key tools are somewhat too bloomy and fragmented for successful professional application.
Robert

[Christoph Haas]

On Thursday 23 November 2006 21:29, robert wrote:

When a LAMP programmer comes to Python, there are so many different
confusing things. It starts with a 'non-documented' cgi module - a
'High-Level-Interface', that cannot even iterate over the form items. A
name ZOPE in focus which reveals to be a monster system with 2-year
learning-curve, ready for running an article editorial system for TOP-10
newspaper companies, but unable to make simple things simple. A handful
of different Djangos - choose one for each weekday and programmer ...
And Ruby made it with this single-known simple URL-to-method-router (And
possibly when coming from PHP & Perl one recognizes ::@$_$%§§%/&... and
the old namespace dirt) If there would have been a good cgi-system and a
somewhat comfortable advanced URL-to-OO-router (beyond the socket
wrapper HTTPServer) well exposed in the Python standard lib, the numbers
would be probably very different today ...

I can fully second that. Coming from Perl and being used to the CGI module
that is de-facto standard and already doing things much better than
Python's equivalent my first thought was: "Does Python really expect me to
re-invent the wheel to write basic CGIs?" So I started creating
cookie-based session handlers, form field handling etc.

The reason of my posting it not only to complain though. My Python skills
are average but I would really like to help contribute some code on this
topic. I don't know Ruby-on-Rails myself but I have worked with CGIs for
ten years both in C (yuk) and Perl (Perl=semi-yuk / Perl-CGI=yum) and
think I know what people coming from Perl expect. And I'm not speaking of
Zope or Django or huge frameworks. I try to avoid frameworks wherever I
can (I want to write Python - not Zope or Django). I rather rely on the
standard library unless it's really saving me time and worth learning
another language. Are frameworks perhaps even telling that the standard
library is still lacking in some way?

I'm thinking of features like:
- cookie handling
- cookie-session handling (similar to PHP or Perl's CGI::Session; combined
with database backends or simple text files)
- handling of form fields (Perl's CGI class can easily redisplay what
has been entered in the fields when they got submitted through a <FORM>)
- accessing parameters (honestly I haven't yet understood why I need to use
.value on FielStorage dictionaries - why isn't it just a plain
dictionary?)
- state keeping (storing the contents of all form fields on disk
to retrieve it later)
- creating form elements easily (option lists for example from
dictionaries and lists like in Perl)
- creating standard HTML elements (or do you remember how DOCTYPE
looks without looking it up?)
- handling of file uploads (which is just a recipe on ActivePython
at the moment)
- controlling HTTP headers (expires, redirections, charset)
- convenience functions e.g. for getting the client IP address without
needing to read ENV['REMOTE_ADDR']

Well, of course there are modules like 'cgi' or 'cookielib' and others may
argue that everything is already there. And there is a 'Web.py' already (I
assume every CGI programmer has written their own Web.py already). But
can't we come closer to what other scripting languages provide? Something
common? Can't a simple form-based CGI just be a matter of a dozen lines?
When it comes to CGIs Python loses its elegance for no reason.

I'm ready to invest work and ideas if anyone else is interested. Perhaps
some day it makes it into the standard library or at least gives us
something between the features of the standard library and huge framework
monsters - something people can be pointed at when starting with Python
and CGIs. I'll probably do that anyway because my web projects all use
their own reinvented wheel and I'm losing the overview. And even Perl has
come that route - it started with a cgi-lib.pl which later became
the 'CGI' standard module.

Is it just a matter of lacking resources or interest? Even if there is no
interest I'll probably read "man CGI" and "man CGI::Session" again and
start implementing something nifty for ex-perlies like myself. Hmmm,
batteries included even for CGI programmers, a man can dream. :)

Cheers
Christoph

[Paul Boddie]

Christoph Haas wrote:

On Thursday 23 November 2006 21:29, robert wrote:

When a LAMP programmer comes to Python, there are so many different
confusing things. It starts with a 'non-documented' cgi module - a
'High-Level-Interface', that cannot even iterate over the form items. A
name ZOPE in focus which reveals to be a monster system with 2-year
learning-curve, ready for running an article editorial system for TOP-10
newspaper companies, but unable to make simple things simple.

Zope was simultaneously one of the best things to happen in Python Web
programming, but also one of the worst, mostly because people saw the
power of the solution, correctly realised that it could do a lot of
things they would otherwise have to do themselves, but then got locked
into an approach which wasn't suitable for every kind of application.
It was like having a handful of fairly promising parties ruined by the
opening night of an expensive nightclub where the first two drinks were
free.

A handful of different Djangos - choose one for each weekday and programmer ...

The handful of Djangos isn't necessarily a problem, but there is this
"all or nothing" mentality in writing and promoting Web frameworks. Or
rather, an "all or lots of little pieces" mentality. One is left either
with a room full of tiny Lego bricks to put together, or one actually
has to be the python and swallow a large solution whole, hoping that it
all tastes good - even the nasty parts.

And Ruby made it with this single-known simple URL-to-method-router (And
possibly when coming from PHP & Perl one recognizes ::@$_$%§§%/&...and
the old namespace dirt) If there would have been a good cgi-system and a
somewhat comfortable advanced URL-to-OO-router (beyond the socket
wrapper HTTPServer) well exposed in the Python standard lib, the numbers
would be probably very different today ...

There was probably a window of opportunity to include the old Bobo
dispatcher (or perhaps the "Poor Man's Zope" stuff) in the standard
library, but rigid dispatchers of that style arguably aren't sufficient
any more, even though they can be regarded almost as the original
"URL-to-OO router". If you look now, there are a number of
dispatchers/routers that work in a more-or-less independent way from
frameworks, however.

I can fully second that. Coming from Perl and being used to the CGI module
that is de-facto standard and already doing things much better than
Python's equivalent my first thought was: "Does Python really expect me to
re-invent the wheel to write basic CGIs?" So I started creating
cookie-based session handlers, form field handling etc.

The standard library expects you to do that, yes, since many of the
Web-related modules were written in the infancy of the Web and have
only been conservatively updated since. I remember when the cookie
handling went in, and it was a big but overdue event back then.

I rather rely on the standard library unless it's really saving me time and worth learning
another language. Are frameworks perhaps even telling that the standard
library is still lacking in some way?

I believe so, and I'm not alone with that opinion.

I'm thinking of features like:

[List of HTTP-related, persistence-related and templating-related
things]

I'm ready to invest work and ideas if anyone else is interested.

Take a look at this page for some other work with similar goals:

http://wiki.python.org/moin/WebStandardisation

Perhaps some day it makes it into the standard library or at least gives us
something between the features of the standard library and huge framework
monsters - something people can be pointed at when starting with Python
and CGIs. I'll probably do that anyway because my web projects all use
their own reinvented wheel and I'm losing the overview. And even Perl has
come that route - it started with a cgi-lib.pl which later became
the 'CGI' standard module.

Some people will argue that you just want a big framework (implying
that they know what you want better than you do), whilst others will
talk about lots of reusable middleware. I don't disagree with the
component-based solution mindset, but the bricks really have to be
bigger, and there needs to be a picture on the box showing what the
finished model looks like, along with some clear instructions on
getting started.

Is it just a matter of lacking resources or interest? Even if there is no
interest I'll probably read "man CGI" and "man CGI::Session" again and
start implementing something nifty for ex-perlies like myself. Hmmm,
batteries included even for CGI programmers, a man can dream. :)

I am aware of at least one person who seems dissatisfied with the
current level of standardisation and who wants something a bit more
obvious for those who don't want to take the "30 second Wiki" route.
Perhaps they could openly publish their ideas or proposals and we could
establish some kind of unofficial standard around those things. I'd
certainly be interested in moving things forward in that regard.

Paul

[robert]

Christoph Haas wrote:

On Thursday 23 November 2006 21:29, robert wrote:

>When a LAMP programmer comes to Python, there are so many different
confusing things. It starts with a 'non-documented' cgi module - a
'High-Level-Interface', that cannot even iterate over the form items. A
name ZOPE in focus which reveals to be a monster system with 2-year
learning-curve, ready for running an article editorial system for TOP-10
newspaper companies, but unable to make simple things simple. A handful
of different Djangos - choose one for each weekday and programmer ...
And Ruby made it with this single-known simple URL-to-method-router (And
possibly when coming from PHP & Perl one recognizes ::@$_$%§§%/&... and
the old namespace dirt) If there would have been a good cgi-system and a
somewhat comfortable advanced URL-to-OO-router (beyond the socket
wrapper HTTPServer) well exposed in the Python standard lib, the numbers
would be probably very different today ...

I can fully second that. Coming from Perl and being used to the CGI module
that is de-facto standard and already doing things much better than
Python's equivalent my first thought was: "Does Python really expect me to
re-invent the wheel to write basic CGIs?" So I started creating
cookie-based session handlers, form field handling etc.

That exactly is where Python lost real numbers. All kinds of fancy things are in the standard lib, but not these must-have's in a good collection ..

The reason of my posting it not only to complain though. My Python skills
are average but I would really like to help contribute some code on this
topic. I don't know Ruby-on-Rails myself but I have worked with CGIs for
ten years both in C (yuk) and Perl (Perl=semi-yuk / Perl-CGI=yum) and
think I know what people coming from Perl expect. And I'm not speaking of
Zope or Django or huge frameworks. I try to avoid frameworks wherever I
can (I want to write Python - not Zope or Django). I rather rely on the
standard library unless it's really saving me time and worth learning
another language. Are frameworks perhaps even telling that the standard
library is still lacking in some way?

well, note, for that they have named it Ruby-On-Rails, so its still the language - leveraged.
While it is Zope/Django/Ego-on-Python ... ?

So its about the right level of a framework. (even a cgi module is a framework.)

I think i could learn to like this one as basic intuitive idea: http://www.cherrypy.org/

Unless a Guido'ed version of such thing is not _selected_ into the stdlib or at least promoted single-mindedly and prominently by far before high-tech-but-low-number names like Zope and Django, Python will continue to bleed out heavily on numbers vs. Ruby.

First need of course: an update of that cgi "module".

I'm thinking of features like:
- cookie handling
- cookie-session handling (similar to PHP or Perl's CGI::Session; combined
with database backends or simple text files)
- handling of form fields (Perl's CGI class can easily redisplay what
has been entered in the fields when they got submitted through a <FORM>)
- accessing parameters (honestly I haven't yet understood why I need to use
.value on FielStorage dictionaries - why isn't it just a plain
dictionary?)
- state keeping (storing the contents of all form fields on disk
to retrieve it later)
- creating form elements easily (option lists for example from
dictionaries and lists like in Perl)
- creating standard HTML elements (or do you remember how DOCTYPE
looks without looking it up?)
- handling of file uploads (which is just a recipe on ActivePython
at the moment)
- controlling HTTP headers (expires, redirections, charset)
- convenience functions e.g. for getting the client IP address without
needing to read ENV['REMOTE_ADDR']

tell it loud

Well, of course there are modules like 'cgi' or 'cookielib' and others may

Cookie. (cookielib is for clients.)
But read the doc chapter "Cookie -- HTTP state management"...
What is 'input': "If input is given, it is passed to the load() method. " ...
So first read the "Example", oohhhh .... :-)

I tell you - you will know how to achieve cookie/session handling before you read all source code and the RFC's

So its not much disadvantage to not know about the existence of this module.

argue that everything is already there. And there is a 'Web.py' already (I
assume every CGI programmer has written their own Web.py already). But

yes - which Web.py :-) another v0.138 : http://webpy.org/ ?

can't we come closer to what other scripting languages provide? Something
common? Can't a simple form-based CGI just be a matter of a dozen lines?
When it comes to CGIs Python loses its elegance for no reason.

No other language could do it in less lines. There is no other excuse than: *********

I'm ready to invest work and ideas if anyone else is interested. Perhaps
some day it makes it into the standard library or at least gives us
something between the features of the standard library and huge framework
monsters - something people can be pointed at when starting with Python
and CGIs. I'll probably do that anyway because my web projects all use
their own reinvented wheel and I'm losing the overview. And even Perl has
come that route - it started with a cgi-lib.pl which later became
the 'CGI' standard module.

I'd vote for that.

Is it just a matter of lacking resources or interest? Even if there is no

python-dev is fully occupied with top-notch inner life. Of course that is the basis.
But key issues in lib&tools were simply forgotten - left to a random community.

interest I'll probably read "man CGI" and "man CGI::Session" again and
start implementing something nifty for ex-perlies like myself. Hmmm,
batteries included even for CGI programmers, a man can dream. :)

Go for a start. In order to realize that essential batteries in good quality within time - even after 10 years now - it is necessary, to hook python-dev for even requesting it actively. Just adding to http://wiki.python.org/moin/WebProgramming and http://wiki.python.org/moin/WebFrameworks is not the task. It requires some organization and somewhat a selection process in addition to good (probably existing) code v0.1xxx material.
I think it would not be overly complex. Both, a new cgi and possibly included snake "rails" (vs "oil")
Robert

[Christoph Haas]

On Friday 24 November 2006 13:08, robert wrote:

well, note, for that they have named it Ruby-On-Rails, so its still the
language - leveraged. While it is Zope/Django/Ego-on-Python ... ?

If by that you mean that neither Zope nor Django are exactly pythonic I
think I concur.

Unless a Guido'ed version of such thing is not _selected_ into the
stdlib or at least promoted single-mindedly and prominently by far
before high-tech-but-low-number names like Zope and Django, Python will
continue to bleed out heavily on numbers vs. Ruby.

Guido seems to have been confused about the rank growth of web based
frameworks himself. So it's even less likely one of them gets included as
part of the standard library in finite time.

First need of course: an update of that cgi "module".

Oh, yeah. I just joined the Web SIG and found out that WSGI seems the way
to go. At a first look it seems horrible if you just want to provide a CGI
module. But there must be some reason for its existence. :) Looking
further through http://wiki.python.org/moin/WebFrameworks my head starts
to spin. Somehow I sadly feel I would just add another incomplete
framework to that pile.

I'm especially unsure whether it's good or bad to create another "I'm sick
of the standard library"-style module. I've just become a bit less
confident to actually contribute something useful there. Overwhelming.

python-dev is fully occupied with top-notch inner life. Of course that
is the basis. But key issues in lib&tools were simply forgotten - left
to a random community.

Which doesn't match the "batteries included" fuss at all. Of course the
basis has to be good, too. And there are so many paradigms today that no
core-python developer can really be expected to provide good standard
modules for everyone.

Go for a start. In order to realize that essential batteries in good
quality within time - even after 10 years now - it is necessary, to hook
python-dev for even requesting it actively. Just adding to
http://wiki.python.org/moin/WebProgramming and
http://wiki.python.org/moin/WebFrameworks is not the task. It requires
some organization and somewhat a selection process in addition to good
(probably existing) code v0.1xxx material. I think it would not be
overly complex. Both, a new cgi and possibly included snake "rails" (vs
"oil")

Oil is deprecated anyway. :) I'll see if I can find my way into the SIG.
And - yes - adding another framework will surely not help us out of the
divergence. The more frameworks there are the more people seem to feel
urged to say "heck, it will be easier to write my own framework than
evaluate all 30 packages on that page".

Christoph

[Fredrik Lundh]

Christoph Haas wrote:

>well, note, for that they have named it Ruby-On-Rails, so its still the
language - leveraged. While it is Zope/Django/Ego-on-Python ... ?

If by that you mean that neither Zope nor Django are exactly pythonic I
think I concur.

Django is highly Pythonic (it's pure Python plus templates, and has the same
"pencil-like qualities" as Python itself). Zope 3 is highly Pythonic too, but a
rather more advanced form of Python. but they're both application servers,
not CGI scripting environments.

>First need of course: an update of that cgi "module".

Oh, yeah. I just joined the Web SIG and found out that WSGI seems the way
to go. At a first look it seems horrible if you just want to provide a CGI
module.

WSGI is a CGI replacement, not a CGI implementation. Which is a good thing,
because what really matters, if you think about what a web server is doing, is the
HTTP protocol, not an old and not always practical httpd extension standard.
WSGI simply provides plumbing for working very close to the HTTP level.

(you can of course create a WSGI-compatible adapter for CGI in no time at
all, but that's not really the point of WSGI).

Somehow I sadly feel I would just add another incomplete framework to that
pile.

as they say, if you don't understand history, you're bound to repeat it ;-)

I'm especially unsure whether it's good or bad to create another "I'm sick
of the standard library"-style module. I've just become a bit less
confident to actually contribute something useful there. Overwhelming.

Building a "like cgi.py, but with more support for the kind of things people actually
need" library would be an excellent idea. It's not clear from your posts that you
"get" what things like Django and Zope do, and how that's different from "CGI
programming", but if you have a deep understanding of the latter, I'm sure you
could come up with a nice "cgi2.py" library with relatively little effort. Get to
work!

</F>

[Thomas Guettler]

Christoph Haas wrote:
....

Oh, yeah. I just joined the Web SIG and found out that WSGI
seems the way
to go.

....

I don't want a standard, i want *one* implementation. In the
Java world, there are a lot of standards and N*standards
implementations. In the end you have the opposite of what
a standard should give you: Bad interopability.

One implemantation (which is in the standard library) would
be the right coice. But what could I do? (I am not a python
core developer)? I could only create a new web framework.
And that's why there are so many.

I hope Guido (or someone else who can do this) will decide to choose one
soon.
Thomas

--
Thomas Güttler, http://www.thomas-guettler.de/ http://www.tbz-pariv.de/
E-Mail: guettli (*) thomas-guettler + de
Spam Catcher: ni**************@thomas-guettler.de

[robert]

Christoph Haas wrote:

On Friday 24 November 2006 13:08, robert wrote:

>well, note, for that they have named it Ruby-On-Rails, so its still the
language - leveraged. While it is Zope/Django/Ego-on-Python ... ?

If by that you mean that neither Zope nor Django are exactly pythonic I
think I concur.

on-python, but not python-on :-) - as we discussed about "framework vs. directness/intuition"
Zope and Django's Ego certainly won't fit into/near the stdlib

>Unless a Guido'ed version of such thing is not _selected_ into the
stdlib or at least promoted single-mindedly and prominently by far
before high-tech-but-low-number names like Zope and Django, Python will
continue to bleed out heavily on numbers vs. Ruby.

Guido seems to have been confused about the rank growth of web based
frameworks himself. So it's even less likely one of them gets included as
part of the standard library in finite time.

Yet so he will decide about the magnitude of order of future Python users. I'm sure the door will open once ..
Py3K will not make as big a change regarding this magnitude.

>First need of course: an update of that cgi "module".

Oh, yeah. I just joined the Web SIG and found out that WSGI seems the way
to go. At a first look it seems horrible if you just want to provide a CGI
module. But there must be some reason for its existence. :) Looking
further through http://wiki.python.org/moin/WebFrameworks my head starts
to spin. Somehow I sadly feel I would just add another incomplete
framework to that pile.

I'm especially unsure whether it's good or bad to create another "I'm sick
of the standard library"-style module. I've just become a bit less
confident to actually contribute something useful there. Overwhelming.

tying selected techniques together on the right level is the task. Its not forbidden to learn a little from Rails and Perl module structure.

>python-dev is fully occupied with top-notch inner life. Of course that
is the basis. But key issues in lib&tools were simply forgotten - left
to a random community.

Which doesn't match the "batteries included" fuss at all. Of course the
basis has to be good, too. And there are so many paradigms today that no
core-python developer can really be expected to provide good standard
modules for everyone.

>Go for a start. In order to realize that essential batteries in good
quality within time - even after 10 years now - it is necessary, to hook
python-dev for even requesting it actively. Just adding to
http://wiki.python.org/moin/WebProgramming and
http://wiki.python.org/moin/WebFrameworks is not the task. It requires
some organization and somewhat a selection process in addition to good
(probably existing) code v0.1xxx material. I think it would not be
overly complex. Both, a new cgi and possibly included snake "rails" (vs
"oil")

Oil is deprecated anyway. :) I'll see if I can find my way into the SIG.
And - yes - adding another framework will surely not help us out of the
divergence. The more frameworks there are the more people seem to feel
urged to say "heck, it will be easier to write my own framework than
evaluate all 30 packages on that page".

Christoph

[robert]

Thomas Guettler wrote:

Christoph Haas wrote:
...

>Oh, yeah. I just joined the Web SIG and found out that WSGI
seems the way
to go.

...

I don't want a standard, i want *one* implementation. In the
Java world, there are a lot of standards and N*standards
implementations. In the end you have the opposite of what
a standard should give you: Bad interopability.

One implemantation (which is in the standard library) would
be the right coice. But what could I do? (I am not a python
core developer)? I could only create a new web framework.
And that's why there are so many.

I hope Guido (or someone else who can do this) will decide to choose one
soon.

yes. this talking about formation of somewhat a standardization gremium within some years etc. is not the task.
There is enough base material. There are guys who have an overview of what is good. There are guys who know the details.
A decision call from the inner circle for an actual (probably joint) implementation is necessary.

Regarding the python-on..-"framework" the greatest danger would be, to make it too big. ( its not about full replacement of the existing big packages )

Robert

[robert]

Fredrik Lundh wrote:

Christoph Haas wrote:

>>well, note, for that they have named it Ruby-On-Rails, so its still the
language - leveraged. While it is Zope/Django/Ego-on-Python ... ?

If by that you mean that neither Zope nor Django are exactly pythonic I
think I concur.

Django is highly Pythonic (it's pure Python plus templates, and has the same
"pencil-like qualities" as Python itself). Zope 3 is highly Pythonic too, but a
rather more advanced form of Python. but they're both application servers,
not CGI scripting environments.

pythonic yes, but ..-on-python

>>First need of course: an update of that cgi "module".

Oh, yeah. I just joined the Web SIG and found out that WSGI seems the way
to go. At a first look it seems horrible if you just want to provide a CGI
module.

WSGI is a CGI replacement, not a CGI implementation. Which is a good thing,
because what really matters, if you think about what a web server is doing, is the
HTTP protocol, not an old and not always practical httpd extension standard.
WSGI simply provides plumbing for working very close to the HTTP level.

(you can of course create a WSGI-compatible adapter for CGI in no time at
all, but that's not really the point of WSGI).

its a low level tech basis. Regarding the discussion here, its also the enabler for the confusion :-)

>Somehow I sadly feel I would just add another incomplete framework to that
pile.

as they say, if you don't understand history, you're bound to repeat it ;-)

we are currently bound to repeat 30+ histories. no wonder - nobody will ever understand it and go to Rails & Co.

>I'm especially unsure whether it's good or bad to create another "I'm sick
of the standard library"-style module. I've just become a bit less
confident to actually contribute something useful there. Overwhelming.

Building a "like cgi.py, but with more support for the kind of things people actually
need" library would be an excellent idea. It's not clear from your posts that you
"get" what things like Django and Zope do, and how that's different from "CGI
programming", but if you have a deep understanding of the latter, I'm sure you
could come up with a nice "cgi2.py" library with relatively little effort. Get to
work!

think both are missing standard modules: cgi2 and a comfortable OO-dispatcher/server with clear tutorials. And to have them in front on the Python display window.
Robert

[Harry George]

Christoph Haas <em***@christoph-haas.dewrites:

On Thursday 23 November 2006 21:29, robert wrote:

When a LAMP programmer comes to Python, there are so many different
confusing things. It starts with a 'non-documented' cgi module - a
'High-Level-Interface', that cannot even iterate over the form items. A
name ZOPE in focus which reveals to be a monster system with 2-year
learning-curve, ready for running an article editorial system for TOP-10
newspaper companies, but unable to make simple things simple. A handful
of different Djangos - choose one for each weekday and programmer ...
And Ruby made it with this single-known simple URL-to-method-router (And
possibly when coming from PHP & Perl one recognizes ::@$_$%§§%/&... and
the old namespace dirt) If there would have been a good cgi-system and a
somewhat comfortable advanced URL-to-OO-router (beyond the socket
wrapper HTTPServer) well exposed in the Python standard lib, the numbers
would be probably very different today ...

I can fully second that. Coming from Perl and being used to the CGI module
that is de-facto standard and already doing things much better than
Python's equivalent my first thought was: "Does Python really expect me to
re-invent the wheel to write basic CGIs?" So I started creating
cookie-based session handlers, form field handling etc.

The reason of my posting it not only to complain though. My Python skills
are average but I would really like to help contribute some code on this
topic. I don't know Ruby-on-Rails myself but I have worked with CGIs for
ten years both in C (yuk) and Perl (Perl=semi-yuk / Perl-CGI=yum) and
think I know what people coming from Perl expect. And I'm not speaking of
Zope or Django or huge frameworks. I try to avoid frameworks wherever I
can (I want to write Python - not Zope or Django). I rather rely on the
standard library unless it's really saving me time and worth learning
another language. Are frameworks perhaps even telling that the standard
library is still lacking in some way?

I'm thinking of features like:
- cookie handling
- cookie-session handling (similar to PHP or Perl's CGI::Session; combined
with database backends or simple text files)
- handling of form fields (Perl's CGI class can easily redisplay what
has been entered in the fields when they got submitted through a <FORM>)
- accessing parameters (honestly I haven't yet understood why I need to use
.value on FielStorage dictionaries - why isn't it just a plain
dictionary?)
- state keeping (storing the contents of all form fields on disk
to retrieve it later)
- creating form elements easily (option lists for example from
dictionaries and lists like in Perl)
- creating standard HTML elements (or do you remember how DOCTYPE
looks without looking it up?)
- handling of file uploads (which is just a recipe on ActivePython
at the moment)
- controlling HTTP headers (expires, redirections, charset)
- convenience functions e.g. for getting the client IP address without
needing to read ENV['REMOTE_ADDR']

Well, of course there are modules like 'cgi' or 'cookielib' and others may
argue that everything is already there. And there is a 'Web.py' already (I
assume every CGI programmer has written their own Web.py already). But
can't we come closer to what other scripting languages provide? Something
common? Can't a simple form-based CGI just be a matter of a dozen lines?
When it comes to CGIs Python loses its elegance for no reason.

I'm ready to invest work and ideas if anyone else is interested. Perhaps
some day it makes it into the standard library or at least gives us
something between the features of the standard library and huge framework
monsters - something people can be pointed at when starting with Python
and CGIs. I'll probably do that anyway because my web projects all use
their own reinvented wheel and I'm losing the overview. And even Perl has
come that route - it started with a cgi-lib.pl which later became
the 'CGI' standard module.

Is it just a matter of lacking resources or interest? Even if there is no
interest I'll probably read "man CGI" and "man CGI::Session" again and
start implementing something nifty for ex-perlies like myself. Hmmm,
batteries included even for CGI programmers, a man can dream. :)

Cheers
Christoph

When I came from Perl, I too missed perl-isms and specifically CGI.pm, so wrote my own:
http://www.seanet.com/~hgg9140/comp/index.html
http://www.seanet.com/~hgg9140/comp/...oc/manual.html
http://www.seanet.com/~hgg9140/comp/...doc/index.html

Others on this newsgroup said I'd be better off just doing it in raw
python. After a while, I realized that was true. You do
triple-quoted templates with normal python idioms. Throw in
some persistence mechanisms to deal with maintaining state across
transactions, and you are in business.

Since then I've looked at Zope, Plone, TurboGears, Django, and (for
standalone apps) Dabo. TurboGears is mostly a set of recommendations
on what 3rd party packages to use, with a wee bit of glueware. So far
nothing feels as simple as just doing it in python.

--
Harry George
PLM Engineering Architecture

[robert]

Harry George wrote:

When I came from Perl, I too missed perl-isms and specifically CGI.pm, so wrote my own:
http://www.seanet.com/~hgg9140/comp/index.html
http://www.seanet.com/~hgg9140/comp/...oc/manual.html
http://www.seanet.com/~hgg9140/comp/...doc/index.html

Others on this newsgroup said I'd be better off just doing it in raw
python. After a while, I realized that was true. You do
triple-quoted templates with normal python idioms. Throw in
some persistence mechanisms to deal with maintaining state across
transactions, and you are in business.

Since then I've looked at Zope, Plone, TurboGears, Django, and (for
standalone apps) Dabo. TurboGears is mostly a set of recommendations
on what 3rd party packages to use, with a wee bit of glueware. So far
nothing feels as simple as just doing it in python.

Thats the fragmented journey, almost any web programmer has to go when coming to python. A clear standard, even a clear intro, for simple tasks, like doing state mng, db, error handling, etc. is not there on an easy path.

For a level above cgi, what do you think about cherrypy ? http://docs.cherrypy.org/

Robert

[Harry George]

robert <no*****@no-spam-no-spam.invalidwrites:

Harry George wrote:

When I came from Perl, I too missed perl-isms and specifically CGI.pm, so wrote my own:
http://www.seanet.com/~hgg9140/comp/index.html
http://www.seanet.com/~hgg9140/comp/...oc/manual.html
http://www.seanet.com/~hgg9140/comp/...doc/index.html
Others on this newsgroup said I'd be better off just doing it in raw
python. After a while, I realized that was true. You do
triple-quoted templates with normal python idioms. Throw in
some persistence mechanisms to deal with maintaining state across
transactions, and you are in business.
Since then I've looked at Zope, Plone, TurboGears, Django, and (for
standalone apps) Dabo. TurboGears is mostly a set of recommendations
on what 3rd party packages to use, with a wee bit of glueware. So far
nothing feels as simple as just doing it in python.

Thats the fragmented journey, almost any web programmer has to go when coming to python. A clear standard, even a clear intro, for simple tasks, like doing state mng, db, error handling, etc. is not there on an easy path.

For a level above cgi, what do you think about cherrypy ? http://docs.cherrypy.org/

Robert

I have only done "hello, world" stuff in cherrypy. We do everything
from apache, so the server part of cherrypy wouldn't be needed, and
getting to it from a mod_rewrite would just be extra hassle.

Mostly we do model-view-controller, were the "view" may be batch,
commandline, desktop gui, GUI, SOAP, etc. If it works with a simple
coded-by-hand CGI, that's all we do.

--
Harry George
PLM Engineering Architecture