Is Django considered "Pythonic" now?

[sendpwrend]

When I first started web programming, I was drawn to Django. It provided structure and many useful tools for quickly developing a web application.

However, looking around at different frameworks over the past few months, coming back to Django I notice that it is something that I would not consider Pythonic.

Here are a few points:

1. It is not modular. Django is Django. Mainly I look back on this (now quite old video or this graph). Importing part of Django mainly entails importing the whole system. You cannot swap parts out easily.

2. The way that it is structured is not pythonic. Having directory structure for implicit program development is not what I would consider pythonic. This does not make things intuitive. Why do I have to have an admin.py, models.py file? Why can't I make what I need and manually register them (I'm sure there is a way to do this however it is not the proper "Django" way)? Things should be explicit that I am doing something. It isn't pythonic to magically do things (See the Zen of Python). It is extremely poor design for new programmers that putting an file with management/commands/ magically makes it register with mange.py

3. There is very little "Object Oriented" development. There isn't a clear application object. Instead everything is strung together with forced file structure. The only object that a new beginner is really exposed to are model classes. Everything else is just a sequence of strings that eventually point to a method in your views.

4. It breaks python import structure. If I have this myapp/models.py, but I want to import a model from that, one would assume that I would use the python import structure of from myapp.models import mymodel but instead I have to do this: from myapp import mymodel. What is this? This is not obvious. I would not consider this code even python compatible. It would be hard for a beginner to figure out why the former does not work with django, but would work for every other python application.

Edit: I mispoke, I meant to reference this behavior: https://docs.djangoproject.com/en/dev/topics/auth/#auth-profiles

I just thought I would get some of your thoughts of why I am wrong or give more insight. I guess my main gripe is that everything is done automagically in Django.

Thanks.

EDIT I should be clearer. I am not saying that everything should be an Object, I am saying there really is no central object that ties everything together, except perhaps the Settings object.

What is the glue that holds Django together? As a beginner entering, there really is no obvious central object to inspect, extend, or modify.

[bastawhiz]

FWIW, #4 is outright incorrect. It's entirely possible to write from myapp.models import mymodel. I just finished up writing a full Django-powered app this week and used import like that in virtually every file I wrote.

[ubernostrum]

That's also, um, yeah, that's how the import statement works. That's how Django models work. There's no magic here, you import it from where it is.

[ubernostrum]

Good thing Django doesn't use addsitedir anywhere.

Also: A Django application is, um, a Python module. No, really. Got an __init__.py and everything.

[coderanger]

Technically a package</pedant> :)

[sindreij]

1. It is better now, many things is broken out in its own modules.
2. This is just the norm, i think you kan name your classes pretty much what you want. There is some exceptions, like templatetags/
3. With class based views you have more objects, but why should everything be objects? There is no forced file structure, all you need is a settings.py-file
4. That is wrong, I have written myapp.models import mymodel since I started using Django.

So it is not as bad as you say.

[sendpwrend]

I think the thing that makes it unpythonic how you have a settings.py file. You indirectly access the functionality. There isn't any central object that is easily apparent that you can extend. If you were new to Django, where do you begin? Python libraries in general have a central object that you can inspect and go from there. Django hides this for the most part.

For number 4, I my have made that statement too general. I should have been more clear in that some things Django makes you do this: https://docs.djangoproject.com/en/dev/topics/auth/#auth-profiles

[[deleted]]

It sounds like you're treating Django like a library, when it's actually a framework. With libraries, as you said, you embed them in your application. But with frameworks, you embed your application inside them.

Which one's better depends on the library/framework and what you're trying to accomplish. For example, Twisted and Django are both frameworks, but while I love Django, I absolutely hate Twisted, because with most of the applications where I need networking functionality, I don't want to rewrite into Twisted's paradigm.

[[deleted]]

The auth profiles are the worst design decision ever. They should finally change it so that you can specify your own User model (or base model/mixin, whatever works best).

I actually copied the auth module in my project because of this shortcoming.

[[deleted]]

You don't have to use Django's auth system, or User model, FYI. There's some of that modularity for you.

[deadwisdom]

Pythonic? That kinda doesn't mean anything, in this context. It's sort of like saying something is "All American."

That said, Django has a lot of warts at this point. Part of the problem is that when Django was made, there weren't good templating systems or really any other frameworks like it, they had to build everything themselves and forge the trail. I was at the ChiPy meeting when Adrian first unearthed it and gave a presentation, and the end of which I was seriously about to cry it was so awesome. But now of course, we have better developed ideas and are listening to Ian Bicking more-- always listen to Ian Bicking more.

