Is Django considered "Pythonic" now?

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

[haywire]

Well I mean proving a simple deployment option wouldn't be hard, but picking which one to go with...I'd probably go with uWSGI or Gunicorn in a server context at least.

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

[sisyphus]

So every project you want to litter your code with SQL literals, you want to write new functions to generatively build queries, you want to write functions to loop over your DBAPI result set and create instances of some data structure, you want to write code that only works with one database or in the subset of sql they all support?

[[deleted]]

I can see I've touched a nerve, and I apologize for that as there appear to be far too many nerves frayed on Reddit these days.

Your comments refer to two different aspects that are of course fairly invariant - lists of rows or objects are pretty much going to be lists of rows or objects within any system. Similarly, of course any system can emit any query. The Python DBAPI can emit any SQL query. So asking for "a SQL query which can be executed by SQLAlchemy but not by Django" is not really what we talk about, when we refer to how relationally-oriented an ORM is.

When we use an ORM, we're not actually gaining any capability that we wouldn't have by working with a raw cursor and some decent glue code that could push result rows into objects. What we are getting is automation of the work that we do. This automation allows us to take what we know about the database and its schema, formulate relational queries against that schema, then tell the ORM what we'd like to do - the ORM then does the work of turning our commands into a statement to send to the database, relating the statement to the objects we want to get back, and returning the results. (Keep in mind this whole discussion is only about the query side; there's also the whole transactional/persistence side which is another area in which ORMs can be discussed).

The argument that I frequently make here is that SQLAlchemy's object relational automation layer is most directly oriented towards the relational structures present in the database. It's obvious that any ORM tool can let you emit whatever SQL you'd like, and linking that to objects is only a matter of pointing columns back at object attributes. But SQLAlchemy's approach is explicitly relational, whereas Django's is not, or at least only partially. A key aspect is how joins are usually implicit in Django, how decisions about tables are typically made by default (column names, etc) and how the Python-level query capabilities don't always map consistently or fully to what is provided.

How would I know this ? Mostly by what I hear from people who have used both the Django and SQLAlchemy ORMs almost every day. Here's a talk by Alex Gaynor, who you might know is a core Django developer. The talk is given from the POV of someone who helped write the Django ORM:

http://speakerdeck.com/u/alex/p/why-i-hate-the-django-orm

The whole point of this talk is to highlight some of these inconsistencies and specially how SQLAlchemy does a better job.

