[Python-Dev] DRAFT: python-dev summary for 2006-02-01 to 2006-02-15 (original) (raw)

Steven Bethard steven.bethard at gmail.com
Mon Apr 10 19:22:53 CEST 2006

Sorry about the delay folks. Here's the summary for the first half of February. I'm going to try to get the ones out for the second half of February and first half of March shortly.

Please send me any comments/corrections!

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

QOTF: Quotes of the Fortnight

We had a plethora (yes, I did just say plethora) of quotable quotes this fortnight.

Martin v. Löwis on the lambda keyword_:

I believe that usage of a keyword with the name of a Greek letter

also contributes to people considering something broken.

Raymond Hettinger on the learnability of Python_:

A language suitable for beginners should be easy to learn, but it

should not leave them permanently crippled... To misquote Einstein: The language should be as simple as possible, but no simpler.

Robert Brewer on Pythonic syntax_:

Community consensus on syntax is a pipe dream.

.. _lambda keyword: http://mail.python.org/pipermail/python-dev/2006-February/060389.html .. _learnability of Python: http://mail.python.org/pipermail/python-dev/2006-February/060420.html .. _Pythonic syntax: http://mail.python.org/pipermail/python-dev/2006-February/060556.html

[SJB]

Release plan for 2.5

PEP 356_ lists the release plan for Python 2.5. Check it out for the latest feature updates and planned release dates.

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

Contributing threads:

[SJB]

lsprof available as cProfile

Armin Rigo finished his integration of the lsprof profiler. It's now available as the cProfile module which exposes the same interface as profile.

Contributing thread:

[SJB]

ssize_t branch merged

Martin v. Löwis merged in the ssize_t branch (PEP 353_). All you folks on 64 bit machines should now be able to index sequences using your full address space. Enjoy!

.. _PEP 353: http://www.python.org/dev/peps/pep-0353/

Contributing threads:

[SJB]

========= Summaries

Rumors of lambda's death have been greatly exaggerated

Guido's finally given in -- the lambda expression will stay in Python 3.0. Of course, this didn't stave off another massively long thread discussing the issue, but Guido finally killed that by providing a pretty exhaustive list of why we should keep lambda as it is:

.. _syntactic change to lambda: http://wiki.python.org/moin/AlternateLambdaSyntax

Contributing threads:

[SJB]

The bytes type

Guido asked for an update to PEP 332_, which proposed a bytes type. This spawned a massive discussion about what the bytes type should look like and how it should interact with strings, especially in Python 3.0 when all strings would be unicode. Pretty much everyone agreed that bytes objects should be mutable sequences of ints in the range(0, 256). Guido and others were also generally against a b'...' literal for bytes, as that would confusingly suggest that bytes objects were text-like, which they wouldn't be.

There was a fair bit of haggling over the signature of the bytes constructor, but it seemed towards the end of the discussion that people were coming to an agreement on bytes(initializer [,encoding]), where initializer could be a sequence of ints or a str or unicode instance, and where encoding would be an error for a sequence of ints, ignored for a str instance, and the encoding for a unicode instance. Some people argued that the encoding argument was unnecessary as unicode objects could be encoded using their .encode() method, but Guido was concerned that, at least before Python 3.0 when .encode() would return bytes objects, the multiple copying (one for the encode, one for the bytes object creation) would require too much overhead.

The default encoding for unicode objects was also a contentious point, with people suggesting ASCII, Latin-1, and the system default encoding. Guido argued that since Python strings don't know the encoding that was used to create them, and since a programmer who typed in Latin-1 would expect Latin-1 as the encoding and a programmer who typed in UTF-8 would expect UTF-8 as the encoding, then the only sensible solution was to encode unicode objects using the system default encoding (which is pretty much always ASCII).

It seemed like an official PEP for the bytes type would be forthcoming.

.. _PEP 332: http://www.python.org/peps/pep-0332.html

Contributing threads:

[SJB]

Octal literals

Mattheww proposed removing octal literals, making 0640 a SyntaxError, and modifying functions like os.chmod to take string arguments instead, e.g. os.chmod(path, "0640"). This led to a discussion about how necessary octal literals actually are -- the only use case mentioned in the thread was os.chmod() -- and how to improve their syntax. For octal literals people seemed to prefer an 0o or 0c prefix along the lines of the 0x prefix, possibly introducing an analogous 0b as binary literal syntax at the same time. People also suggested a number of syntaxes for expressing numeric literals in any base, but these seemed like overkill for the problem at hand.

