A first look at Python 3.0 alpha 1

The first alpha release [1] of Python 3.0 was made available for download on Friday. Python 3.0 includes syntactic and architectural changes that are incompatible with the 2.x series.

In June, we described [2] some of the preliminary plans for Python 3.0 and examined the reasoning behind a handful of the changes. Several of those features appear in this first alpha, but much work still remains. Additional alpha releases will occur throughout the rest of the year. The first beta releases are scheduled for 2008, and the final Python 3.0 release is expected to occur one year from now.

The alpha releases aren't intended for production use, and are primarily available for testing purposes. Developers can use the alphas to explore changes in the language and prepare to port their own applications. Documentation [3] is already available for Python 3.0, including a list of changes [4].

I put alpha 1 to the test and experimented with several of the new features, including the new string formatting tools and the new with and as [5] keywords.

I compiled and installed Python 3.0 alpha 1 on Ubuntu Linux 7.04. The process was relatively painless, but there was one minor unexpected problem that I encountered. When I installed the Python 3.0 alpha, it placed the Python 3.0 executable at /usr/local/bin/python, which essentially made Python 3.0 the default on my system. Since Python 3.0 isn't backwards compatible, making it the default in that manner can break other Python applications. I had to move the executable so that the python command would go back to using Python 2.5, which is located at /usr/bin/python.

Although many of the changes planned for Python 3.0 are very valuable and practical, other aspects are less impressive. I took a close look at the new string interpolation mechanisms [6] in Python 3.0, which aim to supplement the conventional % operator. Simple expressions using a specialized syntax can be included in strings and are signified with curly braces. The format method is then used to provide values to replace the braces. Inside the curly braces, one can use attribute and item selection syntax, but not normal Python expressions. The following is an example using Python 3.0 in an interactive session:

>>> class Test:
...   def __init__(self):
...     self.foo = "bar"          
...
>>> t = Test()
>>> "Testing string interpolation: {0.foo}".format(t)
'Testing string interpolation: bar'

The number 0 specifies which format parameter should be used to provide the value, and regular attribute notation is used to access the foo property. The new format method is a clear improvement over the % operator in several ways. For instance, it allows you to use the same number multiple times in an expression to refer to a single parameter. With the % operator, by comparison, you would have to use named parameters with a dict in order to use same value more than once. Another advantage of the format method is that you can seamlessly mix positional and named references:

>>> "Test 1: {spam} and another test: {0.foo}".format(t, spam="eggs")
'Test 1: eggs and another test: bar'

The new string formatting mechanism offers a lot more flexibility than the % operator. The format method can be overloaded in individual classes by defining the __format__ method, and developers can get even more control by mixing in subclasses of the formatter class.

Although the new formatting mechanism is an improvement in many ways, I still think it's suboptimal. The syntax used for the expressions is rather complex and includes a lot of confusing elements that are used for pretty-printing and spacing (for instance, <, >, and ^ are used to specify alignment). It would be far more advantageous to be able to embed normal Python syntax directly in strings, much like one can do with Ruby. My other complaint is with the redundancy in string formatting mechanisms. One of the underlying philosophies of Python is that there should be one obvious way for doing each thing. There are now three completely distinct string interpolation mechanisms with a lot of overlap: the % operator, the Template library [7] added in Python 2.4, and now the format method. This redundancy really goes against the grain of Python's philosophy.

Although I'm not entirely happy with all of the changes, I think that Python 3.0 will have a lot to offer by the time it is finished. There are many changes that increase syntactic consistency and tangibly improve the language. Other significant changes in Python 3.0 relate to unicode handling, the consistent use of iterators for sequence manipulation functions, function annotations, and new metaclass syntax. We will be looking at other features in greater depth in the future.

[1] http://www.python.org/download/releases/3.0/
[2] http://arstechnica.com/journals/linux.ars/2007/06/19/guido-van-rossum-comments-on-status-of-python-3-0
[3] http://docs.python.org/dev/3.0/
[4] http://docs.python.org/dev/3.0/whatsnew/3.0.html
[5] http://www.python.org/dev/peps/pep-0343/
[6] http://svn.python.org/projects/peps/trunk/pep-3101.txt
[7] http://docs.python.org/lib/node40.html

http://arstechnica.com/journals/linux.ars/2007/09/02/afirst-look-at-python-3-0-alpha-1

I like % better than .format, save for __format__

But this article just commented on one thing about Python 3. I'm more interested in:
- outer
- The forced unicode of strings
- Generatorization of some library functions
- print no longer a statement

>>2
I like % better than .format, save for __format__
Me too. I think this ``mini-python inside braces'' approach is completely ass-backwards. % (with dicts, if formatting large strings) is very clear and simple.

The annoying thing about % with dicts is, forget the 's' at the end and shit blows up.

Hey guys lets make python more ugly and look like perl

Several projects where flat   files definitely would   not be an   EXPERT PROGRAMMER One   day The master   and ran away   crying From that   point ie straight   down etc I   tried replacing all   instances of D   with Taylor but.

Rwanda.