By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,645 Members | 1,065 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,645 IT Pros & Developers. It's quick & easy.

Yet another comparison of Python Web Frameworks

P: n/a
At work we are shopping for a Web framework, so I have been looking at
the available options
on the current market. In particular I have looked at Paste and Pylons
and I have written my
impressions here:

http://www.phyast.pitt.edu/~micheles...rameworks.html

I do not speak too well of Pylons, so if you thing I am wrong feel
free to correct me here ;)
Michele Simionato

Oct 6 '07 #1
Share this Question
Share on Google+
37 Replies


P: n/a
Michele Simionato:
At work we are shopping for a Web framework, so I have been looking at
the available options
on the current market.
At least, you missed Turbo Gears :)
http://turbogears.org/
For me, it feels more integrated than Pylons.

--
Thomas Wittek
Web: http://gedankenkonstrukt.de/
Jabber: st*********@jabber.i-pobox.net
GPG: 0xF534E231
Oct 6 '07 #2

P: n/a
Thomas Wittek <ma**@gedankenkonstrukt.dewrote:
At least, you missed Turbo Gears :)
http://turbogears.org/
For me, it feels more integrated than Pylons.
Yeah, so integrated that the next version will be based upon Pylons ;-)
?

--
Lawrence, oluyede.org - neropercaso.it
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair
Oct 6 '07 #3

P: n/a
>At work we are shopping for a Web framework, so I have been
>looking at the available options on the current market.

At least, you missed Turbo Gears :)
http://turbogears.org/
For me, it feels more integrated than Pylons.
Django [1] barely gets anything more than a mention as well.

Any respectable comparison of Python web frameworks should
include evaluation of at least Django and TG. Or at least give
good reason why the comparison excludes them.

Zope is also missing, but I'm not sure Zope qualifies so much as
a framework, but as an answer to the question "If Emacs were a
Python web environment, what would it look like?"

I chose Django, but saw the power in TG as well...from my testing
of them, Django has a nice unified OOB experience, while TG feels
like it's trying to rein in very strong, but disparate parts.
Django's built-in templating system is one of those things you
either love or you hate. Fortunately, if you're a hater, you can
mindlessly swap it out for your template system of choice with
minimal fuss.

-tim

[1] http://www.djangoproject.com
Oct 6 '07 #4

P: n/a
Tim Chase wrote:
Any respectable comparison of Python web frameworks should
include evaluation of at least Django and TG. Or at least give
good reason why the comparison excludes them.
When he said that he didn't want anything complex neither anything that used
a templating system, I thought this had already excluded a lot of
frameworks, including TG and Django.
Zope is also missing, but I'm not sure Zope qualifies so much as
a framework, but as an answer to the question "If Emacs were a
Python web environment, what would it look like?"
He already had dislikings with Plone that weren't clear, maybe a lot of
those are Zope related...
I agree, though, that more time could be spent explaining "why" things were
discarded / ignored.
Oct 6 '07 #5

P: n/a
Lawrence Oluyede wrote:
Thomas Wittek <ma**@gedankenkonstrukt.dewrote:
>At least, you missed Turbo Gears :)
http://turbogears.org/
For me, it feels more integrated than Pylons.

