Django or Pylons - comparison details

[zunzun]

Comparison before starting a project, used to decide which framework
to use.


Django: according to http://groups.google.com/group/django-users/about

Members 12,016
Group Activity is High


Pylons: according to http://groups.google.com/group/pylons-discuss/about

Members: 1,748
Group Activity is Low


Also, Django just made a major release. The last (non-security fix)
Pylons release is over a year old. Guido van Rossum has blessed
Django here: http://www.djangoproject.com/weblog/2006/aug/07/guidointerview/

Seems like I should use Django? Or should it be Pylons instead? Is a
long-planned major release immediately forthcoming?

James

[Ben Bangert]

On Dec 6, 2008, at 9:31 AM, zunzun wrote:

> Comparison before starting a project, used to decide which framework
> to use.
> Django: according to http://groups.google.com/group/django-users/about
> Members 12,016
> Group Activity is High
> Pylons: according to http://groups.google.com/group/pylons-discuss/about
> Members: 1,748
> Group Activity is Low

Really? That's how you decide? Then I believe you *must* choose PHP.
It completely dwarfs Django and Python altogether, its the only choice
really if you want to determine framework based on user-base
(popularity). :)

> Also, Django just made a major release. The last (non-security fix)
> Pylons release is over a year old. Guido van Rossum has blessed
> Django here: http://www.djangoproject.com/weblog/2006/aug/07/guidointerview/

Before that release, they hadn't made a release in almost 2 years, and
actually told everyone to run production websites on the development
branch... Pylons 0.9.7 RC4 came out about 2 weeks ago. Guido is not a
veteran web developer, nor does he actually use any of Django beyond
Django templates, his apps have been generally built with pure WSGI
and Django templates, the recent port of his Mondrian to a Django app
was prolly his first actual Django project.

> Seems like I should use Django? Or should it be Pylons instead? Is a
> long-planned major release immediately forthcoming?

What kind of app/site are you building? What tools matter to you? Do
you think you'll need to scale heavily? Are you talking to a legacy
database? etc.

Those questions are the ones you should be asking yourself, then
seeing which framework has the tools you need to accomplish your task.
Otherwise, merely posting some mail list numbers and that Guido likes
Django seems to be awfully trollish as it doesn't seem to be a serious
attempt to evaluate the frameworks benefits for the task you're
actually trying to complete.

I'd highly suggest searching the mail list for some previous threads
on the subject, as this doesn't really need rehashing again.
http://markmail.org/search/?q=list%3Apylons+django+pylons

Cheers,
Ben

[Jorge Vargas]

Totally agreed with Ben, you may also want to learn a similar post
just a couple of days old on the TG list with another set of bad
comparison and misinterpretations
http://groups.google.com/group/turbogears/browse_thread/thread/a63ad43936c8f821

[Noah Gift]

I wouldn't necessarily agree that it doesn't need rehashing, at least from a marketing and documentation perspective.  I just talked with some co-workers last week, that are very experienced Python programmers and they asked me why they hadn't heard about Pylon's much.  One person mentioned he looked at it about a year and half ago, and decided to go with Django.  Now he ran into a problem that only SQLAlchemy can solve, and after he went through the new pylons book online he was quite impressed.

In my opinion Pylons and Django solve two different problems, although there is some overlap, but even still many people don't know this.  For example, if you have several legacy databases that you need to talk from the same web application, while you are dealing with parallel processing farms, then Django is going to cause you much, much pain...i.e. the typical film animation workflow.  If you want to write a CMS from scratch, Django is damn nice.

To be fair I do agree too that Pylons has had some documentation, installation, marketing issues, which I have whined about as well :)  It sounds like a lot of this is resolved with the book, new installation procedures, and people writing articles and blog posts about Pylons.  I think looking at the Ruby framework Merb is a good comparison to see how successful, and viable multiple framework approaches are in a language.  Not every problem for Ruby is solved by Ruby on Rails.  Many people are unhappy with parts of it, and Merb seems to address this.  

Cheers,
Ben

[Mike Orr]

On Sat, Dec 6, 2008 at 10:39 AM, Ben Bangert <b...@groovie.org> wrote:
> On Dec 6, 2008, at 9:31 AM, zunzun wrote:
>
>> Comparison before starting a project, used to decide which framework
>> to use.
>> Django: according to http://groups.google.com/group/django-users/about
>> Members 12,016
>> Group Activity is High
>> Pylons: according to http://groups.google.com/group/pylons-discuss/about
>> Members: 1,748
>> Group Activity is Low
>
> Really? That's how you decide? Then I believe you *must* choose PHP. It
> completely dwarfs Django and Python altogether, its the only choice really
> if you want to determine framework based on user-base (popularity). :)

Excellent answer.

Pylons 0.9.7 is almost released, the main issue being finishing the
documentation. In the meantime, the Pylons Book is pretty complete
and covers the RC version. It's an axiom of open-source programming
that the last 10% of a release takes N months longer than anticipated.
N = 5 and counting for Pylons, and it has been > 12 for both Django
and Cheetah in the past.

Django's popularity is mainly due to superior marketing and
documentation. They have a corporate backer and thus more people with
those skills. Pylons' developers are mainly hackers/web programmers,
who would rather build software than do marketing. So many people
have not heard about Pylons or its voice gets drowned out. But Pylons
has particular favor among those who like extremely modular tools, and
those people have been coming to us.

