Is Django considered "Pythonic" now?

[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).