Contributing threads:

[SJB]

PEP 357: Allowing Any Object to be Used for Slicing

Travis Oliphant presented PEP 357_ to address some issues with the sequence protocol. In Python 2.4 and earlier, if you defined an integer-like type, there was no way of letting Python use instances of your type in sequence indexing. And Python couldn't just call the __int__ slot because then floats could be inappropriately used as indices, e.g. range(10)[5.7] would be 5. To solve this problem, PEP 357_ proposed adding an __index__ slot that would be called when a sequence was given a non-integer in a slice. Floats would not define __index__ because they could not be guaranteed to produce an exact integer, but exact integers like those in numpy_ could define this method and then be allowable as sequence indices.

.. _PEP 357: http://www.python.org/peps/pep-0357.html .. _numpy: http://www.numpy.org/

Contributing threads:

[SJB]

const declarations in CPython

To avoid some deprecation warnings generated by C++, Jeremy Hylton had added const to a few CPython APIs that took char* but were typically called by passing string literals. This generated compiler errors when char** variables were passed to PyArg_ParseTupleAndKeywords. Initially, people thought this could be solved by changing const char ** declarations to const char * const * declarations, but while this was fine for C++, it did not solve the problem for C. The end result was to remove the const declaration from the char ** variables, but not the char * variables.

Contributing thread:

[SJB]

asynchat and threads

Mark Edgington presented a patch adding "thread safety" to asynchat. Most people seemed to think mixing threads and asynchat was a bad idea, and the thread drifted off to talking about exracting a subset of Twisted to add to the stdlib (as a replacement for asynchat and asyncore). People seemed generally in favor of this (if the subset was reasonably small) but no one stepped forward to extract that subset.

Contributing thread:

[SJB]

Approximate equality between floating point numbers

To make floating-point math easier for newbies, Alex Martelli proposed math.areclose() which would take two floating point numbers with optional tolerances and indicate whether or not they were "equal". With a similar motivation, Smith proposed a math.nice() function which would round floating point numbers in the same way that str() does. Raymond Hettinger and others expressed concern over the stated use case and suggested that hiding floating point details would only make learning their intricacies later more difficult. A few people suggested that math.areclose() might also be useful for experienced floating-point users, but it seemed that the proposal probably didn't have enough strength to get into the stdlib.

Contributing threads:

[SJB]

Eliminating compiler warnings

Thomas Wouters noticed a few warnings on amd64, and asked if Python developers should strive to remove all warnings even if they're harmless. Tim Peters was definitely in favor of eliminating all warnings whenever possible, and so had Thomas Wouters unnecessarily (for other compilers at least) initialize a variable to silence the warning.

Contributing threads:

[SJB]

Adding syntactic support for sets

Greg Wilson asked about providing syntactic support for sets literals and set comprehensions, e.g. {1, 2, 3, 4, 5} and {z for z in x if (z % 2)}. The set comprehension suggestion was pretty quickly shot down as it wasn't deemed to be much of an improvement over a generator expression in the set constructor, e.g. set(z for z in x if (z % 2)). The question of syntactic support for set literals sparked a little more of a discussion. Some people initially suggested that syntactic support for set literals was unnecessary as the set constructor could be expanded, e.g set(1, 2, 3, 4, 5). However this proposal would not be backwards compatible as it would be unclear whether set('title') should be a set of one element or five. Others questioned whether the syntactically supported set literal should create a set() or a frozenset(). No one had a good answer for this latter question, and the rest of the thread drifted off into a miscellany of syntax suggestions.

Contributing thread:

[SJB]

FD_SETSIZE in Windows and POSIX

Revision 42253 introduced a bug in Windows sockets by assuming that FD_SETSIZE was the maximum number of distinct file descriptors a file descriptor set can hold, and checking for this. FD_SETSIZE is actually the numerical magnitude of a file descriptor (which happens to correspond to the maximum number of distinct file descriptors on POSIX systems where fdsets are just big bit vectors). A #define, Py_DONT_CHECK_FD_SETSIZE, was introduced so that the check could be skipped on windows machines.

Contributing thread:

[SJB]

Iterators and length_hint

