And now for something completely Pythonic...

Werkzeug 0.1

written by Georg, on Sunday, December 9, 2007 21:54.

If you're not a friend of large web frameworks but prefer to use small agile libraries to roll your own, Werkzeug may be the WSGI adapter of choice for you. Armin just released version 0.1, and here is the feature list:
  • Provides Request and Response objects for WSGI
  • Handles file uploads by using temporary files for incoming data.
  • Provides a middleware for static data for development purposes
  • Tiny wrapper around wsgiref for easier development (autoreload, optional
    multithreaded enviornment)
  • Unicode aware data processing. Just use unicode everywhere, werkzeug
    handles that for you.
  • Mini template engine. Sometimes string formattings just are not enough
    and real template engines are too big for that tiny task.
  • Context locals. Don’t pass request/user/database connections and
    other objects around. Put them on a global context local object and
    werkzeug makes sure that everyting is cleaned up end delivered well.
  • Test utilities. Create fake WSGI environments and requests to test
    your application.
  • Interactive debugger. Application dies with an error? Hook the debugger
    in and inspect every frame.
More at his blog.

Python 3.0a2, new tasks in GHOP

written by Georg, on Friday, December 7, 2007 20:01.

Two updates:

  1. Guido just released Python 3.0 alpha 2, to be downloaded at the usual locations -- get it and check it out! There was quite a lot of work behind the scenes, and lots of bugs have been fixed. The core changes are now almost done, next step is the library.

  2. Titus has added 100 new tasks to Python's GHOP tracker! Considering the speed with which the students claimed and completed the first 60-something tasks, let's see if they last until Monday ;)

    (Ah yes, and there is a video with Guido on Google Code's blog!)

GHOP coming along nicely

written by Georg, on Saturday, December 1, 2007 23:21.

The Google contest for pre-college students is now running for a few days, and we (the PSF) have had already quite a lot of response.

Of our initial 60-something tasks, we've only 45 left open, and only 8 are unclaimed so far. That means that we're running out of tasks!

You saw it coming, didn't you? Because this is your chance to get involved. Everyone can suggest tasks (see the wiki page on how exactly) and help out as a mentor, reviewing submissions and answering questions from students.

If you have some time and ideas, join and help making this a success for both Python and the students!

Announcement: the Google Highly Open Participation Contest

written by Georg, on Wednesday, November 28, 2007 16:31.

logo

The Highly Open Participation Contest is part of a new Google Open Source program, an effort to bring together pre-college students and open-source development. The contestants are completing various tasks (that will be a contribution to the respective project) and for that can get prizes and rewards from Google.

The PSF has been invited to this — you can read the official announcement of the PSF's involvement over on the Python Software Foundation blog (in a bit), or read about the overall Google Highly Open Participation Contest at the official announcement. Python's GHOP project page is here.

I've been involved in it for a couple of weeks, mainly contributing tasks (in the docs area, no surprise there), and now I'll serve as a mentor for whoever is audacious enough to tackle a task ;-)

That said, if you look at the list of tasks and think you know another one in the same spirit, let us know!

I'm really looking forward to the results and hope that both students and Python can benefit from Google's engagement.

Pygments 0.9 "Herbstzeitlose" released

written by Georg, on Sunday, October 14, 2007 20:49.

I've just uploaded the Pygments 0.9 packages to CheeseShop. Highlights in this release are:
  • Lexers added:
    • Erlang
    • ActionScript
    • Literate Haskell
    • Common Lisp
    • Various assembly languages
    • Gettext catalogs
    • Squid configuration
    • Debian control files
    • MySQL-style SQL
    • MOOCode
  • Lexers improved:
    • Greatly improved the Haskell and OCaml lexers.
    • Improved the Bash lexer's handling of nested constructs.
    • The C# and Java lexers exhibited abysmal performance with some input code; this should now be fixed.
    • The IRC logs lexer is now able to colorize weechat logs too.
    • The Lua lexer now recognizes multi-line comments.
    • Fixed bugs in the D and MiniD lexer.
  • The encoding handling of the command line mode (pygmentize) was enhanced. You shouldn't get UnicodeErrors from it anymore if you don't give an encoding option.
  • Added a -P option to the command line mode which can be used to give options whose values contain commas or equals signs.
  • Added 256-color terminal formatter.
  • Added an experimental SVG formatter.
  • Added the lineanchors option to the HTML formatter, thanks to Ian Charnas for the idea.
  • Gave the line numbers table a CSS class in the HTML formatter.
  • Added a Vim 7-like style.
I want to express my gratitude to all contributors who helped to build this impressive feature list for 0.9. Thanks!

Bytes are not just numbers

written by Georg, on Saturday, October 13, 2007 15:56.

In this comment, mathrick said that bytes are "not characters, they are numbers, uppercasing them makes no sense".

Guido does not mention in PEP 3137 why the upper(), lower() etc. methods are added back to the Python 3 bytes and buffer types.

The way I see it is that bytes are integers, but not just integers: each integer in the 0-127 range has a fixed character attached to it, which is also why you can construct a bytes object with b"ABC", with only printable ASCII characters allowed in the literal. So it actually makes sense for me to provide operations on these characters, as well as it makes sense not to use the locale for them.

On a related note, there were suggestions for another new literal, a character literal: c"A" would mean the same as ord("A"), so that you could do something like bytesobj[i] == c"A".

String types in Python 3

written by Georg, on Monday, October 8, 2007 19:30.

For a while, there were only two string-like types planned for Python 3, and the Alpha 1 shipped with them:
  • str, which is an immutable string of Unicode characters (what was unicode in Python 2)
  • bytes, which is a mutable array of bytes (a sequence whose items are integers), with no equivalent in Python 2
