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: <FA19E97873301B48B29F217ABF64EA8797F021@GUREXMB01.ASIAN.AD.ARICENT.COM>
	<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: <bbaeab100807311920n57a063a3ya31883005c15e93a@mail.gmail.com>

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: <op.ue579jzuhlrjc9@conan>
References: <b7975ab80807251504q209d9c39v2f3bc01114e1ec77@mail.gmail.com>
	<488A8302.3050408@canterbury.ac.nz>
	<ca471dc20807291726y2e4133f3p15884b4fec135fa0@mail.gmail.com>
	<3d0cebfb0807291759u3716e68at7046354260c09ebc@mail.gmail.com>
	<b7975ab80807291853v515b6252g9da2831ee2e02f6b@mail.gmail.com>
	<b7975ab80807300213p4dba4428n79edfdf4deebd908@mail.gmail.com>
	<4891C36E.4070200@gmail.com> <op.ue579jzuhlrjc9@conan>
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: <BB189CD6-0276-411D-ABCD-9CE4BA9C6B8C@barrys-emacs.org>

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: <bbaeab100807311920n57a063a3ya31883005c15e93a@mail.gmail.com>
References: <bbaeab100807311920n57a063a3ya31883005c15e93a@mail.gmail.com>
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: <BB189CD6-0276-411D-ABCD-9CE4BA9C6B8C@barrys-emacs.org>
References: <BB189CD6-0276-411D-ABCD-9CE4BA9C6B8C@barrys-emacs.org>
Message-ID: <1afaf6160808010629s66953c5dmc7470cc98ef35cd2@mail.gmail.com>

On Fri, Aug 1, 2008 at 8:06 AM, Barry Scott <barry at barrys-emacs.org> 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: <BB189CD6-0276-411D-ABCD-9CE4BA9C6B8C@barrys-emacs.org>
References: <BB189CD6-0276-411D-ABCD-9CE4BA9C6B8C@barrys-emacs.org>
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: <BB189CD6-0276-411D-ABCD-9CE4BA9C6B8C@barrys-emacs.org>
	<1afaf6160808010629s66953c5dmc7470cc98ef35cd2@mail.gmail.com>
Message-ID: <e27efe130808010638y7d9c15a9p44b1e4d6fc3788ff@mail.gmail.com>

Benjamin Peterson wrote:
> On Fri, Aug 1, 2008 at 8:06 AM, Barry Scott <barry at barrys-emacs.org> 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: <e27efe130808010638y7d9c15a9p44b1e4d6fc3788ff@mail.gmail.com>
References: <BB189CD6-0276-411D-ABCD-9CE4BA9C6B8C@barrys-emacs.org>	<1afaf6160808010629s66953c5dmc7470cc98ef35cd2@mail.gmail.com>
	<e27efe130808010638y7d9c15a9p44b1e4d6fc3788ff@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 <barry at barrys-emacs.org> 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: <ca471dc20807301117y661306f4r365c08c7483b0bfc@mail.gmail.com>
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>
	<loom.20080721T154744-225@post.gmane.org>
	<20080721174141.GA16598@amk-desktop.matrixgroup.net>
	<ca471dc20807301117y661306f4r365c08c7483b0bfc@mail.gmail.com>
Message-ID: <ca471dc20808011058oc83f8ddk796de860b18bfaec@mail.gmail.com>

On Wed, Jul 30, 2008 at 11:17 AM, Guido van Rossum <guido at python.org> wrote:
> On Mon, Jul 21, 2008 at 10:41 AM, A.M. Kuchling <amk at amk.ca> 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: <b7975ab80807251504q209d9c39v2f3bc01114e1ec77@mail.gmail.com>
	<488A8302.3050408@canterbury.ac.nz>
	<ca471dc20807291726y2e4133f3p15884b4fec135fa0@mail.gmail.com>
Message-ID: <g6vkh2$bm8$1@ger.gmane.org>

Guido van Rossum wrote:

> On Fri, Jul 25, 2008 at 6:50 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>
> 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: <g6vkh2$bm8$1@ger.gmane.org>
References: <b7975ab80807251504q209d9c39v2f3bc01114e1ec77@mail.gmail.com>	<488A8302.3050408@canterbury.ac.nz>	<ca471dc20807291726y2e4133f3p15884b4fec135fa0@mail.gmail.com>
	<g6vkh2$bm8$1@ger.gmane.org>
Message-ID: <g700rf$is0$1@ger.gmane.org>


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: <g700rf$is0$1@ger.gmane.org>
References: <b7975ab80807251504q209d9c39v2f3bc01114e1ec77@mail.gmail.com>	<488A8302.3050408@canterbury.ac.nz>	<ca471dc20807291726y2e4133f3p15884b4fec135fa0@mail.gmail.com>	<g6vkh2$bm8$1@ger.gmane.org>
	<g700rf$is0$1@ger.gmane.org>
Message-ID: <g706br$165$1@ger.gmane.org>

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: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>

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: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
Message-ID: <ca471dc20808011856p1b251fecp57ddbb7f7201186f@mail.gmail.com>

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 <jonas.esp at googlemail.com> 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: <ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
Message-ID: <g70gb1$lqm$1@ger.gmane.org>

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 <jonas.esp at googlemail.com> 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: <BB189CD6-0276-411D-ABCD-9CE4BA9C6B8C@barrys-emacs.org>
	<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: <g70gb1$lqm$1@ger.gmane.org>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
Message-ID: <cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>

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 <st... at holdenweb.com> 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: <cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
Message-ID: <e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>

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 <jonas.esp at googlemail.com> 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 <st... at holdenweb.com> 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: <e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>	<g70gb1$lqm$1@ger.gmane.org>	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
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: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
Message-ID: <e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>

On Sat, Aug 2, 2008 at 10:09 AM, "Martin v. L?wis" <martin at v.loewis.de> 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: <e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>
Message-ID: <ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>

On Sat, Aug 2, 2008 at 10:37 AM, Josiah Carlson
<josiah.carlson at gmail.com> wrote:
> On Sat, Aug 2, 2008 at 10:09 AM, "Martin v. L?wis" <martin at v.loewis.de> 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: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>	<g70gb1$lqm$1@ger.gmane.org>	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
Message-ID: <loom.20080802T194913-285@post.gmane.org>

Martin v. L?wis <martin <at> 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: <loom.20080802T194913-285@post.gmane.org>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<loom.20080802T194913-285@post.gmane.org>
Message-ID: <ca471dc20808021407w719f6baco2384b2e3a27e6f2d@mail.gmail.com>

On Sat, Aug 2, 2008 at 12:58 PM, Antoine Pitrou <solipsis at pitrou.net> 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: <ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>
	<ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>
Message-ID: <ca471dc20808021415r28a12c30l9d204320cdb3104b@mail.gmail.com>

