Hi,
Lisandro Dalcin and me are working on a common version of our patches
([1232343],[955928]) that we plan to submit soon (this would close the
two previously proposed patches, and we plan also to review 5 other
patches to push this one before 2.5 ;-) ).
We would like this new patch to be as clean and as safe as possible, but
to do so we would need some infos/advices from the list, and in
particular peoples having worked in the readline C implementation, i.e.
in modules Modules/readline.c, Parser/myreadline.c (PyOS_StdioReadline,
PyOS_StdioReadline, vms__StdioReadline), Python/bltinmodule.c
(builtin_raw_input).
First a general question about implementation guidelines for CPython:
-is it ok to initialize a static pointer to a non-null value (the
address of a predefined function) at compile time? ANSI-C (or even
pre-ansi C afaik) accept this, we have tested it on various linux and
unix, and there are occurrences of similar construct in the python C
sources, but not so many and not for function pointers (or I did not
found it ;) ).
We wonder if this can cause problem on some platforms not correctly
implementing C standard(s) but that python have to support nonetheless,
or if there is a feeling against it...The idea is to initialize
PyOS_ReadlineFunctionPointer this way.
Then something about the VMS platform support:
-readline seems to make uses of the extern function
vms__StdioReadline() on VMS...Where can we find the source or doc about
this function? In particular, we would like to know if this function
call (or can call) PyOS_StdioReadline, which would cause infinite
recursion in some version of our patch....without havind access to VMS
for testing or info about vms__StdioReadline, this is impossible to
know...
Thanks for any info,
Greg.
Hi Python-dev'ers,
The first Python implementation of Python is now also the
second C implementation of Python :-)
Samuele & Armin (& the rest of the team)
-+-+-
pypy-0.7.0: first PyPy-generated Python Implementations
==============================================================
What was once just an idea between a few people discussing
on some nested mailing list thread and in a pub became reality ...
the PyPy development team is happy to announce its first
public release of a fully translatable self contained Python
implementation. The 0.7 release showcases the results of our
efforts in the last few months since the 0.6 preview release
which have been partially funded by the European Union:
- whole program type inference on our Python Interpreter
implementation with full translation to two different
machine-level targets: C and LLVM
- a translation choice of using a refcounting or Boehm
garbage collectors
- the ability to translate with or without thread support
- very complete language-level compliancy with CPython 2.4.1
What is PyPy (about)?
------------------------------------------------
PyPy is a MIT-licensed research-oriented reimplementation of
Python written in Python itself, flexible and easy to
experiment with. It translates itself to lower level
languages. Our goals are to target a large variety of
platforms, small and large, by providing a compilation toolsuite
that can produce custom Python versions. Platform, Memory and
Threading models are to become aspects of the translation
process - as opposed to encoding low level details into a
language implementation itself. Eventually, dynamic
optimization techniques - implemented as another translation
aspect - should become robust against language changes.
Note that PyPy is mainly a research and development project
and does not by itself focus on getting a production-ready
Python implementation although we do hope and expect it to
become a viable contender in that area sometime next year.
Where to start?
-----------------------------
Getting started: http://codespeak.net/pypy/dist/pypy/doc/getting-started.html
PyPy Documentation: http://codespeak.net/pypy/dist/pypy/doc/
PyPy Homepage: http://codespeak.net/pypy/
The interpreter and object model implementations shipped with
the 0.7 version can run on their own and implement the core
language features of Python as of CPython 2.4. However, we still
do not recommend using PyPy for anything else than for education,
playing or research purposes.
Ongoing work and near term goals
---------------------------------
PyPy has been developed during approximately 15 coding sprints
across Europe and the US. It continues to be a very
dynamically and incrementally evolving project with many
one-week meetings to follow. You are invited to consider coming to
the next such meeting in Paris mid October 2005 where we intend to
plan and head for an even more intense phase of the project
involving building a JIT-Compiler and enabling unique
features not found in other Python language implementations.
PyPy has been a community effort from the start and it would
not have got that far without the coding and feedback support
from numerous people. Please feel free to give feedback and
raise questions.
contact points: http://codespeak.net/pypy/dist/pypy/doc/contact.html
contributor list: http://codespeak.net/pypy/dist/pypy/doc/contributor.html
have fun,
the pypy team, of which here is a partial snapshot
of mainly involved persons:
Armin Rigo, Samuele Pedroni,
Holger Krekel, Christian Tismer,
Carl Friedrich Bolz, Michael Hudson,
Eric van Riet Paap, Richard Emslie,
Anders Chrigstroem, Anders Lehmann,
Ludovic Aubry, Adrien Di Mascio,
Niklaus Haldimann, Jacob Hallen,
Bea During, Laura Creighton,
and many contributors ...
PyPy development and activities happen as an open source project
and with the support of a consortium partially funded by a two
year European Union IST research grant. Here is a list of
the full partners of that consortium:
Heinrich-Heine University (Germany), AB Strakt (Sweden)
merlinux GmbH (Germany), tismerysoft GmbH(Germany)
Logilab Paris (France), DFKI GmbH (Germany)
ChangeMaker (Sweden), Impara (Germany)
hi, all
You know Jython (Java version of Python) has only a stable version of
2.1, and two alpha version was release after 3 years.
So if it wants to evolve to 2.2 , 2.3 or 2.4 as Python, some detail
change list was need, and it's great if there are some test case
script to test the new implemention version.
So does Python has this kinds of things? Where can I find them or
something like this?
Regards
FAN
> A new hashlib module to replace the md5 and sha modules. It adds
> support for additional secure hashes such as SHA-256 and SHA-512. The
> hashlib module uses OpenSSL for fast platform optimized
> implementations of algorithms when available. The old md5 and sha
> modules still exist as wrappers around hashlib to preserve backwards
> compatibility.
I'm getting compilation errors:
C:\py25\Modules\sha512module.c(146) : error C2059: syntax error : 'bad
suffix on number'
C:\py25\Modules\sha512module.c(146) : error C2146: syntax error :
missing ')' before identifier 'L'
C:\py25\Modules\sha512module.c(146) : error C2059: syntax error : 'bad
suffix on number'
C:\py25\Modules\sha512module.c(146) : error C2059: syntax error : 'bad
suffix on number'
C:\py25\Modules\sha512module.c(146) : error C2059: syntax error : 'bad
suffix on number'
C:\py25\Modules\sha512module.c(146) : error C2059: syntax error : 'bad
suffix on number'
C:\py25\Modules\sha512module.c(146) : error C2059: syntax error : 'bad
suffix on number'
C:\py25\Modules\sha512module.c(146) : fatal error C1013: compiler limit
: too many open parentheses
Also, there should be updating entries to Misc/NEWS,
PC/VC6/pythoncore.dsp, and PC/config.c.
Raymond
Okay. Even though I know that most people here would probably find it
difficult to give input when MinGW is used to build Python, I am going
to post what I found out so far anyway concerning the test_bz2 situation
for referencing purposes.
--------------------------------------------------------------------
Python version Mode used Location of test Result
from CVS
--------------------------------------------------------------------
Python 2.5a0 normal ../Lib/test/ PASS
Python 2.5a0 normal CWD of Python PASS
Python 2.5a0 interactive ../Lib/test/ PASS
Python 2.5a0 interactive CWD of Python PASS
Python 2.4.1 normal ../Lib/test/ FAIL
Python 2.4.1 normal CWD of Python PASS
Python 2.4.1 interactive ../Lib/test/ PASS
Python 2.4.1 interactive CWD of Python PASS
--------------------------------------------------------------------
For python 2.4.1, tried both bzip2-1.0.2, and bzip2-1.0.3 on Win98 SE,
and WinXP Pro SP2, using MinGW 3.4.4.
I'll try to see what else I can find out.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Reinhold Birkenfeld wrote:
>>#--------------------------- Python 2.5a0 from CVS -----------------#
>># Result: passes
>>$ /g/projs/py25/python/dist/src/MinGW/python testbz2.py
>>
>>
>>#--------------------------- Python 2.4.1 from CVS -----------------#
>># Result: fails
>>$ /g/projs/py24/python/dist/src/MinGW/python testbz2.py
>>Traceback (most recent call last):
>> File "testbz2.py", line 9, in ?
>> lines = bz2f.readlines()
>>RuntimeError: wrong sequence of bz2 library commands used
>
>I don't understand this. The sources for the bz2 modules are exactly equal
>in both branches.
I know. Even the tests are equal. I didn't say that these files are to
blame, I just said that the test is failing in Python 2.4.1 on Windows.
>How do you check out the 2.4.1 from CVS?
Well, I've been updating Python from CVS from more than a year now and I
doubt that this is the problem. After all, Python 2.3.5 is passing the
regrtests, and last time I checked, so is Python 2.5a0. Python 2.4.1 was
also passing all the regtests until recently (not sure exatcly when, but it
could be about a month ago). But anyway, here is how I update my copy of
Python 2.4 from CVS. Roughly,
cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/python login
[Enter]
cvs -z7 -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/python update -dP
-r release24-maint python
And it is, more or less, the same way I check out other branches.
I will download the Python 2.4.1 source archieve and to build it to see what
happens. I'll report back when I am done.
Regards,
Khalid
_________________________________________________________________
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
[Guido]
> However, after 12 years, I believe that the small benefit of having
> find() is outweighed by the frequent occurrence of bugs in its use.
My little code transformation exercise is bearing that out. Two of the
first four cases in the standard library were buggy :-(
Raymond
Okay here is the output of test_bz2 on Python 2.4.1 updated and compiled
fresh from CVS, and on Python 2.4.1 from the source archieve from python.org
(http://www.python.org/ftp/python/2.4.1/Python-2.4.1.tar.bz2).
#-----------------------------------------------------------------------------
# Python 2.4.1 compiled from source archieve:
# Result: passes
#-----------------------------------------------------------------------------
$ cd /g/projs/py241-src-arc/mingw
$ python ../Lib/test/test_bz2.py
testIterator (__main__.BZ2FileTest) ... ok
testOpenDel (__main__.BZ2FileTest) ... ok
testOpenNonexistent (__main__.BZ2FileTest) ... ok
testRead (__main__.BZ2FileTest) ... ok
testRead100 (__main__.BZ2FileTest) ... ok
testReadChunk10 (__main__.BZ2FileTest) ... ok
testReadLine (__main__.BZ2FileTest) ... ok
testReadLines (__main__.BZ2FileTest) ... ok
testSeekBackwards (__main__.BZ2FileTest) ... ok
testSeekBackwardsFromEnd (__main__.BZ2FileTest) ... ok
testSeekForward (__main__.BZ2FileTest) ... ok
testSeekPostEnd (__main__.BZ2FileTest) ... ok
testSeekPostEndTwice (__main__.BZ2FileTest) ... ok
testSeekPreStart (__main__.BZ2FileTest) ... ok
testUniversalNewlinesCRLF (__main__.BZ2FileTest) ... ok
testUniversalNewlinesLF (__main__.BZ2FileTest) ... ok
testWrite (__main__.BZ2FileTest) ... ok
testWriteChunks10 (__main__.BZ2FileTest) ... ok
testWriteLines (__main__.BZ2FileTest) ... ok
testXReadLines (__main__.BZ2FileTest) ... ok
testCompress (__main__.BZ2CompressorTest) ... ok
testCompressChunks10 (__main__.BZ2CompressorTest) ... ok
testDecompress (__main__.BZ2DecompressorTest) ... ok
testDecompressChunks10 (__main__.BZ2DecompressorTest) ... ok
testDecompressUnusedData (__main__.BZ2DecompressorTest) ... ok
testEOFError (__main__.BZ2DecompressorTest) ... ok
test_Constructor (__main__.BZ2DecompressorTest) ... ok
testCompress (__main__.FuncTest) ... ok
testDecompress (__main__.FuncTest) ... ok
testDecompressEmpty (__main__.FuncTest) ... ok
testDecompressIncomplete (__main__.FuncTest) ... ok
----------------------------------------------------------------------
Ran 31 tests in 6.430s
OK
#-----------------------------------------------------------------------------
# Python 2.4.1 compiled from CVS updated even today:
# Result: fails
#-----------------------------------------------------------------------------
$ cd /g/projs/py24/python/dist/src/MinGW
$ python ../Lib/test/test_bz2.py
testBug1191043 (__main__.BZ2FileTest) ... ERROR
ERROR
testIterator (__main__.BZ2FileTest) ... ok
testModeU (__main__.BZ2FileTest) ... ok
testOpenDel (__main__.BZ2FileTest) ... ok
testOpenNonexistent (__main__.BZ2FileTest) ... ok
testRead (__main__.BZ2FileTest) ... ok
testRead100 (__main__.BZ2FileTest) ... ok
testReadChunk10 (__main__.BZ2FileTest) ... ok
testReadLine (__main__.BZ2FileTest) ... ok
testReadLines (__main__.BZ2FileTest) ... ok
testSeekBackwards (__main__.BZ2FileTest) ... ok
testSeekBackwardsFromEnd (__main__.BZ2FileTest) ... ok
testSeekForward (__main__.BZ2FileTest) ... ok
testSeekPostEnd (__main__.BZ2FileTest) ... ok
testSeekPostEndTwice (__main__.BZ2FileTest) ... ok
testSeekPreStart (__main__.BZ2FileTest) ... ok
testUniversalNewlinesCRLF (__main__.BZ2FileTest) ... ok
testUniversalNewlinesLF (__main__.BZ2FileTest) ... ok
testWrite (__main__.BZ2FileTest) ... ok
testWriteChunks10 (__main__.BZ2FileTest) ... ok
testWriteLines (__main__.BZ2FileTest) ... ok
testXReadLines (__main__.BZ2FileTest) ... ok
testCompress (__main__.BZ2CompressorTest) ... ok
testCompressChunks10 (__main__.BZ2CompressorTest) ... ok
testDecompress (__main__.BZ2DecompressorTest) ... ok
testDecompressChunks10 (__main__.BZ2DecompressorTest) ... ok
testDecompressUnusedData (__main__.BZ2DecompressorTest) ... ok
testEOFError (__main__.BZ2DecompressorTest) ... ok
test_Constructor (__main__.BZ2DecompressorTest) ... ok
testCompress (__main__.FuncTest) ... ok
testDecompress (__main__.FuncTest) ... ok
testDecompressEmpty (__main__.FuncTest) ... ok
testDecompressIncomplete (__main__.FuncTest) ... ok
======================================================================
ERROR: testBug1191043 (__main__.BZ2FileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "../Lib/test/test_bz2.py", line 255, in testBug1191043
lines = bz2f.readlines()
RuntimeError: wrong sequence of bz2 library commands used
======================================================================
ERROR: testBug1191043 (__main__.BZ2FileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "../Lib/test/test_bz2.py", line 47, in tearDown
os.unlink(self.filename)
OSError: [Errno 13] Permission denied: '@test'
----------------------------------------------------------------------
Ran 33 tests in 5.980s
FAILED (errors=2)
Traceback (most recent call last):
File "../Lib/test/test_bz2.py", line 357, in ?
test_main()
File "../Lib/test/test_bz2.py", line 353, in test_main
FuncTest
File "G:\PROJS\PY24\PYTHON\DIST\SRC\lib\test\test_support.py", line 290,
in run_unittest
run_suite(suite, testclass)
File "G:\PROJS\PY24\PYTHON\DIST\SRC\lib\test\test_support.py", line 274,
in run_suite
raise TestFailed(msg)
test.test_support.TestFailed: errors occurred; run in verbose mode for
details
_________________________________________________________________
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Here's August Part One. As usual, if anyone can spare the time to proofread
this, that would be great! Please send any corrections or suggestions to
Steve (steven.bethard at gmail.com) and/or me, rather than cluttering the
list. Ta!
=============
Announcements
=============
----------------------------
QOTF: Quote of the Fortnight
----------------------------
Some wise words from Donovan Baarda in the PEP 347 discussions:
It is true that some well designed/developed software becomes reliable
very quickly. However, it still takes heavy use over time to prove that.
Contributing thread:
- `PEP: Migrating the Python CVS to Subversion
<http://mail.python.org/pipermail/python-dev/2005- August/055105.html>`__
[SJB]
------------
Process PEPs
------------
The PEP editors have introduced a new PEP category: "Process", for PEPs that
don't fit into the "Standards Track" and "Informational" categories. More
detail can be found in `PEP 1`_, which it itself a Process PEP.
.. _PEP 1: http://www.python.org/peps/pep-0001.html
Contributing thread:
- `new PEP type: Process
<http://mail.python.org/pipermail/python-dev/2005-August/055361.html>`__
[TAM]
-----------------------------------------------
Tentative Schedule for 2.4.2 and 2.5a1 Releases
-----------------------------------------------
Python 2.4.2 is tentatively scheduled for a mid-to-late September release,
and a first alpha of Python 2.5 for March 2006 (with a final release around
May/June). This means that a PEP for the 2.5 release, detailing what will
be included, will likely be created soon; at present there are various
accepted PEPs that have not yet been implemented.
Contributing thread:
- `plans for 2.4.2 and 2.5a1
<http://mail.python.org/pipermail/python-dev/2005-August/055342.html>`__
[TAM]
=========
Summaries
=========
-------------------------------
Moving Python CVS to Subversion
-------------------------------
The `PEP 347`_ discussion from last fortnight continued this week, with a
revision of the PEP, and a lot more discussion about possible version
control software (RCS) for the Python repository, and where the repository
should be hosted. Note that this is not a discussion about bug trackers,
which will remain with Sourceforge (unless a separate PEP is developed for
moving that).
Many revision control systems were extensively discussed, including
`Subversion`_ (SVN), `Perforce`_, and `Monotone`_. Whichever system is
moved to, it should be able to be hosted somewhere (if *.python.org, then
it needs to be easily installable), needs to have software available to
convert a repository from CVS, and ideally would be open-source; similarity
to CVS is also an advantage in that it requires a smaller learning curve
for existing developers. While Martin isn't willing to discuss every
system there is, he will investigate those that make him curious, and will
add other people's submissions to the PEP, where appropriate.
The thread included a short discussion about the authentication mechanism
that svn.python.org will use; svn+ssh seems to be a clear winner, and a
test repository will be setup by Martin next fortnight.
The possibility of moving to a distributed revision control system
(particularly `Bazaar-NG`_) was also brought up. Many people liked the
idea of using a distributed revision control system, but it seems unlikely
that Bazaar-NG is mature enough to be used for the main Python repository at
the current time (a move to it at a later time is possible, but outside the
scope of the PEP). Distributed RCS are meant to reduce the barrier to
participation (anyone can create the their own branches, for example);
Bazaar-NG is also implemented in Python, which is of some benefit. James Y
Knight pointed out `svk`_, which lets developers create their own branches
within SVN.
In general, the python-dev crowd is in favour of moving to SVN. Initial
concern about the demands on the volunteer admins should the repository be
hosted at svn.python.org were addressed by Barry Warsaw, who believes that
the load will be easily managed with the existing volunteers. Various
alternative hosts were discussed, and if detailed reports about any of them
are created, these can be added to the PEP.
While the fate of all PEPS lie with the BDFL (Guido), it is likely that the
preferences of those that frequently check in changes, the pydotorg admins,
and the release managers (who have all given favourable reports so far),
will have a significant effect on the pronouncement of this PEP.
.. _PEP 347: http://www.python.org/peps/pep-0347.html
.. _svk: http://svk.elixus.org/
.. _Perforce: http://www.perforce.com/
.. _Subversion: http://subversion.tigris.org/
.. _Monotone: http://venge.net/monotone/
.. _Bazaar-NG: http://www.bazaar-ng.org/
Contributing threads:
- `PEP: Migrating the Python CVS to Subversion
<http://mail.python.org/pipermail/python-dev/2005- August/055064.html>`__
- `PEP 347: Migration to Subversion
<http://mail.python.org/pipermail/python-dev/2005- August/055211.html>`__
- `Hosting svn.python.org
<http://mail.python.org/pipermail/python-dev/2005-August/055360.html>`__
- `Fwd: Distributed RCS
<http://mail.python.org/pipermail/python-dev/2005-August/055372.html>`__
- `cvs to bzr?
<http://mail.python.org/pipermail/python-dev/2005-August/055373.html>`__
- `Distributed RCS
<http://mail.python.org/pipermail/python-dev/2005-August/055377.html>`__
- `Fwd: PEP: Migrating the Python CVS to Subversion
<http://mail.python.org/pipermail/python-dev/2005 -August/055388.html>`__
- `On distributed vs centralised SCM for Python
<http://mail.python.org/pipermail/python-dev/2005- August/055432.html>`__
[TAM]
------------------------------------------
PEP 348: Exception Hierarchy in Python 3.0
------------------------------------------
This fortnight mostly concluded the previous discussion about `PEP 348`_,
which sets out a roadmap for changes to the exception hierarchy in Python
3.0. The proposal was heavily scaled back to retain most of the current
exception hierarchy unchanged. A new exception, BaseException, will be
introduced above Exception in the current hierarchy, and KeyboardInterrupt
and SystemExit will become siblings of Exception. The goal here is that::
except Exception:
will now do the right thing for most cases, that is, it will catch all the
exceptions that you can generally recover from. The PEP would also move
NotImplementedError out from under RuntimeError, and alter the semantics of
the bare except so that::
except:
is the equivalent of::
except Exception:
Only BaseException will appear in Python 2.5. The remaining modifications
will not occur until Python 3.0.
.. _PEP 348: http://www.python.org/peps/pep-0348.html
Contributing threads:
- `Pre-PEP: Exception Reorganization for Python 3.0
<http://mail.python.org/pipermail/python-dev/2005 -August/055063.html>`__
- `PEP, take 2: Exception Reorganization for Python 3.0
<http://mail.python.org/pipermail/python- dev/2005-August/055103.html>`__
- `Exception Reorg PEP checked in
<http://mail.python.org/pipermail/python-dev/2005- August/055138.html>`__
- `PEP 348: Exception Reorganization for Python 3.0
<http://mail.python.org/pipermail/python-dev/2005 -August/055162.html>`__
- `Major revision of PEP 348 committed
<http://mail.python.org/pipermail/python-dev/2005- August/055199.html>`__
- `Exception Reorg PEP revised yet again
<http://mail.python.org/pipermail/python-dev/2005- August/055292.html>`__
- `PEP 348 and ControlFlow
<http://mail.python.org/pipermail/python-dev/2005-August/055310.html>`__
- `PEP 348 (exception reorg) revised again
<http://mail.python.org/pipermail/python-dev/2005- August/055412.html>`__
[SJB]
----------------------
Moving towards Unicode
----------------------
Neil Schemenauer presented `PEP 349`_, which tries to ease the transition to
Python 3.0, in which there will be a bytes() type for byte data and a str()
type for text data. Currently to convert an object to text, you have one
of three options:
* Call str(). This breaks with a UnicodeEncodeError if the object is of type
unicode (or a subtype) or can only represent itself in unicode and
therefore returns unicode from __str__.
* Call unicode(). This can break external code that is not yet Unicode-safe
and that passed a str object to your code but got a unicode object back.
* Use the "%s" format specifier. This breaks with a UnicodeEncodeError if
the object can only represent itself in unicode and therefore returns
unicode from __str__.
`PEP 349`_ attempts to address this problem by introducing a text() builtin
which returns str or unicode instances unmodified, and returns the result
of calling __str__() on the object otherwise. Guido preferred to instead
relax the restrictions on str() to allow it to return unicode objects. Neil
implemented such a patch, and found that it broke only two test cases. The
discussion stopped shortly after Neil's report however, so it was unclear
if any permanent changes had been agreed upon.
Guido made a few other Python 3.0 suggestions in this thread:
* The bytes() type should be mutable with a corresponding frozenbytes()
immutable type
* Opening a file in binary or text mode would cause it to return bytes() or
str() objects, respectively
* The file type should grow a getpos()/setpos() pair that are identical to
tell()/seek() when a file is open in binary mode, and which work like
tell()/seek() but on characters instead of bytes when a file is open in
text mode
However, none of these seemed to be solid commitments.
.. _PEP 349: http://www.python.org/peps/pep-0349.html
Contributing threads:
- `PEP: Generalised String Coercion
<http://mail.python.org/pipermail/python-dev/2005- August/055186.html>`__
- `Generalised String Coercion
<http://mail.python.org/pipermail/python-dev/2005- August/055194.html>`__
[SJB]
----------------------------
PEP 344 and reference cycles
----------------------------
Armin Rigo brought up an issue with `PEP 344`_ which proposes, among other
things, adding a __traceback__ attribute to exceptions to avoid the hassle
of extracting it from sys.exc_info(). Armin pointed out that if exceptions
grow a __traceback__ attribute, every statement::
except Exception, e:
will create a cycle::
e.__traceback__.tb_frame.f_locals['e']
Despite the fact that Python has cyclic garbage collection, there are still
some situations where cycles like this can cause problems. Armin showed an
example of such a case::
class X:
def __del__(self):
try:
typo
except Exception, e:
e_type, e_value, e_tb = sys.exc_info()
Even in current Python, instances of the X class are uncollectible. When
garbage collection runs and tries to collect an X object, it calls the
__del__() method. This creates the cycle::
e_tb.tb_frame.f_locals['e_tb']
The X object itself is available through this cycle (in
``f_locals['self']``), so the X object's refcount does not drop to 0 when
__del__() returns, so it cannot be collected. The next time garbage
collection runs, it finds that the X object has not been collected, calls
its __del__() method again and repeats the process.
Tim Peters suggested this problem could be solved by declaring that
__del__() methods are called exactly once. This allows the above X object
to be collected because on the second run of the garbage collection,
__del__() is not called again. Thus, the refcount of the X object is not
incremented, and so it is collected by garbage collection. However,
guaranteeing that __del__() is called only once means keeping track somehow
of which objects' __del__() methods were called, which seemed somewhat
unattractive.
There was also brief talk about removing __del__ in favor of weakrefs, but
those waters seemed about as murky as the garbage collection ones.
.. _PEP 344: http://www.python.org/peps/pep-0344.html
Contributing thread:
- `__traceback__ and reference cycles
<http://mail.python.org/pipermail/python-dev/2005- August/055251.html>`__
[SJB]
----------------------------
Style for raising exceptions
----------------------------
Guido explained that these days exceptions should always be raised as::
raise SomeException("some argument")
instead of::
raise SomeException, "some argument"
The second will go away in Python 3.0, and is only present now for backwards
compatibility. (It was necessary when strings could be exceptions, in
order to pass both the exception "type" and message.) PEPs 8_ and 3000_
were accordingly updated.
.. _8: http://www.python.org/peps/pep-0008.html
.. _3000: http://www.python.org/peps/pep-3000.html
Contributing threads:
- `PEP 8: exception style
<http://mail.python.org/pipermail/python-dev/2005-August/055187.html>`__
- `FW: PEP 8: exception style
<http://mail.python.org/pipermail/python-dev/2005-August/055191.html>`__
[SJB]
-----------------------------------
Skipping list comprehensions in pdb
-----------------------------------
When using pdb, the only way to skip to the end of a loop is to set a
breakpoint on the line after the loop. Ilya Sandler suggested adding an
optimal numeric argument to pdb's "next" comment to indicate how many lines
of code should be skipped. Martin v. Löwis pointed out that this differs
from gdb's "next <n>" command, which does "next" n times. Ilya suggested
implementing gdb's "until" command instead, which gained Martin's approval.
It was also pointed out that pdb is one of the less Pythonic modules,
particularly in terms of the ability to subclass/extend, and would be a
good candidate for rewriting, if anyone had the inclination and time.
Contributing threads:
- `pdb: should next command be extended?
<http://mail.python.org/pipermail/python-dev/2005- August/055218.html>`__
- `an alternative suggestion, Re: pdb: should next command be extended?
<http://mail.python.org/pipermail/python-dev/2005-August/055286.html>`__
[TAM]
------------------
Sets in Python 2.5
------------------
Raymond Hettinger has been checking-in the new implementation for sets in
Python 2.5. The implementation is based heavily on dictobject.c, the code
for Python dict() objects, and generally deviates only when there is an
obvious gain in doing so. Raymond posted his new API for discussion, but
there didn't appear to be any comments.
Contributing threads:
- `[Python-checkins] python/dist/src/Objects setobject.c, 1.45, 1.46
<http://mail.python.org/pipermail/python-dev/2005-August/055337.html>`__
- `Discussion draft: Proposed Py2.5 C API for set and frozenset objects
<http://mail.python.org/pipermail/python-dev/2005-August/055365.html>`__
[SJB]
================================
Deferred Threads (for next time)
================================
- `SWIG and rlcompleter
<http://mail.python.org/pipermail/python-dev/2005-August/055413.html>`__
===============
Skipped Threads
===============
- `Extension of struct to handle non byte aligned values?
<http://mail.python.org/pipermail/python- dev/2005-August/055062.html>`__
- `Syscall Proxying in Python
<http://mail.python.org/pipermail/python-dev/2005-August/055069.html>`__
- `__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z
boilerplate code)
<http://mail.python.org/pipermail/python-dev/2005-August/055093.html>`__
- `Weekly Python Patch/Bug Summary
<http://mail.python.org/pipermail/python-dev/2005- August/055110.html>`__
- `PEP 342 Implementation
<http://mail.python.org/pipermail/python-dev/2005-August/055151.html>`__
- `String exceptions in Python source
<http://mail.python.org/pipermail/python-dev/2005- August/055155.html>`__
- `[ python-Patches-790710 ] breakpoint command lists in pdb
<http://mail.python.org/pipermail/python -dev/2005-August/055157.html>`__
- `[C++-sig] GCC version compatibility
<http://mail.python.org/pipermail/python-dev/2005- August/055219.html>`__
- `PyTuple_Pack added references undocumented
<http://mail.python.org/pipermail/python-dev/2005- August/055232.html>`__
- `PEP-- Context Managment variant
<http://mail.python.org/pipermail/python-dev/2005- August/055271.html>`__
- `Sourceforge CVS down?
<http://mail.python.org/pipermail/python-dev/2005-August/055307.html>`__
- `PSF grant / contacts
<http://mail.python.org/pipermail/python-dev/2005-August/055311.html>`__
- `Python + Ping
<http://mail.python.org/pipermail/python-dev/2005-August/055319.html>`__
- `Terminology for PEP 343
<http://mail.python.org/pipermail/python-dev/2005-August/055347.html>`__
- `dev listinfo page (was: Re: Python + Ping)
<http://mail.python.org/pipermail/python-dev/2005- August/055348.html>`__
- `set.remove feature/bug
<http://mail.python.org/pipermail/python-dev/2005-August/055352.html>`__
- `Extension to dl module to allow passing strings from native function
<http://mail.python.org/pipermail/python-dev/2005-August/055363.html>`__
- `build problems on macosx (CVS HEAD)
<http://mail.python.org/pipermail/python-dev/2005- August/055385.html>`__
- `request for code review - hashlib - patch #1121611
<http://mail.python.org/pipermail/python- dev/2005-August/055410.html>`__
- `python-dev Summary for 2005-07-16 through 2005-07-31 [draft]
<http://mail.python.org/pipermail/python-dev/2005-August/055411.html>`__
- `string_join overrides TypeError exception thrown in generator
<http://mail.python.org/pipermail/python-dev/2005-August/055414.html>`__
- `implementation of copy standard lib
<http://mail.python.org/pipermail/python-dev/2005- August/055450.html>`__
- `xml.parsers.expat no userdata in callback functions
<http://mail.python.org/pipermail/python- dev/2005-August/055362.html>`__
Reinhold Birkenfeld wrote:
>Are you sure that you are calling the newly-built python.exe? It is strange
>that
>the test should pass in interactive mode when it doesn't in normal mode.
>For a confirmation, can you execute this piece of code both interactively
>and
>from a file:
Yes, both Python's tested are fresh from CVS. Here is the output of the test
you asked I run
#----------------------
# File: testbz2.py
#----------------------
"""
import os
from bz2 import BZ2File
data = 'BZh91AY&SY\xd9b\x89]\x00\x00\x00\x03\x80\x04\x00\x02\x00\x0c\x00
\x00!\x9ah3M\x13<]\xc9\x14\xe1BCe\x8a%t'
f = open('test.bz2', "wb")
f.write(data)
f.close()
bz2f = BZ2File('test.bz2')
lines = bz2f.readlines()
bz2f.close()
assert lines == ['Test']
bz2f = BZ2File('test.bz2')
xlines = list(bz2f.xreadlines())
bz2f.close()
assert lines == ['Test']
os.unlink('test.bz2')
"""
-------------
RESULTS:
-------------
#--------------------------- Python 2.5a0 from CVS -----------------#
# Result: passes
$ /g/projs/py25/python/dist/src/MinGW/python testbz2.py
#--------------------------- Python 2.4.1 from CVS -----------------#
# Result: fails
$ /g/projs/py24/python/dist/src/MinGW/python testbz2.py
Traceback (most recent call last):
File "testbz2.py", line 9, in ?
lines = bz2f.readlines()
RuntimeError: wrong sequence of bz2 library commands used
#--------------------------- Python 2.4.1 from CVS -----------------#
# Interpreted session: testbz2 fails here as well now
$ /g/projs/py24/python/dist/src/MinGW/python -i
Python 2.4.1 (#65, Aug 26 2005, 14:38:48)
[GCC 3.4.4 (mingw special)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>import os
>>>from bz2 import BZ2File
>>>data = 'BZh91AY&SY\xd9b\x89]\x00\x00\x00\x03\x80\x04\x00\x02\x00\x0c\x00
>>>\x0 0!\x9ah3M\x13<]\xc9\x14\xe1BCe\x8a%t'
>>>f = open('test.bz2', "wb")
>>>f.write(data)
>>>f.close()
>>>bz2f = BZ2File('test.bz2')
>>>lines = bz2f.readlines()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
RuntimeError: wrong sequence of bz2 library commands used
>>>raise SystemExit
#--------------------------- Python 2.5a0 from CVS -----------------#
# Interpreted session: testbz2 passes
$ /g/projs/py25/python/dist/src/MinGW/python -i
Python 2.5a0 (#65, Aug 26 2005, 14:57:28)
[GCC 3.4.4 (mingw special)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>import os
>>>from bz2 import BZ2File
>>>data = 'BZh91AY&SY\xd9b\x89]\x00\x00\x00\x03\x80\x04\x00\x02\x00\x0c\x00
>>>\x0 0!\x9ah3M\x13<]\xc9\x14\xe1BCe\x8a%t'
>>>f = open('test.bz2', "wb")
>>>f.write(data)
>>>f.close()
>>>bz2f = BZ2File('test.bz2')
>>>lines = bz2f.readlines()
>>>bz2f.close()
>>>assert lines == ['Test']
>>>bz2f = BZ2File('test.bz2')
>>>xlines = list(bz2f.xreadlines())
>>>bz2f.close()
>>>assert lines == ['Test']
>>>os.unlink('test.bz2')
>>>raise SystemExit
Regards,
Khalid
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/