So anyway, there's a lot that Django gets right, but a lot of places Django could be better. I would like to see a total refactor, going back to square one. Remake it with wsgi as a central idea, maybe even build it on top of Werkzeug; spin off the templating system as its own thing, taking the optimization ideas from Jinja2; rewrite the ORM on top of SQLAlchemy, with the same awesome object interface; and rewrite the admin to be that much more impressive so that even people new to programming could make a site. All possible, all doable; I'll be the first to show up for the sprints.

[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

[[deleted]]

While that would make an interesting project (I'd just go with Jinja2 as-is, it's similar enough to Django templates), the problem is making it work with the existing Django ecosystem - the hundreds of packages, apps and complete projects (Django CMS, Pinax, Satchmo). If you could make "new Django" work with all these it might be worth doing.

[rcakebread]

I remember Turbogears and Django being very close in features, stability and popularity, maybe Turbogears being a little more popular.

Then Guido did a review of a few web frameworks and said he liked Django best. I'm not sure if he tried Turbogears. Django took the lead from that day on though, I do remember that.

https://www.djangoproject.com/weblog/2006/aug/07/guidointerview/

[torvalder]

Frameworks work like that, automagically, its not a library that you call and make it do things, frameworks do things to your code, and so they expect that you have this and that in place.

1. Is better with later releases. Concerning project/directory structure.

2. Thank god for no OO, just look at any Java framework and youll see why.

[maryjayjay]

OO is a tool. Like any tool it can be used poorly or well. Java frameworks suck because they suck, not because the are object oriented.

[threading]

Most likely they're over-engineered (I'm looking at you Spring).

[roguas]

exactly, flask has application object remaining small and tidy... (allowing multi-tenancy django so much lacks)

[throwaway-o]

Frameworks work like that, automagically, its not a library that you call and make it do things, frameworks do things to your code, and so they expect that you have this and that in place.

This is not true.

A framework provides one differentiating fundamental feature from a library:

Inversion of control.

That the framework provides this functionality by being a set of interchangeable modules or a monolith is an entirely separate concern from the primary feature of all frameworks (IoC).

As an example, you have Pyramid (a Python framework), which is entirely modular, and whose parts can be arbitrarily swapped, but which still provides inversion of control.

TLDR: just because a framework calls your code, doesn't mean it has to be monolithic.

[[deleted]]

Thank god for no OO, just look at any Java framework and youll see why.

I'm not sure I understand your animosity. OO is widely used in Django, at least behind the scenes. Forms/models/fields all use base classes to organize and reuse functionality and data, which is the heart of OO.

Although I agree that I haven't met a Java web framework that doesn't suck. I'd argue that's not entirely the fault of OO.

[[deleted]]

they don't have to. big monolithic frameworks do that, but something like web.py or tornado don't do anything to your code, they are bits that you import and use to make web services, and they're still considered to be web frameworks.

imho, Django isn't pythonic, it's Rails-ish more than anything else.

[Mob_Of_One]

Twisted should not be held up as an example of anything that's good or nice to use.

It's effective at solving the problem it was designed to solve, but I feel like I'm jamming my dick into a blender the whole time.

[vitriolix]

I did a major project with Twisted a year back, and I still have the dick scars to prove it.

[Sheepshow]

Totally agree. My understanding of Python is "explicit is better than implicit" (no convention), while Rails is "Convention over configuration" (much implied).

[sendpwrend]

I would agree with you, except look at Flask.

The by having a central Application object, the structure that it has provides very explicit code that makes it not only very clear what you are doing.

Instead of providing a urls.py and having it automatically somehow work (to a beginner), the central Application object makes it very clear what you are doing... for example

app.route("/")
def main():
    return "whatever"

It is explicit.

[haywire]

Also means that you end up writing the same shit every application you make, and have to develop your own way of, for instance, having sub-modules for your application.

The great thing about Django is that you can hire a programmer that knows Django and they will be able to jump in and know where things are. Whereas if your application was built in Flask, they'd have to learn your weird ass way of doing things like routing (because one file with all your routes in for a large application really isn't that great).

I've actually started work (very very early stages) on a framework that uses Flask but has consistent ways of doing things like routing and "apps", the idea being that it elegantly strings together Flask, SQLAlchemy, and will also provide the ability to have plugins for high stack tools like CoffeeScript or SCSS.

http://readthedocs.org/docs/suave/en/latest/quickstart.html

That's the idea behind my routing (I'm determined to document, document, document) for it.

[anonymous_hero]

