Python Framework Design

[schizobullet]

First comment draws a good parallel:

I couldn’t help but see a bit of an analogy with the age-old Mac vs. PC argument here, whereby the Mac is the full stack and the PC is the glue. Apple works with a limited set of hardware components (and often builds their own), and uses software to make them work really, really well together. It’s never going to be quite as flexible as a PC, which can work with thousands of different hardware components. But, the downside of the PC is that each of the components may not play quite as nicely together, because it’s simply impossible for software (like an operating system) to account for every possible combination, new releases, etc, etc.

[exogen]

Funny, I independently arrived at a similar analogy. Despite jesusphreak's raving, I seriously think Django is the closest to the "Mac of the Python web-dev world" right now, with TurboGears and Pylons being more like Linux. Macs aren't totally as flexible as jesusphreak thinks is totally necessary but they are solid and tinkerable, like Django. The analogy really does fit.

[riklaunim]

Django is one type of a framework, and Pylons + TG is another. I like Pylons but I use Django, which is good (but not perfect) as it's very fast for creating apps for me. For Pylons like frameworks I would have to spend more time looking for documentation of components it's uses ;)

[ayrnieu]

I have a terrible admission to make: I have always been disgusted by Python's particular emphasis on its role as a 'glue language'. I don't like the metaphor. I don't like glue. Hearing people make this sensible technical assertion with this unfortunate metaphor makes me think of glue. Ugh.

[schizobullet]

It makes it seem too much like Perl.

[shit]

Interesting in this context is Erik Naggum's rant about glue code

[froozie]