In Python 2.4, a number of iterators had grown len methods to allow for some optimizations (like allocating enough space to create a list out of them). Guido had asked for these methods to be removed and hidden instead as an implementation detail. Originally, Raymond had used the name _length_cue, but he was convinced instead to use the name __lenght_hint__.

Contributing thread:

[SJB]

Linking with mscvrt instead of the compiler CRT

Martin v. Löwis suggested that on Windows, instead of linking Python with the CRT of the compiler used to compile Python, Python should be linked with mscvrt, the CRT that is part of the operating system. Martin hoped that this would get rid of problems where extension modules had to be compiled with the same compiler as the Python with which they were to run. Unfortunately, after further investigation, Martin had to withdraw the proposal as the platform SDK doesn't provide an import library for msvrt.dll and mscvrt is documented as being intended only for "system components".

Contributing thread:

[SJB]

Opening text and binary files in Python 3.0

Guido indicated that in Python 3.0 there should be two open() functions, one for opening text files and one for opening binary files. The .read*() methods of text files would return unicode objects, while the .read*() methods of binary files would return bytes objects. People then suggested a variety of names for these functions including:

Guido didn't like the tight coupling of data types and IO libraries present in the latter two. He also expressed a preference for using open() instead of opentext(), since it was the more common use case. Of course, modifying open() in this way would be backwards incompatible and would thus have to wait until Python 3.0.

Contributing thread:

[SJB]

Adding additional bdist_* installation types

Phillip Eby suggested adding bdist_deb, bdist_msi, and friends to the standard library in Python 2.5. People seemed generally in favor of this, though there was some discussion as to whether or not bdist_egg should also be included. The thread then trailed off into a discussion of the various installation behaviors on different platforms.

Contributing thread:

[SJB]

URL for the development documentation

Georg Brandl pointed out that while http://docs.python.org/dev/ holds the current development documentation, http://www.python.org/dev/doc/devel was still available. Fred Drake indicated that it was definitely preferable to use the automatically updated docs (http://docs.python.org/dev/) but that having them on docs.python.org seemed wrong -- docs.python.org was established so that queries could be made for the current stable documentation without old docs or development docs showing up. Fred then proposed that the current stable documentation go up at http://www.python.org/doc/current/ and the current development documentation go up at http://www.python.org/dev/doc/. Guido thought that http://docs.python.org/ could possibly disappear in the new python.org redesign_.

.. _python.org redesign: http://beta.python.org

Contributing threads:

[SJB]

PEP 355: Path - Object oriented filesystem paths

BJörn Lindqvist updated PEP 355_ which proposes adding the path module to replace some of the functions in os, shutil, etc. At Guido's request, the use of / and // operators for path concatenation was removed, and a number of redundancies brought up in the last Path PEP discussion were addressed (though some redundancies, e.g. .name and .basename() seem to still be present).

.. _PEP 355: http://www.python.org/peps/pep-0355.html

Contributing threads:

[SJB]

Rejection of PEP 351: The freeze protocol

Raymond Hettinger's strong opposition to PEP 351_, the freeze protocol, finally won out, and Guido rejected the PEP.

.. _PEP 351: http://www.python.org/peps/pep-0351.html

Contributing thread:

[SJB]

PEP 338 - Executing Modules as Scripts

Nick Coghlan updated PEP 338_ to comply with the import system of PEP 302. The updated PEP includes a run_module() function which will execute the supplied module as if it were a script (e.g. with name == "main"). Since it supports the PEP 302 import system, it properly handles modules in both packages and zip files.

.. _PEP 302: http://www.python.org/peps/pep-0302.html .. _PEP 338: http://www.python.org/peps/pep-0338.html

Contributing thread:

[SJB]

Getting sources for a particular Python release

David Abrahams wanted to get the Python-2.4.2 sources from SVN but couldn't figure out which tag to check out. The right answer for him was http://svn.python.org/projects/python/tags/r242/ and in general it seemed that the r tags corresponded to the .. release.

Contributing thread:

[SJB]

PEP for *args and **kwargs unpacking

Thomas Wouters asked if people would be interested in a PEP to generalize the use of *args and **kwargs to unpacking, e.g.:

People definitely wanted to see a PEP, as these or similar suggestions have been raised a number of times. The time-table would likely be for Python 2.6 though, so no PEP has yet been made available.

Contributing thread:

[SJB]

================ Deferred Threads

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

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

More information about the Python-Dev mailing list