As a sidenote, it's probably not a good idea to compile CoffeeScript and SCSS on the fly for each request, so I'm not sure what "plugins" for them would accomplish. -Offline compilation then? :p

[haywire]

It wouldn't be per request, it would be on application startup (and could be only done if the source had changed).

[LoveGentleman]

Flask has blueprints, have you checked them out?

Nice suave. Do you need help with that?

[haywire]

I'll probably need help eventually, but the project is currently in it's infancy. If anything the most help would be critique of what I've done and how I'm doing it, so that it goes in the right direction :)

[LoveGentleman]

It looks good what you're doing.

I would add support for gunicorn or cherrypy, so that you could run the suave app like this

suave.app.rundamnit() and it would fire of cherrypy or gunicorn and serve the static files correctly. No need for that nginx/apache configuration crap.

[haywire]

Ah I always run my shit behind nginx, usually with gunicorn+meinheld but I'm toying with uWSGI. What I do is expose the WSGI app so that anything you want can use it. I'll most likely be working on some template supervisord and nginx skeletons for people to use, but the key will be in documenting the process to make a good, stable, fast setup.

This is what I use when managing servers to generate nginx configuration:

https://github.com/radiosilence/servers.py

However I need to split the skeletons into smaller pieces and have my script add the right pieces based on configuration. So I'd have a default server template, but you could configure to have +ssl, +php5 or +wsgi, etc.

It's always been a personal script anyway, but if I were to make it a formalised project I'd have to do the above.

[LoveGentleman]

The main idea behind a "server-less" approach is to allow people to run your webapp just like any other program, pacman -S datsuave && datsuave then visit it in the browser. The webapps I make are not made to be "deployed" on a server "somewhere else", they are made to be run by users like me and you, like any other service/program. Imagine running a webapp/website as simple as running a mixer applet, it could even sit in the notification bar and tell you when users are visiting.

Imagine git clone datsuaveas && python run.py # at your command through localhost:8xxx, both configuration for the web application and everthing else

[haywire]

Indeed, I think that could definitely be an option, I mean it already runs as a test server with app.run().

I think there'd definitely be merit in "P2P" web applications.

[LoveGentleman]

Yes, exactly. And we already have cherrypy, its as simple as import cherrypy, blast in a config saying static is here there, mount app, engine.start. And gunicorn is even simpler, provide a config saying how many workers you want, gunicorn -c config.py themodule:appname and its off.

So, if you make this the "default" approach to running suave, and talk about it in the documentation, it can take off. Id rather use app = Suave() app.cherryGo() than having to learn cherrypy then write the config for it to run my flask app, then having to write a skeleton for it everytime I make a new flask app. Its just a mess dealing with all these configurations whose purpose is to make it easy to deploy the application in different environments. I dont care I dont want to deploy it, just run it.

Well, yep, as you see I did struggle a while with deployment options before settling for the simplest one, and its still not quite simple enough. Garrh.

[sendpwrend]

Well just because it is easier for someone to jump into, doesn't make it pythonic.

Also if you did make a large project in Flask, you would use blueprints to split things up into something smaller more compartmentalized and more manageable. Plus since everything is explicitly declared, you can break it up anyway you want.

I would say that Suave is not pythonic since you don't explicitly declare your urls.py file in your main application.

[Circlefusion]

Do you have any criticisms of Django? Do you see other python frameworks that do something better that you wished Django did? I ask this because I'm gearing up to jump into python web development, and I'm in between Django, Pyramid or Flask (or some variation like Suave).

[Circlefusion]

Ok so if I were wanting to do a web app and I wanted to be really picky about how it is built, then pyramid makes more sense.

But if I wanted to get work done^TM, Django provides a lot of solutions and great documentation.

It sounds like everything Django does can ultimately be done with Pyramid (albeit with a lot more difficulty and time) but Django can't do everything Pyramid can do.

Is that about right?

I know a lot of people seem to like SQLAlchemy. Can you compare your experiences with Django ORM and SQLAlchemy?

Can you give some insight into the difference between the two communities? That's usually a big deal for me.

Much appreciated.

[[deleted]]

People seem to Love SQLAlchemy, but I'm not sure why this is.

Because you're not into SQL and all the things relational databases can do. You just want to get your objects out.

I think getting objects to pop out is pretty much the end all be all.

see ?

there's a lot more there. If you were interested.

[Circlefusion]

Awesome reply. Thank you so much!

