[Python-Dev] DRAFT: python-dev summary for 2006-06-16 to 2006-06-30 (original) (raw)

Steven Bethard steven.bethard at gmail.com
Thu Jul 27 01:42:58 CEST 2006

Here's the draft for the second half of June. As always, comments and corrections are greatly appreciated.

============= Announcements

Python 2.5 schedule

A number of bugs are being squashed as Python 2.5 moves towards its next release. See PEP 356_ for more details and the full schedule.

.. _PEP 356: http://www.python.org/dev/peps/pep-0356/

Contributing threads:

Checkins for betas and release candidates

Anthony Baxter announced some guidelines for checkins for the beta and release candidate releases. For all beta releases:

For all release candidates:

Approval from a release manager (Anthony or Neal) should preferably be obtained in public (e.g. the python-dev list) and should be noted in the commit message.

Contributing threads:

FishEye on the Python Subversion Repository

FishEye is once again available for the Python repository_.

.. _available for the Python repository: http://fisheye3.cenqua.com/browse/python

Contributing thread:

========= Summaries

PEP 3103: A Switch/Case Statement

After Thomas Lee provided a simple patch implementing a switch statement_ for Python, there was a massive discussion about it and how PEP 275_ should best be implemented. After much discussion, basically three camps arose:

School I was primarily concerned with the repetition of the x == in something like::

if x == ...:
   ...
elif x == ...:
   ...
elif x == ...:
   ...
else:
   ...

School II seemed to feel that just aiding DRY was not enough to introduce a new construct, and that the switch statement should also be able to avoid the function definitions in dispatching code like::

def f(...):
    ...
def g(...):
    ...
def h(...):
    ...
dispatch_dict = {x:f, y:g, z:h}
dispatch_dict[value](*args)

In order to optimize this kind of code, School II wanted to be able to compute the dispatch dict ahead of time, so that it wouldn't have be recomputed each time the switch statement was executed. There was a lot of discussion as to exactly when this freezing should occur, with some voting for module compilation time (allowing only constants in the cases), some voting for function definition time (allowing only constants and non-local names in the cases) and some voting for the first time the switch statement is executed (allowing only constants and both local and non-local names). Guido put together a thorough summary of the options in PEP 3103_.

There was some discussion of introducing a static keyword which would cause an expression to be evaluated at function definition time, so that, for example, the following code would create a list of functions returning each of 0, 1, ... 9::

funcs = [lambda: (static i) for i in xrange(10)]

The intention was that switch statement cases would then allow only constants or static expressions. Guido requested a separate PEP on the idea, and Fredrik Lundh posted a proto-PEP_, but at the time of this summary, no official PEP had been submitted.

In the end, it looked like Guido was leaning towards the switch statement as syntactic sugar for a dispatching dict, with the dict frozen at function definition time (which would mean compile-time for module-level switch statements). However, the introduction of the statement seemed likely to be postponed at least until Python 3.0.

.. _simple patch implementing a switch statement: http://bugs.python.org/1504199 .. _PEP 275: http://www.python.org/dev/peps/pep-0275/ .. _PEP 3103: http://www.python.org/dev/peps/pep-3103/ .. _Fredrik Lundh posted a proto-PEP: http://online.effbot.org/2006_06_01_archive.htm#pep-static

Contributing threads:

Restricted execution in Python

For his Ph.D. thesis, Brett Cannon is looking into adding facilities for restricted execution to Python, partly with the goal of getting Python into Firefox alongside Javascript. His restricted execution specifications aimed to take advantage of the C-to-Python language barrier to enforce security restrictions. Though there's no real way to get private attributes in pure Python, objects coded in C and exposed to Python can select which attributes are exposed, thus making the non-exposed attributes truly private to Python-level code.

His initial draft aimed to hide as many "dangerous" objects as possible, and then cripple objects like file that would be difficult to hide. A number of people seemed to prefer a hiding-only approach, but comments from Armin Rigo seemed to suggest that plugging all the introspection holes that give access to file objects might be quite difficult.

The discussion continued on into the next fortnight.

Contributing threads:

NaN and infinities in Python float calculations

Nick Maclaren asked about trying to get more platform-independent behavior in Python's floats, so that IEEE 754 values as in PEP 754_ would be produced more consistently. Currently, different OSes produce different results when these values are involved::