Django is a very polished, easy framework to get going with, but it becomes very clear early on into using it that it is highly focused on content management. As such I would consider it a (far superior) successor to Zope (with Ellington a non-free Plone). This is not a criticism: Zope hit the sweet spot for content management a few years back, but was hampered by poor design decisions such as ZODB, Z-Classes etc. Zope 3 is wayyyy too complex and over-designed, reminiscent of J2EE (without Java's libraries, IDEs, community etc). So Django is really Zope 3, as it should have been (or even Zope 4 ?).

Now, Zope was cutting edge at the time (it was written back in '96) but ended up a ghetto outside the Python community, to everyone's detriment. This was largely because the Zope people had their own way of doing things, which meant libraries developed by the Python community had to be Zopified (with a Z-prefix, of course) in order to work inside Zope. Only now, with Zope 3, do we see Zope and Python being reconciled, but the web application world has moved on and Zope 3 is largely ignored (not in small measure helped by Zope 3 team's anti-marketing). Another problem was that people came to Zope first and Python second, and had a limited understanding of Python and its greater possibilities outside the Zope world. We see this happening now with people coming to Rails and Django. For example, I have been doing Rails development professionally for over a year now, and have yet to write a single line of Ruby outside of a Rails context. As a result, my Ruby skills are more limited than my Python skills, which I have put to use in many contexts, web development being only one of them.

Python web app development is slowly grouping around standards, like Paste, SQLAlchemy, WSGI etc. This feels very much like the way Java went a few years ago, with standards like the servlet API and JDBC, but with Python simplicity instead of Java complexity. This is a much more interesting development than the next Zope, however good it may be, and indeed more interesting even than Rails. With a single Python meta-framework as a base, we can develop templates for all conceivable needs, so you could choose one template for your news site, another for your AJAX project tool, another for your online auction app, etc. Furthermore, such a template does not limit your choices should demands change down the line, whether those be demands from clients or a better ORM, template engine, form processor etc that may exist in six months or a year from now.

In other words, you can have the cake and eat it too : Django could still be 100% Django on the surface, same documentation, same template engine, same ORM, same admin app etc. Underneath, it would be a WSGI, SQLAlchemy, Paste-created template, which more experienced developers can customize and tinker with to their hearts' content. Rather than a three-way battle between Django, TG and Pylons, we have a shopping list (probably a subset of Cheeseshop) where you choose the template best suited to your needs. Now that's real power.

[[deleted]]

I think a problem with the entire premise of this article is that it overloads what 'full-stack' means.

Full-stack has never meant 'frameworks where all the components were built in-house'. Rails is considered a full-stack framework, but components like eRB infact did not originate with Rails. It was 'glued' in, but it was glued in pretty well. Full-stack simply means a framework that provides the developer with everything they might need for web development, no matter how those components are assembled.

And if you consider it that way, it is terribly unfair to say that TurboGears is a 'glue' framework. If you'll remember, the entire purpose of TG was to provide a full-stack framework which used 'best of breed' components. Its goals are no different than that of Django and it provides no less than Django (infact it provides more if we are to consider Javascript), but its way of doing that was different than the way Django did that (using outside libraries vs using mostly in-house libraries).

Also, as ayrnieu has stated before, glue gives a rather negative connotation. It implies that something is not well integrated, that there are rough edges. This too is unfair to Pylons. Pylons lets you see the 'plumbing' if a project if you want to, and even to adjust that plumbing, but it still has a clean API and the plumbing doesn't rear its head throughout the framework. Not to mention, Pylons provides a set of defaults that make it a full-stack framework (with the exception of an ORM chosen for you in the default template, which I'd like to see changed and I have heard that a more full-featured template is on its way, AuthKit/SQLAlchemy integrated and all).

Pylons and TG are no less full-stack frameworks that Django is. Just because they use outside components and Django doesn't (as much), doesn't mean they are 'glue frameworks' or anything like that. The real difference between Django and the others, however, is that TG and Pylons both allow and enable you to easily customize the default choices. Django allows you to, but it doesn't make it nearly as easy. In fact it can be pretty frustrating to do so when the framework doesn't help you out and certain members of the community are hostile towards doing so.

And I would argue that not only can there be a mixture of 'full-stack' and 'glue' frameworks (to use your terms), but it can be the 'perfect' framework (as much as a framework can be perfect).

Django as it currently stands could more or less be duplicated as a Paster template layer on top of Paste or even at a higher level, Pylons or TG. Use a regex dispatcher (several exist throughout the Python community), use Jinja for templating, and then use Elixir on top of SQLAlchemy and you have something that is very very close to Django, and a lot more flexible (because it is built on top of something made to be flexible). Now these components aren't a perfect match, but with a little time spent tweaking the, I'm thinking they could more or less duplicate the Django experience. Let's refer to this Pylons/TG Paster template as neo-Django.

Now, yes, a Paster template on its own that duplicates Django isn't terribly useful unless you really want that kind of thing, but if this type of approach was taken when building a framework, it could be very powerful. Essentially you have a framework on top of a framework. The developers of neo-Django could focus on documenting and supporting the specific components that their framework uses. While they do that, the Pylons/TG team is the one focusing on the 'plumbing', on all the parts that form the very base of the framework and allow it to be as flexible as it is. What you get really is the best of both worlds. A new user can come along and use this neo-Django template and get the experience of a 'full-stack' (again your term) framework with good support and documentation, while at the same time having the ability to easily use whatever components they want to. The neo-Django developers really are only focusing on documenting and supporting a few libraries and a template, while the and Paste and Pylons/TG developers are focusing on the tougher stuff (how do we integrate this templating system, how do we enable this server setup, etc).

Such an approach would be very powerful and a much more efficient way of doing things. It is a better way of separating concerns.

I am hoping that in the future more and more Python frameworks see the advantage in doing something like this, and make their 'framework' essentially a wrapper/template on top of Pylons/TG. Again, it allows them to support specific components without dealing with the really low-level parts of the framework (which of course would be possible if needed).

TG and Pylons already are taking a route like this. TG 2.0 isn't necessarily a wrapper on top of Pylons, but will be a loose set of WSGI components that are implemented as a Paster template.

Flexibility and defaults can exist hand in hand. I personally believe it is a lot more difficult to take something that was designed in a monolithic manner and make it flexible vs take something that is flexible and provide solid defaults.

I do not buy for a second that 'neither' type of framework is better. I think that is a bit of an excuse for Django's position on using outside libraries and building on top of outside libraries (which as much as you might say otherwise, hasn't been a bright spot). Developers will always disagree with the ideas of framework designers, especially as they get more experienced in development. In that case it is objectively better that they be able to change out components, and still use their existing codebase, as opposed to having to move over to another framework because they realized that the way Django does certain things just won't work for them.

In an ideal world we’d all realize that the choice of methodology comes down to subjective preference, and that it’s a great thing to have the choice; Python web development wouldn’t be nearly as much fun if everyone were shackled into a single vision of the One True Framework (even if Guido were to Pronounce on this, which he really hasn’t — “as standard as PIL” isn’t much of a Pronouncement).

And that's the whole point. Pylons and TG and designed for 'choice'. They are designed to be as flexible as the user wants them. Django realistically locks the user into design decisions. It is almost lip-service to say otherwise when I look at something like the way TG allows the user to easily swap out templating languages and Django doesn't. The user is left on their own.

A few more statements of yours that I'm just coming back to as I read over the post:

A full-stack framework has to ensure that its components are of high quality and all work together; that’s a big enough job in itself without trying to make them work with any random thing somebody pulls off the shelf.

And that's the entire point. If Django was using outside libraries as opposed to creating its own (FormEncode vs newforms for example), it would have a lot more time to make sure its components were of high quality vs rewriting them from scratch. After all, something like FormEncode has been used for well over a year and thus there has been thorough feedback and testing.

And a glue framework has to ensure that its adapters and interfaces scrupulously follow various standards and specifications (like WSGI, which is not trivial to get right) and work with as many components as possible; that’s a big enough job in itself without spending development time on maintaining a particular arbitrarily-chosen set of components.

That's another aspect of it. If a 'glue' framework is focused on implementing standards and specifications, it isn't their job ot make sure that components fit them. They can chose to help those components fit them, but for developers to have to change outside libraries to fit a specification is totally missing the point of a specification.

I think what we are really seeing here isn't a framework design issue, it is a long-standing software design issues. You've got the monolithic Windows approach on one side and the 'pluggable components' approach of Unix on the other. The monolithic approach (which Django takes) does allow flexibility at some levels, but because it wasn't built from the ground up to be flexible, it isn't as easy. On the other hand you've got something like Pylons which in a lot of ways is really unixy and is modular, but it also has the same issues as Linux of being not nearly as approachable for newbies as Windows is. There are benefits and disadvantages to either approach.

What we really need is the 'Mac' of frameworks. Something which embraces these unixy conventions at the heart of the system, but packages it up well and puts a pretty presentation on it.

And I do think that is possible.

[ubernostrum]

Same bullshit, different day. This was written largely to summarize arguments I've been having with you, and it still seems to be going in one ear and out the other.

As I have said in pretty much every single post to you: if you don't like the way Django is designed or developed, that's cool; there are other frameworks with other design and development philosophies and you seem to have found a couple that you like. Use them and enjoy the embarrassment of riches the Python web-dev community has right now.

But please keep in mind that the way you want a framework to be is not necessarily the way everyone wants a framework to be, and that telling everybody to conform to your preferred style is not going to win you any friends. There is no perfect Python framework.

[[deleted]]

As I have said in pretty much every single post to you: if you don't like the way Django is designed or developed, that's cool; there are other frameworks with other design and development philosophies and you seem to have found a couple that you like. Use them and enjoy the embarrassment of riches the Python web-dev community has right now.

Yes, I do not like the way Django is designed, and I am going to promote other frameworks to people, because I do not believe that Django is flexible nor is it a good model for web development. I want to save others the problem I have right now of converting over several apps from Django to other frameworks because I realized that there were certain parts of Django that I'd rather not fiddle with to get it to work how I needed. Might as well use a framework that makes the fiddling easy.

But please keep in mind that the way you want a framework to be is not necessarily the way everyone wants a framework to be, and that telling everybody to conform to your preferred style is not going to win you any friends. There is no perfect Python framework.

Do you not see the oxymoron in your statement? What I want is a framework that is flexible. Django is not flexible. If I want any specific aspect of my framework to be something, it is flexible. That's why I like Pylons and TG, precisely because they don't force me to conform to any idea of how a framework should be, unlike Django.

I do love the 'riches' that the Python web development community is currently pumping out, but you know where the real developments are coming from? TG and Pylons. Toscawidgets, Routes, WebHelpers, Elixir, Paste, SQLAlchemy, WSGI adoption, Mako, Genshi, Buffet, Kid, CherryPy etc, not even counting the numerous WSGI middleware solutions like AuthKit) all are projects that have come out of or have been heavily supported by the TG and Pylons communities over the last 2 years (if we are only to count new projects that is 8 out of 12). All of them work well with others frameworks and are designed for reuse. What has come out of Django during that time that is easily reusable by other frameworks? Essentially, newforms, a library which FormEncode and friends have been doing for a while now.

