Frameworks

[flebber]

Hi

I have been searching through the vast array of python frameworks
http://wiki.python.org/moin/WebFrameworks and its quite astounding the
choice available.

I am looking at using a web framework for my personal project which
isn't actually aimed at developing a website as such. However I deduce
that rather than creating a gui application and screen input for data,
I can use a web browser for this and have a great array of tools to
format input screens and output display formats.

Since I will be retreiving information from several websites (usually
csv files) formatting them and submitting them to a database and
creating queries and printouts based on them most frameworks seem to
handle this basically with ease and for any complex queries most
support SqlAlchemy.

Is it simply a case of just picking one and starting and I would find
it hard to be dissapointed or is there a few special considerations to
make, though I am unsure what they are?

Most obvious ones I am considering are Django (Of course), Pylons
includes SqlAlchemy, Sql Object and templating and I here turbogears
plans to sit on top of this platform. Zope I am considering but I am a
little confused by this. The are heaps of others but not sure how to
narrow the selection criteria.

How/Why woul you split Django and Pylons let alone the others?

Database likely to be MySQl

 

[flebber]

Hi

I have been searching through the vast array of python frameworkshttp://wiki.python.org/moin/WebFrameworksand its quite astounding the
choice available.

I am looking at using a web framework for my personal project which
isn't actually aimed at developing a website as such. However I deduce
that rather than creating a gui application and screen input for data,
I can use a web browser for this and have a great array of tools to
format input screens and output display formats.

Since I will be retreiving information from several websites (usually
csv files) formatting them and submitting them to a database and
creating queries and printouts based on them most frameworks seem to
handle this basically with ease and for any complex queries most
support SqlAlchemy.

Is it simply a case of just picking one and starting and I would find
it hard to be dissapointed or is there a few special considerations to
make, though I am unsure what they are?

Most obvious ones I am considering are Django (Of course), Pylons
includes SqlAlchemy, Sql Object and templating and I here turbogears
plans to sit on top of this platform. Zope I am considering but I am a
little confused by this. The are heaps of others but not sure how to
narrow the selection criteria.

How/Why woul you split Django and Pylons let alone the others?

Database likely to be MySQl

I guess what makes it so interesting is that there appear to be so man
high quality options. Its astounding.

 

[Bruno Desthuilliers]

flebber a écrit :

Hi

I have been searching through the vast array of python frameworks
http://wiki.python.org/moin/WebFrameworks and its quite astounding the
choice available.

I am looking at using a web framework for my personal project which
isn't actually aimed at developing a website as such. However I deduce
that rather than creating a gui application and screen input for data,
I can use a web browser for this and have a great array of tools to
format input screens and output display formats.

Yeps - but remember that a web app will have a couple limitations /
drawbacks, specially wrt/ handling complex UI.

Since I will be retreiving information from several websites (usually
csv files) formatting them and submitting them to a database and
creating queries and printouts based on them most frameworks seem to
handle this basically with ease and for any complex queries most
support SqlAlchemy.

Is it simply a case of just picking one and starting and I would find
it hard to be dissapointed or is there a few special considerations to
make, though I am unsure what they are?

Given your "specs", forget about monstruosities like Zope, Twisted etc,
that will mostly get in the way. You have simple needs, use a simple
tool !-)

Most obvious ones I am considering are Django (Of course),

A pretty good framework, but you'll loose some of it's nice features if
you ever want to use an alternate DB layer or templating system. OTHO,
most other more "flexible" frameworks just don't offer this level of
integration, so it's may not be such a big deal.

Note that Django's ORM, while already pretty good and constently
improving, is not as powerful as SLQAlchemy (now nothing prevents you
from going down to raw SQL for the more complex queries - and this might
be better anyway, since complex queries usually requires to be very fine
tuned and tend to not be really portable). The Forms API OTHO is a real
winner IMHO.

Pylons
includes SqlAlchemy, Sql Object and templating and I here turbogears
plans to sit on top of this platform.

I admit I fail to see what TG brings except for more indirection levels.

Zope I am considering but I am a
little confused by this.

Friendly advice (based on years of working experience): don't waste your
time with Zope.

The are heaps of others but not sure how to
narrow the selection criteria.

How/Why woul you split Django and Pylons let alone the others?

Django : very strong integration, excellent documentation and support,
huge community, really easy to get started with. And possibly a bit more
mature and stable...

Pylons : more loosely coupled (imply: less integration), based on
"standard" components - which is both a blessing and a curse, specially
wrt/ documentation -, requires a good knowledge of Python and the HTTP
protocol to get started with. Very powerful and flexible but this comes
with a price...

