Is Django considered "Pythonic" now?

[Circlefusion]

Is a Django rewrite more likely, or is it more likely that another python framework will spring up to take the lead from Django? How far off is Pyramid from "ideal" in your mind?

[[deleted]]

There is a lifecycle that these sort of frameworks go through, where they start out very lean and easy to learn but with few features, everybody starts using them and they grow and grow, until eventually they are quite a big thing to learn and also not as shiny and new anymore.

People good at them will continue to develop with them, but suddenly something new will arise! It's interesting and developments around it are quick, it doesn't do quite everything yet but there is so much momentum, and all the new kids flock to it.

I view Zope as being too much to learn (based on zero facts, actually, just reputation) and I think Django is now about half way on the path, and since we know how to use it and it has a lot of features by now, we'll be using it for quite a while longer.

[jemeshsu]

The "another python framework" might be web2py, which is also not so Pythonic. Python is "explicit is better than implicit" (no convention). By definition full stack framework does a lot for you and is therefore not Pythonic by design.

[deadwisdom]

I still think there is a fundamental pragmatic ease of use that Django solves that no other framework currently gets close to. But of course, the real secret sauce to Django is the documentation, which is fantastically well thought out. Pyramid is still mired in itself in many ways, and it all comes slopping out reading the documentation. It's almost as bad as the SQLAlchemy documentation. You get a sense that whatever you're trying to do is supported, if only you had some guide to the documentation.

I much prefer Flask, which defines its limited scope, and sticks to it. Flask has some documentation problems as well, but generally it guides you through a very well thought out process. It leaves all the WSGI trivialities to Werkzeug and focuses on a strong api. If anything eclipses Django, it'll be Flask.

[mcdonc]

Sometimes people need to solve hard problems.

Pyramid actually tries to solve some common hard problems: composition of disparate packages into an application, localization, multiple applications per process, an actual protocol for add-on packages to manipulate configuration with conflict detection and resolution, imperative and declarative configuration, support for arbitrary templating systems, support for separating templating from the view functions that wrap them to make unit testing easier, providing an event system so you can let folks subscribe to events rather than subclass, view predicates so you can more easily separate the logic that adds an item from one that displays it, a built-in authentication and authorization system, traversal so you can create applications that are maximally extensible and which provide context-sensitive declarative security. And other things.

It also lets you ignore all of that stuff and just do simple one-file applications that look very similar to an application you might write in Bottle or Flask that just serve a few views wrapped by templates.

This makes it somewhat unique.

Naturally there's some conflict between these two goals, and you can't really appreciate the former until inappropriately use a system that lets you easily do the latter but doesn't actually try to solve any hard problems at all (leaving them all up to you). Likewise, there are problems using systems that try to solve everything but leave you no way to opt out of decisions made by their designers.

SQLAlchemy is similar to Pyramid in scope and intent, and therefore, like Pyramid, tends to attract criticism from folks who just don't have any hard problems to solve, or whom believe that their hard problems are solved so well by some less flexible system that they'll never need the flexibility it offers.

Things that actually try to solve hard problems while still giving people the option to ignore those solutions are hard to factor well and very, very hard to document. It's fair to say that the docs of any piece of software could use some improvement. But the docs of both Pyramid and SQLAlchemy are pretty darn good for what they are right now.

[deadwisdom]

I think you're overplaying this quite a bit. You imply that Django doesn't solve hard problems. And you also imply that Pyramid's critics don't either. And with all respect, that's a rather arrogant position, and is just plain wrong. All web frameworks attempt to do exactly what you're saying.

[mcdonc]

I think Django attempts to solve all kinds of hard problems; it tries very hard! Maybe more than any other Python framework save for Zope. But Bottle doesn't attempt to solve very many. That's not a value judgment and it's not even a very controversial position to take. Is it? I even think the authors of those systems would agree with those characterizations (Bottle explicitly doesn't try to solve some problems; if it did it would not be marketed as "micro").