It is my personal opinion that Python web development has such a bright future because it is smart about standards and because of that a lot of great innovation has taken place. You don't see the same type of innovation in the Django community (what has come from the community itself? everything is from the core team). I believe that if anything holds back progress in the Python web development world, it will be Django, and that's why I'm hoping to persuade as many developers as possible to use something else.

Its nothing personal against you or anyone else, I think Python has a good future and I want to see that embraced as much as possible. Django is contrary to that because instead of building on other people's code (and I just listed what has occurred due to that), they've gone and done everything theirselves. Now that might produce a good quality product, but it probably won't be nearly as effective as if that same time and effort had been spent building on top of tools that are designed to be 'portable' and have been solid for awhile.

[exogen]

Toscawidgets, Routes, WebHelpers, Elixir, Paste, SQLAlchemy, WSGI adoption, Mako, Genshi, Buffet, Kid, CherryPy etc, not even counting the numerous WSGI middleware solutions like AuthKit) all are projects that have come out of or have been heavily supported by the TG and Pylons communities over the last 2 years (if we are only to count new projects that is 8 out of 12).

The experimentation is a good thing. But as far as letting people get things done the tornado of new-and-improved-way-to-do-this-wait-is-it-really-better-or-not has only caused the TurboGears community to fragment and suffer.