Python 2.4.2 (#1, May  2 2006, 08:28:01)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "NaN"
>>> b = float(a)
>>> c = int(b)
>>> d = (b == b)
>>> print a, b, c, d
NaN nan 0 False

Python 2.3.3 (#1, Feb 18 2004, 11:58:04)
[GCC 2.8.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "NaN"
>>> b = float(a)
>>> c = int(b)
>>> d = (b == b)
>>> print a, b, c, d
NaN NaN 0 True

Nick Maclaren suggested either raising an exception for all ambiguous or invalid operations, or returning NaN or infinity as appropriate and then raising exceptions whenever an operation that would lose the error indication was performed. Nick Coghlan explained that the decimal module already does most of this::

>>> from decimal import Decimal as d
>>> nan = d('NaN')
>>> int(nan)
Traceback (most recent call last):
  ...
decimal.InvalidOperation
>>>
>>> from decimal import getcontext, Overflow
>>> ctx = getcontext()
>>> ctx.traps[Overflow] = False
>>> d('1e999999999') * 10
Decimal("Infinity")

Nick Maclaren seemed to suggest that he would be working on a PEP and an implementation that would bring some of the decimal module consistencies to Python's floats as well.

.. _PEP 754: http://www.python.org/dev/peps/pep-0754/

Contributing threads:

ImportWarnings for directories without init

Ralf W. Grosse-Kunstleve complained that with Python 2.5 he started getting tons of "ImportWarning: Not importing directory" messages. James Y Knight pointed out that running Python in your home directory is quite likely to issue such warnings if you have any directories in your home directory that have the same name as a python module (e.g. readline). A number of options for silencing the errors were discussed, including invoking Python like python -W'ignore:Not importing directory' and including warnings.filterwarnings('ignore', 'Not importing directory', ImportWarning) in site.py or .pythonrc.py. Two patches were provided that introduce the warning only if the import fails, one by Shane Hathaway_ and one by Sergey A. Lipnevich_. No final decision had been made at the time of this summary.

.. _one by Shane Hathaway: http://bugs.python.org/1515361 .. _one by Sergey A. Lipnevich: http://bugs.python.org/1515609

Contributing threads:

Updating turtle.py

Gregor Lingl proposed replacing turtle.py in the Python standard library with his new xturtle.py module_. The xturtle module is backwards compatible with the turtle module and adds a number of enhancements. However, Gregor's request came after Python 2.5's feature freeze, so he was told to propose it again in Python 2.6. There was some discussion about this -- as the stdlib turtle module is poorly tested, some contended that introducing the new APIs of xturtle would not make things any worse. A couple of compromises were offered: mentioning xturtle in the turtle module docs, and putting xturtle in the Tools directory.

.. _new xturtle.py module: http://ada.rg16.asn-wien.ac.at/~python/xturtle/

Contributing threads:

Relative imports and PEP 338: Executing Modules as Scripts

Relative imports, as described in PEP 328, introduced problems for PEP 338 which allows modules within packages and zipfiles to be run with the -m command-line switch. The -m switch sets the name of the module to 'main' so that if __name__ == '__main__' blocks will get executed. However, relative imports use name to determine the parent package, so if a module that has a relative import is executed using the -m switch, the relative import will fail. Nick Coghlan suggested adding a module_name attribute that would not be clobbered by the -m switch, but people generally seemed to think that it would be simpler to just require absolute imports in main modules.

.. _PEP 328: http://www.python.org/dev/peps/pep-0328/ .. _PEP 338: http://www.python.org/dev/peps/pep-0338/

Contributing threads:

Importing modules within unicode directories

Kristján V. Jónsson pointed out that currently, Python on Windows cannot import modules from directories with unicode names, even if the module names themselves are plain ASCII. Nick Coghlan suggested that this was likely because import.c was doing something like u'c:/tmp/\u814c'.encode('mbcs'), getting back 'c:/tmp/?' and being unable to do anything useful with that. Martin v. Löwis suggested using the 8.3 simplified filename used by DOS, at least until the import machinery gets reworked to better handle encodings, hopefully for Python 2.6. Thomas Heller had provided a patch_ for reworking import.c in this manner a while back, but it was large enough that no one had reviewed it.

.. _Thomas Heller had provided a patch: http://bugs.python.org/1093253

Contributing thread:

MS VC++ 2003 toolkit no longer available

Bill Janssen pointed out that Python 2.4 on Windows expects to be compiled with the MS Visual C++ compiler version 7.1, and that the corresponding MS VC++ 2003 toolkit is no longer available. Fredrik Lundh explained that the compiler is still available in the .net SDK as well as being available to MSDN subscribers. There was again some discussion about moving to the VS 2005 toolkit for compiling Python. It would have made compiling for 64bit architectures somewhat easier, but would have meant that extension writers would have to install three different compilers just to compile extensions for Python 2.3, 2.4 and 2.5, and would also have given problems for MinGW users as MinGW does not yet easily support linking to the msvcr80 runtime library.

Contributing threads:

Keeping interned strings in a set

Alexander Belopolsky tried out the new set C API by replacing the dict of interned strings with a set_ instead. He had to make two changes to get this to work: there's currently no way to retrieve a single object from a set, and Py_Finalize() needed to be changed to finalize sets after strings (instead of the other way around as it used to be). There was some discussion about trying to get rid of PySet_Fini() so the latter problem wouldn't be an issue at all, but with all the other Py*Fini() functions already existing, it didn't seem worth it.

The patch had no slowdown and reduced the memory consumption of the interning structure slightly.

.. _replacing the dict of interned strings with a set: http://bugs.python.org/1507011

Contributing threads:

Allowing empty subscripts

Guido finally vetoed the proposal to allow x[()] to be written as x[]. The use-cases were weak, and in most cases the functionality seemed better expressed as attribute access.

Contributing threads:

Creating range objects at the C level

Ralf W. Grosse-Kunstleve asked about the removal of the C function PyRange_New() which had been deprecated in Python 2.4. The right way to create ranges is to call PyRange_Type with the appropriate parameters, e.g. something like PyObject_CallFunction((PyObject*) &PyRange_Type, "lll", start, stop, step). Ralf was nervous about this alternative because it also appeared to be undocumented, and requested that something like the above be at least put into the What's New document.

Contributing threads:

type(), class and isinstance()

Martin Maly pointed out that you can't fool isinstance() into thinking your object is not a subclass of its true base class::

>>> class C(object):
...     pass
...
>>> class D(object):
...     __class__ = property(lambda self: C)
...
>>> isinstance(D(), D)
True
>>> isinstance(D(), C)
True

Phillip J. Eby explained that isinstance() checks both the type() of the object and the class attribute. In essence, you can lie about your class to make isinstance() return True, but you can't lie to make it return False. Guido suggested that these issues, as well as lying about an object's bases, should be revisited for Python 3000.

Contributing thread:

Requiring backward compatibility in the standard library modules

Ka-Ping Yee's uuid module, newly added for Python 2.5, contained a comment "This module works with Python 2.3 or higher". George Yoshida asked if that comment should be interpreted as requiring Python 2.3 compatibility. People generally felt like the list of backwards compatible modules in PEP 291_ should be as small as possible so as to keep maintenance as simple as possible. Ka-Ping removed the comment, and submitted the module to PyPI for Python 2.3 and 2.4 users.

.. _PEP 291: http://www.python.org/dev/peps/pep-0291/

Contributing thread:

Figleaf code coverage

Titus Brown offered some reports_ from his figleaf code coverage_ utility. People seemed particularly interested in trying to get coverage across multiple platforms, perhaps using a BuildBot extension, and Titus said he'd try to look into it. Walter Dörwald also pointed to his own code coverage module_.

.. _Titus Brown offered some reports: http://vallista.idyll.org/~t/temp/python2.4-svn/ .. _figleaf code coverage: http://darcs.idyll.org/~t/projects/figleaf-latest.tar.gz .. _his own code coverage module: http://styx.livinglogic.de/~walter/python/coverage/PythonCodeCoverage.py

Contributing threads:

Improving error messages

Georg Brandl proposed going through abstract.c and modifying error messages like "object does not support item assignment" to also include the type of the object. He got little feedback, mainly because everyone seemed to think it was such an obviously good idea that there was no need for any. Python 2.5 now incorporates Georg's better error messages_.

.. _Georg's better error messages: http://bugs.python.org/1507676

Contributing threads:

Allowing assignments in global statements

Talin proposed allowing a global statement to be combined with an assignment statement, e.g.::

global badger = 42

Guido suggested that such a desire was a sure indicator of overuse of global.

Contributing thread:

Splitting Python tests from CPython tests

Frank Wierzbicki volunteered some time into splitting out CPython specific test from Python-the-language tests. Armin Rigo pointed him to PyPy's tests modified to be more implementation independent_.

.. _tests modified to be more implementation independent: http://codespeak.net/svn/pypy/dist/lib-python/modified-2.4.1/test

Contributing thread:

A multi-dimensional array type for Python

For Google's Summer of Code, Karol Langner will be working on implementing a basic multi-dimensional array type for Python core, based on the numpy_ array struct. He asked for any comments or suggestions that people had for the project.

.. _Google's Summer of Code: http://code.google.com/summerofcode.html .. _numpy: http://www.numpy.org/ .. _implementing a basic multi-dimensional array type: http://scipy.org/BaseArray

Contributing thread:

================== Previous Summaries

=============== Skipped Threads

More information about the Python-Dev mailing list