An interesting question is, why did [any framework's] users choose it?
Django:
- technical capability: same as Pylons/TurboGears. Not a reason to
choose one over another.
- design philosophy: build our own tools so it's well integrated.
Some number of people like this.
- completeness of toolset: if you need CMS tools, there may be some
that are only available in Django and Plone currently.
- tutorials: "I read Django's docs and they were easy to
understand". A lot of people cite this.
- marketing: "It seems everybody's using Django." or "I didn't know
there were any other viable Python frameworks.": A lot of people say
this.

Pylons:
- technical capability: the same.
- design philosophy: use 3rd-party tools when feasable, WSGI to the
core: many Pylons' enthusiasts come from this mindset.
- completeness of toolset: the basic stuff is all there and then some.
- tutorials: it takes a bit of work to find the relevant
documentation. For 0.9.7, the Pylons Book is your best bet right now.
For 0.9.6, the official docs are good.
- marketing: there will be a stronger marketing push after 0.9.7 is
released and the new website is finished.

>> Guido van Rossum has blessed
>> Django here:
>> http://www.djangoproject.com/weblog/2006/aug/07/guidointerview/

That was written two years ago. At the time Guido also hoped Django
and Pylons would merge. I don't think he understood the situation
very well at that point, because Django and Pylons can't merge without
one of them giving up its fundamental philosophy. And the ascent of
WSGI makes a merger less necessary: what's needed is interoperability.
Django has had a weakness on that point, but it's gradually getting
better as it moves closer to WSGI. In any case, Guido now understands
that multiple frameworks are here to stay (like multiple GUI
libraries), and each has its unique strengths.

--
Mike Orr <slugg...@gmail.com>

[Krishgy]

If your questions needs to be answered quickly, Django may be right
choice. I think, you could have known why not to use PHP when you ask
question on Django vs Pylons :-) .

I NEVER worked on Python at jobs. I wanted to create a website. I have
chosen Pylons over Django due to its customization feature & luxuries.
I have gathered small small frustration while working due to lack of
documentation & community support. I am very thankful for people who
helped me in some cases. I spend more time on Pylons. Now I don't have
time & interest to learn another framework. I have to go with Pylons.

All I would ask seniors/library developers of pylons to respond to the
questions asked by newbies like me. Let the newcomers to feel good
about using Pylons by heart. I REALLY don't understand what do you
people mean by marketing Pylons. I tried to use authkit in my project,
which is evil in my project life. I asked many questions here but got
no reply. I do not expect such a thing from a matured community.

Things are changing but very slowly.

Sorry about my English.

On Dec 7, 5:30 am, "Mike Orr" <sluggos...@gmail.com> wrote:
> On Sat, Dec 6, 2008 at 10:39 AM, Ben Bangert <b...@groovie.org> wrote:
> > On Dec 6, 2008, at 9:31 AM, zunzun wrote:
>
> >> Comparison before starting a project, used to decide which framework
> >> to use.

> >> Django: according tohttp://groups.google.com/group/django-users/about

> >> Members 12,016
> >> Group Activity is High

> >> Pylons: according tohttp://groups.google.com/group/pylons-discuss/about

> Mike Orr <sluggos...@gmail.com>

[Alex Marandon]

2008/12/6 zunzun <zunzu...@gmail.com>:

> Seems like I should use Django? Or should it be Pylons instead?

Here is the advice of an average programmer with no emotional
involvement in any of these projects.

I think it depends on your background. The Pylons ecosystem is very
powerful but it's quite complex and not really suitable for beginners.
If it's going to be the first web framework you use, you should
probably stick with Django or even better Rails. If you're a seasoned
web developer used to get acquainted quickly with new APIs and want a
maximum of flexibility, then Pylons is for you. Don't let the size of
the community fool you, when it comes to technical advice quality
matters more than quantity.

[Wichert Akkerman]

Previously Alex Marandon wrote:
>
> 2008/12/6 zunzun <zunzu...@gmail.com>:
> > Seems like I should use Django? Or should it be Pylons instead?
>
> Here is the advice of an average programmer with no emotional
> involvement in any of these projects.
>
> I think it depends on your background. The Pylons ecosystem is very
> powerful but it's quite complex and not really suitable for beginners.
> If it's going to be the first web framework you use, you should
> probably stick with Django or even better Rails.

grok might also be a good choice. I'm not quite sure of repoze.bfg is
quite there yet, but it is shaping up to be another excellent candidate
as well.

Wichert.

--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.

[Jorge Vargas]

On Mon, Dec 8, 2008 at 3:54 AM, Krishgy <kri...@gmail.com> wrote:
>
> If your questions needs to be answered quickly, Django may be right
> choice. I think, you could have known why not to use PHP when you ask
> question on Django vs Pylons :-) .
>
> I NEVER worked on Python at jobs. I wanted to create a website. I have
> chosen Pylons over Django due to its customization feature & luxuries.
> I have gathered small small frustration while working due to lack of
> documentation & community support. I am very thankful for people who
> helped me in some cases. I spend more time on Pylons. Now I don't have
> time & interest to learn another framework. I have to go with Pylons.
>
> All I would ask seniors/library developers of pylons to respond to the
> questions asked by newbies like me. Let the newcomers to feel good
> about using Pylons by heart. I REALLY don't understand what do you
> people mean by marketing Pylons. I tried to use authkit in my project,
> which is evil in my project life. I asked many questions here but got
> no reply. I do not expect such a thing from a matured community.
>