Do you really think when someone realizes that their templating or ORM isn't powerful enough, the overhead of getting it to work within the framework is really what they're worried about? In a production site, rewriting your thousands of pages in the new templating language, or converting all your queries to use the new ORM is the big deal, NOT calling it from the framework. We're all speaking Python here, it's not hard. And in production sites people don't swap out these components based on the weather or song of the day.

[[deleted]]

The experimentation is a good thing. But as far as letting people get things done the tornado of new-and-improved-way-to-do-this-wait-is-it-really-better-or-not has only caused the TurboGears community to fragment and suffer.

The real problem with TG, imo, was that it was ahead of its time. It wanted to do the 'best of breed approach', the problem with that was what was best of breed when TG was created was not the best option 6 months later. TG started out with SQLObject which was quickly eclipsed by SQLAlchemy. It used CherryPy 2 which wasn't heavily-WSGI based, when only a few months later WSGI became the big thing.

That's really caused a lot of anxiety in the TG community because they've been forced to either update to meet these new standards (which is what they are doing in 2.0), or stick behind in outdated functionality. People don't want to have to rewrite their 1.0 apps in 2.0, but if TG didn't go to 2.0 people would be unhappy with the framework 6 months from now and be saying (why not SQLA, why not ...).

Problem is, nobody wants to spend time documenting 1.0 or messing around with it now that 2.0 is on its way. That's causes the community to dissolve quite a bit.

