Movement in PEP Land

PEP 334 (Simple Coroutines via SuspendIteration) came into existence.

PEP 328 (Relative Imports) got some discussion on postponing making imports absolute instead of the relative/absolute semantics they have now. As it stands it looks like the changeover might get pushed off.

PEP 292 (Simpler String Substitutions) seems to finally be done and locked down.

PEP 335 (Overloadable Boolean Operators) came into existence.

Contributing threads:

• PEP 334 - Simple Coroutines via SuspendIteration
• PEP 328 - Relative Imports
• Re: Alternative Implementation for PEP 292:Simple String Substitutions
• ANN: PEP 335: Overloadable Boolean Operators

__str__, __unicode__, and how to have them play nicely

Did you know that __str__ methods are allowed to return Unicode objects? Well, it turns out they can, but that str() (which calls PyObject_Str()) automatically tries to convert the value returned by __str__ into ASCII. Basically __str__ shouldn't return Unicode if you can help it and you should use __unicode__ instead and reserve __str__ to return str objects only.

Contributing threads:

• unicode and __str__ (couldn't find in archives)

Backporting C APIs bad

Somebody (cough Guido cough) asked if the datetime C API could be backported to 2.3 . The argument was that the only person who would probably use it is the person who asked for it, the author of cx_Oracle.

Well, pretty much everyone spoke up against this. The argument went that adding an API would just be bad since there would suddenly be a point in the 2.3 releases where backwards compatibility was broken. People brought up the point of 2.2 where in 2.2.1 booleans were added and how that has caused compatibility headaches for some people.

In the end the API was not backported.

Contributing threads:

• Re: [Python-checkins] python/dist/src/Modules threadmodule.c, 2.56, 2.56.8.1

Got to love race conditions thanks to the filesystem and external apps

Tim Peters found a race condition one can have on Windows if you have an app that uses the low-level hooks into the filesystem. If you create a file, delete it, and then try to delete the directory the directory deletion will fail since the file is not deleted yet. What can happen is an indexing program can still be indexing the file before the filesystem is allowed to delete it and thus the directory is not truly empty when the directory deletion is executed. Fun stuff.

Contributing threads:

• Coernic Desktop Search versus shutil.rmtree

Python 2.4a3 is out the door!!!

Go to http://www.python.org/2.4/ , download it (using the bz2 version if possible so as to save on bandwidth), and run it against your code, run the test suite, put it on your head and sell yourself to an art gallery, etc.

Contributing threads:

• RELEASED Python 2.4, alpha 3

Cleaning the Exception House

The idea of reorganizing the exceptions hierarchy came up again (see http://www.python.org/dev/summary/2004-08-01_2004-08-15.html#an-exception-is-an-exception-unless-it-doesn-t-inherit-from-exception for a previous discussion on this). This time, the idea of separating the hierarchy into exceptions one would like to catch with a bare 'except' and those that you wouldn't was brought up.

The idea is that some exceptions, such as MemoryError, one does not want to catch in a blanket statement usually. Chances of recovering from that kind of exception is low and should only be caught if you know what you are doing. So tweaking the exception hierarchy so that exceptions that were not near-catastrophic could inherit from an exception class that people could catch so as to allow the proper exceptions to propagate to the top-level without issue.

Tim Peters even went as far as to suggest deprecating bare 'except' statements. This would force people to be explicit about what they want to catch, whether it be all "safe" exceptions or all exceptions.

As it stands now no officially decision has been made for Python 3000 since that is about the only place this could happen.

Contributing threads:

• Dangerous exceptions

Making decorators not look like decorators to the outside world

Raymond Hettinger pointed out that a decorator does not, by default, look like the function that it is fiddling with (if that is the intent). Since most decorators will most likely be a wrapper function some things need to be set in the wrapper in order not to mask things in the wrapped function (doc string, argument parameters, etc.).

So Raymond pointed out some things one can do. This also led to the suggestion of having a common name used to store a reference back to the wrapped function. There was also the mention that a decorator-oriented module in the stdlib will probably materialize in Python 2.5 . For now, though, stick recipes either in the Python Cookbook or in the Python wiki at http://www.python.org/cgi-bin/moinmoin/PythonDecoratorLibrary .

Contributing threads:

• decorator support