that is because
a) the author or authkit is never around
b) authkit is way over complicated
c) autukit sucks in other ways
d) all of the above.

that said, I do think that a default auth should be added to pylons,
as it's a "pretty common feeture" but that's another discussion. if
you hate your tool then change it. Now don't come back complaining
that django wants you to do things in X,Y and Z way, and even if
that's bad/dumb/not-the-best you will expend way way more time trying
to get around it.

[Ian Bicking]

Wichert Akkerman wrote:
> Previously Alex Marandon wrote:
>> 2008/12/6 zunzun <zunzu...@gmail.com>:
>>> Seems like I should use Django? Or should it be Pylons instead?
>> Here is the advice of an average programmer with no emotional
>> involvement in any of these projects.
>>
>> I think it depends on your background. The Pylons ecosystem is very
>> powerful but it's quite complex and not really suitable for beginners.
>> If it's going to be the first web framework you use, you should
>> probably stick with Django or even better Rails.
>
> grok might also be a good choice. I'm not quite sure of repoze.bfg is
> quite there yet, but it is shaping up to be another excellent candidate
> as well.

Grok over Pylons? I don't think Grok is really any less complex. Doing
basic stuff isn't particularly hard in Pylons, is it? There's no reason
you have to use FormEncode, AuthKit, or any of those other pieces unless
you want to, and if you are beginner to Python or web development you
might off avoiding those pieces and just writing your own ad hoc code.

Understanding Pylons will be a lot easier for you if you've spent time
understanding a "framework" in any language. If you've written your own
ad hoc PHP framework, for instance, or spent time spelunking in Rails
code... that experience should help you recognize some of what's going
on in Pylons.

--
Ian Bicking : ia...@colorstudy.com : http://blog.ianbicking.org

[Jose Galvez]

Alex Marandon wrote:

2008/12/6 zunzun <zunzu...@gmail.com>:
  

Seems like I should use Django?  Or should it be Pylons instead?
    

Here is the advice of an average programmer with no emotional
involvement in any of these projects.

I think it depends on your background. The Pylons ecosystem is very
powerful but it's quite complex and not really suitable for beginners.
  

I'm not sure there is a good framework for beginners.  If your a beginner to python, then starting with  web design will only make it harder.  If you a beginner to python web frameworks then pylons might not be your first choice only because it is complex and lets you do almost anything you want (even if its wrong).  Starting with Django or TG might be a good idea.  I stated with Webware (it made a lot of scene especially coming from a php background), but now I do most everything in pylons because of the power.  With Pylons the simple stuff is pretty simple (once you get beyond setting up your first application) and the complex stuff is possible.  I really think its the same with any web framework, the better ones are complex by their very nature, after all we're building applications where we often have to user multiple "languages" to get the desired effects, serverside code for logic and data modeling,  template code to generate a view and javascript to add ajax or just make the application look the way you want it to.  Frameworks like pylons do their best to help you separate the three, other frameworks (Webware, php) let you mash it all together.  So the long answer what is better, it all depends on what you want to do, how you want to do it, and where you are in the beginner-expert range (me I'm in the middle, not an expert yet, but I do ok).  I don't like Django because I deal with lots of legacy data, an administrative staff that is constantly changing the system requirements, so even though sometimes things might be simpler to do in something like Django, in the long run I find Pylons easier to deal with and modify.

If it's going to be the first web framework you use, you should
probably stick with Django or even better Rails. If you're a seasoned
web developer used to get acquainted quickly with new APIs and want a
maximum of flexibility, then Pylons is for you. Don't let the size of
the community fool you, when it comes to technical advice quality
matters more than quantity.
  

I agree, this group although not huge, is usually very helpful and committed to helping folks use pylons.  the problem is not that people don't always get an answer, its that they get multiple answers, different ways of doing the same thing, and to a noob I could see how that would be confusing. 

[Wichert Akkerman]

Previously Ian Bicking wrote:
>
> Wichert Akkerman wrote:
> > Previously Alex Marandon wrote:
> >> 2008/12/6 zunzun <zunzu...@gmail.com>:
> >>> Seems like I should use Django? Or should it be Pylons instead?
> >> Here is the advice of an average programmer with no emotional
> >> involvement in any of these projects.
> >>
> >> I think it depends on your background. The Pylons ecosystem is very
> >> powerful but it's quite complex and not really suitable for beginners.
> >> If it's going to be the first web framework you use, you should
> >> probably stick with Django or even better Rails.
> >
> > grok might also be a good choice. I'm not quite sure of repoze.bfg is
> > quite there yet, but it is shaping up to be another excellent candidate
> > as well.
>
> Grok over Pylons? I don't think Grok is really any less complex. Doing
> basic stuff isn't particularly hard in Pylons, is it? There's no reason
> you have to use FormEncode, AuthKit, or any of those other pieces unless
> you want to, and if you are beginner to Python or web development you
> might off avoiding those pieces and just writing your own ad hoc code.

grok is much more pluggable than pylons and has more documentation
available (especially if you also consider all zope documentation that
works for grok apps as well).

In terms of complexity for simple apps I don't think grok and pylons
differ much.

[Mike Orr]

On Mon, Dec 8, 2008 at 5:50 AM, Jorge Vargas <jorge....@gmail.com> wrote:
>
> On Mon, Dec 8, 2008 at 3:54 AM, Krishgy <kri...@gmail.com> wrote:
>>
>> If your questions needs to be answered quickly, Django may be right
>> choice. I think, you could have known why not to use PHP when you ask
>> question on Django vs Pylons :-) .
>>
>> I NEVER worked on Python at jobs. I wanted to create a website. I have
>> chosen Pylons over Django due to its customization feature & luxuries.
>> I have gathered small small frustration while working due to lack of
>> documentation & community support. I am very thankful for people who
>> helped me in some cases. I spend more time on Pylons. Now I don't have
>> time & interest to learn another framework. I have to go with Pylons.
>>
>> All I would ask seniors/library developers of pylons to respond to the
>> questions asked by newbies like me. Let the newcomers to feel good
>> about using Pylons by heart. I REALLY don't understand what do you
>> people mean by marketing Pylons. I tried to use authkit in my project,
>> which is evil in my project life. I asked many questions here but got
>> no reply. I do not expect such a thing from a matured community.
>>
> that is because
> a) the author or authkit is never around
> b) authkit is way over complicated
> c) autukit sucks in other ways
> d) all of the above.