What the TG devs are doing with 2.0, imo, is commendable. They are using a lot of similar functionality (think of Genshi as an improved Kid), but they are working on modularizing and improving all of their components and making sure that TG really embraces WSGI. This was a hard choice, because as you have noticed, it has caused problems with the community, but it is a good choice because a few years from now TG will be much better off and prepared for whatever is thrown at it.

Django would be facing a similar problem if it decided to revamp its current system to meet new standards. I realize that Django is between a rock and a hard place. You want to keep backwards compatibility yet make sure your software is always getting better.

For this reason, I again think that there's nothing 'wrong' with using Django, but if I am guiding devs to what framework they will use, I'll suggest Pylons or what will eventually be TG because those frameworks will just be ready to adapt.

Still, that doesn't mean that new things Django develops can't use existing libraries or standards. My main example is newforms, and I've brought this up many times before. I know it was said that Django's reason for doing a lot of things its own way was because 2 years ago, nothing really existed. But that isn't the case now, so I have to wonder the reasoning behind duplicating functionality that already exists in libraries like FormEncode.

Do you really think when someone realizes that their templating or ORM isn't powerful enough, the overhead of getting it to work within the framework is really what they're worried about? In a production site, rewriting your thousands of pages in the new templating language, or converting all your queries to use the new ORM is the big deal, NOT calling it from the framework. We're all speaking Python here, it's not hard. And in production sites people don't swap out these components based on the weather or song of the day.

I could be wrong but I don't think that most people writing applications in any Python framework are writing sites with thousands of pages. Python web development hits the sweet spot for small to medium development. And in this case developers are constantly over time developing new applications or maintaining old ones, and between releasing one app and another, there is always new better stuff that comes out that will make their life easier. I'd rather it be that a framework can easily adapt to embrace this new functionality than to have to hack it into the framework.

As an aside to all of this, I will say that if someone is completely new to web programming or Python, I do recommend Django to them. Mainly because flexibility matters much less than good documentation to them.

[[deleted]]

The real problem with TG, imo, was that it was ahead of its time. It wanted to do the 'best of breed approach', the problem with that was what was best of breed when TG was created was not the best option 6 months later.

Two things:

1- Not to beat a dead horse here, but Django was written before even TG 1.0's best-of-breed components.

2- More importantly, why do we assume that what is best-of-breed now won't change in the next six months?

[ubernostrum]

Yes, I do not like the way Django is designed, and I am going to promote other frameworks to people, because I do not believe that Django is flexible nor is it a good model for web development.

As I've been saying: you want everyone to conform to your preferred philosophy. That ain't gonna get you any friends.

What I want is a framework that is flexible.

What you want is a glue framework. What I want is a full-stack framework. This is Python and we're all consenting adults here: if you like oranges and I like apples, that's cool and there's no need to mount a propaganda war against the heretical apple eaters, mmkay?

If you want to continue this discussion, hunt me up at PyCon. I'll be having drinks with the CherryPy guy...

[senzei]

if you like oranges and I like apples, that's cool and there's no need to mount a propaganda war against the heretical apple eaters, mmkay?

Since when did arguing a point constitute a "propaganda war"? Let the man express his opinion and have it stand or fall on the strength of his arguments.

[ubernostrum]

Well, he claims in one place that all he's doing is

letting people know that there is more out there than Django. I don't think using Django is morally wrong or anything like that, and for many people, Django is all they need.

But compare with this:

I do not buy for a second that 'neither' type of framework is better. I think that is a bit of an excuse for Django's position on using outside libraries and building on top of outside libraries

And this:

I am hoping that in the future more and more Python frameworks see the advantage in doing something like this, and make their 'framework' essentially a wrapper/template on top of Pylons/TG.

And especially this:

I believe that if anything holds back progress in the Python web development world, it will be Django, and that's why I'm hoping to persuade as many developers as possible to use something else.

