[Python-Dev] DRAFT: python-dev Summary for 2005-10-01 to 2005-10-15

Tony Meyer tony.meyer at gmail.com
Thu Nov 17 01:36:33 CET 2005 

As you have noticed, there has been a summary delay recently.  This  
is my fault (insert your favourite thesis/work/leisure excuse here).   
Steve has generously covered my slackness by doing all of the October  
summaries himself (thanks!).  Anyway, if you have some moments to  
spare, cast your mind back to the start of October, and see if these  
reflect what happened.  Comments/corrections to tony.meyer at gmail.com  
or steven.bethard at gmail.com.  Thanks!

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

----------------------------
QOTF: Quote of the Fortnight
----------------------------

 From Phillip J. Eby:

     So, if threads are "easy" in Python compared to other langauges,  
it's *because of* the GIL, not in spite of it.

Contributing thread:

- `Pythonic concurrency <http://mail.python.org/pipermail/python-dev/ 
2005-October/057062.html>`__

[SJB]

----------------------------------------
GCC/G++ Issues on Linux: Patch available
----------------------------------------

Christoph Ludwig provided the previously `promised patch`_ to address  
some of the issues in compiling Python with GCC/G++ on Linux.  The  
patch_ keeps ELF systems like x86 / Linux from having any  
dependencies on the C++ runtime, and allows systems that require main 
() to be a C++ function to be configured appropriately.

.. _promised patch: http://www.python.org/dev/summary/ 
2005-07-01_2005-07-15.html#gcc-g-issues-on-linux
.. _patch: http://python.org/sf/1324762

Contributing thread:

- `[C++-sig] GCC version compatibility <http://mail.python.org/ 
pipermail/python-dev/2005-October/057230.html>`__

[SJB]

=========
Summaries
=========

---------------------
Concurrency in Python
---------------------

Michael Sparks spent a bit of time descibing the current state and  
future goals of the Kamaelia_ project.  Mainly, Kamaelia aims to make  
concurrency as simple and easy to use as possible.  A scheduler  
manages a set of generators that communicate with each other through  
Queues.  The long term goals include being able to farm the various  
generators off into thread or processes as needed, so that whether  
your concurrency model is cooperative, threaded or process-based,  
your code can basically look the same.

There was also continued discussion about how "easy" threads are.   
Shane Hathaway made the point that it's actually locking that's  
"insanely difficult", and approaches that simplify how much you need  
to think about locking can keep threading relatively easy -- this was  
one of the strong points of ZODB.  A fairly large camp also got  
behind the claim that threads are easy if you're limited to only  
message passing.  There were also a few comments about how Python  
makes threading easier, e.g. through the GIL (see `QOTF: Quote of the  
Fortnight`_) and through threading.threads's encapsulation of thread- 
local resources as instance attributes.

.. _Kamaelia: http://kamaelia.sourceforge.ne

Contributing threads:

- `Pythonic concurrency - cooperative MT <http://mail.python.org/ 
pipermail/python-dev/2005-October/056898.html>`__
- `Pythonic concurrency <http://mail.python.org/pipermail/python-dev/ 
2005-October/057023.html>`__

[SJB]

-------------------------------------
Organization of modules for threading
-------------------------------------

A few people took issue with the current organization of the  
threading modules into Queue, thread and threading.  Guido views  
Queue as an application of threading, so putting it in the threading  
module is inappropriate (though with a deeper package structure, it  
should definitely be a sibling).  Nick Coghlan suggested that Queue  
should be in a threadtools module (in parallel with itertools), while  
Skip proposed a hierarchy of modules with thread and lock being in  
the lowest level one, and Thread and Queue being in the highest  
level.  Aahz suggested (and Guido approved) deprecating the thread  
module and renaming it to _thread at least in Python 3.0.  It seems  
the deprecation may happen sooner though.

Contributing threads:

- `Making Queue.Queue easier to use <http://mail.python.org/pipermail/ 
python-dev/2005-October/057184.html>`__
- `Autoloading? (Making Queue.Queue easier to use) <http:// 
mail.python.org/pipermail/python-dev/2005-October/057216.html>`__
- `threadtools (was Re: Autoloading? (Making Queue.Queue easier to  
use)) <http://mail.python.org/pipermail/python-dev/2005-October/ 
057262.html>`__
- `Threading and synchronization primitives <http://mail.python.org/ 
pipermail/python-dev/2005-October/057269.html>`__

[SJB]

-------------------------
Speed of Unicode decoding
-------------------------