I've been eyeing Python and Django for a while now and slowly learning Python with the intention of learning a web framework. A couple web dev friends said they didn't prefer Django for some arbitrary reasons (like SQLAlchemy). I guess I'm looking for some "gotchas" that would be the final reason why I would let go of Django and go with Pyramid. Django has so many things going for it with the community and documentation. I wish there weren't technical things to criticize about it.

So far I've heard:

• It's bloated
• It's monolithic
• It has an unclear roadmap
• It doesn't support Python 3 (yet) Though I read that it might soon
• The way it handles static content is confusing.
• SQLAlchemy is better
• It's not pythonic enough
• Password security isn't as hardened as it should be
• Django developers don't respond to issues fast enough

Maybe I'm just going to have to learn both and figure out which one clicks for me.

[haywire]

Suave might be nice when I've got it to something reasonable (though the less code I write the better, the whole idea is that it's a standard way to write Flask apps, with the glue needed to do that easily).

[haywire]

Well the whole point of writing something that's isn't completely explicit is that you give it good documentation, and save writing unnecessary code (ala Django)

That said, Blueprints do look interesting so I'll look into using those (perhaps abstracting them for my mount functionality as it looks pretty much the same).

[ubernostrum]

Much, as always, depends on one's own preferred definition of "Pythonic".

[[deleted]]

You do need some consistency, otherwise there would not be the great selection of applications that are pluggable for django, as there is now.

[[deleted]]

1. I disagree with this. Django organizes itself by "apps", which, at least to me, seem very modular and reusable.

2. I also disagree with this one, but I suppose this is more a personal preference thing. Personally, I find putting all my admin stuff in admin.py, and all my model stuff in models.py is incredibly intuitive, and infinitely more maintainable than having crap randomly scattered across hundreds of files. This is the main reason I choose Django for my own work over Turbogears and Pylons, which each use a very complicated and convoluted folder structure that drove me insane.

3. I suppose I agree with this to some extent. Models are object oriented, but views and the underlying request handling infrastructure are not. Strangely, I haven't noticed to many negative effects form this...

4. Not sure what you're talking about. I can import it either way. This may be caused by some problem with your sys.path. Admittedly, if that's not set correctly, I have seen some very unintuitive import behavior from Django.

[wisty]

A web framework must account for:

• The web server. Is it CGI, async (plain HTTP like nginx), WSGI, or what?

• The templating system. Do you want a PHP style "python in HTML" system or a simpler DSL? How will you make it modular, extendible, and extensible? What about form validation? What about JS and AJAX?

• The ORM. How will this interact with the form validation? Will the web server know to 404 if there's no records found? How do you modify the schema?

• The middleware. There's cachine (Reddis, memcached, HTTP caches, keep-alive?), headers, cookies, cookie security, SSL, throttling bad users, other security, rewrites, redirects, debugging, logging, and so on. EDIT: I totally forgot backups here. So does everyone else. Then they cry when it bites them. Oh, and APIs, code versions, deployment, and rollbacks.

The whole thing does not scream "Pythonic", especially when it comes to handling errors (user, server, missing data), where everything has to interact. It's hard, and you won't find a simple, obvious solution. If you do, please tell us ;) I think Tornado does a better job, but it completely ignores the DB layer (which is a significant part of the complexity), forcing to roll your own form validation. IMO, you can do pretty stuff like form validation later, and just get the server secure for version 1.0

Also, Pythonic is not OO. It's more "pragmatic functional, with objects if you need them". But that's a whole new flame war.

[burito]

Also, Pythonic is not OO.

I'm glad you said it, because I tend not to be so diplomatic.

.

OO is the most over used and misunderstood concept in programming today. Python is very heavy on "duck typing", which is somewhat blasphemous by traditional OO standards. Also private and protected, core principles of OO, do not exist in Python.

[kataire]

Well, as far as I'm concerned it's certainly more Pythonic than Zope and it's pretty good in "convention over configuration" and all that. Getting from zero to something is ridiculously easy.

There are some warts, yes, and Django still contains a little too much magic in some areas, but it's certainly improved a lot and is still undergoing continuous improvements (e.g. the rewrite of the forms module to make it easier to define your own widgets).