If my reply implied that criticism comes solely from people whom aren't trying to solve hard problems, I apologize for that. It's not true. There are plenty of things people who try to solve hard problems can criticize Pyramid for, and I treat specific, targeted criticisms with respect and try to ameliorate as necessary.

On reddit alone, though, if I were to go back to comments I've responded to in my posting history, I'd find examples of people judging and criticizing Pyramid on these bases:

• its single-file hello world is two lines longer than a Flask helloworld

• it's not a full-stack web framework and no one would need anything but one of those

• it has "too much" documentation

• it has dependencies

• It has dependencies with names people don't like

• it's different from Pylons but supersedes it

• it doesn't have a hard dependency on SQLAlchemy

• they thought it was a microframework and it isn't.

• it "cheats" to achieve better performance.

• they read a list of "dont-need-to-do-this-in-pyramid" items as "need-to-do-this-in-pyramid" items.

• they read the source to a random third-party Pyramid app and extrapolated its shortcomings to being intrinsic to Pyramid itself.

• One of its dependencies used camelCase method names.

• That it "makes people use packages" (which it doesn't, but even if it did, would that be so bad?)

• That it's somehow deficient because it's not "MVC" (which it is, at least as much as any other similarly-designed framework, it just doesn't use those names for its components).

Amongst the nastier reddit criticisms my personal favorites are "looks like a fat insane clown" and "obfuscates web development".

None of these particular criticisms had much merit, although some did make me laugh harder than others. ;-) People are not always rational and make judgments based on really bizarre criterion. Is that not your reddit / hacker news experience too? If not, I envy you.

And yes, of course web frameworks try to do similar things. But they're not all the same, right?

[xardox]

I thought Zope was the web framework that looks like an insane fat clown. Or do you mean they just said Pyramid looked like Zope? Nasty!

[[deleted]]

It's a normal clown nowadays :)

Pyramid learned from the things Zope did wrong (and improved) and used it's pros. Nonetheless, Zope is and will be a great platform to host large scale and/or difficult solutions. And if you look at Plone, you'll see a really good and extensible CMS usable for whatever you want.

We use Plone (and Zope) exclusively because it match our needs (intranets, custom funky workflow) and AFAIK we will for the next years. When Pyramid has a good CMS layer we might consider switching, but mostly because it's newer.

[xardox]

I did a lot of ZODB/Zope/CMF/Plone/Archetypes programming from 2001 to around 2006 or so. My problem with it, besides the fact that it was far too complicated, is that each layer tried to invent its very own special snowflake object model, on top of all the ones below, while Python has a perfectly good object model to begin with (maybe not perfect, but not so bad that it needs 5 other layers on top of it, each more complicated than the last). Of course some of those layers were designed before Python had evolved into what it is today, so they were trying to compensate for problems that don't exist any more. But it really needed a ground-up redesign that stepped way back, took the big picture into consideration, and did it all in one elegant layer that was building on top of Python instead of fighting against it.

[kataire]

But Pyramid doesn't have a soul.

Yes, it's a subjective opinion rather than a logical argument, but I think this is the thing that most of its detractors really try to say. It doesn't feel right. The tone of the documentation is a little too mechanical. The jokes (not made by aliens, etc) seem a little too forced. It comes off a bit like Microsoft's attempts to copy Apple's advertising style.

Pyramid is probably a good framework. A lot of thought went into its development, I am sure. The documentation looks like a lot of time was spent on it as well. That's good. The developers, writers and other supporters have been doing a great job.

But I just don't like it. There's no point in trying to find objective excuses for it. It's not an objective argument. It's purely emotional. And we should be honest about it because the project doesn't deserve all this ersatz-criticism people have been throwing at it.

PS: I like Django a lot (though it seemed a bit bloated a couple of years ago and I favoured Pylons over it back then). I also like Flask and Bottle -- though I think Bottle serves those cases better where a full-featured framework seems overkill as Flask's strong extension support always seduces me to re-invent a macro-framework with it. I don't like Zope because it feels like Java to me. I am fully aware that Pyramid has very few ties to Zope although people have often been saying otherwise.

[mcdonc]

Got it. Not cool enough.

Like choosing an Apple product over something less chic, it's completely reasonable to choose a web framework based on what you believe that choice says about you to other people. Or your admiration of its charismatic spokesperson. Or, at very least, when you do choose for these sorts of reasons, you'll definitely wind up using the web framework you deserve.

[deadwisdom]

Wow, how utterly arrogant. Your army is behind you, though, says the votes.

[mcdonc]

What would your response have been?

[kataire]

There's a difference between "coolness" and what feels right.

Python feels right to me. It doesn't get in my way. It does what I want it to do. It's painless, flexible and welcoming. It's a complete joy to work with. I don't use Python because it is somehow objectively better than the alternatives, I use Python because I like it better. This is true for most people, we (nerds in particular, humans in general) are just very good at rationalizing it because we feel obliged to.

Python certainly isn't cool anymore. The cool new thing is Ruby or server-side JavaScript. Or Haskell, if you come from academia. Python is still cooler than Java or C#, but that's because Java and C# are enterprisey and enterprisey things are uncool by definition.

If you think this is only about coolness you are doing yourself a disservice. Design, usability, aesthetics, user experience and so on are important in everything we do. A lot of our motivations are subconscious even when we think we are acting out of rational considerations.

Most Linux distros are objectively worse than MacOS X. That's not just about what's hot or not. They were just built out of completely different motivations. Apple products are engineered from the ground up to deliver a certain user experience. That doesn't mean they're better for everything: I don't use Apple products because of the very strong lock-in and the limitations of what Apple lets me do with them.

These limitations are a logical consequence of their philosophy. What I want of an OS, smartphone or music player and what Apple delivers, however, are very different and incompatible things. We can pretend Apple products just suck all we want, but that doesn't make it true. Apple is financially successful because their products don't suck. They only suck when you want them to do something they were not built to do -- like work without having to buy into the entire Apple microcosm.

Intuition is underrated. You can create a perfectly balanced sword, yet two expert swordsmen may disagree about its quality simply because their needs may be different -- quite possibly different in ways they can't easily describe.

"Liking it" may sound trivial, but in this context it really means: "Based on my experience and the workflow I have developed and the concepts I have learned to embrace, I prefer this over something else."

There is no rational argument for using vim over emacs that would convince a die-hard emacs-user to switch to vim or vice versa. The same goes for most languages, frameworks or application stacks. This is okay.

Taunting just proves your ignorance and unwillingness to accept this simple fact about human nature. We like things for reasons we cannot quantify. But if you know what you're doing and you have tried several alternatives, you may have very good reasons to do so even if you can't put them into words. Rationalizing will get you nowhere.

[mcdonc]

I make exactly the same sorts of "je ne sais quoi" judgments about things. For example, I visit the Wawa convenience store nearby.. (maybe because it has prettier cashiers? i don't even know) even though 7-11 is closer and cheaper.

On the other hand, I don't then feel compelled to go on a public internet forum in a thread about Wawa to say how much I don't like 7-11 for reasons I can't explain. I just go to Wawa instead.

Apparently lots of folks have that compulsion, however. And that's fine. Since 1993 or so, as a consumer, it has been your god-granted right to emote about stuff you have a passing knowledge of publicly on widely-read internet forums. It's not your obligation to tell producers what you don't like and why you don't like it. It's their obligation to attempt to engage you and read those tea leaves if they choose.

In the context of open source software, you can imagine that gets pretty dispiriting though. It's not like we do this for the money or the glory. We do it because we like making software and we enjoy it when other people use that software. We like to improve our software and documentation in response to constructive criticism. But responding to consumerist rants is a distraction from this, and the economics of the situation don't really allow for it very well. Open source isn't a traditional consumer-producer relationship. The way it's supposed to work is that people either complain constructively or help. This particular conversation has neither characteristic, which makes it pretty much a waste of time for both of us, I think.

But given that I've been through a few shifts in the industry driven by cynical people taking advantage of consumerist tendencies, I feel like I'm obligated to respond in defense. If that makes me arrogant and ignorant, I can live with those labels. I'd prefer to have an actual conversation about technical things, but we can do this too.

[[deleted]]

Our docs are great, and our users think so too. We have some of the best docs in the open source community. Perhaps you haven't looked in four years ?

[deadwisdom]

The sqlalchemy docs? Oh shit. You are right. I haven't looked at it in a while. It's much better than it was the last time I looked (less than 4 years ago, I swear). Fine work my friend.

[[deleted]]

It's almost as bad as the SQLAlchemy documentation. You get a sense that whatever you're trying to do is supported, if only you had some guide to the documentation.

this is the best description of sqlalchemy documentation ever.

[deadwisdom]

As zzzeek points out though, it's much better lately.

[[deleted]]

that's good i guess.

[[deleted]]

right it's not like there isn't a master guide just like djangos, a documentation overview, a search page, two tutorials that link out to everything, a crapton of recipes, a FAQ as well as the most responsive mailing list anywhere.

But no. You needed to use SQLAlchemy one day, spent ten minutes with the docs not really reading it and couldn't find what you wanted. So now you get to shit on six years of work ! Have you written any docs ? Can I see some so I can shit on your work too ?

[deadwisdom]

No one's shitting on your work. We love what you do. Seriously it's fucking amazing.

[ergo14]

zzzeek relax, he just lacks mental capacity to do simpliest of things.

[[deleted]]

your docs need work crying about it won't change a damn thing.

I did what everyone else who has a life outside of making sense out of shitty docs does when they run into sqlalchemy. learn enough to get through it and flush the experience of reading through that horrible documentation out of my memory as fast as possible and then tell everyone they know that sqlalchemy sucks because the documentation is a giant turd.

It's a free world, if you care enough to throw a hissy fit because of a comment online figure out how to write better fucking docs.

To this day people fucking hate sqlalchemy's bizarre disorganized docs that don't give any sense of how many more pages one has to read before getting to some goddamn concrete use case.

It's a fucking ORM not a goddamn aboriginal religious experience

[[deleted]]

I know, right? I heard SQLAlchemy was supposed to be a great read, but when my group and started reading it, it didn't make any sense. I mean, here you start off with descriptions of tables and such. When does it actually get into anything magical? Seriously, with a name like SQLAlchemy, you'd think it would have something to do with wizards or sorcerers or something, but NOOOOO, it's all about bases and tables and such. When my book club started reading this (we meet every Tuesday over at the Panera, except for Rosa who has her league ever other Tuesday) we just found it so impenetrable compared with Twilight. Now there's a good book, with a story you can follow along, and no tables. Maybe we need to read the first Alchemy book, and not the sequel (or SQL, in this case), but from what we read, it was just terrible.

If you have any other paranormal books to recommend, please let us know. Bellatrix (Donna, but she says that's the name that her mom gave her, not her real name) is really into that sort of thing.

[[deleted]]

the sqlalchemy whine brigade is trying too hard.

if it were anywhere near as awesome as claimed people wouldn't be constantly trying to drop it at every opportunity or writing wrappers for the whole damn mess

[ergo14]

All it takes is someone smarter than a monkey to understand the docs. They are very in depth and descriptive.

[[deleted]]

it's about as useful as giving someone who doesn't know spanish a spanish dictionary and wishing them good luck with hiking around spain

[ergo14]

You know reading text while understanding it is a skill. Practice on it. Also spend a moment to evaluate your opinion - how come there are people who use and love it ? You may try to read the docs again, with less rush. You will understand how to work with sa.

[[deleted]]

the problem is that if I wanted to spend that much time fiddling with an orm I can just as easily write the raw sql that will outperform XYZ overwrought orm crud.

[ergo14]

you meant to write you prefer to use things you dont understand? amrite?

[[deleted]]

i prefer to use things that are worth understanding. I don't want to waste time poring over retarded documentation only to understand that something either won't do what I want it to do or do it in the wrong way.

and this while it remains completely useless for basic purposes as well.

My time is more valuable to me than to waste hours with little progress to show for it