python - 20.1.2006 - 3.7.2007
httplib2.py - better HTTP library than the one in the standard library.
PyCells - calculating memory cells. Basically something like a machinery for spreadsheet calculations. Hadn't I already seen that before? Never mind. It's still interesting.
Beautiful Soup: We called him Tortoise because he taught us. - not new, but practical: an HTML parser for broken HTML. In Python. (and yes, I need to automate HTML browsing for tests right now)
twill: a simple scripting language for Web browsing - automated web browsing. I think I've mentioned it before, but never mind, things are often repeated.
PyInstaller - interesting alternative to py2exe, which can create executable files for both Windows and Linux.
Kamelia - interesting concept: component programming in Python. Components are operated in parallel via threads and communicate via a simple pipe interface. Similar to the Unix shell, but for high-level objects and within a programming language.
DjangoKit - great idea. Basically Apollo with Python - Django applications can easily be turned into real OSX applications. Could definitely become interesting.
appscript - Python as an alternative to AppleScript (hadn't I already mentioned this one?)
Python, Django and DB2: we need your input! - sounds like there will soon be a DBAPI2 module for Python and DB/2 directly from the source.
soaplib - there's something new here. Besides the rather slow SOAPpy and the, in my opinion, somewhat over-engineered ZSI, there is now another Python library for SOAP web services with soaplib. Let's take a look.
boto - a library for accessing Amazon Webservices. Supported are S3, SQS and EC2 - exactly what I need. Documentation also looks quite useful.
Jython 2.2 Beta - finally something new from Jython, the Python implementation for the Java VM. Still Python 2.2 syntax level, but at least a new release. However, the roadmap reads a bit harsh when talking about code quality ...
ModWsgi - an Apache module for WSGI applications (WSGI is a python standard for web applications).
IronPython and libsecondlife
libsecondlife is a C# reimplementation of the SecondLife protocol. IronPython is Python on .NET. They should be able to be used together. They can be. However, IronPython is not Python - most of the standard library is missing (although many of the pure-Python modules would certainly work). External libraries are also handled differently. The following makes one happy:
import clr
clr.AddReferenceToFile("libsecondlife.dll")
import libsecondlife
With this, I got everything loaded together. Maybe a start for me to play around with it.
Python for Maemo - playing with Python 2.5 on the Nokia Tablet.
[Google Pagerank Algorithm](http://kraeutler.net/vincent/essays/google page rank in python) - in Python. Interesting.
ajp-wsgi - an implementation of WSGI (the abstract Python server protocol) based on AJP (the Java Server Protocol), written entirely in C and executing Python applications via embedded Python interpreters. Could be very interesting for efficient operation of Python applications.
The Django Book - progressive Beta-Releases of the Django Book chapters on the web (with information on when the chapters go online).
Security vulnerability in Python 2.3 and above - definitely not just Ubuntu, but also Debian. Ubuntu is only linked because there is no security advisory from Debian yet. Is someone sleeping?
Introducing Django 0.95 - new Django release out. Magic removed.
WPHP - Call PHP from Python via a FastCGI server. This could, for example, integrate PHP into Django.
TLS Lite - a nice small Python-only lib for SSL, TLS and low-level X509 handling. Quite useful for quick-off projects and for larger systems it integrates with other PKI libraries for Python.
CLPython - an implementation of Python in Common Lisp - ok, that's already crazy.
Python Cheatsheet : saprfc 0.08 - another SAP-RFC module for Python.
Generic Table Relations for Django. Very interesting, this makes things like tags in data models much easier. I should be able to get rid of a lot of stuff from my Stuff-Library with this.
Automatic Pickle Serialization and Deserialization with PostgreSQL - very interesting, automatic pickle/unpickle when using PsycoPG2.
Feedjack - A Django+Python Powered Feed Aggregator (Planet) - could perhaps be used as a replacement for the rather outdated WordPress at metaowl.de?
PyCells and peak.events - Phillip J. Eby on Cells and what they mean for event-oriented programming. Particularly interesting, as one of the projects in the Google Summer of Code is a Python implementation of the Cell concept.
Django for non-programmers - Django from a web designer's perspective.
Django Weblog "magic-removal" branch merged - gaaaah. Work. Crap.
Python 3000 - Adaptation or Generic Functions?
Python 3000 - Adaptation or Generic Functions? Wow. GvR sees the light! Generic functions in Python 3000! Hell freezes over, third time ...
python-constraint - had I already seen this? Doesn't matter, there's a new link and everything is repeated on TV anyway. Constraint solver in Python. Could definitely be interesting for projects.
Merquery, Text Indexing and Search with a Focus - a full-text search engine in Python specifically for RAD frameworks? Let's see what comes out of this.
MP3 Python Module - simple lib for accessing MP3 information.
Divmod - a whole series of very interesting Python projects. Of course, also its own web framework and its own ORM, but also a few smaller, interesting things like, for example, a Bayesian Classifier.
Tail Call Optimization in Python
At the beginning of the month, I was still annoyed that GvR doesn't want tail-call optimization in Python - because he thinks that this is a feature that cannot have a simple interface. On [Lambda the Ultimate] there is also a comment on this - because logically, this statement by GvR has led to some amusement in the Lisp community. Especially cute about this: there is a solution to optimize tail calls via decorator - where Python simply fiddles around in the stack (thanks to stack introspection, this works quite well). So much for the topic of Rube Goldberg Device - the decorator is extremely compact, there is really not much complexity contained. Of course, the optimization is not really optimal - it avoids stack overflow, but uses exception handling to avoid function calls, which then affects performance a bit. But for the simple transfer of recursive algorithms, this can still be quite useful.
And why is something like this not built directly into Python as a better, more efficient solution? Python 2.5 gets conditional expressions inherited from Perl (value if condition else othervalue), but not something like a simple decorator to optimize certain function calls?
pyOpenSSL - Python interface to the OpenSSL library - quite complete bindings. Looks much better than the previous libs I have looked at.
Language Design Is Not Just Solving Puzzles
Language Design Is Not Just Solving Puzzles is a rather interesting article by Guido van Rossum about the impossibility of an elegant syntax for multi-line lambdas in Python. Worth reading, and in large parts I agree with him. However, I then stumble over such a last paragraph:
And there's the rub: there's no way to make a Rube Goldberg language feature appear simple. Features of a programming language, whether syntactic or semantic, are all part of the language's user interface. And a user interface can handle only so much complexity or it becomes unusable. This is also the reason why Python will never have continuations, and even why I'm uninterested in optimizing tail recursion. But that's for another installment.
I am quite willing to accept that continuations are complex - but not because of the interface. For the interface for continuations, you only need the callcc call to bind the continuation and a simple function syntax to trigger the continuation. The main problem with continuations lies in the cooperation with generators and exceptions - what happens when a continuation is triggered within a generator? What happens when an exception is triggered within a continuation? These are the difficult aspects - which, by the way, also make Scheme implementers sweat, which is why exceptions are not particularly popular there (the same problem, just viewed from the other direction).
So okay, no continuations in Python - even though we already have poor-man's continuations with pickable generators (or with greenlets, or with cloneable coroutines, or one of the many other approaches to obtain subsets of continuation features).
But what on earth is complex about tail-call optimization (because it's not just about tail recursion)? It is so primitive that it can be implemented transparently for the programmer - if a tail call is present, do not note a return address on the stack, but reload the parameters in the stack frame and note a simple jump. If you want to be nice, you can introduce a pseudo-function "tailcall" that throws an exception if it is not to be executed in a tail call position. There may be further conditions under which tail calls cannot be optimized - but these can also be incorporated into a corresponding check.
It is precisely the function overhead that makes some algorithms only awkwardly implementable in scripting languages. And tail-call optimization would definitely help here. Especially in situations where you have a chain of small function calls. As far as I'm concerned, it can also be an optimization that is only activated at -O (or -O2 or something else).
Django Templates are not limited
shannon -jj behrens thinks that Django template language is limited - because it doesn't have functions with parameters to do html snippet reuse. Of course the official - and simplified - answer to this is, that Djangos template language is that simple by design, so that it can easily be learned by non-programmers (as often designers aren't necessarily programmers). This is a quite good reasoning, but I think it's a bit too simplified.
So here is the longer - more complete - answer to this accusition: the Django template language isn't limited at all. Yes, I know that the "include" and "block" tags aren't parameterizable and so aren't often that useful for more complex situations (at least if you don't want to end in namespace hell due to passing some template-globals in the context).
So what should you do if you notice that your templates would need more complex code? One way would be to precompute the data in the view function and pass it on via the context to the template - that way the template has the ready data and can directly present it.
But what to do if you can't precompute, because you are using generic views? You could wrap your generic view with your own code and call the original generic view in that function with the modified context. That way you have the same benefit as above - youre templates have the data readily available. If you have many view functions that all need the same context enrichment, you can write your wrapper as a decorator - and just decorate the generic views and use those decorated functions in your urlpatterns.
But what if even wrapping isn't the answer? Shouldn't there be some way to do more complex code without all that wrapping? Sure there is! The answer are custom template tags. This might sound like a bit of overkill, but believe me, writing some template tags isn't really that hard. There is documentation on using and extending the template system in python
An even easier way to write your own tags is to use the "simple_tag" or "inclusion_tag" helpers in django.template.Library. Those functions allow to build simple tags very easily - the inclusion tag will base it's output on some template snippet, so you can see it as a template function with paramerters. A lot of usage of custom templates is in the contrib/admin stuff.
The main problem with the newer stuff in the code is, there is documentation missing for it. Hopefully that will be solved over time. But please, if the next time someone tries to tell you that the Django Template Language is to primitive, don't believe him. The Django Template Language is easy to grasp for non-programmers - but it's very extensible for Python programmers. And you extend it in the language you like - in Python.
lambda remains in Python
Let's just keep lambda - GvR gives up
Mandelbrot Set - Labix - Example source code that draws little apples with PyGame on the Nokia Tablet.
Guido van Rossum and Web Frameworks
Guido van Rossum asks about web frameworks - nothing exciting in itself. He just hasn't done anything with them before and wants to inform himself. He makes some claims that aren't quite accurate (e.g., that Django's template language is similar to PHP), but given the likely brevity of his "looking into" it, it's forgivable.
It gets funny in the comments on his post. Mountains of frameworks, all of which aren't finished. Piles of comments like "take XYZ, it's great and in the next few months it will definitely be usable" - especially often TurboGears is suggested.
Sorry, what? If I'm looking for a web framework, I don't want one that will be usable in a few months. I want one that is usable now and for which there are clear statements about its fitness right now. We really don't need any more web frameworks that won't be finished.
I don't have anything against a variety of frameworks - it makes life exciting and interesting because you never know if you've bet on the right framework - but there are certainly more than enough unfinished frameworks that are pitched by their users as if they were the best thing since sliced bread.
By the way, I use Django for exactly these reasons: the stuff has been in use for quite some time and has proven that it is suitable for large sites and high loads. It was developed from real applications and is not the byproduct of some unimportant Web2.0 thing of which I have never heard outside the TurboGears clique. It was also not cobbled together by a kid alone who thinks he's the new Einstein and believes he's the only one who knows how frameworks should be. And it's not a project that has been dead in principle for over a year because the author has long since moved on to something else. And it's only called 0.9 at the moment because API changes and cleanup work are pending in the guts (which would be appropriate for any project that has been developed for two years in live operation) - not because it's only 90% finished.
Of course, after this Artima post, everyone will look at GvR and wait to see what he chooses. And of course, all the web framework authors will jump up and down and want to make themselves noticed. And of course, every word will be analyzed and rubbed in the other's face. And a whole series of projects will make short-term quick-fix changes because they hope GvR will choose their framework. All of which is a really insane waste of time. Sometimes these kids in the OSS projects really get on my nerves.
PythonForMaemo - Python for Maemo - Using Python on the Nokia 770 Tablet (the shipping confirmation arrived today, hopefully the device will arrive soon).
twill: a simple scripting language for Web browsing - a Python scriptable Web client. Interesting for automated page requests and for specialized robots. Possibly also for testing web applications.
pyvm home - another Python implementation. Its own bytecode interpreter and a Python compiler written in Python. Sounds almost like PyPy meets Parrot - though retaining the Python bytecode.
A list of open-source HTTP proxies written in python - many of them are still active, and potentially quite interesting for mobile use (especially those based on asyncore, due to the low resource usage)
WebCleaner - a filtering HTTP proxy - absolute high-tech, that part. Asyncore, so low resources, built-in JavaScript interpreter against obfuscation and a bunch of other features. Sounds very good on paper.
Hurring.com: Code: Python: PHP Serialize implemented in Python - Deserialize PHP data in Python. Could be interesting if I want to migrate further sites from PHP to Django and, for example, access Wordpress settings.