Now both are written by talented programmers, and both are pretty good
tools. I guess it's more a matter of personal preferences and/or
external constraints (PHB etc...) than anything else.

A couple other "lightweight" candidates you migh want to consider are
werkzeug and web.py:

http://werkzeug.pocoo.org/
http://webpy.org/

Database likely to be MySQl

Mmmm.... If your application is "write-heavy", PostgreSQL might be a
better choice. Anyway, both Django's ORM and SQLAlchemy work fine with
MySQL AFAICT.

 

[Javier Santana]

juno
http://github.com/breily/juno

it's very easy, uses sqlalchemy as ORM and jinja2 (others can be used
if you want) for templates.

 

[flebber]

junohttp://github.com/breily/juno

it's very easy, uses sqlalchemy as ORM and jinja2 (others can be used
if you want) for templates.

After further reading Django does indeed cover a lot of bases. When
looking at jinja2 and werkzueg, first thing I noticed is that they are
by the same group called pocoo. Second it shows that I must be
misunderstanding something, can I really use jinja2 and sqlAlchemy by
itself? The werkzeug documentation shows a screencast http://werkzeug.pocoo..org/wiki30/
of making a wiki and uses werkzueg, jinja2 and sqlAlchemy, why
werkzueg and jinja2 in combination?

And pylons advises use of SqlAlchemy and Mako or choices of Genshi and
Jinja2, so what is pylons adding? Might have to do a bit more reading
and watch a few more screencasts

 

[flebber]

After further reading Django does indeed cover a lot of bases. When
looking at jinja2 and werkzueg, first thing I noticed is that they are
by the same group called pocoo. Second it shows that I must be
misunderstanding something, can I really use jinja2 and sqlAlchemy by
itself? The werkzeug documentation shows a screencasthttp://werkzeug.pocoo.org/wiki30/
of making a wiki and uses werkzueg, jinja2 and sqlAlchemy, why
werkzueg and jinja2 in combination?

And pylons advises use of SqlAlchemy and Mako or choices of Genshi and
Jinja2, so what is pylons adding? Might have to do a bit more reading
and watch a few more screencasts

web2py is interesting the author appears to be implying(I could be
misunderstanding this) that the web2py db ORM is equal to if not
superior to SQLAlchemy - From http://www.web2py.com/AlterEgo/default/show/150

 

[Diez B. Roggisch]

web2py is interesting the author appears to be implying(I could be
misunderstanding this) that the web2py db ORM is equal to if not
superior to SQLAlchemy - From
http://www.web2py.com/AlterEgo/default/show/150

I don't read that out of the post, and it almost certainly is wrong, at
least on a general level. There isn't much above SQLAlchemy regarding
flexibility & power, so while simple cases might be simpler with other
ORMs, they often make more complicated ones impossible.

But again, I don't think that's the claim there.

Diez

 

[Marco Mariani]

I don't read that out of the post, and it almost certainly is wrong, at
least on a general level. There isn't much above SQLAlchemy regarding
flexibility & power, so while simple cases might be simpler with other
ORMs, they often make more complicated ones impossible.

But again, I don't think that's the claim there.

Both ORMs and others have been described, by their authors, during the
PyCon in March 2009:

http://us.pycon.org/2009/conference/schedule/event/60/


By the way, this line

in web2py you can access legacy databases if tables have an existing unique auto-increment field id and if this field is used for references

is a bit like saying "any color you like as long as it's black" and it's
not a light limitation. There wouldn't be much of an impedence mismatch
(*) if a numeric auto-increment primary key was enough for everybody.

Sure SQLAlchemy is more complex to master :-/



(*)
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

 

[flebber]

I don't read that out of the post, and it almost certainly is wrong, at
least on a general level. There isn't much above SQLAlchemy regarding
flexibility & power, so while simple cases might be simpler with other
ORMs, they often make more complicated ones impossible.

But again, I don't think that's the claim there.

Diez

That sounds fair.

Bruno posted earlier

huge community, really easy to get started with. And possibly a bit more
mature and stable...

Pylons : more loosely coupled (imply: less integration), based on
"standard" components - which is both a blessing and a curse, specially
wrt/ documentation -, requires a good knowledge of Python and the HTTP
protocol to get started with. Very powerful and flexible but this comes
with a price...

Now both are written by talented programmers, and both are pretty good
tools. I guess it's more a matter of personal preferences and/or
external constraints (PHB etc...) than anything else.