Yeah, so integrated that the next version will be based upon Pylons ;-) ?
What is good, since a lot of good things from Pylons will work with TG and a
lot of good TG things will remain (and possibly be compatible with Pylons).
If you take a better look at "the next version", you'll also see that the
major concern was with WSGI support and reinventing / "rewriting" the wheel
(what TG developers don't want to do all the time).

As an example of this fusion, take a look at ToscaWidgets. Works, *today*,
with both frameworks. You don't have to wait for "the next version".
Oct 6 '07 #6

P: n/a
On Oct 6, 7:15 am, Jorge Godoy <jgo...@gmail.comwrote:
Tim Chase wrote:
Any respectable comparison of Python web frameworks should
include evaluation of at least Django and TG. Or at least give
good reason why the comparison excludes them.

Mine is not a respectable comparison of Web frameworks, it is
NOT intended to be so. It is just a set of notes I kept for
myself and that may be or may be not of interest to others.
When he said that he didn't want anything complex neither anything that used
a templating system, I thought this had already excluded a lot of
frameworks, including TG and Django.
This is clearly not true, since I could use these frameworks
without using their templates if I wanted. It would be very
stupid to dismiss an entire framework only because I dislike
its templates.
Zope is also missing, but I'm not sure Zope qualifies so much as
a framework, but as an answer to the question "If Emacs were a
Python web environment, what would it look like?"

He already had dislikings with Plone that weren't clear, maybe a lot of
those are Zope related...

I agree, though, that more time could be spent explaining "why" things were
discarded / ignored.
Look, there are already tons of pages on the net ranting against
Zope, my complaints are quite common and I have no interest
in repeating what has been already said. For instance, if you
Google a bit you should find the rants of the Quixote people
against Zope. I share their position.
I did not talk about TG because I see it as being very close to
Pylons and everybody is saying they will be unified in the near
future, so it would be a waste of effort to discuss TG per se.

Michele Simionato

Oct 6 '07 #7

P: n/a
Michele Simionato a écrit :
At work we are shopping for a Web framework, so I have been looking at
the available options
on the current market. In particular I have looked at Paste and Pylons
and I have written my
impressions here:

http://www.phyast.pitt.edu/~micheles...rameworks.html

I do not speak too well of Pylons, so if you thing I am wrong feel
free to correct me here ;)
Well... Last year, I had a look at Pylons, then played a bit with wsgi
and building my own framework over it. I finally dropped that code and
went back to Pylons, which I felt could become far better than my own
efforts. Now since then I had way too much to do at work (using other
technos) and didn't find the time to work on my own projects, so I still
don't know how well Pylons will pass the "real world" test, but it seems
to me that it's rapidly progressing and mostly in the right direction. I
still wait for an opportunity to check this out !-)

While we're at it:

- talking about routes, you say:

"""
I have no Ruby On Rails background, so I don't see the advantages of routes.
"""

I don't have any RoR neither, but as far as I'm concerned, one of the
big points with routes is url_for(), that avoids having too much
hard-coded urls.

- about FormEncode : that's a package I've used before without Pylons,
and while it has a few dark corners, it's mostly doing TheRightThing for
most current validation/conversion tasks. I'll still use it with or
without Pylons

- about SQLAlchemy : here again, I used this package prior any
experience with Pylons. FWIW, I used it in the most basic, 'low-level'
way, ie without any ORM stuff, and I found it to be a pretty good
alternative to db-api. It's a bit complex, but powerful, and having the
possibility to handle sql requests as Python objects (instead of raw
strings) really helps.
Oct 6 '07 #8

P: n/a
On Oct 6, 9:13 am, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.comwrote:
- talking about routes, you say:

"""
I have no Ruby On Rails background, so I don't see the advantages of routes.
"""

I don't have any RoR neither, but as far as I'm concerned, one of the
big points with routes is url_for(), that avoids having too much
hard-coded urls.
Well, url_for is convenient, I would not deny it. Still it is
not compelling to me.
- about FormEncode : that's a package I've used before without Pylons,
and while it has a few dark corners, it's mostly doing TheRightThing for
most current validation/conversion tasks. I'll still use it with or
without Pylons

- about SQLAlchemy : here again, I used this package prior any
experience with Pylons. FWIW, I used it in the most basic, 'low-level'
way, ie without any ORM stuff, and I found it to be a pretty good
alternative to db-api. It's a bit complex, but powerful, and having the
possibility to handle sql requests as Python objects (instead of raw
strings) really helps.
I have wanted to do a serious test of SQLAlchemy for a
couple of years, but never found the time :-(

Do you (or something else) have something to say about Beaker?
I looked at the source code and it seems fine to me, but I have
not used it directly, not stressed it. I need a
production-level WSGI session middleware and I wonder what the
players are (for instance how Beaker does compare with flup?)

Michele Simionato

Oct 6 '07 #9

P: n/a
Jorge Godoy <jg****@gmail.comwrote:
What is good, since a lot of good things from Pylons will work with TG and a
lot of good TG things will remain (and possibly be compatible with Pylons).
If you take a better look at "the next version", you'll also see that the
major concern was with WSGI support and reinventing / "rewriting" the wheel
(what TG developers don't want to do all the time).
Not reinventing the wheel just don't feel as a universal dogma to me. I
developed quite a bit with Django and I was glad they started from
scratch. On the paper reusing different and existing projects is great
but not always is good or done the right way. Anyway I don't know TG at
all so I'm speaking in a figurative way.

We (Michele, myself and our colleagues) have a series of stuff we need
to stick to so the choosing of a web framework ain't that easy. Most of
the frameworks are a vision of the author of how to do things from
scratch but a framework (by definition an evolution of a library) is not
always meant to be used when the scratch is far from your starting
point.

I'd like to read some commenting of Michele's thoughts, they would be
really useful.

:-)

--
Lawrence, oluyede.org - neropercaso.it
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair
Oct 6 '07 #10

P: n/a
Tim Chase <py*********@tim.thechases.comwrote:
Any respectable comparison of Python web frameworks should
include evaluation of at least Django and TG. Or at least give
good reason why the comparison excludes them.
I think you didn't read the foreword of the comparison. That is by no
means a comprehensive comparison and is not meant to be one. Is a series
of thoughts about the frameworks we already tried (we don't have to
decide today) and the ones we experimented with. Django is not
completely off the radar because I used it extensively this year but the
company has certain requirements and the full stackness of Django is not
really one of our needs.
Zope is also missing, but I'm not sure Zope qualifies so much as
a framework, but as an answer to the question "If Emacs were a
Python web environment, what would it look like?"
Zope2/Plone2 is the one framework they are running away from :-)
More KISS less over engineering, that's the mantra.
Django's built-in templating system is one of those things you
either love or you hate. Fortunately, if you're a hater, you can
mindlessly swap it out for your template system of choice with
minimal fuss.
I really, really like Django (and its community and the competence of
the developers) and I think it deserves what it has gained and more but
we are not here to decide who's the best (there's always no best).

