Remember folks, the typical alternative to (A)GPL isn't a permissive license, it's proprietary source code and a proliferation of NDAs :P
— Nick Coghlan (@ncoghlan_dev) February 26, 2013
Inspired by Noufal Ibrahim's recent article on the general state of the Python community in India, I've finally written this belated report on my recent India trip :)
At the end of October, I had the good fortune to attend PyCon India 2012 in Bangalore. Sankarshan Mukhopadhyay (from Red Hat's Pune office) suggested I submit some talk proposals a few months earlier, and I was able to combine a trip to attend the conference with visits to the Red Hat offices in Bangalore and Pune. It's always good to finally get to associate IRC nicks and email addresses with people that you've actually met in person! While Sankarshan unfortunately wasn't able to make it to the conference himself, I did get to meet him when I visited Pune, and Kushal Das and Ramakrishna Reddy (also fellow Red Hatters) took great care of me while I was over there (including a weekend trip out from Pune to see the Ajanta and Ellora caves - well worth the visit, especially if you're from somewhere like Australia with no human-built structures more than a couple of hundred years old!)
While I wasn't one of the keynote speakers (David Mertz gave the Saturday keynote, and Jacob Kaplan-Moss gave an excellent "State of the Python Web" keynote on Sunday), I did give a couple of talks - one on the new features in the recent Python 3.3 release, along with a longer version of the Path Dependent Development talk that I had previously presented at PyCon AU in August. Both seemed to go over reasonably well, and people liked the way Ryan Kelly's "playitagainsam" and "playitagainsam-js" tools allowed me to embed some demonstration code directly in the HTML5 presentation for the Python 3.3 talk.
Aside from giving those two talks, this was a rather different conference for me, as I spent a lot more time in the hallway chatting with people than I have at other Python conferences. It was interesting to see quite a few folks making the assumption that because I'm a core developer, I must be an expert on all things Python, when I'm really a relative novice in many specific application areas. Fortunately, I was able to pass the many web technology related questions on to Jacob, so people were still able to get good answers to their questions, even when I couldn't supply them myself. I also got to hear about some interesting projects people are working on, such as an IVRS utility for mothers to call to find out about required and recommended vaccinations for their newborn children (I alluded to this previously in my post about my perspective on Python's future prospects).
One thing unfortunately missing from the PyCon India schedule was the target experience level for the talks, so I did end up going to a couple of talks that, while interesting and well presented introductions to the topic, didn't actually tell me anything I didn't already know. Avoiding any chance of that outcome is one of the reasons I really like attending "How we are using Python" style talks, and my favourite talk of the conference (aside from Jacob's keynote) was actually the one from Noufal Ibrahim and Anand Chitipothu on rewriting the Wayback Machine's archiving system (The other major reason I like attending such talks is that knowing I played a part, however small, in making these things possible is just plain cool).
While the volunteers involved put in a lot of effort and the conference was well attended and well worth attending, the A/V handling at the conference does still have room for improvement, as the videos linked above indicate. I've sent a few ideas to the organisers about reaching out to the PSF board for assistance and suggestions on that front. Hopefully they'll look into that a bit more for next year, as I think producing high quality talk recordings can act as excellent advertising for tech conferences in subsequent years, but doing that effectively requires a lot of preparation work both before and during the conference. There are some good resources for this now in the Python community at least in Australia and the US, so I'm hopeful that the PSF will be able to play a part in transferring that knowledge and experience to other parts of the world and we'll start seeing more and more Python conferences with recordings of a similar calibre to those from PyCon US and PyCon AU.
Since writing my Python 3 Q & A, including some thoughts on why the CPython GIL isn't likely to go away any time soon, I've been pondering the question of free-threaded cross platform virtual machines for dynamic languages. Specifically, I've been trying to think of any examples of such that are driven almost entirely by volunteer based development.
Prompted by a thread on python-ideas, I published some thoughts on understanding the behaviour of else clauses on Python's loop statements.
Apologies to RSS users, I still don't have a good setup for reproducing Sphinx content here on the blog - the real content is over on Read the Docs.
This interesting piece from Luke Plant went by on Planet Python this morning, and really helped me in understanding many of the complaints I see about Django's Class Based Views. That problem seems to be that when CBVs were introduced, they were brought in as a replacement for the earlier procedural Function Based Views, rather than as a lower level supplemental API that covered an additional set of use cases that weren't being adequately served by the previous approach (I only started using Django with 1.3, so it's taken me a while to come up to speed on this aspect of the framework's history).
The key point in Luke's article that I agree with is that deprecating FBVs in favour of CBVs and saying the latter is always the superior solution is a mistake. The part I disagree with is that saying this also means that introducing the CBV concept itself was a mistake. CBVs may have been oversold as the "one true way" to do Django views, but "There's one - and preferably only one - obvious way to do it" is not meant to apply at the level of programming paradigms. Yes, it's a design principle that's part of the Zen of Python, and it's a good philosophy to help reduce needless API complication, but when it comes to the complexities of real world programming, you need flexibility in your modelling tools, or you end up fighting the limitations of your tools instead of being able to clearly express your intent.
Procedural programming, functional programming, object-oriented programming, pipeline-based programming etc - they're all different ways to approach a problem space, and Python is deliberately designed to support all of them.
It helps to know a bit of programming history and the origins of OOP in the context of this discussion, as Django's FBVs are very similar to implementations of OOP in C and other languages with no native OOP support: you have an object (the HTTP request) and a whole lot of functions that accept that object as their first argument.
Thus, when you don't use CBVs at all, what you're really doing is bypassing Python's native OO support in favour of a truckload of what are effectively methods on request objects (just written in a procedural style). If you want to pass state around you either store it on the request, you store it in global state (which includes your cache and main datastore) or you pass it explicitly as function arguments (which means you have to daisy chain it to anyone else that needs it). If you use classes instead, then you get an additional mechanism that you can use to affect behaviour for a subset of your views. For example, I recently restricted write access to the PulpDist REST API to site admins, when it had previously been open to all logged in users. I could do that in one place and be confident it affected the entire API because every REST view in PulpDist inherits from a common base class. Since that base class now enforces the new access restrictions, the entire API obeys the rules even though I only changed one class.
Where Luke is absolutely right, though, is that switching from a procedural approach to an object-oriented one comes with a cost, mostly in the form of non-local effects and non-obvious flow control. If you look at Python's standard library, a rather common model to alleviate this problem is the idea of providing an implementation class, which you can choose to use directly, as well as a set of module level convenience functions. Much of the time, using the convenience functions is a better choice, since they're designed to be simple and clean solutions to common tasks. However, if you need to start tweaking, then being able to either instantiate or subclass the existing backend implementation directly lets you get a lot further before you have to resort to the brute force copy-paste-edit approach to code reuse.
But please, don't confuse "Django's Generic View implementation is overly complicated and FBVs should be retained as an officially blessed and supported convenience API" with "CBVs are a bad idea". Making the latter claim is really saying "OOP is a bad idea", which is not a supportable assertion (unless you want to argue with decades of CS and software engineering experience). While the weaker claim that "An OOP implementation is often best presented to the API user behind a procedural facade" is less exciting, it has the virtue of being more universally true. Procedural APIs often are simpler and generally introduce less coupling between components. The trick with exposing an OOP layer as well is that it increases the options for your users, as they can now:
Years ago (but still within the last decade) I was involved in a source control trade study for a large multi-national corporation. Management had let a non-software developer select the original "source control tool" and they had picked something that required custom scripting just to do a baseline (I wish I was kidding).
So a bunch of candidate replacements were put forward for consideration, and CVS won because it was free, thus there would be fewer arguments with management about rolling it out on a project that was already over budget and behind schedule. (The fact that Subversion wasn't considered as a candidate should give you some additional hints about the precise timing of this - Subversion 1.0 was released in February 2004. Yes, for those that are new to this game, you read that right: it is only within the last decade that the majority of the open source VCS world began to enjoy the benefits of atomic commits).
Other interesting aspects of that system included the fact that one of the developers on that project basically had to write a custom xUnit testing system from scratch in order to start putting together a decent automated test suite for the system, there was no code review tool, and you couldn't include direct links to bug tracker items in emails or anything else - you had to reference them by name or number, and people would then look those names or numbers up in the dedicated bug tracking application client.
High level design documentation, if it existed at all, was in the form of Microsoft Word documents. Low level API documentation? Yes, that would have been nice (there were some attempts to generate something vaguely readable with Doxygen but, yeah, well, C++).
Less than ten years later, though, and there are signs our industry is starting to grow up (although I expect many enterprise shops are still paying extortionate rates to the likes of IBM for the "Rational" suite of tools only to gain a significantly inferior development experience):