So, we've established that AuthKit is not officially part of Pylons.
AuthKit is supported by James, and I don't think any of the other
Pylons developers have used AuthKit enough to be able to answer
questions about it. At least that's why I personally am silent
whenever an AuthKit question is raised. James was devoting all his
time to his book so he wasn't able to follow the list. Now that he's
finished that, I think AuthKit will be better supported.

So there's one issue about AuthKit questions not being answered and
another issue about other Pylons questions not being answered. My
impression is that Pylons questions remain unanswered only if nobody
knows the answer, or if the question is so application-specific that
the answerers don't understand the question. Because the Pylons
documentation is in a bit of a disarray, I think people are more
willing to answer questions here than they would be in other places.

One of Pylons' goals is to be the framework for newbies, but everybody
realizes it's not there yet. Pylons' hybrid structure makes it more
of a challenge to explain: not impossible, just more difficult.
Django and TurboGears have done a better job at supporting newbies,
and the Pylons developers routinely recommend those frameworks to
anybody who finds Pylons' current state too difficult to understand.

But I disagree that Django is 100% easier to use across the board. It
depends more in the individual than the framework. Some people are
really comfortable with Django's approach; others are not. Some find
Pylons to be the framework they've been waiting for; others find
aspects of it annoying. The best thing is to choose two or more
frameworks, browse through the documentation and try one or two little
programs. It should then become apparent which one is more suited to
you. Also think about your long-term goals. The framework that's
easiest to write "Hello, world" in is not necessarily the one you want
to be using when complex issues such as internationalization,
authorization, AJAX, or database migration come up. I choose software
based partly on its structure, partly on how responsive the mailing
list is, and partly on whether the developers have expertise in areas
I'm likely to need in the future.

> that said, I do think that a default auth should be added to pylons,
> as it's a "pretty common feeture" but that's another discussion.

It's one thing to want an auth system in the abstract. It's another
to choose a particular implementation and have to support it, and then
possibly change your mind if a better one comes along. Pylons has
already had enough trouble with blessing things that turned out to be
less than ideal in the long run (Buffet, Rails helpers, old SQLAlchemy
AssignMapper, pre-webob request/response). If we had chosen an auth
system at the beginning it would have been AuthKit because it was
written first, and then the people who say "AuthKit sucks!" would have
been howling even louder. As with SQLAlchemy, after one of the auth
systems proves itself sufficiently popular, it will become
semi-supported in the docs, and then *maybe* become a part of Pylons
at a later date.

--
Mike Orr <slugg...@gmail.com>

[cropr]

I choose Pylons and not Django for 2 specific reasons
- Mako & SQLAlchemy are far superior than the templating engine and
ORM of Django.
- Pylons is full WSGi from the ground up. It Django WSGI smells like
Object Orientation is pasted into Perl

One item I really liked about Django that is not in Pylons, is the
admin section to do simple database operations. One can argue that
this is very easy to develop (which is true), but in Django I don't
have the waste my time in writing it.

I don't use FormEncode. It is based on a very common design mistake
made by a lot of programmers, who think one can better generate html
from code. When a graphical artist designs the layout of a web page,
he uses tools who speak html, css and javascript, but no python (or
Perl, Java, C++, ...).

