% formatting to str.format converter

Recent discussions on Python-dev have revolved around transitioning the standard library to the new str.format method. One suggestion was to write a automatic converter for old format strings to new ones. I've taken on the task and written mod2format at https://code.launchpad.net/~gutworth/+junk/mod2format. You can try it out by running "python3 -m mod2format [your format strings here]".

Reivew: IronPython in action

Disclaimer: Manning Press and Michael Ford very generously sent me a free copy of the book.

One thing that always slightly annoys me when I'm reading a book about Python programming is having the first few chapters devoted to introducing the Python language. However, I'm sure experienced .NET people felt the same while scanning through the introduction chapters to .NET, which was totally new to me. (I'm also glad there was an appendix about C# syntax; I learned that C# seems to have invented a new syntax or keyword for every possible programming paradigm.) IronPython in Action seems to do a very job, overall, of catering both Python programmers tiptoeing into IronPython and .NET and C# developers finding the light of dynamic programming.

I found the web programming part of the book, especially the part on Silverlight, most interesting, since embedding Python in the browser seems like a lot more fun than writing cross-browser JavaScript. Michael Foord's Try Python (source) is a good demonstration of what can be accomplished. (Though, I wonder if PyPy's sandboxing could someday be used in the browser to do the same thing.)

I would have appreciated a chapter or section on parallel processing, since IronPython offers much better threading and concurrency primitives than CPython. Perhaps an example where IronPython can perform a task that would be impossible on other implementations of Python is in order. I want to see how .NET can make concurrency easy and pythonic.

Before reading this book, I had dismissed .NET as a non-cross-platform hunk of Javaish APIs. I see now, though, that IronPython is able to combine the beauty of Python with some of .NET's better APIs (I would still rather use PyQt for GUI programming. Windows Forms has not improved.) to make a powerful development platform.

parser-compiler branch merged

The PyPy project I have been working on over the summer, rewriting the parser and compiler, has finally been merged back to trunk (during the now-ending JIT sprint in Gothenburg, Sweden). I wrote a little summary up about it on the PyPy blog.

Python 3.1 released!

I'm happy to announce that today Python 3.1 was released. I won't dwell the new features, since those are more completely listed elsewhere. I'm quite happy with this release. A lot of work has been put into 3.x as stable as its older 2.x siblings. I would like to see a lot of libraries and applications start serious looking at the port to 3.x now. As always there's a bunch of core developers waiting to help on the python-porting mailing list.

Anyway, 3.1 is available for download in source and several binary formats on python.org.

Python 3.1 beta 1 released

I'm pleased to announce that the first beta of Python 3.1 has been released. In addition to the features found in the previous alphas, the beta has several more improvements. Most importantly, I think, is PEP 383. It defines a way for undecodable paths in file systems to be safely round tripped from Unicode strings. The repr of floats also now uses a new algorithm which determines the shortest possible value.

It is planned that this will be the only beta in order for 3.1 to make a final in late June. Please download it and try it out. This is 3.x's future, and in my opinion, much of an improvement. As always, you can submit any problems you see to bugs.python.org

unittest - now with test skipping (finally)

Yesterday, I was happy to commit a patch which added test skipping and expected failure support to the venerable unittest module. It adds a skip() method to TestCase, which marks the current test being run as skipped, as well as a set of useful decorators. Here's a short example:

import sys
import unittest

class SkippingExample(unittest.TestCase):

    @unittest.skip("testing skipping")
    def test_skip_me(self):
        self.fail("shouldn't happen")

    def test_normal(self):
        self.assertEqual(1, 1)

    @unittest.skipIf(sys.version_info < (2, 6),
                     "not supported in this veresion")
    def test_show_skip_if(self):
        # testing some things here
        pass

    @unittest.expectedFailure
    def test_expected_failure(self):
        self.fail("this should happen unfortunately")


# Yes, you can skip whole classes, too!
@unittest.skip("classing skipping")
class CompletelySkippedTest(unittest.TestCase):

    def test_not_run_at_all(self):
        self.fail("shouldn't happen")


if __name__ == "__main__":
    unittest.main()

Running it in verbose mode gives:

__main__.CompletelySkippedTest ... skipped 'classing skipping'
test_expected_failure (__main__.SkippingExample) ... expected failure
test_normal (__main__.SkippingExample) ... ok
test_show_skip_if (__main__.SkippingExample) ... ok
test_skip_me (__main__.SkippingExample) ... skipped 'testing skipping'

----------------------------------------------------------------------
Ran 5 tests in 0.010s

OK (skipped=2, expected failures=1)

I have high hopes for this and Python's regression tests. Hopefully it will simplify the ugly system of test skipping we have now. It should also help us pacify other implementations who want CPython implementation detail tests skipped.

Python 3.0.1 released

The first bugfix release, 3.0.1, of the new Python 3.x series has been released! Many embarrassing bugs have been fixed. Among other things:

• The wsgiref package has been fixed for 3.x.


• A few hideous bugs in the new IO implementation have been squashed. In addition, a few cases have been optimized. (Note that IO in 3.x is still quite a bit slower than 2.x; more on that later.)


• Unbuffered standard streams (the "-u" flag) have been restored.

This is actually a bit more than an average point release. Somehow, the builtin cmp() and __cmp__ slipped into the final release and has been removed in 3.0.1.

Our next goal is 3.1. We plan to compress our rather huge release cycle to make 3.1 between 1/2 and 1 year after 3.0. The focus of 3.1 will be stabilizing the feature set and change in 3.x. This is includes the rewrite of IO in C for speed and Brett's rewrite of import in Python.

MRO magic

Here's some more less publicized evil you can accomplish with metaclasses. Here's a simple example file: (Note that although I'm using Python 3.0, this works with all new-style class supporting versions.)

# mromagic.py
class A(object):

    def a_method(self):
        print("A")

class B(object):

    def b_method(self):
        print("B")

class MROMagicMeta(type):

    def mro(cls):
        return (cls, B, object)

class C(A, metaclass=MROMagicMeta):

    def c_method(self):
        print("C")

Now let's play with this a little:

>>> import mromagic
>>> mycls = mromagic.C()
>>> mycls
<mromagic.C object at 0x622890>
>>> mycls.c_method()
C
>>> mycls.a_method()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'C' object has no attribute 'a_method'
>>> mycls.b_method()
B
>>> type(mycls).__mro__
(<class 'mromagic.C'>, <class 'mromagic.B'>, <class 'object'>)
>>> type(mycls).__bases__
(<class 'mromagic.A'>,)

How does this work? By overriding mro() on the a metaclass we can define a custom __mro__ for our class. Python will then traverse it instead of the default implementation, which is provided by type.mro().