Movatterモバイル変換
[0]ホーム
[Python-Dev] python-dev Summary for 2005-08-01 through 2005-08-15[draft]
Tony Meyert-meyer at ihug.co.nz
Thu Aug 25 10:51:18 CEST 2005
Here's August Part One. As usual, if anyone can spare the time to proofreadthis, that would be great! Please send any corrections or suggestions toSteve (steven.bethard at gmail.com) and/or me, rather than cluttering thelist. 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 reliablevery 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 thatdon't fit into the "Standards Track" and "Informational" categories. Moredetail can be found in `PEP 1`_, which it itself a Process PEP... _PEP 1:http://www.python.org/peps/pep-0001.htmlContributing 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 aroundMay/June). This means that a PEP for the 2.5 release, detailing what willbe included, will likely be created soon; at present there are variousaccepted 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 arevision of the PEP, and a lot more discussion about possible versioncontrol software (RCS) for the Python repository, and where the repositoryshould be hosted. Note that this is not a discussion about bug trackers,which will remain with Sourceforge (unless a separate PEP is developed formoving that).Many revision control systems were extensively discussed, including`Subversion`_ (SVN), `Perforce`_, and `Monotone`_. Whichever system ismoved to, it should be able to be hosted somewhere (if *.python.org, thenit needs to be easily installable), needs to have software available toconvert a repository from CVS, and ideally would be open-source; similarityto CVS is also an advantage in that it requires a smaller learning curvefor existing developers. While Martin isn't willing to discuss everysystem there is, he will investigate those that make him curious, and willadd other people's submissions to the PEP, where appropriate.The thread included a short discussion about the authentication mechanismthat svn.python.org will use; svn+ssh seems to be a clear winner, and atest 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 theidea of using a distributed revision control system, but it seems unlikelythat Bazaar-NG is mature enough to be used for the main Python repository atthe current time (a move to it at a later time is possible, but outside thescope of the PEP). Distributed RCS are meant to reduce the barrier toparticipation (anyone can create the their own branches, for example);Bazaar-NG is also implemented in Python, which is of some benefit. James YKnight pointed out `svk`_, which lets developers create their own brancheswithin SVN.In general, the python-dev crowd is in favour of moving to SVN. Initialconcern about the demands on the volunteer admins should the repository behosted at svn.python.org were addressed by Barry Warsaw, who believes thatthe load will be easily managed with the existing volunteers. Variousalternative hosts were discussed, and if detailed reports about any of themare created, these can be added to the PEP.While the fate of all PEPS lie with the BDFL (Guido), it is likely that thepreferences 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 Python3.0. The proposal was heavily scaled back to retain most of the currentexception hierarchy unchanged. A new exception, BaseException, will beintroduced above Exception in the current hierarchy, and KeyboardInterruptand 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 theexceptions that you can generally recover from. The PEP would also moveNotImplementedError out from under RuntimeError, and alter the semantics ofthe bare except so that:: except:is the equivalent of:: except Exception:Only BaseException will appear in Python 2.5. The remaining modificationswill not occur until Python 3.0... _PEP 348:http://www.python.org/peps/pep-0348.htmlContributing 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 toPython 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 oneof three options:* Call str(). This breaks with a UnicodeEncodeError if the object is of typeunicode (or a subtype) or can only represent itself in unicode andtherefore returns unicode from __str__.* Call unicode(). This can break external code that is not yet Unicode-safeand that passed a str object to your code but got a unicode object back.* Use the "%s" format specifier. This breaks with a UnicodeEncodeError ifthe object can only represent itself in unicode and therefore returnsunicode from __str__.`PEP 349`_ attempts to address this problem by introducing a text() builtinwhich returns str or unicode instances unmodified, and returns the resultof calling __str__() on the object otherwise. Guido preferred to insteadrelax the restrictions on str() to allow it to return unicode objects. Neilimplemented such a patch, and found that it broke only two test cases. Thediscussion stopped shortly after Neil's report however, so it was unclearif 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() orstr() objects, respectively* The file type should grow a getpos()/setpos() pair that are identical totell()/seek() when a file is open in binary mode, and which work liketell()/seek() but on characters instead of bytes when a file is open intext modeHowever, none of these seemed to be solid commitments... _PEP 349:http://www.python.org/peps/pep-0349.htmlContributing 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 otherthings, adding a __traceback__ attribute to exceptions to avoid the hassleof extracting it from sys.exc_info(). Armin pointed out that if exceptionsgrow 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 stillsome situations where cycles like this can cause problems. Armin showed anexample 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. Whengarbage 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 garbagecollection runs, it finds that the X object has not been collected, callsits __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 objectto be collected because on the second run of the garbage collection,__del__() is not called again. Thus, the refcount of the X object is notincremented, and so it is collected by garbage collection. However,guaranteeing that __del__() is called only once means keeping track somehowof which objects' __del__() methods were called, which seemed somewhatunattractive.There was also brief talk about removing __del__ in favor of weakrefs, butthose waters seemed about as murky as the garbage collection ones... _PEP 344:http://www.python.org/peps/pep-0344.htmlContributing 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 backwardscompatibility. (It was necessary when strings could be exceptions, inorder 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.htmlContributing 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 abreakpoint on the line after the loop. Ilya Sandler suggested adding anoptimal numeric argument to pdb's "next" comment to indicate how many linesof code should be skipped. Martin v. Löwis pointed out that this differsfrom gdb's "next <n>" command, which does "next" n times. Ilya suggestedimplementing 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 agood 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 inPython 2.5. The implementation is based heavily on dictobject.c, the codefor Python dict() objects, and generally deviates only when there is anobvious gain in doing so. Raymond posted his new API for discussion, butthere 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=zboilerplate 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>`__
More information about the Python-Devmailing list
[8]ページ先頭