I tried to AuthKit in my last project (http://www.kosk.be), but I
could not bend it in the way I wanted. I want to have a login applet
open all the time (in the bottem left on www.kosk.be). I did not
manage to do this with AuthKit, but I used the methods described in
the PylonsBook, to write my own authorization layer. This was a piece
of cake and demonstrates the flexibility of Pylons

Ruben

[Wichert Akkerman]

Previously cropr wrote:
> I don't use FormEncode. It is based on a very common design mistake
> made by a lot of programmers, who think one can better generate html
> from code. When a graphical artist designs the layout of a web page,
> he uses tools who speak html, css and javascript, but no python (or
> Perl, Java, C++, ...).

While I agree FormEncode is very far from ideal, your argument does not
make sense to me. FormEncode does not generate markup at all unless
you explicitly tell it to. I do exactly what you describe: hand-written
markup written by a designer, with FormEncode on the backend only
doing decoding and validation.

[Noah Gift]

On Tue, Dec 9, 2008 at 11:33 PM, Wichert Akkerman <wic...@wiggy.net> wrote:

Previously cropr wrote:
> I don't use FormEncode.  It is based on a very common design mistake
> made by a lot of programmers, who think one can better generate html
> from code.  When a graphical artist designs the layout of a web page,
> he uses tools who speak html, css and javascript, but no python (or
> Perl, Java, C++, ...).

While I agree FormEncode is very far from ideal, your argument does not
make sense to me. FormEncode does not generate markup at all unless
you explicitly tell it to. I do exactly what you describe: hand-written
markup written by a designer, with FormEncode on the backend only
doing decoding and validation.

I think this is a case where the unified documentation that Django presents is much clearer:

http://docs.djangoproject.com/en/dev/topics/forms/

It took me 3 seconds to find how Django does form validation.  And most people aren't confused about what it exactly does.

[Ian Bicking]

Wichert Akkerman wrote:
> Previously cropr wrote:
>> I don't use FormEncode. It is based on a very common design mistake
>> made by a lot of programmers, who think one can better generate html
>> from code. When a graphical artist designs the layout of a web page,
>> he uses tools who speak html, css and javascript, but no python (or
>> Perl, Java, C++, ...).
>
> While I agree FormEncode is very far from ideal, your argument does not
> make sense to me. FormEncode does not generate markup at all unless
> you explicitly tell it to. I do exactly what you describe: hand-written
> markup written by a designer, with FormEncode on the backend only
> doing decoding and validation.

Not only doesn't it generate markup unless you tell it to, it won't even
generate markup if you *do* tell it to ;)

[Mike Orr]

On Tue, Dec 9, 2008 at 2:36 AM, Noah Gift <noah...@gmail.com> wrote:
>
>
> On Tue, Dec 9, 2008 at 11:33 PM, Wichert Akkerman <wic...@wiggy.net> wrote:
>>
>> Previously cropr wrote:
>> > I don't use FormEncode. It is based on a very common design mistake
>> > made by a lot of programmers, who think one can better generate html
>> > from code. When a graphical artist designs the layout of a web page,
>> > he uses tools who speak html, css and javascript, but no python (or
>> > Perl, Java, C++, ...).
>>
>> While I agree FormEncode is very far from ideal, your argument does not
>> make sense to me. FormEncode does not generate markup at all unless
>> you explicitly tell it to. I do exactly what you describe: hand-written
>> markup written by a designer, with FormEncode on the backend only
>> doing decoding and validation.
>
> I think this is a case where the unified documentation that Django presents
> is much clearer:
> http://docs.djangoproject.com/en/dev/topics/forms/
>
> It took me 3 seconds to find how Django does form validation. And most
> people aren't confused about what it exactly does.

Cropr's point seems to be that programmers should not design forms
because graphic designers do a much better job. That is true only if
a complex visual design for the form page is paramount. In most cases
the complex design occurs on the home page and content pages, and the
form is merely an add-on and can be simple. In some cases the form is
for technical users who will tolerate a lack of bells and whistles.
And some organizations do not have graphic designers for things like
form pages. In any case, the programmer can put CSS IDs in the form
as instructed by the graphic designer, or the graphic designer can be
taught the simple syntax of input-tag helpers.

Or you can use Genshi, which allows you to place dummy tags in the
template source, which will be replaced by the actual input tags which
can be calculated using WebHelpers. It's something like this:

<input type="text" name="name" class="my-class"
py:replace="h.text('name', value=None, class_='my-class')" />

If you're setting tag attributes, it's much more convenient to call a
helper than to interpolate the value into a static tag.

${h.text("name", id="my_name", class_=c.my_class)
<input type="text" name="name", id="my_name", class="${c.my_class}" />

The helper also takes care of issues like attributes in a dictionary.
${h.text("name", **attrs)}
<input type="text" name="name"
${FUNCTION_TO_CONVERT_A_DICT_TO_A_TAG_FRAGMENT(attrs)}>

Making links and the form tag is also more convenient with a helper.

${link_to(c.title, url("bla", anchor="bla-bla"), class_="C")}
<a href="${url('bla', anchor='bla-bla')}" class="C">${c.title}</a>

${h.form(c.action, c,method, multipart=True, class_="search")}
<form action="${c.action}" method="${c.method}"
enctype="multipart/form-data" class="search">

I haven't used Django forms but it seems to generate HTML based on a
Python field specification, akin to ToscaWidgets or Quixote forms. So
that would not meet Cropr's standards either. Especially since the
kinds of forms that require graphic designers have arbitrary and
changing requirements like "Put this field exactly here, to the right
of this other field. And could we add two paragraphs of help text
below this field? And oh, this field needs a little green message
below the title." It takes a lot of time to program this into an HTML
generator and write unit tests for it, about the same amount of time
as it does to lay out the form manually. But laying out the form
manually is made more convenient with WebHelpers.

In any case, in Pylons the programmer is free to let the graphic
designer handle all templates, or design the form with WebHelpers, or
design the form without WebHelpers, or use ToscaWidgets or Django
forms or FormAlchemy. WebHelpers is just there to provide a basic
alternative, and doesn't get much in the way if you don't use it.

--
Mike Orr <slugg...@gmail.com>

[Iain Duncan]

> I don't use FormEncode. It is based on a very common design mistake
> made by a lot of programmers, who think one can better generate html
> from code.

I think you are maybe mixing up Formencode and some projects that use
formencode. Formencode's core is for validating and converting to and
from python and raising errors. That's it.

What you're talking about is the context in which formencode is often
used, not formencode itself. Formencode does one job very well and
cleanly, it makes no assumptions about whether you are generating html
from code or not.

Iain

[Iain Duncan]

> Cropr's point seems to be that programmers should not design forms
> because graphic designers do a much better job. That is true only if
> a complex visual design for the form page is paramount. In most cases
> the complex design occurs on the home page and content pages, and the
> form is merely an add-on and can be simple.

It must also mean that their css guys are not very good. ;-)

