Assume nothing when mutability is possible

Tim Peters discovered a new way to create an infinite list thanks to generator expressions. But what really came out of this whole discussion came about when someone else came up with an example that exposed a bug in list.extend().

The first thing was that "you can't assume anything about a mutable object after potentially calling back into Python." Basically you can't assume the state of any mutable object was not changed if you execute Python code from C. While it might seem handy to store state while in a loop for instance, you can't count on things not changing by the time you get control back so you just have to do it the hard way and get state all over again.

Second was that you need to be careful when dealing with iterators. If you mutate an iterator while iterating you don't have a guarantee it won't explode in your face. Unless you explicitly support it, document it, and take care to protect against it then just don't assume you can mutate an iterator while using it.

Contributing threads:

• A cute new way to get an infinite loop
• More data points

The fewer licenses the better

The idea of copying some code from OpenSSH for better pty handling was proposed. This was frowned upon since that becomes one more legal issue to keep track of. Minimizing the licenses that Python must keep track of and make sure to comply with, no matter how friendly, is a good thing.

Contributing threads:

• using openssh's pty code

Trying to deal with the exception hierarchy in a backwards-friendly way

Nick Coghlan came up with the idea of having a tuple that contained all of the exceptions you normally would not want to catch in a blanket 'except' statement; KeyboardInterrupt, MemoryError, SystemExit, etc.). This tuple was proposed to live in sys.special_exceptions with the intended usage of:

try:
  pass # stuff...
except sys.special_exceptions:
  raise # exceptions that you would not want to catch should keep propogating up the call chain
except:
  pass # if you reach here the exception should not be a *huge* deal

Obviously the best solution is to just clean up the exception hierarchy, but that breaks backwards-compatibility. But this idea seemed to lose steam.

Contributing threads:

• Proposing a sys.special_exceptions tuple

Built on beer!

by Michael Chermside

In this short thread Guido admits that Python is really built on beer: "...it's true! During the early days, when hacking on Python, I often lived on stroopwafels and beer."

Contributing threads:

• built on beer?

Docs still available in gzip format

by Michael Chermside

Fred Drake suggested that we stop providing the Python documentation in gzip format. We offered the zip and bzip2 formats which have unique advantages (bzip2 compresses better and zip has a directory built in so individual files can be extracted) over gzip and he wanted to reduce the number of different formats offered. However, there was much dissention, so the final decision was to retain the format.

Contributing threads:

• Planning to drop gzip compression for future releases.

Making running stdlib modules as scripts that much easier

Nick Coghlan contributed a patch for a new command-line option, -m, that will search sys.path for a module of that name and execute it as a __main__. This can be really handy for things such as checking the docstrings of a module (python -m pydoc heapq) and such.

Currently, though, it only for top-level modules in sys.path and thus ignores packages. If you want that functionality there is a recipe by Nick on the Python Cookbook at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/307772 . There is also discussions going on python-dev about how to possibly add this in the future.

Contributing threads:

• Running a module as a script