--
Lawrence, oluyede.org - neropercaso.it
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair
Oct 6 '07 #11

P: n/a
I really, really like Django (and its community and the competence of
the developers) and I think it deserves what it has gained and more but
we are not here to decide who's the best (there's always no best).
+1 QOTW

Oct 6 '07 #12

P: n/a
On Oct 6, 12:57 pm, Bruno Desthuilliers
Michele Simionato a écrit :
I looked at the source code and it seems fine to me, but I have
not used it directly, not stressed it. I need a
production-level WSGI session middleware and I wonder what the
players are (for instance how Beaker does compare with flup?)

Can't tell, but I'd trust the Pylons team on this kind of choices.
They're doing good job so far AFAICT.
Probably Beaker works well, but it is certainly NOT doing things
as Eby recommends:

http://dirtsimple.org/2007/02/wsgi-m...d-harmful.html

BTW, I know that Eby is asking opinions about WSGI 2.0 on the
WSGI SIG and interested people may have a look there.

Michele Simionato

Oct 7 '07 #13

P: n/a
On Oct 7, 8:35 am, Michele Simionato <michele.simion...@gmail.com>
wrote:
On Oct 6, 12:57 pm, Bruno Desthuilliers
Michele Simionato a écrit :
I looked at the source code and it seems fine to me, but I have
not used it directly, not stressed it. I need a
production-level WSGI session middleware and I wonder what the
players are (for instance how Beaker does compare with flup?)
Can't tell, but I'd trust the Pylons team on this kind of choices.
They're doing good job so far AFAICT.

Probably Beaker works well, but it is certainly NOT doing things
as Eby recommends:

http://dirtsimple.org/2007/02/wsgi-m...d-harmful.html

BTW, I know that Eby is asking opinions about WSGI 2.0 on the
WSGI SIG and interested people may have a look there.

Michele Simionato

I think that Beaker is a Mako dependency.
So if you use Mako, Beaker is not an option :)

G

Oct 7 '07 #14

P: n/a
Lawrence Oluyede wrote:
Jorge Godoy <jg****@gmail.comwrote:
>What is good, since a lot of good things from Pylons will work with TG and a
lot of good TG things will remain (and possibly be compatible with Pylons).
If you take a better look at "the next version", you'll also see that the
major concern was with WSGI support and reinventing / "rewriting" the wheel
(what TG developers don't want to do all the time).

Not reinventing the wheel just don't feel as a universal dogma to me. I
developed quite a bit with Django and I was glad they started from
scratch. On the paper reusing different and existing projects is great
but not always is good or done the right way. Anyway I don't know TG at
all so I'm speaking in a figurative way.

We (Michele, myself and our colleagues) have a series of stuff we need
to stick to so the choosing of a web framework ain't that easy. Most of
the frameworks are a vision of the author of how to do things from
scratch but a framework (by definition an evolution of a library) is not
always meant to be used when the scratch is far from your starting
point.

I'd like to read some commenting of Michele's thoughts, they would be
really useful.

:-)
Porting existing web applications to new architectures requires more
than just transliteration, since you lose some metaphors available only
in the donor system and may therefore need to take advantage of new
idioms in the new environment to compensate.