If they are using front end css people, it should be no problem for the
coders to produce clean forms and the designers to be able to make those
look as fancy as they want with css only. A good css person should be
able to do whatever they need with nothing more than a clean list form
and some sensible id tags in there. I do both backend and front end
coding for some very picky graphic designers, and have never had
problems making toscawidget generated forms look exactly as I need them
to.

Iain

[chris....@gmail.com]

That's it.. that's the reason to use Pylons: SQLAlchemy. If you need
to actually use a database correctly (which I'm guessing that you do),
then you need to use Pylons. The db framework that ships with Django
tries to be functionally compatible with RoR-style development...
which is ok, as long you don't use your DB for anything more than
'select.. '. Totally brain-dead, IMO...and frankly targeted for
people w/o DB experience.

On Dec 6 2008, 4:42 pm, "Noah Gift" <noah.g...@gmail.com> wrote:
> On Sun, Dec 7, 2008 at 7:39 AM, Ben Bangert <b...@groovie.org> wrote:
> > On Dec 6, 2008, at 9:31 AM, zunzun wrote:
>
> >  Comparison before starting a project, used to decide which framework
> >> to use.

> >> Django: according tohttp://groups.google.com/group/django-users/about

> >> Members 12,016
> >> Group Activity is High

> >> Pylons: according tohttp://groups.google.com/group/pylons-discuss/about

> <http://markmail.org/search/?q=list%3Apylons+django+pylons>
>
>
>
> > Cheers,
> > Ben

[Jonathan Vanasco]

Django is like Rails -- it forces you into building certain types of
apps with certain styles.

If you build a Django app , you're pretty much married to it -- and
can expect it to work much like other apps. That's not necessarily a
bad thing.

Pylons & SqlAlchemy offer a lot more control.

One of my websites is 90% ModPerl with 10% pylons offloaded ; we use
the same tables & db seamlessly. I don't know if its possible in
django - but it was too hard to get done.

Another one of my projects is 60% Pylons, 20% PHP and 20% MovableType
(Perl). Again, Pylons power and flexibility let me seamlessly get all
of them working together.

( btw , we're *finally* about to release a web framework toolkit based
on Pylons that lets people do all this . huge product launches in the
next 6 weeks after 1yr of development and testing ).

[Thomas G. Willis]

Being a pylons newb myself, the first thing I did was write auth and
registration. It took a day.Granted I wasn't trying to support every
auth method I could think of like authkit does,but I learned lots.If
you want auth (and other things) rolled in use use turbogears. But
getting basic authentication and registration working is not that big
of a deal.

[chris mollis]

True.. ("..you're pretty much married to it..") that's what I saw also.. Like any bad class library, once you link to it, you're basically toast from then on.

The flip side, of course, is too much flexibility.. so much so that you're not really sure where to begin.  I was somewhat wary of that when I pushed into Pylons initially.  But I quickly found that not to be the case.   There is a definite development process, I think, that keeps some order for the developer (which is particularly important when you're starting out).


on the new startup.. that's cool..  I'm working on (yet another) one myself.. www.trailbender.net.    The coolest things are what we've done with Pylons/Postgresql/PostGIS for geo-spatial stuff..

Anyone can read the dev blog trailbender.wordpress.com...  Some (slightly schizophrenic) examples and how we use it with SQLAlchemy/PostGIS.

[Colin Flanagan]

The SQLAlchemy argument is a very compelling one. I have an application that, while being a CMS, has heavily relational data. I was urged by different people to do it either in Django or Plone, but went with Pylons. My domain objects are far easier to work with, though I did suffer from the authentication layer and a few other things I had to build from scratch.

Django can use SQLAlchemy, but by doing so you pretty much nullify a lot of the things that are unique to that framework like their "automatic admin interfaces." Django's object generation came nowhere near understanding my moderately-complicated data model and would have been much more difficult to develop with, as compared to Pylons with SQLAlchemy.

On another note:
I find it interesting that a lot of people recommend Django for CMS-type applications. I would think that Plone might be more far more suitable given that:
1. your data fits well with the hierarchical structure of the ZODB
2. your content is comparable to the content types already established in Plone
3. you don't have any legacy data or need to integrate with other systems
4. you don't need to do lots of custom UI/presentation layer work

I'm curious if Django's CMS reputation comes from the fact that it's used by a lot of newspapers and content providers, or if there really is something that makes it advantageous over other frameworks.

[Noah Gift]

Jonathan,

This seems like a very interesting set of projects. I wonder if there
is somewhere people could here, "customer stories" like this in one
spot. I had no idea people where doing this with Django.


> >
>

[Lawrence Oluyede]

On Mon, Jan 19, 2009 at 6:20 PM, Colin Flanagan <quadv...@yahoo.com> wrote:
> I'm curious if Django's CMS reputation comes from the fact that it's used by a lot of newspapers and content providers, or if there really is something that makes it advantageous over other frameworks.

Django's admin is very handy for content based sites. We're developing
the Italian PyCon website with Django. While we develop the webiste
some people can upload and review documents, rollback and stuff like
that.