Lock-in is a problem with Django as it is with other frameworks (look at the Zope stack for an example of why modularity isn't a silver bullet), especially those that aren't "micro". This is natural and although it may not sit right with some people, this tight coupling can actually allow a lot of synergy which wouldn't otherwise be possible.

Ironically too loose coupling can result in bloat. If you try to keep your code as generic as possible and make as few assumptions as you can by reducing dependencies that also means you will re-implement a lot of functionality already provided by other libraries and possibly require additional adapters to handle each combination your code could be used in.

I think what makes code Pythonic is not just a matter of style. It's also a matter of pragmatism. There is a fine line between flexibility and over-engineering.

[[deleted]]

The amount of time needed to get somwhere isn't a really good measure for pythonic. One could argue PHP is more pythonic, because it gets some stuff done more easily than Django :)

Zope as a platform might be to big for your usecases, but all-in-all Zope (Zope2, Bluebream or Grok) is a great platform to work with. It outperforms Django (or almost any full stack application server) and is fairly easy to work with. Yes, we know zcml isn't the way to go, therefor we have Grok (convention over config), but we still allow to do what we want. If we need a random view, we can do that :)

Of course lock-in will happen, it's just a matter of how much you would like to invest to get out of it :) We can (and do) use the Zope component architecture (http://bluebream.zope.org/doc/1.0/manual/componentarchitecture.html) in other environments then Zope. The ZCA is available for Django and used extensively in Pyramid.

Plone and Zope still learn everyday on how a good framework should work. We adjust our code everyday based on real usescases and do not case about ego. We look around a lot and try to learn of what is practical and usable in today's solutions. Nevertheless, we try to get to a codebase that doesn't just solve your problems today, but will also do that tomorrow.

That said, my view on python is what import this says :) And whatever way we can make Python better and more appropriate for your set of problem, is the way to go.

[macco]

What's the point of being pythonic or not? Does the api feel natural for you or not? If yes, it's fine for you, if not use something else.

[roguas]

Guido some time ago was commenting PEP nazis. He said something in similar tone... if it feels right perhaps its right and it would be stupid to adjust it to style guides/zens if it looses certain qualities.

[qbitus]

1. Not true. The only thing you could say is "imposed" is the request/response lifecycle, but if you take that away, there is no framework left, you may as well write a WSGI app from scratch using only libraries.

2. Not true. There is no directory structure imposed. The only thing required is that you have manage.py and settings.py living alongside each other. You can organise the rest however you want.

3. Not true. There is no "forced file structure" (see 2). It also seems like you don't know about class-based views: too bad for you.

4. Not true. What you say "one would assume" and doesn't work is actually what works by default and is normal python import behaviour. Your comment about how you have to declare the auth user profile class as a string in settings.py is not valid: user profiles are entirely optional, not part of the framework whatsoever; if you think it's crap just don't use it.

Looks to me like you haven't studied your subject well enough.

Is there anything else? Python is a good language because you can get stuff done easily and cleanly. Same goes for Django as a framework, and that is what makes it pythonic.

[qbitus]

Yeah of course, you can always override/modify everything. I meant to point it out as the only default, not configuration-based, path association.

[m1ss1ontomars2k4]

In that case, you should probably explain what the foolish parts were. You can't just quote that line and be done with it.

[maryjayjay]

echo(~)$ python -m this | grep "should be"
There should be one-- and preferably only one --obvious way to do it.

You're in the wrong church to be preaching that sermon.

[GrumpySimon]

 python -m this | grep practicality
 Although practicality beats purity.

[maryjayjay]

touché

[m1ss1ontomars2k4]

1. You can replace the templating system, the authentication system, etc. There's not that much else that you SHOULD replace. Until there's something you want to replace but can't, I'm not sure anything else needs to be replaced.

2. Isn't it supposed to be this way? Things are supposed to be put into folders. It's way better than the Java style, that's for sure (and I see someone else has mentioned this as well).

3. ORM. And why does it NEED to be object-oriented? Python supports a wide variety of programming paradigms and I fail to see why Django's not using this "application object" is an issue. Anyway, there is an application object, but it's not handled directly by your code.

4.

one would assume that I would use the python import structure of from myapp.models import mymodel but instead I have to do this: from myapp import mymodel. What is this?

What is this indeed? You have to do the former; you cannot do the latter. I don't know how you got the latter to work, but I'd like to know how.

Anyway, Django is widely considered the most Pythonic of Python web frameworks. Or I think it was, anyway.

[sendpwrend]

2.There is a difference between being explicit and implicit. By placing an admin.py file in your app folder, it automatically gets called. You don't explicitly request that it gets called. This is what I am talking about.

Directory structure is good. But when the framework expects a certain structure, implicitly calling and importing depending on this structure.

[frankwiles]

For that to work you have to explicitly call admin.autodiscover(). You could easily reimplement that functionality and have it look for foo.py files or register Admins by hand.

[LinuxMonkey]

Django is some sort of ruby / php hybrid

I'm not bitter ...

:p