I spent some time trying to re-architect the code from "Python Web
Programming" in TurboGears. That was difficult not because TG is a bad
system but because there was an impedance mismatch between the original
code's framework and the way TG does things.

I guess I would have similar problems with Django.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline so I couldn't cat it

Oct 7 '07 #15

P: n/a
Steve Holden a écrit :
Lawrence Oluyede wrote:
(snip)
>We (Michele, myself and our colleagues) have a series of stuff we need
to stick to so the choosing of a web framework ain't that easy. Most of
the frameworks are a vision of the author of how to do things from
scratch but a framework (by definition an evolution of a library) is not
always meant to be used when the scratch is far from your starting
point.
Porting existing web applications to new architectures requires more
than just transliteration, since you lose some metaphors available only
in the donor system and may therefore need to take advantage of new
idioms in the new environment to compensate.

I spent some time trying to re-architect the code from "Python Web
Programming" in TurboGears. That was difficult not because TG is a bad
system but because there was an impedance mismatch between the original
code's framework and the way TG does things.

I guess I would have similar problems with Django.
Indeed. But AFAICT, Lawrence and Michele problems is not to port an
existing web application, but to choose a web framework that will play
well with their existing *system* (RDBMS, existing apps and libs etc).
Which is quite another problem, and may eliminate some otherwise pretty
good frameworks for compatibility reasons (DBMS support and other issues).