A couple other "lightweight" candidates you migh want to consider are
werkzeug and web.py:

http://werkzeug.pocoo.org/
http://webpy.org/

In short it seems to me that Django and Web2py include more "magic" in
assisting oneself to create you web/application, whilst Pylons and
Werkzueg leave more control in the users hands hopefully leading to
greater expression and power.

Pylons recommends SQLALchemy and Mako (offers Genshi and Jinja2) and
Werkzueg SQLAlchemy and Jinja2. As I don't have the experience to tell
the pro's cons of these two apart, would choosing Pylons based on
Documentation be a fair call?

 

[Emmanuel Surleau]

Django : very strong integration, excellent documentation and support,

huge community, really easy to get started with. And possibly a bit more
mature and stable...

One strong point in favour of Django: it follows Python's philosophy of
"batteries included", and features a large array of plugins. There are also
numerous other add-ons created by the community.

Also, it has a pretty great administration interface.

It still manages to retain flexibility, but you're basically stuck with
Django's ORM (which is OK for simple things) and templating language (which is
OK as long as you don't need custom tags).

Pylons : more loosely coupled (imply: less integration), based on
"standard" components - which is both a blessing and a curse, specially
wrt/ documentation -, requires a good knowledge of Python and the HTTP
protocol to get started with. Very powerful and flexible but this comes
with a price...