Very nice. Nothing you can't code in Pylons or CGI with C, but it's
nice to have it for free.

--
Lawrence, http://oluyede.org - http://twitter.com/lawrenceoluyede
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair

[Wyatt Baldwin]

On Jan 19, 9:20 am, Colin Flanagan <quadvill...@yahoo.com> wrote:
> The SQLAlchemy argument is a very compelling one.  I have an application that, while being a CMS, has heavily relational data.  I was urged by different people to do it either in Django or Plone, but went with Pylons. My domain objects are far easier to work with, though I did suffer from the authentication layer and a few other things I had to build from scratch.
>
> Django can use SQLAlchemy, but by doing so you pretty much nullify a lot of the things that are unique to that framework like their "automatic admin interfaces."  Django's  object generation came nowhere near understanding my moderately-complicated data model and would have been much more difficult to develop with, as compared to Pylons with SQLAlchemy.
>
> On another note:
> I find it interesting that a lot of people recommend Django for CMS-type applications.  I would think that Plone might be more far more suitable given that:
> 1. your data fits well with the hierarchical structure of the ZODB
> 2. your content is comparable to the content types already established in Plone
> 3. you don't have any legacy data or need to integrate with other systems
> 4. you don't need to do lots of custom UI/presentation layer work

I'm no Plone expert, but I don't think #4 is a problem for Plone. I
think there are actually quite a few Plone sites with custom UIs (my
company's new Intranet being one of them).

And just to add another voice to this SQLAlchemy hurrah, like Colin,
I'm also doing (complex) GIS stuff with PostGIS (& Shapely & GeoJSON &
PyProj). Having a bit of experience with both Django and Rails, I
don't know how I'd accomplish with their ORMs what I can with SA. I'm
not saying it's not possible, but it seems nowhere near as
straightforward or flexible.

I'm also using Pylons/SA with a big, ugly, legacy Oracle schema. Fun,
fun, fun.

PS If anyone needs an SA type def for PostGIS geometry columns, give
me a shout. I have one version based on PCL and another on Shapely.

[Wyatt Baldwin]

On Jan 19, 1:29 pm, Wyatt Baldwin <wyatt.lee.bald...@gmail.com> wrote:
> On Jan 19, 9:20 am, Colin Flanagan <quadvill...@yahoo.com> wrote:
>
> > The SQLAlchemy argument is a very compelling one.  I have an application that, while being a CMS, has heavily relational data.  I was urged by different people to do it either in Django or Plone, but went with Pylons. My domain objects are far easier to work with, though I did suffer from the authentication layer and a few other things I had to build from scratch.
>
> > Django can use SQLAlchemy, but by doing so you pretty much nullify a lot of the things that are unique to that framework like their "automatic admin interfaces."  Django's  object generation came nowhere near understanding my moderately-complicated data model and would have been much more difficult to develop with, as compared to Pylons with SQLAlchemy.
>
> > On another note:
> > I find it interesting that a lot of people recommend Django for CMS-type applications.  I would think that Plone might be more far more suitable given that:
> > 1. your data fits well with the hierarchical structure of the ZODB
> > 2. your content is comparable to the content types already established in Plone
> > 3. you don't have any legacy data or need to integrate with other systems
> > 4. you don't need to do lots of custom UI/presentation layer work
>
> I'm no Plone expert, but I don't think #4 is a problem for Plone. I
> think there are actually quite a few Plone sites with custom UIs (my
> company's new Intranet being one of them).
>
> And just to add another voice to this SQLAlchemy hurrah, like Colin,
> I'm also doing (complex) GIS stuff with PostGIS (& Shapely & GeoJSON &
> PyProj). Having a bit of experience with both Django and Rails, I
> don't know how I'd accomplish with their ORMs what I can with SA. I'm
> not saying it's not possible, but it seems nowhere near as
> straightforward or flexible.

s/Colin/Chris

[Wyatt Baldwin]

On Jan 19, 12:26 pm, Noah Gift <noah.g...@gmail.com> wrote:

With Django or with Pylons?

[Eric Lemoine]

Hi,

We also have this in MapFish.
<https://trac.mapfish.org/trac/mapfish/browser/trunk/MapFish/server/python/mapfish/sqlalchemygeom.py>

--
Eric

[Noah Gift]

Ah, I meant Pylons :) Maybe this could be done officially or unofficially.


> >
>

[Jorge Vargas]

On Mon, Jan 19, 2009 at 3:15 PM, Lawrence Oluyede <l.ol...@gmail.com> wrote:
>
> On Mon, Jan 19, 2009 at 6:20 PM, Colin Flanagan <quadv...@yahoo.com> wrote:
>> I'm curious if Django's CMS reputation comes from the fact that it's used by a lot of newspapers and content providers, or if there really is something that makes it advantageous over other frameworks.
>
> Django's admin is very handy for content based sites. We're developing
> the Italian PyCon website with Django. While we develop the webiste
> some people can upload and review documents, rollback and stuff like
> that.
>
> Very nice. Nothing you can't code in Pylons or CGI with C, but it's
> nice to have it for free.

you should try out Catwalk2, tgext.admin and/or Rum. They are
currently the competitors in TurboGears2 regarding this playing field.

Catwalk2 and tgext.admin are build on top of Turbogears so you will
need that dependency (totally worth it) or if you don't want that then
Rum is a wsgi app