(please Michele or Lawrence correct me if I'm wrong...)
Oct 7 '07 #16

P: n/a
On Oct 7, 8:36 am, Bruno Desthuilliers
Indeed. But AFAICT, Lawrence and Michele problems is not to port an
existing web application, but to choose a web framework that will play
well with their existing *system* (RDBMS, existing apps and libs etc).
Which is quite another problem, and may eliminate some otherwise pretty
good frameworks for compatibility reasons (DBMS support and other issues).

(please Michele or Lawrence correct me if I'm wrong...)
Yes, our main concern is compatibility with the existing
system: for instance, one constraint is the MS SQL database.
Having said that, we would like to port parts of a Zope application to
the new framework, but I do not expect this to be
particularly difficult for the parts we want to migrate since
they are not really using Zope features. Other parts instead
would require a very substantial rewrite so for the moment I think
they will stay in Zope.

Michele Simionato

Oct 7 '07 #17

P: n/a

IMO this is not as much a framework comparison rather than an
evaluation of the individual components that make up Pylons.

The framework is the sum of all its parts. Programmers should not need
to know that that a package named Beaker is used for sessions, Routes
for url mapping, PasteDeploy for whatever. This is the weakness of all
glue-type frameworks i.e. TG and Pylons. It makes them look like they
are duct-taped together.

The more important question are whether the sessions actually work
properly: i.e does session data persist through a server restart?
Where is the session data stored: in memory, files, database and so
on.

The choice of templating language should be a non issue. Any half
decent framework should allow you to use any other templating engine
with ease.
.... even python as you seem to prefer

i.


Oct 7 '07 #18

P: n/a
On Oct 7, 11:31 am, Istvan Albert <istvan.alb...@gmail.comwrote:
IMO this is not as much a framework comparison rather than an
evaluation of the individual components that make up Pylons.
More in general let's say that I am interested in the evaluation
of WSGI-compatible components.
The framework is the sum of all its parts. Programmers should not need
to know that that a package named Beaker is used for sessions, Routes
for url mapping, PasteDeploy for whatever. This is the weakness of all
glue-type frameworks i.e. TG and Pylons. It makes them look like they
are duct-taped together.
Here we disagree: I think that a programmer should know what he
is using. Moreover I think that composability is good since you
can understand the components one at the time and replace one
component with another according to your needs. OTOH, it is
true that duct-taped framework have some weak points, I am
the first to recognize that. But I also think the issues
will be less and less relevant as time goes by and the
culture of composable frameworks will become more widespread
in the community.
The more important question are whether the sessions actually work
properly: i.e does session data persist through a server restart?
Where is the session data stored: in memory, files, database and so
on.
Of course Beaker has all these features and I have no reasons
to believe they will not work.
The choice of templating language should be a non issue. Any half
decent framework should allow you to use any other templating engine
with ease.
... even python as you seem to prefer
Yes, the choice of templating language is a non-issue. Maybe
I should have removed my considerations on the subject in
my essay, just to avoid the bikeshed effect.

Michele Simionato

Oct 7 '07 #19

P: n/a
On Oct 7, 12:24 pm, Michele Simionato <michele.simion...@gmail.com>
wrote:
Here we disagree: I think that a programmer should know what he
is using.
My point was that they should not *need* to know. Too much information
can be detrimental.
Where is the session data stored: in memory, files, database and so
on.

Of course Beaker has all these features
Well their main page does not say anything about database based
storage:

http://beaker.groovie.org/

but then a Pylons wiki says it does, but I could not find any
information on out how to set up beaker with a database ... truth to
be told I was just curious of how they would go about integrating a
database and still keep it "pluggable".

Because it would either need to know about the way the server handles
the database connections (which makes it application specific) or it
has to create new database connections in which case it would be
duplicating the functionality leading to all kinds of headaches.

So there, even a simple requirement exposes the fallacy of building
anything complex out of "pluggable" components.

i.

Oct 7 '07 #20

P: n/a
On Oct 7, 6:14 pm, Istvan Albert <istvan.alb...@gmail.comwrote:
On Oct 7, 12:24 pm, Michele Simionato <michele.simion...@gmail.com>
wrote:
Here we disagree: I think that a programmer should know what he
is using.

My point was that they should not *need* to know. Too much information
can be detrimental.

Actually, in principle I *do* agree with you. For instance,
when I type 1+1, I have no idea of what exactly Python is
doing, but I don't need to know, because adding two integers
is a problem which is well understood and has been solved by
others years ago, I don't need to care about it. I wait with
impatience the time when Web programming will become a solved
problem with a standard built-in solution that works.
Unfortunately, that time is not near in the future and for the
moment I am forced to know how all the pieces work if I want to
build a reliable application. I don't like it, since I am not
particularly interested in the low levels and in the plumbings
myself, but this is the way it is.
... truth to
be told I was just curious of how they would go about integrating a
database and still keep it "pluggable".

Because it would either need to know about the way the server handles
the database connections (which makes it application specific) or it
has to create new database connections in which case it would be
duplicating the functionality leading to all kinds of headaches.

So there, even a simple requirement exposes the fallacy of building
anything complex out of "pluggable" components.
I suppose Beaker rely on SQLAlchemy since it comes from the
same mind, but I don't see the issue: a component may well
depend from another one, partially or totally, but this
does not detract at all from the usefulness of the component
approach. If I don't need persistent on a database, for instance,
I like to have the choice between a full-fledged component
and a poor man component that satisfies my basic requirements
and nothing more. I don't want to be forced to use a
monolithic-good-for-everybody solution.

Michele Simionato

Oct 8 '07 #21

P: n/a
Michele Simionato wrote:
I wait with
impatience the time when Web programming will become a solved
problem with a standard built-in solution that works.
That will probably come from Microsoft. At least for
all-Microsoft environments. They're the only player who
controls enough of the pieces.

John Nagle
Oct 8 '07 #22

P: n/a
Since you are starting a new project you may want to look into
something new and different

http://mdp.cti.depaul.edu/examples
Oct 10 '07 #23

P: n/a
On Oct 10, 5:57 am, mdipie...@cs.depaul.edu wrote:
Since you are starting a new project you may want to look into
something new and different

http://mdp.cti.depaul.edu/examples
Well, the name is certainly appealing to an old gauge field theorist
like myself ;)
Michele Simionato

Oct 10 '07 #24

P: n/a
Michele,
At work we are shopping for a Web framework, so I have been looking at
the available options on the current market.
just because you were involved in creating an own version of Python
does NOT free you from the social obligation to create your own Python
web framework. So stop shopping and start announcing your own pwf like
all other Python programmers do.

Harald

Oct 10 '07 #25

P: n/a
On Oct 9, 11:57 pm, mdipie...@cs.depaul.edu wrote:
Since you are starting a new project you may want to look into
something new and different

http://mdp.cti.depaul.edu/examples
This is actually a neat framework! I'm a somewhat of fan of web-
frameworks and I used most major ones and I like to poke around.

Here is a mini review:

Gluon seems to be modeled with the web.py mentality, everything in one
package, very simple but covering all essentials templating, database,
sessions and server. It reminds me of a content management system, you
start with a working server, then you add your components to it.

It also implements a Zope-like through-the-web interaction, everything
can be modified in the administration interface, templates, databases,
code, media. This sort of functionality is sometimes frowned upon but
can be a very convenient way to make small changes.

Honestly the framework field is a bit crowded so it is an uphill
battle to get a framework accepted, but it is nice to see something
different.

i.

ps. fix the typos in the docs and get people's names right, it makes a
bad impression otherwise

Oct 10 '07 #26

P: n/a
On Oct 10, 5:57 am, mdipie...@cs.depaul.edu wrote:
Since you are starting a new project you may want to look into
something new and different

http://mdp.cti.depaul.edu/examples
Requiring Python 2.5 may not be a good idea for the time being. For
instance, I am
forced to use Python 2.4 because of some C libraries I need, so I
cannot even consider
a framework based on Python 2.5 for the moment :-(

Michele Simionato

Oct 10 '07 #27

P: n/a
On Oct 10, 5:57 am, mdipie...@cs.depaul.edu wrote:
Since you are starting a new project you may want to look into
something new and different

http://mdp.cti.depaul.edu/examples
The delivered sourcecode is syntactically broken. Tabs and whitespaces
were mixed and when I open a file like gluon/global.py I find sections
like this:

class Request(Storage):
"""
defines the request object and the default values of its members
"""
def __init__(self):
self.env=Storage() # this line is incorrect syntax in Python
self.cookies=Storage()
self.get_vars=Storage()

Moreover there aren't any indications that the code was tested.

Kay
Oct 10 '07 #28

P: n/a
Kay Schluehr wrote:
>http://mdp.cti.depaul.edu/examples

The delivered sourcecode is syntactically broken. Tabs and whitespaces
were mixed and when I open a file like gluon/global.py I find sections
like this:

class Request(Storage):
"""
defines the request object and the default values of its members
"""
def __init__(self):
self.env=Storage() # this line is incorrect syntax in Python
You may have configured your editor to use a tabwidth of four spaces
(Python always uses 8).

Peter
Oct 10 '07 #29

P: n/a
On Oct 10, 8:15 pm, Peter Otten <__pete...@web.dewrote:
Kay Schluehr wrote:
>http://mdp.cti.depaul.edu/examples
The delivered sourcecode is syntactically broken. Tabs and whitespaces
were mixed and when I open a file like gluon/global.py I find sections
like this:
class Request(Storage):
"""
defines the request object and the default values of its members
"""
def __init__(self):
self.env=Storage() # this line is incorrect syntax in Python

You may have configured your editor to use a tabwidth of four spaces
(Python always uses 8).

Peter
You are right! I looked at the tokenizer.py module and the default
value for tabsize is 8. Now I feel stupid since I believe everyone
knew this for at least a decade and it is somewhere between page 1 and
10 of the Python tutorial I didn't look at for 5 years or so.

Now I get the following class definition:

class Request(Storage):
def __init__(self):
self.env=Storage()
self.cookies=Storage()
self.get_vars=Storage()
self.post_vars=Storage()
self.vars=Storage()
self.application=None
self.function=None
self.args=[]
pass

This is syntactically correct but the "pass" at the end makes me worry
about understanding even less about yet unknown language conventions
( setting pass as an endmarker of a block ) or the programmers
intentions or both. It's very scary in either way and I might need a
few days of recovering.

Kay

Oct 10 '07 #30

P: n/a
On Oct 6, 8:29 am, Michele Simionato <michele.simion...@gmail.com>
wrote:
Do you (or something else) have something to say about Beaker?
I looked at the source code and it seems fine to me, but I have
not used it directly, not stressed it. I need a
production-level WSGI session middleware and I wonder what the
players are (for instance how Beaker does compare with flup?)
Beaker is the only seriously maintained WSGI session at the moment --
flup isn't, AFAIK, very actively maintained or improved.
paste.session is a particularly naive implementation of sessions.

So as a result, Beaker is kind of the only game in town.
Incidentally, it's not really related to SQLAlchemy; it came out of
Myghty. Same author, of course, but fairly different domains.

Ian

Oct 14 '07 #31

P: n/a
On Oct 6, 8:13 am, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.comwrote:
Well... Last year, I had a look at Pylons, then played a bit with wsgi
and building my own framework over it. I finally dropped that code and
went back to Pylons, which I felt could become far better than my own
efforts. Now since then I had way too much to do at work (using other
technos) and didn't find the time to work on my own projects, so I still
don't know how well Pylons will pass the "real world" test, but it seems
to me that it's rapidly progressing and mostly in the right direction. I
still wait for an opportunity to check this out !-)
This would be my general suggestion too. It's fine to write your own,
and not that hard, but you'll be missing out on the momentum and help
from the community. You'll be maintaining your own code instead of
having other people work on maintenance -- which actually isn't that
much more work, except that you'll be doing it alone and without that
collective experience at hand.

That said, going without a framework (which at least in his article is
what Michele seems to be comparing Pylons against) isn't always so
bad. I started writing an Atompub server in Pylons, but felt like I
was spending too much time navigating around what the framework setup
and not enough time just paying attention to what Atompub really is.
So I ended up writing it (as FlatAtomPub), effectively without a
framework (though developing it at the same time as WebOb, so I leaned
on that quite a bit). The development went quite well, and for a web
service like Atompub that's probably what I'd recommend (at least to
experienced developers -- you might find yourself left to drift
otherwise without a clear idea of where to start).

But for writing a traditional web application, I'd still use Pylons.
The choices Pylons have made are with that in mind, and it doesn't at
all exclude other forms of development in the process. You could
actually drop a FlatAtomPub instance right into a Pylons app, for
instance. Pylons is a small enough framework that it really is quite
reasonable to pick and choose and use a very minimal style with it.

Ian

Oct 14 '07 #32

P: n/a
On Oct 14, 2:52 am, Ian Bicking <i...@colorstudy.comwrote:
That said, going without a framework (which at least in his article is
what Michele seems to be comparing Pylons against) isn't always so
bad. I started writing an Atompub server in Pylons, but felt like I
was spending too much time navigating around what the framework setup
and not enough time just paying attention to what Atompub really is.
So I ended up writing it (as FlatAtomPub), effectively without a
framework (though developing it at the same time as WebOb, so I leaned
on that quite a bit). The development went quite well, and for a web
service like Atompub that's probably what I'd recommend (at least to
experienced developers -- you might find yourself left to drift
otherwise without a clear idea of where to start).

But for writing a traditional web application, I'd still use Pylons.
The choices Pylons have made are with that in mind, and it doesn't at
all exclude other forms of development in the process. You could
actually drop a FlatAtomPub instance right into a Pylons app, for
instance. Pylons is a small enough framework that it really is quite
reasonable to pick and choose and use a very minimal style with it.
I think we do agree entirely, it is just that the application we have
in
mind is more a collection of web services than a traditional Web
application.
Now, since you are here, there is an unrelated question that I want to
ask you, concerning the future of Paste with respect to WSGI 2.0.
I do realize that at this stage WSGI 2.0, is only a draft, still I
would
like to know:

1. if you think that WSGI 2.0 is good idea (I expect you will say
"yes")
2. if you plan to support it in Paste and if yes when (I mean, in a
month,
in a year, in three years?)
3. if you already have thought of a migration plan and, in that case,
what your strategy would likely be.

Thanks for sharing,

Michele Simionato

Oct 14 '07 #33

P: n/a
On Oct 14, 6:46 pm, Michele Simionato <michele.simion...@gmail.com>
wrote:
Now, since you are here, there is an unrelated question that I want to
ask you, concerning the future of Paste with respect to WSGI 2.0.
I do realize that at this stage WSGI 2.0, is only a draft
Hmmm, not sure where people keep getting this idea that there exists a
WSGI 2.0 draft.

The only thing that exists that I know of is:

http://www.wsgi.org/wsgi/WSGI_2.0

This is at this point merely a collection of ideas for change, or
areas where the existing WSGI 1.0 is deficient. There are a various
things around this where decisions would need to be made or solutions
developed before one could even consider calling it a draft. I
certainly wouldn't necessarily go off making decisions based on what
may or may not be in WSGI 2.0. :-)