Haven't used Pylons, but the documentation has improved the last few years
with the Pylons book (http://pylonsbook.com/en/1.0/), while still not being up
to par with Django's. It has also a methodology for deployment, which Django
decidedly lacks.

Cheers,

Emm

 

[Bruno Desthuilliers]

Emmanuel Surleau a écrit :

One strong point in favour of Django: it follows Python's philosophy of
"batteries included", and features a large array of plugins. There are also
numerous other add-ons created by the community.

Also, it has a pretty great administration interface.

It still manages to retain flexibility, but you're basically stuck with
Django's ORM

You're by no way "stuck" with Django's ORM - you are perfectly free not
to use it. But then you'll obviously loose quite a lot of useful
features and 3rd part apps...

(which is OK for simple things) and templating language (which is
OK as long as you don't need custom tags).

Custom tags are nothing complicated.

 

[Bruno Desthuilliers]

flebber a écrit :
(snip)

In short it seems to me that Django and Web2py include more "magic" in
assisting oneself to create you web/application, whilst Pylons and
Werkzueg leave more control in the users hands hopefully leading to
greater expression and power.

I can't tell much about web2py - never used it. wrt/ Django, there's not
that much "magic" involved - Django's ORM is not "more magic" than
SQLAlchemy, Django templates are by no mean "more magic" than Mako or
Genshi (and probably way simpler to understand than Mako). And FWIW,
Jinja started as a standalone rewrite of Django templates.

The main difference between Django and Pylons is that Django is highly
'integrated' - all parts were designed by the same team, and were
designed to work together - while Pylons is very loose - it's mainly an
"assembly" of 3rd part components, most of them swappable, with some
glue code to make the whole thing work. Very different philosophies.

Having serious working knowledge of Django, I don't buy the "Pylons
gives you more control" stuff - you have as much "control" with Django,
the only point is that you'll obviously loose some hi-level features
when using "non-standard" components. Pylons just don't have these
features OOTB.

Pylons recommends SQLALchemy and Mako (offers Genshi and Jinja2) and
Werkzueg SQLAlchemy and Jinja2. As I don't have the experience to tell
the pro's cons of these two apart, would choosing Pylons based on
Documentation be a fair call?

If you know right from the start you won't need Django's hi-level
features, and/or that the level of integration it offers will be more of
a nuisance than help for your project, then go for
Pylons/SQLAlchemy/Mako. It's probably one of the most powerful combo -
while not the easiest to get started with.

 

[mdipierro]

In short it seems to me that Django and Web2py include more "magic" in
assisting oneself to create you web/application, whilst Pylons and
Werkzueg leave more control in the users hands hopefully leading to
greater expression and power.

it depends on how one defines "magic". web2py provides a DAL, not an
ORM. DAL expressions translate one-to-one into SQL statements in the
appropriate dialect (or GQL on GAE), no more, without additional
superstructure. The basic API are

db.tablename.insert(filename=value)
db(query).select(...)
db(query).update(...)
db(query).delete()
db(query).count()

an example of query is

query=(db.tablename.fieldname=='value')|(db.tablename.fieldname.like
('A%'))

which translates into

WEHERE tablename.fieldname = 'value' OR tablename.fieldname LIKE 'A
%'

with the appropriate escaping for security or course.


Of course you can more complex expressions for nested selects, joins,
left joins, aggregates, etc. but the general principle stands. Here is
an example:


db().select(db.table1.field1,db.table1.field2.sum
(),groupby=db.table1.field1)

and another (which does a nested select, a join and a left join):

db((db.table1.field1.belongs(db(db.table2.field2.id>0)._select
(db.table2.field3)))&
(db.table1.field4==db.table3.field5)).select
(
db.table1.ALL,db.table2.field6,
left=db.table4.on
(db.table4.field6==db.table1.field7),
orderby=db.table1.field8)

 

[mdipierro]

One more clarification to avoid confusion. Django has "admin" and it
is great. Web2py also has something called "admin" but that is not
apples to apples.

The closest thing to Django "admin" in web2py is called "appadmin" (it
comes with it).

For example consider the following complete program:

db=DAL('sqlite://test.sqlite)
db.define_table('person',Field('name'))

appadmin is a controller that comes with each web2py app and provides
a web based interface to the database, that can be customized at the
app level, and that inherits the layout of the app.

The Django "admin" can be customized more and it is designed for
users. It is very sleek. The web2py "appadmin" is designed for the
administrator not users, and allows you to insert DAL queries
directly.

web2py also has something called "admin" which has nothing to do with
Django "admin". It is instead a web based IDE including web based
tools for installing apps remotely, packaging apps, editing apps,
debugging, running doctests, etc. via the web interface.

Massimo

 

[Emmanuel Surleau]

Emmanuel Surleau a écrit :

You're by no way "stuck" with Django's ORM - you are perfectly free not
to use it. But then you'll obviously loose quite a lot of useful
features and 3rd part apps...

You lose most of what makes it worth using Django, so you're in effect kind of
stuck with it. If you don't need/want the ORM, you might as well use something
else.

Custom tags are nothing complicated.

Compared to custom tags in, say, Mako? Having to implement a mini-parser for
each single tag when you can write a stupid Python function is needless
complication.

Cheers,

Emm

 

[Massimo Di Pierro]

Compared to custom tags in, say, Mako? Having to implement a mini-
parser for
each single tag when you can write a stupid Python function is
needless
complication.

I like Mako a lot and in fact web2py template took some inspiration
from it. Here is a mako example:

% for a in ['one', 'two', 'three', 'four', 'five']:
% if a[0] == 't':
its two or three
% elif a[0] == 'f':
four/five
% else:
${a}
%endif
% endfor


Here is the same in web2py-ese, translated line by line

{{for a in ['one', 'two', 'three', 'four', 'five']:}}
{{if a[0] == 't':}}
its two or three
{{elif a[0] == 'f':}}
four/five
{{else:}}
{{=a}}
{{pass}}
{{pass}}

Legend Mako -> web2py
% -> {{ .... }}
endif -> pass
endfor -> pass
${...} -> {{=...}}

Mako introduces terms like "endif", "endfor" which are not Python
keywords. Web2py only uses valid python keywords.

Here is another example, in Mako:

<%def name="myfunc(x)">
this is myfunc, x is ${x}
</%def>
${myfunc(7)}

and the same in web2py

{{def myfunc(x):}}
this is myfunc, x is {{=x}}
{{return}}
{{myfunc(7)}}

Again web2py does not introduce any new syntax. only valid Python in
{{...}} tags.
(Notice {{myfunc(7)}} not {{=myfunc(7)}} becase the function is
printing, we are not printing the return value of the function).

Mako needs to parse % ..., <%>...</%>, ... and ${...}. web2py needs to
parse only {{...}}.

The use of {{...}} in web2py is inspired by Django. This has a big
advantage over <%...%>, it is transparent to html editors and so you
use any html editor with the templates.

Massimo

 

[Emmanuel Surleau]

Compared to custom tags in, say, Mako? Having to implement a mini-
parser for
each single tag when you can write a stupid Python function is
needless
complication.

I like Mako a lot and in fact web2py template took some inspiration
from it. Here is a mako example:

% for a in ['one', 'two', 'three', 'four', 'five']:
% if a[0] == 't':
its two or three
% elif a[0] == 'f':
four/five
% else:
${a}
%endif
% endfor


Here is the same in web2py-ese, translated line by line

{{for a in ['one', 'two', 'three', 'four', 'five']:}}
{{if a[0] == 't':}}
its two or three
{{elif a[0] == 'f':}}
four/five
{{else:}}
{{=a}}
{{pass}}
{{pass}}

Legend Mako -> web2py
% -> {{ .... }}
endif -> pass
endfor -> pass
${...} -> {{=...}}

Mako introduces terms like "endif", "endfor" which are not Python
keywords. Web2py only uses valid python keywords.

Ingenious. Web2py looks more consistent (everything relies on {{ }} while Mako
uses %, $ and <% >). On the other hand, the Mako syntax is a bit lighter to my
eyes. Tradeoffs, tradeoffs...

Here is another example, in Mako:

<%def name="myfunc(x)">
this is myfunc, x is ${x}
</%def>
${myfunc(7)}

and the same in web2py

{{def myfunc(x):}}
this is myfunc, x is {{=x}}
{{return}}
{{myfunc(7)}}

Again web2py does not introduce any new syntax. only valid Python in
{{...}} tags.
(Notice {{myfunc(7)}} not {{=myfunc(7)}} becase the function is
printing, we are not printing the return value of the function).

Mako needs to parse % ..., <%>...</%>, ... and ${...}. web2py needs to
parse only {{...}}.

The use of {{...}} in web2py is inspired by Django. This has a big
advantage over <%...%>, it is transparent to html editors and so you
use any html editor with the templates.

Bah, as if anyone needed anything else than vim Just joking, I see the
advantage if you are working with external designers.

Cheers,

Emm

 

[Bruno Desthuilliers]

Emmanuel Surleau a écrit :

You lose most of what makes it worth using Django,

Mmmm... I beg to disagree. You still have the core framework (request /
response handling, sessions etc), the templating system, the form API
etc. As far as I'm concerned, it's quite enough to "make it worth".

Compared to custom tags in, say, Mako?

I lack _working_ experience with Mako (only played with it), but I found
it to sometimes have a "bend backbward" feel. One nice thing with
Django's templates is the very straightforward approach. Might not be as
smart and elegant - and certainly not as powerful, I won't even discuss
this point -, but hey, it JustWork(tm), and my fellow html coders can
use it without difficulty.

Don't misunderstand me - as a computer programmer, I of course find Mako
to be way above Django's template. But this doesn't make the latter bad,
and from the average html coder POV Django is easier to grasp. But well,
this has been debatted to hell and back, so let's not waste time with this.

Having to implement a mini-parser for
each single tag

Most of the "mini-parser" stuff is so very easily factored out I'm
afraid I won't buy your argument.

 

[Emmanuel Surleau]

Emmanuel Surleau a écrit :

Mmmm... I beg to disagree. You still have the core framework (request /
response handling, sessions etc), the templating system, the form API
etc. As far as I'm concerned, it's quite enough to "make it worth".

The form API is pretty good, but I don't think the rest makes it stand out
that much, compared to other frameworks. To me, the notion of reusable apps
and the application ecosystem it allows is Django's most compelling feature.
You are, of course, welcome to disagree.

Most of the "mini-parser" stuff is so very easily factored out I'm
afraid I won't buy your argument.

You'll at least agree that in terms of line of codes necessary to implement a
custom tag, it's very far from optimal, I hope?

Cheers,

Emm

 

[Bruno Desthuilliers]

Emmanuel Surleau a écrit :

The form API is pretty good, but I don't think the rest makes it stand out
that much, compared to other frameworks.

I don't care if it "stand out that much" - it works fine and is well
documented. Given that for most web apps, Django's ORM is a good enough
tool, I don't see the point in using 3 or more "different" frameworks
that basically do the same things in slightly different ways, each with
it's own strong and weak points.

To me, the notion of reusable apps
and the application ecosystem it allows is Django's most compelling feature.
+1.

You are, of course, welcome to disagree.

I'm not saying that Django is "better" than Pylons or web.py or (insert
yur favorite framework here) - and to be true, I think Pylons is
globally smarter than Django -, I'm saying that it do the job, and do it
well enough to be worth using. Sorry for being so pragmatic.

You'll at least agree that in terms of line of codes necessary to implement a
custom tag, it's very far from optimal, I hope?

I also agree that in terms of LOCs necessary to implement a log file
parser, Python is also very far from optimal, at least compared to Perl !-)

How many Django custom tags did you write, exactly ? And of which level
of complexity ? Once again, I'm not pretending Django is the best thing
ever, but most of your remarks remind me of what I once could have say -
that is, before having enough experience writing and maintaining Django
apps. One of the greatest features of Django - and possibly what finally
makes it so pythonic - is that it doesn't try to be *too* smart - just
smart enough.

My 2 cents.