These two would not be as interchangeable as str and unicode were in Python 2: comparison between these two would raise TypeError, and bytes would have much less methods than the old str type had.

However, several issues arised with having only a mutable bytes array:
  • The new b"..." literal would produce a mutable object, in contrast to the other "..."-type literals.
  • Bytes objects couldn't be used as dictionary keys because of mutability - you'd have to decode them to some Unicode string first which doesn't make sense in many places.
  • How to represent code - Python bytecode is, well, bytes, but having mutable bytecode arrays attachted to code objects is questionable from a security standpoint.
Therefore, summarizing the discussion and his thoughts about the matter, Guido wrote PEP 3137, which will be implemented before Alpha 2 is released. It features these changes:
  • Now we have three string types: str, unchanged as immutable Unicode string, bytes, almost completely the same as the Python 2 str, with b"..." literals yielding bytes, and buffer, renamed from Alpha 1's bytes.
  • Bytes and buffer objects regain the old string methods bytes lost, e.g. upper().
  • Comparison between str and bytes/buffer always yields False, bytes and buffer can be compared.
  • However, indexing bytes and buffer will still give an integer.
  • The old, underused buffer function will be gone, the new "buffer interface" has a new memoryview function instead.
That way, porting from Python 2 is quite easy, provided you have already used unicode and str where they belong: change u"..." literals to "..." and "..." literals to b"...". Look at cases where you could use a mutable byte string and use buffer there.

A venture into functional programming

written by Georg, on Monday, October 8, 2007 18:39.

I've recently decided to take a time-out from Python development and immerse myself in the group of languages that's usually called "functional programming languages"; they had always sounded very interesting (because different) to me, but I couldn't muster the time and will to look at them in depth.

I decided to skip Lisp, having encountered some Emacs Lisp code in the past, looked at OCaml and Erlang and finally stuck with Haskell. Why? I think it was because Haskell is the most "different" of all those languages, and I wanted to learn something as "different" as possible.

(If you already know Haskell, you can skip the following explanations.)


What makes it "different"? Among the fundamental design decisions that make Haskell pretty unique (among the more or less well-known languages) are purity and laziness. Let me explain these terms a bit (I hope I do them justice):
  • Purity means that a function calculates its return value only from its arguments - it cannot have side effects, such as writing to global memory or printing to the screen. (Nevertheless, I/O is of course possible, and it does not violate this principle. How? See below.)
  • Laziness means that calculations are not done until their result is really needed. It is similar to generators producing the next item on request only, but ingrained in every part of the language. For example, laziness makes it possible to work with infinite lists. There is no map vs. imap distinction, the normal map is already lazy enough not to produce lists that are never needed.
Despite the limitation that purity seems to pose on code, one is able to write quite formidable programs in Haskell, for a not-so-small part with the help of monads.

(Having uttered that magic word now, let me tell you that Simon Peyton Jones, one of Haskell's fathers, once said that the biggest mistake made in the introduction of monads into the language was to call them by such a scary name and not, for example, "warm fuzzy thing".)

Monads may come from "the most abstract branch of mathematics called category theory" but are, in real life, a way to build "computations" and stick them together in a specific way, so that the dull, repeated boilerplate code needed to stick them together is hidden by the monad. I won't say much more on them (yet - they say one of the duties of a new Haskell programmer is to write Another Monad Tutorial).

Monads allow you to do I/O purely, to have mutable state, to parse text, to write nondeterministic functions easily or, for a more advanced example, to use Software Transactional Memory to manage concurrent threads.

More stuff that makes Haskell fun(ctional):
  • The whole functional paradigma, meaning functions passed around everywhere, partial application made easy, recursion etc.
  • The type system. It's based on Hindley-Milner, enriched with ad-hoc polymorphism facilities of type classes (think function overloading based on arguments as well as the return type), and allows type inference of the whole program. Static typing done right!
  • The nice mathematical-notation-like syntax, and the whitespace-based grouping.
  • The well-designed module system, including import statements!
In other words, you should try it out! It takes a while getting used to, especially if you have, like me, never really done functional programming (except what Python offers), but it is fun to write. More than once, I've had the feeling that Haskell and Python share a similar spirit of expression - to exaggerate, you write down pseudo-code, and it's executable already.

After the first few steps (which included a primitive unpickler and such things), I ported a Python library to Haskell, namely CleverCSS, which is a preprocessor for CSS with variables and nesting enabling DRY, and after fighting with the Parsec parser generator a bit, it was a really pleasant exercise with lots of stuff learned.

I also have to note that while the Python implementation had 1072 lines of code, the functional equivalent Haskell one is down at 760. You can look at the code in the repository or the documentation (it's also on Hackage, the Haskell package repository under the name clevercss).

Excellent sources for taking a more in-depth look at Haskell are:
There is also a very nice, friendly and always-helpful IRC channel #haskell on Freenode.

Python 3.0 alpha 1 released!

written by Georg, on Friday, August 31, 2007 16:29.

Today, Guido himself released the first alpha of Python 3.0, now available for download at http://www.python.org/download/releases/3.0/.

Get it, test it, port your code (see http://svn.python.org/view/sandbox/trunk/2to3/) and report many, many bugs -- I want to be at 1500 by the time the final is released! :-)

reST Python Documentation live

written by Georg, on Friday, August 17, 2007 17:45.

Much has happened since my call for documentation team members.

The new docs have now taken over in the Python 2.6 and Python 3.0 branches of development, and the static HTML version can be viewed at

http://docs.python.org/dev and http://docs.python.org/dev/3.0.

The build process also has been simplified; now a simple "make html" should suffice on a sufficiently equipped system (which means, Python >= 2.5 and Make present).