Graham

Oct 14 '07 #34

P: n/a
On Oct 14, 3:46 am, Michele Simionato <michele.simion...@gmail.com>
wrote:
I think we do agree entirely, it is just that the application we have
in
mind is more a collection of web services than a traditional Web
application.
Now, since you are here, there is an unrelated question that I want to
ask you, concerning the future of Paste with respect to WSGI 2.0.
I do realize that at this stage WSGI 2.0, is only a draft, still I
would
like to know:

1. if you think that WSGI 2.0 is good idea (I expect you will say
"yes")
Yeah. WebOb's functions have made me feel less of a need for that
change, and it normalizes some of the parts of WSGI that WSGI 2
removes. But I think it would generally help.
2. if you plan to support it in Paste and if yes when (I mean, in a
month,
in a year, in three years?)
3. if you already have thought of a migration plan and, in that case,
what your strategy would likely be.
This I'm really not sure about. A middleware could wrap any WSGI
application to make it support both WSGI 1 and 2. However, on the
server side it's unclear how to do the transition (including
middleware that calls WSGI applications).

If WSGI 2 included some marker that I could look for, then it would be
relatively easy too -- I'd always just call applications with a
library function that knew how to deal with both kinds of
applications. Without that... well, maybe I'll just have to be sure
that there's a clear upgrade path for the spec in general.