Tony Nelson found that decoding with a codec like mac-roman or  
iso8859-1 can take around ten times as long as decoding with utf-8.   
Walter Dˆrwald provided a patch_ that implements the mapping using a  
unicode string of length 256 where undefined characters are mapped to  
u"\ufffd".  This dropped the decode time for mac-roman to nearly the  
speed of the utf-8 decoding.  Hye-Shik Chang showed off a fastmap  
decoder with comparable performance.  In the end, Walter's patch was  
accepted.

.. patch: http://www.python.org/sf/1313939

Contributing thread:

- `Unicode charmap decoders slow <http://mail.python.org/pipermail/ 
python-dev/2005-October/056958.html>`__

[SJB]

------------------
Updates to PEP 343
------------------

Jason Orendorff proposed replacing the __enter__() and __exit__()  
methods on context managers with a simple __with__() method instead.   
While Guido was unconvinced that __enter__() and __exit__() should be  
dropped, he was convinced that context managers should have a __with__ 
() method for in parallel with the __iter__() method for iterators.   
There was some talk of special-casing the @contextmanager decorator  
on the __with__() method, but no conclusion.

Contributing threads:

- `Proposed changes to PEP 343 <http://mail.python.org/pipermail/ 
python-dev/2005-October/057040.html>`__
- `PEP 343 and __with__ <http://mail.python.org/pipermail/python-dev/ 
2005-October/056931.html>`__

[SJB]

----------------------
str and unicode issues
----------------------

Martin Blais wanted to completely disable the implicit conversions  
between unicode and str, so that you would always be forced to call  
either .encode() or .decode() to convert between one and the other.   
This is already available through adding ``sys.setdefaultencoding 
('undefined')`` to your sitecustomize.py file, but the suggestion  
started another long discussion over unicode issues.  Antoine Pitrou  
suggested that a good rule of thumb is to convert to unicode  
everything that is semantically textual, and to only use str for what  
is to be semantically treated as a string of bytes.  Fredrik Lundh  
argued against this for efficiency reasons -- pure ASCII text would  
consume more space as a unicode object.

There were suggestions that in Python 3.0, opening files in text mode  
will require an encoding and produce string objects, while opening  
files in binary mode will produce bytes objects.  The bytes() type  
will be a mutable array of bytes, which can be converted to a string  
object by specifying an encoding.

Contributing threads:

- `Divorcing str and unicode (no more implicit conversions). <http:// 
mail.python.org/pipermail/python-dev/2005-October/056916.html>`__
- `unifying str and unicode <http://mail.python.org/pipermail/python- 
dev/2005-October/056934.html>`__
- `bytes type <http://mail.python.org/pipermail/python-dev/2005- 
October/056945.html>`__

[SJB]

----------------------------------------------------------------------
Allowing \*args syntax in tuple unpacking and before keyword arguments
----------------------------------------------------------------------

Gustavo Niemeyer propsed the oft-seen request for allowing the \*args  
syntax in tuple unpacking, e.g.::

     for first, second, *rest in iterator:

Guido requested a PEP, saying that he wasn't convinced that there was  
much of a gain over the already valid::

     for item in iterator:
         (first, second), rest = item[2:], item[:2]