On Sat, Aug 2, 2008 at 11:57 AM, Guido van Rossum <guido at python.org> 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: <ca471dc20808021407w719f6baco2384b2e3a27e6f2d@mail.gmail.com>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<loom.20080802T194913-285@post.gmane.org>
	<ca471dc20808021407w719f6baco2384b2e3a27e6f2d@mail.gmail.com>
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 <solipsis at pitrou.net> 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
z<g>qYkn__U%akFI(fHNxLoP?qI1sW!5 at Div?MoBQU<}W8T2DXa{`gkjO1RO?{-Yz3
z-yd-sVx%pSu0elCXI*-RPErV~&bEbl*yk6ff?mV<KJ-WwL$dK$cWOO8v8nQ6i6@~u
zvw~4tJo7xMUB<3mj-!r at xsl3A+<JySyN4MA5V)G1_~N92FPXjkyeyjjlF2Cwdfx=~
zrIy88pZDkmmlT6BVEB&HsO>pWHk^!$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*sIU93zA4b<Bi<K+TWMzdB4}W%epKy!i*d>tzW?3CiviE&Xi9>Bo
zUeM*=71Le)&!sv725-*vg<uCI_{^T8FxI^)wh*sYr0H at is@*)iWzn066>S1naIlau
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~c0<c+6^Ln)%3kuKh-Dp%rRlz3?{E)fP1KT406
Xzmcn%Pn at uyr&=uAM*jcfzxCr^k_Znj


>From 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: <bbaeab100808021546l603419d7u50444c325682d22d@mail.gmail.com>

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: <cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
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: <ca471dc20808021415r28a12c30l9d204320cdb3104b@mail.gmail.com>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>
	<ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>
	<ca471dc20808021415r28a12c30l9d204320cdb3104b@mail.gmail.com>
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 <guido at python.org> 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: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>	<g70gb1$lqm$1@ger.gmane.org>	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>	<489494E5.3050306@v.loewis.de>	<e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>	<ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>	<ca471dc20808021415r28a12c30l9d204320cdb3104b@mail.gmail.com>
	<20080803091948.GB5866@phd.pp.ru>
Message-ID: <g73tgk$3er$1@ger.gmane.org>

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 <guido at python.org> 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: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>
	<ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>
	<ca471dc20808021415r28a12c30l9d204320cdb3104b@mail.gmail.com>
	<20080803091948.GB5866@phd.pp.ru>
Message-ID: <ca471dc20808030756x397d8ff7l5c934537d6d967bb@mail.gmail.com>

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 <phd at phd.pp.ru> 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 <guido at python.org> 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: <ca471dc20808030756x397d8ff7l5c934537d6d967bb@mail.gmail.com>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>
	<ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>
	<ca471dc20808021415r28a12c30l9d204320cdb3104b@mail.gmail.com>
	<20080803091948.GB5866@phd.pp.ru>
	<ca471dc20808030756x397d8ff7l5c934537d6d967bb@mail.gmail.com>
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: <loom.20080803T182740-708@post.gmane.org>

Tres Seaver <tseaver <at> 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: <loom.20080803T182740-708@post.gmane.org>
References: <4895EE62.8080605@korokithakis.net> <4895F311.60200@palladion.com>
	<loom.20080803T182740-708@post.gmane.org>
Message-ID: <fb73205e0808031138j3570147h8b75b298d34d475c@mail.gmail.com>

On Sun, Aug 3, 2008 at 8:29 PM, Antoine Pitrou <solipsis at pitrou.net> 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: <fb73205e0808031138j3570147h8b75b298d34d475c@mail.gmail.com>
References: <4895EE62.8080605@korokithakis.net> <4895F311.60200@palladion.com>
	<loom.20080803T182740-708@post.gmane.org>
	<fb73205e0808031138j3570147h8b75b298d34d475c@mail.gmail.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: <bbaeab100808031249u1f74434csab9c438674c92b68@mail.gmail.com>

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: <ca471dc20808030756x397d8ff7l5c934537d6d967bb@mail.gmail.com>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>
	<ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>
	<ca471dc20808021415r28a12c30l9d204320cdb3104b@mail.gmail.com>
	<20080803091948.GB5866@phd.pp.ru>
	<ca471dc20808030756x397d8ff7l5c934537d6d967bb@mail.gmail.com>
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: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>
	<ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>
	<ca471dc20808021415r28a12c30l9d204320cdb3104b@mail.gmail.com>
	<20080803091948.GB5866@phd.pp.ru>
	<ca471dc20808030756x397d8ff7l5c934537d6d967bb@mail.gmail.com>
	<18581.60646.443926.686619@montanaro-dyndns-org.local>
Message-ID: <ca471dc20808031921n78d8de2bnd5850cff67fc6fa7@mail.gmail.com>

On Sun, Aug 3, 2008 at 10:37 AM,  <skip at pobox.com> 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: <ca471dc20808031921n78d8de2bnd5850cff67fc6fa7@mail.gmail.com>
References: <cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>
	<ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>
	<ca471dc20808021415r28a12c30l9d204320cdb3104b@mail.gmail.com>
	<20080803091948.GB5866@phd.pp.ru>
	<ca471dc20808030756x397d8ff7l5c934537d6d967bb@mail.gmail.com>
	<18581.60646.443926.686619@montanaro-dyndns-org.local>
	<ca471dc20808031921n78d8de2bnd5850cff67fc6fa7@mail.gmail.com>
Message-ID: <20080804034329.GB12449@panix.com>

On Sun, Aug 03, 2008, Guido van Rossum wrote:
> On Sun, Aug 3, 2008 at 10:37 AM,  <skip at pobox.com> 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: <loom.20080804T083724-56@post.gmane.org>


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: <g73tgk$3er$1@ger.gmane.org>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>	<g70gb1$lqm$1@ger.gmane.org>	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>	<489494E5.3050306@v.loewis.de>	<e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>	<ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>	<ca471dc20808021415r28a12c30l9d204320cdb3104b@mail.gmail.com>	<20080803091948.GB5866@phd.pp.ru>
	<g73tgk$3er$1@ger.gmane.org>
Message-ID: <g76rmt$jgi$1@ger.gmane.org>

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 <guido at python.org> 
>>> 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: <loom.20080804T083724-56@post.gmane.org>
References: <4896A141.2020006@eventuallyanyway.com>
	<loom.20080804T083724-56@post.gmane.org>
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: <cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>
	<ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>
	<ca471dc20808021415r28a12c30l9d204320cdb3104b@mail.gmail.com>
	<20080803091948.GB5866@phd.pp.ru>
	<ca471dc20808030756x397d8ff7l5c934537d6d967bb@mail.gmail.com>
	<18581.60646.443926.686619@montanaro-dyndns-org.local>
	<ca471dc20808031921n78d8de2bnd5850cff67fc6fa7@mail.gmail.com>
	<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: <loom.20080804T083724-56@post.gmane.org>
References: <4896A141.2020006@eventuallyanyway.com>
	<loom.20080804T083724-56@post.gmane.org>
Message-ID: <bbaeab100808041203q3b5c1f2bw891548a570c677e3@mail.gmail.com>

On Mon, Aug 4, 2008 at 1:42 AM, Antoine Pitrou <solipsis at pitrou.net> 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: <cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808021037m29ba433ah6b2d1de4a2261b58@mail.gmail.com>
	<ca471dc20808021157j5210ea6cy98f25a916aa08f4b@mail.gmail.com>
	<ca471dc20808021415r28a12c30l9d204320cdb3104b@mail.gmail.com>
	<20080803091948.GB5866@phd.pp.ru>
	<ca471dc20808030756x397d8ff7l5c934537d6d967bb@mail.gmail.com>
	<18581.60646.443926.686619@montanaro-dyndns-org.local>
	<ca471dc20808031921n78d8de2bnd5850cff67fc6fa7@mail.gmail.com>
	<20080804034329.GB12449@panix.com>
	<18583.18040.814142.664878@montanaro-dyndns-org.local>
Message-ID: <ca471dc20808041309p609b2878lc9c72cea920238bf@mail.gmail.com>

On Mon, Aug 4, 2008 at 11:12 AM,  <skip at pobox.com> 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 <pythonic award tim peters> 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: <e6268af30807311019j14519f5eh233e827313b358e3@mail.gmail.com>
References: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>
	<3968642431361249330@unknownmsgid>
	<ca471dc20807301100v48c41a2alf49ebb91a0b95949@mail.gmail.com>
	<7769003638770459002@unknownmsgid>
	<ca471dc20807301332r23724cffi7de38373df234938@mail.gmail.com>
	<e6268af30807302049u2e953d41m4e84f9f9d8c3aaba@mail.gmail.com>
	<ca471dc20807302101m5ad7f08bv10b22af90262d7ac@mail.gmail.com>
	<e6268af30807310507m4fd678c9q3926e097cbac811a@mail.gmail.com>
	<1bc395c10807310933n519ac306v7656c83093e7cb6c@mail.gmail.com>
	<e6268af30807311019j14519f5eh233e827313b358e3@mail.gmail.com>
Message-ID: <e6268af30808050547g5b019a4al217f986c6d8f35b0@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-dev/attachments/20080805/c7d06d3e/attachment.htm>

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: <e04bdf310808050601y5f389571h8898dd55e649f177@mail.gmail.com>

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: <e6268af30808050547g5b019a4al217f986c6d8f35b0@mail.gmail.com>
References: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>
	<ca471dc20807301100v48c41a2alf49ebb91a0b95949@mail.gmail.com>
	<7769003638770459002@unknownmsgid>
	<ca471dc20807301332r23724cffi7de38373df234938@mail.gmail.com>
	<e6268af30807302049u2e953d41m4e84f9f9d8c3aaba@mail.gmail.com>
	<ca471dc20807302101m5ad7f08bv10b22af90262d7ac@mail.gmail.com>
	<e6268af30807310507m4fd678c9q3926e097cbac811a@mail.gmail.com>
	<1bc395c10807310933n519ac306v7656c83093e7cb6c@mail.gmail.com>
	<e6268af30807311019j14519f5eh233e827313b358e3@mail.gmail.com>
	<e6268af30808050547g5b019a4al217f986c6d8f35b0@mail.gmail.com>
Message-ID: <ca471dc20808051306xd674738v99d15d2f7e39b645@mail.gmail.com>

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 <matt.giuca at gmail.com> 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
<http://docs.python.org/ref/coercion-rules.html>: 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
<http://docs.python.org/ref/coercion-rules.html> 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: <ca471dc20808051345x7b3da2c9i2d9596ae6ad35036@mail.gmail.com>

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. <leo.soto at gmail.com> 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
> <http://docs.python.org/ref/coercion-rules.html>: 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
> <http://docs.python.org/ref/coercion-rules.html> 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: <ca471dc20808051348h54d2252ao98f5c0deace6b07c@mail.gmail.com>

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 <pogonyshev at gmx.net> 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: <ca471dc20808051345x7b3da2c9i2d9596ae6ad35036@mail.gmail.com>
References: <5a8cc9e00808051343ne5d36e9u1c0d63ccf402d053@mail.gmail.com>
	<ca471dc20808051345x7b3da2c9i2d9596ae6ad35036@mail.gmail.com>
Message-ID: <5a8cc9e00808051356i74f6bf7eud3366b36a4e62950@mail.gmail.com>

On Tue, Aug 5, 2008 at 4:45 PM, Guido van Rossum <guido at python.org> 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>
	<ca471dc20808051345x7b3da2c9i2d9596ae6ad35036@mail.gmail.com>
	<5a8cc9e00808051356i74f6bf7eud3366b36a4e62950@mail.gmail.com>
Message-ID: <ca471dc20808051359k667f0e3fx29dc6aeed8881a89@mail.gmail.com>

On Tue, Aug 5, 2008 at 1:56 PM, Leo Soto M. <leo.soto at gmail.com> wrote:
> On Tue, Aug 5, 2008 at 4:45 PM, Guido van Rossum <guido at python.org> 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: <eae285400808051404v4d03c691p83ebbc8b9eac94b3@mail.gmail.com>

On Tue, Aug 5, 2008 at 3:38 PM, Paul Pogonyshev <pogonyshev at gmx.net> 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 <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20080805/acd229b7/attachment.htm>

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: <eae285400808051404v4d03c691p83ebbc8b9eac94b3@mail.gmail.com>
References: <200808052338.21596.pogonyshev@gmx.net>
	<eae285400808051404v4d03c691p83ebbc8b9eac94b3@mail.gmail.com>
Message-ID: <200808060030.49481.pogonyshev@gmx.net>

Daniel Stutzbach wrote:
> On Tue, Aug 5, 2008 at 3:38 PM, Paul Pogonyshev <pogonyshev at gmx.net> 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: <ca471dc20808051306xd674738v99d15d2f7e39b645@mail.gmail.com>
References: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>
	<7769003638770459002@unknownmsgid>
	<ca471dc20807301332r23724cffi7de38373df234938@mail.gmail.com>
	<e6268af30807302049u2e953d41m4e84f9f9d8c3aaba@mail.gmail.com>
	<ca471dc20807302101m5ad7f08bv10b22af90262d7ac@mail.gmail.com>
	<e6268af30807310507m4fd678c9q3926e097cbac811a@mail.gmail.com>
	<1bc395c10807310933n519ac306v7656c83093e7cb6c@mail.gmail.com>
	<e6268af30807311019j14519f5eh233e827313b358e3@mail.gmail.com>
	<e6268af30808050547g5b019a4al217f986c6d8f35b0@mail.gmail.com>
	<ca471dc20808051306xd674738v99d15d2f7e39b645@mail.gmail.com>
Message-ID: <e6268af30808051603r7857b918k99db0366d7a16488@mail.gmail.com>

> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080806/922163fb/attachment-0001.htm>

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>
	<eae285400808051404v4d03c691p83ebbc8b9eac94b3@mail.gmail.com>
	<200808060030.49481.pogonyshev@gmx.net>
Message-ID: <loom.20080805T230704-720@post.gmane.org>

Paul Pogonyshev <pogonyshev <at> 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: <ca471dc20808051359k667f0e3fx29dc6aeed8881a89@mail.gmail.com>
References: <5a8cc9e00808051343ne5d36e9u1c0d63ccf402d053@mail.gmail.com>
	<ca471dc20808051345x7b3da2c9i2d9596ae6ad35036@mail.gmail.com>
	<5a8cc9e00808051356i74f6bf7eud3366b36a4e62950@mail.gmail.com>
	<ca471dc20808051359k667f0e3fx29dc6aeed8881a89@mail.gmail.com>
Message-ID: <5a8cc9e00808051756i15f418c5gf5cc5261c6d7ceac@mail.gmail.com>

On Tue, Aug 5, 2008 at 4:59 PM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Aug 5, 2008 at 1:56 PM, Leo Soto M. <leo.soto at gmail.com> wrote:
>> On Tue, Aug 5, 2008 at 4:45 PM, Guido van Rossum <guido at python.org> 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>
	<eae285400808051404v4d03c691p83ebbc8b9eac94b3@mail.gmail.com>
	<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 
<bound method Foo.__del__ of <__main__.Foo object at 0x6b6f0>> 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>
	<ca471dc20808051345x7b3da2c9i2d9596ae6ad35036@mail.gmail.com>
	<5a8cc9e00808051356i74f6bf7eud3366b36a4e62950@mail.gmail.com>
	<ca471dc20808051359k667f0e3fx29dc6aeed8881a89@mail.gmail.com>
	<5a8cc9e00808051756i15f418c5gf5cc5261c6d7ceac@mail.gmail.com>
Message-ID: <ca471dc20808051946m2abfc71coe4069a867c229c69@mail.gmail.com>

On Tue, Aug 5, 2008 at 5:56 PM, Leo Soto M. <leo.soto at gmail.com> wrote:
> On Tue, Aug 5, 2008 at 4:59 PM, Guido van Rossum <guido at python.org> wrote:
>> On Tue, Aug 5, 2008 at 1:56 PM, Leo Soto M. <leo.soto at gmail.com> wrote:
>>> On Tue, Aug 5, 2008 at 4:45 PM, Guido van Rossum <guido at python.org> 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>
	<eae285400808051404v4d03c691p83ebbc8b9eac94b3@mail.gmail.com>
	<200808060030.49481.pogonyshev@gmx.net>
Message-ID: <eae285400808052000g69cc3846w4d8f2c4184a83375@mail.gmail.com>

On Tue, Aug 5, 2008 at 4:30 PM, Paul Pogonyshev <pogonyshev at gmx.net> 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 <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20080805/b5847812/attachment.htm>

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: <e6268af30808051603r7857b918k99db0366d7a16488@mail.gmail.com> 
References: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>
	<7769003638770459002@unknownmsgid>
	<ca471dc20807301332r23724cffi7de38373df234938@mail.gmail.com>
	<e6268af30807302049u2e953d41m4e84f9f9d8c3aaba@mail.gmail.com>
	<ca471dc20807302101m5ad7f08bv10b22af90262d7ac@mail.gmail.com>
	<e6268af30807310507m4fd678c9q3926e097cbac811a@mail.gmail.com>
	<1bc395c10807310933n519ac306v7656c83093e7cb6c@mail.gmail.com>
	<e6268af30807311019j14519f5eh233e827313b358e3@mail.gmail.com>
	<e6268af30808050547g5b019a4al217f986c6d8f35b0@mail.gmail.com>
	<ca471dc20808051306xd674738v99d15d2f7e39b645@mail.gmail.com>
	<e6268af30808051603r7857b918k99db0366d7a16488@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: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>
	<e6268af30808051603r7857b918k99db0366d7a16488@mail.gmail.com>
	<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: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>
	<e6268af30808051603r7857b918k99db0366d7a16488@mail.gmail.com>
	<200808060951.54723.nd@perlig.de>
Message-ID: <e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>

> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080806/5cfa27a4/attachment.htm>

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: <ca471dc20808051946m2abfc71coe4069a867c229c69@mail.gmail.com>
References: <5a8cc9e00808051343ne5d36e9u1c0d63ccf402d053@mail.gmail.com>
	<ca471dc20808051345x7b3da2c9i2d9596ae6ad35036@mail.gmail.com>
	<5a8cc9e00808051356i74f6bf7eud3366b36a4e62950@mail.gmail.com>
	<ca471dc20808051359k667f0e3fx29dc6aeed8881a89@mail.gmail.com>
	<5a8cc9e00808051756i15f418c5gf5cc5261c6d7ceac@mail.gmail.com>
	<ca471dc20808051946m2abfc71coe4069a867c229c69@mail.gmail.com>
Message-ID: <5a8cc9e00808060630y2f3cee65m77fff197221936a7@mail.gmail.com>

On Tue, Aug 5, 2008 at 10:46 PM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Aug 5, 2008 at 5:56 PM, Leo Soto M. <leo.soto at gmail.com> 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: <e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>
References: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>
	<200808060951.54723.nd@perlig.de>
	<e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>
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: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>
	<200808060951.54723.nd@perlig.de>
	<e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>
	<200808061559.28341.nd@perlig.de>
Message-ID: <e6268af30808060812r6c3ff357h6843c78c7c32801d@mail.gmail.com>

> 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 <http://bugs.python.org/issue3300> all the way
to the beginning, you'll see I use a good many examples, and I also went
through the entire standard library <http://bugs.python.org/msg69591> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080807/ccb015f1/attachment.htm>

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: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>	<200808060951.54723.nd@perlig.de>	<e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>
	<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: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>
	<200808060951.54723.nd@perlig.de>
	<e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>
	<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: <ca471dc20808051348h54d2252ao98f5c0deace6b07c@mail.gmail.com>
References: <200808052338.21596.pogonyshev@gmx.net>
	<ca471dc20808051348h54d2252ao98f5c0deace6b07c@mail.gmail.com>
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: <e6268af30808060812r6c3ff357h6843c78c7c32801d@mail.gmail.com>
References: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>	<200808060951.54723.nd@perlig.de>	<e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>	<200808061559.28341.nd@perlig.de>
	<e6268af30808060812r6c3ff357h6843c78c7c32801d@mail.gmail.com>
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: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>	<200808060951.54723.nd@perlig.de>	<e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>	<200808061559.28341.nd@perlig.de>
	<e6268af30808060812r6c3ff357h6843c78c7c32801d@mail.gmail.com>
	<4899CCB3.5020208@v.loewis.de>
Message-ID: <loom.20080806T162530-202@post.gmane.org>

Martin v. L?wis <martin <at> 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: <loom.20080806T162530-202@post.gmane.org>
References: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>	<200808060951.54723.nd@perlig.de>	<e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>	<200808061559.28341.nd@perlig.de>	<e6268af30808060812r6c3ff357h6843c78c7c32801d@mail.gmail.com>	<4899CCB3.5020208@v.loewis.de>
	<loom.20080806T162530-202@post.gmane.org>
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: <loom.20080806T162530-202@post.gmane.org>
References: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>	<200808060951.54723.nd@perlig.de>	<e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>	<200808061559.28341.nd@perlig.de>	<e6268af30808060812r6c3ff357h6843c78c7c32801d@mail.gmail.com>	<4899CCB3.5020208@v.loewis.de>
	<loom.20080806T162530-202@post.gmane.org>
Message-ID: <4899E0B8.8070907@egenix.com>

On 2008-08-06 18:55, Antoine Pitrou wrote:
> Martin v. L?wis <martin <at> 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: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>
	<200808060951.54723.nd@perlig.de>
	<e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>
	<200808061559.28341.nd@perlig.de>
	<e6268af30808060812r6c3ff357h6843c78c7c32801d@mail.gmail.com>
	<4899CCB3.5020208@v.loewis.de>
Message-ID: <ca471dc20808061444t42ee63c3k843296ac38f34617@mail.gmail.com>

On Wed, Aug 6, 2008 at 9:09 AM, "Martin v. L?wis" <martin at v.loewis.de> 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-<version-number>/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: <B49A950E-7D9E-4D9D-B199-FCFEF5656E77@fuhm.net>


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: <B49A950E-7D9E-4D9D-B199-FCFEF5656E77@fuhm.net>
References: <18e505e30808062136s8f8c67x21d32e5849e886d4@mail.gmail.com>
	<B49A950E-7D9E-4D9D-B199-FCFEF5656E77@fuhm.net>
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>	<B49A950E-7D9E-4D9D-B199-FCFEF5656E77@fuhm.net>
	<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: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>
	<200808060951.54723.nd@perlig.de>
	<e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>
	<200808061559.28341.nd@perlig.de>
	<e6268af30808060812r6c3ff357h6843c78c7c32801d@mail.gmail.com>
	<4899CCB3.5020208@v.loewis.de>
Message-ID: <e6268af30808070337l386dac2as9f0e8d55872da76c@mail.gmail.com>

Wow .. a lot of replies today!

On Thu, Aug 7, 2008 at 2:09 AM, "Martin v. L?wis" <martin at v.loewis.de>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 <mal at egenix.com> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080807/7b20a8a8/attachment.htm>

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>	<B49A950E-7D9E-4D9D-B199-FCFEF5656E77@fuhm.net>
	<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>
	<B49A950E-7D9E-4D9D-B199-FCFEF5656E77@fuhm.net>
	<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" <martin at v.loewis.de> 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>
	<B49A950E-7D9E-4D9D-B199-FCFEF5656E77@fuhm.net>
	<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 <ian.charnas at gmail.com> 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" <martin at v.loewis.de> 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: <d2155e360808071525n801778at5148d16a40bc30c7@mail.gmail.com>

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: <d2155e360808071525n801778at5148d16a40bc30c7@mail.gmail.com>
References: <d2155e360808071525n801778at5148d16a40bc30c7@mail.gmail.com>
Message-ID: <bbaeab100808071536u6da52985p342218aa6bdd781c@mail.gmail.com>

On Thu, Aug 7, 2008 at 3:25 PM, Curt Hagenlocher <curt at hagenlocher.org> 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: <e6268af30808070337l386dac2as9f0e8d55872da76c@mail.gmail.com>
References: <e6268af30807121027o48cc010fu369bce99bde0233b@mail.gmail.com>
	<200808060951.54723.nd@perlig.de>
	<e6268af30808060555j4f292ccflf7a0f33f467648a1@mail.gmail.com>
	<200808061559.28341.nd@perlig.de>
	<e6268af30808060812r6c3ff357h6843c78c7c32801d@mail.gmail.com>
	<4899CCB3.5020208@v.loewis.de>
	<e6268af30808070337l386dac2as9f0e8d55872da76c@mail.gmail.com>
Message-ID: <ca471dc20808071630s6f1f1a95pd1ffcfb6070bbc27@mail.gmail.com>

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: <bbaeab100808071536u6da52985p342218aa6bdd781c@mail.gmail.com>
References: <d2155e360808071525n801778at5148d16a40bc30c7@mail.gmail.com>
	<bbaeab100808071536u6da52985p342218aa6bdd781c@mail.gmail.com>
Message-ID: <ca471dc20808071648m5dfa085agea83f5b775bf85af@mail.gmail.com>

On Thu, Aug 7, 2008 at 3:36 PM, Brett Cannon <brett at python.org> wrote:
> On Thu, Aug 7, 2008 at 3:25 PM, Curt Hagenlocher <curt at hagenlocher.org> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080808/c9b30ff5/attachment-0001.htm>

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 <jstritar at gmail.com> 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 <http://wiki.python.org/moin/CPythonVmInternals>?
-- 
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: <e6268af30808090022l29d3f960qe69912e9caf207a1@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-dev/attachments/20080809/2bd5843d/attachment.htm>

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: <e6268af30808090040x4900324raf6cab9028658985@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-dev/attachments/20080809/5e34472f/attachment.htm>

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: <ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>

On Sat, Aug 9, 2008 at 7:40 AM,  <skip at pobox.com> 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: <e6268af30808090040x4900324raf6cab9028658985@mail.gmail.com>
References: <e6268af30808090040x4900324raf6cab9028658985@mail.gmail.com>
Message-ID: <e6268af30808090933y3949cee3veb0d958b2e783bbb@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-dev/attachments/20080810/3556c7fb/attachment.htm>

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: <ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>
References: <18589.44145.168712.151985@montanaro-dyndns-org.local>
	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>
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>
	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>
	<18589.51175.581371.874708@montanaro-dyndns-org.local>
Message-ID: <ca471dc20808090943q5a84afbeg7ea2e2ae2b44937@mail.gmail.com>

Google for it. It's worth learning. :-)

On Sat, Aug 9, 2008 at 9:37 AM,  <skip at pobox.com> 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: <e6268af30808090040x4900324raf6cab9028658985@mail.gmail.com>
References: <e6268af30808090040x4900324raf6cab9028658985@mail.gmail.com>
Message-ID: <ca471dc20808090945t4075ff09q200917b39e1777a1@mail.gmail.com>

On Sat, Aug 9, 2008 at 12:40 AM, Matt Giuca <matt.giuca at gmail.com> 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: <ca471dc20808090945t4075ff09q200917b39e1777a1@mail.gmail.com>
References: <e6268af30808090040x4900324raf6cab9028658985@mail.gmail.com>
	<ca471dc20808090945t4075ff09q200917b39e1777a1@mail.gmail.com>
Message-ID: <e6268af30808091141t2ffe90fcsae167da99c33a415@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-dev/attachments/20080810/a151a4d0/attachment.htm>

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>	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>
	<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>
	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>
	<18589.51175.581371.874708@montanaro-dyndns-org.local>
Message-ID: <bbaeab100808091148q9dff510o293950cc369d9672@mail.gmail.com>

On Sat, Aug 9, 2008 at 9:37 AM,  <skip at pobox.com> 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>
	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>
	<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>
	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>
	<18589.51175.581371.874708@montanaro-dyndns-org.local>
	<bbaeab100808091148q9dff510o293950cc369d9672@mail.gmail.com>
Message-ID: <loom.20080809T194535-169@post.gmane.org>

>> 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: <loom.20080809T194535-169@post.gmane.org>
References: <18589.44145.168712.151985@montanaro-dyndns-org.local>
	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>
	<18589.51175.581371.874708@montanaro-dyndns-org.local>
	<bbaeab100808091148q9dff510o293950cc369d9672@mail.gmail.com>
	<loom.20080809T194535-169@post.gmane.org>
Message-ID: <ca471dc20808091328y59461c08m991ddb92d88bc2df@mail.gmail.com>

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 <skip at pobox.com> 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>
	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>
	<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: <ca471dc20808091328y59461c08m991ddb92d88bc2df@mail.gmail.com>
References: <18589.44145.168712.151985@montanaro-dyndns-org.local>
	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>
	<18589.51175.581371.874708@montanaro-dyndns-org.local>
	<bbaeab100808091148q9dff510o293950cc369d9672@mail.gmail.com>
	<loom.20080809T194535-169@post.gmane.org>
	<ca471dc20808091328y59461c08m991ddb92d88bc2df@mail.gmail.com>
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>
	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>
	<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>	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>	<18589.51175.581371.874708@montanaro-dyndns-org.local>	<bbaeab100808091148q9dff510o293950cc369d9672@mail.gmail.com>	<loom.20080809T194535-169@post.gmane.org>	<ca471dc20808091328y59461c08m991ddb92d88bc2df@mail.gmail.com>
	<18590.849.872443.529009@montanaro-dyndns-org.local>
Message-ID: <g7l1ai$pgf$1@ger.gmane.org>

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: <g7l1ai$pgf$1@ger.gmane.org>
References: <18589.44145.168712.151985@montanaro-dyndns-org.local>
	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>
	<18589.51175.581371.874708@montanaro-dyndns-org.local>
	<bbaeab100808091148q9dff510o293950cc369d9672@mail.gmail.com>
	<loom.20080809T194535-169@post.gmane.org>
	<ca471dc20808091328y59461c08m991ddb92d88bc2df@mail.gmail.com>
	<18590.849.872443.529009@montanaro-dyndns-org.local>
	<g7l1ai$pgf$1@ger.gmane.org>
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>	<ca471dc20808090751r64d2d72dy58a79105d3f4708f@mail.gmail.com>	<18589.51175.581371.874708@montanaro-dyndns-org.local>	<bbaeab100808091148q9dff510o293950cc369d9672@mail.gmail.com>	<loom.20080809T194535-169@post.gmane.org>	<ca471dc20808091328y59461c08m991ddb92d88bc2df@mail.gmail.com>	<18590.849.872443.529009@montanaro-dyndns-org.local>	<g7l1ai$pgf$1@ger.gmane.org>
	<18590.3010.873903.72637@montanaro-dyndns-org.local>
Message-ID: <g7l3q1$vou$1@ger.gmane.org>

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: <bbaeab100808092241p69af17f1ve782e7de95e70645@mail.gmail.com>

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: <bbaeab100808092241p69af17f1ve782e7de95e70645@mail.gmail.com>
References: <bbaeab100808092241p69af17f1ve782e7de95e70645@mail.gmail.com>
Message-ID: <aac2c7cb0808092352q6613e574qbc562eafd25df54e@mail.gmail.com>

On Sat, Aug 9, 2008 at 11:41 PM, Brett Cannon <brett at python.org> 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: <ca471dc20808011058oc83f8ddk796de860b18bfaec@mail.gmail.com>
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>	<loom.20080721T154744-225@post.gmane.org>	<20080721174141.GA16598@amk-desktop.matrixgroup.net>	<ca471dc20807301117y661306f4r365c08c7483b0bfc@mail.gmail.com>
	<ca471dc20808011058oc83f8ddk796de860b18bfaec@mail.gmail.com>
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: <bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es>
	<319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com>
	<488150A5.8050804@jcea.es>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
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: <aac2c7cb0808092352q6613e574qbc562eafd25df54e@mail.gmail.com>
References: <bbaeab100808092241p69af17f1ve782e7de95e70645@mail.gmail.com>
	<aac2c7cb0808092352q6613e574qbc562eafd25df54e@mail.gmail.com>
Message-ID: <bbaeab100808102310k26fb4f94i9d4f1242a00240c5@mail.gmail.com>

On Sat, Aug 9, 2008 at 11:52 PM, Adam Olsen <rhamph at gmail.com> wrote:
> On Sat, Aug 9, 2008 at 11:41 PM, Brett Cannon <brett at python.org> 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>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
Message-ID: <loom.20080811T095014-204@post.gmane.org>

Barry Warsaw <barry <at> 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: <loom.20080811T095014-204@post.gmane.org>
References: <4838EA2D.7060402@jcea.es>
	<319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com>
	<488150A5.8050804@jcea.es>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.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 <barry <at> 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>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
Message-ID: <loom.20080811T123355-48@post.gmane.org>

Barry Warsaw <barry <at> 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: <loom.20080811T123355-48@post.gmane.org>
References: <488150A5.8050804@jcea.es>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<loom.20080811T123355-48@post.gmane.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: <loom.20080802T194913-285@post.gmane.org>
References: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>	<g70gb1$lqm$1@ger.gmane.org>	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<loom.20080802T194913-285@post.gmane.org>
Message-ID: <26D6A289-4CFB-4ACB-A018-3680E4B0F079@zooko.com>

On Aug 2, 2008, at 13:58 PM, Antoine Pitrou wrote:

> Martin v. L?wis <martin <at> 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: <a9890139-9120-432c-91d6-003279860103@f36g2000hsa.googlegroups.com>
	<ca471dc20808011856p1b251fecp57ddbb7f7201186f__45665.5466733084$1217642433$gmane$org@mail.gmail.com>
	<g70gb1$lqm$1@ger.gmane.org>
	<cf13105d-8a16-4dda-a87a-b88063186f90@f63g2000hsf.googlegroups.com>
	<e6511dbf0808020909ke063bd8rfd8c8490a9befd33@mail.gmail.com>
	<489494E5.3050306@v.loewis.de>
	<loom.20080802T194913-285@post.gmane.org>
	<26D6A289-4CFB-4ACB-A018-3680E4B0F079@zooko.com>
Message-ID: <e6511dbf0808110859j733c2dfcq2cabff2ed8d86005@mail.gmail.com>

On Mon, Aug 11, 2008 at 8:43 AM, zooko <zooko at zooko.com> wrote:
> On Aug 2, 2008, at 13:58 PM, Antoine Pitrou wrote:
>
>> Martin v. L?wis <martin <at> 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>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.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 <olemis at gmail.com> 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 <barry at python.org> 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: <E7783835-C5C2-4F0C-9C3A-14E4E9357B33@python.org>

-----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: <b10bcdfd-83fa-45d5-9620-e9dc0272375c@m3g2000hsc.googlegroups.com>

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: <b10bcdfd-83fa-45d5-9620-e9dc0272375c@m3g2000hsc.googlegroups.com>
References: <b10bcdfd-83fa-45d5-9620-e9dc0272375c@m3g2000hsc.googlegroups.com>
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: <ca471dc20808121112x610e941cy9de70363b3e877ac@mail.gmail.com>

Is it using fork()? Threads?

On Tue, Aug 12, 2008 at 10:01 AM, Bill Janssen <janssen at parc.com> 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: <ca471dc20808121112x610e941cy9de70363b3e877ac@mail.gmail.com> 
References: <-8870320530519875871@unknownmsgid>
	<ca471dc20808121112x610e941cy9de70363b3e877ac@mail.gmail.com>
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>
	<ca471dc20808121112x610e941cy9de70363b3e877ac@mail.gmail.com>
	<3583499109816891065@unknownmsgid>
Message-ID: <ca471dc20808121138jd2c6dbjb04c56a869f7679a@mail.gmail.com>

On Tue, Aug 12, 2008 at 11:32 AM, Bill Janssen <janssen at 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. :-(

-- 
--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>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de> <48A21B13.3060304@egenix.com>
Message-ID: <ca471dc20808121957r59c2a4afra887cade25b51ca6@mail.gmail.com>

On Tue, Aug 12, 2008 at 4:21 PM, M.-A. Lemburg <mal at egenix.com> 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>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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>
	<ca471dc20808121112x610e941cy9de70363b3e877ac@mail.gmail.com>
	<3583499109816891065@unknownmsgid>
	<ca471dc20808121138jd2c6dbjb04c56a869f7679a@mail.gmail.com>
Message-ID: <loom.20080813T090531-355@post.gmane.org>

Guido van Rossum <guido <at> python.org> writes:
> 
> On Tue, Aug 12, 2008 at 11:32 AM, Bill Janssen <janssen <at> 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>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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: <loom.20080813T090531-355@post.gmane.org>
References: <-8870320530519875871@unknownmsgid>	<ca471dc20808121112x610e941cy9de70363b3e877ac@mail.gmail.com>	<3583499109816891065@unknownmsgid>	<ca471dc20808121138jd2c6dbjb04c56a869f7679a@mail.gmail.com>
	<loom.20080813T090531-355@post.gmane.org>
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: <ca471dc20808121957r59c2a4afra887cade25b51ca6@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es>	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	<48A114EB.3090801@v.loewis.de>	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>
	<48A21B13.3060304@egenix.com>
	<ca471dc20808121957r59c2a4afra887cade25b51ca6@mail.gmail.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: <e69d3ed20807231650x1cc1716ew3789b2aacc280d1d@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es>
	<319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com>
	<488150A5.8050804@jcea.es>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<319e029f0807211437w53619985s85157a60d42966e@mail.gmail.com>
	<e69d3ed20807231650x1cc1716ew3789b2aacc280d1d@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>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<319e029f0807211437w53619985s85157a60d42966e@mail.gmail.com>
	<e69d3ed20807231650x1cc1716ew3789b2aacc280d1d@mail.gmail.com>
	<6167796BFEB5D0438720AC212E89A6B0078F4D7E@exchange.onresolve.com>
Message-ID: <e69d3ed20808130518v6074c8d3g5c2fc5478426edb4@mail.gmail.com>

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 <tnelson at onresolve.com> 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: <BAF14EE0-6706-40F9-90F1-EBB97EEAB28E@barrys-emacs.org>
References: <4838EA2D.7060402@jcea.es>
	<319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com>
	<488150A5.8050804@jcea.es>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<319e029f0807211437w53619985s85157a60d42966e@mail.gmail.com>
	<BAF14EE0-6706-40F9-90F1-EBB97EEAB28E@barrys-emacs.org>
Message-ID: <e69d3ed20808130520u6f804447gacc80aa9466a35d4@mail.gmail.com>

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 <barry at barrys-emacs.org> wrote:
>
> On Jul 21, 2008, at 22:37, Lennart Regebro wrote:
>
>> On Mon, Jul 21, 2008 at 20:16, Brett Cannon <brett at python.org> 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>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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: <g7un3p$the$1@ger.gmane.org>

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: <e69d3ed20808130520u6f804447gacc80aa9466a35d4@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es>
	<319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com>
	<488150A5.8050804@jcea.es>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<319e029f0807211437w53619985s85157a60d42966e@mail.gmail.com>
	<BAF14EE0-6706-40F9-90F1-EBB97EEAB28E@barrys-emacs.org>
	<e69d3ed20808130520u6f804447gacc80aa9466a35d4@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: <g7un3p$the$1@ger.gmane.org>
References: <4838EA2D.7060402@jcea.es>	<4884581F.8010201@jcea.es>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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> <g7un3p$the$1@ger.gmane.org>
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>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<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>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<319e029f0807211437w53619985s85157a60d42966e@mail.gmail.com>
	<e69d3ed20807231650x1cc1716ew3789b2aacc280d1d@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>
	<e69d3ed20808130520u6f804447gacc80aa9466a35d4@mail.gmail.com>
	<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: <loom.20080813T152003-864@post.gmane.org>

Barry Warsaw <barry <at> 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: <loom.20080813T152003-864@post.gmane.org>
Message-ID: <20080813155736.29191.1241046810.divmod.quotient.13910@ohm>

On Wed, 13 Aug 2008 15:35:15 +0000 (UTC), Antoine Pitrou <solipsis at pitrou.net> wrote:
>Barry Warsaw <barry <at> 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>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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: <loom.20080813T152003-864@post.gmane.org>
References: <20080812143059.GB20161@jroger.in-berlin.de>
	<853B3E43-669D-4D2D-B46F-66371DDB9FD6@python.org>
	<loom.20080813T152003-864@post.gmane.org>
Message-ID: <alpine.DEB.1.00.0808132139000.6708@alice>

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>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<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>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<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: <bbaeab100808132029l23a50a1fk79b606e17056f15@mail.gmail.com>

On Wed, Aug 13, 2008 at 4:11 PM, "Martin v. L?wis" <martin at v.loewis.de> 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: <g80b15$45r$1@ger.gmane.org>

Ben Finney wrote:
> Michael Foord <fuzzyman at voidspace.org.uk> writes:
> 
>> The full list of changes proposed [?] and not shot down was
>> something like:
> [?]
> 
>>    assertLessThan
>>    assertGreaterThan
>>    assertLessThanOrEquals
>>    assertGreaterThanOrEquals
> [?]
> 
> "Brett Cannon" <brett at python.org> 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>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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: <loom.20080813T152003-864@post.gmane.org>
	<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: <loom.20080813T152003-864@post.gmane.org>
	<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   <fdrake at acm.org>


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: <e6268af30808140754jaea0d48n71b471f4397f219e@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-dev/attachments/20080815/c147e719/attachment.htm>

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: <bbaeab100808141257pa625937ic0eaa9d7c1fc763@mail.gmail.com>

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>	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	<loom.20080811T095014-204@post.gmane.org>	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	<48A114EB.3090801@v.loewis.de>	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<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>	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>	<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: <bbaeab100808141257pa625937ic0eaa9d7c1fc763@mail.gmail.com>
References: <bbaeab100808141257pa625937ic0eaa9d7c1fc763@mail.gmail.com>
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 <yanagisawa at csg.is.titech.ac.jp>


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 <yanagisawa at csg.is.titech.ac.jp>

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: <e04bdf310808160643sc013457u5297751db9a16026@mail.gmail.com>

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: <e04bdf310808160704g36140bfbod0b68d38e91b9ed1@mail.gmail.com>

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: <e04bdf310808160643sc013457u5297751db9a16026@mail.gmail.com>
References: <e04bdf310808160643sc013457u5297751db9a16026@mail.gmail.com>
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: <e04bdf310808160643sc013457u5297751db9a16026@mail.gmail.com>
References: <e04bdf310808160643sc013457u5297751db9a16026@mail.gmail.com>
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: <e04bdf310808160643sc013457u5297751db9a16026@mail.gmail.com>
Message-ID: <loom.20080816T154541-456@post.gmane.org>

Facundo Batista <facundobatista <at> 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: <loom.20080816T154541-456@post.gmane.org>
References: <e04bdf310808160643sc013457u5297751db9a16026@mail.gmail.com>
	<loom.20080816T154541-456@post.gmane.org>
Message-ID: <e04bdf310808160901j2cd62408sd6cb8adfe7a0e96@mail.gmail.com>

2008/8/16 Antoine Pitrou <solipsis at pitrou.net>:

> 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: <d09829f50808160905y750d0f98v4682de792f32a186@mail.gmail.com>

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: <e04bdf310808160901j2cd62408sd6cb8adfe7a0e96@mail.gmail.com>
Message-ID: <20080816161120.29191.622897079.divmod.quotient.15255@ohm>

On Sat, 16 Aug 2008 13:01:33 -0300, Facundo Batista <facundobatista at gmail.com> wrote:
>2008/8/16 Antoine Pitrou <solipsis at pitrou.net>:
>
>> 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: <e04bdf310808160643sc013457u5297751db9a16026@mail.gmail.com>
	<loom.20080816T154541-456@post.gmane.org>
	<e04bdf310808160901j2cd62408sd6cb8adfe7a0e96@mail.gmail.com>
Message-ID: <loom.20080816T160936-480@post.gmane.org>

Facundo Batista <facundobatista <at> 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: <e04bdf310808160643sc013457u5297751db9a16026@mail.gmail.com>
References: <e04bdf310808160643sc013457u5297751db9a16026@mail.gmail.com>
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: <e04bdf310808160643sc013457u5297751db9a16026@mail.gmail.com>
	<48A70228.8030907@v.loewis.de>
Message-ID: <e04bdf310808161234nfcbc8c7s86b2b146b2fb1263@mail.gmail.com>

2008/8/16 "Martin v. L?wis" <martin at v.loewis.de>:

> 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: <loom.20080816T154541-456@post.gmane.org>
References: <e04bdf310808160643sc013457u5297751db9a16026@mail.gmail.com>
	<loom.20080816T154541-456@post.gmane.org>
Message-ID: <g87b1t$75r$1@ger.gmane.org>



Antoine Pitrou wrote:
> Facundo Batista <facundobatista <at> 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: <e04bdf310808160704g36140bfbod0b68d38e91b9ed1@mail.gmail.com>
References: <e04bdf310808160704g36140bfbod0b68d38e91b9ed1@mail.gmail.com>
Message-ID: <bbaeab100808161252l3ed4b26fjee08b4bbc1f8f5ce@mail.gmail.com>

On Sat, Aug 16, 2008 at 7:04 AM, Facundo Batista
<facundobatista at gmail.com> 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: <d09829f50808160905y750d0f98v4682de792f32a186@mail.gmail.com>
References: <d09829f50808160905y750d0f98v4682de792f32a186@mail.gmail.com>
Message-ID: <g87e9a$f0u$1@ger.gmane.org>



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: <bbaeab100808161834g2a1d436fyc6286d3a81c1d96d@mail.gmail.com>

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: <bbaeab100808161834g2a1d436fyc6286d3a81c1d96d@mail.gmail.com>
References: <bbaeab100808161834g2a1d436fyc6286d3a81c1d96d@mail.gmail.com>
Message-ID: <1afaf6160808161839o92b03fdw6a57bef0eb5c505b@mail.gmail.com>

On Sat, Aug 16, 2008 at 8:34 PM, Brett Cannon <brett at python.org> 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: <C6A1C20DB743364EB446E923B2229FEF06B19539@xmb-sjc-229.amer.cisco.com>

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: <http://mail.python.org/pipermail/python-dev/attachments/20080817/6d5d7e07/attachment.htm>

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: <C6A1C20DB743364EB446E923B2229FEF06B19539@xmb-sjc-229.amer.cisco.com>
References: <C6A1C20DB743364EB446E923B2229FEF06B19539@xmb-sjc-229.amer.cisco.com>
Message-ID: <bbaeab100808171210p6b7bf88n4c575358bebdd725@mail.gmail.com>

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)
<sarvi at cisco.com> 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: <C6A1C20DB743364EB446E923B2229FEF06B19539@xmb-sjc-229.amer.cisco.com>
References: <C6A1C20DB743364EB446E923B2229FEF06B19539@xmb-sjc-229.amer.cisco.com>
Message-ID: <bbaeab100808171210p6b7bf88n4c575358bebdd725@mail.gmail.com>

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)
<sarvi at cisco.com> 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: <bbaeab100808171319t1657bf78q5f8025ec7d6abc16@mail.gmail.com>

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: <bbaeab100808171319t1657bf78q5f8025ec7d6abc16@mail.gmail.com>
References: <bbaeab100808171319t1657bf78q5f8025ec7d6abc16@mail.gmail.com>
Message-ID: <g8a2c9$23v$1@ger.gmane.org>

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: <bbaeab100808171319t1657bf78q5f8025ec7d6abc16@mail.gmail.com>
References: <bbaeab100808171319t1657bf78q5f8025ec7d6abc16@mail.gmail.com>
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: <g8a2c9$23v$1@ger.gmane.org>
References: <bbaeab100808171319t1657bf78q5f8025ec7d6abc16@mail.gmail.com>
	<g8a2c9$23v$1@ger.gmane.org>
Message-ID: <bbaeab100808171504u27294271i84fd7dd4bd3afbc0@mail.gmail.com>

On Sun, Aug 17, 2008 at 1:40 PM, Georg Brandl <g.brandl at gmx.net> 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: <bbaeab100808171504u27294271i84fd7dd4bd3afbc0@mail.gmail.com>
Message-ID: <20080817230953.29191.1782754713.divmod.quotient.15855@ohm>

On Sun, 17 Aug 2008 15:04:58 -0700, Brett Cannon <brett at python.org> wrote:
>On Sun, Aug 17, 2008 at 1:40 PM, Georg Brandl <g.brandl at gmx.net> 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: <bbaeab100808171504u27294271i84fd7dd4bd3afbc0@mail.gmail.com>
References: <bbaeab100808171319t1657bf78q5f8025ec7d6abc16@mail.gmail.com>
	<g8a2c9$23v$1@ger.gmane.org>
	<bbaeab100808171504u27294271i84fd7dd4bd3afbc0@mail.gmail.com>
Message-ID: <ee2a432c0808171838k21cefd3fwfa9c83be8d7c0e55@mail.gmail.com>

On Sun, Aug 17, 2008 at 3:04 PM, Brett Cannon <brett at python.org> wrote:
> On Sun, Aug 17, 2008 at 1:40 PM, Georg Brandl <g.brandl at gmx.net> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080818/8c61dc78/attachment.htm>

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 <module>
        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 <module>
        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: <g1fee5$f8b$1@ger.gmane.org>	<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: <g1fee5$f8b$1@ger.gmane.org>	<483BD10E.7050600@gmail.com>	<483C14D1.1050007@trueblade.com>	<483C2535.2040306@trueblade.com>
	<4840AE6E.40900@trueblade.com> <48A989A7.3090802@trueblade.com>
Message-ID: <loom.20080818T144519-238@post.gmane.org>

Eric Smith <eric <at> 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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>

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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
References: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
References: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
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: <ca471dc20808181006h4e44c1ccyfd8c56d10ce0bf1c@mail.gmail.com>

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 <ncoghlan at gmail.com> 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: <bbaeab100808181032i4717c91x3cccbbf0aba54473@mail.gmail.com>

On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan <ncoghlan at gmail.com> 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: <ca471dc20808181006h4e44c1ccyfd8c56d10ce0bf1c@mail.gmail.com>
References: <18601.22584.469957.920301@montanaro-dyndns-org.local>
	<48A95E7D.1010002@gmail.com>
	<ca471dc20808181006h4e44c1ccyfd8c56d10ce0bf1c@mail.gmail.com>
Message-ID: <bbaeab100808181034h451ba7a2ubab0cd7c96c07f07@mail.gmail.com>

On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum <guido at python.org> 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 <ncoghlan at gmail.com> 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: <bbaeab100808181034h451ba7a2ubab0cd7c96c07f07@mail.gmail.com>
References: <18601.22584.469957.920301@montanaro-dyndns-org.local>
	<48A95E7D.1010002@gmail.com>
	<ca471dc20808181006h4e44c1ccyfd8c56d10ce0bf1c@mail.gmail.com>
	<bbaeab100808181034h451ba7a2ubab0cd7c96c07f07@mail.gmail.com>
Message-ID: <ca471dc20808181110r25358df9sbf54cf4c873bad08@mail.gmail.com>

On Mon, Aug 18, 2008 at 10:34 AM, Brett Cannon <brett at python.org> wrote:
> On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum <guido at python.org> 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 <ncoghlan at gmail.com> 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: <ca471dc20808181110r25358df9sbf54cf4c873bad08@mail.gmail.com>
References: <18601.22584.469957.920301@montanaro-dyndns-org.local>
	<48A95E7D.1010002@gmail.com>
	<ca471dc20808181006h4e44c1ccyfd8c56d10ce0bf1c@mail.gmail.com>
	<bbaeab100808181034h451ba7a2ubab0cd7c96c07f07@mail.gmail.com>
	<ca471dc20808181110r25358df9sbf54cf4c873bad08@mail.gmail.com>
Message-ID: <bbaeab100808181123v28d6e76bwd62474b8e8941436@mail.gmail.com>

On Mon, Aug 18, 2008 at 11:10 AM, Guido van Rossum <guido at python.org> wrote:
> On Mon, Aug 18, 2008 at 10:34 AM, Brett Cannon <brett at python.org> wrote:
>> On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum <guido at python.org> 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 <ncoghlan at gmail.com> 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: <bbaeab100808181123v28d6e76bwd62474b8e8941436@mail.gmail.com>
References: <18601.22584.469957.920301@montanaro-dyndns-org.local>
	<48A95E7D.1010002@gmail.com>
	<ca471dc20808181006h4e44c1ccyfd8c56d10ce0bf1c@mail.gmail.com>
	<bbaeab100808181034h451ba7a2ubab0cd7c96c07f07@mail.gmail.com>
	<ca471dc20808181110r25358df9sbf54cf4c873bad08@mail.gmail.com>
	<bbaeab100808181123v28d6e76bwd62474b8e8941436@mail.gmail.com>
Message-ID: <ca471dc20808181131m4099a39cxa280645b9a0e15e3@mail.gmail.com>

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 <brett at python.org> wrote:
> On Mon, Aug 18, 2008 at 11:10 AM, Guido van Rossum <guido at python.org> wrote:
>> On Mon, Aug 18, 2008 at 10:34 AM, Brett Cannon <brett at python.org> wrote:
>>> On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum <guido at python.org> 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 <ncoghlan at gmail.com> 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: <ca471dc20808181131m4099a39cxa280645b9a0e15e3@mail.gmail.com>
References: <18601.22584.469957.920301@montanaro-dyndns-org.local>
	<48A95E7D.1010002@gmail.com>
	<ca471dc20808181006h4e44c1ccyfd8c56d10ce0bf1c@mail.gmail.com>
	<bbaeab100808181034h451ba7a2ubab0cd7c96c07f07@mail.gmail.com>
	<ca471dc20808181110r25358df9sbf54cf4c873bad08@mail.gmail.com>
	<bbaeab100808181123v28d6e76bwd62474b8e8941436@mail.gmail.com>
	<ca471dc20808181131m4099a39cxa280645b9a0e15e3@mail.gmail.com>
Message-ID: <1afaf6160808181133u4650fce2x7cd1579e63bd592f@mail.gmail.com>

On Mon, Aug 18, 2008 at 1:31 PM, Guido van Rossum <guido at python.org> 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>
	<bbaeab100808181032i4717c91x3cccbbf0aba54473@mail.gmail.com>
Message-ID: <loom.20080818T184304-797@post.gmane.org>

Brett Cannon <brett <at> 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>
	<ca471dc20808181006h4e44c1ccyfd8c56d10ce0bf1c@mail.gmail.com>
	<bbaeab100808181034h451ba7a2ubab0cd7c96c07f07@mail.gmail.com>
	<ca471dc20808181110r25358df9sbf54cf4c873bad08@mail.gmail.com>
	<bbaeab100808181123v28d6e76bwd62474b8e8941436@mail.gmail.com>
	<ca471dc20808181131m4099a39cxa280645b9a0e15e3@mail.gmail.com>
	<1afaf6160808181133u4650fce2x7cd1579e63bd592f@mail.gmail.com>
Message-ID: <B35BA234-1623-463E-8F17-AF5BFDAA00C7@acm.org>

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   <fdrake at acm.org>


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: <loom.20080818T184304-797@post.gmane.org>
References: <18601.22584.469957.920301@montanaro-dyndns-org.local>
	<48A95E7D.1010002@gmail.com>
	<bbaeab100808181032i4717c91x3cccbbf0aba54473@mail.gmail.com>
	<loom.20080818T184304-797@post.gmane.org>
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   <fdrake at acm.org>


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>
	<bbaeab100808181032i4717c91x3cccbbf0aba54473@mail.gmail.com>
	<loom.20080818T184304-797@post.gmane.org>
	<67B54E00-976A-459B-937A-11B35CF4805E@acm.org>
Message-ID: <bbaeab100808181213l75b4bff4kf3308b73ea9a85f2@mail.gmail.com>

On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake <fdrake at acm.org> 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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
Message-ID: <ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>

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 <barry at python.org> 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: <ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
References: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
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 <barry at python.org> 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: <ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
References: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
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 <barry at python.org> 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: <ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
References: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
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 <guido at python.org> 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 <barry at python.org> 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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<48A9ECDD.5050206@holdenweb.com>
Message-ID: <CAB6F7AD-F0C9-40A6-86DA-7FEAB55DA1AA@acm.org>

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   <fdrake at acm.org>


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: <CAB6F7AD-F0C9-40A6-86DA-7FEAB55DA1AA@acm.org>
References: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<48A9ECDD.5050206@holdenweb.com>
	<CAB6F7AD-F0C9-40A6-86DA-7FEAB55DA1AA@acm.org>
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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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 <http://python.net/~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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<48A9ECDD.5050206@holdenweb.com>
	<CAB6F7AD-F0C9-40A6-86DA-7FEAB55DA1AA@acm.org>
	<572697F6-D394-4906-965B-54723AF8E1E2@python.org>
Message-ID: <6a36e7290808181557t3cd94a2aw27b5537fbefd9140@mail.gmail.com>

On Mon, Aug 18, 2008 at 3:41 PM, Barry Warsaw <barry at python.org> 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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>	<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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>	<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: <bbaeab100808161252l3ed4b26fjee08b4bbc1f8f5ce@mail.gmail.com>
References: <e04bdf310808160704g36140bfbod0b68d38e91b9ed1@mail.gmail.com>
	<bbaeab100808161252l3ed4b26fjee08b4bbc1f8f5ce@mail.gmail.com>
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
><facundobatista at gmail.com> 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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
References: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
Message-ID: <B5A17C27-01B3-4857-953A-89025B40FA36@mac.com>


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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>	<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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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   <fdrake at acm.org>


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 <barry at python.org> 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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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 <wink>.  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: <ca816810808190653j60edeac3r142d4292d768a30f@mail.gmail.com>

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/<snip>/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: <E07C53F9-AB37-40F3-8507-F737CFDAC817@python.org>

-----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 <barry at python.org>  
> 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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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 <fdrake at acm.org> 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   <fdrake at acm.org>

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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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: <FAE51579-F66E-44BC-A1DB-02761CC8588F@acm.org>

[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   <fdrake at acm.org>


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: <ca816810808190653j60edeac3r142d4292d768a30f@mail.gmail.com>
References: <ca816810808190653j60edeac3r142d4292d768a30f@mail.gmail.com>
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: <bbaeab100808181213l75b4bff4kf3308b73ea9a85f2@mail.gmail.com>
References: <18601.22584.469957.920301@montanaro-dyndns-org.local>	<48A95E7D.1010002@gmail.com>	<bbaeab100808181032i4717c91x3cccbbf0aba54473@mail.gmail.com>	<loom.20080818T184304-797@post.gmane.org>	<67B54E00-976A-459B-937A-11B35CF4805E@acm.org>
	<bbaeab100808181213l75b4bff4kf3308b73ea9a85f2@mail.gmail.com>
Message-ID: <48AAEAC6.10702@gmail.com>

Brett Cannon wrote:
> On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake <fdrake at acm.org> 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: <ca816810808190653j60edeac3r142d4292d768a30f@mail.gmail.com>
References: <ca816810808190653j60edeac3r142d4292d768a30f@mail.gmail.com>
Message-ID: <e6268af30808191004o147e1dbfj9dd67ffb9a756e7b@mail.gmail.com>

> ImportError: cannot import name annotate from /usr/<snip>/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: <http://mail.python.org/pipermail/python-dev/attachments/20080820/cd42b4b0/attachment.htm>

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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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: <e6268af30808191004o147e1dbfj9dd67ffb9a756e7b@mail.gmail.com>
References: <ca816810808190653j60edeac3r142d4292d768a30f@mail.gmail.com>
	<e6268af30808191004o147e1dbfj9dd67ffb9a756e7b@mail.gmail.com>
Message-ID: <e6268af30808191017v5c4c5fb8tefff5e7504ddc05@mail.gmail.com>

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_GetAttrString<http://www.python.org/doc/api/object.html>and
PyString_FromString
<http://www.python.org/doc/api/stringObjects.html>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: <http://mail.python.org/pipermail/python-dev/attachments/20080820/3359b6a0/attachment-0001.htm>

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>
	<bbaeab100808181032i4717c91x3cccbbf0aba54473@mail.gmail.com>
	<loom.20080818T184304-797@post.gmane.org>
	<67B54E00-976A-459B-937A-11B35CF4805E@acm.org>
	<bbaeab100808181213l75b4bff4kf3308b73ea9a85f2@mail.gmail.com>
	<48AAEAC6.10702@gmail.com>
Message-ID: <ca471dc20808191025j61315972of9bf719011df4b1e@mail.gmail.com>

On Tue, Aug 19, 2008 at 8:46 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Brett Cannon wrote:
>> On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake <fdrake at acm.org> 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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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: <E68FE43B-1665-4199-80A6-73A7A7381166@python.org>

-----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>
	<bbaeab100808181032i4717c91x3cccbbf0aba54473@mail.gmail.com>
	<loom.20080818T184304-797@post.gmane.org>
	<67B54E00-976A-459B-937A-11B35CF4805E@acm.org>
	<bbaeab100808181213l75b4bff4kf3308b73ea9a85f2@mail.gmail.com>
	<48AAEAC6.10702@gmail.com>
Message-ID: <bbaeab100808191131t11876a6djb7e1e030081aa7ba@mail.gmail.com>

On Tue, Aug 19, 2008 at 8:46 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Brett Cannon wrote:
>> On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake <fdrake at acm.org> 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: <bbaeab100808191131t11876a6djb7e1e030081aa7ba@mail.gmail.com>
References: <18601.22584.469957.920301@montanaro-dyndns-org.local>
	<48A95E7D.1010002@gmail.com>
	<bbaeab100808181032i4717c91x3cccbbf0aba54473@mail.gmail.com>
	<loom.20080818T184304-797@post.gmane.org>
	<67B54E00-976A-459B-937A-11B35CF4805E@acm.org>
	<bbaeab100808181213l75b4bff4kf3308b73ea9a85f2@mail.gmail.com>
	<48AAEAC6.10702@gmail.com>
	<bbaeab100808191131t11876a6djb7e1e030081aa7ba@mail.gmail.com>
Message-ID: <E5CEDD7E-4315-4A44-811E-8ECF2FC5D307@python.org>

-----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 <ncoghlan at gmail.com>  
> wrote:
>> Brett Cannon wrote:
>>> On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake <fdrake at acm.org> 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: <ca471dc20808191319g2959d506vbb29cb4761bd974d@mail.gmail.com>

On Mon, Aug 18, 2008 at 8:29 PM, Barry Warsaw <barry at python.org> 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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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: <F2186A3E-B795-4AC3-9CE1-37D4960FCFC9@cwi.nl>


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, <Jack.Jansen at cwi.nl>, 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: <http://mail.python.org/pipermail/python-dev/attachments/20080819/ee6dbf98/attachment-0001.htm>

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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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 <janssen at parc.com> 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: <ca471dc20808191319g2959d506vbb29cb4761bd974d@mail.gmail.com>
References: <20080818232950.5f234f31@resist.wooz.org>
	<ca471dc20808191319g2959d506vbb29cb4761bd974d@mail.gmail.com>
Message-ID: <ca471dc20808191403m128d76b4t14f4c2d29cfcf9dd@mail.gmail.com>

On Tue, Aug 19, 2008 at 1:19 PM, Guido van Rossum <guido at python.org> 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()<timeout)
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.

Cheers,

Mark


From barry at python.org  Thu Aug 21 14:28:47 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 21 Aug 2008 08:28:47 -0400
Subject: [Python-Dev] 2.6 on Windows
In-Reply-To: <017501c9033e$9accf9b0$d066ed10$@com.au>
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()<timeout)
> 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 <barry at python.org> 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: <op.uf8plqmx03jqhe@cesareprova.org>

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 "<stdin>", line 1, in <module>
  File "c:\tmp\Python-2.6b3\lib\lib-tk\Tkinter.py", line 38, in <module>
    import FixTk
  File "c:\tmp\Python-2.6b3\lib\lib-tk\FixTk.py", line 28, in <module>
    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 <barry at python.org> 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: <op.uf8plqmx03jqhe@cesareprova.org>
References: <20080820231715.57fde07f@resist.wooz.org>
	<1afaf6160808210633k1ba326ber2bd87eda693f13f5@mail.gmail.com>
	<op.uf8plqmx03jqhe@cesareprova.org>
Message-ID: <d2155e360808210834l30888700l87923905ebf5b357@mail.gmail.com>

On Thu, Aug 21, 2008 at 7:09 AM, Cesare Di Mauro
<cesare.dimauro at a-tono.com> wrote:
>
>>>> import Tkinter
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "c:\tmp\Python-2.6b3\lib\lib-tk\Tkinter.py", line 38, in <module>
>    import FixTk
>  File "c:\tmp\Python-2.6b3\lib\lib-tk\FixTk.py", line 28, in <module>
>    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: <d2155e360808210834l30888700l87923905ebf5b357@mail.gmail.com>
References: <20080820231715.57fde07f@resist.wooz.org>
	<1afaf6160808210633k1ba326ber2bd87eda693f13f5@mail.gmail.com>
	<op.uf8plqmx03jqhe@cesareprova.org>
	<d2155e360808210834l30888700l87923905ebf5b357@mail.gmail.com>
Message-ID: <op.uf8vqgs003jqhe@cesareprova.org>

Thank you for the hint: it works. :)

Cesare

In data 21 agosto 2008 alle ore 17:34:56, Curt Hagenlocher <curt at hagenlocher.org> ha scritto:

> On Thu, Aug 21, 2008 at 7:09 AM, Cesare Di Mauro
> <cesare.dimauro at a-tono.com> wrote:
>>
>>>>> import Tkinter
>> Traceback (most recent call last):
>>  File "<stdin>", line 1, in <module>
>>  File "c:\tmp\Python-2.6b3\lib\lib-tk\Tkinter.py", line 38, in <module>
>>    import FixTk
>>  File "c:\tmp\Python-2.6b3\lib\lib-tk\FixTk.py", line 28, in <module>
>>    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: <loom.20080821T171500-973@post.gmane.org>

Mark Hammond <mhammond <at> 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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>

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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com><59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org><ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com><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: <g8ko82$8f6$1@ger.gmane.org>


"Jesse Noller" <jnoller at gmail.com> wrote in message 
news:4222a8490808191344y6af0b4a3pe7f99dcd263e162e at mail.gmail.com...
> On Tue, Aug 19, 2008 at 1:28 PM, Bill Janssen <janssen at parc.com> 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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
Message-ID: <g8kqb0$fan$1@ger.gmane.org>



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: <loom.20080821T171500-973@post.gmane.org>
References: <016201c90336$ea16cd50$be4467f0$@com.au>
	<loom.20080821T171500-973@post.gmane.org>
Message-ID: <026301c903e5$b53a22d0$1fae6870$@com.au>

Antoine writes:

> Mark Hammond <mhammond <at> 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 <wink>

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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<48ADDD94.2080903@egenix.com>
Message-ID: <ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>

On Thu, Aug 21, 2008 at 2:26 PM, M.-A. Lemburg <mal at egenix.com> 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>
	<loom.20080821T171500-973@post.gmane.org>
	<026301c903e5$b53a22d0$1fae6870$@com.au>
Message-ID: <loom.20080822T090554-329@post.gmane.org>


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: <ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<48ADDD94.2080903@egenix.com>
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>
Message-ID: <368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com>

On Fri, Aug 22, 2008 at 3:25 AM, Guido van Rossum <guido at python.org> 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?)

</F>

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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
Message-ID: <e04bdf310808220642l7a591f10r620de11bde9ef85f@mail.gmail.com>

2008/8/21 Guido van Rossum <guido at python.org>:

> 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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<e04bdf310808220642l7a591f10r620de11bde9ef85f@mail.gmail.com>
Message-ID: <loom.20080822T145209-49@post.gmane.org>

Facundo Batista <facundobatista <at> 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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<48ADDD94.2080903@egenix.com>
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>
	<368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com>
Message-ID: <ca471dc20808220759g5697f8afkea4b14e65f62490d@mail.gmail.com>

On Fri, Aug 22, 2008 at 3:47 AM, Fredrik Lundh <fredrik at pythonware.com> wrote:
> On Fri, Aug 22, 2008 at 3:25 AM, Guido van Rossum <guido at python.org> 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: <e04bdf310808220642l7a591f10r620de11bde9ef85f@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<e04bdf310808220642l7a591f10r620de11bde9ef85f@mail.gmail.com>
Message-ID: <ca471dc20808220805l753051ddj8a119b32bf137080@mail.gmail.com>

On Fri, Aug 22, 2008 at 6:42 AM, Facundo Batista
<facundobatista at gmail.com> 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 <solipsis at pitrou.net> 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: <a4d5dbb4-727f-484a-8c89-0e88ea0f08a9@f63g2000hsf.googlegroups.com>

  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: <ca471dc20808220759g5697f8afkea4b14e65f62490d@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<48ADDD94.2080903@egenix.com>
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>
	<368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com>
	<ca471dc20808220759g5697f8afkea4b14e65f62490d@mail.gmail.com>
Message-ID: <368a5cd50808220813r6e48c6a5w25413e1a1c17946a@mail.gmail.com>

On Fri, Aug 22, 2008 at 4:59 PM, Guido van Rossum <guido at python.org> 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 ;-)

</F>

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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<48ADDD94.2080903@egenix.com>
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>
	<368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com>
	<ca471dc20808220759g5697f8afkea4b14e65f62490d@mail.gmail.com>
	<368a5cd50808220813r6e48c6a5w25413e1a1c17946a@mail.gmail.com>
Message-ID: <ca471dc20808220912x5f5dd033pb2f41409c89c0d3c@mail.gmail.com>

2008/8/22 Fredrik Lundh <fredrik at pythonware.com>:
> On Fri, Aug 22, 2008 at 4:59 PM, Guido van Rossum <guido at python.org>
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: <http://mail.python.org/pipermail/python-dev/attachments/20080822/b9223317/attachment.htm>

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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<48ADDD94.2080903@egenix.com>
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>
	<368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com>
	<ca471dc20808220759g5697f8afkea4b14e65f62490d@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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<48ADDD94.2080903@egenix.com>
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>
	<368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com>
	<ca471dc20808220759g5697f8afkea4b14e65f62490d@mail.gmail.com>
	<368a5cd50808220813r6e48c6a5w25413e1a1c17946a@mail.gmail.com>
	<368a5cd50808220815s45ace95di50b67fcf12545889@mail.gmail.com>
Message-ID: <ca471dc20808220951t1bab868apbbff4f98f2d8ef42@mail.gmail.com>

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 <fredrik at pythonware.com> 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: <ca471dc20808220759g5697f8afkea4b14e65f62490d@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<48ADDD94.2080903@egenix.com>
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>
	<368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com>
	<ca471dc20808220759g5697f8afkea4b14e65f62490d@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: <a4d5dbb4-727f-484a-8c89-0e88ea0f08a9@f63g2000hsf.googlegroups.com>
References: <a4d5dbb4-727f-484a-8c89-0e88ea0f08a9@f63g2000hsf.googlegroups.com>
Message-ID: <1afaf6160808221118p3a6f032btf0e93183798362a7@mail.gmail.com>

On Fri, Aug 22, 2008 at 9:03 AM, harp <horvath.arpad at roik.bmf.hu> 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: <g8ne6n$rsb$1@ger.gmane.org>

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: <loom.20080822T090554-329@post.gmane.org>
References: <016201c90336$ea16cd50$be4467f0$@com.au>
	<loom.20080821T171500-973@post.gmane.org>
	<026301c903e5$b53a22d0$1fae6870$@com.au>
	<loom.20080822T090554-329@post.gmane.org>
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: <g8ooso$sic$1@ger.gmane.org>

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.

</F>


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: <g8ooso$sic$1@ger.gmane.org>
References: <4895EE62.8080605@korokithakis.net> <4895F311.60200@palladion.com>
	<g8ooso$sic$1@ger.gmane.org>
Message-ID: <Pine.GSO.4.64.0808230752001.29416@core.cs.uwaterloo.ca>

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: <Pine.GSO.4.64.0808230752001.29416@core.cs.uwaterloo.ca>
References: <4895EE62.8080605@korokithakis.net>
	<4895F311.60200@palladion.com>	<g8ooso$sic$1@ger.gmane.org>
	<Pine.GSO.4.64.0808230752001.29416@core.cs.uwaterloo.ca>
Message-ID: <g8p0lh$ga6$1@ger.gmane.org>

 >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.

<F>


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: <g8pe75$lc2$1@ger.gmane.org>

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?

</F>


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: <bbaeab100808231353k188d7e5ey9e5891e7bdfffae5@mail.gmail.com>
References: <20080823202744.367931E4003@bag.python.org>	<bbaeab100808231348t10332314jca1fda6a4424d272@mail.gmail.com>	<1afaf6160808231350y44b9d53i4e4e534ede049260@mail.gmail.com>
	<bbaeab100808231353k188d7e5ey9e5891e7bdfffae5@mail.gmail.com>
Message-ID: <48B0D1EE.6050903@gmail.com>

Brett Cannon wrote:
> On Sat, Aug 23, 2008 at 1:50 PM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
>> On Sat, Aug 23, 2008 at 3:48 PM, Brett Cannon <brett at python.org> 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: <ee2a432c0808232212v1a634d6fo97a0a2c9ae5ae398@mail.gmail.com>

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: <g8pe75$lc2$1@ger.gmane.org>
References: <g8pe75$lc2$1@ger.gmane.org>
Message-ID: <e27efe130808240240m73f738b0yf5439c4f726b2389@mail.gmail.com>

Hello,

2008/8/23 Fredrik Lundh <fredrik at pythonware.com>:
> 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: <e27efe130808240240m73f738b0yf5439c4f726b2389@mail.gmail.com>
References: <g8pe75$lc2$1@ger.gmane.org>
	<e27efe130808240240m73f738b0yf5439c4f726b2389@mail.gmail.com>
Message-ID: <g8rar8$2vi$1@ger.gmane.org>

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.

</F>


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: <g8rar8$2vi$1@ger.gmane.org>
References: <g8pe75$lc2$1@ger.gmane.org>	<e27efe130808240240m73f738b0yf5439c4f726b2389@mail.gmail.com>
	<g8rar8$2vi$1@ger.gmane.org>
Message-ID: <g8rf6o$dld$1@ger.gmane.org>

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: <ee2a432c0808232212v1a634d6fo97a0a2c9ae5ae398@mail.gmail.com>
References: <ee2a432c0808232212v1a634d6fo97a0a2c9ae5ae398@mail.gmail.com>
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: <ee2a432c0808232212v1a634d6fo97a0a2c9ae5ae398@mail.gmail.com>
Message-ID: <loom.20080824T122023-961@post.gmane.org>

Neal Norwitz <nnorwitz <at> 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: <ee2a432c0808232212v1a634d6fo97a0a2c9ae5ae398@mail.gmail.com>
	<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: <g8rf6o$dld$1@ger.gmane.org>
References: <g8pe75$lc2$1@ger.gmane.org>	<e27efe130808240240m73f738b0yf5439c4f726b2389@mail.gmail.com>	<g8rar8$2vi$1@ger.gmane.org>
	<g8rf6o$dld$1@ger.gmane.org>
Message-ID: <g8rnin$4s7$1@ger.gmane.org>

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.)

</F>

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: <g8rnin$4s7$1@ger.gmane.org>
References: <g8pe75$lc2$1@ger.gmane.org>	<e27efe130808240240m73f738b0yf5439c4f726b2389@mail.gmail.com>	<g8rar8$2vi$1@ger.gmane.org>	<g8rf6o$dld$1@ger.gmane.org>
	<g8rnin$4s7$1@ger.gmane.org>
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: <e6268af30808240643o1db3b90at9c716705db62a886@mail.gmail.com>

Hi Michele,

Do you have a URL for this blog?

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20080824/7b9e2265/attachment.htm>

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: <e6268af30808240815l75b4d74eq6b687d0df93cb2ee@mail.gmail.com>
References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com>
	<e6268af30808240643o1db3b90at9c716705db62a886@mail.gmail.com>
	<6cd7c525-dd2e-4389-b5ec-73617bfefbf1@m45g2000hsb.googlegroups.com>
	<e6268af30808240815l75b4d74eq6b687d0df93cb2ee@mail.gmail.com>
Message-ID: <e6268af30808240817g6473dac2o9f36ae983338d2e4@mail.gmail.com>

Had a brief offline discussion with Michele - forwarding.

---------- Forwarded message ----------
From: michele.simionato at gmail.com <michele.simionato at gmail.com>
Date: Mon, Aug 25, 2008 at 12:13 AM

On Aug 24, 3:43 pm, "Matt Giuca" <matt.gi... at gmail.com> 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 <matt.giuca at gmail.com>
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: <http://mail.python.org/pipermail/python-dev/attachments/20080825/71a6b9e4/attachment.htm>

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: <loom.20080824T122023-961@post.gmane.org>
References: <ee2a432c0808232212v1a634d6fo97a0a2c9ae5ae398@mail.gmail.com>
	<loom.20080824T122023-961@post.gmane.org>
Message-ID: <ee2a432c0808241025m199355by88dfd1dc53451474@mail.gmail.com>

Thanks Antoine!

On Sun, Aug 24, 2008 at 5:58 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Neal Norwitz <nnorwitz <at> 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: <ee2a432c0808241025m199355by88dfd1dc53451474@mail.gmail.com>
References: <ee2a432c0808232212v1a634d6fo97a0a2c9ae5ae398@mail.gmail.com>
	<loom.20080824T122023-961@post.gmane.org>
	<ee2a432c0808241025m199355by88dfd1dc53451474@mail.gmail.com>
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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	
	<48ADDD94.2080903@egenix.com>	
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.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: <ca471dc20808220759g5697f8afkea4b14e65f62490d@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	
	<48ADDD94.2080903@egenix.com>	
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>	
	<368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com>
	<ca471dc20808220759g5697f8afkea4b14e65f62490d@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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	
	<48ADDD94.2080903@egenix.com>	
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>	
	<368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com>	
	<ca471dc20808220759g5697f8afkea4b14e65f62490d@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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	
	<48ADDD94.2080903@egenix.com>	
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>	
	<368a5cd50808220347o403844d3m9dc856184ac7da79@mail.gmail.com>
	<ca471dc20808220759g5697f8afkea4b14e65f62490d@mail.gmail.com>
	<48B1B92D.3090204@v.loewis.de>
Message-ID: <loom.20080824T194519-258@post.gmane.org>

Martin v. L?wis <martin <at> 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: <ee2a432c0808232212v1a634d6fo97a0a2c9ae5ae398@mail.gmail.com>	<loom.20080824T122023-961@post.gmane.org>	<ee2a432c0808241025m199355by88dfd1dc53451474@mail.gmail.com>
	<1219604656.5635.2.camel@fsol>
Message-ID: <g8snrg$9ng$1@ger.gmane.org>

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: <ee2a432c0808232212v1a634d6fo97a0a2c9ae5ae398@mail.gmail.com>
	<ee2a432c0808241025m199355by88dfd1dc53451474@mail.gmail.com>
	<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: <ee2a432c0808241815n57de2264o2c958327968673da@mail.gmail.com>

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: <ee2a432c0808241815n57de2264o2c958327968673da@mail.gmail.com>
References: <ee2a432c0808241815n57de2264o2c958327968673da@mail.gmail.com>
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: <e6268af30808240643o1db3b90at9c716705db62a886@mail.gmail.com>
References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com>
	<e6268af30808240643o1db3b90at9c716705db62a886@mail.gmail.com>
Message-ID: <922fecbe-e873-4df9-ada1-52730ba53388@79g2000hsk.googlegroups.com>



On Aug 24, 3:43?pm, "Matt Giuca" <matt.gi... at gmail.com> 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: <d5bf79c60808180905g570713c8ib041692c0bc2580e@mail.gmail.com>
	<59C86CC6-D154-4704-81B9-8AB3CB408E6F@python.org>
	<ca471dc20808181308w73aba171kc73853dda65ee699@mail.gmail.com>
	<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: <e27efe130808250422n49297bbesee824b1230256c52@mail.gmail.com>

Hello,

2008/8/25 Robert Schuppenies <robert.schuppenies at 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'?

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: <http://mail.python.org/pipermail/python-dev/attachments/20080825/bc93b24a/attachment.py>

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: <e04bdf310808220642l7a591f10r620de11bde9ef85f@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<e04bdf310808220642l7a591f10r620de11bde9ef85f@mail.gmail.com>
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: <a4d5dbb4-727f-484a-8c89-0e88ea0f08a9@f63g2000hsf.googlegroups.com>
	<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 <module>
    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" <musiccomposit... at gmail.com>
wrote:
> On Fri, Aug 22, 2008 at 9:03 AM, harp <horvath.ar... at roik.bmf.hu> 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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
Message-ID: <19e566510808250643v496a138dp64fa45f3eda9ee8d@mail.gmail.com>

Hi,

On Thu, Aug 21, 2008 at 23:35, Guido van Rossum <guido at python.org> 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: <ee2a432c0808232212v1a634d6fo97a0a2c9ae5ae398@mail.gmail.com>	<loom.20080824T122023-961@post.gmane.org>	<ee2a432c0808241025m199355by88dfd1dc53451474@mail.gmail.com>
	<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: <ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	<48ADDD94.2080903@egenix.com>
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.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 <mal at egenix.com> 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: <ee2a432c0808232212v1a634d6fo97a0a2c9ae5ae398@mail.gmail.com>	<loom.20080824T122023-961@post.gmane.org>	<ee2a432c0808241025m199355by88dfd1dc53451474@mail.gmail.com>
	<1219604656.5635.2.camel@fsol> <48B2BC69.3080601@egenix.com>
Message-ID: <loom.20080825T154043-614@post.gmane.org>

M.-A. Lemburg <mal <at> 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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<48ADDD94.2080903@egenix.com>
	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>
	<48B2C689.5030503@egenix.com>
Message-ID: <ca471dc20808250904v788aeeceice1d4bb1acaef99a@mail.gmail.com>

2008/8/25 M.-A. Lemburg <mal at egenix.com>:
> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080825/06697171/attachment.htm>

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: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>

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: <ca471dc20808250904v788aeeceice1d4bb1acaef99a@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	<48ADDD94.2080903@egenix.com>	<ca471dc20808211825m498127d3n4cc85521de7cff2@mail.gmail.com>	<48B2C689.5030503@egenix.com>
	<ca471dc20808250904v788aeeceice1d4bb1acaef99a@mail.gmail.com>
Message-ID: <g8up7r$v30$1@ger.gmane.org>



Guido van Rossum wrote:
> 2008/8/25 M.-A. Lemburg <mal at egenix.com <mailto:mal at egenix.com>>:
>  > 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: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
References: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
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: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
	<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: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
	<989B2B74-D5AB-4FAA-BE6D-8D409D194388@python.org>
Message-ID: <ca471dc20808251034j1e116207t46c114925ec38360@mail.gmail.com>

On Mon, Aug 25, 2008 at 10:30 AM, Barry Warsaw <barry at python.org> 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: <g8kqb0$fan$1@ger.gmane.org>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<g8kqb0$fan$1@ger.gmane.org>
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: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
	<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 <wink>.

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: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
	<989B2B74-D5AB-4FAA-BE6D-8D409D194388@python.org>
Message-ID: <d11dcfba0808251039x5f6fa163jc6c5832baf4b18ba@mail.gmail.com>

On Mon, Aug 25, 2008 at 11:30 AM, Barry Warsaw <barry at python.org> 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: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
References: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
Message-ID: <F1962646D3B64642B7C9A06068EE1E64048234FC@ex10.hostedexchange.local>

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: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
Message-ID: <20080825174409.29191.1018559950.divmod.quotient.18404@ohm>

On Mon, 25 Aug 2008 10:13:32 -0700, Guido van Rossum <guido at python.org> 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 <http://twistedmatrix.com/trac/ticket/1123>) 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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<g8kqb0$fan$1@ger.gmane.org>
	<57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org>
Message-ID: <1afaf6160808251052q78fea0c2u4ca97ac911bab7e7@mail.gmail.com>

On Mon, Aug 25, 2008 at 12:34 PM, Barry Warsaw <barry at python.org> 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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	<g8kqb0$fan$1@ger.gmane.org>
	<57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org>
Message-ID: <g8uri2$83k$1@ger.gmane.org>

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).

</F>


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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<g8kqb0$fan$1@ger.gmane.org>
	<57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org>
	<1afaf6160808251052q78fea0c2u4ca97ac911bab7e7@mail.gmail.com>
Message-ID: <ca471dc20808251056y48f1b51enc57bfda46bd29f1@mail.gmail.com>

On Mon, Aug 25, 2008 at 10:52 AM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> On Mon, Aug 25, 2008 at 12:34 PM, Barry Warsaw <barry at python.org> 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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	<g8kqb0$fan$1@ger.gmane.org>
	<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: <ca471dc20808251056y48f1b51enc57bfda46bd29f1@mail.gmail.com>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>
	<g8kqb0$fan$1@ger.gmane.org>
	<57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org>
	<1afaf6160808251052q78fea0c2u4ca97ac911bab7e7@mail.gmail.com>
	<ca471dc20808251056y48f1b51enc57bfda46bd29f1@mail.gmail.com>
Message-ID: <bbaeab100808251116x52f41ebiadc8f3c4f0e14dd3@mail.gmail.com>

On Mon, Aug 25, 2008 at 10:56 AM, Guido van Rossum <guido at python.org> wrote:
> On Mon, Aug 25, 2008 at 10:52 AM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
>> On Mon, Aug 25, 2008 at 12:34 PM, Barry Warsaw <barry at python.org> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080825/4e93c7e7/attachment.patch>
-------------- 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: <http://mail.python.org/pipermail/python-dev/attachments/20080825/4e93c7e7/attachment.pgp>

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: <g8uri2$83k$1@ger.gmane.org>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	<g8kqb0$fan$1@ger.gmane.org>
	<57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org>
	<g8uri2$83k$1@ger.gmane.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 <wink>.

- -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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	<g8kqb0$fan$1@ger.gmane.org>
	<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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	<g8kqb0$fan$1@ger.gmane.org>	<57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org>	<g8uri2$83k$1@ger.gmane.org>
	<6DD88C6B-7586-43C9-A060-A1D8C5D3E4E3@python.org>
Message-ID: <g8v0g0$rdg$1@ger.gmane.org>

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 <wink>.

Well, at least Guido managed to figure out what I was trying to say ;-)

</F>


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: <g8v0g0$rdg$1@ger.gmane.org>
References: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	<g8kqb0$fan$1@ger.gmane.org>	<57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org>	<g8uri2$83k$1@ger.gmane.org>
	<6DD88C6B-7586-43C9-A060-A1D8C5D3E4E3@python.org>
	<g8v0g0$rdg$1@ger.gmane.org>
Message-ID: <AF8E38A3-D2F2-4A8F-A6FA-C97719F6F9FD@python.org>

-----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 <wink>.
>
> 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: <e27efe130808250422n49297bbesee824b1230256c52@mail.gmail.com>
References: <48B26E30.3020701@gmail.com>
	<e27efe130808250422n49297bbesee824b1230256c52@mail.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>	<e27efe130808250422n49297bbesee824b1230256c52@mail.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: <ca471dc20808211335p326048a3g228bf77c80262d6e@mail.gmail.com>	<g8kqb0$fan$1@ger.gmane.org>
	<57CCEBDE-ABE7-46A9-AD3F-4843FF9E1F98@python.org>
Message-ID: <g8vd9a$bfu$1@ger.gmane.org>

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: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
References: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
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: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
	<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: <http://mail.python.org/pipermail/python-dev/attachments/20080826/e76bcc05/attachment.htm>

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: <E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>

[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: <loom.20080826T154107-870@post.gmane.org>


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: <E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
Message-ID: <4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>

On Tue, Aug 26, 2008 at 5:32 PM, Raymond Hettinger <python at rcn.com> 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: <loom.20080826T154107-870@post.gmane.org>
References: <loom.20080826T154107-870@post.gmane.org>
Message-ID: <1afaf6160808260942t27091332ncc8b786e5781ffbb@mail.gmail.com>

On Tue, Aug 26, 2008 at 10:53 AM, Antoine Pitrou <solipsis at pitrou.net> 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: <loom.20080826T154107-870@post.gmane.org>
	<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  
> <solipsis at pitrou.net> 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: <rowen-40181E.10590926082008@news.gmane.org>

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: <loom.20080826T154107-870@post.gmane.org>
References: <loom.20080826T154107-870@post.gmane.org>
Message-ID: <bbaeab100808261147l707b50bck87ca9ec7cee5521@mail.gmail.com>

On Tue, Aug 26, 2008 at 8:53 AM, Antoine Pitrou <solipsis at pitrou.net> 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><E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
Message-ID: <DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>

[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: <loom.20080826T190254-149@post.gmane.org>

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 "<stdin>", line 1, in <module>
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: <loom.20080826T190254-149@post.gmane.org>
References: <loom.20080826T190254-149@post.gmane.org>
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
<listreverseiterator object at 0x00D5C8F0>
>>> i
<listiterator object at 0x00D5C3F0>
>>> t = (1,2,3,4)
>>> it = iter(t)
>>> rit = reversed(t)
>>> it
<tupleiterator object at 0x00D5C030>
>>> rit
<reversed object at 0x00D5CC90>
>>>

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: <http://mail.python.org/pipermail/python-dev/attachments/20080826/9b0d71f1/attachment.htm>

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: <loom.20080826T190254-149@post.gmane.org>
	<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 'reversed'>
type(rt)
<type 'reversed'>
type(rl)
<type 'listreverseiterator'>
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: <http://mail.python.org/pipermail/python-dev/attachments/20080826/2f616072/attachment.htm>

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: <loom.20080826T190254-149@post.gmane.org>
	<1bc395c10808261221n5e6e7c88le0f30f7199e0cee2@mail.gmail.com>
	<1bc395c10808261247n5b658197g8872539a757e7c33@mail.gmail.com>
Message-ID: <loom.20080826T200042-935@post.gmane.org>

Jeff Hall <hall.jeff <at> 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: <loom.20080826T190254-149@post.gmane.org>
Message-ID: <D9EC151CBA234F7FBB1636B7ABD0EDD5@RaymondLaptop1>

From: "Armin Ronacher" <armin.ronacher at active-4.com>
>>>> 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: <loom.20080826T190254-149@post.gmane.org>	<1bc395c10808261221n5e6e7c88le0f30f7199e0cee2@mail.gmail.com>
	<1bc395c10808261247n5b658197g8872539a757e7c33@mail.gmail.com>
Message-ID: <g91p61$18q$1@ger.gmane.org>

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: <rowen-40181E.10590926082008@news.gmane.org>
References: <rowen-40181E.10590926082008@news.gmane.org>
Message-ID: <1afaf6160808261335u2dfb92m6a538b2dbdf1b886@mail.gmail.com>

On Tue, Aug 26, 2008 at 12:59 PM, Russell E. Owen
<rowen at u.washington.edu> 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>	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
Message-ID: <g91rfo$blm$1@ger.gmane.org>

Michele Simionato wrote:
> On Tue, Aug 26, 2008 at 5:32 PM, Raymond Hettinger <python at rcn.com> 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: <loom.20080826T154107-870@post.gmane.org>
	<1afaf6160808260942t27091332ncc8b786e5781ffbb@mail.gmail.com>
Message-ID: <loom.20080826T222505-697@post.gmane.org>

Benjamin Peterson <musiccomposition <at> 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: <loom.20080826T154107-870@post.gmane.org>
	<bbaeab100808261147l707b50bck87ca9ec7cee5521@mail.gmail.com>
Message-ID: <loom.20080826T222726-161@post.gmane.org>

Brett Cannon <brett <at> 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: <ee2a432c0808232212v1a634d6fo97a0a2c9ae5ae398@mail.gmail.com>
	<loom.20080824T122023-961@post.gmane.org>
	<ee2a432c0808241025m199355by88dfd1dc53451474@mail.gmail.com>
	<1219604656.5635.2.camel@fsol>
Message-ID: <loom.20080826T231008-34@post.gmane.org>

Antoine Pitrou <solipsis <at> 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: <loom.20080826T222726-161@post.gmane.org>
References: <loom.20080826T154107-870@post.gmane.org>
	<bbaeab100808261147l707b50bck87ca9ec7cee5521@mail.gmail.com>
	<loom.20080826T222726-161@post.gmane.org>
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 <brett <at> 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: <DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
Message-ID: <4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com>

On Tue, Aug 26, 2008 at 8:56 PM, Raymond Hettinger <python at rcn.com> 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>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com>
Message-ID: <e8a0972d0808261830j37f0b727gc434694ba9f7ebf7@mail.gmail.com>

On Tue, Aug 26, 2008 at 6:16 PM, Michele Simionato
<michele.simionato at gmail.com> 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: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
References: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
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>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<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: <e8a0972d0808261830j37f0b727gc434694ba9f7ebf7@mail.gmail.com>
References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com>
	<e8a0972d0808261830j37f0b727gc434694ba9f7ebf7@mail.gmail.com>
Message-ID: <4edc17eb0808262018yc904c4dq5320e165ac7dd4c5@mail.gmail.com>

On Wed, Aug 27, 2008 at 3:30 AM, Alex Martelli <aleaxit at gmail.com> wrote:
> On Tue, Aug 26, 2008 at 6:16 PM, Michele Simionato
> <michele.simionato at gmail.com> 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>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
Message-ID: <4edc17eb0808262048j200f4640v10dff6bc11c434ad@mail.gmail.com>

On Tue, Aug 26, 2008 at 6:13 PM, Michele Simionato
<michele.simionato at gmail.com> 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>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<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 <pje at telecommunity.com> 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: <g91rfo$blm$1@ger.gmane.org>
References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<g91rfo$blm$1@ger.gmane.org>
Message-ID: <4edc17eb0808262302gc770ec6s5d72f5db011f9626@mail.gmail.com>

On Tue, Aug 26, 2008 at 11:10 PM, Steve Holden <steve at holdenweb.com> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080827/08e9ac5f/attachment.htm>

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: <op.ugjadrtf03jqhe@cesareprova.org>

On 27 agu 2008 at 08:46:15, Kilian Klimek <kilian.klimek at googlemail.com> 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 
> <http://www-lehre.inf.uos.de/%7Ekklimek/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: <g930ce$575$1@ger.gmane.org>



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: <g930iq$4tn$1@ger.gmane.org>

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>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<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
<kilian.klimek at googlemail.com> 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
> <kilian.klimek at googlemail.com> 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>	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>	<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: <op.ugjadrtf03jqhe@cesareprova.org>
References: <647a40920808262346y5c5593fal285afe85a39a27b4@mail.gmail.com>
	<op.ugjadrtf03jqhe@cesareprova.org>
Message-ID: <647a40920808270647t5b67005cyb7f7c574b8d1075f@mail.gmail.com>

On Wed, Aug 27, 2008 at 9:14 AM, Cesare Di Mauro
<cesare.dimauro at a-tono.com>wrote:

> On 27 agu 2008 at 08:46:15, Kilian Klimek <kilian.klimek at googlemail.com>
> 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<http://www-lehre.inf.uos.de/%7Ekklimek/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: <http://mail.python.org/pipermail/python-dev/attachments/20080827/8198f7a6/attachment.htm>

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>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com>
	<20080827031445.C9B8B3A4079@sparrow.telecommunity.com>
	<4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com>
Message-ID: <e8a0972d0808270730j66fdf00ej91c8ecaded787c04@mail.gmail.com>

On Tue, Aug 26, 2008 at 10:24 PM, Michele Simionato
<michele.simionato at gmail.com> 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: <e8a0972d0808270730j66fdf00ej91c8ecaded787c04@mail.gmail.com>
References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com>
	<20080827031445.C9B8B3A4079@sparrow.telecommunity.com>
	<4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com>
	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@mail.gmail.com>
Message-ID: <4edc17eb0808270736s2a5b3211x15c20aa8f74f48eb@mail.gmail.com>

On Wed, Aug 27, 2008 at 4:30 PM, Alex Martelli <aleaxit at gmail.com> 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: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
	<056601c907f2$3d5f36e0$b81da4a0$@com.au>
Message-ID: <ca471dc20808270943q1783a036o4a6554626671b801@mail.gmail.com>

On Tue, Aug 26, 2008 at 8:08 PM, Mark Hammond <mhammond at skippinet.com.au> 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: <ca471dc20808270943q1783a036o4a6554626671b801@mail.gmail.com>
References: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>
	<056601c907f2$3d5f36e0$b81da4a0$@com.au>
	<ca471dc20808270943q1783a036o4a6554626671b801@mail.gmail.com>
Message-ID: <d2155e360808271003i29c062b6n711be7e2e02484e@mail.gmail.com>

On Wed, Aug 27, 2008 at 9:43 AM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Aug 26, 2008 at 8:08 PM, Mark Hammond <mhammond at skippinet.com.au> 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>	<op.ugjadrtf03jqhe@cesareprova.org>
	<647a40920808270647t5b67005cyb7f7c574b8d1075f@mail.gmail.com>
Message-ID: <g942nh$116$2@ger.gmane.org>

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.

</F>


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: <ca471dc20808270943q1783a036o4a6554626671b801@mail.gmail.com>
References: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>	<056601c907f2$3d5f36e0$b81da4a0$@com.au>
	<ca471dc20808270943q1783a036o4a6554626671b801@mail.gmail.com>
Message-ID: <g9436n$3p7$1@ger.gmane.org>

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).

</F>


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: <d2155e360808271003i29c062b6n711be7e2e02484e@mail.gmail.com>
References: <ca471dc20808251013j73d1eb3dx1852069b90878cf1@mail.gmail.com>	<056601c907f2$3d5f36e0$b81da4a0$@com.au>	<ca471dc20808270943q1783a036o4a6554626671b801@mail.gmail.com>
	<d2155e360808271003i29c062b6n711be7e2e02484e@mail.gmail.com>
Message-ID: <g943ac$3p7$2@ger.gmane.org>

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."

</F>


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: <g945v1$gd5$1@ger.gmane.org>

(using 3.0a4)

 >>> exec(open("file.py"))
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
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)

</F>


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: <g945v1$gd5$1@ger.gmane.org>
References: <g945v1$gd5$1@ger.gmane.org>
Message-ID: <g946ph$k58$1@ger.gmane.org>

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.)

</F>


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: <g945v1$gd5$1@ger.gmane.org>
References: <g945v1$gd5$1@ger.gmane.org>
Message-ID: <g94kr2$cob$1@ger.gmane.org>

Fredrik Lundh schrieb:
> (using 3.0a4)
> 
>  >>> exec(open("file.py"))
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080827/6e8ed9f7/attachment.bin>

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: <g94kr2$cob$1@ger.gmane.org>
References: <g945v1$gd5$1@ger.gmane.org> <g94kr2$cob$1@ger.gmane.org>
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 "<stdin>", line 1, in <module>
>> 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>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<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: <g946ph$k58$1@ger.gmane.org>
References: <g945v1$gd5$1@ger.gmane.org> <g946ph$k58$1@ger.gmane.org>
Message-ID: <ca471dc20808271810i79b96feeo538f9b56212773ab@mail.gmail.com>

2008/8/27 Fredrik Lundh <fredrik at pythonware.com>:
> 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 <stdio.h> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080827/fcc8b258/attachment-0001.htm>

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: <g94kr2$cob$1@ger.gmane.org>
References: <g945v1$gd5$1@ger.gmane.org> <g94kr2$cob$1@ger.gmane.org>
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 "<stdin>", line 1, in <module>
> > 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)
<module 'parrot' from 'parrot.pyc'>
>>> 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: <g945v1$gd5$1@ger.gmane.org> <g94kr2$cob$1@ger.gmane.org>
	<200808281121.15908.steve@pearwood.info>
Message-ID: <ca471dc20808272038t25c793acobf8fdbf894e3d358@mail.gmail.com>

On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano <steve at pearwood.info> 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 "<stdin>", line 1, in <module>
>> > 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)
> <module 'parrot' from 'parrot.pyc'>
>>>> 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: <e8a0972d0808270730j66fdf00ej91c8ecaded787c04@mail.gmail.com>
References: <54eae8eb-6cb1-4088-a277-7fad9b4225fd@m45g2000hsb.googlegroups.com>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com>
	<20080827031445.C9B8B3A4079@sparrow.telecommunity.com>
	<4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com>
	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@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]
  <class __main__.OldStyle at 0x777060>
  >>> New.__base__
  <class '__main__.NewStyle'>

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: <ca471dc20808272038t25c793acobf8fdbf894e3d358@mail.gmail.com>
References: <g945v1$gd5$1@ger.gmane.org>
	<200808281121.15908.steve@pearwood.info>
	<ca471dc20808272038t25c793acobf8fdbf894e3d358@mail.gmail.com>
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 <steve at pearwood.info> 
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: <ca471dc20808272038t25c793acobf8fdbf894e3d358@mail.gmail.com>
References: <g945v1$gd5$1@ger.gmane.org>
	<g94kr2$cob$1@ger.gmane.org>	<200808281121.15908.steve@pearwood.info>
	<ca471dc20808272038t25c793acobf8fdbf894e3d358@mail.gmail.com>
Message-ID: <g95ke6$ibh$1@ger.gmane.org>

Guido van Rossum wrote:
> On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano <steve at pearwood.info> 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 "<stdin>", line 1, in <module>
>>>> 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)
>> <module 'parrot' from 'parrot.pyc'>
>>>>> 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: <loom.20080828T102639-256@post.gmane.org>


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: <loom.20080828T102639-256@post.gmane.org>
References: <loom.20080828T102639-256@post.gmane.org>
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: <loom.20080828T102639-256@post.gmane.org>
	<04B40C81-D9DA-4F68-B23F-79FC31609E30@python.org>
Message-ID: <e04bdf310808280527g6ac0783ag7df717b1b9cb153e@mail.gmail.com>

2008/8/28 Barry Warsaw <barry at python.org>:

> 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: <loom.20080828T102639-256@post.gmane.org>
	<04B40C81-D9DA-4F68-B23F-79FC31609E30@python.org>
	<e04bdf310808280527g6ac0783ag7df717b1b9cb153e@mail.gmail.com>
Message-ID: <loom.20080828T132415-684@post.gmane.org>

Facundo Batista <facundobatista <at> 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: <loom.20080828T132415-684@post.gmane.org>
References: <loom.20080828T102639-256@post.gmane.org>
	<04B40C81-D9DA-4F68-B23F-79FC31609E30@python.org>
	<e04bdf310808280527g6ac0783ag7df717b1b9cb153e@mail.gmail.com>
	<loom.20080828T132415-684@post.gmane.org>
Message-ID: <e04bdf310808280638m641d2c1ds64bba081b60aeb71@mail.gmail.com>

2008/8/28 Antoine Pitrou <solipsis at pitrou.net>:

> 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>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com>
	<20080827031445.C9B8B3A4079@sparrow.telecommunity.com>
	<4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com>
	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@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>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com>
	<20080827031445.C9B8B3A4079@sparrow.telecommunity.com>
	<4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com>
	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@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" <p... at telecommunity.com> 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>	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>	<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 <div> 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>
	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>
	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com>
	<20080827031445.C9B8B3A4079@sparrow.telecommunity.com>
	<4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com>
	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@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" <p... at telecommunity.com> 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>	<E5EADE59251B403CA21794F3F1372AD5@RaymondLaptop1>	<4edc17eb0808260913v323a700pbeabbec84d0f1406@mail.gmail.com>	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>	<4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com>	<20080827031445.C9B8B3A4079@sparrow.telecommunity.com>	<4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com>	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@mail.gmail.com>	<4edc17eb0808272135q44985feaj1ba550022919eaac@mail.gmail.com>	<20080828152941.CD4E43A410E@sparrow.telecommunity.com>
	<4edc17eb0808280850xa842656l9fea70acc0717bce@mail.gmail.com>
Message-ID: <g9703d$5tf$1@ger.gmane.org>



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: <http://mail.python.org/pipermail/python-dev/attachments/20080828/7a87414f/attachment.htm>

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: <g976s0$cb7$1@ger.gmane.org>



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: <e6268af30808281500m265494fdse37c1576a152ff2@mail.gmail.com>

> 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 "<stdin>", line 1, in <module>
TypeError: unhashable type: 'X'

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20080829/bec02062/attachment.htm>

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: <g945v1$gd5$1@ger.gmane.org> <g94kr2$cob$1@ger.gmane.org>
	<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: <g945v1$gd5$1@ger.gmane.org> <g94kr2$cob$1@ger.gmane.org>
	<200808281121.15908.steve@pearwood.info>
	<48B75335.6090502@canterbury.ac.nz>
Message-ID: <Pine.GSO.4.64.0808282143200.11352@core.cs.uwaterloo.ca>

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: <g95ke6$ibh$1@ger.gmane.org>
References: <g945v1$gd5$1@ger.gmane.org> <g94kr2$cob$1@ger.gmane.org>
	<200808281121.15908.steve@pearwood.info>
	<ca471dc20808272038t25c793acobf8fdbf894e3d358@mail.gmail.com>
	<g95ke6$ibh$1@ger.gmane.org>
Message-ID: <ca471dc20808281925s5c333f35x6464dc66dbfe26e1@mail.gmail.com>

2008/8/28 Steve Holden <steve at holdenweb.com>:
> Guido van Rossum wrote:
>> On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano <steve at pearwood.info>
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 "<stdin>", line 1, in <module>
>>>>> 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)
>>> <module 'parrot' from 'parrot.pyc'>
>>>>>> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080828/edeb292e/attachment.htm>

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>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com>
	<20080827031445.C9B8B3A4079@sparrow.telecommunity.com>
	<4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com>
	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@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 <pje at telecommunity.com> 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>
	<DF136CB4265D4E94B9E6D3BAAAC75349@RaymondLaptop1>
	<4edc17eb0808261816r7dd2eff9hb42772e907e3e9bf@mail.gmail.com>
	<20080827031445.C9B8B3A4079@sparrow.telecommunity.com>
	<4edc17eb0808262224g59c959c9s8a15f778695b8e7a@mail.gmail.com>
	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@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 <pje at telecommunity.com> 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>
	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@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 <pje at telecommunity.com> 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: <e6268af30808290403j216980a6k562a87890955f54a@mail.gmail.com>

> 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: <http://mail.python.org/pipermail/python-dev/attachments/20080829/10d14a53/attachment.htm>

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: <e6268af30808290403j216980a6k562a87890955f54a@mail.gmail.com>
References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com>
	<e6268af30808290403j216980a6k562a87890955f54a@mail.gmail.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: <e6268af30808290547i40820a82r4401a850cfe7344c@mail.gmail.com>

>
>> 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__()<http://docs.python.org/dev/reference/datamodel.html#object.__cmp__>or
__eq__() <http://docs.python.org/dev/reference/datamodel.html#object.__eq__>but
not
__hash__()<http://docs.python.org/dev/reference/datamodel.html#object.__hash__>,
its instances will not be usable as dictionary keys."
versus
b) "User-defined classes have
__cmp__()<http://docs.python.org/dev/3.0/reference/datamodel.html#object.__cmp__>and
__hash__()<http://docs.python.org/dev/3.0/reference/datamodel.html#object.__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: <http://mail.python.org/pipermail/python-dev/attachments/20080829/4ab07333/attachment-0001.htm>

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>
	<e6268af30808290403j216980a6k562a87890955f54a@mail.gmail.com>
	<48B7EEDF.70305@egenix.com>
Message-ID: <e6268af30808290607s69171a02t17233a27829b9a68@mail.gmail.com>

> 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__()<http://docs.python.org/dev/3.0/reference/datamodel.html#object.__cmp__>or
__eq__()<http://docs.python.org/dev/3.0/reference/datamodel.html#object.__eq__>but
not
__hash__()<http://docs.python.org/dev/3.0/reference/datamodel.html#object.__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: <http://mail.python.org/pipermail/python-dev/attachments/20080829/2facfe3d/attachment.htm>

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: <ee2a432c0808241815n57de2264o2c958327968673da@mail.gmail.com>
References: <ee2a432c0808241815n57de2264o2c958327968673da@mail.gmail.com>
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: <e6268af30808290547i40820a82r4401a850cfe7344c@mail.gmail.com>
References: <48B6FD04.6080008@voidspace.org.uk>
	<48B7C718.7020802@egenix.com>	<48B7DBD8.8070205@voidspace.org.uk>
	<e6268af30808290547i40820a82r4401a850cfe7344c@mail.gmail.com>
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 ',<whitespace>' 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>	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@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>
	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@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>
	<48B82098.8090106@gmail.com>
Message-ID: <4edc17eb0808291046j62d6ff9dh612e7d0698bbfba6@mail.gmail.com>

On Fri, Aug 29, 2008 at 6:15 PM, Nick Coghlan <ncoghlan at gmail.com> 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>
	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@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>
	<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 <ncoghlan at gmail.com>  
> 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>
	<e8a0972d0808270730j66fdf00ej91c8ecaded787c04@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>
	<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 <ncoghlan at gmail.com> 
>>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><e8a0972d0808270730j66fdf00ej91c8ecaded787c04@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><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: <glyph at divmod.com>
> 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 <casey at pandora.com> 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: <g9bh5l$8l6$2@ger.gmane.org>

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>
	<e6268af30808290547i40820a82r4401a850cfe7344c@mail.gmail.com>
	<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>
	<e6268af30808290547i40820a82r4401a850cfe7344c@mail.gmail.com>
	<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" <ondrej at certik.cz> 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>
	<e6268af30808290547i40820a82r4401a850cfe7344c@mail.gmail.com>
	<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: <loom.20080830T192234-459@post.gmane.org>


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: <loom.20080830T192234-459@post.gmane.org>
References: <loom.20080830T192234-459@post.gmane.org>
Message-ID: <bbaeab100808301329w5b7d9e35r23a8ad26fe9cd2c7@mail.gmail.com>

On Sat, Aug 30, 2008 at 1:06 PM, Antoine Pitrou <solipsis at pitrou.net> 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: <g9calu$s1p$1@ger.gmane.org>

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>	<e6268af30808290547i40820a82r4401a850cfe7344c@mail.gmail.com>	<48B81E24.2070906@gmail.com>	<85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com>	<9AE6735E-45F6-4A66-B749-1DB7A3D39EA3@gmail.com>
	<85b5c3130808301235t7ce79662t767c2831e736d808@mail.gmail.com>
Message-ID: <g9ccth$g7r$1@ger.gmane.org>

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: <g9calu$s1p$1@ger.gmane.org>
References: <g9calu$s1p$1@ger.gmane.org>
Message-ID: <g9cd1p$g7r$2@ger.gmane.org>

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: <g9calu$s1p$1@ger.gmane.org>
References: <g9calu$s1p$1@ger.gmane.org>
Message-ID: <94bdd2610808301415laaf9e01rc0a8637f90b17f3d@mail.gmail.com>

On Sat, Aug 30, 2008 at 10:30 PM, KLEIN St?phane <stephane at harobed.org>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-<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-<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<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: <http://mail.python.org/pipermail/python-dev/attachments/20080830/d66f5781/attachment.htm>

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: <g9ccth$g7r$1@ger.gmane.org>
References: <48B6FD04.6080008@voidspace.org.uk> <48B7C718.7020802@egenix.com>
	<48B7DBD8.8070205@voidspace.org.uk>
	<e6268af30808290547i40820a82r4401a850cfe7344c@mail.gmail.com>
	<48B81E24.2070906@gmail.com>
	<85b5c3130808301141t4f2b24d8ybd544de0f26d7f4c@mail.gmail.com>
	<9AE6735E-45F6-4A66-B749-1DB7A3D39EA3@gmail.com>
	<85b5c3130808301235t7ce79662t767c2831e736d808@mail.gmail.com>
	<g9ccth$g7r$1@ger.gmane.org>
Message-ID: <85b5c3130808301424j5da8308fg212e2a06b84d5981@mail.gmail.com>

Hi Georg!

On Sat, Aug 30, 2008 at 11:09 PM, Georg Brandl <g.brandl at gmx.net> 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: <g9calu$s1p$1@ger.gmane.org>
	<94bdd2610808301415laaf9e01rc0a8637f90b17f3d@mail.gmail.com>
Message-ID: <g9ce3f$s1p$2@ger.gmane.org>

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
> <stephane at harobed.org>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-
<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-
<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 <gward at python.net>

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-----