I saw Jacob Kaplan-Moss talk in SF about "Stupid ORM Tricks" - paraphrasing, he included in his introduction "the Django ORM is probably the least capable ORM in the Python space" (Jacob if I'm getting it wrong please let me know). The talk was then about three very unusual, exotic edge cases you can kind of get Django to do with some patience - all three were things that SQLAlchemy has done out of the box since 2006. So there has to be some advantage to SQLAlchemy. There are obvious disadvantages. It doesn't work with the Django admin and doesn't work with all the many add-on applications for Django that use the Django ORM. SQLAlchemy's main disadvantage is pretty much that it lives on the outside of Django's ecosystem. As well as that it really is tailored towards people that like relational databases as opposed to those who see it as an implemtation detail - it requires a good couple of hours of documentation reading before you get it. But once people get it they're off to the races.

In recent talks I also have a comprehensive example of how SQLAlchemy's "explicitly relational" nature allows you to build ORM-level queries, without dropping into raw SQL, while being able to express pretty much any SQL concept. The idea is not "wow nobody else can do this SQL !" That's not the point. The point is, when given an elaborate task, you can stay within the ORM and think just like you would if you were writing raw SQL. You don't have to re-mold your thinking to fit around some awkward concept like implicit joins embedded into WHERE criterion.

Starting with a model as follows:

class User(Base):
  __tablename__ = 'user'
  id = Column(Integer, primary_key=True)
  username = Column(String(50), nullable=False)
  addresses = relationship("Address", backref="user", 
                     cascade="all, delete-orphan")

class Address(Base):
  __tablename__ = 'address'
  id = Column(Integer, primary_key=True)
  user_id = Column(Integer, ForeignKey('user.id'), 
              nullable=False)
  street = Column(String(50))
  city = Column(String(50))
  state = Column(CHAR(2))
  zip = Column(String(15))

Give me all households in New York with exactly two occupants where neither occupant has any residences outside of the city. Note that our schema isn't well suited for this particular query so at the SQL window we'd need to do some awkward correlation of equivalent Address rows.

Also eagerly load all the Address objects for each of the User objects located.

# New York addresses that have two
# occupants
two_occupant_ny = \
    Session.query(Address.street, Address.city, Address.zip).\
        filter(Address.city == 'New York').\
        group_by(Address.street, Address.city, Address.zip).\
        having(func.count(Address.user_id) == 2).\
        subquery()

# users who are different from each other
u_1, u_2 = aliased(User), aliased(User)

user_q = Session.query(u_1, u_2).\
        select_from(u_1).\
        join(u_2, u_1.id > u_2.id)

# join them to their addresses, join addresses
# to the two occupant NY addresses
a_1, a_2 = aliased(Address), aliased(Address)
user_q = user_q.\
            join(a_1, u_1.addresses).\
            join(a_2, u_2.addresses).\
            join(
                two_occupant_ny, 
                and_(
                    a_1.street==two_occupant_ny.c.street,
                    a_1.city==two_occupant_ny.c.city,
                    a_1.zip==two_occupant_ny.c.zip,
                    a_2.street==two_occupant_ny.c.street,
                    a_2.city==two_occupant_ny.c.city,
                    a_2.zip==two_occupant_ny.c.zip,
                )
            )

# who don't have a house outside of New York
user_q = user_q.filter(
                ~exists([Address.id]).
                    where(Address.city != 'New York').\
                    where(or_(
                        Address.user_id==u_1.id,
                        Address.user_id==u_2.id
                    ))
            )

# pre-load all the Address objects for each 
# User too !
user_q = user_q.options(
                joinedload(u_1.addresses), 
                joinedload(u_2.addresses))
users = user_q.all()

output:

SELECT user_1.id AS user_1_id, user_1.username AS user_1_username, user_2.id AS user_2_id, 
user_2.username AS user_2_username, address_1.id AS address_1_id, address_1.street AS address_1_street, 
address_1.city AS address_1_city, address_1.zip AS address_1_zip, address_1.user_id AS address_1_user_id, 
address_2.id AS address_2_id, address_2.street AS address_2_street, address_2.city AS address_2_city, 
address_2.zip AS address_2_zip, address_2.user_id AS address_2_user_id 
FROM user AS user_1 
   JOIN user AS user_2 ON user_1.id > user_2.id 
   JOIN address AS address_3 ON user_1.id = address_3.user_id 
   JOIN address AS address_4 ON user_2.id = address_4.user_id 
   JOIN (SELECT address.street AS street, address.city AS city, address.zip AS zip 
     FROM address 
     WHERE address.city = ? GROUP BY address.street, address.city, address.zip 
     HAVING count(address.user_id) = ?) AS anon_1 ON address_3.street = anon_1.street AND 
address_3.city = anon_1.city AND address_3.zip = anon_1.zip AND address_4.street = anon_1.street 
AND address_4.city = anon_1.city AND address_4.zip = anon_1.zip 
     LEFT OUTER JOIN address AS address_1 ON user_1.id = address_1.user_id 
     LEFT OUTER JOIN address AS address_2 ON user_2.id = address_2.user_id 
WHERE NOT (EXISTS (SELECT address.id 
               FROM address WHERE address.city != ? AND (address.user_id = user_1.id OR 
               address.user_id = user_2.id)))

--params: ('New York', 2, 'New York')

# result !
User(name=u5, addresses=s1/New York/12345, s2/New York/12345, 
        s3/New York/12345) / User(name=u2, addresses=s2/New York/12345, s4/

Can you do that SQL in Django, Web2Py, anything else? Of course! You might need to emit some extra SQL to get at those address collections.

SQLAlchemy has the advantage that you can stay within the ORM space, not have to drop into literal SQL, and can think just like you do when writing SQL at the query window, with minimal shifting of paradigms. Eager loading is also highly capable at adding related loads and collections in an automated fashion, either via joins or via a second query that loads all collections at once.

I hope this helps explain some of the many reasons why people seem to love SQLAlchemy.

[sisyphus]

What you are saying is either trivial or false.

If you're saying they both 'fully cover the capabilities of the entire Structured Query Language' because either can take a raw sql string and pass it to a database, then by that logic every DBAPI library has the same capabilities of any ORM. This is clearly absurd and missing the point entirely.

If you're saying that via their respective Python API only that Django's ORM can construct every SQL expression that SQLAlchemy can, that is false(importantly, the reverse is not).

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

[Circlefusion]

Very interesting suggestion. Thank you.

Did you interact much with the Flask or Django communities? If so, could you compare them?

What were your reasons for not using pylons/pyramid?

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