Of course, as Graham says, WSGI 2 is just talk at this point; there's
not a ton of momentum toward actually delivering a new spec.

Ian

Oct 15 '07 #35

P: n/a
Thomas,
Like many others I have been going round the same loop for months.

I have struggled with most of the Python solutions, including
TurboGears and have given up and gone back to ColdFusion. I am not
trying to kick of a religious war about the pros and cons of
ColdFusion as a scripting langauge, but IMHO, as a development
environment (Dreamweaver), it is unbeatable. In one product, "out of
the box" I can integrate database access and web design, including
AJAX, in one GUI IDE. Ok, the IDE is on Windows, but the servers run
on Linux.

This seems to be an aspect of web design that has been totally
ignored in the Python community. Developers have been falling over
each other to come up with yet another web development framework
( about 15 at the last count!), but they are all a collection of bits
and pieces from all over the place. Turbogears is attempting to pull
it all together, but that is like trying to hit a moving target. As
soon as you get something working they move to a different level of
one of the components and it all falls apart. For example, you might
try widgets and get them working with Kid Templates. Then you read
that they want you to move to Genshi Templates and after wasting
hours, you find the small print and discover you need different
widgets to work with Genshi. Some may think it is a strength of
Python to have so many options, but I think it is a weakness and
putting people off using Python for Web development, driving them to
products like PHP, Rails or ColdFusion. When I develop a web
application, I don't want to have to decide whether to use mod-python,
Cherrypy, Django, Pylons... for my server. Then I have to decide
whether to access my database with basic SQL or learn the quirky
options available with SQLObjects or SQLAlchemy, with or without,
Elixir. Finally, I have to decide which of umpteen templating systems
to use and hope that it will work with the rest of the components.