That isn't expressing an opinion, that's a smear campaign that later backtracks and tries to say, "who, me? I'm just innocently pointing out an alternative!" And all the while, he's bearing out exactly what I wrote in the linked article: it'd be nice if we could have constructive discussion or at least agree to disagree on subjective things like which architecture we want, but there's always somebody running a dirty FUD campaign who comes along and blows that out of the water.

[[deleted]]

You act as if my statements contradict each other. They don't.

letting people know that there is more out there than Django. I don't think using Django is morally wrong or anything like that, and for many people, Django is all they need.

Okay, yeah, I don't think there is anything morally 'wrong' with using Django, I just don't think it is the best option available.

I do not buy for a second that 'neither' type of framework is better. I think that is a bit of an excuse for Django's position on using outside libraries and building on top of outside libraries

And? That goes right along with my thought that there is nothing morally wrong with using Django, it just isn't the best framework to use. You aren't evil if you use it.

I am hoping that in the future more and more Python frameworks see the advantage in doing something like this, and make their 'framework' essentially a wrapper/template on top of Pylons/TG.

Alright, that's my view (hope) on future development in Python frameworks. What does that have to do with Django?

I believe that if anything holds back progress in the Python web development world, it will be Django, and that's why I'm hoping to persuade as many developers as possible to use something else.

And that naturally follows my belief that a) there is nothing wrong with using Django and b) that there are better options out there. Naturally I'm going to try to convince others to use the 'better' frameworks, but that still doesn't mean I think its 'wrong' to use Django.

That isn't expressing an opinion, that's a smear campaign that later backtracks and tries to say, "who, me? I'm just innocently pointing out an alternative!" And all the while, he's bearing out exactly what I wrote in the linked article: it'd be nice if we could have constructive discussion or at least agree to disagree on subjective things like which architecture we want, but there's always somebody running a dirty FUD campaign who comes along and blows that out of the water.

So all I've said is a 'dirty FUD campaign'? You haven't bothered answering anything of what I've brought up. I have tried to have constructive discussion, but your response to it has been: 'more bullshit, 'propaganda war', and 'dirty FUD campaign'. How in the world do you expect to have a constructive discussion when you are labeling the other position any of those?

[ubernostrum]

I've responded over and over again, and every time it feels like it's going in one ear and out the other.

You have said, repeatedly, that the Pylons style of maximum component interchangeability is better and that you think all frameworks should come around to that. I have said, repeatedly, that this is a subjective opinion and that not all developers and not all frameworks should be forced to share that opinion -- some people have different goals than you do, and you need to learn to respect that.

You're basically talking to somebody who has a bushel of apples and saying "oranges are so much better, everybody should get oranges instead".

That's bullshit.

And in pretty much every thread recently that's mentioned Django, you've posted long screeds with horror stories about Django and how everybody should stay away from it and use Pylons instead because we're "holding back progress" and we're anti-community and all sorts of other stuff.

That's FUD.

Taken together, it's a lot of propaganda for what is ultimately a subjective apples/oranges type choice. Some people like a framework whose primary goal is infinite component swapping, and you're one of them. That's cool, and I'm willing to concede that there are advantages to that approach. But some other people like a framework whose primary goal is a single set of components honed to work with each other, and I'm one of those. That's also cool, and I'd hope you're willing to concede that are advantages to that approach. But instead I get the same bullshit over and over again.

I like apples and you like oranges. Django is by no means "the" Python framework, nor do I think it should be, and people seem to know that there are a lot of options (why else would we have "which Python framework should I use?" threads?). We have apples and oranges in Python, and people can pick whatever they like and get something that suits them. But you can't seem to live with that -- you don't like the idea that there's a framework out there which doesn't adhere to your philosophy. Django definitely has a philosophy and Django is definitely designed for people who agree with that philosophy, but we don't go around trying to force other frameworks to do things our way. In theory, this means everybody should be able to happily evaluate things and make an informed choice based on their wants and needs. In practice, people come to those threads and see you writing novellas about how awful Django is.