Greg Ewing and others didn't like Guido's suggestion as it violates  
DRY (Don't Repeat Yourself).  Others also chimed in with some  
examples in support of the proposal, but no one has yet put together  
a PEP.

In a related matter, Guido indicated that he wants to be able to  
write keyword-only arguments after a \*args, so that you could, for  
example, write::

     f(a, b, *args, foo=1, bar=2, **kwds)

People seemed almost unanimously in support of this proposal, but, to  
quote Nick Coghlan, it has still "never bugged anyone enough for them  
to actaully get around to fixing it".

Contributing thread:

- `Extending tuple unpacking <http://mail.python.org/pipermail/python- 
dev/2005-October/057056.html>`__

[SJB]

----------
AST Branch
----------

Guido gave the AST branch a three week ultimatum: either the branch  
should be merged into MAIN within the next three weeks, or the branch  
should be abandoned entirely.  This jump-started work on the branch,  
and the team was hoping to merge the changes the weekend of October  
15th.

Contributing threads:

- `Python 2.5a1, ast-branch and PEP 342 and 343 <http:// 
mail.python.org/pipermail/python-dev/2005-September/056449.html>`__
- `Python 2.5 and ast-branch <http://mail.python.org/pipermail/python- 
dev/2005-October/056986.html>`__
- `AST branch update <http://mail.python.org/pipermail/python-dev/ 
2005-October/057281.html>`__

[SJB]

-----------------------------------
Allowing "return obj" in generators
-----------------------------------

Piet Delport suggested having ``return obj`` in generators be  
translated into ``raise StopIteration(obj)``.  The return value of a  
generator function would thus be available as the first arg in the  
StopIteration exception.  Guido asked for some examples to give the  
idea a better motivation, and felt uncomfortable with the return  
value being silently ignored in for-loops.  The idea was postponed  
until at least one release after a PEP 342 implementation enters  
Python, so that people can have some more experience with coroutines.

Contributing threads:

- `Proposal for 2.5: Returning values from PEP 342 enhanced  
generators <http://mail.python.org/pipermail/python-dev/2005-October/ 
056957.html>`__
- `PEP 342 suggestion: start(), __call__() and unwind_call() methods  
<http://mail.python.org/pipermail/python-dev/2005-October/ 
057042.html>`__
- `New PEP 342 suggestion: result() and allow &quot;return with  
arguments&quot; in generators (was Re: PEP 342 suggestion: start(),  
__call__() and unwind_call() methods) <http://mail.python.org/ 
pipermail/python-dev/2005-October/057116.html>`__

[SJB]

-----------------------------
API for the line-number table
-----------------------------

Greg Ewing suggested trying to simplify the line-number table  
(lnotab) by simply matching each byte-code index with a file and line  
number.  Phillip J. Eby pointed out that this would make the stdlib  
take up an extra megabyte, suggesting two tables instead, one  
matching bytecodes to line numbers, and one matching the first line- 
number of a chunk with its file.  Michael Hudson suggested that what  
we really want is an API for accessing the lnotab, so that the  
implementation that is chosen is less important.  The conversation  
trailed off without a resolution.

Contributing thread:

- `Simplify lnotab? (AST branch update) <http://mail.python.org/ 
pipermail/python-dev/2005-October/057285.html>`__

[SJB]

------------------------------
Current directory and sys.path
------------------------------

A question about the status of `the CurrentVersion registry entry`_  
led to a discussion about the different behaviors of sys.path across  
platforms.  Apparently, on Windows, sys.path includes the current  
directory and the directory of the script being executed, while on  
Linux, it only includes the directory of the script.

.. _the CurrentVersion registry entry: http://www.python.org/windows/ 
python/registry.html

Contributing thread:

- `PythonCore\CurrentVersion <http://mail.python.org/pipermail/python- 
dev/2005-October/057095.html>`__

[SJB]

----------------------------------
Changing the __class__ of builtins
----------------------------------

As of Python 2.3, you can no longer change the __class__ of any  
builtin.  Phillip J. Eby suggested that these rules might be overly  
strict; modules and other mutable objects could probably reasonably  
have their __class__s changed.  No one seemed really opposed to the  
idea, but no one offered up a patch to make the change either.

Contributing thread:

- `Assignment to __class__ of module? (Autoloading? (Making  
Queue.Queue easier to use)) <http://mail.python.org/pipermail/python- 
dev/2005-October/057253.html>`__

[SJB]

------------------------------------------
exec function specification for Python 3.0
------------------------------------------

In Python 3.0, exec is slated to become a function (instead of a  
statement).  Currently, the presence of an exec statement in a  
function can cause some subtle changes since Python has to worry  
about exec modifying function locals.  Guido suggested that the exec 
() function could require a namespace, basically dumping the exec-in- 
local-namespace altogether.  People seemed generally in favor of the  
proposal, though no official specification was established.

Contributing thread:

- `PEP 3000 and exec <http://mail.python.org/pipermail/python-dev/ 
2005-October/057135.html>`__

[SJB]

------------------------------------
Adding opcodes to speed up self.attr
------------------------------------

Phillip J. Eby experimented with adding LOAD_SELF and SELF_ATTR  
opcodes to improve the speed of object-oriented programming.  This  
gained about a 5% improvement in pystone, which isn't organized in a  
very OO manner.  People seemed uncertain as to whether paying the  
cost of adding two opcodes to gain a 5% speedup was worth it.  No  
decision had been made at the time of this summary.

Contributing thread:

- `LOAD_SELF and SELF_ATTR opcodes <http://mail.python.org/pipermail/ 
python-dev/2005-October/057321.html>`__

[SJB]

--------------------------------------
Dropping support for --disable-unicode
--------------------------------------

Reinhold Birkenfeld tried unsuccessfully to make the test-suite pass  
with --disable-unicode set.  M.-A. Lemburg suggested that the feature  
should be ripped out entirely, to simplify the code.  Martin v. Lˆwis  
suggested deprecating it to give people a chance to object.  The plan  
is now to add a note to the configure switch that the feature will be  
removed in Python 2.6.

Contributing threads:

- `Tests and unicode <http://mail.python.org/pipermail/python-dev/ 
2005-October/056897.html>`__
- `--disable-unicode (Tests and unicode) <http://mail.python.org/ 
pipermail/python-dev/2005-October/056920.html>`__

[SJB]

-----------------------------------------
Bug in __getitem__ inheritance at C level
-----------------------------------------

Travis Oliphant discovered that the addition of the mp_item and  
sq_item descriptors and the resolution of any comptetion for  
__getitem__ calls is done  *before*  the inheritance of any slots  
takes place.  This means that if you create a type in C that supports  
the sequence protocol, and tries to inherit the mapping protocol from  
a parent C type which does not support the sequence protocol,  
__getitem__ will point to the parent type's __getitem__ instead of  
the child type's __getitem__.  This seemed like more of a bug than a  
feature, so the behavior may be changed in future Pythons.

Contributing thread:

- `Why does __getitem__ slot of builtin call sequence methods first?  
<http://mail.python.org/pipermail/python-dev/2005-October/ 
056901.html>`__

[SJB]

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

- `Early PEP draft (For Python 3000?) <http://mail.python.org/ 
pipermail/python-dev/2005-October/057251.html>`__
- `Pythonic concurrency - offtopic <http://mail.python.org/pipermail/ 
python-dev/2005-October/057294.html>`__

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

- `PEP 350: Codetags <http://mail.python.org/pipermail/python-dev/ 
2005-October/056894.html>`__
- `Active Objects in Python <http://mail.python.org/pipermail/python- 
dev/2005-October/056896.html>`__
- `IDLE development <http://mail.python.org/pipermail/python-dev/2005- 
October/056907.html>`__
- `Help needed with MSI permissions <http://mail.python.org/pipermail/ 
python-dev/2005-October/056908.html>`__
- `C API doc fix <http://mail.python.org/pipermail/python-dev/2005- 
October/056910.html>`__
- `Static builds on Windows (continued) <http://mail.python.org/ 
pipermail/python-dev/2005-October/056976.html>`__
- `Removing the block stack (was Re: PEP 343 and __with__) <http:// 
mail.python.org/pipermail/python-dev/2005-October/057001.html>`__
- `Removing the block stack <http://mail.python.org/pipermail/python- 
dev/2005-October/057008.html>`__
- `Lexical analysis and NEWLINE tokens <http://mail.python.org/ 
pipermail/python-dev/2005-October/057014.html>`__
- `PyObject_Init documentation <http://mail.python.org/pipermail/ 
python-dev/2005-October/057039.html>`__
- `Sourceforge CVS access <http://mail.python.org/pipermail/python- 
dev/2005-October/057051.html>`__
- `__doc__ behavior in class definitions <http://mail.python.org/ 
pipermail/python-dev/2005-October/057066.html>`__
- `Sandboxed Threads in Python <http://mail.python.org/pipermail/ 
python-dev/2005-October/057082.html>`__
- `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/ 
python-dev/2005-October/057092.html>`__
- `test_cmd_line failure on Kubuntu 5.10 with GCC 4.0 <http:// 
mail.python.org/pipermail/python-dev/2005-October/057094.html>`__
- `defaultproperty (was: Re: RFC: readproperty) <http:// 
mail.python.org/pipermail/python-dev/2005-October/057120.html>`__
- `async IO and helper threads <http://mail.python.org/pipermail/ 
python-dev/2005-October/057121.html>`__
- `defaultproperty <http://mail.python.org/pipermail/python-dev/2005- 
October/057129.html>`__
- `Fwd: defaultproperty <http://mail.python.org/pipermail/python-dev/ 
2005-October/057131.html>`__
- `C.E.R. Thoughts <http://mail.python.org/pipermail/python-dev/2005- 
October/057137.html>`__
- `problem with genexp <http://mail.python.org/pipermail/python-dev/ 
2005-October/057175.html>`__
- `Python-Dev Digest, Vol 27, Issue 44 <http://mail.python.org/ 
pipermail/python-dev/2005-October/057207.html>`__
- `Europeans attention please! <http://mail.python.org/pipermail/ 
python-dev/2005-October/057233.html>`__

More information about the Python-Dev mailing list