Am I asking too much to have a Python product "X" which is a fully
self-contained web development framework?
John B

On 6 Oct, 11:44, Thomas Wittek <m...@gedankenkonstrukt.dewrote:
Michele Simionato:
At work we are shopping for a Web framework, so I have been looking at
the available options
on the current market.

At least, you missed Turbo Gears :)http://turbogears.org/
For me, it feels more integrated than Pylons.

--
Thomas Wittek
Web:http://gedankenkonstrukt.de/
Jabber: streawkc...@jabber.i-pobox.net
GPG: 0xF534E231

Oct 27 '07 #36

P: n/a
johnbraduk a écrit :
Thomas,
Like many others I have been going round the same loop for months.

I have struggled with most of the Python solutions, including
TurboGears and have given up and gone back to ColdFusion. I am not
trying to kick of a religious war about the pros and cons of
ColdFusion as a scripting langauge, but IMHO, as a development
environment (Dreamweaver), it is unbeatable.
Won't talk about opinion here. Enough to say that Dreamweaver is IMHO a
bloated piece of crap.
In one product, "out of
the box" I can integrate database access and web design,
Which are totally orthogonal aspects, and as such are better kept
seperate. In my current shop - as well as in the previous one,
programmers deal with database access, designers deal with design, and
integrators deal with html and templates.
including
AJAX, in one GUI IDE.
I don't want a "GUI IDE", I want my code editor. Using which I can edit
(x)html, css, any template language, javascript, python, php, sql,
whatever...
Ok, the IDE is on Windows, but the servers run
on Linux.
No way I'm going to inflict myself the pain of using Windows. Sorry.
This seems to be an aspect of web design that has been totally
ignored in the Python community.
(snip rant about having too much choice)
Am I asking too much to have a Python product "X" which is a fully
self-contained web development framework?
Have you tried Django ? One of the main criticism against it is that
it's a bit too much "self-contained" !-)

But anyway, since all these are free softwares - freely written and
contributed by mostly benelovent contributors -, yes, you *are* "asking"
too much.

Oct 29 '07 #37

P: n/a
Gluon was made at my school? I seriously gotta start talking to the
CTI department.
Dec 15 '07 #38

This discussion thread is closed

Replies have been disabled for this discussion.