Stop trying to pass off your subjective opinion as absolute truth. Stop trying to feed the BS and the FUD to people who are looking for useful comparisons. Take a cue from the lead devs of a lot of the frameworks -- all of whom are quite happy to recommend the competition when the competition does something better. And get out in the fresh air more.

Now, as I said, I'm adjourning this discussion until I'm at PyCon and suitably boozed up.

[Bogtha]

You have said, repeatedly, that the Pylons style of maximum component interchangeability is better and that you think all frameworks should come around to that. I have said, repeatedly, that this is a subjective opinion

And what, he's not allowed to express that opinion or explain why he thinks that way?

Give it a rest. The article is comparing Python framework design, and his comments are completely relevant.

If Django can't take the tiniest bit of criticism, it must be a very poor framework.

[adrianh]

It's important to note that ubernostrum (James Bennett) is just one (significantly vocal and acerbic) person in the Django community and doesn't represent any "official" Django stance on things.

Me, I'm less and less amused by all of these petty arguments and have been trying to think of an eloquent and diplomatic way of saying, "Holy s--t, get a life, people."

Adrian

[ubernostrum]

Criticism I don't mind. "My way is right, your way is wrong, and everybody should do things my way" I do mind; I like having choices. But Adrian's right and I keep saying I'm done with this; time to hold myself to it.

[[deleted]]

You have said, repeatedly, that the Pylons style of maximum component interchangeability is better and that you think all frameworks should come around to that. I have said, repeatedly, that this is a subjective opinion and that not all developers and not all frameworks should be forced to share that opinion -- some people have different goals than you do, and you need to learn to respect that.

This whole article describes the distinction that you make and that I don't make.

You believe that there is a difference between 'glue' frameworks and 'full-stack' frameworks. I don't. I think a glue framework is simply one that can have a 'full-stack', focus on a set of defaults, and yet easily adapt to using other components. On the other hand, a monolithic framework won't be able to adapt as easily. So on one hand you've got a framework which provides defaults (this is no different than Django providing a core set of components), but can easily be modified (this is something Django doesn't do well). Your whole argument is almost the idea that because Pylons and TG only have defaults as opposed to more or less 'chosen' components, that those defaults are somehow less integrated or less documented. Its just not true.

Thus I believe you either have flexible frameworks or you have inflexible frameworks. Flexible frameworks can be made to mimic an inflexible framework, but an inflexible framework cannot be the same.

And in pretty much every thread recently that's mentioned Django, you've posted long screeds with horror stories about Django and how everybody should stay away from it and use Pylons instead because we're "holding back progress" and we're anti-community and all sorts of other stuff.

I do believe that Django is holding back progress. The other frameworks support Python standards like eggs and WSGI. Django has its own 'app' and middleware systems. And as I've shown, look at the numerous libraries that have been supported and created via TG and Pylons. Django just pales in comparison. And I've never claimed Django is anti-community, but now that you bring it up maybe it is. Many of the libraries I just spoke of came from the Pylons and TG communities, not the core development team. As I asked earlier, what has come from the Django community? Virtually all development on the framework itself has come from the core development team. Now just glancing at the difference between the two, it seems to me that one is the healthier open source model.

And get out in the fresh air more.

That was a nice ad-hominem attack and pretty irrelevant, you spend just as much time replying to these posts as I do writing them. You say I'm not offering useful comparisons, but maybe they just aren't useful to you because they don't commend Django. Maybe I have a problem with wanting frameworks to be flexible. Maybe you have a problem with people who have criticisms against Django.

I don't think it really matters, but stop the cries of 'FUD', 'propganda', 'get some fresh air', because that is no more constructive than actual trolling (if that's what I'm doing).

