From greg.ewing at canterbury.ac.nz Fri Aug 1 03:49:22 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 01 Aug 2008 13:49:22 +1200 Subject: [Python-Dev] Memory Error while reading large file In-Reply-To: <48922350.9030102@v.loewis.de> References: <200807311702.30163.steve@pearwood.info> <48922350.9030102@v.loewis.de> Message-ID: <48926BA2.3010108@canterbury.ac.nz> Martin v. L?wis wrote: > (maybe the use of the question mark is more typical in German > than in English; my stomach turns around when I read a question > that ends with a full stop) No, it's required in English, too. -- Greg From brett at python.org Fri Aug 1 04:20:15 2008 From: brett at python.org (Brett Cannon) Date: Thu, 31 Jul 2008 19:20:15 -0700 Subject: [Python-Dev] Looking for the email addresses of some committers Message-ID: If someone can email me the addresses for the following committers, I would appreciate it: * Greg Stein * Jackilyn Hoxworth * Jeff Senn * John Benediktsson * Mateusz Rukowicz * Richard Emslie * Roy Smith And if any of the above people no longer want commit privileges or were only given them temporarily (e.g., GSoC) that would be helpful as well. -Brett From ncoghlan at gmail.com Fri Aug 1 12:18:05 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 01 Aug 2008 20:18:05 +1000 Subject: [Python-Dev] Matrix product In-Reply-To: References: <488A8302.3050408@canterbury.ac.nz> <3d0cebfb0807291759u3716e68at7046354260c09ebc@mail.gmail.com> <4891C36E.4070200@gmail.com> Message-ID: <4892E2DD.4090704@gmail.com> Cesare Di Mauro wrote: > Nick Coghlan write: > >> Sebastien Loisel wrote: >>> Dear Raymond, >>> >>> Thank you for your email. >>> >>>> I think much of this thread is a repeat of conversations >>>> that were held for PEP 225: >>>> http://www.python.org/dev/peps/pep-0225/ >>>> >>>> That PEP is marked as deferred. Maybe it's time to >>>> bring it back to life. >>> This is a much better PEP than the one I had found, and would solve >>> all of the numpy problems. The PEP is very well thought-out. >> A very interesting read! I wouldn't support some of the more exotic >> elements tacked on to the end (particularly the replacement of the now >> thoroughly entrenched bitwise operators), but the basic idea of >> providing ~op variants of several operators seems fairly sound. I'd be >> somewhat inclined to add ~not, ~and and ~or to the list even though >> that would pretty much force the semantics to be elementwise for the ~ >> variants (since the standard not, and and or are always objectwise and >> without PEP 335 there's no way for an object to change that). >> >> Cheers, >> Nick. > > I agree: adding ~op will be very interesting. As interesting as I may have found it though, further discussion of the prospect of resurrecting it for consideration in the 2.7/3.1 timeframe should really take place on python-ideas. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From barry at barrys-emacs.org Fri Aug 1 15:06:21 2008 From: barry at barrys-emacs.org (Barry Scott) Date: Fri, 1 Aug 2008 14:06:21 +0100 Subject: [Python-Dev] 3.0 C API to decode bytes into unicode? Message-ID: I cannot see how I implement decode() for bytes objects using the C API for PyCXX library, I'd assuming that I should find a PyBytes_Decode function but cannot find it in beta 2. What is the preferred way to do this? Barry From amk at amk.ca Fri Aug 1 15:28:57 2008 From: amk at amk.ca (A.M. Kuchling) Date: Fri, 1 Aug 2008 09:28:57 -0400 Subject: [Python-Dev] Looking for the email addresses of some committers In-Reply-To: References: Message-ID: <20080801132857.GA6084@amk-desktop.matrixgroup.net> On Thu, Jul 31, 2008 at 07:20:15PM -0700, Brett Cannon wrote: > * Jackilyn Hoxworth She was a Google SoC person in 2006; since she hasn't done anything subsequently, her commit privs can be revoked. --amk From musiccomposition at gmail.com Fri Aug 1 15:29:28 2008 From: musiccomposition at gmail.com (Benjamin Peterson) Date: Fri, 1 Aug 2008 08:29:28 -0500 Subject: [Python-Dev] 3.0 C API to decode bytes into unicode? In-Reply-To: References: Message-ID: <1afaf6160808010629s66953c5dmc7470cc98ef35cd2@mail.gmail.com> On Fri, Aug 1, 2008 at 8:06 AM, Barry Scott wrote: > I cannot see how I implement decode() for bytes objects using the C API > for PyCXX library, > > I'd assuming that I should find a PyBytes_Decode function but cannot find it > in beta 2. > > What is the preferred way to do this? PyObject_CallMethod(bytesobj, "decode", "") PyUnicode_FromEncodedObject takes an encoding argument. > > Barry > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." From mal at egenix.com Fri Aug 1 15:30:39 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 01 Aug 2008 15:30:39 +0200 Subject: [Python-Dev] 3.0 C API to decode bytes into unicode? In-Reply-To: References: Message-ID: <48930FFF.9020005@egenix.com> On 2008-08-01 15:06, Barry Scott wrote: > I cannot see how I implement decode() for bytes objects using the C API > for PyCXX library, > > I'd assuming that I should find a PyBytes_Decode function but cannot > find it > in beta 2. > > What is the preferred way to do this? PyUnicode_FromEncodedObject() should to the trick. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 01 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From amauryfa at gmail.com Fri Aug 1 15:38:58 2008 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Fri, 1 Aug 2008 15:38:58 +0200 Subject: [Python-Dev] 3.0 C API to decode bytes into unicode? In-Reply-To: <1afaf6160808010629s66953c5dmc7470cc98ef35cd2@mail.gmail.com> References: <1afaf6160808010629s66953c5dmc7470cc98ef35cd2@mail.gmail.com> Message-ID: Benjamin Peterson wrote: > On Fri, Aug 1, 2008 at 8:06 AM, Barry Scott wrote: >> I cannot see how I implement decode() for bytes objects using the C API >> for PyCXX library, >> >> I'd assuming that I should find a PyBytes_Decode function but cannot find it >> in beta 2. >> >> What is the preferred way to do this? > > PyObject_CallMethod(bytesobj, "decode", "") > > PyUnicode_FromEncodedObject takes an encoding argument. There is also PyCodec_Decode() but it does not seem to be documented, nor is any function declared in codecs.h. Is it part of the public API? -- Amaury Forgeot d'Arc From mal at egenix.com Fri Aug 1 15:42:37 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 01 Aug 2008 15:42:37 +0200 Subject: [Python-Dev] 3.0 C API to decode bytes into unicode? In-Reply-To: References: <1afaf6160808010629s66953c5dmc7470cc98ef35cd2@mail.gmail.com> Message-ID: <489312CD.2060507@egenix.com> On 2008-08-01 15:38, Amaury Forgeot d'Arc wrote: > Benjamin Peterson wrote: >> On Fri, Aug 1, 2008 at 8:06 AM, Barry Scott wrote: >>> I cannot see how I implement decode() for bytes objects using the C API >>> for PyCXX library, >>> >>> I'd assuming that I should find a PyBytes_Decode function but cannot find it >>> in beta 2. >>> >>> What is the preferred way to do this? >> PyObject_CallMethod(bytesobj, "decode", "") >> >> PyUnicode_FromEncodedObject takes an encoding argument. > > There is also PyCodec_Decode() but it does not seem to be documented, > nor is any function declared in codecs.h. > Is it part of the public API? Yes, of course. I guess I never got around to writing docs for it at the time. This should basically just be a matter of converting the header file codecs.h into ReST. The APIs are all documented in that header file. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 01 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From status at bugs.python.org Fri Aug 1 18:06:26 2008 From: status at bugs.python.org (Python tracker) Date: Fri, 1 Aug 2008 18:06:26 +0200 (CEST) Subject: [Python-Dev] Summary of Python tracker Issues Message-ID: <20080801160626.6CFD278238@psf.upfronthosting.co.za> ACTIVITY SUMMARY (07/25/08 - 08/01/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1951 open (+21) / 13354 closed (+15) / 15305 total (+36) Open issues with patches: 615 Average duration of open issues: 715 days. Median duration of open issues: 1628 days. Open Issues Breakdown open 1937 (+20) pending 14 ( +1) Issues Created Or Reopened (37) _______________________________ csv.DictReader inconsistency 07/30/08 http://bugs.python.org/issue3436 reopened ncoghlan patch itertools.izip_longest docs don't specify default fillvalue 07/25/08 CLOSED http://bugs.python.org/issue3447 created alecu patch Multi-process 2to3 07/25/08 http://bugs.python.org/issue3448 created nedds patch Update decimal module to version 1.68 of the IBM specification 07/25/08 CLOSED http://bugs.python.org/issue3449 created marketdickinson patch Buy stocks now to make money 07/26/08 CLOSED http://bugs.python.org/issue3450 created nobody Asymptotically faster divmod and str(long) 07/27/08 http://bugs.python.org/issue3451 created fredrikj subprocess.Popen description unclear. 07/27/08 CLOSED http://bugs.python.org/issue3452 created lregebro PyType_Ready doesn't ensure that all bases are ready 07/27/08 http://bugs.python.org/issue3453 created rupole __getitem__() doesn't capture all slices if class inherits from 07/27/08 CLOSED http://bugs.python.org/issue3454 created johnf os.remove()method document error 07/28/08 CLOSED http://bugs.python.org/issue3455 created zkfarmer compile python using MinGW 07/28/08 http://bugs.python.org/issue3456 created xuecan Release notes for 2.6b2 call it an alpha release 07/28/08 http://bugs.python.org/issue3457 created jcd dict.update() optimisation gives unexpected/invalid results when 07/28/08 CLOSED http://bugs.python.org/issue3458 created david patch optimize bytes.join() 07/28/08 http://bugs.python.org/issue3459 created pitrou patch PyUnicode_Join could perhaps be simpler 07/28/08 http://bugs.python.org/issue3460 created pitrou patch smtplib does not fully support IPv6 in EHLO 07/28/08 http://bugs.python.org/issue3461 created dmorr patch test_builtin fails after test_decimal 07/29/08 CLOSED http://bugs.python.org/issue3462 created benjamin.peterson make life.py use more rendering characters 07/29/08 http://bugs.python.org/issue3463 created mvngu patch Python & NCURSES 07/29/08 CLOSED http://bugs.python.org/issue3464 created nandha doctest unable to use '...' for unicode literals 07/29/08 CLOSED http://bugs.python.org/issue3465 created wysek urllib2 should support HTTPS connections with client keys 07/29/08 http://bugs.python.org/issue3466 created marcelo_fernandez sqlite3 path is hard coded in setup.py 07/29/08 http://bugs.python.org/issue3467 created ericfrederich Satisfy her lovemaking desire 07/30/08 CLOSED http://bugs.python.org/issue3468 created gvanrossum Umlauts make conf.latex_documents fail 07/30/08 http://bugs.python.org/issue3469 created hoel Wrong name for getrandbits in docstring and documentation 07/30/08 CLOSED http://bugs.python.org/issue3470 created fredrikj PyObject_GetAttr() to get special methods 07/30/08 http://bugs.python.org/issue3471 created arigo Updates to "Macintosh Library Modules" Section 1.1 07/30/08 http://bugs.python.org/issue3472 created jrodman In function call, keyword arguments could follow *args 07/31/08 http://bugs.python.org/issue3473 created amaury.forgeotdarc patch Using functools.reduce() does not stop DeprecationWarning when u 07/31/08 http://bugs.python.org/issue3474 created brett.cannon _elementtree.c import can fail silently 07/31/08 http://bugs.python.org/issue3475 created naufraghi BufferedWriter not thread-safe 07/31/08 http://bugs.python.org/issue3476 created pitrou patch grammar productionlist are not properly indented 07/31/08 http://bugs.python.org/issue3477 created amaury.forgeotdarc Documentation for struct module is out of date in 3.0 07/31/08 CLOSED http://bugs.python.org/issue3478 created mgiuca patch unichr integer overflow 07/31/08 CLOSED http://bugs.python.org/issue3479 created schmir Fix_imports pattern optimization 07/31/08 http://bugs.python.org/issue3480 created nedds patch Length of struct.pack('HL', 1,1) incorrect (8 instead of 6 bytes 08/01/08 CLOSED http://bugs.python.org/issue3481 created dparolin re.split, re.sub and re.subn should support flags 08/01/08 http://bugs.python.org/issue3482 created benoit Issues Now Closed (41) ______________________ Test issue 331 days http://bugs.python.org/issue1064 loewis patch Link to call me for free 254 days http://bugs.python.org/issue1446 georg.brandl xmlrpclib.ServerProxy() doesn't use x509 data 233 days http://bugs.python.org/issue1581 benjamin.peterson operations on closed shelves fail cryptically 227 days http://bugs.python.org/issue1592 rhettinger patch Speed hack for function calls with named parameters 194 days http://bugs.python.org/issue1819 pitrou patch test_locale doesn't use unittest 189 days http://bugs.python.org/issue1864 pitrou patch Decoding UTF-7 with "ignore warnings" crashes Python on Windows 142 days http://bugs.python.org/issue2242 pitrou patch Backport PEP 3114 (__next__) 135 days http://bugs.python.org/issue2336 benjamin.peterson 26backport Fixer needed to change __builtin__ -> builtins 135 days http://bugs.python.org/issue2368 benjamin.peterson 26backport Raise Py3K warnings for comparisons that changed 135 days http://bugs.python.org/issue2373 benjamin.peterson patch, 26backport Allow Python code to change Py3k warning flag 130 days http://bugs.python.org/issue2458 benjamin.peterson patch binary buffered reading is quadratic 119 days http://bugs.python.org/issue2523 pitrou patch PyErr_ExceptionMatches must not fail 119 days http://bugs.python.org/issue2542 benjamin.peterson patch, patch Multiple buffer overflows in unicode processing 107 days http://bugs.python.org/issue2620 nnorwitz patch test issue 83 days http://bugs.python.org/issue2771 loewis *** glibc detected *** python: double free or corruption 77 days http://bugs.python.org/issue2853 benjamin.peterson re module fails to handle byte strings 78 days http://bugs.python.org/issue2860 pitrou tkinter uses MacOS 75 days http://bugs.python.org/issue2902 benjamin.peterson PyExc_BufferError is declared but nowhere defined 25 days http://bugs.python.org/issue3295 benjamin.peterson patch zipfile.writestr doesn't set external attributes, so files are e 8 days http://bugs.python.org/issue3394 pitrou patch 2to3 fails to run on Mac OS X 10.4 PPC 3.0b2 12 days http://bugs.python.org/issue3420 benjamin.peterson Test failure in test_math::testSum 6 days http://bugs.python.org/issue3421 rhettinger sphinx.doc.autodoc: Hook for changing argspec 9 days http://bugs.python.org/issue3422 pv patch robotparser.py missing one line 2 days http://bugs.python.org/issue3437 skip.montanaro Regression in "module as a script" command-line option 1 days http://bugs.python.org/issue3441 ncoghlan crash on badly initialised AttributeError 2 days http://bugs.python.org/issue3443 amaury.forgeotdarc itertools.izip_longest docs don't specify default fillvalue 0 days http://bugs.python.org/issue3447 benjamin.peterson patch Update decimal module to version 1.68 of the IBM specification 1 days http://bugs.python.org/issue3449 marketdickinson patch Buy stocks now to make money 0 days http://bugs.python.org/issue3450 amaury.forgeotdarc subprocess.Popen description unclear. 0 days http://bugs.python.org/issue3452 benjamin.peterson __getitem__() doesn't capture all slices if class inherits from 0 days http://bugs.python.org/issue3454 amaury.forgeotdarc os.remove()method document error 1 days http://bugs.python.org/issue3455 georg.brandl dict.update() optimisation gives unexpected/invalid results when 0 days http://bugs.python.org/issue3458 rhettinger patch test_builtin fails after test_decimal 1 days http://bugs.python.org/issue3462 amaury.forgeotdarc Python & NCURSES 0 days http://bugs.python.org/issue3464 amaury.forgeotdarc doctest unable to use '...' for unicode literals 0 days http://bugs.python.org/issue3465 amaury.forgeotdarc Satisfy her lovemaking desire 0 days http://bugs.python.org/issue3468 loewis Wrong name for getrandbits in docstring and documentation 0 days http://bugs.python.org/issue3470 benjamin.peterson Documentation for struct module is out of date in 3.0 0 days http://bugs.python.org/issue3478 mgiuca patch unichr integer overflow 0 days http://bugs.python.org/issue3479 amaury.forgeotdarc Length of struct.pack('HL', 1,1) incorrect (8 instead of 6 bytes 0 days http://bugs.python.org/issue3481 amaury.forgeotdarc Top Issues Most Discussed (10) ______________________________ 16 bytearrays are not thread safe 43 days open http://bugs.python.org/issue3139 15 test_builtin fails after test_decimal 1 days closed http://bugs.python.org/issue3462 15 csv.DictReader inconsistency 2 days open http://bugs.python.org/issue3436 11 Full precision summation 82 days open http://bugs.python.org/issue2819 8 os.remove()method document error 1 days closed http://bugs.python.org/issue3455 7 Update decimal module to version 1.68 of the IBM specification 1 days closed http://bugs.python.org/issue3449 6 BufferedWriter not thread-safe 1 days open http://bugs.python.org/issue3476 6 Test failure in test_math::testSum 6 days closed http://bugs.python.org/issue3421 6 Add gamma and error functions to math module 17 days open http://bugs.python.org/issue3366 6 2to3 Iterative Wildcard Matching 17 days open http://bugs.python.org/issue3358 From guido at python.org Fri Aug 1 19:58:33 2008 From: guido at python.org (Guido van Rossum) Date: Fri, 1 Aug 2008 10:58:33 -0700 Subject: [Python-Dev] Fuzzing bugs: most bugs are closed In-Reply-To: References: <200807191323.13124.victor.stinner@haypocalc.com> <200807202245.39874.victor.stinner@haypocalc.com> <20080721133319.GA15912@amk-desktop.matrixgroup.net> <200807211554.11468.victor.stinner@haypocalc.com> <20080721174141.GA16598@amk-desktop.matrixgroup.net> Message-ID: On Wed, Jul 30, 2008 at 11:17 AM, Guido van Rossum wrote: > On Mon, Jul 21, 2008 at 10:41 AM, A.M. Kuchling wrote: >> On Mon, Jul 21, 2008 at 03:53:18PM +0000, Antoine Pitrou wrote: >>> The underscore at the beginning of _sre clearly indicates that the module is >>> not recommended for direct consumption, IMO. Even the functions that don't >>> themselves start with an underscore... >> >> Sure, but if someone is trying to break in or DoS your application >> server, they don't care if the module starts with an underscore or >> not. >> >> To answer Victor's original question: the parser & compiler that turn >> a regex into bytecode is written in Python. I can't think of a way to >> prevent other Python modules from importing _sre or accessing the >> compile() function; if nothing else, code could always do 'import re ; >> re.sre_compile._sre.compile(...)'. > > I've written a re-code verifier for the Google App Engine. I have > permission to open source this, hopefully I will get to this before > 2.6 beta 3. The code is now in the bug tracker: http://bugs.python.org/issue3487 I'll hold off submitting for a while until Barry has had the time to veto it (or hopefully not :-). -- --Guido van Rossum (home page: http://www.python.org/~guido/) From fperez.net at gmail.com Fri Aug 1 20:26:41 2008 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 01 Aug 2008 11:26:41 -0700 Subject: [Python-Dev] Matrix product References: <488A8302.3050408@canterbury.ac.nz> Message-ID: Guido van Rossum wrote: > On Fri, Jul 25, 2008 at 6:50 PM, Greg Ewing > wrote: >> Sebastien Loisel wrote: >> >>> What are the odds of this thing going in? >> >> I don't know. Guido has said nothing about it so far this >> time round, and his is the only opinion that matters in the >> end. > > I'd rather stay silent until a PEP exists, but I should point out that > last time '@' was considered as a new operator, that character had no > uses in the language at all. Now it is the decorator marker. Therefore > it may not be so attractive any more. Others have indicated already how pep 225 seems to be the best current summary of this issue. Here's a concrete proposal: the SciPy conference, where a lot of people with a direct stake on this mattter will be present, will be held very soon (August 19-24 at Caltech): http://conference.scipy.org/ I am hereby volunteering to try to organize a BOF session at the conference on this topic, and can come back later with the summary. I'm also scheduled to give a talk at BayPiggies on Numpy/Scipy soon after the conference, so that may be a good opportunity to have some further discussions in person with some of you. It's probably worth noting that python is *really* growing in the scientific world. A few weeks ago I ran a session on Python for science at the annual SIAM conference (the largest applied math conference in the country), with remarkable success: http://fdoperez.blogspot.com/2008/07/python-tools-for-science-go-to-siam.html (punchline: we were selected for the annual highlights - http://www.ams.org/ams/siam-2008.html#python). This is just to show that python really matters to scientific users, and its impact is growing rapidly, as the tools mature and we reach critical mass so the network effects kick in. It would be great to see this topic considered for the language in the 2.7/3.1 timeframe, and I'm willing to help with some of the legwork. So if this idea sounds agreeable to python-dev, I'd need to know whether I should propose the BOF using pep 225 as a starting point, or if there are any other considerations on the matter I should be aware of (I've read this thread in full, but I just want to start on track since the BOF is a one-shot event). I'll obviously post this on the numpy/scipy mailing lists so those not coming to the conference can participate, but an all-hands BOF is an excellent opportunity to collect feedback and ideas from the community that is likely to care most about this feature. Thanks, f From tjreedy at udel.edu Fri Aug 1 23:57:04 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 01 Aug 2008 17:57:04 -0400 Subject: [Python-Dev] Matrix product In-Reply-To: References: <488A8302.3050408@canterbury.ac.nz> Message-ID: Fernando Perez wrote: re http://www.python.org/dev/peps/pep-0225/ > > I am hereby volunteering to try to organize a BOF session at the conference on this topic, and can come back later with the summary. I'm also scheduled to give a talk at BayPiggies on Numpy/Scipy soon after the conference, so that may be a good opportunity to have some further discussions in person with some of you. ... > So if this idea sounds agreeable to python-dev, I'd need to know whether I should propose the BOF using pep 225 as a starting point, or if there are any other considerations on the matter I should be aware of (I've read this thread in full, but I just want to start on track since the BOF is a one-shot event). I'll obviously post this on the numpy/scipy mailing lists so those not coming to the conference can participate, but an all-hands BOF is an excellent opportunity to collect feedback and ideas from the community that is likely to care most about this feature. When I read this some years ago, I was impressed by the unifying concept of operations on elements versus objects. And rereading, I plan to use the concept in writing about computation with Python. But implementing even half of the total examples with operator syntax rather than functions seemed a bit revolutionary and heavy. I am not sure I would want the number of __special__ methods nearly doubled. On the other hand, there is something to be said for orthogonality. That said, I am curious what working scientists using Python think. tjr From robert.kern at gmail.com Sat Aug 2 01:31:07 2008 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 01 Aug 2008 18:31:07 -0500 Subject: [Python-Dev] Matrix product In-Reply-To: References: <488A8302.3050408@canterbury.ac.nz> Message-ID: Terry Reedy wrote: > That said, I am curious what working scientists using Python think. Well, we'll let you know more after SciPy '08, but I suspect the answer is that they just want one teensy little wafer-thin operator to do matrix multiplication on numpy arrays or their favorite matrix object. I don't think there are many scientists/engineers/whatnot who want to double the number of operators to learn or who care if the matmult operator works on lists of lists or anything else in the standard library. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From jonas.esp at googlemail.com Sat Aug 2 01:06:01 2008 From: jonas.esp at googlemail.com (Kless) Date: Fri, 1 Aug 2008 16:06:01 -0700 (PDT) Subject: [Python-Dev] Base-96 Message-ID: I think that would be very interesting thay Python would have a module for working on base 96 too. [1] It could be converted to base 96 the digests from hashlib module, and random bytes used on crypto (to create the salt, the IV, or a key). As you can see here [2], the printable ASCII characters are 94 (decimal code range of 33-126). So only left to add another 2 characters more; the space (code 32), and one not-printable char (which doesn't create any problem) by last. [1] http://svn.python.org/view/python/trunk/Modules/binascii.c [2] http://en.wikipedia.org/wiki/ISO/IEC_8859-1 From guido at python.org Sat Aug 2 03:56:05 2008 From: guido at python.org (Guido van Rossum) Date: Fri, 1 Aug 2008 18:56:05 -0700 Subject: [Python-Dev] Base-96 In-Reply-To: References: Message-ID: This sounds more like something to bring up in python-ideas at python.org. Also, rather than being vague about the motivation ("would be very interesting", you ought to think of a realistic use case. For example, are there existing encodings of binary data using base-96? I'm not aware of any. On Fri, Aug 1, 2008 at 4:06 PM, Kless wrote: > I think that would be very interesting thay Python would have a module > for working on base 96 too. [1] > > It could be converted to base 96 the digests from hashlib module, and > random bytes used on crypto (to create the salt, the IV, or a key). > > As you can see here [2], the printable ASCII characters are 94 > (decimal code range of 33-126). So only left to add another 2 > characters more; the space (code 32), and one not-printable char > (which doesn't create any problem) by last. > > > [1] http://svn.python.org/view/python/trunk/Modules/binascii.c > [2] http://en.wikipedia.org/wiki/ISO/IEC_8859-1 -- --Guido van Rossum (home page: http://www.python.org/~guido/) From steve at holdenweb.com Sat Aug 2 04:21:16 2008 From: steve at holdenweb.com (Steve Holden) Date: Fri, 01 Aug 2008 22:21:16 -0400 Subject: [Python-Dev] Base-96 In-Reply-To: References: Message-ID: Guido van Rossum wrote: > This sounds more like something to bring up in > python-ideas at python.org. Also, rather than being vague about the > motivation ("would be very interesting", you ought to think of a > realistic use case. For example, are there existing encodings of > binary data using base-96? I'm not aware of any. > > On Fri, Aug 1, 2008 at 4:06 PM, Kless wrote: >> I think that would be very interesting thay Python would have a module >> for working on base 96 too. [1] >> >> It could be converted to base 96 the digests from hashlib module, and >> random bytes used on crypto (to create the salt, the IV, or a key). >> >> As you can see here [2], the printable ASCII characters are 94 >> (decimal code range of 33-126). So only left to add another 2 >> characters more; the space (code 32), and one not-printable char >> (which doesn't create any problem) by last. >> >> >> [1] http://svn.python.org/view/python/trunk/Modules/binascii.c >> [2] http://en.wikipedia.org/wiki/ISO/IEC_8859-1 > 96 is approximately 2^6.585 For some reason, integral powers of two seem so much more, well, POWERFUL, if you know what I mean. Frankly I think you are being either optimistic or charitable in suggesting that such a use case might exist. There's a reason that DEC called their equivalent of base64 "6-bit encoding". But then I wanted to keep integer division as it was, so I am clearly a techno-luddite. If the world wants fractional bits I'm sure it's only a matter of time before some genius decides to design a 67.9-bit computer. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From barry at barrys-emacs.org Sat Aug 2 14:49:22 2008 From: barry at barrys-emacs.org (Barry Scott) Date: Sat, 2 Aug 2008 13:49:22 +0100 Subject: [Python-Dev] 3.0 C API to decode bytes into unicode? In-Reply-To: <48930FFF.9020005@egenix.com> References: <48930FFF.9020005@egenix.com> Message-ID: <82A9AEFE-5A30-4A34-8207-E60702D00E9A@barrys-emacs.org> On Aug 1, 2008, at 14:30, M.-A. Lemburg wrote: > On 2008-08-01 15:06, Barry Scott wrote: >> I cannot see how I implement decode() for bytes objects using the >> C API >> for PyCXX library, >> I'd assuming that I should find a PyBytes_Decode function but >> cannot find it >> in beta 2. >> What is the preferred way to do this? > > PyUnicode_FromEncodedObject() should to the trick. Thanks thats what I've use. Barry From jonas.esp at googlemail.com Sat Aug 2 09:57:50 2008 From: jonas.esp at googlemail.com (Kless) Date: Sat, 2 Aug 2008 00:57:50 -0700 (PDT) Subject: [Python-Dev] Base-96 In-Reply-To: References: Message-ID: It's true, I didn't pay attention to that. So the next encoding possible would of base-128 (7-bits encoding), althought I don't know if were possible since that there would than use non-printable characters and could change the text (by use of chars. as Backspace or Delete). On 2 ago, 03:21, Steve Holden wrote: > 96 is approximately 2^6.585 > > For some reason, integral powers of two seem so much more, well, > POWERFUL, if you know what I mean. Frankly I think you are being either > optimistic or charitable in suggesting that such a use case might exist. > > There's a reason that DEC called their equivalent of base64 "6-bit > encoding". > > But then I wanted to keep integer division as it was, so I am clearly a > techno-luddite. If the world wants fractional bits I'm sure it's only a > matter of time before some genius decides to design a 67.9-bit computer. From josiah.carlson at gmail.com Sat Aug 2 18:09:12 2008 From: josiah.carlson at gmail.com (Josiah Carlson) Date: Sat, 2 Aug 2008 09:09:12 -0700 Subject: [Python-Dev] Base-96 In-Reply-To: References: Message-ID: The standard high-bit-density encoding past base-64 is base-85 (http://en.wikipedia.org/wiki/Ascii85), which encodes 4 binary bytes as 5 ascii bytes, versus 3 binary bytes as 4 ascii bytes. It works, is an RFC somewhere, ... and maybe should find it's way into the Python standard library's codec package at some point. - Josiah On Sat, Aug 2, 2008 at 12:57 AM, Kless wrote: > It's true, I didn't pay attention to that. > > So the next encoding possible would of base-128 (7-bits encoding), > althought I don't know if were possible since that there would than > use non-printable characters and could change the text (by use of > chars. as Backspace or Delete). > > On 2 ago, 03:21, Steve Holden wrote: >> 96 is approximately 2^6.585 >> >> For some reason, integral powers of two seem so much more, well, >> POWERFUL, if you know what I mean. Frankly I think you are being either >> optimistic or charitable in suggesting that such a use case might exist. >> >> There's a reason that DEC called their equivalent of base64 "6-bit >> encoding". >> >> But then I wanted to keep integer division as it was, so I am clearly a >> techno-luddite. If the world wants fractional bits I'm sure it's only a >> matter of time before some genius decides to design a 67.9-bit computer. > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/josiah.carlson%40gmail.com > From martin at v.loewis.de Sat Aug 2 19:09:57 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 02 Aug 2008 19:09:57 +0200 Subject: [Python-Dev] Base-96 In-Reply-To: References: Message-ID: <489494E5.3050306@v.loewis.de> Josiah Carlson wrote: > The standard high-bit-density encoding past base-64 is base-85 > (http://en.wikipedia.org/wiki/Ascii85), which encodes 4 binary bytes > as 5 ascii bytes, versus 3 binary bytes as 4 ascii bytes. It works, > is an RFC somewhere, RFC 1924, published on April 1, 1996, to shorten the representation of IPv6 addresses, so that you can write ssh '4)+k&C#VzJ4br>0wv%Yp' instead of having to write ssh 1080:0:0:0:8:800:200C:417A Most notably, section 7 (implementation issues) points out Many current processors do not find 128 bit integer arithmetic, as required for this technique, a trivial operation. This is not considered a serious drawback in the representation, but a flaw of the processor designs. For arbitrary-sized data, you'd have to give up 128-bit arithmetic, of course, and represent the input data to encode as a long integer. Regards, Martin P.S. Just in case it isn't clear: I would oppose any specific proposal to add this Ascii85 algorithm to the standard library. It would sound like we don't have any real problems to solve. From josiah.carlson at gmail.com Sat Aug 2 19:37:34 2008 From: josiah.carlson at gmail.com (Josiah Carlson) Date: Sat, 2 Aug 2008 10:37:34 -0700 Subject: [Python-Dev] Base-96 In-Reply-To: <489494E5.3050306@v.loewis.de> References: <489494E5.3050306@v.loewis.de> Message-ID: On Sat, Aug 2, 2008 at 10:09 AM, "Martin v. L?wis" wrote: > Josiah Carlson wrote: >> The standard high-bit-density encoding past base-64 is base-85 >> (http://en.wikipedia.org/wiki/Ascii85), which encodes 4 binary bytes >> as 5 ascii bytes, versus 3 binary bytes as 4 ascii bytes. It works, >> is an RFC somewhere, > > RFC 1924, published on April 1, 1996, to shorten the representation > of IPv6 addresses, so that you can write > > ssh '4)+k&C#VzJ4br>0wv%Yp' > > instead of having to write > > ssh 1080:0:0:0:8:800:200C:417A > > Most notably, section 7 (implementation issues) points out > > Many current processors do not find 128 bit integer arithmetic, as > required for this technique, a trivial operation. This is not > considered a serious drawback in the representation, but a flaw of > the processor designs. > > For arbitrary-sized data, you'd have to give up 128-bit arithmetic, > of course, and represent the input data to encode as a long integer. > > Regards, > Martin > > P.S. Just in case it isn't clear: I would oppose any specific proposal > to add this Ascii85 algorithm to the standard library. It would sound > like we don't have any real problems to solve. Original intent (encoding IPV6 addresses) != current usefulness (a more efficient ascii encoding of binary data). Generally, I'm of the opinion that base64 (as an ascii encoding of binary data) is sufficient for any needs I have, but there are cases where having a more efficient representation would be useful. I would also not suggest addition in the 2.6/3.0 timeframe, at best it would be 2.7/3.1, and only if someone submits a patch with testcases (note that the wiki page provides C source for one-shot encoding and decoding that doesn't require 128-bit arithmetic). Sounds to me like a project for the OP. - Josiah From guido at python.org Sat Aug 2 20:57:37 2008 From: guido at python.org (Guido van Rossum) Date: Sat, 2 Aug 2008 11:57:37 -0700 Subject: [Python-Dev] Base-96 In-Reply-To: References: <489494E5.3050306@v.loewis.de> Message-ID: On Sat, Aug 2, 2008 at 10:37 AM, Josiah Carlson wrote: > On Sat, Aug 2, 2008 at 10:09 AM, "Martin v. L?wis" wrote: >> Josiah Carlson wrote: >>> The standard high-bit-density encoding past base-64 is base-85 >>> (http://en.wikipedia.org/wiki/Ascii85), which encodes 4 binary bytes >>> as 5 ascii bytes, versus 3 binary bytes as 4 ascii bytes. It works, >>> is an RFC somewhere, >> >> RFC 1924, published on April 1, 1996, to shorten the representation >> of IPv6 addresses, so that you can write >> >> ssh '4)+k&C#VzJ4br>0wv%Yp' >> >> instead of having to write >> >> ssh 1080:0:0:0:8:800:200C:417A >> >> Most notably, section 7 (implementation issues) points out >> >> Many current processors do not find 128 bit integer arithmetic, as >> required for this technique, a trivial operation. This is not >> considered a serious drawback in the representation, but a flaw of >> the processor designs. >> >> For arbitrary-sized data, you'd have to give up 128-bit arithmetic, >> of course, and represent the input data to encode as a long integer. >> >> Regards, >> Martin >> >> P.S. Just in case it isn't clear: I would oppose any specific proposal >> to add this Ascii85 algorithm to the standard library. It would sound >> like we don't have any real problems to solve. Same here. > Original intent (encoding IPV6 addresses) != current usefulness (a > more efficient ascii encoding of binary data). That was an April Fool's RFC. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From solipsis at pitrou.net Sat Aug 2 21:58:50 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 2 Aug 2008 19:58:50 +0000 (UTC) Subject: [Python-Dev] Base-85 References: <489494E5.3050306@v.loewis.de> Message-ID: Martin v. L?wis v.loewis.de> writes: > > P.S. Just in case it isn't clear: I would oppose any specific proposal > to add this Ascii85 algorithm to the standard library. It would sound > like we don't have any real problems to solve. According to Wikipedia, "its main modern use is in Adobe's PostScript and Portable Document Format file formats". It is also used by git for diffs of binary files, and those diffs are supposedly understood by other VCSes like Mercurial... indeed, Mercurial has a Python extension for base85 encoding (but licensed under the GPL): http://selenic.com/hg/index.cgi/file/cbdfd08eabc9/mercurial/base85.c (I suppose Bazaar has something similar) Endly, since this encoding allows to pack more bytes into the same number of ASCII characters than its traditional alternatives, it is likely to gain traction in applications which need to create a pure ASCII representation of binary data. Regards Antoine. From guido at python.org Sat Aug 2 23:07:27 2008 From: guido at python.org (Guido van Rossum) Date: Sat, 2 Aug 2008 14:07:27 -0700 Subject: [Python-Dev] Base-85 In-Reply-To: References: <489494E5.3050306@v.loewis.de> Message-ID: On Sat, Aug 2, 2008 at 12:58 PM, Antoine Pitrou wrote: > It is also used by git for diffs of binary files, and those diffs are supposedly > understood by other VCSes like Mercurial... I'm very interested in this (for Rietveld). Where can I learn more about how git handles diffs of binary files? Does it actually show adds and deletes of sections of the file? -- --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Sat Aug 2 23:15:29 2008 From: guido at python.org (Guido van Rossum) Date: Sat, 2 Aug 2008 14:15:29 -0700 Subject: [Python-Dev] Base-96 In-Reply-To: References: <489494E5.3050306@v.loewis.de> Message-ID: On Sat, Aug 2, 2008 at 11:57 AM, Guido van Rossum wrote: > That was an April Fool's RFC. See also http://en.wikipedia.org/wiki/April_Fools%27_Day_RFC -- it has a ton of these. Great fun reading through some of them on an idle Saturday afternoon. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) From solipsis at pitrou.net Sat Aug 2 23:34:18 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 02 Aug 2008 23:34:18 +0200 Subject: [Python-Dev] Base-85 In-Reply-To: References: <489494E5.3050306@v.loewis.de> Message-ID: <1217712858.26455.7.camel@fsol> Le samedi 02 ao?t 2008 ? 14:07 -0700, Guido van Rossum a ?crit : > On Sat, Aug 2, 2008 at 12:58 PM, Antoine Pitrou wrote: > > It is also used by git for diffs of binary files, and those diffs are supposedly > > understood by other VCSes like Mercurial... > > I'm very interested in this (for Rietveld). Where can I learn more > about how git handles diffs of binary files? Does it actually show > adds and deletes of sections of the file? > Well, I'm not sure. I just tried with Mercurial, first committing a binary file with the following structure: part1 part3 and then changing it to the following structure: part1 part2 part3 part2 (part{1,2,3} being some binary chunks of 400 bytes each from /dev/urandom) The "git-style" diff given by Mercurial is then: diff --git a/binfile b/binfile index acfa6ffc5287c6e9cd400af7b8ab09d072a28b02..5b9a69212ae8f39bf41fbf2194db2b730dcb0ae9 GIT binary patch literal 1600 zc%1Fi`#%#1003~2SQat~^D2)~Q>OB2Y-`ijkz&}wZbC#-o=0t7jaVepQ|D0_8*3gJ zMSY0rj%^W39zC2fTEo0 at yVCs|_rrbvhcAJotX5m|hB+RX(Aa5xSa4Y^GkS%y10Hva z3^q{I&mAF9vs at GpEP1!lCxtq*vdKD&+M&87%65P%egC&>7+Bgzx0-lUziyCW?%ELc z;eHsAnXOY+YY~y3f6~CD+?JujZGa*JV=V-x-twhC^~z}e+->VcW=&UqfNg97Mxf3d zP2!VM#<4|n+(B|5rOUMBfQ=w}vEdoi_TK&saEG1S{mn at ndj^rKLkR~K7EJZGGO3U9 zqYkn__U%akFI(fHNxLoP?qI1sW!5 at Div?MoBQU<}W8T2DXa{`gkjO1RO?{-Yz3 z-yd-sVx%pSu0elCXI*-RPErV~&bEbl*yk6ff?mVpWHk^!$4x~AJ$M!$>LrjA^UDjlQD0igDHf?>kfTL8C zT`$ToUViVhgSRSdJij81#v>3jDpj>m&hGZ(a4UQqYSc{FI)@&=mHL-D&8&McIqHsU zfI-aCDfNmLo!AZjn=0JV{sMJcsTSiO;$}r>P(?>*s6&cpc-Lu5__+c38NPW>O=Ze3 zuFNT^b+XahK^P*sIU93zA4btzW?3CiviE&Xi9>Bo zUeM*=71Le)&!sv725-*vgS1naIlau zItQO-*hG^8yP=|O<8TL=MWBR_ts5qYMlzBvx9 at assRs0B-+%0N-!#0o=9E#}7KwgS zL(7(rp`ZFnuqIS(+L{IckNZ%BsAvS7nS6!Qvhd<7{m}yj9>#ZU at DGy9C0o;vRo8VN z{7^{BvC^#ss2zI20|7B%d7&`+;}M|Lb4kcpnT&a>ztw$PNWnC?zuEIbUm<$TLPu{@ zFY}#Iu~hB^StZra*ohA%zVI_1hLduWZa6S~5X9x-A^(HQYtpfwIrX2BO0ucP;atl( z9w7PlD`@LzhQ`qgJ$YA&U#BnZ>E7FQ)o02 at hJW4jTYGs3*i0#Kwn2EEC`iaj#%!n! zBp#{xc{d%j`Q}GwfJ*5YN5L1jO$egiqV_Dr=2I4()xVmuAhxjtq%Tv8Xpj0eNbDC` zr)~pTMOKjpr4)Ts!=w3K?TKMAmsB;SKU4G(tZRNi_28i83YGM!sFTf at cL9z%07l$5 zz=K?Re2pPf)sp-XNp`QKAIQ}l7Qjr5SbMa;Q&#UT4(|#}kQ>Zx58&XEdwZV}rT}gi zAJ(u*feBc}#SFv;?WH=Nl}c*ntY4Tbs at l#;Ya(NdbFhN{QV43Y-kINHGC2 at E)ms1` zEe~IK=-G~B2d_gQ&0mTKxO#ub8Q)9wI!6xVMVM}&lvlFHsV+BT+H~fhnnW~!EEnc+ zD=DAs=Y01@@>AfcR=Yz7$Z5mZ8P~c0From that I don't know what can be done with the diff. Looking at the Mercurial source code suggests that you can encode deltas in the patch, but that Mercurial doesn't support it (see "# TODO: deltas"): http://www.selenic.com/hg/index.cgi/file/cbdfd08eabc9/mercurial/patch.py#l1117 A basic explanation of binary diffs here: http://www.selenic.com/pipermail/mercurial/2008-July/020184.html The explanation mentions base-64 but it was corrected in a later message here: http://www.selenic.com/pipermail/mercurial/2008-July/020192.html Regards Antoine. PS: here are the commands I've typed: $ hg init bindiff $ cd bindiff/ $ dd if=/dev/urandom of=part1 bs=1 count=400 [snip output] $ dd if=/dev/urandom of=part2 bs=1 count=400 [snip output] $ dd if=/dev/urandom of=part3 bs=1 count=400 [snip output] $ cat part1 part3 > binfile $ hg add binfile $ hg ci -m "added binfile" $ cat part1 part2 part3 > binfile $ hg di diff -r 19cfb10c4a01 binfile Binary file binfile has changed $ hg di --git [produces the patch above] From brett at python.org Sun Aug 3 00:46:42 2008 From: brett at python.org (Brett Cannon) Date: Sat, 2 Aug 2008 15:46:42 -0700 Subject: [Python-Dev] What to do with uuid? Message-ID: I was running the test suite and I noticed test_uuid's warning message is still up: test_uuid WARNING: uuid.getnode is unreliable on many platforms. It is disabled until the code and/or test can be fixed properly. WARNING: uuid._ifconfig_getnode is unreliable on many platforms. It is disabled until the code and/or test can be fixed properly. WARNING: uuid._unixdll_getnode is unreliable on many platforms. It is disabled until the code and/or test can be fixed properly. The state of uuid has been like this for a while now. Are we going to actively try to fix this, or was uuid a mistake? I guess my real question is how long are we willing to let the code sit in this partial state before we decide the module just is not getting enough attention? -Brett From greg.ewing at canterbury.ac.nz Sun Aug 3 03:35:36 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sun, 03 Aug 2008 13:35:36 +1200 Subject: [Python-Dev] Base-95 (Re: Base-96) In-Reply-To: References: Message-ID: <48950B68.6000605@canterbury.ac.nz> Kless wrote: > So the next encoding possible would of base-128 (7-bits encoding) A while ago I wanted to pack as much information as possible into a string of printable characters, and I came up with a base-95 encoding that packs 9 bytes into 11 characters. The application involved representing data using Python string literals, so it was important that only printable characters were used. I settled on the 9/11 combination as a reasonable compromise between packing efficiency and not having the block size too long. If anyone's interested, I could dig out the encoding and decoding routines I wrote. -- Greg From phd at phd.pp.ru Sun Aug 3 11:19:48 2008 From: phd at phd.pp.ru (Oleg Broytmann) Date: Sun, 3 Aug 2008 13:19:48 +0400 Subject: [Python-Dev] April 1st jokes (was: Base-96) In-Reply-To: References: <489494E5.3050306@v.loewis.de> Message-ID: <20080803091948.GB5866@phd.pp.ru> On Sat, Aug 02, 2008 at 02:15:29PM -0700, Guido van Rossum wrote: > On Sat, Aug 2, 2008 at 11:57 AM, Guido van Rossum wrote: > > That was an April Fool's RFC. > > See also http://en.wikipedia.org/wiki/April_Fools%27_Day_RFC -- it has > a ton of these. Great fun reading through some of them on an idle > Saturday afternoon. :-) There were a lot of Python jokes for the Apr 1st. What a pity we have ceased to make such jokes. http://mail.python.org/pipermail/python-list/2001-April/076593.html http://mail.python.org/pipermail/python-list/2003-April/197232.html http://mail.python.org/pipermail/python-list/2004-April/256320.html (Despite being a joke it really works!) http://mail.python.org/pipermail/python-list/2005-April/315453.html http://mail.python.org/pipermail/python-list/2005-April/315457.html http://mail.python.org/pipermail/python-list/2006-April/375866.html Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From g.brandl at gmx.net Sun Aug 3 11:24:36 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Sun, 03 Aug 2008 11:24:36 +0200 Subject: [Python-Dev] April 1st jokes In-Reply-To: <20080803091948.GB5866@phd.pp.ru> References: <489494E5.3050306@v.loewis.de> <20080803091948.GB5866@phd.pp.ru> Message-ID: Oleg Broytmann schrieb: > On Sat, Aug 02, 2008 at 02:15:29PM -0700, Guido van Rossum wrote: >> On Sat, Aug 2, 2008 at 11:57 AM, Guido van Rossum wrote: >> > That was an April Fool's RFC. >> >> See also http://en.wikipedia.org/wiki/April_Fools%27_Day_RFC -- it has >> a ton of these. Great fun reading through some of them on an idle >> Saturday afternoon. :-) > > There were a lot of Python jokes for the Apr 1st. What a pity we have > ceased to make such jokes. You forget the April 1st PEPs: http://www.python.org/dev/peps/pep-0313/ http://www.python.org/dev/peps/pep-3117/ Georg From guido at python.org Sun Aug 3 16:56:16 2008 From: guido at python.org (Guido van Rossum) Date: Sun, 3 Aug 2008 07:56:16 -0700 Subject: [Python-Dev] April 1st jokes (was: Base-96) In-Reply-To: <20080803091948.GB5866@phd.pp.ru> References: <489494E5.3050306@v.loewis.de> <20080803091948.GB5866@phd.pp.ru> Message-ID: Hm, I'm sure there were many more, perhaps in different places. I recall participating with Larry Wall in the announcement of Parrot, a Python/Perl merger -- hence the name of the Perl 6 VM. And others. I'd love to see people post more references here! (Georg already posted the April Fool's PEPs.) On Sun, Aug 3, 2008 at 2:19 AM, Oleg Broytmann wrote: > On Sat, Aug 02, 2008 at 02:15:29PM -0700, Guido van Rossum wrote: >> On Sat, Aug 2, 2008 at 11:57 AM, Guido van Rossum wrote: >> > That was an April Fool's RFC. >> >> See also http://en.wikipedia.org/wiki/April_Fools%27_Day_RFC -- it has >> a ton of these. Great fun reading through some of them on an idle >> Saturday afternoon. :-) > > There were a lot of Python jokes for the Apr 1st. What a pity we have > ceased to make such jokes. > > http://mail.python.org/pipermail/python-list/2001-April/076593.html > > http://mail.python.org/pipermail/python-list/2003-April/197232.html > > http://mail.python.org/pipermail/python-list/2004-April/256320.html > (Despite being a joke it really works!) > > http://mail.python.org/pipermail/python-list/2005-April/315453.html > > http://mail.python.org/pipermail/python-list/2005-April/315457.html > > http://mail.python.org/pipermail/python-list/2006-April/375866.html > > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru > Programmers don't die, they just GOSUB without RETURN. > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From p.f.moore at gmail.com Sun Aug 3 18:17:36 2008 From: p.f.moore at gmail.com (Paul Moore) Date: Sun, 3 Aug 2008 17:17:36 +0100 Subject: [Python-Dev] Issue with distutils and new mingw binutils Message-ID: <79990c6b0808030917w362446a1p90e2ca15b9cfd8f7@mail.gmail.com> Can I draw python-dev's attention to http://bugs.python.org/issue3496 ? Without this fix, distutils doesn't support the new version of binutils (which is probably coming into more common use). It would be good if this could be fixed for 2.6. I've attached a patch to the issue report, could someone possibly check it over and apply if appropriate? Thanks, Paul. From skip at pobox.com Sun Aug 3 19:37:42 2008 From: skip at pobox.com (skip at pobox.com) Date: Sun, 3 Aug 2008 12:37:42 -0500 Subject: [Python-Dev] April 1st jokes (was: Base-96) In-Reply-To: References: <489494E5.3050306@v.loewis.de> <20080803091948.GB5866@phd.pp.ru> Message-ID: <18581.60646.443926.686619@montanaro-dyndns-org.local> Guido> Hm, I'm sure there were many more, perhaps in different places. I figured it's a slow Sunday so I'd collect them on the wiki: http://wiki.python.org/moin/AprilFools I found the Python/Perl joint development press release, but only on the Wayback machine. It appears that when redesigning the python.org website that page was deemed inappropriate. Skip From stavros at korokithakis.net Sun Aug 3 19:44:02 2008 From: stavros at korokithakis.net (Stavros Korokithakis) Date: Sun, 03 Aug 2008 20:44:02 +0300 Subject: [Python-Dev] String concatenation Message-ID: <4895EE62.8080605@korokithakis.net> Hello, is concatenation of adjacent strings a useful feature? So far the only use case I've seen is causing me endless hours of debugging when I forget the comma in a tuple of strings, like so: ("first", "second" "third") Which then becomes a tuple of two items, instead of three. It would have been much better if it produced an error. Is there any good reason that this feature exists, or would it be better if it were removed? Regards, Stavros Korokithakis From fuzzyman at voidspace.org.uk Sun Aug 3 20:03:12 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 03 Aug 2008 19:03:12 +0100 Subject: [Python-Dev] String concatenation In-Reply-To: <4895EE62.8080605@korokithakis.net> References: <4895EE62.8080605@korokithakis.net> Message-ID: <4895F2E0.5040709@voidspace.org.uk> Stavros Korokithakis wrote: > Hello, > is concatenation of adjacent strings a useful feature? So far the only > use case I've seen is causing me endless hours of debugging when I > forget the comma in a tuple of strings, like so: > > ("first", > "second" > "third") > > Which then becomes a tuple of two items, instead of three. It would > have been much better if it produced an error. Is there any good > reason that this feature exists, or would it be better if it were > removed? It can be a very useful feature. See the rejected PEP 3126 for a discussion: http://www.python.org/dev/peps/pep-3126/ Michael Foord > > Regards, > Stavros Korokithakis > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From tseaver at palladion.com Sun Aug 3 20:04:01 2008 From: tseaver at palladion.com (Tres Seaver) Date: Sun, 03 Aug 2008 14:04:01 -0400 Subject: [Python-Dev] String concatenation In-Reply-To: <4895EE62.8080605@korokithakis.net> References: <4895EE62.8080605@korokithakis.net> Message-ID: <4895F311.60200@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stavros Korokithakis wrote: > Hello, > is concatenation of adjacent strings a useful feature? So far the only > use case I've seen is causing me endless hours of debugging when I > forget the comma in a tuple of strings, like so: > > ("first", > "second" > "third") > > Which then becomes a tuple of two items, instead of three. It would have > been much better if it produced an error. Is there any good reason that > this feature exists, or would it be better if it were removed? - -1. The feature exists to allow adherence to PEP-8, "Limit all lines to a maximum of 79 characters.", without requiring runtime concatenation costs. I use it frequently when assembling and testing message strings, for instance. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIlfMR+gerLs4ltQ4RAjc/AJ9QiO4EWMfamHwyRLaZ+cowu8bT9gCbB+/Y 979rSOIrbRs8lYW3T8Kv6WE= =NSdL -----END PGP SIGNATURE----- From stavros at korokithakis.net Sun Aug 3 20:12:14 2008 From: stavros at korokithakis.net (Stavros Korokithakis) Date: Sun, 03 Aug 2008 21:12:14 +0300 Subject: [Python-Dev] String concatenation In-Reply-To: <4895F2E0.5040709@voidspace.org.uk> References: <4895EE62.8080605@korokithakis.net> <4895F2E0.5040709@voidspace.org.uk> Message-ID: <4895F4FE.3040102@korokithakis.net> Hmm, thanks, although I don't see why it was rejected, since it seems to me that by using the addition operator or triple-quoting all the use cases would become clearer and not significantly harder to write, while the (often silent) errors would not happen any more. The PEP only mentions that "the feature to be removed isn't all that harmful, and there are some use cases that would become harder", but I'm not sure that the "harder use cases" (which ones?) justify the error potential. Stavros Korokithakis Michael Foord wrote: > Stavros Korokithakis wrote: >> Hello, >> is concatenation of adjacent strings a useful feature? So far the only >> use case I've seen is causing me endless hours of debugging when I >> forget the comma in a tuple of strings, like so: >> >> ("first", >> "second" >> "third") >> >> Which then becomes a tuple of two items, instead of three. It would >> have been much better if it produced an error. Is there any good >> reason that this feature exists, or would it be better if it were >> removed? > > It can be a very useful feature. > > See the rejected PEP 3126 for a discussion: > > http://www.python.org/dev/peps/pep-3126/ > > Michael Foord > >> >> Regards, >> Stavros Korokithakis >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk >> > > From solipsis at pitrou.net Sun Aug 3 20:29:43 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 3 Aug 2008 18:29:43 +0000 (UTC) Subject: [Python-Dev] String concatenation References: <4895EE62.8080605@korokithakis.net> <4895F311.60200@palladion.com> Message-ID: Tres Seaver palladion.com> writes: > > -1. The feature exists to allow adherence to PEP-8, "Limit all lines to > a maximum of 79 characters.", without requiring runtime concatenation > costs. I use it frequently when assembling and testing message strings, > for instance. In many cases there is no runtime concatenation cost. >>> def f(): ... return "first" + "second" ... >>> import dis >>> dis.dis(f) 2 0 LOAD_CONST 3 ('firstsecond') 3 RETURN_VALUE Regards Antoine. From hodgestar at gmail.com Sun Aug 3 20:38:33 2008 From: hodgestar at gmail.com (Simon Cross) Date: Sun, 3 Aug 2008 20:38:33 +0200 Subject: [Python-Dev] String concatenation In-Reply-To: References: <4895EE62.8080605@korokithakis.net> <4895F311.60200@palladion.com> Message-ID: On Sun, Aug 3, 2008 at 8:29 PM, Antoine Pitrou wrote: > In many cases there is no runtime concatenation cost. > >>>> def f(): > ... return "first" + "second" > ... >>>> import dis >>>> dis.dis(f) > 2 0 LOAD_CONST 3 ('firstsecond') > 3 RETURN_VALUE The "many cases" only extends to strings whose combined length is less than 20 characters: >>> dis.dis(lambda : "1234567890123456789" + "0") 1 0 LOAD_CONST 2 ('12345678901234567890') 3 RETURN_VALUE >>> dis.dis(lambda : "1234567890123456789" + "01") 1 0 LOAD_CONST 0 ('1234567890123456789') 3 LOAD_CONST 1 ('01') 6 BINARY_ADD 7 RETURN_VALUE Adjacent string concentation works on arbitrary length string constants: >>> dis.dis(lambda : "12345678901234567890" "12345678901234567890") 1 0 LOAD_CONST 0 ('1234567890123456789012345678901234567890') 3 RETURN_VALUE From solipsis at pitrou.net Sun Aug 3 20:49:17 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 03 Aug 2008 20:49:17 +0200 Subject: [Python-Dev] String concatenation In-Reply-To: References: <4895EE62.8080605@korokithakis.net> <4895F311.60200@palladion.com> Message-ID: <1217789357.5816.0.camel@fsol> Le dimanche 03 ao?t 2008 ? 20:38 +0200, Simon Cross a ?crit : > The "many cases" only extends to strings whose combined length is less > than 20 characters: Oops. I didn't know that. Is there any rationale (I suppose so)? From brett at python.org Sun Aug 3 21:49:54 2008 From: brett at python.org (Brett Cannon) Date: Sun, 3 Aug 2008 12:49:54 -0700 Subject: [Python-Dev] new mailing list: python-committers Message-ID: I figured I would send out a quick email to let people know of the existence of a new mailing list: python-committers (http://mail.python.org/mailman/listinfo/python-committers) so that no one thinks something sneaky is going on behind the scenes. It is invite-only, but publicly archived. The point of the list is for stuff like when the repository is off-limits to commits or to discuss release dates, etc.; basically stuff where every committer needs to be aware of something and input from the community is not needed. That way nothing important gets drowned out in python-dev by accident. At this point all committers should be subscribed to the list. But almost all discussions will continue to be on python-ideas, python-dev, and python-3000. Any new proposals should continue to go to python-ideas first (since those discussions tend to be the noisiest, and people should feel okay to tell people quickly that a discussion should be moved over to python-ideas), and then stuff about developing Python should go to python-dev or python-3000 since some community input is almost always good and practically every developer still reads python-dev anyway. -Brett From ncoghlan at gmail.com Mon Aug 4 00:49:52 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 04 Aug 2008 08:49:52 +1000 Subject: [Python-Dev] String concatenation In-Reply-To: <4895F4FE.3040102@korokithakis.net> References: <4895EE62.8080605@korokithakis.net> <4895F2E0.5040709@voidspace.org.uk> <4895F4FE.3040102@korokithakis.net> Message-ID: <48963610.1000206@gmail.com> Stavros Korokithakis wrote: > Hmm, thanks, although I don't see why it was rejected, since it seems to > me that by using the addition operator or triple-quoting all the use > cases would become clearer and not significantly harder to write, while > the (often silent) errors would not happen any more. > > The PEP only mentions that "the feature to be removed isn't all that > harmful, and there are some use cases that would become harder", but I'm > not sure that the "harder use cases" (which ones?) justify the error > potential. As I recall, removing implicit string concatenation simply resulted in too much code breakage for not enough benefit. There is also the minor(!) issue of breaking il8n tools that understand implicit string concatenation but not string addition. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From greg.ewing at canterbury.ac.nz Mon Aug 4 03:32:02 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Mon, 04 Aug 2008 13:32:02 +1200 Subject: [Python-Dev] April 1st jokes In-Reply-To: References: <489494E5.3050306@v.loewis.de> <20080803091948.GB5866@phd.pp.ru> Message-ID: <48965C12.9060600@canterbury.ac.nz> Guido van Rossum wrote: > Hm, I'm sure there were many more, perhaps in different places. Although it wasn't April 1, here's one I posted in response to python-dev discussions. http://mail.python.org/pipermail/python-list/2001-May/084169.html There was also another one concerning how to reduce the number of ways of copying a list, but Google doesn't seem to want to find it. -- Greg From guido at python.org Mon Aug 4 04:21:12 2008 From: guido at python.org (Guido van Rossum) Date: Sun, 3 Aug 2008 19:21:12 -0700 Subject: [Python-Dev] April 1st jokes (was: Base-96) In-Reply-To: <18581.60646.443926.686619@montanaro-dyndns-org.local> References: <489494E5.3050306@v.loewis.de> <20080803091948.GB5866@phd.pp.ru> <18581.60646.443926.686619@montanaro-dyndns-org.local> Message-ID: On Sun, Aug 3, 2008 at 10:37 AM, wrote: > > Guido> Hm, I'm sure there were many more, perhaps in different places. > > I figured it's a slow Sunday so I'd collect them on the wiki: > > http://wiki.python.org/moin/AprilFools Great! > I found the Python/Perl joint development press release, but only on the > Wayback machine. It appears that when redesigning the python.org website > that page was deemed inappropriate. Alas, way too much stuff was dropped by the redesign. ;-( I should track down the Tim Peters award (or whatever it was called) and link that. We should probably cross-link with the Python humor page on python.org (unless that's also been axed). -- --Guido van Rossum (home page: http://www.python.org/~guido/) From aahz at pythoncraft.com Mon Aug 4 05:43:30 2008 From: aahz at pythoncraft.com (Aahz) Date: Sun, 3 Aug 2008 20:43:30 -0700 Subject: [Python-Dev] April 1st jokes (was: Base-96) In-Reply-To: References: <489494E5.3050306@v.loewis.de> <20080803091948.GB5866@phd.pp.ru> <18581.60646.443926.686619@montanaro-dyndns-org.local> Message-ID: <20080804034329.GB12449@panix.com> On Sun, Aug 03, 2008, Guido van Rossum wrote: > On Sun, Aug 3, 2008 at 10:37 AM, wrote: >> >> I found the Python/Perl joint development press release, but only on the >> Wayback machine. It appears that when redesigning the python.org website >> that page was deemed inappropriate. > > Alas, way too much stuff was dropped by the redesign. ;-( > > I should track down the Tim Peters award (or whatever it was called) > and link that. > > We should probably cross-link with the Python humor page on python.org > (unless that's also been axed). IIRC, the humor page was axed due to lack of updates -- I recommend finding the material using Wayback and just adding it to the wiki. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ Adopt A Process -- stop killing all your children! From paul at eventuallyanyway.com Mon Aug 4 08:27:13 2008 From: paul at eventuallyanyway.com (Paul Hummer) Date: Mon, 04 Aug 2008 00:27:13 -0600 Subject: [Python-Dev] Py3k tasks spreadsheet Message-ID: <4896A141.2020006@eventuallyanyway.com> I'm not sure if this should go here or the python3000 list, but I think it probably fits a bit better here, as it has to do with development. I'm putting together a small sprint for our newly formed Python group here locally, and I stumbled across this Google doc with Py3k tasks that need completed. It's found here: http://spreadsheets.google.com/ccc?key=pBLWM8elhFAmKbrhhh0ApQA How up to date is this? Could we base some sprint tasks off of some of the things that are on there? I see mention of earlier versions of Py3k, so I thought I'd confirm. There are quite a few tasks there that an experienced Python coder could probably hammer out in a weekend (if not sooner). If this spreadsheet is out of date, is there a current list of tasks somewhere else that might help us to set some goals and provide some help to Py3k development? What about python 2.x development? Thanks, Paul From solipsis at pitrou.net Mon Aug 4 10:42:21 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 4 Aug 2008 08:42:21 +0000 (UTC) Subject: [Python-Dev] Py3k tasks spreadsheet References: <4896A141.2020006@eventuallyanyway.com> Message-ID: Hi, Welcome to python-3000! > How up to date is this? Probably way out of date. The best way to find tasks is to go to the tracker (bugs.python.org) and search for issues tagged with version 3.0. Preferably the "release blocker", "critical" or "high priority" ones (there are quite a lot of them :-)). Regards Antoine. From steve at holdenweb.com Mon Aug 4 14:11:32 2008 From: steve at holdenweb.com (Steve Holden) Date: Mon, 04 Aug 2008 08:11:32 -0400 Subject: [Python-Dev] April 1st jokes In-Reply-To: References: <489494E5.3050306@v.loewis.de> <20080803091948.GB5866@phd.pp.ru> Message-ID: Georg Brandl wrote: > Oleg Broytmann schrieb: >> On Sat, Aug 02, 2008 at 02:15:29PM -0700, Guido van Rossum wrote: >>> On Sat, Aug 2, 2008 at 11:57 AM, Guido van Rossum >>> wrote: >>> > That was an April Fool's RFC. >>> >>> See also http://en.wikipedia.org/wiki/April_Fools%27_Day_RFC -- it has >>> a ton of these. Great fun reading through some of them on an idle >>> Saturday afternoon. :-) >> >> There were a lot of Python jokes for the Apr 1st. What a pity we have >> ceased to make such jokes. > > You forget the April 1st PEPs: > > http://www.python.org/dev/peps/pep-0313/ > http://www.python.org/dev/peps/pep-3117/ > Not to mention the April 1 Licensing blog entry: http://pyfound.blogspot.com/2006/04/python-25-licensing-change.html regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From barry at python.org Mon Aug 4 14:20:18 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 4 Aug 2008 08:20:18 -0400 Subject: [Python-Dev] Py3k tasks spreadsheet In-Reply-To: References: <4896A141.2020006@eventuallyanyway.com> Message-ID: <5163A5B6-B3FA-46C5-AB0A-D246658CD394@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 4, 2008, at 4:42 AM, Antoine Pitrou wrote: >> How up to date is this? > > Probably way out of date. > The best way to find tasks is to go to the tracker (bugs.python.org) > and search > for issues tagged with version 3.0. Preferably the "release > blocker", "critical" > or "high priority" ones (there are quite a lot of them :-)). Just to add: there's also a 'deferred blocker' state, but right now there are no issues with that priority. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSJb0AnEjvBPtnXfVAQJOOQP/b+5FlpYzSTj52TEC5JQ5GoZC4d5Wdl3I vpJ7N8HRXF1Alimzo1001x//6UYl0T55HhwXbBcmJCwkXo9keqFY6noL1R8mGRAn pQP8jtFQPHz8l6SYVd1caKUjp4DTFcXYUDyeO915WTjynnX1IiwEVz8yEPqGQL9J k/yaQLwN9F4= =IeT/ -----END PGP SIGNATURE----- From skip at pobox.com Mon Aug 4 20:12:08 2008 From: skip at pobox.com (skip at pobox.com) Date: Mon, 4 Aug 2008 13:12:08 -0500 Subject: [Python-Dev] April 1st jokes (was: Base-96) In-Reply-To: <20080804034329.GB12449@panix.com> References: <489494E5.3050306@v.loewis.de> <20080803091948.GB5866@phd.pp.ru> <18581.60646.443926.686619@montanaro-dyndns-org.local> <20080804034329.GB12449@panix.com> Message-ID: <18583.18040.814142.664878@montanaro-dyndns-org.local> >> We should probably cross-link with the Python humor page on >> python.org (unless that's also been axed). >> aahz> IIRC, the humor page was axed due to lack of updates -- I aahz> recommend finding the material using Wayback and just adding it to aahz> the wiki. It's still there: http://www.python.org/doc/humor/ it's just been absorbed into the documentation. ;-) I can't find Tim Peters' award page and don't know if you can search the Wayback Machine. (I suspect you have to know a precise URL.) Skip From brett at python.org Mon Aug 4 21:03:15 2008 From: brett at python.org (Brett Cannon) Date: Mon, 4 Aug 2008 12:03:15 -0700 Subject: [Python-Dev] Py3k tasks spreadsheet In-Reply-To: References: <4896A141.2020006@eventuallyanyway.com> Message-ID: On Mon, Aug 4, 2008 at 1:42 AM, Antoine Pitrou wrote: > > Hi, > > Welcome to python-3000! > >> How up to date is this? > > Probably way out of date. It isn't "probably", is just is. =) > The best way to find tasks is to go to the tracker (bugs.python.org) and search > for issues tagged with version 3.0. Preferably the "release blocker", "critical" > or "high priority" ones (there are quite a lot of them :-)). If you look in the left-hand column at the tracker you will see a Showstoppers search; that will list all of the current release blockers. Otherwise what Antoine suggested about going through critical issues good. High has some importance, but not as much. And unclassified issues might fall into one of the categories but just need someone to look at them and make a judgment call. -Brett From guido at python.org Mon Aug 4 22:09:09 2008 From: guido at python.org (Guido van Rossum) Date: Mon, 4 Aug 2008 13:09:09 -0700 Subject: [Python-Dev] April 1st jokes (was: Base-96) In-Reply-To: <18583.18040.814142.664878@montanaro-dyndns-org.local> References: <20080803091948.GB5866@phd.pp.ru> <18581.60646.443926.686619@montanaro-dyndns-org.local> <20080804034329.GB12449@panix.com> <18583.18040.814142.664878@montanaro-dyndns-org.local> Message-ID: On Mon, Aug 4, 2008 at 11:12 AM, wrote: > > >> We should probably cross-link with the Python humor page on > >> python.org (unless that's also been axed). > >> > aahz> IIRC, the humor page was axed due to lack of updates -- I > aahz> recommend finding the material using Wayback and just adding it to > aahz> the wiki. > > It's still there: > > http://www.python.org/doc/humor/ > > it's just been absorbed into the documentation. ;-) I added a link to the wiki page. > I can't find Tim Peters' award page and don't know if you can search the > Wayback Machine. (I suspect you have to know a precise URL.) Added this too; searching for gave me an email that had the correct URLs. It's still one of my favorites. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From noreply at scour.com Tue Aug 5 13:26:53 2008 From: noreply at scour.com (Raja Rokkam) Date: Tue, 5 Aug 2008 04:26:53 -0700 Subject: [Python-Dev] Scour.com invite from Raja Rokkam Message-ID: <489838fd93d27@scour.com> Hey, Did you hear about Scour? It is the next gen search engine with Google/Yahoo/MSN results and user comments all on one page. Best of all we get paid for using it by earning points with every search, comment and vote. The points are redeemable for Visa gift cards! It's like earning credit card or airline points just for searching! Hit the link below to join for free and we will both get points! http://scour.com/invite/rajar/ I know you'll like it! - Raja Rokkam From matt.giuca at gmail.com Tue Aug 5 14:47:37 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Tue, 5 Aug 2008 22:47:37 +1000 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: References: <3968642431361249330@unknownmsgid> <7769003638770459002@unknownmsgid> <1bc395c10807310933n519ac306v7656c83093e7cb6c@mail.gmail.com> Message-ID: Has anyone had time to look at the patch for this issue? It got a lot of support about a week ago, but nobody has replied since then, and the patch still hasn't been assigned to anybody or given a priority. I hope I've complied with all the patch submission procedures. Please let me know if there is anything I can do to speed this along. Also I'd be interested in hearing anyone's opinion on the "quote_from_bytes" issue as raised in the previous email. I posted a suggested implementation of a more restrictive quote_from_bytes in that email, but I haven't included it in the patch yet. Matt Giuca -------------- next part -------------- An HTML attachment was scrubbed... URL: From facundobatista at gmail.com Tue Aug 5 15:01:56 2008 From: facundobatista at gmail.com (Facundo Batista) Date: Tue, 5 Aug 2008 10:01:56 -0300 Subject: [Python-Dev] [OT] Commit number Message-ID: Congratulations to Andrew Kuchling for doing the commit # 2**16 Lover-of-round-numbers--ly yours, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From james.zhuo at gmail.com Tue Aug 5 14:47:53 2008 From: james.zhuo at gmail.com (jamesz) Date: Tue, 5 Aug 2008 05:47:53 -0700 (PDT) Subject: [Python-Dev] New to python, let me know if i should be posting somewhere else Message-ID: <18830344.post@talk.nabble.com> Hi, I am new to Python, so this question that is probably blindingly obvious to you all. If I have 2 classes that references each other (a circular reference of some sort) and both class are defined in the single file in the order shown. class Resume(db.Model): file_data = db.BlobProperty() candidate = db.ReferenceProperty(Candidate) class Candidate(db.Model): first_name = db.StringProperty() last_name = db.StringProperty() latest_resume = db.ReferenceProperty(Resume) the Resume class does not know about the Candidate class as this module is imported, so it throws a error. Is there any way to get around this problem? -- View this message in context: http://www.nabble.com/New-to-python%2C-let-me-know-if-i-should-be-posting-somewhere-else-tp18830344p18830344.html Sent from the Python - python-dev mailing list archive at Nabble.com. From steve at holdenweb.com Tue Aug 5 17:34:45 2008 From: steve at holdenweb.com (Steve Holden) Date: Tue, 05 Aug 2008 11:34:45 -0400 Subject: [Python-Dev] New to python, let me know if i should be posting somewhere else In-Reply-To: <18830344.post@talk.nabble.com> References: <18830344.post@talk.nabble.com> Message-ID: <48987315.2030506@holdenweb.com> jamesz wrote: > Hi, > > I am new to Python, so this question that is probably blindingly obvious to > you all. > If I have 2 classes that references each other (a circular reference of some > sort) > and both class are defined in the single file in the order shown. > > class Resume(db.Model): > file_data = db.BlobProperty() > candidate = db.ReferenceProperty(Candidate) > > class Candidate(db.Model): > first_name = db.StringProperty() > last_name = db.StringProperty() > latest_resume = db.ReferenceProperty(Resume) > > the Resume class does not know about the Candidate class as this > module is imported, so it throws a error. Is there any way to get around > this problem? > Jamesz: This list (python-dev) is for the development *of* Python, not development *with* Python. If you ask your question on comp.lang.python (python-list at python.org) you will almost certainly receive an answer. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From guido at python.org Tue Aug 5 22:06:22 2008 From: guido at python.org (Guido van Rossum) Date: Tue, 5 Aug 2008 13:06:22 -0700 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: References: <7769003638770459002@unknownmsgid> <1bc395c10807310933n519ac306v7656c83093e7cb6c@mail.gmail.com> Message-ID: After the most recent flurry of discussion I've lost track of what's the right thing to do. I also believe it was said it should wait until 2.7/3.0, so there's no hurry (in fact there's no way to check it -- we don't have branches for those versions yet). On Tue, Aug 5, 2008 at 5:47 AM, Matt Giuca wrote: > Has anyone had time to look at the patch for this issue? It got a lot of > support about a week ago, but nobody has replied since then, and the patch > still hasn't been assigned to anybody or given a priority. > > I hope I've complied with all the patch submission procedures. Please let me > know if there is anything I can do to speed this along. > > Also I'd be interested in hearing anyone's opinion on the "quote_from_bytes" > issue as raised in the previous email. I posted a suggested implementation > of a more restrictive quote_from_bytes in that email, but I haven't included > it in the patch yet. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From pogonyshev at gmx.net Tue Aug 5 22:38:21 2008 From: pogonyshev at gmx.net (Paul Pogonyshev) Date: Tue, 5 Aug 2008 23:38:21 +0300 Subject: [Python-Dev] Py_CLEAR and assigning values Message-ID: <200808052338.21596.pogonyshev@gmx.net> Hi, Sorry if this topic was discussed before, but I couldn't find. Py_CLEAR documentation explains why it is better than Py_DECREF and NULL assignment. However, I don't understand why there is no similar macro for the case you want to replace one object with another? I.e. 'naive' way: Py_DECREF (self->x); /* This is prone to the same bug Py_CLEAR prevents. */ self->x = y; Py_INCREF (self->x); Py_CLEAR way: Py_CLEAR (self->x); /* But __del__ can now in principle trigger access to NULL. */ self->x = y; Py_INCREF (self->x); Way I'd think would be possible: Py_ASSIGN (self->x, y) where Py_ASSIGN is defined this way: #define Py_ASSIGN(op, val) \ do { \ PyObject *_py_tmp = (PyObject *)(op); \ (op) = val; \ Py_XINCREF(op); \ Py_XDECREF(_py_tmp); \ } while (0) Do I miss something obvious? Or is there already a standard way to do that which I overlooked? Paul From leo.soto at gmail.com Tue Aug 5 22:43:25 2008 From: leo.soto at gmail.com (Leo Soto M.) Date: Tue, 5 Aug 2008 16:43:25 -0400 Subject: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython) Message-ID: <5a8cc9e00808051343ne5d36e9u1c0d63ccf402d053@mail.gmail.com> Hi Python developers! First, a quick introduction: My name is Leonardo Soto, I'm a GSoC 2008 student working under PSF and the Jython project, and a Jython commiter since one month ago. As part of what I did on this GSoC, I've improved Jython's __cmp__ a bit. That made me go to look at CPython sources (v2.5.2) to read the implementation of cmp(a,b). Aside from what I've already fixed on Jython, I've found four differences between Jython and CPython cmp(a, b): (1). CPython's cmp() uses a.__cmp__(b) before rich-cmp methods if the types of the two arguments are the same. (2). When using rich-cmp methods, CPython first check if the second type is a subtype of the first, and starts trying with the second method instead of the first. [i.e, the process starts by b.__gt__(a) instead of a.__lt__(b) if type(b) != type(a) and issubclass(b, a)] (3). Similar to above, if the second argument to cmp(a, b) is a old-style instance, and the first isn't, b.__cmp__(a) is used instead of a.__cmp__(b). (4). CPython tries coercion as part of the three way comparison. But doesn't do it exactly as advertised on : it does coercion *after* trying a.__cmp__(b), while the docs says *before*. And it only uses the coerced values if both values have the same tp_compare function. I fail to see why, and this is not mentioned on the docs either. [The examples that show this behaviors are at the end of this mail.] Now, my questions: - Are (1), (2) and (3) intentional features? Frankly, Jython being different on (1) and (3) isn't a big deal, but I'd like to match CPython as much as possible (and reasonable). Point (2) is a more interesting, because it seems to follow what says for binary ops: "Exception to the previous item: if the left operand is an instance of a built-in type or a new-style class, and the right operand is an instance of a proper subclass of that type or class and overrides the base's __rop__() method, the right operand's __rop__() method is tried before the left operand's __op__() method." But I haven't found any documentation telling that it applies to rich-cmp methods too. Interestingly, it *doesn't* apply to __cmp__ on CPython 2.5.2. BTW, PyPy also fails to follow CPython on points (2) and (3), so it is not just me failing to found the appropriate docs ;-) - What's the idea behind the current implemention of __cmp__ and coercion, as described on (4)? I've to implement this feauture on Jython, but checking that two Java instances have the same __cmp__ method is not that easy as in C. And more important: it could be wrong, depending on what is the idea behind the current CPython implementation. Finally, here are the examples of the behaviors outlined at the start of this mail. (1): >>> class A(object): ... def __eq__(self, other): return True ... def __cmp__(self, other): return 1 ... >>> cmp(A(), A()) 1 (2): >>> class A(object): ... def __lt__(self, other): return True ... def __gt__(self, other): return False ... def __eq__(self, other): return False ... >>> class B(A): pass ... >>> cmp(A(), B()) 1 (3): >>> class A(object): ... def __cmp__(self, other): return 1 ... >>> class B: ... def __cmp__(self, other): return 1 ... >>> cmp(A(), B()) -1 (4): >>> class A(object): ... def __coerce__(self, other): return 0, 0 ... def __cmp__(self, other): return -1 ... >>> cmp(A(), A()) -1 Regards, -- Leo Soto M. http://blog.leosoto.com From guido at python.org Tue Aug 5 22:45:58 2008 From: guido at python.org (Guido van Rossum) Date: Tue, 5 Aug 2008 13:45:58 -0700 Subject: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython) In-Reply-To: <5a8cc9e00808051343ne5d36e9u1c0d63ccf402d053@mail.gmail.com> References: <5a8cc9e00808051343ne5d36e9u1c0d63ccf402d053@mail.gmail.com> Message-ID: Given that in Python 3.0 __cmp__ is going away, I'm not sure how much it all matters -- but if you care, as long as it's supported at all, you might as well strive for the most compatibility with 2.5... On Tue, Aug 5, 2008 at 1:43 PM, Leo Soto M. wrote: > Hi Python developers! > > First, a quick introduction: My name is Leonardo Soto, I'm a GSoC > 2008 student working under PSF and the Jython project, and a Jython > commiter since one month ago. > > As part of what I did on this GSoC, I've improved Jython's __cmp__ a > bit. That made me go to look at CPython sources (v2.5.2) to read the > implementation of cmp(a,b). > > Aside from what I've already fixed on Jython, I've found four > differences between Jython and CPython cmp(a, b): > > (1). CPython's cmp() uses a.__cmp__(b) before rich-cmp methods if the > types of the two arguments are the same. > > (2). When using rich-cmp methods, CPython first check if the second > type is a subtype of the first, and starts trying with the second > method instead of the first. [i.e, the process starts by b.__gt__(a) > instead of a.__lt__(b) if type(b) != type(a) and issubclass(b, a)] > > (3). Similar to above, if the second argument to cmp(a, b) is a > old-style instance, and the first isn't, b.__cmp__(a) is used instead > of a.__cmp__(b). > > (4). CPython tries coercion as part of the three way comparison. But > doesn't do it exactly as advertised on > : it does coercion > *after* trying a.__cmp__(b), while the docs says *before*. And it only > uses the coerced values if both values have the same tp_compare > function. I fail to see why, and this is not mentioned on the docs > either. > > [The examples that show this behaviors are at the end of this mail.] > > Now, my questions: > > - Are (1), (2) and (3) intentional features? Frankly, Jython being > different on (1) and (3) isn't a big deal, but I'd like to match > CPython as much as possible (and reasonable). Point (2) is a more > interesting, because it seems to follow what > says for binary ops: > > "Exception to the previous item: if the left operand is an instance of > a built-in type or a new-style class, and the right operand is an > instance of a proper subclass of that type or class and overrides the > base's __rop__() method, the right operand's __rop__() method is tried > before the left operand's __op__() method." > > But I haven't found any documentation telling that it applies to > rich-cmp methods too. Interestingly, it *doesn't* apply to __cmp__ on > CPython 2.5.2. > > BTW, PyPy also fails to follow CPython on points (2) and (3), so it is > not just me failing to found the appropriate docs ;-) > > - What's the idea behind the current implemention of __cmp__ and > coercion, as described on (4)? I've to implement this feauture on > Jython, but checking that two Java instances have the same __cmp__ > method is not that easy as in C. And more important: it could be > wrong, depending on what is the idea behind the current CPython > implementation. > > Finally, here are the examples of the behaviors outlined at the start > of this mail. > > (1): > >>>> class A(object): > ... def __eq__(self, other): return True > ... def __cmp__(self, other): return 1 > ... >>>> cmp(A(), A()) > 1 > > (2): > >>>> class A(object): > ... def __lt__(self, other): return True > ... def __gt__(self, other): return False > ... def __eq__(self, other): return False > ... >>>> class B(A): pass > ... >>>> cmp(A(), B()) > 1 > > (3): > >>>> class A(object): > ... def __cmp__(self, other): return 1 > ... >>>> class B: > ... def __cmp__(self, other): return 1 > ... >>>> cmp(A(), B()) > -1 > > (4): > >>>> class A(object): > ... def __coerce__(self, other): return 0, 0 > ... def __cmp__(self, other): return -1 > ... >>>> cmp(A(), A()) > -1 > > Regards, > -- > Leo Soto M. > http://blog.leosoto.com > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Tue Aug 5 22:48:06 2008 From: guido at python.org (Guido van Rossum) Date: Tue, 5 Aug 2008 13:48:06 -0700 Subject: [Python-Dev] Py_CLEAR and assigning values In-Reply-To: <200808052338.21596.pogonyshev@gmx.net> References: <200808052338.21596.pogonyshev@gmx.net> Message-ID: I don't see a way that __del__ could be invoked and access the NULL between the Py_CLEAR() call and the Py_INCREF() call in the second version. On Tue, Aug 5, 2008 at 1:38 PM, Paul Pogonyshev wrote: > Hi, > > Sorry if this topic was discussed before, but I couldn't find. > > Py_CLEAR documentation explains why it is better than Py_DECREF and > NULL assignment. However, I don't understand why there is no similar > macro for the case you want to replace one object with another? > > I.e. 'naive' way: > > Py_DECREF (self->x); > /* This is prone to the same bug Py_CLEAR prevents. */ > self->x = y; > Py_INCREF (self->x); > > Py_CLEAR way: > > Py_CLEAR (self->x); > /* But __del__ can now in principle trigger access to NULL. */ > self->x = y; > Py_INCREF (self->x); > > Way I'd think would be possible: > > Py_ASSIGN (self->x, y) > > where Py_ASSIGN is defined this way: > > #define Py_ASSIGN(op, val) \ > do { \ > PyObject *_py_tmp = (PyObject *)(op); \ > (op) = val; \ > Py_XINCREF(op); \ > Py_XDECREF(_py_tmp); \ > } while (0) > > Do I miss something obvious? Or is there already a standard way to > do that which I overlooked? > > Paul > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From leo.soto at gmail.com Tue Aug 5 22:56:27 2008 From: leo.soto at gmail.com (Leo Soto M.) Date: Tue, 5 Aug 2008 16:56:27 -0400 Subject: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython) In-Reply-To: References: <5a8cc9e00808051343ne5d36e9u1c0d63ccf402d053@mail.gmail.com> Message-ID: <5a8cc9e00808051356i74f6bf7eud3366b36a4e62950@mail.gmail.com> On Tue, Aug 5, 2008 at 4:45 PM, Guido van Rossum wrote: > Given that in Python 3.0 __cmp__ is going away, I'm not sure how much > it all matters -- but if you care, as long as it's supported at all, > you might as well strive for the most compatibility with 2.5... Sure, it won't be a problem on Jython 3.0. But I'm doing this for the upcoming Jython 2.5, where we still have to live with __cmp__ -- Leo Soto M. http://blog.leosoto.com From guido at python.org Tue Aug 5 22:59:22 2008 From: guido at python.org (Guido van Rossum) Date: Tue, 5 Aug 2008 13:59:22 -0700 Subject: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython) In-Reply-To: <5a8cc9e00808051356i74f6bf7eud3366b36a4e62950@mail.gmail.com> References: <5a8cc9e00808051343ne5d36e9u1c0d63ccf402d053@mail.gmail.com> <5a8cc9e00808051356i74f6bf7eud3366b36a4e62950@mail.gmail.com> Message-ID: On Tue, Aug 5, 2008 at 1:56 PM, Leo Soto M. wrote: > On Tue, Aug 5, 2008 at 4:45 PM, Guido van Rossum wrote: >> Given that in Python 3.0 __cmp__ is going away, I'm not sure how much >> it all matters -- but if you care, as long as it's supported at all, >> you might as well strive for the most compatibility with 2.5... > > Sure, it won't be a problem on Jython 3.0. But I'm doing this for the > upcoming Jython 2.5, where we still have to live with __cmp__ Which is why I recommend the closest possible compatibility. :-) > -- > Leo Soto M. > http://blog.leosoto.com > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From daniel at stutzbachenterprises.com Tue Aug 5 23:04:55 2008 From: daniel at stutzbachenterprises.com (Daniel Stutzbach) Date: Tue, 5 Aug 2008 16:04:55 -0500 Subject: [Python-Dev] Py_CLEAR and assigning values In-Reply-To: <200808052338.21596.pogonyshev@gmx.net> References: <200808052338.21596.pogonyshev@gmx.net> Message-ID: On Tue, Aug 5, 2008 at 3:38 PM, Paul Pogonyshev wrote: > Py_CLEAR way: > > Py_CLEAR (self->x); > /* But __del__ can now in principle trigger access to NULL. */ > self->x = y; > Py_INCREF (self->x); The Py_DECREF inside the Py_CLEAR may call arbitrary code while self->x points to NULL. This is OK if you write your code to recognize that self->x may be NULL. Without Py_CLEAR, a Py_DECREF may call arbitrary code while self->x points to a deallocated object. This is never OK since it's impossible to detect that self->x is bogus. Generally, I end up storing all the objects to be Py_DECREF'd in temporary variables and doing the Py_DECREF's just before returning. That way, "self" is never in an inconsistent state. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From pogonyshev at gmx.net Tue Aug 5 23:30:49 2008 From: pogonyshev at gmx.net (Paul Pogonyshev) Date: Wed, 6 Aug 2008 00:30:49 +0300 Subject: [Python-Dev] Py_CLEAR and assigning values In-Reply-To: References: <200808052338.21596.pogonyshev@gmx.net> Message-ID: <200808060030.49481.pogonyshev@gmx.net> Daniel Stutzbach wrote: > On Tue, Aug 5, 2008 at 3:38 PM, Paul Pogonyshev wrote: > > > Py_CLEAR way: > > > > Py_CLEAR (self->x); > > /* But __del__ can now in principle trigger access to NULL. */ > > self->x = y; > > Py_INCREF (self->x); > > The Py_DECREF inside the Py_CLEAR may call arbitrary code while self->x > points to NULL. This is OK if you write your code to recognize that self->x > may be NULL. Yes, this is quite similar to Python code del obj.x obj.x = y though I'm not sure if for Python code x.__del__ will see obj.x as non-set attribute (I guess so, but I'm not sure). However, I'm trying to emulate obj.x = y in C. > Without Py_CLEAR, a Py_DECREF may call arbitrary code while self->x points > to a deallocated object. This is never OK since it's impossible to detect > that self->x is bogus. Yes, this I don't argue. > Generally, I end up storing all the objects to be Py_DECREF'd in temporary > variables and doing the Py_DECREF's just before returning. That way, "self" > is never in an inconsistent state. Right. But wouldn't it be easier if there was a standard Python macro for this, sort of like proposed Py_ASSIGN? Paul From matt.giuca at gmail.com Wed Aug 6 01:03:06 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Wed, 6 Aug 2008 09:03:06 +1000 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: References: <7769003638770459002@unknownmsgid> <1bc395c10807310933n519ac306v7656c83093e7cb6c@mail.gmail.com> Message-ID: > After the most recent flurry of discussion I've lost track of what's > the right thing to do. I also believe it was said it should wait until > 2.7/3.0, so there's no hurry (in fact there's no way to check it -- we > don't have branches for those versions yet). > I assume you mean 2.7/3.1. I've always been concerned with the suggestion that this wait till 3.1. I figure this patch is going to change the documented behaviour of these functions, so it might be unacceptable to change it after 3.0 is released. It seems logical that this patch be part of the "incompatible-for-the-sake-of-fixing-things" set of changes in 3.0. The current behaviour is broken. Any code which uses quote to produce a URL, then unquotes the same URL later will simply break for characters outside the Latin-1 range. This is evident in the SimpleHTTPServer class as I said above (which presents users with URLs for the files in a directory using quote, then gives 404 when they click on them, because unquote can't handle it). And it will break any user's code which also assumes unquote is the inverse of quote. We could hack a fix into SimpleHTTPServer and expect other users to do the same (along the lines of .encode('utf-8').decode('latin-1')), but then those hacks will break when we apply the patch in 3.1 because they abuse Unicode strings, and we'll have to have another debate about how to be backwards compatible with them. (The patched version is largely compatible with the 2.x version, but the unpatched version isn't compatible with either the 2.x version or the patched version). Surely the sane option is to get this UTF-8 patch into version 3.0 so we don't have to support this bug into the future? I'm far less concerned about the decision with regards to unquote_to_bytes/quote_from_bytes, as those are new features which can wait. Matt Giuca -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Wed Aug 6 01:07:50 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 5 Aug 2008 23:07:50 +0000 (UTC) Subject: [Python-Dev] =?utf-8?q?Py=5FCLEAR_and_assigning_values?= References: <200808052338.21596.pogonyshev@gmx.net> <200808060030.49481.pogonyshev@gmx.net> Message-ID: Paul Pogonyshev gmx.net> writes: > > Right. But wouldn't it be easier if there was a standard Python macro > for this, sort of like proposed Py_ASSIGN? I proposed something similar in http://bugs.python.org/issue3081. From leo.soto at gmail.com Wed Aug 6 02:56:11 2008 From: leo.soto at gmail.com (Leo Soto M.) Date: Tue, 5 Aug 2008 20:56:11 -0400 Subject: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython) In-Reply-To: References: <5a8cc9e00808051343ne5d36e9u1c0d63ccf402d053@mail.gmail.com> <5a8cc9e00808051356i74f6bf7eud3366b36a4e62950@mail.gmail.com> Message-ID: <5a8cc9e00808051756i15f418c5gf5cc5261c6d7ceac@mail.gmail.com> On Tue, Aug 5, 2008 at 4:59 PM, Guido van Rossum wrote: > On Tue, Aug 5, 2008 at 1:56 PM, Leo Soto M. wrote: >> On Tue, Aug 5, 2008 at 4:45 PM, Guido van Rossum wrote: >>> Given that in Python 3.0 __cmp__ is going away, I'm not sure how much >>> it all matters -- but if you care, as long as it's supported at all, >>> you might as well strive for the most compatibility with 2.5... >> >> Sure, it won't be a problem on Jython 3.0. But I'm doing this for the >> upcoming Jython 2.5, where we still have to live with __cmp__ > > Which is why I recommend the closest possible compatibility. :-) Oh, right :) But that's going to be easier if I understand the "why" and not only the "how". I can live with a "no idea why" answer, though. -- Leo Soto M. http://blog.leosoto.com From greg.ewing at canterbury.ac.nz Wed Aug 6 03:03:44 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 06 Aug 2008 13:03:44 +1200 Subject: [Python-Dev] Py_CLEAR and assigning values In-Reply-To: <200808060030.49481.pogonyshev@gmx.net> References: <200808052338.21596.pogonyshev@gmx.net> <200808060030.49481.pogonyshev@gmx.net> Message-ID: <4898F870.9020504@canterbury.ac.nz> Paul Pogonyshev wrote: > del obj.x > obj.x = y > > though I'm not sure if for Python code x.__del__ will see obj.x as > non-set attribute (I guess so, but I'm not sure). A quick experiment suggests that it does: Python 2.5 (r25:51908, Apr 8 2007, 22:22:18) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class Foo(object): ... def __del__(self): ... print "__del__" ... print x.a ... >>> x = Foo() >>> x.a = Foo() >>> del x.a __del__ Exception exceptions.AttributeError: "'Foo' object has no attribute 'a'" in > ignored -- Greg From guido at python.org Wed Aug 6 04:46:25 2008 From: guido at python.org (Guido van Rossum) Date: Tue, 5 Aug 2008 19:46:25 -0700 Subject: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython) In-Reply-To: <5a8cc9e00808051756i15f418c5gf5cc5261c6d7ceac@mail.gmail.com> References: <5a8cc9e00808051343ne5d36e9u1c0d63ccf402d053@mail.gmail.com> <5a8cc9e00808051356i74f6bf7eud3366b36a4e62950@mail.gmail.com> <5a8cc9e00808051756i15f418c5gf5cc5261c6d7ceac@mail.gmail.com> Message-ID: On Tue, Aug 5, 2008 at 5:56 PM, Leo Soto M. wrote: > On Tue, Aug 5, 2008 at 4:59 PM, Guido van Rossum wrote: >> On Tue, Aug 5, 2008 at 1:56 PM, Leo Soto M. wrote: >>> On Tue, Aug 5, 2008 at 4:45 PM, Guido van Rossum wrote: >>>> Given that in Python 3.0 __cmp__ is going away, I'm not sure how much >>>> it all matters -- but if you care, as long as it's supported at all, >>>> you might as well strive for the most compatibility with 2.5... >>> >>> Sure, it won't be a problem on Jython 3.0. But I'm doing this for the >>> upcoming Jython 2.5, where we still have to live with __cmp__ >> >> Which is why I recommend the closest possible compatibility. :-) > > Oh, right :) > > But that's going to be easier if I understand the "why" and not only > the "how". I can live with a "no idea why" answer, though. Close -- I would have to do a lot of thinking, swapping in parts of my memory that have been gone for years. I say, follow CPython blindly and you can't go too wrong: even if the rules are arbitrary, they are what everyone expects. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From daniel at stutzbachenterprises.com Wed Aug 6 05:00:38 2008 From: daniel at stutzbachenterprises.com (Daniel Stutzbach) Date: Tue, 5 Aug 2008 22:00:38 -0500 Subject: [Python-Dev] Py_CLEAR and assigning values In-Reply-To: <200808060030.49481.pogonyshev@gmx.net> References: <200808052338.21596.pogonyshev@gmx.net> <200808060030.49481.pogonyshev@gmx.net> Message-ID: On Tue, Aug 5, 2008 at 4:30 PM, Paul Pogonyshev wrote: > > Generally, I end up storing all the objects to be Py_DECREF'd in > temporary > > variables and doing the Py_DECREF's just before returning. That way, > "self" > > is never in an inconsistent state. > > Right. But wouldn't it be easier if there was a standard Python macro > for this, sort of like proposed Py_ASSIGN? > If you're modifying exactly one property in the C function, yes. In my C code, when I modifying an object I usually need to modifying many of the properties which means that I need to delay all of the Py_DECREF's until just before returning. The Py_ASSIGN macro that you propose would not achieve this. If I used Py_ASSIGN, all the pointers would point to valid objects, true, but the object might not be in a consistent state. If in your code you frequently need to modifying just one property, you are certainly free to create your own macro. :-) -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From janssen at parc.com Wed Aug 6 06:46:37 2008 From: janssen at parc.com (Bill Janssen) Date: Tue, 5 Aug 2008 21:46:37 PDT Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: References: <7769003638770459002@unknownmsgid> <1bc395c10807310933n519ac306v7656c83093e7cb6c@mail.gmail.com> Message-ID: <08Aug5.214644pdt."58698"@synergy1.parc.xerox.com> > I'm far less concerned about > the decision with regards to unquote_to_bytes/quote_from_bytes, as those are > new features which can wait. Forgive me, but those are the *old* features, which must be there. Bill From nd at perlig.de Wed Aug 6 09:51:54 2008 From: nd at perlig.de (=?iso-8859-1?q?Andr=E9_Malo?=) Date: Wed, 6 Aug 2008 09:51:54 +0200 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: <08Aug5.214644pdt."58698"@synergy1.parc.xerox.com> References: <08Aug5.214644pdt."58698"@synergy1.parc.xerox.com> Message-ID: <200808060951.54723.nd@perlig.de> * Bill Janssen wrote: > > I'm far less concerned about > > the decision with regards to unquote_to_bytes/quote_from_bytes, as > > those are new features which can wait. > > Forgive me, but those are the *old* features, which must be there. This whole discussion circles too much, I think. Maybe it should be pepped? nd From matt.giuca at gmail.com Wed Aug 6 14:55:45 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Wed, 6 Aug 2008 22:55:45 +1000 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: <200808060951.54723.nd@perlig.de> References: <200808060951.54723.nd@perlig.de> Message-ID: > This whole discussion circles too much, I think. Maybe it should be pepped? The issue isn't circular. It's been patched and tested, then a whole lot of people agreed including Guido. Then you and Bill wanted the bytes functionality back. So I wrote that in there too, and Bill at least said that was sufficient. On Thu, Jul 31, 2008, Bill Janssen wrote: > > But: OK, OK, I yield. Though I still think this is a bad idea, I'll shut > up if we can also add "unquote_as_bytes" which returns a byte sequence > instead of a string. I'll just change my code to use that. > We've reached, to quote Guido, "as close as consensus as we can get on this issue". There is a bug in Python. I've proposed a working fix, and nobody else has. Guido okayed it. I made all the changes the community suggested. What more needs to be discussed here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.soto at gmail.com Wed Aug 6 15:30:19 2008 From: leo.soto at gmail.com (Leo Soto M.) Date: Wed, 6 Aug 2008 09:30:19 -0400 Subject: [Python-Dev] On __cmp__ specifications and implementation (to mimic it on Jython) In-Reply-To: References: <5a8cc9e00808051343ne5d36e9u1c0d63ccf402d053@mail.gmail.com> <5a8cc9e00808051356i74f6bf7eud3366b36a4e62950@mail.gmail.com> <5a8cc9e00808051756i15f418c5gf5cc5261c6d7ceac@mail.gmail.com> Message-ID: <5a8cc9e00808060630y2f3cee65m77fff197221936a7@mail.gmail.com> On Tue, Aug 5, 2008 at 10:46 PM, Guido van Rossum wrote: > On Tue, Aug 5, 2008 at 5:56 PM, Leo Soto M. wrote: > > But that's going to be easier if I understand the "why" and not only > > the "how". I can live with a "no idea why" answer, though. > > Close -- I would have to do a lot of thinking, swapping in parts of my > memory that have been gone for years. I say, follow CPython blindly > and you can't go too wrong: even if the rules are arbitrary, they are > what everyone expects. Fair enough. It is going to be tricky with coercion (AFAIK, there is no easy way to ask two java objects if they share the same method implementation without resorting to reflection), but I'll do my best. Thanks! -- Leo Soto M. http://blog.leosoto.com From nd at perlig.de Wed Aug 6 15:59:28 2008 From: nd at perlig.de (=?utf-8?q?Andr=C3=A9_Malo?=) Date: Wed, 6 Aug 2008 15:59:28 +0200 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: References: <200808060951.54723.nd@perlig.de> Message-ID: <200808061559.28341.nd@perlig.de> * Matt Giuca wrote: > > This whole discussion circles too much, I think. Maybe it should be > > pepped? > > The issue isn't circular. It's been patched and tested, then a whole lot > of people agreed including Guido. Then you and Bill wanted the bytes > functionality back. So I wrote that in there too, and Bill at least said > that was sufficient. > > On Thu, Jul 31, 2008, Bill Janssen wrote: > > But: OK, OK, I yield. Though I still think this is a bad idea, I'll > > shut up if we can also add "unquote_as_bytes" which returns a byte > > sequence instead of a string. I'll just change my code to use that. > > We've reached, to quote Guido, "as close as consensus as we can get on > this issue". There are a lot of quotes around. Including "After the most recent flurry of discussion I've lost track of what's the right thing to do." But I don't talk for other people. > There is a bug in Python. I've proposed a working fix, and nobody else > has. Well, you proposed a patch ;-) It may fix things, it will break a lot. While this was denied over and over again, it's still gonna happen, because the axioms are still not accounting for the reality. > I made all the changes the community suggested. I don't think so. > What more needs to be discussed here? Huh? You feel, the discussion is over? Then why are there still open questions? I admit, a lot of discussion is triggered by the assessments you're stating in your posts. Don't take it as a personal offense, it's a simple observation. There were made a lot of statements and nobody even bothered to substantiate them. A PEP could fix that. But it's a lost issue now. Nobody comes up with an alternative (for various reasons, I suppose). So go ahead, EOD from my side. nd From matt.giuca at gmail.com Wed Aug 6 17:12:31 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Thu, 7 Aug 2008 01:12:31 +1000 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: <200808061559.28341.nd@perlig.de> References: <200808060951.54723.nd@perlig.de> <200808061559.28341.nd@perlig.de> Message-ID: > There are a lot of quotes around. Including "After the most recent flurry > of > discussion I've lost track of what's the right thing to do." > But I don't talk for other people. > OK .. let me compose myself a little. Sorry I went ahead and assumed this was closed. It's just frustrating to me that I've now spent a month trying to push this through, and while it seems everybody has an opinion, nobody seems to have bothered trying my code. (I've even implemented your suggestions and posted my feedback, and nobody replied to that). Nobody's been assigned to look at it and it hasn't been given a priority, even though we all agree it's a bug (though we disagree on how to fix it). > > > There is a bug in Python. I've proposed a working fix, and nobody else > > has. > > Well, you proposed a patch ;-) > It may fix things, it will break a lot. While this was denied over and over > again, it's still gonna happen, because the axioms are still not accounting > for the reality. Well all you're getting from me is "it works". And all I'm getting from you is "it might not". Please .. I've been asking for weeks now for someone to review the patch. I've already spent hours (like ... days worth of hours) testing this patch against the whole library. I've written reams of reports on the tracker to try and convince people it works. There isn't any more *I* can do. If you think it's going to break code, go ahead and try it out. The claims I am making are based on my experience working with a) Python 2, b) Python 3 as it stands, c) Python 3 with my patch, and d) Python 3 with quote/unquote using bytes. In my experience, (c) is the only version of Python 3 which works properly. > I made all the changes the community suggested. > > I don't think so. > ? > > What more needs to be discussed here? > > Huh? You feel, the discussion is over? Then why are there still open > questions? I admit, a lot of discussion is triggered by the assessments > you're stating in your posts. Don't take it as a personal offense, it's a > simple observation. There were made a lot of statements and nobody even > bothered to substantiate them. If you read the bug tracker all the way to the beginning, you'll see I use a good many examples, and I also went through the entire standard library to try and substantiate my claims. (Admittedly, I didn't finish investigating the request module, but that shouldn't prevent the patch from being reviewed). As I've said all along, yes, it will break code, but then *all solutions possible* will break code, including leaving it in. Mine *seems* to break the least existing code. If there is ever a time to break code, Python 3.0 is it. > A PEP could fix that. > I could write a PEP. But as you've read above, I'm concerned this won't get into Python 3.0, and then we'll be locked into the existing functionality and it'll never get accepted; hence I'd rather this be resolved as quickly as possible. If you think it's worth writing a PEP, let's do it. Apologies again for my antagonistic reply earlier. Not trying to step on toes, just get stuff done. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at scottdial.com Wed Aug 6 17:05:16 2008 From: scott at scottdial.com (Scott Dial) Date: Wed, 06 Aug 2008 11:05:16 -0400 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: <200808061559.28341.nd@perlig.de> References: <200808060951.54723.nd@perlig.de> <200808061559.28341.nd@perlig.de> Message-ID: <4899BDAC.1030605@scottdial.com> Andr? Malo wrote: > * Matt Giuca wrote: >> We've reached, to quote Guido, "as close as consensus as we can get on >> this issue". > > There are a lot of quotes around. Including "After the most recent flurry of > discussion I've lost track of what's the right thing to do." > But I don't talk for other people. Let's not play the who-can-find-the-best-quote-to-make-their-point game. Yes, there was a lot of discussion, and yes, it would be difficult to follow if it wasn't something you were paying much attention to. I believe (as someone who didn't even participate in the discussion) that it was clear that: * quote/unquote should "just work" for strings in 3.x. Meaning that quote should be str->str and unquote str->str, because *most* uses of quote/unquote are naive. There is a quite clear proclamation from the BDFL that quote/unquote should not be bound by pedantic readings of the RFCs. * an alternative set of functions that support byte->str and str->byte should be added to support other use-cases that are less naive. Matt added unquote_to_bytes/quote_from_bytes to fill this gap. Bill agreed it was sufficient to satisfy his use-cases (stipulating that they are a necessary addition if any change should be made at all). >> There is a bug in Python. I've proposed a working fix, and nobody else >> has. > > Well, you proposed a patch ;-) > It may fix things, it will break a lot. While this was denied over and over > again, it's still gonna happen, because the axioms are still not accounting > for the reality. I've not read anyone other than Bill come forward saying they had a lot of code that uses quote/unquote that will be broke. Matt has went through the stdlib and found most uses consistent with the "quote/unquote users are naive" statement. I would suggest that the onus is on you to substantiate this claim that "it will break a lot." >> I made all the changes the community suggested. > > I don't think so. This short reply is useless. What are those changes? If your problem is that *your* suggestions were dropped, then I remind you that they *were discussed*. And, Matt correctly pointed out that setting the defaults to encoding in latin-1 and decoding in utf-8 would be a nightmare. It would be much more sane to pick one encoding for both. However, which encoding it should be is an arguable point. The apparent consensus was that most people didn't care as long as they could override it. >> What more needs to be discussed here? > > Huh? You feel, the discussion is over? Can we please avoid discussions about discussion? Arguing about arguing does not benefit this discussion. If you have a problem with his proposed patch, then please elaborate on that rather than /just/ complain that it is unsatisfactory in some way. Do you agree there is a bug? Do you agree it needs to be solved? And, what about the proposed solution is unsatisfactory? -Scott -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From janssen at parc.com Wed Aug 6 17:35:28 2008 From: janssen at parc.com (Bill Janssen) Date: Wed, 6 Aug 2008 08:35:28 PDT Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: <4899BDAC.1030605@scottdial.com> References: <200808060951.54723.nd@perlig.de> <200808061559.28341.nd@perlig.de> <4899BDAC.1030605@scottdial.com> Message-ID: <08Aug6.083535pdt."58698"@synergy1.parc.xerox.com> I suggest we continue this discussion, if at all, on the bug-tracker, where there's code, and more participants. http://bugs.python.org/issue3300 I've now posted my idea of how quote/unquote should work in py3K, there. Bill From martin at v.loewis.de Wed Aug 6 17:55:07 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 06 Aug 2008 17:55:07 +0200 Subject: [Python-Dev] Py_CLEAR and assigning values In-Reply-To: References: <200808052338.21596.pogonyshev@gmx.net> Message-ID: <4899C95B.20104@v.loewis.de> Guido van Rossum wrote: > I don't see a way that __del__ could be invoked and access the NULL > between the Py_CLEAR() call and the Py_INCREF() call in the second > version. Consider this: class Bad: def __del__(self): obj.some_method() obj.set_foo(Bad()) obj.set_foo(None) Now, the second set_foo does a Py_CLEAR on foo, which invokes Bad.__del__, which invokes a method on obj, which crashes as foo is NULL - it has not yet been assigned Py_None as expected. Regards, Martin From martin at v.loewis.de Wed Aug 6 18:09:23 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 06 Aug 2008 18:09:23 +0200 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: References: <200808060951.54723.nd@perlig.de> <200808061559.28341.nd@perlig.de> Message-ID: <4899CCB3.5020208@v.loewis.de> > Nobody's been > assigned to look at it and it hasn't been given a priority, even though > we all agree it's a bug (though we disagree on how to fix it). This I can explain (I think). Nobody is assigned to look: we usually don't do assignments of bugs or patches, except when there is a specific maintainer for the code in question. urllib has no maintainer. It hasn't been given priority: There are currently 606 patches in the tracker, many fixing bugs of some sort. It's not clear (to me, at least) why this should be given priority over all the other things such as interpreter crashes. We all agree it's a bug: no, I don't. I think it's a missing feature, at best, but I'm staying out of the discussion. As-is, urllib only supports ASCII in URLs, and that is fine for most purposes. URLs are just not made for non-ASCII characters. Implement IRIs if you want non-ASCII characters; the rules are much clearer for these. As it stands, a committer would have - to agree it's an important problem - to agree the patch is correct - to judge it is not a new feature, as we are in beta already - implicitly accept maintenance of that change, and take all the blame that it might produce in the coming years Regards, Martin From solipsis at pitrou.net Wed Aug 6 18:55:51 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 6 Aug 2008 16:55:51 +0000 (UTC) Subject: [Python-Dev] urllib.quote and unquote - Unicode issues References: <200808060951.54723.nd@perlig.de> <200808061559.28341.nd@perlig.de> <4899CCB3.5020208@v.loewis.de> Message-ID: Martin v. L?wis v.loewis.de> writes: > URLs are just not made for non-ASCII characters. Perhaps they are not, but every non-English wiki (just to take a simple, generic example) potentially contains non-ASCII URLs. e.g. http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant http://wiki.python.org/moin/J%C3%BCrgenHermann (notice the utf-8 encoding in both) > Implement IRIs if you want non-ASCII characters; the rules are much clearer for these. I think most people would expect something which works with the current World Wide Web rather than a rigorous implementation of a specific RFC. Implementing RFCs is fine but it does not magically eliminate all problems, especially when the RFCs themselves are not in sync with real-world usage. Regards Antoine. From martin at v.loewis.de Wed Aug 6 19:33:44 2008 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Wed, 06 Aug 2008 19:33:44 +0200 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: References: <200808060951.54723.nd@perlig.de> <200808061559.28341.nd@perlig.de> <4899CCB3.5020208@v.loewis.de> Message-ID: <4899E078.8050007@v.loewis.de> >> Implement IRIs if you want non-ASCII characters; the rules are much clearer > for these. > > I think most people would expect something which works with the current World > Wide Web rather than a rigorous implementation of a specific RFC. Implementing > RFCs is fine but it does not magically eliminate all problems, especially when > the RFCs themselves are not in sync with real-world usage. Why do you think implementing IRIs would not work with the current World Wide Web? IRIs are *made* for the current World Wide Web. Applications desiring to work in the current World Wide Web would then, of course, need to use the IRI library. Regards, Martin From mal at egenix.com Wed Aug 6 19:34:48 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 06 Aug 2008 19:34:48 +0200 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: References: <200808060951.54723.nd@perlig.de> <200808061559.28341.nd@perlig.de> <4899CCB3.5020208@v.loewis.de> Message-ID: <4899E0B8.8070907@egenix.com> On 2008-08-06 18:55, Antoine Pitrou wrote: > Martin v. L?wis v.loewis.de> writes: >> URLs are just not made for non-ASCII characters. > > Perhaps they are not, but every non-English wiki (just to take a simple, generic > example) potentially contains non-ASCII URLs. > e.g. http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant > http://wiki.python.org/moin/J%C3%BCrgenHermann > (notice the utf-8 encoding in both) > >> Implement IRIs if you want non-ASCII characters; the rules are much clearer > for these. > > I think most people would expect something which works with the current World > Wide Web rather than a rigorous implementation of a specific RFC. Implementing > RFCs is fine but it does not magically eliminate all problems, especially when > the RFCs themselves are not in sync with real-world usage. +1. Practicality beats purity... The web is moving towards UTF-8 as standard Unicode encoding, so it's probably wise to follow that approach for quote(). http://en.wikipedia.org/wiki/Percent-encoding The other way around will also have to deal with old-style URLs which typically still use the Latin-1 encoding which was the basis for HTML: http://www.w3schools.com/TAGS/ref_urlencode.asp So unquote() should probably try to decode using UTF-8 first and then fall back to Latin-1 if that doesn't work. Whether the result of quote()/unquote() should be bytes or Unicode is a different story and probably also depends on what the application does with the result. I don't think there's a good general answer for that one, except maybe just going for one possible combination and document that. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 05 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From guido at python.org Wed Aug 6 23:44:35 2008 From: guido at python.org (Guido van Rossum) Date: Wed, 6 Aug 2008 14:44:35 -0700 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: <4899CCB3.5020208@v.loewis.de> References: <200808060951.54723.nd@perlig.de> <200808061559.28341.nd@perlig.de> <4899CCB3.5020208@v.loewis.de> Message-ID: On Wed, Aug 6, 2008 at 9:09 AM, "Martin v. L?wis" wrote: >> Nobody's been >> assigned to look at it and it hasn't been given a priority, even though >> we all agree it's a bug (though we disagree on how to fix it). > > This I can explain (I think). Nobody is assigned to look: we usually > don't do assignments of bugs or patches, except when there is a specific > maintainer for the code in question. urllib has no maintainer. I'm somehow strangely attracted to this issue, and have posted a bit of a code review. > It hasn't been given priority: There are currently 606 patches in the > tracker, many fixing bugs of some sort. It's not clear (to me, at least) > why this should be given priority over all the other things such as > interpreter crashes. Well, it's an API change, and those are impossible after beta3 is released (or at least have to wait for 3.1). > We all agree it's a bug: no, I don't. I think it's a missing feature, > at best, but I'm staying out of the discussion. As-is, urllib only > supports ASCII in URLs, and that is fine for most purposes. URLs > are just not made for non-ASCII characters. Implement IRIs if you > want non-ASCII characters; the rules are much clearer for these. The wikipedia use of urlencoded UTF-8 (and other examples) suggest that whether we like it or not the trend is towards this. I'd like to support such usage rather than fight it (standards or no standards). > As it stands, a committer would have > - to agree it's an important problem > - to agree the patch is correct > - to judge it is not a new feature, as we are in beta already > - implicitly accept maintenance of that change, and take all > the blame that it might produce in the coming years It could be a small enough new feature. Also note that for urls that only use ASCII there is no behavior change. (And certainly this *is* an important use case, e.g. to encode occurrences of + or & in query strings). -- --Guido van Rossum (home page: http://www.python.org/~guido/) From ian.charnas at gmail.com Thu Aug 7 06:36:54 2008 From: ian.charnas at gmail.com (Ian Charnas) Date: Thu, 7 Aug 2008 00:36:54 -0400 Subject: [Python-Dev] small PATCH to fix os.fsync on OS X Message-ID: <18e505e30808062136s8f8c67x21d32e5849e886d4@mail.gmail.com> Hello heroes and heroins of the python universe, lend me your ears and I will tell you a tale that will make your platters spin! As noted by SQLite [1] and MySQL [2] developers, fsync on OS X does not actually flush a file to disk... instead OS X provides "fullfsync" which actually flushes the file descriptor to disk. This simple patch modifies python's "fsync" to take advantage of fullfsync on platforms that support it: http://bugs.python.org/issue3512 While some people might suggest that fullfsync should be exposed as a method on the 'os' module for platforms that support it, I believe this is not the best approach. Because the docstring for os.fsync says that it forces the file to be written to disk, I think it's up to python to ensure that functionality is really there on all platforms. Currently on OS X, fullfsync is needed to provide this functionality, so I think python's os.fsync should use fullfsync on OS X. Looking at 'svn blame' output for Modules/posixmodule.c, I see that guido wrote the original python fsync, ronald.oussoren added all the OS X specific stuff to posixmodule.c, and recent commits have been made to that file by martin.v.loewis. christian.heimes, facundo.batista, and gregory.p.smith. Would any of you fine folks like to take a look at this? I believe it's a *very* small patch. Many thanks, -Ian Charnas [1] SQLite uses fullfsync on all platforms that define it: http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_unix.c [2] MySQL uses fullfsync only on the darwin platform and only when F_FULLFSYNC is defined as 51, which seems to be short-sighted in that this symbol may change value in future versions of OS X. To see this code, download a mysql 5.x source snapshot and open up mysql-/innobase/os/os0file.c From scott+python-dev at scottdial.com Thu Aug 7 06:52:34 2008 From: scott+python-dev at scottdial.com (Scott Dial) Date: Thu, 07 Aug 2008 00:52:34 -0400 Subject: [Python-Dev] small PATCH to fix os.fsync on OS X In-Reply-To: <18e505e30808062136s8f8c67x21d32e5849e886d4@mail.gmail.com> References: <18e505e30808062136s8f8c67x21d32e5849e886d4@mail.gmail.com> Message-ID: <489A7F92.9060009@scottdial.com> Ian Charnas wrote: > As noted by SQLite [1] and MySQL [2] developers, fsync on OS X does > not actually flush a file to disk... instead OS X provides "fullfsync" > which actually flushes the file descriptor to disk. This simple patch > modifies python's "fsync" to take advantage of fullfsync on platforms > that support it: > http://bugs.python.org/issue3512 I don't believe your patch is correct. My understanding is that fsync() on OS X does the exact same thing as it does on any other POSIX platform. On all platforms, fsync() does not guarantee that your data has made it to permanent storage. fcntl(fd, F_FULLSYNC) is an additional feature on OS X to force the OS X to wait for the underlying device's write buffers to have cleared. See the discussion on darwin-dev[1]: """ So in summary, I believe that the comments in the MySQL news posting are slightly confused. On MacOS X fsync() behaves the same as it does on all Unices. That's not good enough if you really care about data integrity and so we also provide the F_FULLFSYNC fcntl. As far as I know, MacOS X is the only OS to provide this feature for apps that need to truly guarantee their data is on disk. """ If you want this feature to be accessible in python, then I think you should modify the fcntl module to include F_FULLSYNC. -Scott [1] http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From foom at fuhm.net Thu Aug 7 06:56:46 2008 From: foom at fuhm.net (James Y Knight) Date: Thu, 7 Aug 2008 00:56:46 -0400 Subject: [Python-Dev] small PATCH to fix os.fsync on OS X In-Reply-To: <18e505e30808062136s8f8c67x21d32e5849e886d4@mail.gmail.com> References: <18e505e30808062136s8f8c67x21d32e5849e886d4@mail.gmail.com> Message-ID: On Aug 7, 2008, at 12:36 AM, Ian Charnas wrote: > Hello heroes and heroins of the python universe, lend me your ears and > I will tell you a tale that will make your platters spin! > > As noted by SQLite [1] and MySQL [2] developers, fsync on OS X does > not actually flush a file to disk... instead OS X provides "fullfsync" > which actually flushes the file descriptor to disk. This simple patch > modifies python's "fsync" to take advantage of fullfsync on platforms > that support it: > http://bugs.python.org/issue3512 > > While some people might suggest that fullfsync should be exposed as a > method on the 'os' module for platforms that support it, I believe > this is not the best approach. Because the docstring for os.fsync > says that it forces the file to be written to disk, I think it's up to > python to ensure that functionality is really there on all platforms. > Currently on OS X, fullfsync is needed to provide this functionality, > so I think python's os.fsync should use fullfsync on OS X. Please don't make that change. fsync on OSX does the same thing as fsync traditionally does on other OSes. That is: it flushes the data to "disk", but doesn't make any effort to ensure that the disk drive actually flushes the data from its own write cache to the platter. Other OSes just don't expose that functionality *at all*. See e.g. this thread: http://lists.apple.com/archives/Darwin-dev/2005/Feb/msg00072.html You should instead propose a patch to add F_FULLSYNC to the fcntl module when present. James From richard at tartarus.org Thu Aug 7 07:18:53 2008 From: richard at tartarus.org (Richard Boulton) Date: Thu, 07 Aug 2008 06:18:53 +0100 Subject: [Python-Dev] small PATCH to fix os.fsync on OS X In-Reply-To: References: <18e505e30808062136s8f8c67x21d32e5849e886d4@mail.gmail.com> Message-ID: <489A85BD.4070902@tartarus.org> James Y Knight wrote: > On Aug 7, 2008, at 12:36 AM, Ian Charnas wrote: >> While some people might suggest that fullfsync should be exposed as a >> method on the 'os' module for platforms that support it, I believe >> this is not the best approach. Because the docstring for os.fsync >> says that it forces the file to be written to disk, I think it's up to >> python to ensure that functionality is really there on all platforms. >> Currently on OS X, fullfsync is needed to provide this functionality, >> so I think python's os.fsync should use fullfsync on OS X. > > Please don't make that change. fsync on OSX does the same thing as fsync > traditionally does on other OSes. That is: it flushes the data to > "disk", but doesn't make any effort to ensure that the disk drive > actually flushes the data from its own write cache to the platter. > > Other OSes just don't expose that functionality *at all*. > > See e.g. this thread: > http://lists.apple.com/archives/Darwin-dev/2005/Feb/msg00072.html > > You should instead propose a patch to add F_FULLSYNC to the fcntl module > when present. I can't think of a situation where it would be useful to do an fsync() in which you don't want the data to be flushed as far as possible. If you're bothering to call fsync(), it's presumably because you need to guarantee that the data will be in a consistent state in the event of a failure (like a power cut). So I think it would be helpful for an fsync call in a high-level language to handle the details of this. However, my perspective is largely tied to databases, so there may be other situations that I can't think of where it does make sense to want to push changes as far as the on-disk buffers, but no further. If the change suggested isn't to be made to os.fsync(), I think it would at least be helpful to add a note to the os.fsync docstring mentioning this limitation, and pointing to the F_FULLSYNC in the fcntl module when this is implemented. And perhaps add an implementation of fsync which _does_ also do F_FULLSYNC elsewhere (shutil.fsync()?), to save all those users of fsync() who also want F_FULLSYNC from having to implement code which calls F_FULLSYNC when available and os.fsync() otherwise. -- Richard From scott+python-dev at scottdial.com Thu Aug 7 07:44:58 2008 From: scott+python-dev at scottdial.com (Scott Dial) Date: Thu, 07 Aug 2008 01:44:58 -0400 Subject: [Python-Dev] small PATCH to fix os.fsync on OS X In-Reply-To: <489A85BD.4070902@tartarus.org> References: <18e505e30808062136s8f8c67x21d32e5849e886d4@mail.gmail.com> <489A85BD.4070902@tartarus.org> Message-ID: <489A8BDA.2050507@scottdial.com> Richard Boulton wrote: > I can't think of a situation where it would be useful to do an fsync() > in which you don't want the data to be flushed as far as possible. If > you're bothering to call fsync(), it's presumably because you need to > guarantee that the data will be in a consistent state in the event of a > failure (like a power cut). So I think it would be helpful for an fsync > call in a high-level language to handle the details of this. But the file descriptor functions provided by the posix module are *not* high-level calls, and in fact, that is part of the point of the module. There is a noticeable performance penalty for waiting on F_FULLSYNC to complete, and a programmer who is already going outside of the normal mode of python file-handling (using file objects) should have a choice in the matter. -Scott -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From matt.giuca at gmail.com Thu Aug 7 12:37:39 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Thu, 7 Aug 2008 20:37:39 +1000 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: <4899CCB3.5020208@v.loewis.de> References: <200808060951.54723.nd@perlig.de> <200808061559.28341.nd@perlig.de> <4899CCB3.5020208@v.loewis.de> Message-ID: Wow .. a lot of replies today! On Thu, Aug 7, 2008 at 2:09 AM, "Martin v. L?wis" wrote: > It hasn't been given priority: There are currently 606 patches in the > tracker, many fixing bugs of some sort. It's not clear (to me, at least) > why this should be given priority over all the other things such as > interpreter crashes. Sorry ... when I said "it hasn't been given priority" I mean "it hasn't been given *a* priority" - as in, nobody's assigned a priority to it, whatever that priority should rightfully be. > We all agree it's a bug: no, I don't. I think it's a missing feature, > at best, but I'm staying out of the discussion. As-is, urllib only > supports ASCII in URLs, and that is fine for most purposes. Seriously, Mr. L%C3%B6wis, that's a tremendously na%C3%AFve statement. > URLs are just not made for non-ASCII characters. Implement IRIs if you > want non-ASCII characters; the rules are much clearer for these. Python 3.0 fully supports Unicode. URIs support *encoding* of arbitrary characters (as of more recent revisions). The difference is that URIs *may only consist* of ASCII characters (even though they can encode Unicode characters), while IRIs may also consist of Unicode characters. It's our responsibility to implement URIs here ... IRIs are a separate issue. Having said this, I'm pretty sure Martin can't be convinced, so I'll leave that alone. On Thu, Aug 7, 2008 at 3:34 AM, M.-A. Lemburg wrote: > So unquote() should probably try to decode using UTF-8 first > and then fall back to Latin-1 if that doesn't work. That's an interesting proposal. I think I don't like it - for a user application that's a good policy. But for a programming language library, I think it should not do guesswork. It should use the encoding supplied, and have a single default. But I'd be interested to hear if anyone else wants this. As-is, it passes 'replace' to the errors argument, so encoding errors get replaced by '?' characters. OK I haven't looked at the review yet .. guess it's off to the tracker :) Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at v.loewis.de Thu Aug 7 15:48:55 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 07 Aug 2008 15:48:55 +0200 Subject: [Python-Dev] small PATCH to fix os.fsync on OS X In-Reply-To: <489A85BD.4070902@tartarus.org> References: <18e505e30808062136s8f8c67x21d32e5849e886d4@mail.gmail.com> <489A85BD.4070902@tartarus.org> Message-ID: <489AFD47.7080100@v.loewis.de> > I can't think of a situation where it would be useful to do an fsync() > in which you don't want the data to be flushed as far as possible. Essentially, you are saying that you don't see a use for fsync. If that's the case, then this API should be removed from Python completely. As all others have said: the strong feature of the posix module is that it exposes the operating system calls *as-is*, i.e. without trying to tweak their semantics. If Apple had found it as a useful default for fsync to have the harddisk flushed, they would have put that into the implementation of fsync, instead of coming up with a new API. We don't second-guess operating system vendors (normally). Please understand the enormous relevance of this strategy. If we deviate from it, people might be stuck in chasing the culprit, complaining alternatingly to the OS vendor and to Python. With our strategy to the POSIX module, we can always defer people to the system vendor, and they can easily reproduce the behavior with a C program. (Of course, we also have higher-layer libbraries, were any bugs are our own). Regards, Martin From ian.charnas at gmail.com Thu Aug 7 16:17:34 2008 From: ian.charnas at gmail.com (Ian Charnas) Date: Thu, 7 Aug 2008 10:17:34 -0400 Subject: [Python-Dev] small PATCH to fix os.fsync on OS X In-Reply-To: <489AFD47.7080100@v.loewis.de> References: <18e505e30808062136s8f8c67x21d32e5849e886d4@mail.gmail.com> <489A85BD.4070902@tartarus.org> <489AFD47.7080100@v.loewis.de> Message-ID: <18e505e30808070717i466d25a3y637b9e0be2244655@mail.gmail.com> Excellent comments, everyone. It looks like I didn't know the full situation, thanks scott for pointing me towards that email on darwin-dev. The email said that fsync on OS X does indeed force a flush from the operating system to the hard drive (so my earlier understanding was incorrect), but data could still be waiting in the write buffer of the physical hard drive, so OS X provides a "fullfsync" feature to force the disk to flush its buffers. So far they are seemingly the only unix to provide this. So, I think we should cancel the ticket I made in Roundup, and I'd like to make another patch that exposes os.fullfsync on platforms that support it, just like we already have os.fdatasync on supported platforms. That way, os.fsync remains untouched, and people wishing to get at fullfsync may do so. comments? Should I go ahead and make this patch? many thanks, -Ian Charnas On Thu, Aug 7, 2008 at 9:48 AM, "Martin v. L?wis" wrote: >> I can't think of a situation where it would be useful to do an fsync() >> in which you don't want the data to be flushed as far as possible. > > Essentially, you are saying that you don't see a use for fsync. If > that's the case, then this API should be removed from Python completely. > > As all others have said: the strong feature of the posix module is that > it exposes the operating system calls *as-is*, i.e. without trying to > tweak their semantics. > > If Apple had found it as a useful default for fsync to have the > harddisk flushed, they would have put that into the implementation > of fsync, instead of coming up with a new API. We don't second-guess > operating system vendors (normally). > > Please understand the enormous relevance of this strategy. If we > deviate from it, people might be stuck in chasing the culprit, > complaining alternatingly to the OS vendor and to Python. With our > strategy to the POSIX module, we can always defer people to the > system vendor, and they can easily reproduce the behavior with > a C program. (Of course, we also have higher-layer libbraries, were > any bugs are our own). > > Regards, > Martin > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ian.charnas%40gmail.com > From ian.charnas at gmail.com Thu Aug 7 19:39:46 2008 From: ian.charnas at gmail.com (Ian Charnas) Date: Thu, 7 Aug 2008 13:39:46 -0400 Subject: [Python-Dev] small PATCH to fix os.fsync on OS X In-Reply-To: <18e505e30808070717i466d25a3y637b9e0be2244655@mail.gmail.com> References: <18e505e30808062136s8f8c67x21d32e5849e886d4@mail.gmail.com> <489A85BD.4070902@tartarus.org> <489AFD47.7080100@v.loewis.de> <18e505e30808070717i466d25a3y637b9e0be2244655@mail.gmail.com> Message-ID: <18e505e30808071039w70ca11b3t7cda2b0cf36efa38@mail.gmail.com> OK I finished a patch that exposes os.fullfsync on platforms that support it, and I added the corresponding documentation in Doc/library/os.rst Any comments? http://bugs.python.org/issue3517 -ian On Thu, Aug 7, 2008 at 10:17 AM, Ian Charnas wrote: > Excellent comments, everyone. It looks like I didn't know the full > situation, thanks scott for pointing me towards that email on > darwin-dev. The email said that fsync on OS X does indeed force a > flush from the operating system to the hard drive (so my earlier > understanding was incorrect), but data could still be waiting in the > write buffer of the physical hard drive, so OS X provides a > "fullfsync" feature to force the disk to flush its buffers. So far > they are seemingly the only unix to provide this. > > So, I think we should cancel the ticket I made in Roundup, and I'd > like to make another patch that exposes os.fullfsync on platforms that > support it, just like we already have os.fdatasync on supported > platforms. > > That way, os.fsync remains untouched, and people wishing to get at > fullfsync may do so. > > comments? Should I go ahead and make this patch? > > many thanks, > -Ian Charnas > > On Thu, Aug 7, 2008 at 9:48 AM, "Martin v. L?wis" wrote: >>> I can't think of a situation where it would be useful to do an fsync() >>> in which you don't want the data to be flushed as far as possible. >> >> Essentially, you are saying that you don't see a use for fsync. If >> that's the case, then this API should be removed from Python completely. >> >> As all others have said: the strong feature of the posix module is that >> it exposes the operating system calls *as-is*, i.e. without trying to >> tweak their semantics. >> >> If Apple had found it as a useful default for fsync to have the >> harddisk flushed, they would have put that into the implementation >> of fsync, instead of coming up with a new API. We don't second-guess >> operating system vendors (normally). >> >> Please understand the enormous relevance of this strategy. If we >> deviate from it, people might be stuck in chasing the culprit, >> complaining alternatingly to the OS vendor and to Python. With our >> strategy to the POSIX module, we can always defer people to the >> system vendor, and they can easily reproduce the behavior with >> a C program. (Of course, we also have higher-layer libbraries, were >> any bugs are our own). >> >> Regards, >> Martin >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ian.charnas%40gmail.com >> > From curt at hagenlocher.org Fri Aug 8 00:25:51 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 7 Aug 2008 15:25:51 -0700 Subject: [Python-Dev] Milestones in IronPython Message-ID: We reached an important milestone in the IronPython project this week with the release of IronPython 2.0 beta 4. But it's not our code that makes this release so remarkable -- it's yours, the Python developers. For the first time, Microsoft is including the standard Python library as part of what you can download from CodePlex. Previously, users of IronPython who wanted to make use of the urllib module (to give just one example) would have to download the CPython distribution separately and then fiddle with the bits on the disk to make them work together. That is no longer the case. Of course, this isn't any kind of great technical achievement -- but it is legal and cultural progress here at Microsoft. All of us working on the IronPython and IronRuby projects are committed to pulling the company in a more open source direction, so it's very gratifying to see this happening. Links: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=14353 http://devhawk.net/2008/08/06/Including+The+Batteries+In+IronPython.aspx (IronPython 2.0 targets compatibility with Python 2.5.) -- Curt Hagenlocher curt at hagenlocher.org From brett at python.org Fri Aug 8 00:36:10 2008 From: brett at python.org (Brett Cannon) Date: Thu, 7 Aug 2008 15:36:10 -0700 Subject: [Python-Dev] Milestones in IronPython In-Reply-To: References: Message-ID: On Thu, Aug 7, 2008 at 3:25 PM, Curt Hagenlocher wrote: > We reached an important milestone in the IronPython project this week > with the release of IronPython 2.0 beta 4. But it's not our code that > makes this release so remarkable -- it's yours, the Python developers. > For the first time, Microsoft is including the standard Python > library as part of what you can download from CodePlex. Previously, > users of IronPython who wanted to make use of the urllib module (to > give just one example) would have to download the CPython distribution > separately and then fiddle with the bits on the disk to make them work > together. That is no longer the case. > > Of course, this isn't any kind of great technical achievement -- but > it is legal and cultural progress here at Microsoft. All of us > working on the IronPython and IronRuby projects are committed to > pulling the company in a more open source direction, so it's very > gratifying to see this happening. > Glad you were able to work out what you needed internally to see this happen, Curt! -Brett From guido at python.org Fri Aug 8 01:30:17 2008 From: guido at python.org (Guido van Rossum) Date: Thu, 7 Aug 2008 16:30:17 -0700 Subject: [Python-Dev] urllib.quote and unquote - Unicode issues In-Reply-To: References: <200808060951.54723.nd@perlig.de> <200808061559.28341.nd@perlig.de> <4899CCB3.5020208@v.loewis.de> Message-ID: FWIW, the rest of this discussion is now happening in the tracker: http://bugs.python.org/issue3300. We could really use some feedback from Python users in Asian countries. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Fri Aug 8 01:48:30 2008 From: guido at python.org (Guido van Rossum) Date: Thu, 7 Aug 2008 16:48:30 -0700 Subject: [Python-Dev] Milestones in IronPython In-Reply-To: References: Message-ID: On Thu, Aug 7, 2008 at 3:36 PM, Brett Cannon wrote: > On Thu, Aug 7, 2008 at 3:25 PM, Curt Hagenlocher wrote: >> We reached an important milestone in the IronPython project this week >> with the release of IronPython 2.0 beta 4. But it's not our code that >> makes this release so remarkable -- it's yours, the Python developers. >> For the first time, Microsoft is including the standard Python >> library as part of what you can download from CodePlex. Previously, >> users of IronPython who wanted to make use of the urllib module (to >> give just one example) would have to download the CPython distribution >> separately and then fiddle with the bits on the disk to make them work >> together. That is no longer the case. >> >> Of course, this isn't any kind of great technical achievement -- but >> it is legal and cultural progress here at Microsoft. All of us >> working on the IronPython and IronRuby projects are committed to >> pulling the company in a more open source direction, so it's very >> gratifying to see this happening. >> > > Glad you were able to work out what you needed internally to see this > happen, Curt! Indeed, very good news. It made Google's internal open source list already. :-) Congrats on the release, Curt and team!! -- --Guido van Rossum (home page: http://www.python.org/~guido/) From status at bugs.python.org Fri Aug 8 18:07:21 2008 From: status at bugs.python.org (Python tracker) Date: Fri, 8 Aug 2008 18:07:21 +0200 (CEST) Subject: [Python-Dev] Summary of Python tracker Issues Message-ID: <20080808160721.69D74781EA@psf.upfronthosting.co.za> ACTIVITY SUMMARY (08/01/08 - 08/08/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1943 open (+19) / 13408 closed (+27) / 15351 total (+46) Open issues with patches: 611 Average duration of open issues: 722 days. Median duration of open issues: 1632 days. Open Issues Breakdown open 1931 (+19) pending 12 ( +0) Issues Created Or Reopened (46) _______________________________ sys.stdin.read won't return on EOF 08/01/08 CLOSED http://bugs.python.org/issue3483 created benjamin.peterson Sphinx tests fail because of missing dir 08/01/08 CLOSED http://bugs.python.org/issue3484 created cakebread os.path.normcase documentation/behaviour unclear on Mac OS X 08/01/08 http://bugs.python.org/issue3485 created ijmorlan bytes.join does not accept a sequence of bytearrays 08/01/08 http://bugs.python.org/issue3486 created pitrou sre "bytecode" verifier 08/01/08 CLOSED http://bugs.python.org/issue3487 created gvanrossum patch, patch Provide compress/uncompress functions on the gzip module 08/01/08 http://bugs.python.org/issue3488 created pythonhacker patch add rotate{left,right} methods to bytearray 08/01/08 http://bugs.python.org/issue3489 created pitrou Example Code Error in Tutorial Documentation 08/02/08 CLOSED http://bugs.python.org/issue3490 created yoshokun compile error fixing (_multiprocessing, windows) 08/02/08 CLOSED http://bugs.python.org/issue3491 created ocean-city patch, patch Zlib compress/decompress functions returning bytearray 08/02/08 http://bugs.python.org/issue3492 created pythonhacker patch No Backslash (\) in IDLE 1.2.2 08/02/08 http://bugs.python.org/issue3493 created Marc67 "[Errno 11] Resource temporarily unavailable" while using tracin 08/02/08 http://bugs.python.org/issue3494 created fabioz site module doc typo 08/03/08 CLOSED http://bugs.python.org/issue3495 created ijstokes distutils fails with mingw binutils 2.18.50.20080109 08/03/08 http://bugs.python.org/issue3496 created pmoore patch a bug in the interpreter? 08/03/08 CLOSED http://bugs.python.org/issue3497 created bad mod_cls 08/04/08 CLOSED http://bugs.python.org/issue3498 created schuppenies patch Python 2.6 requires pre-installed Python to build 08/04/08 http://bugs.python.org/issue3499 created lemburg unbound methods of different classes compare equal 08/04/08 http://bugs.python.org/issue3500 created exarkun expm1 missing 08/04/08 http://bugs.python.org/issue3501 created ms Inconsistency between string.letters and default encoding. 08/05/08 CLOSED http://bugs.python.org/issue3502 created ramong Calls to print() function in Python 3.0 tutorial 08/05/08 CLOSED http://bugs.python.org/issue3503 created jsizelove patch Python Reference Manual inconsistency (Notation) 08/05/08 CLOSED http://bugs.python.org/issue3504 created pavlosto single/double quote error in Python v2.6b2 documentation 08/05/08 CLOSED http://bugs.python.org/issue3505 created pavlosto Change buffer/memoryview DeprecationWarning 08/05/08 CLOSED http://bugs.python.org/issue3506 created brett.cannon spelling in try.html 08/05/08 CLOSED http://bugs.python.org/issue3507 created jqxvjqxv range() is not a generator when used in for's 08/06/08 CLOSED http://bugs.python.org/issue3508 created epsilon_da La Lutte, Je Vais Vous Montrer Mon Piquer! 08/06/08 CLOSED http://bugs.python.org/issue3509 created MrJean1 Site-specific configuration hook documentation incorrect 08/06/08 http://bugs.python.org/issue3510 created proebuck Incorrect charset range handling with ignore case flag? 08/06/08 http://bugs.python.org/issue3511 created mrabarnett Change fsync to use fullfsync on platforms (like OS X) that have 08/07/08 CLOSED http://bugs.python.org/issue3512 created icharnas patch test_multiprocessing hangs without this patch on win2k 08/07/08 CLOSED http://bugs.python.org/issue3513 created ocean-city patch pickle segfault with infinite loop in __getattr__ 08/07/08 http://bugs.python.org/issue3514 created erickt refcount gc bug? 08/07/08 CLOSED http://bugs.python.org/issue3515 created ocean-city string formatting quirk using %.% 08/07/08 CLOSED http://bugs.python.org/issue3516 created blop PATCH - Providing fullfsync on supported platforms 08/07/08 CLOSED http://bugs.python.org/issue3517 created icharnas patch multiprocessing: BaseManager.from_address documented but doesn't 08/07/08 http://bugs.python.org/issue3518 created marketdickinson Evaluation order example lacks suffix 08/07/08 CLOSED http://bugs.python.org/issue3519 created tjreedy New Global Module Index glitch on WinXP 08/07/08 http://bugs.python.org/issue3520 created tjreedy file.readline: bad exception recovery 08/07/08 http://bugs.python.org/issue3521 created tjreedy easy zip() function example in tutorial 08/08/08 CLOSED http://bugs.python.org/issue3522 created jsizelove patch Reverse quotes in Python 3.0 tutorial 08/08/08 CLOSED http://bugs.python.org/issue3523 created jsizelove patch IOError when attempting negative seek in file (Python 3.0 tutori 08/08/08 CLOSED http://bugs.python.org/issue3524 created jsizelove Changes to exceptions not reflected in tutorial examples. 08/08/08 CLOSED http://bugs.python.org/issue3525 created jsizelove patch Customized malloc implementation on SunOS and AIX 08/08/08 http://bugs.python.org/issue3526 created sable patch Py_WIN_WIDE_FILENAMES removal 08/08/08 http://bugs.python.org/issue3527 created ocean-city patch TypeError when compiling with no translator 08/08/08 CLOSED http://bugs.python.org/issue3528 created schuppenies patch Issues Now Closed (55) ______________________ ioctl request argument broken on 64-bit OpenBSD or OS X 258 days http://bugs.python.org/issue1471 gregory.p.smith patch, 64bit, easy Doc: subprocess wait() may lead to dead lock 235 days http://bugs.python.org/issue1606 gregory.p.smith subprocess.Popen.poll/__del__ API breakage 200 days http://bugs.python.org/issue1857 gregory.p.smith patch Bad interaction between signal and subprocess 171 days http://bugs.python.org/issue2113 gregory.p.smith patch MozillaCookieJar does not support Firefox3 cookie files 145 days http://bugs.python.org/issue2277 gregory.p.smith patch Backport reload() moving to imp.reload() 142 days http://bugs.python.org/issue2338 brett.cannon 26backport memoryview of bytes is not readonly 122 days http://bugs.python.org/issue2538 pitrou patch Error when nesting many while loops 98 days http://bugs.python.org/issue2688 jackdied Create the urllib package 49 days http://bugs.python.org/issue2885 brett.cannon rfc822.py line 395 strings connection 72 days http://bugs.python.org/issue2935 jackdied ElementTree parsing bus error (but only from mod_python) 70 days http://bugs.python.org/issue2951 jackdied tarfile.TarFileCompat.writestr(ZipInfo, str) raises AttributeErr 58 days http://bugs.python.org/issue3039 lars.gustaebel patch subprocess module truncates handles on AMD64 49 days http://bugs.python.org/issue3120 gregory.p.smith patch, 64bit, easy mailbox.mbox creates files with execute bit set 37 days http://bugs.python.org/issue3228 akuchling patch Memory corruption in multiprocessing module, OS X 10.5.4 15 days http://bugs.python.org/issue3399 jnoller patch urllib.urlopen() return type 17 days http://bugs.python.org/issue3429 ThomasH os.remove()method document error 7 days http://bugs.python.org/issue3455 georg.brandl optimize bytes.join() 5 days http://bugs.python.org/issue3459 tjreedy patch PyUnicode_Join could perhaps be simpler 10 days http://bugs.python.org/issue3460 pitrou patch make life.py use more rendering characters 7 days http://bugs.python.org/issue3463 akuchling patch Umlauts make conf.latex_documents fail 2 days http://bugs.python.org/issue3469 georg.brandl grammar productionlist are not properly indented 5 days http://bugs.python.org/issue3477 georg.brandl Fix_imports pattern optimization 1 days http://bugs.python.org/issue3480 collinwinter patch sys.stdin.read won't return on EOF 0 days http://bugs.python.org/issue3483 benjamin.peterson Sphinx tests fail because of missing dir 0 days http://bugs.python.org/issue3484 benjamin.peterson sre "bytecode" verifier 3 days http://bugs.python.org/issue3487 gvanrossum patch, patch Example Code Error in Tutorial Documentation 0 days http://bugs.python.org/issue3490 yoshokun compile error fixing (_multiprocessing, windows) 0 days http://bugs.python.org/issue3491 benjamin.peterson patch, patch site module doc typo 0 days http://bugs.python.org/issue3495 georg.brandl a bug in the interpreter? 0 days http://bugs.python.org/issue3497 tim_one mod_cls 0 days http://bugs.python.org/issue3498 georg.brandl patch Inconsistency between string.letters and default encoding. 0 days http://bugs.python.org/issue3502 loewis Calls to print() function in Python 3.0 tutorial 0 days http://bugs.python.org/issue3503 georg.brandl patch Python Reference Manual inconsistency (Notation) 0 days http://bugs.python.org/issue3504 georg.brandl single/double quote error in Python v2.6b2 documentation 1 days http://bugs.python.org/issue3505 georg.brandl Change buffer/memoryview DeprecationWarning 2 days http://bugs.python.org/issue3506 brett.cannon spelling in try.html 1 days http://bugs.python.org/issue3507 georg.brandl range() is not a generator when used in for's 0 days http://bugs.python.org/issue3508 marketdickinson La Lutte, Je Vais Vous Montrer Mon Piquer! 0 days http://bugs.python.org/issue3509 loewis Change fsync to use fullfsync on platforms (like OS X) that have 1 days http://bugs.python.org/issue3512 icharnas patch test_multiprocessing hangs without this patch on win2k 0 days http://bugs.python.org/issue3513 ocean-city patch refcount gc bug? 0 days http://bugs.python.org/issue3515 pitrou string formatting quirk using %.% 0 days http://bugs.python.org/issue3516 georg.brandl PATCH - Providing fullfsync on supported platforms 0 days http://bugs.python.org/issue3517 gvanrossum patch Evaluation order example lacks suffix 0 days http://bugs.python.org/issue3519 georg.brandl zip() function example in tutorial 0 days http://bugs.python.org/issue3522 georg.brandl patch Reverse quotes in Python 3.0 tutorial 0 days http://bugs.python.org/issue3523 georg.brandl patch IOError when attempting negative seek in file (Python 3.0 tutori 0 days http://bugs.python.org/issue3524 georg.brandl Changes to exceptions not reflected in tutorial examples. 0 days http://bugs.python.org/issue3525 georg.brandl patch TypeError when compiling with no translator 0 days http://bugs.python.org/issue3528 georg.brandl patch tk_focusNext() fails 1795 days http://bugs.python.org/issue799428 loewis patch Update htmllib to HTML 4.01 1735 days http://bugs.python.org/issue836088 akuchling patch Python code.interact() and UTF-8 locale 1060 days http://bugs.python.org/issue1288615 pitrou patch long(float('nan'))!=0L 14 days http://bugs.python.org/issue1481296 marketdickinson patch long.__str__ is quadratic time 400 days http://bugs.python.org/issue1746088 marketdickinson Top Issues Most Discussed (10) ______________________________ 25 urllib.quote and unquote - Unicode issues 33 days open http://bugs.python.org/issue3300 11 multiprocessing module is racy 20 days open http://bugs.python.org/issue3419 10 Change buffer/memoryview DeprecationWarning 2 days closed http://bugs.python.org/issue3506 10 mailbox.mbox creates files with execute bit set 37 days closed http://bugs.python.org/issue3228 8 a bug in the interpreter? 0 days closed http://bugs.python.org/issue3497 8 bytearrays are not thread safe 50 days open http://bugs.python.org/issue3139 7 test_multiprocessing: test_listener_client flakiness 36 days open http://bugs.python.org/issue3270 6 refcount gc bug? 0 days closed http://bugs.python.org/issue3515 6 range() is not a generator when used in for's 0 days closed http://bugs.python.org/issue3508 6 unbound methods of different classes compare equal 4 days open http://bugs.python.org/issue3500 From jstritar at gmail.com Fri Aug 8 22:17:57 2008 From: jstritar at gmail.com (Jon Stritar) Date: Fri, 8 Aug 2008 16:17:57 -0400 Subject: [Python-Dev] Python Virtual Machine Architecture Message-ID: <8338cad40808081317t9c3d30bl9912210b07b6aeae@mail.gmail.com> I'm trying to understand the architecture of the core Python interpreter and virtual machine, but I've been having trouble finding the documentation. It looks like most of the docs are for either writing Python programs or extending / writing modules. Is there any documentation (or papers) geared towards understanding the core? The closest I could find was this, http://docs.python.org/api/api.html but that is still geared towards extending it with C modules. I guess I'm more interested in python's security architecture, but anything about the VM or interpreter would be great! Thanks, --Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.soto at gmail.com Fri Aug 8 23:02:35 2008 From: leo.soto at gmail.com (Leo Soto M.) Date: Fri, 8 Aug 2008 17:02:35 -0400 Subject: [Python-Dev] Python Virtual Machine Architecture In-Reply-To: <8338cad40808081317t9c3d30bl9912210b07b6aeae@mail.gmail.com> References: <8338cad40808081317t9c3d30bl9912210b07b6aeae@mail.gmail.com> Message-ID: <5a8cc9e00808081402h58790bfiff154ce8a9756f13@mail.gmail.com> On Fri, Aug 8, 2008 at 4:17 PM, Jon Stritar wrote: > I'm trying to understand the architecture of the core Python interpreter and > virtual machine, but I've been having trouble finding the documentation. It > looks like most of the docs are for either writing Python programs or > extending / writing modules. Is there any documentation (or papers) geared > towards understanding the core? Maybe ? -- Leo Soto M. http://blog.leosoto.com From barry at barrys-emacs.org Sat Aug 9 00:26:43 2008 From: barry at barrys-emacs.org (Barry Scott) Date: Fri, 8 Aug 2008 23:26:43 +0100 Subject: [Python-Dev] String concatenation In-Reply-To: <4895F4FE.3040102@korokithakis.net> References: <4895EE62.8080605@korokithakis.net> <4895F2E0.5040709@voidspace.org.uk> <4895F4FE.3040102@korokithakis.net> Message-ID: <3955FA47-EFC4-4520-A903-9CB32CA166B7@barrys-emacs.org> On Aug 3, 2008, at 19:12, Stavros Korokithakis wrote: > Hmm, thanks, although I don't see why it was rejected, since it > seems to me that by using the addition operator or triple-quoting > all the use cases would become clearer and not significantly harder > to write, while the (often silent) errors would not happen any more. I use this feature all the time in preference to triple quote strings to allow the indenting structure to be preserved. def I_like_this(): s = ("a multi line\n" "that keeps the indent of the function") return def I_do_not_like_this(): s = '''a multi line that break the indent of the function" return Barry From matt.giuca at gmail.com Sat Aug 9 09:22:19 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Sat, 9 Aug 2008 17:22:19 +1000 Subject: [Python-Dev] String concatenation In-Reply-To: <3955FA47-EFC4-4520-A903-9CB32CA166B7@barrys-emacs.org> References: <4895EE62.8080605@korokithakis.net> <4895F2E0.5040709@voidspace.org.uk> <4895F4FE.3040102@korokithakis.net> <3955FA47-EFC4-4520-A903-9CB32CA166B7@barrys-emacs.org> Message-ID: Is the only issue with this feature that you might accidentally miss a comma after a string in a sequence of strings? That seems like a significantly obscure scenario compared to the usefulness of the current syntax, for exactly the purpose Barry points out (which most people use all the time). I think the runtime concatenation costs are less important than the handiness of being able to break strings across lines without having to figure out where to put that '+' operator. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.giuca at gmail.com Sat Aug 9 09:40:32 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Sat, 9 Aug 2008 17:40:32 +1000 Subject: [Python-Dev] bytes.tohex in Python 3 Message-ID: Hi, I'm confused as to how you represent a bytes object in hexadecimal in Python 3. Of course in Python 2, you use str.encode('hex') to go to hex, and hexstr.decode('hex') to go from hex. In Python 3, they removed "hex" as a codec (which was a good move, I think). Now there's the static method bytes.fromhex(hexbytes) to go from hex. But I haven't figured out any (easy) way to convert a byte string to hex. Is there some way I haven't noticed, or is this an oversight? The easiest thing I can think of currently is this: ''.join(hex(b)[2:] for b in mybytes) I think there should be a bytes.tohex() method. I'll add this as a bug report if it indeed is an oversight, but I thought I'd check here first to make sure I'm not just missing something. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From skip at pobox.com Sat Aug 9 16:40:49 2008 From: skip at pobox.com (skip at pobox.com) Date: Sat, 9 Aug 2008 09:40:49 -0500 Subject: [Python-Dev] Merges from 2.6 to 3.0? Message-ID: <18589.44145.168712.151985@montanaro-dyndns-org.local> Are big merges from the trunk still being made to the py3k branch? I checked in a change to csv.DictReader on the trunk yesterday evening. I will port it to py3k if necessary, but I was under the impression that the merge gnomes are constantly busy at work behind the scene. If this activity has been curtailed because we are nearly late betas or something, let me know and I'll do it myself. Thx, Skip From guido at python.org Sat Aug 9 16:51:19 2008 From: guido at python.org (Guido van Rossum) Date: Sat, 9 Aug 2008 07:51:19 -0700 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: <18589.44145.168712.151985@montanaro-dyndns-org.local> References: <18589.44145.168712.151985@montanaro-dyndns-org.local> Message-ID: On Sat, Aug 9, 2008 at 7:40 AM, wrote: > Are big merges from the trunk still being made to the py3k branch? I > checked in a change to csv.DictReader on the trunk yesterday evening. I > will port it to py3k if necessary, but I was under the impression that the > merge gnomes are constantly busy at work behind the scene. If this activity > has been curtailed because we are nearly late betas or something, let me > know and I'll do it myself. They's still happening, as irregularly scheduled as ever. However if you think your change requires any kind of manual help to be merged, it's better to do the merge yourself for just that revision: svnmerge.py merge -rNNNNN. That way it'll be recorded as merged and a later big merge will skip it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From matt.giuca at gmail.com Sat Aug 9 18:33:12 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Sun, 10 Aug 2008 02:33:12 +1000 Subject: [Python-Dev] bytes.tohex in Python 3 In-Reply-To: References: Message-ID: Well, whether there's community support for this or not, I thought I'd have a go at implementing this, so I did. I've submitted a feature request + working patch to the bug tracker: http://bugs.python.org/issue3532 Matt PS. I mean ''.join("%02x" % b for b in mybytes) -------------- next part -------------- An HTML attachment was scrubbed... URL: From skip at pobox.com Sat Aug 9 18:37:59 2008 From: skip at pobox.com (skip at pobox.com) Date: Sat, 9 Aug 2008 11:37:59 -0500 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: References: <18589.44145.168712.151985@montanaro-dyndns-org.local> Message-ID: <18589.51175.581371.874708@montanaro-dyndns-org.local> Guido> However if you think your change requires any kind of manual help Guido> to be merged, it's better to do the merge yourself for just that Guido> revision: svnmerge.py merge -rNNNNN. That way it'll be recorded Guido> as merged and a later big merge will skip it. Looks like there's a bit of manual work to do (replacing "try/finally" with "with", for example). I don't know what svnmerge.py is though and don't see it in my svn tools or my trunk sandbox: ~% cd ~/src/python/trunk/ trunk% find . -name svnmerge.py trunk% like svn /usr/bin/svn /usr/bin/svnadmin /usr/bin/svndumpfilter /usr/bin/svnlook /usr/bin/svnserve /usr/bin/svnsync /usr/bin/svnversion Skip From guido at python.org Sat Aug 9 18:43:37 2008 From: guido at python.org (Guido van Rossum) Date: Sat, 9 Aug 2008 09:43:37 -0700 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: <18589.51175.581371.874708@montanaro-dyndns-org.local> References: <18589.44145.168712.151985@montanaro-dyndns-org.local> <18589.51175.581371.874708@montanaro-dyndns-org.local> Message-ID: Google for it. It's worth learning. :-) On Sat, Aug 9, 2008 at 9:37 AM, wrote: > > Guido> However if you think your change requires any kind of manual help > Guido> to be merged, it's better to do the merge yourself for just that > Guido> revision: svnmerge.py merge -rNNNNN. That way it'll be recorded > Guido> as merged and a later big merge will skip it. > > Looks like there's a bit of manual work to do (replacing "try/finally" with > "with", for example). I don't know what svnmerge.py is though and don't see > it in my svn tools or my trunk sandbox: > > ~% cd ~/src/python/trunk/ > trunk% find . -name svnmerge.py > trunk% like svn > /usr/bin/svn > /usr/bin/svnadmin > /usr/bin/svndumpfilter > /usr/bin/svnlook > /usr/bin/svnserve > /usr/bin/svnsync > /usr/bin/svnversion > > Skip > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Sat Aug 9 18:45:42 2008 From: guido at python.org (Guido van Rossum) Date: Sat, 9 Aug 2008 09:45:42 -0700 Subject: [Python-Dev] bytes.tohex in Python 3 In-Reply-To: References: Message-ID: On Sat, Aug 9, 2008 at 12:40 AM, Matt Giuca wrote: > I'm confused as to how you represent a bytes object in hexadecimal in Python > 3. Of course in Python 2, you use str.encode('hex') to go to hex, and > hexstr.decode('hex') to go from hex. > > In Python 3, they removed "hex" as a codec (which was a good move, I think). > Now there's the static method bytes.fromhex(hexbytes) to go from hex. But I > haven't figured out any (easy) way to convert a byte string to hex. Is there > some way I haven't noticed, or is this an oversight? > > The easiest thing I can think of currently is this: > ''.join(hex(b)[2:] for b in mybytes) > > I think there should be a bytes.tohex() method. I'll add this as a bug > report if it indeed is an oversight, but I thought I'd check here first to > make sure I'm not just missing something. How about import binascii binascii.hexlify(b'abc') -- --Guido van Rossum (home page: http://www.python.org/~guido/) From matt.giuca at gmail.com Sat Aug 9 20:41:33 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Sun, 10 Aug 2008 04:41:33 +1000 Subject: [Python-Dev] bytes.tohex in Python 3 In-Reply-To: References: Message-ID: Hi Guido, Ah yes Martin just pointed this out on the tracker. I think it would still be worthwhile having the tohex method, if not just to counter the obscurity of the binascii.hexlify function (but for other reasons too). Also there's an issue with all the functions in binascii - they return bytes, not strings. Is this an oversight? (My version of tohex returns a str). See tracker: http://bugs.python.org/issue3532 Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at v.loewis.de Sat Aug 9 20:47:19 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 09 Aug 2008 20:47:19 +0200 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: <18589.51175.581371.874708@montanaro-dyndns-org.local> References: <18589.44145.168712.151985@montanaro-dyndns-org.local> <18589.51175.581371.874708@montanaro-dyndns-org.local> Message-ID: <489DE637.8060909@v.loewis.de> > Looks like there's a bit of manual work to do (replacing "try/finally" with > "with", for example). Why that? Shouldn't the 2.6 code already use the with statement? Regards, Martin From brett at python.org Sat Aug 9 20:48:15 2008 From: brett at python.org (Brett Cannon) Date: Sat, 9 Aug 2008 11:48:15 -0700 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: <18589.51175.581371.874708@montanaro-dyndns-org.local> References: <18589.44145.168712.151985@montanaro-dyndns-org.local> <18589.51175.581371.874708@montanaro-dyndns-org.local> Message-ID: On Sat, Aug 9, 2008 at 9:37 AM, wrote: > > Guido> However if you think your change requires any kind of manual help > Guido> to be merged, it's better to do the merge yourself for just that > Guido> revision: svnmerge.py merge -rNNNNN. That way it'll be recorded > Guido> as merged and a later big merge will skip it. > > Looks like there's a bit of manual work to do (replacing "try/finally" with > "with", for example). I don't know what svnmerge.py is though and don't see > it in my svn tools or my trunk sandbox: > As always, the dev FAQ has the answer you are looking for: http://python.org/dev/faq/#how-do-i-merge-between-branches . From skip at pobox.com Sat Aug 9 21:11:26 2008 From: skip at pobox.com (skip at pobox.com) Date: Sat, 9 Aug 2008 14:11:26 -0500 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: <489DE637.8060909@v.loewis.de> References: <18589.44145.168712.151985@montanaro-dyndns-org.local> <18589.51175.581371.874708@montanaro-dyndns-org.local> <489DE637.8060909@v.loewis.de> Message-ID: <18589.60382.104109.721521@montanaro-dyndns-org.local> >> Looks like there's a bit of manual work to do (replacing >> "try/finally" with "with", for example). Martin> Why that? Shouldn't the 2.6 code already use the with statement? The csv test code uses try/finally on trunk but with on py3k. Skip From skip at pobox.com Sat Aug 9 21:50:03 2008 From: skip at pobox.com (Skip Montanaro) Date: Sat, 9 Aug 2008 19:50:03 +0000 (UTC) Subject: [Python-Dev] Merges from 2.6 to 3.0? References: <18589.44145.168712.151985@montanaro-dyndns-org.local> <18589.51175.581371.874708@montanaro-dyndns-org.local> Message-ID: >> I don't know what svnmerge.py is ... > As always, the dev FAQ has the answer you are looking for: > http://python.org/dev/faq/#how-do-i-merge-between-branches . OK, I ran svnmerge, resolved conflicts, ran the tests, checked in the changes with the commit message svnmerge generated. Am I supposed to block either the earlier revision (65605) from being merged from trunk to py3k or the later revision (65611) from being merged from py3k to trunk? Thx, Skip From guido at python.org Sat Aug 9 22:28:44 2008 From: guido at python.org (Guido van Rossum) Date: Sat, 9 Aug 2008 13:28:44 -0700 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: References: <18589.44145.168712.151985@montanaro-dyndns-org.local> <18589.51175.581371.874708@montanaro-dyndns-org.local> Message-ID: If you use svnmerge properly you won't have to block anything in this case. Blocking is used to mark revs that are applied to 2.6 but should *not* apply to 3.0. We never merge from py3k to the trunk, only from the trunk to py3k. --Guido On Sat, Aug 9, 2008 at 12:50 PM, Skip Montanaro wrote: >>> I don't know what svnmerge.py is ... > >> As always, the dev FAQ has the answer you are looking for: >> http://python.org/dev/faq/#how-do-i-merge-between-branches . > > OK, I ran svnmerge, resolved conflicts, ran the tests, checked in the > changes with the commit message svnmerge generated. Am I supposed to block > either the earlier revision (65605) from being merged from trunk to py3k or > the later revision (65611) from being merged from py3k to trunk? > > Thx, > > Skip > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From martin at v.loewis.de Sat Aug 9 22:36:31 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 09 Aug 2008 22:36:31 +0200 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: <18589.60382.104109.721521@montanaro-dyndns-org.local> References: <18589.44145.168712.151985@montanaro-dyndns-org.local> <18589.51175.581371.874708@montanaro-dyndns-org.local> <489DE637.8060909@v.loewis.de> <18589.60382.104109.721521@montanaro-dyndns-org.local> Message-ID: <489DFFCF.8000501@v.loewis.de> > Martin> Why that? Shouldn't the 2.6 code already use the with statement? > > The csv test code uses try/finally on trunk but with on py3k. So why doesn't it use with on the trunk? Regards, Martin From skip at pobox.com Sat Aug 9 22:51:29 2008 From: skip at pobox.com (skip at pobox.com) Date: Sat, 9 Aug 2008 15:51:29 -0500 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: References: <18589.44145.168712.151985@montanaro-dyndns-org.local> <18589.51175.581371.874708@montanaro-dyndns-org.local> Message-ID: <18590.849.872443.529009@montanaro-dyndns-org.local> Guido> If you use svnmerge properly you won't have to block anything in Guido> this case. Let's assume I used it correctly. (That, of course, remains to be seen.) What about the checkin I did will tell someone running svnmerge later that r65605 has already been merged to py3k? Skip From skip at pobox.com Sat Aug 9 22:52:09 2008 From: skip at pobox.com (skip at pobox.com) Date: Sat, 9 Aug 2008 15:52:09 -0500 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: <489DFFCF.8000501@v.loewis.de> References: <18589.44145.168712.151985@montanaro-dyndns-org.local> <18589.51175.581371.874708@montanaro-dyndns-org.local> <489DE637.8060909@v.loewis.de> <18589.60382.104109.721521@montanaro-dyndns-org.local> <489DFFCF.8000501@v.loewis.de> Message-ID: <18590.889.200327.640387@montanaro-dyndns-org.local> Martin> Why that? Shouldn't the 2.6 code already use the with statement? >> The csv test code uses try/finally on trunk but with on py3k. Martin> So why doesn't it use with on the trunk? I don't know. I sure wasn't going to change that code at this point. Skip From g.brandl at gmx.net Sun Aug 10 01:13:00 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Sat, 09 Aug 2008 23:13:00 +0000 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: <18590.849.872443.529009@montanaro-dyndns-org.local> References: <18589.44145.168712.151985@montanaro-dyndns-org.local> <18589.51175.581371.874708@montanaro-dyndns-org.local> <18590.849.872443.529009@montanaro-dyndns-org.local> Message-ID: skip at pobox.com schrieb: > Guido> If you use svnmerge properly you won't have to block anything in > Guido> this case. > > Let's assume I used it correctly. (That, of course, remains to be seen.) > What about the checkin I did will tell someone running svnmerge later that > r65605 has already been merged to py3k? svnmerge stores information about merged and blocked revisions in SVN properties of the root directory. In your case, you didn't commit the property change, so svnmerge doesn't assume 65605 as integrated yet. If you still have the property change in your working copy, please commit it. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From skip at pobox.com Sat Aug 9 23:27:30 2008 From: skip at pobox.com (skip at pobox.com) Date: Sat, 9 Aug 2008 16:27:30 -0500 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: References: <18589.44145.168712.151985@montanaro-dyndns-org.local> <18589.51175.581371.874708@montanaro-dyndns-org.local> <18590.849.872443.529009@montanaro-dyndns-org.local> Message-ID: <18590.3010.873903.72637@montanaro-dyndns-org.local> Georg> svnmerge stores information about merged and blocked revisions in Georg> SVN properties of the root directory. In your case, you didn't Georg> commit the property change, so svnmerge doesn't assume 65605 as Georg> integrated yet. If you still have the property change in your Georg> working copy, please commit it. Ah, ok. Done. I guess I shouldn't have specified the files to commit. I should have committed everything. Skip From g.brandl at gmx.net Sun Aug 10 01:55:23 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Sat, 09 Aug 2008 23:55:23 +0000 Subject: [Python-Dev] Merges from 2.6 to 3.0? In-Reply-To: <18590.3010.873903.72637@montanaro-dyndns-org.local> References: <18589.44145.168712.151985@montanaro-dyndns-org.local> <18589.51175.581371.874708@montanaro-dyndns-org.local> <18590.849.872443.529009@montanaro-dyndns-org.local> <18590.3010.873903.72637@montanaro-dyndns-org.local> Message-ID: skip at pobox.com schrieb: > Georg> svnmerge stores information about merged and blocked revisions in > Georg> SVN properties of the root directory. In your case, you didn't > Georg> commit the property change, so svnmerge doesn't assume 65605 as > Georg> integrated yet. If you still have the property change in your > Georg> working copy, please commit it. > > Ah, ok. Done. I guess I shouldn't have specified the files to commit. I > should have committed everything. Yep; thankfully svnmerge makes sure the working copy is clean before merging. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From brett at python.org Sun Aug 10 07:41:10 2008 From: brett at python.org (Brett Cannon) Date: Sat, 9 Aug 2008 22:41:10 -0700 Subject: [Python-Dev] Dealing with mimetools usage in the stdlib Message-ID: On my quest to remove warnings raised in 2.6 when Python is run with -3, the issue of dealing with mimetools has come up in terms of backwards-compatibility. For instance, in BaseHTTPServer, the headers attribute on BaseHTTPRequestHandler is an instance of mimetools.Message. But in 3.0 it is an instance of http.client.HTTPMessage. So my question is, should 2.6 be changed to match 3.0, or should deprecation warnings for mimetools (and possibly other modules) just be silenced so as to not risk breaking backwards-compatibility? -Brett From rhamph at gmail.com Sun Aug 10 08:52:47 2008 From: rhamph at gmail.com (Adam Olsen) Date: Sun, 10 Aug 2008 00:52:47 -0600 Subject: [Python-Dev] Dealing with mimetools usage in the stdlib In-Reply-To: References: Message-ID: On Sat, Aug 9, 2008 at 11:41 PM, Brett Cannon wrote: > On my quest to remove warnings raised in 2.6 when Python is run with > -3, the issue of dealing with mimetools has come up in terms of > backwards-compatibility. For instance, in BaseHTTPServer, the headers > attribute on BaseHTTPRequestHandler is an instance of > mimetools.Message. But in 3.0 it is an instance of > http.client.HTTPMessage. > > So my question is, should 2.6 be changed to match 3.0, or should > deprecation warnings for mimetools (and possibly other modules) just > be silenced so as to not risk breaking backwards-compatibility? Just silence them. The warnings are an aid for finding bugs, not an excuse to create more bugs. -- Adam Olsen, aka Rhamphoryncus From victor.stinner at haypocalc.com Sun Aug 10 18:43:31 2008 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Sun, 10 Aug 2008 18:43:31 +0200 Subject: [Python-Dev] Fuzzing bugs: most bugs are closed In-Reply-To: References: <200807191323.13124.victor.stinner@haypocalc.com> <200807202245.39874.victor.stinner@haypocalc.com> <20080721133319.GA15912@amk-desktop.matrixgroup.net> <200807211554.11468.victor.stinner@haypocalc.com> <20080721174141.GA16598@amk-desktop.matrixgroup.net> Message-ID: <489F1AB3.7050409@haypocalc.com> Guido van Rossum wrote: >>>> The underscore at the beginning of _sre clearly indicates that the module is >>>> not recommended for direct consumption, IMO. Even the functions that don't >>>> themselves start with an underscore... >>> >> I've written a re-code verifier for the Google App Engine ... which means that a protection against "evil _sre bytecode" was needed :-) Thanks Google and Guido to release this validator. Victor From barry at python.org Sun Aug 10 19:36:32 2008 From: barry at python.org (Barry Warsaw) Date: Sun, 10 Aug 2008 13:36:32 -0400 Subject: [Python-Dev] Any PEP about 2.6 -> 3000 code transition? In-Reply-To: References: <4838EA2D.7060402@jcea.es> <319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com> <488150A5.8050804@jcea.es> <488451AB.50406@jcea.es> <4884581F.8010201@jcea.es> Message-ID: <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 21, 2008, at 2:16 PM, Brett Cannon wrote: > But waiting until all the betas have gone out totally defeats the > purpose of the betas! It has already been stated that new code changes > that are even remotely shaky or anything not small needs a code review > at this point since we only have one beta left. Barry can correct me > if I am wrong, but dropping a major rewrite of bsddb into 3.0 between > b3 and rc1 is not acceptable. I wouldn't be surprised if all code > after b3 requires a code review since at that point we should just be > squashing bugs, not rewriting code. And if you are migrating all of > bsddb3 at once then that is going to be a massive code review that > should be happening in prep for rc1. I agree. Our last beta is scheduled for this wednesday and if we have any hope of hitting our Oct 1 target, we really can't afford to slip. I'll just state that I'm going to be even more conservative about what gets in after b3. I'd say that if you expect it to go in to Python 2.6 or 3.0, you better get it in now. > I really hate feeling like I am coming off as a jerk harping on this, > Jesus, as I don't want to discourage your contributions to pybsddb, > but it just doesn't feel reasonable to me to be doing this so late in > the release cycle. Let's however try to find a way to let Jesus and others continue to work on important tools like bsddb even if it can't make it into the final releases. Perhaps we can move this stuff to the sandbox and setuptools-ify it. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSJ8nIXEjvBPtnXfVAQKLKAP/dH9TkMUhNxWDn6hAwVWe/Jjen9/hEPAL ExYEMK1qxI8b2FYjphjG7+dA/xFh+tzOdymyjJuBMy69TJMdWF1uh614Dfl0NYNA 7IsHCZlRZWVARPv0ZG8DZR3scBDPmHjxkBpzzyXH/yqJ/SaN5cdoOuYcMZUsIilN 2gr0MNvfe4I= =Rkk4 -----END PGP SIGNATURE----- From brett at python.org Mon Aug 11 08:10:20 2008 From: brett at python.org (Brett Cannon) Date: Sun, 10 Aug 2008 23:10:20 -0700 Subject: [Python-Dev] Dealing with mimetools usage in the stdlib In-Reply-To: References: Message-ID: On Sat, Aug 9, 2008 at 11:52 PM, Adam Olsen wrote: > On Sat, Aug 9, 2008 at 11:41 PM, Brett Cannon wrote: >> On my quest to remove warnings raised in 2.6 when Python is run with >> -3, the issue of dealing with mimetools has come up in terms of >> backwards-compatibility. For instance, in BaseHTTPServer, the headers >> attribute on BaseHTTPRequestHandler is an instance of >> mimetools.Message. But in 3.0 it is an instance of >> http.client.HTTPMessage. >> >> So my question is, should 2.6 be changed to match 3.0, or should >> deprecation warnings for mimetools (and possibly other modules) just >> be silenced so as to not risk breaking backwards-compatibility? > > Just silence them. The warnings are an aid for finding bugs, not an > excuse to create more bugs. > The problem I just realized with silencing them, though, is that the warning only occurs once at initial import, so if you silence the import in BaseHTTPServer but then import mimetools directly later on the DeprecationWarning won't come up from the later import. It's an unfortunate side-effect of caching imported modules in sys.modules. The only way around it is to either delete the module out of sys.modules so that subsequent imports will reload the module, or to come up with some modification to import that does some check for a __deprecated__ flag or something and raises the proper deprecation with the specified message before returning the module (which I really don't see happening this late in the development cycle, but still might be a good idea to think through for 2.7/3.1):: import sys if sys.py3kwarning: __deprecated__ = "the mimetools module has been removed in Python 3.0" # Rest of module's code -Brett From solipsis at pitrou.net Mon Aug 11 11:51:05 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 11 Aug 2008 09:51:05 +0000 (UTC) Subject: [Python-Dev] next beta References: <4838EA2D.7060402@jcea.es> <319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com> <488150A5.8050804@jcea.es> <488451AB.50406@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> Message-ID: Barry Warsaw python.org> writes: > > I agree. Our last beta is scheduled for this wednesday Are you sure? According to http://mail.python.org/pipermail/python-3000/2008-July/014269.html, it's scheduled for August 23rd. From barry at python.org Mon Aug 11 14:27:14 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 11 Aug 2008 08:27:14 -0400 Subject: [Python-Dev] next beta In-Reply-To: References: <4838EA2D.7060402@jcea.es> <319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com> <488150A5.8050804@jcea.es> <488451AB.50406@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> Message-ID: <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 11, 2008, at 5:51 AM, Antoine Pitrou wrote: > Barry Warsaw python.org> writes: >> >> I agree. Our last beta is scheduled for this wednesday > > Are you sure? > According to http://mail.python.org/pipermail/python-3000/2008-July/014269.html > , > it's scheduled for August 23rd. Ah darn, that's a typo in the PEP. I definitely meant August 13, as the Google calendar shows. Do we think we can be ready for beta3 this Wednesday? If not, I'd rather stick to a weekday release and do it on Wednesday August 20th. Let me know what you think. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKAwI3EjvBPtnXfVAQLumgQAqq6Vmk9qMQQRQkapppNPkypj8IuJiRAN MSCHi9iEj0RP4XpOuXF6oLAOJPajsabnC13J8Zu/tPqnrKR6gwTm/PG/6CDDi5tv JqNQJwBWyXOT56TtDxXNaIy2HIS2Klu6uqNUXoUrGdLuBskWeNBWlj87GKs0ozhq EfgXVbdl0+Y= =ZZd7 -----END PGP SIGNATURE----- From solipsis at pitrou.net Mon Aug 11 14:50:16 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 11 Aug 2008 12:50:16 +0000 (UTC) Subject: [Python-Dev] next beta References: <4838EA2D.7060402@jcea.es> <319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com> <488150A5.8050804@jcea.es> <488451AB.50406@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> Message-ID: Barry Warsaw python.org> writes: > > Ah darn, that's a typo in the PEP. I definitely meant August 13, as > the Google calendar shows. Ah, am I the only one *not* to use Google calendar? :) > Do we think we can be ready for beta3 this Wednesday? If not, I'd > rather stick to a weekday release and do it on Wednesday August 20th. > Let me know what you think. There are quite a few showstoppers, a number of them non-trivial, in the bug tracker. I'm not very optimistic for a release this Wednesday. By the way, I need your pronouncement on http://bugs.python.org/issue2834 cheers Antoine. From phd at phd.pp.ru Mon Aug 11 14:53:21 2008 From: phd at phd.pp.ru (Oleg Broytmann) Date: Mon, 11 Aug 2008 16:53:21 +0400 Subject: [Python-Dev] next beta In-Reply-To: References: <488150A5.8050804@jcea.es> <488451AB.50406@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> Message-ID: <20080811125321.GC19013@phd.pp.ru> On Mon, Aug 11, 2008 at 12:50:16PM +0000, Antoine Pitrou wrote: > Ah, am I the only one *not* to use Google calendar? :) Certainly, no! (-: Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From ncoghlan at gmail.com Mon Aug 11 17:03:41 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 12 Aug 2008 01:03:41 +1000 Subject: [Python-Dev] Resource flag for unicode memory error tests? Message-ID: <48A054CD.2010103@gmail.com> Currently running the test suite, even without any resource flags, renders my machine unusable for at least part of the test execution. The main culprit appears to be the checks for expected memory errors in test_unicode. Does anyone have any objections to making the offending test dependent on a resource flag after beta 3 is out the door? Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From zooko at zooko.com Mon Aug 11 17:43:21 2008 From: zooko at zooko.com (zooko) Date: Mon, 11 Aug 2008 09:43:21 -0600 Subject: [Python-Dev] Base-85 In-Reply-To: References: <489494E5.3050306@v.loewis.de> Message-ID: <26D6A289-4CFB-4ACB-A018-3680E4B0F079@zooko.com> On Aug 2, 2008, at 13:58 PM, Antoine Pitrou wrote: > Martin v. L?wis v.loewis.de> writes: >> >> P.S. Just in case it isn't clear: I would oppose any specific >> proposal >> to add this Ascii85 algorithm to the standard library. It would sound >> like we don't have any real problems to solve. > > According to Wikipedia, "its main modern use is in Adobe's > PostScript and > Portable Document Format file formats". ... git ... mercurial ... bzr It's sort of too bad about the April Fool's RFC, because now people tend to think that an encoding with a non-power-of-2 base is just a joke. I had to overcome that when working with my programming partner, but he eventually decided that base-62 was indeed a useful encoding for our purposes. :-) I've written a few ascii encoders over the years, mostly in Python, plus an optimized C version of base-32 (with a real live Duff's Device): base62.py: http://allmydata.org/source/z-base-62/trunk-hashedformat/z-base-62/ base62/base62.py base36.py: http://allmydata.org/source/z-base-36/trunk-hashedformat/z-base-36/ base36/base36.py base32.py: http://allmydata.org/source/z-base-32/trunk-hashedformat/base32/ base32/base32.py base32.c: http://allmydata.org/source/z-base-32/trunk-hashedformat/base32/base32.c Regards, Zooko From josiah.carlson at gmail.com Mon Aug 11 17:59:19 2008 From: josiah.carlson at gmail.com (Josiah Carlson) Date: Mon, 11 Aug 2008 08:59:19 -0700 Subject: [Python-Dev] Base-85 In-Reply-To: <26D6A289-4CFB-4ACB-A018-3680E4B0F079@zooko.com> References: <489494E5.3050306@v.loewis.de> <26D6A289-4CFB-4ACB-A018-3680E4B0F079@zooko.com> Message-ID: On Mon, Aug 11, 2008 at 8:43 AM, zooko wrote: > On Aug 2, 2008, at 13:58 PM, Antoine Pitrou wrote: > >> Martin v. L?wis v.loewis.de> writes: >>> >>> P.S. Just in case it isn't clear: I would oppose any specific proposal >>> to add this Ascii85 algorithm to the standard library. It would sound >>> like we don't have any real problems to solve. >> >> According to Wikipedia, "its main modern use is in Adobe's PostScript and >> Portable Document Format file formats". > > ... git ... mercurial ... bzr > > It's sort of too bad about the April Fool's RFC, because now people tend to > think that an encoding with a non-power-of-2 base is just a joke. The best April Fool's jokes (imo) are the ones that are obviously silly right off, but that 1) work, 2) no sane person would ever use, and 3) offer up something useful hidden in the joke. The April Fool's RFC fits the bill perfectly, because out of it all comes base85, which is an actual improvement over base64 (25% expansion of data vs. 33%). That some people missed that part of the joke isn't terribly surprising (I have in other situations). - Josiah > I had to overcome that when working with my programming partner, but he > eventually decided that base-62 was indeed a useful encoding for our > purposes. :-) > > I've written a few ascii encoders over the years, mostly in Python, plus an > optimized C version of base-32 (with a real live Duff's Device): > > base62.py: > > http://allmydata.org/source/z-base-62/trunk-hashedformat/z-base-62/base62/base62.py > > base36.py: > > http://allmydata.org/source/z-base-36/trunk-hashedformat/z-base-36/base36/base36.py > > base32.py: > > http://allmydata.org/source/z-base-32/trunk-hashedformat/base32/base32/base32.py > > base32.c: > > http://allmydata.org/source/z-base-32/trunk-hashedformat/base32/base32.c > > Regards, > > Zooko > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/josiah.carlson%40gmail.com > From barry at python.org Tue Aug 12 01:02:15 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 11 Aug 2008 19:02:15 -0400 Subject: [Python-Dev] next beta In-Reply-To: <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> References: <4838EA2D.7060402@jcea.es> <319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com> <488150A5.8050804@jcea.es> <488451AB.50406@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> Message-ID: <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 11, 2008, at 8:27 AM, Barry Warsaw wrote: > Ah darn, that's a typo in the PEP. I definitely meant August 13, as > the Google calendar shows. > > Do we think we can be ready for beta3 this Wednesday? If not, I'd > rather stick to a weekday release and do it on Wednesday August > 20th. Let me know what you think. It sounds like Wednesday August 13th will not be feasible, so we'll do beta 3 on Wednesday August 20th. I've updated both the PEP and the Google Calendar. Thanks, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKDE+XEjvBPtnXfVAQIATwQApbwwrof862rrH8YU0QP3gVENMU4TRpZx 9jdnJk+OZJpFo74XitnrWDsprY1r/lJdGaLnebfg9DztbjHVgCWvkRNXI7qIbRpf QfSeMusrhVwDNITBhJ/0j+A1phWUQG6CU0dez+iKvCJUcohgDlFmlIsw8tCkgDYG On7b7ZKlHd8= =kLcU -----END PGP SIGNATURE----- From olemis at gmail.com Tue Aug 12 15:08:46 2008 From: olemis at gmail.com (Olemis Lang) Date: Tue, 12 Aug 2008 09:08:46 -0400 Subject: [Python-Dev] An OO API for doctest / unittest integration... Message-ID: <24ea26600808120608u200198cew26d687ffbeef0bce@mail.gmail.com> Hello... this is my first post to this list and... I would like to introduce myself by proposing a module for inclusion (hopefully in a "near future") among the standard libraries (modules) offered by Python (of course the idea is to present it here, promote the debate and if "we all like it", well... distribute it together with Python). I will be as concise as possible all the way through this message so as to avoid writing a long speech (and therefore a lengthy message). Further details can be found in an article published "a few months ago" [1]. The module (its name... dutest) has the same goals considered to develop the unittest API provided by doctest since Python 2.4. However it includes other important features which make the difference. Some of them are the following: * A novel object-oriented API programmers can use in order to retrieve test cases out of interactive sessions in the form doctest examples. In other words, novel test loaders find and put test cases together, just like unittest test loaders do. Nowadays the unittest API included in doctest offers the functions DocFileSuite and DocTestSuite for this purpose, therefore lacking in object orientation. * The match made for different doctest examples during a doctest run is stored separately by instances of TestResult. Nowadays the unittest API included in doctest stores the whole doctest report at once into test results. This has some "drawbacks". Firstly, it is difficult to know what is wrong during the test (since to kinds of reports are intermingled). Besides several summaries can be found throughout test reports. When building test analysis tools, this also means that further parsing should be done so as to discover the descriptions of individual failures ... (further and more detailed analysis and explanations can be found in the aforementioned article [1]) * A few more features... The module is actually employed for testing the pyOOP package (under development by the FLiOOPS project [2]). You can simply download dutest [3] and try it out, or you can also check out the trunk [4] doing something like $ svn co https://flioops.svn.sourceforge.net/svnroot/flioops/py/trunk . install the package doing something like $ setup.py install $ setup.py clean Optionally (if you like to see a much more real test report) you can also download the modules ipdbc [5], PyDBC [6], and PyContracts [7], and install them. Next, run pyOOP test suite from the Python interpreter doing something like {{{ #!python try: from oop.test import check_oopdbc except ImportWarning: from oop.test import check_oopdbc oop.test.test_oopdbc.TESTLOG_FILE = '/path/to/log/file' check_oopdbc() }}} and "see" the output report (e.g. $ vi /path/to/log/file). Finally, any bug or bizarre behavior you find, please submit it to the bug tracking system of the FLiOOPS project [8]. We will fix it "as soon as we can". If you have any suggestion or need an additional feature, please submit a feature request to the FLiOOPs project [9]... and/or share it with us here in python-dev... ;) as well as any comments about the whole thing. I hope you like it :) ---- [1] O. Lang, "Doctest and unittest? now they'll live happily forever" (2008) The Python Papers, vol. 3, no. 1, pp 38:51, ISSN 1834-3147. [2] FLiOOPS project home page (https://flioops.sourceforge.net) [3] Download page of module dutest (https://sourceforge.net/project/showfiles.php?group_id=220287&abmode=1) [4] pyOOP SVN trunk (https://flioops.svn.sourceforge.net/svnroot/flioops/py/trunk) [5] Yet another invariant/pre-/postcondition design-by-contract support module, Dmitry Dvoinikov (http://www.targeted.org/python/recipes/ipdbc.py) [6] PyDBC -- Design by Contract for Python 2.2+, Daniel Arbuckle (http://www.nongnu.org/pydbc/) [7] Contracts for Python (PEP 316), Terence Way (http://www.wayforward.net/pycontract/) [8] Bug tracking system of the FLiOOPS project (https://sourceforge.net/tracker/admin/?atid=1049023&group_id=220287) [9] Feature Request tracker system of the FLiOOPS project (https://sourceforge.net/tracker/admin/?atid=1049026&group_id=220287) [10] Send patches to the FLiOOPS project (https://sourceforge.net/tracker/admin/?atid=1049025&group_id=220287) -- Regards, Olemis. From ironfroggy at gmail.com Tue Aug 12 15:58:05 2008 From: ironfroggy at gmail.com (Calvin Spealman) Date: Tue, 12 Aug 2008 09:58:05 -0400 Subject: [Python-Dev] An OO API for doctest / unittest integration... In-Reply-To: <24ea26600808120608u200198cew26d687ffbeef0bce@mail.gmail.com> References: <24ea26600808120608u200198cew26d687ffbeef0bce@mail.gmail.com> Message-ID: <76fd5acf0808120658h143eb93dg77e3a567e4b29560@mail.gmail.com> You need to bring this sort of thing up in python-ideas before here, first of all. Also, there isnt a strong case for including a module that is only used by one project somewhere. Promote it on its own, outside of this other project. Let other people use it and get feedback from real use. When its popular, then it has a case for inclusion. What does it do that we cant already do without it? Just a "A novel object-oriented API" isn't enough and your argument about downplay of unittest for "lacking object-orientation" is a bit weak. It is what works and people have problems with unittest but claims that just vaguely talk about something being "OO enough" are almost always to be skeptical about. On Tue, Aug 12, 2008 at 9:08 AM, Olemis Lang wrote: > Hello... this is my first post to this list and... > > I would like to introduce myself by proposing a module for inclusion > (hopefully in a "near future") among the standard libraries (modules) > offered by Python (of course the idea is to present it here, promote > the debate and if "we all like it", well... distribute it together > with Python). I will be as concise as possible all the way through > this message so as to avoid writing a long speech (and therefore a > lengthy message). Further details can be found in an article published > "a few months ago" [1]. > > The module (its name... dutest) has the same goals considered to > develop the unittest API provided by doctest since Python 2.4. > However it includes other important features which make the > difference. Some of them are the following: > > * A novel object-oriented API programmers can use in order to > retrieve test cases out of interactive sessions in the form > doctest examples. In other words, novel test loaders find and > put test cases together, just like unittest test loaders do. > Nowadays the unittest API included in doctest offers the functions > DocFileSuite and DocTestSuite for this purpose, therefore lacking > in object orientation. > > * The match made for different doctest examples during a doctest run > is stored separately by instances of TestResult. Nowadays > the unittest API included in doctest stores the whole doctest > report at once into test results. This has some "drawbacks". > Firstly, it is difficult to know what is wrong during the test > (since to kinds of reports are intermingled). Besides several > summaries can be found throughout test reports. When building test > analysis tools, this also means that further parsing should be > done so as to discover the descriptions of individual failures ... > (further and more detailed analysis and explanations can be found > in the aforementioned article [1]) > > * A few more features... > > The module is actually employed for testing the pyOOP package > (under development by the FLiOOPS project [2]). You can simply > download dutest [3] and try it out, or you can also check out the > trunk [4] doing something like > > $ svn co https://flioops.svn.sourceforge.net/svnroot/flioops/py/trunk . > > install the package doing something like > > $ setup.py install > $ setup.py clean > > Optionally (if you like to see a much more real test report) you > can also download the modules ipdbc [5], PyDBC [6], and > PyContracts [7], and install them. > > Next, run pyOOP test suite from the Python interpreter doing something > like > > {{{ > #!python > > try: > from oop.test import check_oopdbc > except ImportWarning: > from oop.test import check_oopdbc > > oop.test.test_oopdbc.TESTLOG_FILE = '/path/to/log/file' > > check_oopdbc() > }}} > > and "see" the output report (e.g. $ vi /path/to/log/file). > > Finally, any bug or bizarre behavior you find, please submit it to the > bug tracking system of the FLiOOPS project [8]. We will fix it "as > soon as we can". If you have any suggestion or need an additional > feature, please submit a feature request to the FLiOOPs project [9]... > and/or share it with us here in python-dev... ;) as well as any > comments about the whole thing. > > I hope you like it :) > > ---- > > [1] O. Lang, "Doctest and unittest? now they'll live happily forever" > (2008) The Python Papers, vol. 3, no. 1, pp 38:51, ISSN 1834-3147. > > [2] FLiOOPS project home page > (https://flioops.sourceforge.net) > > [3] Download page of module dutest > (https://sourceforge.net/project/showfiles.php?group_id=220287&abmode=1) > > [4] pyOOP SVN trunk > (https://flioops.svn.sourceforge.net/svnroot/flioops/py/trunk) > > [5] Yet another invariant/pre-/postcondition design-by-contract > support module, > Dmitry Dvoinikov > (http://www.targeted.org/python/recipes/ipdbc.py) > > [6] PyDBC -- Design by Contract for Python 2.2+, > Daniel Arbuckle > (http://www.nongnu.org/pydbc/) > > [7] Contracts for Python (PEP 316), > Terence Way > (http://www.wayforward.net/pycontract/) > > [8] Bug tracking system of the FLiOOPS project > (https://sourceforge.net/tracker/admin/?atid=1049023&group_id=220287) > > [9] Feature Request tracker system of the FLiOOPS project > (https://sourceforge.net/tracker/admin/?atid=1049026&group_id=220287) > > [10] Send patches to the FLiOOPS project > (https://sourceforge.net/tracker/admin/?atid=1049025&group_id=220287) > > > > -- > Regards, > > Olemis. > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ From srittau at jroger.in-berlin.de Tue Aug 12 16:30:59 2008 From: srittau at jroger.in-berlin.de (Sebastian Rittau) Date: Tue, 12 Aug 2008 16:30:59 +0200 Subject: [Python-Dev] unittest Suggestions Message-ID: <20080812143059.GB20161@jroger.in-berlin.de> [I just saw the other post about unit testing, while I was writing this. A strange conincidence.] Hello, since this is the first time I post to this list, I'd like to introduce myself briefly. As you can see my name is Sebastian. I am working as a software developer both as a professional and as a hobbyist. During the years I've used many programming languages, but in the last few years I've fallen in love with Python. (Blame Martin v. L?wis for that - I started using Python after participating in a seminar held by him at university.) I'd like to propose a few changes to the unittest module. These changes are supposed to ease usage, enable future changes and enhancements, and bring unittest more in line with other modern xUnit variants (such as JUnit 4 and NUnit). I have implemented most of those changes in a custom library that hacks around the current unittest behaviour. I've published the relevant package at [1]. All proposed changes are (mostly) backward compatible. Change unittest into a package ------------------------------ Currently unittest is a module. Changing it into a package would enable us to separate concerns and move code out into separate modules. For example the unittest.asserts proposal below requires this change. If a mocking framework would be included in the Python standard library at some point, it could go into unittest.mock etc. @test, @before, and @after decorators ------------------------------------- Currently unittest uses "magic" names starting with "test_" for detecting the test methods in a test case class. Following the "explicit is better than implicit" guideline, I propose to add a @test decorator to explicitly mark test methods: class MyTest(TestCase): @test def attributes(self): """Do stuff.""" I've been bitten in the past by naming methods test_xyz that were not supposed to be called by the test runner. For now those methods still need to be recognized, since they are widely used. But enabling (and recommending) an alternative is a first step. The decorator syntax makes is possible to introduce alternative decorators as well, like @disabled_test. In the example package I included a @performance_test decorator that takes a time argument where the test fails if it takes more than a given amount of time. Similarily I recommend to introduce @before and @after decorators to supplement the setUp and tearDown methods. The decorators were named after the decorators in JUnit 4, although I wonder whether @setup and @teardown would be a better name. @before and @after methods are called in any order, but @before methods in a super class are guaranteed to be called before @before methods in a derived class, while it's vice versa with @after methods. Introducing these has the added benefit of being able to get rid of the mixedCase setUp and tearDown methods in my own code. unittest.asserts ---------------- Currently all assertions reside as methods on the TestCase class. This means that all testing functions, including utility functions, need to be on a TestCase-derived class. This seems wrong to me, especially since it combines different concerns on a class: Testing the functionality of a SUT, running a test suite, and providing test functions. This proposal will not try to separate the first two concerns, but only the third one. In the long term I think it's worthwhile to make tests work on any class, not only on classes derived from TestCase, but as I said, this is not part of this proposal. JUnit 4 moved the assertions to a static class in a separate module. In Python I'd propose to use functions in a separate module. A typical test suite would then look like this: from unittest import TestCase from unittest.asserts import * class FooTest(TestCase): """Tests for the Foo class.""" @before def setup(self): self._sut = create_an_object_to_test() @test def construct__some_attribute(self): assert_equals("foobar", self._sut.some_attribute) ... Again, as a side effect this removes inconsistent naming (mixedCase and three different version of each test) from my tests. There is one regression, though. Currently it's possible to change the assertion exception (which defaults to AssertionError) by setting an attribute of the TestCase instance. I am not sure how relevant that is, though. I've never used this feature myself, not even when testing the unittest module and its extensions, and this approach wouldn't work anyway, if you use classes with utility assertions etc. Anyway, I am happy about any comments. - Sebastian [1] http://www.rittau.biz/~srittau/unittest, though I will move it to http://www.rittau.org/python/unittest, once I'm home. From barry at python.org Tue Aug 12 17:05:57 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 12 Aug 2008 11:05:57 -0400 Subject: [Python-Dev] unittest Suggestions In-Reply-To: <20080812143059.GB20161@jroger.in-berlin.de> References: <20080812143059.GB20161@jroger.in-berlin.de> Message-ID: <853B3E43-669D-4D2D-B46F-66371DDB9FD6@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 12, 2008, at 10:30 AM, Sebastian Rittau wrote: > [I just saw the other post about unit testing, while I was writing > this. > A strange conincidence.] Indeed. I've played around (again) recently with both nose and py.test, so I'd like to make a meta comment. I would really like to see some of the people who are interested in Python unit testing to get together and work on an updated testing framework that incorporates the best ideas from all the existing frameworks. I'd like to see good integration with setuptools, both for running the tests and for packaging. I'd like to see good doctest support, with the ability to hook in setups and teardowns. I'd like to see some of useful things like layers taken from zope.testing. This doesn't belong on python-dev, and probably not on python-ideas either, but I'd be willing to start a testing SIG on python.org if others are interested in getting together for this purpose. The goal should be to produce something like a unittest-ng, distribute it via the Cheeseshop, and gather consensus around it for possible inclusion in Python 2.7/3.1. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKGm1XEjvBPtnXfVAQIEjgP+LsA8VpX62cnLzNgGv1jTLk7yhIvyKjEP nYgLOb1506FXnOUuXpPrqSS6ZOkr5Evt7jvkbSdIqbdLG3fpHYGFpt/KA0CHDdsE QuumBO5WenrFhB6yEoQoIa+oKg1McYYQfIFSVg+5owBi+Vo5vTZ7JaZyR43MUJon LbGqnMXRlqg= =sF2p -----END PGP SIGNATURE----- From exarkun at divmod.com Tue Aug 12 17:12:43 2008 From: exarkun at divmod.com (Jean-Paul Calderone) Date: Tue, 12 Aug 2008 11:12:43 -0400 Subject: [Python-Dev] unittest Suggestions In-Reply-To: <853B3E43-669D-4D2D-B46F-66371DDB9FD6@python.org> Message-ID: <20080812151243.29191.1410633723.divmod.quotient.13523@ohm> On Tue, 12 Aug 2008 11:05:57 -0400, Barry Warsaw wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Aug 12, 2008, at 10:30 AM, Sebastian Rittau wrote: >>[I just saw the other post about unit testing, while I was writing this. >>A strange conincidence.] > >Indeed. I've played around (again) recently with both nose and py.test, so >I'd like to make a meta comment. > >I would really like to see some of the people who are interested in Python >unit testing to get together and work on an updated testing framework that >incorporates the best ideas from all the existing frameworks. I'd like to >see good integration with setuptools, both for running the tests and for >packaging. I'd like to see good doctest support, with the ability to hook >in setups and teardowns. I'd like to see some of useful things like layers >taken from zope.testing. > >This doesn't belong on python-dev, and probably not on python-ideas either, >but I'd be willing to start a testing SIG on python.org if others are >interested in getting together for this purpose. The goal should be to >produce something like a unittest-ng, distribute it via the Cheeseshop, and >gather consensus around it for possible inclusion in Python 2.7/3.1. A SIG might be a good idea. There's also already the "testing in python" list, too: http://lists.idyll.org/listinfo/testing-in-python A lot of this discussion would be appropriate there. Jean-Paul From ctb at msu.edu Tue Aug 12 17:13:42 2008 From: ctb at msu.edu (C. Titus Brown) Date: Tue, 12 Aug 2008 08:13:42 -0700 Subject: [Python-Dev] unittest Suggestions In-Reply-To: <853B3E43-669D-4D2D-B46F-66371DDB9FD6@python.org> References: <20080812143059.GB20161@jroger.in-berlin.de> <853B3E43-669D-4D2D-B46F-66371DDB9FD6@python.org> Message-ID: <20080812151342.GA31404@idyll.org> On Tue, Aug 12, 2008 at 11:05:57AM -0400, Barry Warsaw wrote: -> -----BEGIN PGP SIGNED MESSAGE----- -> Hash: SHA1 -> -> On Aug 12, 2008, at 10:30 AM, Sebastian Rittau wrote: -> -> >[I just saw the other post about unit testing, while I was writing -> >this. -> >A strange conincidence.] -> -> Indeed. I've played around (again) recently with both nose and -> py.test, so I'd like to make a meta comment. -> -> I would really like to see some of the people who are interested in -> Python unit testing to get together and work on an updated testing -> framework that incorporates the best ideas from all the existing -> frameworks. I'd like to see good integration with setuptools, both -> for running the tests and for packaging. I'd like to see good doctest -> support, with the ability to hook in setups and teardowns. I'd like -> to see some of useful things like layers taken from zope.testing. -> -> This doesn't belong on python-dev, and probably not on python-ideas -> either, but I'd be willing to start a testing SIG on python.org if -> others are interested in getting together for this purpose. The goal -> should be to produce something like a unittest-ng, distribute it via -> the Cheeseshop, and gather consensus around it for possible inclusion -> in Python 2.7/3.1. Hi, Barry, I'll forward this idea on to testing-in-python: http://lists.idyll.org/listinfo/testing-in-python where there was another bikeshed discussion about testing, a few weeks ago. That might be a good place to continue this discussion, at least until/if unittest-ng is created. Sebastian, there was a looooong discussion on Python-Dev two or three weeks ago (you can't miss it in the July archives, I'd bet). You should read that IMO. cheers, --titus -- C. Titus Brown, ctb at msu.edu From barry at python.org Tue Aug 12 17:23:00 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 12 Aug 2008 11:23:00 -0400 Subject: [Python-Dev] unittest Suggestions In-Reply-To: <20080812151243.29191.1410633723.divmod.quotient.13523@ohm> References: <20080812151243.29191.1410633723.divmod.quotient.13523@ohm> Message-ID: <17E6B02F-F60D-48C3-BA79-3CCF9B04408B@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 12, 2008, at 11:12 AM, Jean-Paul Calderone wrote: > A SIG might be a good idea. There's also already the "testing in > python" > list, too: > > http://lists.idyll.org/listinfo/testing-in-python > > A lot of this discussion would be appropriate there. Ah, thanks for the pointer. If there's a good existing list that people want to keep, let's just raise its profile and point people there. I'm happy to create a SIG though if that's what people want. /me-subscribes-now-ly y'rs, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKGq1HEjvBPtnXfVAQIxygP+JrmWqbKDKDLWIPRK4QuPREZWEI35JHa7 CnDhXlcfayp/L0ZflO/7Vzeb5Q7gbOQR0pVR/YX0cjPZhcOm0XiyrTOSV8zJbbA4 XAMnR0vGqEgL9UgTb6K3XPt6fZT+72zhHomcqbALP/CBivwSkwEVNPas6/Ng2Dog P5Uigi7tsp0= =GypB -----END PGP SIGNATURE----- From barry at python.org Tue Aug 12 17:24:39 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 12 Aug 2008 11:24:39 -0400 Subject: [Python-Dev] unittest Suggestions In-Reply-To: <20080812151342.GA31404@idyll.org> References: <20080812143059.GB20161@jroger.in-berlin.de> <853B3E43-669D-4D2D-B46F-66371DDB9FD6@python.org> <20080812151342.GA31404@idyll.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 12, 2008, at 11:13 AM, C. Titus Brown wrote: > I'll forward this idea on to testing-in-python: > > http://lists.idyll.org/listinfo/testing-in-python > > where there was another bikeshed discussion about testing, a few weeks > ago. That might be a good place to continue this discussion, at least > until/if unittest-ng is created. Thanks Titus. I'm subscribing to that list now, but I fear the bikeshed. :) - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKGrOHEjvBPtnXfVAQLFyQP+K9C71PfVLI1JxsfnZQKfDEi7FtRLN6GT W+DZOr/WnC6sDpSFF3xwfehNCDgu8GkW8zVcDQS2pbMW606RCXV8kvpmjL0Iuov8 rex0rhU16KPBAS1cgkf/dZQWUUy31OFzWTSSegtMw0T5EgOnbWWe2N3Tx2QKxGuv XBCjpcz4ofg= =Jwgr -----END PGP SIGNATURE----- From bparakala at gmail.com Tue Aug 12 15:59:21 2008 From: bparakala at gmail.com (Bhavani) Date: Tue, 12 Aug 2008 06:59:21 -0700 (PDT) Subject: [Python-Dev] Need 2 python developers in Dallas TX Message-ID: Hello: I am looking to replace 2 Python developers for my client in Dallas TX. This is a full time position and due to teh challenge in finding Python Developers, my client is willing to be open on his salary requirement and will offer relocation assistance as well plus benefits. Please email resumes to bhavani at ztek-inc.com Regards, Bhavani From aahz at pythoncraft.com Tue Aug 12 19:00:42 2008 From: aahz at pythoncraft.com (Aahz) Date: Tue, 12 Aug 2008 10:00:42 -0700 Subject: [Python-Dev] Need 2 python developers in Dallas TX In-Reply-To: References: Message-ID: <20080812170042.GA27844@panix.com> On Tue, Aug 12, 2008, Bhavani wrote: > > I am looking to replace 2 Python developers for my client in Dallas > TX. This is a full time position and due to teh challenge in finding > Python Developers, my client is willing to be open on his salary > requirement and will offer relocation assistance as well plus > benefits. Please email resumes to bhavani at ztek-inc.com python-dev is the wrong place to advertise for jobs. Please see http://www.python.org/community/jobs/ -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ Adopt A Process -- stop killing all your children! From janssen at parc.com Tue Aug 12 19:01:13 2008 From: janssen at parc.com (Bill Janssen) Date: Tue, 12 Aug 2008 10:01:13 PDT Subject: [Python-Dev] why duplicate output lines in verbose tests? Message-ID: <08Aug12.100114pdt."58698"@synergy1.parc.xerox.com> Every so often, running the SSL test suite in verbose mode, I get something like this: server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256) server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256) That is, duplicate output lines. Any idea why that is? They're all written with something like: if support.verbose: sys.stdout.write(" some message\n") Bill From guido at python.org Tue Aug 12 20:12:49 2008 From: guido at python.org (Guido van Rossum) Date: Tue, 12 Aug 2008 11:12:49 -0700 Subject: [Python-Dev] why duplicate output lines in verbose tests? In-Reply-To: <-8870320530519875871@unknownmsgid> References: <-8870320530519875871@unknownmsgid> Message-ID: Is it using fork()? Threads? On Tue, Aug 12, 2008 at 10:01 AM, Bill Janssen wrote: > Every so often, running the SSL test suite in verbose mode, I get > something like this: > > server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256) > server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256) > > That is, duplicate output lines. Any idea why that is? They're all > written with something like: > > if support.verbose: > sys.stdout.write(" some message\n") -- --Guido van Rossum (home page: http://www.python.org/~guido/) From janssen at parc.com Tue Aug 12 20:32:05 2008 From: janssen at parc.com (Bill Janssen) Date: Tue, 12 Aug 2008 11:32:05 PDT Subject: [Python-Dev] why duplicate output lines in verbose tests? In-Reply-To: References: <-8870320530519875871@unknownmsgid> Message-ID: <08Aug12.113215pdt."58698"@synergy1.parc.xerox.com> > Is it using fork()? Threads? No on fork(), yes on threads. Bill From guido at python.org Tue Aug 12 20:38:28 2008 From: guido at python.org (Guido van Rossum) Date: Tue, 12 Aug 2008 11:38:28 -0700 Subject: [Python-Dev] why duplicate output lines in verbose tests? In-Reply-To: <3583499109816891065@unknownmsgid> References: <-8870320530519875871@unknownmsgid> <3583499109816891065@unknownmsgid> Message-ID: On Tue, Aug 12, 2008 at 11:32 AM, Bill Janssen wrote: >> Is it using fork()? Threads? > > No on fork(), yes on threads. Hmm... I don't believe that io.py is thread-safe. :-( -- --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at egenix.com Wed Aug 13 01:21:55 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 13 Aug 2008 01:21:55 +0200 Subject: [Python-Dev] [python-committers] next beta In-Reply-To: <48A1DA1A.7090103@v.loewis.de> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> Message-ID: <48A21B13.3060304@egenix.com> First, I'd like to know why this discussion is happening on the committers list. Python-dev is the right list for these things. I've adjusted the CC accordingly. On 2008-08-12 20:44, Martin v. L?wis wrote: >>>> I am planning to offer a single file patch for 2.3 and 2.4. As far as >>>> one more 2.5 release, I don't think there's going to be many changes >>>> to the 2.5 branch between now and 2.6/3.0 final - although if there >>>> is, we'll obviously have to do another release. >>> I would like to establish a tradition where, after some final bug fix >>> release (e.g. for 2.5), further "mere" bug fixes are banned from the >>> maintenance branch (and I did revert several bug fixes from the 2.4 >>> branch). >> I'm not sure I agree with this policy. Can you elaborate on /why/ you >> want this? > > Because there won't typically be sufficient testing and release > infrastructure to allow arbitrary bug fixes to be committed on the > branch. The buildbots are turned off, and nobody tests the release > candidate, no Windows binaries are provided - thus, chances are very > high that a bug fix release for some very old branch will be *worse* > than the previous release, rather than better. Second, I don't think this is true. People using those patch level releases will test and report bugs if they are introduced by such backports. Besides, developers backporting such changes are diligent enough to test their changes - they will usually have a reason for applying the extra effort to backport. I don't see any advantage in undoing already tested and committed patches to an older branch. Note that Python 2.4 is still widely used out there. As an example, all the Zope and Plone installations run Python 2.4 and will continue to do so for quite a while. And there's a reason for this slow uptake of Python 2.5: as more and more servers run 64-bit OSes, the Py_ssize_t changes cause serious trouble with Python C extensions that were not updated by their authors. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 13 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From guido at python.org Wed Aug 13 04:57:58 2008 From: guido at python.org (Guido van Rossum) Date: Tue, 12 Aug 2008 19:57:58 -0700 Subject: [Python-Dev] [python-committers] next beta In-Reply-To: <48A21B13.3060304@egenix.com> References: <4838EA2D.7060402@jcea.es> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> Message-ID: On Tue, Aug 12, 2008 at 4:21 PM, M.-A. Lemburg wrote: > First, I'd like to know why this discussion is happening on > the committers list. > > Python-dev is the right list for these things. I've adjusted the > CC accordingly. > > On 2008-08-12 20:44, Martin v. L?wis wrote: >>>>> >>>>> I am planning to offer a single file patch for 2.3 and 2.4. As far as >>>>> one more 2.5 release, I don't think there's going to be many changes >>>>> to the 2.5 branch between now and 2.6/3.0 final - although if there >>>>> is, we'll obviously have to do another release. >>>> >>>> I would like to establish a tradition where, after some final bug fix >>>> release (e.g. for 2.5), further "mere" bug fixes are banned from the >>>> maintenance branch (and I did revert several bug fixes from the 2.4 >>>> branch). >>> >>> I'm not sure I agree with this policy. Can you elaborate on /why/ you >>> want this? >> >> Because there won't typically be sufficient testing and release >> infrastructure to allow arbitrary bug fixes to be committed on the >> branch. The buildbots are turned off, and nobody tests the release >> candidate, no Windows binaries are provided - thus, chances are very >> high that a bug fix release for some very old branch will be *worse* >> than the previous release, rather than better. > > Second, I don't think this is true. People using those patch > level releases will test and report bugs if they are introduced > by such backports. > > Besides, developers backporting such changes are diligent enough > to test their changes - they will usually have a reason for applying > the extra effort to backport. But then it's too late! If there's a regression in 2.5.3 we'd have to issue a brown bag release 2.5.4. That would be more work for the release managers and frankly we don't have enough release manager hours as it is. So the argument that bugs will still get reported doesn't add up to much. The point is to avoid introducing bugs in the first place. > I don't see any advantage in undoing already tested and committed > patches to an older branch. > > Note that Python 2.4 is still widely used out there. As an > example, all the Zope and Plone installations run Python 2.4 and > will continue to do so for quite a while. And they do so because they want stability. I agree with the release managers that we should only issue security fixes for these platforms. Anything else adds the risk of breakage, i.e. instability. > And there's a reason for this slow uptake of Python 2.5: as more > and more servers run 64-bit OSes, the Py_ssize_t changes cause > serious trouble with Python C extensions that were not updated > by their authors. I'm not sure what that has to do with anything. The older releases have *worse* support for 64-bit platforms! -- --Guido van Rossum (home page: http://www.python.org/~guido/) From martin at v.loewis.de Wed Aug 13 07:53:50 2008 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 13 Aug 2008 07:53:50 +0200 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <48A21B13.3060304@egenix.com> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> Message-ID: <48A276EE.8070903@v.loewis.de> >> Because there won't typically be sufficient testing and release >> infrastructure to allow arbitrary bug fixes to be committed on the >> branch. The buildbots are turned off, and nobody tests the release >> candidate, no Windows binaries are provided - thus, chances are very >> high that a bug fix release for some very old branch will be *worse* >> than the previous release, rather than better. > > Second, I don't think this is true. People using those patch > level releases will test and report bugs if they are introduced > by such backports. They might be using releases, but they are *not* using the subversion maintenance branches. Do you know anybody who regularly checks out the 2.4 maintenance branch and tests it? So at best, people will only report bugs *after* the release was made, meaning that there is a realistic chance that the release itself breaks things. As for using the releases themselves: there have been 80462 downloads of 2.4.5 since it was released in March, as compared to 517325 downloads of the 2.5.2 MSI in July alone. So I'm skeptical that many people do actually use the 2.4.5 release. > Besides, developers backporting such changes are diligent enough > to test their changes - they will usually have a reason for applying > the extra effort to backport. My problem is that this backporting is not systematic. It's arbitrary whether patches get backported or not. Part of the problem is that it is/was also unclear whether there ever will be another release made out of 2.4. When 2.4.4 was released, Anthony announced, in http://mail.python.org/pipermail/python-dev/2006-October/069326.html "This will be the last planned release in the Python 2.4 series" So anybody committing to the 2.4 branch after that should have expected that the patches will never get released. Regards, Martin From solipsis at pitrou.net Wed Aug 13 11:07:34 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 13 Aug 2008 09:07:34 +0000 (UTC) Subject: [Python-Dev] why duplicate output lines in verbose tests? References: <-8870320530519875871@unknownmsgid> <3583499109816891065@unknownmsgid> Message-ID: Guido van Rossum python.org> writes: > > On Tue, Aug 12, 2008 at 11:32 AM, Bill Janssen parc.com> wrote: > >> Is it using fork()? Threads? > > > > No on fork(), yes on threads. > > Hmm... I don't believe that io.py is thread-safe. There is an issue open for the BufferedWriter + threads problem (which is probably what causes Bill's problem above). http://bugs.python.org/issue3476 As Martin suggested in this issue's comments, a simple fix would be to wrap most methods with an instance-specific mutex. I don't know how that would affect performance. Regards Antoine. From mal at egenix.com Wed Aug 13 11:55:29 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 13 Aug 2008 11:55:29 +0200 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <48A276EE.8070903@v.loewis.de> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> Message-ID: <48A2AF91.2040709@egenix.com> On 2008-08-13 07:53, Martin v. L?wis wrote: >>> Because there won't typically be sufficient testing and release >>> infrastructure to allow arbitrary bug fixes to be committed on the >>> branch. The buildbots are turned off, and nobody tests the release >>> candidate, no Windows binaries are provided - thus, chances are very >>> high that a bug fix release for some very old branch will be *worse* >>> than the previous release, rather than better. >> Second, I don't think this is true. People using those patch >> level releases will test and report bugs if they are introduced >> by such backports. > > They might be using releases, but they are *not* using the subversion > maintenance branches. Do you know anybody who regularly checks out the > 2.4 maintenance branch and tests it? > > So at best, people will only report bugs *after* the release was made, > meaning that there is a realistic chance that the release itself breaks > things. I think that's an overly pessimistic view. There's always a chance of breaking things when patching anything - whether that's a security fix or a fix for a bug that's hard to work around in an application using Python. Note that those fixes will usually be backports from a more recent release, so even if they don't receive enough direct testing on the older branch before the release is cut, they will get their share of testing either in the context of the more recent branch. > As for using the releases themselves: there have been 80462 downloads > of 2.4.5 since it was released in March, as compared to 517325 downloads > of the 2.5.2 MSI in July alone. So I'm skeptical that many people do > actually use the 2.4.5 release. It's difficult to use such download numbers as hint for the number of deployed installations. 2.4.5 was not released as binary, so interested parties had to compile that version by themselves and those installations don't show up in your statistics. I'm sure that if we had released binaries as well, the number would have looked different, esp. if you only look at the Windows binaries. >> Besides, developers backporting such changes are diligent enough >> to test their changes - they will usually have a reason for applying >> the extra effort to backport. > > My problem is that this backporting is not systematic. It's arbitrary > whether patches get backported or not. Part of the problem is that > it is/was also unclear whether there ever will be another release made > out of 2.4. That's a valid point, but does this really warrant backing out changes that have already been applied ? Isn't it better to get at least some bugs fixed rather than to not fix them at all ? > When 2.4.4 was released, Anthony announced, in > > http://mail.python.org/pipermail/python-dev/2006-October/069326.html > > "This will be the last planned release in the Python 2.4 series" > > So anybody committing to the 2.4 branch after that should have expected > that the patches will never get released. Perhaps we should just document the maintenance of Python releases more clearly and also plan for a final bug fix release 3 years after the initial branch release. That way developers and users can also adjust their plans accordingly. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 13 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From ncoghlan at gmail.com Wed Aug 13 12:08:54 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 13 Aug 2008 20:08:54 +1000 Subject: [Python-Dev] why duplicate output lines in verbose tests? In-Reply-To: References: <-8870320530519875871@unknownmsgid> <3583499109816891065@unknownmsgid> Message-ID: <48A2B2B6.3020205@gmail.com> Antoine Pitrou wrote: > As Martin suggested in this issue's comments, a simple fix would be to wrap most > methods with an instance-specific mutex. I don't know how that would affect > performance. For 3.0, I think correctness is more important than speed. At this stage, we may have to live with the fact that some aspects of 3.0 are going to be slower than they are in 2.6 (the Decimal module comes to mind, and it looks like IO may be another one). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From mal at egenix.com Wed Aug 13 12:56:06 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 13 Aug 2008 12:56:06 +0200 Subject: [Python-Dev] Maintaining old releases In-Reply-To: References: <4838EA2D.7060402@jcea.es> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> Message-ID: <48A2BDC6.8080808@egenix.com> On 2008-08-13 04:57, Guido van Rossum wrote: >> And there's a reason for this slow uptake of Python 2.5: as more >> and more servers run 64-bit OSes, the Py_ssize_t changes cause >> serious trouble with Python C extensions that were not updated >> by their authors. > > I'm not sure what that has to do with anything. The older releases > have *worse* support for 64-bit platforms! This is one of the reasons why porting applications from 2.4 to 2.5 takes longer than e.g. moving from 2.3 to 2.4. Python 2.4 works just fine on 64-bit platforms and so do the C extensions that were written for it. Moving to 2.5 you often find that those C extensions do not support the new Py_ssize_t types and thus generate segfaults. As a result, you either have to start using a different C extension, patch the extension, stay with Python 2.4 or use a custom Python interpreter that is patched always map Py_ssize_t to int. The move from 2.5 to 2.6 will be a lot easier and uptake a lot faster. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 13 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From tnelson at onresolve.com Wed Aug 13 14:09:05 2008 From: tnelson at onresolve.com (Trent Nelson) Date: Wed, 13 Aug 2008 13:09:05 +0100 Subject: [Python-Dev] Any PEP about 2.6 -> 3000 code transition? In-Reply-To: References: <4838EA2D.7060402@jcea.es> <319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com> <488150A5.8050804@jcea.es> <488451AB.50406@jcea.es> <4884581F.8010201@jcea.es> <319e029f0807211437w53619985s85157a60d42966e@mail.gmail.com> Message-ID: <6167796BFEB5D0438720AC212E89A6B0078F4D7E@exchange.onresolve.com> > (*) slides: > http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf Hilarious! Seems like that would have been a riot of a session to attend. (I'm kicking myself for attending some other uninteresting talk when yours was on.) Trent. From anthonybaxter at gmail.com Wed Aug 13 14:18:30 2008 From: anthonybaxter at gmail.com (Anthony Baxter) Date: Wed, 13 Aug 2008 22:18:30 +1000 Subject: [Python-Dev] Any PEP about 2.6 -> 3000 code transition? In-Reply-To: <6167796BFEB5D0438720AC212E89A6B0078F4D7E@exchange.onresolve.com> References: <4838EA2D.7060402@jcea.es> <488150A5.8050804@jcea.es> <488451AB.50406@jcea.es> <4884581F.8010201@jcea.es> <319e029f0807211437w53619985s85157a60d42966e@mail.gmail.com> <6167796BFEB5D0438720AC212E89A6B0078F4D7E@exchange.onresolve.com> Message-ID: I'm planning on re-presenting it at the local google office in the next couple of weeks. I might try and arrange for it to be recorded and put online. At the moment we seem to have a real lack of concrete information for people about the transition. If I had time (ha! HA!) I'd try to turn the slides into a series of articles. Right now, there's the What's New In Python 3.0, and the PEPs. The former isn't complete yet (obviously) and isn't all that detailed. The latter is a whole pile of text, some relevant and some not so much. Anthony On Wed, Aug 13, 2008 at 10:09 PM, Trent Nelson wrote: >> (*) slides: >> http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf > > Hilarious! Seems like that would have been a riot of a session to attend. (I'm kicking myself for attending some other uninteresting talk when yours was on.) > > Trent. > From anthonybaxter at gmail.com Wed Aug 13 14:20:47 2008 From: anthonybaxter at gmail.com (Anthony Baxter) Date: Wed, 13 Aug 2008 22:20:47 +1000 Subject: [Python-Dev] Any PEP about 2.6 -> 3000 code transition? In-Reply-To: References: <4838EA2D.7060402@jcea.es> <319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com> <488150A5.8050804@jcea.es> <488451AB.50406@jcea.es> <4884581F.8010201@jcea.es> <319e029f0807211437w53619985s85157a60d42966e@mail.gmail.com> Message-ID: Last time I looked at it, the C API wasn't nailed down yet. That's why I passed over it entirely for my tutorial. The only advice I was able to give was that if your extension is just a wrapper around existing C code, you might be better off rewriting it using ctypes. That way it should work on both 2.6 and 3.0. This doesn't work for PyCXX, of course :-( On Fri, Jul 25, 2008 at 8:33 AM, Barry Scott wrote: > > On Jul 21, 2008, at 22:37, Lennart Regebro wrote: > >> On Mon, Jul 21, 2008 at 20:16, Brett Cannon wrote: >>> >>> But waiting until all the betas have gone out totally defeats the >>> purpose of the betas! >> >> I agree. Writing an actual *guide* can wait, but documenting the >> differences with code examples is a work that can start now, and I >> agree that it would be great if this would start now. >> >> But writing a guide might not be a good idea until we know what the >> changes are, and if the API is changing quickly now we don't. :-) > > I'm working on getting a version of PyCXX working with Python 3.0. > The lack of any docs outside of the header files is making this a slow > process. > > I think its a mistake to expect a serious beta test of extensions > when you have no guide to the changes in the C API. > > If you had a guide then diff it between releases would be a guide to > what need fixing up going from beta to beta to rc. > > Oh and I'm not going to try and make a version of PyCXX that works > on 2.x and 3.x as the changes are too fundamental. > > Barry > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/anthony%40interlink.com.au > > From steve at holdenweb.com Wed Aug 13 15:20:29 2008 From: steve at holdenweb.com (Steve Holden) Date: Wed, 13 Aug 2008 09:20:29 -0400 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <48A2AF91.2040709@egenix.com> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <48A2AF91.2040709@egenix.com> Message-ID: M.-A. Lemburg wrote: > On 2008-08-13 07:53, Martin v. L?wis wrote: >>>> Because there won't typically be sufficient testing and release >>>> infrastructure to allow arbitrary bug fixes to be committed on the >>>> branch. The buildbots are turned off, and nobody tests the release >>>> candidate, no Windows binaries are provided - thus, chances are very >>>> high that a bug fix release for some very old branch will be *worse* >>>> than the previous release, rather than better. >>> Second, I don't think this is true. People using those patch >>> level releases will test and report bugs if they are introduced >>> by such backports. >> >> They might be using releases, but they are *not* using the subversion >> maintenance branches. Do you know anybody who regularly checks out the >> 2.4 maintenance branch and tests it? >> >> So at best, people will only report bugs *after* the release was made, >> meaning that there is a realistic chance that the release itself breaks >> things. > > I think that's an overly pessimistic view. There's always a chance > of breaking things when patching anything - whether that's a security > fix or a fix for a bug that's hard to work around in an application > using Python. > > Note that those fixes will usually be backports from a more recent > release, so even if they don't receive enough direct testing on > the older branch before the release is cut, they will get their > share of testing either in the context of the more recent branch. > I'm not a great believer in "indirect testing" of this kind. >> As for using the releases themselves: there have been 80462 downloads >> of 2.4.5 since it was released in March, as compared to 517325 downloads >> of the 2.5.2 MSI in July alone. So I'm skeptical that many people do >> actually use the 2.4.5 release. > > It's difficult to use such download numbers as hint for the number > of deployed installations. 2.4.5 was not released as binary, so > interested parties had to compile that version by themselves and > those installations don't show up in your statistics. > > I'm sure that if we had released binaries as well, the number would > have looked different, esp. if you only look at the Windows binaries. > >>> Besides, developers backporting such changes are diligent enough >>> to test their changes - they will usually have a reason for applying >>> the extra effort to backport. >> >> My problem is that this backporting is not systematic. It's arbitrary >> whether patches get backported or not. Part of the problem is that >> it is/was also unclear whether there ever will be another release made >> out of 2.4. > > That's a valid point, but does this really warrant backing out > changes that have already been applied ? Isn't it better to get > at least some bugs fixed rather than to not fix them at all ? > No, given that (in teh USA in 1999, anyway) there's a 7% chance that a bugfix will inject a new problem. That chance goes up when testing is minimal - testing of later releases doesn't validate untested amendments to earlier releases. >> When 2.4.4 was released, Anthony announced, in >> >> http://mail.python.org/pipermail/python-dev/2006-October/069326.html >> >> "This will be the last planned release in the Python 2.4 series" >> >> So anybody committing to the 2.4 branch after that should have expected >> that the patches will never get released. > > Perhaps we should just document the maintenance of Python releases > more clearly and also plan for a final bug fix release 3 years after > the initial branch release. That way developers and users can also > adjust their plans accordingly. > As always the problem is getting someone to do this not insignificant amount of work. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From hrvoje.niksic at avl.com Wed Aug 13 15:27:42 2008 From: hrvoje.niksic at avl.com (Hrvoje =?UTF-8?Q?Nik=C5=A1i=C4=87?=) Date: Wed, 13 Aug 2008 15:27:42 +0200 Subject: [Python-Dev] Any PEP about 2.6 -> 3000 code transition? In-Reply-To: References: <4838EA2D.7060402@jcea.es> <319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com> <488150A5.8050804@jcea.es> <488451AB.50406@jcea.es> <4884581F.8010201@jcea.es> <319e029f0807211437w53619985s85157a60d42966e@mail.gmail.com> Message-ID: <1218634062.31375.164.camel@localhost> On Wed, 2008-08-13 at 22:20 +1000, Anthony Baxter wrote: > Last time I looked at it, the C API wasn't nailed down yet. That's why > I passed over it entirely for my tutorial. The only advice I was able > to give was that if your extension is just a wrapper around existing C > code, you might be better off rewriting it using ctypes. Given that ctypes doesn't work on a number of popular architectures, including x86_64 (the last time I looked), I'd hardly call that "better off". :-( From mal at egenix.com Wed Aug 13 16:07:43 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 13 Aug 2008 16:07:43 +0200 Subject: [Python-Dev] Maintaining old releases In-Reply-To: References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <48A2AF91.2040709@egenix.com> Message-ID: <48A2EAAF.4080709@egenix.com> On 2008-08-13 15:20, Steve Holden wrote: > M.-A. Lemburg wrote: >> Perhaps we should just document the maintenance of Python releases >> more clearly and also plan for a final bug fix release 3 years after >> the initial branch release. That way developers and users can also >> adjust their plans accordingly. >> > As always the problem is getting someone to do this not insignificant > amount of work. We'd just have to add a section to the release schedule PEP: Release Maintenance Bug fix releases will be made available until September 19, 2009. The following bug fix releases have been posted: 2.5.1: February 22, 2008 2.5.2: April 18, 2007 Security fix releases will continue to be made available as necessary until September 19, 2011. No further updates will be posted after that date. The following security fix releases have been posted: No security fix releases have been released. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 13 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From skip at pobox.com Wed Aug 13 16:29:36 2008 From: skip at pobox.com (skip at pobox.com) Date: Wed, 13 Aug 2008 09:29:36 -0500 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <48A2AF91.2040709@egenix.com> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <48A2AF91.2040709@egenix.com> Message-ID: <18594.61392.391621.540976@montanaro-dyndns-org.local> Why not migrate support for older releases to interested parties outside of the regular developer team? Presuming there is someone out there with the interest in maintaining, say, Python 2.2, they could take over the entire responsibility for making releases, continuing to use the Subversion repository if they like, releasing on their own schedule, in the formats they deem appropriate. Skip From skip at pobox.com Wed Aug 13 16:41:51 2008 From: skip at pobox.com (skip at pobox.com) Date: Wed, 13 Aug 2008 09:41:51 -0500 Subject: [Python-Dev] Any PEP about 2.6 -> 3000 code transition? In-Reply-To: <6167796BFEB5D0438720AC212E89A6B0078F4D7E@exchange.onresolve.com> References: <4838EA2D.7060402@jcea.es> <319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com> <488150A5.8050804@jcea.es> <488451AB.50406@jcea.es> <4884581F.8010201@jcea.es> <319e029f0807211437w53619985s85157a60d42966e@mail.gmail.com> <6167796BFEB5D0438720AC212E89A6B0078F4D7E@exchange.onresolve.com> Message-ID: <18594.62127.615278.322937@montanaro-dyndns-org.local> >> (*) slides: >> http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf Trent> Hilarious! Seems like that would have been a riot of a session Trent> to attend. (I'm kicking myself for attending some other Trent> uninteresting talk when yours was on.) Indeed. Slide 155 is a typo, right? Skip From victor.stinner at haypocalc.com Wed Aug 13 16:46:32 2008 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Wed, 13 Aug 2008 16:46:32 +0200 Subject: [Python-Dev] Any PEP about 2.6 -> 3000 code transition? In-Reply-To: <1218634062.31375.164.camel@localhost> References: <4838EA2D.7060402@jcea.es> <1218634062.31375.164.camel@localhost> Message-ID: <200808131646.32224.victor.stinner@haypocalc.com> Le Wednesday 13 August 2008 15:27:42 Hrvoje Nik?i?, vous avez ?crit?: > Given that ctypes doesn't work on a number of popular architectures, > including x86_64 (the last time I looked), I'd hardly call that "better > off". :-( I wrote a debugger based on ptrace using ctypes: http://fusil.hachoir.org/trac/wiki/python-ptrace The debugger works well on: - Ubuntu Gutsy, i386 - Debian Etch, x86_64 <= yes, it works well - Debian Etch, ppc32 - FreeBSD 6.2 and 7.0, i386 <= yes, ctypes runs fine on FreeBSD too (so Python 2.4 with ctypes the external ctypes module and Python 2.5 with included ctypes) I have no other computer to test other CPUs :) ctypes allows to write code working on CPython 2.4, 2.5, 2.6 and 3.0 (with 2to3), but also on PyPy! Jython plans also to support ctypes. So, please, retry ctypes ;-) -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ From solipsis at pitrou.net Wed Aug 13 17:35:15 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 13 Aug 2008 15:35:15 +0000 (UTC) Subject: [Python-Dev] unittest Suggestions References: <20080812143059.GB20161@jroger.in-berlin.de> <853B3E43-669D-4D2D-B46F-66371DDB9FD6@python.org> Message-ID: Barry Warsaw python.org> writes: > The goal > should be to produce something like a unittest-ng, distribute it via > the Cheeseshop, and gather consensus around it for possible inclusion > in Python 2.7/3.1. There is already unittest, nose, py.test, trial... perhaps others I don't know of. I fear writing yet another testing framework from the ground-up will lead to more bikeshedding and less focussed discussion (see some testing-in-python threads for an example :-)). nose itself is not a completely independent piece of work but "a discovery-based unittest extension" (although a very big extension!). For that reason, Michael Foord's suggestion to gradually modernize and improve the stdlib unittest sounds reasonable to me: it allows to be more focussed, keep backwards compatibility, and also to decide and implement changes piecewise - avoiding the blank sheet effect where people all push for wild ideas and radically new concepts (tm). (however, nose is LGPL-licensed so it would not be suitable for direct reuse of large chunks of code in the stdlib, unless the authors agree for a relicensing) From exarkun at divmod.com Wed Aug 13 17:57:36 2008 From: exarkun at divmod.com (Jean-Paul Calderone) Date: Wed, 13 Aug 2008 11:57:36 -0400 Subject: [Python-Dev] unittest Suggestions In-Reply-To: Message-ID: <20080813155736.29191.1241046810.divmod.quotient.13910@ohm> On Wed, 13 Aug 2008 15:35:15 +0000 (UTC), Antoine Pitrou wrote: >Barry Warsaw python.org> writes: >> The goal >> should be to produce something like a unittest-ng, distribute it via >> the Cheeseshop, and gather consensus around it for possible inclusion >> in Python 2.7/3.1. > >There is already unittest, nose, py.test, trial... perhaps others I don't know >of. I fear writing yet another testing framework from the ground-up will lead to >more bikeshedding and less focussed discussion (see some testing-in-python >threads for an example :-)). > >nose itself is not a completely independent piece of work but "a discovery-based >unittest extension" (although a very big extension!). For that reason, Michael >Foord's suggestion to gradually modernize and improve the stdlib unittest sounds >reasonable to me: it allows to be more focussed, keep backwards compatibility, >and also to decide and implement changes piecewise - avoiding the blank sheet >effect where people all push for wild ideas and radically new concepts (tm). > >(however, nose is LGPL-licensed so it would not be suitable for direct reuse of >large chunks of code in the stdlib, unless the authors agree for a relicensing) > trial is also an extension of the stdlib unittest module (less and less over time as more and more stdlib unittest changes break it). Incremental improvements with backwards compatibility are a great thing. I very strongly encourage that course of action. It has already happened a number of times in this thread that some proposed functionality already exists in some third-party unittest extension and could easily be moved into the stdlib unittest module. That's a good thing: it shows that the functionality is actually valuable and it makes it easy to include, since it's already implemented. For what it's worth, trial is MIT licensed; anyone should feel free to grab any part of it they like for any purpose. Jean-Paul From jcea at jcea.es Wed Aug 13 19:14:21 2008 From: jcea at jcea.es (Jesus Cea) Date: Wed, 13 Aug 2008 19:14:21 +0200 Subject: [Python-Dev] pybsddb 4.7.3pre1: Compatibility with Python 3.0 Message-ID: <48A3166D.8080703@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. Sorry for spamming several mailing list. After many hours of hard work, I'm proud to present a preview of pybsddb 4.7.3, able to compile and work under Python 2.3, 2.4, 2.5, 2.6b2 and 3.0b2. You can try it out downloading it directly from my repository: ~ svn co -r 597 svn://svn.argo.es/jcea/pybsddb/trunk \ ~ pybsddb-4.7.3pre1 Please, DO NOT download any other revision, since I can make changes anytime, breaking things. To exercise the testsuite (currently, 304 tests, if you are running the more recent Berkeley DB release (4.7.25)), do: ~ python2.3 test.py -bv ~ python2.4 test.py -bv ~ python2.5 test.py -bv ~ python2.6 test.py -bv ~ python3.0 test.py -bv This will compile the code and run the testsuite for each supported python release. Of course you need to have Berkeley DB installed, better if you have 4.6 (fully patched, the original release was very buggy) or the last 4.7.25 release (rock solid). You can install the code using the usual "python setup.py install". BEWARE, nevertheless; this code is not ready for production use, especially under Python 3.0. But, please, test your code with this preview. Test it as hard as you can. Current code has several ugly hacks (like some abuse of "hasattr" to avoid selected automatic 2to3 conversion), but it works and it will be improved in the future. Please, report any issue, incompatibility or improvement you can see. I plan to release pybsddb 4.7.3 in mid-september, ready to be delivered bundled in Python 2.6/3.0 (to be released early in october). I'll be on summer holidays, 100% offline, until early september. I will read your comments as soon as possible. Thanks for your time!. Homepage: http://www.jcea.es/programacion/pybsddb.htm http://www.jcea.es/programacion/pybsddb.htm#bsddb-4.7.3 http://www.jcea.es/programacion/pybsddb_doc/preview/ CHANGES SINCE 4.7.2: """ ~ * "private" is a keyword in C++. (Duncan Grisby) ~ * setup.py should install "bsddb.h". (Duncan Grisby) ~ * "DB_remove" memory corruption & crash. (Duncan Grisby) ~ * Under Python 3.0, you can't use string keys/values, but ~ bytes ones. Print the right error message. ~ * "DB.has_key()" allowed transactions as a positional parameter. ~ We allow, now, transactions as a keyword parameter also, as ~ documented. ~ * Correct "DB.associate()" parameter order in the documentation. ~ * "DB.append()" recognizes "txn" both as a positional and a ~ keyword parameter. ~ * Small fix in "dbshelve" for compatibility with Python 3.0. ~ * A lot of changes in "dbtables" for compatibility with Python 3.0. ~ * Huge work making the testsuite compatible with Python 3.0. ~ * In some cases the C module returned Unicode strings under ~ Python 3.0. It should return "bytes", ALWAYS. Solved. """ NOTES ABOUT PYTHON 3.0: The most visible change in Python 3.0, related to this library, is that Python 2.x strings are replaced by unicode strings and "bytes" objects. Under Python 3.0, pybsddb always consumes and produces "bytes" objects. Unicode strings are rejected. To easy testsuite porting, I've defined some minimal proxy/adapter objects to facade unicode strings from/to "bytes". So, current testsuite works for every supported python release, with the minimal conditional code. These adapter objects ARE NOT INTENTED to be used in production. If you are developing for Python 3.0, just use the right approach: use the native "bytes" objects. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSKMWY5lgi5GaxT1NAQL64gP/flHcMi3PIMuy2iiMZftYZ9GLVFLztxxD FZBivMJj/n3+B6tQ4PK9FZwYvelE4lgTPuC/Lv94SJi8xW3CxtLyjoUcj7Pobf3t 8cV6jXdcczQbYa8/4+kptQyHhr/lNnQD9vZ7Do1+D8Zdoz/vUM6yXKoKQnAiDcfQ 0qmlY+15SgA= =RNRk -----END PGP SIGNATURE----- From martin at v.loewis.de Wed Aug 13 22:32:27 2008 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 13 Aug 2008 22:32:27 +0200 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <48A2AF91.2040709@egenix.com> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <48A2AF91.2040709@egenix.com> Message-ID: <48A344DB.9080002@v.loewis.de> > It's difficult to use such download numbers as hint for the number > of deployed installations. 2.4.5 was not released as binary, so > interested parties had to compile that version by themselves and > those installations don't show up in your statistics. You mean, they installed it *without* downloading it? How did they do that? > I'm sure that if we had released binaries as well, the number would > have looked different, esp. if you only look at the Windows binaries. See, that's exactly the problem. We don't have the resources to provide Windows binaries. So even if the release contained regular bug fixes, I *still* would not have released Windows binaries. > That's a valid point, but does this really warrant backing out > changes that have already been applied ? Isn't it better to get > at least some bugs fixed rather than to not fix them at all ? Yes. Otherwise, neither developers nor users have a clear guideline what to expect. > Perhaps we should just document the maintenance of Python releases > more clearly and also plan for a final bug fix release 3 years after > the initial branch release. That way developers and users can also > adjust their plans accordingly. There was clear documentation. It said "2.4 is done, finished, closed, over with, not maintained anymore". We had been doing that for many releases in the past. Now, you and me, we both want to change the policy. I want to change to provide security releases for a period of five years, and I think this is feasible with the resources that we have. You just suggested to provide bug fix releases for three years, and I think that is not feasible. In addition, it still would mean that we should not have done a bug fix release in 2008 (as 2.4.5 was released in March 2008); instead, the last bug fix release should have been made in November 2007. Nobody (including yourself) stepped forward at that time and offered to roll a release. 2.4 was release on November 30, 2004. Regards, Martin From jjl at pobox.com Wed Aug 13 22:42:28 2008 From: jjl at pobox.com (John J Lee) Date: Wed, 13 Aug 2008 21:42:28 +0100 (BST) Subject: [Python-Dev] unittest Suggestions In-Reply-To: References: <20080812143059.GB20161@jroger.in-berlin.de> <853B3E43-669D-4D2D-B46F-66371DDB9FD6@python.org> Message-ID: On Wed, 13 Aug 2008, Antoine Pitrou wrote: [...] > nose itself is not a completely independent piece of work but "a discovery-based > unittest extension" (although a very big extension!). For that reason, Michael > Foord's suggestion to gradually modernize and improve the stdlib unittest sounds > reasonable to me: it allows to be more focussed, keep backwards compatibility, > and also to decide and implement changes piecewise - avoiding the blank sheet > effect where people all push for wild ideas and radically new concepts (tm). +1 (speaking as somebody who has worked on nose a bit) John From mal at egenix.com Wed Aug 13 23:11:48 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 13 Aug 2008 23:11:48 +0200 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <48A344DB.9080002@v.loewis.de> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <48A2AF91.2040709@egenix.com> <48A344DB.9080002@v.loewis.de> Message-ID: <48A34E14.9090209@egenix.com> On 2008-08-13 22:32, Martin v. L?wis wrote: >> It's difficult to use such download numbers as hint for the number >> of deployed installations. 2.4.5 was not released as binary, so >> interested parties had to compile that version by themselves and >> those installations don't show up in your statistics. > > You mean, they installed it *without* downloading it? How did they > do that? What I was trying to say is that you only see a single source download, which someone then takes, compiles and possibly redistributed or integrates into a product. As a result a single download can easily map to quite a few installations - and that's what we should base our assumptions on. >> I'm sure that if we had released binaries as well, the number would >> have looked different, esp. if you only look at the Windows binaries. > > See, that's exactly the problem. We don't have the resources to provide > Windows binaries. So even if the release contained regular bug fixes, > I *still* would not have released Windows binaries. I was just suggesting that the number of downloads would have been higher had you released Windows binaries as well. We see that all the time with the eGenix products. Anyway, that's just statistics :-) >> That's a valid point, but does this really warrant backing out >> changes that have already been applied ? Isn't it better to get >> at least some bugs fixed rather than to not fix them at all ? > > Yes. Otherwise, neither developers nor users have a clear guideline > what to expect. I disagree on that, but I'm fine with such a plan if it's documented well in advance. >> Perhaps we should just document the maintenance of Python releases >> more clearly and also plan for a final bug fix release 3 years after >> the initial branch release. That way developers and users can also >> adjust their plans accordingly. > > There was clear documentation. It said "2.4 is done, finished, closed, > over with, not maintained anymore". We had been doing that for many > releases in the past. Right, but that documentation was only available after the release manager decided to stop creating releases for that branch - ie. around the time that final release was cut. In order to plan for the end of lifetime of a software product, you need this information well upfront - for both the developers (so that they can get fixes in before the end-of-lifetime) and users (who will then have to plan to upgrade their installations and products relying on Python). > Now, you and me, we both want to change the policy. I want to change > to provide security releases for a period of five years, and I think > this is feasible with the resources that we have. You just suggested > to provide bug fix releases for three years, and I think that is > not feasible. Actually, I was suggesting to have bug fix releases for 3 years and security fixes for another 2 years (ie. 5 years lifetime in total). > In addition, it still would mean that we should not have > done a bug fix release in 2008 (as 2.4.5 was released in March 2008); > instead, the last bug fix release should have been made in November > 2007. Nobody (including yourself) stepped forward at that time and > offered to roll a release. 2.4 was release on November 30, 2004. I don't want this written in stone, but there should be a pre-defined roadmap for the whole lifetime Python release branch - from start to end. Please note that a policy is really just that: a guideline for everyone to follow. It doesn't restrict us in maintaining a release for more than the originally intended 3/5 years phases or creating a bug fix release after the initial 3 years. However, it should be seen as guideline for the minimum amount of time a release is being maintained - for everyone to see early (ie. in the Python release PEP) and use as basis for making decisions on which release to take as basis for a software project. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 13 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From martin at v.loewis.de Wed Aug 13 23:37:40 2008 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 13 Aug 2008 23:37:40 +0200 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <48A34E14.9090209@egenix.com> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <48A2AF91.2040709@egenix.com> <48A344DB.9080002@v.loewis.de> <48A34E14.9090209@egenix.com> Message-ID: <48A35424.9060108@v.loewis.de> > What I was trying to say is that you only see a single source download, > which someone then takes, compiles and possibly redistributed or > integrates into a product. As a result a single download can > easily map to quite a few installations - and that's what we should > base our assumptions on. The same is true for any later release, too. A single release of Python 2.5.2 will result in many Debian installations, for example. Still, the *ratio* of the downloads is quite informative, since the same factors apply to both branches. In the specific case, we know that Debian provides 2.5.2, but not 2.4.5, as they avoid integrating newer releases out of fear for new features, and selectively only pick the security patches. So I can cite at least one large multiplicator product which *doesn't* want new maintenance branch releases, but wants explicit identification of security patches only. I recall people from Redhat saying the same thing. >> There was clear documentation. It said "2.4 is done, finished, closed, >> over with, not maintained anymore". We had been doing that for many >> releases in the past. > > Right, but that documentation was only available after the release > manager decided to stop creating releases for that branch - ie. > around the time that final release was cut. No, it was discussed months in advance, and had been followed at least for the 2.3 release (the final 2.2 release occurred even before 2.3). 2.3.5 states, on its web page, that it is the final release of 2.3. > In order to plan for the end of lifetime of a software product, > you need this information well upfront - for both the developers > (so that they can get fixes in before the end-of-lifetime) and > users (who will then have to plan to upgrade their installations > and products relying on Python). Right. Therefore, I circulated a PEP proposing such a strategy in May 2007. > I don't want this written in stone, but there should be a pre-defined > roadmap for the whole lifetime Python release branch - from start to > end. I agree with that. Unfortunately, my PEP didn't get much feedback at that time. Regards, Martin From barry at python.org Thu Aug 14 00:37:04 2008 From: barry at python.org (Barry Warsaw) Date: Wed, 13 Aug 2008 18:37:04 -0400 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <48A276EE.8070903@v.loewis.de> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> Message-ID: <8A084AA0-B0B9-40D6-821B-671941357884@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 13, 2008, at 1:53 AM, Martin v. L?wis wrote: >>> Because there won't typically be sufficient testing and release >>> infrastructure to allow arbitrary bug fixes to be committed on the >>> branch. The buildbots are turned off, and nobody tests the release >>> candidate, no Windows binaries are provided - thus, chances are very >>> high that a bug fix release for some very old branch will be *worse* >>> than the previous release, rather than better. >> >> Second, I don't think this is true. People using those patch >> level releases will test and report bugs if they are introduced >> by such backports. > > They might be using releases, but they are *not* using the subversion > maintenance branches. Do you know anybody who regularly checks out the > 2.4 maintenance branch and tests it? > > So at best, people will only report bugs *after* the release was made, > meaning that there is a realistic chance that the release itself > breaks > things. Sure, but this is just as true for security fixes. The only thing the policy buys us is fewer /possibilities/ of breakage. I'm not discounting that as worthwhile, but qualitatively, there's no difference between non-security fixes and security fixes, as far as our Q/A process goes. > My problem is that this backporting is not systematic. It's arbitrary > whether patches get backported or not. Part of the problem is that > it is/was also unclear whether there ever will be another release made > out of 2.4. When 2.4.4 was released, Anthony announced, in > > http://mail.python.org/pipermail/python-dev/2006-October/069326.html > > "This will be the last planned release in the Python 2.4 series" > > So anybody committing to the 2.4 branch after that should have > expected > that the patches will never get released. There's a difference between never being released, and unavailable in the source repository. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKNiEXEjvBPtnXfVAQIQgAP6A84mpv0JUkP4Z904TzoYDuqb3OtCNBMc wo+VGw00p9JJ0f4lWRmXSkimtLNe1xoOj0/qhYXBa64P7ti3oa9Wo4VHCK/N0IcW p8vXvhMG9sIhYrGb2cWDc4d/UA0kQqBPp3srtXwEumoWQbScH0zJHM7llX10unJ1 UfTST6Tof/s= =ilvh -----END PGP SIGNATURE----- From barry at python.org Thu Aug 14 00:42:33 2008 From: barry at python.org (Barry Warsaw) Date: Wed, 13 Aug 2008 18:42:33 -0400 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <18594.61392.391621.540976@montanaro-dyndns-org.local> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <48A2AF91.2040709@egenix.com> <18594.61392.391621.540976@montanaro-dyndns-org.local> Message-ID: <3FD273DF-525F-4311-B8D7-F7BDA97D9919@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 13, 2008, at 10:29 AM, skip at pobox.com wrote: > Why not migrate support for older releases to interested parties > outside of > the regular developer team? Presuming there is someone out there > with the > interest in maintaining, say, Python 2.2, they could take over the > entire > responsibility for making releases, continuing to use the Subversion > repository if they like, releasing on their own schedule, in the > formats > they deem appropriate. This I agree with. If nobody's motivated to do the work, then problem solved, it doesn't get done. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKNjW3EjvBPtnXfVAQLCLwP/QEFeXZstWcEuLbicMuqipREQsruTJW9v SJURMYCZBdfkgiTm3cr2MVK9e/FpX7FUvhCKlAOpyAFOWM3FFiv/J+wBRNHcli2p NHYbG8scmUHwVZ1oL1pWr7NLgECh0DsXBTWWubRyR3XqG1bdnk+B0wKuzcxNOH5Y McLahXhN56g= =m7SB -----END PGP SIGNATURE----- From martin at v.loewis.de Thu Aug 14 01:11:23 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 14 Aug 2008 01:11:23 +0200 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <8A084AA0-B0B9-40D6-821B-671941357884@python.org> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <8A084AA0-B0B9-40D6-821B-671941357884@python.org> Message-ID: <48A36A1B.4010707@v.loewis.de> > There's a difference between never being released, and unavailable in > the source repository. So would you have preferred if I had forked another branch that still contained these patches? Such branch can still be added now. Nothing that gets added to the source repository ever becomes unavailable. Re-adding them is fairly easy: they are all in r61179. Going forward, the question would then be if these patches will ever get released. So there could be two branches, one that people can commit arbitrary bug fixes to (which will never be released), and one that gets security patches (which will get released for five years). Of course, I would personally find it fairly confusing to have people commit patches that are explicitly will not be released, and still aren't experimental or private-use. Regards, Martin From brett at python.org Thu Aug 14 05:29:14 2008 From: brett at python.org (Brett Cannon) Date: Wed, 13 Aug 2008 20:29:14 -0700 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <48A36A1B.4010707@v.loewis.de> References: <4838EA2D.7060402@jcea.es> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <8A084AA0-B0B9-40D6-821B-671941357884@python.org> <48A36A1B.4010707@v.loewis.de> Message-ID: On Wed, Aug 13, 2008 at 4:11 PM, "Martin v. L?wis" wrote: >> There's a difference between never being released, and unavailable in >> the source repository. > > So would you have preferred if I had forked another branch that still > contained these patches? Such branch can still be added now. Nothing > that gets added to the source repository ever becomes unavailable. > Re-adding them is fairly easy: they are all in r61179. > > Going forward, the question would then be if these patches will ever > get released. So there could be two branches, one that people can commit > arbitrary bug fixes to (which will never be released), and one that > gets security patches (which will get released for five years). > > Of course, I would personally find it fairly confusing to have people > commit patches that are explicitly will not be released, and still > aren't experimental or private-use. > And toss in having the potential 2.6/2.7/3.0/3.1 branches all at once and that makes having separate security and bug fix branches just not work. To toss in my opinion (which shouldn't count for too much since I have yet to cut a release), I am mostly with Martin on this one. We currently keep one version back running on the buildbots so we at least have some inkling of what patches do so we can provide some level of quality control on releases (even though we have some red stable buildbots for 2.5 right now). But without running buildbots on the code who knows what a change will do on various platforms. And who wants to deal with a bug report on 2.4 at this point? Now I would have said that someone could just cut a release if they want and people can just not be expected to backport if they don't feel like it. But then what about when we do fix security issues? If someone does a backport of a security fix but can't run the test suite because that version of Python has not been tested on their OS or buildbot, then that stonewalls their work. I would not want to potentially see this happen. Basically my opinion boils down to a version should be maintained as long as we have the infrastructure to be testing it regularly on the buildbots (or whatever the equivalent is for our integrated testing). As of right now that means the current version and the trunk. If we actually manage to get the manpower and machines to maintain more, then we can consider maintaining versions longer. But as of right now we don't not have the volunteers to do this and so I don't think we should be considering doing more than what we are doing now. -Brett From Scott.Daniels at Acm.Org Thu Aug 14 06:18:38 2008 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Wed, 13 Aug 2008 21:18:38 -0700 Subject: [Python-Dev] PEP: Frequently-requested additional features for the `unittest` module In-Reply-To: <877ibm5y37.fsf_-_@benfinney.id.au> References: <20080713093936.GA3623@benfinney.id.au> <487A8700.8000200@voidspace.org.uk> <877ibm5y37.fsf_-_@benfinney.id.au> Message-ID: Ben Finney wrote: > Michael Foord writes: > >> The full list of changes proposed [?] and not shot down was >> something like: > [?] > >> assertLessThan >> assertGreaterThan >> assertLessThanOrEquals >> assertGreaterThanOrEquals > [?] > > "Brett Cannon" writes: > >> Is any of this really necessary? Isn't this the equivalent of >> ``assert_(a < b)``? It seems like the only thing you get out of this >> is a nicer error message, but ``assert_(a < b, 'not %r <= %s' % (a, >> b))`` is not that complex. And do these cases really come up that >> often? I would want to see some numbers showing that these are >> really necessary (in both usage and people even specifying an error >> message in the first place). > > Though I'm the champion of this PEP, I'll have to refer to Michael > Foord for his reasoning (or reference to others' reasoning) on this. > My reasoning goes something like this: self.assertLessThan(abs(self.base.method(parm1, parm2) - self.base.nominal), 2.54, 'Within an inch') vs. distance = self.base.method(parm1, parm2) deviation = self.base.method(parm1, parm2) - self.base.nominal self.assert_(abs(deviation) < 2.54, '%s is %s out of spec (more ' 'than an inch)' % (distance, deviation) It is not so much the assertion on values in variables, as it is assertions on results of calculations. Unfortunately, my tendency would be to forgo the "within an inch" over extracting the values into locals for the purpose of the test; the tests I'm writing currently focus on the manipulation of hardware for the reader, not on the extraction of data for the purpose of testing. Some of the longer sections are already nearly a couple of pages long; that's how much code it takes to do a coherent operation on this particular hardware. I hate that I am using 2 pages now (half a page per is what I'd prefer), and I'm not willing to bloat the operation with more code. As a result, I implemented my own versions of these asserts (Le, Lt, ...) a year or so ago, and still find them so useful that I'll re-implement them where- ever I am working without similar tests available. --Scott David Daniels Scott.Daniels at Acm.Org From barry at python.org Thu Aug 14 06:08:45 2008 From: barry at python.org (Barry Warsaw) Date: Thu, 14 Aug 2008 00:08:45 -0400 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <48A36A1B.4010707@v.loewis.de> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <8A084AA0-B0B9-40D6-821B-671941357884@python.org> <48A36A1B.4010707@v.loewis.de> Message-ID: <7F31EB3D-23DF-429A-8F44-5AA630D8F1EA@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 13, 2008, at 7:11 PM, Martin v. L?wis wrote: >> There's a difference between never being released, and unavailable in >> the source repository. > > So would you have preferred if I had forked another branch that still > contained these patches? Such branch can still be added now. Nothing > that gets added to the source repository ever becomes unavailable. > Re-adding them is fairly easy: they are all in r61179. Sure, but nobody's going to dig through commit messages to dig out those patches. I'm not sure what I would have preferred. Really, I was mostly fine with the decision to do as we did. But if we stick with the policy you propose (which I'm not sure is completely nailed down yet), then I will be sure not to waste my time on closed releases next time. > Going forward, the question would then be if these patches will ever > get released. So there could be two branches, one that people can > commit > arbitrary bug fixes to (which will never be released), and one that > gets security patches (which will get released for five years). > > Of course, I would personally find it fairly confusing to have people > commit patches that are explicitly will not be released, and still > aren't experimental or private-use. No, I don't think we need another branch per version. I'm clearly in the minority, and I've said my peace on the subject, so I'll let it go. Moving forward, I do want to make sure we communicate to our users and developers, exactly what the policy is, with enough advanced warning for each version so that they can plan ahead and won't waste time. Ideally, we would lay this out when we plan the release. For example, let's project dates for closing 2.6 and 3.0 now, and add them to PEP 361. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKOvzXEjvBPtnXfVAQImrAP+IZHk711jPL8GdfrFiENt0KgGD5vjjg/g kxgBsyVWi/wOonM0cFUABzSxBzfCOPd1eWtD54bs4rk32sXA+v3qtoHKylPsv/0O 8WUq4dXZ3LLn7D50WKWrJNIKTlAaxoH+OWCKK+qgaCEFhv/uKAISaeAxADh2vlzK YQmkz//7Jjs= =GTEP -----END PGP SIGNATURE----- From martin at v.loewis.de Thu Aug 14 08:43:06 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 14 Aug 2008 08:43:06 +0200 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <7F31EB3D-23DF-429A-8F44-5AA630D8F1EA@python.org> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <8A084AA0-B0B9-40D6-821B-671941357884@python.org> <48A36A1B.4010707@v.loewis.de> <7F31EB3D-23DF-429A-8F44-5AA630D8F1EA@python.org> Message-ID: <48A3D3FA.9040805@v.loewis.de> > For example, let's project dates for closing 2.6 and 3.0 now, and add > them to PEP 361. My view is that they should be closed when 2.7 and 3.1 are released. Following another informal policy, we were going for an 18 months release cycle at some time (2.6 clearly took longer), which would mean that those branches get closed on March 1, 2010. Security releases will be available until October 1, 2013. Regards, Martin From mal at egenix.com Thu Aug 14 12:03:56 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 14 Aug 2008 12:03:56 +0200 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <48A3D3FA.9040805@v.loewis.de> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <8A084AA0-B0B9-40D6-821B-671941357884@python.org> <48A36A1B.4010707@v.loewis.de> <7F31EB3D-23DF-429A-8F44-5AA630D8F1EA@python.org> <48A3D3FA.9040805@v.loewis.de> Message-ID: <48A4030C.3030407@egenix.com> On 2008-08-14 08:43, Martin v. L?wis wrote: >> For example, let's project dates for closing 2.6 and 3.0 now, and add >> them to PEP 361. > > My view is that they should be closed when 2.7 and 3.1 are released. Since we don't have a fixed release cycle, making the 2.(n-1) maintenance time frame depend on the 2.n release is not a reliable way of defining the 2.(n-1) lifetime. Instead, we should fix the dates based on the 2.(n-1) release date. > Following another informal policy, we were going for an 18 months > release cycle at some time (2.6 clearly took longer), which would > mean that those branches get closed on March 1, 2010. Security > releases will be available until October 1, 2013. That would only allow 1.5 years for bug fixes - we were discussing 3 years for bug fixes and another 2 years for security fixes, ie. 2.6 bug fixes until Oct 01 2011 2.6 security fixes until Oct 01 2013 Ditto for 3.0. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 14 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From ncoghlan at gmail.com Thu Aug 14 13:41:26 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 14 Aug 2008 21:41:26 +1000 Subject: [Python-Dev] pybsddb 4.7.3pre1: Compatibility with Python 3.0 In-Reply-To: <48A3166D.8080703@jcea.es> References: <48A3166D.8080703@jcea.es> Message-ID: <48A419E6.4070206@gmail.com> Jesus Cea wrote: > I plan to release pybsddb 4.7.3 in mid-september, ready to be delivered > bundled in Python 2.6/3.0 (to be released early in october). Jesus, I think your target date is off by a month - it may be better to try and land an initial cut of this in Python SVN for beta 3 (August 20), rather than hoping to make significant changes after the first release candidate (which is currently slated for September 3). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From olemis at gmail.com Thu Aug 14 14:13:43 2008 From: olemis at gmail.com (Olemis Lang) Date: Thu, 14 Aug 2008 08:13:43 -0400 Subject: [Python-Dev] unittest Suggestions In-Reply-To: <20080813155736.29191.1241046810.divmod.quotient.13910@ohm> References: <20080813155736.29191.1241046810.divmod.quotient.13910@ohm> Message-ID: <24ea26600808140513l3fc8b653kb656bcf670fdc378@mail.gmail.com> > > > > > The goal > > > should be to produce something like a unittest-ng, distribute it via > > > the Cheeseshop, and gather consensus around it for possible inclusion > > > in Python 2.7/3.1. > > > > > IMO test support in Python needs some enhancements. I also think there are great libraries available today in Python (stdlib)... but you know... other frameworks (e.g. JUnit, NUnit, ...) have evolved in order to support more effective practices and also to satisfy new requirements present in more complex test environments and ... and improvements are really necessary. That's why... > unittest.asserts > ---------------- > > Currently all assertions reside as methods on the TestCase class. This > means that all testing functions, including utility functions, need to be > on a TestCase-derived class. This seems wrong to me, especially since it > combines different concerns on a class: Testing the functionality of a > SUT, running a test suite, and providing test functions. I agree... > This proposal > will not try to separate the first two concerns, but only the third one. I think this is cool... > In the long term I think it's worthwhile to make tests work on any > class, not only on classes derived from TestCase, but as I said, this is > not part of this proposal. > I am not very sure about this... even though I love doctest, and you can define that kind of tests in almost every class... but I think this case is different since doctests have an additional value... Users can quickly and easily see example usage while they are looking for help. IMO today (I would like you to make me change my mind) this could lead to test code mixed with the functionality of (for example) a class... and at least now I don't see the benefits. > JUnit 4 moved the assertions to a static class in a separate module. In > Python I'd propose to use functions in a separate module. I agree 100% with this... However, I think that TestCase assert* (or fail*, as you wish... that's another thread) methods should remain available for a while so as to avoid breaking third party (and perhaps stdlib) test code. But conceptually I think this is ok. It'd be precise to evaluate how much convinient it is in practice. About the rest... I will have further comments once I see this... in action ;-). > > There is already unittest, nose, py.test, trial... perhaps others I don't > know > > of. I fear writing yet another testing framework from the ground-up will > lead to > > more bikeshedding and less focussed discussion (see some testing-in-python > > threads for an example :-)). > > I think there should be a consensus about which are the most relevant improvements needed nowadays in this field. The weaknesses and strong points. And also what will be considered standard and what will be considered third party modules (because including every library code available, or a particular framework as a whole, "might" not be a good idea). And this does not mean that some code that is available and distributed under "appropriate" terms will (can) not be included in the future, nor that a new test framework ought to be built from scratch. I mean that both kinds of decisions should be made considering some kind of "requirements" or "milestones" which clearly state what should (needs to) be done... and perhaps this could be the first milestone to avoid chaos. What I do think is that we need a mail list (or equivalent) dedicated to discuss such things... because (again IMO) python-dev might not be the best place to talk about these topics. Or what is the same... there should be a place (preferently here in python.org) to talk about this topics in detail, without interfering with the development of the language itself. The relevant decisions and ideas might be communicated somehow (e.g. informational / ST / Process PEPs, guidelines) in order to "keep focused". > Incremental > improvements with backwards compatibility are a great thing. I agree... > I very > strongly encourage that course of action. It has already happened a number > of times in this thread that some proposed functionality already exists in > some third-party unittest extension and could easily be moved into the > stdlib unittest module. That's a good thing: it shows that the > functionality > is actually valuable and it makes it easy to include, since it's already > implemented. > Yes... this is right when "we all" agree on what "we" want and find out that the library turns "our dreams" into "reality". -- Regards, Olemis. From fdrake at acm.org Thu Aug 14 14:21:49 2008 From: fdrake at acm.org (Fred Drake) Date: Thu, 14 Aug 2008 08:21:49 -0400 Subject: [Python-Dev] unittest Suggestions In-Reply-To: <24ea26600808140513l3fc8b653kb656bcf670fdc378@mail.gmail.com> References: <20080813155736.29191.1241046810.divmod.quotient.13910@ohm> <24ea26600808140513l3fc8b653kb656bcf670fdc378@mail.gmail.com> Message-ID: <86596030-81F9-47B8-A534-2F4F33E1FE06@acm.org> On Aug 14, 2008, at 8:13 AM, Olemis Lang wrote: > What I do think is that we need a mail list (or equivalent) dedicated > to discuss such things... because (again IMO) python-dev might not be It's not, but this list is the right place: http://lists.idyll.org/listinfo/testing-in-python -Fred -- Fred Drake From matt.giuca at gmail.com Thu Aug 14 16:54:12 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Fri, 15 Aug 2008 00:54:12 +1000 Subject: [Python-Dev] uuid test fails Message-ID: Hi, I thought I'd bring this up on both the tracker and mailing list, since it's important. It seems the test suite breaks as of r65661. I've posted details to the bug tracker and a patch which fixes the module in question (uuid.py). http://bugs.python.org/issue3552 Cheers Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From olemis at gmail.com Thu Aug 14 17:34:47 2008 From: olemis at gmail.com (Olemis Lang) Date: Thu, 14 Aug 2008 11:34:47 -0400 Subject: [Python-Dev] Fwd: PEP: Frequently-requested additional features for the `unittest` module In-Reply-To: <24ea26600808140617j46e2caa9q33880d6695f6dcdb@mail.gmail.com> References: <87fxqa62xb.fsf@benfinney.id.au> <24ea26600808140617j46e2caa9q33880d6695f6dcdb@mail.gmail.com> Message-ID: <24ea26600808140834u1d4cc3aese06805fb3ef29d22@mail.gmail.com> > > Abstract > ======== > > This PEP proposes frequently-requested additions to the standard > library `unittest` module that are natural extensions of its existing > functionality. > I had not seen this proposal... I will post a few comments. > > Motivation > ========== > > The `unittest` module is functionally complete. Nevertheless, many > users request and devise extensions to perform functions that are so > common they deserve to be in the standard module. > > > Specification > ============= > > New condition tests > ------------------- > > The following test methods will be added to the ``TestCase`` class. > The function signature is part of this specification. The body is to > be treated as a reference implementation only; any functionally > identical implementation also meets this specification. > ... > > The following test methods are also added. Their implementation in > each case is simply the logical inverse of a corresponding method > above. > My question here is... should assert* (fail*) methods be included in a separate class or module? I think this is a good idea (at least in the long term) Take a look at the following thread [1] for further details > > Simple invocation of test collection > ------------------------------------ > > The following new functionality will be added to the `unittest` > module. The function signature for ``run_tests`` is part of this > specification; the implementation is to be considered a reference > implementation only. > > :: > > def run_tests( > tests, > loader_class=TestLoader, suite_class=TestSuite, > runner_class=TextTestRunner): > """ Run a collection of tests with a test runner > > :param tests: > A sequence of objects that can contain test cases: > modules, `TestSuite` instances, or `TestCase` > subclasses. > :param loader_class: > The type of test loader to use for collecting tests > from the `tests` collection. > :param suite_class: > The type of test suite to use for accumulating the > collected test cases. > :param runner_class: > The type of test runner to instantiate for running the > collected test cases. > :return: > None. > > """ > I suppose that the reason for this function to exist is to ease test code (provide a shortcut or something), reuse some test code, and still allow different loading, running strategies. However, I dont think that passing (loader / suite / runner) classes in to this function is a good idea... IMO objects should be considered instead... Why? Mainly because the code assumes that all loaders are stateless. This may be true for unittest's and perhaps others, but this might not always be true. An example of statefull test loaders might be found in [2] (presented in [3]), and perhaps there other examples like this (even though I don't know them). This kind of code might restrain the use of this kind of loaders, and therefore might not be as reusable as should be. Nonetheless, you might think this is a very peculiar case and decide that this comment is irrelevant, but as far as I know, semantics of unittest TestLoader do not enforce that its subclasses ought to be stateless (although, I repeat, unittest test loaders are stateless). The same might be said for test runners... and they are more likely to be stateful. > def iter_testcases_recursively(collection, loader): > # Flatten and iterate over collection, generating > # instances of TestCase > loader = loader_class() > suite = suite_class() > for testcase in iter_testcases_recursively(tests, loader): > suite.add_tests(testcase) > runner = runner_class() > runner.run(suite) Besides... why is it necessary to flatten a hierarchy of test suites containing test cases? Why do you need to put them into another suite if the test loader already does this for us? Isn't it an extra overhead? Also there is a class attribute (`suiteClass`) in TestLoader which allows doing something like this. [1] [Python-Dev] unittest Suggestions (http://mail.python.org/pipermail/python-dev/2008-August/081763.html) [2] Module dutest (https://sourceforge.net/project/showfiles.php?group_id=220287&abmode=1) [3] [Python-Dev] An OO API for doctest / unittest integration... (http://mail.python.org/pipermail/python-dev/2008-August/081761.html) -- Regards, Olemis. From brett at python.org Thu Aug 14 21:57:16 2008 From: brett at python.org (Brett Cannon) Date: Thu, 14 Aug 2008 12:57:16 -0700 Subject: [Python-Dev] Looking for an up-to-date address for john.benediktsson Message-ID: I was going through our list of email addreses for committers and realized that I don't have an address for john.benediktsson that works; his ewtllc.com address is bouncing. Anyone have an up-to-date one? -Brett From ncoghlan at gmail.com Thu Aug 14 23:04:33 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 15 Aug 2008 07:04:33 +1000 Subject: [Python-Dev] [python-committers] PQM? In-Reply-To: <48A4424E.3000600@cheimes.de> References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es> <1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org> <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org> <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org> <48A114EB.3090801@v.loewis.de> <48A12D81.1040309@v.loewis.de> <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org> <1218667291.22748.12.camel@fsol> <48A38669.4050204@cheimes.de> <8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org> <48A4424E.3000600@cheimes.de> Message-ID: <48A49DE1.4050009@gmail.com> Christian Heimes wrote: > Perhaps we could adopt a release plan similar to Ubuntu. They have > releases with cool, new and bleeding edge stuff followed by a release > that focuses on stability and long term support. Python 2.6 and > especially 3.0 are releases with new features. What do you think about > focusing on stability and long time support for 2.7 and 3.1? 2.7 might > be the last version of the 2.x series and we sure gonna have to fix lots > of issues in the 3.x series until it's matured. I actually thought that was the plan for 2.7/3.1 ever since Guido started talking about Py3k as a real thing instead of a "at some unspecified time in the future" activity. (Well, for 3.1 anyway - 2.6 should be as rock solid as we can make it, but 3.0 is going to have issues with availability of third party extensions no matter how solid or otherwise the core might be) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From van.lindberg at gmail.com Thu Aug 14 22:42:00 2008 From: van.lindberg at gmail.com (VanL) Date: Thu, 14 Aug 2008 15:42:00 -0500 Subject: [Python-Dev] Looking for an up-to-date address for john.benediktsson In-Reply-To: References: Message-ID: <48A49898.6070707@gmail.com> Brett Cannon wrote: > I was going through our list of email addreses for committers and > realized that I don't have an address for john.benediktsson that > works; his ewtllc.com address is bouncing. Anyone have an up-to-date > one? Replied privately. From aahz at pythoncraft.com Fri Aug 15 05:29:23 2008 From: aahz at pythoncraft.com (Aahz) Date: Thu, 14 Aug 2008 20:29:23 -0700 Subject: [Python-Dev] Maintaining old releases In-Reply-To: <48A4030C.3030407@egenix.com> References: <48A13DFA.3080504@v.loewis.de> <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org> <48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com> <48A276EE.8070903@v.loewis.de> <8A084AA0-B0B9-40D6-821B-671941357884@python.org> <48A36A1B.4010707@v.loewis.de> <7F31EB3D-23DF-429A-8F44-5AA630D8F1EA@python.org> <48A3D3FA.9040805@v.loewis.de> <48A4030C.3030407@egenix.com> Message-ID: <20080815032923.GB14312@panix.com> On Thu, Aug 14, 2008, M.-A. Lemburg wrote: > On 2008-08-14 08:43, Martin v. L?wis wrote: >>>For example, let's project dates for closing 2.6 and 3.0 now, and add >>>them to PEP 361. >> >>My view is that they should be closed when 2.7 and 3.1 are released. > > Since we don't have a fixed release cycle, making the 2.(n-1) > maintenance time frame depend on the 2.n release is not a reliable way > of defining the 2.(n-1) lifetime. > > Instead, we should fix the dates based on the 2.(n-1) release date. Why? As Brett pointed out, we simply don't have the infrastructure to maintain multiple releases -- if we force time-based maintenance, it won't work. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ Adopt A Process -- stop killing all your children! From status at bugs.python.org Fri Aug 15 18:06:34 2008 From: status at bugs.python.org (Python tracker) Date: Fri, 15 Aug 2008 18:06:34 +0200 (CEST) Subject: [Python-Dev] Summary of Python tracker Issues Message-ID: <20080815160634.D27ED7825B@psf.upfronthosting.co.za> ACTIVITY SUMMARY (08/08/08 - 08/15/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1949 open (+18) / 13434 closed (+14) / 15383 total (+32) Open issues with patches: 608 Average duration of open issues: 726 days. Median duration of open issues: 1646 days. Open Issues Breakdown open 1936 (+17) pending 13 ( +1) Issues Created Or Reopened (32) _______________________________ Remove long integer literals from Python 3.0 tutorial 08/09/08 CLOSED http://bugs.python.org/issue3529 created jsizelove patch ast.NodeTransformer bug 08/09/08 http://bugs.python.org/issue3530 created daishiharada file read preallocs 'size' bytes which can cause memory problems 08/09/08 http://bugs.python.org/issue3531 created dalke bytes.tohex method 08/09/08 http://bugs.python.org/issue3532 created mgiuca patch mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf 08/09/08 CLOSED http://bugs.python.org/issue3533 created barry-scott refactor.py can lose indentation for relative imports 08/09/08 CLOSED http://bugs.python.org/issue3534 created rupole zipfile has problem reading zip files over 2GB 08/10/08 http://bugs.python.org/issue3535 created alonwas case conversion problems in Turkish 08/10/08 http://bugs.python.org/issue3536 created ozan dict creation failure causes crash 08/10/08 CLOSED http://bugs.python.org/issue3537 created rupole patch Docstring typos 08/10/08 CLOSED http://bugs.python.org/issue3538 created Rambo007 Problem with pgen make dependencies in certain circumstances 08/11/08 http://bugs.python.org/issue3539 created skip.montanaro NotEmptyErrorError 08/11/08 CLOSED http://bugs.python.org/issue3540 created mft bsddb memory leak on ubuntu 08/11/08 http://bugs.python.org/issue3541 created kcwu Building an MSI installer crashes 08/11/08 http://bugs.python.org/issue3542 created pitrou patch ctypes works on Intel OS X, fails on PPC OS X 08/11/08 CLOSED http://bugs.python.org/issue3543 created janssen "expection" typo 08/11/08 CLOSED http://bugs.python.org/issue3544 created endolith Python turning off assertions (Windows) 08/12/08 CLOSED http://bugs.python.org/issue3545 created abe Missing linebreak in ext.doctest output 08/12/08 CLOSED http://bugs.python.org/issue3546 created schuppenies patch Ctypes is confused by bitfields of varying integer types 08/12/08 http://bugs.python.org/issue3547 created tim.maxwell subprocess.pipe function 08/12/08 http://bugs.python.org/issue3548 created tebeka patch Missing IDLE Preferences on Mac 08/13/08 http://bugs.python.org/issue3549 created pchew Socket Python 3k Documentation mistake OR Unicode string is not 08/14/08 CLOSED http://bugs.python.org/issue3550 created st33med multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES i 08/14/08 http://bugs.python.org/issue3551 created ocean-city uuid - exception on uuid3/uuid5 08/14/08 CLOSED http://bugs.python.org/issue3552 created mgiuca patch "2to3 -l" doesn't work when installed in /opt 08/14/08 CLOSED http://bugs.python.org/issue3553 created haypo patch ctypes.wstring_at and string_at call Python API without the GIL 08/14/08 http://bugs.python.org/issue3554 created kevinwatters Regression: nested exceptions crash (Cannot recover from stack o 08/14/08 http://bugs.python.org/issue3555 created ajaksu2 test_raiseMemError consumes an insane amount of memory 08/14/08 http://bugs.python.org/issue3556 created loewis Segfault in sha1 08/15/08 CLOSED http://bugs.python.org/issue3557 created mgiuca patch Operator precedence misdocumented 08/15/08 http://bugs.python.org/issue3558 created tjreedy Pasted \n not same as typed \n 08/15/08 http://bugs.python.org/issue3559 created tjreedy redundant "base" field in memoryview objects 08/15/08 http://bugs.python.org/issue3560 created pitrou Issues Now Closed (28) ______________________ Can't pickle partial functions 282 days http://bugs.python.org/issue1398 ngrilly Strange behavior of urlparse.urljoin 276 days http://bugs.python.org/issue1432 facundobatista patch trunk version does not compile with vs8 and vc6 185 days http://bugs.python.org/issue2065 loewis patch Windows: "Runtime Error!" crash from pythonw.exe (3.0a5) 90 days http://bugs.python.org/issue2841 tjreedy sphinx: config option for exclude_dirnames 59 days http://bugs.python.org/issue3097 georg.brandl shutil references undefined WindowsError symbol 54 days http://bugs.python.org/issue3134 pitrou patch bytearrays are not thread safe 56 days http://bugs.python.org/issue3139 loewis patch bz2 iterator fails silently on MemoryError 44 days http://bugs.python.org/issue3205 pitrou patch shutil.move bahave unexpected in fat32 39 days http://bugs.python.org/issue3253 pitrou csv.DictReader inconsistency 9 days http://bugs.python.org/issue3436 skip.montanaro patch BufferedWriter not thread-safe 15 days http://bugs.python.org/issue3476 pitrou patch pickle segfault with infinite loop in __getattr__ 8 days http://bugs.python.org/issue3514 alexandre.vassalotti Remove long integer literals from Python 3.0 tutorial 1 days http://bugs.python.org/issue3529 georg.brandl patch mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf 1 days http://bugs.python.org/issue3533 barry-scott refactor.py can lose indentation for relative imports 0 days http://bugs.python.org/issue3534 benjamin.peterson dict creation failure causes crash 1 days http://bugs.python.org/issue3537 georg.brandl patch Docstring typos 0 days http://bugs.python.org/issue3538 georg.brandl NotEmptyErrorError 0 days http://bugs.python.org/issue3540 georg.brandl ctypes works on Intel OS X, fails on PPC OS X 0 days http://bugs.python.org/issue3543 janssen "expection" typo 0 days http://bugs.python.org/issue3544 georg.brandl Python turning off assertions (Windows) 2 days http://bugs.python.org/issue3545 loewis Missing linebreak in ext.doctest output 2 days http://bugs.python.org/issue3546 georg.brandl patch Socket Python 3k Documentation mistake OR Unicode string is not 0 days http://bugs.python.org/issue3550 georg.brandl uuid - exception on uuid3/uuid5 1 days http://bugs.python.org/issue3552 loewis patch "2to3 -l" doesn't work when installed in /opt 1 days http://bugs.python.org/issue3553 benjamin.peterson patch Segfault in sha1 0 days http://bugs.python.org/issue3557 loewis patch Python code.interact() and UTF-8 locale 1063 days http://bugs.python.org/issue1288615 haypo patch Tkinter.Menu.delete doesn't delete command of entry 1015 days http://bugs.python.org/issue1342811 schuppenies patch Top Issues Most Discussed (10) ______________________________ 35 urllib.quote and unquote - Unicode issues 40 days open http://bugs.python.org/issue3300 15 bytearrays are not thread safe 56 days closed http://bugs.python.org/issue3139 13 bytes.tohex method 6 days open http://bugs.python.org/issue3532 11 locale.getpreferredencoding() gives bus error on Mac OS X 10.4. 31 days open http://bugs.python.org/issue3362 9 Array pickling exposes internal memory representation of elemen 150 days open http://bugs.python.org/issue2389 7 Building a Win32 binary installer crashes 55 days open http://bugs.python.org/issue3160 6 mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf 1 days closed http://bugs.python.org/issue3533 6 file read preallocs 'size' bytes which can cause memory problem 7 days open http://bugs.python.org/issue3531 5 Python turning off assertions (Windows) 2 days closed http://bugs.python.org/issue3545 5 zipfile has problem reading zip files over 2GB 5 days open http://bugs.python.org/issue3535 From yanagisawa at csg.is.titech.ac.jp Sat Aug 16 12:24:22 2008 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Sat, 16 Aug 2008 19:24:22 +0900 Subject: [Python-Dev] Implementation of Camellia block cipher for Python Cryptography Toolkit. Message-ID: <48A6AAD6.6020705@csg.is.titech.ac.jp> Hi, I am afraid that here is the right place to say but I implemented a patch to add support for Camellia block cipher to Python Cryptography Toolkit (aka. pycrypto). Camellia is one of the approved encryption methods by European Union (one of the finalist of NESSIE) and has specified in several RFCs. It is also included in some open source softwares such as Linux, OpenSSL, Firefox 3, and so on. I put the patch at: http://www.csg.is.titech.ac.jp/~yanagisawa/Sites/text/camellia/pycrypto-2.0.1.patch in http://www.csg.is.titech.ac.jp/~yanagisawa/Sites/text/camellia-e.html Will you please review and test it? I hope pycrypto will include the patch. Thank you in advance, -- Yoshisato Yanagisawa From martin at v.loewis.de Sat Aug 16 13:10:28 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 16 Aug 2008 13:10:28 +0200 Subject: [Python-Dev] Implementation of Camellia block cipher for Python Cryptography Toolkit. In-Reply-To: <48A6AAD6.6020705@csg.is.titech.ac.jp> References: <48A6AAD6.6020705@csg.is.titech.ac.jp> Message-ID: <48A6B5A4.5020205@v.loewis.de> > Will you please review and test it? > I hope pycrypto will include the patch. Dear Yoshisato, python-dev is not the right place - we deal with the core Python distribution only. OTOH, amk.ca is probably a good place; you might also consider posting it to the Python-Crypto mailing list (http://listserv.surfnet.nl/archives/python-crypto.html) The best place for contributions is probably the pycrypto patches tracker, at http://sourceforge.net/projects/pycrypto http://sourceforge.net/tracker/?group_id=20937&atid=320937 Regards, Martin From yanagisawa at csg.is.titech.ac.jp Sat Aug 16 14:23:43 2008 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Sat, 16 Aug 2008 21:23:43 +0900 Subject: [Python-Dev] Implementation of Camellia block cipher for Python Cryptography Toolkit. In-Reply-To: <48A6B5A4.5020205@v.loewis.de> References: <48A6AAD6.6020705@csg.is.titech.ac.jp> <48A6B5A4.5020205@v.loewis.de> Message-ID: <48A6C6CF.5090703@csg.is.titech.ac.jp> > python-dev is not the right place - we deal with the core > Python distribution only. OTOH, amk.ca is probably a good I am sorry to my send email to wrong place, and thank you for letting me know the right place. I will send my email to the python-crypto mailing list, and will also post my patch to the tracker. Thank you, -- Yoshisato Yanagisawa From facundobatista at gmail.com Sat Aug 16 15:43:28 2008 From: facundobatista at gmail.com (Facundo Batista) Date: Sat, 16 Aug 2008 10:43:28 -0300 Subject: [Python-Dev] Memory tests in Unicode Message-ID: The test_raiseMemError() in test_unicode.py is complicating me the regression tests: tries to use all the memory in my system, which starts to swap as crazy, and almost freezes everything. When the test finishes (always pass ok), I have all the memory flushed so it take a few seconds to go back to the normal system. I told myself that this test should run only in some special cases, but didn't find any flag in regrtest.py (like "largefile", or "network"), to put this test under. Are you having also this issue? Do you think that it should run not *always*? It's ok if I add a flag like "memory" that will hold "Tests that use large amount of memory. Normally these tests take long to run because use all your memory and make the system swap"? Thank you!! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From facundobatista at gmail.com Sat Aug 16 16:04:24 2008 From: facundobatista at gmail.com (Facundo Batista) Date: Sat, 16 Aug 2008 11:04:24 -0300 Subject: [Python-Dev] parse_qs and parse_qsl functions Message-ID: Hi! The issue 600362 has two patches (one for 2.6 and the other for 3.0) that are ready to commit (with a small change in the docs). This patches relocates the parse_qs and parse_qsl functions into the urlparse module (urllib.parse in 3k), bringing them from the cgi one. For backward compatibility, those functions are also accessible from the cgi module, but in the documentation says that the function was moved, and you should use it from the urlparse one. So, we don't have *any* change in the behaviour towards the final user. Two questions: - It's ok to do this now or we should wait for 3.1/2.7? - Should we add a deprecation warning in the cgi module for this functions? I propose to commit this now, but leave a deprecation warning for the next release. Thanks!! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From ncoghlan at gmail.com Sat Aug 16 16:44:50 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 17 Aug 2008 00:44:50 +1000 Subject: [Python-Dev] Memory tests in Unicode In-Reply-To: References: Message-ID: <48A6E7E2.2050206@gmail.com> Facundo Batista wrote: > The test_raiseMemError() in test_unicode.py is complicating me the > regression tests: tries to use all the memory in my system, which > starts to swap as crazy, and almost freezes everything. When the test > finishes (always pass ok), I have all the memory flushed so it take a > few seconds to go back to the normal system. > > I told myself that this test should run only in some special cases, > but didn't find any flag in regrtest.py (like "largefile", or > "network"), to put this test under. > > Are you having also this issue? Do you think that it should run not *always*? > > It's ok if I add a flag like "memory" that will hold "Tests that use > large amount of memory. Normally these tests take long to run because > use all your memory and make the system swap"? I asked a similar question the other day, so a definite +1 from me. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From victor.stinner at haypocalc.com Sat Aug 16 17:33:10 2008 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Sat, 16 Aug 2008 17:33:10 +0200 Subject: [Python-Dev] Memory tests in Unicode In-Reply-To: References: Message-ID: <200808161733.10992.victor.stinner@haypocalc.com> Hi, Le Saturday 16 August 2008 15:43:28 Facundo Batista, vous avez ?crit?: > The test_raiseMemError() in test_unicode.py is complicating me the > regression tests: tries to use all the memory in my system, which > starts to swap as crazy, and almost freezes everything. On UNIX, it's possible to limit a process memory using RLIMIT_AS: from resource import getrlimit, setrlimit, RLIMIT_AS def limitMemory(soft): try: old_soft, hard = getrlimit(RLIMIT_AS) if old_soft != -1: soft = min(soft, old_soft) except ValueError: hard = -1 setrlimit(RLIMIT_AS, (soft, hard)) Values are in bytes. So it's possible to get MemoryError without using the whole system memory. Victor From solipsis at pitrou.net Sat Aug 16 17:50:34 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 16 Aug 2008 15:50:34 +0000 (UTC) Subject: [Python-Dev] Memory tests in Unicode References: Message-ID: Facundo Batista gmail.com> writes: > > The test_raiseMemError() in test_unicode.py is complicating me the > regression tests: tries to use all the memory in my system, which > starts to swap as crazy, and almost freezes everything. When the test > finishes (always pass ok), I have all the memory flushed so it take a > few seconds to go back to the normal system. If the test does allocate the very large string, it means MemoryError isn't raised, which defeats the purpose of the test. I think that: u"a" * (sys.maxint // 2 - 100) should be replaced with: u"a" * (sys.maxsize - 100) The latter raises MemoryError reliably here, while the former doesn't. An assertRaises could also be used in place of the try/except, it would ensure the test does exercise what it is meant to exercise. Regards Antoine. From facundobatista at gmail.com Sat Aug 16 18:01:33 2008 From: facundobatista at gmail.com (Facundo Batista) Date: Sat, 16 Aug 2008 13:01:33 -0300 Subject: [Python-Dev] Memory tests in Unicode In-Reply-To: References: Message-ID: 2008/8/16 Antoine Pitrou : > If the test does allocate the very large string, it means MemoryError isn't > raised, which defeats the purpose of the test. I do *not* want to remove the test. I just want to execute it *only* when I run "-u all" or "-u memory", not everytime I run the regression tests. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From pmaupin at gmail.com Sat Aug 16 18:05:12 2008 From: pmaupin at gmail.com (Patrick Maupin) Date: Sat, 16 Aug 2008 11:05:12 -0500 Subject: [Python-Dev] eval() accepts compiled 'exec' statements Message-ID: This may or may not be relevant to 2.6 or 3.0 (because I don't have those handy at the moment), but on 2.5 and earlier: Python 2.5.2 (r252:60911, May 7 2008, 15:19:09) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print eval(compile('print "It works"\n', '', 'exec')) It works None >>> Personally, I'm absolutely fine with this (because I have a use case, naturally), but eval() does work differently for compiled vs non-compiled objects, and this behavior doesn't match what the doc at http://docs.python.org/lib/built-in-funcs.html says, namely "This function can also be used to execute arbitrary code objects (such as those created by compile()). In this case pass a code object instead of a string. The code object must have been compiled passing 'eval' as the kind argument." That doc statement is, itself, contradictory. How can it be an "arbitrary code object" if it must have been compiled using 'eval'? Perhaps all that is meant is "In order to return a result other than None to eval's caller, the code object must have been compiled passing 'eval' as the kind argument." So, either the code or the doc should be fixed. I would vote +1 for fixing the doc to match the code, but then I'm the sort of dysfunctional programmer who sometimes has a use-case for expressions with side-effects. Thanks, Pat From exarkun at divmod.com Sat Aug 16 18:11:20 2008 From: exarkun at divmod.com (Jean-Paul Calderone) Date: Sat, 16 Aug 2008 12:11:20 -0400 Subject: [Python-Dev] Memory tests in Unicode In-Reply-To: Message-ID: <20080816161120.29191.622897079.divmod.quotient.15255@ohm> On Sat, 16 Aug 2008 13:01:33 -0300, Facundo Batista wrote: >2008/8/16 Antoine Pitrou : > >> If the test does allocate the very large string, it means MemoryError isn't >> raised, which defeats the purpose of the test. > >I do *not* want to remove the test. Antoine wasn't suggesting removing it. He's suggesting that the test is not accomplishing its goal if the "except" suite isn't executed, and so the test should be changed to make this failure noticable. Jean-Paul From solipsis at pitrou.net Sat Aug 16 18:12:39 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 16 Aug 2008 16:12:39 +0000 (UTC) Subject: [Python-Dev] Memory tests in Unicode References: Message-ID: Facundo Batista gmail.com> writes: > > I do *not* want to remove the test. You misunderstood my remark. If the test takes a lot of time and eats a lot of memory, it's precisely because the MemoryError isn't raised; and the test needs MemoryError to be raised in order to be meaningful. I was proposing a way of fixing the test so that the MemoryError is raised, which would also stop it from taking a lot of time. Regards Antoine. From martin at v.loewis.de Sat Aug 16 18:36:56 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 16 Aug 2008 18:36:56 +0200 Subject: [Python-Dev] Memory tests in Unicode In-Reply-To: References: Message-ID: <48A70228.8030907@v.loewis.de> > Are you having also this issue? Do you think that it should run not *always*? See bug http://bugs.python.org/issue3556 If no solution is forthcoming quickly, I recommend to remove/disable the test. Regards, Martin From facundobatista at gmail.com Sat Aug 16 21:34:54 2008 From: facundobatista at gmail.com (Facundo Batista) Date: Sat, 16 Aug 2008 16:34:54 -0300 Subject: [Python-Dev] Memory tests in Unicode In-Reply-To: <48A70228.8030907@v.loewis.de> References: <48A70228.8030907@v.loewis.de> Message-ID: 2008/8/16 "Martin v. L?wis" : > See bug http://bugs.python.org/issue3556 > > If no solution is forthcoming quickly, I recommend to remove/disable the > test. The Antoine patch works ok for me, and solves the whole issue. I'm on linux, if somebody can give it a try in another platform, we should commit it ASAP... Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From tjreedy at udel.edu Sat Aug 16 21:50:23 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 16 Aug 2008 15:50:23 -0400 Subject: [Python-Dev] Memory tests in Unicode In-Reply-To: References: Message-ID: Antoine Pitrou wrote: > Facundo Batista gmail.com> writes: >> The test_raiseMemError() in test_unicode.py is complicating me the >> regression tests: tries to use all the memory in my system, which >> starts to swap as crazy, and almost freezes everything. When the test >> finishes (always pass ok), I have all the memory flushed so it take a >> few seconds to go back to the normal system. > > If the test does allocate the very large string, it means MemoryError isn't > raised, which defeats the purpose of the test. > I think that: > u"a" * (sys.maxint // 2 - 100) > should be replaced with: > u"a" * (sys.maxsize - 100) > The latter raises MemoryError reliably here, while the former doesn't. In 3.0, sys.maxint is gone, only sys.maxsize remains, so that some change must have been made for 3.0. Just checked: in 3.0b2 test_unicode.py has no test_raisexxx(). > An assertRaises could also be used in place of the try/except, it would ensure > the test does exercise what it is meant to exercise. From brett at python.org Sat Aug 16 21:52:04 2008 From: brett at python.org (Brett Cannon) Date: Sat, 16 Aug 2008 12:52:04 -0700 Subject: [Python-Dev] parse_qs and parse_qsl functions In-Reply-To: References: Message-ID: On Sat, Aug 16, 2008 at 7:04 AM, Facundo Batista wrote: > Hi! > > The issue 600362 has two patches (one for 2.6 and the other for 3.0) > that are ready to commit (with a small change in the docs). This > patches relocates the parse_qs and parse_qsl functions into the > urlparse module (urllib.parse in 3k), bringing them from the cgi one. > > For backward compatibility, those functions are also accessible from > the cgi module, but in the documentation says that the function was > moved, and you should use it from the urlparse one. > > So, we don't have *any* change in the behaviour towards the final user. > > Two questions: > > - It's ok to do this now or we should wait for 3.1/2.7? > > - Should we add a deprecation warning in the cgi module for this functions? > > I propose to commit this now, but leave a deprecation warning for the > next release. > Obviously Barry's call, but I think it's fine to do what you are proposing. -Brett From tjreedy at udel.edu Sat Aug 16 22:45:32 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 16 Aug 2008 16:45:32 -0400 Subject: [Python-Dev] eval() accepts compiled 'exec' statements In-Reply-To: References: Message-ID: Patrick Maupin wrote: > This may or may not be relevant to 2.6 or 3.0 (because I don't have > those handy at the moment), but on 2.5 and earlier: > > Python 2.5.2 (r252:60911, May 7 2008, 15:19:09) > [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> print eval(compile('print "It works"\n', '', 'exec')) > It works > None In 3.0b2, print( eval(compile('print( "It works")\n', '', 'exec'))) does the same thing. So does print( exec(compile('print( "It works")\n', '', 'exec'))) and I presume the exec statement would in 2.x. > Personally, I'm absolutely fine with this (because I have a use case, > naturally), The only possible use I can think of would be is you are eval-ing mixed-kind code objects: def eval_and_go(cobj): # cobj = code object of whatever kind x = eval(cobj) if x is not None: # was not side-effect only return g(x) else: return None > but eval() does work differently for compiled vs > non-compiled objects, and this behavior doesn't match what the doc at > http://docs.python.org/lib/built-in-funcs.html says, namely "This > function can also be used to execute arbitrary code objects (such as > those created by compile()). In this case pass a code object instead > of a string. The code object must have been compiled passing 'eval' as > the kind argument." > > That doc statement is, itself, contradictory. How can it be an > "arbitrary code object" if it must have been compiled using 'eval'? > Perhaps all that is meant is "In order to return a result other than > None to eval's caller, the code object must have been compiled > passing 'eval' as the kind argument." > > So, either the code or the doc should be fixed. I would vote +1 for > fixing the doc to match the code, but then I'm the sort of > dysfunctional programmer who sometimes has a use-case for expressions > with side-effects. I filed a condensed version of this report, with my suggested added text, as http://bugs.python.org/issue3569 tjr From brett at python.org Sun Aug 17 03:34:43 2008 From: brett at python.org (Brett Cannon) Date: Sat, 16 Aug 2008 18:34:43 -0700 Subject: [Python-Dev] Where are universal newlines handled in the parser/compiler? Message-ID: If you import a module that uses '\r\n' line endings, Python does the right thing. But if you read in the bytes for the same file and then pass it to compile() you get an unhelpful syntax error pointing at a blank line. Normally I would say one should just open the source file as 'r' instead of 'rb', but with source code that does not work well as their can be a source encoding set. Lib/test/test_pep263.py is the perfect example of this; Windows newlines with a koi8-r encoding. What I would like to do is get compile() to work properly with a bytes stream just as if Python itself was handling the compilation through import and from a file directly. But before I try to dig into the parser to figure out where the translation of newlines occurs (or where the translation option is set), I thought I would ask to see if anyone just happened to know (I have already spent a few hours figuring out why Latin-1 encodings were not working with compile() so I don't want to go diving into the maze of function calls in the parser again). -Brett From musiccomposition at gmail.com Sun Aug 17 03:39:50 2008 From: musiccomposition at gmail.com (Benjamin Peterson) Date: Sat, 16 Aug 2008 20:39:50 -0500 Subject: [Python-Dev] Where are universal newlines handled in the parser/compiler? In-Reply-To: References: Message-ID: <1afaf6160808161839o92b03fdw6a57bef0eb5c505b@mail.gmail.com> On Sat, Aug 16, 2008 at 8:34 PM, Brett Cannon wrote: > If you import a module that uses '\r\n' line endings, Python does the > right thing. But if you read in the bytes for the same file and then > pass it to compile() you get an unhelpful syntax error pointing at a > blank line. > > Normally I would say one should just open the source file as 'r' > instead of 'rb', but with source code that does not work well as their > can be a source encoding set. Lib/test/test_pep263.py is the perfect > example of this; Windows newlines with a koi8-r encoding. > > What I would like to do is get compile() to work properly with a bytes > stream just as if Python itself was handling the compilation through > import and from a file directly. But before I try to dig into the > parser to figure out where the translation of newlines occurs (or > where the translation option is set), I thought I would ask to see if > anyone just happened to know (I have already spent a few hours > figuring out why Latin-1 encodings were not working with compile() so > I don't want to go diving into the maze of function calls in the > parser again). Have a look at tok_nextc in Parser/tokenizer.c. > > -Brett > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." From sarvi at cisco.com Sun Aug 17 12:52:22 2008 From: sarvi at cisco.com (Saravanan Shanmugham (sarvi)) Date: Sun, 17 Aug 2008 03:52:22 -0700 Subject: [Python-Dev] A Testing language Construct that could also be a Distributed programming construct - How can this be done in Python Message-ID: I am using Python as a test language and wondering how best to represent what is shown below in TTCN-3 TTCN-3, a testing domain specific language has a construct that looks like below Its trying to send a request and define 3 alternative outcomes/events. web_port.send("http://www.googe.com/") resonseTimer.start(300) alt { [] web_port.receive("something") { responseTimer.stop; setverdict(pass); } [] web_port.receive("somethingelse") { responseTimer.stop; setverdict(fail); } [] responseTimer.timeout { setverdict(fail); } } I am trying to do something similar with python and find myself in a fix as to how to code it clean. I can't do it with if ...elseif ... elseif .... else unless I wrap it in an event loop. Since otherwise it means that each condition function will be executed once. While what we are looking for is way to define potential events that can happen and a particular segment of code to executed for a specific event match The closest thing that I can do is something like this, assuming I implement the doalternatives method to take a list of function, code pairs. It would take the list of function-name, parameters list and run it in an event loop or in separate threads as the need may be to match one of them. When one of them matches it would be expected to run the code block associated with it. Which would get me the same behaviour. doalternatives( [web_port.receive,"something"], "responseTimer.stop; setverdict(pass);" [web_port.receive,"somethingelse"], "responseTimer.stop; setverdict(fail);" [responseTimer.timeout], "responseTimer.stop; setverdict(pass);" } The above looks pretty ok. Except that I have to define the python code block as a string. It would be nice if there was a python language construct that would allow me to define a block of python code that can be passed as a code object into a function. That would serve the above purpose as well as cases for distributed or parallel programming as well. A construct like invoke doalternatives with: param [web_port.receive,"something"] param: responseTimer.stop() setverdict(pass) param [web_port.receive,"something else"] param: responseTimer.stop() setverdict(fail) param [responseTimer.timeout] param: responseTimer.stop() setverdict(pass) I am sure we can do better than what I have proposed above. But the general idea is to be able to define and pass code segments as code objects around a function invocation and and pass the code objects as parameters into the invoked function. What do people think? Is there any existing construct that I might be missing to achieve the above? Sarvi -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sun Aug 17 21:10:37 2008 From: brett at python.org (Brett Cannon) Date: Sun, 17 Aug 2008 12:10:37 -0700 Subject: [Python-Dev] A Testing language Construct that could also be a Distributed programming construct - How can this be done in Python In-Reply-To: References: Message-ID: This is the wrong mailing list to ask this question; python-dev is for discussing the design of the language. General help questions should go to comp.lang.python. On Sun, Aug 17, 2008 at 3:52 AM, Saravanan Shanmugham (sarvi) wrote: > I am using Python as a test language and wondering how best to represent > what is shown below in TTCN-3 > TTCN-3, a testing domain specific language has a construct that looks like > below Its trying to send a request and define 3 alternative > outcomes/events. > > web_port.send("http://www.googe.com/") > resonseTimer.start(300) > alt { > [] web_port.receive("something") { > responseTimer.stop; > setverdict(pass); > } > [] web_port.receive("somethingelse") { > responseTimer.stop; > setverdict(fail); > } > [] responseTimer.timeout { > setverdict(fail); > } > } > > I am trying to do something similar with python and find myself in a fix as > to how to code it clean. > > I can't do it with > if ...elseif ... elseif .... else > unless I wrap it in an event loop. > Since otherwise it means that each condition function will be executed > once. While what we are looking for is way to define potential events that > can happen and a particular segment of code to executed for a specific event > match > > The closest thing that I can do is something like this, assuming I implement > the doalternatives method to take a list of function, code pairs. It would > take the list of function-name, parameters list and run it in an event loop > or in separate threads as the need may be to match one of them. > When one of them matches it would be expected to run the code block > associated with it. Which would get me the same behaviour. > > doalternatives( > [web_port.receive,"something"], > "responseTimer.stop; > setverdict(pass);" > [web_port.receive,"somethingelse"], > "responseTimer.stop; > setverdict(fail);" > [responseTimer.timeout], > "responseTimer.stop; > setverdict(pass);" > } > > The above looks pretty ok. Except that I have to define the python code > block as a string. > It would be nice if there was a python language construct that would allow > me to define a block of python code that can be passed as a code object into > a function. > > That would serve the above purpose as well as cases for distributed or > parallel programming as well. > > A construct like > invoke doalternatives with: > param [web_port.receive,"something"] > param: > responseTimer.stop() > setverdict(pass) > param [web_port.receive,"something else"] > param: > responseTimer.stop() > setverdict(fail) > param [responseTimer.timeout] > param: > responseTimer.stop() > setverdict(pass) > > I am sure we can do better than what I have proposed above. But the general > idea is to be able to define and pass code segments as code objects around a > function invocation and and pass the code objects as parameters into the > invoked function. > > What do people think? Is there any existing construct that I might be > missing to achieve the above? > > Sarvi > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > > From brett at python.org Sun Aug 17 21:10:37 2008 From: brett at python.org (Brett Cannon) Date: Sun, 17 Aug 2008 12:10:37 -0700 Subject: [Python-Dev] A Testing language Construct that could also be a Distributed programming construct - How can this be done in Python In-Reply-To: References: Message-ID: This is the wrong mailing list to ask this question; python-dev is for discussing the design of the language. General help questions should go to comp.lang.python. On Sun, Aug 17, 2008 at 3:52 AM, Saravanan Shanmugham (sarvi) wrote: > I am using Python as a test language and wondering how best to represent > what is shown below in TTCN-3 > TTCN-3, a testing domain specific language has a construct that looks like > below Its trying to send a request and define 3 alternative > outcomes/events. > > web_port.send("http://www.googe.com/") > resonseTimer.start(300) > alt { > [] web_port.receive("something") { > responseTimer.stop; > setverdict(pass); > } > [] web_port.receive("somethingelse") { > responseTimer.stop; > setverdict(fail); > } > [] responseTimer.timeout { > setverdict(fail); > } > } > > I am trying to do something similar with python and find myself in a fix as > to how to code it clean. > > I can't do it with > if ...elseif ... elseif .... else > unless I wrap it in an event loop. > Since otherwise it means that each condition function will be executed > once. While what we are looking for is way to define potential events that > can happen and a particular segment of code to executed for a specific event > match > > The closest thing that I can do is something like this, assuming I implement > the doalternatives method to take a list of function, code pairs. It would > take the list of function-name, parameters list and run it in an event loop > or in separate threads as the need may be to match one of them. > When one of them matches it would be expected to run the code block > associated with it. Which would get me the same behaviour. > > doalternatives( > [web_port.receive,"something"], > "responseTimer.stop; > setverdict(pass);" > [web_port.receive,"somethingelse"], > "responseTimer.stop; > setverdict(fail);" > [responseTimer.timeout], > "responseTimer.stop; > setverdict(pass);" > } > > The above looks pretty ok. Except that I have to define the python code > block as a string. > It would be nice if there was a python language construct that would allow > me to define a block of python code that can be passed as a code object into > a function. > > That would serve the above purpose as well as cases for distributed or > parallel programming as well. > > A construct like > invoke doalternatives with: > param [web_port.receive,"something"] > param: > responseTimer.stop() > setverdict(pass) > param [web_port.receive,"something else"] > param: > responseTimer.stop() > setverdict(fail) > param [responseTimer.timeout] > param: > responseTimer.stop() > setverdict(pass) > > I am sure we can do better than what I have proposed above. But the general > idea is to be able to define and pass code segments as code objects around a > function invocation and and pass the code objects as parameters into the > invoked function. > > What do people think? Is there any existing construct that I might be > missing to achieve the above? > > Sarvi > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > > From brett at python.org Sun Aug 17 22:19:25 2008 From: brett at python.org (Brett Cannon) Date: Sun, 17 Aug 2008 13:19:25 -0700 Subject: [Python-Dev] Think a dead import finding script would be handy? Message-ID: After Christian mentioned how we could speed up interpreter start-up by removing some dead imports he found, I decided to write up a quick script that generates the AST for a source file and (very roughly) tries to find imports that are never used. People think it's worth tossing into Tools, even if it is kind of rough? Otherwise I might toss it into the sandbox or make a quick Google code project out of it. Regardless, one interesting side-effect of the script is that beyond finding some extraneous imports in various places, it also found some holes in __all__. I have the script look for the definition of __all__ and consider an import used if it is listed there. -Brett From g.brandl at gmx.net Sun Aug 17 22:40:34 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Sun, 17 Aug 2008 22:40:34 +0200 Subject: [Python-Dev] Think a dead import finding script would be handy? In-Reply-To: References: Message-ID: Brett Cannon schrieb: > After Christian mentioned how we could speed up interpreter start-up > by removing some dead imports he found, I decided to write up a quick > script that generates the AST for a source file and (very roughly) > tries to find imports that are never used. People think it's worth > tossing into Tools, even if it is kind of rough? Otherwise I might > toss it into the sandbox or make a quick Google code project out of > it. > > Regardless, one interesting side-effect of the script is that beyond > finding some extraneous imports in various places, it also found some > holes in __all__. I have the script look for the definition of __all__ > and consider an import used if it is listed there. pylint already finds unused imports. It finds tons of other, relatively useless, stuff in the default configuration, but I'm sure it can be coaxed into only showing unused imports too. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From musiccomposition at gmail.com Sun Aug 17 23:00:17 2008 From: musiccomposition at gmail.com (Benjamin Peterson) Date: Sun, 17 Aug 2008 16:00:17 -0500 Subject: [Python-Dev] no-op symtable methods Message-ID: <1afaf6160808171400ya314c16pa87a9dcaa0bc54fb@mail.gmail.com> I've been working on getting the symtable module back in working order. However, there are some methods that aren't functioning as they advertise because of changes in the compiler internally. I doubt that any cares or has noticed because I think it's been broken for several releases now. :) These methods are: Symbol.is_in_tuple() Symbol.is_vararg() Symbol.is_keyword() Anyway, if there are no objects, I will deprecate the functions in 2.6 and kill them off for good in 3.0. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." From pogonyshev at gmx.net Sun Aug 17 23:16:24 2008 From: pogonyshev at gmx.net (Paul Pogonyshev) Date: Mon, 18 Aug 2008 00:16:24 +0300 Subject: [Python-Dev] PEP-3121 and PyType_Copy Message-ID: <200808180016.24958.pogonyshev@gmx.net> Hi, In the mailing list archive I see a message that this PEP was implemented, dated June 10. However, while everything else PEP describes does seem to be in SVN, I cannot find PyType_Copy(). Is this function still planned for Python 3000, or are there any simple alternatives? Or are modules just supposed to share types across interpreters? Thanks, Paul From lists at cheimes.de Sun Aug 17 23:12:52 2008 From: lists at cheimes.de (Christian Heimes) Date: Sun, 17 Aug 2008 23:12:52 +0200 Subject: [Python-Dev] Think a dead import finding script would be handy? In-Reply-To: References: Message-ID: <48A89454.8030004@cheimes.de> Brett Cannon wrote: > After Christian mentioned how we could speed up interpreter start-up > by removing some dead imports he found, I decided to write up a quick > script that generates the AST for a source file and (very roughly) > tries to find imports that are never used. People think it's worth > tossing into Tools, even if it is kind of rough? Otherwise I might > toss it into the sandbox or make a quick Google code project out of > it. > > Regardless, one interesting side-effect of the script is that beyond > finding some extraneous imports in various places, it also found some > holes in __all__. I have the script look for the definition of __all__ > and consider an import used if it is listed there. Zope 3 has various tools for sorting imports or checking for unused imports. See http://svn.zope.org/Zope3/trunk/utilities/ Python 3.0 currently imports 25 modules on startup, Python 2.6 just 14: ./python -S -c "import sys; print(list(sorted(sys.modules)), len(sys.modules))" ['__main__', '_abcoll', '_codecs', '_fileio', '_thread', '_weakref', '_weakrefset', 'abc', 'builtins', 'codecs', 'copyreg', 'encodings', 'encodings.aliases', 'encodings.latin_1', 'encodings.utf_8', 'errno', 'genericpath', 'io', 'os', 'os.path', 'posix', 'posixpath', 'signal', 'stat', 'sys', 'zipimport'] 26 _abcoll os.envirion uses _abcoll.MutableMapping _weakref + _weakrefset imported for abc abc imported for io.IOBase copyreg imported by os to register some pickle handlers. Could be removed by placing the code into copyreg instead. encodings.* imported early to avoid various bootstrapping issues (IIRC) encodings.aliases: Could be removing by delaying the import until search_function() is called the first time errno, genericpath, posix, posixpath, stat: import by os and os.path stat: Could probably be replaced by a simple and faster C implementation in posixmodule.c to spare the import signal: I'm not sure why the module is loaded at all. I think we can get rid of copyreg and encodings.aliases easily. Christian From brett at python.org Mon Aug 18 00:04:58 2008 From: brett at python.org (Brett Cannon) Date: Sun, 17 Aug 2008 15:04:58 -0700 Subject: [Python-Dev] Think a dead import finding script would be handy? In-Reply-To: References: Message-ID: On Sun, Aug 17, 2008 at 1:40 PM, Georg Brandl wrote: > Brett Cannon schrieb: >> After Christian mentioned how we could speed up interpreter start-up >> by removing some dead imports he found, I decided to write up a quick >> script that generates the AST for a source file and (very roughly) >> tries to find imports that are never used. People think it's worth >> tossing into Tools, even if it is kind of rough? Otherwise I might >> toss it into the sandbox or make a quick Google code project out of >> it. >> >> Regardless, one interesting side-effect of the script is that beyond >> finding some extraneous imports in various places, it also found some >> holes in __all__. I have the script look for the definition of __all__ >> and consider an import used if it is listed there. > > pylint already finds unused imports. It finds tons of other, relatively > useless, stuff in the default configuration, but I'm sure it can be > coaxed into only showing unused imports too. > Does anyone ever run pylint over the stdlib on occasion? -Brett From exarkun at divmod.com Mon Aug 18 01:09:53 2008 From: exarkun at divmod.com (Jean-Paul Calderone) Date: Sun, 17 Aug 2008 19:09:53 -0400 Subject: [Python-Dev] Think a dead import finding script would be handy? In-Reply-To: Message-ID: <20080817230953.29191.1782754713.divmod.quotient.15855@ohm> On Sun, 17 Aug 2008 15:04:58 -0700, Brett Cannon wrote: >On Sun, Aug 17, 2008 at 1:40 PM, Georg Brandl wrote: >> Brett Cannon schrieb: >>> After Christian mentioned how we could speed up interpreter start-up >>> by removing some dead imports he found, I decided to write up a quick >>> script that generates the AST for a source file and (very roughly) >>> tries to find imports that are never used. People think it's worth >>> tossing into Tools, even if it is kind of rough? Otherwise I might >>> toss it into the sandbox or make a quick Google code project out of >>> it. >>> >>> Regardless, one interesting side-effect of the script is that beyond >>> finding some extraneous imports in various places, it also found some >>> holes in __all__. I have the script look for the definition of __all__ >>> and consider an import used if it is listed there. >> >> pylint already finds unused imports. It finds tons of other, relatively >> useless, stuff in the default configuration, but I'm sure it can be >> coaxed into only showing unused imports too. >> > >Does anyone ever run pylint over the stdlib on occasion? > Buildbot includes a pyflakes step. Jean-Paul From nnorwitz at gmail.com Mon Aug 18 03:38:46 2008 From: nnorwitz at gmail.com (Neal Norwitz) Date: Sun, 17 Aug 2008 18:38:46 -0700 Subject: [Python-Dev] Think a dead import finding script would be handy? In-Reply-To: References: Message-ID: On Sun, Aug 17, 2008 at 3:04 PM, Brett Cannon wrote: > On Sun, Aug 17, 2008 at 1:40 PM, Georg Brandl wrote: >> Brett Cannon schrieb: >>> After Christian mentioned how we could speed up interpreter start-up >>> by removing some dead imports he found, I decided to write up a quick >>> script that generates the AST for a source file and (very roughly) >>> tries to find imports that are never used. People think it's worth >>> tossing into Tools, even if it is kind of rough? Otherwise I might >>> toss it into the sandbox or make a quick Google code project out of >>> it. >>> >>> Regardless, one interesting side-effect of the script is that beyond >>> finding some extraneous imports in various places, it also found some >>> holes in __all__. I have the script look for the definition of __all__ >>> and consider an import used if it is listed there. >> >> pylint already finds unused imports. It finds tons of other, relatively >> useless, stuff in the default configuration, but I'm sure it can be >> coaxed into only showing unused imports too. >> > > Does anyone ever run pylint over the stdlib on occasion? I usually run pychecker (which also finds unused imports and a whole lot more) before releases. I typically wait for things to settle down (ie, well into beta). n From gregor.lingl at aon.at Mon Aug 18 10:15:45 2008 From: gregor.lingl at aon.at (Gregor Lingl) Date: Mon, 18 Aug 2008 10:15:45 +0200 Subject: [Python-Dev] turtle.Screen- how to implement best a Singleton Message-ID: <48A92FB1.7010201@aon.at> Hi, this posting - concerning the new turtle module - goes to the Python-Dev and Python-3000 lists and to a couple of 'power users' of turtle graphics, hoping to recieve feedback from the developer's point of view as well as from the user's point of view. Currently the implementations of the turtle.Screen class for Python 2.6 and Python 3.0 differ by a 'tiny' detail with an important difference in behaviour. So clearly this has to be resolved before the final release.(The origin of this difference is, that when I ported turtle.py to Python 3.0 I discovered (and 'fixed') what I now consider to be a bug in the 2.6 version.) I'd like to ask you kindly for your advice to achieve an optimal solution. The posting consists of three parts: 1. Exposition of design goals 2. Problem with the implementation 3. How to solve it? Preliminary remark: I've had some discussions on this topic before but I still do not see a clear solution. Moreover I'm well aware of the fact that using the Singleton pattern is controversial. So ... 1. Exposition of design goals ... why use the Singleton design pattern? The turtle module contains a TurtleScreen class, which implements methods to control the drawing area the turtle is (turtles are) drawing on. It's constructor needs a Tkinter Canvas as argument. In order to avoid the need for users to tinker around with Tkinter stuff there is the Screen(TurtleScreen) class, designed to be used by beginners(students, kids,...), particularly in interactive sessions. A (THE (!)) Screen object is essentially a window containing a scrolled canvas, the TurtleScreen. So it's a ressource which should exist only once. It can be constructed in several ways: - implicitely by calling an arbitrary function derived from a Turtle-method, such as forward(100) or by constructing a Turtle such as bob = Turtle() - implicitely by calling an arbitrary function derived from a Screen method, such as bgcolor("red") - explicitely by calling it's constructor such as s = Screen() Anyway this construction should only happen if a Screen object doesn't exist yet. Now for the pending question: What should happen, when s = Screen() is called explicitely and there exists already 'the' Screen object. (i) Clearly s should get a reference to the existing Screen object, but ... (ii) (a)... should s be reinitialized (this is the case now in Python 2.6), or (b)... should s be left untouched (this is the case now in Python 3.0) I, for my part, prefer the latter solution (b). Example: a student, having (interactively) produced some design using some turtle t = Turtle() decides spontaneously to change backgroundcolor. s = Screen(); s.bgcolor("pink") should do this for her - instead of deleting her design and moreover her turtle. To reinitialize the screen she still can use s.clear(). Of course, there are workarounds to achieve the same effect also with solution (a), for instance by assigning s = Screen() *before* drawing anything or by assigning s = t.getscreen(). But imho (which derives itself from my experience as a teacher) solution (b) supports better the oop-view as well as experimenting spontaneously in interactive sessions. 2. Problem with the implementation The task is to derive a Singleton class from a Nonsingleton class (Screen from TurtleScreen). The current implementations of the Screen 'Singleton' both use the Borg idiom. Just for *explaining* the difference between the two versions of class Screen here concisely, I'll use a 'standard' Singleton pattern (roughly equivalent to the Borg idiom): class Spam(object): def __init__(self, s): self.s = s class SingleSpam(Spam): _inst = None def __new__(cls, *args, **kwargs): if cls != type(cls._inst): cls._inst = Spam.__new__(cls, *args, **kwargs) return cls._inst def __init__(self, s): if vars(self): return ###### should this be here??? Spam.__init__(self, s) Shortly, this means that SingleSpam.__init__() acts like an empty method whenever a (the!) SingleSpam object already exists. 3.0 version of Screen acts like this. By contrast 2.6 version of Screen acts as if the butlast line were not there and thus reinitializes the Screen object. 3. How to solve it? Main question: which *behaviour* of the Screen class should be preferred. If 3.0, is it feasible and correct not to call the constructor of the parent class if the object already exists? Additional question: Do you consider the Borg idiom a good solution for this task or should the standard singleton pattern as shown above be preferred. Or would you suggest a solution/an approach different from both? Thanks for your patience, and - in advance - for your assistance Regard, Gregor From kristjan at ccpgames.com Mon Aug 18 13:06:33 2008 From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=) Date: Mon, 18 Aug 2008 11:06:33 +0000 Subject: [Python-Dev] issue 3582 Message-ID: <4E9372E6B2234D4F859320D896059A951011BC6FD0@exchis.ccp.ad.local> Hello there. Yesterday I posted a feature request, http://bugs.python.org/issue3582, along with a patch. It provides platform specifict TLS functions on windows. Implementing it I came across the strange semantics of PyThread_set_key_value(). If a value has been set previously, it will ignore the set. This is most unusual, and I had to make two TLS calls in the NT version to emulate this behaviour. This behaviour is mentioned in pystate.c: The only situation where you can legitimately have more than one thread state for an OS level thread is when there are multiple interpreters, when: a) You shouldn't really be using the PyGILState_ APIs anyway, and: b) The slightly odd way PyThread_set_key_value works (see comments by its implementation) means that the first thread state created for that given OS level thread will "win", which seems reasonable behaviour. */ Now, this seems to be the only place where this is required, but I fail to see how even in this scenario it makes sense. As a) code says, you shouldn't be using the GIL api anyway, and it will undoubtebly create problems elsewhere if sticking the thread state into TLS fails silently. Changing this odd behaviour of PyThread_set_key_value () is trivial and would make it easier to use native TLS functions on other platforms. Any thoughts? K -------------- next part -------------- An HTML attachment was scrubbed... URL: From skip at pobox.com Mon Aug 18 13:08:40 2008 From: skip at pobox.com (skip at pobox.com) Date: Mon, 18 Aug 2008 06:08:40 -0500 Subject: [Python-Dev] Why does httplib import from test_support? Message-ID: <18601.22584.469957.920301@montanaro-dyndns-org.local> Is this new as of the last couple of days? Traceback (most recent call last): File "/Users/skip/tmp/py/mmfold.py", line 182, in sys.exit(main()) File "/Users/skip/tmp/py/mmfold.py", line 95, in main for line in urllib.urlopen(url+"?adminpw=%s" % passwd): File "/Users/skip/local/lib/python2.6/urllib.py", line 87, in urlopen return opener.open(url) File "/Users/skip/local/lib/python2.6/urllib.py", line 203, in open return getattr(self, name)(url) File "/Users/skip/local/lib/python2.6/urllib.py", line 285, in open_http import httplib File "/Users/skip/local/lib/python2.6/httplib.py", line 72, in from test.test_support import catch_warning ImportError: No module named test_support The import statement seems to work from an interactive shell (I have a module named test in the same directory as the main prog, hence the problem), but even if it does work should we be importing stuff from the test package in non-test code? Skip From ncoghlan at gmail.com Mon Aug 18 13:35:25 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 18 Aug 2008 21:35:25 +1000 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: <18601.22584.469957.920301@montanaro-dyndns-org.local> References: <18601.22584.469957.920301@montanaro-dyndns-org.local> Message-ID: <48A95E7D.1010002@gmail.com> skip at pobox.com wrote: > The import statement seems to work from an interactive shell (I have a > module named test in the same directory as the main prog, hence the > problem), but even if it does work should we be importing stuff from the > test package in non-test code? I saw those checkins go by on the checkins list - they have to do with silencing -3 warnings for modules that the stdlib still uses in Python 2.6 for backwards compatibility reasons (but switching to the relevant new approaches in 3.0, thus making the warnings a false alarm). test.test_support.catch_warning is a convenient way to suppress a warning for a small piece of code and then revert the state of the warnings module back to the way it was afterwards. Those imports should probably be guarded with sys.py3kwarn though, with a standard import being used if the command line flag isn't set. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From gregor.lingl at aon.at Mon Aug 18 14:14:33 2008 From: gregor.lingl at aon.at (Gregor Lingl) Date: Mon, 18 Aug 2008 14:14:33 +0200 Subject: [Python-Dev] turtle.Screen- how to implement best a Singleton In-Reply-To: <48A95CC6.9090706@canterburyschool.org> References: <48A92FB1.7010201@aon.at> <48A95CC6.9090706@canterburyschool.org> Message-ID: <48A967A9.3040102@aon.at> Thanks for the feedback, Gregor Vern Ceder schrieb: > Gregor, > > I don't feel authoritative on the correctness/appropriateness of the > implementation, but I do agree completely that behavior b, or what you > have in the 3.0 version, is vastly preferable. > > Cheers, > Vern > > Gregor Lingl wrote: >> Hi, >> >> this posting - concerning the new turtle module - goes to the >> Python-Dev and Python-3000 lists and to a couple of 'power users' of >> turtle graphics, hoping to recieve feedback from the developer's >> point of view as well as from the user's point of view. >> >> Currently the implementations of the turtle.Screen class for Python >> 2.6 and Python 3.0 differ by a 'tiny' detail with an important >> difference in behaviour. So clearly this has to be resolved before >> the final release.(The origin of this difference is, that when I >> ported turtle.py to Python 3.0 I discovered (and 'fixed') what I now >> consider to be a bug in the 2.6 version.) I'd like to ask you kindly >> for your advice to achieve an optimal solution. >> >> The posting consists of three parts: >> 1. Exposition of design goals >> 2. Problem with the implementation 3. How to solve it? >> >> Preliminary remark: I've had some discussions on this topic before >> but I still do not see a clear solution. Moreover I'm well aware of >> the fact that using the Singleton pattern is controversial. So ... >> >> 1. Exposition of design goals >> ... why use the Singleton design pattern? The turtle module contains >> a TurtleScreen class, which implements methods to control the drawing >> area the turtle is (turtles are) drawing on. It's constructor needs a >> Tkinter Canvas as argument. In order to avoid the need for users to >> tinker around with Tkinter stuff there is the Screen(TurtleScreen) >> class, designed to be used by beginners(students, kids,...), >> particularly in interactive sessions. >> >> A (THE (!)) Screen object is essentially a window containing a >> scrolled canvas, the TurtleScreen. So it's a ressource which should >> exist only once. It can be constructed in several ways: >> - implicitely by calling an arbitrary function derived from a >> Turtle-method, such as forward(100) or by constructing a Turtle such >> as bob = Turtle() >> - implicitely by calling an arbitrary function derived from a Screen >> method, such as bgcolor("red") >> - explicitely by calling it's constructor such as s = Screen() >> Anyway this construction should only happen if a Screen object >> doesn't exist yet. >> Now for the pending question: What should happen, when s = Screen() >> is called explicitely and there exists already 'the' Screen object. >> (i) Clearly s should get a reference to the existing Screen object, >> but ... >> (ii) (a)... should s be reinitialized (this is the case now in Python >> 2.6), or >> (b)... should s be left untouched (this is the case now in Python >> 3.0) >> >> I, for my part, prefer the latter solution (b). Example: a student, >> having (interactively) produced some design using some turtle t = >> Turtle() decides spontaneously to change backgroundcolor. s = >> Screen(); s.bgcolor("pink") should do this for her - instead of >> deleting her design and moreover her turtle. To reinitialize the >> screen she still can use s.clear(). >> >> Of course, there are workarounds to achieve the same effect also with >> solution (a), for instance by assigning s = Screen() *before* drawing >> anything or by assigning s = t.getscreen(). But imho (which derives >> itself from my experience as a teacher) solution (b) supports better >> the oop-view as well as experimenting spontaneously in interactive >> sessions. >> >> 2. Problem with the implementation >> The task is to derive a Singleton class from a Nonsingleton class >> (Screen from TurtleScreen). The current implementations of the Screen >> 'Singleton' both use the Borg idiom. Just for *explaining* the >> difference between the two versions of class Screen here concisely, >> I'll use a 'standard' Singleton pattern (roughly equivalent to the >> Borg idiom): >> >> class Spam(object): >> def __init__(self, s): >> self.s = s >> >> class SingleSpam(Spam): >> _inst = None >> def __new__(cls, *args, **kwargs): if cls != >> type(cls._inst): >> cls._inst = Spam.__new__(cls, *args, **kwargs) >> return cls._inst >> def __init__(self, s): >> if vars(self): return ###### should this be here??? >> Spam.__init__(self, s) >> >> Shortly, this means that SingleSpam.__init__() acts like an empty >> method whenever a (the!) SingleSpam object already exists. 3.0 >> version of Screen acts like this. By contrast 2.6 version of Screen >> acts as if the butlast line were not there and thus reinitializes the >> Screen object. >> >> 3. How to solve it? >> >> Main question: which *behaviour* of the Screen class should be >> preferred. If 3.0, is it feasible and correct not to call the >> constructor of the parent class if the object already exists? >> >> Additional question: Do you consider the Borg idiom a good solution >> for this task or should the standard singleton pattern as shown above >> be preferred. Or would you suggest a solution/an approach different >> from both? >> >> Thanks for your patience, and - in advance - for your assistance >> >> Regard, >> Gregor >> >> >> >> > From eric at trueblade.com Mon Aug 18 16:39:35 2008 From: eric at trueblade.com (Eric Smith) Date: Mon, 18 Aug 2008 10:39:35 -0400 Subject: [Python-Dev] optimization required: .format() is much slower than % In-Reply-To: <4840AE6E.40900@trueblade.com> References: <483BD10E.7050600@gmail.com> <483C14D1.1050007@trueblade.com> <483C2535.2040306@trueblade.com> <4840AE6E.40900@trueblade.com> Message-ID: <48A989A7.3090802@trueblade.com> Eric Smith wrote: > Eric Smith wrote: >> Eric Smith wrote: >>> Nick Coghlan wrote: >>>> Secondly, the string % operator appears to have an explicit >>>> optimisation for the 'just return str(self)' case. This optimisation >>>> is missing from the new string format method. >>> >>> I'll see if I can optimize this case. >> >> 3.0, from svn: >> $ ./python.exe -m timeit "'some text with {0}'.format('nothing')" >> 100000 loops, best of 3: 3.14 usec per loop >> >> 3.0, with PyUnicode_ExactCheck, skipping __format__ lookup: >> $ ./python.exe -m timeit "'some text with {0}'.format('nothing')" >> 100000 loops, best of 3: 2.32 usec per loop >> >> I could probably improve this some more, by skipping the creation of >> the object used to describe the format_spec. >> >> Compare with: >> $ ./python.exe -m timeit "'some text with %s' % 'nothing'" >> 1000000 loops, best of 3: 1.37 usec per loop > > r63826 has an optimization when formatting types that are exactly > unicode, long, or float (not subclasses). Unfortunately it's only for > 3.0. For 2.6 it's messier. I'm still pondering what to do with that. > I'll get to it sometime, but maybe after the beta. I finally backported this to 2.6 in r65814. There's a similar 30% speedup for the simplest cases. Unicode optimization is worse than string optimization, because of the way int, long, and float formatters work. This can be fixed, but I'm not sure the gain justifies the effort. I doubt I'll have time to look into this before beta3. Eric. From solipsis at pitrou.net Mon Aug 18 16:48:08 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 18 Aug 2008 14:48:08 +0000 (UTC) Subject: [Python-Dev] optimization required: .format() is much slower than % References: <483BD10E.7050600@gmail.com> <483C14D1.1050007@trueblade.com> <483C2535.2040306@trueblade.com> <4840AE6E.40900@trueblade.com> <48A989A7.3090802@trueblade.com> Message-ID: Eric Smith trueblade.com> writes: > > I finally backported this to 2.6 in r65814. There's a similar 30% > speedup for the simplest cases. Unicode optimization is worse than > string optimization, because of the way int, long, and float formatters > work. This can be fixed, but I'm not sure the gain justifies the > effort. I doubt I'll have time to look into this before beta3. Given the choice, I would think it's more important to further speedup the implementation in 3.0 rather than try to backport the existing speedups to 2.6. In 2.6 the standard formatting facility is still the % operator. (Just my two suboptimal cents) From janssen at parc.com Mon Aug 18 17:34:16 2008 From: janssen at parc.com (Bill Janssen) Date: Mon, 18 Aug 2008 08:34:16 PDT Subject: [Python-Dev] issue 3582 In-Reply-To: <4E9372E6B2234D4F859320D896059A951011BC6FD0@exchis.ccp.ad.local> References: <4E9372E6B2234D4F859320D896059A951011BC6FD0@exchis.ccp.ad.local> Message-ID: <08Aug18.083420pdt."58698"@synergy1.parc.xerox.com> > It provides platform specific TLS functions on windows. In this context, TLS is "thread-local storage". Bill From guido at google.com Mon Aug 18 18:05:45 2008 From: guido at google.com (Guido van Rossum) Date: Mon, 18 Aug 2008 09:05:45 -0700 Subject: [Python-Dev] Should we help pythonmac.org? Message-ID: Does anyone have connections with the owners of pythonmac.org? Apparently they are serving up an ancient version of Python 2.5. The Google App Engine has a minor issue in 2.5 that's solved in 2.5.1, but that is apparently not available from that site. Perhaps we can contribute more recent Mac versions, or provide them directly on python.org? (The Downloads -> Macintosh page points to pythonmac.org, which means lots of All Engine users download this old version.) -- --Guido van Rossum (home: python.org/~guido/) From skip at pobox.com Mon Aug 18 18:33:32 2008 From: skip at pobox.com (skip at pobox.com) Date: Mon, 18 Aug 2008 11:33:32 -0500 Subject: [Python-Dev] Should we help pythonmac.org? In-Reply-To: References: Message-ID: <18601.42076.428829.785059@montanaro-dyndns-org.local> Guido> Does anyone have connections with the owners of pythonmac.org? I believe that's Bob Ippolito (bob at redivi.com - cc'd). Skip Guido> Apparently they are serving up an ancient version of Python Guido> 2.5. The Google App Engine has a minor issue in 2.5 that's solved Guido> in 2.5.1, but that is apparently not available from that Guido> site. Perhaps we can contribute more recent Mac versions, or Guido> provide them directly on python.org? (The Downloads -> Macintosh Guido> page points to pythonmac.org, which means lots of All Engine Guido> users download this old version.) Guido> -- Guido> --Guido van Rossum (home: python.org/~guido/) Guido> _______________________________________________ Guido> Python-Dev mailing list Guido> Python-Dev at python.org Guido> http://mail.python.org/mailman/listinfo/python-dev Guido> Unsubscribe: http://mail.python.org/mailman/options/python-dev/skip%40pobox.com From barry at python.org Mon Aug 18 18:54:16 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 18 Aug 2008 12:54:16 -0400 Subject: [Python-Dev] Should we help pythonmac.org? In-Reply-To: References: Message-ID: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 18, 2008, at 12:05 PM, Guido van Rossum wrote: > Does anyone have connections with the owners of pythonmac.org? > Apparently they are serving up an ancient version of Python 2.5. The > Google App Engine has a minor issue in 2.5 that's solved in 2.5.1, but > that is apparently not available from that site. Perhaps we can > contribute more recent Mac versions, or provide them directly on > python.org? (The Downloads -> Macintosh page points to pythonmac.org, > which means lots of All Engine users download this old version.) I'd be happy to arrange things with a Mac expert to put the Mac binaries on the download site. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKmpOHEjvBPtnXfVAQJNFAQAiQu+ZgeHoi7fzF7NWwqDoP4AAH8UNF5B 6JL74CmJnarhZ40dum3RUz+bEM3Htfik+baMUInCEz+hlOBBbZi9qTyVxTdA9zOg t2/Z/mzl7o/0POyoxAaVcYVBife2FYiNUIfB9AvP7TtUYCJmI2bCTCiBkTO/GLDm 7VBpEF3gNhs= =jIn7 -----END PGP SIGNATURE----- From guido at python.org Mon Aug 18 19:06:12 2008 From: guido at python.org (Guido van Rossum) Date: Mon, 18 Aug 2008 10:06:12 -0700 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: <48A95E7D.1010002@gmail.com> References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> Message-ID: Note that many distros are in the habit of not installing the test package by default. So dependencies outside that package on *anything* in it are a problem. Maybe test_support should be lifted out of the test package? On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan wrote: > skip at pobox.com wrote: >> The import statement seems to work from an interactive shell (I have a >> module named test in the same directory as the main prog, hence the >> problem), but even if it does work should we be importing stuff from the >> test package in non-test code? > > I saw those checkins go by on the checkins list - they have to do with > silencing -3 warnings for modules that the stdlib still uses in Python > 2.6 for backwards compatibility reasons (but switching to the relevant > new approaches in 3.0, thus making the warnings a false alarm). > > test.test_support.catch_warning is a convenient way to suppress a > warning for a small piece of code and then revert the state of the > warnings module back to the way it was afterwards. > > Those imports should probably be guarded with sys.py3kwarn though, with > a standard import being used if the command line flag isn't set. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > --------------------------------------------------------------- > http://www.boredomandlaziness.org > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From brett at python.org Mon Aug 18 19:32:21 2008 From: brett at python.org (Brett Cannon) Date: Mon, 18 Aug 2008 10:32:21 -0700 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: <48A95E7D.1010002@gmail.com> References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> Message-ID: On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan wrote: > skip at pobox.com wrote: >> The import statement seems to work from an interactive shell (I have a >> module named test in the same directory as the main prog, hence the >> problem), but even if it does work should we be importing stuff from the >> test package in non-test code? > > I saw those checkins go by on the checkins list - they have to do with > silencing -3 warnings for modules that the stdlib still uses in Python > 2.6 for backwards compatibility reasons (but switching to the relevant > new approaches in 3.0, thus making the warnings a false alarm). > Nick is right and all of those checkins were mine. > test.test_support.catch_warning is a convenient way to suppress a > warning for a small piece of code and then revert the state of the > warnings module back to the way it was afterwards. > Yep. > Those imports should probably be guarded with sys.py3kwarn though, with > a standard import being used if the command line flag isn't set. That's probably a good idea. -Brett From brett at python.org Mon Aug 18 19:34:25 2008 From: brett at python.org (Brett Cannon) Date: Mon, 18 Aug 2008 10:34:25 -0700 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> Message-ID: On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum wrote: > Note that many distros are in the habit of not installing the test > package by default. So dependencies outside that package on *anything* > in it are a problem. Maybe test_support should be lifted out of the > test package? > Well, if distros do tend to do this and we are going to continue to document what is in that module for people's benefit, then yes, it should probably be moved or we try to convince distros to at least include the module and possibly regrtest. -Brett > On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan wrote: >> skip at pobox.com wrote: >>> The import statement seems to work from an interactive shell (I have a >>> module named test in the same directory as the main prog, hence the >>> problem), but even if it does work should we be importing stuff from the >>> test package in non-test code? >> >> I saw those checkins go by on the checkins list - they have to do with >> silencing -3 warnings for modules that the stdlib still uses in Python >> 2.6 for backwards compatibility reasons (but switching to the relevant >> new approaches in 3.0, thus making the warnings a false alarm). >> >> test.test_support.catch_warning is a convenient way to suppress a >> warning for a small piece of code and then revert the state of the >> warnings module back to the way it was afterwards. >> >> Those imports should probably be guarded with sys.py3kwarn though, with >> a standard import being used if the command line flag isn't set. >> >> Cheers, >> Nick. >> >> -- >> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia >> --------------------------------------------------------------- >> http://www.boredomandlaziness.org >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org > From guido at python.org Mon Aug 18 20:10:22 2008 From: guido at python.org (Guido van Rossum) Date: Mon, 18 Aug 2008 11:10:22 -0700 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> Message-ID: On Mon, Aug 18, 2008 at 10:34 AM, Brett Cannon wrote: > On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum wrote: >> Note that many distros are in the habit of not installing the test >> package by default. So dependencies outside that package on *anything* >> in it are a problem. Maybe test_support should be lifted out of the >> test package? >> > > Well, if distros do tend to do this and we are going to continue to > document what is in that module for people's benefit, then yes, it > should probably be moved or we try to convince distros to at least > include the module and possibly regrtest. Don't fight the distros! Move it. I'm not sure why regrtest needs to be moved though? > -Brett > > >> On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan wrote: >>> skip at pobox.com wrote: >>>> The import statement seems to work from an interactive shell (I have a >>>> module named test in the same directory as the main prog, hence the >>>> problem), but even if it does work should we be importing stuff from the >>>> test package in non-test code? >>> >>> I saw those checkins go by on the checkins list - they have to do with >>> silencing -3 warnings for modules that the stdlib still uses in Python >>> 2.6 for backwards compatibility reasons (but switching to the relevant >>> new approaches in 3.0, thus making the warnings a false alarm). >>> >>> test.test_support.catch_warning is a convenient way to suppress a >>> warning for a small piece of code and then revert the state of the >>> warnings module back to the way it was afterwards. >>> >>> Those imports should probably be guarded with sys.py3kwarn though, with >>> a standard import being used if the command line flag isn't set. >>> >>> Cheers, >>> Nick. >>> >>> -- >>> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia >>> --------------------------------------------------------------- >>> http://www.boredomandlaziness.org >>> _______________________________________________ >>> Python-Dev mailing list >>> Python-Dev at python.org >>> http://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org >>> >> >> >> >> -- >> --Guido van Rossum (home page: http://www.python.org/~guido/) >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org >> > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From brett at python.org Mon Aug 18 20:23:15 2008 From: brett at python.org (Brett Cannon) Date: Mon, 18 Aug 2008 11:23:15 -0700 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> Message-ID: On Mon, Aug 18, 2008 at 11:10 AM, Guido van Rossum wrote: > On Mon, Aug 18, 2008 at 10:34 AM, Brett Cannon wrote: >> On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum wrote: >>> Note that many distros are in the habit of not installing the test >>> package by default. So dependencies outside that package on *anything* >>> in it are a problem. Maybe test_support should be lifted out of the >>> test package? >>> >> >> Well, if distros do tend to do this and we are going to continue to >> document what is in that module for people's benefit, then yes, it >> should probably be moved or we try to convince distros to at least >> include the module and possibly regrtest. > > Don't fight the distros! Move it. And now the great debate; what should it be named? Should we start a testing package and name the module testing.support, possibly moving doctest, unittest, and any other testing code there at some point? Or just make it test_support at the top level? Or should the granularity be greater, such as separating out stuff that deals with the interpreter, files, and system state (or something)? The module has stuff ranging from is_resource_enabled and verbose for regrtest to catch_warning, TESTFN, and run_with_locale. >I'm not sure why regrtest needs to > be moved though? > Doesn't have to move. It's just the only other piece of code in the 'test' package that isn't just a test. -Brett >> -Brett >> >> >>> On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan wrote: >>>> skip at pobox.com wrote: >>>>> The import statement seems to work from an interactive shell (I have a >>>>> module named test in the same directory as the main prog, hence the >>>>> problem), but even if it does work should we be importing stuff from the >>>>> test package in non-test code? >>>> >>>> I saw those checkins go by on the checkins list - they have to do with >>>> silencing -3 warnings for modules that the stdlib still uses in Python >>>> 2.6 for backwards compatibility reasons (but switching to the relevant >>>> new approaches in 3.0, thus making the warnings a false alarm). >>>> >>>> test.test_support.catch_warning is a convenient way to suppress a >>>> warning for a small piece of code and then revert the state of the >>>> warnings module back to the way it was afterwards. >>>> >>>> Those imports should probably be guarded with sys.py3kwarn though, with >>>> a standard import being used if the command line flag isn't set. >>>> >>>> Cheers, >>>> Nick. >>>> >>>> -- >>>> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia >>>> --------------------------------------------------------------- >>>> http://www.boredomandlaziness.org >>>> _______________________________________________ >>>> Python-Dev mailing list >>>> Python-Dev at python.org >>>> http://mail.python.org/mailman/listinfo/python-dev >>>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org >>>> >>> >>> >>> >>> -- >>> --Guido van Rossum (home page: http://www.python.org/~guido/) >>> _______________________________________________ >>> Python-Dev mailing list >>> Python-Dev at python.org >>> http://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org >>> >> > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > From guido at python.org Mon Aug 18 20:31:26 2008 From: guido at python.org (Guido van Rossum) Date: Mon, 18 Aug 2008 11:31:26 -0700 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> Message-ID: Given that we're about to release beta3, I propose to name it test_support at the top level and leave it at that for now. Introducing a testing package should be relegated to 3.1 IMO. On Mon, Aug 18, 2008 at 11:23 AM, Brett Cannon wrote: > On Mon, Aug 18, 2008 at 11:10 AM, Guido van Rossum wrote: >> On Mon, Aug 18, 2008 at 10:34 AM, Brett Cannon wrote: >>> On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum wrote: >>>> Note that many distros are in the habit of not installing the test >>>> package by default. So dependencies outside that package on *anything* >>>> in it are a problem. Maybe test_support should be lifted out of the >>>> test package? >>>> >>> >>> Well, if distros do tend to do this and we are going to continue to >>> document what is in that module for people's benefit, then yes, it >>> should probably be moved or we try to convince distros to at least >>> include the module and possibly regrtest. >> >> Don't fight the distros! Move it. > > And now the great debate; what should it be named? Should we start a > testing package and name the module testing.support, possibly moving > doctest, unittest, and any other testing code there at some point? Or > just make it test_support at the top level? Or should the granularity > be greater, such as separating out stuff that deals with the > interpreter, files, and system state (or something)? The module has > stuff ranging from is_resource_enabled and verbose for regrtest to > catch_warning, TESTFN, and run_with_locale. > >>I'm not sure why regrtest needs to >> be moved though? >> > > Doesn't have to move. It's just the only other piece of code in the > 'test' package that isn't just a test. > > -Brett > > >>> -Brett >>> >>> >>>> On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan wrote: >>>>> skip at pobox.com wrote: >>>>>> The import statement seems to work from an interactive shell (I have a >>>>>> module named test in the same directory as the main prog, hence the >>>>>> problem), but even if it does work should we be importing stuff from the >>>>>> test package in non-test code? >>>>> >>>>> I saw those checkins go by on the checkins list - they have to do with >>>>> silencing -3 warnings for modules that the stdlib still uses in Python >>>>> 2.6 for backwards compatibility reasons (but switching to the relevant >>>>> new approaches in 3.0, thus making the warnings a false alarm). >>>>> >>>>> test.test_support.catch_warning is a convenient way to suppress a >>>>> warning for a small piece of code and then revert the state of the >>>>> warnings module back to the way it was afterwards. >>>>> >>>>> Those imports should probably be guarded with sys.py3kwarn though, with >>>>> a standard import being used if the command line flag isn't set. >>>>> >>>>> Cheers, >>>>> Nick. >>>>> >>>>> -- >>>>> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia >>>>> --------------------------------------------------------------- >>>>> http://www.boredomandlaziness.org >>>>> _______________________________________________ >>>>> Python-Dev mailing list >>>>> Python-Dev at python.org >>>>> http://mail.python.org/mailman/listinfo/python-dev >>>>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org >>>>> >>>> >>>> >>>> >>>> -- >>>> --Guido van Rossum (home page: http://www.python.org/~guido/) >>>> _______________________________________________ >>>> Python-Dev mailing list >>>> Python-Dev at python.org >>>> http://mail.python.org/mailman/listinfo/python-dev >>>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org >>>> >>> >> >> >> >> -- >> --Guido van Rossum (home page: http://www.python.org/~guido/) >> > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From musiccomposition at gmail.com Mon Aug 18 20:33:55 2008 From: musiccomposition at gmail.com (Benjamin Peterson) Date: Mon, 18 Aug 2008 13:33:55 -0500 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> Message-ID: <1afaf6160808181133u4650fce2x7cd1579e63bd592f@mail.gmail.com> On Mon, Aug 18, 2008 at 1:31 PM, Guido van Rossum wrote: > Given that we're about to release beta3, I propose to name it > test_support at the top level and leave it at that for now. > Introducing a testing package should be relegated to 3.1 IMO. Why not name it testutils? -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." From solipsis at pitrou.net Mon Aug 18 20:43:43 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 18 Aug 2008 18:43:43 +0000 (UTC) Subject: [Python-Dev] =?utf-8?q?Why_does_httplib_import_from_test=5Fsuppor?= =?utf-8?q?t=3F?= References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> Message-ID: Brett Cannon python.org> writes: > > > > I saw those checkins go by on the checkins list - they have to do with > > silencing -3 warnings for modules that the stdlib still uses in Python > > 2.6 for backwards compatibility reasons (but switching to the relevant > > new approaches in 3.0, thus making the warnings a false alarm). > > > > Nick is right and all of those checkins were mine. If it's about silencing warnings, then how about putting it in the warnings module? From fdrake at acm.org Mon Aug 18 20:45:21 2008 From: fdrake at acm.org (Fred Drake) Date: Mon, 18 Aug 2008 14:45:21 -0400 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: <1afaf6160808181133u4650fce2x7cd1579e63bd592f@mail.gmail.com> References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> <1afaf6160808181133u4650fce2x7cd1579e63bd592f@mail.gmail.com> Message-ID: On Aug 18, 2008, at 2:33 PM, Benjamin Peterson wrote: > Why not name it testutils? Heh. And what's the difference between *utils, *tools, and *lib? They all sound the same to me. :-( -Fred -- Fred Drake From fdrake at acm.org Mon Aug 18 20:55:01 2008 From: fdrake at acm.org (Fred Drake) Date: Mon, 18 Aug 2008 14:55:01 -0400 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> Message-ID: <67B54E00-976A-459B-937A-11B35CF4805E@acm.org> On Aug 18, 2008, at 2:43 PM, Antoine Pitrou wrote: > If it's about silencing warnings, then how about putting it in the > warnings > module? That sounds good to me, and would be very reasonable. This would make a nice context manager. -Fred -- Fred Drake From brett at python.org Mon Aug 18 21:13:11 2008 From: brett at python.org (Brett Cannon) Date: Mon, 18 Aug 2008 12:13:11 -0700 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: <67B54E00-976A-459B-937A-11B35CF4805E@acm.org> References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> <67B54E00-976A-459B-937A-11B35CF4805E@acm.org> Message-ID: On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake wrote: > On Aug 18, 2008, at 2:43 PM, Antoine Pitrou wrote: >> >> If it's about silencing warnings, then how about putting it in the >> warnings >> module? > > > That sounds good to me, and would be very reasonable. This would make a > nice context manager. > That works for me as well; just move catch_warning() to 'warnings' and leave test.test_support as-is. If we did that, though, I would want to make 'record' False by default so that it had more reasonable defaults for non-testing purposes. -Brett From guido at python.org Mon Aug 18 22:08:10 2008 From: guido at python.org (Guido van Rossum) Date: Mon, 18 Aug 2008 13:08:10 -0700 Subject: [Python-Dev] Should we help pythonmac.org? In-Reply-To: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> Message-ID: Alternatively, I just got mail from Bob Ippolito indicating that he'd be happy to hand over the domain to the PSF. It's got quite a bit more on it than Python distros, and it's a fairly popular resource for Mac users I imagine. However macports.org seems to have more Python stuff, and has a more recent version of 2.5. (2.5.2). Perhaps we should link to macports.org instead? On Mon, Aug 18, 2008 at 9:54 AM, Barry Warsaw wrote: > On Aug 18, 2008, at 12:05 PM, Guido van Rossum wrote: > >> Does anyone have connections with the owners of pythonmac.org? >> Apparently they are serving up an ancient version of Python 2.5. The >> Google App Engine has a minor issue in 2.5 that's solved in 2.5.1, but >> that is apparently not available from that site. Perhaps we can >> contribute more recent Mac versions, or provide them directly on >> python.org? (The Downloads -> Macintosh page points to pythonmac.org, >> which means lots of All Engine users download this old version.) > > I'd be happy to arrange things with a Mac expert to put the Mac binaries on > the download site. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From steve at holdenweb.com Mon Aug 18 23:42:53 2008 From: steve at holdenweb.com (Steve Holden) Date: Mon, 18 Aug 2008 17:42:53 -0400 Subject: [Python-Dev] Should we help pythonmac.org? In-Reply-To: References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> Message-ID: <48A9ECDD.5050206@holdenweb.com> Someone told me the other day that macports made for difficult installs, but not being a Mac user I wasn't in a position to evaluate the advice. I can see the desirability of having a Python-specific domain, but then again if the pydotorg team were going to maintain the content then they might just as well maintain it under python.org. I really do think it would be better if the Mac downloads were available from the same site as all the others, but I don't know whether we have the manpower and skills available to cut the releases and maintain the additional content. I'm copying the pydotorg list to see what, if anything, they have to say about it. That's where the work is likely to land, so we'd better know in advance if it would cause problems. regards Steve Guido van Rossum wrote: > Alternatively, I just got mail from Bob Ippolito indicating that he'd > be happy to hand over the domain to the PSF. It's got quite a bit more > on it than Python distros, and it's a fairly popular resource for Mac > users I imagine. However macports.org seems to have more Python stuff, > and has a more recent version of 2.5. (2.5.2). Perhaps we should link > to macports.org instead? > > On Mon, Aug 18, 2008 at 9:54 AM, Barry Warsaw wrote: >> On Aug 18, 2008, at 12:05 PM, Guido van Rossum wrote: >> >>> Does anyone have connections with the owners of pythonmac.org? >>> Apparently they are serving up an ancient version of Python 2.5. The >>> Google App Engine has a minor issue in 2.5 that's solved in 2.5.1, but >>> that is apparently not available from that site. Perhaps we can >>> contribute more recent Mac versions, or provide them directly on >>> python.org? (The Downloads -> Macintosh page points to pythonmac.org, >>> which means lots of All Engine users download this old version.) >> I'd be happy to arrange things with a Mac expert to put the Mac binaries on >> the download site. > -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From steve at holdenweb.com Mon Aug 18 23:42:53 2008 From: steve at holdenweb.com (Steve Holden) Date: Mon, 18 Aug 2008 17:42:53 -0400 Subject: [Python-Dev] Should we help pythonmac.org? In-Reply-To: References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> Message-ID: <48A9ECDD.5050206@holdenweb.com> Someone told me the other day that macports made for difficult installs, but not being a Mac user I wasn't in a position to evaluate the advice. I can see the desirability of having a Python-specific domain, but then again if the pydotorg team were going to maintain the content then they might just as well maintain it under python.org. I really do think it would be better if the Mac downloads were available from the same site as all the others, but I don't know whether we have the manpower and skills available to cut the releases and maintain the additional content. I'm copying the pydotorg list to see what, if anything, they have to say about it. That's where the work is likely to land, so we'd better know in advance if it would cause problems. regards Steve Guido van Rossum wrote: > Alternatively, I just got mail from Bob Ippolito indicating that he'd > be happy to hand over the domain to the PSF. It's got quite a bit more > on it than Python distros, and it's a fairly popular resource for Mac > users I imagine. However macports.org seems to have more Python stuff, > and has a more recent version of 2.5. (2.5.2). Perhaps we should link > to macports.org instead? > > On Mon, Aug 18, 2008 at 9:54 AM, Barry Warsaw wrote: >> On Aug 18, 2008, at 12:05 PM, Guido van Rossum wrote: >> >>> Does anyone have connections with the owners of pythonmac.org? >>> Apparently they are serving up an ancient version of Python 2.5. The >>> Google App Engine has a minor issue in 2.5 that's solved in 2.5.1, but >>> that is apparently not available from that site. Perhaps we can >>> contribute more recent Mac versions, or provide them directly on >>> python.org? (The Downloads -> Macintosh page points to pythonmac.org, >>> which means lots of All Engine users download this old version.) >> I'd be happy to arrange things with a Mac expert to put the Mac binaries on >> the download site. > -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From bob at redivi.com Mon Aug 18 23:06:46 2008 From: bob at redivi.com (Bob Ippolito) Date: Mon, 18 Aug 2008 14:06:46 -0700 Subject: [Python-Dev] Should we help pythonmac.org? In-Reply-To: References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> Message-ID: <6a36e7290808181406w24b8b836wb9619227c0e67333@mail.gmail.com> The major difference between the packages on macports and pythonmac.org is that macports is their own distro of nearly everything, akin to installing a copy of FreeBSD over top of Mac OS X. pythonmac.org contains packages that are self-contained and don't have a whole new set of libraries to install (in the cases where they do require libraries, they link them in statically for the most part). These days I don't have a lot of preference, I don't use either :) On Mon, Aug 18, 2008 at 1:08 PM, Guido van Rossum wrote: > Alternatively, I just got mail from Bob Ippolito indicating that he'd > be happy to hand over the domain to the PSF. It's got quite a bit more > on it than Python distros, and it's a fairly popular resource for Mac > users I imagine. However macports.org seems to have more Python stuff, > and has a more recent version of 2.5. (2.5.2). Perhaps we should link > to macports.org instead? > > On Mon, Aug 18, 2008 at 9:54 AM, Barry Warsaw wrote: >> On Aug 18, 2008, at 12:05 PM, Guido van Rossum wrote: >> >>> Does anyone have connections with the owners of pythonmac.org? >>> Apparently they are serving up an ancient version of Python 2.5. The >>> Google App Engine has a minor issue in 2.5 that's solved in 2.5.1, but >>> that is apparently not available from that site. Perhaps we can >>> contribute more recent Mac versions, or provide them directly on >>> python.org? (The Downloads -> Macintosh page points to pythonmac.org, >>> which means lots of All Engine users download this old version.) >> >> I'd be happy to arrange things with a Mac expert to put the Mac binaries on >> the download site. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > From fdrake at acm.org Tue Aug 19 00:13:54 2008 From: fdrake at acm.org (Fred Drake) Date: Mon, 18 Aug 2008 18:13:54 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <48A9ECDD.5050206@holdenweb.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> Message-ID: On Aug 18, 2008, at 5:42 PM, Steve Holden wrote: > Someone told me the other day that macports made for difficult > installs, but not being a Mac user I wasn't in a position to > evaluate the advice. Not being a Mac user either, I've been using Mac OS X for about a year now for most of my development. I've got mixed feelings about macports: It's painful to use, compared to things like rpm and apt, but... it might be the best that's available for the Mac. I'm not going to trust it to give me a usable Python, though, in spite of not having had problems with Pythons it provides. Just 'cause I've gotten paranoid. > I'm copying the pydotorg list to see what, if anything, they have to > say about it. That's where the work is likely to land, so we'd > better know in advance if it would cause problems. If there are content maintainers for the Mac content (including installation packages of whatever form), then python.org is the right place for it. Presumably //someone// is creating those now, right? If they could upload them to python.org and update the pages accordingly, that should be no worse than anything they're doing now. -Fred -- Fred Drake From barry at python.org Tue Aug 19 00:41:23 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 18 Aug 2008 18:41:23 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> Message-ID: <572697F6-D394-4906-965B-54723AF8E1E2@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 18, 2008, at 6:13 PM, Fred Drake wrote: > On Aug 18, 2008, at 5:42 PM, Steve Holden wrote: >> Someone told me the other day that macports made for difficult >> installs, but not being a Mac user I wasn't in a position to >> evaluate the advice. > > Not being a Mac user either, I've been using Mac OS X for about a > year now for most of my development. > > I've got mixed feelings about macports: It's painful to use, > compared to things like rpm and apt, but... it might be the best > that's available for the Mac. > > I'm not going to trust it to give me a usable Python, though, in > spite of not having had problems with Pythons it provides. Just > 'cause I've gotten paranoid. I use macports too, mostly for stuff I'm too lazy to build from source. I'm sure there's a Python in there, but like Fred, I don't use it. I do agree that we could and probably should maintain any Mac Python content on the main python.org site, but also if Bob wants to donate the domain, we can just have it forward to www.python.org/allyourmacsarebelongtous - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKn6k3EjvBPtnXfVAQJdZgP/a2G3T9jowXMjYc5dc/+PFFVM0mxe0+Y1 rJKoHZ+jumWEsxERD6kXCjrq00z21lGISnEBQkT5taieGgt8ouI3RtC3Atpp/wCR oqvyFJUb9Xxu7TUAV94G3yC/CUq0ZQiKT80F0YB/IQAGeYy6orkfolUqMosUOsVo KB1WDrqXEiU= =SZ1A -----END PGP SIGNATURE----- From goodger at python.org Tue Aug 19 02:45:31 2008 From: goodger at python.org (David Goodger) Date: Mon, 18 Aug 2008 20:45:31 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <48A9ECDD.5050206@holdenweb.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> Message-ID: <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> > Guido van Rossum wrote: >> Alternatively, I just got mail from Bob Ippolito indicating that he'd >> be happy to hand over the domain to the PSF. It's got quite a bit more >> on it than Python distros, and it's a fairly popular resource for Mac >> users I imagine. However macports.org seems to have more Python stuff, >> and has a more recent version of 2.5. (2.5.2). Perhaps we should link >> to macports.org instead? I strongly recommend that we *NOT* make macports.org the main, official Mac OS X version of Python. Secondary is fine, but not primary. Macports is what the name says: it's a system of Mac ports of Linux packages, mostly command-line only. Those who want/need it know about it or will find it easily, while those who don't need it would only be confused by it. The official Mac Python should be an OS X application, with an icon, living in /Applications, ideally with a Mac-standard editor app (the 2.5.1 I have has IDLE), etc. Unfortunately, I can only recommend. I don't know anything about building Mac apps. -- David Goodger From bob at redivi.com Tue Aug 19 00:57:37 2008 From: bob at redivi.com (Bob Ippolito) Date: Mon, 18 Aug 2008 15:57:37 -0700 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <572697F6-D394-4906-965B-54723AF8E1E2@python.org> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <572697F6-D394-4906-965B-54723AF8E1E2@python.org> Message-ID: <6a36e7290808181557t3cd94a2aw27b5537fbefd9140@mail.gmail.com> On Mon, Aug 18, 2008 at 3:41 PM, Barry Warsaw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Aug 18, 2008, at 6:13 PM, Fred Drake wrote: > >> On Aug 18, 2008, at 5:42 PM, Steve Holden wrote: >>> >>> Someone told me the other day that macports made for difficult installs, >>> but not being a Mac user I wasn't in a position to evaluate the advice. >> >> Not being a Mac user either, I've been using Mac OS X for about a year now >> for most of my development. >> >> I've got mixed feelings about macports: It's painful to use, compared to >> things like rpm and apt, but... it might be the best that's available for >> the Mac. >> >> I'm not going to trust it to give me a usable Python, though, in spite of >> not having had problems with Pythons it provides. Just 'cause I've gotten >> paranoid. > > I use macports too, mostly for stuff I'm too lazy to build from source. I'm > sure there's a Python in there, but like Fred, I don't use it. > > I do agree that we could and probably should maintain any Mac Python content > on the main python.org site, but also if Bob wants to donate the domain, we > can just have it forward to www.python.org/allyourmacsarebelongtous We already do that for the wiki, we could do that for the other parts of the site just as easily (even without or before a transfer of ownership) :) I'm happy to pay for the domain and hosting, I just don't have a lot of spare cycles these days unless I need something at work. -bob From janssen at parc.com Tue Aug 19 03:18:25 2008 From: janssen at parc.com (Bill Janssen) Date: Mon, 18 Aug 2008 18:18:25 PDT Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> Message-ID: <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> > I strongly recommend that we *NOT* make macports.org the main, > official Mac OS X version of Python. Secondary is fine, but not > primary. Macports is what the name says: it's a system of Mac ports of > Linux packages, mostly command-line only. I agree with David about this. > The official Mac Python should be an OS X application, with an icon, > living in /Applications, ideally with a Mac-standard editor app (the > 2.5.1 I have has IDLE), etc. No, probably not. Frankly, I think the official Mac Python should be (and is) /usr/bin/python, the version that Apple ships with the system. I always try to make my stuff work with that Python, instead of installing a different version, which in my experience usually leads to grief somewhere down the road. Bill From steve at holdenweb.com Tue Aug 19 03:45:12 2008 From: steve at holdenweb.com (Steve Holden) Date: Mon, 18 Aug 2008 21:45:12 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> Message-ID: <48AA25A8.6060101@holdenweb.com> Bill Janssen wrote: >> I strongly recommend that we *NOT* make macports.org the main, >> official Mac OS X version of Python. Secondary is fine, but not >> primary. Macports is what the name says: it's a system of Mac ports of >> Linux packages, mostly command-line only. > > I agree with David about this. > >> The official Mac Python should be an OS X application, with an icon, >> living in /Applications, ideally with a Mac-standard editor app (the >> 2.5.1 I have has IDLE), etc. > > No, probably not. Frankly, I think the official Mac Python should be > (and is) /usr/bin/python, the version that Apple ships with the > system. I always try to make my stuff work with that Python, instead > of installing a different version, which in my experience usually > leads to grief somewhere down the road. > I've certainly heard many tales of Mac users coming to grief because they decided to overwrite their system Python, or tried to be clever and run multiple interpreters (which is usually somewhat less disastrous). I guess this underlines the fact that Apple don't really want the hoi polloi tinkering with their systems; it's somewhat tedious when code is released for later Python versions and you have to privately backport, though, isn't it? There have been hints dropped that if the 2.6 release hits its deadline it will be incorporated into vendor builds. Let's hope one of them is MacOS, then at least it'll be relatively up to date. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From steve at holdenweb.com Tue Aug 19 03:45:12 2008 From: steve at holdenweb.com (Steve Holden) Date: Mon, 18 Aug 2008 21:45:12 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> Message-ID: <48AA25A8.6060101@holdenweb.com> Bill Janssen wrote: >> I strongly recommend that we *NOT* make macports.org the main, >> official Mac OS X version of Python. Secondary is fine, but not >> primary. Macports is what the name says: it's a system of Mac ports of >> Linux packages, mostly command-line only. > > I agree with David about this. > >> The official Mac Python should be an OS X application, with an icon, >> living in /Applications, ideally with a Mac-standard editor app (the >> 2.5.1 I have has IDLE), etc. > > No, probably not. Frankly, I think the official Mac Python should be > (and is) /usr/bin/python, the version that Apple ships with the > system. I always try to make my stuff work with that Python, instead > of installing a different version, which in my experience usually > leads to grief somewhere down the road. > I've certainly heard many tales of Mac users coming to grief because they decided to overwrite their system Python, or tried to be clever and run multiple interpreters (which is usually somewhat less disastrous). I guess this underlines the fact that Apple don't really want the hoi polloi tinkering with their systems; it's somewhat tedious when code is released for later Python versions and you have to privately backport, though, isn't it? There have been hints dropped that if the 2.6 release hits its deadline it will be incorporated into vendor builds. Let's hope one of them is MacOS, then at least it'll be relatively up to date. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From barry at python.org Tue Aug 19 04:57:33 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 18 Aug 2008 22:57:33 -0400 Subject: [Python-Dev] [Python-3000] parse_qs and parse_qsl functions In-Reply-To: References: Message-ID: <20080818225733.0457f242@resist.wooz.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 16, 2008, at 12:52 PM, Brett Cannon wrote: >On Sat, Aug 16, 2008 at 7:04 AM, Facundo Batista > wrote: >> Hi! >> >> The issue 600362 has two patches (one for 2.6 and the other for 3.0) >> that are ready to commit (with a small change in the docs). This >> patches relocates the parse_qs and parse_qsl functions into the >> urlparse module (urllib.parse in 3k), bringing them from the cgi one. >> >> For backward compatibility, those functions are also accessible from >> the cgi module, but in the documentation says that the function was >> moved, and you should use it from the urlparse one. >> >> So, we don't have *any* change in the behaviour towards the final user. >> >> Two questions: >> >> - It's ok to do this now or we should wait for 3.1/2.7? >> >> - Should we add a deprecation warning in the cgi module for this functions? >> >> I propose to commit this now, but leave a deprecation warning for the >> next release. >> > >Obviously Barry's call, but I think it's fine to do what you are proposing. I think it's fine to commit this. I would put a DeprecationWarning in 3.0 and a PendingDeprecationWarning in 2.6 (updated to a DW in 2.7). - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIqja42YZpQepbvXERAp7oAJ9t6h/MtzAQQDDS3J65p7Zwpf+JzgCeO24r kCmcTtPIeo/M0hiqmtee0/o= =FVuq -----END PGP SIGNATURE----- From barry at python.org Tue Aug 19 05:29:50 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 18 Aug 2008 23:29:50 -0400 Subject: [Python-Dev] Beta 3 planned for this Wednesday Message-ID: <20080818232950.5f234f31@resist.wooz.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, I am going to try to release the last planned beta of 2.6 and 3.0 this Wednesday. Looking at the stable buildbots and showstopper bugs indicates some work to do between now and then. Here are the showstoppers, along with my recommendations. 1878 class attribute cache failure (regression) - - Medium priority - - Guido, there are some design choices that need your decision. I'd like to fix this for beta 3 if it's going to be fixed at all, because I suspect the changes will be too disruptive once we reach release candidates. 2394 [Py3k] Finish the memoryview object implementation - - High priority - - This one is serious enough to hold up the release. I really do not think we should be finishing this implementation in the rc phase. 1179 [CVE-2007-4965] Integer overflow in imageop module - - High priority - - This will block final release and I think it needs to be fixed for this beta. 3131 2to3 can't find fixes_dir - - Medium priority - - I'm willing to defer this to the release candidates, but it will definitely block the release candidates. 3402 test_nis is hanging on Solaris - - Medium priority - - I suggest disabling this test and adding a note to the release notes. If nobody comes forward to fix it for the final release, tough. 3352 Deficiencies in multiprocessing/threading API - - Medium priority - - This one is getting some love, so I'm confident this will get fixed before beta 3. As for the buildbots, they're not looking so good. It looks like the trunk has various failures in multiprocessing (hopefully fixed soon) and bsddb3. Also some crashes in test_anydbm. Hmm. 3.0 is looking better but there's a weird error in test_sys and test_threading. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIqj4v2YZpQepbvXERAolaAJ4uydGlv5wP2/SrZt4HzROkWfQUeACcDyoJ 7DZW8MgxYKQMedhj7wJywDo= =oJk1 -----END PGP SIGNATURE----- From santagada at gmail.com Tue Aug 19 06:54:15 2008 From: santagada at gmail.com (Leonardo Santagada) Date: Tue, 19 Aug 2008 01:54:15 -0300 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> Message-ID: <805699C6-3E72-46F2-A0AD-B09811A8881A@gmail.com> -1 to use mac ports python as the base python On 18/08/2008, at 22:18, Bill Janssen wrote: >> >> The official Mac Python should be an OS X application, with an icon, >> living in /Applications, ideally with a Mac-standard editor app (the >> 2.5.1 I have has IDLE), etc. > > No, probably not. Frankly, I think the official Mac Python should be > (and is) /usr/bin/python, the version that Apple ships with the > system. I always try to make my stuff work with that Python, instead > of installing a different version, which in my experience usually > leads to grief somewhere down the road. I don't think this way, the official python should be the one from python.org, as it is on windows or there will be no point to make python 2.5.1 and 2.5.2 (or any point release that is not incorporated in vendors builds). The only grief I ever had in using the python from python.org is that I have to compile PyObjC from source, but this can be easily fixed. Talking about this, why not just point pythonmac.org to python.org python version and release the packages as eggs on cheeseshop? (specially py2exe and pyobjc as those are usually heavily needed on macs). -- Leonardo Santagada From fuzzyman at mail2.webfaction.com Tue Aug 19 09:45:43 2008 From: fuzzyman at mail2.webfaction.com (fuzzyman at mail2.webfaction.com) Date: Tue, 19 Aug 2008 02:45:43 -0500 (CDT) Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <48AA25A8.6060101@holdenweb.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> <48AA25A8.6060101@holdenweb.com> Message-ID: <1699.92.83.146.25.1219131943.squirrel@mail2.webfaction.com> > Bill Janssen wrote: >>> I strongly recommend that we *NOT* make macports.org the main, >>> official Mac OS X version of Python. Secondary is fine, but not >>> primary. Macports is what the name says: it's a system of Mac ports of >>> Linux packages, mostly command-line only. >> >> I agree with David about this. >> >>> The official Mac Python should be an OS X application, with an icon, >>> living in /Applications, ideally with a Mac-standard editor app (the >>> 2.5.1 I have has IDLE), etc. >> >> No, probably not. Frankly, I think the official Mac Python should be >> (and is) /usr/bin/python, the version that Apple ships with the >> system. I always try to make my stuff work with that Python, instead >> of installing a different version, which in my experience usually >> leads to grief somewhere down the road. >> > I've certainly heard many tales of Mac users coming to grief because > they decided to overwrite their system Python, or tried to be clever and > run multiple interpreters (which is usually somewhat less disastrous). > The Mac system depends a lot on stuff that comes installed with the system version of Python - including specific versions of Twisted etc. I *thought* (relative Mac newbie), the standard advice was that if you want to install extension modules then you should install your own version of Python and not mess with the system version. Meaning that you have to maintain two Python installs - something that hasn't been a problem for me yet. So even if Mac OS ships with Python 2.6, many users will still want to install their own version. The default page for Python on the Mac is horribly out of date: http://python.org/download/mac/ No mention of Leopard. Michael > I guess this underlines the fact that Apple don't really want the hoi > polloi tinkering with their systems; it's somewhat tedious when code is > released for later Python versions and you have to privately backport, > though, isn't it? > > There have been hints dropped that if the 2.6 release hits its deadline > it will be incorporated into vendor builds. Let's hope one of them is > MacOS, then at least it'll be relatively up to date. > > regards > Steve > -- > Steve Holden +1 571 484 6266 +1 800 494 3119 > Holden Web LLC http://www.holdenweb.com/ > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > From ronaldoussoren at mac.com Tue Aug 19 11:23:17 2008 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 19 Aug 2008 11:23:17 +0200 Subject: [Python-Dev] Should we help pythonmac.org? In-Reply-To: References: Message-ID: My two cents: the link to pythonmac.org should be removed, especially for downloading an installer for Python. The main 2.5.x download pages already have a binary installer for OSX (10.3.9 or later), the copy on pythonmac.org is just that: an (outdated) copy of the installer on the main python.org download page. There's also a collection of installers for various packages (such as PIL) on there, which make it easy to install such packages without trying to build them yourself and without pulling in all of macports or fink. Sadly enough that package collection doesn't seem to be maintained at the moment. Ronald On 18 Aug, 2008, at 18:05, Guido van Rossum wrote: > Does anyone have connections with the owners of pythonmac.org? > Apparently they are serving up an ancient version of Python 2.5. The > Google App Engine has a minor issue in 2.5 that's solved in 2.5.1, but > that is apparently not available from that site. Perhaps we can > contribute more recent Mac versions, or provide them directly on > python.org? (The Downloads -> Macintosh page points to pythonmac.org, > which means lots of All Engine users download this old version.) > > -- > --Guido van Rossum (home: python.org/~guido/) > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com From steve at holdenweb.com Tue Aug 19 13:25:22 2008 From: steve at holdenweb.com (Steve Holden) Date: Tue, 19 Aug 2008 07:25:22 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <805699C6-3E72-46F2-A0AD-B09811A8881A@gmail.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> <805699C6-3E72-46F2-A0AD-B09811A8881A@gmail.com> Message-ID: <48AAADA2.80401@holdenweb.com> Leonardo Santagada wrote: > -1 to use mac ports python as the base python > > On 18/08/2008, at 22:18, Bill Janssen wrote: > >>> >>> The official Mac Python should be an OS X application, with an icon, >>> living in /Applications, ideally with a Mac-standard editor app (the >>> 2.5.1 I have has IDLE), etc. >> >> No, probably not. Frankly, I think the official Mac Python should be >> (and is) /usr/bin/python, the version that Apple ships with the >> system. I always try to make my stuff work with that Python, instead >> of installing a different version, which in my experience usually >> leads to grief somewhere down the road. > > > I don't think this way, the official python should be the one from > python.org, as it is on windows or there will be no point to make python > 2.5.1 and 2.5.2 (or any point release that is not incorporated in > vendors builds). > > The only grief I ever had in using the python from python.org is that I > have to compile PyObjC from source, but this can be easily fixed. > > Talking about this, why not just point pythonmac.org to python.org > python version and release the packages as eggs on cheeseshop? > (specially py2exe and pyobjc as those are usually heavily needed on macs). > I'm suspicious of any solution involving the word "just". I suppose we will "just" be able to recruit volunteers to maintain the additional content? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From fdrake at acm.org Tue Aug 19 14:51:36 2008 From: fdrake at acm.org (Fred Drake) Date: Tue, 19 Aug 2008 08:51:36 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <1699.92.83.146.25.1219131943.squirrel@mail2.webfaction.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> <48AA25A8.6060101@holdenweb.com> <1699.92.83.146.25.1219131943.squirrel@mail2.webfaction.com> Message-ID: <7801D1D8-B938-4523-8167-D405BA0192F6@acm.org> On Aug 19, 2008, at 3:45 AM, fuzzyman at mail2.webfaction.com wrote: > I *thought* (relative Mac newbie), the standard advice was that if you > want to install extension modules then you should install your own > version > of Python and not mess with the system version. My understanding is that if there is a system Python, you shouldn't change it. Ever. System Python's are for other components of the system; you can use them, but shouldn't modify them. Including installing or updating packages in the site-packages directory. At Zope Corporation, we use a clean Python for all development and deployments. Nothing gets installed into the site-packages, because different applications want different packages (or different versions), and we want to deploy with what we test with. > Meaning that you have to maintain two Python installs - something that > hasn't been a problem for me yet. So even if Mac OS ships with > Python 2.6, > many users will still want to install their own version. Indeed. I've never had to do anything to maintain the system Python on Mac OS X. It's there, Mac OS X does what it will with it, and I use my private (and squeaky clean!) Python installations. -Fred -- Fred Drake From barry at python.org Tue Aug 19 15:01:12 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 19 Aug 2008 09:01:12 -0400 Subject: [Python-Dev] Hanging out on freenode IRC #python-dev Message-ID: <3AD66C78-C365-48FB-94DB-4462E5AC9A0C@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I will be hanging out as much as possible over the next two days on the #python-dev channel on freenode IRC. If you have any last minute decisions you need, that will be the most immediate way to get in touch with me. Modulo work commitments, I'm generally available from about 7am to about 7pm US Eastern (UTC -0400) time. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKrEGHEjvBPtnXfVAQKCZAP+JyldH4bq1MO/0s5cJYDIM1hKNuXTm488 Ys/scWaPb7zBGi5/+Wdbwmle82EAsl3SDH6yDzjzhvgHOkOdsvaCP2bbVaXzDQ2r gOWs9jNBug/1HuGlaD3UPLehZ0I8Hy192XZz0o9z6jXmh7+ffbbDdyUW8x3D4IKX +pu/DsL8EkY= =+MNA -----END PGP SIGNATURE----- From musiccomposition at gmail.com Tue Aug 19 15:02:40 2008 From: musiccomposition at gmail.com (Benjamin Peterson) Date: Tue, 19 Aug 2008 08:02:40 -0500 Subject: [Python-Dev] [Python-3000] Beta 3 planned for this Wednesday In-Reply-To: <20080818232950.5f234f31@resist.wooz.org> References: <20080818232950.5f234f31@resist.wooz.org> Message-ID: <1afaf6160808190602u8c00856oe08d76a198a6c382@mail.gmail.com> On Mon, Aug 18, 2008 at 10:29 PM, Barry Warsaw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello everyone, > > I am going to try to release the last planned beta of 2.6 and 3.0 this > Wednesday. Looking at the stable buildbots and showstopper bugs indicates > some work to do between now and then. Here are the showstoppers, along with > my recommendations. > > 1878 class attribute cache failure (regression) > - - Medium priority > - - Guido, there are some design choices that need your decision. I'd like to > fix this for beta 3 if it's going to be fixed at all, because I suspect the > changes will be too disruptive once we reach release candidates. > > 2394 [Py3k] Finish the memoryview object implementation > - - High priority > - - This one is serious enough to hold up the release. I really do not think we > should be finishing this implementation in the rc phase. How finished is finished? I see Antoine has implemented a little more of it. > > 1179 [CVE-2007-4965] Integer overflow in imageop module > - - High priority > - - This will block final release and I think it needs to be fixed for this beta. I've never used imageop, but I'll see if I can review the patch. > > 3131 2to3 can't find fixes_dir > - - Medium priority > - - I'm willing to defer this to the release candidates, but it will definitely > block the release candidates. This is pretty simple. There are patches that can be applied, but I think 2to3 requires a little refactoring. I suppose that can be done after the beta, though. > > 3402 test_nis is hanging on Solaris > - - Medium priority > - - I suggest disabling this test and adding a note to the release notes. If > nobody comes forward to fix it for the final release, tough. > > 3352 Deficiencies in multiprocessing/threading API > - - Medium priority > - - This one is getting some love, so I'm confident this will get fixed before > beta 3. Jesse said he could have it done today. > > As for the buildbots, they're not looking so good. It looks like the trunk > has various failures in multiprocessing (hopefully fixed soon) and bsddb3. > Also some crashes in test_anydbm. Hmm. > > 3.0 is looking better but there's a weird error in test_sys and > test_threading. > > - -Barry > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIqj4v2YZpQepbvXERAolaAJ4uydGlv5wP2/SrZt4HzROkWfQUeACcDyoJ > 7DZW8MgxYKQMedhj7wJywDo= > =oJk1 > -----END PGP SIGNATURE----- > _______________________________________________ > Python-3000 mailing list > Python-3000 at python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." From barry at python.org Tue Aug 19 15:37:08 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 19 Aug 2008 09:37:08 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <7801D1D8-B938-4523-8167-D405BA0192F6@acm.org> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> <48AA25A8.6060101@holdenweb.com> <1699.92.83.146.25.1219131943.squirrel@mail2.webfaction.com> <7801D1D8-B938-4523-8167-D405BA0192F6@acm.org> Message-ID: <92D5F670-B4F5-4D0E-A64B-92B8DAAC0C2E@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 19, 2008, at 8:51 AM, Fred Drake wrote: > My understanding is that if there is a system Python, you shouldn't > change it. Ever. Huge, big, honkin' +1 from me on that. Besides, for a system Python, you want your distribution to manage packages, not setuptools, otherwise you confuse -- and probably break -- your system. As a corollary, a system Python script should never ever use #!/usr/ bin/env python as its first line. It should always use /usr/bin/ python because that's the only thing it can guarantee it knows anything about. I've had several discussions with distro vendors about this, some at Pycon and others I'm more intimately involved with . I think there's general agreement about these principles, even if it's not always implemented correctly for every tool (but that's what bug reports are for :). - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKrMhXEjvBPtnXfVAQKprwQAsuckU4jw5B+asnd6XNqCjuOuIDYRuv3w sOlfn76qwoxaA9KJe7aCBOcoXpUnB4ibEm8O403LYV9izRXf62xgGdyVWTS73yEc Sj6maoeIIO9ph7/p7eWT0Hl3pVmphsiLRgd7usyDSeRf+8ncXmE8Clr7i1vZ1rn+ fkFznLm7Kb0= =xHHt -----END PGP SIGNATURE----- From ktenney at gmail.com Tue Aug 19 15:53:59 2008 From: ktenney at gmail.com (Kent Tenney) Date: Tue, 19 Aug 2008 08:53:59 -0500 Subject: [Python-Dev] ImportError message suggestion Message-ID: Howdy, I brought this up on c.l.p., was encouraged to try it here. http://groups.google.com/group/comp.lang.python/browse_thread/thread/88474a32877026fc/ ================================================== from image import annotate ImportError: cannot import name annotate I found the problem via import image print image.__file__ which told me the wrong image module had been found. It would be nice if ImportError announced this up front: ImportError: cannot import name annotate from /usr//image.pyc ================================================== I got a bit of encouragement, and a patch from Wojtek Walczak http://www.stud.umk.pl/~wojtekwa/patches/from-import-py2.5.1.patch a bit more encouragement: "I think the acceptance for this wouldn't be that hard since there is no real issue for regression (the only one I could think of is for doctest module, although I'm not sure there are any reason to test for failed import in doctest)" and a caveat: "I have code that uses numpy if available, otherwise uses slower normal Python code. Inside the doctests I'd like to test both situations..." I can't write the C code myself, or evaluate the patch. I think this change might save some other poor schlub the time I've spent fussing with this issue. Thanks, Kent From barry at python.org Tue Aug 19 16:16:52 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 19 Aug 2008 10:16:52 -0400 Subject: [Python-Dev] [Python-3000] Beta 3 planned for this Wednesday In-Reply-To: <1afaf6160808190602u8c00856oe08d76a198a6c382@mail.gmail.com> References: <20080818232950.5f234f31@resist.wooz.org> <1afaf6160808190602u8c00856oe08d76a198a6c382@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 19, 2008, at 9:02 AM, Benjamin Peterson wrote: > On Mon, Aug 18, 2008 at 10:29 PM, Barry Warsaw > wrote: >> >> 1878 class attribute cache failure (regression) >> - - Medium priority >> - - Guido, there are some design choices that need your decision. >> I'd like to >> fix this for beta 3 if it's going to be fixed at all, because I >> suspect the >> changes will be too disruptive once we reach release candidates. >> >> 2394 [Py3k] Finish the memoryview object implementation >> - - High priority >> - - This one is serious enough to hold up the release. I really do >> not think we >> should be finishing this implementation in the rc phase. > > How finished is finished? I see Antoine has implemented a little > more of it. The API needs to be completed. If there are bugs, that's fine but we need to stabilize the API by the release candidate. I just followed up on the issues and it looks like Antoine has a good handle on this. >> 1179 [CVE-2007-4965] Integer overflow in imageop module >> - - High priority >> - - This will block final release and I think it needs to be fixed >> for this beta. > > I've never used imageop, but I'll see if I can review the patch. Great, thanks! >> 3131 2to3 can't find fixes_dir >> - - Medium priority >> - - I'm willing to defer this to the release candidates, but it >> will definitely >> block the release candidates. > > This is pretty simple. There are patches that can be applied, but I > think 2to3 requires a little refactoring. I suppose that can be done > after the beta, though. Yep, but it should be done before rc1. >> 3402 test_nis is hanging on Solaris >> - - Medium priority >> - - I suggest disabling this test and adding a note to the release >> notes. If >> nobody comes forward to fix it for the final release, tough. >> >> 3352 Deficiencies in multiprocessing/threading API >> - - Medium priority >> - - This one is getting some love, so I'm confident this will get >> fixed before >> beta 3. > > Jesse said he could have it done today. Excellent. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKrV1nEjvBPtnXfVAQLtXgP9HiHfxtbCPojQ1r6oMeou+7iWcedoBROL BhtEEDxp74X8Bnnu8IfONMvQRL3I9wrktm6AztCKN8o9ZEAY5IlcFD4ICKM8f6My kU5P6/ffJL7DgMyZSHh2w8p9lafNeH8tH1twy1hRWmh+jq8hkp1pgipYBCVqzSzp iO3fKdhIGXk= =IpIE -----END PGP SIGNATURE----- From jnoller at gmail.com Tue Aug 19 16:51:41 2008 From: jnoller at gmail.com (Jesse Noller) Date: Tue, 19 Aug 2008 10:51:41 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <7801D1D8-B938-4523-8167-D405BA0192F6@acm.org> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <48AA25A8.6060101@holdenweb.com> <1699.92.83.146.25.1219131943.squirrel@mail2.webfaction.com> <7801D1D8-B938-4523-8167-D405BA0192F6@acm.org> Message-ID: <4222a8490808190751j4ad805cicfdb41d2a5fdbdfa@mail.gmail.com> On Tue, Aug 19, 2008 at 8:51 AM, Fred Drake wrote: > On Aug 19, 2008, at 3:45 AM, fuzzyman at mail2.webfaction.com wrote: >> >> I *thought* (relative Mac newbie), the standard advice was that if you >> want to install extension modules then you should install your own version >> of Python and not mess with the system version. > > My understanding is that if there is a system Python, you shouldn't change > it. Ever. > > System Python's are for other components of the system; you can use them, > but shouldn't modify them. Including installing or updating packages in the > site-packages directory. > > At Zope Corporation, we use a clean Python for all development and > deployments. Nothing gets installed into the site-packages, because > different applications want different packages (or different versions), and > we want to deploy with what we test with. > >> Meaning that you have to maintain two Python installs - something that >> hasn't been a problem for me yet. So even if Mac OS ships with Python 2.6, >> many users will still want to install their own version. > > Indeed. I've never had to do anything to maintain the system Python on Mac > OS X. It's there, Mac OS X does what it will with it, and I use my private > (and squeaky clean!) Python installations. > > > -Fred > > -- > Fred Drake Just to add to this - with the advent of PEP 370[1], we now have the ability to use per-user site-packages directories. This neatly sidesteps the problem (for the most part) of tainting the system installations of python directly. As for the Mac issue - as a mac user/developer - I only install "big ticket" packages into the system path - for everything else, I either use virtualenv.py, a custom python install or the PYTHONPATH overrides. I've personally *never* used a python distribution from macports or fink - if I need a custom build, I'll do it myself, rather than install something into the /opt/ tree macports uses - I've had too many issues with library/binary conflicts with the pre-installed libraries/tools from twiddling with PATH and LD_LIBRARY_PATH to add the /opt tree to my environment in order to get compiles/tools to play nice. -Jesse [1] http://www.python.org/dev/peps/pep-0370/ From fdrake at acm.org Tue Aug 19 17:00:39 2008 From: fdrake at acm.org (Fred Drake) Date: Tue, 19 Aug 2008 11:00:39 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <4222a8490808190751j4ad805cicfdb41d2a5fdbdfa@mail.gmail.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <48AA25A8.6060101@holdenweb.com> <1699.92.83.146.25.1219131943.squirrel@mail2.webfaction.com> <7801D1D8-B938-4523-8167-D405BA0192F6@acm.org> <4222a8490808190751j4ad805cicfdb41d2a5fdbdfa@mail.gmail.com> Message-ID: [Removed pydotorg from the recipients; this has nothing to do with the website.] On Aug 19, 2008, at 10:51 AM, Jesse Noller wrote: > Just to add to this - with the advent of PEP 370[1], we now have the > ability to use per-user site-packages directories. This neatly > sidesteps the problem (for the most part) of tainting the system > installations of python directly. True. This can help with newer Pythons. It doesn't really deal with having multiple Python versions, IIRC. > As for the Mac issue - as a mac user/developer - I only install "big > ticket" packages into the system path - for everything else, I either > use virtualenv.py, a custom python install or the PYTHONPATH > overrides. I've no idea what a "big ticket" package would be. Using zc.buildout nicely sidesteps any issues of installing into the Python installation, and caches expensive builds. > I've personally *never* used a python distribution from macports or > fink - if I need a custom build, I'll do it myself, rather than > install something into the /opt/ tree macports uses - I've had too > many issues with library/binary conflicts with the pre-installed > libraries/tools from twiddling with PATH and LD_LIBRARY_PATH to add > the /opt tree to my environment in order to get compiles/tools to play > nice. I'd go so far as to say that any reliance on LD_LIBRARY_PATH is a bad idea, since it's horribly fragile. But I do link in the readline from macports. -Fred -- Fred Drake From aahz at pythoncraft.com Tue Aug 19 17:05:12 2008 From: aahz at pythoncraft.com (Aahz) Date: Tue, 19 Aug 2008 08:05:12 -0700 Subject: [Python-Dev] ImportError message suggestion In-Reply-To: References: Message-ID: <20080819150511.GA2373@panix.com> On Tue, Aug 19, 2008, Kent Tenney wrote: > > I can't write the C code myself, or evaluate the patch. Maybe not, but maybe you can upload them to the bug tracker -- that's the only way this will get looked at. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ Adopt A Process -- stop killing all your children! From ncoghlan at gmail.com Tue Aug 19 17:46:14 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 20 Aug 2008 01:46:14 +1000 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> <67B54E00-976A-459B-937A-11B35CF4805E@acm.org> Message-ID: <48AAEAC6.10702@gmail.com> Brett Cannon wrote: > On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake wrote: >> On Aug 18, 2008, at 2:43 PM, Antoine Pitrou wrote: >>> If it's about silencing warnings, then how about putting it in the >>> warnings >>> module? >> >> That sounds good to me, and would be very reasonable. This would make a >> nice context manager. >> > > That works for me as well; just move catch_warning() to 'warnings' and > leave test.test_support as-is. If we did that, though, I would want to > make 'record' False by default so that it had more reasonable defaults > for non-testing purposes. Moving this single context manager over to warnings definitely makes more sense to me than moving the whole test_support module. It would also be easy enough to add a "catch_warning" factory function in test_support that switched the default back to record=True so we didn't have to change all of the invocations in the test suite. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From matt.giuca at gmail.com Tue Aug 19 19:04:37 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Wed, 20 Aug 2008 03:04:37 +1000 Subject: [Python-Dev] ImportError message suggestion In-Reply-To: References: Message-ID: > ImportError: cannot import name annotate from /usr//image.pyc That could be handy. Not sure it's necessary, however, and exposes some system information in the error message. I can imagine a web app which prints out exception messages, and this would mean the server file structure is printed to the world (though arguably you should not be doing this on your web app, I work on an open source web app and we do dump tracebacks to our users sometimes -- because it's open source we don't mind them seeing the code -- but we'd rather not have them see our server details). If you do get this issue (as a developer), I find the built-in help() function very handy -- you can import a module then go help(that_module) and it tells you the absolute path to the module. That might be a sufficient alternative to this patch (though requiring a bit more manual labour). So I am neither for nor against this suggestion. "I think the acceptance for this wouldn't be that hard since there is > no real issue for regression (the only one I could think of is for > doctest module, although I'm not sure there are any reason to test for > failed import in doctest)" I agree. (I'm more familiar with unittest than doctest, where you'd just use assertRaises(ImportError, ...) and not care what the exception message is -- is there any way in doctest to check for the exception type without caring about the message?) I can't write the C code myself, or evaluate the patch. > Go to http://bugs.python.org/ and add a new issue. Upload the patch as an attachment when you enter the issue description. I think you'll have to put it down as a feature request for 2.7/3.1, since the beta tomorrow will mean no more features in 2.6/3.0. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From janssen at parc.com Tue Aug 19 19:13:53 2008 From: janssen at parc.com (Bill Janssen) Date: Tue, 19 Aug 2008 10:13:53 PDT Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <48AA25A8.6060101@holdenweb.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> <48AA25A8.6060101@holdenweb.com> Message-ID: <08Aug19.101358pdt."58698"@synergy1.parc.xerox.com> > I've certainly heard many tales of Mac users coming to grief because > they decided to overwrite their system Python, or tried to be clever and > run multiple interpreters (which is usually somewhat less disastrous). > > I guess this underlines the fact that Apple don't really want the hoi > polloi tinkering with their systems; it's somewhat tedious when code is > released for later Python versions and you have to privately backport, > though, isn't it? I build lots of different versions of Python on my Macs, and it all works fine. I think people run into trouble when they try to "replace" the system Python, in one way or another, for general use. But if you want to bundle a different Python version in an app, or in a framework-private bundle, it seems to be fine. > There have been hints dropped that if the 2.6 release hits its deadline > it will be incorporated into vendor builds. Let's hope one of them is > MacOS, then at least it'll be relatively up to date. Hah! After spending years with Python 2.3 (for OS X 10.4), 2.5.1 is a breath of fresh air. Bill From matt.giuca at gmail.com Tue Aug 19 19:17:37 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Wed, 20 Aug 2008 03:17:37 +1000 Subject: [Python-Dev] ImportError message suggestion In-Reply-To: References: Message-ID: I think this is not the place to be discussing the patch (the tracker is), but while I think of it, I'll just say: You need to DECREF the fn variable (both PyObject_GetAttrStringand PyString_FromString return new references). If this makes no sense, read up on reference counting (http://docs.python.org/ext/refcounts.html, http://www.python.org/doc/api/countingRefs.html). .... + PyString_AsString(name), + PyString_AsString(fn)); + Py_DECREF(fn); } Also: - Do you really want "?" if you can't get the filename for some reason -- why not just not say anything? - Perhaps don't create a new variable "fn", use one of the many defined at the top of the eval function. Otherwise, looks like it will do the job. But I haven't tested it, just eyeballed it. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Tue Aug 19 19:25:35 2008 From: guido at python.org (Guido van Rossum) Date: Tue, 19 Aug 2008 10:25:35 -0700 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: <48AAEAC6.10702@gmail.com> References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> <67B54E00-976A-459B-937A-11B35CF4805E@acm.org> <48AAEAC6.10702@gmail.com> Message-ID: On Tue, Aug 19, 2008 at 8:46 AM, Nick Coghlan wrote: > Brett Cannon wrote: >> On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake wrote: >>> On Aug 18, 2008, at 2:43 PM, Antoine Pitrou wrote: >>>> If it's about silencing warnings, then how about putting it in the >>>> warnings >>>> module? >>> >>> That sounds good to me, and would be very reasonable. This would make a >>> nice context manager. >>> >> >> That works for me as well; just move catch_warning() to 'warnings' and >> leave test.test_support as-is. If we did that, though, I would want to >> make 'record' False by default so that it had more reasonable defaults >> for non-testing purposes. > > Moving this single context manager over to warnings definitely makes > more sense to me than moving the whole test_support module. Works for me. > It would also be easy enough to add a "catch_warning" factory function > in test_support that switched the default back to record=True so we > didn't have to change all of the invocations in the test suite. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From janssen at parc.com Tue Aug 19 19:28:20 2008 From: janssen at parc.com (Bill Janssen) Date: Tue, 19 Aug 2008 10:28:20 PDT Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <92D5F670-B4F5-4D0E-A64B-92B8DAAC0C2E@python.org> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> <48AA25A8.6060101@holdenweb.com> <1699.92.83.146.25.1219131943.squirrel@mail2.webfaction.com> <7801D1D8-B938-4523-8167-D405BA0192F6@acm.org> <92D5F670-B4F5-4D0E-A64B-92B8DAAC0C2E@python.org> Message-ID: <08Aug19.102823pdt."58698"@synergy1.parc.xerox.com> > > My understanding is that if there is a system Python, you shouldn't > > change it. Ever. > > Huge, big, honkin' +1 from me on that. Besides, for a system Python, > you want your distribution to manage packages, not setuptools, > otherwise you confuse -- and probably break -- your system. I find this discussion fascinating. I install new packages into my system Python all the time, with "/usr/bin/python setup.py install", and that includes setuptools. I've got PIL, ReportLab, Twisted, Xlib, appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen, roman, setuptools, and SSL installed in the Leopard machine I'm writing from. They don't wind up in /System/Library/.../site-packages/, they wind up in /Library/Python/2.5/site-packages/, which is sort of the right place, from an Apple point of view. I do this on lots of Macs -- I've got a regular posse of them at work. And I've never had any problems with it. I agree that there are some things I'd be very wary of installing into the system Python, like PyObjC, and Zope. Usually, I don't install anything which appears to already be there. Bill From barry at python.org Tue Aug 19 19:45:04 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 19 Aug 2008 13:45:04 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <08Aug19.102823pdt."58698"@synergy1.parc.xerox.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> <48AA25A8.6060101@holdenweb.com> <1699.92.83.146.25.1219131943.squirrel@mail2.webfaction.com> <7801D1D8-B938-4523-8167-D405BA0192F6@acm.org> <92D5F670-B4F5-4D0E-A64B-92B8DAAC0C2E@python.org> <08Aug19.102823pdt."58698"@synergy1.parc.xerox.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 19, 2008, at 1:28 PM, Bill Janssen wrote: >>> My understanding is that if there is a system Python, you shouldn't >>> change it. Ever. >> >> Huge, big, honkin' +1 from me on that. Besides, for a system Python, >> you want your distribution to manage packages, not setuptools, >> otherwise you confuse -- and probably break -- your system. > > I find this discussion fascinating. I install new packages into my > system Python all the time, with "/usr/bin/python setup.py install", > and that includes setuptools. I've got PIL, ReportLab, Twisted, Xlib, > appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen, > roman, setuptools, and SSL installed in the Leopard machine I'm > writing from. They don't wind up in > /System/Library/.../site-packages/, they wind up in > /Library/Python/2.5/site-packages/, which is sort of the right place, > from an Apple point of view. I do this on lots of Macs -- I've got a > regular posse of them at work. And I've never had any problems with > it. > > I agree that there are some things I'd be very wary of installing into > the system Python, like PyObjC, and Zope. Usually, I don't install > anything which appears to already be there. It probably affects OS X and Windows less than Linux distros like Gentoo or Ubuntu because the former don't heavily rely on the system python for their basic operation. You can pretty royally screw up the latter if your Python environment isn't just right. I think it's a /good/ thing that some OS distros are heavily invested in Python for their core operation. We just need to understand the best practices when they are. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKsGoHEjvBPtnXfVAQLvoQP+K4DPZ2XyBZIR6IY9Tnf2c8hUm7+MNaVh o6J0qLDm7XFVtQw6OhWd6zzRMLswFV86yojGvXb/rM8dwF8zIjrw4HZguIBxSIq8 e88zSNr713lTN/ds394bPkTC323+7QJEA/JOYNztAw2SUlvP7r1o67RDVptxlSvq vrtb3VNl+7A= =U4jT -----END PGP SIGNATURE----- From brett at python.org Tue Aug 19 20:31:47 2008 From: brett at python.org (Brett Cannon) Date: Tue, 19 Aug 2008 11:31:47 -0700 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: <48AAEAC6.10702@gmail.com> References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> <67B54E00-976A-459B-937A-11B35CF4805E@acm.org> <48AAEAC6.10702@gmail.com> Message-ID: On Tue, Aug 19, 2008 at 8:46 AM, Nick Coghlan wrote: > Brett Cannon wrote: >> On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake wrote: >>> On Aug 18, 2008, at 2:43 PM, Antoine Pitrou wrote: >>>> If it's about silencing warnings, then how about putting it in the >>>> warnings >>>> module? >>> >>> That sounds good to me, and would be very reasonable. This would make a >>> nice context manager. >>> >> >> That works for me as well; just move catch_warning() to 'warnings' and >> leave test.test_support as-is. If we did that, though, I would want to >> make 'record' False by default so that it had more reasonable defaults >> for non-testing purposes. > > Moving this single context manager over to warnings definitely makes > more sense to me than moving the whole test_support module. > > It would also be easy enough to add a "catch_warning" factory function > in test_support that switched the default back to record=True so we > didn't have to change all of the invocations in the test suite. > Right; just have a simple wrapper in test.test_support that had a different default. I will get to this when I can, although I am sure Barry won't be too upset if this misses b3. -Brett From barry at python.org Tue Aug 19 21:05:26 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 19 Aug 2008 15:05:26 -0400 Subject: [Python-Dev] Why does httplib import from test_support? In-Reply-To: References: <18601.22584.469957.920301@montanaro-dyndns-org.local> <48A95E7D.1010002@gmail.com> <67B54E00-976A-459B-937A-11B35CF4805E@acm.org> <48AAEAC6.10702@gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 19, 2008, at 2:31 PM, Brett Cannon wrote: > On Tue, Aug 19, 2008 at 8:46 AM, Nick Coghlan > wrote: >> Brett Cannon wrote: >>> On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake wrote: >>>> On Aug 18, 2008, at 2:43 PM, Antoine Pitrou wrote: >>>>> If it's about silencing warnings, then how about putting it in the >>>>> warnings >>>>> module? >>>> >>>> That sounds good to me, and would be very reasonable. This would >>>> make a >>>> nice context manager. >>>> >>> >>> That works for me as well; just move catch_warning() to 'warnings' >>> and >>> leave test.test_support as-is. If we did that, though, I would >>> want to >>> make 'record' False by default so that it had more reasonable >>> defaults >>> for non-testing purposes. >> >> Moving this single context manager over to warnings definitely makes >> more sense to me than moving the whole test_support module. >> >> It would also be easy enough to add a "catch_warning" factory >> function >> in test_support that switched the default back to record=True so we >> didn't have to change all of the invocations in the test suite. >> > > Right; just have a simple wrapper in test.test_support that had a > different default. > > I will get to this when I can, although I am sure Barry won't be too > upset if this misses b3. Nope. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKsZd3EjvBPtnXfVAQLGRAQAhVwJLkwi/+ZlW7x53sKyyMEf+pJj7UTK l0MjS/JFXlDmW5uBg9VnKbSrdMnbQPwHIhA1Xl20Pz3qV4mPTdrD6+pVuwyBQJj6 rakN6wtjvYMq3S3cDIZIabbaqx05XT5+mqWA+2fIc7/mzHboORtJmfAlE/Tjr4/P TR7TgSqryzQ= =TCYz -----END PGP SIGNATURE----- From guido at python.org Tue Aug 19 22:19:37 2008 From: guido at python.org (Guido van Rossum) Date: Tue, 19 Aug 2008 13:19:37 -0700 Subject: [Python-Dev] [Python-3000] Beta 3 planned for this Wednesday In-Reply-To: <20080818232950.5f234f31@resist.wooz.org> References: <20080818232950.5f234f31@resist.wooz.org> Message-ID: On Mon, Aug 18, 2008 at 8:29 PM, Barry Warsaw wrote: > 1878 class attribute cache failure (regression) > - - Medium priority > - - Guido, there are some design choices that need your decision. I'd like to > fix this for beta 3 if it's going to be fixed at all, because I suspect the > changes will be too disruptive once we reach release candidates. Resolved, see r65874. > 2394 [Py3k] Finish the memoryview object implementation > - - High priority > - - This one is serious enough to hold up the release. I really do not think we > should be finishing this implementation in the rc phase. Can someone review Antoine's patch at http://codereview.appspot.com/3004 ? It's above my head. > 1179 [CVE-2007-4965] Integer overflow in imageop module > - - High priority > - - This will block final release and I think it needs to be fixed for this beta. I'll look into this. Didn't we have a patch? -- --Guido van Rossum (home page: http://www.python.org/~guido/) From Jack.Jansen at cwi.nl Tue Aug 19 22:36:34 2008 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue, 19 Aug 2008 22:36:34 +0200 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <08Aug19.102823pdt."58698"@synergy1.parc.xerox.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <08Aug18.181830pdt."58698"@synergy1.parc.xerox.com> <48AA25A8.6060101@holdenweb.com> <1699.92.83.146.25.1219131943.squirrel@mail2.webfaction.com> <7801D1D8-B938-4523-8167-D405BA0192F6@acm.org> <92D5F670-B4F5-4D0E-A64B-92B8DAAC0C2E@python.org> <08Aug19.102823pdt."58698"@synergy1.parc.xerox.com> Message-ID: On 19-Aug-2008, at 19:28 , Bill Janssen wrote: >>> My understanding is that if there is a system Python, you shouldn't >>> change it. Ever. >> >> Huge, big, honkin' +1 from me on that. Besides, for a system Python, >> you want your distribution to manage packages, not setuptools, >> otherwise you confuse -- and probably break -- your system. > > I find this discussion fascinating. I install new packages into my > system Python all the time, with "/usr/bin/python setup.py install", > and that includes setuptools. I've got PIL, ReportLab, Twisted, Xlib, > appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen, > roman, setuptools, and SSL installed in the Leopard machine I'm > writing from. They don't wind up in > /System/Library/.../site-packages/, they wind up in > /Library/Python/2.5/site-packages/, which is sort of the right place, > from an Apple point of view. I do this on lots of Macs -- I've got a > regular posse of them at work. And I've never had any problems with > it. Same here: if have yet to see adverse consequences of installing third party packages into system Python. And now that Apple is distributing fairly current versions of things like PyObjC there's even little reason to build my own copy of Python. I have one on disk, but I find that I use the system Python for almost everything. Fink (and to a lesser extent MacPorts) I don't touch with a 10 feet pole: too often I've created software for distribution only to find that it somehow, behind my back, was linked against a dynamic library that I had installed locally through it. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnoller at gmail.com Tue Aug 19 22:44:00 2008 From: jnoller at gmail.com (Jesse Noller) Date: Tue, 19 Aug 2008 16:44:00 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? In-Reply-To: <6626084533285733447@unknownmsgid> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <48A9ECDD.5050206@holdenweb.com> <4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com> <48AA25A8.6060101@holdenweb.com> <1699.92.83.146.25.1219131943.squirrel@mail2.webfaction.com> <7801D1D8-B938-4523-8167-D405BA0192F6@acm.org> <92D5F670-B4F5-4D0E-A64B-92B8DAAC0C2E@python.org> <6626084533285733447@unknownmsgid> Message-ID: <4222a8490808191344y6af0b4a3pe7f99dcd263e162e@mail.gmail.com> On Tue, Aug 19, 2008 at 1:28 PM, Bill Janssen wrote: >> > My understanding is that if there is a system Python, you shouldn't >> > change it. Ever. >> >> Huge, big, honkin' +1 from me on that. Besides, for a system Python, >> you want your distribution to manage packages, not setuptools, >> otherwise you confuse -- and probably break -- your system. > > I find this discussion fascinating. I install new packages into my > system Python all the time, with "/usr/bin/python setup.py install", > and that includes setuptools. I've got PIL, ReportLab, Twisted, Xlib, > appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen, > roman, setuptools, and SSL installed in the Leopard machine I'm > writing from. They don't wind up in > /System/Library/.../site-packages/, they wind up in > /Library/Python/2.5/site-packages/, which is sort of the right place, > from an Apple point of view. I do this on lots of Macs -- I've got a > regular posse of them at work. And I've never had any problems with > it. > > I agree that there are some things I'd be very wary of installing into > the system Python, like PyObjC, and Zope. Usually, I don't install > anything which appears to already be there. > > Bill Bill is correct - using /usr/bin/python does install packages to /Library/... - this is sort of the right place because it still installs it to a "system path", where it can side-effect other users, but it is a "mostly correct" way for Apple framework installs. From guido at python.org Tue Aug 19 23:03:11 2008 From: guido at python.org (Guido van Rossum) Date: Tue, 19 Aug 2008 14:03:11 -0700 Subject: [Python-Dev] [Python-3000] Beta 3 planned for this Wednesday In-Reply-To: References: <20080818232950.5f234f31@resist.wooz.org> Message-ID: On Tue, Aug 19, 2008 at 1:19 PM, Guido van Rossum wrote: >> 1179 [CVE-2007-4965] Integer overflow in imageop module >> - - High priority >> - - This will block final release and I think it needs to be fixed for this beta. Submitted the patch to 2.5 and 2.6. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From jnoller at gmail.com Tue Aug 19 23:06:49 2008 From: jnoller at gmail.com (Jesse Noller) Date: Tue, 19 Aug 2008 17:06:49 -0400 Subject: [Python-Dev] [Python-3000] Beta 3 planned for this Wednesday In-Reply-To: <20080818232950.5f234f31@resist.wooz.org> References: <20080818232950.5f234f31@resist.wooz.org> Message-ID: <4222a8490808191406r3f002916o7e9f02ea200988c@mail.gmail.com> > 3352 Deficiencies in multiprocessing/threading API > - - Medium priority > - - This one is getting some love, so I'm confident this will get fixed before > beta 3. > This is complete on 2.6 as of r65864 From barry at python.org Thu Aug 21 00:45:06 2008 From: barry at python.org (Barry Warsaw) Date: Wed, 20 Aug 2008 18:45:06 -0400 Subject: [Python-Dev] Releasing beta 3's tonight Message-ID: <4FEA536F-45BC-4EA2-8806-71B721A45350@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pending a resolution of bug 3611 (which has an attached patch that we're testing now), I plan on releasing 2.6 and 3.0 beta 3 tonight. Please do not make any commits to the trees unless you ask me first, until further notice. I am on #python-dev if you need an immediate decision. Thanks. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKyecnEjvBPtnXfVAQJ4DgQAg7hNzp76nUT8/dA4C2xTqwL+mmtXeu2s MLbez1xVk3IoU3J/GRRcposaUQKoPToophndj1yk57v/g/AtrXIAjFRXkqH7giU5 eD7WltOt3Ch/f6ZBkT9eHttq9uaQB35kKcCPNUSL81C24xn8z7JS08KG+6bgx1hE g0tYCMAj7Wk= =tomA -----END PGP SIGNATURE----- From barry at python.org Thu Aug 21 02:25:15 2008 From: barry at python.org (Barry Warsaw) Date: Wed, 20 Aug 2008 20:25:15 -0400 Subject: [Python-Dev] 2.6 on Windows Message-ID: <20080820202515.5f1a006b@resist.wooz.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can anybody verify and hopefully fix the problems seen in the Windows bots for the trunk (i.e. 2.6)? http://www.python.org/dev/buildbot/stable/ 3.0 doesn't look too bad, and I'm going to release beta 3 anyway, but I hope we can get the 2.6 Windows buildbots looking green after the beta. These will definitely block the release candidates. Thanks, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIrLXw2YZpQepbvXERAkn7AJwNNoq+ApgeP/j8TyPL4x71SPju5QCePzdw KC5QXa1Tk72OSTmQIelU2hs= =zYog -----END PGP SIGNATURE----- From mhammond at skippinet.com.au Thu Aug 21 04:37:43 2008 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu, 21 Aug 2008 12:37:43 +1000 Subject: [Python-Dev] Python 2.6 on AMD64 recusion crash Message-ID: <016201c90336$ea16cd50$be4467f0$@com.au> While looking at 2.6 for Windows, I've found a recursion related crash in test_cpickle on 64bit builds. Specifically, the 'cPickleDeepRecursive' is causing a stack overflow, and the debugger tells me the actual recursion depth was 629 at the crash. The reason the 64bit build doesn't see more crashes is apparently due to another regression in 2.6 - http://bugs.python.org/issue3373. It appears that in some cases, the recursion counter is actually incremented *twice* for each entry, thereby causing the "maximum recursion depth exceeded" exception to appear at a true recusion limit of 500. However, test_cpickle takes a different path and doesn't see this doubling of the count - therefore dieing at the depth of 629 that I can see. My solution to this was to simply double the stack size for the executables in 64bit builds, from 2MB to 4MB (2.1 and 4.2 for debug builds.) Is this an appropriate fix? Cheers, Mark From barry at python.org Thu Aug 21 05:17:15 2008 From: barry at python.org (Barry Warsaw) Date: Wed, 20 Aug 2008 23:17:15 -0400 Subject: [Python-Dev] RELEASED Python 2.6b3 and 3.0b3 Message-ID: <20080820231715.57fde07f@resist.wooz.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team and the Python community, I am happy to announce the third and last planned beta releases of Python 2.6 and Python 3.0. Please note that these are beta releases, and as such are not suitable for production environments. We continue to strive for a high degree of quality, and these releases are intended to freeze the feature set for Python 2.6 and 3.0. As these are the last planned beta releases, we strongly urge you to download these releases and test them against your code. Once we reach release candidates (currently planned for 03-Sep-2008), only highly critical bugs will be fixed before the final release. If you find things broken or incorrect, please submit bug reports at http://bugs.python.org For more information and downloadable distributions, see the Python 2.6 website: http://www.python.org/download/releases/2.6/ and the Python 3.0 web site: http://www.python.org/download/releases/3.0/ See PEP 361 for release schedule details: http://www.python.org/dev/peps/pep-0361/ Enjoy, - -Barry Barry Warsaw barry at python.org Python 2.6/3.0 Release Manager (on behalf of the entire python-dev team) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIrN472YZpQepbvXERAl4fAJ9QxHhSn/jYdA3lCYvgfXRhBVV2pgCfdNUx 3NTlSrsSULxXhoMqiNmUMSg= =Z4+y -----END PGP SIGNATURE----- From mhammond at skippinet.com.au Thu Aug 21 05:32:52 2008 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu, 21 Aug 2008 13:32:52 +1000 Subject: [Python-Dev] 2.6 on Windows In-Reply-To: <20080820202515.5f1a006b@resist.wooz.org> References: <20080820202515.5f1a006b@resist.wooz.org> Message-ID: <017501c9033e$9accf9b0$d066ed10$@com.au> > Can anybody verify and hopefully fix the problems seen in the Windows > bots for the trunk (i.e. 2.6)? FWIW, I can't reproduce most of those problems. My 32bit build sees: 303 tests OK. 57 tests skipped: test__locale test_aepack test_al test_applesingle test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_commands test_crypt test_curses test_dbm test_dl test_epoll test_fcntl test_fork1 test_gdbm test_gl test_grp test_imageop test_imgfile test_ioctl test_kqueue test_largefile test_linuxaudiodev test_macos test_macostools test_mhlib test_nis test_normalization test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_py3kwarn test_resource test_scriptpackages test_signal test_socketserver test_ssl test_sunaudiodev test_tcl test_threadsignals test_timeout test_urllib2net test_urllibnet test_wait3 test_wait4 test_zipfile64 2 skips unexpected on win32: test_tcl test_ssl and once I made the changes I just uploaded to http://bugs.python.org/issue3625 (which are just tweaks to skip certain tests on win64), a 64bit build reports: 303 tests OK. 57 tests skipped: test__locale test_aepack test_al test_applesingle test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_commands test_crypt test_curses test_dbm test_dl test_epoll test_fcntl test_fork1 test_gdbm test_gl test_grp test_imageop test_imgfile test_ioctl test_kqueue test_largefile test_linuxaudiodev test_macos test_macostools test_mhlib test_nis test_normalization test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_py3kwarn test_resource test_scriptpackages test_signal test_socketserver test_ssl test_sunaudiodev test_tcl test_threadsignals test_timeout test_urllib2net test_urllibnet test_wait3 test_wait4 test_zipfile64 2 skips unexpected on win32: test_tcl test_ssl Which is the best state I've ever managed to get the 64bit build to. Note however that bsddb3 was skipped by my tests. Running that test alone, both platforms report the same error as the buildbot: FAIL: test01_basic_replication (bsddb.test.test_replication.DBReplicationManager) ---------------------------------------------------------------------- Traceback (most recent call last): File "o:\src\python-svn-amd64\lib\bsddb\test\test_replication.py", line 134, in test01_basic_replication self.assertTrue(time.time() References: <20080820202515.5f1a006b@resist.wooz.org> <017501c9033e$9accf9b0$d066ed10$@com.au> Message-ID: <41945CC0-1FAC-44EE-801C-C127D877B887@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Which is the best state I've ever managed to get the 64bit build to. > > Note however that bsddb3 was skipped by my tests. Running that test > alone, > both platforms report the same error as the buildbot: > > FAIL: test01_basic_replication > (bsddb.test.test_replication.DBReplicationManager) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "o:\src\python-svn-amd64\lib\bsddb\test\test_replication.py", > line > 134, in test01_basic_replication > self.assertTrue(time.time() AssertionError > > However, the error appears after a number of seconds of inactivity - > so I > suspect it has nothing to do with the timer resolution on Windows > and more > about the fact that the test really did fail. > > So while I'm not sure what else the buildbot is seeing, the only real > problem seems exactly 1 test in the bsddb3 tests. Thanks Mark. If we can't get bsddb3 running cleanly, we'll have to add an item to the release notes about it. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSK1fgHEjvBPtnXfVAQLu2wP8D5dBf6wAeGgOgK49FPDhN+5hvcrlp4KT pMJTD161e21+XdgzY0pohWWPXiUnpUuJduuUTpVOfbi73kpDJakExDWqL7T3D4T+ CtNPxnoTZlv/AkrYwQfc0qKdWGn82uAiH8j6C6xMqtxNMgWCHjhD1z9w1eOssLRt +r9MfRCLRqs= =XXlj -----END PGP SIGNATURE----- From musiccomposition at gmail.com Thu Aug 21 15:33:34 2008 From: musiccomposition at gmail.com (Benjamin Peterson) Date: Thu, 21 Aug 2008 08:33:34 -0500 Subject: [Python-Dev] RELEASED Python 2.6b3 and 3.0b3 In-Reply-To: <20080820231715.57fde07f@resist.wooz.org> References: <20080820231715.57fde07f@resist.wooz.org> Message-ID: <1afaf6160808210633k1ba326ber2bd87eda693f13f5@mail.gmail.com> And this release, the special award for making it possible goes to Antoine Pitrou for quick and accurate work on the memoryview implementation. [Resounding Applause] On Wed, Aug 20, 2008 at 10:17 PM, Barry Warsaw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On behalf of the Python development team and the Python community, I am happy > to announce the third and last planned beta releases of Python 2.6 and Python > 3.0. > > Please note that these are beta releases, and as such are not suitable for > production environments. We continue to strive for a high degree of quality, > and these releases are intended to freeze the feature set for Python 2.6 and > 3.0. > > As these are the last planned beta releases, we strongly urge you to download > these releases and test them against your code. Once we reach release > candidates (currently planned for 03-Sep-2008), only highly critical bugs will > be fixed before the final release. > > If you find things broken or incorrect, please submit bug reports at > > http://bugs.python.org > > For more information and downloadable distributions, see the Python > 2.6 website: > > http://www.python.org/download/releases/2.6/ > > and the Python 3.0 web site: > > http://www.python.org/download/releases/3.0/ > > See PEP 361 for release schedule details: > > http://www.python.org/dev/peps/pep-0361/ > > Enjoy, > - -Barry > > Barry Warsaw > barry at python.org > Python 2.6/3.0 Release Manager > (on behalf of the entire python-dev team) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIrN472YZpQepbvXERAl4fAJ9QxHhSn/jYdA3lCYvgfXRhBVV2pgCfdNUx > 3NTlSrsSULxXhoMqiNmUMSg= > =Z4+y > -----END PGP SIGNATURE----- > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." From cesare.dimauro at a-tono.com Thu Aug 21 16:09:16 2008 From: cesare.dimauro at a-tono.com (Cesare Di Mauro) Date: Thu, 21 Aug 2008 16:09:16 +0200 Subject: [Python-Dev] RELEASED Python 2.6b3 and 3.0b3 In-Reply-To: <1afaf6160808210633k1ba326ber2bd87eda693f13f5@mail.gmail.com> References: <20080820231715.57fde07f@resist.wooz.org> <1afaf6160808210633k1ba326ber2bd87eda693f13f5@mail.gmail.com> Message-ID: I've downloaded the Python 2.6b3 source, exported with svn all external packages as stated in PCBuild/Readme.txt, edited external.bat removing DEBUG=1, ran external.bat to get tcl/tk compiled, set "Release" on Visual C++ Express Edition 2008, and everything seemed to be worked out fine (on Vista Ultimate x64), but running python (both from VSC++ or by command prompt) and trying to import Tkinter I've got this: >>> import Tkinter Traceback (most recent call last): File "", line 1, in File "c:\tmp\Python-2.6b3\lib\lib-tk\Tkinter.py", line 38, in import FixTk File "c:\tmp\Python-2.6b3\lib\lib-tk\FixTk.py", line 28, in import _tkinter ImportError: DLL load failed: Impossibile trovare il modulo specificato. It seems that its impossible to find the _tkinter module, but in PCbuild I've found these files: 21/08/2008 10.35 636 _tkinter.exp 21/08/2008 10.35 1.732 _tkinter.lib 21/08/2008 10.35 338.944 _tkinter.pdb 21/08/2008 10.35 34.304 _tkinter.pyd 19/03/2008 08.45 9.569 _tkinter.vcproj 21/08/2008 10.33 2.577 _tkinter.vcproj.Conan.Cesare.user All other external packages (sqlite3, bsddb and socket.ssl) works well. Any idea? Cesare On Wed, Aug 20, 2008 at 10:17 PM, Barry Warsaw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On behalf of the Python development team and the Python community, I am happy > to announce the third and last planned beta releases of Python 2.6 and Python > 3.0. > > Please note that these are beta releases, and as such are not suitable for > production environments. We continue to strive for a high degree of quality, > and these releases are intended to freeze the feature set for Python 2.6 and > 3.0. > > As these are the last planned beta releases, we strongly urge you to download > these releases and test them against your code. Once we reach release > candidates (currently planned for 03-Sep-2008), only highly critical bugs will > be fixed before the final release. > > If you find things broken or incorrect, please submit bug reports at > > http://bugs.python.org > > For more information and downloadable distributions, see the Python > 2.6 website: > > http://www.python.org/download/releases/2.6/ > > and the Python 3.0 web site: > > http://www.python.org/download/releases/3.0/ > > See PEP 361 for release schedule details: > > http://www.python.org/dev/peps/pep-0361/ > > Enjoy, > - -Barry > > Barry Warsaw > barry at python.org > Python 2.6/3.0 Release Manager > (on behalf of the entire python-dev team) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIrN472YZpQepbvXERAl4fAJ9QxHhSn/jYdA3lCYvgfXRhBVV2pgCfdNUx > 3NTlSrsSULxXhoMqiNmUMSg= > =Z4+y > -----END PGP SIGNATURE----- > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > From curt at hagenlocher.org Thu Aug 21 17:34:56 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 21 Aug 2008 08:34:56 -0700 Subject: [Python-Dev] RELEASED Python 2.6b3 and 3.0b3 In-Reply-To: References: <20080820231715.57fde07f@resist.wooz.org> <1afaf6160808210633k1ba326ber2bd87eda693f13f5@mail.gmail.com> Message-ID: On Thu, Aug 21, 2008 at 7:09 AM, Cesare Di Mauro wrote: > >>>> import Tkinter > Traceback (most recent call last): > File "", line 1, in > File "c:\tmp\Python-2.6b3\lib\lib-tk\Tkinter.py", line 38, in > import FixTk > File "c:\tmp\Python-2.6b3\lib\lib-tk\FixTk.py", line 28, in > import _tkinter > ImportError: DLL load failed: Impossibile trovare il modulo specificato. > > It seems that its impossible to find the _tkinter module, but in PCbuild > I've found these files: > > 21/08/2008 10.35 34.304 _tkinter.pyd The most likely explanation for this is that _tkinter.pyd has a static dependency that can't be loaded. If, for instance, the TCL and TK DLLs themselves are neither in PCbuild nor elsewhere in the path, then you wouldn't be able to load _tkinter. -- Curt Hagenlocher curt at hagenlocher.org From cesare.dimauro at a-tono.com Thu Aug 21 18:21:42 2008 From: cesare.dimauro at a-tono.com (Cesare Di Mauro) Date: Thu, 21 Aug 2008 18:21:42 +0200 Subject: [Python-Dev] RELEASED Python 2.6b3 and 3.0b3 In-Reply-To: References: <20080820231715.57fde07f@resist.wooz.org> <1afaf6160808210633k1ba326ber2bd87eda693f13f5@mail.gmail.com> Message-ID: Thank you for the hint: it works. :) Cesare In data 21 agosto 2008 alle ore 17:34:56, Curt Hagenlocher ha scritto: > On Thu, Aug 21, 2008 at 7:09 AM, Cesare Di Mauro > wrote: >> >>>>> import Tkinter >> Traceback (most recent call last): >> File "", line 1, in >> File "c:\tmp\Python-2.6b3\lib\lib-tk\Tkinter.py", line 38, in >> import FixTk >> File "c:\tmp\Python-2.6b3\lib\lib-tk\FixTk.py", line 28, in >> import _tkinter >> ImportError: DLL load failed: Impossibile trovare il modulo specificato. >> >> It seems that its impossible to find the _tkinter module, but in PCbuild >> I've found these files: >> >> 21/08/2008 10.35 34.304 _tkinter.pyd > > The most likely explanation for this is that _tkinter.pyd has a static > dependency that can't be loaded. If, for instance, the TCL and TK > DLLs themselves are neither in PCbuild nor elsewhere in the path, then > you wouldn't be able to load _tkinter. > > -- > Curt Hagenlocher > curt at hagenlocher.org > -- Dott. Cesare Di Mauro A-Tono S.r.l. T.: (+39)095-7365314 Information in this email is confidential and may be privileged. It is intended for the addresses only. If you have received it in error, please notify the sender immediately and delete it from your system. You should not otherwise copy it, retransmit it or use or disclose its content to anyone. Thank you for your co-operation. From solipsis at pitrou.net Thu Aug 21 19:16:50 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 21 Aug 2008 17:16:50 +0000 (UTC) Subject: [Python-Dev] Python 2.6 on AMD64 recusion crash References: <016201c90336$ea16cd50$be4467f0$@com.au> Message-ID: Mark Hammond skippinet.com.au> writes: > > However, test_cpickle takes a different path and doesn't see this doubling of > the count - therefore dieing at the depth of 629 that I can see. 629 is a very low number, far lower than the default recursion limit of 1000. Please open a bug for the problem. > My solution to this was to simply double the stack size for the executables > in 64bit builds, from 2MB to 4MB (2.1 and 4.2 for debug builds.) Is this an > appropriate fix? Unless this can be set in the configure script for all affected architectures, I'm not sure this is ok. Regards Antoine. From guido at python.org Thu Aug 21 22:35:20 2008 From: guido at python.org (Guido van Rossum) Date: Thu, 21 Aug 2008 13:35:20 -0700 Subject: [Python-Dev] Unicode 5.1.0 Message-ID: I was just paid a visit by my Google colleague Mark Davis, co-founder of the Unicode project and the president of the Unicode Consortium. He would like to see improved Unicode support for Python. (Well duh. :-) On his list of top priorities are: 1. Upgrade the unicodata module to the Unicode 5.1.0 standard 2. Extende the unicodedata module with some additional properties 3. Add support for Unicode properties to the regex syntax, including Boolean combinations I've tried to explain our release schedule and no-new-features-in-point-releases policies to him, and he understands that it's too late to add #2 or #3 to 2.6 and 3.0, and that these will have to wait for 2.7 and 3.1, respectively. However, I've kept the door sligthtly ajar for adding #1 -- it can't be too much work and it can't have too much impact. Or can it? I don't actually know what the impact would be, so I'd like some impact from developers who are closer to the origins of the unicodedata module. The two, quite separate, questions, then, are (a) how much work would it be to upgrade to version 5.1.0 of the database; and (b) would it be acceptable to do this post-beta3 (but before rc1). If the answer to (b) is positive, Google can help with (a). In general, Google has needs in this area that can't wait for 2.7/3.1, so what we may end up doing is create internal implementations of all three features (compatible with Python 2.4 and later), publish them as open source on Google Code, and fold them into core Python at the first opportunity, which would likely be 2.7 and 3.1. Comments? -- --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at egenix.com Thu Aug 21 23:26:44 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 21 Aug 2008 23:26:44 +0200 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: Message-ID: <48ADDD94.2080903@egenix.com> On 2008-08-21 22:35, Guido van Rossum wrote: > I was just paid a visit by my Google colleague Mark Davis, co-founder > of the Unicode project and the president of the Unicode Consortium. He > would like to see improved Unicode support for Python. (Well duh. :-) > On his list of top priorities are: > > 1. Upgrade the unicodata module to the Unicode 5.1.0 standard > 2. Extende the unicodedata module with some additional properties > 3. Add support for Unicode properties to the regex syntax, including > Boolean combinations > > I've tried to explain our release schedule and > no-new-features-in-point-releases policies to him, and he understands > that it's too late to add #2 or #3 to 2.6 and 3.0, and that these will > have to wait for 2.7 and 3.1, respectively. However, I've kept the > door sligthtly ajar for adding #1 -- it can't be too much work and it > can't have too much impact. Or can it? I don't actually know what the > impact would be, so I'd like some impact from developers who are > closer to the origins of the unicodedata module. > > The two, quite separate, questions, then, are (a) how much work would > it be to upgrade to version 5.1.0 of the database; and (b) would it be > acceptable to do this post-beta3 (but before rc1). If the answer to > (b) is positive, Google can help with (a). > > In general, Google has needs in this area that can't wait for 2.7/3.1, > so what we may end up doing is create internal implementations of all > three features (compatible with Python 2.4 and later), publish them as > open source on Google Code, and fold them into core Python at the > first opportunity, which would likely be 2.7 and 3.1. > > Comments? There are two things to consider: unicodedata is just an optimized database for accessing code point properties of a specific Unicode version (currently 4.1.0 and 3.2.0). Adding support for a new version needs some work on the generation script, perhaps keeping the 4.1.0 version of it like we did for 3.2.0, but that's about it. However, there are other implications to consider when moving to Unicode 5.1.0. Just see the top of http://www.unicode.org/versions/Unicode5.1.0/ for a summary of changes compared to 5.0, plus http://www.unicode.org/versions/Unicode5.0.0/ for changes between 4.1.0 and 5.0. So while we could say: "we provide access to the Unicode 5.1.0 database", we cannot say: "we support Unicode 5.1.0", simply because we have not reviewed the all the necessary changes and implications. I think it's better to look through all the changes and then come up with proper support for 2.7/3.1. If Google wants to contribute to this, even better. To avoid duplication of work or heading in different directions, it may be a good idea to create a unicode-sig to discuss things. Offline 'til next week-ly, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 21 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From unknown_kev_cat at hotmail.com Thu Aug 21 23:55:11 2008 From: unknown_kev_cat at hotmail.com (Joe Smith) Date: Thu, 21 Aug 2008 17:55:11 -0400 Subject: [Python-Dev] [Pydotorg] Should we help pythonmac.org? References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org><48A9ECDD.5050206@holdenweb.com><4335d2c40808181745s6a70e51ai584b2dbe0f770aa0@mail.gmail.com><48AA25A8.6060101@holdenweb.com><1699.92.83.146.25.1219131943.squirrel@mail2.webfaction.com><7801D1D8-B938-4523-8167-D405BA0192F6@acm.org><92D5F670-B4F5-4D0E-A64B-92B8DAAC0C2E@python.org><6626084533285733447@unknownmsgid> <4222a8490808191344y6af0b4a3pe7f99dcd263e162e@mail.gmail.com> Message-ID: "Jesse Noller" wrote in message news:4222a8490808191344y6af0b4a3pe7f99dcd263e162e at mail.gmail.com... > On Tue, Aug 19, 2008 at 1:28 PM, Bill Janssen wrote: >>> > My understanding is that if there is a system Python, you shouldn't >>> > change it. Ever. >>> >>> Huge, big, honkin' +1 from me on that. Besides, for a system Python, >>> you want your distribution to manage packages, not setuptools, >>> otherwise you confuse -- and probably break -- your system. >> >> I find this discussion fascinating. I install new packages into my >> system Python all the time, with "/usr/bin/python setup.py install", >> and that includes setuptools. I've got PIL, ReportLab, Twisted, Xlib, >> appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen, >> roman, setuptools, and SSL installed in the Leopard machine I'm >> writing from. They don't wind up in >> /System/Library/.../site-packages/, they wind up in >> /Library/Python/2.5/site-packages/, which is sort of the right place, >> from an Apple point of view. I do this on lots of Macs -- I've got a >> regular posse of them at work. And I've never had any problems with >> it. >> >> I agree that there are some things I'd be very wary of installing into >> the system Python, like PyObjC, and Zope. Usually, I don't install >> anything which appears to already be there. >> >> Bill > > Bill is correct - using /usr/bin/python does install packages to > /Library/... - this is sort of the right place because it still > installs it to a "system path", where it can side-effect other users, > but it is a "mostly correct" way for Apple framework installs. /Library is system-wide, yes, but not system-reserved. /System/Library/ is system-wide and system reserved. Just like on most distros (LFS and some older distros excluded): /usr/ is system-wide and system-reserved. /usr/local/ is sytem-wide, but not system-reserved. Computer admins are supposed to install into /Library/ or /usr/local/. The only possible problem of installing new Python modules into /Library/ is if any system Python scripts that depend on exact versions of libraries shipped in /System/Library/, but were not crafted as to ignore /Library/. That can be problematic, and arguablly a bug in the script, but Apple does not tend to fix those bugs that quickly. (OS bugs is one area where Apple's traditional secrecy is a bad thing. More transparency in bug fixing can only be an improvement.) From tjreedy at udel.edu Fri Aug 22 00:30:56 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 21 Aug 2008 18:30:56 -0400 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: Message-ID: Guido van Rossum wrote: > I was just paid a visit by my Google colleague Mark Davis, co-founder > of the Unicode project and the president of the Unicode Consortium. He > would like to see improved Unicode support for Python. (Well duh. :-) > On his list of top priorities are: > > 1. Upgrade the unicodata module to the Unicode 5.1.0 standard > 2. Extende the unicodedata module with some additional properties > 3. Add support for Unicode properties to the regex syntax, including > Boolean combinations > > I've tried to explain our release schedule and > no-new-features-in-point-releases policies to him, and he understands > that it's too late to add #2 or #3 to 2.6 and 3.0, and that these will > have to wait for 2.7 and 3.1, respectively. However, I've kept the > door sligthtly ajar for adding #1 -- it can't be too much work and it > can't have too much impact. Or can it? I don't actually know what the > impact would be, so I'd like some impact from developers who are > closer to the origins of the unicodedata module. > > The two, quite separate, questions, then, are (a) how much work would > it be to upgrade to version 5.1.0 of the database; and (b) would it be > acceptable to do this post-beta3 (but before rc1). If the answer to > (b) is positive, Google can help with (a). http://www.unicode.org/versions/Unicode5.1.0/ "Unicode 5.1.0 contains over 100,000 characters, and provides significant additions and improvements..." to existing features, including new files and upgrades to existing files. Sounds close to adding features ;-) > In general, Google has needs in this area that can't wait for 2.7/3.1, > so what we may end up doing is create internal implementations of all > three features (compatible with Python 2.4 and later), publish them as > open source on Google Code, and fold them into core Python at the > first opportunity, which would likely be 2.7 and 3.1. If possible, I would suggest going a bit further and release a '3rd' party replacement/extension package, including a Windows installer, that is also listed on PyPI. Revised releases could and might need to be done even more rapidly than the bugfix release schedule would allow. (This could be done with other proposed new/revised modules also.) What would need to be done now, I believe, if possible and acceptable, it to slightly repackage the core to put unicode (3.0 strings) and _re* code in a separate library so that they can be drop-in replaced or masked. Terry Jan Reedy From mhammond at skippinet.com.au Fri Aug 22 01:29:02 2008 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 22 Aug 2008 09:29:02 +1000 Subject: [Python-Dev] Python 2.6 on AMD64 recusion crash In-Reply-To: References: <016201c90336$ea16cd50$be4467f0$@com.au> Message-ID: <026301c903e5$b53a22d0$1fae6870$@com.au> Antoine writes: > Mark Hammond skippinet.com.au> writes: > > > > However, test_cpickle takes a different path and doesn't see this > doubling of > > the count - therefore dieing at the depth of 629 that I can see. > > 629 is a very low number, far lower than the default recursion limit of > 1000. Yes, exactly - that is the point. If we got to 1000 Python would have prevented us going any further. As it was, we ran out of stack space at 629. I believe that this is the only path that allows us to go past an *actual* recursion level of 1/2 the nominated maximum value due to that other regression I mentioned. > Please open a bug for the problem. http://bugs.python.org/issue3640 > > My solution to this was to simply double the stack size for the > > executables > > in 64bit builds, from 2MB to 4MB (2.1 and 4.2 for debug builds.) Is > > this an appropriate fix? > > Unless this can be set in the configure script for all affected > architectures, I'm not sure this is ok. IIUC, each platform and architecture has its own stack requirements, so therefore it is the responsibility of that platform to ensure enough stack is available for a depth of 1000. The 32bit windows versions of Python do exactly this and nominate 2MB, which the 64bit builds inherited. It seems 2MB isn't enough for 64bit Windows, and doubling it seemed like a fairly safe way to go. So while other 64bit platforms may well need adjusting if they use the same values as their 32bit versions, that is independent of what Windows 64bit builds need to do. Obviously, all IIUC Cheers, Mark From guido at python.org Fri Aug 22 03:25:59 2008 From: guido at python.org (Guido van Rossum) Date: Thu, 21 Aug 2008 18:25:59 -0700 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <48ADDD94.2080903@egenix.com> References: <48ADDD94.2080903@egenix.com> Message-ID: On Thu, Aug 21, 2008 at 2:26 PM, M.-A. Lemburg wrote: > On 2008-08-21 22:35, Guido van Rossum wrote: >> >> I was just paid a visit by my Google colleague Mark Davis, co-founder >> of the Unicode project and the president of the Unicode Consortium. He >> would like to see improved Unicode support for Python. (Well duh. :-) >> On his list of top priorities are: >> >> 1. Upgrade the unicodata module to the Unicode 5.1.0 standard >> 2. Extende the unicodedata module with some additional properties >> 3. Add support for Unicode properties to the regex syntax, including >> Boolean combinations >> >> I've tried to explain our release schedule and >> no-new-features-in-point-releases policies to him, and he understands >> that it's too late to add #2 or #3 to 2.6 and 3.0, and that these will >> have to wait for 2.7 and 3.1, respectively. However, I've kept the >> door sligthtly ajar for adding #1 -- it can't be too much work and it >> can't have too much impact. Or can it? I don't actually know what the >> impact would be, so I'd like some impact from developers who are >> closer to the origins of the unicodedata module. >> >> The two, quite separate, questions, then, are (a) how much work would >> it be to upgrade to version 5.1.0 of the database; and (b) would it be >> acceptable to do this post-beta3 (but before rc1). If the answer to >> (b) is positive, Google can help with (a). >> >> In general, Google has needs in this area that can't wait for 2.7/3.1, >> so what we may end up doing is create internal implementations of all >> three features (compatible with Python 2.4 and later), publish them as >> open source on Google Code, and fold them into core Python at the >> first opportunity, which would likely be 2.7 and 3.1. >> >> Comments? > > There are two things to consider: > > unicodedata is just an optimized database for accessing code > point properties of a specific Unicode version (currently 4.1.0 > and 3.2.0). Adding support for a new version needs some work on > the generation script, perhaps keeping the 4.1.0 version of it > like we did for 3.2.0, but that's about it. > > However, there are other implications to consider when moving to > Unicode 5.1.0. > > Just see the top of http://www.unicode.org/versions/Unicode5.1.0/ > for a summary of changes compared to 5.0, plus > http://www.unicode.org/versions/Unicode5.0.0/ for changes between > 4.1.0 and 5.0. > > So while we could say: "we provide access to the Unicode 5.1.0 > database", we cannot say: "we support Unicode 5.1.0", simply because > we have not reviewed the all the necessary changes and implications. Mark's response to this was: """ I'd suspect that you'll be as conformant to U5.1.0 as you were to U4.1.0 ;-) More seriously, I don't think this is a roadblock -- I doubt that there are real differences between U5.1.0 and U4.10 in terms of conformance that would be touched by Python -- the conformance changes tend to be either completely backward compatible or very esoteric. What I can do is to review the Python support to see if and where there are any problems, but I wouldn't anticipate any. """ Which suggests that he believes that the differences in the database are very minor, and that upgrading just the database would not cause any problems for code that worked well with the 4.1.0 database. > I think it's better to look through all the changes and then come > up with proper support for 2.7/3.1. If Google wants to contribute > to this, even better. To avoid duplication of work or heading in > different directions, it may be a good idea to create a > unicode-sig to discuss things. Not me. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) From solipsis at pitrou.net Fri Aug 22 11:11:10 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 22 Aug 2008 09:11:10 +0000 (UTC) Subject: [Python-Dev] Python 2.6 on AMD64 recusion crash References: <016201c90336$ea16cd50$be4467f0$@com.au> <026301c903e5$b53a22d0$1fae6870$@com.au> Message-ID: Hi Mark, > I believe that this is the only path that allows us to go past an > *actual* recursion level of 1/2 the nominated maximum value due to that > other regression I mentioned. I believe it's the wrong diagnosis :) If you look at http://bugs.python.org/issue3373 and the small script I posted, there are paths where the actual recursion level is still 1000. Furthermore: > Yes, exactly - that is the point. If we got to 1000 Python would have > prevented us going any further. As it was, we ran out of stack space at > 629. [...] > The 32bit windows versions of Python do > exactly this and nominate 2MB, which the 64bit builds inherited. 2MB divided by 629 is more than 3KB. It means each cPickle recursion level consumes more than 3KB of stack. It sounds awful enough to be considered a bug in cPickle, IMO. 2MB is plenty of stack space. Regards Antoine. From fredrik at pythonware.com Fri Aug 22 12:47:01 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 22 Aug 2008 12:47:01 +0200 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: <48ADDD94.2080903@egenix.com> Message-ID: <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> On Fri, Aug 22, 2008 at 3:25 AM, Guido van Rossum wrote: >> So while we could say: "we provide access to the Unicode 5.1.0 >> database", we cannot say: "we support Unicode 5.1.0", simply because >> we have not reviewed the all the necessary changes and implications. > > Mark's response to this was: > > """ > I'd suspect that you'll be as conformant to U5.1.0 as you were to U4.1.0 ;-) is the suggestion to *replace* the 4.1.0 database with a 5.1.0 database, or to add yet another database in that module? (how's the 3.2/4.1 dual support implemented? do we have two distinct datasets, or are the differences encoded in some clever way? would it make sense to split the unicodedata module into three separate modules, one for each major Unicode version?) From facundobatista at gmail.com Fri Aug 22 15:42:10 2008 From: facundobatista at gmail.com (Facundo Batista) Date: Fri, 22 Aug 2008 10:42:10 -0300 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: Message-ID: 2008/8/21 Guido van Rossum : > The two, quite separate, questions, then, are (a) how much work would > it be to upgrade to version 5.1.0 of the database; and (b) would it be > acceptable to do this post-beta3 (but before rc1). If the answer to > (b) is positive, Google can help with (a). Two thoughts: - In view of jumping to a new standard at *this* point, what I'd like to have is a comprehensive test suite for unicodedata in a similar sense to what happens with Decimal... It would be great to have from the Unicode Consortium a series of test cases (in Python, or in something we could process), to verify that we support Unicode properly. - We always could have a beta4 if it's necessary... Just my two pesos cents. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From solipsis at pitrou.net Fri Aug 22 16:54:17 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 22 Aug 2008 14:54:17 +0000 (UTC) Subject: [Python-Dev] Unicode 5.1.0 References: Message-ID: Facundo Batista gmail.com> writes: > > Two thoughts: > > - In view of jumping to a new standard at *this* point, what I'd like > to have is a comprehensive test suite for unicodedata in a similar > sense to what happens with Decimal... It would be great to have from > the Unicode Consortium a series of test cases (in Python, or in > something we could process), to verify that we support Unicode > properly. > And another question: would it be hard for Google to maintain this separately until at least it's integrated to 3.1? > - We always could have a beta4 if it's necessary... If we go this route there are lots of attractive things that might justify yet and yet another beta :-) Just my two over-evaluated euro cents. Regards Antoine. From guido at python.org Fri Aug 22 16:59:46 2008 From: guido at python.org (Guido van Rossum) Date: Fri, 22 Aug 2008 07:59:46 -0700 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> References: <48ADDD94.2080903@egenix.com> <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> Message-ID: On Fri, Aug 22, 2008 at 3:47 AM, Fredrik Lundh wrote: > On Fri, Aug 22, 2008 at 3:25 AM, Guido van Rossum wrote: [MAL] >>> So while we could say: "we provide access to the Unicode 5.1.0 >>> database", we cannot say: "we support Unicode 5.1.0", simply because >>> we have not reviewed the all the necessary changes and implications. >> >> Mark's response to this was: >> >> """ >> I'd suspect that you'll be as conformant to U5.1.0 as you were to U4.1.0 ;-) > > is the suggestion to *replace* the 4.1.0 database with a 5.1.0 > database, or to add yet another database in that module? That's up to us. I don't know what the reason was for keeping the 3.2.0 database around -- does anyone here recall ever using it? For what? I think Mark believes that 5.1.0 is very much backwards compatible with 4.1.0 so that there is no need to retain access to 4.1.0; but as I said I don't know the use case so who knows. > (how's the 3.2/4.1 dual support implemented? do we have two distinct > datasets, or are the differences encoded in some clever way? would it > make sense to split the unicodedata module into three separate > modules, one for each major Unicode version?) The current API looks fine to me: unicodedata is the latest version whereas unicodedata.ucd_3_2_0 is the older version. The APIs are the same; there's a tiny bit of code in the generated _db.h file that expresses the differences: static const change_record* get_change_3_2_0(Py_UCS4 n) { int index; if (n >= 0x110000) index = 0; else { index = changes_3_2_0_index[n>>7]; index = changes_3_2_0_data[(index<<7)+(n & 127)]; } return change_records_3_2_0+index; } static Py_UCS4 normalization_3_2_0(Py_UCS4 n) { switch(n) { case 0x2f868: return 0x2136A; case 0x2f874: return 0x5F33; case 0x2f91f: return 0x43AB; case 0x2f95f: return 0x7AAE; case 0x2f9bf: return 0x4D57; default: return 0; } } -- --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Fri Aug 22 17:05:05 2008 From: guido at python.org (Guido van Rossum) Date: Fri, 22 Aug 2008 08:05:05 -0700 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: Message-ID: On Fri, Aug 22, 2008 at 6:42 AM, Facundo Batista wrote: > - In view of jumping to a new standard at *this* point, what I'd like > to have is a comprehensive test suite for unicodedata in a similar > sense to what happens with Decimal... It would be great to have from > the Unicode Consortium a series of test cases (in Python, or in > something we could process), to verify that we support Unicode > properly. Unicode conformance isn't specified in the same way as Decimal conformance. While there are certain algorithms that can be tested (e.g. normalization, encoding, decoding), much of the conformance requirements (AFAIK) are expressed in lots of words about providing certain facilities etc. I don't actually think putting lots of effort into this is well-spent; given the mechanical nature of the translation from the unicode database files into C code (see Tools/unicode/makeunicodedata.py) a bug in the translation is likely to result in either bad C code or a systematic error that is easily spotted. > - We always could have a beta4 if it's necessary... No way. On Fri, Aug 22, 2008 at 7:54 AM, Antoine Pitrou wrote: > And another question: would it be hard for Google to maintain this separately > until at least it's integrated to 3.1? That's the plan. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From horvath.arpad at roik.bmf.hu Fri Aug 22 16:03:17 2008 From: horvath.arpad at roik.bmf.hu (harp) Date: Fri, 22 Aug 2008 07:03:17 -0700 (PDT) Subject: [Python-Dev] Doc translation -- from LaTeX to reStructuredText Message-ID: Dear Developers, We have translated the tutorial into Hungarian earlier, and I do not know how to convert the LaTeX file into reStructuredText. Could somebody help us? HTML: http://pythonlib.pergamen.hu/html/tut/ LaTeX file: http://mail.roik.bmf.hu/linux/python/tutorial/tut.tex There will be included translations of documentation on the python.org homepage? Arpad From fredrik at pythonware.com Fri Aug 22 17:13:08 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 22 Aug 2008 17:13:08 +0200 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: <48ADDD94.2080903@egenix.com> <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> Message-ID: <368a5cd50808220813r6e48c6a5w25413e1a1c17946a@mail.gmail.com> On Fri, Aug 22, 2008 at 4:59 PM, Guido van Rossum wrote: >> (how's the 3.2/4.1 dual support implemented? do we have two distinct >> datasets, or are the differences encoded in some clever way? would it >> make sense to split the unicodedata module into three separate >> modules, one for each major Unicode version?) > > The current API looks fine to me: unicodedata is the latest version > whereas unicodedata.ucd_3_2_0 is the older version. The APIs are the > same; there's a tiny bit of code in the generated _db.h file that > expresses the differences: > > static const change_record* get_change_3_2_0(Py_UCS4 n) > { > int index; > if (n >= 0x110000) index = 0; > else { > index = changes_3_2_0_index[n>>7]; > index = changes_3_2_0_data[(index<<7)+(n & 127)]; > } > return change_records_3_2_0+index; > } there's a bunch of data tables as well, but they don't seem to be very large. looks like Martin did a thorough job here. ... digging digging digging ... yes, the generator script produces difference tables between the main version and a list of older versions. I'd say it's worth running the script on the 5.1.0 tables, and if it doesn't choke, compare the resulting table with the corresponding table for 4.1.0 (a simple loop fetching the main properties for all code points). if the differences look reasonably small, switch 5.1.0 and keep the others. I can tinker a little with this over the weekend, unless Martin tells me not to ;-) From status at bugs.python.org Fri Aug 22 18:06:36 2008 From: status at bugs.python.org (Python tracker) Date: Fri, 22 Aug 2008 18:06:36 +0200 (CEST) Subject: [Python-Dev] Summary of Python tracker Issues Message-ID: <20080822160636.ED0047851C@psf.upfronthosting.co.za> ACTIVITY SUMMARY (08/15/08 - 08/22/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1976 open (+67) / 13495 closed (+21) / 15471 total (+88) Open issues with patches: 626 Average duration of open issues: 717 days. Median duration of open issues: 1688 days. Open Issues Breakdown open 1963 (+67) pending 13 ( +0) Issues Created Or Reopened (92) _______________________________ Can't pickle partial functions 08/15/08 http://bugs.python.org/issue1398 reopened alexandre.vassalotti Operator precedence misdocumented 08/19/08 http://bugs.python.org/issue3558 reopened tjreedy Windows installer should add Python and Scripts directories to t 08/15/08 CLOSED http://bugs.python.org/issue3561 created jasonspiro Intermitent failure in test_multiprocessing.test_number_of_objec 08/15/08 http://bugs.python.org/issue3562 created pitrou fix_idioms.py generates bad code 08/16/08 http://bugs.python.org/issue3563 created hawking patch making partial functions comparable 08/16/08 http://bugs.python.org/issue3564 created erickt array documentation, method names not 3.0 compliant 08/16/08 http://bugs.python.org/issue3565 created mgiuca patch httplib persistent connections violate MUST in RFC2616 sec 8.1.4 08/16/08 http://bugs.python.org/issue3566 created cananian test_ossaudiodev fails when run with -bb 08/16/08 CLOSED http://bugs.python.org/issue3567 created pitrou list enumeration corrupt when remove() 08/16/08 CLOSED http://bugs.python.org/issue3568 created jacek Glitch in eval() doc 08/16/08 http://bugs.python.org/issue3569 created tjreedy str.find docstring typo 08/16/08 CLOSED http://bugs.python.org/issue3570 created andyharrington test_closerange in test_os can crash the test suite 08/16/08 CLOSED http://bugs.python.org/issue3571 created pitrou patch with closed file descriptor #2 (stderr), py3k hangs when trying 08/16/08 CLOSED http://bugs.python.org/issue3572 created pitrou IDLE hangs when passing invalid command line args (directory(ies 08/16/08 http://bugs.python.org/issue3573 created gpolo patch, needs review compile() cannot decode Latin-1 source encodings 08/17/08 http://bugs.python.org/issue3574 created brett.cannon patch, needs review [py3k] tell() fails in some situation 08/17/08 CLOSED http://bugs.python.org/issue3575 created ocean-city patch Demo/embed builds against old version 08/17/08 CLOSED http://bugs.python.org/issue3576 created mgiuca patch Interpreter name: python vs. python-3.0 08/17/08 http://bugs.python.org/issue3577 created jjlee 'dictionary changed size' error in test_multiprocessing 08/17/08 http://bugs.python.org/issue3578 created marketdickinson Faites Attention en Utilisant Cette Merveille! 08/17/08 CLOSED http://bugs.python.org/issue3579 created MrJean1 failures in test_os 08/17/08 http://bugs.python.org/issue3580 created pitrou patch failures in test_uuid 08/17/08 http://bugs.python.org/issue3581 created pitrou thread_nt.c update 08/17/08 http://bugs.python.org/issue3582 created krisvale patch, patch test_urllibnet.test_bad_address() fails when using OpenDNS 08/17/08 http://bugs.python.org/issue3583 created brett.cannon Exception for test_urllib2_localnet 08/17/08 http://bugs.python.org/issue3584 created jimhermann pkg-config support 08/18/08 http://bugs.python.org/issue3585 created ClintonRoy patch pwd.getpwnam('nobody') produces incorrect results if sizeof(uid_ 08/18/08 http://bugs.python.org/issue3586 created marketdickinson Bad parsing of compiling regex with re.MULTILINE 08/18/08 CLOSED http://bugs.python.org/issue3587 created misha sysconfig variable LINKFORSHARED has wrong value for MacOS X fra 08/18/08 http://bugs.python.org/issue3588 created khinsen Misleading names for multiprocessing "convenience" functions 08/18/08 http://bugs.python.org/issue3589 created ncoghlan sax.parser considers XML as text rather than bytes 08/18/08 http://bugs.python.org/issue3590 created edreamleo elementtree tests do not include bytes handling 08/18/08 http://bugs.python.org/issue3591 created pitrou Patch to add imp.get_codingspec() 08/18/08 http://bugs.python.org/issue3592 created brett.cannon patch, patch subprocess + stdout redirection + wait + svn= hang 08/18/08 http://bugs.python.org/issue3593 created tebeka PyTokenizer_FindEncoding() never succeeds 08/19/08 http://bugs.python.org/issue3594 created brett.cannon patch, needs review Windows base64 Decode 08/19/08 http://bugs.python.org/issue3595 created ahirreddy Provide a way to disable SSLv2 (or better yet, disable by defaul 08/19/08 http://bugs.python.org/issue3596 created heikki Allow application developers to select ciphers, and default to s 08/19/08 http://bugs.python.org/issue3597 created heikki multiprocessing.Pool windows/linux behaviour difference 08/19/08 CLOSED http://bugs.python.org/issue3598 created mark test_pydoc after test_urllib2 causes exception in Popen.__del__ 08/19/08 http://bugs.python.org/issue3599 created benjamin.peterson Include Tcl/Tk 8.5.4 in the windows binary for the upcoming beta 08/19/08 http://bugs.python.org/issue3600 created gpolo test_unicode.test_raiseMemError fails in UCS4 08/19/08 http://bugs.python.org/issue3601 created benjamin.peterson Move test.test_suport.catch_warning() to the 'warnings' module 08/19/08 http://bugs.python.org/issue3602 created brett.cannon trivial typo in Include/pymath.h 08/19/08 CLOSED http://bugs.python.org/issue3603 created sgala broken link in curses module docs 08/19/08 http://bugs.python.org/issue3604 created mattb Py_FatalError causes infinite loop 08/19/08 http://bugs.python.org/issue3605 created rupole 2to3: commands varible replaced by subprocess 08/19/08 http://bugs.python.org/issue3606 created haypo test_multiprocessing failure (Unserializable message) 08/19/08 http://bugs.python.org/issue3607 created pitrou memoryview constructor has no deallocator 08/19/08 CLOSED http://bugs.python.org/issue3608 created rupole does parse_header really belong in CGI module? 08/20/08 http://bugs.python.org/issue3609 created janssen Fix gdbinit for Python 3.0 08/20/08 http://bugs.python.org/issue3610 created haypo patch invalid exception context 08/21/08 http://bugs.python.org/issue3611 reopened benjamin.peterson patch, needs review Add some missing basic types in ctypes.wintypes 08/20/08 http://bugs.python.org/issue3612 created ocean-city patch base64.encodestring does not actually accept strings 08/20/08 http://bugs.python.org/issue3613 created ddvoinikov typo in xmlrpc.client 08/20/08 CLOSED http://bugs.python.org/issue3614 created ddvoinikov Expect methods for testing. 08/20/08 http://bugs.python.org/issue3615 created pupeno patch shutil.rmtree() fails on invalid filename 08/20/08 CLOSED http://bugs.python.org/issue3616 created haypo Add MS EULA to the list of third-party licenses in the Windows i 08/20/08 http://bugs.python.org/issue3617 created lemburg easy possible deadlock in IO library (Lib/io.py) 08/20/08 http://bugs.python.org/issue3618 created haypo patch A more informative message for ImportError 08/20/08 http://bugs.python.org/issue3619 created ktenney patch test_smtplib is flaky 08/20/08 http://bugs.python.org/issue3620 created benjamin.peterson it would be nice if installers made by bdist_wininst stored an E 08/20/08 http://bugs.python.org/issue3621 created jasonspiro Slight documentation quirk for random.random 08/20/08 CLOSED http://bugs.python.org/issue3622 created amc1 _json: fix raise_errmsg(), py_encode_basestring_ascii() and line 08/20/08 http://bugs.python.org/issue3623 created haypo patch Null byte \0 not listed as a possible escape sequence 08/20/08 CLOSED http://bugs.python.org/issue3624 created voket test issues on 64bit windows 08/21/08 http://bugs.python.org/issue3625 created mhammond patch, patch, 64bit python3.0 interpreter on Cygwin ignores all arguments 08/21/08 http://bugs.python.org/issue3626 created yselkowitz patch apple security patches need to be forward ported to py3k 08/21/08 http://bugs.python.org/issue3627 created nnorwitz IDLE does not run with Py30b3 08/21/08 http://bugs.python.org/issue3628 created mark Py30b3 won't compile a regex that compiles with 2.5.2 and 30b2 08/21/08 http://bugs.python.org/issue3629 created mark Unable to inherit bytes: bytes.__init__() doesn't accept argumen 08/21/08 CLOSED http://bugs.python.org/issue3630 created haypo Improve gdbinit of Python 2.6 08/21/08 http://bugs.python.org/issue3631 created haypo patch use string_print() in gdb 08/21/08 http://bugs.python.org/issue3632 created haypo patch float.fromhex discrepancy under Solaris 08/21/08 CLOSED http://bugs.python.org/issue3633 created pitrou patch, needs review invalid result value of _weakref.__init__() 08/21/08 http://bugs.python.org/issue3634 created haypo patch pickle.dumps cannot save instance of dict-derived class that ove 08/21/08 http://bugs.python.org/issue3635 created msyang Managing dual 2.x and 3.0 installations on Windows 08/21/08 http://bugs.python.org/issue3636 created richard_b_martin 2to3 refactoring 08/21/08 http://bugs.python.org/issue3637 created benjamin.peterson patch tkinter.mainloop() is meanling less and crash: remove it 08/21/08 http://bugs.python.org/issue3638 created haypo patch segfaults calling warnings.warn() with non-string message 08/21/08 http://bugs.python.org/issue3639 created dalcinl patch test_cpickle crash on AMD64 Windows build 08/21/08 http://bugs.python.org/issue3640 created mhammond 64bit Builtin ascii() function from future_builtins includes leading " 08/22/08 CLOSED http://bugs.python.org/issue3641 created tav Objects/obmalloc.c:529: warning: comparison is always false due 08/22/08 http://bugs.python.org/issue3642 created christian.heimes 64bit, needs review Add more checks to testcapi 08/22/08 http://bugs.python.org/issue3643 created haypo patch ``make htmlview`` for docs fails on OS X 08/22/08 http://bugs.python.org/issue3644 created brett.cannon readline module Crashs on OpenBSD/amd64 08/22/08 http://bugs.python.org/issue3645 created henry.precheur patch, needs review MacOS X framework install to non-standard directory fails 08/22/08 http://bugs.python.org/issue3646 created khinsen urlparse - relative url parsing and joins to be RFC3986 complian 08/22/08 http://bugs.python.org/issue3647 created orsenthil patch 'ascii' shoud be range(256) or just set another default encoding 08/22/08 CLOSED http://bugs.python.org/issue3648 created electronixtar threading module can deadlock after fork 08/17/08 http://bugs.python.org/issue874900 reopened benjamin.peterson patch Tkinter.Menu.delete doesn't delete command of entry 08/16/08 CLOSED http://bugs.python.org/issue1342811 reopened gpolo needs review Issues Now Closed (67) ______________________ [CVE-2007-4965] Integer overflow in imageop module 336 days http://bugs.python.org/issue1179 gvanrossum patch New SSL module doesn't seem to verify hostname against commonNam 254 days http://bugs.python.org/issue1589 janssen class attribute cache failure (regression) 212 days http://bugs.python.org/issue1878 gvanrossum Add migration step for DictMixin -> collections.MutableMapping 199 days http://bugs.python.org/issue2012 benjamin.peterson Long object free list optimization 195 days http://bugs.python.org/issue2013 gregory.p.smith patch Memory leak in os.rename? 167 days http://bugs.python.org/issue2222 ocean-city patch cygwinccompiler.py fails for latest MinGW releases. 167 days http://bugs.python.org/issue2234 jlt63 patch, easy __eq__ / __hash__ check doesn't take inheritance into account 167 days http://bugs.python.org/issue2235 ncoghlan patch Reorganize the 3.0 Misc/NEWS file 153 days http://bugs.python.org/issue2310 gvanrossum sys.exc_{type,values,traceback} needs a 2to3 fixer 157 days http://bugs.python.org/issue2357 benjamin.peterson patch, 26backport, needs review get rid of warnings in regrtest with -3 156 days http://bugs.python.org/issue2402 benjamin.peterson Backport ctypes support for buffer protocol to Python 2.6 (ref i 156 days http://bugs.python.org/issue2404 theller 2to3 is rather slow 155 days http://bugs.python.org/issue2431 benjamin.peterson patch urllib2 can't handle http://www.wikispaces.com 147 days http://bugs.python.org/issue2464 gregory.p.smith patch _Py_ForgetReference crash when called from _PyUnicode_New on Mem 128 days http://bugs.python.org/issue2629 gregory.p.smith email/message.py [Message.get_content_type]: Trivial regex hangs 115 days http://bugs.python.org/issue2676 pitrou patch c_char doesn't implement py3k buffer interface 109 days http://bugs.python.org/issue2764 theller urllib2.urlopen() gets confused with path with // in it 102 days http://bugs.python.org/issue2776 facundobatista patch re.IGNORECASE not Unicode-ready 100 days http://bugs.python.org/issue2834 pitrou patch Test_imports takes a long time to run 89 days http://bugs.python.org/issue2968 benjamin.peterson test_list uses unreasonable amounts of memory on 64-bit Linux 69 days http://bugs.python.org/issue3107 pitrou test_multiprocessing seems fragile 66 days http://bugs.python.org/issue3109 jnoller 2to3 can't find fixes_dir 63 days http://bugs.python.org/issue3131 benjamin.peterson patch bytearrays are not thread safe 62 days http://bugs.python.org/issue3139 cartman patch 2to3 Slight Patch 59 days http://bugs.python.org/issue3182 benjamin.peterson urllib.quote and unquote - Unicode issues 45 days http://bugs.python.org/issue3300 mgiuca patch missing lock release in BZ2File_iternext() 42 days http://bugs.python.org/issue3309 gregory.p.smith patch, easy Documentation: timeit: "lower bound" should read "upper bound" 43 days http://bugs.python.org/issue3318 unutbu sys recursion limit a lot shorter on trunk? 37 days http://bugs.python.org/issue3373 gvanrossum imghdr test order makes it slow 25 days http://bugs.python.org/issue3424 benjamin.peterson In function call, keyword arguments could follow *args 20 days http://bugs.python.org/issue3473 benjamin.peterson patch Using functools.reduce() does not stop DeprecationWarning when u 18 days http://bugs.python.org/issue3474 benjamin.peterson patch distutils fails with mingw binutils 2.18.50.20080109 15 days http://bugs.python.org/issue3496 amaury.forgeotdarc patch Python 2.6 requires pre-installed Python to build 11 days http://bugs.python.org/issue3499 benjamin.peterson ast.NodeTransformer bug 8 days http://bugs.python.org/issue3530 benjamin.peterson Building an MSI installer crashes 5 days http://bugs.python.org/issue3542 loewis patch ctypes.wstring_at and string_at call Python API without the GIL 5 days http://bugs.python.org/issue3554 theller test_raiseMemError consumes an insane amount of memory 3 days http://bugs.python.org/issue3556 pitrou patch redundant "base" field in memoryview objects 4 days http://bugs.python.org/issue3560 pitrou patch Windows installer should add Python and Scripts directories to t 0 days http://bugs.python.org/issue3561 loewis test_ossaudiodev fails when run with -bb 0 days http://bugs.python.org/issue3567 pitrou list enumeration corrupt when remove() 0 days http://bugs.python.org/issue3568 tjreedy str.find docstring typo 1 days http://bugs.python.org/issue3570 benjamin.peterson test_closerange in test_os can crash the test suite 0 days http://bugs.python.org/issue3571 pitrou patch with closed file descriptor #2 (stderr), py3k hangs when trying 0 days http://bugs.python.org/issue3572 pitrou [py3k] tell() fails in some situation 0 days http://bugs.python.org/issue3575 ocean-city patch Demo/embed builds against old version 1 days http://bugs.python.org/issue3576 benjamin.peterson patch Faites Attention en Utilisant Cette Merveille! 0 days http://bugs.python.org/issue3579 benjamin.peterson Bad parsing of compiling regex with re.MULTILINE 0 days http://bugs.python.org/issue3587 pitrou multiprocessing.Pool windows/linux behaviour difference 0 days http://bugs.python.org/issue3598 mark trivial typo in Include/pymath.h 1 days http://bugs.python.org/issue3603 benjamin.peterson memoryview constructor has no deallocator 1 days http://bugs.python.org/issue3608 georg.brandl typo in xmlrpc.client 1 days http://bugs.python.org/issue3614 amaury.forgeotdarc shutil.rmtree() fails on invalid filename 0 days http://bugs.python.org/issue3616 pitrou Slight documentation quirk for random.random 0 days http://bugs.python.org/issue3622 amaury.forgeotdarc Null byte \0 not listed as a possible escape sequence 0 days http://bugs.python.org/issue3624 georg.brandl Unable to inherit bytes: bytes.__init__() doesn't accept argumen 0 days http://bugs.python.org/issue3630 pitrou float.fromhex discrepancy under Solaris 1 days http://bugs.python.org/issue3633 benjamin.peterson patch, needs review Builtin ascii() function from future_builtins includes leading " 0 days http://bugs.python.org/issue3641 benjamin.peterson 'ascii' shoud be range(256) or just set another default encoding 0 days http://bugs.python.org/issue3648 pitrou thread unsafe file objects cause crash 1785 days http://bugs.python.org/issue815646 gregory.p.smith patch help(obj) should use __doc__ when available 1738 days http://bugs.python.org/issue843385 benjamin.peterson symtable module not documented 1647 days http://bugs.python.org/issue896052 benjamin.peterson symtable.Symbol.is_global() is strange 1650 days http://bugs.python.org/issue896061 benjamin.peterson symtable module crashes w/ coding declaration 1646 days http://bugs.python.org/issue898271 benjamin.peterson glob doesn't return unicode with no dir in unicode filename 1481 days http://bugs.python.org/issue1001604 lcantey patch Tkinter.Menu.delete doesn't delete command of entry 5 days http://bugs.python.org/issue1342811 schuppenies needs review Top Issues Most Discussed (10) ______________________________ 35 invalid exception context 1 days open http://bugs.python.org/issue3611 21 Deficiencies in multiprocessing/threading API 39 days open http://bugs.python.org/issue3352 16 os.listdir can return byte strings 59 days open http://bugs.python.org/issue3187 12 float.fromhex discrepancy under Solaris 1 days closed http://bugs.python.org/issue3633 11 redundant "base" field in memoryview objects 4 days closed http://bugs.python.org/issue3560 10 sax.parser considers XML as text rather than bytes 4 days open http://bugs.python.org/issue3590 10 [Py3k] Finish the memoryview object implementation 157 days open http://bugs.python.org/issue2394 10 Tkinter.Menu.delete doesn't delete command of entry 5 days closed http://bugs.python.org/issue1342811 9 test_raiseMemError consumes an insane amount of memory 3 days closed http://bugs.python.org/issue3556 8 Move test.test_suport.catch_warning() to the 'warnings' module 3 days open http://bugs.python.org/issue3602 From guido at python.org Fri Aug 22 18:12:55 2008 From: guido at python.org (Guido van Rossum) Date: Fri, 22 Aug 2008 09:12:55 -0700 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <368a5cd50808220813r6e48c6a5w25413e1a1c17946a@mail.gmail.com> References: <48ADDD94.2080903@egenix.com> <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> <368a5cd50808220813r6e48c6a5w25413e1a1c17946a@mail.gmail.com> Message-ID: 2008/8/22 Fredrik Lundh : > On Fri, Aug 22, 2008 at 4:59 PM, Guido van Rossum wrote: > >>> (how's the 3.2/4.1 dual support implemented? do we have two distinct >>> datasets, or are the differences encoded in some clever way? would it >>> make sense to split the unicodedata module into three separate >>> modules, one for each major Unicode version?) >> >> The current API looks fine to me: unicodedata is the latest version >> whereas unicodedata.ucd_3_2_0 is the older version. The APIs are the >> same; there's a tiny bit of code in the generated _db.h file that >> expresses the differences: >> >> static const change_record* get_change_3_2_0(Py_UCS4 n) >> { >> int index; >> if (n >= 0x110000) index = 0; >> else { >> index = changes_3_2_0_index[n>>7]; >> index = changes_3_2_0_data[(index<<7)+(n & 127)]; >> } >> return change_records_3_2_0+index; >> } > > there's a bunch of data tables as well, but they don't seem to be very > large. looks like Martin did a thorough job here. > > ... digging digging digging ... > > yes, the generator script produces difference tables between the main > version and a list of older versions. I'd say it's worth running the > script on the 5.1.0 tables, and if it doesn't choke, compare the > resulting table with the corresponding table for 4.1.0 (a simple loop > fetching the main properties for all code points). if the differences > look reasonably small, switch 5.1.0 and keep the others. Right, that's my hope as well. I believe the changes between 3.2 and 4.1 were much larger than more recent changes. (Yay convergence! :-) > I can tinker a little with this over the weekend, unless Martin tells > me not to ;-) That would be great! -- --Guido van Rossum (home page: http://www.python.org/~guido/) -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik at pythonware.com Fri Aug 22 17:15:13 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 22 Aug 2008 17:15:13 +0200 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <368a5cd50808220813r6e48c6a5w25413e1a1c17946a@mail.gmail.com> References: <48ADDD94.2080903@egenix.com> <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> <368a5cd50808220813r6e48c6a5w25413e1a1c17946a@mail.gmail.com> Message-ID: <368a5cd50808220815s45ace95di50b67fcf12545889@mail.gmail.com> when did Python-Dev turn into a members only list, btw? --- Your mail to 'Python-Dev' with the subject Re: Unicode 5.1.0 Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list --- From guido at python.org Fri Aug 22 18:51:30 2008 From: guido at python.org (Guido van Rossum) Date: Fri, 22 Aug 2008 09:51:30 -0700 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <368a5cd50808220815s45ace95di50b67fcf12545889@mail.gmail.com> References: <48ADDD94.2080903@egenix.com> <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> <368a5cd50808220813r6e48c6a5w25413e1a1c17946a@mail.gmail.com> <368a5cd50808220815s45ace95di50b67fcf12545889@mail.gmail.com> Message-ID: I think it's an anti-spam measure. Anybody can be a member though. :-) On Fri, Aug 22, 2008 at 8:15 AM, Fredrik Lundh wrote: > when did Python-Dev turn into a members only list, btw? > > --- > > Your mail to 'Python-Dev' with the subject > > Re: Unicode 5.1.0 > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post by non-member to a members-only list -- --Guido van Rossum (home page: http://www.python.org/~guido/) From amk at amk.ca Fri Aug 22 18:52:18 2008 From: amk at amk.ca (A.M. Kuchling) Date: Fri, 22 Aug 2008 12:52:18 -0400 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: <48ADDD94.2080903@egenix.com> <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> Message-ID: <20080822165218.GA10316@amk-desktop.matrixgroup.net> On Fri, Aug 22, 2008 at 07:59:46AM -0700, Guido van Rossum wrote: > That's up to us. I don't know what the reason was for keeping the > 3.2.0 database around -- does anyone here recall ever using it? For > what? RFC 3491, one of the internationalized domain name RFCs, explicitly requires Unicode 3.2.0, so Lib/stringprep.py needs to use the old database and we have to keep 3.2.0 available. Maybe no specs depend on 4.1.0, so it could simply be replaced by 5.1.0. --amk From musiccomposition at gmail.com Fri Aug 22 20:18:38 2008 From: musiccomposition at gmail.com (Benjamin Peterson) Date: Fri, 22 Aug 2008 13:18:38 -0500 Subject: [Python-Dev] Doc translation -- from LaTeX to reStructuredText In-Reply-To: References: Message-ID: <1afaf6160808221118p3a6f032btf0e93183798362a7@mail.gmail.com> On Fri, Aug 22, 2008 at 9:03 AM, harp wrote: > Dear Developers, > > We have translated the tutorial into Hungarian earlier, and I do not > know how to convert the LaTeX file into reStructuredText. Could > somebody help us? Have you looked at the LaTeX to reST converter at http://svn.python.org/view/doctools/converter? > > HTML: http://pythonlib.pergamen.hu/html/tut/ > LaTeX file: http://mail.roik.bmf.hu/linux/python/tutorial/tut.tex > > There will be included translations of documentation on the python.org > homepage? > > Arpad > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." From tjreedy at udel.edu Sat Aug 23 00:22:15 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 22 Aug 2008 18:22:15 -0400 Subject: [Python-Dev] IDLE croaks on both beta3s? Message-ID: Marks Summerfield and Dickenson report 2.6/3.0 b3 will not run IDLE http://bugs.python.org/issue3628 because idlelib/run.py needs s/set_daemon(True)/daemon = True/ Assuming they are correct and this is general: 1. Is not there any test to make sure that IDLE basically runs? For instance by having it run a file that writes a test file? 2. If the Windows installers have not been made yet (they are not on Python.org yet), could they incorporate the needed change? For me, this is a show stopper since I use IDLE as my Python editor and tester. tjr From mhammond at skippinet.com.au Sat Aug 23 03:53:11 2008 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 23 Aug 2008 11:53:11 +1000 Subject: [Python-Dev] Python 2.6 on AMD64 recusion crash In-Reply-To: References: <016201c90336$ea16cd50$be4467f0$@com.au> <026301c903e5$b53a22d0$1fae6870$@com.au> Message-ID: <031d01c904c3$0228ec60$067ac520$@com.au> > I believe it's the wrong diagnosis :) As I mentioned in the bug, I believe you are correct :) Thanks! Mark From fredrik at pythonware.com Sat Aug 23 12:30:47 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Sat, 23 Aug 2008 12:30:47 +0200 Subject: [Python-Dev] String concatenation In-Reply-To: <4895F311.60200@palladion.com> References: <4895EE62.8080605@korokithakis.net> <4895F311.60200@palladion.com> Message-ID: Tres Seaver wrote: > - -1. The feature exists to allow adherence to PEP-8, "Limit all lines to > a maximum of 79 characters.", without requiring runtime concatenation > costs. I use it frequently when assembling and testing message strings, > for instance. removing it is a bad idea for the reasons already given, but requiring parentheses could help. that is, the following would result in a warning or an error: L = ["first", "second" "third"] but the following wouldn't: L = ["first", ("second" "third")] T = ("This is a line of text.\n" "This is another line of text.\n") etc. From ijmorlan at cs.uwaterloo.ca Sat Aug 23 13:57:54 2008 From: ijmorlan at cs.uwaterloo.ca (Isaac Morland) Date: Sat, 23 Aug 2008 07:57:54 -0400 (EDT) Subject: [Python-Dev] String concatenation In-Reply-To: References: <4895EE62.8080605@korokithakis.net> <4895F311.60200@palladion.com> Message-ID: On Sat, 23 Aug 2008, Fredrik Lundh wrote: > removing it is a bad idea for the reasons already given, but requiring > parentheses could help. > > that is, the following would result in a warning or an error: > > L = ["first", "second" "third"] > > but the following wouldn't: > > L = ["first", ("second" "third")] > > T = ("This is a line of text.\n" > "This is another line of text.\n") This would avoid accidentally leaving out commas in list construction, but tuple construction would still have the same problem. And it's still a change in the language which would probably affect lots of existing code. I doubt if there is any problem-free way of trying to address this issue by changing the language. One suggestion to help minimize problems when writing code would be always to put the optional trailing comma: [ 'a', 'b', 'c', ] which is also a revision-control-friendly practice, and in the tuple constuction context avoids the possibility of removing an item from a two-tuple and ending up with not a one-tuple but instead just the item itself. Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist From fredrik at pythonware.com Sat Aug 23 14:43:27 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Sat, 23 Aug 2008 14:43:27 +0200 Subject: [Python-Dev] String concatenation In-Reply-To: References: <4895EE62.8080605@korokithakis.net> <4895F311.60200@palladion.com> Message-ID: >Isaac Morland wrote: > This would avoid accidentally leaving out commas in list construction, > but tuple construction would still have the same problem. Tuple construction already has a "no comma, no tuple" problem. That problem remains, but as soon as you add a comma, you'll get the same protection as you get for lists. > And it's still a change in the language which would probably affect > lots of existing code. Having read and written tons of existing code, I'm not so sure about that. A tool that wraps backslash-escaped blocks in parentheses would take care of most cases. What's left after that is probably ambiguous to a human reader anyway. From fredrik at pythonware.com Sat Aug 23 18:34:44 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Sat, 23 Aug 2008 18:34:44 +0200 Subject: [Python-Dev] "error: None" when building extensions under 2.6 Message-ID: when I'm trying to build extensions under Python 2.6 on Windows XP, the build process terminates with single line that says: error: None which is about as useless as an error message can be. Googling for this brings up a few hits which all seem to involve setuptools (and none of the hits contain any answers), but I'm using straightforward distutils stuff that has worked without a glitch since 1.5.2. Has anyone else seen this for 2.6? From ncoghlan at gmail.com Sun Aug 24 05:13:50 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 24 Aug 2008 13:13:50 +1000 Subject: [Python-Dev] Committer guidelines In-Reply-To: References: <20080823202744.367931E4003@bag.python.org> <1afaf6160808231350y44b9d53i4e4e534ede049260@mail.gmail.com> Message-ID: <48B0D1EE.6050903@gmail.com> Brett Cannon wrote: > On Sat, Aug 23, 2008 at 1:50 PM, Benjamin Peterson > wrote: >> On Sat, Aug 23, 2008 at 3:48 PM, Brett Cannon wrote: >>> I don't think Victor has commit privileges, which would mean you >>> should have had another committer review this first before committing. >> Ah. Ok. >> >> Can we make a wiki page for rules like this? I feel like I'm poking >> around it a dark room which is actually a monster's mouth. :) > > This commit review thing is new to all of us; never been done while I > have been around. It's just that committing a non-committers patch > without a second opinion is just like any other external patch we > accept, and thus lacks the extra protection that having a second > committer sign off it gives us during the rc phase. > > And yes, I will write up a doc on all of this after we hit final. My > current plan is that once we release final to spark a conversation > about our workflow and then write up a doc that lists what is expected > for each step in the life of an issue. In the meantime, I put some (very) rough notes based on what we did for the betas and are doing for the release candidates up on the wiki: http://wiki.python.org/moin/PythonCommitterGuidelines Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From nnorwitz at gmail.com Sun Aug 24 07:12:49 2008 From: nnorwitz at gmail.com (Neal Norwitz) Date: Sat, 23 Aug 2008 22:12:49 -0700 Subject: [Python-Dev] current problems that should be fixed before release (2.6) Message-ID: Below are the problems I found that have not been fixed at r65995 on trunk (2.6). There will be a separate mail for the 3.0 problems. I've done the following: * built in debug and opt mode (gcc 4.1.2) fixing the important warnings * run all the tests in both modes * run all the tests (except test_logging and test_ssl) under valgrind 3.3.1 fixing the problems * run failmalloc (1.0) on startup for the first 4000 allocations fixing most problems * run pychecker 0.8.18 over the stdlib (Lib/*.py, Lib/[bcdelhjmswx]*/*.py) Can someone run purify on windows over 2.6? Can someone (else) compare performance of 2.5, 2.6, and 3.0? pychecker reported problems: Lib/gzip.py:114: Using property (filename) in classic class GzipFile may not work Lib/io.py:1394: No module attribute (device_encoding) found - device_encoding access is protected, but I don't see where it can be set Lib/sched.py:122: Using property (queue) in classic class scheduler may not work Lib/tempfile.py:535: Using property (closed) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:539: Using property (encoding) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:553: Using property (mode) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:557: Using property (name) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:561: Using property (newlines) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:580: Using property (softspace) in classic class SpooledTemporaryFile may not work Lib/multiprocessing/connection.py:95: No global (PipeListener) found Lib/multiprocessing/connection.py:132: No global (PipeClient) found - both of the Pipe classes are defined only for windows. I don't see a similar def for Unix. Lib/multiprocessing/connection.py:378: No global (AuthenticationError) found I haven't looked into the property complaint to see how bad it is. test_bsddb3 is failing on several 2.6 buildbots. test_bsddb3 leaks 80 references. Results of valgrind 3.3.1 on Ubuntu 6.10 amd64, gcc 4.1.2 (prerelease): Uninitialized memory reads: No problems in python code. Though it's possible there are errors in ctypes. I'm ignoring those reports due to a problem in dlopen. Wild memory writes: No problems in python code. Memory leaks: No major problems. However, it seems that there are a bunch of little leaks when forking a process. I haven't determined if these are real problems or not. There is one memory leak in ctypes (sorry no real useful information): 44 bytes in 1 blocks are definitely lost in loss record 43 of 191 malloc (vg_replace_malloc.c:207) resize (callproc.c:1733) It seems to always leak 44 bytes n From amauryfa at gmail.com Sun Aug 24 11:40:51 2008 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Sun, 24 Aug 2008 11:40:51 +0200 Subject: [Python-Dev] "error: None" when building extensions under 2.6 In-Reply-To: References: Message-ID: Hello, 2008/8/23 Fredrik Lundh : > when I'm trying to build extensions under Python 2.6 on Windows XP, the > build process terminates with single line that says: > > error: None > > which is about as useless as an error message can be. Googling for this > brings up a few hits which all seem to involve setuptools (and none of the > hits contain any answers), but I'm using straightforward distutils stuff > that has worked without a glitch since 1.5.2. Has anyone else seen this for > 2.6? I tried to rebuild some extensions, and it either succeeds, or fails with a meaningful (for an expert) error message. Which extensions did you try? is there some output before the error? -- Amaury Forgeot d'Arc From fredrik at pythonware.com Sun Aug 24 11:49:26 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Sun, 24 Aug 2008 11:49:26 +0200 Subject: [Python-Dev] "error: None" when building extensions under 2.6 In-Reply-To: References: Message-ID: Amaury Forgeot d'Arc wrote: >> when I'm trying to build extensions under Python 2.6 on Windows XP, the >> build process terminates with single line that says: >> >> error: None >> >> which is about as useless as an error message can be. Googling for this >> brings up a few hits which all seem to involve setuptools (and none of the >> hits contain any answers), but I'm using straightforward distutils stuff >> that has worked without a glitch since 1.5.2. Has anyone else seen this for >> 2.6? > > I tried to rebuild some extensions, and it either succeeds, > or fails with a meaningful (for an expert) error message. > > Which extensions did you try? is there some output before the error? pick any: http://effbot.org/downloads/ ;-) I'm beginning to suspect that I have a botched VS install on this machine, though. I'll investigate. From theller at ctypes.org Sun Aug 24 13:03:54 2008 From: theller at ctypes.org (Thomas Heller) Date: Sun, 24 Aug 2008 13:03:54 +0200 Subject: [Python-Dev] "error: None" when building extensions under 2.6 In-Reply-To: References: Message-ID: Fredrik Lundh schrieb: > Amaury Forgeot d'Arc wrote: > >>> when I'm trying to build extensions under Python 2.6 on Windows XP, the >>> build process terminates with single line that says: >>> >>> error: None >>> >>> which is about as useless as an error message can be. Googling for this >>> brings up a few hits which all seem to involve setuptools (and none of the >>> hits contain any answers), but I'm using straightforward distutils stuff >>> that has worked without a glitch since 1.5.2. Has anyone else seen this for >>> 2.6? >> >> I tried to rebuild some extensions, and it either succeeds, >> or fails with a meaningful (for an expert) error message. >> >> Which extensions did you try? is there some output before the error? > > pick any: > > http://effbot.org/downloads/ > > ;-) > > I'm beginning to suspect that I have a botched VS install on this > machine, though. I'll investigate. > Do you get a traceback when you set the DISTUTILS_DEBUG environment variable? Thomas From skip at pobox.com Sun Aug 24 14:16:56 2008 From: skip at pobox.com (skip at pobox.com) Date: Sun, 24 Aug 2008 07:16:56 -0500 Subject: [Python-Dev] current problems that should be fixed before release (2.6) In-Reply-To: References: Message-ID: <18609.20792.53909.137357@montanaro-dyndns-org.local> Neal> Lib/gzip.py:114: Using property (filename) in classic class GzipFile Neal> may not work Seems shallow. Just inherit from object. Neal> Lib/sched.py:122: Using property (queue) in classic class scheduler Neal> may not work Ditto. Neal> Lib/tempfile.py:535: Using property (closed) in classic class Neal> SpooledTemporaryFile may not work ... Ditto. Neal> Lib/multiprocessing/connection.py:378: No global (AuthenticationError) found This is defined in the __init__ module of the package. Is it accessible from connection.py without further import? (My guess would be no.) A slight code rearrangement or adding imports at the point of the raise statements probably fixes that. Neal> I haven't looked into the property complaint to see how bad it is. I'm testing out the inherit-from-object fixes now. Will report back later. Skip From solipsis at pitrou.net Sun Aug 24 14:58:31 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 24 Aug 2008 12:58:31 +0000 (UTC) Subject: [Python-Dev] performance References: Message-ID: Neal Norwitz gmail.com> writes: > Can someone (else) compare performance of 2.5, 2.6, and 3.0? Tests done on a 32-bit Linux installation on an Athlon 3600+ X2. Compiled with gcc in UCS2 mode. pystone ------- - 2.5: 43859.6 pystones/second - 2.6: 42016.8 pystones/second - 3.0: 38759.7 pystones/second richards.py ----------- (roughly, richards is an object-oriented method-calling benchmark) - 2.5: 770.54 ms per iteration - 2.6: 572.84 ms per iteration - 3.0: 566.69 ms per iteration stringbench ----------- - 2.5: unicode: 265.84 s / bytes: 180.50 s - 2.6: unicode: 256.22 s / bytes: 184.45 s - 3.0: unicode: 248.07 s / bytes: not tested pybench: 2.6 vs. 2.5 -------------------- "this" is 2.6, "other" is 2.5. Test minimum run-time average run-time this other diff this other diff ------------------------------------------------------------------------------- BuiltinFunctionCalls: 177ms 181ms -2.2% 178ms 182ms -2.1% BuiltinMethodLookup: 157ms 177ms -11.1% 158ms 177ms -11.0% CompareFloats: 171ms 171ms -0.3% 171ms 171ms -0.3% CompareFloatsIntegers: 158ms 162ms -2.1% 160ms 167ms -4.8% CompareIntegers: 208ms 208ms -0.0% 209ms 209ms -0.3% CompareInternedStrings: 189ms 183ms +3.4% 189ms 184ms +2.7% CompareLongs: 154ms 154ms -0.2% 154ms 154ms -0.2% CompareStrings: 162ms 159ms +1.7% 163ms 159ms +2.5% CompareUnicode: 144ms 149ms -3.6% 144ms 152ms -5.0% ComplexPythonFunctionCalls: 173ms 242ms -28.5% 176ms 243ms -27.6% ConcatStrings: 196ms 198ms -0.9% 203ms 200ms +1.4% ConcatUnicode: 153ms 151ms +1.5% 155ms 157ms -1.5% CreateInstances: 172ms 169ms +1.5% 173ms 170ms +1.4% CreateNewInstances: 131ms 148ms -11.6% 132ms 151ms -12.2% CreateStringsWithConcat: 209ms 206ms +1.4% 209ms 208ms +0.8% CreateUnicodeWithConcat: 128ms 124ms +3.7% 129ms 124ms +3.4% DictCreation: 115ms 149ms -22.8% 116ms 150ms -22.8% DictWithFloatKeys: 208ms 207ms +0.4% 208ms 208ms +0.0% DictWithIntegerKeys: 173ms 173ms -0.0% 174ms 173ms +0.5% DictWithStringKeys: 162ms 162ms -0.1% 162ms 162ms +0.1% ForLoops: 181ms 181ms -0.2% 181ms 182ms -0.2% IfThenElse: 169ms 168ms +0.2% 169ms 169ms -0.2% ListSlicing: 109ms 108ms +0.2% 109ms 109ms +0.1% NestedForLoops: 198ms 197ms +0.2% 198ms 197ms +0.1% NormalClassAttribute: 176ms 172ms +2.0% 176ms 173ms +1.7% NormalInstanceAttribute: 162ms 161ms +1.0% 163ms 161ms +1.1% PythonFunctionCalls: 161ms 151ms +6.6% 162ms 153ms +6.0% PythonMethodCalls: 188ms 189ms -0.7% 189ms 193ms -2.0% Recursion: 235ms 230ms +2.2% 236ms 233ms +1.2% SecondImport: 113ms 114ms -1.0% 115ms 115ms +0.0% SecondPackageImport: 120ms 116ms +3.6% 120ms 117ms +2.9% SecondSubmoduleImport: 154ms 146ms +6.0% 156ms 148ms +5.7% SimpleComplexArithmetic: 163ms 151ms +8.3% 163ms 151ms +8.6% SimpleDictManipulation: 177ms 173ms +2.6% 180ms 174ms +3.2% SimpleFloatArithmetic: 169ms 164ms +3.0% 169ms 166ms +2.2% SimpleIntFloatArithmetic: 153ms 152ms +1.2% 156ms 153ms +1.8% SimpleIntegerArithmetic: 156ms 152ms +2.5% 156ms 153ms +2.0% SimpleListManipulation: 156ms 158ms -1.0% 157ms 158ms -0.5% SimpleLongArithmetic: 159ms 150ms +6.1% 161ms 151ms +6.3% SmallLists: 156ms 154ms +1.1% 160ms 155ms +3.0% SmallTuples: 156ms 155ms +0.4% 157ms 156ms +0.8% SpecialClassAttribute: 173ms 172ms +0.6% 173ms 172ms +0.7% SpecialInstanceAttribute: 202ms 198ms +2.4% 203ms 199ms +2.2% StringMappings: 164ms 170ms -3.2% 165ms 171ms -3.9% StringPredicates: 160ms 185ms -13.6% 160ms 186ms -13.9% StringSlicing: 169ms 178ms -5.3% 174ms 180ms -3.4% TryExcept: 181ms 184ms -1.5% 181ms 184ms -1.5% TryFinally: 157ms 158ms -0.3% 159ms 161ms -1.2% TryRaiseExcept: 183ms 122ms +49.6% 184ms 124ms +48.2% TupleSlicing: 142ms 140ms +1.5% 144ms 141ms +2.0% UnicodeMappings: 198ms 190ms +4.1% 198ms 190ms +4.1% UnicodePredicates: 157ms 175ms -10.2% 157ms 176ms -10.6% UnicodeProperties: 161ms 161ms +0.1% 162ms 170ms -5.0% UnicodeSlicing: 148ms 153ms -3.3% 151ms 155ms -2.6% WithFinally: 191ms 203ms -5.9% 193ms 208ms -7.5% WithRaiseExcept: 151ms 160ms -5.8% 152ms 167ms -9.0% ------------------------------------------------------------------------------- Totals: 9287ms 9363ms -0.8% 9351ms 9455ms -1.1% pybench: 3.0 ------------ Not entirely comparable with the above since some tests disappeared. Test minimum average operation overhead ------------------------------------------------------------------------------- BuiltinFunctionCalls: 134ms 134ms 0.26us 0.631ms BuiltinMethodLookup: 127ms 127ms 0.12us 0.738ms CompareFloats: 174ms 174ms 0.14us 0.845ms CompareFloatsIntegers: 274ms 274ms 0.30us 0.630ms CompareIntegers: 277ms 277ms 0.15us 1.272ms CompareInternedStrings: 261ms 261ms 0.17us 3.201ms CompareLongs: 162ms 162ms 0.15us 0.736ms CompareStrings: 171ms 173ms 0.17us 2.188ms ComplexPythonFunctionCalls: 172ms 178ms 0.89us 1.073ms ConcatStrings: 260ms 273ms 0.55us 1.222ms CreateInstances: 178ms 178ms 1.59us 0.944ms CreateNewInstances: 133ms 135ms 1.61us 0.759ms CreateStringsWithConcat: 253ms 256ms 0.26us 2.127ms DictCreation: 118ms 118ms 0.29us 0.845ms DictWithFloatKeys: 207ms 215ms 0.24us 1.593ms DictWithIntegerKeys: 174ms 176ms 0.15us 2.132ms DictWithStringKeys: 158ms 158ms 0.13us 2.127ms ForLoops: 188ms 188ms 7.51us 0.097ms IfThenElse: 212ms 212ms 0.16us 1.597ms ListSlicing: 111ms 111ms 7.96us 0.165ms NestedForLoops: 218ms 220ms 0.15us 0.001ms NormalClassAttribute: 339ms 340ms 0.28us 1.111ms NormalInstanceAttribute: 186ms 186ms 0.16us 1.116ms PythonFunctionCalls: 156ms 158ms 0.48us 0.633ms PythonMethodCalls: 200ms 201ms 0.89us 0.374ms Recursion: 259ms 260ms 5.21us 1.059ms SecondImport: 128ms 128ms 1.28us 0.417ms SecondPackageImport: 140ms 143ms 1.43us 0.417ms SecondSubmoduleImport: 200ms 200ms 2.00us 0.417ms SimpleComplexArithmetic: 142ms 144ms 0.16us 0.844ms SimpleDictManipulation: 280ms 285ms 0.24us 1.059ms SimpleFloatArithmetic: 161ms 161ms 0.12us 1.275ms SimpleIntFloatArithmetic: 199ms 213ms 0.16us 1.272ms SimpleIntegerArithmetic: 200ms 209ms 0.16us 1.301ms SimpleListManipulation: 165ms 166ms 0.14us 1.379ms SimpleLongArithmetic: 132ms 137ms 0.21us 0.630ms SmallLists: 188ms 191ms 0.28us 0.844ms SmallTuples: 197ms 199ms 0.37us 0.951ms SpecialClassAttribute: 534ms 535ms 0.45us 1.121ms SpecialInstanceAttribute: 185ms 186ms 0.15us 1.125ms StringMappings: 471ms 471ms 1.87us 0.884ms StringPredicates: 190ms 191ms 0.27us 4.315ms StringSlicing: 285ms 290ms 0.52us 1.881ms TryExcept: 182ms 182ms 0.08us 1.663ms TryFinally: 134ms 136ms 0.85us 0.882ms TryRaiseExcept: 137ms 138ms 2.15us 0.885ms TupleSlicing: 202ms 204ms 0.78us 0.110ms WithFinally: 185ms 188ms 1.18us 0.881ms WithRaiseExcept: 274ms 275ms 3.44us 1.105ms ------------------------------------------------------------------------------- Totals: 10011ms 10120ms From skip at pobox.com Sun Aug 24 15:12:06 2008 From: skip at pobox.com (skip at pobox.com) Date: Sun, 24 Aug 2008 08:12:06 -0500 Subject: [Python-Dev] current problems that should be fixed before release (2.6) In-Reply-To: <18609.20792.53909.137357@montanaro-dyndns-org.local> References: <18609.20792.53909.137357@montanaro-dyndns-org.local> Message-ID: <18609.24102.380986.616063@montanaro-dyndns-org.local> me> Seems shallow. Just inherit from object. ... me> I'm testing out the inherit-from-object fixes now. They all passed. Here's the patch: http://bugs.python.org/issue3658 In addition, I get these two test failures on trunk: % ./python.exe ../Lib/test/regrtest.py test_distutils test_multiprocessing test_distutils test test_distutils failed -- Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/distutils/tests/test_build_ext.py", line 23, in setUp shutil.copy(xx_c, self.tmp_dir) File "/Users/skip/src/python/trunk/Lib/shutil.py", line 88, in copy copyfile(src, dst) File "/Users/skip/src/python/trunk/Lib/shutil.py", line 52, in copyfile fsrc = open(src, 'rb') IOError: [Errno 2] No such file or directory: '/Users/skip/src/python/trunk/regular/Modules/xxmodule.c' test_multiprocessing test test_multiprocessing failed -- Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/test/test_multiprocessing.py", line 1223, in test_connection res = conn.recv_bytes_into(buffer) TypeError: argument 1 must be pinned buffer, not bytearray 2 tests failed: test_distutils test_multiprocessing The former is almost certainly because I'm building in a subdirectory of my trunk sandbox. (Doesn't anybody else build that way these days? I routinely encounter problems with this setup.) Looks like distutils.sysconfig.project_base is set incorrectly: % ./python.exe Python 2.6b3+ (trunk:66009M, Aug 24 2008, 07:17:12) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> import sys >>> project_base = os.path.dirname(os.path.abspath(sys.executable)) >>> project_base '/Users/skip/src/python/trunk/regular' I think project_base should be /Users/skip/src/python/trunk, not .../trunk/regular. Skip From michele.simionato at gmail.com Sun Aug 24 12:19:54 2008 From: michele.simionato at gmail.com (michele.simionato at gmail.com) Date: Sun, 24 Aug 2008 03:19:54 -0700 (PDT) Subject: [Python-Dev] Things to Know About Super Message-ID: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> Recently I have opened a blog on Artima and I am publishing a few Python-related essays I had in store. In particular a trilogy of papers about "super". From the foreword: """ In 2004 I decided to write a comprehensive paper documenting ``super`` pitfalls and traps, with the goal of publishing it on the Python web site, just as I had published my essay on multiple inheritance and the `Method Resolution Order`_. With time the paper grew longer and longer but I never had the feeling that I had covered everything I needed to say: moreover I have a full time job, so I never had the time to fully revise the paper as a whole. As a consequence, four years have passed and the paper is still in draft status. This is a pity, since it documents issues that people encounter and that regularly come out on the Python newsgroups and forums. Keeping the draft sitting on my hard disk is doing a disservice to the community. Still, I lack to time to finish it properly. To come out from the impasse, I decided to split the long paper in a series of short blog posts, which I do have the time to review properly. Moreover people are free to post comments and corrections in case I am making mistakes (speaking about ``super`` this is always possible). Once I finish the series, I may integrate the corrections, put it together again and possibly publish it as whole on the Python website. In other words, in order to finish the task, I am trying the strategies of *divide et conquer* and *release early, release often*. We will see how it goes. """ It seems the strategy worked since I have finished the paper, by splitting it in three post. Actually, it it not really finished because it does not say anything about the new super in Python 3.0, but that could do in a separate essay. Here I am asking for feedback/corrections. Moreover if people think it is worthy idea, I can re-assemble the paper again, donate it to the PSF and publish it on the Python website. Michele Simionato From fredrik at pythonware.com Sun Aug 24 15:26:45 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Sun, 24 Aug 2008 15:26:45 +0200 Subject: [Python-Dev] "error: None" when building extensions under 2.6 In-Reply-To: References: Message-ID: Thomas Heller wrote: >> I'm beginning to suspect that I have a botched VS install on this >> machine, though. I'll investigate. > > Do you get a traceback when you set the DISTUTILS_DEBUG environment > variable? Indeed I do: ... File "c:\python26\lib\distutils\msvc9compiler.py", line 436, in compile self.initialize() File "c:\python26\lib\distutils\msvc9compiler.py", line 347, in initialize vc_env = query_vcvarsall(VERSION, plat_spec) File "c:\python26\lib\distutils\msvc9compiler.py", line 239, in query_vcvarsall raise IOError("Unable to find vcvarsall.bat") Oops. Guess that's what you get for having too many Windows development boxes ;-) (a nicer error message in non-debug mode would be a good thing, I think.) PS. Can any resident Microsoft compiler expert perhaps summarize the differences between the Express Edition and the "real" editions wrt. generated code? Are there any differences at all? From lists at cheimes.de Sun Aug 24 15:36:38 2008 From: lists at cheimes.de (Christian Heimes) Date: Sun, 24 Aug 2008 15:36:38 +0200 Subject: [Python-Dev] "error: None" when building extensions under 2.6 In-Reply-To: References: Message-ID: <48B163E6.5090005@cheimes.de> Fredrik Lundh wrote: > PS. Can any resident Microsoft compiler expert perhaps summarize the > differences between the Express Edition and the "real" editions wrt. > generated code? Are there any differences at all? The express edition does neither support PGO (profile guided optimization) nor cross compilation of 64bit binaries on 32bit platforms. The other missing features are mostly uninteresting from the PoV of a extension developer. From wikipedia: Visual C++ 2008 Express does not include OpenMP support, 64-bit compilers, or a resource editor. The higher-end commercial editions of Visual Studio, specifically the Professional and Team Suite editions, have these features. From MS: http://msdn.microsoft.com/en-us/library/hs24szh9.aspx Christian From matt.giuca at gmail.com Sun Aug 24 15:43:01 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Sun, 24 Aug 2008 23:43:01 +1000 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> Message-ID: Hi Michele, Do you have a URL for this blog? Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.giuca at gmail.com Sun Aug 24 17:17:16 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Mon, 25 Aug 2008 01:17:16 +1000 Subject: [Python-Dev] Fwd: Things to Know About Super In-Reply-To: References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <6cd7c525-dd2e-4389-b5ec-73617bfefbf1@m45g2000hsb.googlegroups.com> Message-ID: Had a brief offline discussion with Michele - forwarding. ---------- Forwarded message ---------- From: michele.simionato at gmail.com Date: Mon, Aug 25, 2008 at 12:13 AM On Aug 24, 3:43 pm, "Matt Giuca" wrote: > Hi Michele, > > Do you have a URL for this blog? Sorry, here it is: http://www.artima.com/weblogs/index.jsp?blogger=micheles ---------- Forwarded message ---------- From: Matt Giuca Date: Mon, Aug 25, 2008 at 1:15 AM I skimmed (will read in detail later). As an "intermediate" (I'll describe myself as) Python developer, I tend not to use/understand super (I just call baseclassname.methodname(self,...) directly, so I guess I'm the target audience of this article. It's good - very informative and thorough. It's a bit too informal, personal, and opinionative to be used as "documentation" IMHO but it could certainly be cleaned up without being rewritten. Of interest though, is this: "The first sentence is just plain wrong: super does not return the superclass." >From what I remember of using super, this statement is true, and the documentation is wrong (or at least over-simplifies things). http://docs.python.org/dev/library/functions.html#super http://docs.python.org/dev/3.0/library/functions.html#super Perhaps this should be amended? (A brief statement to the effect of super creating a proxy object which can call the methods of any base class). It actually mentions the "super object" later, even though it claims to be returning the superclass. Also Michele, looks as if super in Python 3 works about the same but has the additional feature of supporting 0 arguments, in which case it defaults to super(this_class, first_arg). (Does not create unbound super objects). Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From nnorwitz at gmail.com Sun Aug 24 19:25:55 2008 From: nnorwitz at gmail.com (Neal Norwitz) Date: Sun, 24 Aug 2008 10:25:55 -0700 Subject: [Python-Dev] performance In-Reply-To: References: Message-ID: Thanks Antoine! On Sun, Aug 24, 2008 at 5:58 AM, Antoine Pitrou wrote: > Neal Norwitz gmail.com> writes: >> Can someone (else) compare performance of 2.5, 2.6, and 3.0? > > Tests done on a 32-bit Linux installation on an Athlon 3600+ X2. Compiled with > gcc in UCS2 mode. > > pystone > ------- > > - 2.5: 43859.6 pystones/second > - 2.6: 42016.8 pystones/second > - 3.0: 38759.7 pystones/second So 3.0 is about 10% slower than 2.x. Given all the changes, that doesn't seem too bad. Though, see below. It looks like at least class attribute lookup is much, much slower. Can you investigate some of these and file bugs as appropriate? > richards.py > ----------- > > (roughly, richards is an object-oriented method-calling benchmark) > > - 2.5: 770.54 ms per iteration > - 2.6: 572.84 ms per iteration > - 3.0: 566.69 ms per iteration I'm a little concerned about why the big change here. Though if I'm reading this right it's a speed up...or am I just being optimistic? The only things I remember that changed between 2.5 and 2.6 that might affect this (without looking at any code) were: 1) Armin's method caching, and 2) the slowdown to isinstance/issubclass which has a release blocker: http://bugs.python.org/issue2534 Can you dig into this and see what caused the slowdown? > > stringbench > ----------- > > - 2.5: unicode: 265.84 s / bytes: 180.50 s > - 2.6: unicode: 256.22 s / bytes: 184.45 s > - 3.0: unicode: 248.07 s / bytes: not tested > > pybench: 2.6 vs. 2.5 > -------------------- > > "this" is 2.6, "other" is 2.5. Hopefully anything >10% is a real change and not just noise. > Test minimum run-time average run-time > this other diff this other diff > ------------------------------------------------------------------------------- > BuiltinFunctionCalls: 177ms 181ms -2.2% 178ms 182ms -2.1% > BuiltinMethodLookup: 157ms 177ms -11.1% 158ms 177ms -11.0% Maybe explained by Armin's patch. > CompareFloats: 171ms 171ms -0.3% 171ms 171ms -0.3% > CompareFloatsIntegers: 158ms 162ms -2.1% 160ms 167ms -4.8% > CompareIntegers: 208ms 208ms -0.0% 209ms 209ms -0.3% > CompareInternedStrings: 189ms 183ms +3.4% 189ms 184ms +2.7% > CompareLongs: 154ms 154ms -0.2% 154ms 154ms -0.2% > CompareStrings: 162ms 159ms +1.7% 163ms 159ms +2.5% > CompareUnicode: 144ms 149ms -3.6% 144ms 152ms -5.0% > ComplexPythonFunctionCalls: 173ms 242ms -28.5% 176ms 243ms -27.6% Maybe explained by Armin's patch. > ConcatStrings: 196ms 198ms -0.9% 203ms 200ms +1.4% > ConcatUnicode: 153ms 151ms +1.5% 155ms 157ms -1.5% > CreateInstances: 172ms 169ms +1.5% 173ms 170ms +1.4% > CreateNewInstances: 131ms 148ms -11.6% 132ms 151ms -12.2% Maybe explained by Armin's patch. > CreateStringsWithConcat: 209ms 206ms +1.4% 209ms 208ms +0.8% > CreateUnicodeWithConcat: 128ms 124ms +3.7% 129ms 124ms +3.4% > DictCreation: 115ms 149ms -22.8% 116ms 150ms -22.8% Why? What changed? > DictWithFloatKeys: 208ms 207ms +0.4% 208ms 208ms +0.0% > DictWithIntegerKeys: 173ms 173ms -0.0% 174ms 173ms +0.5% > DictWithStringKeys: 162ms 162ms -0.1% 162ms 162ms +0.1% > ForLoops: 181ms 181ms -0.2% 181ms 182ms -0.2% > IfThenElse: 169ms 168ms +0.2% 169ms 169ms -0.2% > ListSlicing: 109ms 108ms +0.2% 109ms 109ms +0.1% > NestedForLoops: 198ms 197ms +0.2% 198ms 197ms +0.1% > NormalClassAttribute: 176ms 172ms +2.0% 176ms 173ms +1.7% > NormalInstanceAttribute: 162ms 161ms +1.0% 163ms 161ms +1.1% > PythonFunctionCalls: 161ms 151ms +6.6% 162ms 153ms +6.0% > PythonMethodCalls: 188ms 189ms -0.7% 189ms 193ms -2.0% > Recursion: 235ms 230ms +2.2% 236ms 233ms +1.2% > SecondImport: 113ms 114ms -1.0% 115ms 115ms +0.0% > SecondPackageImport: 120ms 116ms +3.6% 120ms 117ms +2.9% > SecondSubmoduleImport: 154ms 146ms +6.0% 156ms 148ms +5.7% > SimpleComplexArithmetic: 163ms 151ms +8.3% 163ms 151ms +8.6% > SimpleDictManipulation: 177ms 173ms +2.6% 180ms 174ms +3.2% > SimpleFloatArithmetic: 169ms 164ms +3.0% 169ms 166ms +2.2% > SimpleIntFloatArithmetic: 153ms 152ms +1.2% 156ms 153ms +1.8% > SimpleIntegerArithmetic: 156ms 152ms +2.5% 156ms 153ms +2.0% > SimpleListManipulation: 156ms 158ms -1.0% 157ms 158ms -0.5% > SimpleLongArithmetic: 159ms 150ms +6.1% 161ms 151ms +6.3% > SmallLists: 156ms 154ms +1.1% 160ms 155ms +3.0% > SmallTuples: 156ms 155ms +0.4% 157ms 156ms +0.8% > SpecialClassAttribute: 173ms 172ms +0.6% 173ms 172ms +0.7% > SpecialInstanceAttribute: 202ms 198ms +2.4% 203ms 199ms +2.2% > StringMappings: 164ms 170ms -3.2% 165ms 171ms -3.9% > StringPredicates: 160ms 185ms -13.6% 160ms 186ms -13.9% Maybe explained by Armin's patch. > StringSlicing: 169ms 178ms -5.3% 174ms 180ms -3.4% > TryExcept: 181ms 184ms -1.5% 181ms 184ms -1.5% > TryFinally: 157ms 158ms -0.3% 159ms 161ms -1.2% > TryRaiseExcept: 183ms 122ms +49.6% 184ms 124ms +48.2% Whoa, that's a big slowdown. I wonder if it's consistent? > TupleSlicing: 142ms 140ms +1.5% 144ms 141ms +2.0% > UnicodeMappings: 198ms 190ms +4.1% 198ms 190ms +4.1% > UnicodePredicates: 157ms 175ms -10.2% 157ms 176ms -10.6% ? > UnicodeProperties: 161ms 161ms +0.1% 162ms 170ms -5.0% > UnicodeSlicing: 148ms 153ms -3.3% 151ms 155ms -2.6% > WithFinally: 191ms 203ms -5.9% 193ms 208ms -7.5% > WithRaiseExcept: 151ms 160ms -5.8% 152ms 167ms -9.0% > ------------------------------------------------------------------------------- > Totals: 9287ms 9363ms -0.8% 9351ms 9455ms -1.1% > > > pybench: 3.0 > ------------ > > Not entirely comparable with the above since some tests disappeared. > > Test minimum average operation overhead > ------------------------------------------------------------------------------- > BuiltinFunctionCalls: 134ms 134ms 0.26us 0.631ms > BuiltinMethodLookup: 127ms 127ms 0.12us 0.738ms > CompareFloats: 174ms 174ms 0.14us 0.845ms > CompareFloatsIntegers: 274ms 274ms 0.30us 0.630ms Much slower, but probably due to switch from int -> long. There could be potential for optimizing this case. > CompareIntegers: 277ms 277ms 0.15us 1.272ms That's really slow! > CompareInternedStrings: 261ms 261ms 0.17us 3.201ms Much slower, but probably str -> unicode conversion. > CompareLongs: 162ms 162ms 0.15us 0.736ms But this is comparable to 2.x. I don't understand that? > CompareStrings: 171ms 173ms 0.17us 2.188ms > ComplexPythonFunctionCalls: 172ms 178ms 0.89us 1.073ms > ConcatStrings: 260ms 273ms 0.55us 1.222ms This is much slower in 3.0, even taking into account str -> unicode? > CreateInstances: 178ms 178ms 1.59us 0.944ms > CreateNewInstances: 133ms 135ms 1.61us 0.759ms > CreateStringsWithConcat: 253ms 256ms 0.26us 2.127ms > DictCreation: 118ms 118ms 0.29us 0.845ms > DictWithFloatKeys: 207ms 215ms 0.24us 1.593ms > DictWithIntegerKeys: 174ms 176ms 0.15us 2.132ms > DictWithStringKeys: 158ms 158ms 0.13us 2.127ms > ForLoops: 188ms 188ms 7.51us 0.097ms > IfThenElse: 212ms 212ms 0.16us 1.597ms Slower? > ListSlicing: 111ms 111ms 7.96us 0.165ms > NestedForLoops: 218ms 220ms 0.15us 0.001ms > NormalClassAttribute: 339ms 340ms 0.28us 1.111ms Over twice as slow? > NormalInstanceAttribute: 186ms 186ms 0.16us 1.116ms > PythonFunctionCalls: 156ms 158ms 0.48us 0.633ms > PythonMethodCalls: 200ms 201ms 0.89us 0.374ms > Recursion: 259ms 260ms 5.21us 1.059ms > SecondImport: 128ms 128ms 1.28us 0.417ms > SecondPackageImport: 140ms 143ms 1.43us 0.417ms > SecondSubmoduleImport: 200ms 200ms 2.00us 0.417ms > SimpleComplexArithmetic: 142ms 144ms 0.16us 0.844ms > SimpleDictManipulation: 280ms 285ms 0.24us 1.059ms Slower. str -> unicode? > SimpleFloatArithmetic: 161ms 161ms 0.12us 1.275ms > SimpleIntFloatArithmetic: 199ms 213ms 0.16us 1.272ms > SimpleIntegerArithmetic: 200ms 209ms 0.16us 1.301ms > SimpleListManipulation: 165ms 166ms 0.14us 1.379ms > SimpleLongArithmetic: 132ms 137ms 0.21us 0.630ms > SmallLists: 188ms 191ms 0.28us 0.844ms > SmallTuples: 197ms 199ms 0.37us 0.951ms > SpecialClassAttribute: 534ms 535ms 0.45us 1.121ms ~4x slower! > SpecialInstanceAttribute: 185ms 186ms 0.15us 1.125ms > StringMappings: 471ms 471ms 1.87us 0.884ms ~3X slower. > StringPredicates: 190ms 191ms 0.27us 4.315ms > StringSlicing: 285ms 290ms 0.52us 1.881ms > TryExcept: 182ms 182ms 0.08us 1.663ms > TryFinally: 134ms 136ms 0.85us 0.882ms > TryRaiseExcept: 137ms 138ms 2.15us 0.885ms > TupleSlicing: 202ms 204ms 0.78us 0.110ms > WithFinally: 185ms 188ms 1.18us 0.881ms > WithRaiseExcept: 274ms 275ms 3.44us 1.105ms Slower. > ------------------------------------------------------------------------------- > Totals: 10011ms 10120ms > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com > From solipsis at pitrou.net Sun Aug 24 21:04:16 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 24 Aug 2008 21:04:16 +0200 Subject: [Python-Dev] performance In-Reply-To: References: Message-ID: <1219604656.5635.2.camel@fsol> Hi, > So 3.0 is about 10% slower than 2.x. Given all the changes, that > doesn't seem too bad. Yes, I think it's rather good. > > - 2.5: 770.54 ms per iteration > > - 2.6: 572.84 ms per iteration > > - 3.0: 566.69 ms per iteration > > I'm a little concerned about why the big change here. Though if I'm > reading this right it's a speed up...or am I just being optimistic? Yes, it is a speed up. It is thanks to Armin's method cache. > > ComplexPythonFunctionCalls: 173ms 242ms -28.5% 176ms 243ms -27.6% > > Maybe explained by Armin's patch. Actually it is I and Raymond's patch speeding up function calls with named parameters. > > DictCreation: 115ms 149ms -22.8% 116ms 150ms -22.8% > > Why? What changed? The opcode sequence for creation of dict literals has been optimized. > > StringPredicates: 160ms 185ms -13.6% 160ms 186ms -13.9% > > Maybe explained by Armin's patch. I don't think so. > > TryRaiseExcept: 183ms 122ms +49.6% 184ms 124ms +48.2% > > Whoa, that's a big slowdown. I wonder if it's consistent? Yes, I can definitely reproduce it. > > UnicodePredicates: 157ms 175ms -10.2% 157ms 176ms -10.6% > > ? Probably thanks to the speedup in whitespace detection. > > CompareFloatsIntegers: 274ms 274ms 0.30us 0.630ms > > Much slower, but probably due to switch from int -> long. There could > be potential for optimizing this case. Well honestly you don't often compare different types. I think the most common exception to this rule would be None vs. non-None. > > CompareIntegers: 277ms 277ms 0.15us 1.272ms > > That's really slow! > > > CompareInternedStrings: 261ms 261ms 0.17us 3.201ms > > Much slower, but probably str -> unicode conversion. > > > CompareLongs: 162ms 162ms 0.15us 0.736ms > > But this is comparable to 2.x. I don't understand that? I think CompareIntegers and CompareLongs aren't the same tests exactly, although they test the same operations. I've already proposed a patch to speedup comparisons in py3k: http://bugs.python.org/issue3106 > > ConcatStrings: 260ms 273ms 0.55us 1.222ms > > This is much slower in 3.0, even taking into account str -> unicode? The number of rounds is not the same (60000 for 2.6 with unicode, 100000 for 3.0 with str). It should probably be fixed. > > IfThenElse: 212ms 212ms 0.16us 1.597ms > > Slower? It is based on integer comparisons though. > > NormalClassAttribute: 339ms 340ms 0.28us 1.111ms > > Over twice as slow? Yes, should be investigated. > > SimpleDictManipulation: 280ms 285ms 0.24us 1.059ms > > Slower. str -> unicode? No, there are just integers. > > SpecialClassAttribute: 534ms 535ms 0.45us 1.121ms > > ~4x slower! Should be investigated as well. > > StringMappings: 471ms 471ms 1.87us 0.884ms > > ~3X slower. It's normal. This test measures functions like upper(), etc., which are much expensive using the full unicode database than when doing a straight lookup in a 256-entry table. > > WithFinally: 185ms 188ms 1.18us 0.881ms > > WithRaiseExcept: 274ms 275ms 3.44us 1.105ms > > Slower. Yes, the new exception semantics have a cost. Regards Antoine. From martin at v.loewis.de Sun Aug 24 21:35:24 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 24 Aug 2008 21:35:24 +0200 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> References: <48ADDD94.2080903@egenix.com> <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> Message-ID: <48B1B7FC.60706@v.loewis.de> > is the suggestion to *replace* the 4.1.0 database with a 5.1.0 > database, or to add yet another database in that module? I would replace it. > (how's the 3.2/4.1 dual support implemented? The compiler needs data files for all supported versions, with old_versions listing the, well, old versions. It then computes deltas, expecting that they should mostly consist of new assignments (i.e. characters unassigned in 3.2 might be assigned in newer versions). It detects all differences, but might not be able to represent all changes. > do we have two distinct > datasets, or are the differences encoded in some clever way? The latter. It doesn't really need to be that clever: primarily just a compressed list of "new" characters is needed, per version. > would it > make sense to split the unicodedata module into three separate > modules, one for each major Unicode version?) You couldn't use the space savings then, I suppose. Regards, Martin From martin at v.loewis.de Sun Aug 24 21:40:29 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 24 Aug 2008 21:40:29 +0200 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: <48ADDD94.2080903@egenix.com> <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> Message-ID: <48B1B92D.3090204@v.loewis.de> > That's up to us. I don't know what the reason was for keeping the > 3.2.0 database around -- does anyone here recall ever using it? For > what? It's needed for IDNA. The IDNA RFC requires that Unicode 3.2 is used for performing IDNA (in particular, for determining what a valid domain name is). The IDNA people consider it security-relevant that it is really the 3.2 database, and would probably consider it a serious security bug if newer Python versions suddenly started to use newer Unicode databases for IDNA. At some point, IDNA might get updated to a newer version of the Unicode spec; we can then drop 3.2 (and stick with whatever the RFC then specifies). Regards, Martin From martin at v.loewis.de Sun Aug 24 21:44:04 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 24 Aug 2008 21:44:04 +0200 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <368a5cd50808220813r6e48c6a5w25413e1a1c17946a@mail.gmail.com> References: <48ADDD94.2080903@egenix.com> <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> <368a5cd50808220813r6e48c6a5w25413e1a1c17946a@mail.gmail.com> Message-ID: <48B1BA04.40805@v.loewis.de> > I can tinker a little with this over the weekend, unless Martin tells > me not to ;-) Go ahead; I can't work on this at the moment, anyway. I would also be confident that a mere replacement of 4.1 with 5.1 should be easy, and I see no reason to keep the 4.1 version. Perhaps makeunicodedata should list *why* certain old versions remain supported; for 3.2, the use case is IDNA. Regards, Martin From solipsis at pitrou.net Sun Aug 24 21:46:13 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 24 Aug 2008 19:46:13 +0000 (UTC) Subject: [Python-Dev] IDNA References: <48ADDD94.2080903@egenix.com> <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com> <48B1B92D.3090204@v.loewis.de> Message-ID: Martin v. L?wis v.loewis.de> writes: > > It's needed for IDNA. The IDNA RFC requires that Unicode 3.2 is used > for performing IDNA (in particular, for determining what a valid domain > name is). Speaking of which, Martin, did you take a look at http://bugs.python.org/issue3232 ? I suppose the fix is trivial, but I don't know what it should be :-) Regards Antoine. From g.brandl at gmx.net Mon Aug 25 00:37:19 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Mon, 25 Aug 2008 00:37:19 +0200 Subject: [Python-Dev] performance In-Reply-To: <1219604656.5635.2.camel@fsol> References: <1219604656.5635.2.camel@fsol> Message-ID: Antoine Pitrou schrieb: > Hi, pystone ------- - 2.5: 43859.6 pystones/second - 2.6: 42016.8 pystones/second - 3.0: 38759.7 pystones/second >> So 3.0 is about 10% slower than 2.x. Given all the changes, that >> doesn't seem too bad. > > Yes, I think it's rather good. Well, pystone really doesn't test much of what causes the largest slowdowns in 3.0... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From steve at pearwood.info Mon Aug 25 01:54:48 2008 From: steve at pearwood.info (Steven D'Aprano) Date: Mon, 25 Aug 2008 09:54:48 +1000 Subject: [Python-Dev] performance In-Reply-To: <1219604656.5635.2.camel@fsol> References: <1219604656.5635.2.camel@fsol> Message-ID: <200808250954.49208.steve@pearwood.info> On Mon, 25 Aug 2008 05:04:16 am Antoine Pitrou wrote: > > > ? ? ? ? CompareFloatsIntegers: ? ?274ms ? ?274ms ? ?0.30us ? > > > ?0.630ms > > > > Much slower, but probably due to switch from int -> long. ?There > > could be potential for optimizing this case. > > Well honestly you don't often compare different types. I think the > most common exception to this rule would be None vs. non-None. Surely the most common None vs non-None comparison would be the "is" operator, which I hope remains fast. I don't know about other people, but I often compare floats with ints. Here's a contrived example: x = some_float() if x == -1: return -2 else: return (x**2-1)/(x+1) I suppose it's no hardship to start writing float literals instead of int literals, if needed. -- Steven From nnorwitz at gmail.com Mon Aug 25 03:15:06 2008 From: nnorwitz at gmail.com (Neal Norwitz) Date: Sun, 24 Aug 2008 18:15:06 -0700 Subject: [Python-Dev] what version of bsddb to use/accept for 2.6/3.0 Message-ID: Many buildbots are running bsddb 4.7, particularly the debian/ubuntu ones (4.7.25 which seems to be the latest). Some of them are crashing, others are not. The max version we support in both 2.6 and 3.0 is 4.7. Should we allow this version or should we use a lower maximum that is more likely to work (ie, not crash)? It looks like the WIndows buildbots use 4.4.20. Unfortunately, the Windows bots aren't in great shape either. Additionally, there are reference leaks in both 2.6 and 3.0: test_bsddb3 leaked [80, 80] references, sum=160 (2.6) test_bsddb3 leaked [63, 63] references, sum=126 (3.0) It would be nice to get as many of these things fixed up before release. Jesus, Greg, Trent, can you make some time over the next week to stabilize bsddb support? Thanks, n PS. To change the max version of bsddb supported in Unix, modify max_db_ver in setup.py. From doko at ubuntu.com Mon Aug 25 03:21:02 2008 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 25 Aug 2008 03:21:02 +0200 Subject: [Python-Dev] what version of bsddb to use/accept for 2.6/3.0 In-Reply-To: References: Message-ID: <48B208FE.8050600@ubuntu.com> [CCing Clint] 4.7.25 generally looks fine, except for sparc (afaics); I asked the Debian bsddb maintainer to have a look at the sparc problems. At least on sparc, there's no difference between 4.6 and 4.7. I usually try to run the buildbots with the recent software in the distribution, as this is what users will see with the next release. Matthias PS: currently travelling, won't be able to answer in time. Neal Norwitz schrieb: > Many buildbots are running bsddb 4.7, particularly the debian/ubuntu > ones (4.7.25 which seems to be the latest). Some of them are > crashing, others are not. The max version we support in both 2.6 and > 3.0 is 4.7. Should we allow this version or should we use a lower > maximum that is more likely to work (ie, not crash)? > > It looks like the WIndows buildbots use 4.4.20. Unfortunately, the > Windows bots aren't in great shape either. > > Additionally, there are reference leaks in both 2.6 and 3.0: > test_bsddb3 leaked [80, 80] references, sum=160 (2.6) > test_bsddb3 leaked [63, 63] references, sum=126 (3.0) > > It would be nice to get as many of these things fixed up before > release. Jesus, Greg, Trent, can you make some time over the next > week to stabilize bsddb support? > > Thanks, > n > PS. To change the max version of bsddb supported in Unix, modify > max_db_ver in setup.py. From michele.simionato at gmail.com Sun Aug 24 16:12:18 2008 From: michele.simionato at gmail.com (michele.simionato at gmail.com) Date: Sun, 24 Aug 2008 07:12:18 -0700 (PDT) Subject: [Python-Dev] Things to Know About Super In-Reply-To: References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> Message-ID: <922fecbe-e873-4df9-ada1-52730ba53388@79g2000hsk.googlegroups.com> On Aug 24, 3:43?pm, "Matt Giuca" wrote: > Hi Michele, > > Do you have a URL for this blog? > Sorry, here it is: http://www.artima.com/weblogs/index.jsp?blogger=micheles From robert.schuppenies at gmail.com Mon Aug 25 10:32:48 2008 From: robert.schuppenies at gmail.com (Robert Schuppenies) Date: Mon, 25 Aug 2008 10:32:48 +0200 Subject: [Python-Dev] no tp_traverse for dict iters Message-ID: <48B26E30.3020701@gmail.com> Hi. Could you please explain to me why some iterators have a tp_traverse implementation and others do not? For example tupleiterator has one, but none of the dict iterators. Same for set iterators (and possibly others). It shows in Python when you use the get_referents function. >>> t = (1,2,3) >>> gc.get_referents(iter(t)) [(1, 2, 3)] >>> s = set([1,2,3]) >>> gc.get_referents(iter(s)) [] >>> d = {1:1, 2:2} >>> gc.get_referents(iter(d)) [] And is it correct that you can rephrase the question to 'why some iterators are seen as container objects and others are not'? thanks, robert From barry at barrys-emacs.org Mon Aug 25 13:18:50 2008 From: barry at barrys-emacs.org (Barry Scott) Date: Mon, 25 Aug 2008 12:18:50 +0100 Subject: [Python-Dev] Should we help pythonmac.org? In-Reply-To: <6a36e7290808181406w24b8b836wb9619227c0e67333@mail.gmail.com> References: <59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org> <6a36e7290808181406w24b8b836wb9619227c0e67333@mail.gmail.com> Message-ID: <19CF9B30-6D42-4D88-AEC2-49DF0F1AB546@barrys-emacs.org> On Aug 18, 2008, at 22:06, Bob Ippolito wrote: > The major difference between the packages on macports and > pythonmac.org is that macports is their own distro of nearly > everything, akin to installing a copy of FreeBSD over top of Mac OS X. > pythonmac.org contains packages that are self-contained and don't have > a whole new set of libraries to install (in the cases where they do > require libraries, they link them in statically for the most part). > Theses comments are from my point of view as a developer for end users on the Mac. For my pysvn project I release kits for all the python versions * Apple python 2.3 powerpc * Apple python 2.4 intel * MacPython 2.4.x powerpc * MacPython 2.5.x powerpc and intel And in the future I intend to support: * 2.6b3 framework build * 3.0b3 framework build These are all framework builds and they are totally isolated from each other. And I release pysvn as DMG kits as well. For pysvn workbench I use the wxWidgets released DMG kits. And create a application using python module bundlebuilder. Whatever you do should point to a framework build including bundelbuilder which is installed using a Mac installer. Which is the status quo so far. Barry From amauryfa at gmail.com Mon Aug 25 13:22:10 2008 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Mon, 25 Aug 2008 13:22:10 +0200 Subject: [Python-Dev] no tp_traverse for dict iters In-Reply-To: <48B26E30.3020701@gmail.com> References: <48B26E30.3020701@gmail.com> Message-ID: Hello, 2008/8/25 Robert Schuppenies : > Hi. > > Could you please explain to me why some iterators have a tp_traverse > implementation and others do not? For example tupleiterator has one, > but none of the dict iterators. Same for set iterators (and possibly > others). It shows in Python when you use the get_referents function. > >>>> t = (1,2,3) >>>> gc.get_referents(iter(t)) > [(1, 2, 3)] >>>> s = set([1,2,3]) >>>> gc.get_referents(iter(s)) > [] >>>> d = {1:1, 2:2} >>>> gc.get_referents(iter(d)) > [] > > And is it correct that you can rephrase the question to 'why some > iterators are seen as container objects and others are not'? Yes, this can lead to some object cycle that are not collected. See the attached script: a cycle involving a list iterator is collected by the garbage collector, but a cycle with a dict iterator is not. This is worth a bug report IMO. -- Amaury Forgeot d'Arc -------------- next part -------------- A non-text attachment was scrubbed... Name: cycle.py Type: text/x-python Size: 740 bytes Desc: not available URL: From barry at python.org Mon Aug 25 14:50:01 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 25 Aug 2008 08:50:01 -0400 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: Message-ID: <33B21715-8C49-4AE2-BB7D-8829264DCC64@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was away for the weekend and am struggling to catch up on my email. Since I haven't digested this entire thread, I'll refrain for the moment from giving my opinion, however this comment jumped out to me. On Aug 22, 2008, at 9:42 AM, Facundo Batista wrote: > - We always could have a beta4 if it's necessary... I do not want to slip the schedule if at all possible. If serious security issues, performance problems, show stopper bugs crop up, then we will obviously slip so that we don't have to put a brown bag over our heads. Slipping to get yet one more feature in is not (IMO) acceptable. An incentive for keeping the schedule: If we hit our October 1st deadline, then 2.6 and 3.0 will almost certainly be included in some upcoming major new OS releases. If we slip, then it's unlikely to happen. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLKqenEjvBPtnXfVAQJukAP+L93nxTP436Au9GkLZQUhy1Gbk8rDvq2K jZtJA5Rb9VKUr7TDoqZ2iFRRg9tsxwz+fLzZp0m00WWGRvKHdgqS+c6sHBaXazzk txFhyspkw0cndD7zsNoqThlY6Q1CkhK3BHYmRLWS+PVhfOm6bRgudL+ePcWneT2X 24pFB83GSjo= =/lq8 -----END PGP SIGNATURE----- From horvath.arpad at roik.bmf.hu Mon Aug 25 15:19:56 2008 From: horvath.arpad at roik.bmf.hu (harp) Date: Mon, 25 Aug 2008 06:19:56 -0700 (PDT) Subject: [Python-Dev] Doc translation -- from LaTeX to reStructuredText In-Reply-To: <1afaf6160808221118p3a6f032btf0e93183798362a7@mail.gmail.com> References: <1afaf6160808221118p3a6f032btf0e93183798362a7@mail.gmail.com> Message-ID: <06ddf912-ef51-47d4-bbd4-783b0da08ab8@a1g2000hsb.googlegroups.com> Not succeeded. I have done these steps: - I downloaded the tutorial in LaTeX. (http://www.python.org/doc/2.5.2/ download/ ) - Extracted. - Put the hungarian tut.tex into the tut directory - downloaded the files from http://svn.python.org/view/doctools/converter - Run the `convert.py . ../pydoc` in the /Python-Docs-2.5.2 directory - Because of some errors* I leave only the 'tut' item in the subdirs in converter/__init__.py (for subdir in...) - Run again. - In the pydoc/tutorial directory there is only an index.rst file. No appetite.rst and so on. And the index.rst is english as well. *The error message mentioned above: (...) lib/libal.tex lib/liballos.tex Traceback (most recent call last): File "./converter/convert.py", line 26, in convert_dir(destdir, *sys.argv[3:]) File "/home/ha/Munkaasztal/Python-Docs-2.5.2/convert/converter/ __init__.py", line 86, in convert_dir newname = fn_mapping[subdir][filename] KeyError: 'libamoeba' On aug. 22, 20:18, "Benjamin Peterson" wrote: > On Fri, Aug 22, 2008 at 9:03 AM, harp wrote: > > ?Dear Developers, > > > We have translated the tutorial into Hungarian earlier, and I do not > > know how to convert the LaTeX file into reStructuredText. Could > > somebody help us? > > Have you looked at the LaTeX to reST converter athttp://svn.python.org/view/doctools/converter? > > > > > HTML:http://pythonlib.pergamen.hu/html/tut/ > > LaTeX file:http://mail.roik.bmf.hu/linux/python/tutorial/tut.tex > > > There will be included translations of documentation on the python.org > > homepage? > > > ? Arpad .python.org/mailman/options/python-dev/musiccomposition%40... > > -- > Cheers, > Benjamin Peterson > "There's no place like 127.0.0.1." From ismail at namtrac.org Mon Aug 25 15:43:43 2008 From: ismail at namtrac.org (=?UTF-8?Q?=C4=B0smail_D=C3=B6nmez?=) Date: Mon, 25 Aug 2008 16:43:43 +0300 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: Message-ID: <19e566510808250643v496a138dp64fa45f3eda9ee8d@mail.gmail.com> Hi, On Thu, Aug 21, 2008 at 23:35, Guido van Rossum wrote: > I was just paid a visit by my Google colleague Mark Davis, co-founder > of the Unicode project and the president of the Unicode Consortium. He > would like to see improved Unicode support for Python. (Well duh. :-) > On his list of top priorities are: > > 1. Upgrade the unicodata module to the Unicode 5.1.0 standard > 2. Extende the unicodedata module with some additional properties > 3. Add support for Unicode properties to the regex syntax, including > Boolean combinations Adding support for SpecialCasing rules[0] would be good for full Unicode support too. It would fix i/I problems that are currently going on with Turkish locale. [0] http://unicode.org/Public/UNIDATA/SpecialCasing.txt Regards, ismail -- Programmer Excuse #17: The processor stack spring has worn out. From mal at egenix.com Mon Aug 25 16:06:33 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 25 Aug 2008 16:06:33 +0200 Subject: [Python-Dev] try-except slower in 2.6 (was: performance) In-Reply-To: <1219604656.5635.2.camel@fsol> References: <1219604656.5635.2.camel@fsol> Message-ID: <48B2BC69.3080601@egenix.com> On 2008-08-24 21:04, Antoine Pitrou wrote: >>> TryRaiseExcept: 183ms 122ms +49.6% 184ms 124ms +48.2% >> Whoa, that's a big slowdown. I wonder if it's consistent? > > Yes, I can definitely reproduce it. That's a huge slow-down compared to 2.5. Are there any obvious reasons for this ? Has the exception handling mechanism changed that much between 2.5 and 2.6 ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 25 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From mal at egenix.com Mon Aug 25 16:49:45 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 25 Aug 2008 16:49:45 +0200 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: <48ADDD94.2080903@egenix.com> Message-ID: <48B2C689.5030503@egenix.com> On 2008-08-22 03:25, Guido van Rossum wrote: > On Thu, Aug 21, 2008 at 2:26 PM, M.-A. Lemburg wrote: >> On 2008-08-21 22:35, Guido van Rossum wrote: >>> I was just paid a visit by my Google colleague Mark Davis, co-founder >>> of the Unicode project and the president of the Unicode Consortium. He >>> would like to see improved Unicode support for Python. (Well duh. :-) >>> On his list of top priorities are: >>> >>> 1. Upgrade the unicodata module to the Unicode 5.1.0 standard >>> 2. Extende the unicodedata module with some additional properties >>> 3. Add support for Unicode properties to the regex syntax, including >>> Boolean combinations >>> >>> I've tried to explain our release schedule and >>> no-new-features-in-point-releases policies to him, and he understands >>> that it's too late to add #2 or #3 to 2.6 and 3.0, and that these will >>> have to wait for 2.7 and 3.1, respectively. However, I've kept the >>> door sligthtly ajar for adding #1 -- it can't be too much work and it >>> can't have too much impact. Or can it? I don't actually know what the >>> impact would be, so I'd like some impact from developers who are >>> closer to the origins of the unicodedata module. >>> >>> The two, quite separate, questions, then, are (a) how much work would >>> it be to upgrade to version 5.1.0 of the database; and (b) would it be >>> acceptable to do this post-beta3 (but before rc1). If the answer to >>> (b) is positive, Google can help with (a). >>> >>> In general, Google has needs in this area that can't wait for 2.7/3.1, >>> so what we may end up doing is create internal implementations of all >>> three features (compatible with Python 2.4 and later), publish them as >>> open source on Google Code, and fold them into core Python at the >>> first opportunity, which would likely be 2.7 and 3.1. >>> >>> Comments? >> There are two things to consider: >> >> unicodedata is just an optimized database for accessing code >> point properties of a specific Unicode version (currently 4.1.0 >> and 3.2.0). Adding support for a new version needs some work on >> the generation script, perhaps keeping the 4.1.0 version of it >> like we did for 3.2.0, but that's about it. >> >> However, there are other implications to consider when moving to >> Unicode 5.1.0. >> >> Just see the top of http://www.unicode.org/versions/Unicode5.1.0/ >> for a summary of changes compared to 5.0, plus >> http://www.unicode.org/versions/Unicode5.0.0/ for changes between >> 4.1.0 and 5.0. >> >> So while we could say: "we provide access to the Unicode 5.1.0 >> database", we cannot say: "we support Unicode 5.1.0", simply because >> we have not reviewed the all the necessary changes and implications. > > Mark's response to this was: > > """ > I'd suspect that you'll be as conformant to U5.1.0 as you were to U4.1.0 ;-) > > More seriously, I don't think this is a roadblock -- I doubt that > there are real differences between U5.1.0 and U4.10 in terms of > conformance that would be touched by Python -- the conformance changes > tend to be either completely backward compatible or very esoteric. > What I can do is to review the Python support to see if and where > there are any problems, but I wouldn't anticipate any. > """ > > Which suggests that he believes that the differences in the database > are very minor, and that upgrading just the database would not cause > any problems for code that worked well with the 4.1.0 database. Fine with me. >> I think it's better to look through all the changes and then come >> up with proper support for 2.7/3.1. If Google wants to contribute >> to this, even better. To avoid duplication of work or heading in >> different directions, it may be a good idea to create a >> unicode-sig to discuss things. > > Not me. :-) I would really like to see more Unicode support in Python, e.g. for collation, compression, indexing based on graphemes and code points, better support for special casing situations (to cover e.g. the dotted vs. non-dotted i in the Turkish scripts), etc. There are also a few changes that we'd need to incorporate into the UTF codecs, e.g. warn about more ill-formed byte sequences. Would Google be willing to contribute such support or part of it ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 25 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From solipsis at pitrou.net Mon Aug 25 17:42:41 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 25 Aug 2008 15:42:41 +0000 (UTC) Subject: [Python-Dev] try-except slower in 2.6 (was: performance) References: <1219604656.5635.2.camel@fsol> <48B2BC69.3080601@egenix.com> Message-ID: M.-A. Lemburg egenix.com> writes: > > That's a huge slow-down compared to 2.5. > > Are there any obvious reasons for this ? Has the exception handling > mechanism changed that much between 2.5 and 2.6 ? I've looked at it a bit and I think it's because of the issubclass()/isinstance() slowdown (which itself is due to ABCs). If I apply the patch in http://bugs.python.org/issue2534, the exception handling slowdown seems to disappear. From guido at python.org Mon Aug 25 18:04:20 2008 From: guido at python.org (Guido van Rossum) Date: Mon, 25 Aug 2008 09:04:20 -0700 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <48B2C689.5030503@egenix.com> References: <48ADDD94.2080903@egenix.com> <48B2C689.5030503@egenix.com> Message-ID: 2008/8/25 M.-A. Lemburg : > I would really like to see more Unicode support in Python, e.g. > for collation, compression, indexing based on graphemes and > code points, better support for special casing situations (to > cover e.g. the dotted vs. non-dotted i in the Turkish scripts), > etc. > > There are also a few changes that we'd need to incorporate into > the UTF codecs, e.g. warn about more ill-formed byte sequences. > > Would Google be willing to contribute such support or part > of it ? That depends purely on how much need Google itself has for these features. I'll ask around, but for now I wouldn't bet on anything beyond the three points I raised at the start of this thread: 1. Upgrade the unicodata module to the Unicode 5.1.0 standard 2. Extende the unicodedata module with some additional properties 3. Add support for Unicode properties to the regex syntax, including Boolean combinations -- --Guido van Rossum (home page: http://www.python.org/~guido/) -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Mon Aug 25 19:13:32 2008 From: guido at python.org (Guido van Rossum) Date: Mon, 25 Aug 2008 10:13:32 -0700 Subject: [Python-Dev] subprocess insufficiently platform-independent? Message-ID: Several people at Google seem to have independently discovered that despite all of the platform-independent goodness in subprocess.py, you still need to be platform aware. One of my colleagues summarized it like this: """ Given a straightforward command list like: cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk'] You apparently cannot pass this list to any subprocess function (subprocess.call() or otherwise) with a set of arguments that allow it to "just work" on both Windows and non-Windows systems. If you call: subprocess.call(cmd, shell=False) Then it works on Linux, but fails on Windows because it does not perform the Windows %PATHEXT% search that allows it to find that "svn.exe" is the actual executable to be invoked. If you call: subprocess.call(cmd, shell=True) Then it works on Windows (it finds the "svn.exe" executable), but it fails on Linux because it *only* executes the first argument in the list ("svn") and does not pass the remaining arguments in the list to the "svn" invocation. This forces you to code platform-dependent behavior in how you call subprocess.call() when using a list. For example, you can make the shell= argument depend on the platform you're running on, like: subprocess.call(cmd, shell=(sys.platform=='win32')) Or you could vary cmd[0] in your list based on the platform: if sys.platform == 'win32': svn = 'svn.exe' else: svn = 'svn' cmd = [svn, 'ls', 'http://rietveld.googlecode.com/svn/trunk'] But either way, this seems clearly broken (or at least sub-optimal) for a module that's supposed to abstract platform-specific execution issues from the user. """ -- --Guido van Rossum (home page: http://www.python.org/~guido/) From tjreedy at udel.edu Mon Aug 25 19:13:33 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 25 Aug 2008 13:13:33 -0400 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: <48ADDD94.2080903@egenix.com> <48B2C689.5030503@egenix.com> Message-ID: Guido van Rossum wrote: > 2008/8/25 M.-A. Lemburg >: > > I would really like to see more Unicode support in Python, e.g. > > for collation, compression, indexing based on graphemes and > > code points, better support for special casing situations (to > > cover e.g. the dotted vs. non-dotted i in the Turkish scripts), > > etc. > > > > There are also a few changes that we'd need to incorporate into > > the UTF codecs, e.g. warn about more ill-formed byte sequences. > > > > Would Google be willing to contribute such support or part > > of it ? > > That depends purely on how much need Google itself has for these > features. I'll ask around, but for now I wouldn't bet on anything beyond > the three points I raised at the start of this thread: > > 1. Upgrade the unicodata module to the Unicode 5.1.0 standard > 2. Extende the unicodedata module with some additional properties > 3. Add support for Unicode properties to the regex syntax, including > Boolean combinations I think an Improve Unicode Support PEP would be a good idea to collect (and get approval or not for) various ideas from various people, even if Google only implements part of the PEP. From barry at python.org Mon Aug 25 19:30:58 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 25 Aug 2008 13:30:58 -0400 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: References: Message-ID: <989B2B74-D5AB-4FAA-BE6D-8D409D194388@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 25, 2008, at 1:13 PM, Guido van Rossum wrote: > Several people at Google seem to have independently discovered that > despite all of the platform-independent goodness in subprocess.py, you > still need to be platform aware. One of my colleagues summarized it > like this: > > """ > Given a straightforward command list like: > > cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk'] > > You apparently cannot pass this list to any subprocess function > (subprocess.call() or otherwise) with a set of arguments that allow it > to "just work" on both Windows and non-Windows systems. Unless I'm misremembering (I no longer have access to Windows), I believe that if you use ' '.join(cmd) as the first argument, it will work cross-platform. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLLsU3EjvBPtnXfVAQJapQP+N4HY0I/uczbdQKB1bi6OV0BZgj5JS8an Tz4FEnaD9LDegTnV8fqAx5/blIidZEdPjVkdmW4m4bz8tRNIEdoZyghHUmKycgRj d65FU0e1tL40u0AoKl3ARO6WWkKKhaqn4R17065lh+V1ZNKutu2btiAso6VfWVW5 V7hvo/61ACM= =P0Nb -----END PGP SIGNATURE----- From phd at phd.pp.ru Mon Aug 25 19:33:46 2008 From: phd at phd.pp.ru (Oleg Broytmann) Date: Mon, 25 Aug 2008 21:33:46 +0400 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: <989B2B74-D5AB-4FAA-BE6D-8D409D194388@python.org> References: <989B2B74-D5AB-4FAA-BE6D-8D409D194388@python.org> Message-ID: <20080825173346.GA24017@phd.pp.ru> On Mon, Aug 25, 2008 at 01:30:58PM -0400, Barry Warsaw wrote: > Unless I'm misremembering (I no longer have access to Windows), I > believe that if you use ' '.join(cmd) as the first argument, it will > work cross-platform. What about arguments that contain spaces? Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From guido at python.org Mon Aug 25 19:34:09 2008 From: guido at python.org (Guido van Rossum) Date: Mon, 25 Aug 2008 10:34:09 -0700 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: <989B2B74-D5AB-4FAA-BE6D-8D409D194388@python.org> References: <989B2B74-D5AB-4FAA-BE6D-8D409D194388@python.org> Message-ID: On Mon, Aug 25, 2008 at 10:30 AM, Barry Warsaw wrote: > Unless I'm misremembering (I no longer have access to Windows), I believe > that if you use ' '.join(cmd) as the first argument, it will work > cross-platform. That will mean something different if there are spaces or shell metacharacters in the arguments. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From barry at python.org Mon Aug 25 19:34:39 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 25 Aug 2008 13:34:39 -0400 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: Message-ID: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote: > > http://www.unicode.org/versions/Unicode5.1.0/ > "Unicode 5.1.0 contains over 100,000 characters, and provides > significant additions and improvements..." to existing features, > including new files and upgrades to existing files. Sounds close to > adding features ;-) I agree. This seriously feels like new, potentially high risk code to be adding this late in the game. The BDFL can always override, but unless someone is really convincing that this is low risk high benefit, I'd vote no for 2.6/3.0. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLLtMnEjvBPtnXfVAQKg0wP+LJ1XYXhEQHUAvT3fPbPzStCN8Lb+D7XG hZOANnTCbPGaeCY19B8mYZbXkvjkCBptauKGB5yGOAnb1KCkSaQWx0wCInkeyIFE mVMupGZCUsdsO7KreEwvyhBpOJ/HNY0+eacv8GZKCwC9xW3WmhaOjry7sZFhjffw hAX1AuxaPWA= =2j8a -----END PGP SIGNATURE----- From barry at python.org Mon Aug 25 19:36:45 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 25 Aug 2008 13:36:45 -0400 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: <20080825173346.GA24017@phd.pp.ru> References: <989B2B74-D5AB-4FAA-BE6D-8D409D194388@python.org> <20080825173346.GA24017@phd.pp.ru> Message-ID: <152426DD-3825-4DA6-B420-24A6CC319F13@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 25, 2008, at 1:33 PM, Oleg Broytmann wrote: > On Mon, Aug 25, 2008 at 01:30:58PM -0400, Barry Warsaw wrote: >> Unless I'm misremembering (I no longer have access to Windows), I >> believe that if you use ' '.join(cmd) as the first argument, it will >> work cross-platform. > > What about arguments that contain spaces? Oh sure, throw a monkey wrench into it . Guido's original problem statement is still correct though. It's advertised to take a sequence of arguments, so that should work. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLLtr3EjvBPtnXfVAQKJpgP/TPmVgsRdRiAE+jvZOCl9unHWU6LtLSx/ uU3gIkQfvPYcyv9oUS0mcTwWsRDCeP42foQxP+MgX2Zx1ItQPi8/QDbW2bS809pF q8igObharc0kSokhTw2zrkNXsEx3S+epPJXaiueY2cs9jC4mCvXnlnt67ZtWEc8r r+eNLlI2/eo= =SfRl -----END PGP SIGNATURE----- From steven.bethard at gmail.com Mon Aug 25 19:39:22 2008 From: steven.bethard at gmail.com (Steven Bethard) Date: Mon, 25 Aug 2008 11:39:22 -0600 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: <989B2B74-D5AB-4FAA-BE6D-8D409D194388@python.org> References: <989B2B74-D5AB-4FAA-BE6D-8D409D194388@python.org> Message-ID: On Mon, Aug 25, 2008 at 11:30 AM, Barry Warsaw wrote: > On Aug 25, 2008, at 1:13 PM, Guido van Rossum wrote: > >> Several people at Google seem to have independently discovered that >> despite all of the platform-independent goodness in subprocess.py, you >> still need to be platform aware. One of my colleagues summarized it >> like this: >> >> """ >> Given a straightforward command list like: >> >> cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk'] >> >> You apparently cannot pass this list to any subprocess function >> (subprocess.call() or otherwise) with a set of arguments that allow it >> to "just work" on both Windows and non-Windows systems. > > Unless I'm misremembering (I no longer have access to Windows), I believe > that if you use ' '.join(cmd) as the first argument, it will work > cross-platform. FWIW, I've also struggled with similar issues. For example, with no shell= argument, Windows typically opens up an extra window to run the command, while Unix doesn't. My most recent hack around this looked something like:: try: import win32con except ImportError: win32con = None kwargs = dict(...) if win32con is not None: kwargs['creationflags'] = win32con.CREATE_NO_WINDOW subprocess.Popen(cmd, **kwargs) I'd love to see subprocess become more consistent cross-platform. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy From fumanchu at aminus.org Mon Aug 25 19:32:36 2008 From: fumanchu at aminus.org (Robert Brewer) Date: Mon, 25 Aug 2008 10:32:36 -0700 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: References: Message-ID: Guido van Rossum wrote: > Several people at Google seem to have independently discovered that > despite all of the platform-independent goodness in subprocess.py, you > still need to be platform aware. I can verify this. For CP we went back to using spawnl, but in an internal project we checked sys.platform and set shell=True for Windows. Robert Brewer fumanchu at aminus.org From exarkun at divmod.com Mon Aug 25 19:44:09 2008 From: exarkun at divmod.com (Jean-Paul Calderone) Date: Mon, 25 Aug 2008 13:44:09 -0400 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: Message-ID: <20080825174409.29191.1018559950.divmod.quotient.18404@ohm> On Mon, 25 Aug 2008 10:13:32 -0700, Guido van Rossum wrote: >Several people at Google seem to have independently discovered that >despite all of the platform-independent goodness in subprocess.py, you >still need to be platform aware. One of my colleagues summarized it >like this: > >""" >Given a straightforward command list like: > > cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk'] > Launching child processes on Windows is actually pretty hard to do. The idea of an array of arguments is more like a group hallucination than a reality there. If you assume certain things about how the launched process will interpret its command line (something each program gets to decide for itself on Windows), and many programs do actually use the same rules, then you can get something together that mostly works and is mostly general. Twisted's process support does this and presents a cross-platform API (at least as far as arguments are concerned). Perhaps the subprocess module should borrow that implementation? http://twistedmatrix.com/trac/browser/trunk/twisted/python/win32.py#L66 This doesn't handle all possible inputs correctly (you can read about its flaws in some detail at ) but it does handle *most* inputs. It also isn't appropriate for all programs, but for the programs which don't follow these quoting rules, it's probably a mistake to have a list-based API anyway: they should be invoked using one string giving the entire command line. Jean-Paul From musiccomposition at gmail.com Mon Aug 25 19:52:39 2008 From: musiccomposition at gmail.com (Benjamin Peterson) Date: Mon, 25 Aug 2008 12:52:39 -0500 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> References: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> Message-ID: <1afaf6160808251052q78fea0c2u4ca97ac911bab7e7@mail.gmail.com> On Mon, Aug 25, 2008 at 12:34 PM, Barry Warsaw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote: >> >> http://www.unicode.org/versions/Unicode5.1.0/ >> "Unicode 5.1.0 contains over 100,000 characters, and provides significant >> additions and improvements..." to existing features, including new files and >> upgrades to existing files. Sounds close to adding features ;-) > > I agree. This seriously feels like new, potentially high risk code to be > adding this late in the game. The BDFL can always override, but unless > someone is really convincing that this is low risk high benefit, I'd vote no > for 2.6/3.0. +1 Something I think we should also be considering is the 2.7/3.1 release cycle. I propose that we shorten it to ~1 year from 2.6/3.0's release with our main aim being binding 2.x and 3.x more closely. This would get the new unicode features out fairly quickly without having to wait another 2.5 years like 2.5 -> 2.6. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." From fredrik at pythonware.com Mon Aug 25 19:53:07 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 25 Aug 2008 19:53:07 +0200 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> References: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> Message-ID: Barry Warsaw wrote: > I agree. This seriously feels like new, potentially high risk code to > be adding this late in the game. The BDFL can always override, but > unless someone is really convincing that this is low risk high benefit, > I'd vote no for 2.6/3.0. at least two Unicode experts have stated that they don't think the changes are that important. determining exactly what the changes to the *core* character database was the whole point of my offer to tinker with this. (I got distracted due to compiler issues and certain other things to be announced later, but I expect to have some results later this week). From guido at python.org Mon Aug 25 19:56:05 2008 From: guido at python.org (Guido van Rossum) Date: Mon, 25 Aug 2008 10:56:05 -0700 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <1afaf6160808251052q78fea0c2u4ca97ac911bab7e7@mail.gmail.com> References: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> <1afaf6160808251052q78fea0c2u4ca97ac911bab7e7@mail.gmail.com> Message-ID: On Mon, Aug 25, 2008 at 10:52 AM, Benjamin Peterson wrote: > On Mon, Aug 25, 2008 at 12:34 PM, Barry Warsaw wrote: >> On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote: >>> >>> http://www.unicode.org/versions/Unicode5.1.0/ >>> "Unicode 5.1.0 contains over 100,000 characters, and provides significant >>> additions and improvements..." to existing features, including new files and >>> upgrades to existing files. Sounds close to adding features ;-) >> >> I agree. This seriously feels like new, potentially high risk code to be >> adding this late in the game. The BDFL can always override, but unless >> someone is really convincing that this is low risk high benefit, I'd vote no >> for 2.6/3.0. > > +1 > > Something I think we should also be considering is the 2.7/3.1 release > cycle. I propose that we shorten it to ~1 year from 2.6/3.0's release > with our main aim being binding 2.x and 3.x more closely. This would > get the new unicode features out fairly quickly without having to wait > another 2.5 years like 2.5 -> 2.6. I was never proposing to support any new features in 2.6/3.0. I was only proposing to update the data files that we already support to the versions provided by 5.1.0. Those data files should have the same format, just slightly improved content: some new characters, some corrected properties. Fredrik says it best: > at least two Unicode experts have stated that they don't think the changes > are that important. determining exactly what the changes to the *core* > character database was the whole point of my offer to tinker with this. > > (I got distracted due to compiler issues and certain other things to be > announced later, but I expect to have some results later this week). -- --Guido van Rossum (home page: http://www.python.org/~guido/) From musiccomposition at gmail.com Mon Aug 25 20:05:30 2008 From: musiccomposition at gmail.com (Benjamin Peterson) Date: Mon, 25 Aug 2008 13:05:30 -0500 Subject: [Python-Dev] 2to3 patches and reviews Message-ID: <1afaf6160808251105xf189a01nf7978465ba3a408b@mail.gmail.com> I've been working on and reviewing some of the release blocking 2to3 patches and issues. Unfortunately, it seems like we don't have many core devs available for reviewing 2to3 changes. I have one patch in particular [1] that I would like to get in soon, since it changes the API a bit to make it more extensible. [1] http://bugs.python.org/3637 -- Thanks, Benjamin Peterson "There's no place like 127.0.0.1." From mal at egenix.com Mon Aug 25 20:15:36 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 25 Aug 2008 20:15:36 +0200 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> References: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> Message-ID: <48B2F6C8.90800@egenix.com> On 2008-08-25 19:34, Barry Warsaw wrote: > On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote: > >> http://www.unicode.org/versions/Unicode5.1.0/ >> "Unicode 5.1.0 contains over 100,000 characters, and provides >> significant additions and improvements..." to existing features, >> including new files and upgrades to existing files. Sounds close to >> adding features ;-) > > I agree. This seriously feels like new, potentially high risk code to > be adding this late in the game. The BDFL can always override, but > unless someone is really convincing that this is low risk high benefit, > I'd vote no for 2.6/3.0. The above quote from the Unicode site is misleading in this context. Guido's request was just for updating the Unicode database with the data from 5.1 - without adding new support for properties or changing the interfaces. See this page for a list of changes to the Unicode database: http://www.unicode.org/Public/UNIDATA/UCD.html The main file used for the unicodedata module is called "UnicodeData.txt". -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 25 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From brett at python.org Mon Aug 25 20:16:33 2008 From: brett at python.org (Brett Cannon) Date: Mon, 25 Aug 2008 11:16:33 -0700 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> <1afaf6160808251052q78fea0c2u4ca97ac911bab7e7@mail.gmail.com> Message-ID: On Mon, Aug 25, 2008 at 10:56 AM, Guido van Rossum wrote: > On Mon, Aug 25, 2008 at 10:52 AM, Benjamin Peterson > wrote: >> On Mon, Aug 25, 2008 at 12:34 PM, Barry Warsaw wrote: >>> On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote: >>>> >>>> http://www.unicode.org/versions/Unicode5.1.0/ >>>> "Unicode 5.1.0 contains over 100,000 characters, and provides significant >>>> additions and improvements..." to existing features, including new files and >>>> upgrades to existing files. Sounds close to adding features ;-) >>> >>> I agree. This seriously feels like new, potentially high risk code to be >>> adding this late in the game. The BDFL can always override, but unless >>> someone is really convincing that this is low risk high benefit, I'd vote no >>> for 2.6/3.0. >> >> +1 >> >> Something I think we should also be considering is the 2.7/3.1 release >> cycle. I propose that we shorten it to ~1 year from 2.6/3.0's release >> with our main aim being binding 2.x and 3.x more closely. This would >> get the new unicode features out fairly quickly without having to wait >> another 2.5 years like 2.5 -> 2.6. > > I was never proposing to support any new features in 2.6/3.0. I was > only proposing to update the data files that we already support to the > versions provided by 5.1.0. Those data files should have the same > format, just slightly improved content: some new characters, some > corrected properties. Fredrik says it best: > >> at least two Unicode experts have stated that they don't think the changes >> are that important. determining exactly what the changes to the *core* >> character database was the whole point of my offer to tinker with this. >> >> (I got distracted due to compiler issues and certain other things to be >> announced later, but I expect to have some results later this week). > Plus the Europeans who probably use Unicode more than the dissenting Americans also seem to think it's a good idea. It's just a data table, and it's auto-generated, *and* one of the main guys from the Unicode Consortium is willing to help. I say let the change go in. -Brett From arfrever.fta at gmail.com Mon Aug 25 20:40:26 2008 From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 25 Aug 2008 20:40:26 +0200 Subject: [Python-Dev] [PATCH] Respect LDFLAGS Message-ID: <200808252040.34277.Arfrever.FTA@gmail.com> I'm attaching the patch which fixes respecting LDFLAGS when building libpython$(VERSION).so. -- Arfrever Frehtes Taifersar Arahesis -------------- next part -------------- A non-text attachment was scrubbed... Name: python-respect_LDFLAGS.patch Type: text/x-diff Size: 712 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From barry at python.org Mon Aug 25 21:04:40 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 25 Aug 2008 15:04:40 -0400 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> Message-ID: <6DD88C6B-7586-43C9-A060-A1D8C5D3E4E3@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 25, 2008, at 1:53 PM, Fredrik Lundh wrote: > Barry Warsaw wrote: > >> I agree. This seriously feels like new, potentially high risk code >> to be adding this late in the game. The BDFL can always override, >> but unless someone is really convincing that this is low risk high >> benefit, I'd vote no for 2.6/3.0. > > at least two Unicode experts have stated that they don't think the > changes are that important. determining exactly what the changes to > the *core* character database was the whole point of my offer to > tinker with this. You don't mean the experts claimed they weren't important, right? Unimportant changes definitely don't need to go in now . - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLMCSHEjvBPtnXfVAQKgLwP/YlrqcdlmoeBsK9JdJMnxkgN92L1K86cg lzvQT6bv8vda64Su8bV81UT+NdoB+/ZGpZ1t+Dn4Z0uvB0uaVrZZ7uOUoqQTkvG7 yrj/Clbedi2v35vYjudqAaZyBnJtz+V0rH8tdgpDVU5zILSK4gQm385nFuoUXQpC iJlqok3tjuU= =YfQR -----END PGP SIGNATURE----- From barry at python.org Mon Aug 25 21:07:52 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 25 Aug 2008 15:07:52 -0400 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <48B2F6C8.90800@egenix.com> References: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> <48B2F6C8.90800@egenix.com> Message-ID: <41911284-196D-484A-97DD-A2AD8547D826@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 25, 2008, at 2:15 PM, M.-A. Lemburg wrote: > Guido's request was just for updating the Unicode database with > the data from 5.1 - without adding new support for properties or > changing the interfaces. > > See this page for a list of changes to the Unicode database: > > http://www.unicode.org/Public/UNIDATA/UCD.html > > The main file used for the unicodedata module is called > "UnicodeData.txt". That's much less scary. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLMDCHEjvBPtnXfVAQIrYQQAoABjn/KWd8VdFeplR1i3Lqx5lNAWiJu9 6QWhE/4PPGpCBWhsUejnqHTdCOHmo7y6g3YWwPJ1hDZbl+oXrHd4/bcnHWMJgbOO BV7ACRdVcf9tuewiyNkWXGDn99WcXrGHSTXEnhQsQWL58PDbLxbbDgDUPdbXsGgC zCQbSykYv2E= =yheO -----END PGP SIGNATURE----- From fredrik at pythonware.com Mon Aug 25 21:17:21 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 25 Aug 2008 21:17:21 +0200 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <6DD88C6B-7586-43C9-A060-A1D8C5D3E4E3@python.org> References: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> <6DD88C6B-7586-43C9-A060-A1D8C5D3E4E3@python.org> Message-ID: Barry Warsaw wrote: > You don't mean the experts claimed they weren't important, right? > Unimportant changes definitely don't need to go in now . Well, at least Guido managed to figure out what I was trying to say ;-) From barry at python.org Mon Aug 25 21:36:11 2008 From: barry at python.org (Barry Warsaw) Date: Mon, 25 Aug 2008 15:36:11 -0400 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: References: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> <6DD88C6B-7586-43C9-A060-A1D8C5D3E4E3@python.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 25, 2008, at 3:17 PM, Fredrik Lundh wrote: > Barry Warsaw wrote: > >> You don't mean the experts claimed they weren't important, right? >> Unimportant changes definitely don't need to go in now . > > Well, at least Guido managed to figure out what I was trying to > say ;-) Yeah, I was just being curmudgeonly. :) - -B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLMJq3EjvBPtnXfVAQKG6QQAl3MliLaqhaibf12INX6EUoeIiYBEJlhY IiFgdc6VXe7evMsxUj2xE+1S+rg9BEhwiY38NTZdaqDCRiHBUY6aKFYlnawuyaKf 8m+jIdkJyudBpT5dBvfBCvYlwmXl/RwKHzDRDCHUjKfBVgAo9elv+EDy2kFLUpM1 W8dVEYwo3dg= =fue6 -----END PGP SIGNATURE----- From robert.schuppenies at gmail.com Mon Aug 25 22:49:22 2008 From: robert.schuppenies at gmail.com (Robert Schuppenies) Date: Mon, 25 Aug 2008 22:49:22 +0200 Subject: [Python-Dev] no tp_traverse for dict iters In-Reply-To: References: <48B26E30.3020701@gmail.com> Message-ID: <48B31AD2.4070808@gmail.com> Created bug report at http://bugs.python.org/issue3546. Amaury Forgeot d'Arc wrote: > Yes, this can lead to some object cycle that are not collected. > See the attached script: a cycle involving a list iterator is > collected by the garbage collector, but a cycle with a dict iterator > is not. > This is worth a bug report IMO. From robert.schuppenies at gmail.com Mon Aug 25 23:09:34 2008 From: robert.schuppenies at gmail.com (Robert Schuppenies) Date: Mon, 25 Aug 2008 23:09:34 +0200 Subject: [Python-Dev] no tp_traverse for dict iters In-Reply-To: <48B31AD2.4070808@gmail.com> References: <48B26E30.3020701@gmail.com> <48B31AD2.4070808@gmail.com> Message-ID: <48B31F8E.80803@gmail.com> Sry, wrong link. I meant http://bugs.python.org/issue3680. Robert Schuppenies wrote: > Created bug report at http://bugs.python.org/issue3546. > > Amaury Forgeot d'Arc wrote: >> Yes, this can lead to some object cycle that are not collected. >> See the attached script: a cycle involving a list iterator is >> collected by the garbage collector, but a cycle with a dict iterator >> is not. >> This is worth a bug report IMO. From steve at holdenweb.com Tue Aug 26 00:55:36 2008 From: steve at holdenweb.com (Steve Holden) Date: Mon, 25 Aug 2008 18:55:36 -0400 Subject: [Python-Dev] Unicode 5.1.0 In-Reply-To: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> References: <57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org> Message-ID: Barry Warsaw wrote: > On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote: > >> http://www.unicode.org/versions/Unicode5.1.0/ >> "Unicode 5.1.0 contains over 100,000 characters, and provides >> significant additions and improvements..." to existing features, >> including new files and upgrades to existing files. Sounds close to >> adding features ;-) > > I agree. This seriously feels like new, potentially high risk code to > be adding this late in the game. The BDFL can always override, but > unless someone is really convincing that this is low risk high benefit, > I'd vote no for 2.6/3.0. But it's [the] wafer-thin [end of the wedge] ... The difficulties with subprocess suggest there's plenty to do without adding yet one more tiny little task. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From aahz at pythoncraft.com Tue Aug 26 03:11:27 2008 From: aahz at pythoncraft.com (Aahz) Date: Mon, 25 Aug 2008 18:11:27 -0700 Subject: [Python-Dev] [PATCH] Respect LDFLAGS In-Reply-To: <200808252040.34277.Arfrever.FTA@gmail.com> References: <200808252040.34277.Arfrever.FTA@gmail.com> Message-ID: <20080826011127.GA17310@panix.com> On Mon, Aug 25, 2008, Arfrever Frehtes Taifersar Arahesis wrote: > > I'm attaching the patch which fixes respecting LDFLAGS when > building libpython$(VERSION).so. Please post your patch to bugs.python.org -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ Adopt A Process -- stop killing all your children! From greg.ewing at canterbury.ac.nz Tue Aug 26 03:52:16 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 26 Aug 2008 13:52:16 +1200 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: References: Message-ID: <48B361D0.60402@canterbury.ac.nz> Guido van Rossum wrote: > If you call: > > subprocess.call(cmd, shell=False) > > Then it works on Linux, but fails on Windows because it does not > perform the Windows %PATHEXT% search that allows it to find that > "svn.exe" is the actual executable to be invoked. Maybe the Windows implementation should do its own %PATHEXT% lookup when the shell is not being used. -- Greg From foom at fuhm.net Tue Aug 26 04:17:32 2008 From: foom at fuhm.net (James Y Knight) Date: Mon, 25 Aug 2008 22:17:32 -0400 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: <48B361D0.60402@canterbury.ac.nz> References: <48B361D0.60402@canterbury.ac.nz> Message-ID: <351E513C-4369-4426-BBF4-715250C2BB9B@fuhm.net> On Aug 25, 2008, at 9:52 PM, Greg Ewing wrote: > Guido van Rossum wrote: > >> If you call: >> subprocess.call(cmd, shell=False) >> Then it works on Linux, but fails on Windows because it does not >> perform the Windows %PATHEXT% search that allows it to find that >> "svn.exe" is the actual executable to be invoked. > > Maybe the Windows implementation should do its own > %PATHEXT% lookup when the shell is not being used. +1 to that. It's really nice to be able to *not* invoke a shell, and thus not have to worry about the shell doing nasty things to your process spawning. So, any solution that aids portability to windows without requiring the invocation of a shell seems like a good thing to me. James From ziade.tarek at gmail.com Tue Aug 26 10:54:24 2008 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Tue, 26 Aug 2008 10:54:24 +0200 Subject: [Python-Dev] distutils small fix Message-ID: <94bdd2610808260154j5e726646gb39aceacaeee9dbc@mail.gmail.com> Hello Marc-Andr? and I are looking for one more reviewer for the patch http://bugs.python.org/issue2562 It makes it possible to use accented letters in distutils' metadata, like the author name, by switching those fields to Unicode. setuptools and PyPI are both fine with this, it is just a matter of making distutils writing the PKG_FILE correctly. Regards Tarek -- Tarek Ziad? | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From python at rcn.com Tue Aug 26 17:32:23 2008 From: python at rcn.com (Raymond Hettinger) Date: Tue, 26 Aug 2008 12:32:23 -0300 Subject: [Python-Dev] Things to Know About Super References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> Message-ID: [Michele Simionato] > Recently I have opened a blog on Artima and I am publishing a > few Python-related essays I had in store. In particular a trilogy > of papers about "super". From the foreword: > > """ > In 2004 I decided to write a comprehensive paper documenting > ``super`` pitfalls and traps, ... Thanks for posting these blogs. I think they serve as a nice compilation of docs, original analysis, and various discussions on super(). What I would really like to see is a fourth blog entry that shows how to use super() reliably and correctly. In general, I opposed to creating documentation in the form of "danger, danger this could explode ...." IMO, there is not much point in dwelling on bugs that have already been fixed, nor is there an advantage to showing all the ways the tool can be misused. In applications without multiple inheritance, it is a straight-forward to use super() as a way to avoid directly naming an immediate parent class. This is useful in and of itself. For cooperative multiple inheritance, I take issue with the abstracted examples provided (i.e. inconsistent signatures). In a real app that actually needs cooperative multiple inheritance, it becomes self-evident what "cooperative" actually means -- the methods *have* to be designed to interoperate -- it is intrinsic to the problem at hand. Your reasoning is akin to saying that cooperative multitasking is intrinsically flawed because one of the tasks could be designed to not cooperate (never yield). Cooperative multiple inheritance is *not* about mixing two unrelated parents that just happen to use the same method name but have different semantics and were not designed to cooperate with each other. The A-B-C-D diagrams and foo/bar methods in the examples are deceptive because they silently drop the precondition of cooperation while attempting to demonstrate a supposed flaw in the tool. If I understand the problem correctly, in the rare cases where you do need cooperative multiple inheritance, then super() is the only workable solution short of designing some equivalent using composition instead of inheritance. I do agree with you that the docs can be improved. I'll work on patch that makes clear that super() returns a proxy-object (not an actual parent class) that dispatches explict method calls (not syntax driven) to one of multiple parents designed to interact cooperatively. Also, it may be controversial, but there may be some merit in de-documenting the "unbound" case. It seems to add more confusion than it's worth. Lastly, I take issue with one other part of the blogs. While they show a clear dislike for cooperative multiple inheritance, they take a potshot at multiple inheritance in general. I don't follow the logic here. IMO, mixin classes like DictMixin have proven themselves as being very useful. Plenty of frameworks share this approach. Likewise, the new ABCs offer mixin capabilities that are really nice. I think it is a non-sequiter to reason from "diamond diagrams are complicated" to "mixins should be disallowed". Instead, I think it better to simply recommend that a key to happiness is to keep various mixin classes completely orthogonal to one another (no overlapping method names). Lest I sound negative, let me thank you again for the blog entries and for compiling the most complete discussion of it in one place. Raymond From solipsis at pitrou.net Tue Aug 26 17:53:27 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 26 Aug 2008 15:53:27 +0000 (UTC) Subject: [Python-Dev] Mercurial mirrors Message-ID: Hello, Thanks to Neil Schemenauer, we now have some Mercurial mirrors hosted at http://code.python.org/hg/ Here are the URLs for each of the available repositories: - http://code.python.org/hg/trunk/ - http://code.python.org/hg/branches/py3k/ - http://code.python.org/hg/branches/release2.5-maint/ For Mercurial beginners, each of the URLs above references both a human-readable Web interface to browse the repositories (view changesets, subscribe to an RSS feed, annotate source files...), and a machine-queryable address to "clone" the repositories for local, offline use. That is, if you run "hg clone http://code.python.org/hg/trunk/", you'll get a "trunk" subdirectory containing the whole trunk history in a local repository, as well as a working copy. You can then do, e.g. "hg annotate setup.py" at light speed. The Mercurial mirrors are sync'ed with the SVN repo every 5 minutes. They are read-only, that is you cannot push to them. (technical note: the mirrors are done using my own "hgsvn", but an alternate strategy would be to use the builtin "hg convert" instead) Regards Antoine. From michele.simionato at gmail.com Tue Aug 26 18:13:03 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Tue, 26 Aug 2008 18:13:03 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> Message-ID: <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> On Tue, Aug 26, 2008 at 5:32 PM, Raymond Hettinger wrote: > What I would really like to see is a fourth blog entry that shows > how to use super() reliably and correctly. That could be arranged. > In general, I opposed > to creating documentation in the form of "danger, danger this > could explode ...." IMO, there is not much point in dwelling on > bugs that have already been fixed, nor is there an advantage to > showing all the ways the tool can be misused. Yep. The parts about the bugs of super in 2.2 and 2.3 were written years ago, when they were relevant. Nowadays they are less relevant, but since they were already written and since there are still people using older versions of Python I decided to keep them. I would not keep them in a revised version intended as "semi-official" documentation of super. Still, I think they are fine as a blog post. > For cooperative multiple inheritance, I take issue with the abstracted > examples provided (i.e. inconsistent signatures). In a real app that > actually needs cooperative multiple inheritance, it becomes self-evident > what "cooperative" actually means -- the methods *have* to be > designed to interoperate -- it is intrinsic to the problem at hand. > Cooperative multiple inheritance is *not* about mixing two unrelated > parents that just happen to use the same method name but have > different semantics and were not designed to cooperate with each other. > > The A-B-C-D diagrams and foo/bar methods in the examples are > deceptive because they silently drop the precondition of cooperation > while attempting to demonstrate a supposed flaw in the tool. They just show that the tool is delicate and not easy to use. > If I understand the problem correctly, in the rare cases where you do > need cooperative multiple inheritance, then super() is the only workable > solution short of designing some equivalent using composition instead > of inheritance. In my experience, one can go a long way using composition instead of inheritance. I also think that Python would not lose much without cooperative multiple inheritance. This is however a personal opinion and in any case the point is moot because the language is the way it is. Still, in a blog post personal opinions and even rants have their place. That part could be removed in an "semi-official" document. > Also, it may be controversial, but there may be some merit in de-documenting > the "unbound" case. It seems to add more confusion than it's worth. Fine with me. > Lastly, I take issue with one other part of the blogs. While they show > a clear dislike for cooperative multiple inheritance, they take a potshot > at multiple inheritance in general. I don't follow the logic here. IMO, > mixin classes like DictMixin have proven themselves as being very > useful. Plenty of frameworks share this approach. Likewise, the > new ABCs offer mixin capabilities that are really nice. > > I think it is a non-sequiter to reason from "diamond diagrams are > complicated" to "mixins should be disallowed". Instead, I think it better > to simply recommend that a key to happiness is to keep various mixin classes > completely orthogonal to one another (no overlapping method names). I not completely against multiple inheritance. I am against multiple inheritance as it is now. A restricted form of multiple inheritance in which mixins classes are guaranteed to be orthogonal would be fine with me (provided it is not abused). This concept exists already in other languages, the orthogonal mixins are called "traits". I have written a trilogy of papers about mixins: if you read them, you will see where I come from (Zope, which I do not like) and you will also see that I like DictMixin instead. I will publish the papers in the blog soon or later, but you can find the Italian version here: http://stacktrace.it/articoli/2008/06/i-pericoli-della-programmazione-con-i-mixin1/ http://stacktrace.it/articoli/2008/07/i-pericoli-della-programmazione-con-i-mixin2/ http://stacktrace.it/articoli/2008/08/i-pericoli-della-programmazione-con-i-mixin3/ Michele Simionato From musiccomposition at gmail.com Tue Aug 26 18:42:21 2008 From: musiccomposition at gmail.com (Benjamin Peterson) Date: Tue, 26 Aug 2008 11:42:21 -0500 Subject: [Python-Dev] Mercurial mirrors In-Reply-To: References: Message-ID: <1afaf6160808260942t27091332ncc8b786e5781ffbb@mail.gmail.com> On Tue, Aug 26, 2008 at 10:53 AM, Antoine Pitrou wrote: > > Hello, > > Thanks to Neil Schemenauer, we now have some Mercurial mirrors hosted at > http://code.python.org/hg/ Cool! It's nice to have these become "official". My hg branches are all pointing to your site. Can I easily relocate the parent branch? -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." From barry at python.org Tue Aug 26 19:18:01 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 26 Aug 2008 13:18:01 -0400 Subject: [Python-Dev] Mercurial mirrors In-Reply-To: <1afaf6160808260942t27091332ncc8b786e5781ffbb@mail.gmail.com> References: <1afaf6160808260942t27091332ncc8b786e5781ffbb@mail.gmail.com> Message-ID: <2B7774E9-1B08-4D7B-8CBA-EA2FDE44F44F@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 26, 2008, at 12:42 PM, Benjamin Peterson wrote: > On Tue, Aug 26, 2008 at 10:53 AM, Antoine Pitrou > wrote: >> >> Hello, >> >> Thanks to Neil Schemenauer, we now have some Mercurial mirrors >> hosted at >> http://code.python.org/hg/ > > Cool! It's nice to have these become "official". My hg branches are > all pointing to your site. Can I easily relocate the parent branch? Actually, right now anything that's not Subversion is still experimental. But agreed that it's nice Mercurial and Bazaar are available. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLQ6yXEjvBPtnXfVAQK/fgP/aRTdNeqdWddQetANArV8zpYLbS7TUUbl b/h0p6fWJdSf4ZPkuN4yjXZz8F+4QXc+B1qF8qxEdtc9BjvSBbgOED/GEjF++9OJ fQ2JpT01+Cj2Z8rl034leTrGq1CQ9uDC7YTWJblJjyFiFiCEzSiiJ6aETe3LDpwe ZJT6OxyQVwU= =7YSu -----END PGP SIGNATURE----- From rowen at u.washington.edu Tue Aug 26 19:59:09 2008 From: rowen at u.washington.edu (Russell E. Owen) Date: Tue, 26 Aug 2008 10:59:09 -0700 Subject: [Python-Dev] Fix python darwin build to look for non-framework Tk if not a framework build? Message-ID: Python's own setup.py file seems to only look for a Framework Tcl/Tk on darwin. This is a headache if one is trying to build a non-framework python that uses a non-framework tcl/tk. Any chance of getting this fixed? I'm willing to work on a patch if it has any chance of being accepted. Any hints on how to determine if it is a framework build from within setup.py would be most welcome! -- Russell From brett at python.org Tue Aug 26 20:47:32 2008 From: brett at python.org (Brett Cannon) Date: Tue, 26 Aug 2008 11:47:32 -0700 Subject: [Python-Dev] Mercurial mirrors In-Reply-To: References: Message-ID: On Tue, Aug 26, 2008 at 8:53 AM, Antoine Pitrou wrote: > > Hello, > > Thanks to Neil Schemenauer, we now have some Mercurial mirrors hosted at > http://code.python.org/hg/ > > Here are the URLs for each of the available repositories: > - http://code.python.org/hg/trunk/ > - http://code.python.org/hg/branches/py3k/ > - http://code.python.org/hg/branches/release2.5-maint/ > > For Mercurial beginners, each of the URLs above references both a human-readable > Web interface to browse the repositories (view changesets, subscribe to an RSS > feed, annotate source files...), and a machine-queryable address to "clone" the > repositories for local, offline use. > > That is, if you run "hg clone http://code.python.org/hg/trunk/", you'll get a > "trunk" subdirectory containing the whole trunk history in a local repository, > as well as a working copy. You can then do, e.g. "hg annotate setup.py" at light > speed. > > The Mercurial mirrors are sync'ed with the SVN repo every 5 minutes. They are > read-only, that is you cannot push to them. > But can we push branches up to our personal directories on code.python.org like we can with bzr? -Brett From python at rcn.com Tue Aug 26 20:56:48 2008 From: python at rcn.com (Raymond Hettinger) Date: Tue, 26 Aug 2008 15:56:48 -0300 Subject: [Python-Dev] Things to Know About Super References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> Message-ID: [Raymond] >> Cooperative multiple inheritance is *not* about mixing two unrelated >> parents that just happen to use the same method name but have >> different semantics and were not designed to cooperate with each other. >> >> The A-B-C-D diagrams and foo/bar methods in the examples are >> deceptive because they silently drop the precondition of cooperation >> while attempting to demonstrate a supposed flaw in the tool. [Michele] > They just show that the tool is delicate and not easy to use. To me, they miss the point. Simply, if you don't have diamonds, then super() is easy to use and if you do have have diamonds, then super() is the *only* way to do it. Diamonds impose a set of design constraints (making the classes cooperative). The A-B-C-D diagrams ignore this point and make super() seem like an accident waiting to happen. In contrast, with a concrete example, accidental non-cooperativeness would be more self-evident. The problem isn't that super() is fragile. The problem is that a cooperative design pattern requires you to actually make the classes cooperate. This is no different than a visitor design pattern requiring that you attach a conformant visit() method for on each of the visited classes. [Michele] > In my experience, one can go a long way using composition instead of > inheritance. While that is often true, I don't think it applies to the case of cooperative multiple inheritence. To achieve substantially the same functionality using composition, you would likely have to re-invent much of what super() does for us automatically, and you would still be imposing constraits on the composed classes that are substantially the same as what you have with inheritance. [Michele] > I also think that Python would not lose much without cooperative > multiple inheritance. I would state this differently: "The use cases for cooperative multiple inheritence don't arise often in practice; so, if we dropped support for those cases, you probably wouldn't notice until you encountered one of the rare occasions where it was the right answer to your problem." There was some quote floating around that expressed the situation well -- it went something like: "Python makes most problems easy and hard problems possible". The use cases for cooperative multiple inheritance fall in the latter category. BTW, I really like your paper explaining the MRO. Excellent work. Raymond From armin.ronacher at active-4.com Tue Aug 26 21:05:19 2008 From: armin.ronacher at active-4.com (Armin Ronacher) Date: Tue, 26 Aug 2008 19:05:19 +0000 (UTC) Subject: [Python-Dev] Confusing listreverseiterator Behavior Message-ID: Hi, I stumbled upon a confusing listreverseiterator behavior: >>> l = [1, 2, 3, 4] >>> i = iter(l) >>> ri = reversed(l) >>> len(i) Traceback (most recent call last): File "", line 1, in TypeError: object of type 'listiterator' has no len() >>> len(ri) 4 >>> ri.next() 4 >>> len(ri) 3 This is the only reverse iterator with that sort of behavior. Is that intentional if yes, why? I stumbled upon that when writing a templating engine that tried to lazily get the length of the sequence / iterator but failed doing so after the first iteration because the length of the reverse iterator changes every iteration. Regards, Armin From hall.jeff at gmail.com Tue Aug 26 21:21:15 2008 From: hall.jeff at gmail.com (Jeff Hall) Date: Tue, 26 Aug 2008 15:21:15 -0400 Subject: [Python-Dev] Confusing listreverseiterator Behavior In-Reply-To: References: Message-ID: <1bc395c10808261221n5e6e7c88le0f30f7199e0cee2@mail.gmail.com> Unless I'm misconstruing something the problem is that reversed returns two different object types depending on if it's a list or a tuple >>> l = [1,2,3,4] >>> i = iter(l) >>> ri = reversed(l) >>> l [1, 2, 3, 4] >>> ri >>> i >>> t = (1,2,3,4) >>> it = iter(t) >>> rit = reversed(t) >>> it >>> rit >>> reversing a tuple (or a string) returns a "reversed object" reversing a list returns a "listreverseiterator" definitely an inconsistency -------------- next part -------------- An HTML attachment was scrubbed... URL: From hall.jeff at gmail.com Tue Aug 26 21:47:13 2008 From: hall.jeff at gmail.com (Jeff Hall) Date: Tue, 26 Aug 2008 15:47:13 -0400 Subject: [Python-Dev] Confusing listreverseiterator Behavior In-Reply-To: <1bc395c10808261221n5e6e7c88le0f30f7199e0cee2@mail.gmail.com> References: <1bc395c10808261221n5e6e7c88le0f30f7199e0cee2@mail.gmail.com> Message-ID: <1bc395c10808261247n5b658197g8872539a757e7c33@mail.gmail.com> I realized after I fired off my response that this was still bugging me... it appears that the documentation is incorrect from 2.1 Built-in Functions (v2.5 in case it matters... a quick search of bugs doesn't seem to show anything though) *reversed*( seq) Return a reverse iterator. seq must be an object which supports the sequence protocol (the __len__() method and the __getitem__()method with integer arguments starting at 0). New in version 2.4. the above appears to only be true for lists. For tuples and strings it creates a reverse OBJECT which behaves slightly differently (notably by not including a len() method as you noticed) I can't find how to actually create a "tuplereverseiterator" or "stringreverseiterator" objects... nor does there appear to be a way to create a "reversed" object from a list... Just tested this s = 'bob' t = (1,2,3,4) l = [1,2,3,4) rs = reversed(s) rt = reversed(t) rl = reversed(l) type(rs) type(rt) type(rl) type(rs) == type(rt) True type(rs) == type(rl) False Surely this isn't intentional? -------- Haikus are easy Most make very little sense Refrigerator -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.ronacher at active-4.com Tue Aug 26 22:04:03 2008 From: armin.ronacher at active-4.com (Armin Ronacher) Date: Tue, 26 Aug 2008 20:04:03 +0000 (UTC) Subject: [Python-Dev] Confusing listreverseiterator Behavior References: <1bc395c10808261221n5e6e7c88le0f30f7199e0cee2@mail.gmail.com> <1bc395c10808261247n5b658197g8872539a757e7c33@mail.gmail.com> Message-ID: Jeff Hall gmail.com> writes: > reversed( > seq) > Return a reverse iterator. seq must be an object which > supports the sequence protocol (the __len__() method and the __getitem__() method with integer arguments starting at > 0). New in version 2.4. the above appears to only be true for lists. For > tuples and strings it creates a reverse OBJECT which behaves slightly > differently (notably by not including a len() method as you noticed) > I can't find how to actually create a "tuplereverseiterator" or > "stringreverseiterator" objects... nor does there appear to be a way to > create a "reversed" object from a list... That's an implementation detail what exactly the reverse iterator is. The same applies to iter() calls. iter("foo") for example returns a iterator type, iter([]) returns a list iterator. The thing you quoted above is the requirement for the object that you pass to reverse(), not the object returned which is some kind of iterator that happens to iterate over the sequence in reverse. The problem I personally have with it is that the listreverseiterator is the only iterator in the standard library that changes the length during iteration and that it's the only reverse iterator that has a length. Even more stunning as the normal iterator doesn't have one. Regards, Armin From python at rcn.com Tue Aug 26 22:05:46 2008 From: python at rcn.com (Raymond Hettinger) Date: Tue, 26 Aug 2008 17:05:46 -0300 Subject: [Python-Dev] Confusing listreverseiterator Behavior References: Message-ID: From: "Armin Ronacher" >>>> len(ri) > 4 >>>> ri.next() > 4 >>>> len(ri) > 3 > > This is the only reverse iterator with that sort of behavior. Use the bug tracker please and assign to me. At one time, some iterators had the ability to know their own length and that would change as the iterator got consumed. Later, it was decided that iterators should not report length and should instead report a length hint. It looks like listreversediterator got missed when this was changed. Raymond From g.brandl at gmx.net Tue Aug 26 22:30:56 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Tue, 26 Aug 2008 22:30:56 +0200 Subject: [Python-Dev] Confusing listreverseiterator Behavior In-Reply-To: <1bc395c10808261247n5b658197g8872539a757e7c33@mail.gmail.com> References: <1bc395c10808261221n5e6e7c88le0f30f7199e0cee2@mail.gmail.com> <1bc395c10808261247n5b658197g8872539a757e7c33@mail.gmail.com> Message-ID: Jeff Hall schrieb: > I realized after I fired off my response that this was still bugging > me... it appears that the documentation is incorrect > > from 2.1 Built-in Functions (v2.5 in case it matters... a quick search > of bugs doesn't seem to show anything though) > > *reversed*( seq) > > Return a reverse iterator. seq must be an object which supports the > sequence protocol (the __len__() method and the __getitem__() method > with integer arguments starting at |0|). New in version 2.4. > > the above appears to only be true for lists. Not at all. (I think you misread; the __len__ method must be present on the argument, not the returned object.) > For tuples and strings it > creates a reverse OBJECT which behaves slightly differently (notably by > not including a len() method as you noticed) > > I can't find how to actually create a "tuplereverseiterator" or > "stringreverseiterator" objects... nor does there appear to be a way to > create a "reversed" object from a list... You don't need to. An object returned by reversed() only needs to follow the iterator protocol. Whether it is a listreverseiterator or a general reversed object doesn't matter. In fact, reversed() calls __reversed__ on its argument if it exists, so that custom types may provide their own optimized reverse iterator. Georg From musiccomposition at gmail.com Tue Aug 26 22:35:52 2008 From: musiccomposition at gmail.com (Benjamin Peterson) Date: Tue, 26 Aug 2008 15:35:52 -0500 Subject: [Python-Dev] Fix python darwin build to look for non-framework Tk if not a framework build? In-Reply-To: References: Message-ID: <1afaf6160808261335u2dfb92m6a538b2dbdf1b886@mail.gmail.com> On Tue, Aug 26, 2008 at 12:59 PM, Russell E. Owen wrote: > Python's own setup.py file seems to only look for a Framework Tcl/Tk on > darwin. This is a headache if one is trying to build a non-framework > python that uses a non-framework tcl/tk. > > Any chance of getting this fixed? I'm willing to work on a patch if it > has any chance of being accepted. Any hints on how to determine if it is > a framework build from within setup.py would be most welcome! If you do, please file a ticket on the tracker with your patch. Thanks! > > -- Russell > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." From steve at holdenweb.com Tue Aug 26 23:10:10 2008 From: steve at holdenweb.com (Steve Holden) Date: Tue, 26 Aug 2008 17:10:10 -0400 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> Message-ID: Michele Simionato wrote: > On Tue, Aug 26, 2008 at 5:32 PM, Raymond Hettinger wrote: [...] >> I think it is a non-sequiter to reason from "diamond diagrams are >> complicated" to "mixins should be disallowed". Instead, I think it better >> to simply recommend that a key to happiness is to keep various mixin classes >> completely orthogonal to one another (no overlapping method names). > > I not completely against multiple inheritance. I am against multiple inheritance > as it is now. A restricted form of multiple inheritance in which mixins classes > are guaranteed to be orthogonal would be fine with me (provided it is > not abused). > This concept exists already in other languages, the orthogonal mixins > are called "traits". > If you aren't aware of it you should take a look at Enthought's traits package. It's part of the Enthought Tool Suite (ETS). https://svn.enthought.com/enthought/wiki While I too appreciate your comments about super I believe you have perhaps overdone it. I do look forward to seeing the edited edition as a part of the documentation. [Hint: the *docs* aren't in feature freeze ;-)] regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From solipsis at pitrou.net Wed Aug 27 00:26:27 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 26 Aug 2008 22:26:27 +0000 (UTC) Subject: [Python-Dev] Mercurial mirrors References: <1afaf6160808260942t27091332ncc8b786e5781ffbb@mail.gmail.com> Message-ID: Benjamin Peterson gmail.com> writes: > > Cool! It's nice to have these become "official". My hg branches are > all pointing to your site. Can I easily relocate the parent branch? Just edit .hg/hgrc in your branches and modify the "default" value in the "[paths]" section. Then "hg in" to be sure everything went ok. Regards Antoine. From solipsis at pitrou.net Wed Aug 27 00:28:24 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 26 Aug 2008 22:28:24 +0000 (UTC) Subject: [Python-Dev] Mercurial mirrors References: Message-ID: Brett Cannon python.org> writes: > > But can we push branches up to our personal directories on > code.python.org like we can with bzr? If you have an ssh access to code.python.org, it should be easy. However, giving other people anonymous read-only access would require some manual configuration I think (not lots of, though). From solipsis at pitrou.net Wed Aug 27 01:13:13 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 26 Aug 2008 23:13:13 +0000 (UTC) Subject: [Python-Dev] class attributes slower in py3k References: <1219604656.5635.2.camel@fsol> Message-ID: Antoine Pitrou pitrou.net> writes: > > > NormalClassAttribute: 339ms 340ms 0.28us 1.111ms > > > > Over twice as slow? > > Yes, should be investigated. > [...] > > > > SpecialClassAttribute: 534ms 535ms 0.45us 1.121ms > > > > ~4x slower! > > Should be investigated as well. It turns out that these two slowdowns are due to classes always being new-style in py3k. Indeed, if I add "__metaclass__ = type" at the beginning of Tools/pybench/Lookups.py, 2.6 becomes as slow as 3.0. Regards Antoine. From barry at python.org Wed Aug 27 01:33:38 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 26 Aug 2008 19:33:38 -0400 Subject: [Python-Dev] Mercurial mirrors In-Reply-To: References: Message-ID: <01F759F8-D271-411B-BC52-7D621C274D61@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 26, 2008, at 6:28 PM, Antoine Pitrou wrote: > Brett Cannon python.org> writes: >> >> But can we push branches up to our personal directories on >> code.python.org like we can with bzr? > > If you have an ssh access to code.python.org, it should be easy. > However, giving > other people anonymous read-only access would require some manual > configuration > I think (not lots of, though). It should not be too hard to adapt the generalizations we made when we brought up the Bazaar repository. Unfortunately, I don't have time to do it, but Thomas and Martin (who are both also probably pretty swamped) probably know how we did it. If not before, we should spend time after the releases in making this available. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLSS03EjvBPtnXfVAQKAVQP+KCbGOHU0xjfR1mghhdPhlzhHslC1Jwc+ WJAIoDfO/qWGwzBBImIoEqsAqdEBWVbaEjQN57EtL0LRUoR0S3bJdg9P/EeOBDlv 2RHxYZomMFE4rlUJer27oHVBXRO/MgIfWiePQEHowEQQ1pe4INnqiF0OeMlou8sb fYsrpEIun5k= =gtAb -----END PGP SIGNATURE----- From michele.simionato at gmail.com Wed Aug 27 03:16:04 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Wed, 27 Aug 2008 03:16:04 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> Message-ID: <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> On Tue, Aug 26, 2008 at 8:56 PM, Raymond Hettinger wrote: > I would state this differently: "The use cases for cooperative multiple > inheritence don't arise often in practice; so, if we dropped support > for those cases, you probably wouldn't notice until you encountered > one of the rare occasions where it was the right answer to your problem." > > There was some quote floating around that expressed the situation > well -- it went something like: "Python makes most problems easy > and hard problems possible". The use cases for cooperative multiple > inheritance fall in the latter category. It is just a matter of how rare the use cases really are. Cooperative methods has been introduced 6+ years ago. In all this time surely they must have been used. How many compelling uses of cooperation we can find in real life code? For instance in the standard library or in some well known framework? This is a serious question I have been wanting to ask for years. I am sure people here can find some example, so just give me a pointer and we will see. > BTW, I really like your paper explaining the MRO. Excellent work. The issue with that paper is that I wrote it when my Python experience was reduced to six month and my experience with real life large object oriented frameworks was zero. Nowadays I value simplicity more. From aleaxit at gmail.com Wed Aug 27 03:30:17 2008 From: aleaxit at gmail.com (Alex Martelli) Date: Tue, 26 Aug 2008 18:30:17 -0700 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> Message-ID: On Tue, Aug 26, 2008 at 6:16 PM, Michele Simionato wrote: ... > It is just a matter of how rare the use cases really are. Cooperative > methods has been introduced 6+ years ago. In all this time surely > they must have been used. How many compelling uses of cooperation > we can find in real life code? For instance in the standard library or > in some well known framework? This is a serious question I have been > wanting to ask for years. I am sure people here can find some example, > so just give me a pointer and we will see. http://www.koders.com/default.aspx?s=super&btn=&la=Python&li=* finds over 5,000 hits, but it would take substantial work to sift through them (in particular because not all refer to the built-in super, as you'll see even in the first page!) -- and a random hit I found by going to p.7 is really bad...: """Mixin to enable reification.""" def __init__(self): super(ReificationStore, self).__init__() [there's *nothing else* in this __init__!]. Alex From mhammond at skippinet.com.au Wed Aug 27 05:08:49 2008 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 27 Aug 2008 13:08:49 +1000 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: References: Message-ID: <056601c907f2$3d5f36e0$b81da4a0$@com.au> Guido quotes a colleague: > """ > Given a straightforward command list like: > > cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk'] > > You apparently cannot pass this list to any subprocess function > (subprocess.call() or otherwise) with a set of arguments that allow it > to "just work" on both Windows and non-Windows systems. > > If you call: > > subprocess.call(cmd, shell=False) > > Then it works on Linux, but fails on Windows because it does not > perform the Windows %PATHEXT% search that allows it to find that > "svn.exe" is the actual executable to be invoked. I can't reproduce this as described. >>> subprocess.call(['svn', 'ls'], shell=False) svn: '.' is not a working copy 1 The reason this works is that Windows itself (CreateProcess) has support both for implied '.exe' extensions and searching $PATH. Thus, PATHEXT handling isn't required for executables. I *can* reproduce with another extension - eg, 'svn.py' - for this test I had a 'foo.py' on my PATH (but not in the cwd), and .py in PATHEXT. >>> import subprocess >>> subprocess.call(['foo'], shell=False) ... fails >>> subprocess.call(['foo'], shell=True) Hello 0 So I can't see this problem for 'svn.exe' and at face value the behaviour on Windows looks quite correct - you *do* need the shell for this functionality on Windows (in the same way you would to execute a .bat file, for example) > If you call: > > subprocess.call(cmd, shell=True) > > Then it works on Windows (it finds the "svn.exe" executable), but it > fails on Linux because it *only* executes the first argument in the > list ("svn") and does not pass the remaining arguments in the list to > the "svn" invocation. It sounds like in this particular example at least, this behaviour on Linux is the problem? Mark From pje at telecommunity.com Wed Aug 27 05:15:36 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 26 Aug 2008 23:15:36 -0400 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.co m> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> Message-ID: <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> At 03:16 AM 8/27/2008 +0200, Michele Simionato wrote: >It is just a matter of how rare the use cases really are. Cooperative >methods has been introduced 6+ years ago. In all this time surely >they must have been used. How many compelling uses of cooperation >we can find in real life code? For instance in the standard library or >in some well known framework? This is a serious question I have been >wanting to ask for years. I am sure people here can find some example, >so just give me a pointer and we will see. ISTR pointing out on more than one occasion that a major use case for co-operative super() is in the implementation of metaclasses. The __init__ and __new__ signatures are fixed, multiple inheritance is possible, and co-operativeness is a must (as the base class methods *must* be called). I'm hard-pressed to think of a metaclass constructor or initializer that I've written in the last half-decade or more where I didn't use super() to make it co-operative. That, IMO, is a compelling use case even if there were not a single other example of the need for super. However, I'm pretty sure I've had other cases where it was necessary to co-operate in cases where multiple inheritance occurred later; ie. where it was possible for a subclass to add a new class between parents. Remember that subclasses of a new-style class do not always have the same MRO tail as the original class; i.e., a subclass of "class A(B, C):" is only constrained to have [A...B...C] in its MRO; semi-arbitrary classes may be inserted between e.g. A and B. So, a new-style class cannot, as a general rule, statically determine what base class implementation of a method should be invoked. I personally consider the rare case where I have to force such static knowledge to be an unfortunate wart in the design (of that code, not Python). From michele.simionato at gmail.com Wed Aug 27 05:18:01 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Wed, 27 Aug 2008 05:18:01 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> Message-ID: <4edc17eb0808262018yc904c4dq5320e165ac7dd4c5@mail.gmail.com> On Wed, Aug 27, 2008 at 3:30 AM, Alex Martelli wrote: > On Tue, Aug 26, 2008 at 6:16 PM, Michele Simionato > wrote: > ... >> It is just a matter of how rare the use cases really are. Cooperative >> methods has been introduced 6+ years ago. In all this time surely >> they must have been used. How many compelling uses of cooperation >> we can find in real life code? For instance in the standard library or >> in some well known framework? This is a serious question I have been >> wanting to ask for years. I am sure people here can find some example, >> so just give me a pointer and we will see. > > http://www.koders.com/default.aspx?s=super&btn=&la=Python&li=* finds > over 5,000 hits, but it would take substantial work to sift through > them (in particular because not all refer to the built-in super, as > you'll see even in the first page!) Yep. Notice (I am sure you understood the point correctly, but just to clarify) that I am not interested in random occurrences of super, but in code/frameworks expressly designed to leverage on cooperation and doing it in a compelling way. IOW, I want to see cases where using cooperation is really better than relying on other techniques. Guido gives an example in http://www.python.org/download/releases/2.2.3/descrintro/#cooperation with a .save method, so in theory there are good use cases, but I wonder in practice how common they are and if they are frequent enough to justify the added complication. M.S. From michele.simionato at gmail.com Wed Aug 27 05:48:06 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Wed, 27 Aug 2008 05:48:06 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> Message-ID: <4edc17eb0808262048j200f4640v10dff6bc11c434ad@mail.gmail.com> On Tue, Aug 26, 2008 at 6:13 PM, Michele Simionato wrote: > I not completely against multiple inheritance. I am against multiple inheritance > as it is now. A restricted form of multiple inheritance in which mixins classes > are guaranteed to be orthogonal would be fine with me (provided it is > not abused). > This concept exists already in other languages, the orthogonal mixins > are called "traits". I must correct myself here. Even if for practical purposes traits look like a restricted multiple inheritance, in principle it is better to think of them as of an enhanced single inheritance. With traits there is always a single superclass: traits are just single inheritance with a nice syntax to include methods (like in Ruby) and a guarantee that methods will not be overridden silently (this one is missing in Ruby). M.S. From michele.simionato at gmail.com Wed Aug 27 07:24:39 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Wed, 27 Aug 2008 07:24:39 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> Message-ID: <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> On Wed, Aug 27, 2008 at 5:15 AM, Phillip J. Eby wrote: > ISTR pointing out on more than one occasion that a major use case for > co-operative super() is in the implementation of metaclasses. The __init__ > and __new__ signatures are fixed, multiple inheritance is possible, and > co-operativeness is a must (as the base class methods *must* be called). > I'm hard-pressed to think of a metaclass constructor or initializer that > I've written in the last half-decade or more where I didn't use super() to > make it co-operative. > > That, IMO, is a compelling use case even if there were not a single other > example of the need for super. I have been giving a lot of thought to this use case, at least from the time of the metaclass conflict recipe. I have always wondered why the recipe had to be so complicated. At the end, I have come to the conclusion that the problem was not with the recipe but with multiple inheritance itself. Let me explain the argument. A possible use case for multiple inheritance of metaclasses is the following: suppose I have a DebugMeta metaclass which adds some debugging support to classes; now I want to apply it to a third party framework which uses a FrameworkMeta metaclass internally. Let us suppose the framework author wrote its metaclass correctly, by supporting cooperation: .. code-block:: python class FrameworkMeta(type): def __new__(mcl, name, bases, dic): print "Adding framework features to %s" % name return super(FrameworkMeta, mcl).__new__(mcl, name, bases, dic) >>> class FrameworkClass(object): ... __metaclass__ = FrameworkMeta Adding framework features to FrameworkClass Moreover, suppose I wrote my DebugMeta to support cooperation correctly: .. code-block:: python class DebugMeta(type): def __new__(mcl, name, bases, dic): print "Adding debugging features to %s" % name return super(DebugMeta, mcl).__new__(mcl, name, bases, dic) Now I can add the debugging features to a class in this way: .. code-block:: python class DebugFrameworkMeta(DebugMeta, FrameworkMeta): pass >>> class DebugFrameworkClass(FrameworkClass): ... __metaclass__ = DebugFrameworkMeta Adding debugging features to DebugFrameworkClass Adding framework features to DebugFrameworkClass As you see everything works fine. Now, lets travel in the fictional world of a fictional language called T-Python which is just like Python, except it lacks multiple inheritance but has some support for traits. By this I mean that there is an ``include_mixin`` function working more or less like this (it could be enhanced but I am keeping it dead simple here for the sake of the argument): .. code-block:: python def include_mixin(mixin, cls): # could be extended to use more mixins # traits as in Squeak take the precedence over the base class dic = vars(mixin).copy() # could be extended to walk the ancestors return type(mixin.__name__ + cls.__name__, (cls,), dic) I will argue that T-Python is not worse than Python for this use case (composition of metaclasses). In the fictional world there is not need for super since all hierarchies are linear and you can just call the base class; FrameworkMeta could have been written as .. code-block:: python class FrameworkMeta2(type): def __new__(mcl, name, bases, dic): print "Adding framework features to %s" % name return type.__new__(mcl, name, bases, dic) and DebugMetas as .. code-block:: python class DebugMeta2(type): def __new__(mcl, name, bases, dic): print "Adding debugging features to %s" % name return mcl.__base__.__new__(mcl, name, bases, dic) Notice that DebugMeta2 is performing a sort of cooperative call here (``mcl.__base__.__new__``) but dead simple since there is just one base class. The analogous of FrameworkClass can be defined as >>> class FrameworkClass2(object): ... __metaclass__ = FrameworkMeta2 Adding framework features to FrameworkClass2 and the analogous of DebugFrameworkClass as >>> class DebugFrameworkClass2(FrameworkClass2): ... __metaclass__ = DebugFrameworkMeta2 Adding debugging features to DebugFrameworkClass2 Adding framework features to DebugFrameworkClass2 So, as you see, it works. Checks of the kind ``isinstance(DebugFrameworkClass2, DebugMeta2)`` would fail, but this is not a big issue (isinstance should not be used, or you could register DebugMeta2 as a base class even if it is not by using Python 2.6 ABC's). Now, I am not claiming that I have thought of all possible usages of multiple inheritance and metaclasses: however I have not found yet a use case that I could not rewrite by using single-inheritance + traits as the one I have just shown. Possibly there are cases which are difficult to rewrite: but how common are they? Notice that I am not advocating rewriting Python. The argument here is purely hyphotetic and concerning a fictional language: I just want to understand if full multiple inheritance is really that useful or not, as a matter of principle. M.S. From michele.simionato at gmail.com Wed Aug 27 08:02:47 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Wed, 27 Aug 2008 08:02:47 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> Message-ID: <4edc17eb0808262302gc770ec6s5d72f5db011f9626@mail.gmail.com> On Tue, Aug 26, 2008 at 11:10 PM, Steve Holden wrote: > If you aren't aware of it you should take a look at Enthought's traits > package. It's part of the Enthought Tool Suite (ETS). I know of the existence of that framework, however it is quite large and I don't see the relation with the concept of traits I have in mind, which is more or less the one described here: http://www.iam.unibe.ch/%7Escg/Archive/Papers/Scha03aTraits.pdf Basically, these are the properties of traits: 1. the methods/attributes in a trait go logically together; 2. if a trait enhances a class, then all subclasses are enhanced too; 3. if a trait has methods in common with the class, then the methods defined in the class have the precedence; 4. the ordering of traits is not important, i.e. enhancing a class first with trait T1 and then with trait T2 or viceversa is the same; 5. if traits T1 and T2 have names in common, enhancing a class both with T1 and T2 raises an error unless there is an explicitoverriding; 6. if a trait has methods in common with the base class, then the trait methods have the precedence; Properties from 4 to 6 are the distinguishing properties of traits with respect to multiple inheritance and mixins. From kilian.klimek at googlemail.com Wed Aug 27 08:46:15 2008 From: kilian.klimek at googlemail.com (Kilian Klimek) Date: Wed, 27 Aug 2008 08:46:15 +0200 Subject: [Python-Dev] the explicit self Message-ID: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> Hello, i know this has been discusses very much, i'm sorry, but i can't help it. In a nutshell, the proposal is as follows: 1. Self remains explicit (like it is now). 2. if a class is a subclass of a special class, e.g. named 'selfless', the self parameter is not required and a special variable, named 'this' is provided. For example: class Foo (selfless): def __init__ (x, y): this.x = x ... A patch for 3.0b3 implementing this can be found at http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff regards, Kilian Klimek -------------- next part -------------- An HTML attachment was scrubbed... URL: From cesare.dimauro at a-tono.com Wed Aug 27 09:14:05 2008 From: cesare.dimauro at a-tono.com (Cesare Di Mauro) Date: Wed, 27 Aug 2008 09:14:05 +0200 Subject: [Python-Dev] the explicit self In-Reply-To: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> References: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> Message-ID: On 27 agu 2008 at 08:46:15, Kilian Klimek wrote: > Hello, > > i know this has been discusses very much, i'm sorry, > but i can't help it. In a nutshell, the proposal is as > follows: > > 1. Self remains explicit (like it is now). > 2. if a class is a subclass of a special class, e.g. > named 'selfless', the self parameter is not required > and a special variable, named 'this' is provided. > > > For example: > > class Foo (selfless): > def __init__ (x, y): > this.x = x > ... > > A patch for 3.0b3 implementing this can be found at > http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff > > regards, > Kilian Klimek > I disagree. From "The Zen of Python": Explicit is better than implicit. Readability counts. Special cases aren't special enough to break the rules. There should be one-- and preferably only one --obvious way to do it. Cheers, Cesare From gherron at islandtraining.com Wed Aug 27 09:12:50 2008 From: gherron at islandtraining.com (Gary Herron) Date: Wed, 27 Aug 2008 00:12:50 -0700 Subject: [Python-Dev] the explicit self In-Reply-To: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> References: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> Message-ID: <48B4FE72.6050200@islandtraining.com> Kilian Klimek wrote: > Hello, > > i know this has been discusses very much, i'm sorry, > but i can't help it. In a nutshell, the proposal is as > follows: > > 1. Self remains explicit (like it is now). > 2. if a class is a subclass of a special class, e.g. > named 'selfless', the self parameter is not required > and a special variable, named 'this' is provided. > > > For example: > > class Foo (selfless): > def __init__ (x, y): > this.x = x > ... > > A patch for 3.0b3 implementing this can be found at > http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff > Why not just do this? class Foo: def __init__ (this, x, y): this.x = x It's fewer characters, it gets rid of the "self" you seem to dread, and it requires no patches or changes of any kind to Python. And most importantly, has no need to introduce any "magic" into the language. Gary Herron > > regards, > Kilian Klimek > ------------------------------------------------------------------------ > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/gherron%40islandtraining.com > From tjreedy at udel.edu Wed Aug 27 09:40:01 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 27 Aug 2008 03:40:01 -0400 Subject: [Python-Dev] the explicit self In-Reply-To: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> References: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> Message-ID: Kilian Klimek wrote: > i know this has been discusses very much, There is a related discussion on python-ideas right now and was a long discussion on python-list/c.l.p within the last month. And the month before..... Either would have been the place to post this. > i'm sorry, but i can't help it. ??? From g.brandl at gmx.net Wed Aug 27 09:47:10 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 27 Aug 2008 09:47:10 +0200 Subject: [Python-Dev] the explicit self In-Reply-To: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> References: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> Message-ID: Kilian Klimek schrieb: > Hello, > > i know this has been discusses very much, i'm sorry, > but i can't help it. In a nutshell, the proposal is as > follows: > > 1. Self remains explicit (like it is now). > 2. if a class is a subclass of a special class, e.g. > named 'selfless', the self parameter is not required > and a special variable, named 'this' is provided. > > > For example: > > class Foo (selfless): > def __init__ (x, y): > this.x = x > ... > > A patch for 3.0b3 implementing this can be found at > http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff Just a note about the patch: it introduces the implicit "this" by injecting it into the function's globals. Due to how Python looks up globals and locals, this will be much slower than having a local called "self". Georg From greg.ewing at canterbury.ac.nz Wed Aug 27 09:54:47 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 27 Aug 2008 19:54:47 +1200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> Message-ID: <48B50847.6060703@canterbury.ac.nz> Phillip J. Eby wrote: > ISTR pointing out on more than one occasion that a major use case for > co-operative super() is in the implementation of metaclasses. The > __init__ and __new__ signatures are fixed, multiple inheritance is > possible, and co-operativeness is a must Do you have a real-life example of this where multiple inheritance is actually used? A non-contrived example or two would be a good thing to have in tutorials etc. where super() is discussed. It would help to convey the kinds of situations in which use of super() is and is not appropriate. -- Greg From fijall at gmail.com Wed Aug 27 10:07:28 2008 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 27 Aug 2008 10:07:28 +0200 Subject: [Python-Dev] the explicit self In-Reply-To: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> References: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> Message-ID: <693bc9ab0808270107o74dd7417la66dd6c552b6a2ce@mail.gmail.com> You can provide selfless class as a class with special metaclass that overloads __new__ and changes signature of each method. Not sure how good is this, but requires no changes to the language and will work as you want. Cheers, fijal On Wed, Aug 27, 2008 at 8:46 AM, Kilian Klimek wrote: > Hello, > > i know this has been discusses very much, i'm sorry, > but i can't help it. In a nutshell, the proposal is as > follows: > > 1. Self remains explicit (like it is now). > 2. if a class is a subclass of a special class, e.g. > named 'selfless', the self parameter is not required > and a special variable, named 'this' is provided. > > > For example: > > class Foo (selfless): > def __init__ (x, y): > this.x = x > ... > > A patch for 3.0b3 implementing this can be found at > http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff > > regards, > Kilian Klimek > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com > > From fuzzyman at voidspace.org.uk Wed Aug 27 10:21:08 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 27 Aug 2008 09:21:08 +0100 Subject: [Python-Dev] the explicit self In-Reply-To: <693bc9ab0808270107o74dd7417la66dd6c552b6a2ce@mail.gmail.com> References: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> <693bc9ab0808270107o74dd7417la66dd6c552b6a2ce@mail.gmail.com> Message-ID: <48B50E74.4090805@voidspace.org.uk> Maciej Fijalkowski wrote: > You can provide selfless class as a class with special metaclass that > overloads __new__ and changes signature of each method. Not sure how > good is this, but requires no changes to the language and will work as > you want. > > Are you advocating this Maciej? ;-) There's an example that does this here: http://www.voidspace.org.uk/python/articles/metaclasses.shtml#the-selfless-metaclass Michael > Cheers, > fijal > > On Wed, Aug 27, 2008 at 8:46 AM, Kilian Klimek > wrote: > >> Hello, >> >> i know this has been discusses very much, i'm sorry, >> but i can't help it. In a nutshell, the proposal is as >> follows: >> >> 1. Self remains explicit (like it is now). >> 2. if a class is a subclass of a special class, e.g. >> named 'selfless', the self parameter is not required >> and a special variable, named 'this' is provided. >> >> >> For example: >> >> class Foo (selfless): >> def __init__ (x, y): >> this.x = x >> ... >> >> A patch for 3.0b3 implementing this can be found at >> http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff >> >> regards, >> Kilian Klimek >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com >> >> >> > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://wwww.theotherdelia.co.uk/ From mal at egenix.com Wed Aug 27 12:53:16 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 27 Aug 2008 12:53:16 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <48B50847.6060703@canterbury.ac.nz> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <48B50847.6060703@canterbury.ac.nz> Message-ID: <48B5321C.2080303@egenix.com> On 2008-08-27 09:54, Greg Ewing wrote: > Do you have a real-life example of this where multiple > inheritance is actually used? > > A non-contrived example or two would be a good thing to > have in tutorials etc. where super() is discussed. It > would help to convey the kinds of situations in which > use of super() is and is not appropriate. The typical use is in mixin classes that can be used to add functionality to base classes, something you often find in application frameworks, e.g. class NewComponent(Feature1Mixin, Feature2Mixin, BaseComponent): ... If the mixin classes have to override one of the methods defined in BaseComponent, then they must pay attention to all other mixin classes used to define the NewComponent. Without super() (or some other mechanism of accessing the base method, like e.g. mxTools' basemethod() for classic classes), the mixins could potentially override methods defined by other mixin classes which would then not get called. As example, think of a typical application server method def process_request(self, request): ... To work properly, each implementation of the method in the mixin classes and base class will have to be called - in the order they were defined in the class definition. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 27 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From kilian.klimek at googlemail.com Wed Aug 27 15:47:18 2008 From: kilian.klimek at googlemail.com (Kilian Klimek) Date: Wed, 27 Aug 2008 15:47:18 +0200 Subject: [Python-Dev] the explicit self In-Reply-To: References: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> Message-ID: <647a40920808270647t5b67005cyb7f7c574b8d1075f@mail.gmail.com> On Wed, Aug 27, 2008 at 9:14 AM, Cesare Di Mauro wrote: > On 27 agu 2008 at 08:46:15, Kilian Klimek > wrote: > > > Hello, > > > > i know this has been discusses very much, i'm sorry, > > but i can't help it. In a nutshell, the proposal is as > > follows: > > > > 1. Self remains explicit (like it is now). > > 2. if a class is a subclass of a special class, e.g. > > named 'selfless', the self parameter is not required > > and a special variable, named 'this' is provided. > > > > > > For example: > > > > class Foo (selfless): > > def __init__ (x, y): > > this.x = x > > ... > > > > A patch for 3.0b3 implementing this can be found at > > http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff > > > > regards, > > Kilian Klimek > > > > I disagree. From "The Zen of Python": > > Explicit is better than implicit. no point in discussing this, but ... someone else emailed me this one too and i don't see the point: writing down 'self' as the first paramenter of your method does not make it any more explicit what it means. (If you want to consider readability: even worse, you can name it whatever you want). Saying "your method must accept an extra parameter (which most people call 'self') that carries all object attributes" is hardly any more explicit then saying "there is a special variable (which is always named 'this') that carries all object attributes". > > Readability counts. > Special cases aren't special enough to break the rules. > There should be one-- and preferably only one --obvious way to do it. > > Cheers, > Cesare > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleaxit at gmail.com Wed Aug 27 16:30:29 2008 From: aleaxit at gmail.com (Alex Martelli) Date: Wed, 27 Aug 2008 07:30:29 -0700 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> Message-ID: On Tue, Aug 26, 2008 at 10:24 PM, Michele Simionato wrote: ... > .. code-block:: python > > def include_mixin(mixin, cls): # could be extended to use more mixins > # traits as in Squeak take the precedence over the base class > dic = vars(mixin).copy() # could be extended to walk the ancestors > return type(mixin.__name__ + cls.__name__, (cls,), dic) I don't see any use of this in your following example so I assume you're introducing it just to be able to say that: > In the fictional world there is not need for super since > all hierarchies are linear and you can just call the base class; Nevertheless I must be missing something in the following example: > FrameworkMeta could have been written as > > .. code-block:: python > > class FrameworkMeta2(type): > def __new__(mcl, name, bases, dic): > print "Adding framework features to %s" % name > return type.__new__(mcl, name, bases, dic) > > > and DebugMetas as > > .. code-block:: python > > class DebugMeta2(type): > def __new__(mcl, name, bases, dic): > print "Adding debugging features to %s" % name > return mcl.__base__.__new__(mcl, name, bases, dic) > > > Notice that DebugMeta2 is performing a sort of cooperative call here > (``mcl.__base__.__new__``) but dead simple since there is just one base class. > > The analogous of FrameworkClass can be defined as > >>>> class FrameworkClass2(object): > ... __metaclass__ = FrameworkMeta2 > Adding framework features to FrameworkClass2 > > and the analogous of DebugFrameworkClass as > >>>> class DebugFrameworkClass2(FrameworkClass2): > ... __metaclass__ = DebugFrameworkMeta2 What's DebugFrameworkMeta2? I assume it's some kind of mix but I don't see it defined anywhere so I'm having to guess. > Adding debugging features to DebugFrameworkClass2 > Adding framework features to DebugFrameworkClass2 But where does DebugMeta2 get injected or otherwise get into the picture in this example, so that the "Adding debugging features" print executes? I don't see any code in your example that performs this injection. Maybe you're missing a key bit where you build DebugFrameworkMeta2 by using that example include_mixin you have? I'd like to understand what, in this example, removes the apparent "fragility" (or, lack of flexibility) where DebugMeta2 specifically uses mcl.__base__ -- IOW, if I have another "mixin metaclass" just like DebugMeta2 but called (say) RemotableMeta which does a print "Adding remoting features" and then also calls mcl.__base__.__new__(mcl ... just like DebugMeta2, what gets both of their __new__ methods called in the right order? Maybe you could help me understand this by giving a fully executable Python snippet using __bases__[0] instead of the hypothetical __base__? A;ex From michele.simionato at gmail.com Wed Aug 27 16:36:15 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Wed, 27 Aug 2008 16:36:15 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> Message-ID: <4edc17eb0808270736s2a5b3211x15c20aa8f74f48eb@mail.gmail.com> On Wed, Aug 27, 2008 at 4:30 PM, Alex Martelli wrote: > Maybe you could help me understand this by giving a fully executable > Python snippet using __bases__[0] instead of the hypothetical > __base__? Sorry Alex, I have the fully functional snippet but evidently I have sent some other blurb instead (it was early in the morning) It is on my machine at home and now I am at work, so have patience ;) Michele From guido at python.org Wed Aug 27 18:43:25 2008 From: guido at python.org (Guido van Rossum) Date: Wed, 27 Aug 2008 09:43:25 -0700 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: <056601c907f2$3d5f36e0$b81da4a0$@com.au> References: <056601c907f2$3d5f36e0$b81da4a0$@com.au> Message-ID: On Tue, Aug 26, 2008 at 8:08 PM, Mark Hammond wrote: > Guido quotes a colleague: > >> """ >> Given a straightforward command list like: >> >> cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk'] >> >> You apparently cannot pass this list to any subprocess function >> (subprocess.call() or otherwise) with a set of arguments that allow it >> to "just work" on both Windows and non-Windows systems. >> >> If you call: >> >> subprocess.call(cmd, shell=False) >> >> Then it works on Linux, but fails on Windows because it does not >> perform the Windows %PATHEXT% search that allows it to find that >> "svn.exe" is the actual executable to be invoked. > > I can't reproduce this as described. Which Windows version? This sounds like one of those things that could well vary by Windows version; if it works for you in Vista it may well be broken in XP. It could also vary by other setup parameters besides PATHEXT. >>>> subprocess.call(['svn', 'ls'], shell=False) > svn: '.' is not a working copy > 1 > > The reason this works is that Windows itself (CreateProcess) has support > both for implied '.exe' extensions and searching $PATH. Thus, PATHEXT > handling isn't required for executables. > > I *can* reproduce with another extension - eg, 'svn.py' - for this test I > had a 'foo.py' on my PATH (but not in the cwd), and .py in PATHEXT. > >>>> import subprocess >>>> subprocess.call(['foo'], shell=False) > ... fails >>>> subprocess.call(['foo'], shell=True) > Hello > 0 > > So I can't see this problem for 'svn.exe' and at face value the behaviour on > Windows looks quite correct - you *do* need the shell for this functionality > on Windows (in the same way you would to execute a .bat file, for example) > >> If you call: >> >> subprocess.call(cmd, shell=True) >> >> Then it works on Windows (it finds the "svn.exe" executable), but it >> fails on Linux because it *only* executes the first argument in the >> list ("svn") and does not pass the remaining arguments in the list to >> the "svn" invocation. > > It sounds like in this particular example at least, this behaviour on Linux > is the problem? I think so yes. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From curt at hagenlocher.org Wed Aug 27 19:03:20 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 27 Aug 2008 10:03:20 -0700 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: References: <056601c907f2$3d5f36e0$b81da4a0$@com.au> Message-ID: On Wed, Aug 27, 2008 at 9:43 AM, Guido van Rossum wrote: > On Tue, Aug 26, 2008 at 8:08 PM, Mark Hammond wrote: >>> >>> Then it works on Linux, but fails on Windows because it does not >>> perform the Windows %PATHEXT% search that allows it to find that >>> "svn.exe" is the actual executable to be invoked. >> >> I can't reproduce this as described. > > Which Windows version? This sounds like one of those things that could > well vary by Windows version; if it works for you in Vista it may well > be broken in XP. It could also vary by other setup parameters besides > PATHEXT. When passing the executable name to CreateProcess via the lpCommandLine parameter, PATH is considered but PATHEXT is ignored. The only extension that's automatically appended is ".exe", and only if no other extension is present. This has been true for as long as I can remember. I've found the documentation for CreateProcess (http://msdn.microsoft.com/en-us/library/ms682425.aspx) to be pretty reliable. And the mention of a ".com" in the docs suggests that the description has been around for a while... -- Curt Hagenlocher curt at hagenlocher.org From fredrik at pythonware.com Wed Aug 27 19:26:09 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 27 Aug 2008 19:26:09 +0200 Subject: [Python-Dev] the explicit self In-Reply-To: <647a40920808270647t5b67005cyb7f7c574b8d1075f@mail.gmail.com> References: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com> <647a40920808270647t5b67005cyb7f7c574b8d1075f@mail.gmail.com> Message-ID: Kilian Klimek wrote: > Saying "your method must accept an extra parameter (which most people > call 'self') that carries all object attributes" is hardly any more > explicit then saying "there is a special variable (which is always named > 'this') that carries all object attributes". in this context, implicit and explicit refers to the code, not the documentation. From fredrik at pythonware.com Wed Aug 27 19:34:14 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 27 Aug 2008 19:34:14 +0200 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: References: <056601c907f2$3d5f36e0$b81da4a0$@com.au> Message-ID: Guido van Rossum wrote: >> I can't reproduce this as described. > > Which Windows version? This sounds like one of those things that could > well vary by Windows version; if it works for you in Vista it may well > be broken in XP. It could also vary by other setup parameters besides > PATHEXT. It works the same way on XP, at least: >>> import subprocess >>> cmd = ['svn', 'ls', '.'] >>> subprocess.call(cmd, shell=False) svn: '.' is not a working copy 1 According to the MS docs, CreateProcess works the same way on at least 2K, XP and Vista. The documentation is a bit vague (as usual), but it contains an example that implies that CreateProcess always adds ".exe" if not already there, and that you need to use the command interpreter (that is, shell=True) if you want to run something that's not a Windows executable module (e.g. a batch file). From fredrik at pythonware.com Wed Aug 27 19:36:12 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 27 Aug 2008 19:36:12 +0200 Subject: [Python-Dev] subprocess insufficiently platform-independent? In-Reply-To: References: <056601c907f2$3d5f36e0$b81da4a0$@com.au> Message-ID: Curt Hagenlocher wrote: > I've found the documentation for CreateProcess > (http://msdn.microsoft.com/en-us/library/ms682425.aspx) to be pretty > reliable. And the mention of a ".com" in the docs suggests that the > description has been around for a while... And I just described it as pretty vague ;-) Reading it again, I realize that I completely missed the part that says: "If the file name does not contain an extension, .exe is appended. Therefore, if the file name extension is .com, this parameter must include the .com extension. If the file name ends in a period (.) with no extension, or if the file name contains a path, .exe is not appended." From fredrik at pythonware.com Wed Aug 27 20:21:21 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 27 Aug 2008 20:21:21 +0200 Subject: [Python-Dev] confusing exec error message in 3.0 Message-ID: (using 3.0a4) >>> exec(open("file.py")) Traceback (most recent call last): File "", line 1, in TypeError: exec() arg 1 must be a string, file, or code object, not TextIOWrapper so what's "file" referring to here? (the above works under 2.5, of course) From fredrik at pythonware.com Wed Aug 27 20:35:29 2008 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 27 Aug 2008 20:35:29 +0200 Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: References: Message-ID: Fredrik Lundh wrote: > (using 3.0a4) ahem. I could have sworn that I installed a beta, but I guess the Windows builds weren't fully synchronized when I did that. I still get the same error after updating to 3.0b2, though. (the download page still says "This is an alpha release", btw.) From g.brandl at gmx.net Thu Aug 28 00:39:01 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 28 Aug 2008 00:39:01 +0200 Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: References: Message-ID: Fredrik Lundh schrieb: > (using 3.0a4) > > >>> exec(open("file.py")) > Traceback (most recent call last): > File "", line 1, in > TypeError: exec() arg 1 must be a string, file, or code object, not > TextIOWrapper > > so what's "file" referring to here? > > (the above works under 2.5, of course) See http://bugs.python.org/issue1762972 -- it has been decided to drop that possibility. I've a patch that fixes the wrong error message in http://bugs.python.org/issue3706. Georg From Ben.Cottrell at nominum.com Thu Aug 28 00:28:50 2008 From: Ben.Cottrell at nominum.com (Ben.Cottrell at nominum.com) Date: Wed, 27 Aug 2008 15:28:50 -0700 Subject: [Python-Dev] Reference leak in thread._local Message-ID: <20080827222850.AAC451A8206@shell-ng.nominum.com> I noticed that thread._local can leak references if objects are being stored inside the thread._local object whose destructors might release the GIL. The way this happens is that in Modules/threadmodule.c, in the _ldict() function, it does things like this: Py_CLEAR(self->dict); Py_INCREF(ldict); self->dict = ldict; If the Py_CLEAR ends up taking away the last reference to an object contained in the dict, and a thread context switch occurs during that object's deallocation, then self->dict might not be NULL on return from Py_CLEAR; another thread might have run, accessed something in the same thread._local object, and caused self->dict to be set to something else (and Py_INCREF'ed). So when we blindly do the assignment into self->dict, we may be overwriting a valid reference, and not properly Py_DECREFing it. The recent change (revision 64601 to threadmodule.c) did not address context switches during the Py_CLEAR call; only context switches during tp_init. The attached patch (against trunk) is my first attempt at fixing this. It detects if self->dict has been set to something else after the Py_CLEAR, and retries the Py_CLEAR (because _ldict really only cares about installing the proper value of self->dict for the currently running thread). However, I am still uncomfortable about the fact that local_getattro and local_setattro discard the value returned from _ldict, and instead hand off control to the PyObject_Generic layer and trust that by the time self->dict is actually used, it still has the correct value for the current thread. Would it be better to, say, inline a copy of the PyObject_Generic* functions inside local_getattro/local_setattro, and force the operations to be done on the actual dict returned by _ldict()? Thanks, ~Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-patch Size: 672 bytes Desc: not available URL: From fuzzyman at voidspace.org.uk Thu Aug 28 00:55:56 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 27 Aug 2008 23:55:56 +0100 Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: References: Message-ID: <48B5DB7C.8020103@voidspace.org.uk> Georg Brandl wrote: > Fredrik Lundh schrieb: > >> (using 3.0a4) >> >> >>> exec(open("file.py")) >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: exec() arg 1 must be a string, file, or code object, not >> TextIOWrapper >> >> so what's "file" referring to here? >> >> (the above works under 2.5, of course) >> > > See http://bugs.python.org/issue1762972 -- it has been decided to drop > that possibility. > > I've a patch that fixes the wrong error message in http://bugs.python.org/issue3706. > In order to obtain a string from a Python source code file, honouring encoding cookies, the tokenize module has a 'detect_encoding' function that could be useful. Michael > Georg > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From aahz at pythoncraft.com Thu Aug 28 01:41:59 2008 From: aahz at pythoncraft.com (Aahz) Date: Wed, 27 Aug 2008 16:41:59 -0700 Subject: [Python-Dev] Reference leak in thread._local In-Reply-To: <20080827222850.AAC451A8206@shell-ng.nominum.com> References: <20080827222850.AAC451A8206@shell-ng.nominum.com> Message-ID: <20080827234159.GA25481@panix.com> On Wed, Aug 27, 2008, Ben.Cottrell at nominum.com wrote: > > I noticed that thread._local can leak references if objects are > being stored inside the thread._local object whose destructors > might release the GIL. Please post this bug report & patch to bugs.python.org -- otherwise, it will almost certainly get lost. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ Adopt A Process -- stop killing all your children! From greg.ewing at canterbury.ac.nz Thu Aug 28 02:14:15 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 28 Aug 2008 12:14:15 +1200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <48B5321C.2080303@egenix.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <48B50847.6060703@canterbury.ac.nz> <48B5321C.2080303@egenix.com> Message-ID: <48B5EDD7.5050802@canterbury.ac.nz> M.-A. Lemburg wrote: > The typical use is in mixin classes that can be used to > add functionality to base classes... But this is just another waffly made-up example. I'm talking about real-life use cases from actual code that's in use. -- Greg From guido at python.org Thu Aug 28 03:10:00 2008 From: guido at python.org (Guido van Rossum) Date: Wed, 27 Aug 2008 18:10:00 -0700 Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: References: Message-ID: 2008/8/27 Fredrik Lundh : > Fredrik Lundh wrote: > >> (using 3.0a4) > > ahem. I could have sworn that I installed a beta, but I guess the Windows builds weren't fully synchronized when I did that. I still get the same error after updating to 3.0b2, though. It's still there. It's a hold-over from 2.x where opened files were indeed usable for exec(). It was a rarely-used feature that turned out to be hard to implement given the continued reliance of the parser on while the I/O system no longer uses that, so it was dropped with very little protests. Please do fix it! -- --Guido van Rossum (home page: http://www.python.org/~guido/) -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Thu Aug 28 03:21:15 2008 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 28 Aug 2008 11:21:15 +1000 Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: References: Message-ID: <200808281121.15908.steve@pearwood.info> On Thu, 28 Aug 2008 08:39:01 am Georg Brandl wrote: > Fredrik Lundh schrieb: > > (using 3.0a4) > > > > >>> exec(open("file.py")) > > > > Traceback (most recent call last): > > File "", line 1, in > > TypeError: exec() arg 1 must be a string, file, or code object, not > > TextIOWrapper > > > > so what's "file" referring to here? > > > > (the above works under 2.5, of course) > > See http://bugs.python.org/issue1762972 -- it has been decided to > drop that possibility. Hmmm... I have a concern with one of the patches in that issue; I refer to patch that changes the semantics of module's __file__ attribute. Guido noted that exec(open(M.__file__).read(), M.__dict__) almost worked as a replacement for reload(), except that there were issues with file extensions (.py, .pyc, .pyo and even things like .pyc24). So it was decided that M.__file__ should always point to the source file. But now that reload() is now moved into the imp module, I don't see that the justification for changing the semantics of M.__file__ still exists. imp.reload(M) is much better for interactive use than exec(open(M.__file__).read(), M.__dict__). Is there still a justification for having M.__file__ point to the source even if the module was actually loaded from the .pyc version? If so, what is that? Some years ago, as a newbie, I was having trouble with reload() repeatedly not picking up changes I was making to a module. The problem turned out to be user-error, but how I discovered that was by looking at M.__file__ and noticing that Python was loading the .pyc file instead of the .py file I was expecting. Had M.__file__ given misleading information, I would have been mislead for much longer. Here's a small contrived example under Python 2.5: >>> import parrot >>> parrot.__file__ 'parrot.py' >>> # pretend that I made changes to the source ... # in my editor, but forgot to save them ... reload(parrot) >>> parrot.__file__ 'parrot.pyc' I don't think M.__file__ should lie and say it was loaded from a file that it wasn't loaded from. It's useful to be able to look at a module and see what file it was actually loaded from. -- Steven From guido at python.org Thu Aug 28 05:38:14 2008 From: guido at python.org (Guido van Rossum) Date: Wed, 27 Aug 2008 20:38:14 -0700 Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: <200808281121.15908.steve@pearwood.info> References: <200808281121.15908.steve@pearwood.info> Message-ID: On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano wrote: > On Thu, 28 Aug 2008 08:39:01 am Georg Brandl wrote: >> Fredrik Lundh schrieb: >> > (using 3.0a4) >> > >> > >>> exec(open("file.py")) >> > >> > Traceback (most recent call last): >> > File "", line 1, in >> > TypeError: exec() arg 1 must be a string, file, or code object, not >> > TextIOWrapper >> > >> > so what's "file" referring to here? >> > >> > (the above works under 2.5, of course) >> >> See http://bugs.python.org/issue1762972 -- it has been decided to >> drop that possibility. > > Hmmm... I have a concern with one of the patches in that issue; I refer > to patch that changes the semantics of module's __file__ attribute. > > Guido noted that exec(open(M.__file__).read(), M.__dict__) almost worked > as a replacement for reload(), except that there were issues with file > extensions (.py, .pyc, .pyo and even things like .pyc24). So it was > decided that M.__file__ should always point to the source file. > > But now that reload() is now moved into the imp module, I don't see that > the justification for changing the semantics of M.__file__ still > exists. imp.reload(M) is much better for interactive use than > exec(open(M.__file__).read(), M.__dict__). > > Is there still a justification for having M.__file__ point to the source > even if the module was actually loaded from the .pyc version? If so, > what is that? > > Some years ago, as a newbie, I was having trouble with reload() > repeatedly not picking up changes I was making to a module. The problem > turned out to be user-error, but how I discovered that was by looking > at M.__file__ and noticing that Python was loading the .pyc file > instead of the .py file I was expecting. Had M.__file__ given > misleading information, I would have been mislead for much longer. > Here's a small contrived example under Python 2.5: > >>>> import parrot >>>> parrot.__file__ > 'parrot.py' >>>> # pretend that I made changes to the source > ... # in my editor, but forgot to save them > ... reload(parrot) > >>>> parrot.__file__ > 'parrot.pyc' > > > I don't think M.__file__ should lie and say it was loaded from a file > that it wasn't loaded from. It's useful to be able to look at a module > and see what file it was actually loaded from. While appreciate the use case, there are way more use cases where there's code that must painstakingly strip the trailing 'c' or 'o' from __file__ in order to read the source code. Perhaps we should have a separate API for finding out whether a module was loaded from source or from a .pyc file; but I think it would be better to have such an API somewhere in the imp module. It's also possible to follow what goes on by watching the verbose -v output. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From michele.simionato at gmail.com Thu Aug 28 06:35:08 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Thu, 28 Aug 2008 06:35:08 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> Message-ID: <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> Alex Martelli wrote: > What's DebugFrameworkMeta2? I assume it's some kind of mix but I > don't see it defined anywhere so I'm having to guess. Sorry Alex, here is definition which got lost in cut&paste: DebugFrameworkMeta2 = include_mixin(DebugMeta2, FrameworkMeta2) > I'd like to understand what, in this example, removes the apparent > "fragility" (or, lack of flexibility) where DebugMeta2 specifically > uses mcl.__base__ -- IOW, if I have another "mixin metaclass" just > like DebugMeta2 but called (say) RemotableMeta which does a print > "Adding remoting features" and then also calls > mcl.__base__.__new__(mcl ... just like DebugMeta2, what gets both of > their __new__ methods called in the right order? If you want to reimplement full cooperation between mixins classes you must rework a bit the example, but it does not take a big effort (see later). However my main point is: do we really want cooperative methods? Multiple inheritance of metaclasses is perhaps the strongest use case for multiple inheritance, but is it strong enough? I mean, in real code how many times did I need that? I would not mind make life harder for gurus and simpler for application programmers. I do not think removing cooperation would be so bad in practice. In many practical cases, one could just write the metaclass by hand, in this example something like class RemotableDebugFrameworkMeta(FrameworkMeta): def __new__(mcl, name, bases, dic): print "Adding remoting features to %s" % name print "Adding debugging features to %s" % name return FrameworkMeta.__new__(mcl, name, bases, dic) Maybe you would need to duplicate a couple of lines and/or to introduce an helper function, but you would have the benefit of having a more explicit metaclass, with a simpler hierarchy (see the appendix for an alternative solution). > Maybe you could help me understand this by giving a fully executable > Python snippet using __bases__[0] instead of the hypothetical > __base__? To the best of my knowledge __base__ is a valid class attribute, it denotes the "right" class to use as base. Usually it is the same as bases[0], but there is at least one case when it is different, when composing old style and new style classes: >>> class OldStyle: pass >>> class NewStyle(object): pass >>> class New(OldStyle, NewStyle): pass >>> New.__bases__[0] >>> New.__base__ Appendix: how to reimplement cooperation in a single-inheritance world ---------------------------------------------------------------------------- Quoting Raymond: "To achieve substantially the same functionality, you would likely have to re-invent much of what super() does for us automatically, and you would still be imposing constraits on the composed classes that are substantially the same as what you have with inheritance." Raymond of course is right, but I am arguing that one does not really need to re-invent cooperation because the use case for cooperation are exceedingly rare. Still, if one really wants to reimplement cooperation, here is my take at the challenge: $ cat cooperative_mixins.py "Implements cooperative mixins using multiple-inheritance only" ## everything in three lines def include_mixin(mixin, cls): # could be extended to use more mixins # traits as in Squeak take the precedence over the base class dic = vars(mixin).copy() # could be extended to walk the ancestors dic['_%s__super' % mixin.__name__] = cls return type(mixin.__name__ + cls.__name__, (cls,), dic) ## examples: class FrameworkMeta(type): # example metaclass def __new__(mcl, name, bases, dic): print "Adding framework features to %s" % name return type.__new__(mcl, name, bases, dic) class DebugMeta(type): # mixin metaclass def __new__(mcl, name, bases, dic): print "Adding debugging features to %s" % name return mcl.__super.__new__(mcl, name, bases, dic) class RemotableMeta(type): # another mixin metaclass def __new__(mcl, name, bases, dic): print "Adding remoting features to %s" % name return mcl.__super.__new__(mcl, name, bases, dic) class FrameworkClass(object): __metaclass__ = FrameworkMeta DebugFrameworkMeta = include_mixin(DebugMeta, FrameworkMeta) print '**************** creating DebugFrameworkClass' class DebugFrameworkClass(FrameworkClass): __metaclass__ = DebugFrameworkMeta RemotableDebugFrameworkMeta = include_mixin( RemotableMeta, DebugFrameworkMeta) print '**************** creating RemotableDebugFrameworkClass' class RemotableDebugFrameworkClass(FrameworkClass): __metaclass__ = RemotableDebugFrameworkMeta From steve at pearwood.info Thu Aug 28 07:14:40 2008 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 28 Aug 2008 15:14:40 +1000 Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: References: <200808281121.15908.steve@pearwood.info> Message-ID: <200808281514.41216.steve@pearwood.info> On Thu, 28 Aug 2008 01:38:14 pm Guido van Rossum wrote: > On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano wrote: ... > > I don't think M.__file__ should lie and say it was loaded from a > > file that it wasn't loaded from. It's useful to be able to look at > > a module and see what file it was actually loaded from. > > While appreciate the use case, there are way more use cases where > there's code that must painstakingly strip the trailing 'c' or 'o' > from __file__ in order to read the source code. Perhaps we should > have a separate API for finding out whether a module was loaded from > source or from a .pyc file; but I think it would be better to have > such an API somewhere in the imp module. It's also possible to follow > what goes on by watching the verbose -v output. Thinking more about it, I'm quite enthusiastic about Brett Cannon's suggestion that modules should grow a __source__ attribute as well as __file__. One disadvantage of a separate API is that it's relatively hard to discover, compared to dir(module) or help(module). I don't think I would have thought to look at a module "imp" (implementation?) when I needed that information. But perhaps that's a separate issue. How would such an API work? Knowing nothing concrete about the implementation, I can think of two ways: (1) Look at the module object and extract information from it that recorded what file it came from at the time, even if the Python path (or its contents) changed. This is the 2.x semantics of __file__. (2) Look at the Python path as it exists now, and try to predict (postdict?) which file might have been used to import the module. Of the two, I feel that postdiction is the worse solution. I imagine that this behaviour would be undesirable: # not real code >>> sys.path.append('somewhere') >>> import parrot # imports from 'somewhere/parrot.pyc' >>> parrot.__file__ 'somewhere/parrot.py' >>> del sys.path[-1] >>> sys.path.append('somewhere_else/different') >>> imp.where_from(parrot) 'somewhere_else/different/parrot.py' But maybe that can't happen and I'm worrying for nothing. So what happens now? Does this need a PEP for further discussion? -- Steven From steve at holdenweb.com Thu Aug 28 09:34:27 2008 From: steve at holdenweb.com (Steve Holden) Date: Thu, 28 Aug 2008 03:34:27 -0400 Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: References: <200808281121.15908.steve@pearwood.info> Message-ID: Guido van Rossum wrote: > On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano wrote: >> On Thu, 28 Aug 2008 08:39:01 am Georg Brandl wrote: >>> Fredrik Lundh schrieb: >>>> (using 3.0a4) >>>> >>>> >>> exec(open("file.py")) >>>> >>>> Traceback (most recent call last): >>>> File "", line 1, in >>>> TypeError: exec() arg 1 must be a string, file, or code object, not >>>> TextIOWrapper >>>> >>>> so what's "file" referring to here? >>>> >>>> (the above works under 2.5, of course) >>> See http://bugs.python.org/issue1762972 -- it has been decided to >>> drop that possibility. >> Hmmm... I have a concern with one of the patches in that issue; I refer >> to patch that changes the semantics of module's __file__ attribute. >> >> Guido noted that exec(open(M.__file__).read(), M.__dict__) almost worked >> as a replacement for reload(), except that there were issues with file >> extensions (.py, .pyc, .pyo and even things like .pyc24). So it was >> decided that M.__file__ should always point to the source file. >> >> But now that reload() is now moved into the imp module, I don't see that >> the justification for changing the semantics of M.__file__ still >> exists. imp.reload(M) is much better for interactive use than >> exec(open(M.__file__).read(), M.__dict__). >> >> Is there still a justification for having M.__file__ point to the source >> even if the module was actually loaded from the .pyc version? If so, >> what is that? >> >> Some years ago, as a newbie, I was having trouble with reload() >> repeatedly not picking up changes I was making to a module. The problem >> turned out to be user-error, but how I discovered that was by looking >> at M.__file__ and noticing that Python was loading the .pyc file >> instead of the .py file I was expecting. Had M.__file__ given >> misleading information, I would have been mislead for much longer. >> Here's a small contrived example under Python 2.5: >> >>>>> import parrot >>>>> parrot.__file__ >> 'parrot.py' >>>>> # pretend that I made changes to the source >> ... # in my editor, but forgot to save them >> ... reload(parrot) >> >>>>> parrot.__file__ >> 'parrot.pyc' >> >> >> I don't think M.__file__ should lie and say it was loaded from a file >> that it wasn't loaded from. It's useful to be able to look at a module >> and see what file it was actually loaded from. > > While appreciate the use case, there are way more use cases where > there's code that must painstakingly strip the trailing 'c' or 'o' > from __file__ in order to read the source code. Perhaps we should have > a separate API for finding out whether a module was loaded from source > or from a .pyc file; but I think it would be better to have such an > API somewhere in the imp module. It's also possible to follow what > goes on by watching the verbose -v output. > Painstakingly? Surely the pain level isn't that high, and I agree with Michael that the __file__ information would be better as the literal truth. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From solipsis at pitrou.net Thu Aug 28 12:28:53 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 28 Aug 2008 10:28:53 +0000 (UTC) Subject: [Python-Dev] Stable / unstable buildbots Message-ID: Hello everyone, What is the rationale behind the distinction between "stable" and "unstable" buildbots? I ask that because the OpenBSD buildbot has failed compiling 3.0 for quite some time, but since that buildbot was in the "unstable" bunch, it was not discovered until someone filed a bug report for it (see http://bugs.python.org/issue3696). Regards Antoine. From barry at python.org Thu Aug 28 14:16:41 2008 From: barry at python.org (Barry Warsaw) Date: Thu, 28 Aug 2008 08:16:41 -0400 Subject: [Python-Dev] Stable / unstable buildbots In-Reply-To: References: Message-ID: <04B40C81-D9DA-4F68-B23F-79FC31609E30@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 28, 2008, at 6:28 AM, Antoine Pitrou wrote: > What is the rationale behind the distinction between "stable" and > "unstable" > buildbots? > I ask that because the OpenBSD buildbot has failed compiling 3.0 for > quite some > time, but since that buildbot was in the "unstable" bunch, it was > not discovered > until someone filed a bug report for it (see http://bugs.python.org/issue3696) > . Mostly, it was a determination that Neal and I made at Pycon, about which bots we should "trust" to judge the health of the trees. I don't think the current list needs to be set in stone, and in fact several of the "stable" bots have had simple svn or other non-tree related problems for a while. As for the "unstable" ones, I personally rarely check them. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLaXKXEjvBPtnXfVAQJfqgQAiyoqqUNQWByKEalKmWpRyqlX56PJIzPB S5gqubUZOvUTjVvHgvUtePPmJwEntyE+WcWXrX2tRlmMiCwantjgYOuNJeqonuwE BVZRrIjU/mayM9gRiN9NhuGHfV/YiLKpte+DKzuYZwGW2TnaCM3ijWe2QuMxmgqZ MMAO1w+M1kE= =qIFo -----END PGP SIGNATURE----- From facundobatista at gmail.com Thu Aug 28 14:27:02 2008 From: facundobatista at gmail.com (Facundo Batista) Date: Thu, 28 Aug 2008 09:27:02 -0300 Subject: [Python-Dev] Stable / unstable buildbots In-Reply-To: <04B40C81-D9DA-4F68-B23F-79FC31609E30@python.org> References: <04B40C81-D9DA-4F68-B23F-79FC31609E30@python.org> Message-ID: 2008/8/28 Barry Warsaw : > bots we should "trust" to judge the health of the trees. I don't think the > current list needs to be set in stone, and in fact several of the "stable" > bots have had simple svn or other non-tree related problems for a while. Maybe a good requisite to move a buildbot from unstable to stable is to find a champion for it. I mean, something that can test on that platform and cares enough about it to, or fix the issue himself/herself, or find who broke it and bother the responsible until it gets fixed. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From solipsis at pitrou.net Thu Aug 28 15:33:21 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 28 Aug 2008 13:33:21 +0000 (UTC) Subject: [Python-Dev] Stable / unstable buildbots References: <04B40C81-D9DA-4F68-B23F-79FC31609E30@python.org> Message-ID: Facundo Batista gmail.com> writes: > > Maybe a good requisite to move a buildbot from unstable to stable is > to find a champion for it. I mean, something that can test on that > platform and cares enough about it to, or fix the issue > himself/herself, or find who broke it and bother the responsible until > it gets fixed. By that metric, I fear that the only remaining buildbots would be the Linux/Windows x86/x64 ones. I'm not sure anyone here, for example, cares really much about Sparc buildbots, apart from the fact that having red "stable" buildbots doesn't make Python look very good, and we try to avoid that. But then Python wouldn't be really cross-platform anymore, or just in a very theoretical way. Also, lacking stable buildbots means some chunks of the language or stdlib aren't even tested anymore. For example, the bigmem/bigaddrspace tests are completely broken in the py3k branch. Regards Antoine. From facundobatista at gmail.com Thu Aug 28 15:38:40 2008 From: facundobatista at gmail.com (Facundo Batista) Date: Thu, 28 Aug 2008 10:38:40 -0300 Subject: [Python-Dev] Stable / unstable buildbots In-Reply-To: References: <04B40C81-D9DA-4F68-B23F-79FC31609E30@python.org> Message-ID: 2008/8/28 Antoine Pitrou : > By that metric, I fear that the only remaining buildbots would be the > Linux/Windows x86/x64 ones. I'm not sure anyone here, for example, cares really Note that I meant to "move from unstable to stable, starting from the actual state", not to "decide again which ones will be stables or not". I agree with you in all the other matters. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From pje at telecommunity.com Thu Aug 28 17:30:39 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 28 Aug 2008 11:30:39 -0400 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.co m> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> Message-ID: <20080828152941.CD4E43A410E@sparrow.telecommunity.com> At 06:35 AM 8/28/2008 +0200, Michele Simionato wrote: >Multiple inheritance of metaclasses is perhaps >the strongest use case for multiple inheritance, but is it strong >enough? I mean, in real code how many times did I need that? >I would not mind make life harder for gurus and simpler for >application programmers. Then you need to leave MI and co-operation the hell alone. Right now, an application programmer can mix metaclasses like this: class FooBar(Foo, Bar): class __metaclass__(Foo.__class__, Bar.__class__): pass ... Or, in 3.x: class FooBarClass(Foo.__class__, Bar.__class__): pass class FooBar(Foo, Bar, metaclass=FooBarClass): ... Either way, this is useful in cases where Foo and Bar come from different frameworks. That's the *only* way to get such things to co-operate, in fact. >I do not think removing cooperation >would be so bad in practice. In many practical cases, one could just write >the metaclass by hand, How is that making things easier for application programmers? >Maybe you would need to duplicate a couple of lines and/or to introduce >an helper function, ...which then has to have an agreed-upon protocol that all metaclass authors have to follow... which we already have... but which you're proposing to get rid of... so we can re-invent it lots of times... in mutually incompatible ways. :) From michele.simionato at gmail.com Thu Aug 28 17:50:29 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Thu, 28 Aug 2008 17:50:29 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <20080828152941.CD4E43A410E@sparrow.telecommunity.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> Message-ID: <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> On Aug 28, 5:30 pm, "Phillip J. Eby" wrote: > How is that making things easier for application programmers? We have different definitions of "application programmer". For me a typical application programmer is somebody who never fiddles with metaclasses, which are the realm of framework builders. But the borders are fluid, I agree. > >Maybe you would need to duplicate a couple of lines and/or to introduce > >an helper function, > > ...which then has to have an agreed-upon protocol that all metaclass > authors have to follow... which we already have... but which you're > proposing to get rid of... so we can re-invent it lots of > times... in mutually incompatible ways. :) Notice that I was discussing an hypothetical language. I was arguing that in principle one could write a different language from Python, with single inheritance only, and not lose much expressivity. I am not advocating any change to current Python. My point was in language design: I want to know how much I can remove from a language and still have something useful, in the spirit of the famous Saint-Exupery quote. Michele Simionato From jjb5 at cornell.edu Thu Aug 28 20:36:00 2008 From: jjb5 at cornell.edu (Joel Bender) Date: Thu, 28 Aug 2008 14:36:00 -0400 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <48B50847.6060703@canterbury.ac.nz> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <48B50847.6060703@canterbury.ac.nz> Message-ID: <48B6F010.9000704@cornell.edu> Greg, > Do you have a real-life example of this where multiple > inheritance is actually used? I have built a framework that I have called the "capability pattern" which uses multiple inheritance in a way that might be unique (I'm not familiar enough with other frameworks to know for sure). There are two classes, a Collector and a Capability. The result of calling a function of the collector is a list of results of calling the functions of the bound capabilities. For example, these three are capability classes: class X(Capability): def f(self): return 'X.f' class Y(Capability): def g(self): return 'Y.g' class Z(Capability): def f(self): return 'Z.f' def g(self): return 'Z.g' Now to create a sample collector: class A(Collector, X, Y, Z): pass Calling A().f() returns ['X.f', 'Z.f']. I use this pattern in a web application. The do_GET call is mapped into do_SHOW, and each 'capability' can return something from its do_SHOW (usually a
element) and the results are sent back to the user. In my case I have lots of combinations of capabilities that can be mixed together. I decided to use multiple inheritance over other patterns because I wanted to leverage isinstance(obj,Y) to indicate that some object has some capability, and not having to duplicate the method resolution order code for other kinds of methods is really nice. > A non-contrived example or two would be a good thing to > have in tutorials etc. where super() is discussed. It > would help to convey the kinds of situations in which > use of super() is and is not appropriate. So this is a collection of cooperative classes, and super() isn't used. Joel From pje at telecommunity.com Thu Aug 28 20:54:08 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 28 Aug 2008 14:54:08 -0400 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com > References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> Message-ID: <20080828185312.943163A408D@sparrow.telecommunity.com> At 05:50 PM 8/28/2008 +0200, Michele Simionato wrote: >On Aug 28, 5:30 pm, "Phillip J. Eby" wrote: > > How is that making things easier for application programmers? > >We have different definitions of "application programmer". For me a typical >application programmer is somebody who never fiddles with metaclasses, >which are the realm of framework builders. Application programmers use frameworks, and sometimes more than one. If they're subclassing from two different frameworks, each using a different metaclass, they will need to also multiple-inherit the metaclass. This is in fact so annoying that I created a "universal metaclass" in DecoratorTools whose sole function is to delegate metaclass __new__, __init__, and __call__ to class-level methods (e.g. __class_new__, __class_call__, etc.), thereby eliminating the need to have custom metaclasses for most use cases in the first place. Now, wherever possible, I use that single metaclass in my frameworks, so that there's no need to mix them. That, IMO, would be a more useful change than getting rid of super(); it would get rid of the explicit metaclass mixing. (It would still not remove the need for co-operative methods, as the class-delegated methods still need to be co-operative for MI to work.) There are, of course, other ways to create co-operative function calls besides super(), and I've certainly created more a few of them in my time. (E.g. generic function method combination, instancemethod() chains, and next-method-iterators, to name the ones that occur to me right off.) But these are more for cases where super() is wholly inadequate to the purpose, and none are anywhere near as convenient as super(). From fuzzyman at voidspace.org.uk Thu Aug 28 21:31:16 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 28 Aug 2008 20:31:16 +0100 Subject: [Python-Dev] Documentation Error for __hash__ Message-ID: <48B6FD04.6080008@voidspace.org.uk> Hello all, The documentation for __hash__ seems to be outdated. I'm happy to submit a patch, so long as I am not misunderstanding something. http://docs.python.org/dev/reference/datamodel.html#object.__hash__ The documentation states: If a class does not define a __cmp__() or __eq__() method it should not define a __hash__() operation either; if it defines __cmp__() or __eq__() but not __hash__(), its instances will not be usable as dictionary keys. If a class defines mutable objects and implements a __cmp__() or __eq__() method, it should not implement __hash__(), since the dictionary implementation requires that a key?s hash value is immutable (if the object?s hash value changes, it will be in the wrong hash bucket). This may have been true for old style classes, but as new style classes inherit a default __hash__ from object - mutable objects *will* be usable as dictionary keys (hashed on identity) *unless* they implement a __hash__ method that raises a type error. Shouldn't the advice be that classes that implement comparison methods should always implement __hash__ (wasn't this nearly enforced?), and that mutable objects should raise a TypeError in __hash__. Additionally the following documentation states that __reversed__ is new in Python 2.6 and I think it was actually new in Python 2.4 (it certainly works for Python 2.5 and IronPython 1 which targets 2.4...). http://docs.python.org/dev/reference/datamodel.html#object.__reversed__ Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From tjreedy at udel.edu Thu Aug 28 21:59:44 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 28 Aug 2008 15:59:44 -0400 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> Message-ID: Michele Simionato wrote: > Notice that I was discussing an hypothetical language. I was arguing > that in principle > one could write a different language from Python, with single inheritance only, > and not lose much expressivity. I am not advocating any change to > current Python. Since this is a list for discussing changing current Python, you will have to excuse misunderstanding on that point. I do realize that you began with a concrete offer of improving the documentation of the super you hypothetically would like to be rid of ;-) From hall.jeff at gmail.com Thu Aug 28 22:42:18 2008 From: hall.jeff at gmail.com (Jeff Hall) Date: Thu, 28 Aug 2008 16:42:18 -0400 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B6FD04.6080008@voidspace.org.uk> References: <48B6FD04.6080008@voidspace.org.uk> Message-ID: <1bc395c10808281342v5d9a0d48sf748758a7b0fe6dd@mail.gmail.com> I'm not sure about the first but as for the __reversed__ we had a discussion yesterday and it was indeed added in 2.4 (oddly, my 2.5 documentation has this correct... ) -- Haikus are easy Most make very little sense Refrigerator -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Thu Aug 28 23:51:45 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 29 Aug 2008 07:51:45 +1000 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B6FD04.6080008@voidspace.org.uk> References: <48B6FD04.6080008@voidspace.org.uk> Message-ID: <48B71DF1.8020902@gmail.com> Michael Foord wrote: > This may have been true for old style classes, but as new style classes > inherit a default __hash__ from object - mutable objects *will* be > usable as dictionary keys (hashed on identity) *unless* they implement a > __hash__ method that raises a type error. > > Shouldn't the advice be that classes that implement comparison methods > should always implement __hash__ (wasn't this nearly enforced?), and > that mutable objects should raise a TypeError in __hash__. Hmm, I thought I fixed those docs when I did the PyObject_HashNotImplemented patch... (you can set __hash__ = None rather than raising a TypeError explicitly now so that collections.Hashable correctly returns False - the slot machinery in typeobject.c will then take of turning that into PyObject_HashNotImplemented at the C level). However, looking at the relevant checkins, it appears I only updated the C API docs and didn't correct the library or language references. I reopened http://bugs.python.org/issue2235 - there are some other doc fixes I need to do this weekend for RC1, so I can tackle this at the same time. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From tjreedy at udel.edu Thu Aug 28 23:55:14 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 28 Aug 2008 17:55:14 -0400 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <1bc395c10808281342v5d9a0d48sf748758a7b0fe6dd@mail.gmail.com> References: <48B6FD04.6080008@voidspace.org.uk> <1bc395c10808281342v5d9a0d48sf748758a7b0fe6dd@mail.gmail.com> Message-ID: Jeff Hall wrote: > I'm not sure about the first but as for the __reversed__ we had a > discussion yesterday and it was indeed added in 2.4 (oddly, my 2.5 > documentation has this correct... ) 2.4 doc: reversed( seq) Return a reverse iterator. seq must be an object which supports the sequence protocol (the __len__() method and the __getitem__() method with integer arguments starting at 0). New in version 2.4. [no mention of __reversed__] 3.3.6 Additional methods for emulation of sequence types [ditto] However, I confirmed that __reversed__ is used by reverse() class C: def __reversed__(self): return 'abc' c=C() print(reversed(c)) >>> abc From matt.giuca at gmail.com Fri Aug 29 00:00:06 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Fri, 29 Aug 2008 08:00:06 +1000 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B6FD04.6080008@voidspace.org.uk> References: <48B6FD04.6080008@voidspace.org.uk> Message-ID: > This may have been true for old style classes, but as new style classes > inherit a default __hash__ from object - mutable objects *will* be usable as > dictionary keys (hashed on identity) *unless* they implement a __hash__ > method that raises a type error. > I always thought this was a bug in new-style classes (due to the fact that, as you say, they inherit __hash__ from object whether it's wanted or not). However, it seems to be fixed in Python 3.0. So this documentation is only "wrong" for Python 2.x branch. See: Python 2.6b3+ (trunk:66055, Aug 29 2008, 07:50:39) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __eq__(self, other): ... return True ... >>> x = X() >>> hash(x) -1211564180 versus Python 3.0b3+ (py3k:66055M, Aug 29 2008, 07:52:23) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __eq__(self, other): ... return True ... >>> x = X() >>> hash(x) Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'X' Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Fri Aug 29 03:39:01 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 29 Aug 2008 13:39:01 +1200 Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: <200808281121.15908.steve@pearwood.info> References: <200808281121.15908.steve@pearwood.info> Message-ID: <48B75335.6090502@canterbury.ac.nz> Steven D'Aprano wrote: > I don't think M.__file__ should lie and say it was loaded from a file > that it wasn't loaded from. It's useful to be able to look at a module > and see what file it was actually loaded from. On the other hand, it could be useful to be able to find the source file for a module, regardless of whether it was loaded from a .py, .pyc or .pyo. Maybe there should be a __source__ attribute for that? Or is os.path.splitext(M.__file__)[0] + ".py" considered good enough for that? -- Greg From ijmorlan at cs.uwaterloo.ca Fri Aug 29 03:50:14 2008 From: ijmorlan at cs.uwaterloo.ca (Isaac Morland) Date: Thu, 28 Aug 2008 21:50:14 -0400 (EDT) Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: <48B75335.6090502@canterbury.ac.nz> References: <200808281121.15908.steve@pearwood.info> <48B75335.6090502@canterbury.ac.nz> Message-ID: On Fri, 29 Aug 2008, Greg Ewing wrote: > Steven D'Aprano wrote: > >> I don't think M.__file__ should lie and say it was loaded from a file that >> it wasn't loaded from. It's useful to be able to look at a module and see >> what file it was actually loaded from. > > On the other hand, it could be useful to be able to find > the source file for a module, regardless of whether it > was loaded from a .py, .pyc or .pyo. > > Maybe there should be a __source__ attribute for that? > > Or is os.path.splitext(M.__file__)[0] + ".py" considered > good enough for that? I think .__source__ is a much better idea. It's more explicit to start with, and on top of that it can simply be None when there is no source file available, which is much more explicit than "file not found means no source file available". Also, if a feature is ever added to allow telling Python to put the compiled files in a separate tree (like javac -d directory in the Java universe) then it will be even more clear that computing the source location from __file__ is not the way to go. PS, in case it's not clear, I want that feature, in order to keep .pyc files out of my SVN checkouts. I hate having automatically generated files in my workspace. Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist From guido at python.org Fri Aug 29 04:25:47 2008 From: guido at python.org (Guido van Rossum) Date: Thu, 28 Aug 2008 19:25:47 -0700 Subject: [Python-Dev] confusing exec error message in 3.0 In-Reply-To: References: <200808281121.15908.steve@pearwood.info> Message-ID: 2008/8/28 Steve Holden : > Guido van Rossum wrote: >> On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano wrote: >>> On Thu, 28 Aug 2008 08:39:01 am Georg Brandl wrote: >>>> Fredrik Lundh schrieb: >>>>> (using 3.0a4) >>>>> >>>>> >>> exec(open("file.py")) >>>>> >>>>> Traceback (most recent call last): >>>>> File "", line 1, in >>>>> TypeError: exec() arg 1 must be a string, file, or code object, not >>>>> TextIOWrapper >>>>> >>>>> so what's "file" referring to here? >>>>> >>>>> (the above works under 2.5, of course) >>>> See http://bugs.python.org/issue1762972 -- it has been decided to >>>> drop that possibility. >>> Hmmm... I have a concern with one of the patches in that issue; I refer >>> to patch that changes the semantics of module's __file__ attribute. >>> >>> Guido noted that exec(open(M.__file__).read(), M.__dict__) almost worked >>> as a replacement for reload(), except that there were issues with file >>> extensions (.py, .pyc, .pyo and even things like .pyc24). So it was >>> decided that M.__file__ should always point to the source file. >>> >>> But now that reload() is now moved into the imp module, I don't see that >>> the justification for changing the semantics of M.__file__ still >>> exists. imp.reload(M) is much better for interactive use than >>> exec(open(M.__file__).read(), M.__dict__). >>> >>> Is there still a justification for having M.__file__ point to the source >>> even if the module was actually loaded from the .pyc version? If so, >>> what is that? >>> >>> Some years ago, as a newbie, I was having trouble with reload() >>> repeatedly not picking up changes I was making to a module. The problem >>> turned out to be user-error, but how I discovered that was by looking >>> at M.__file__ and noticing that Python was loading the .pyc file >>> instead of the .py file I was expecting. Had M.__file__ given >>> misleading information, I would have been mislead for much longer. >>> Here's a small contrived example under Python 2.5: >>> >>>>>> import parrot >>>>>> parrot.__file__ >>> 'parrot.py' >>>>>> # pretend that I made changes to the source >>> ... # in my editor, but forgot to save them >>> ... reload(parrot) >>> >>>>>> parrot.__file__ >>> 'parrot.pyc' >>> >>> >>> I don't think M.__file__ should lie and say it was loaded from a file >>> that it wasn't loaded from. It's useful to be able to look at a module >>> and see what file it was actually loaded from. >> >> While appreciate the use case, there are way more use cases where >> there's code that must painstakingly strip the trailing 'c' or 'o' >> from __file__ in order to read the source code. Perhaps we should have >> a separate API for finding out whether a module was loaded from source >> or from a .pyc file; but I think it would be better to have such an >> API somewhere in the imp module. It's also possible to follow what >> goes on by watching the verbose -v output. >> > Painstakingly? Surely the pain level isn't that high, and I agree with > Michael that the __file__ information would be better as the literal truth. Some people have custom mods to Python that change the extension, and then the c/o stripping code breaks. What is the literal truth depends on your use case. It is the literal truth that the source file is the .py file. -- --Guido van Rossum (home page: http://www.python.org/~guido/) -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele.simionato at gmail.com Fri Aug 29 06:07:27 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Fri, 29 Aug 2008 06:07:27 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <20080828185312.943163A408D@sparrow.telecommunity.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> Message-ID: <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> On Thu, Aug 28, 2008 at 8:54 PM, Phillip J. Eby wrote: > I created a "universal metaclass" in > DecoratorTools whose sole function is to delegate metaclass __new__, > __init__, and __call__ to class-level methods (e.g. __class_new__, > __class_call__, etc.), thereby eliminating the need to have custom > metaclasses for most use cases in the first place. Now, wherever possible, > I use that single metaclass in my frameworks, so that there's no need to mix > them. easy_installed DecoratorTools and found it: classy_class. >From the point of view of the code, this is a beautiful and elegant snippet. However, suppose that from tomorrow everybody starts using it. Since metaclasses would become so easy to use, possibly a lot of people would take advantage of them. Then we would have potentially complex (multiple) inheritance hierarchies with chains of methods (_class__new__/_class__init__) calling themselves cooperatively in the MRO. Would the resulting code be readable? How easy would be for an average framework user to understand what is happening to his class? I think class decorators would be a much better solution than classy_class for most use cases and we should push that way, not the cooperative inheritance way. Generally speaking I like more solutions bases on functional composition (as in WSGI that you know very well) than on method cooperation. Rather than improve the support for inheritance, I would like (in an ideal world) to reduce it, to make easier the choice for people between inheritance and alternatives (object composition, delegation, functional composition). In the real world, I am content in documenting the pitfalls of super, warn people about the dangers of complex design involving multiple inheritance and cooperation, and suggest alternatives. Michele Simionato From pje at telecommunity.com Fri Aug 29 06:22:39 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 29 Aug 2008 00:22:39 -0400 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.co m> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> Message-ID: <20080829042146.6DC123A408D@sparrow.telecommunity.com> At 06:07 AM 8/29/2008 +0200, Michele Simionato wrote: >On Thu, Aug 28, 2008 at 8:54 PM, Phillip J. Eby wrote: > > I created a "universal metaclass" in > > DecoratorTools whose sole function is to delegate metaclass __new__, > > __init__, and __call__ to class-level methods (e.g. __class_new__, > > __class_call__, etc.), thereby eliminating the need to have custom > > metaclasses for most use cases in the first place. Now, wherever possible, > > I use that single metaclass in my frameworks, so that there's no > need to mix > > them. > >easy_installed DecoratorTools and found it: classy_class. > >From the point of view of the code, this is a beautiful and elegant >snippet. However, suppose that from tomorrow everybody starts >using it. Since metaclasses would become so easy to use, possibly a >lot of people would take advantage of them. That was sort of the idea. ;-) > Then we would have >potentially complex (multiple) inheritance hierarchies with >chains of methods (_class__new__/_class__init__) calling >themselves cooperatively in the MRO. Would the resulting >code be readable? Readability's orthogonal. Some of them might be readable, some not. Depends on who's writing them. :) >How easy would be for an average framework user >to understand what is happening to his class? You're right, let's abolish inheritance, too, because then you might have to read more than one class to see what's happening. >I think class decorators would be a much better solution than >classy_class for most use cases Obviously, I disagree. :) You'll notice that DecoratorTools supports class decorators for Python 2.3 and up (actually, I think that particular bit worked in 2.2 as well). So, it's not the absence of class decorators that motivated the 'classy' mixin. >Generally speaking I like >more solutions bases on functional composition (as in WSGI >that you know very well) than on method cooperation. Rather than >improve the support for inheritance, I would like (in an ideal >world) to reduce it, to make easier the choice for people between >inheritance and alternatives (object composition, delegation, functional >composition). In the real world, I am content in documenting the >pitfalls of super, warn people about the dangers of complex >design involving multiple inheritance and cooperation, and suggest >alternatives. Naturally, if you can design a system to use delegates instead of class hierarchy to represent a chain of responsibility, it might well be an improvement. But there are tradeoffs, and no matter what you are going to end up coding chains of responsibility. Co-operative inheritance is a nice solution for chains of responsibility that can be expressed in a class hierarchy, and are no more "dangerous" than any other sort of chain of responsibility. In fact, they are in some ways less so since the patterns are likely to be better documented than anything you come up with on your own. From michele.simionato at gmail.com Fri Aug 29 06:44:24 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Fri, 29 Aug 2008 06:44:24 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <20080829042146.6DC123A408D@sparrow.telecommunity.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> Message-ID: <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> On Fri, Aug 29, 2008 at 6:22 AM, Phillip J. Eby wrote: > You're right, let's abolish inheritance, too, because then you might have to > read more than one class to see what's happening. You are joking, but I actually took this idea quite seriously. Once (four years ago or so) I did implement an object system from scratch in Scheme, completely without inheritance, to see how far it would go. It didn't go far, of course (nor I did expect it to go very far) but at least I learned exactly what (single) inheritance was good for. OTOH, for what concerns multiple inheritance, I am still not convinced it is really worth it. I mean, the MRO is beautiful, elegant and all that on paper, but on real-life code things as different, especially from the side of the users of frameworks heavily based on inheritance. > Naturally, if you can design a system to use delegates instead of class > hierarchy to represent a chain of responsibility, it might well be an > improvement. But there are tradeoffs, and no matter what you are going to > end up coding chains of responsibility. Agreed, it is all about tradeoffs. We have a different opinion on what a good tradeoff is in this case, but that's fine. I guess it depends on personal experience and the kind of code one has to work with. For instance I never had to integrated different frameworks using different metaclasses in my daily work, so I don't see a very strong case for classy_class over class decorators, but I could change my mind in the future, who knows? Anyway, It would be nice to have a good simple *real life* use case of cooperative inheritance not involving metaclasses, suitable for a beginners' tutorial about super, but I haven't found one yet :-( M.S. From mal at egenix.com Fri Aug 29 11:53:28 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 29 Aug 2008 11:53:28 +0200 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B6FD04.6080008@voidspace.org.uk> References: <48B6FD04.6080008@voidspace.org.uk> Message-ID: <48B7C718.7020802@egenix.com> On 2008-08-28 21:31, Michael Foord wrote: > Hello all, > > The documentation for __hash__ seems to be outdated. I'm happy to submit > a patch, so long as I am not misunderstanding something. > > http://docs.python.org/dev/reference/datamodel.html#object.__hash__ > > The documentation states: > > If a class does not define a __cmp__() or __eq__() method it should not > define a __hash__() operation either; if it defines __cmp__() or > __eq__() but not __hash__(), its instances will not be usable as > dictionary keys. If a class defines mutable objects and implements a > __cmp__() or __eq__() method, it should not implement __hash__(), since > the dictionary implementation requires that a key's hash value is > immutable (if the object's hash value changes, it will be in the wrong > hash bucket). > > > This may have been true for old style classes, but as new style classes > inherit a default __hash__ from object - mutable objects *will* be > usable as dictionary keys (hashed on identity) *unless* they implement a > __hash__ method that raises a type error. Being hashable is a different from being usable as dictionary key. Dictionaries perform the lookup based on the hash value, but will then have to check for hash collisions based on an equal comparison. If an object does not define an equal comparison, then it is not usable as dictionary key. > Shouldn't the advice be that classes that implement comparison methods > should always implement __hash__ (wasn't this nearly enforced?), It's probably a good idea to implement __hash__ for objects that implement comparisons, but it won't always work and it is certainly not needed, unless you intend to use them as dictionary keys. > and that mutable objects should raise a TypeError in __hash__. That's a good idea, even though it's not needed either ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 29 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From matt.giuca at gmail.com Fri Aug 29 13:03:22 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Fri, 29 Aug 2008 21:03:22 +1000 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B7C718.7020802@egenix.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> Message-ID: > Being hashable is a different from being usable as dictionary key. > > Dictionaries perform the lookup based on the hash value, but will > then have to check for hash collisions based on an equal comparison. > > If an object does not define an equal comparison, then it is not > usable as dictionary key. > But if an object defines *neither* __eq__ or __hash__, then by default it is usable as a dictionary key (using the id() of the object for both default equality and hashing, which is fine, and works for all user-defined types by default). An object defining __hash__ but not __eq__ is not problematic, since it still uses id() default for equality. (It just has potentially bad dictionary performance, if lots of things hash the same even though they aren't equal). This it not a problem by definition because *it is officially "okay" for two objects to hash the same, even if they aren't equal, though undesirable*. So all hashable objects are usable as dictionary keys, are they not? (As far as I know it isn't possible to have an object that does not have an equality comparison, unless you explicitly override __eq__ and have it raise a TypeError for some reason). It's probably a good idea to implement __hash__ for objects that > implement comparisons, but it won't always work and it is certainly > not needed, unless you intend to use them as dictionary keys. > But from what I know, it is a *bad* idea to implement __hash__ for any mutable object with non-reference equality (where equality depends on the mutable state), as an unbreakable rule. This is because if they are inserted into a dictionary, then mutated, they may suddenly be in the wrong bucket. This is why all the mutable types in Python with non-reference equality (eg. list, set, dict) are explicitly not hashable, while the immutable types (eg. tuple, frozenset, str) are hashable, and so are the mutable types with reference equality (eg. functions, user-defined classes by default). > > > and that mutable objects should raise a TypeError in __hash__. > > That's a good idea, even though it's not needed either ;-) > So I think my above "axioms" are a better (less restrictive, and still correct) rule than this one. It's OK for a mutable object to define __hash__, as long as its __eq__ doesn't depend upon its mutable state. For example, you can insert a function object into a dictionary, and mutate its closure, and it won't matter, because neither the hash nor the equality of the object is changing. It's only types like list and dict, with deep equality, where you run into this hash table problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Fri Aug 29 13:22:00 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 29 Aug 2008 12:22:00 +0100 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B7C718.7020802@egenix.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> Message-ID: <48B7DBD8.8070205@voidspace.org.uk> M.-A. Lemburg wrote: > On 2008-08-28 21:31, Michael Foord wrote: > >> Hello all, >> >> The documentation for __hash__ seems to be outdated. I'm happy to submit >> a patch, so long as I am not misunderstanding something. >> >> http://docs.python.org/dev/reference/datamodel.html#object.__hash__ >> >> The documentation states: >> >> If a class does not define a __cmp__() or __eq__() method it should not >> define a __hash__() operation either; if it defines __cmp__() or >> __eq__() but not __hash__(), its instances will not be usable as >> dictionary keys. If a class defines mutable objects and implements a >> __cmp__() or __eq__() method, it should not implement __hash__(), since >> the dictionary implementation requires that a key's hash value is >> immutable (if the object's hash value changes, it will be in the wrong >> hash bucket). >> >> >> This may have been true for old style classes, but as new style classes >> inherit a default __hash__ from object - mutable objects *will* be >> usable as dictionary keys (hashed on identity) *unless* they implement a >> __hash__ method that raises a type error. >> > > Being hashable is a different from being usable as dictionary key. > > Dictionaries perform the lookup based on the hash value, but will > then have to check for hash collisions based on an equal comparison. > > If an object does not define an equal comparison, then it is not > usable as dictionary key. > > >> Shouldn't the advice be that classes that implement comparison methods >> should always implement __hash__ (wasn't this nearly enforced?), >> > > It's probably a good idea to implement __hash__ for objects that > implement comparisons, but it won't always work and it is certainly > not needed, unless you intend to use them as dictionary keys. > > So you're suggesting that we document something like. Classes that represent mutable values and define equality methods are free to define __hash__ so long as you don't mind them being used incorrectly if treated as dictionary keys... Technically true, but not very helpful in my opinion... :-) Michael >> and that mutable objects should raise a TypeError in __hash__. >> > > That's a good idea, even though it's not needed either ;-) > > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From mal at egenix.com Fri Aug 29 14:43:11 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 29 Aug 2008 14:43:11 +0200 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> Message-ID: <48B7EEDF.70305@egenix.com> On 2008-08-29 13:03, Matt Giuca wrote: >> Being hashable is a different from being usable as dictionary key. >> >> Dictionaries perform the lookup based on the hash value, but will >> then have to check for hash collisions based on an equal comparison. >> >> If an object does not define an equal comparison, then it is not >> usable as dictionary key. >> > > But if an object defines *neither* __eq__ or __hash__, then by default it is > usable as a dictionary key (using the id() of the object for both default > equality and hashing, which is fine, and works for all user-defined types by > default). > > An object defining __hash__ but not __eq__ is not problematic, since it > still uses id() default for equality. (It just has potentially bad > dictionary performance, if lots of things hash the same even though they > aren't equal). This it not a problem by definition because *it is officially > "okay" for two objects to hash the same, even if they aren't equal, though > undesirable*. Note that only instances have the default hash value id(obj). This is not true in general. Most types don't implement the tp_hash slot and thus are not hashable. Indeed, mutable types should not implement that slot unless they know what they're doing :-) > So all hashable objects are usable as dictionary keys, are they not? (As far > as I know it isn't possible to have an object that does not have an equality > comparison, unless you explicitly override __eq__ and have it raise a > TypeError for some reason). Sorry, I wasn't clear enough: with "not defining an equal comparison" I meant that an equal comparison does not succeed, ie. raises an exception or returns Py_NotImplemented (at the C level). Due to the default of using the id(obj) as fallback for the equal comparison, this has to be explicitly coded for. If this is not the case (and that's probably the most common situation), then you're right: hashable implies usable as dictionary key. >> It's probably a good idea to implement __hash__ for objects that >> implement comparisons, but it won't always work and it is certainly >> not needed, unless you intend to use them as dictionary keys. >> > > But from what I know, it is a *bad* idea to implement __hash__ for any > mutable object with non-reference equality (where equality depends on the > mutable state), as an unbreakable rule. This is because if they are inserted > into a dictionary, then mutated, they may suddenly be in the wrong bucket. > This is why all the mutable types in Python with non-reference equality (eg. > list, set, dict) are explicitly not hashable, while the immutable types (eg. > tuple, frozenset, str) are hashable, and so are the mutable types with > reference equality (eg. functions, user-defined classes by default). Right. By implementing __hash__ in classes you have the explicit choice of either raising an exception or returning a useful hash value. Again, the situation is better at the C level, since types don't have a default tp_hash implementation, so have to explicitly code such a slot in order for hash(obj) to work. >>> and that mutable objects should raise a TypeError in __hash__. >> That's a good idea, even though it's not needed either ;-) >> > > So I think my above "axioms" are a better (less restrictive, and still > correct) rule than this one. It's OK for a mutable object to define > __hash__, as long as its __eq__ doesn't depend upon its mutable state. For > example, you can insert a function object into a dictionary, and mutate its > closure, and it won't matter, because neither the hash nor the equality of > the object is changing. It's only types like list and dict, with deep > equality, where you run into this hash table problem. I think the documentation needs to be changed to make the defaults explicit. The documentation should probably say: "If you implement __cmp__ or __eq__ on a class, also implement a __hash__ method (and either have it raise an exception or return a valid non-changing hash value for the object)." "If you implement __hash__ on classes, you should consider implementing __eq__ and/or __cmp__ as well, in order to control how dictionaries use your objects." In general, it's probably best to always implement both methods on classes, even if the application will just use one of them. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 29 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From matt.giuca at gmail.com Fri Aug 29 14:47:48 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Fri, 29 Aug 2008 22:47:48 +1000 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B7DBD8.8070205@voidspace.org.uk> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> Message-ID: > >> It's probably a good idea to implement __hash__ for objects that >> implement comparisons, but it won't always work and it is certainly >> not needed, unless you intend to use them as dictionary keys. >> >> >> > > > So you're suggesting that we document something like. > > Classes that represent mutable values and define equality methods are free > to define __hash__ so long as you don't mind them being used incorrectly if > treated as dictionary keys... > > Technically true, but not very helpful in my opinion... :-) No, I think he was suggesting we document that if a class overrides __eq__, it's a good idea to also implement __hash__, so it can be used as a dictionary key. However I have issues with this. First, he said: "It's probably a good idea to implement __hash__ for objects that implement comparisons, but it won't always work and it is certainly not needed, unless you intend to use them as dictionary keys." You can't say "certainly not needed unless you intend to use them as dictionary keys", since if you are defining an object, you never know when someone else will want to use them as a dict key (or in a set, mind!) So *if possible*, it is a good idea to implement __hash__ if you are implementing __eq__. But also, it needs to be very clear that if you *should not* implement __hash__ on a mutable object -- and it already is. So basically the docs should suggest that it is a good idea to implement __hash__ if you are implementing __eq__ on an immutable object. HOWEVER, There are two contradictory pieces of information in the docs. a) "if it defines __cmp__()or __eq__() but not __hash__(), its instances will not be usable as dictionary keys." versus b) "User-defined classes have __cmp__()and __hash__()methods by default; with them, all objects compare unequal and x.__hash__() returns id(x)." Note that these statements are somewhat contradictory: if a class has a __hash__ method by default (as b suggests), then it isn't possible to "not have a __hash__" (as suggested by a). In Python 2, statement (a) is true for old-style classes only, while statement (b) is true for new style classes only. This distinction needs to be made. (For old-style classes, it isn't the case that it has a __hash__ method by default - rather that the hash() function knows how to deal with objects without a __hash__ method, by calling id()). In Python 3, statement (a) is true always, while statement (b) is not (in fact just the same as old-style classes are in Python 2). So the Python 3 docs can get away with being simpler (without having to handle that weird case). I just saw Marc-Andre's new email come in; I'll look at that now. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.giuca at gmail.com Fri Aug 29 15:07:25 2008 From: matt.giuca at gmail.com (Matt Giuca) Date: Fri, 29 Aug 2008 23:07:25 +1000 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B7EEDF.70305@egenix.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7EEDF.70305@egenix.com> Message-ID: > Note that only instances have the default hash value id(obj). This > is not true in general. Most types don't implement the tp_hash > slot and thus are not hashable. Indeed, mutable types should not > implement that slot unless they know what they're doing :-) By "instances" you mean "instances of user-defined classes"? (I carefully avoid the term "instance" on its own, since I believe that was phased out when they merged types and classes; it probably still exists in the C API but shouldn't be mentioned in Python-facing documentation). But anyway, yes, we should make that distinction. Sorry, I wasn't clear enough: with "not defining an equal comparison" > I meant that an equal comparison does not succeed, ie. raises an > exception or returns Py_NotImplemented (at the C level). Oh OK. I didn't even realise it was "valid" or "usual" to explicitly block __eq__ like that. > Again, the situation is better at the C level, since types > don't have a default tp_hash implementation, so have to explicitly > code such a slot in order for hash(obj) to work. Yes but I gather that this "data model" document we are talking about is not designed for C authors, but Python authors, so it should be written for the point of view of people coding only in Python. (Only the "Extending and Embedding" and the "C API" documents are for C authors). The documentation should probably say: > > "If you implement __cmp__ or > __eq__ on a class, also implement a __hash__ method (and either > have it raise an exception or return a valid non-changing hash > value for the object)." > I agree, except maybe not for the Python 3 docs. As long as the behaviour I am observing is well-defined and not just a side-effect which could go away -- that is, if you define __eq__/__cmp__ but not __hash__, in a user-defined class, it raises a TypeError -- then I think it isn't necessary to recommend implementing a __hash__ method and raising a TypeError. Better just to leave as-is ("if it defines __cmp__()or __eq__()but not __hash__(), its instances will not be usable as dictionary keys") and clarify the later statement. > > "If you implement __hash__ on classes, you should consider implementing > __eq__ and/or __cmp__ as well, in order to control how dictionaries use > your objects." I don't think I agree with that. I'm not sure why you'd implement __hash__ without __eq__ and/or __cmp__, but it doesn't cause issues so we may as well not address it. > In general, it's probably best to always implement both methods > on classes, even if the application will just use one of them. > Well it certainly is for new-style classes in the 2.x branch. I don't think you should implement __hash__ in Python 3 if you just want a non-hashable object (since this is the default behaviour anyway). A lot of my opinion here, though, which doesn't count very much -- so I'm just making suggestions. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From python-3000-list at trentnelson.com Fri Aug 29 13:30:08 2008 From: python-3000-list at trentnelson.com (Trent Nelson) Date: Fri, 29 Aug 2008 11:30:08 +0000 Subject: [Python-Dev] [Python-3000] what version of bsddb to use/accept for 2.6/3.0 In-Reply-To: References: Message-ID: <20080829113008.GA29787@wind.teleri.net> On Sun, Aug 24, 2008 at 06:15:06PM -0700, Neal Norwitz wrote: > It looks like the WIndows buildbots use 4.4.20. Unfortunately, the > Windows bots aren't in great shape either. It won't be that hard to bump 3.0 on Windows to use 4.7 (assuming that the 3.0 bsddb codebase has Jesus's new code). I'll be able to take a look at this early next week. Trent. From ncoghlan at gmail.com Fri Aug 29 18:04:52 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 30 Aug 2008 02:04:52 +1000 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> Message-ID: <48B81E24.2070906@gmail.com> Matt Giuca wrote: > > > It's probably a good idea to implement __hash__ for objects that > implement comparisons, but it won't always work and it is certainly > not needed, unless you intend to use them as dictionary keys. > > > > > > So you're suggesting that we document something like. > > Classes that represent mutable values and define equality methods > are free to define __hash__ so long as you don't mind them being > used incorrectly if treated as dictionary keys... > > Technically true, but not very helpful in my opinion... :-) > > > No, I think he was suggesting we document that if a class overrides > __eq__, it's a good idea to also implement __hash__, so it can be used > as a dictionary key. I strongly advise people interested in this topic to take a closer look at the functionality that was added to address issue 2235. The "don't inherit __hash__" behaviour has been backported from 3.0 and broke a bunch of code, but the naive fix of reverting to the 2.5 behaviour proceeded to make the 2.6 version of collections.Hashable completely useless (since pretty much *everything* then claimed to be hashable, including all of the container types in the standard library). After thrashing out those problems, the 2.6 behaviour ended up being: - __hash__ is still inherited by default - you can block inheritance explicitly by setting "__hash__ = None" in the class definition or on the class object - for a class defined in C, you can block __hash__ inheritance by setting the tp_hash slot to PyObject_HashNotImplemented - using one of the above approaches will cause hash(obj) to raise a TypeError, as will calling the tp_hash slot directly - unlike defining your own __hash__ method, using one of the above techniques will also mean that isinstance(obj, collections.Hashable) will also return False - defining __eq__ and/or __cmp__ without defining __hash__ will lead to a Py3k Warning being raised on the class definition when run with the -3 switch The Python 3.0 behaviour is similar to the above, except that the unconditional inheritance of __hash__ is gone. If you define __eq__ or __cmp__ without defining __hash__, __hash__ will NOT be inherited from the parent class - instead, it will be set to None. The documentation of all of this could definitely use a bit more work - that's why I reopened 2235 in response to Michael's post. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From status at bugs.python.org Fri Aug 29 18:06:34 2008 From: status at bugs.python.org (Python tracker) Date: Fri, 29 Aug 2008 18:06:34 +0200 (CEST) Subject: [Python-Dev] Summary of Python tracker Issues Message-ID: <20080829160634.CBBD978357@psf.upfronthosting.co.za> ACTIVITY SUMMARY (08/22/08 - 08/29/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2029 open (+66) / 13524 closed (+16) / 15553 total (+82) Open issues with patches: 655 Average duration of open issues: 704 days. Median duration of open issues: 1760 days. Open Issues Breakdown open 2015 (+65) pending 14 ( +1) Issues Created Or Reopened (84) _______________________________ __eq__ / __hash__ check doesn't take inheritance into account 08/28/08 http://bugs.python.org/issue2235 reopened ncoghlan patch Objects/obmalloc.c:529: warning: comparison is always false due 08/24/08 http://bugs.python.org/issue3642 reopened christian.heimes 64bit IA5 Encoding should be in the default encodings 08/22/08 CLOSED http://bugs.python.org/issue3649 created pascal.bach Memory leak in bytes.split() 08/22/08 CLOSED http://bugs.python.org/issue3650 created amaury.forgeotdarc patch, needs review eval() leaks 1 reference every time 08/22/08 CLOSED http://bugs.python.org/issue3651 created amaury.forgeotdarc patch, needs review Remove DeprecationWarning in _warnings about 'line' 08/23/08 http://bugs.python.org/issue3652 created brett.cannon segfault calling sys.excepthook with non-Exception argument 08/23/08 CLOSED http://bugs.python.org/issue3653 created ajaksu2 patch, needs review Duplicated test name in regex test script 08/23/08 CLOSED http://bugs.python.org/issue3654 created mrabarnett latexwriter: \footnotemark can only take numbers as arguments 08/23/08 http://bugs.python.org/issue3655 created pv unicode encoding has lots of leaks of bytes 08/24/08 CLOSED http://bugs.python.org/issue3656 created nnorwitz pickle can pickle the wrong function 08/24/08 http://bugs.python.org/issue3657 created nnorwitz fix for pychecker property complaints 08/24/08 http://bugs.python.org/issue3658 created skip.montanaro patch, easy, needs review sqlite: enumeration value 'TYPE_STRING' not handled in switch 08/24/08 http://bugs.python.org/issue3659 created christian.heimes reference leaks in 3.0 08/24/08 http://bugs.python.org/issue3660 created nnorwitz patch sys.call_tracing segfaults 08/24/08 http://bugs.python.org/issue3661 created ajaksu2 _fileio._FileIO segfaults 08/24/08 CLOSED http://bugs.python.org/issue3662 created ajaksu2 needs review Extra DECREF on syntax errors 08/24/08 CLOSED http://bugs.python.org/issue3663 created amaury.forgeotdarc patch, needs review Pickler.dump from a badly initialized Pickler segfaults 08/24/08 http://bugs.python.org/issue3664 created ajaksu2 Support \u and \U escapes in regexes 08/24/08 http://bugs.python.org/issue3665 created georg.brandl patch atexit.register with bad input segfaults on exit 08/24/08 http://bugs.python.org/issue3666 created ajaksu2 Reloading an extension module always leaks 08/24/08 http://bugs.python.org/issue3667 created amaury.forgeotdarc patch, needs review "s*" argument parser marker leaks memory 08/24/08 http://bugs.python.org/issue3668 created amaury.forgeotdarc patch, needs review sqlite3.Connection.iterdump docs pythonicity 08/24/08 http://bugs.python.org/issue3669 created lehmannro patch Reporting bugs - no such sections 08/24/08 CLOSED http://bugs.python.org/issue3670 created kjohnson What's New in 2.6 - corrections 08/24/08 http://bugs.python.org/issue3671 created kjohnson Ill-formed surrogates not treated as errors during encoding/deco 08/24/08 http://bugs.python.org/issue3672 created Rhamphoryncus bsddb module leaks memory 08/25/08 http://bugs.python.org/issue3673 created nnorwitz patch, patch test_dbm_ndbm skip is unexpected on win32? 08/25/08 http://bugs.python.org/issue3674 created ocean-city patch Python 2.6 can't read sets pickled with Python 3.0 08/25/08 http://bugs.python.org/issue3675 created hagen patch Obsolete references to PEP 291 in py3k lib 08/25/08 http://bugs.python.org/issue3676 created orent importing from UNC roots doesn't work 08/25/08 http://bugs.python.org/issue3677 created krisvale Ignored LDFLAGS during linking libpython$(VERSION).so 08/25/08 http://bugs.python.org/issue3678 created Arfrever patch, easy, needs review pressing HOME key in IDLE editor ends IDLE 08/25/08 http://bugs.python.org/issue3679 created tjd Cycles with some iterator are leaking. 08/25/08 http://bugs.python.org/issue3680 created schuppenies patch Cannot read saved csv file in a single run 08/25/08 http://bugs.python.org/issue3681 created paul test_math: math.log(-ninf) fails to raise exception on OpenBSD 08/26/08 http://bugs.python.org/issue3682 created djmdjm compilation --without-threads fails 08/26/08 http://bugs.python.org/issue3683 created djmdjm needs review traceback.format_exception_only() misplaces the caret for certai 08/26/08 http://bugs.python.org/issue3684 created brodierao patch Crash while compiling Python 3000 in OpenBSD 4.4 08/26/08 http://bugs.python.org/issue3685 created henry.precheur patch PKG-INFO file should differentiate between authors and maintaine 08/26/08 http://bugs.python.org/issue3686 created lemburg Popen() object stdout attribute reassignment behaviour 08/26/08 http://bugs.python.org/issue3687 created vincent.legoll open() rejects bytes as filename 08/26/08 CLOSED http://bugs.python.org/issue3688 created dlitz listreverseiterator has a decreasing len() 08/26/08 http://bugs.python.org/issue3689 created laxrulz777 sys.getsizeof wrong for Py3k bool objects 08/26/08 http://bugs.python.org/issue3690 created schuppenies patch Incorrect variable reference 08/26/08 CLOSED http://bugs.python.org/issue3691 created timh improper scope in list comprehension, when used in class declara 08/26/08 CLOSED http://bugs.python.org/issue3692 created kaizhu Obscure array.array error message 08/27/08 http://bugs.python.org/issue3693 created tjreedy Undetected error in _struct.pack_into 08/27/08 http://bugs.python.org/issue3694 created ajaksu2 patch Source tarball for Sphinx 0.4.3 missing 08/27/08 http://bugs.python.org/issue3695 created hircus Error parsing arguments on OpenBSD <= 4.4 08/27/08 http://bugs.python.org/issue3696 created henry.precheur patch, needs review "Fatal Python error: Cannot recover from stack overflow" on Wind 08/27/08 http://bugs.python.org/issue3697 created pitrou patch, needs review incompatible arguments in warning formatting for idle 08/27/08 http://bugs.python.org/issue3698 created gcoffin test_bigaddrspace broken 08/27/08 http://bugs.python.org/issue3699 created pitrou test_bigmem broken 08/27/08 http://bugs.python.org/issue3700 created pitrou test_ntpath.test_relpath fails when launched from a different Wi 08/27/08 http://bugs.python.org/issue3701 created pitrou test_urllib2.test_trivial fails when run from another Windows dr 08/27/08 http://bugs.python.org/issue3702 created pitrou open() on directory raises IOError with unhelpful message 08/27/08 http://bugs.python.org/issue3703 created hagen patch, needs review cookielib doesn't handle URLs with / in parameters 08/27/08 http://bugs.python.org/issue3704 created andyk patch, needs review py3k aborts if "-c" or "-m" is given a non-ascii value 08/27/08 http://bugs.python.org/issue3705 created pitrou patch, needs review Fix error message for wrong exec() argument type 08/27/08 CLOSED http://bugs.python.org/issue3706 created georg.brandl patch, patch, needs review help('finally') behaves bizarrely 08/27/08 http://bugs.python.org/issue3707 created ms patch, easy, needs review os.urandom(1.1): infinite loop 08/27/08 http://bugs.python.org/issue3708 created ajaksu2 patch, easy, needs review BaseHTTPRequestHandler innefficient when sending HTTP header 08/27/08 http://bugs.python.org/issue3709 created yangman Reference leak in thread._local 08/28/08 http://bugs.python.org/issue3710 created tamino patch docs still say to use .dll for compiled extensions 08/28/08 CLOSED http://bugs.python.org/issue3711 created gagenellina patch memoryview leaks references 08/28/08 http://bugs.python.org/issue3712 created amaury.forgeotdarc patch, needs review Compile warning for Objects/stringlib 08/28/08 CLOSED http://bugs.python.org/issue3713 created kirkshorts patch nntplib module broken by str to unicode conversion 08/28/08 http://bugs.python.org/issue3714 created hdima patch hashlib's docstring throws exception in pydoc 08/28/08 http://bugs.python.org/issue3715 created erickt mistake in 3.4.2 Customizing attribute access 08/28/08 http://bugs.python.org/issue3716 created Alex7564 Py_InitModule* is still referenced in docs 08/28/08 http://bugs.python.org/issue3717 created erickt environment variable MACHDEP and python build system 08/28/08 http://bugs.python.org/issue3718 created rpetrov patch platform.py: _syscmd_file() can't handle target path with space 08/29/08 http://bugs.python.org/issue3719 created jfdp segfault in for loop with evil iterator 08/29/08 http://bugs.python.org/issue3720 created gideon patch, needs review invalid literal for int() with base 16: '' 08/29/08 http://bugs.python.org/issue3721 created xhomol11 print followed by exception eats print with doctest 08/29/08 http://bugs.python.org/issue3722 created cjw296 Py_NewInterpreter does not work 08/29/08 http://bugs.python.org/issue3723 created amaury.forgeotdarc math.log(x, 10) gives different result than math.log10(x) 08/29/08 http://bugs.python.org/issue3724 created segfaulthunter patch telnetlib module broken by str to unicode conversion 08/29/08 http://bugs.python.org/issue3725 created hdima Allow ',' delimiters in logging.config.fileConfig() 08/29/08 http://bugs.python.org/issue3726 created wcmaier patch poplib module broken by str to unicode conversion 08/29/08 http://bugs.python.org/issue3727 created hdima imaplib module broken by str to unicode conversion 08/29/08 CLOSED http://bugs.python.org/issue3728 created hdima SystemError on calling len() if __len__() doesn't return an int 08/29/08 http://bugs.python.org/issue3729 created hagen patch Update BaseHTTPServer docs 08/29/08 http://bugs.python.org/issue3730 created catlee Issues Now Closed (35) ______________________ LookupError: unknown encoding: X-MAC-JAPANESE 317 days http://bugs.python.org/issue1276 lemburg patch Error using >>> from OpenGL.GLUT import * 301 days http://bugs.python.org/issue1346 igorcamp Using __(get|set|del)slice__ needs a Py3K warning 160 days http://bugs.python.org/issue2351 benjamin.peterson patch, needs review Fixer to handle new places where parentheses are needed 158 days http://bugs.python.org/issue2367 benjamin.peterson patch, 26backport bytes() should respect __bytes__ 161 days http://bugs.python.org/issue2415 benjamin.peterson patch, needs review urllib2 can't handle http://www.wikispaces.com 157 days http://bugs.python.org/issue2464 orsenthil patch Restore isinstance and issubclass speed in 2.6 147 days http://bugs.python.org/issue2534 pitrou patch, patch, needs review Locking should be removed from the new buffer protocol 80 days http://bugs.python.org/issue3046 teoliphant patch bytearrays are not thread safe 66 days http://bugs.python.org/issue3139 pitrou patch multiprocessing build fails on Solaris 10 68 days http://bugs.python.org/issue3149 pitrou 2to3 Fix_imports optimization 59 days http://bugs.python.org/issue3218 benjamin.peterson patch invalid call to PyMem_Free() in fileio_init() 49 days http://bugs.python.org/issue3304 nnorwitz patch, easy making partial functions comparable 7 days http://bugs.python.org/issue3564 tjreedy SPAM 5 days http://bugs.python.org/issue3579 tjreedy invalid exception context 8 days http://bugs.python.org/issue3611 amaury.forgeotdarc patch, needs review shutil.rmtree() fails on invalid filename 8 days http://bugs.python.org/issue3616 pitrou test issues on 64bit windows 2 days http://bugs.python.org/issue3625 mhammond patch, patch, 64bit apple security patches need to be forward ported to py3k 3 days http://bugs.python.org/issue3627 nnorwitz Add more checks to testcapi 2 days http://bugs.python.org/issue3643 benjamin.peterson patch IA5 Encoding should be in the default encodings 3 days http://bugs.python.org/issue3649 pascal.bach Memory leak in bytes.split() 0 days http://bugs.python.org/issue3650 amaury.forgeotdarc patch, needs review eval() leaks 1 reference every time 4 days http://bugs.python.org/issue3651 benjamin.peterson patch, needs review segfault calling sys.excepthook with non-Exception argument 1 days http://bugs.python.org/issue3653 benjamin.peterson patch, needs review Duplicated test name in regex test script 1 days http://bugs.python.org/issue3654 georg.brandl unicode encoding has lots of leaks of bytes 0 days http://bugs.python.org/issue3656 amaury.forgeotdarc _fileio._FileIO segfaults 0 days http://bugs.python.org/issue3662 nnorwitz needs review Extra DECREF on syntax errors 2 days http://bugs.python.org/issue3663 pitrou patch, needs review Reporting bugs - no such sections 0 days http://bugs.python.org/issue3670 kjohnson open() rejects bytes as filename 0 days http://bugs.python.org/issue3688 amaury.forgeotdarc Incorrect variable reference 0 days http://bugs.python.org/issue3691 benjamin.peterson improper scope in list comprehension, when used in class declara 0 days http://bugs.python.org/issue3692 georg.brandl Fix error message for wrong exec() argument type 0 days http://bugs.python.org/issue3706 georg.brandl patch, patch, needs review docs still say to use .dll for compiled extensions 0 days http://bugs.python.org/issue3711 georg.brandl patch Compile warning for Objects/stringlib 0 days http://bugs.python.org/issue3713 christian.heimes patch imaplib module broken by str to unicode conversion 0 days http://bugs.python.org/issue3728 hdima Top Issues Most Discussed (10) ______________________________ 23 eval() leaks 1 reference every time 4 days closed http://bugs.python.org/issue3651 10 "s*" argument parser marker leaks memory 5 days open http://bugs.python.org/issue3668 9 import of site.py fails on startup 57 days open http://bugs.python.org/issue3279 8 Restore isinstance and issubclass speed in 2.6 147 days closed http://bugs.python.org/issue2534 7 Error parsing arguments on OpenBSD <= 4.4 2 days open http://bugs.python.org/issue3696 7 IA5 Encoding should be in the default encodings 3 days closed http://bugs.python.org/issue3649 6 os.urandom(1.1): infinite loop 2 days open http://bugs.python.org/issue3708 6 Objects/obmalloc.c:529: warning: comparison is always false due 5 days open http://bugs.python.org/issue3642 6 test_cpickle crash on AMD64 Windows build 8 days open http://bugs.python.org/issue3640 6 python3.0 interpreter on Cygwin ignores all arguments 8 days open http://bugs.python.org/issue3626 From ncoghlan at gmail.com Fri Aug 29 18:15:20 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 30 Aug 2008 02:15:20 +1000 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <20080827031445.C9B8B3A4079@sparrow.telecommunity.com> <4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> Message-ID: <48B82098.8090106@gmail.com> Michele Simionato wrote: > OTOH, for what concerns multiple inheritance, I am still not > convinced it is really worth it. I mean, the MRO is beautiful, > elegant and all that on paper, but on real-life code things as different, > especially from the side of the users of frameworks heavily > based on inheritance. The mixin methods in the ABC machinery would be a lot less useful without multiple inheritance (and the collections ABCs would be a whole lot harder to define and to write). So if you're looking for use cases for multiple inheritance, I'd suggest starting with the Python 2.6 collections module and seeing how you would go about rewriting it using only single inheritance. I believe the new io module is also fairly dependent on multiple inheritance. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From michele.simionato at gmail.com Fri Aug 29 19:46:36 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Fri, 29 Aug 2008 19:46:36 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <48B82098.8090106@gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> <48B82098.8090106@gmail.com> Message-ID: <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com> On Fri, Aug 29, 2008 at 6:15 PM, Nick Coghlan wrote: > The mixin methods in the ABC machinery would be a lot less useful > without multiple inheritance (and the collections ABCs would be a whole > lot harder to define and to write). > > So if you're looking for use cases for multiple inheritance, I'd suggest > starting with the Python 2.6 collections module and seeing how you would > go about rewriting it using only single inheritance. I believe the new > io module is also fairly dependent on multiple inheritance. I am very well aware of the collection module and the ABC mechanism. However, you are missing that mixins can be implemented in a single-inheritance world without the complications of the MRO. See my answer to Alex Martelli in this same thread. From casey at pandora.com Fri Aug 29 20:33:35 2008 From: casey at pandora.com (Casey Duncan) Date: Fri, 29 Aug 2008 12:33:35 -0600 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> <48B82098.8090106@gmail.com> <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com> Message-ID: <5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> On Aug 29, 2008, at 11:46 AM, Michele Simionato wrote: > On Fri, Aug 29, 2008 at 6:15 PM, Nick Coghlan > wrote: >> The mixin methods in the ABC machinery would be a lot less useful >> without multiple inheritance (and the collections ABCs would be a >> whole >> lot harder to define and to write). >> >> So if you're looking for use cases for multiple inheritance, I'd >> suggest >> starting with the Python 2.6 collections module and seeing how you >> would >> go about rewriting it using only single inheritance. I believe the >> new >> io module is also fairly dependent on multiple inheritance. > > I am very well aware of the collection module and the ABC mechanism. > However, you are missing that mixins can be implemented in a single- > inheritance > world without the complications of the MRO. See my answer to Alex > Martelli in this same thread. As interesting as this conversation is at a meta-level, I'm not sure how much more can be accomplished here by debating the merits of multiple vs. single inheritance. Unfortunately I think this is a case where there is not just one good way to do it in all cases, especially given the subjective nature of "good" in this context. This is what I take away from this: - super() is tricky to use at best, and its documentation is inaccurate and incomplete. I think it should also be made more clear that super() is really mostly useful for framework developers, including users extending frameworks. Unfortunately many frameworks require you to extend them in order to write useful applications in my experience, so it trickles down to the app developer at times. In short, more correct documentation == good. - The difficulties of super() are really symptomatic of the difficulties of multiple inheritance. I think it's clear that multiple inheritance is here to stay in Python, and it solves certain classes of problems quite well. But, it requires careful consideration, and it's easy to get carried away and create a huge mess (ala Zope2, which I am all too familiar), and it can hinder code clarity as much as it facilitates reuse. - There are good alternatives to multiple inheritance for many cases, but there are cases where multiple inheritance is arguably best. Traits are a possible alternative that deserve further study. I think that study would be greatly aided by a 3rd-party library implementing traits for Python. If traits are to gain any traction or ever be considered for inclusion into the language such a library would need to exist first and demonstrate its utility. I know I'm probably just stating the obvious here, but I found it therapeutic ;^) -Casey From glyph at divmod.com Fri Aug 29 22:31:07 2008 From: glyph at divmod.com (glyph at divmod.com) Date: Fri, 29 Aug 2008 20:31:07 -0000 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> <48B82098.8090106@gmail.com> <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com> <5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> Message-ID: <20080829203107.25821.320776057.divmod.xquotient.15101@joule.divmod.com> On 06:33 pm, casey at pandora.com wrote: >On Aug 29, 2008, at 11:46 AM, Michele Simionato wrote: >>On Fri, Aug 29, 2008 at 6:15 PM, Nick Coghlan >>wrote: >>I am very well aware of the collection module and the ABC mechanism. >>However, you are missing that mixins can be implemented in a single- >>inheritance >>world without the complications of the MRO. See my answer to Alex >>Martelli in this same thread. >- super() is tricky to use at best, and its documentation is >inaccurate and incomplete. I think it should also be made more clear >that super() is really mostly useful for framework developers, >including users extending frameworks. Unfortunately many frameworks >require you to extend them in order to write useful applications in my >experience, so it trickles down to the app developer at times. In >short, more correct documentation == good. >I know I'm probably just stating the obvious here, but I found it >therapeutic ;^) I think this is a problem with this topic. Everyone writing about super() seems to be not just clearing up the documentation issues that surround it, but venting from personal frustrations with using it as well. I confess that I have done the same - if not in widely-publicized articles, at least on IRC and mailing list posts. I think it would benefit everyone if this discussion would end up with some patches to the library documentation that documented the semantics of super() more completely in the reference documentation and the "multiple inheritance" area of the tutorial, so that when people *do* run in to difficulties there is a very clear, central explanation of what it's supposed to do. Personally I think the thing that really should be pointed out is that it may behave in a confusing manner if the signature of the method being invoked is not the same on all classes in the same inheritance hierarchy. Theoretical problems aside, 99% of the trouble I've had with super() has to do with __init__ methods. I'll try my hand at such a patch over the weekend, but I'd be grateful for some pointers on a "quick start" for that. I am a complete newb at modifying the official documentation, and I seem to recall from a prior (failed) attempt that the tools are a bit difficult to work with. From python at rcn.com Fri Aug 29 22:39:39 2008 From: python at rcn.com (Raymond Hettinger) Date: Fri, 29 Aug 2008 13:39:39 -0700 Subject: [Python-Dev] Things to Know About Super References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com><4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com><20080828152941.CD4E43A410E@sparrow.telecommunity.com><4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com><20080828185312.943163A408D@sparrow.telecommunity.com><4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com><20080829042146.6DC123A408D@sparrow.telecommunity.com><4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com><48B82098.8090106@gmail.com><4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com><5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> <20080829203107.25821.320776057.divmod.xquotient.15101@joule.divmod.com> Message-ID: <23438612C5C6482F89B23B262ECE4259@RaymondLaptop1> From: > I think it would benefit everyone if this discussion would end up with > some patches to the library documentation that documented the semantics > of super() more completely in the reference documentation and the > "multiple inheritance" area of the tutorial, so that when people *do* > run in to difficulties there is a very clear, central explanation of > what it's supposed to do. Am working on a doc patch, will post this weekend. Raymond From michele.simionato at gmail.com Sat Aug 30 06:16:15 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Sat, 30 Aug 2008 06:16:15 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <20080828152941.CD4E43A410E@sparrow.telecommunity.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> <48B82098.8090106@gmail.com> <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com> <5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> Message-ID: <4edc17eb0808292116q39763348g162b8f90787e8e6c@mail.gmail.com> On Fri, Aug 29, 2008 at 8:33 PM, Casey Duncan wrote: > - There are good alternatives to multiple inheritance for many cases, but > there are cases where multiple inheritance is arguably best. Maybe, but I am still biased in the opposite direction ;) >Traits are a > possible alternative that deserve further study. I think that study would be > greatly aided by a 3rd-party library implementing traits for Python. If > traits are to gain any traction or ever be considered for inclusion into the > language such a library would need to exist first and demonstrate its > utility. I wrote a trait library which I plan to release soon or later. However it is intended as a proof of concept, not as a candidate for inclusion in the standard library. As of now, I don't think we should have a different way of doing mixins in the standard library. There should be only one obvious way and the obvious way in current Python is multiple inheritance as it is now. The proof of concept is important for educational purposes, to open the mind to alternatives, to give inspiration to the creators of new languages: it is not intended to add complication (whenever small) to current Python. Having said that, maybe once I release the library people will start using it in production and will ask for inclusion for the standard library, but this is not my goal now. This happened for my decorator module years ago: when I wrote it I did not expect people to use it, I saw it as a temporary hack until we got a better support for fiddling with function signatures in the standard library. Nevertheless now a lot of people are using it and I am not even sure it is a good thing (I have seen many decorator abuses out there). This the strange thing that happens when you release a library: you will never now what people will end up using it for ;) Michele Simionato From michal at yogi.htu.tuwien.ac.at Sat Aug 30 12:04:41 2008 From: michal at yogi.htu.tuwien.ac.at (Michal Revucky) Date: Sat, 30 Aug 2008 12:04:41 +0200 Subject: [Python-Dev] script containing all opcs Message-ID: <20080830100441.GC29943@yogi> hello everyone, i would like to get a python script which executes all interpreter's opcodes, or how am i supposed to create such script... i just need to make sure that all opcodes (as defined in Include/opcode.h) are executed by this scrip i need this script for testing purposes while rewritting the python's ceval.c code... bye michal From g.brandl at gmx.net Sat Aug 30 15:15:09 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Sat, 30 Aug 2008 15:15:09 +0200 Subject: [Python-Dev] script containing all opcs In-Reply-To: <20080830100441.GC29943@yogi> References: <20080830100441.GC29943@yogi> Message-ID: Michal Revucky schrieb: > hello everyone, > > i would like to get a python script which executes all interpreter's opcodes, or > how am i supposed to create such script... i just need to make sure that all > opcodes (as defined in Include/opcode.h) are executed by this scrip > i need this script for testing purposes while rewritting the python's ceval.c > code... This question might better suit comp.lang.python, but nevertheless: The opcodes are quite well documented, in the documentation of the "dis" module. Many of them serve a specific purpose (like implementing `x[y]` or `raise x`) and should therefore be easy to test. For the others, like ROT_TWO, you'll need to look into Python/compile.c to find out in which cases they are generated. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From ondrej at certik.cz Sat Aug 30 20:41:30 2008 From: ondrej at certik.cz (Ondrej Certik) Date: Sat, 30 Aug 2008 20:41:30 +0200 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <48B81E24.2070906@gmail.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> <48B81E24.2070906@gmail.com> Message-ID: <85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com> > I strongly advise people interested in this topic to take a closer look > at the functionality that was added to address issue 2235. The "don't > inherit __hash__" behaviour has been backported from 3.0 and broke a > bunch of code, but the naive fix of reverting to the 2.5 behaviour > proceeded to make the 2.6 version of collections.Hashable completely > useless (since pretty much *everything* then claimed to be hashable, > including all of the container types in the standard library). > > After thrashing out those problems, the 2.6 behaviour ended up being: > - __hash__ is still inherited by default > - you can block inheritance explicitly by setting "__hash__ = None" in > the class definition or on the class object > - for a class defined in C, you can block __hash__ inheritance by > setting the tp_hash slot to PyObject_HashNotImplemented > - using one of the above approaches will cause hash(obj) to raise a > TypeError, as will calling the tp_hash slot directly > - unlike defining your own __hash__ method, using one of the above > techniques will also mean that isinstance(obj, collections.Hashable) > will also return False > - defining __eq__ and/or __cmp__ without defining __hash__ will lead to > a Py3k Warning being raised on the class definition when run with the -3 > switch > > The Python 3.0 behaviour is similar to the above, except that the > unconditional inheritance of __hash__ is gone. If you define __eq__ or > __cmp__ without defining __hash__, __hash__ will NOT be inherited from > the parent class - instead, it will be set to None. > > The documentation of all of this could definitely use a bit more work - > that's why I reopened 2235 in response to Michael's post. Couple months ago I was trying to figure out how __eq__, __cmp__, __hash__ and similar methods are called in Python and in which order and wrote a docs here: http://docs.sympy.org/python-comparisons.html Feel free to reuse any of it. I wrote it to myself, as I didn't find the official docs very clear. Ondrej From jnoller at gmail.com Sat Aug 30 21:13:32 2008 From: jnoller at gmail.com (Jesse Noller) Date: Sat, 30 Aug 2008 15:13:32 -0400 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> <48B81E24.2070906@gmail.com> <85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com> Message-ID: <9AE6735E-45F6-4A66-B749-1DB7A3D39EA3@gmail.com> On Aug 30, 2008, at 2:41 PM, "Ondrej Certik" wrote: >> I strongly advise people interested in this topic to take a closer >> look >> at the functionality that was added to address issue 2235. The "don't >> inherit __hash__" behaviour has been backported from 3.0 and broke a >> bunch of code, but the naive fix of reverting to the 2.5 behaviour >> proceeded to make the 2.6 version of collections.Hashable completely >> useless (since pretty much *everything* then claimed to be hashable, >> including all of the container types in the standard library). >> >> After thrashing out those problems, the 2.6 behaviour ended up being: >> - __hash__ is still inherited by default >> - you can block inheritance explicitly by setting "__hash__ = None" >> in >> the class definition or on the class object >> - for a class defined in C, you can block __hash__ inheritance by >> setting the tp_hash slot to PyObject_HashNotImplemented >> - using one of the above approaches will cause hash(obj) to raise a >> TypeError, as will calling the tp_hash slot directly >> - unlike defining your own __hash__ method, using one of the above >> techniques will also mean that isinstance(obj, collections.Hashable) >> will also return False >> - defining __eq__ and/or __cmp__ without defining __hash__ will >> lead to >> a Py3k Warning being raised on the class definition when run with >> the -3 >> switch >> >> The Python 3.0 behaviour is similar to the above, except that the >> unconditional inheritance of __hash__ is gone. If you define __eq__ >> or >> __cmp__ without defining __hash__, __hash__ will NOT be inherited >> from >> the parent class - instead, it will be set to None. >> >> The documentation of all of this could definitely use a bit more >> work - >> that's why I reopened 2235 in response to Michael's post. > > Couple months ago I was trying to figure out how __eq__, __cmp__, > __hash__ and similar methods are called in Python and in which order > and wrote a docs here: > > http://docs.sympy.org/python-comparisons.html > > Feel free to reuse any of it. I wrote it to myself, as I didn't find > the official docs very clear. > > Ondrej Ondrej, a patch that improves the official docs would be welcome and still potentially make 2.6/3.0 From ondrej at certik.cz Sat Aug 30 21:35:21 2008 From: ondrej at certik.cz (Ondrej Certik) Date: Sat, 30 Aug 2008 21:35:21 +0200 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <9AE6735E-45F6-4A66-B749-1DB7A3D39EA3@gmail.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> <48B81E24.2070906@gmail.com> <85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com> <9AE6735E-45F6-4A66-B749-1DB7A3D39EA3@gmail.com> Message-ID: <85b5c3130808301235t7ce79662t767c2831e736d808@mail.gmail.com> >> Ondrej > > Ondrej, a patch that improves the official docs would be welcome and still > potentially make 2.6/3.0 That'd be awesome. I need to finish my thesis in the next couple days, so I'd welcome if anyone could just take it and put usefult things in. I could get to do it the next week the earliest. Ondrej From solipsis at pitrou.net Sat Aug 30 22:06:00 2008 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 30 Aug 2008 20:06:00 +0000 (UTC) Subject: [Python-Dev] The recursion checking problem Message-ID: Hi, I was working on a recursion overflow checking bug (http://bugs.python.org/issue2548) and, while I've managed to produce a working patch, I've also become uncomfortable with the very idea of trying to plug all those holes just for the sake of plugging them. I'll try to explain why, by describing the conflicting factors I've identified: - more and more, we are adding calls to Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() all over the interpreter, to avoid special/obscure cases of undetected infinite recursion; this can probably be considered a good thing, but: - after a recursion error has been raised (technically a RuntimeError), usually some code has to do cleanup after noticing the exception; this cleanup now can very easily bump into the recursion limit again, due to the point mentioned above (the funniest example of this is PyErr_ExceptionMatches, which makes a call to PyObject_IsSubclass which itself increases the recursion count because __subclasscheck__ can be recursively invoked...). - to counter the latter problem, py3k has introduced a somewhat smarter mechanism (which I've tracked down to a commit in the defunct p3yk branch by Martin): when the recursion limit is exceeded, a special flag named "overflowed" is set in the thread state structure which disables the primary recursion check, so that cleanup code has a bit of room to increase the recursion count a bit. A secondary recursion check exists (equal to the primary one /plus/ 50) and, if it is reached, the interpreter aborts with a fatal error. The "overflowed" flag is cleared when the recursion count drops below the primary recursion limit /minus/ 50. Now it looks rather smart but: - unfortunately, some functions inside the interpreter discard every exception by design. The primary example is PyDict_GetItem(), which is certainly used quite a lot :-)... When PyDict_GetItem() returns NULL, the caller can only assume that the key isn't in the dict, it has no way to know that there was a critical problem due to a recursion overflow. I encountered the latter problem when trying to backport the py3k recursion overflow algorithm to trunk. A fatal error suddenly appeared in test_cpickle, and it turned out that the recursion count was exceeded in PyObject_RichCompare(), the error was then cleared in PyDict_GetItem(), but the "overflowed" flag was still set so that a subsequent recursion overflow would trigger the secondary check and lead to the fatal error. I guess that, if it doesn't happen in py3k, it's just by chance: the recursion overflow is probably happening at another point where errors don't get discarded. Indeed, the failure I got on trunk was manifesting itself when running "regrtest.py test_cpickle" but not directly "test_cpickle.py"... which shows how delicate the recursion mechanism has become. My attempt to solve the latter problem while still backporting the py3k scheme involves clearing the "overflowed" flag in PyErr_Clear(). This makes all tests pass ok, but also means the "overflowed" flag loses a lot of its meaning... since PyErr_Clear() is called in a lot of places (and, especially, in PyDict_GetItem()). Also, at this point I fear that the solution to the problem is becoming, because of its complexity, perhaps worse than the problem itself. That's why I'm bringing it here, to have your opinion. (I also suggest that we stop trying to fix recursion checking bugs until the stable release, so as to give us some time to do the Right Thing later - if there is such a thing) Regards Antoine. From brett at python.org Sat Aug 30 22:29:12 2008 From: brett at python.org (Brett Cannon) Date: Sat, 30 Aug 2008 13:29:12 -0700 Subject: [Python-Dev] The recursion checking problem In-Reply-To: References: Message-ID: On Sat, Aug 30, 2008 at 1:06 PM, Antoine Pitrou wrote: > > Hi, > > I was working on a recursion overflow checking bug > (http://bugs.python.org/issue2548) and, while I've managed to produce a working > patch, I've also become uncomfortable with the very idea of trying to plug all > those holes just for the sake of plugging them. I'll try to explain why, by > describing the conflicting factors I've identified: > > - more and more, we are adding calls to Py_EnterRecursiveCall() and > Py_LeaveRecursiveCall() all over the interpreter, to avoid special/obscure > cases of undetected infinite recursion; this can probably be considered a good > thing, but: > > - after a recursion error has been raised (technically a RuntimeError), usually > some code has to do cleanup after noticing the exception; this cleanup now can > very easily bump into the recursion limit again, due to the point mentioned > above (the funniest example of this is PyErr_ExceptionMatches, which makes a > call to PyObject_IsSubclass which itself increases the recursion count because > __subclasscheck__ can be recursively invoked...). > > - to counter the latter problem, py3k has introduced a somewhat smarter > mechanism (which I've tracked down to a commit in the defunct p3yk branch by > Martin): when the recursion limit is exceeded, a special flag named > "overflowed" is set in the thread state structure which disables the primary > recursion check, so that cleanup code has a bit of room to increase the > recursion count a bit. A secondary recursion check exists (equal to the primary > one /plus/ 50) and, if it is reached, the interpreter aborts with a fatal error. > The "overflowed" flag is cleared when the recursion count drops below the > primary recursion limit /minus/ 50. Now it looks rather smart but: > > - unfortunately, some functions inside the interpreter discard every exception > by design. The primary example is PyDict_GetItem(), which is certainly used > quite a lot :-)... When PyDict_GetItem() returns NULL, the caller can only > assume that the key isn't in the dict, it has no way to know that there was a > critical problem due to a recursion overflow. > As the comment says for PyDict_GetItem(), it's a relic from the days when there was no way to call Python code when making the call. That is no longer true (and is probably true for a lot of places where a similar assumption is made). > I encountered the latter problem when trying to backport the py3k recursion > overflow algorithm to trunk. A fatal error suddenly appeared in test_cpickle, > and it turned out that the recursion count was exceeded in > PyObject_RichCompare(), the error was then cleared in PyDict_GetItem(), but the > "overflowed" flag was still set so that a subsequent recursion overflow would > trigger the secondary check and lead to the fatal error. > > I guess that, if it doesn't happen in py3k, it's just by chance: the recursion > overflow is probably happening at another point where errors don't get > discarded. Indeed, the failure I got on trunk was manifesting itself when > running "regrtest.py test_cpickle" but not directly "test_cpickle.py"... which > shows how delicate the recursion mechanism has become. > > My attempt to solve the latter problem while still backporting the py3k scheme > involves clearing the "overflowed" flag in PyErr_Clear(). This makes all tests > pass ok, but also means the "overflowed" flag loses a lot of its meaning... > since PyErr_Clear() is called in a lot of places (and, especially, in > PyDict_GetItem()). > > > Also, at this point I fear that the solution to the problem is becoming, > because of its complexity, perhaps worse than the problem itself. That's why > I'm bringing it here, to have your opinion. > Well, For Py3K at least we might need to consider going through the C API and fixing it so that these incorrect assumptions that functions like PyDict_GetItem() make are no longer made by introducing some new functions that behave in a "better" way. And for the recursion issue, I think it stems from corners that are cut in the C API by us. We inline functions all over the place, assume that Python's implementation underneath the hood is going to make calls that stay in C, etc. But as time has gone on and we have added flexibility to Python, more and more places have a chance to call Python code and trigger issues. > (I also suggest that we stop trying to fix recursion checking bugs until the > stable release, so as to give us some time to do the Right Thing later - if > there is such a thing) > I have no problem punting for now; there is no way I would be willing to wager any amount of money that the recursion check covered all cases. I have always viewed the check as a bonus sanity check, but not something to heavily rely upon. -Brett From stephane at harobed.org Sat Aug 30 22:30:54 2008 From: stephane at harobed.org (=?iso-8859-1?q?KLEIN_St=E9phane?=) Date: Sat, 30 Aug 2008 20:30:54 +0000 (UTC) Subject: [Python-Dev] [optparse] I wonder if optparse is dead ? because... Message-ID: Hello, I wonder if optparse is dead ? because : * svn access is down (svn co svn://starship.python.net/optik/trunk optik) ( http://sourceforge.net/mailarchive/forum.php? thread_name=466F541C.6010804%40users.sourceforge.net&forum_name=optik- users ) * last release is out 2 years ago ( http://sourceforge.net/mailarchive/forum.php? thread_name=20060723161651.GA2076%40cthulhu.gerg.ca&forum_name=optik- users ) * Greg Ward mail ( gward at python.net ) and is home page (http:// www.gerg.ca/) are away * I'm interested by this feature http://sourceforge.net/tracker/index.php? func=detail&aid=1819510&group_id=38019&atid=421097 but it hasn't comment since one year ago. Otherwise optparse is a great module ! Thanks for your information, Stephane From g.brandl at gmx.net Sat Aug 30 23:09:05 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Sat, 30 Aug 2008 23:09:05 +0200 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: <85b5c3130808301235t7ce79662t767c2831e736d808@mail.gmail.com> References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> <48B81E24.2070906@gmail.com> <85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com> <9AE6735E-45F6-4A66-B749-1DB7A3D39EA3@gmail.com> <85b5c3130808301235t7ce79662t767c2831e736d808@mail.gmail.com> Message-ID: Ondrej Certik schrieb: >>> Ondrej >> >> Ondrej, a patch that improves the official docs would be welcome and still >> potentially make 2.6/3.0 > > That'd be awesome. I need to finish my thesis in the next couple days, > so I'd welcome if anyone could just take it and put usefult things in. > I could get to do it the next week the earliest. Doc patches are always accepted, and I intend to update the online 2.6 and 3.0 docs continually even when the finals are released, so there is no particular deadline you have to make. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From g.brandl at gmx.net Sat Aug 30 23:11:21 2008 From: g.brandl at gmx.net (Georg Brandl) Date: Sat, 30 Aug 2008 23:11:21 +0200 Subject: [Python-Dev] [optparse] I wonder if optparse is dead ? because... In-Reply-To: References: Message-ID: KLEIN St?phane schrieb: > Hello, > > I wonder if optparse is dead ? because : > > * svn access is down (svn co svn://starship.python.net/optik/trunk optik) > ( http://sourceforge.net/mailarchive/forum.php? > thread_name=466F541C.6010804%40users.sourceforge.net&forum_name=optik- > users ) > > * last release is out 2 years ago > ( http://sourceforge.net/mailarchive/forum.php? > thread_name=20060723161651.GA2076%40cthulhu.gerg.ca&forum_name=optik- > users ) > > * Greg Ward mail ( gward at python.net ) and is home page (http:// > www.gerg.ca/) are away > > * I'm interested by this feature > http://sourceforge.net/tracker/index.php? > func=detail&aid=1819510&group_id=38019&atid=421097 > but it hasn't comment since one year ago. > > Otherwise optparse is a great module ! Well, the module itself certainly isn't dead since it's distributed with Python. What might be dead is the standalone version, Optik. However, we have so far delegated feature requests to Greg and expected them to be included in Optik first before being merged to the core. If Optik is no longer maintained, we can do this directly in the core, with Python's release cycle. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From ziade.tarek at gmail.com Sat Aug 30 23:15:13 2008 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Sat, 30 Aug 2008 23:15:13 +0200 Subject: [Python-Dev] [optparse] I wonder if optparse is dead ? because... In-Reply-To: References: Message-ID: <94bdd2610808301415laaf9e01rc0a8637f90b17f3d@mail.gmail.com> On Sat, Aug 30, 2008 at 10:30 PM, KLEIN St?phane wrote: > Hello, > > I wonder if optparse is dead ? because : > > * svn access is down (svn co svn://starship.python.net/optik/trunk optik) > ( http://sourceforge.net/mailarchive/forum.php? > thread_name=466F541C.6010804%40users.sourceforge.net&forum_name=optik- > users ) > > * last release is out 2 years ago > ( http://sourceforge.net/mailarchive/forum.php? > thread_name=20060723161651.GA2076%40cthulhu.gerg.ca&forum_name=optik- > users ) > Hello, It has been integrated in Python since then, afaik http://svn.python.org/projects/python/trunk/Lib/optparse.py > > * Greg Ward mail ( gward at python.net ) and is home page (http:// > www.gerg.ca/) are away > > * I'm interested by this feature > http://sourceforge.net/tracker/index.php? > func=detail&aid=1819510&group_id=38019&atid=421097 > but it hasn't comment since one year ago. > > Otherwise optparse is a great module ! > > Thanks for your information, > Stephane > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com > -- Tarek Ziad? | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at certik.cz Sat Aug 30 23:24:45 2008 From: ondrej at certik.cz (Ondrej Certik) Date: Sat, 30 Aug 2008 23:24:45 +0200 Subject: [Python-Dev] Documentation Error for __hash__ In-Reply-To: References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com> <48B7DBD8.8070205@voidspace.org.uk> <48B81E24.2070906@gmail.com> <85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com> <9AE6735E-45F6-4A66-B749-1DB7A3D39EA3@gmail.com> <85b5c3130808301235t7ce79662t767c2831e736d808@mail.gmail.com> Message-ID: <85b5c3130808301424j5da8308fg212e2a06b84d5981@mail.gmail.com> Hi Georg! On Sat, Aug 30, 2008 at 11:09 PM, Georg Brandl wrote: > Ondrej Certik schrieb: >>>> Ondrej >>> >>> Ondrej, a patch that improves the official docs would be welcome and still >>> potentially make 2.6/3.0 >> >> That'd be awesome. I need to finish my thesis in the next couple days, >> so I'd welcome if anyone could just take it and put usefult things in. >> I could get to do it the next week the earliest. > > Doc patches are always accepted, and I intend to update the online 2.6 and > 3.0 docs continually even when the finals are released, so there is no > particular deadline you have to make. This is awesome, I didn't know you take care of the official docs too. I'll send the doc patches when I get to it, unless someone else does it before me. Ondrej From stephane at harobed.org Sat Aug 30 23:29:19 2008 From: stephane at harobed.org (=?iso-8859-1?q?KLEIN_St=E9phane?=) Date: Sat, 30 Aug 2008 21:29:19 +0000 (UTC) Subject: [Python-Dev] [optparse] I wonder if optparse is dead ? because... References: <94bdd2610808301415laaf9e01rc0a8637f90b17f3d@mail.gmail.com> Message-ID: Le Sat, 30 Aug 2008 23:15:13 +0200, Tarek Ziad? a ?crit?: > On Sat, Aug 30, 2008 at 10:30 PM, KLEIN St?phane > wrote: > >> Hello, >> >> I wonder if optparse is dead ? because : >> >> * svn access is down (svn co svn://starship.python.net/optik/trunk >> optik) ( http://sourceforge.net/mailarchive/forum.php? >> thread_name=466F541C.6010804%40users.sourceforge.net&forum_name=optik- >> users ) >> >> * last release is out 2 years ago >> ( http://sourceforge.net/mailarchive/forum.php? >> thread_name=20060723161651.GA2076%40cthulhu.gerg.ca&forum_name=optik- >> users ) >> >> > Hello, > > It has been integrated in Python since then, afaik > > http://svn.python.org/projects/python/trunk/Lib/optparse.py > Yes, I know but there are this lines in optparse.py source code : """ By Greg Ward Originally distributed as Optik; see http://optik.sourceforge.net/ . If you have problems with this module, please do not file bugs, patches, or feature requests with Python; instead, use Optik's SourceForge project page: http://sourceforge.net/projects/optik For support, use the optik-users at lists.sourceforge.net mailing list (http://lists.sourceforge.net/lists/listinfo/optik-users). """ then if I read this, I need to send my request feature to Optik web site but it appear asleep. Regards, Stephane From michele.simionato at gmail.com Sun Aug 31 09:12:27 2008 From: michele.simionato at gmail.com (Michele Simionato) Date: Sun, 31 Aug 2008 09:12:27 +0200 Subject: [Python-Dev] Things to Know About Super In-Reply-To: <4edc17eb0808292116q39763348g162b8f90787e8e6c@mail.gmail.com> References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com> <4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com> <20080828185312.943163A408D@sparrow.telecommunity.com> <4edc17eb0808282107q65969a63qb6b8745461b57b44@mail.gmail.com> <20080829042146.6DC123A408D@sparrow.telecommunity.com> <4edc17eb0808282144l6d81979bic95ae8c11d69cd37@mail.gmail.com> <48B82098.8090106@gmail.com> <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com> <5A0A8180-273D-4739-869C-8F5A35184FC5@pandora.com> <4edc17eb0808292116q39763348g162b8f90787e8e6c@mail.gmail.com> Message-ID: <4edc17eb0808310012w4cd0f340u70f3664aa938be6d@mail.gmail.com> On Sat, Aug 30, 2008 at 6:16 AM, Michele Simionato > I wrote a trait library which I plan to release soon or later. Ok, just for the people here that cannot wait I have prepared a pre-alpha snapshot and uploaded it to my site: http://www.phyast.pitt.edu/~micheles/python/strait.html At some moment I want to release it officially, but as of now I do not feel I have nailed out all the details and there may be difficulties I have not foreseen. If it is so, I am sure Phillip will find out all the loopholes ;) Nevertheless, I feel that I have covered out a lot of use cases that I cared to cover, and that there is something good in there, so have fun with this foolish attempt of putting multiple inheritance straight! ;-) Michele Simionato From jcea at jcea.es Sun Aug 31 16:43:34 2008 From: jcea at jcea.es (Jesus Cea) Date: Sun, 31 Aug 2008 16:43:34 +0200 Subject: [Python-Dev] Email update Message-ID: <48BAAE16.9010200@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm getting some private email about python issues in "jcea at argo.es". This email address works for now, but it is "deprecated". My current email is "jcea at jcea.es". Please, update your addressbooks, and any list/contact info out there. I already updated my mailman subscriptions months ago. My old email can vanish without warning. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSLquCZlgi5GaxT1NAQKQRwP/fI7xR3O87aPRSunGIibVqLEAwiSczc8N diWZ2QxSmr2GnL7tDWXU9B/ROxuFL3Rhti21T/BfLDDPn5pi9YmwVkKji4Jt+v1L UROgaJ5nnv1CBiLvKPDSkIoHoFKa4Gx1hIWihEy6Oed8mA8qKP+rm0tX0NfWJaRo ofEja3FooDs= =wYIM -----END PGP SIGNATURE-----