Pymine is underway at last, and learning Python has been quite the experience.

Python as a language is marvelously clear and concise (although I wistfully miss the “swashbuckling” qualities of Perl) and I can well see why it is so popular in enterprise deployments; Django has in 48 hours replaced a few thousand lines of Perl with a few hundred lines of Python (and generated SQL) – although it has taken me several weeks to get to a point where I can see how they work and why they are the right thing.

So far Django has made several simple things very easy; I hope that it does not further follow the model of the GUI and “make harder things, impossible”.

All this aside, the things which have simultaneously helped me and terrified me most are the communities; I have taken to hanging out on #python and #django on the Freenode IRC network, and it’s absolutely great any time you have some dumb little question about “how do I do [foo]?”

That’s not the scary bit, though.

The scary bit is when “[foo]” falls outside the community’s expectation of “how web2.0 software works”; it’s gotten to the point now where I am using proactive ad-baculum arguments in an attempt to stave off people who reflexively tell me that what I am doing, I am doing wrong – for instance:

alecm: anyone here familiar with the Twitter REST API?

user1: alecmuffett, there are python modules that interface it

user2: yeah, python-twitter

alecm: cool; maybe I should look at them. What I am doing is implementing something similar, where a GET /foo.json returns a “foo” structure in JSON, whereas GET /foo.xml returns it in XML. I am wondering whether it is smartest to write complex URLconfs like r'/foo\.(?(xml|json))$'… or if it is wisest to break them out into separate callbacks for JSON versus XML

user3: i would use the one with format because the both view will use the sames datas so the same view seems to be more dry for me…

alecm: that’s what I am tearing myself up about; the risk of having potentially dozens of instances of ‘if format == “xml” blobs all over the place; in theory I should just have to create the data structure once and then hand it off to a custom response handler, preserving the ‘format’ option so *that* can switch and decide on the output format… but that doesn’t always work out the way i wanted… 🙂

user3: in the mean time it’s a little weird that your application need to provide both xml and json (-:

Maybe that’s a weak example since it was really short, so how about this one:

alecm: If I was writing a multi-user blog, what would most people do (in Django) to separate one user’s postings and data from another? Separate instances of the application? Separate databases? Separate tables? And what about maintenance of distinct per-user sessions with authentication?

user4: it would be typical to use a column of the post table to indicate the author

user5: why would you need any of that?

user5: in the simplest case just fkey [FOREIGN KEY – IE: CREATE A REFERENCE] from [EACH] post to [ITS] user

alecm: let’s just imagine that it’s a blog with a lot of secret stuff in it, and the ability to separate one user from another with pretty thick walls separating them, is administratively and politically desirable

user5: that’s silly talk, but okay

user5: you still only need the fkey

alecm: the fkey works so long as the number of tables is small – postings, say – but if there are postings, friends-list-tables, tag-tables, password-tables, etc, etc, then keeping track of fkeys for each record in each kind of table is a pain. That’s why I was thinking of separate databases…

user5: i really don’t see the difficulty

I could explain stuff like “not all clients are browsers and/or have JavaScript stacks“, or “sometimes separation of user data is really important” – and somewhat discourteously I sometimes mentally want to add “…and you might understand this if you had ever used a system that supported more than 200 simultaneous users” – but I refrain because the explanations tend to turn into arguments that (ultimately) achieve nothing.

Aside from that, the Python and Django communities are wonderful. I’ve had a lot of help from them.

Let’s just hope the above is not a bellwether of ultimate limitations in Django.