http://pypi.python.org/pypi/Catwalk
http://pypi.python.org/pypi/tgext.admin/
http://docs.python-rum.org/user/install.html

Note: the author is catwalk and tgext.admin is the same guy, he is
currently considering of folding one of the projects into the other as
at this moment their only difference is that Catwalk2 is equivalent to
"django's autodiscovery" while tgext.admin is the "customizable by
code type of thing"
Note2: I haven't used any of the 3 outside a turbogears project, but
they will work in parallel

[Mike Orr]

On Mon, Jan 19, 2009 at 1:29 PM, Wyatt Baldwin
<wyatt.le...@gmail.com> wrote:
>
> On Jan 19, 9:20 am, Colin Flanagan <quadvill...@yahoo.com> wrote:
>> The SQLAlchemy argument is a very compelling one. I have an application that, while being a CMS, has heavily relational data. I was urged by different people to do it either in Django or Plone, but went with Pylons. My domain objects are far easier to work with, though I did suffer from the authentication layer and a few other things I had to build from scratch.
>>
>> Django can use SQLAlchemy, but by doing so you pretty much nullify a lot of the things that are unique to that framework like their "automatic admin interfaces." Django's object generation came nowhere near understanding my moderately-complicated data model and would have been much more difficult to develop with, as compared to Pylons with SQLAlchemy.
>>
>> On another note:
>> I find it interesting that a lot of people recommend Django for CMS-type applications. I would think that Plone might be more far more suitable given that:
>> 1. your data fits well with the hierarchical structure of the ZODB
>> 2. your content is comparable to the content types already established in Plone
>> 3. you don't have any legacy data or need to integrate with other systems
>> 4. you don't need to do lots of custom UI/presentation layer work
>
> I'm no Plone expert, but I don't think #4 is a problem for Plone. I
> think there are actually quite a few Plone sites with custom UIs (my
> company's new Intranet being one of them).

Plone is certainly very complete. Its main problem is its Zope 2
legacy, which many people see as baggage. But if you ignore that,
it's got many many things a content-based site needs. Pylons is
clearly better for a calculation-based site with a lot of little
pieces of data, although of course you can build any site in either.
Django is in between, with some CMS-handy features built in, yet also
capable of running a calculation-based site, but is perhaps not as
attuned to it as Pylons is.

> PS If anyone needs an SA type def for PostGIS geometry columns, give
> me a shout. I have one version based on PCL and another on Shapely.

I don't know this, but there are open-source GIS groups who probably do.
http://groups.google.com/group/cugos

--
Mike Orr <slugg...@gmail.com>

[Jorge Vargas]

sorry for more TG propaganda, but one of our gsoc projects from last
year was exactly this. I know the author and even though I haven't
used the code for anything real, it looks very nice. His gsoc was
really nice as it was mainly to "try to get as much gis stuff working
with tg as possible"

overview docs http://turbogears.org/2.0/docs/main/Extensions/Geo/
here is a demo app http://geo.turbogears.org/
and the project page http://code.google.com/p/tgtools/

Now keep in mind this was one of the goals for TG2, let pylons
concentrate on the details of the framework while TG explored the
extensions.

[Noah Gift]

Although, this might eventually move to an even more common "United"
core that many web frameworks extend off of:

http://www.openplans.org/projects/pypefitters/

We can only hope...

>
> >
>

[Colin Flanagan]

----- Original Message ----
From: Jorge Vargas <jorge....@gmail.com>
To: pylons-...@googlegroups.com
Sent: Monday, January 19, 2009 4:45:35 PM
Subject: Re: Django or Pylons - comparison details

These are really interesting. I'm especially curious to hear anyone's experience using Rum with Pylons. I'm getting ready to build something really similar but am now thinking otherwise.

My impression of Django's admin was that, once you've replaced the native ORM, you no longer "get it for free." That still holds true, no?

[Jorge Vargas]

as I said rum is a wsgi app, so it runs standalone, rumAlchemy <your
dburi> is enough. to try it out. As for the integration (running in
the same process, theme sharing, etc.) that's another story, you could
base yourself on the tg2 sample app.

>
> My impression of Django's admin was that, once you've replaced the native ORM, you no longer "get it for free." That still holds true, no?

yes, django admin is tied into django ORM. On the contrary rum has
interfaces to use other ORMs, but so far it only has a SQLAlchemy
backend. The same hold s true for catwalk2.

Just to be clear, all 3 of these tools provide some how the same
feature set of django admin. they are NOT django they are 100%
TG/pylons code. Both use as base ToscaWidgets which ones was
TruboGears widgets, catwalk2 and tgext.admin build on top of a second
framework call sprox (which is somehow like formalchemy), The
difference between the three is really set in internal components and
some design issue, but to the end use they all should be quite alike.

[Chris Miles]

On 20/01/2009, at 3:30 AM, Thomas G. Willis wrote:

> Being a pylons newb myself, the first thing I did was write auth and
> registration. It took a day.Granted I wasn't trying to support every
> auth method I could think of like authkit does,but I learned lots.If
> you want auth (and other things) rolled in use use turbogears. But
> getting basic authentication and registration working is not that big
> of a deal.

Similar story, but I used repoze.who for authentication and am very
happy with it. It is very customisable, which is what I needed; the
app supports both form/cookie auth and HTTP basic auth simultaneously.
repoze.who made this easy to configure in exactly the way I wanted.

Cheers,
Chris Miles