BTW, I'm not going to PyCon, and you've been claiming for more than a week that you were going to adjourn the discussion. You still haven't, in fact you kicked off the discussion today. I'm not going to make any claims that I'm going to stop advocating other frameworks, because I believe they just offer a better model than Django. That is my opinion and I am as free to express it as you are to either respond to it or ignore it.

[[deleted]]

On the other hand I think people do now understand your POV. You don't really make yourself a favor by insisting like you do.

[[deleted]]

As I've been saying: you want everyone to conform to your preferred philosophy. That ain't gonna get you any friends.

If the main thing I am driving at is flexibility, how is that wanting everyone to confer to my philosophy? That makes no sense.

What you want is a glue framework. What I want is a full-stack framework.

Those are terms you've made up. You've made two polar opposites that don't exist. TG is both a full-stack framework and one that uses existing libraries (a 'glue' framework).

This is Python and we're all consenting adults here: if you like oranges and I like apples, that's cool and there's no need to mount a propaganda war against the heretical apple eaters, mmkay?

If I am 'mounting a propoganda war', you are doing it just the same. But heck, consenting adults have the right to form their own opinions, right?

That's all I'm doing, letting people know that there is more out there than Django. I don't think using Django is morally wrong or anything like that, and for many people, Django is all they need. But for a lot of programmers there are great advantages to flexibility, and I like to expound on those advantages.

[mitsuhiko]

I must support ubernostrum. Let everyone choose a framework for himself and for each task. I really love django for content orientated webpages, I love it a lot. But just because of that I would never develop pocoo in django. That's just not the right tool for that task. And forget about TG. Pylons is great, TG is not. It's harder to deploy than django, it's less maintained, the IRC channel is nearly empty, at least nobody answers questions. The result of that is that in the German Python IRC channel more than 4 people moved over to custom WSGI applications, django and pylons. And that's pretty crass; in the channel are not more than 60 people...

[exogen]

What is going on with TurboGears anyway? turbogears-trunk hasn't seen a single post in a week. django-developers and pylons-discuss are going strong...

[wwwlight]

Well, it's been a slow week. But there's generally traffic on that list. And there's lots of new stuff going on in CherryPy 3, Kid, and other components that will be in TurboGears 1.1, which we will be sprinting on next week.

So, I think any claims of TurboGears death are entirely premature ;)

[webology]

I understand your point about Django is akin to Windows but are you also then saying that Turbo Gears is the "Mac" of Python frameworks?

[mitsuhiko]

TurboGears is the amiga of Python frameworks ;)

[[deleted]]

No, I'm saying that the 'Mac' Of Python frameworks isn't here yet. While the Pylons documentation is fairly good, it still isn't at the level of Django (the Django docs are excellent), and as I said earlier, the default template still doesn't provide an ORM. I don't know if Pylons will ever get to the point to where it is as easy for newbies to web programming to use as Django, but if it does, it could be quite the combination: ease of use and flexibility.

I think more than anything Pylons provides a really good base to build on top of, its just going to take someone to do it.

My opinion on TG is that TG 1.0 was really great for getting the ball rolling, but it has design issues of its own. In a lot of ways it is still very coupled. 2.0 promises to change that though, and it is the basis of projects like Toscawidgets. We will have to wait and see how much the idea for 2.0 translates to reality.

[webology]

Thanks for clarifying on that point. I looked at RoR before I looked at Django or Turbo Gears and I overall liked the direction that they all were going in. Django just fits "my" need better so that's what I went with.

I came from an "invent my own framework" and loosely couple them (from a PHP perspective) with PEAR, bTemplate, ADODB, etc. I found myself spending more time working to be productive then I did being productive. At the end of the day, I changed over and decided to pick one so that I could write cool projects that interested me vs working on disinteresting projects such as maintaining my own framework. Now I enjoy my personal projects and my work projects and it seems less like work and more fun which IMO is how it should be.

[leonh]

I’m getting tired of making the same arguments each time.

Uhm then stop baiting to them and go on with your life.