From nnorwitz at gmail.com  Fri Feb  1 06:42:40 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 31 Jan 2008 21:42:40 -0800
Subject: [Python-Dev] Upcoming 2.5.2 release
In-Reply-To: <47A197FD.9080001@argo.es>
References: <479CD349.6060604@v.loewis.de> <47A07E8D.7000500@argo.es>
	<47A0D860.5030108@v.loewis.de> <47A197FD.9080001@argo.es>
Message-ID: <ee2a432c0801312142o2e32b6afw43f3c491c4021698@mail.gmail.com>

On Jan 31, 2008 1:42 AM, Jesus Cea <jcea at argo.es> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin v. L?wis wrote:
> |> As current bsddb module maintainer, I was wondering if 2.5.2 will
> |> support BerkeleyDB 4.6 :-?.
> |
> | Maybe I'm misunderstanding the question - whom are asking?
> | If me - Python 2.5.2 will essentially do what the maintenance branch
> | does currently.
>
> I beg your pardon. My role is recent (a week) and I'm still learning my
> way thru procedures and conventions :-).
>
> Current bsddb module in 2.5.1 supports up to BerkeleyDB 4.5. There is
> support for 4.6 in trunk (future 2.6, I guess) and I'm working in a
> private branch at the moment, since I have no commit access to python
> repository. That private version is intented to be merged into python
> 2.6 by Greg, when time comes.

Note that db 4.6 might be the cause of some crashes on the buildbots:
  http://www.python.org/dev/buildbot/all/

I asked to have it disabled on one platform (sparc).  I haven't
checked the results and I'm not sure if Greg has either.  Greg checked
in a change to setup.py on trunk to disable 4.6 to see if the crashes
go away.

~5 buildbots had crashes in bsddb or related code with 4.6 before the
change to setup.py.

n

From nicko at nicko.org  Fri Feb  1 15:43:07 2008
From: nicko at nicko.org (Nicko van Someren)
Date: Fri, 1 Feb 2008 14:43:07 +0000
Subject: [Python-Dev] Tracker marks my messages as spam :-)
In-Reply-To: <47A19DDC.7030508@argo.es>
References: <47A19DDC.7030508@argo.es>
Message-ID: <74B4D166-86D2-4B8D-B9DD-BF71B72DC7C4@nicko.org>

Perhaps it has to do with the low signal to noise ratio of your  
messages...

	Nicko

On 31 Jan 2008, at 10:07, Jesus Cea wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>>>> This will be my last email today, I don't want to waste (more of)  
>>>> your
>>>> *valuable* time.
>
> http://bugs.python.org/issue1391
> http://bugs.python.org/msg61892
>
> - --
> Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
> jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/ 
> _/
> 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.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQCVAwUBR6Gd25lgi5GaxT1NAQLDiwP/aMUOxhoRH8/ZnCtHCUzr95tIJUe1ySh6
> SuDjR3OS19S8lcRVgEL0droIP44lmozpdyOW1eaPDPBMA02XCqiPWmCxBCeXsbJ/
> xf/XVzl53vAQmtfqxHrNyrS+mXv5YW2CjOKWk52IKuf/Rckf9FYSP13OKW7WTjNy
> orjAdOYRd/8=
> =gSNB
> -----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/nicko%40nicko.org


From j_p at centrum.cz  Fri Feb  1 16:46:38 2008
From: j_p at centrum.cz (Jaroslav Pachola)
Date: Fri, 1 Feb 2008 16:46:38 +0100
Subject: [Python-Dev] Upcoming 2.5.2 release
Message-ID: <200802011646.38791.j_p@centrum.cz>

It would be very nice if http://bugs.python.org/issue1692335 fix was included 
in 2.5.2. The patch exists, have been tested, reviewed by Georg Brandl, who 
says he needs some other developer to review the patches (there is a separate 
patch for 2.6). Could please someone look at the issue and help get the 
problem fixed in 2.5.2.?

Regards,
Jaroslav Pachola

From status at bugs.python.org  Fri Feb  1 19:06:16 2008
From: status at bugs.python.org (Tracker)
Date: Fri,  1 Feb 2008 18:06:16 +0000 (UTC)
Subject: [Python-Dev] Summary of Tracker Issues
Message-ID: <20080201180616.276627833E@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (01/25/08 - 02/01/08)
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.


 1680 open (+31) / 12172 closed (+21) / 13852 total (+52)

Open issues with patches:   434

Average duration of open issues: 759 days.
Median duration of open issues: 1045 days.

Open Issues Breakdown
   open  1656 (+30)
pending    24 ( +1)

Issues Created Or Reopened (52)
_______________________________

os.path.isabs documentation error                                01/25/08
CLOSED http://bugs.python.org/issue1933    created  giampaolo.rodola         
                                                                               

os.path.isabs documentation error                                01/25/08
CLOSED http://bugs.python.org/issue1934    created  giampaolo.rodola         
                                                                               

test_descr.py converted to unittest                              01/25/08
       http://bugs.python.org/issue1935    created  amaury.forgeotdarc       
       patch                                                                   

test_zipfile failure                                             01/26/08
CLOSED http://bugs.python.org/issue1938    created  giampaolo.rodola         
                                                                               

code object docstring obsolete                                   01/26/08
CLOSED http://bugs.python.org/issue1939    created  pitrou                   
                                                                               

curses.filter can not be used as described in its documentation  01/26/08
CLOSED http://bugs.python.org/issue1940    created  robinbryce               
                                                                               

2.6 stdlib using with statement                                  01/26/08
       http://bugs.python.org/issue1941    created  gutworth                 
       patch                                                                   

test_plistlib started failing                                    01/26/08
CLOSED http://bugs.python.org/issue1942    created  gvanrossum               
                                                                               

improved allocation of PyUnicode objects                         01/26/08
       http://bugs.python.org/issue1943    created  pitrou                   
                                                                               

Documentation for PyUnicode_AsString (et al.) missing.           01/27/08
       http://bugs.python.org/issue1944    created  alexandre.vassalotti     
       easy                                                                    

Document back ported C functions                                 01/27/08
       http://bugs.python.org/issue1945    created  tiran                    
       easy                                                                    

re.search hangs on this                                          01/27/08
       http://bugs.python.org/issue1946    created  itsadok                  
                                                                               

Exception exceptions.AttributeError '_shutdown' in <module 'thre 01/27/08
       http://bugs.python.org/issue1947    created  Mr Shore                 
                                                                               

Cant open python gui using VISTA                                 01/27/08
       http://bugs.python.org/issue1948    created  needhelpasap             
                                                                               

test_ntpath.py converted to unittest                             01/27/08
       http://bugs.python.org/issue1949    created  giampaolo.rodola         
       patch, easy                                                             

Potential overflows due to incorrect usage of PyUnicode_AsString 01/27/08
       http://bugs.python.org/issue1950    created  alexandre.vassalotti     
       patch                                                                   

test_wave.py converted to unittest                               01/28/08
       http://bugs.python.org/issue1951    created  giampaolo.rodola         
       patch, easy                                                             

test_select.py converted to unittest                             01/28/08
       http://bugs.python.org/issue1952    created  giampaolo.rodola         
       patch                                                                   

Compact int and float freelists                                  01/28/08
       http://bugs.python.org/issue1953    created  tiran                    
       patch                                                                   

SocketServer.ForkingMixIn creates a zombie                       01/28/08
CLOSED http://bugs.python.org/issue1954    created  schmir                   
                                                                               

fix using unittest as a superclass                               01/28/08
CLOSED http://bugs.python.org/issue1955    created  agoucher                 
       patch                                                                   

Lib/bsddb/test/test_thread.py uses old 'except' syntax           01/28/08
CLOSED http://bugs.python.org/issue1956    created  orivej                   
                                                                               

[patch] syslogmodule: Release GIL when calling syslog(3)         01/28/08
       http://bugs.python.org/issue1957    created  rd2                      
       patch                                                                   

IPv6 compiled getaddrinfo returns IPv6 address even if the syste 01/28/08
CLOSED http://bugs.python.org/issue1958    created  douglas                  
                                                                               

test_contains.py converted to unittest                           01/28/08
       http://bugs.python.org/issue1959    created  giampaolo.rodola         
                                                                               

test_gdbm.py converted to unittest                               01/28/08
       http://bugs.python.org/issue1960    created  giampaolo.rodola         
                                                                               

possible error with json format for sphinx                       01/29/08
CLOSED http://bugs.python.org/issue1961    created  brett.cannon             
                                                                               

ctypes feature request: Automatic type conversion of input argum 01/29/08
       http://bugs.python.org/issue1962    created  mattbaas                 
                                                                               

marshal module is leaking references                             01/29/08
CLOSED http://bugs.python.org/issue1963    created  tiran                    
                                                                               

Slight adjustment to sphinx print-media stylesheet               01/29/08
       http://bugs.python.org/issue1964    created  tim.golden               
       patch                                                                   

Move trunc() to math module                                      01/29/08
CLOSED http://bugs.python.org/issue1965    created  rhettinger               
                                                                               

infinite loop in httplib                                         01/29/08
       http://bugs.python.org/issue1966    created  klaas                    
       patch, easy                                                             

Backport dictviews to 2.6                                        01/29/08
       http://bugs.python.org/issue1967    created  twouters                 
       patch                                                                   

Unused number magic methods leaked into Py2.6                    01/29/08
CLOSED http://bugs.python.org/issue1968    created  rhettinger               
                                                                               

split and rsplit in bytearray are inconsistent                   01/29/08
CLOSED http://bugs.python.org/issue1969    created  pitrou                   
       easy                                                                    

Speedup unicode whitespace and linebreak detection               01/30/08
CLOSED http://bugs.python.org/issue1970    created  pitrou                   
       patch                                                                   

ctypes exposing the pep 3118 buffer interface                    01/30/08
       http://bugs.python.org/issue1971    created  theller                  
       patch                                                                   

improve bytes and bytearray tests                                01/30/08
CLOSED http://bugs.python.org/issue1972    created  pitrou                   
       patch                                                                   

bytes.fromhex('') raises SystemError                             01/30/08
CLOSED http://bugs.python.org/issue1973    created  pitrou                   
       patch                                                                   

email.MIMEText.MIMEText.as_string incorrectly folding long subje 01/30/08
       http://bugs.python.org/issue1974    created  cjw296                   
                                                                               

signals in thread problem                                        01/30/08
       http://bugs.python.org/issue1975    created  bamby                    
                                                                               

pybsddb leak in using cursors                                    01/30/08
       http://bugs.python.org/issue1976    created  jcea                     
                                                                               

Python reinitialization test                                     01/30/08
       http://bugs.python.org/issue1977    created  tiran                    
       patch                                                                   

Python(2.5.1) will be crashed when i use _ssl module in multi-th 01/30/08
       http://bugs.python.org/issue1978    created  dugang at 188.com           
       patch                                                                   

Make Decimal comparisons with NaN less arbitrary                 01/31/08
       http://bugs.python.org/issue1979    created  marketdickinson          
       patch                                                                   

pdb losing __file__                                              01/31/08
CLOSED http://bugs.python.org/issue1980    created  erno                     
                                                                               

operator "is"                                                    01/31/08
CLOSED http://bugs.python.org/issue1981    created  shigin                   
                                                                               

Feature: extend strftime to accept milliseconds                  01/31/08
       http://bugs.python.org/issue1982    created  asbalogh                 
                                                                               

Return from fork() is pid_t, not int                             01/31/08
       http://bugs.python.org/issue1983    created  stutsman                 
                                                                               

The raw string r'\' fails                                        01/31/08
CLOSED http://bugs.python.org/issue1984    created  passage                  
                                                                               

Bug/Patch: Problem with xml/__init__.py when using freeze.py     01/31/08
       http://bugs.python.org/issue1985    created  glomde                   
                                                                               

io.StringIO allows any parameter                                 02/01/08
       http://bugs.python.org/issue1986    created  georg.brandl             
                                                                               



Issues Now Closed (45)
______________________

semaphore errors on AIX 5.2                                       119 days
       http://bugs.python.org/issue1234    tiran                    
       patch                                                                   

IMAP4 SSL isn't working                                            72 days
       http://bugs.python.org/issue1482    janssen                  
       patch                                                                   

Remove cmp parameter to list.sort() and builtin.sorted()           22 days
       http://bugs.python.org/issue1771    rhettinger               
                                                                               

patch for pydoc to work in py3k                                     9 days
       http://bugs.python.org/issue1867    georg.brandl             
       patch, easy                                                             

test_urllib fails                                                   1 days
       http://bugs.python.org/issue1928    georg.brandl             
                                                                               

httplib _read_chunked TypeError ||| i = line.find(";")              1 days
       http://bugs.python.org/issue1929    georg.brandl             
       easy                                                                    

NameError: global name 'basestring' is not defined                  1 days
       http://bugs.python.org/issue1931    georg.brandl             
                                                                               

os.path.isabs documentation error                                   0 days
       http://bugs.python.org/issue1933    marketdickinson          
                                                                               

os.path.isabs documentation error                                   1 days
       http://bugs.python.org/issue1934    georg.brandl             
                                                                               

test_zipfile failure                                                1 days
       http://bugs.python.org/issue1938    giampaolo.rodola         
                                                                               

code object docstring obsolete                                      0 days
       http://bugs.python.org/issue1939    georg.brandl             
                                                                               

curses.filter can not be used as described in its documentation     0 days
       http://bugs.python.org/issue1940    georg.brandl             
                                                                               

test_plistlib started failing                                       0 days
       http://bugs.python.org/issue1942    gvanrossum               
                                                                               

SocketServer.ForkingMixIn creates a zombie                          1 days
       http://bugs.python.org/issue1954    gvanrossum               
                                                                               

fix using unittest as a superclass                                  0 days
       http://bugs.python.org/issue1955    gvanrossum               
       patch                                                                   

Lib/bsddb/test/test_thread.py uses old 'except' syntax              0 days
       http://bugs.python.org/issue1956    tiran                    
                                                                               

IPv6 compiled getaddrinfo returns IPv6 address even if the syste    0 days
       http://bugs.python.org/issue1958    douglas                  
                                                                               

possible error with json format for sphinx                          1 days
       http://bugs.python.org/issue1961    georg.brandl             
                                                                               

marshal module is leaking references                                3 days
       http://bugs.python.org/issue1963    tiran                    
                                                                               

Move trunc() to math module                                         3 days
       http://bugs.python.org/issue1965    rhettinger               
                                                                               

Unused number magic methods leaked into Py2.6                       2 days
       http://bugs.python.org/issue1968    jyasskin                 
                                                                               

split and rsplit in bytearray are inconsistent                      0 days
       http://bugs.python.org/issue1969    tiran                    
       easy                                                                    

Speedup unicode whitespace and linebreak detection                  0 days
       http://bugs.python.org/issue1970    tiran                    
       patch                                                                   

improve bytes and bytearray tests                                   0 days
       http://bugs.python.org/issue1972    tiran                    
       patch                                                                   

bytes.fromhex('') raises SystemError                                0 days
       http://bugs.python.org/issue1973    tiran                    
       patch                                                                   

pdb losing __file__                                                 0 days
       http://bugs.python.org/issue1980    tiran                    
                                                                               

operator "is"                                                       1 days
       http://bugs.python.org/issue1981    gvanrossum               
                                                                               

The raw string r'\' fails                                           0 days
       http://bugs.python.org/issue1984    georg.brandl             
                                                                               

Just a test                                                      2775 days
       http://bugs.python.org/issue400622  loewis                   
       patch                                                                   

Docstring formatter.                                             1968 days
       http://bugs.python.org/issue606733  draghuram                
                                                                               

SSL support for poplib                                           1687 days
       http://bugs.python.org/issue756914  draghuram                
                                                                               

Makefile.pre.in ignores CPPFLAGS from environment                1644 days
       http://bugs.python.org/issue780024  draghuram                
                                                                               

getopt_long_only()                                               1633 days
       http://bugs.python.org/issue784231  draghuram                
       patch                                                                   

distutils ignored LDFLAGS in Makefile                            1612 days
       http://bugs.python.org/issue799088  draghuram                
                                                                               

CPPFLAGS should not be aded to ldshard command                   1611 days
       http://bugs.python.org/issue799104  draghuram                
                                                                               

Python version numbers in headers/footers PDF documentation      1610 days
       http://bugs.python.org/issue800926  georg.brandl             
                                                                               

OSF/1 test_dbm segfaults                                         1582 days
       http://bugs.python.org/issue814996  draghuram                
                                                                               

Check for signals during regular expression matches              1533 days
       http://bugs.python.org/issue846388  gvanrossum               
       patch                                                                   

optparse int, long types support binary, octal and hex forma     1487 days
       http://bugs.python.org/issue870807  amaury.forgeotdarc       
       patch                                                                   

optparse: parser.remove_option("-h") inconsistency               1256 days
       http://bugs.python.org/issue1014230 amaury.forgeotdarc       
                                                                               

test_socket PORT conflict with boa-constructor                   1200 days
       http://bugs.python.org/issue1049816 draghuram                
                                                                               

Add a gi_code attr to generators                                  647 days
       http://bugs.python.org/issue1473257 georg.brandl             
       patch                                                                   

New-style classes fail to cleanup attributes                      526 days
       http://bugs.python.org/issue1545463 amaury.forgeotdarc       
                                                                               

segfault in python24.dll                                          418 days
       http://bugs.python.org/issue1607759 gvanrossum               
                                                                               

sre module has misleading docs                                    382 days
       http://bugs.python.org/issue1631394 tlynn                    
                                                                               



Top Issues Most Discussed (10)
______________________________

 18 2.6 stdlib using with statement                                    6 days
open    http://bugs.python.org/issue1941   

 18 Do not assume signed integer overflow behavior                    50 days
open    http://bugs.python.org/issue1621   

 11 improved allocation of PyUnicode objects                           6 days
open    http://bugs.python.org/issue1943   

  9 Return from fork() is pid_t, not int                               1 days
pending http://bugs.python.org/issue1983   

  9 Speedup unicode whitespace and linebreak detection                 0 days
closed  http://bugs.python.org/issue1970   

  8 deepcopy doesn't copy instance methods                            65 days
open    http://bugs.python.org/issue1515   

  7 IMAP4 SSL isn't working                                           72 days
closed  http://bugs.python.org/issue1482   

  6 test_gdbm.py converted to unittest                                 4 days
open    http://bugs.python.org/issue1960   

  6 Lib/bsddb/test/test_thread.py uses old 'except' syntax             0 days
closed  http://bugs.python.org/issue1956   

  6 test_descr.py converted to unittest                                7 days
open    http://bugs.python.org/issue1935   




From jyasskin at gmail.com  Fri Feb  1 19:13:36 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Fri, 1 Feb 2008 10:13:36 -0800
Subject: [Python-Dev] Tracker marks my messages as spam :-)
In-Reply-To: <74B4D166-86D2-4B8D-B9DD-BF71B72DC7C4@nicko.org>
References: <47A19DDC.7030508@argo.es>
	<74B4D166-86D2-4B8D-B9DD-BF71B72DC7C4@nicko.org>
Message-ID: <5d44f72f0802011013j1c34075vfff7fb825bd1065b@mail.gmail.com>

On Feb 1, 2008 6:43 AM, Nicko van Someren <nicko at nicko.org> wrote:
> Perhaps it has to do with the low signal to noise ratio of your
> messages...

That was a little uncalled for. Be polite.

From greg at krypto.org  Fri Feb  1 19:23:35 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Fri, 1 Feb 2008 10:23:35 -0800
Subject: [Python-Dev] Upcoming 2.5.2 release
In-Reply-To: <fnsi91$dik$1@ger.gmane.org>
References: <479CD349.6060604@v.loewis.de> <47A07E8D.7000500@argo.es>
	<47A0D860.5030108@v.loewis.de> <47A197FD.9080001@argo.es>
	<fnsi91$dik$1@ger.gmane.org>
Message-ID: <52dc1c820802011023j7f839be8g6aeab30f5a383cd1@mail.gmail.com>

On 1/31/08, Christian Heimes <lists at cheimes.de> wrote:
>
> Jesus Cea wrote:
> > My guess is that 2.5 branch is still open to more patches than pure
> > security/stability patches, so "backporting" BerkeleyDB 4.6 support
> > seems reasonable (to me). If I'm wrong, please educate me :-).
>
> I think you are wrong, sorry pal! DB 4.6 support is a new feature. New
> features must land in the development version(s) of Python, that is
> Python 2.6 and 3.0. You must change as less code as possible in Python
> 2.5 to fix a severe problem.
>
> Christian
>

Actually in all past releaseXX-maint branches I have merged in support for
compiling against a new version of BerkeleyDB.  Its not a feature, its just
something you have to do to support compiling against a new library
version.  Why is this ok?

* There are no API changes on the python module side.
* Binary releases of python for windows continue to be compiled against the
same BerkeleyDB version that was used in the 2.5.0 release.

the combo of those two things keeps it sane to do this.

As Martin pointed out, I already merged that trivial change in to
release25-maint a while back.

That said, BerkeleyDB 4.6.x has proven to be a bit of an unstable release
from Oracle so I'm considering modifying setup.py to disable linking against
that version by default.  I'll be reviewing buildbot results this weekend.
As already mentioned by Neal i've disabled 4.6 support in trunk to watch the
buildbots.  I'll go over the results this weekend to make a decision on
whether or not python's setup.py should default to allowing itself to link
against 4.6.x or not in hopes of avoiding people filing bugs against us for
what is ultimately Oracle's problem.

-Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080201/489af46e/attachment.htm 

From steve at holdenweb.com  Fri Feb  1 19:37:34 2008
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 01 Feb 2008 13:37:34 -0500
Subject: [Python-Dev] Tracker marks my messages as spam :-)
In-Reply-To: <5d44f72f0802011013j1c34075vfff7fb825bd1065b@mail.gmail.com>
References: <47A19DDC.7030508@argo.es>	<74B4D166-86D2-4B8D-B9DD-BF71B72DC7C4@nicko.org>
	<5d44f72f0802011013j1c34075vfff7fb825bd1065b@mail.gmail.com>
Message-ID: <fnvotg$4n3$1@ger.gmane.org>

Jeffrey Yasskin wrote:
> On Feb 1, 2008 6:43 AM, Nicko van Someren <nicko at nicko.org> wrote:
>> Perhaps it has to do with the low signal to noise ratio of your
>> messages...
> 
> That was a little uncalled for. Be polite.

I don't believe it was at all impolite: It was a literal observation of 
a relevant phenomenon. Jesus's email that started this thread used 1305 
characters to simply say

"This will be my last email today, I don't want to waste (more of) your
*valuable* time."

a message of 89 characters. By anyone's standards that's a low S/N 
ratio. Even without the digital signature overhead it is still 89 
characters from a total of 648 ... it's quite possible that's why his 
messages are being misinterpreted.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From guido at python.org  Fri Feb  1 20:04:41 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 1 Feb 2008 11:04:41 -0800
Subject: [Python-Dev] Tracker marks my messages as spam :-)
In-Reply-To: <fnvotg$4n3$1@ger.gmane.org>
References: <47A19DDC.7030508@argo.es>
	<74B4D166-86D2-4B8D-B9DD-BF71B72DC7C4@nicko.org>
	<5d44f72f0802011013j1c34075vfff7fb825bd1065b@mail.gmail.com>
	<fnvotg$4n3$1@ger.gmane.org>
Message-ID: <ca471dc20802011104v1927b1b1o91ea8ef1a767761e@mail.gmail.com>

No. The message Jesus added to the tracer was, in its entirety:

""" 	
Oracle confirms the issue. They will provide a patch.
"""

That's just small, but has a high S/N ratio. The contents of Jesus'
email has nothing to do with this issue.

On Feb 1, 2008 10:37 AM, Steve Holden <steve at holdenweb.com> wrote:
> Jeffrey Yasskin wrote:
> > On Feb 1, 2008 6:43 AM, Nicko van Someren <nicko at nicko.org> wrote:
> >> Perhaps it has to do with the low signal to noise ratio of your
> >> messages...
> >
> > That was a little uncalled for. Be polite.
>
> I don't believe it was at all impolite: It was a literal observation of
> a relevant phenomenon. Jesus's email that started this thread used 1305
> characters to simply say
>
> "This will be my last email today, I don't want to waste (more of) your
> *valuable* time."
>
> a message of 89 characters. By anyone's standards that's a low S/N
> ratio. Even without the digital signature overhead it is still 89
> characters from a total of 648 ... it's quite possible that's why his
> messages are being misinterpreted.
>
> 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/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From nicko at nicko.org  Fri Feb  1 23:49:02 2008
From: nicko at nicko.org (Nicko van Someren)
Date: Fri, 1 Feb 2008 22:49:02 +0000
Subject: [Python-Dev] Tracker marks my messages as spam :-)
In-Reply-To: <fnvotg$4n3$1@ger.gmane.org>
References: <47A19DDC.7030508@argo.es>	<74B4D166-86D2-4B8D-B9DD-BF71B72DC7C4@nicko.org>
	<5d44f72f0802011013j1c34075vfff7fb825bd1065b@mail.gmail.com>
	<fnvotg$4n3$1@ger.gmane.org>
Message-ID: <480097B0-6D45-4BE0-B6ED-5EBC788942DB@nicko.org>

On 1 Feb 2008, at 18:37, Steve Holden wrote:

> Jeffrey Yasskin wrote:
>> On Feb 1, 2008 6:43 AM, Nicko van Someren <nicko at nicko.org> wrote:
>>> Perhaps it has to do with the low signal to noise ratio of your
>>> messages...
>>
>> That was a little uncalled for. Be polite.
>
> I don't believe it was at all impolite: It was a literal observation  
> of
> a relevant phenomenon. Jesus's email that started this thread used  
> 1305
> characters to simply say
>
> "This will be my last email today, I don't want to waste (more of)  
> your
> *valuable* time."
>
> a message of 89 characters. By anyone's standards that's a low S/N
> ratio. Even without the digital signature overhead it is still 89
> characters from a total of 648 ... it's quite possible that's why his
> messages are being misinterpreted.

Exactly.  I by no means meant to suggest that the quality of the  
content was low, only that it was lost in a morass of padding which  
might confuse a spam filter.  Sorry if my comment was misconstrued.

	Nicko


From dickinsm at gmail.com  Fri Feb  1 23:52:13 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Fri, 1 Feb 2008 17:52:13 -0500
Subject: [Python-Dev] Python on non IEEE-754 platforms: plea for information.
Message-ID: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>

A request for information:

What non IEEE 754 platforms exist that people care about running Python 2.6,
Python 3.0 and higher on?
By non IEEE 754 platform, I mean a platform where either the C double is not
the usual 64-bit IEEE floating-point format, or where the C double is IEEE
format but the platform deviates in major ways from the IEEE 754
specification.  There are a few places (mostly in mathmodule.c,
cmathmodule.c, floatobject.c, longobject.c) where it's not clear that the
code behaves correctly on non-IEEE platforms, and I'm finding it difficult
to determine how broken (or not) it is without having a clear idea of what
possible unusual floating-point formats might come up.
The major non-IEEE floating-point formats that I know of, on big iron, are
the VAX, Cray and IBM formats;  I believe anything else is too old to worry
about.  Is this true?  The IBM format is particularly troublesome because
it's base 16 instead of base 2 (so e.g. multiplying a float by 2 can lose
bits), but it appears that recent IBM machines do both IBM format and IEEE
format floating-point.  I assume that the S-390 buildbots are using the IEEE
side---is this true?

At the other end of the spectrum are embedded devices and cellphones.  Here
I have no idea what the situation is at all---any information would be
valuable.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080201/efd2b6a6/attachment.htm 

From lists at cheimes.de  Sat Feb  2 00:04:02 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 02 Feb 2008 00:04:02 +0100
Subject: [Python-Dev] Python on non IEEE-754 platforms: plea for
	information.
In-Reply-To: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>
References: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>
Message-ID: <47A3A562.2030708@cheimes.de>

Mark Dickinson wrote:
> At the other end of the spectrum are embedded devices and cellphones.  Here
> I have no idea what the situation is at all---any information would be
> valuable.

I know two mobile phone platforms for Python: Nokia S60 and Pippy for
Palm. I haven't had time to study Python on Nokia S60 Series yet. Palm's
hardware and Pippy don't support floats at all. Pippy Python is an old
1.5 (?) without the float type.

The third major platform and last platform for mobile devices I can
think for right now are Qtopia and WinCE. I haven't dealt with them
either so you've to check the specs.


Python on Nokia S60 Series: (Python 2.2.x)
http://www.forum.nokia.com/info/sw.nokia.com/id/ee447e84-2851-471a-8387-3434345f2eb0/Python_for_S60.html
http://wiki.opensource.nokia.com/projects/Python_for_S60

Pippy:
http://pippy.sourceforge.net/

Qtopia:
http://en.wikipedia.org/wiki/Qtopia
http://www.trolltech.com/products/qtopia/

WinCE:
http://en.wikipedia.org/wiki/WinCE

Christian


From martin at v.loewis.de  Sat Feb  2 01:56:59 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 02 Feb 2008 01:56:59 +0100
Subject: [Python-Dev] Python on non IEEE-754 platforms: plea for
	information.
In-Reply-To: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>
References: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>
Message-ID: <47A3BFDB.7090304@v.loewis.de>

> What non IEEE 754 platforms exist that people care about running Python 
> 2.6, Python 3.0 and higher on?

VMS, that's even supported to some degree in the source tree, and
OS/390 (aka z/OS); patches to support it have been rejected, but
people will likely maintain a fork themselves.

> The major non-IEEE floating-point formats that I know of, on big iron, 
> are the VAX, Cray and IBM formats;  I believe anything else is too old 
> to worry about.  Is this true?

Mostly. For VAX, there exist two double formats: the D format, and the
G format - not sure whether you counted them as two.

> The IBM format is particularly 
> troublesome because it's base 16 instead of base 2 (so e.g. multiplying 
> a float by 2 can lose bits), but it appears that recent IBM machines do 
> both IBM format and IEEE format floating-point.  I assume that the S-390 
> buildbots are using the IEEE side---is this true?

They run Linux, so yes. Notice that other people also run Python on z/OS.

Regards,
Martin

From lists at cheimes.de  Sat Feb  2 02:04:46 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 02 Feb 2008 02:04:46 +0100
Subject: [Python-Dev] Python on non IEEE-754 platforms: plea for
	information.
In-Reply-To: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>
References: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>
Message-ID: <47A3C1AE.4040309@cheimes.de>

Mark Dickinson wrote:
> At the other end of the spectrum are embedded devices and cellphones.  Here
> I have no idea what the situation is at all---any information would be
> valuable.

I spoke to Mikko Ohtamaa (Moo-- on #pys60) and he gave me the name of a
Nokia developer and this link
http://discussion.forum.nokia.com/forum/showthread.php?t=97263. I
already contacted the developer and asked him to reply here.

Christian



From dickinsm at gmail.com  Sat Feb  2 03:07:33 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Fri, 1 Feb 2008 21:07:33 -0500
Subject: [Python-Dev] Python on non IEEE-754 platforms: plea for
	information.
In-Reply-To: <47A3BFDB.7090304@v.loewis.de>
References: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>
	<47A3BFDB.7090304@v.loewis.de>
Message-ID: <5c6f2a5d0802011807k985e814p55098b2b41f35f3f@mail.gmail.com>

On Feb 1, 2008 7:56 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:

> Mostly. For VAX, there exist two double formats: the D format, and the
> G format - not sure whether you counted them as two.
>

I didn't.  Thanks.


> They run Linux, so yes. Notice that other people also run Python on z/OS.
>

Okay.  So FLT_RADIX==2 can't be assumed, in general.

Thanks for the information.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080201/3ce9ae61/attachment.htm 

From nnorwitz at gmail.com  Sat Feb  2 03:31:51 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Fri, 1 Feb 2008 18:31:51 -0800
Subject: [Python-Dev] Python on non IEEE-754 platforms: plea for
	information.
In-Reply-To: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>
References: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>
Message-ID: <ee2a432c0802011831y40e00050y4d269089520c6e4@mail.gmail.com>

On Feb 1, 2008 2:52 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
>  The IBM format is particularly troublesome because
> it's base 16 instead of base 2 (so e.g. multiplying a float by 2 can lose
> bits), but it appears that recent IBM machines do both IBM format and IEEE
> format floating-point.  I assume that the S-390 buildbots are using the IEEE
> side---is this true?

I don't know and suspect the only way to figure it out would be to
write a test that would expose which is being used.  It's using gcc,
so we probably get whatever the compiler defaults to.  Sometimes we
have to specify flags for certain platforms.  For example -mieee on
the Alpha.

It's fine to check in something so that you can get an answer on a buildbot.

n

From dickinsm at gmail.com  Sat Feb  2 04:21:29 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Fri, 1 Feb 2008 22:21:29 -0500
Subject: [Python-Dev] Python on non IEEE-754 platforms: plea for
	information.
In-Reply-To: <47A3C1AE.4040309@cheimes.de>
References: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>
	<47A3C1AE.4040309@cheimes.de>
Message-ID: <5c6f2a5d0802011921k144221a4h4f1d1c493543a85c@mail.gmail.com>

On Feb 1, 2008 8:04 PM, Christian Heimes <lists at cheimes.de> wrote:

> I spoke to Mikko Ohtamaa (Moo-- on #pys60) and he gave me the name of a
> Nokia developer and this link
> http://discussion.forum.nokia.com/forum/showthread.php?t=97263. I
> already contacted the developer and asked him to reply here.
>

Thank you:  a very useful thread.  From what little information I'm turning
up on Google, it looks as though most of these devices---if they support
floating-point at all---provide some reasonably close approximation to IEEE
754 floats (possibly emulated in software).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080201/89a7a0da/attachment.htm 

From jyasskin at gmail.com  Sat Feb  2 04:26:45 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Fri, 1 Feb 2008 19:26:45 -0800
Subject: [Python-Dev] Python on non IEEE-754 platforms: plea for
	information.
In-Reply-To: <ee2a432c0802011831y40e00050y4d269089520c6e4@mail.gmail.com>
References: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>
	<ee2a432c0802011831y40e00050y4d269089520c6e4@mail.gmail.com>
Message-ID: <5d44f72f0802011926k5fc73c6bs62dcecb3e6663fbf@mail.gmail.com>

On Feb 1, 2008 6:31 PM, Neal Norwitz <nnorwitz at gmail.com> wrote:
> On Feb 1, 2008 2:52 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
> >  The IBM format is particularly troublesome because
> > it's base 16 instead of base 2 (so e.g. multiplying a float by 2 can lose
> > bits), but it appears that recent IBM machines do both IBM format and IEEE
> > format floating-point.  I assume that the S-390 buildbots are using the IEEE
> > side---is this true?
>
> I don't know and suspect the only way to figure it out would be to
> write a test that would expose which is being used.  It's using gcc,
> so we probably get whatever the compiler defaults to.  Sometimes we
> have to specify flags for certain platforms.  For example -mieee on
> the Alpha.
>
> It's fine to check in something so that you can get an answer on a buildbot.

Actually, an even better way to do this would be to craft a test case
that exposes the assumptions you've found about the floating format.
Then it'll be a valuable regression test even after someone fixes the
bug.

-- 
Namast?,
Jeffrey Yasskin

From skip at pobox.com  Fri Feb  1 20:48:37 2008
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 1 Feb 2008 13:48:37 -0600
Subject: [Python-Dev] Tracker marks my messages as spam :-)
In-Reply-To: <ca471dc20802011104v1927b1b1o91ea8ef1a767761e@mail.gmail.com>
References: <47A19DDC.7030508@argo.es>
	<74B4D166-86D2-4B8D-B9DD-BF71B72DC7C4@nicko.org>
	<5d44f72f0802011013j1c34075vfff7fb825bd1065b@mail.gmail.com>
	<fnvotg$4n3$1@ger.gmane.org>
	<ca471dc20802011104v1927b1b1o91ea8ef1a767761e@mail.gmail.com>
Message-ID: <18339.30613.123790.946852@montanaro-dyndns-org.local>


    Guido> """  
    Guido> Oracle confirms the issue. They will provide a patch.
    Guido> """

    Guido> That's just small, but has a high S/N ratio. The contents of Jesus'
    Guido> email has nothing to do with this issue.

As Martin pointed out, small messages tend to get classified as either spam
or unsure.  The spam filter built into the Roundup instance uses the
SpamBayes classifier.  I don't know how many examples have been trained so
far, but I would guess very few.  It's unlikely that the small message gave
any useful clues (far enough away from a score of 0.5 in either the spam or
ham directions) to the classifier.  Maybe "Oracle" or "patch" would have
been hammy clues.  The others were probably tossed out.  In short, there
just wasn't enough "meat" to chew on.  Of course, without seeing the
classifier's database and input it's kind of hard to be more precise.  Over
time though, even such short messages should be classified more accurately
as the training database grows.

Skip


From lists at cheimes.de  Sat Feb  2 17:15:31 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 02 Feb 2008 17:15:31 +0100
Subject: [Python-Dev] Python on non IEEE-754 platforms: plea for
	information.
In-Reply-To: <5c6f2a5d0802011921k144221a4h4f1d1c493543a85c@mail.gmail.com>
References: <5c6f2a5d0802011452u3e6d3ca7v31d5988aa69b1eaa@mail.gmail.com>	<47A3C1AE.4040309@cheimes.de>
	<5c6f2a5d0802011921k144221a4h4f1d1c493543a85c@mail.gmail.com>
Message-ID: <fo24v4$9ln$1@ger.gmane.org>

Mark Dickinson wrote:
> Thank you:  a very useful thread.  From what little information I'm turning
> up on Google, it looks as though most of these devices---if they support
> floating-point at all---provide some reasonably close approximation to IEEE
> 754 floats (possibly emulated in software).


Some of the devices have a (slow) floating point engine. But it's
sometimes disabled to safe power or userland software can't sometimes
access the FPU. Some devices can (ab)use the DSP or GPU/OpenGL engine to
speed up floating point ops.

Christian


From brett at python.org  Sun Feb  3 03:10:24 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 2 Feb 2008 18:10:24 -0800
Subject: [Python-Dev] A word of warning against using sqlite3 from MacPorts
Message-ID: <bbaeab100802021810n6dcf7aeclcc1088668356065c@mail.gmail.com>

I was running the test suite today and I was getting a segfault in
test_sqlite. That seemed odd since I had not seen any issues on any
buildbots. And running the test independently was fine.

Noticing that sqlite 3.5.5 was recently available I had MacPorts
update. Unfortunately this didn't fix things. I narrowed things down
to running test_ctypes before test_sqlite as the trigger. In order to
debug I wanted to use a version of sqlite that I had compiled.

So after figuring out which package to download (turned out to be the
amalgamation version with shell.c and the included makefile), and
discovering a bug in setup.py where directories from CPPFLAGS were
being searched in reversed from their declared order, I managed to get
a build with my own version and the problem went away.

So I suspect that sqlite3 from MacPorts is built in such a way as to
cause issues. This on Leopard which might also somehow influence
things.

-Brett

From brett at python.org  Sun Feb  3 03:20:13 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 2 Feb 2008 18:20:13 -0800
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about developing on
	Windows?
Message-ID: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>

This year at PyCon, sprint coaches are giving tutorials up to three
hours long the night before sprinting starts. Being the sprint coach
on the core means that I get to be that person for the core. Here is
to hoping people wait for me for dinner that night.

Anyway, to make the tutorial as useful as possible I need to worry
about Windows users. But being an OS X/UNIX user, I don't know how to
help these people. =) As or right now I am going to point them to the
readme.txt file in PCbuild for build instructions. But I don't know if
there is any tips or tricks I should be pointing out to them in terms
of developing on Python. I mean I assume they can use the build
executable from their svn checkout and have it pick up changes they
make to code in the checkout, right? I honestly don't know how
different it is to develop on Windows than on UNIX.

So any info that people can give me to cover would be helpful.

-Brett

From lists at cheimes.de  Sun Feb  3 04:34:27 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 03 Feb 2008 04:34:27 +0100
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about
	developing on Windows?
In-Reply-To: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>
Message-ID: <fo3co4$h16$1@ger.gmane.org>

Brett Cannon wrote:
> Anyway, to make the tutorial as useful as possible I need to worry
> about Windows users. But being an OS X/UNIX user, I don't know how to
> help these people. =) As or right now I am going to point them to the
> readme.txt file in PCbuild for build instructions. But I don't know if
> there is any tips or tricks I should be pointing out to them in terms
> of developing on Python. I mean I assume they can use the build
> executable from their svn checkout and have it pick up changes they
> make to code in the checkout, right? I honestly don't know how
> different it is to develop on Windows than on UNIX.
> 
> So any info that people can give me to cover would be helpful.

I can provide some guidance for the poor Windows souls. :] The VS 2008
Express Edition makes it easy to compile Python on Windows. There is no
need to install any extra SDK packages, additional compilers or whatsoever.

Windows users need:

Visual Studio Express Edition (VS C++ 2008)
http://www.microsoft.com/express/

Tortoise SVN (integrates into the explorer)
http://tortoisesvn.net/

Putty for writable checkouts (I highly recommend to use the agent)
http://www.chiark.greenend.org.uk/~sgtatham/putty/

Not required but very useful
----------------------------

Notepad++ to edit Python files
http://notepad-plus.sourceforge.net/

Total Commander (best Norton Commander clone for Windows)
http://ghisler.com/

SVN command line program
http://subversion.tigris.org/project_packages.html

Unix for Windows
http://cygwin.com/


The PCbuild directory contains several helper bat files. The most
important files are build_env.bat and rt.bat. Build_env.bat opens a
command prompt and sets several env vars. rt.bat is a wrapper for the
unit test suite. I normally use "rt -q" or "rt -q -v test_egg
test_spam". build.bat must be run inside build_env command prompt.
build_pgo won't work with the express edition.

The Windows developers should checkout the sources in a directory
without non ASCII chars and without spaces. I'm using the directory
c:\dev\python\ as root for development on Windows. Checkout the trunk
and py3k in the directory as well as the external dependencies. You
don't need Perl for the ssl package but Express Edition users must
compile BSDDB manually for Win32 Release|db_static and Win32
Debug|db_static. build_tkinter.py builds the Tkinter dependencies.

I'm trying to hang out on IRC during PyCon so I might be able to assist
with Windows questions.

It would be really cool if you can recruit some experienced Windows
developers. :]

Christian


From brett at python.org  Sun Feb  3 04:54:54 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 2 Feb 2008 19:54:54 -0800
Subject: [Python-Dev] Should a change in search order of directories in
	setup.py be backported?
Message-ID: <bbaeab100802021954m3877c4c4i9df6556d33407c44@mail.gmail.com>

I found out that the directories listed in $CPPFLAGS and $LDFLAGS were
being added in reverse order in setup.py. That meant having ``-I/foo
-I/bar`` was searching /bar first. I fixed setup.py in the trunk so
that the declared order if followed instead.

But should this be backported? It will change how extensions are
compiled if there is more than one version on a machine. Not sure if
we want people to suddenly have what they link against change in a
micro release.

-Brett

From skip at pobox.com  Sun Feb  3 05:05:50 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 2 Feb 2008 22:05:50 -0600
Subject: [Python-Dev] Should a change in search order of directories in
 setup.py be backported?
In-Reply-To: <bbaeab100802021954m3877c4c4i9df6556d33407c44@mail.gmail.com>
References: <bbaeab100802021954m3877c4c4i9df6556d33407c44@mail.gmail.com>
Message-ID: <18341.15774.402767.597902@montanaro.dyndns.org>


    Brett> [fix setup.py search order]

    Brett> But should this be backported? 

+1.  Seems like a bug to me.

Skip

From martin at v.loewis.de  Sun Feb  3 09:08:24 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 03 Feb 2008 09:08:24 +0100
Subject: [Python-Dev] Should a change in search order of directories in
 setup.py be backported?
In-Reply-To: <bbaeab100802021954m3877c4c4i9df6556d33407c44@mail.gmail.com>
References: <bbaeab100802021954m3877c4c4i9df6556d33407c44@mail.gmail.com>
Message-ID: <47A57678.7050203@v.loewis.de>

> But should this be backported? It will change how extensions are
> compiled if there is more than one version on a machine. Not sure if
> we want people to suddenly have what they link against change in a
> micro release.

I agree with Skip that this is a bug, so please backport it.

Regards,
Martin

From andymac at bullseye.apana.org.au  Sun Feb  3 10:51:13 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Sun, 03 Feb 2008 19:51:13 +1000
Subject: [Python-Dev] A word of warning against using sqlite3 from
	MacPorts
In-Reply-To: <bbaeab100802021810n6dcf7aeclcc1088668356065c@mail.gmail.com>
References: <bbaeab100802021810n6dcf7aeclcc1088668356065c@mail.gmail.com>
Message-ID: <47A58E91.2000005@bullseye.andymac.org>

Brett Cannon wrote:

{...}

> Noticing that sqlite 3.5.5 was recently available I had MacPorts
> update. Unfortunately this didn't fix things. I narrowed things down
> to running test_ctypes before test_sqlite as the trigger. In order to
> debug I wanted to use a version of sqlite that I had compiled.

{...}

> So I suspect that sqlite3 from MacPorts is built in such a way as to
> cause issues. This on Leopard which might also somehow influence
> things.

In a separate context, I've seen a reference to there being build related
issues with sqlite 3.5.5 on several platforms (I don't know which) which
have resulted in 3.5.6 being scheduled for release in fairly short order
(probably in the next few days).

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

From brett at python.org  Sun Feb  3 11:00:31 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 3 Feb 2008 02:00:31 -0800
Subject: [Python-Dev] Should a change in search order of directories in
	setup.py be backported?
In-Reply-To: <47A57678.7050203@v.loewis.de>
References: <bbaeab100802021954m3877c4c4i9df6556d33407c44@mail.gmail.com>
	<47A57678.7050203@v.loewis.de>
Message-ID: <bbaeab100802030200t4bad7b05rd7dc284be4d6429a@mail.gmail.com>

On Feb 3, 2008 12:08 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > But should this be backported? It will change how extensions are
> > compiled if there is more than one version on a machine. Not sure if
> > we want people to suddenly have what they link against change in a
> > micro release.
>
> I agree with Skip that this is a bug, so please backport it.

Done in r60548. I also went back and added a Misc/NEWS entry for the trunk.

-Brett

From mail at timgolden.me.uk  Sun Feb  3 11:53:21 2008
From: mail at timgolden.me.uk (Tim Golden)
Date: Sun, 03 Feb 2008 10:53:21 +0000
Subject: [Python-Dev] Any tips to tell sprinter at PyCon
 about	developing on Windows?
In-Reply-To: <fo3co4$h16$1@ger.gmane.org>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>
	<fo3co4$h16$1@ger.gmane.org>
Message-ID: <47A59D21.7090707@timgolden.me.uk>

Christian Heimes wrote:
> I can provide some guidance for the poor Windows souls. :] The VS 2008
> Express Edition makes it easy to compile Python on Windows. There is no
> need to install any extra SDK packages, additional compilers or whatsoever.

[... snip loads of useful info ...]

> The PCbuild directory contains several helper bat files. The most
> important files are build_env.bat and rt.bat. Build_env.bat opens a
> command prompt and sets several env vars. 

Just a note for those using the Express Edition: the build.bat file
which builds the Python project on the command line assumes that the
name of the executable is devenv.exe. In fact, for "Visual Studio Express
2008 for C++" (or whatever it's called) the executable is vcexpress.exe.
Basically, whatever .exe the Start Menu shortcut for Visual Studio Express
points to, that's your filename. Change it in the build.bat file and Bob's
Your Uncle!

Thanks again to Christian for all the work he's put in to support
VS 2008 (Express).

TJG

From steve at holdenweb.com  Sun Feb  3 12:44:02 2008
From: steve at holdenweb.com (Steve Holden)
Date: Sun, 03 Feb 2008 06:44:02 -0500
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about
	developing on Windows?
In-Reply-To: <47A59D21.7090707@timgolden.me.uk>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>	<fo3co4$h16$1@ger.gmane.org>
	<47A59D21.7090707@timgolden.me.uk>
Message-ID: <47A5A902.2020801@holdenweb.com>

Tim Golden wrote:
> Christian Heimes wrote:
>> I can provide some guidance for the poor Windows souls. :] The VS 2008
>> Express Edition makes it easy to compile Python on Windows. There is no
>> need to install any extra SDK packages, additional compilers or whatsoever.
> 
> [... snip loads of useful info ...]
> 
>> The PCbuild directory contains several helper bat files. The most
>> important files are build_env.bat and rt.bat. Build_env.bat opens a
>> command prompt and sets several env vars. 
> 
> Just a note for those using the Express Edition: the build.bat file
> which builds the Python project on the command line assumes that the
> name of the executable is devenv.exe. In fact, for "Visual Studio Express
> 2008 for C++" (or whatever it's called) the executable is vcexpress.exe.
> Basically, whatever .exe the Start Menu shortcut for Visual Studio Express
> points to, that's your filename. Change it in the build.bat file and Bob's
> Your Uncle!
> 
> Thanks again to Christian for all the work he's put in to support
> VS 2008 (Express).
> 
Hear hear. It's good to see that the whole burden no longer falls on Tim 
and Martin.

Does VS2008 (Express) coexist peacefully with VS2005, which I need to 
retain for certain client projects?

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/

From steve at holdenweb.com  Sun Feb  3 12:44:02 2008
From: steve at holdenweb.com (Steve Holden)
Date: Sun, 03 Feb 2008 06:44:02 -0500
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about
	developing on Windows?
In-Reply-To: <47A59D21.7090707@timgolden.me.uk>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>	<fo3co4$h16$1@ger.gmane.org>
	<47A59D21.7090707@timgolden.me.uk>
Message-ID: <47A5A902.2020801@holdenweb.com>

Tim Golden wrote:
> Christian Heimes wrote:
>> I can provide some guidance for the poor Windows souls. :] The VS 2008
>> Express Edition makes it easy to compile Python on Windows. There is no
>> need to install any extra SDK packages, additional compilers or whatsoever.
> 
> [... snip loads of useful info ...]
> 
>> The PCbuild directory contains several helper bat files. The most
>> important files are build_env.bat and rt.bat. Build_env.bat opens a
>> command prompt and sets several env vars. 
> 
> Just a note for those using the Express Edition: the build.bat file
> which builds the Python project on the command line assumes that the
> name of the executable is devenv.exe. In fact, for "Visual Studio Express
> 2008 for C++" (or whatever it's called) the executable is vcexpress.exe.
> Basically, whatever .exe the Start Menu shortcut for Visual Studio Express
> points to, that's your filename. Change it in the build.bat file and Bob's
> Your Uncle!
> 
> Thanks again to Christian for all the work he's put in to support
> VS 2008 (Express).
> 
Hear hear. It's good to see that the whole burden no longer falls on Tim 
and Martin.

Does VS2008 (Express) coexist peacefully with VS2005, which I need to 
retain for certain client projects?

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From lists at cheimes.de  Sun Feb  3 13:25:58 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 03 Feb 2008 13:25:58 +0100
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about
	developing on Windows?
In-Reply-To: <47A5A902.2020801@holdenweb.com>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>	<fo3co4$h16$1@ger.gmane.org>	<47A59D21.7090707@timgolden.me.uk>
	<47A5A902.2020801@holdenweb.com>
Message-ID: <47A5B2D6.3050705@cheimes.de>

Steve Holden wrote:
> Does VS2008 (Express) coexist peacefully with VS2005, which I need to 
> retain for certain client projects?

I've VS2005 and VS2008 (both professional) on my box. I haven't run into
problems and they are living happily together.

Christian

From lists at cheimes.de  Sun Feb  3 13:33:38 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 03 Feb 2008 13:33:38 +0100
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about
	developing on Windows?
In-Reply-To: <47A59D21.7090707@timgolden.me.uk>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>	<fo3co4$h16$1@ger.gmane.org>
	<47A59D21.7090707@timgolden.me.uk>
Message-ID: <47A5B4A2.5080706@cheimes.de>

Tim Golden wrote:
> Just a note for those using the Express Edition: the build.bat file
> which builds the Python project on the command line assumes that the
> name of the executable is devenv.exe. In fact, for "Visual Studio Express
> 2008 for C++" (or whatever it's called) the executable is vcexpress.exe.
> Basically, whatever .exe the Start Menu shortcut for Visual Studio Express
> points to, that's your filename. Change it in the build.bat file and Bob's
> Your Uncle!

Does the VS Express Edition have the "vcbuild" command? The build bots
are using vcbuild instead of devenv. The professional edition has it.

c:\dev\python\trunk\PCbuild>vcbuild /useenv pcbuild.sln "Release|Win32"
Microsoft (R) Visual C++ Project Builder - Command Line Version 9.00.21022

Christian

From mail at timgolden.me.uk  Sun Feb  3 13:46:15 2008
From: mail at timgolden.me.uk (Tim Golden)
Date: Sun, 03 Feb 2008 12:46:15 +0000
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about
	developing on Windows?
In-Reply-To: <47A5B4A2.5080706@cheimes.de>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>	<fo3co4$h16$1@ger.gmane.org>
	<47A59D21.7090707@timgolden.me.uk> <47A5B4A2.5080706@cheimes.de>
Message-ID: <47A5B797.60209@timgolden.me.uk>

Christian Heimes wrote:
> Tim Golden wrote:
>> Just a note for those using the Express Edition: the build.bat file
>> which builds the Python project on the command line assumes that the
>> name of the executable is devenv.exe. In fact, for "Visual Studio Express
>> 2008 for C++" (or whatever it's called) the executable is vcexpress.exe.
>> Basically, whatever .exe the Start Menu shortcut for Visual Studio Express
>> points to, that's your filename. Change it in the build.bat file and Bob's
>> Your Uncle!
> 
> Does the VS Express Edition have the "vcbuild" command? The build bots
> are using vcbuild instead of devenv. The professional edition has it.
> 
> c:\dev\python\trunk\PCbuild>vcbuild /useenv pcbuild.sln "Release|Win32"
> Microsoft (R) Visual C++ Project Builder - Command Line Version 9.00.21022

It does (under vc\vcpackages). My development laptop's upstairs but I'll
try out the command above when I get a chance later. While you're there,
the HEAD version of Lib\distutils\command\build_ext.py still refers to
pcbuild9 instead of pcbuild which is preventing extensions from finding
python26.dll. It's a trivial fix so you could probably get it in faster
than I can build and submit the patch. (I'll check later on and put a
patch in if you haven't had a chance).

Thanks

TJG

From mail at timgolden.me.uk  Sun Feb  3 13:52:16 2008
From: mail at timgolden.me.uk (Tim Golden)
Date: Sun, 03 Feb 2008 12:52:16 +0000
Subject: [Python-Dev] Any tips to tell sprinter at PyCon
 about	developing on Windows?
In-Reply-To: <47A5B797.60209@timgolden.me.uk>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>	<fo3co4$h16$1@ger.gmane.org>	<47A59D21.7090707@timgolden.me.uk>
	<47A5B4A2.5080706@cheimes.de> <47A5B797.60209@timgolden.me.uk>
Message-ID: <47A5B900.9060707@timgolden.me.uk>

Tim Golden wrote:
> Christian Heimes wrote:
>> Does the VS Express Edition have the "vcbuild" command? The build bots
>> are using vcbuild instead of devenv. The professional edition has it.
>>
>> c:\dev\python\trunk\PCbuild>vcbuild /useenv pcbuild.sln "Release|Win32"
>> Microsoft (R) Visual C++ Project Builder - Command Line Version 9.00.21022

To confirm: this works under VS 2008 Express. I updated my build.bat
file to read:

set cmd=vcbuild /useenv pcbuild.sln "%conf%|%platf%"

and it worked a charm. Thanks, Christian.

TJG

From j_p at centrum.cz  Sun Feb  3 15:01:52 2008
From: j_p at centrum.cz (Jaroslav Pachola)
Date: Sun, 03 Feb 2008 15:01:52 +0100
Subject: [Python-Dev] Fix of urgent exception pickling issue in Python 2.5.2,
	help needed
Message-ID: <47A5C950.6030509@centrum.cz>

As you may know, I recently posted a message about the following issue: 
http://bugs.python.org/issue1692335 . The issue has been reviewed by 
Guido van Rossum yesterday and as it seems there are some serious 
concerns about breaking the pickle protocol functionality and that's why 
I please the mailing list subscribers for help. Review of the attached 
patches by someone who has a deep insight into the pickle protocol would 
be really appreciated.

Let me briefly explain the situation: Before version 2.5, it was 
perfectly possible to pickle and unpickle subclasses of Exception class 
with custom initializer parameters. In 2.5 it does not work any more and 
I think the issue is related to new-style class exceptions introduced in 
Python 2.5. The bug tracker contains patch that fixes the issue and adds 
some useful test cases. The patch seems to be relatively clean and 
simple, but still it seems necessary that another experienced developer 
reviews the patch so the issue can be resolved and closed. The issue 
prevents some existing projects to move to Python 2.5, please help.

Regards,

Jaroslav Pachola

From mail at timgolden.me.uk  Sun Feb  3 18:55:05 2008
From: mail at timgolden.me.uk (Tim Golden)
Date: Sun, 03 Feb 2008 17:55:05 +0000
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about
	developing on Windows?
In-Reply-To: <47A5B797.60209@timgolden.me.uk>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>	<fo3co4$h16$1@ger.gmane.org>
	<47A59D21.7090707@timgolden.me.uk>
	<47A5B4A2.5080706@cheimes.de> <47A5B797.60209@timgolden.me.uk>
Message-ID: <47A5FFF9.6050604@timgolden.me.uk>

Tim Golden wrote:
> Christian Heimes wrote:
>> Does the VS Express Edition have the "vcbuild" command? The build bots
>> are using vcbuild instead of devenv. The professional edition has it.
>>
>> c:\dev\python\trunk\PCbuild>vcbuild /useenv pcbuild.sln "Release|Win32"
>> Microsoft (R) Visual C++ Project Builder - Command Line Version 
>> 9.00.21022
> 
> It does (under vc\vcpackages). My development laptop's upstairs but I'll
> try out the command above when I get a chance later. While you're there,
> the HEAD version of Lib\distutils\command\build_ext.py still refers to
> pcbuild9 instead of pcbuild which is preventing extensions from finding
> python26.dll. It's a trivial fix so you could probably get it in faster
> than I can build and submit the patch. (I'll check later on and put a
> patch in if you haven't had a chance).

OK. I've just picked up the svn update and it works ok. Only
thing is that the /build parameter is now invalid (although
ignored). The default seems to be equivalent to "/build" while
you have to specify "/rebuild" if that's what you want. Works
ok because vcbuild ignores "/build" and moves on.

Thanks for the prompt response.

TJG

From martin at v.loewis.de  Sun Feb  3 19:23:25 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 03 Feb 2008 19:23:25 +0100
Subject: [Python-Dev] Any tips to tell sprinter at PyCon
 about	developing on Windows?
In-Reply-To: <47A5A902.2020801@holdenweb.com>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>	<fo3co4$h16$1@ger.gmane.org>	<47A59D21.7090707@timgolden.me.uk>
	<47A5A902.2020801@holdenweb.com>
Message-ID: <47A6069D.4020609@v.loewis.de>

> Does VS2008 (Express) coexist peacefully with VS2005, which I need to 
> retain for certain client projects?

Depends on the installation order. For most purposes (executable files,
include files, libraries, etc), they live in different file and registry
spaces, so they coexist fine. The only issue is file name extensions:
what happens if you double-click .sln. VS2008 comes with a version
selector that checks the contents of the file before launching a
specific visual studio, so if you install that second, it will still
open old projects with VS 2005.

VS2005 also shipped with a version selector; I'm unsure whether that
tool would also support future versions (ie. vs2008), so its better
to make sure the 2008 selector gets used.

I don't know whether simultaneous installation of the express and
full versions of VS 2008 is supported (but that was not your
question).

Regards,
Martin

From brett at python.org  Sun Feb  3 23:08:20 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 3 Feb 2008 14:08:20 -0800
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about
	developing on Windows?
In-Reply-To: <fo3co4$h16$1@ger.gmane.org>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>
	<fo3co4$h16$1@ger.gmane.org>
Message-ID: <bbaeab100802031408u55ff6be5q13115fb4d90910b2@mail.gmail.com>

On Feb 2, 2008 7:34 PM, Christian Heimes <lists at cheimes.de> wrote:
> Brett Cannon wrote:
> > Anyway, to make the tutorial as useful as possible I need to worry
> > about Windows users. But being an OS X/UNIX user, I don't know how to
> > help these people. =) As or right now I am going to point them to the
> > readme.txt file in PCbuild for build instructions. But I don't know if
> > there is any tips or tricks I should be pointing out to them in terms
> > of developing on Python. I mean I assume they can use the build
> > executable from their svn checkout and have it pick up changes they
> > make to code in the checkout, right? I honestly don't know how
> > different it is to develop on Windows than on UNIX.
> >
> > So any info that people can give me to cover would be helpful.
>
> I can provide some guidance for the poor Windows souls. :] The VS 2008
> Express Edition makes it easy to compile Python on Windows. There is no
> need to install any extra SDK packages, additional compilers or whatsoever.
>
> Windows users need:
>
> Visual Studio Express Edition (VS C++ 2008)
> http://www.microsoft.com/express/
>
> Tortoise SVN (integrates into the explorer)
> http://tortoisesvn.net/
>
> Putty for writable checkouts (I highly recommend to use the agent)
> http://www.chiark.greenend.org.uk/~sgtatham/putty/
>
> Not required but very useful
> ----------------------------
>
> Notepad++ to edit Python files
> http://notepad-plus.sourceforge.net/
>
> Total Commander (best Norton Commander clone for Windows)
> http://ghisler.com/
>
> SVN command line program
> http://subversion.tigris.org/project_packages.html
>
> Unix for Windows
> http://cygwin.com/
>
>
> The PCbuild directory contains several helper bat files. The most
> important files are build_env.bat and rt.bat. Build_env.bat opens a
> command prompt and sets several env vars. rt.bat is a wrapper for the
> unit test suite. I normally use "rt -q" or "rt -q -v test_egg
> test_spam". build.bat must be run inside build_env command prompt.
> build_pgo won't work with the express edition.
>

PCbuild/readme.txt says that pressing F6 will also build everything
fine. Is that true as well?

And what is the best way to just launch an interpreter? Just
double-click the built executable? I assume sys.path will still be set
up properly to use the checkout.

> The Windows developers should checkout the sources in a directory
> without non ASCII chars and without spaces. I'm using the directory
> c:\dev\python\ as root for development on Windows. Checkout the trunk
> and py3k in the directory as well as the external dependencies. You
> don't need Perl for the ssl package but Express Edition users must
> compile BSDDB manually for Win32 Release|db_static and Win32
> Debug|db_static. build_tkinter.py builds the Tkinter dependencies.
>
> I'm trying to hang out on IRC during PyCon so I might be able to assist
> with Windows questions.
>

Great! I am going to expect people to already know how to use svn aand
have a compiler set up, just not necessarily started a compile yet. So
I suspect most issues will just be best practices stuff.

> It would be really cool if you can recruit some experienced Windows
> developers. :]

That's the point in all of this. =)

-Brett

From lists at cheimes.de  Sun Feb  3 23:21:28 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 03 Feb 2008 23:21:28 +0100
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about
 developing on Windows?
In-Reply-To: <bbaeab100802031408u55ff6be5q13115fb4d90910b2@mail.gmail.com>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>	
	<fo3co4$h16$1@ger.gmane.org>
	<bbaeab100802031408u55ff6be5q13115fb4d90910b2@mail.gmail.com>
Message-ID: <47A63E68.80503@cheimes.de>

Brett Cannon wrote:
> PCbuild/readme.txt says that pressing F6 will also build everything
> fine. Is that true as well?
> 
> And what is the best way to just launch an interpreter? Just
> double-click the built executable? I assume sys.path will still be set
> up properly to use the checkout.

Build solution is F7 now. It's often faster to select the pythoncore
project and select build from the right click menu if the developer only
modifies a core file.

You can set up the python project as startup project. F5 launches the
startup project in a debug environment. Double clicking on the exe
works, too. sys.path is set up properly.

Christian

From brett at python.org  Sun Feb  3 23:39:25 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 3 Feb 2008 14:39:25 -0800
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about
	developing on Windows?
In-Reply-To: <47A63E68.80503@cheimes.de>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>
	<fo3co4$h16$1@ger.gmane.org>
	<bbaeab100802031408u55ff6be5q13115fb4d90910b2@mail.gmail.com>
	<47A63E68.80503@cheimes.de>
Message-ID: <bbaeab100802031439h344a6f59j39dc9cb4b036527@mail.gmail.com>

On Feb 3, 2008 2:21 PM, Christian Heimes <lists at cheimes.de> wrote:
> Brett Cannon wrote:
> > PCbuild/readme.txt says that pressing F6 will also build everything
> > fine. Is that true as well?
> >
> > And what is the best way to just launch an interpreter? Just
> > double-click the built executable? I assume sys.path will still be set
> > up properly to use the checkout.
>
> Build solution is F7 now. It's often faster to select the pythoncore
> project and select build from the right click menu if the developer only
> modifies a core file.
>
> You can set up the python project as startup project. F5 launches the
> startup project in a debug environment. Double clicking on the exe
> works, too. sys.path is set up properly.

Great! Just let me know if/when the vcbuild change is made to the
build.bat file and the Windows part of the slides are done.

I will post them online as a PDF for people to look over. I will also
try to make sure no matter their state to have them up before the next
bug day (which is when?).

-Brett

From brett at python.org  Sun Feb  3 23:44:47 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 3 Feb 2008 14:44:47 -0800
Subject: [Python-Dev] Any Emacs tips for core developers?
Message-ID: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>

I noticed on the download page that http://www.python.org/emacs is
listed as the place to get your modes for Python development (which
seemed to lack any mention of Vim and the support in svn; a slight
bias =). Is this true for core development as well?

Basically if someone can tell me the best place to download stuff and
a bullet point or three for core dev new developers who use Emacs will
thank you.

And if you use something other than Vim or TextMate you can make
suggestions as well. But it should be a fairly popular editor for me
to bother to toss a slide into the tutorial.

-Brett

From lists at cheimes.de  Mon Feb  4 00:28:35 2008
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 04 Feb 2008 00:28:35 +0100
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about
	developing on Windows?
In-Reply-To: <bbaeab100802031439h344a6f59j39dc9cb4b036527@mail.gmail.com>
References: <bbaeab100802021820n7baecc13ia935dcf08d33b23f@mail.gmail.com>	<fo3co4$h16$1@ger.gmane.org>	<bbaeab100802031408u55ff6be5q13115fb4d90910b2@mail.gmail.com>	<47A63E68.80503@cheimes.de>
	<bbaeab100802031439h344a6f59j39dc9cb4b036527@mail.gmail.com>
Message-ID: <47A64E23.8070405@cheimes.de>

Brett Cannon wrote:
> Great! Just let me know if/when the vcbuild change is made to the
> build.bat file and the Windows part of the slides are done.

Done ;)

From guido at python.org  Mon Feb  4 00:48:16 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 3 Feb 2008 15:48:16 -0800
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
Message-ID: <ca471dc20802031548i690ef2a4sf1b963dea150ce79@mail.gmail.com>

I believe recent versions of Emacs and Vim have Python support
standard. At least, it's been years since I last had to do anything to
install it.

I've heard that there are two independent Python modes for Emacs --
though they are suppose to be pretty similar. I don't even know how to
tell them apart.

--Guido

On Feb 3, 2008 2:44 PM, Brett Cannon <brett at python.org> wrote:
> I noticed on the download page that http://www.python.org/emacs is
> listed as the place to get your modes for Python development (which
> seemed to lack any mention of Vim and the support in svn; a slight
> bias =). Is this true for core development as well?
>
> Basically if someone can tell me the best place to download stuff and
> a bullet point or three for core dev new developers who use Emacs will
> thank you.
>
> And if you use something other than Vim or TextMate you can make
> suggestions as well. But it should be a fairly popular editor for me
> to bother to toss a slide into the tutorial.
>
> -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/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From ndbecker2 at gmail.com  Mon Feb  4 00:51:58 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 03 Feb 2008 18:51:58 -0500
Subject: [Python-Dev] Any Emacs tips for core developers?
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<ca471dc20802031548i690ef2a4sf1b963dea150ce79@mail.gmail.com>
Message-ID: <fo5k2u$acj$1@ger.gmane.org>

Guido van Rossum wrote:

> I believe recent versions of Emacs and Vim have Python support
> standard. At least, it's been years since I last had to do anything to
> install it.
> 
> I've heard that there are two independent Python modes for Emacs --
> though they are suppose to be pretty similar. I don't even know how to
> tell them apart.
> 
> --Guido
> 
The more functional one is called "python-mode.el", and if it's loaded
you'll have 2 python-related menus, one called "Python" and one
called "IM-Python".  The other is just called 'python.el' and results in
one menu.  It has far fewer features.


From skip at pobox.com  Mon Feb  4 01:53:42 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 3 Feb 2008 18:53:42 -0600
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
Message-ID: <18342.25110.897689.73654@montanaro-dyndns-org.local>


    Brett> I noticed on the download page that http://www.python.org/emacs
    Brett> is listed as the place to get your modes for Python development
    Brett> (which seemed to lack any mention of Vim and the support in svn;
    Brett> a slight bias =). Is this true for core development as well?

Is what true?  That the above URL is the place to get code to support core
development or that the Vim crowd is being dissed?  <wink>

Barry and I are the nominal maintainers of the python-mode package:

    http://sourceforge.net/projects/python-mode

I am also the guy more-or-less responsible for syncing python-mode with the
version delivered as part of the XEmacs packages (last synced about a week
ago).  The GNU Emacs folks wrote their own Python mode from scratch a couple
years ago.  Both are mentioned here:

    http://www.emacswiki.org/cgi-bin/wiki/PythonMode

I have no experience with the GNU Emacs code.

Finally, on a related note, Fran?ois Pinard sent me a message yesterday
which I have yet to respond to.  He is apparently back in the Pymacs saddle.
I think a Pymacs-based Python mode would be very cool (in part because I am
really not an Emacs Lisp person).

Skip

From jflatow at northwestern.edu  Mon Feb  4 17:32:05 2008
From: jflatow at northwestern.edu (Jared Flatow)
Date: Mon, 4 Feb 2008 10:32:05 -0600
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <18342.25110.897689.73654@montanaro-dyndns-org.local>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<18342.25110.897689.73654@montanaro-dyndns-org.local>
Message-ID: <C1A99A12-168C-4E46-AC9B-6530B5D42890@northwestern.edu>

I am not a core developer but I use emacs exclusively for development  
so you may find this useful.

On Feb 3, 2008, at 6:53 PM, skip at pobox.com wrote:
> I am also the guy more-or-less responsible for syncing python-mode  
> with the
> version delivered as part of the XEmacs packages (last synced about  
> a week
> ago).  The GNU Emacs folks wrote their own Python mode from scratch  
> a couple
> years ago.  Both are mentioned here:
>
>    http://www.emacswiki.org/cgi-bin/wiki/PythonMode
>
> I have no experience with the GNU Emacs code.

I recently upgraded to the emacs 22.1/python.el which I tried *really*  
hard to use, but eventually ended up installing python-mode again.  
There are a number of problems in the emacs lisp that I was able to  
get around, but eventually the bugginess overcame my will:
*R, RE, and RET (i.e. the keystroke shift-r) were bound to commands in  
the major mode (meaning you couldn't type an R without triggering  
python-send-string). You can comment out this line in python.el to get  
around this:

;;    (define-key map "\C-c\C-s" 'python-send-string)

*echoing was occurring in the run-python shell. You can easily tell  
comint to process echoes for single-line commands, but if your tabs  
are converted to spaces you would need to do something like this to  
get rid of it in general:

;(add-hook 'inferior-python-mode-hook
;         (lambda ()
;           (setq comint-process-echoes t)
;           (set (make-variable-buffer-local 'indent-tabs-mode) nil)))

* The emacs.py never worked for me (I ended up completely disabling it)
* Opening a run-python shell when you already have one open does not  
work as you would expect. This is fixable also, but this was also the  
final straw for me.

Realizing these things is very painful. Therefore I definitely  
recommend python-mode.el, which you can install by adding this to  
your .emacs:

;; Use a real man's python-mode
(setq auto-mode-alist (cons '("\\.py$" . python-mode) auto-mode-alist))
(setq interpreter-mode-alist (cons '("python" . python-mode)
                                    interpreter-mode-alist))
(autoload 'python-mode "python-mode" "Python editing mode." t)
(autoload 'py-shell "python-mode" "Python shell." t nil)

Assuming the .el files are on your load-path and the .py files are in  
your site-packages.

jared


From glyph at divmod.com  Mon Feb  4 18:12:21 2008
From: glyph at divmod.com (glyph at divmod.com)
Date: Mon, 04 Feb 2008 17:12:21 -0000
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <C1A99A12-168C-4E46-AC9B-6530B5D42890@northwestern.edu>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<18342.25110.897689.73654@montanaro-dyndns-org.local>
	<C1A99A12-168C-4E46-AC9B-6530B5D42890@northwestern.edu>
Message-ID: <20080204171221.21558.2073130175.divmod.xquotient.5896@joule.divmod.com>

To say I "use" emacs would be an understatement.  I *live* in emacs.

On 04:32 pm, jflatow at northwestern.edu wrote:
>I recently upgraded to the emacs 22.1/python.el which I tried *really*
>hard to use, but eventually ended up installing python-mode again.
>There are a number of problems in the emacs lisp that I was able to
>get around, but eventually the bugginess overcame my will:
>*R, RE, and RET (i.e. the keystroke shift-r) were bound to commands in
>the major mode (meaning you couldn't type an R without triggering
>python-send-string). You can comment out this line in python.el to get
>around this:

Personally, I have been using GNU Emacs's new python mode since I 
discovered it, and I've never encountered any of the bugs you just 
described.  (Perhaps you are describing bugs that arise from trying to 
use it with XEmacs?)  I have, however, found that it is *less* buggy in 
certain circumstances; it seems to indent parentheses correctly in more 
circumstances, and it isn't confused by triple-quoted strings.  It also 
has functioning support for which-func-mode which python-mode.el doesn't 
seem to (a hack which displays the current scope on the modeline, which 
is very helpful for long classes: I can just glance down and see 
"FooBarBaz.bozBuz()" rather than needing to hit "C-M-r ^class"

As always, YMMV.

Also, I use twisted-dev.el for all of my Python development.  I don't 
think I'll ever be able to go back to F9 doing anything but running 
tests for the current buffer.  Apparently there's a "ctypes-dev" based 
on those hacks in the main Python repository which basically does the 
same thing.  (I'd also strongly recommend binding F5 to 'next-error'. 
It makes hopping around in the error stack nice and easy.)

Finally, for you Ubuntu developers, I'm also using the the pre-release 
XFT GNU emacs, which is very pretty.  So far, despite stern and dire 
warnings, it has had no stability issues:

    http://www.emacswiki.org/cgi-bin/wiki/XftGnuEmacs

Look for the "PPA" deb lines there, and you get a nicely prepackaged, 
policy-compliant version of emacs with no need to build anything 
yourself.

(I've also got a personal collection of hacks that, if anyone likes 
TextMate-style "snippets", I'll email you.  It does stuff like turning 
""" into """\n(indent)\n"""\n and "class " into "class (cursor 
here):\n"""\n(indent)\n"""\n(indent)\n". I haven't cleaned it up for a 
public release since a lot of people seem to think that automatically 
inserting text is pretty obnoxious and I just don't have the energy for 
that debate.)

From guido at python.org  Mon Feb  4 18:20:30 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 4 Feb 2008 09:20:30 -0800
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <20080204171221.21558.2073130175.divmod.xquotient.5896@joule.divmod.com>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<18342.25110.897689.73654@montanaro-dyndns-org.local>
	<C1A99A12-168C-4E46-AC9B-6530B5D42890@northwestern.edu>
	<20080204171221.21558.2073130175.divmod.xquotient.5896@joule.divmod.com>
Message-ID: <ca471dc20802040920r54b63d99p84f2f4da54a99e0d@mail.gmail.com>

On Feb 4, 2008 9:12 AM,  <glyph at divmod.com> wrote:
> To say I "use" emacs would be an understatement.  I *live* in emacs.

http://www.xkcd.com/378/

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From asmodai at in-nomine.org  Mon Feb  4 18:35:15 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Mon, 4 Feb 2008 18:35:15 +0100
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
Message-ID: <20080204173515.GT39133@nexus.in-nomine.org>

-On [20080203 23:44], Brett Cannon (brett at python.org) wrote:
>And if you use something other than Vim or TextMate you can make
>suggestions as well. But it should be a fairly popular editor for me
>to bother to toss a slide into the tutorial.

I assume you implicitly mean that you already have material on vim and/or
textmate?

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
We have met the enemy and they are ours...

From p.f.moore at gmail.com  Mon Feb  4 18:38:21 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 4 Feb 2008 17:38:21 +0000
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <ca471dc20802040920r54b63d99p84f2f4da54a99e0d@mail.gmail.com>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<18342.25110.897689.73654@montanaro-dyndns-org.local>
	<C1A99A12-168C-4E46-AC9B-6530B5D42890@northwestern.edu>
	<20080204171221.21558.2073130175.divmod.xquotient.5896@joule.divmod.com>
	<ca471dc20802040920r54b63d99p84f2f4da54a99e0d@mail.gmail.com>
Message-ID: <79990c6b0802040938j444fcf1dld924abe3906b39d6@mail.gmail.com>

On 04/02/2008, Guido van Rossum <guido at python.org> wrote:
> On Feb 4, 2008 9:12 AM,  <glyph at divmod.com> wrote:
> > To say I "use" emacs would be an understatement.  I *live* in emacs.
>
> http://www.xkcd.com/378/

BTW, it's often worth checking out the alt text on xkcd cartoons...
Paul.

From ndbecker2 at gmail.com  Mon Feb  4 19:46:11 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Mon, 04 Feb 2008 13:46:11 -0500
Subject: [Python-Dev] Any Emacs tips for core developers?
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<18342.25110.897689.73654@montanaro-dyndns-org.local>
	<C1A99A12-168C-4E46-AC9B-6530B5D42890@northwestern.edu>
	<20080204171221.21558.2073130175.divmod.xquotient.5896@joule.divmod.com>
Message-ID: <fo7mhj$o50$1@ger.gmane.org>

glyph at divmod.com wrote:

[...]
> Finally, for you Ubuntu developers, I'm also using the the pre-release
> XFT GNU emacs, which is very pretty.  So far, despite stern and dire
> warnings, it has had no stability issues:
> 
>     http://www.emacswiki.org/cgi-bin/wiki/XftGnuEmacs
> 
> Look for the "PPA" deb lines there, and you get a nicely prepackaged,
> policy-compliant version of emacs with no need to build anything
> yourself.
> 

FYI, I have built xft gnu emacs, as well as xft xemacs for fedora F7/8.  I
can make the srpms available if anyone wants them.

I use xemacs all day every day and never see any problem (except for some
slight font droppings).


From g.brandl at gmx.net  Mon Feb  4 19:57:03 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 04 Feb 2008 19:57:03 +0100
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
Message-ID: <fo7n1d$qoe$1@ger.gmane.org>

Brett Cannon schrieb:
> I noticed on the download page that http://www.python.org/emacs is
> listed as the place to get your modes for Python development (which
> seemed to lack any mention of Vim and the support in svn; a slight
> bias =). Is this true for core development as well?
> 
> Basically if someone can tell me the best place to download stuff and
> a bullet point or three for core dev new developers who use Emacs will
> thank you.

As others have said, out of the box support (python.el) is already quite
good (I'm using a patched version of python-mode.el though) -- the C mode
is good too -- my Emacs has a built-in style (for c-set-style) named
"python" for editing old-style (tabbed) CPython code, a style for new-style
CPython code can be found at http://wiki.python.org/moin/NeedForSpeed/IRCLog
(look for "python-new").

Cscope has excellent Emacs support and is helpful for navigation through
the C source.

GUD (the Emacs debugger interface) works well with gdb and pdb.

For the documentation, the Docutils svn includes a rst-mode.el (at
http://svn.berlios.de/svnroot/repos/docutils/trunk/docutils/tools/editors/emacs/).

For those who like graphical file browsers (TextMate *cough*), there's
ECB which also parses Python file structure.

Nice snippets:

;; highlight XXX style code tags in source files
(font-lock-add-keywords 'python-mode
  '(("\\<\\(FIXME\\|HACK\\|XXX\\|TODO\\)" 1 font-lock-warning-face prepend)))

;; good for defeating the whitespace-normalization commit hook
(set-variable 'show-trailing-whitespace 1)

;; Custom margin keys (useful for Python indentation)
(global-set-key [?\M-\C-+] 'increase-left-margin)
(global-set-key [?\M-\C--] 'decrease-left-margin)

Georg


From jflatow at northwestern.edu  Mon Feb  4 20:12:33 2008
From: jflatow at northwestern.edu (Jared Flatow)
Date: Mon, 4 Feb 2008 13:12:33 -0600
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <20080204171221.21558.2073130175.divmod.xquotient.5896@joule.divmod.com>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<18342.25110.897689.73654@montanaro-dyndns-org.local>
	<C1A99A12-168C-4E46-AC9B-6530B5D42890@northwestern.edu>
	<20080204171221.21558.2073130175.divmod.xquotient.5896@joule.divmod.com>
Message-ID: <875BC0A6-A5A9-4D74-A295-FE1C05CF86EB@northwestern.edu>


On Feb 4, 2008, at 11:12 AM, glyph at divmod.com wrote:

> Personally, I have been using GNU Emacs's new python mode since I
> discovered it, and I've never encountered any of the bugs you just
> described.  (Perhaps you are describing bugs that arise from trying to
> use it with XEmacs?)

I'm not using XEmacs, but perhaps its Leopard-related.

jared

From brett at python.org  Mon Feb  4 21:38:46 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Feb 2008 12:38:46 -0800
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <ca471dc20802031548i690ef2a4sf1b963dea150ce79@mail.gmail.com>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<ca471dc20802031548i690ef2a4sf1b963dea150ce79@mail.gmail.com>
Message-ID: <bbaeab100802041238l5fa820eas25fbe6b78d7f2546@mail.gmail.com>

On Feb 3, 2008 3:48 PM, Guido van Rossum <guido at python.org> wrote:
> I believe recent versions of Emacs and Vim have Python support
> standard. At least, it's been years since I last had to do anything to
> install it.
>

Python support is standard for Vim. But the stuff in Misc/Vim is much
more up-to-date and specific to core development.

-Brett

From barry at python.org  Mon Feb  4 21:39:16 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 4 Feb 2008 15:39:16 -0500
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <fo7mhj$o50$1@ger.gmane.org>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<18342.25110.897689.73654@montanaro-dyndns-org.local>
	<C1A99A12-168C-4E46-AC9B-6530B5D42890@northwestern.edu>
	<20080204171221.21558.2073130175.divmod.xquotient.5896@joule.divmod.com>
	<fo7mhj$o50$1@ger.gmane.org>
Message-ID: <CDDF273F-3513-4F05-BC88-B95A299589BF@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 4, 2008, at 1:46 PM, Neal Becker wrote:

> glyph at divmod.com wrote:
>
> [...]
>> Finally, for you Ubuntu developers, I'm also using the the pre- 
>> release
>> XFT GNU emacs, which is very pretty.  So far, despite stern and dire
>> warnings, it has had no stability issues:
>>
>>    http://www.emacswiki.org/cgi-bin/wiki/XftGnuEmacs
>>
>> Look for the "PPA" deb lines there, and you get a nicely prepackaged,
>> policy-compliant version of emacs with no need to build anything
>> yourself.
>>
>
> FYI, I have built xft gnu emacs, as well as xft xemacs for fedora  
> F7/8.  I
> can make the srpms available if anyone wants them.
>
> I use xemacs all day every day and never see any problem (except for  
> some
> slight font droppings).

Me too, on multiple platforms.  Specifically, 21.5.28 (or .27) on OS X  
(Tiger & Leopard) and Linux (Ubuntu & Gentoo).  21.5.28 has one little  
buglet that I've already complained to Stephen about but other than  
that, it works beautifully.

FWIW, Skip and I will probably keep maintaining python-mode.el and I  
intend to update its syntax highlighting for Python 3 at some point.   
But for the most part, it just works well enough for me.

The reason there are two Python modes is the same reason there is FSF  
Emacs and XEmacs <wink>.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR6d39XEjvBPtnXfVAQLIUQQAgLbE4vsagSZPOaM5mdlXhbb75ws3oA+M
WZXip9ZA3uSuResiC4miSGQNQZiBAjH4oQA+JjVOls3scOD58jq59ZSXdTSiL3oL
sP/hn1zZxGoC8MF1NranPlnIpWNB9Ga6i/To0WKUiME8uXOwfwGlnTfMILYhqnYE
1inLziB5gxc=
=uTN4
-----END PGP SIGNATURE-----

From barry at python.org  Mon Feb  4 21:41:36 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 4 Feb 2008 15:41:36 -0500
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <fo7n1d$qoe$1@ger.gmane.org>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<fo7n1d$qoe$1@ger.gmane.org>
Message-ID: <31624963-7178-4428-8FD8-1453D6E923D8@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 4, 2008, at 1:57 PM, Georg Brandl wrote:
>
> GUD (the Emacs debugger interface) works well with gdb and pdb.

Don't forget pdbtrack which is in python-mode.el (don't know about  
python.el).  Ken Manheimer wrote this and it rocks.  It basically  
tracks pdb prompts in a shell buffer so it makes it really easy to  
just add a break point, run your code from the command line, and get  
dual-window tracing from the shell.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR6d4gHEjvBPtnXfVAQJg9AP/eM+6Qhni7PuEDFlfwuuVPnT/Zhhy9kdJ
D2rAgGaMg8mYiBV8IGtdpG+tajmeodQUn2UFZTnN+d4CH4Z5JOGFBo4jKGI731se
K8cXtmr+TV2Yv838kOKyTJvKmo8zpCTSkYaBZ2swHbTMq3FEEm1Aa7mVZyjBqYTs
V8QrDYCoGAE=
=JIhC
-----END PGP SIGNATURE-----

From brett at python.org  Mon Feb  4 22:29:40 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Feb 2008 13:29:40 -0800
Subject: [Python-Dev] Initial attempt to PyCon sprint tutorial slides are up
Message-ID: <bbaeab100802041329w215527e3o592adff4258bc571@mail.gmail.com>

The 1 MB PDF can be found at
http://www.cs.ubc.ca/~drifty/pycon/sprint_tutorial.pdf . If you find
any bad info or some info that is really lacking, let me know. But
please realize that my slides are never really meant to be read on
their own as it just goes against my presentation style. So don't
think that some slide doesn't go into enough detail unless there is
some URL I am missing. Every slide will be discussed more during the
presentation than what is on the slide.

-Brett

From rw at smsnet.pl  Mon Feb  4 22:33:31 2008
From: rw at smsnet.pl (Rob Wolfe)
Date: Mon, 04 Feb 2008 22:33:31 +0100
Subject: [Python-Dev] Any Emacs tips for core developers?
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<18342.25110.897689.73654@montanaro-dyndns-org.local>
Message-ID: <87bq6wbe50.fsf@merkury.smsnet.pl>

skip at pobox.com writes:

> Finally, on a related note, Fran?ois Pinard sent me a message yesterday
> which I have yet to respond to.  He is apparently back in the Pymacs saddle.
> I think a Pymacs-based Python mode would be very cool (in part because I am
> really not an Emacs Lisp person).

Full agreement here. I really regret that I didn't discover Pymacs
earlier. It is fun to play with it and I did some sort of completion
for Python in Emacs. 
I used Pymacs, python-mode.el, pycompletion.el, pycompletion.py 
and many different ideas found somewhere and finally got something 
imho pretty useful.
Take a look here: 
http://www.rwdev.eu/articles/emacspyeng

HTH,
Rob


From thomas at python.org  Mon Feb  4 23:07:51 2008
From: thomas at python.org (Thomas Wouters)
Date: Mon, 4 Feb 2008 14:07:51 -0800
Subject: [Python-Dev] Backporting PEP 3115
Message-ID: <9e804ac0802041407j46a12bafs6482a80720738c1f@mail.gmail.com>

Is anyone interested in seeing PEP 3115 (Metaclasses in Python 3000, )
backported to 2.6? Actually, I guess I am interested, so perhaps I should
ask 'does anyone see any objection to it being backported'? Of course there
should be full backward  compatibility in 2.6, but I don't see any issue
preventing that, right now.

(I was actually working on backporting the new super() (incorrectly
described in PEP 3135) which builds on top of PEP 3115; I can backport
without PEP 3115 but it would be a waste if we then backported 3115 after
all.)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080204/9b134361/attachment.htm 

From skip at pobox.com  Mon Feb  4 23:34:18 2008
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 4 Feb 2008 16:34:18 -0600
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <CDDF273F-3513-4F05-BC88-B95A299589BF@python.org>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<18342.25110.897689.73654@montanaro-dyndns-org.local>
	<C1A99A12-168C-4E46-AC9B-6530B5D42890@northwestern.edu>
	<20080204171221.21558.2073130175.divmod.xquotient.5896@joule.divmod.com>
	<fo7mhj$o50$1@ger.gmane.org>
	<CDDF273F-3513-4F05-BC88-B95A299589BF@python.org>
Message-ID: <18343.37610.678454.201938@montanaro-dyndns-org.local>


    Barry> The reason there are two Python modes is the same reason there is
    Barry> FSF Emacs and XEmacs <wink>.

I remember something about some GNU person submitting an enormous patch that
would have made continued distribution of python-mode.el with Python
untenable because it would have been GPL'd or some such.  Which reminds me.
I should sync Misc/python-mode.el for both trunk and py3k branches with the
latest version from the SF python-mode project.

Skip


From skip at pobox.com  Mon Feb  4 23:35:52 2008
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 4 Feb 2008 16:35:52 -0600
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <bbaeab100802041238l5fa820eas25fbe6b78d7f2546@mail.gmail.com>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<ca471dc20802031548i690ef2a4sf1b963dea150ce79@mail.gmail.com>
	<bbaeab100802041238l5fa820eas25fbe6b78d7f2546@mail.gmail.com>
Message-ID: <18343.37704.809905.872782@montanaro-dyndns-org.local>


    Brett> Python support is standard for Vim. But the stuff in Misc/Vim is
    Brett> much more up-to-date and specific to core development.

Brett,

I should have asked this before, but what's so special about core (Python?)
development that the tools should be different than for non-core
development?

Skip


From barry at python.org  Tue Feb  5 00:19:22 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 4 Feb 2008 18:19:22 -0500
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <18343.37610.678454.201938@montanaro-dyndns-org.local>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<18342.25110.897689.73654@montanaro-dyndns-org.local>
	<C1A99A12-168C-4E46-AC9B-6530B5D42890@northwestern.edu>
	<20080204171221.21558.2073130175.divmod.xquotient.5896@joule.divmod.com>
	<fo7mhj$o50$1@ger.gmane.org>
	<CDDF273F-3513-4F05-BC88-B95A299589BF@python.org>
	<18343.37610.678454.201938@montanaro-dyndns-org.local>
Message-ID: <9EB2F13B-44A5-4F9D-B153-3ECA316EDA07@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 4, 2008, at 5:34 PM, skip at pobox.com wrote:

>
>    Barry> The reason there are two Python modes is the same reason  
> there is
>    Barry> FSF Emacs and XEmacs <wink>.
>
> I remember something about some GNU person submitting an enormous  
> patch that
> would have made continued distribution of python-mode.el with Python
> untenable because it would have been GPL'd or some such.

That rings a bell.

> Which reminds me.
> I should sync Misc/python-mode.el for both trunk and py3k branches  
> with the
> latest version from the SF python-mode project.

Yes, thanks!

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR6ede3EjvBPtnXfVAQJAVwP+Nq9nVdTVKQpsnY+zIgnhUezMbWgiUDEm
ggW5fHXmUP1zuoxHRn43PRKBtbHyX/57xBqlrGCJEW5nGbm/YV2cQgdX+B9F0q26
owH4vBXLjWs3kkPxvCrpLIB1ndjXDT3Ze04Oy7013p5z9whVEb5C+KSZpxkEa5c5
AjNIFkgAzqA=
=nJJI
-----END PGP SIGNATURE-----

From brett at python.org  Tue Feb  5 00:30:00 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Feb 2008 15:30:00 -0800
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <18343.37704.809905.872782@montanaro-dyndns-org.local>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<ca471dc20802031548i690ef2a4sf1b963dea150ce79@mail.gmail.com>
	<bbaeab100802041238l5fa820eas25fbe6b78d7f2546@mail.gmail.com>
	<18343.37704.809905.872782@montanaro-dyndns-org.local>
Message-ID: <bbaeab100802041530s55d23b11gbed09473b9a3bd29@mail.gmail.com>

On Feb 4, 2008 2:35 PM,  <skip at pobox.com> wrote:
>
>     Brett> Python support is standard for Vim. But the stuff in Misc/Vim is
>     Brett> much more up-to-date and specific to core development.
>
> Brett,
>
> I should have asked this before, but what's so special about core (Python?)
> development that the tools should be different than for non-core
> development?

Usually the core has keywords, built-ins, etc. that have not been
pushed to the release versions for various editors. I know I like
having my syntax highlighting work for what I am coding against, and
against trunk that can be different than what my editor came with.
Plus coding guidelines might be different from PEPs 7 and 8 compared
to what an editor is set to do by default.

-Brett

From skip at pobox.com  Tue Feb  5 01:47:59 2008
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 4 Feb 2008 18:47:59 -0600
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <bbaeab100802041530s55d23b11gbed09473b9a3bd29@mail.gmail.com>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<ca471dc20802031548i690ef2a4sf1b963dea150ce79@mail.gmail.com>
	<bbaeab100802041238l5fa820eas25fbe6b78d7f2546@mail.gmail.com>
	<18343.37704.809905.872782@montanaro-dyndns-org.local>
	<bbaeab100802041530s55d23b11gbed09473b9a3bd29@mail.gmail.com>
Message-ID: <18343.45631.761498.201618@montanaro-dyndns-org.local>


    >> I should have asked this before, but what's so special about core
    >> (Python?)  development that the tools should be different than for
    >> non-core development?

    Brett> Usually the core has keywords, built-ins, etc. that have not been
    Brett> pushed to the release versions for various editors. 

Ah, okay.  Barry mentioned something about adjusting the python-mode syntax
tables to include Python 3.x stuff, though patches are always
welcome. <wink>

    Brett> Plus coding guidelines might be different from PEPs 7 and 8
    Brett> compared to what an editor is set to do by default.

That might be a bit more challenging.  I was thinking today that it would be
kind of nice to have a set of predefined settings for Python's new C style
(someone mentioned producing that).  Should that go in the C/C++ mode or be
delivered somehow else?

Skip


From brett at python.org  Tue Feb  5 02:00:19 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Feb 2008 17:00:19 -0800
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <18343.45631.761498.201618@montanaro-dyndns-org.local>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<ca471dc20802031548i690ef2a4sf1b963dea150ce79@mail.gmail.com>
	<bbaeab100802041238l5fa820eas25fbe6b78d7f2546@mail.gmail.com>
	<18343.37704.809905.872782@montanaro-dyndns-org.local>
	<bbaeab100802041530s55d23b11gbed09473b9a3bd29@mail.gmail.com>
	<18343.45631.761498.201618@montanaro-dyndns-org.local>
Message-ID: <bbaeab100802041700k5ed863c0s67ff9ba783050085@mail.gmail.com>

On Feb 4, 2008 4:47 PM,  <skip at pobox.com> wrote:
>
>     >> I should have asked this before, but what's so special about core
>     >> (Python?)  development that the tools should be different than for
>     >> non-core development?
>
>     Brett> Usually the core has keywords, built-ins, etc. that have not been
>     Brett> pushed to the release versions for various editors.
>
> Ah, okay.  Barry mentioned something about adjusting the python-mode syntax
> tables to include Python 3.x stuff, though patches are always
> welcome. <wink>
>
>     Brett> Plus coding guidelines might be different from PEPs 7 and 8
>     Brett> compared to what an editor is set to do by default.
>
> That might be a bit more challenging.  I was thinking today that it would be
> kind of nice to have a set of predefined settings for Python's new C style
> (someone mentioned producing that).

Well, I have done that for Vim. Don't know if you Emacs folks have
done that yet. =)

-Brett

From lists at cheimes.de  Tue Feb  5 02:26:38 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 05 Feb 2008 02:26:38 +0100
Subject: [Python-Dev] Initial attempt to PyCon sprint tutorial slides
	are up
In-Reply-To: <bbaeab100802041329w215527e3o592adff4258bc571@mail.gmail.com>
References: <bbaeab100802041329w215527e3o592adff4258bc571@mail.gmail.com>
Message-ID: <fo8e0f$7e6$1@ger.gmane.org>

Brett Cannon wrote:
> The 1 MB PDF can be found at
> http://www.cs.ubc.ca/~drifty/pycon/sprint_tutorial.pdf . If you find
> any bad info or some info that is really lacking, let me know. But
> please realize that my slides are never really meant to be read on
> their own as it just goes against my presentation style. So don't
> think that some slide doesn't go into enough detail unless there is
> some URL I am missing. Every slide will be discussed more during the
> presentation than what is on the slide.

I've written down some notes while I was reading your slide. Some of the
information may be covered by your speech but better safe than sorry. ;)

* Windows builds: Configuration "Debug" or build -c Debug builds a
Py_DEBUG build. All executables and extension modules are postfixed with
_d (python_d.exe, python.exe is always the standard build). Platform X64
builds for AMD64, PGO is not available in the Express edition

* Windows doesn't use automake but a hand crafted PC/pyconfig.h file.

* IRC is missing from the communication list (#python and #python-dev on
irc.freenode.net, #python-dev gets annotations of checkins and bug
tracker activity from CIA bot)

* Bug reports: Don't forget to fill in target version, component
(extension = Modules/), type (feature request is RFE = request for
enhancements). Priority and keywords get filled in by a developer.

* Checking: Don't forget to add an entry to Misc/NEWS. Always add a note
like "Closed in r12345" when you close a bug. The revision is important
und must have the form r12345. Add the bug tracker number #1234 to the
checkin message.

* Block back ports from automatic forward merging with ".../py3k$
svnmerge.py block -r 12345" or write a note in your checkin message that
the revision must not be merged.

* Windows tests: Use "rt -d" to run unit tests for a debug build. The rt
script accepts all options regrtest.py accepts + the option -q. The
argument length on Windows is limited, consider the -f file option.

* Building docs on Windows: Require command line svn tool. Use make.bat
in the Docs/ directory. Requires HTML Help compiler to build chm files
(optional).


From brett at python.org  Tue Feb  5 03:03:32 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Feb 2008 18:03:32 -0800
Subject: [Python-Dev] Initial attempt to PyCon sprint tutorial slides
	are up
In-Reply-To: <fo8e0f$7e6$1@ger.gmane.org>
References: <bbaeab100802041329w215527e3o592adff4258bc571@mail.gmail.com>
	<fo8e0f$7e6$1@ger.gmane.org>
Message-ID: <bbaeab100802041803ic555852nd05a8b36e4cedbdf@mail.gmail.com>

On Feb 4, 2008 5:26 PM, Christian Heimes <lists at cheimes.de> wrote:
>
> Brett Cannon wrote:
> > The 1 MB PDF can be found at
> > http://www.cs.ubc.ca/~drifty/pycon/sprint_tutorial.pdf . If you find
> > any bad info or some info that is really lacking, let me know. But
> > please realize that my slides are never really meant to be read on
> > their own as it just goes against my presentation style. So don't
> > think that some slide doesn't go into enough detail unless there is
> > some URL I am missing. Every slide will be discussed more during the
> > presentation than what is on the slide.
>
> I've written down some notes while I was reading your slide. Some of the
> information may be covered by your speech but better safe than sorry. ;)
>
> * Windows builds: Configuration "Debug" or build -c Debug builds a
> Py_DEBUG build. All executables and extension modules are postfixed with
> _d (python_d.exe, python.exe is always the standard build). Platform X64
> builds for AMD64, PGO is not available in the Express edition
>

Added the debug info.

> * Windows doesn't use automake but a hand crafted PC/pyconfig.h file.
>
> * IRC is missing from the communication list (#python and #python-dev on
> irc.freenode.net, #python-dev gets annotations of checkins and bug
> tracker activity from CIA bot)

Added.

>
> * Bug reports: Don't forget to fill in target version, component
> (extension = Modules/), type (feature request is RFE = request for
> enhancements). Priority and keywords get filled in by a developer.
>

Added a note to fill in all the info.

> * Checking: Don't forget to add an entry to Misc/NEWS.

Covered on slide 42.

> Always add a note
> like "Closed in r12345" when you close a bug. The revision is important
> und must have the form r12345. Add the bug tracker number #1234 to the
> checkin message.
>

I am not worrying about checkins. Figure people who have it know what
to do. And anyone who gets it will be personally instructed on the
spot. But when it comes time to write the docs that go on the web I
will write a committer doc.

> * Block back ports from automatic forward merging with ".../py3k$
> svnmerge.py block -r 12345" or write a note in your checkin message that
> the revision must not be merged.
>

See above.

> * Windows tests: Use "rt -d" to run unit tests for a debug build. The rt
> script accepts all options regrtest.py accepts + the option -q. The
> argument length on Windows is limited, consider the -f file option.
>

Added -d to the two examples.

> * Building docs on Windows: Require command line svn tool. Use make.bat
> in the Docs/ directory. Requires HTML Help compiler to build chm files
> (optional).

Mentioned the svn need and make.bat.

-Brett

From barry at python.org  Tue Feb  5 03:22:05 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 4 Feb 2008 21:22:05 -0500
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <18343.45631.761498.201618@montanaro-dyndns-org.local>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<ca471dc20802031548i690ef2a4sf1b963dea150ce79@mail.gmail.com>
	<bbaeab100802041238l5fa820eas25fbe6b78d7f2546@mail.gmail.com>
	<18343.37704.809905.872782@montanaro-dyndns-org.local>
	<bbaeab100802041530s55d23b11gbed09473b9a3bd29@mail.gmail.com>
	<18343.45631.761498.201618@montanaro-dyndns-org.local>
Message-ID: <E54C3DA4-010E-4061-B7B3-446EDF800179@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 4, 2008, at 7:47 PM, skip at pobox.com wrote:

>
>>> I should have asked this before, but what's so special about core
>>> (Python?)  development that the tools should be different than for
>>> non-core development?
>
>    Brett> Usually the core has keywords, built-ins, etc. that have  
> not been
>    Brett> pushed to the release versions for various editors.
>
> Ah, okay.  Barry mentioned something about adjusting the python-mode  
> syntax
> tables to include Python 3.x stuff, though patches are always
> welcome. <wink>

If left to me, it might not happen until I start writing a lot of  
Python 3 code :).

>    Brett> Plus coding guidelines might be different from PEPs 7 and 8
>    Brett> compared to what an editor is set to do by default.
>
> That might be a bit more challenging.  I was thinking today that it  
> would be
> kind of nice to have a set of predefined settings for Python's new C  
> style
> (someone mentioned producing that).  Should that go in the C/C++  
> mode or be
> delivered somehow else?

I think it might not be horrible if python-mode.el included a function  
that installed Python's new C style, which you could then select  
through your mode hook or whatever.  It's been ages since I hacked on  
that stuff, but I wonder how far Python's new C style differs from the  
built-in styles.  Maybe there's one that's already close enough?

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR6fITXEjvBPtnXfVAQIlZwQApRs/VC2tV7auSRjK2AuWuFf7i/k5EPTf
ZaBSgmHtb8jENTvOZju2XOnOVdhlgHO5Zec5ptvXKc3Y1Mzl9API2RjH0jP9G8mt
mzI22bGScnCbA5bpzM7kh5cyg939+GzUmUF7BsRoAquIwKRdf5NHbJG+qcxKO0pK
vcKIuf6eJxM=
=Ltuj
-----END PGP SIGNATURE-----

From skip at pobox.com  Tue Feb  5 03:28:13 2008
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 4 Feb 2008 20:28:13 -0600
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <fo7n1d$qoe$1@ger.gmane.org>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<fo7n1d$qoe$1@ger.gmane.org>
Message-ID: <18343.51645.110565.996237@montanaro-dyndns-org.local>


    Georg> ... a style for new-style CPython code can be found at
    Georg> http://wiki.python.org/moin/NeedForSpeed/IRCLog (look for
    Georg> "python-new").

I whipped up a trivial patch for cc-styles.el and sent it along to the
cc-modes package maintainer for inclusion in a future version of that
package.

Skip

From skip at pobox.com  Tue Feb  5 03:33:22 2008
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 4 Feb 2008 20:33:22 -0600
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <18343.37610.678454.201938@montanaro-dyndns-org.local>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<18342.25110.897689.73654@montanaro-dyndns-org.local>
	<C1A99A12-168C-4E46-AC9B-6530B5D42890@northwestern.edu>
	<20080204171221.21558.2073130175.divmod.xquotient.5896@joule.divmod.com>
	<fo7mhj$o50$1@ger.gmane.org>
	<CDDF273F-3513-4F05-BC88-B95A299589BF@python.org>
	<18343.37610.678454.201938@montanaro-dyndns-org.local>
Message-ID: <18343.51954.395019.319360@montanaro-dyndns-org.local>

    skip> I should sync Misc/python-mode.el for both trunk and py3k branches
    skip> with the latest version from the SF python-mode project.

Done only on trunk.  I trust one of the mega-merges to the py3k branch will
copy it there and that backporting to 2.5 is not desired.

Skip

From alexandre at peadrop.com  Tue Feb  5 03:39:24 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Mon, 4 Feb 2008 21:39:24 -0500
Subject: [Python-Dev] Any Emacs tips for core developers?
In-Reply-To: <18343.45631.761498.201618@montanaro-dyndns-org.local>
References: <bbaeab100802031444p5831aa00uf23d930a4ba91357@mail.gmail.com>
	<ca471dc20802031548i690ef2a4sf1b963dea150ce79@mail.gmail.com>
	<bbaeab100802041238l5fa820eas25fbe6b78d7f2546@mail.gmail.com>
	<18343.37704.809905.872782@montanaro-dyndns-org.local>
	<bbaeab100802041530s55d23b11gbed09473b9a3bd29@mail.gmail.com>
	<18343.45631.761498.201618@montanaro-dyndns-org.local>
Message-ID: <acd65fa20802041839l349984a8jfd1452c5f4212d9e@mail.gmail.com>

On Feb 4, 2008 7:47 PM,  <skip at pobox.com> wrote:
>
>    >> I should have asked this before, but what's so special about core
>    >> (Python?)  development that the tools should be different than for
>    >> non-core development?
>
>    Brett> Usually the core has keywords, built-ins, etc. that have not been
>    Brett> pushed to the release versions for various editors.
>
> Ah, okay.  Barry mentioned something about adjusting the python-mode syntax
> tables to include Python 3.x stuff, though patches are always
> welcome. <wink>
>
>    Brett> Plus coding guidelines might be different from PEPs 7 and 8
>    Brett> compared to what an editor is set to do by default.
>
> That might be a bit more challenging.  I was thinking today that it would be
> kind of nice to have a set of predefined settings for Python's new C style
> (someone mentioned producing that).  Should that go in the C/C++ mode or be
> delivered somehow else?
>

It's fairly trivial to adjust cc-mode to conform PEP 7 C coding convention:

(defmacro def-styled-c-mode (name style &rest body)
  "Define styled C modes."
  `(defun ,name ()
     (interactive)
     (c-mode)
     (c-set-style ,style)
     , at body))

(def-styled-c-mode python-c-mode "python"
  (setq indent-tabs-mode t
        tab-width 8
        c-basic-offset 8))

(def-styled-c-mode py3k-c-mode "python"
  (setq indent-tabs-mode nil
        tab-width 4
        c-basic-offset 4))


-- Alexandre

From tnelson at onresolve.com  Tue Feb  5 14:38:09 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Tue, 5 Feb 2008 05:38:09 -0800
Subject: [Python-Dev] Any tips to tell sprinter at PyCon about
 developing on Windows?
Message-ID: <87D3F9C72FBF214DB39FA4E3FE618CDC6E152B4B77@EXMBX04.exchhosting.com>

Feb 2, 2008 7:34 PM, Christian Heimes <lists at cheimes.de> wrote:
> > Brett Cannon wrote:
> > It would be really cool if you can recruit some experienced Windows
> > developers. :]
> That's the point in all of this. =)
> -Brett

I'll be around for the sprints -- didn't really have a plan as to what I'd like to sprint on but if there's some interest in farming Windows developers, I'll raise my hand.  Anything in particular you can point myself or others in the Windows camp at such that we're a bit better prepared come sprint time (i.e. open issues)?

(Also, I'm looking to acquire a new reasonably well-spec'd Windows box for work.  If it's available in time for PyCon, I should be able to set up a couple of virtual 64-bit Vista/Server 2008 images with VS 2008 dev environments that non-Windows developers could use, if that would be desirable.)

    Trent.

From kristjan at ccpgames.com  Tue Feb  5 15:58:39 2008
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Tue, 5 Feb 2008 14:58:39 +0000
Subject: [Python-Dev] XXX - in funcobject.c
Message-ID: <4E9372E6B2234D4F859320D896059A950F9B09428E@exchis.ccp.ad.local>

Hello there.

in function_call() in funcobject.c, we have this comment:

/* XXX This is broken if the caller deletes dict items! */

Now,  I wonder what specifically is meant here?  are we really talking about the 'callee' here?
In PyEval_EvalCodeEx() it looks as though all keywords are always INCREFed, so the callee never gets a borrowed reference to something from the keyword dict.

Maybe this comment is out of date, or can someone demonstrate how to break the code accordingly?

The reason I ask is that I am debugging a really tricky crash case on our live servers and I am currently led to believe that the temporary array for the keyword dict is being overwritten somehow.

Cheers,

Kristj?n,
CCP games.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080205/583fefad/attachment.htm 

From guido at python.org  Tue Feb  5 22:10:29 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 5 Feb 2008 13:10:29 -0800
Subject: [Python-Dev] XXX - in funcobject.c
In-Reply-To: <4E9372E6B2234D4F859320D896059A950F9B09428E@exchis.ccp.ad.local>
References: <4E9372E6B2234D4F859320D896059A950F9B09428E@exchis.ccp.ad.local>
Message-ID: <ca471dc20802051310m6f4c108cjf5ab6d005d1fe50e@mail.gmail.com>

I think we really *are* talking about the caller -- the caller owns
the dict, if it managed to delete something from the dict before the
callee can incref it, you'd have trouble. I don't immediately see how
this could happen, which is probably why I left it as an XXX
comment...

--Guido

On Feb 5, 2008 6:58 AM, Kristj?n Valur J?nsson <kristjan at ccpgames.com> wrote:
>
>
>
>
> Hello there.
>
>
>
> in function_call() in funcobject.c, we have this comment:
>
>
>
> /* XXX This is broken if the caller deletes dict items! */
>
>
>
> Now,  I wonder what specifically is meant here?  are we really talking about
> the ?callee' here?
>
> In PyEval_EvalCodeEx() it looks as though all keywords are always INCREFed,
> so the callee never gets a borrowed reference to something from the keyword
> dict.
>
>
>
> Maybe this comment is out of date, or can someone demonstrate how to break
> the code accordingly?
>
>
>
> The reason I ask is that I am debugging a really tricky crash case on our
> live servers and I am currently led to believe that the temporary array for
> the keyword dict is being overwritten somehow.
>
>
>
> Cheers,
>
>
>
> Kristj?n,
>
> CCP games.
>
>
> _______________________________________________
> 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 amauryfa at gmail.com  Tue Feb  5 23:07:02 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 5 Feb 2008 23:07:02 +0100
Subject: [Python-Dev] XXX - in funcobject.c
In-Reply-To: <ca471dc20802051310m6f4c108cjf5ab6d005d1fe50e@mail.gmail.com>
References: <4E9372E6B2234D4F859320D896059A950F9B09428E@exchis.ccp.ad.local>
	<ca471dc20802051310m6f4c108cjf5ab6d005d1fe50e@mail.gmail.com>
Message-ID: <e27efe130802051407g5ce8f8d0hab3c90d4792d3bfc@mail.gmail.com>

Guido van Rossum wrote:
> I think we really *are* talking about the caller -- the caller owns
> the dict, if it managed to delete something from the dict before the
> callee can incref it, you'd have trouble. I don't immediately see how
> this could happen, which is probably why I left it as an XXX
> comment...

I found one way to call python code before the callee can incref the
args: the __eq__ between variable names and the dict entries. The
following snippet crashes the trunk version on win32:

class Name(str):
  def __eq__(self, other):
     del d[self]
     return str.__eq__(self, other)
  def __hash__(self):
     return str.__hash__(self)

d = {Name("a"):1, Name("b"):2}
def f(a, b): print a,b

f(**d)   # Segfault


There are several variants of this crasher; they all have more than
one keyword argument, and keywords strings must override __eq__ or
__hash__.
I could not find any other way to execute python code in this area.

-- 
Amaury Forgeot d'Arc

From guido at python.org  Tue Feb  5 23:39:01 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 5 Feb 2008 14:39:01 -0800
Subject: [Python-Dev] XXX - in funcobject.c
In-Reply-To: <e27efe130802051407g5ce8f8d0hab3c90d4792d3bfc@mail.gmail.com>
References: <4E9372E6B2234D4F859320D896059A950F9B09428E@exchis.ccp.ad.local>
	<ca471dc20802051310m6f4c108cjf5ab6d005d1fe50e@mail.gmail.com>
	<e27efe130802051407g5ce8f8d0hab3c90d4792d3bfc@mail.gmail.com>
Message-ID: <ca471dc20802051439u365ff9a5w76771df8d13c89b2@mail.gmail.com>

On Feb 5, 2008 2:07 PM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> Guido van Rossum wrote:
> > I think we really *are* talking about the caller -- the caller owns
> > the dict, if it managed to delete something from the dict before the
> > callee can incref it, you'd have trouble. I don't immediately see how
> > this could happen, which is probably why I left it as an XXX
> > comment...
>
> I found one way to call python code before the callee can incref the
> args: the __eq__ between variable names and the dict entries. The
> following snippet crashes the trunk version on win32:
>
> class Name(str):
>   def __eq__(self, other):
>      del d[self]
>      return str.__eq__(self, other)
>   def __hash__(self):
>      return str.__hash__(self)
>
> d = {Name("a"):1, Name("b"):2}
> def f(a, b): print a,b
>
> f(**d)   # Segfault
>
>
> There are several variants of this crasher; they all have more than
> one keyword argument, and keywords strings must override __eq__ or
> __hash__.
> I could not find any other way to execute python code in this area.

Thanks Amaury! Do you think it would be sufficient to change the
PyString_Check() call in PyEval_EvalCodeEx into a
PyString_CheckExact() call? Or is the proper fix to incref the values
going into the kw array and decref them upon exit?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From amauryfa at gmail.com  Wed Feb  6 01:02:22 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Wed, 6 Feb 2008 01:02:22 +0100
Subject: [Python-Dev] XXX - in funcobject.c
In-Reply-To: <ca471dc20802051439u365ff9a5w76771df8d13c89b2@mail.gmail.com>
References: <4E9372E6B2234D4F859320D896059A950F9B09428E@exchis.ccp.ad.local>
	<ca471dc20802051310m6f4c108cjf5ab6d005d1fe50e@mail.gmail.com>
	<e27efe130802051407g5ce8f8d0hab3c90d4792d3bfc@mail.gmail.com>
	<ca471dc20802051439u365ff9a5w76771df8d13c89b2@mail.gmail.com>
Message-ID: <e27efe130802051602qa790334n5a2b05c670525571@mail.gmail.com>

Guido van Rossum wrote:
> Thanks Amaury! Do you think it would be sufficient to change the
> PyString_Check() call in PyEval_EvalCodeEx into a
> PyString_CheckExact() call?

This would prevent this "attack", but would remain fragile - future
developments could allow execution of python code somewhere.

> Or is the proper fix to incref the values
> going into the kw array and decref them upon exit?

Yet Another Kind Of Tuple... However this seems the correct thing to do.

In addition, if we agree to restrict arguments names to str (and
disallow subclasses), there are easy optimizations in
PyEval_EvalCodeEx, somewhere around the "XXX slow" comment (!)

-- 
Amaury Forgeot d'Arc

From guido at python.org  Wed Feb  6 01:03:46 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 5 Feb 2008 16:03:46 -0800
Subject: [Python-Dev] XXX - in funcobject.c
In-Reply-To: <e27efe130802051602qa790334n5a2b05c670525571@mail.gmail.com>
References: <4E9372E6B2234D4F859320D896059A950F9B09428E@exchis.ccp.ad.local>
	<ca471dc20802051310m6f4c108cjf5ab6d005d1fe50e@mail.gmail.com>
	<e27efe130802051407g5ce8f8d0hab3c90d4792d3bfc@mail.gmail.com>
	<ca471dc20802051439u365ff9a5w76771df8d13c89b2@mail.gmail.com>
	<e27efe130802051602qa790334n5a2b05c670525571@mail.gmail.com>
Message-ID: <ca471dc20802051603u6b3e12f3v15056ef00c155f9@mail.gmail.com>

On Feb 5, 2008 4:02 PM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> Guido van Rossum wrote:
> > Thanks Amaury! Do you think it would be sufficient to change the
> > PyString_Check() call in PyEval_EvalCodeEx into a
> > PyString_CheckExact() call?
>
> This would prevent this "attack", but would remain fragile - future
> developments could allow execution of python code somewhere.
>
> > Or is the proper fix to incref the values
> > going into the kw array and decref them upon exit?
>
> Yet Another Kind Of Tuple... However this seems the correct thing to do.

Agreed.

> In addition, if we agree to restrict arguments names to str (and
> disallow subclasses), there are easy optimizations in
> PyEval_EvalCodeEx, somewhere around the "XXX slow" comment (!)

Do you think you have time to come up with a patch? If not, can you
file a bug for this so we won't forget?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From kristjan at ccpgames.com  Wed Feb  6 10:49:40 2008
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Wed, 6 Feb 2008 09:49:40 +0000
Subject: [Python-Dev] XXX - in funcobject.c
In-Reply-To: <e27efe130802051602qa790334n5a2b05c670525571@mail.gmail.com>
References: <4E9372E6B2234D4F859320D896059A950F9B09428E@exchis.ccp.ad.local>
	<ca471dc20802051310m6f4c108cjf5ab6d005d1fe50e@mail.gmail.com>
	<e27efe130802051407g5ce8f8d0hab3c90d4792d3bfc@mail.gmail.com>
	<ca471dc20802051439u365ff9a5w76771df8d13c89b2@mail.gmail.com>
	<e27efe130802051602qa790334n5a2b05c670525571@mail.gmail.com>
Message-ID: <4E9372E6B2234D4F859320D896059A950F9C8276ED@exchis.ccp.ad.local>



> -----Original Message-----
> From: Amaury Forgeot d'Arc [mailto:amauryfa at gmail.com]
> Sent: Wednesday, February 06, 2008 00:02
> To: Guido van Rossum
> Cc: Kristj?n Valur J?nsson; python-dev at python.org
> Subject: Re: [Python-Dev] XXX - in funcobject.c
>
> Yet Another Kind Of Tuple... However this seems the correct thing to
> do.
>
> In addition, if we agree to restrict arguments names to str (and
> disallow subclasses), there are easy optimizations in
> PyEval_EvalCodeEx, somewhere around the "XXX slow" comment (!)

Super.  I think I'll do this myself and see if the crashes go away (even though I know that doesn't constitute a proof).
Also, allow me to suggest that we preallocate stack space for, say, 10 kwargs, to avoid the malloc for the common cases.


Kristj?n

From facundobatista at gmail.com  Wed Feb  6 13:46:33 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Wed, 6 Feb 2008 10:46:33 -0200
Subject: [Python-Dev] Initial attempt to PyCon sprint tutorial slides
	are up
In-Reply-To: <bbaeab100802041329w215527e3o592adff4258bc571@mail.gmail.com>
References: <bbaeab100802041329w215527e3o592adff4258bc571@mail.gmail.com>
Message-ID: <e04bdf310802060446t77df5d7ay59b60c33db55c2c9@mail.gmail.com>

2008/2/4, Brett Cannon <brett at python.org>:

> The 1 MB PDF can be found at
> http://www.cs.ubc.ca/~drifty/pycon/sprint_tutorial.pdf . If you find
> any bad info or some info that is really lacking, let me know. But

Brett, please tell me when you have a kind of finished version of
this... I want to send it to the Python Argentina mail list.

Thank you!

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From mal at egenix.com  Wed Feb  6 14:00:04 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 06 Feb 2008 14:00:04 +0100
Subject: [Python-Dev] Limit free list of method and builtin function objects
 (was: [Python-checkins] r60614 - in python/trunk:
 Misc/NEWS	Objects/classobject.c Objects/methodobject.c)
In-Reply-To: <20080206124435.62AF71E401F@bag.python.org>
References: <20080206124435.62AF71E401F@bag.python.org>
Message-ID: <47A9AF54.5090205@egenix.com>

Hi Christian,

could you explain how you came up with the 256 entry limit ?
It appears to be rather low and somehow arbitrary.

I understand that some limit is required, but since these
objects get created a lot (e.g. for bound methods), setting the
limit too low will significantly slow down the interpreter.

BTW: What does pybench have to say to this patch ?

To get an idea of how many objects are typically part of the
free list, I'd suggest running an application such as Zope for
a while and then check the maximum numfree value.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 06 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


On 2008-02-06 13:44, christian.heimes wrote:
> Author: christian.heimes
> Date: Wed Feb  6 13:44:34 2008
> New Revision: 60614
> 
> Modified:
>    python/trunk/Misc/NEWS
>    python/trunk/Objects/classobject.c
>    python/trunk/Objects/methodobject.c
> Log:
> Limit free list of method and builtin function objects to 256 entries each.
> 
> Modified: python/trunk/Misc/NEWS
> ==============================================================================
> --- python/trunk/Misc/NEWS	(original)
> +++ python/trunk/Misc/NEWS	Wed Feb  6 13:44:34 2008
> @@ -12,6 +12,9 @@
>  Core and builtins
>  -----------------
>  
> +- Limit free list of method and builtin function objects to 256 entries
> +  each.
> +
>  - Patch #1953: Added ``sys._compact_freelists()`` and the C API functions
>    ``PyInt_CompactFreeList`` and ``PyFloat_CompactFreeList``
>    to compact the internal free lists of pre-allocted ints and floats.
> 
> Modified: python/trunk/Objects/classobject.c
> ==============================================================================
> --- python/trunk/Objects/classobject.c	(original)
> +++ python/trunk/Objects/classobject.c	Wed Feb  6 13:44:34 2008
> @@ -4,10 +4,16 @@
>  #include "Python.h"
>  #include "structmember.h"
>  
> +/* Free list for method objects to safe malloc/free overhead
> + * The im_self element is used to chain the elements.
> + */
> +static PyMethodObject *free_list;
> +static int numfree = 0;
> +#define MAXFREELIST 256
> +
>  #define TP_DESCR_GET(t) \
>      (PyType_HasFeature(t, Py_TPFLAGS_HAVE_CLASS) ? (t)->tp_descr_get : NULL)
>  
> -
>  /* Forward */
>  static PyObject *class_lookup(PyClassObject *, PyObject *,
>  			      PyClassObject **);
> @@ -2193,8 +2199,6 @@
>     In case (b), im_self is NULL
>  */
>  
> -static PyMethodObject *free_list;
> -
>  PyObject *
>  PyMethod_New(PyObject *func, PyObject *self, PyObject *klass)
>  {
> @@ -2207,6 +2211,7 @@
>  	if (im != NULL) {
>  		free_list = (PyMethodObject *)(im->im_self);
>  		PyObject_INIT(im, &PyMethod_Type);
> +		numfree--;
>  	}
>  	else {
>  		im = PyObject_GC_New(PyMethodObject, &PyMethod_Type);
> @@ -2332,8 +2337,14 @@
>  	Py_DECREF(im->im_func);
>  	Py_XDECREF(im->im_self);
>  	Py_XDECREF(im->im_class);
> -	im->im_self = (PyObject *)free_list;
> -	free_list = im;
> +	if (numfree < MAXFREELIST) {
> +		im->im_self = (PyObject *)free_list;
> +		free_list = im;
> +		numfree++;
> +	}
> +	else {
> +		PyObject_GC_Del(im);
> +	}
>  }
>  
>  static int
> @@ -2620,5 +2631,7 @@
>  		PyMethodObject *im = free_list;
>  		free_list = (PyMethodObject *)(im->im_self);
>  		PyObject_GC_Del(im);
> +		numfree--;
>  	}
> +	assert(numfree == 0);
>  }
> 
> Modified: python/trunk/Objects/methodobject.c
> ==============================================================================
> --- python/trunk/Objects/methodobject.c	(original)
> +++ python/trunk/Objects/methodobject.c	Wed Feb  6 13:44:34 2008
> @@ -4,7 +4,12 @@
>  #include "Python.h"
>  #include "structmember.h"
>  
> +/* Free list for method objects to safe malloc/free overhead
> + * The m_self element is used to chain the objects.
> + */
>  static PyCFunctionObject *free_list = NULL;
> +static int numfree = 0;
> +#define MAXFREELIST 256
>  
>  PyObject *
>  PyCFunction_NewEx(PyMethodDef *ml, PyObject *self, PyObject *module)
> @@ -14,6 +19,7 @@
>  	if (op != NULL) {
>  		free_list = (PyCFunctionObject *)(op->m_self);
>  		PyObject_INIT(op, &PyCFunction_Type);
> +		numfree--;
>  	}
>  	else {
>  		op = PyObject_GC_New(PyCFunctionObject, &PyCFunction_Type);
> @@ -125,8 +131,14 @@
>  	_PyObject_GC_UNTRACK(m);
>  	Py_XDECREF(m->m_self);
>  	Py_XDECREF(m->m_module);
> -	m->m_self = (PyObject *)free_list;
> -	free_list = m;
> +	if (numfree < MAXFREELIST) {
> +		m->m_self = (PyObject *)free_list;
> +		free_list = m;
> +		numfree++;
> +	}
> +	else {
> +		PyObject_GC_Del(m);
> +	}
>  }
>  
>  static PyObject *
> @@ -346,14 +358,16 @@
>  		PyCFunctionObject *v = free_list;
>  		free_list = (PyCFunctionObject *)(v->m_self);
>  		PyObject_GC_Del(v);
> +		numfree--;
>  	}
> +	assert(numfree == 0);
>  }
>  
>  /* PyCFunction_New() is now just a macro that calls PyCFunction_NewEx(),
>     but it's part of the API so we need to keep a function around that
>     existing C extensions can call.
>  */
> -   
> +
>  #undef PyCFunction_New
>  PyAPI_FUNC(PyObject *) PyCFunction_New(PyMethodDef *, PyObject *);
>  
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins


From guido at python.org  Wed Feb  6 17:10:39 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 6 Feb 2008 08:10:39 -0800
Subject: [Python-Dev] XXX - in funcobject.c
In-Reply-To: <4E9372E6B2234D4F859320D896059A950F9C8276ED@exchis.ccp.ad.local>
References: <4E9372E6B2234D4F859320D896059A950F9B09428E@exchis.ccp.ad.local>
	<ca471dc20802051310m6f4c108cjf5ab6d005d1fe50e@mail.gmail.com>
	<e27efe130802051407g5ce8f8d0hab3c90d4792d3bfc@mail.gmail.com>
	<ca471dc20802051439u365ff9a5w76771df8d13c89b2@mail.gmail.com>
	<e27efe130802051602qa790334n5a2b05c670525571@mail.gmail.com>
	<4E9372E6B2234D4F859320D896059A950F9C8276ED@exchis.ccp.ad.local>
Message-ID: <ca471dc20802060810s2a9d27d3q176f46008cbc7604@mail.gmail.com>

On Feb 6, 2008 1:49 AM, Kristj?n Valur J?nsson <kristjan at ccpgames.com> wrote:
>
>
> > -----Original Message-----
> > From: Amaury Forgeot d'Arc [mailto:amauryfa at gmail.com]
> > Sent: Wednesday, February 06, 2008 00:02
> > To: Guido van Rossum
> > Cc: Kristj?n Valur J?nsson; python-dev at python.org
> > Subject: Re: [Python-Dev] XXX - in funcobject.c
> >
> > Yet Another Kind Of Tuple... However this seems the correct thing to
> > do.
> >
> > In addition, if we agree to restrict arguments names to str (and
> > disallow subclasses), there are easy optimizations in
> > PyEval_EvalCodeEx, somewhere around the "XXX slow" comment (!)
>
> Super.  I think I'll do this myself and see if the crashes go away (even though I know that doesn't constitute a proof).
> Also, allow me to suggest that we preallocate stack space for, say, 10 kwargs, to avoid the malloc for the common cases.

Great idea! If you come up with a useful patch, can you attach it to
the appropriate bug issue? (issues 2015 and 2016 on bugs.python.org)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From josepharmbruster at gmail.com  Wed Feb  6 20:54:32 2008
From: josepharmbruster at gmail.com (Joseph Armbruster)
Date: Wed, 6 Feb 2008 14:54:32 -0500
Subject: [Python-Dev] bugs.pythong.org bug?
Message-ID: <938f42d70802061154r6a8bfc1dje8557951b9460f68@mail.gmail.com>

All,

I attempted to search for all issues created by me today so I could catch up
since i've been out of the loop for a bit.  I performed the following steps:

- went to bugs.python.org
- clicked search (on the lhs of the page)
- typed in josepharmbruster as creator
- clicked search

I will create an issue if deemed necessary.

Joseph Armbruster


*exceptions.KeyError*:

Debugging information follows

   1. While evaluating the standard:'request/batch' expression on line 23
   Current variables:
*templates*<roundup.cgi.templating.Templatesinstance at
0x2ab2b64c5fc8>
   *repeat*<roundup.cgi.PageTemplates.TALES.SafeMapping instance at
   0x2ab2b75ad9e0> *false*0 *context*<HTMLClass(0x2ab2b75ad908) issue> *
   utils*<roundup.cgi.templating.TemplatingUtils instance at
   0x2ab2b75ad950> *db*<roundup.cgi.templating.HTMLDatabase instance at
   0x2ab2b75ad6c8> *nothing*None *i18n*<
   roundup.cgi.TranslationService.TranslationService instance at
   0x2ab2b759e200> *true*1 *default*<
   roundup.cgi.PageTemplates.TALES.Default instance at 0x2ab2b6353b90> *
   request*<HTMLRequest {'_context': None, 'startwith': 0, 'show': <
   roundup.support.TruthDict instance at 0x2ab2b75ad830>, 'classname':
   'issue', 'special_char': '@', 'dispname': None, 'group': [('+',
   'priority')], '_client': <roundup.cgi.client.Client instance at
   0x2ab2b759e128>, 'template': 'index', 'input': <function input_xhtml at
   0x2ab2b635b758>, 'columns': ['title', 'id', 'activity', 'status'], 'sort':
   [('+', 'activity')], 'env': {'HTTP_AUTHORIZATION': None, 'SERVER_PORT':
   '8080', 'SERVER_NAME': 'localhost', 'HTTP_ACCEPT_LANGUAGE': 'en-us,en;q=
   0.5', 'SCRIPT_NAME': '', 'REQUEST_METHOD': 'GET', 'HTTP_HOST':
   'localhost:8080', 'PATH_INFO': 'issue', 'CONTENT_TYPE': 'text/plain',
   'QUERY_STRING':
   '%40search_text=&title=&%40columns=title&id=&%40columns=id&creation=&creator=josepharmbruster&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&severity=&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=1&%40columns=status&resolution=&%40pagesize=50&%40startwith=0&%40action=search',
   'TRACKER_NAME': 'tracker'}, 'form': FieldStorage(None, None,
   [MiniFieldStorage('@columns', 'title'), MiniFieldStorage('@columns', 'id'),
   MiniFieldStorage('creator', 'josepharmbruster'),
   MiniFieldStorage('@columns', 'activity'), MiniFieldStorage('@sort',
   'activity'), MiniFieldStorage('@group', 'priority'),
   MiniFieldStorage('status', '1'), MiniFieldStorage('@columns', 'status'),
   MiniFieldStorage('@pagesize', '50'), MiniFieldStorage('@startwith', '0'),
   MiniFieldStorage('@action', 'search'), MiniFieldStorage('@filter',
   'creator'), MiniFieldStorage('@filter', 'status')]), 'nodeid': None, 'base':
   'http://bugs.python.org/', 'user': <HTMLItem(0x2ab2b75ad7e8) user 2>,
   'search_text': None, 'pagesize': 50, 'filterspec': {'status': ['1'],
   'creator': []}, 'filter': ['creator', 'status'], 'client': <
   roundup.cgi.client.Client instance at 0x2ab2b759e128>}> *tracker*<
   roundup.instance.Tracker instance at 0x2ab2b64bccf8> *template*<Roundup
   PageTemplate 'issue.index.html'> *config*<
   roundup.configuration.CoreConfig instance at 0x2ab2b64bcd40>
*options*{'ok_message':
   [], 'error_message': []} *loop*<
   roundup.cgi.PageTemplates.TALES.SafeMapping instance at
   0x2ab2b75ad9e0> *status_notresolved*'-1,1,3' *columns_showall*
   'id,activity,title,creator,assignee,status' *kw_create*0
*attrs*{'tal:define':
   'batch request/batch', 'tal:condition': 'context/is_view_ok'} *columns
   *'id,activity,title,creator,status'
   2. A problem occurred in your template "issue.index.html".

 Full traceback:

Traceback (most recent call last):
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/client.py",
line 770, in renderContext
    result = pt.render(self, None, None, **args)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/templating.py",
line 323, in render
    getEngine().getContext(c), output, tal=1, strictinsert=0)()
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 192, in __call__
    self.interpret(self.program)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 666, in do_useMacro
    self.interpret(macro)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 411, in do_optTag_tal
    self.do_optTag(stuff)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 396, in do_optTag
    return self.no_tag(start, program)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 391, in no_tag
    self.interpret(program)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 689, in do_defineSlot
    self.interpret(slot)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 411, in do_optTag_tal
    self.do_optTag(stuff)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 396, in do_optTag
    return self.no_tag(start, program)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 391, in no_tag
    self.interpret(program)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
    handlers[opcode](self, args)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 462, in do_setLocal_tal
    self.engine.setLocal(name, self.engine.evaluateValue(expr))
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/PageTemplates/TALES.py",
line 227, in evaluate
    return expression(self)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 194, in __call__
    return self._eval(econtext)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 189, in _eval
    return render(ob, econtext.vars)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 95, in render
    ob = ob()
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/cgi/templating.py",
line 2463, in batch
    l = [id for id in klass.filter(matches, filterspec, sort, group)
  File "/home/roundup/roundup-production//lib/python2.4/site-packages/roundup/backends/rdbms_common.py",
line 2178, in filter
    del d[None]
KeyError
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080206/ca6823cc/attachment-0001.htm 

From martin at v.loewis.de  Wed Feb  6 21:14:46 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Feb 2008 21:14:46 +0100
Subject: [Python-Dev] bugs.pythong.org bug?
In-Reply-To: <938f42d70802061154r6a8bfc1dje8557951b9460f68@mail.gmail.com>
References: <938f42d70802061154r6a8bfc1dje8557951b9460f68@mail.gmail.com>
Message-ID: <47AA1536.5090607@v.loewis.de>

> I attempted to search for all issues created by me today so I could 
> catch up since i've been out of the loop for a bit.  I performed the 
> following steps:
> 
> - went to bugs.python.org <http://bugs.python.org>
> - clicked search (on the lhs of the page)
> - typed in josepharmbruster as creator

You need to ask for joearmbruster, then it works fine. In general,
take the string after "Hello, " on the navigation bar.

Regards,
Martin

From draghuram at gmail.com  Wed Feb  6 21:16:04 2008
From: draghuram at gmail.com (Raghuram Devarakonda)
Date: Wed, 6 Feb 2008 15:16:04 -0500
Subject: [Python-Dev] bugs.pythong.org bug?
In-Reply-To: <938f42d70802061154r6a8bfc1dje8557951b9460f68@mail.gmail.com>
References: <938f42d70802061154r6a8bfc1dje8557951b9460f68@mail.gmail.com>
Message-ID: <2c51ecee0802061216x1997b3acradbe103b769d0d74@mail.gmail.com>

On Feb 6, 2008 2:54 PM, Joseph Armbruster <josepharmbruster at gmail.com> wrote:

> - went to bugs.python.org
>  - clicked search (on the lhs of the page)
> - typed in josepharmbruster as creator
> - clicked search
>
> I will create an issue if deemed necessary.
>
> Joseph Armbruster
>
> exceptions.KeyError:

There seems to be a bug open for this problem:

http://psf.upfronthosting.co.za/roundup/meta/issue179

For tracker issues, the right place to ask is tracker-discuss list.

Thanks,
Raghu

From python at rcn.com  Thu Feb  7 02:34:21 2008
From: python at rcn.com (Raymond Hettinger)
Date: Wed,  6 Feb 2008 20:34:21 -0500 (EST)
Subject: [Python-Dev] Buildbot failures
Message-ID: <20080206203421.AGL91437@ms19.lnh.mail.rcn.net>

Some of bsddb tests are failing.  In Py3.0 I switched the bsddb modules from UserDict.DictMixin to collections.MutableMapping.  But, the failures are also happened in the Py2.6 branch so something else must be the cause.  The db.InvalidArgError suggests that one of the defined constants is broken.

There is also a recurring failure in SocketServer.py  returning "ValueError: list.remove(x): x not in list" during attempts to remove a PID from the list of active_children.  Any ideas about what is causing this?

The freelists optimization has been causing periodic failure in test_sys., "test_compact_freelists self.assert_(r[0][2] > 100, r[0][2])".

Also, test_docxmlrpc hasn't been happy. One of the tests isn't getting the exact response string it expected.   Any ideas what is causing this?


Raymond

From brett at python.org  Thu Feb  7 09:05:26 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 7 Feb 2008 00:05:26 -0800
Subject: [Python-Dev] Get rid of strerror.c and memmove.c?
Message-ID: <bbaeab100802070005y79770dceqa801714dbb018762@mail.gmail.com>

I ran LLVM's under-development C front-end, clang
(http://clang.llvm.org), against Python today. While a ton of message
crop up thanks to lacking header files, I did come across a handful of
semi-useful warnings (e.g., the change I checked into
Python/compile.c).

One thing it picked up is that on OS X Python/strerror.c disagrees
with the declaration of sys_nerr and such. But then I thought I
remembered strerror() being in C89. I checked configure-in to make
sure that it wasn't special for some reason, it it isn't; only used
when the function is not normally available. Same goes for memmove().

Since both strerror() and memmove() are both in C89 (they are listed
in K&R), can we ditch these files?

-Brett

From asmodai at in-nomine.org  Thu Feb  7 12:13:09 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Thu, 7 Feb 2008 12:13:09 +0100
Subject: [Python-Dev] Get rid of strerror.c and memmove.c?
In-Reply-To: <bbaeab100802070005y79770dceqa801714dbb018762@mail.gmail.com>
References: <bbaeab100802070005y79770dceqa801714dbb018762@mail.gmail.com>
Message-ID: <20080207111309.GE39133@nexus.in-nomine.org>

-On [20080207 09:05], Brett Cannon (brett at python.org) wrote:
>Since both strerror() and memmove() are both in C89 (they are listed
>in K&R), can we ditch these files?

You got my vote. I am assuming the minimum needed compiler is C90 (ISO over
ANSI, sorry :P) and you might even need the AM1 from 1994 for multibyte
support anyway (so effectively C94).

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
We have met the enemy and they are ours...

From andymac at bullseye.apana.org.au  Thu Feb  7 14:09:13 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Thu, 07 Feb 2008 23:09:13 +1000
Subject: [Python-Dev] int/float freelists vs pymalloc
Message-ID: <47AB02F9.1010501@bullseye.andymac.org>

I note that in r60567 Christian checked in support for compacting the
int and float freelists.

I have no problems with the implementation, but would like to note
that I have been experimenting with an alternate approach which doesn't
require the addition of a knob to initiate the compacting.

Probably in response to the same stimulus as Christian it occurred to me
that the freelist approach had been adopted long before PyMalloc was
enabled as standard (in 2.3), and that much of the performance gains
between 2.2 and 2.3 were in fact due to PyMalloc.

So I've been testing with the freelists ripped out and ints and floats
reverted to fairly standard PyObject_New allocation (retaining the small
int interning) and thus relying on PyMalloc to do any compaction.

The results have been somewhat surprising...

The short version is that:
- for ints, the freelist is ahead of PyMalloc by a very small margin
   (<4%)
- for floats, the freelist is a long way behind PyMalloc (>35% slower)

This without invoking freelist compaction by the way (though PyMalloc
is releasing empty arenas).

I don't know what's pessimising the float freelist, but the results are
similar on 2 boxes:
- AMD Athlon XP-1600+, 512MB RAM, FreeBSD 6.1, gcc 3.4.4
   (~27k pystones)
- AMD Athlon XP-2500+, 512MB RAM, OS/2 v4 with EMX, gcc 2.8.1
   (~38k pystones)

If there's interest in following this up, I can put my patches to 
intobject.c and floatobject.c into the tracker.

Test scripts:
a) int

<code>
# test routine - integer

import time

def b(time_now=time.clock):
     limit_val = 2000000
     start_time = time_now()
     for j in xrange(25):
         d = {}
         for i in xrange(limit_val):
             d[i] = i + limit_val
     return time_now() - start_time

if __name__ == '__main__':
     print 'elapsed: %s s' % b()
</code>

b) float

<code>
# test routine - float

import time

def b(time_now=time.clock):
     limit_val = 1000000
     vals = range(limit_val)
     offset = limit_val * 1.0
     start_time = time_now()
     for j in xrange(25):
         d = {}
         for i in [float(x) for x in vals]:
             d[i] = i + offset
     return time_now() - start_time

if __name__ == '__main__':
     print 'elapsed: %s s' % b()
</code>

The times I've obtained were:

case                  XP1600/Fbsd     XP2500/OS2 (*)
1) int freelist          38.1s           24.6s
2) int pymalloc          39.0s           25.3s
3) float freelist
    (with int freelist)   75s             46.1s
4) float pymalloc
    -with int freelist    55s             29.0s
    -with int pymalloc    55.5s           29.5s

(*) OS/2 tests based on patched 2.5.1 sources rather than svn trunk.
     FreeBSD tests based on svn trunk checked out at 1050UTC 7Feb08.

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

From amk at amk.ca  Thu Feb  7 15:08:26 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Thu, 7 Feb 2008 09:08:26 -0500
Subject: [Python-Dev] Buildbot failures
In-Reply-To: <20080206203421.AGL91437@ms19.lnh.mail.rcn.net>
References: <20080206203421.AGL91437@ms19.lnh.mail.rcn.net>
Message-ID: <20080207140826.GA5858@amk-desktop.matrixgroup.net>

On Wed, Feb 06, 2008 at 08:34:21PM -0500, Raymond Hettinger wrote:
> Also, test_docxmlrpc hasn't been happy. One of the tests isn't
> getting the exact response string it expected.  Any ideas what is
> causing this?

My fault; it should be fixed now.

> There is also a recurring failure in SocketServer.py returning
> "ValueError: list.remove(x): x not in list" during attempts to
> remove a PID from the list of active_children.  Any ideas about what
> is causing this?

I couldn't find a current build that was showing this error, but
searching python.org turned up one that had been indexed:

http://www.python.org/dev/buildbot/trunk/ppc%20Debian%20unstable%20trunk/builds/726/step-test/0

I don't see what could be causing this failure, though; the test isn't
starting any subprocesses outside of what the ForkingServer class
does.  I don't see how this could be an artifact of the buildbot
environment, either.

It would be easy to add an 'if pid in self.active_children' to the
code, but I don't want to do that without understanding the problem.

--amk

From exarkun at divmod.com  Thu Feb  7 15:13:21 2008
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Thu, 7 Feb 2008 09:13:21 -0500
Subject: [Python-Dev] Buildbot failures
In-Reply-To: <20080207140826.GA5858@amk-desktop.matrixgroup.net>
Message-ID: <20080207141321.6859.532077555.divmod.quotient.6283@ohm>

On Thu, 7 Feb 2008 09:08:26 -0500, "A.M. Kuchling" <amk at amk.ca> wrote:
>On Wed, Feb 06, 2008 at 08:34:21PM -0500, Raymond Hettinger wrote:
>> Also, test_docxmlrpc hasn't been happy. One of the tests isn't
>> getting the exact response string it expected.  Any ideas what is
>> causing this?
>
>My fault; it should be fixed now.
>
>> There is also a recurring failure in SocketServer.py returning
>> "ValueError: list.remove(x): x not in list" during attempts to
>> remove a PID from the list of active_children.  Any ideas about what
>> is causing this?
>
>I couldn't find a current build that was showing this error, but
>searching python.org turned up one that had been indexed:
>
>http://www.python.org/dev/buildbot/trunk/ppc%20Debian%20unstable%20trunk/builds/726/step-test/0
>
>I don't see what could be causing this failure, though; the test isn't
>starting any subprocesses outside of what the ForkingServer class
>does.  I don't see how this could be an artifact of the buildbot
>environment, either.
>
>It would be easy to add an 'if pid in self.active_children' to the
>code, but I don't want to do that without understanding the problem.

You could instrument fork() so that it logs the call stack and the child
PID and instrument ForkingServer so that it reports which PID it is about
to try to remove from active_children.  Perhaps this will point to the
problem.

Jean-Paul

From nicdumz at gmail.com  Thu Feb  7 17:31:18 2008
From: nicdumz at gmail.com (Nicolas Dumazet)
Date: Thu, 7 Feb 2008 17:31:18 +0100
Subject: [Python-Dev] Can't decode \x876F character encoded in Shift JIS
	charset ?
Message-ID: <1f077e770802070831l22d097bdtc8b531eeba9d0050@mail.gmail.com>

>>> unicode('\x87\x6F', "shift jis")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'shift_jis' codec can't decode bytes in position 0-1:
illegal multibyte sequence

Still, \x87\x6F is a valid Shift-JIS character :
http://demo.icu-project.org/icu-bin/convexp?conv=ibm-943_P15A-2003&b=87&s=MIME#layout,
it is "?"...

Thanks,

-- 
Nicolas Dumazet ? NicDumZ
Deuxi?me ann?e ENSIMAG.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080207/56ae6ec3/attachment.htm 

From lists at cheimes.de  Thu Feb  7 18:24:28 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 07 Feb 2008 18:24:28 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47AB02F9.1010501@bullseye.andymac.org>
References: <47AB02F9.1010501@bullseye.andymac.org>
Message-ID: <fofesd$2pd$1@ger.gmane.org>

Andrew MacIntyre wrote:
> So I've been testing with the freelists ripped out and ints and floats
> reverted to fairly standard PyObject_New allocation (retaining the small
> int interning) and thus relying on PyMalloc to do any compaction.

Nice! What do you mean with int interning? Are you talking about the
small int cache?

> The results have been somewhat surprising...
> 
> The short version is that:
> - for ints, the freelist is ahead of PyMalloc by a very small margin
>    (<4%)
> - for floats, the freelist is a long way behind PyMalloc (>35% slower)
> 
> This without invoking freelist compaction by the way (though PyMalloc
> is releasing empty arenas).
> 
> I don't know what's pessimising the float freelist, but the results are
> similar on 2 boxes:
> - AMD Athlon XP-1600+, 512MB RAM, FreeBSD 6.1, gcc 3.4.4
>    (~27k pystones)
> - AMD Athlon XP-2500+, 512MB RAM, OS/2 v4 with EMX, gcc 2.8.1
>    (~38k pystones)

That's interesting. I wouldn't have thought that floats are much faster
with pymalloc. I'd bet that pymalloc is a tiny bit slower until the new
free list is filled.

> If there's interest in following this up, I can put my patches to 
> intobject.c and floatobject.c into the tracker.

I've uploaded my patch at http://bugs.python.org/issue2039. It keeps a
standard free list with 8192 elements for floats and ints. Does your
patch also use a free list or does it alloc/free directly?

Can your profile my patch and compare it to your results? It may be a
bit faster if your patch doesn't use a free list.

Christian


From amauryfa at gmail.com  Thu Feb  7 18:12:35 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 7 Feb 2008 18:12:35 +0100
Subject: [Python-Dev] Can't decode \x876F character encoded in Shift JIS
	charset ?
In-Reply-To: <1f077e770802070831l22d097bdtc8b531eeba9d0050@mail.gmail.com>
References: <1f077e770802070831l22d097bdtc8b531eeba9d0050@mail.gmail.com>
Message-ID: <e27efe130802070912rd7cecb4n11cefe0108009987@mail.gmail.com>

Hello,

Nicolas Dumazet :
> >>> unicode('\x87\x6F', "shift jis")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> UnicodeDecodeError: 'shift_jis' codec can't decode bytes in position 0-1:
> illegal multibyte sequence
>
> Still, \x87\x6F is a valid Shift-JIS character :
> http://demo.icu-project.org/icu-bin/convexp?conv=ibm-943_P15A-2003&b=87&s=MIME#layout,
> it is "?L"...

It is possible that the encoding is actually "shift jis 2004" or
"cp932", which are both extensions to the original shift jis.
Please continue this discussion on comp.lang.python; or fill a bug request.

Cheers quand m??me,

-- 
Amaury Forgeot d'Arc

From martin at v.loewis.de  Thu Feb  7 23:06:56 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 07 Feb 2008 23:06:56 +0100
Subject: [Python-Dev] Can't decode \x876F character encoded in Shift JIS
 charset ?
In-Reply-To: <1f077e770802070831l22d097bdtc8b531eeba9d0050@mail.gmail.com>
References: <1f077e770802070831l22d097bdtc8b531eeba9d0050@mail.gmail.com>
Message-ID: <47AB8100.9040305@v.loewis.de>

> UnicodeDecodeError: 'shift_jis' codec can't decode bytes in position 
> 0-1: illegal multibyte sequence

As Amaury says, this is CP932 and Shift-Jis-2004, but not Shift-Jis.
The IBM database must be incorrect: it lists as "all aliases" both
csShiftJIS and csWindows31J, yet, according to

http://www.iana.org/assignments/character-sets

they are different (MIBEnum 17 vs MIBEnum 2024).

Regards,
Martin

From mal at egenix.com  Fri Feb  8 01:23:25 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 08 Feb 2008 01:23:25 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47AB02F9.1010501@bullseye.andymac.org>
References: <47AB02F9.1010501@bullseye.andymac.org>
Message-ID: <47ABA0FD.60306@egenix.com>

On 2008-02-07 14:09, Andrew MacIntyre wrote:
> Probably in response to the same stimulus as Christian it occurred to me
> that the freelist approach had been adopted long before PyMalloc was
> enabled as standard (in 2.3), and that much of the performance gains
> between 2.2 and 2.3 were in fact due to PyMalloc.

One of the hopes of having a custom allocator for Python was to be
able to get rid off all free lists. For some reason that never happened.
Not sure why. People were probably too busy with adding new
features to the language at the time ;-)

Something you could try to make PyMalloc perform better for the builtin
types is to check the actual size of the allocated PyObjects and then
make sure that PyMalloc uses arenas large enough to hold a good quantity
of them, e.g. it's possible that the float types fall into the same
arena as some other type and thus don't have enough "room" to use
as free list.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 08 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 nnorwitz at gmail.com  Fri Feb  8 07:01:49 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 7 Feb 2008 22:01:49 -0800
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47AB02F9.1010501@bullseye.andymac.org>
References: <47AB02F9.1010501@bullseye.andymac.org>
Message-ID: <ee2a432c0802072201u33e5f9d1pa475bbc7038b905b@mail.gmail.com>

On Feb 7, 2008 5:09 AM, Andrew MacIntyre <andymac at bullseye.apana.org.au> wrote:
>
> So I've been testing with the freelists ripped out and ints and floats
> reverted to fairly standard PyObject_New allocation (retaining the small
> int interning) and thus relying on PyMalloc to do any compaction.
>
> The results have been somewhat surprising...
>
> The short version is that:
> - for ints, the freelist is ahead of PyMalloc by a very small margin
>    (<4%)
> - for floats, the freelist is a long way behind PyMalloc (>35% slower)

Martin did some profiling of ints in py3k 1.5 years ago.  The results
of his profiling are here:
    http://svn.python.org/projects/python/branches/py3k/INTBENCH

I think Martin wrote a mail to describe his work in more detail.  But
the only mails I could find are not what I remember:

  http://mail.python.org/pipermail/python-3000/2006-August/003185.html
  http://mail.python.org/pipermail/python-3000/2006-August/003064.html

I don't remember if he did any work on head or if he remembers any
more that might be relevant here.

n

From martin at v.loewis.de  Fri Feb  8 08:21:05 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 08 Feb 2008 08:21:05 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47ABA0FD.60306@egenix.com>
References: <47AB02F9.1010501@bullseye.andymac.org> <47ABA0FD.60306@egenix.com>
Message-ID: <47AC02E1.4020300@v.loewis.de>

> One of the hopes of having a custom allocator for Python was to be
> able to get rid off all free lists. For some reason that never happened.
> Not sure why. People were probably too busy with adding new
> features to the language at the time ;-)

Probably not. It's more that the free lists still outperformed pymalloc.

> Something you could try to make PyMalloc perform better for the builtin
> types is to check the actual size of the allocated PyObjects and then
> make sure that PyMalloc uses arenas large enough to hold a good quantity
> of them, e.g. it's possible that the float types fall into the same
> arena as some other type and thus don't have enough "room" to use
> as free list.

I don't think any improvements can be gained here. PyMalloc carves
out pools of 4096 bytes from an arena when it runs out of blocks
for a certain size class, and then keeps a linked list of pools of
the same size class. So when many float objects get allocated,
you'll have a lot of pools of the float type's size class.
IOW, PyMalloc has always enough room.

Regards,
Martin

From mal at egenix.com  Fri Feb  8 12:23:46 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 08 Feb 2008 12:23:46 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47AC02E1.4020300@v.loewis.de>
References: <47AB02F9.1010501@bullseye.andymac.org>
	<47ABA0FD.60306@egenix.com> <47AC02E1.4020300@v.loewis.de>
Message-ID: <47AC3BC2.9010809@egenix.com>

On 2008-02-08 08:21, Martin v. L?wis wrote:
>> One of the hopes of having a custom allocator for Python was to be
>> able to get rid off all free lists. For some reason that never happened.
>> Not sure why. People were probably too busy with adding new
>> features to the language at the time ;-)
> 
> Probably not. It's more that the free lists still outperformed pymalloc.
> 
>> Something you could try to make PyMalloc perform better for the builtin
>> types is to check the actual size of the allocated PyObjects and then
>> make sure that PyMalloc uses arenas large enough to hold a good quantity
>> of them, e.g. it's possible that the float types fall into the same
>> arena as some other type and thus don't have enough "room" to use
>> as free list.
> 
> I don't think any improvements can be gained here. PyMalloc carves
> out pools of 4096 bytes from an arena when it runs out of blocks
> for a certain size class, and then keeps a linked list of pools of
> the same size class. So when many float objects get allocated,
> you'll have a lot of pools of the float type's size class.
> IOW, PyMalloc has always enough room.

Well, yes, it doesn't run out of memory, but if pymalloc needs
to allocate lots of objects of the same size, then performance
degrades due to the management overhead involved for checking
the free pools as well as creating new arenas as needed.

To reduce this overhead, it may be a good idea to preallocate
pools for common sizes and make sure they don't drop under a
certain threshold.

Here's a list of a few object sizes in bytes for Python 2.5
on an AMD64 machine:

>>> import mx.Tools
>>> mx.Tools.sizeof(int(0))
24
>>> mx.Tools.sizeof(float(0))
24

8-bit strings are var objects:

>>> mx.Tools.sizeof(str(''))
40
>>> mx.Tools.sizeof(str('a'))
41

Unicode objects use an external buffer:

>>> mx.Tools.sizeof(unicode(''))
48
>>> mx.Tools.sizeof(unicode('a'))
48

Lists do as well:

>>> mx.Tools.sizeof(list())
40
>>> mx.Tools.sizeof(list([1,2,3]))
40

Tuples are var objects:

>>> mx.Tools.sizeof(tuple())
24
>>> mx.Tools.sizeof(tuple([1,2,3]))
48

Old style classes:

>>> class C: pass
...
>>> mx.Tools.sizeof(C)
64

New style classes are a lot heavier:

>>> class D(object): pass
...
>>> mx.Tools.sizeof(D)
848
>>>
>>> mx.Tools.sizeof(type(2))
848


As you can see, Integers and floats fall into the same pymalloc size
class. What's strange in Andrew's result is that both integers
and floats use the same free list technique and fall into the same
pymalloc size class, yet the results are different.

The only difference that's apparent is that small integers are
shared, so depending on the data set used for the test, fewer
calls to pymalloc or the free list are made.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 08 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 andymac at bullseye.apana.org.au  Fri Feb  8 12:53:54 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Fri, 08 Feb 2008 21:53:54 +1000
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47ABA0FD.60306@egenix.com>
References: <47AB02F9.1010501@bullseye.andymac.org> <47ABA0FD.60306@egenix.com>
Message-ID: <47AC42D2.1010701@bullseye.andymac.org>

M.-A. Lemburg wrote:
> On 2008-02-07 14:09, Andrew MacIntyre wrote:
>> Probably in response to the same stimulus as Christian it occurred to me
>> that the freelist approach had been adopted long before PyMalloc was
>> enabled as standard (in 2.3), and that much of the performance gains
>> between 2.2 and 2.3 were in fact due to PyMalloc.
> 
> One of the hopes of having a custom allocator for Python was to be
> able to get rid off all free lists. For some reason that never happened.
> Not sure why. People were probably too busy with adding new
> features to the language at the time ;-)

Very probably ;-)

> Something you could try to make PyMalloc perform better for the builtin
> types is to check the actual size of the allocated PyObjects and then
> make sure that PyMalloc uses arenas large enough to hold a good quantity
> of them, e.g. it's possible that the float types fall into the same
> arena as some other type and thus don't have enough "room" to use
> as free list.

Like MvL, I doubt it.  Uncle Timmy did a pretty thorough nose-clean on
PyMalloc.

However, my tests do show that something is funny with the current
freelist implementation for floats on at least 2 platforms, and that
doing without that sort of optimisation for float objects would likely
not be a hardship with PyMalloc.

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

From status at bugs.python.org  Fri Feb  8 19:06:13 2008
From: status at bugs.python.org (Tracker)
Date: Fri,  8 Feb 2008 18:06:13 +0000 (UTC)
Subject: [Python-Dev] Summary of Tracker Issues
Message-ID: <20080208180613.36E2978250@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (02/01/08 - 02/08/08)
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.


 1691 open (+30) / 12209 closed (+18) / 13900 total (+48)

Open issues with patches:   437

Average duration of open issues: 754 days.
Median duration of open issues: 1065 days.

Open Issues Breakdown
   open  1667 (+30)
pending    24 ( +0)

Issues Created Or Reopened (49)
_______________________________

localeconv() does not encode returned strings                    02/01/08
       http://bugs.python.org/issue1995    created  pitrou                   
                                                                               

float.as_integer_ratio() needs to return fraction in lowest term 02/01/08
CLOSED http://bugs.python.org/issue1996    created  rhettinger               
                                                                               

unicode and string compare should not cause an exception         02/01/08
CLOSED http://bugs.python.org/issue1997    created  aaron_watters            
                                                                               

documentation grammatical error                                  02/02/08
CLOSED http://bugs.python.org/issue1998    created  mickbeaver               
       easy                                                                    

wrong tracker                                                    02/02/08
CLOSED http://bugs.python.org/issue1999    created  mickbeaver               
                                                                               

Undefined symbols: _PyOS_mystrnicmp on Mac OS X                  02/02/08
CLOSED http://bugs.python.org/issue2000    created  belopolsky               
                                                                               

Pydoc interactive browsing enhancement                           02/02/08
       http://bugs.python.org/issue2001    created  ron_adam                 
                                                                               

Make int() fall back to trunc()                                  02/02/08
CLOSED http://bugs.python.org/issue2002    created  jyasskin                 
       patch                                                                   

Incorrect definition of new-style class                          02/03/08
CLOSED http://bugs.python.org/issue2003    created  thaneplummer             
                                                                               

tarfile extractall() allows local attacker to overwrite files wh 02/03/08
CLOSED http://bugs.python.org/issue2004    created  mebrown                  
                                                                               

posixmodule expects sizeof(pid_t/gid_t/uid_t) <= sizeof(long)    02/03/08
       http://bugs.python.org/issue2005    created  tiran                    
       easy                                                                    

asyncore loop lacks timers and work tasks                        02/04/08
       http://bugs.python.org/issue2006    created  janssen                  
                                                                               

cookielib lacks FileCookieJar class for Internet Explorer        02/04/08
       http://bugs.python.org/issue2007    created  janssen                  
                                                                               

cookielib lacks FileCookieJar class for Safari                   02/04/08
       http://bugs.python.org/issue2008    created  janssen                  
                                                                               

Grammar change to prevent shift/reduce problem with varargslist  02/05/08
       http://bugs.python.org/issue2009    created  dalke                    
                                                                               

Link to howto section on re module documentation incorrect       02/05/08
CLOSED http://bugs.python.org/issue2010    created  knorby                   
                                                                               

compiler.parse("1;") adds unexpected extra Discard(Const(None))  02/05/08
CLOSED http://bugs.python.org/issue2011    created  dalke                    
                                                                               

Add migration step for DictMixin -> collections.MutableMapping   02/05/08
       http://bugs.python.org/issue2012    created  tiran                    
                                                                               

Long object free list optimization                               02/05/08
       http://bugs.python.org/issue2013    created  tiran                    
       patch                                                                   

xmlrpclib cannot send datetime objects with dates before 1900    02/05/08
       http://bugs.python.org/issue2014    created  schmir                   
       patch                                                                   

Possible optimisations in kwargs handling                        02/06/08
       http://bugs.python.org/issue2015    created  amaury.forgeotdarc       
                                                                               

Crash when modifying the **kwargs passed to a function.          02/06/08
       http://bugs.python.org/issue2016    created  amaury.forgeotdarc       
                                                                               

Calendar.yeardatescalendar etc. do not take 'month' argument     02/06/08
CLOSED http://bugs.python.org/issue2017    created  mft                      
       easy                                                                    

TextCalendar.formatmonth is not influenced by setfirstweekday    02/06/08
CLOSED http://bugs.python.org/issue2018    created  mft                      
       easy                                                                    

API to clear most free lists                                     02/06/08
       http://bugs.python.org/issue2019    created  tiran                    
       patch                                                                   

_sha256 module missing if openssl is not in a "normal" directory 02/06/08
       http://bugs.python.org/issue2020    created  pajs at fodder.org.uk       
                                                                               

Turn NamedTemporaryFile into a context manager                   02/06/08
       http://bugs.python.org/issue2021    created  belopolsky               
       patch                                                                   

test_al converted to unittest                                    02/06/08
       http://bugs.python.org/issue2022    created  giampaolo.rodola         
                                                                               

test_cd converted to unittest                                    02/06/08
       http://bugs.python.org/issue2023    created  giampaolo.rodola         
                                                                               

test_gl.py converted to unittest                                 02/06/08
       http://bugs.python.org/issue2024    created  giampaolo.rodola         
                                                                               

tuples are instances of collections.Sequence but do not support  02/06/08
CLOSED http://bugs.python.org/issue2025    created  rhettinger               
                                                                               

test_largefile.py converted to unittest                          02/06/08
       http://bugs.python.org/issue2026    created  giampaolo.rodola         
                                                                               

Module containing C implementations of common text algorithms    02/07/08
       http://bugs.python.org/issue2027    created  mchaput                  
                                                                               

_fmode = O_TEXT is obsolete                                      02/07/08
CLOSED http://bugs.python.org/issue2028    created  zde                      
                                                                               

"python -m pydoc -g"  fails                                      02/07/08
       http://bugs.python.org/issue2029    created  bpb                      
                                                                               

win32pdh.EnumObjects fails on Windows Server 2003 R2             02/07/08
CLOSED http://bugs.python.org/issue2038    created  rmason                   
                                                                               

Pymalloc patch for int and float objects                         02/07/08
       http://bugs.python.org/issue2039    created  tiran                    
       patch                                                                   

Class instance attributes that are property() should appear in _ 02/07/08
CLOSED http://bugs.python.org/issue2040    created  jag                      
                                                                               

__getslice__ still called                                        02/07/08
CLOSED http://bugs.python.org/issue2041    created  stefan                   
                                                                               

test_audioop.py converted to unittest                            02/07/08
       http://bugs.python.org/issue2042    created  giampaolo.rodola         
                                                                               

test_cl.py converted to unittest                                 02/07/08
       http://bugs.python.org/issue2043    created  giampaolo.rodola         
       easy                                                                    

test_sunaudiodev.py converted to unittest                        02/07/08
       http://bugs.python.org/issue2044    created  giampaolo.rodola         
                                                                               

defaultdict subclasses segfault with a bound method set as a def 02/07/08
CLOSED http://bugs.python.org/issue2045    created  jek                      
                                                                               

patch to fix_import: UserDict -> collections                     02/07/08
       http://bugs.python.org/issue2046    created  eopadoan                 
                                                                               

shutil.destinsrc returns wrong result when source path matches b 02/08/08
       http://bugs.python.org/issue2047    created  computercrustie          
                                                                               

Python 2.5.1 woes on IRIX, Solaris                               02/08/08
       http://bugs.python.org/issue2048    created  atossava                 
                                                                               

IDLE - Restart Shell & Run Module                                02/08/08
       http://bugs.python.org/issue2049    created  taleinat                 
       patch                                                                   

IDLE - make ScriptBinding event handlers return 'break'          02/08/08
       http://bugs.python.org/issue2050    created  taleinat                 
                                                                               

Thread shutdown exception in Thread.notify()                     02/05/08
       http://bugs.python.org/issue1722344 reopened brett.cannon             
                                                                               



Issues Now Closed (39)
______________________

libffi needs an update to support mips64, arm and armeabi on lin  112 days
       http://bugs.python.org/issue1292    doko                     
                                                                               

urllib2 302 POST                                                   92 days
       http://bugs.python.org/issue1401    facundobatista           
                                                                               

test_plistlib fails                                                11 days
       http://bugs.python.org/issue1914    tiran                    
                                                                               

test_descr.py converted to unittest                                 7 days
       http://bugs.python.org/issue1935    georg.brandl             
       patch                                                                   

re.search hangs on this                                             9 days
       http://bugs.python.org/issue1946    facundobatista           
                                                                               

Exception exceptions.AttributeError '_shutdown' in <module 'thre   11 days
       http://bugs.python.org/issue1947    facundobatista           
                                                                               

test_wave.py converted to unittest                                 10 days
       http://bugs.python.org/issue1951    giampaolo.rodola         
       patch, easy                                                             

test_contains.py converted to unittest                              9 days
       http://bugs.python.org/issue1959    facundobatista           
                                                                               

Move trunc() to math module                                         3 days
       http://bugs.python.org/issue1965    jyasskin                 
                                                                               

pybsddb leak in using cursors                                       4 days
       http://bugs.python.org/issue1976    gregory.p.smith          
                                                                               

Make Decimal comparisons with NaN less arbitrary                    7 days
       http://bugs.python.org/issue1979    marketdickinson          
       patch                                                                   

float.as_integer_ratio() needs to return fraction in lowest term    0 days
       http://bugs.python.org/issue1996    rhettinger               
                                                                               

unicode and string compare should not cause an exception            1 days
       http://bugs.python.org/issue1997    gvanrossum               
                                                                               

documentation grammatical error                                     0 days
       http://bugs.python.org/issue1998    georg.brandl             
       easy                                                                    

wrong tracker                                                       0 days
       http://bugs.python.org/issue1999    loewis                   
                                                                               

Undefined symbols: _PyOS_mystrnicmp on Mac OS X                     0 days
       http://bugs.python.org/issue2000    georg.brandl             
                                                                               

Make int() fall back to trunc()                                     1 days
       http://bugs.python.org/issue2002    jyasskin                 
       patch                                                                   

Incorrect definition of new-style class                             0 days
       http://bugs.python.org/issue2003    georg.brandl             
                                                                               

tarfile extractall() allows local attacker to overwrite files wh    2 days
       http://bugs.python.org/issue2004    georg.brandl             
                                                                               

Link to howto section on re module documentation incorrect          0 days
       http://bugs.python.org/issue2010    georg.brandl             
                                                                               

compiler.parse("1;") adds unexpected extra Discard(Const(None))     0 days
       http://bugs.python.org/issue2011    ncoghlan                 
                                                                               

Calendar.yeardatescalendar etc. do not take 'month' argument        0 days
       http://bugs.python.org/issue2017    doerwalter               
       easy                                                                    

TextCalendar.formatmonth is not influenced by setfirstweekday       2 days
       http://bugs.python.org/issue2018    mft                      
       easy                                                                    

tuples are instances of collections.Sequence but do not support     0 days
       http://bugs.python.org/issue2025    rhettinger               
                                                                               

_fmode = O_TEXT is obsolete                                         0 days
       http://bugs.python.org/issue2028    loewis                   
                                                                               

win32pdh.EnumObjects fails on Windows Server 2003 R2                0 days
       http://bugs.python.org/issue2038    amaury.forgeotdarc       
                                                                               

Class instance attributes that are property() should appear in _    1 days
       http://bugs.python.org/issue2040    tiran                    
                                                                               

__getslice__ still called                                           0 days
       http://bugs.python.org/issue2041    marketdickinson          
                                                                               

defaultdict subclasses segfault with a bound method set as a def    0 days
       http://bugs.python.org/issue2045    amaury.forgeotdarc       
                                                                               

Issue warning when LC_NUMERIC is not "C"                         2477 days
       http://bugs.python.org/issue419153  draghuram                
                                                                               

Memory Usage Reporting                                           2128 days
       http://bugs.python.org/issue540952  draghuram                
                                                                               

os.listdir-alike that includes file type                         1948 days
       http://bugs.python.org/issue619222  draghuram                
                                                                               

SRE bugs with capturing groups in negative assertions            1753 days
       http://bugs.python.org/issue725149  draghuram                
                                                                               

Check for signals during regular expression matches              1537 days
       http://bugs.python.org/issue846388  gvanrossum               
       patch                                                                   

pdb should hash stdout                                           1437 days
       http://bugs.python.org/issue908316  rhettinger               
       easy                                                                    

NaN comparison in Decimal broken                                  587 days
       http://bugs.python.org/issue1514428 marketdickinson          
                                                                               

parser stack overflow                                             486 days
       http://bugs.python.org/issue1572320 amaury.forgeotdarc       
                                                                               

Adding an index method to tuples                                  305 days
       http://bugs.python.org/issue1696444 rhettinger               
       patch                                                                   

Python 2.5+ skips while statements in debuggers                   211 days
       http://bugs.python.org/issue1750076 amaury.forgeotdarc       
                                                                               



Top Issues Most Discussed (10)
______________________________

 11 Move Demo/classes/Rat.py to Lib/rational.py and fix it up.        49 days
open    http://bugs.python.org/issue1682   

  9 asyncore loop lacks timers and work tasks                          5 days
open    http://bugs.python.org/issue2006   

  9 Thread shutdown exception in Thread.notify()                       3 days
open    http://bugs.python.org/issue1722344

  8 tarfile extractall() allows local attacker to overwrite files w    2 days
closed  http://bugs.python.org/issue2004   

  6 TextCalendar.formatmonth is not influenced by setfirstweekday      2 days
closed  http://bugs.python.org/issue2018   

  6 Make int() fall back to trunc()                                    1 days
closed  http://bugs.python.org/issue2002   

  5 _fmode = O_TEXT is obsolete                                        0 days
closed  http://bugs.python.org/issue2028   

  5 Add inspect.isgenerator                                           16 days
open    http://bugs.python.org/issue1916   

  4 Class instance attributes that are property() should appear in     1 days
closed  http://bugs.python.org/issue2040   

  4 Module containing C implementations of common text algorithms      2 days
open    http://bugs.python.org/issue2027   




From lists at cheimes.de  Fri Feb  8 19:28:57 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 08 Feb 2008 19:28:57 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47AC40E9.2060505@bullseye.andymac.org>
References: <47AB02F9.1010501@bullseye.andymac.org>
	<fofesd$2pd$1@ger.gmane.org>
	<47AC40E9.2060505@bullseye.andymac.org>
Message-ID: <47AC9F69.6020404@cheimes.de>

Andrew MacIntyre wrote:
> For the int case, that patch is slower than no free list at all.  For the
> float case its very slightly faster (55.3s vs 55.5s) than no free list at
> all.  Slower than the trunk code for both cases.  Did you run the test
> scripts on your own machine?

I've used a simple timeit call to bench mark the memory allocation. The
first statement saturates the free lists and the second one benchmarks
memory allocation and float creation.

./python -m timeit -n10 -s "[float(x) for x in list(range(1000))]" "for
i in range(100): [float(x) for x in list(range(1000))]"

I've done some experiments with a fixed length *free_list[] like dict
and listobject.c. A fixed length list is faster than a single linked
list. I'm going to upload the patch later.

> In addition to the pure performance aspect, there is the issue of memory
> utilisation.  The current trunk code running the int test case in my
> original post peaks at 151MB according to top on my FreeBSD box, dropping
> back to about 62MB after the dict is destroyed (without a compaction).
> The same script running on the no-freelist build of the interpreter peaks
> at 119MB, with a minima of around 57MB.

I wonder why the free list has such a huge impact in memory usage. Int
objects are small (4 byte pointer to type, 4 byte Py_ssize_t and 4 byte
value). A thousand int object should consume less than 20kB including
overhead and padding.

> On the 2 platforms I have, the current trunk code for ints would appear
> to be as good as it gets speed-wise.  If the memory utilisation issue
> were to be considered significant, dropping the int freelist would have
> its attractions...
> 
> As far as floats go, all the indications I have suggest that the current
> freelist code has a performance problem.  Ditching the freelist and
> reverting to inlined PyObject_New()/PyObject_Del() semantics would be an
> attractive course as it appears to perform to within a whisker of the
> best alternatives while simplifying the object's code and taking
> advantage of pymalloc, however there are a number of other
> platforms/compilers that need testing before it would be prudent to do
> so.

I can test the code on Linux and Windows XP. My tests have shown that a
linked free list doesn't give a considerable performance boost - even
for code that allocates and frees a lot of ints and floats at once. But
a fixed length pointer array gives a measurable performance gain.

> The compaction routine you added to trunk gets the job done as far as
> freelist pruning goes, but I can't say I find it anything other than an
> ugly solution (though there is precedent for the concept via the gc
> module).

Yeah, I won't argue with that. The compaction function is a crutch.

Christian


From lists at cheimes.de  Fri Feb  8 19:54:41 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 08 Feb 2008 19:54:41 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47AC42D2.1010701@bullseye.andymac.org>
References: <47AB02F9.1010501@bullseye.andymac.org> <47ABA0FD.60306@egenix.com>
	<47AC42D2.1010701@bullseye.andymac.org>
Message-ID: <foi8hl$v0m$1@ger.gmane.org>

Andrew MacIntyre wrote:
> However, my tests do show that something is funny with the current
> freelist implementation for floats on at least 2 platforms, and that
> doing without that sort of optimisation for float objects would likely
> not be a hardship with PyMalloc.

float objects are slightly larger than int objects. On a 32bit OS both
have ob_type pointer of size 4, a ref counter of size 4. But an int
object has a value of type long with 4 bytes and a float stores its
value in a double with size 8.

I assume that the difference in size leads to a different allocation timing.

Christian




From nnorwitz at gmail.com  Fri Feb  8 20:01:40 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Fri, 8 Feb 2008 11:01:40 -0800
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <foi8hl$v0m$1@ger.gmane.org>
References: <47AB02F9.1010501@bullseye.andymac.org> <47ABA0FD.60306@egenix.com>
	<47AC42D2.1010701@bullseye.andymac.org> <foi8hl$v0m$1@ger.gmane.org>
Message-ID: <ee2a432c0802081101tdcef6bfjd90af945f2a406ff@mail.gmail.com>

On Feb 8, 2008 10:54 AM, Christian Heimes <lists at cheimes.de> wrote:
> Andrew MacIntyre wrote:
> > However, my tests do show that something is funny with the current
> > freelist implementation for floats on at least 2 platforms, and that
> > doing without that sort of optimisation for float objects would likely
> > not be a hardship with PyMalloc.
>
> float objects are slightly larger than int objects. On a 32bit OS both
> have ob_type pointer of size 4, a ref counter of size 4. But an int
> object has a value of type long with 4 bytes and a float stores its
> value in a double with size 8.
>
> I assume that the difference in size leads to a different allocation timing.

It's not just size.  Architectures may require data aligned on 4, 8,
or 16 addresses for optimal performance depending on data type.  IIRC,
malloc aligns by 8 (not sure if that was a particular arch or very
common).  I don't know if pymalloc handles alignment.

n

From tim.peters at gmail.com  Fri Feb  8 20:22:28 2008
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 8 Feb 2008 14:22:28 -0500
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <ee2a432c0802081101tdcef6bfjd90af945f2a406ff@mail.gmail.com>
References: <47AB02F9.1010501@bullseye.andymac.org> <47ABA0FD.60306@egenix.com>
	<47AC42D2.1010701@bullseye.andymac.org> <foi8hl$v0m$1@ger.gmane.org>
	<ee2a432c0802081101tdcef6bfjd90af945f2a406ff@mail.gmail.com>
Message-ID: <1f7befae0802081122w5a358f4dlb5fca830b913e9b8@mail.gmail.com>

[Neal Norwitz]
> It's not just size.  Architectures may require data aligned on 4, 8,
> or 16 addresses for optimal performance depending on data type.  IIRC,
> malloc aligns by 8 (not sure if that was a particular arch or very
> common).

Just very common.  Because malloc has no idea what the pointer it
returns will be used for, it needs to satisfy the strictest alignment
requirement for any type exposed by the C language.  As an extreme
example, when I worked at Kendall Square Research, our hardware
supported atomic locking on a "subpage" basis, and HW subpage
addresses were all those divisible by 128  Subpages were exposed via C
extensions, so the KSR malloc had to return 128-byte aligned pointers.

> I don't know if pymalloc handles alignment.

pymalloc ensures 8-byte alignment.  This is one plausible reason to
keep the current int free list:  an int object struct holds 3 4-byte
members on most boxes (type pointer, refcount, and the int's value),
and the int freelist code uses exactly 12 bytes for each on most
boxes.  To keep 8-byte alignment, pymalloc would have to hand out a
16-byte chunk per int object, wasting a fourth of the space (pymalloc
always rounds up a requested size to a multiple of 8, and ensures the
address returned is 8-byte aligned).

From lists at cheimes.de  Fri Feb  8 20:33:06 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 08 Feb 2008 20:33:06 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <ee2a432c0802081101tdcef6bfjd90af945f2a406ff@mail.gmail.com>
References: <47AB02F9.1010501@bullseye.andymac.org>
	<47ABA0FD.60306@egenix.com>	
	<47AC42D2.1010701@bullseye.andymac.org>
	<foi8hl$v0m$1@ger.gmane.org>
	<ee2a432c0802081101tdcef6bfjd90af945f2a406ff@mail.gmail.com>
Message-ID: <47ACAE72.5010303@cheimes.de>

Neal Norwitz wrote:
> It's not just size.  Architectures may require data aligned on 4, 8,
> or 16 addresses for optimal performance depending on data type.  IIRC,
> malloc aligns by 8 (not sure if that was a particular arch or very
> common).  I don't know if pymalloc handles alignment.

Yes, pymalloc takes care of alignment. From Object/obmalloc.c:

Small requests are grouped in size classes spaced 8 bytes apart, due to
the required valid alignment of the returned address.


From lists at cheimes.de  Fri Feb  8 20:43:02 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 08 Feb 2008 20:43:02 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <1f7befae0802081122w5a358f4dlb5fca830b913e9b8@mail.gmail.com>
References: <47AB02F9.1010501@bullseye.andymac.org>
	<47ABA0FD.60306@egenix.com>	<47AC42D2.1010701@bullseye.andymac.org>
	<foi8hl$v0m$1@ger.gmane.org>	<ee2a432c0802081101tdcef6bfjd90af945f2a406ff@mail.gmail.com>
	<1f7befae0802081122w5a358f4dlb5fca830b913e9b8@mail.gmail.com>
Message-ID: <47ACB0C6.2060302@cheimes.de>

Tim Peters wrote:
> pymalloc ensures 8-byte alignment.  This is one plausible reason to
> keep the current int free list:  an int object struct holds 3 4-byte
> members on most boxes (type pointer, refcount, and the int's value),
> and the int freelist code uses exactly 12 bytes for each on most
> boxes.  To keep 8-byte alignment, pymalloc would have to hand out a
> 16-byte chunk per int object, wasting a fourth of the space (pymalloc
> always rounds up a requested size to a multiple of 8, and ensures the
> address returned is 8-byte aligned).

Given the background information Python's long implementation could
probably optimized. In 3.0 a long has 3 4-byte members (ref count,
ob_size and *ob_type) plus one to many unsigned shorts (2 bytes each) to
hold the value. If pymalloc aligns the objects at 8 byte address
boundaries wouldn't it be better and slightly faster to use unsigned
ints instead of unsigned shorts?

Christian

From brett at python.org  Fri Feb  8 21:34:17 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 8 Feb 2008 12:34:17 -0800
Subject: [Python-Dev] Initial attempt to PyCon sprint tutorial slides
	are up
In-Reply-To: <e04bdf310802060446t77df5d7ay59b60c33db55c2c9@mail.gmail.com>
References: <bbaeab100802041329w215527e3o592adff4258bc571@mail.gmail.com>
	<e04bdf310802060446t77df5d7ay59b60c33db55c2c9@mail.gmail.com>
Message-ID: <bbaeab100802081234j5c4e6dcdt3186e5d621271d7c@mail.gmail.com>

On Feb 6, 2008 4:46 AM, Facundo Batista <facundobatista at gmail.com> wrote:
> 2008/2/4, Brett Cannon <brett at python.org>:
>
> > The 1 MB PDF can be found at
> > http://www.cs.ubc.ca/~drifty/pycon/sprint_tutorial.pdf . If you find
> > any bad info or some info that is really lacking, let me know. But
>
> Brett, please tell me when you have a kind of finished version of
> this... I want to send it to the Python Argentina mail list.
>
> Thank you!

The corrected version of the slides are now up at the same location.

-Brett

From lists at cheimes.de  Fri Feb  8 21:53:38 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 08 Feb 2008 21:53:38 +0100
Subject: [Python-Dev] Initial attempt to PyCon sprint tutorial slides
	are up
In-Reply-To: <bbaeab100802081234j5c4e6dcdt3186e5d621271d7c@mail.gmail.com>
References: <bbaeab100802041329w215527e3o592adff4258bc571@mail.gmail.com>	<e04bdf310802060446t77df5d7ay59b60c33db55c2c9@mail.gmail.com>
	<bbaeab100802081234j5c4e6dcdt3186e5d621271d7c@mail.gmail.com>
Message-ID: <47ACC152.5060108@cheimes.de>

Brett Cannon wrote:
> The corrected version of the slides are now up at the same location.

I found a minor mistake

PC/
 * Build files for compilers older than VS 7.1.

The PC directory contains build directories for VC6.0, VC 7.1, VC8.0 and
OS2.

Christian

From brett at python.org  Fri Feb  8 22:03:37 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 8 Feb 2008 13:03:37 -0800
Subject: [Python-Dev] Initial attempt to PyCon sprint tutorial slides
	are up
In-Reply-To: <47ACC152.5060108@cheimes.de>
References: <bbaeab100802041329w215527e3o592adff4258bc571@mail.gmail.com>
	<e04bdf310802060446t77df5d7ay59b60c33db55c2c9@mail.gmail.com>
	<bbaeab100802081234j5c4e6dcdt3186e5d621271d7c@mail.gmail.com>
	<47ACC152.5060108@cheimes.de>
Message-ID: <bbaeab100802081303vb370b96i97e46dc82362cae0@mail.gmail.com>

On Feb 8, 2008 12:53 PM, Christian Heimes <lists at cheimes.de> wrote:
> Brett Cannon wrote:
> > The corrected version of the slides are now up at the same location.
>
> I found a minor mistake
>
> PC/
>  * Build files for compilers older than VS 7.1.
>
> The PC directory contains build directories for VC6.0, VC 7.1, VC8.0 and
> OS2.

Then a README file either in that directory or PCbuild might need
updating. But then again Python's own README could use a refresh. =)

-Brett

From mal at egenix.com  Fri Feb  8 23:34:17 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 08 Feb 2008 23:34:17 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47AC3BC2.9010809@egenix.com>
References: <47AB02F9.1010501@bullseye.andymac.org>	<47ABA0FD.60306@egenix.com>
	<47AC02E1.4020300@v.loewis.de> <47AC3BC2.9010809@egenix.com>
Message-ID: <47ACD8E9.8090200@egenix.com>

On 2008-02-08 12:23, M.-A. Lemburg wrote:
> On 2008-02-08 08:21, Martin v. L?wis wrote:
>>> One of the hopes of having a custom allocator for Python was to be
>>> able to get rid off all free lists. For some reason that never happened.
>>> Not sure why. People were probably too busy with adding new
>>> features to the language at the time ;-)
>> Probably not. It's more that the free lists still outperformed pymalloc.
>>
>>> Something you could try to make PyMalloc perform better for the builtin
>>> types is to check the actual size of the allocated PyObjects and then
>>> make sure that PyMalloc uses arenas large enough to hold a good quantity
>>> of them, e.g. it's possible that the float types fall into the same
>>> arena as some other type and thus don't have enough "room" to use
>>> as free list.
>> I don't think any improvements can be gained here. PyMalloc carves
>> out pools of 4096 bytes from an arena when it runs out of blocks
>> for a certain size class, and then keeps a linked list of pools of
>> the same size class. So when many float objects get allocated,
>> you'll have a lot of pools of the float type's size class.
>> IOW, PyMalloc has always enough room.
> 
> Well, yes, it doesn't run out of memory, but if pymalloc needs
> to allocate lots of objects of the same size, then performance
> degrades due to the management overhead involved for checking
> the free pools as well as creating new arenas as needed.
> 
> To reduce this overhead, it may be a good idea to preallocate
> pools for common sizes and make sure they don't drop under a
> certain threshold.
> 
> Here's a list of a few object sizes in bytes for Python 2.5
> on an AMD64 machine:
> 
>>>> import mx.Tools
>>>> mx.Tools.sizeof(int(0))
> 24
>>>> mx.Tools.sizeof(float(0))
> 24
> 
> 8-bit strings are var objects:
> 
>>>> mx.Tools.sizeof(str(''))
> 40
>>>> mx.Tools.sizeof(str('a'))
> 41
> 
> Unicode objects use an external buffer:
> 
>>>> mx.Tools.sizeof(unicode(''))
> 48
>>>> mx.Tools.sizeof(unicode('a'))
> 48
> 
> Lists do as well:
> 
>>>> mx.Tools.sizeof(list())
> 40
>>>> mx.Tools.sizeof(list([1,2,3]))
> 40
> 
> Tuples are var objects:
> 
>>>> mx.Tools.sizeof(tuple())
> 24
>>>> mx.Tools.sizeof(tuple([1,2,3]))
> 48
> 
> Old style classes:
> 
>>>> class C: pass
> ...
>>>> mx.Tools.sizeof(C)
> 64
> 
> New style classes are a lot heavier:
> 
>>>> class D(object): pass
> ...
>>>> mx.Tools.sizeof(D)
> 848
>>>> mx.Tools.sizeof(type(2))
> 848
> 
> 
> As you can see, Integers and floats fall into the same pymalloc size
> class. What's strange in Andrew's result is that both integers
> and floats use the same free list technique and fall into the same
> pymalloc size class, yet the results are different.
> 
> The only difference that's apparent is that small integers are
> shared, so depending on the data set used for the test, fewer
> calls to pymalloc or the free list are made.

Here's the same on a 32-bit machine. Notice the differences:

>>> import mx.Tools
>>> mx.Tools.sizeof(int(0))
12
>>> mx.Tools.sizeof(float(0))
16
>>> mx.Tools.sizeof(str(''))
24
>>> mx.Tools.sizeof(str('a'))
25
>>> mx.Tools.sizeof(unicode(''))
24
>>> mx.Tools.sizeof(unicode('a'))
24
>>> mx.Tools.sizeof(list())
20
>>> mx.Tools.sizeof(list([1,2,3]))
20
>>> mx.Tools.sizeof(tuple())
12
>>> mx.Tools.sizeof(tuple([1,2,3]))
24
>>> class C: pass
>>> mx.Tools.sizeof(C)
32
>>> class D(object): pass
>>> mx.Tools.sizeof(D)
424
>>> mx.Tools.sizeof(type(2))
424

Floats use 4 bytes more than integers. However, they still fall
into the same pymalloc size class (16 bytes this time around).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 08 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  Fri Feb  8 23:40:46 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 08 Feb 2008 23:40:46 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47AC9F69.6020404@cheimes.de>
References: <47AB02F9.1010501@bullseye.andymac.org>	<fofesd$2pd$1@ger.gmane.org>	<47AC40E9.2060505@bullseye.andymac.org>
	<47AC9F69.6020404@cheimes.de>
Message-ID: <47ACDA6E.6010205@egenix.com>

On 2008-02-08 19:28, Christian Heimes wrote:
>> In addition to the pure performance aspect, there is the issue of memory
>> utilisation.  The current trunk code running the int test case in my
>> original post peaks at 151MB according to top on my FreeBSD box, dropping
>> back to about 62MB after the dict is destroyed (without a compaction).
>> The same script running on the no-freelist build of the interpreter peaks
>> at 119MB, with a minima of around 57MB.
> 
> I wonder why the free list has such a huge impact in memory usage. Int
> objects are small (4 byte pointer to type, 4 byte Py_ssize_t and 4 byte
> value). A thousand int object should consume less than 20kB including
> overhead and padding.

The free lists keep parts of the pymalloc pools alive.
Since these are only returned to the OS if the whole pool is
unused, a single object could keep 4k of memory associated
with the process.

I suppose that the remaining few MBs shown by the OS are not
really used by the process, but simply kept associated with
the process by the OS in case it quickly needs more memory.

In order to be sure about the true memory usage, you'd have
to force the OS to grab all available memory, e.g. by running
a huge process right next to the one you're testing.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 08 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 andymac at bullseye.apana.org.au  Fri Feb  8 23:56:24 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Sat, 09 Feb 2008 08:56:24 +1000
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <1f7befae0802081122w5a358f4dlb5fca830b913e9b8@mail.gmail.com>
References: <47AB02F9.1010501@bullseye.andymac.org>
	<47ABA0FD.60306@egenix.com>	<47AC42D2.1010701@bullseye.andymac.org>
	<foi8hl$v0m$1@ger.gmane.org>	<ee2a432c0802081101tdcef6bfjd90af945f2a406ff@mail.gmail.com>
	<1f7befae0802081122w5a358f4dlb5fca830b913e9b8@mail.gmail.com>
Message-ID: <47ACDE18.3070600@bullseye.andymac.org>

Tim Peters wrote:

> pymalloc ensures 8-byte alignment.  This is one plausible reason to
> keep the current int free list:  an int object struct holds 3 4-byte
> members on most boxes (type pointer, refcount, and the int's value),
> and the int freelist code uses exactly 12 bytes for each on most
> boxes.  To keep 8-byte alignment, pymalloc would have to hand out a
> 16-byte chunk per int object, wasting a fourth of the space (pymalloc
> always rounds up a requested size to a multiple of 8, and ensures the
> address returned is 8-byte aligned).

Hmmm... the funny thing is that the freelist approach is showing higher
memory consumption than the PyMalloc approach for the int case...

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

From andymac at bullseye.apana.org.au  Sat Feb  9 00:02:38 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Sat, 09 Feb 2008 09:02:38 +1000
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47AC3BC2.9010809@egenix.com>
References: <47AB02F9.1010501@bullseye.andymac.org>	<47ABA0FD.60306@egenix.com>
	<47AC02E1.4020300@v.loewis.de> <47AC3BC2.9010809@egenix.com>
Message-ID: <47ACDF8E.2020206@bullseye.andymac.org>

M.-A. Lemburg wrote:

> As you can see, Integers and floats fall into the same pymalloc size
> class. What's strange in Andrew's result is that both integers
> and floats use the same free list technique and fall into the same
> pymalloc size class, yet the results are different.

My take is not that PyMalloc is so much better in the float case, but
that the float freelist implementation is suboptimal (though exactly
why is subject for conjecture, given it's almost identical to the int
implementation).

> The only difference that's apparent is that small integers are
> shared, so depending on the data set used for the test, fewer
> calls to pymalloc or the free list are made.

My testing was done with millions of unique integers, so the small int
handling should be deep in the measurement noise.

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

From martin at v.loewis.de  Sat Feb  9 00:16:06 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 09 Feb 2008 00:16:06 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47ACB0C6.2060302@cheimes.de>
References: <47AB02F9.1010501@bullseye.andymac.org>	<47ABA0FD.60306@egenix.com>	<47AC42D2.1010701@bullseye.andymac.org>	<foi8hl$v0m$1@ger.gmane.org>	<ee2a432c0802081101tdcef6bfjd90af945f2a406ff@mail.gmail.com>	<1f7befae0802081122w5a358f4dlb5fca830b913e9b8@mail.gmail.com>
	<47ACB0C6.2060302@cheimes.de>
Message-ID: <47ACE2B6.9000903@v.loewis.de>

> Given the background information Python's long implementation could
> probably optimized. In 3.0 a long has 3 4-byte members (ref count,
> ob_size and *ob_type) plus one to many unsigned shorts (2 bytes each) to
> hold the value. If pymalloc aligns the objects at 8 byte address
> boundaries wouldn't it be better and slightly faster to use unsigned
> ints instead of unsigned shorts?

You mean, as the digits? You would have to rewrite the entire long
datatype, which is a tedious exercise. Plus, I believe you would have
to make some operations 64-bit on all systems: when you multiply
digits today, the product will be 32-bit. If you extend the digits,
you might get 64-bit results, which will be slow on 32-bit systems
(plus some 32-bit systems don't support a 64-bit integer type at all
in their compilers).

Regards,
Martin

From lists at cheimes.de  Sat Feb  9 00:22:51 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 09 Feb 2008 00:22:51 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47ACE2B6.9000903@v.loewis.de>
References: <47AB02F9.1010501@bullseye.andymac.org>	<47ABA0FD.60306@egenix.com>	<47AC42D2.1010701@bullseye.andymac.org>	<foi8hl$v0m$1@ger.gmane.org>	<ee2a432c0802081101tdcef6bfjd90af945f2a406ff@mail.gmail.com>	<1f7befae0802081122w5a358f4dlb5fca830b913e9b8@mail.gmail.com>	<47ACB0C6.2060302@cheimes.de>
	<47ACE2B6.9000903@v.loewis.de>
Message-ID: <47ACE44B.30107@cheimes.de>

Martin v. L?wis wrote:
> You mean, as the digits? You would have to rewrite the entire long
> datatype, which is a tedious exercise. Plus, I believe you would have
> to make some operations 64-bit on all systems: when you multiply
> digits today, the product will be 32-bit. If you extend the digits,
> you might get 64-bit results, which will be slow on 32-bit systems
> (plus some 32-bit systems don't support a 64-bit integer type at all
> in their compilers).

I pass! :)

It may be worth a try for Python 4.0 when most OS are 64bit.

Christian

From andymac at bullseye.apana.org.au  Sat Feb  9 00:30:48 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Sat, 09 Feb 2008 09:30:48 +1000
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47AC9F69.6020404@cheimes.de>
References: <47AB02F9.1010501@bullseye.andymac.org>	<fofesd$2pd$1@ger.gmane.org>	<47AC40E9.2060505@bullseye.andymac.org>
	<47AC9F69.6020404@cheimes.de>
Message-ID: <47ACE628.60607@bullseye.andymac.org>

Christian Heimes wrote:
> Andrew MacIntyre wrote:
>> For the int case, that patch is slower than no free list at all.  For the
>> float case its very slightly faster (55.3s vs 55.5s) than no free list at
>> all.  Slower than the trunk code for both cases.  Did you run the test
>> scripts on your own machine?
> 
> I've used a simple timeit call to bench mark the memory allocation. The
> first statement saturates the free lists and the second one benchmarks
> memory allocation and float creation.
> 
> ./python -m timeit -n10 -s "[float(x) for x in list(range(1000))]" "for
> i in range(100): [float(x) for x in list(range(1000))]"

Try testing with 1000000 rather than 1000.  My testing was deliberately
looking at the handling of large numbers of ints/floats, because small
numbers (eg 1000) are not enough to make wasted memory recovery
worthwhile.

> I've done some experiments with a fixed length *free_list[] like dict
> and listobject.c. A fixed length list is faster than a single linked
> list. I'm going to upload the patch later.

I tried a LIFO stack implementation (though I won't claim to have done it
well), and found it slightly slower than no freelist at all. The
advantage of such an approach is that the known size of the stack makes
deallocating excess objects easy (and thus no need for
sys.compact_free_list() ).

I have been guilty of not paying attention to the performance of the
small cases.

>> In addition to the pure performance aspect, there is the issue of memory
>> utilisation.  The current trunk code running the int test case in my
>> original post peaks at 151MB according to top on my FreeBSD box, dropping
>> back to about 62MB after the dict is destroyed (without a compaction).
>> The same script running on the no-freelist build of the interpreter peaks
>> at 119MB, with a minima of around 57MB.
> 
> I wonder why the free list has such a huge impact in memory usage. Int
> objects are small (4 byte pointer to type, 4 byte Py_ssize_t and 4 byte
> value). A thousand int object should consume less than 20kB including
> overhead and padding.

My test script allocates 4000000 ints - ~48MB.  Much of the memory 
"pulse" is the creation/deletion of a dict with 2000000 items (25MB?).

Its interesting to watch the freelist case, as first time through the
loop the process size peaks at 109MB, then at the end of the 2nd pass it
peaks at 151MB which is maintained on subsequent passes through the loop.
(BTW, on this machine just starting the python interpreter leaves the
process size at a bit over 3MB).

The no-freelist build peaks at its maximum of 119MB on the first pass
through the loop.

>> On the 2 platforms I have, the current trunk code for ints would appear
>> to be as good as it gets speed-wise.  If the memory utilisation issue
>> were to be considered significant, dropping the int freelist would have
>> its attractions...
>>
>> As far as floats go, all the indications I have suggest that the current
>> freelist code has a performance problem.  Ditching the freelist and
>> reverting to inlined PyObject_New()/PyObject_Del() semantics would be an
>> attractive course as it appears to perform to within a whisker of the
>> best alternatives while simplifying the object's code and taking
>> advantage of pymalloc, however there are a number of other
>> platforms/compilers that need testing before it would be prudent to do
>> so.
> 
> I can test the code on Linux and Windows XP. My tests have shown that a
> linked free list doesn't give a considerable performance boost - even
> for code that allocates and frees a lot of ints and floats at once. But
> a fixed length pointer array gives a measurable performance gain.

I've added my research patches to issue 2039, so I'd be interested to 
know how they rate in comparison.  In addition to the small case testing
mentioned above, I would suggest you do some large case testing (such as
with the scripts I included in my original posting) as this is the 
justification for the effort on wasted memory recovery.

Cheers,
Andrew.

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

From gnewsg at gmail.com  Sat Feb  9 16:14:15 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Sat, 9 Feb 2008 07:14:15 -0800 (PST)
Subject: [Python-Dev] Initial attempt to PyCon sprint tutorial slides
	are up
In-Reply-To: <bbaeab100802041329w215527e3o592adff4258bc571@mail.gmail.com>
References: <bbaeab100802041329w215527e3o592adff4258bc571@mail.gmail.com>
Message-ID: <0aac088c-6a5f-4cf5-bd8a-5d6f7365ff5b@z17g2000hsg.googlegroups.com>

On 4 Feb, 22:29, "Brett Cannon" <br... at python.org> wrote:
> The 1 MB PDF can be found athttp://www.cs.ubc.ca/~drifty/pycon/sprint_tutorial.pdf. If you find
> any bad info or some info that is really lacking, let me know. But
> please realize that my slides are never really meant to be read on
> their own as it just goes against my presentation style. So don't
> think that some slide doesn't go into enough detail unless there is
> some URL I am missing. Every slide will be discussed more during the
> presentation than what is on the slide.
>
> -Brett

- Page 61 (Fix flaky tests). Add:
test_al
test_cd
test_cl
test_crypt
test_ftplib

...Some of them are inobtrusive tests testing for the existence of the
module's attributes.

From martin at v.loewis.de  Sat Feb  9 16:51:25 2008
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 09 Feb 2008 16:51:25 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47AC3BC2.9010809@egenix.com>
References: <47AB02F9.1010501@bullseye.andymac.org>
	<47ABA0FD.60306@egenix.com> <47AC02E1.4020300@v.loewis.de>
	<47AC3BC2.9010809@egenix.com>
Message-ID: <47ADCBFD.9040005@v.loewis.de>

> Well, yes, it doesn't run out of memory, but if pymalloc needs
> to allocate lots of objects of the same size, then performance
> degrades due to the management overhead involved for checking
> the free pools as well as creating new arenas as needed.
> 
> To reduce this overhead, it may be a good idea to preallocate
> pools for common sizes and make sure they don't drop under a
> certain threshold.

I still can't see why this could speed up anything. The total
time will be the same - whether you allocate them in advance
or on demand should make no difference.

In any case, if you think that you can improve things, please
submit a patch.

Regards,
Martin

From arigo at tunes.org  Sat Feb  9 18:04:58 2008
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 9 Feb 2008 18:04:58 +0100
Subject: [Python-Dev] trunc()
In-Reply-To: <20080124133614.AFQ48572@ms19.lnh.mail.rcn.net>
References: <20080124133614.AFQ48572@ms19.lnh.mail.rcn.net>
Message-ID: <20080209170458.GA31567@code0.codespeak.net>

Hi Raymond,

On Thu, Jan 24, 2008 at 01:36:14PM -0500, Raymond Hettinger wrote:
> Also, it seems that ABC is starting to evolve from an optional
> tool into something embedded in the language in a way that you
> can't escape it.  
>
> I would prefer that it not be on the list of concepts that a
> beginner *must* know in order to be functional in the language.

I can't resist to mention some private discussions I've had at the time,
with people that could see this coming.

Maybe this might be used as an argument against adding optional type
annotations...?  Ok, I'm not optimistic about it.  Sorry, I don't mean
to start yet another endless thread, and will shut up again after this
note.  I'm no longer a regular python-dev contributor anyway; the fact
is that I quite like the language as it is, and I'm a bit concerned
about its evolution - in my humble opinion it seems to become each
release a bit less accessible to beginners.


A bientot,

Armin

From brett at python.org  Sun Feb 10 02:37:29 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 9 Feb 2008 17:37:29 -0800
Subject: [Python-Dev] Initial attempt to PyCon sprint tutorial slides
	are up
In-Reply-To: <0aac088c-6a5f-4cf5-bd8a-5d6f7365ff5b@z17g2000hsg.googlegroups.com>
References: <bbaeab100802041329w215527e3o592adff4258bc571@mail.gmail.com>
	<0aac088c-6a5f-4cf5-bd8a-5d6f7365ff5b@z17g2000hsg.googlegroups.com>
Message-ID: <bbaeab100802091737m26c432d6n2948681f573d5cb9@mail.gmail.com>

On Feb 9, 2008 7:14 AM, Giampaolo Rodola' <gnewsg at gmail.com> wrote:
> On 4 Feb, 22:29, "Brett Cannon" <br... at python.org> wrote:
> > The 1 MB PDF can be found athttp://www.cs.ubc.ca/~drifty/pycon/sprint_tutorial.pdf. If you find
>
> > any bad info or some info that is really lacking, let me know. But
> > please realize that my slides are never really meant to be read on
> > their own as it just goes against my presentation style. So don't
> > think that some slide doesn't go into enough detail unless there is
> > some URL I am missing. Every slide will be discussed more during the
> > presentation than what is on the slide.
> >
> > -Brett
>
> - Page 61 (Fix flaky tests). Add:
> test_al
> test_cd
> test_cl
> test_crypt
> test_ftplib

The tests listed as flaky have a tendency to fail on the buildbots
because some resource is lacking. I have not seen any of these tests
fail like that.

-Brett

From ncoghlan at gmail.com  Sun Feb 10 04:28:43 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 10 Feb 2008 13:28:43 +1000
Subject: [Python-Dev] Error from SVN commit
Message-ID: <47AE6F6B.3040500@gmail.com>

I'm getting an error from SVN when trying to commit a NEWS entry for r60695:

--------------
Sending        Misc/NEWS
Transmitting file data .svn: Commit failed (details follow):
svn: Can't create directory 
'/data/repos/projects/db/transactions/60708-1.txn': No space left on device
--------------

I've tried it a few times over the last 5-10 minutes and got the same 
error each time.

I checked r60695 in last night from that same checkout, so I wouldn't 
expect it to be a local problem. Could the repository drive on 
svn.python.org just be full? Or is something else going on?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From lists at cheimes.de  Sun Feb 10 04:55:24 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 10 Feb 2008 04:55:24 +0100
Subject: [Python-Dev] Error from SVN commit
In-Reply-To: <47AE6F6B.3040500@gmail.com>
References: <47AE6F6B.3040500@gmail.com>
Message-ID: <folsjc$hbg$1@ger.gmane.org>

Nick Coghlan wrote:
> I'm getting an error from SVN when trying to commit a NEWS entry for r60695:
> 
> --------------
> Sending        Misc/NEWS
> Transmitting file data .svn: Commit failed (details follow):
> svn: Can't create directory 
> '/data/repos/projects/db/transactions/60708-1.txn': No space left on device
> --------------

I tried myself. It's failing with the same error message. Somebody has
to call janitor; the hard disk needs some cleaning. ;)

Christian


From python at rcn.com  Sun Feb 10 05:27:31 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sat, 9 Feb 2008 20:27:31 -0800
Subject: [Python-Dev] Error from SVN commit
References: <47AE6F6B.3040500@gmail.com>
Message-ID: <005d01c86b9d$40cca4d0$6800a8c0@RaymondLaptop1>

[Nick]
> I'm getting an error from SVN when trying to commit a NEWS entry for r60695:
> 
> --------------
> Sending        Misc/NEWS
> Transmitting file data .svn: Commit failed (details follow):
> svn: Can't create directory 
> '/data/repos/projects/db/transactions/60708-1.txn': No space left on device
> --------------
> 
> I've tried it a few times over the last 5-10 minutes and got the same 
> error each time.

I got the same a few times last night.


Raymond

From martin at v.loewis.de  Sun Feb 10 08:18:04 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Feb 2008 08:18:04 +0100
Subject: [Python-Dev] Error from SVN commit
In-Reply-To: <47AE6F6B.3040500@gmail.com>
References: <47AE6F6B.3040500@gmail.com>
Message-ID: <47AEA52C.2040006@v.loewis.de>

> I checked r60695 in last night from that same checkout, so I wouldn't 
> expect it to be a local problem. Could the repository drive on 
> svn.python.org just be full? Or is something else going on?

The hard disk was full. I have deleted some files.

Regards,
Martin

From ncoghlan at gmail.com  Sun Feb 10 13:53:42 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 10 Feb 2008 22:53:42 +1000
Subject: [Python-Dev] Backporting tempfile.NamedTemporaryFile context
	management fix
Message-ID: <47AEF3D6.7070900@gmail.com>

In 2.5, tempfile.NamedTemporaryFile passes requests for __enter__ and 
__exit__ through to the underlying file object, which ends up breaking 
in a couple of different ways (by a fortuitous coincidence, it actually 
works in most respects on Windows, so tempfile.TemporaryFile will mostly 
do the right thing in with statements no matter what platform you are on).

This has been fixed on the trunk in response to issue 2021, but I'm not 
sure of the current status of the 2.5 maintenance branch. Should I wait 
until after 2.5.2 is released before backporting? Or backport it now?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From guido at python.org  Sun Feb 10 17:29:34 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 10 Feb 2008 08:29:34 -0800
Subject: [Python-Dev] Backporting tempfile.NamedTemporaryFile context
	management fix
In-Reply-To: <47AEF3D6.7070900@gmail.com>
References: <47AEF3D6.7070900@gmail.com>
Message-ID: <ca471dc20802100829yb25795ds3343462a035ad60c@mail.gmail.com>

Assuming the fix isn't going to break other things, I'd say now is the
time, unless Martin says otherwise. Waiting until after 2.5.2 doesn't
make a lot of sense -- either it is a backportable fix, or it isn't.
If it is backportable, it can go in as long as the 2.5.2 code freeze
isn't in effect.

On Feb 10, 2008 4:53 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> In 2.5, tempfile.NamedTemporaryFile passes requests for __enter__ and
> __exit__ through to the underlying file object, which ends up breaking
> in a couple of different ways (by a fortuitous coincidence, it actually
> works in most respects on Windows, so tempfile.TemporaryFile will mostly
> do the right thing in with statements no matter what platform you are on).
>
> This has been fixed on the trunk in response to issue 2021, but I'm not
> sure of the current status of the 2.5 maintenance branch. Should I wait
> until after 2.5.2 is released before backporting? Or backport it now?
>
> 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 martin at v.loewis.de  Sun Feb 10 19:52:06 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Feb 2008 19:52:06 +0100
Subject: [Python-Dev] Backporting tempfile.NamedTemporaryFile context
 management fix
In-Reply-To: <47AEF3D6.7070900@gmail.com>
References: <47AEF3D6.7070900@gmail.com>
Message-ID: <47AF47D6.7010200@v.loewis.de>

> This has been fixed on the trunk in response to issue 2021, but I'm not 
> sure of the current status of the 2.5 maintenance branch. Should I wait 
> until after 2.5.2 is released before backporting? Or backport it now?

Please backport it now. The code freeze for the 2.5 branch will come
Wednesday night; there will be release candidate first.

Regards,
Martin

From skip at pobox.com  Sun Feb 10 20:34:09 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 10 Feb 2008 13:34:09 -0600
Subject: [Python-Dev] Confused about test_bsddb failures on Mac OS X
Message-ID: <18351.20913.536072.226982@montanaro-dyndns-org.local>

I'm having trouble with test_bsddb on my new MacBook Pro (OS X 10.5.1).
Many tests give this error:

    Traceback (most recent call last):
      File "/Users/skip/src/python/trunk/Lib/test/test_bsddb.py", line 18, in setUp
        self.f = self.openmethod[0](self.fname, self.openflag, cachesize=32768)
      File "/Users/skip/src/python/trunk/Lib/bsddb/__init__.py", line 327, in btopen
        d.open(file, db.DB_BTREE, flags, mode)
    DBFileExistsError: (17, 'File exists -- __fop_file_setup:  Retry limit (100) exc
    eeded')

In TestBSDDB.setUp I added a print statement to the start:

    print os.path.abspath(self.fname), os.path.exists(self.fname)

It always prints:

    /Users/skip/src/python/trunk/build/@test False

I'm using the MacPorts version of Berkeley DB.  I've tried both 4.5 and 4.4:

    % otool -L build/lib.macosx-10.3-i386-2.6/_bsddb.so 
    build/lib.macosx-10.3-i386-2.6/_bsddb.so:
            /opt/local/lib/db44/libdb-4.4.dylib (compatibility version 0.0.0, current version 0.0.0)
            /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)

Any idea what the problem might be?


From guido at python.org  Sun Feb 10 21:22:38 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 10 Feb 2008 12:22:38 -0800
Subject: [Python-Dev] Confused about test_bsddb failures on Mac OS X
In-Reply-To: <18351.20913.536072.226982@montanaro-dyndns-org.local>
References: <18351.20913.536072.226982@montanaro-dyndns-org.local>
Message-ID: <ca471dc20802101222lc7f3279u7cac7a4efed96860@mail.gmail.com>

I recall seeing this too, though my memory is fuzzy. I believe there's
a temp file or directory left behind from a previous run that you need
to delete. Maybe the source around that error will give you a hint on
what its name is. I know I eventually got over is.

On Feb 10, 2008 11:34 AM,  <skip at pobox.com> wrote:
> I'm having trouble with test_bsddb on my new MacBook Pro (OS X 10.5.1).
> Many tests give this error:
>
>     Traceback (most recent call last):
>       File "/Users/skip/src/python/trunk/Lib/test/test_bsddb.py", line 18, in setUp
>         self.f = self.openmethod[0](self.fname, self.openflag, cachesize=32768)
>       File "/Users/skip/src/python/trunk/Lib/bsddb/__init__.py", line 327, in btopen
>         d.open(file, db.DB_BTREE, flags, mode)
>     DBFileExistsError: (17, 'File exists -- __fop_file_setup:  Retry limit (100) exc
>     eeded')
>
> In TestBSDDB.setUp I added a print statement to the start:
>
>     print os.path.abspath(self.fname), os.path.exists(self.fname)
>
> It always prints:
>
>     /Users/skip/src/python/trunk/build/@test False
>
> I'm using the MacPorts version of Berkeley DB.  I've tried both 4.5 and 4.4:
>
>     % otool -L build/lib.macosx-10.3-i386-2.6/_bsddb.so
>     build/lib.macosx-10.3-i386-2.6/_bsddb.so:
>             /opt/local/lib/db44/libdb-4.4.dylib (compatibility version 0.0.0, current version 0.0.0)
>             /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
>
> Any idea what the problem might be?
>
> _______________________________________________
> 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 skip at pobox.com  Sun Feb 10 21:38:00 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 10 Feb 2008 14:38:00 -0600
Subject: [Python-Dev] Confused about test_bsddb failures on Mac OS X
In-Reply-To: <ca471dc20802101222lc7f3279u7cac7a4efed96860@mail.gmail.com>
References: <18351.20913.536072.226982@montanaro-dyndns-org.local>
	<ca471dc20802101222lc7f3279u7cac7a4efed96860@mail.gmail.com>
Message-ID: <18351.24744.567487.334137@montanaro-dyndns-org.local>


    Guido> I recall seeing this too, though my memory is fuzzy. I believe
    Guido> there's a temp file or directory left behind from a previous run
    Guido> that you need to delete. 

Thanks.  I zapped my build directory then reran

    configure ;; make ;; make test

Seems to be working better now.

Skip

From amk at amk.ca  Sun Feb 10 22:49:48 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Sun, 10 Feb 2008 16:49:48 -0500
Subject: [Python-Dev] Python Bug Day on Feb. 23
Message-ID: <20080210214948.GA13439@amk.local>

After the success of January's bug day, which closed 37 issues, let's
have another one this month!  Here's the brief announcement:

Python Bug Day: Saturday, February 23 2008.  Meet in the #python-dev
IRC channel on irc.freenode.net and help improve Python.  For more
information, see http://wiki.python.org/moin/PythonBugDay .

--amk

From lists at cheimes.de  Mon Feb 11 02:48:38 2008
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 11 Feb 2008 02:48:38 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47ACE628.60607@bullseye.andymac.org>
References: <47AB02F9.1010501@bullseye.andymac.org>	<fofesd$2pd$1@ger.gmane.org>	<47AC40E9.2060505@bullseye.andymac.org>	<47AC9F69.6020404@cheimes.de>
	<47ACE628.60607@bullseye.andymac.org>
Message-ID: <foo9i1$sn6$2@ger.gmane.org>

Andrew MacIntyre wrote:
> I tried a LIFO stack implementation (though I won't claim to have done it
> well), and found it slightly slower than no freelist at all. The
> advantage of such an approach is that the known size of the stack makes
> deallocating excess objects easy (and thus no need for
> sys.compact_free_list() ).

I've tried a single linked free list myself. I used the ob_type field to
daisy chain the int and float objects. Although the code was fairly
short it was slightly slower than an attempt without a free list at all.
pymalloc is fast. It's very hard to beat it though.

A fixed size LIFO array like PyFloatObject
*free_list[PyFloat_MAXFREELIST] increased the speed slightly. IMHO a
value of about 80-200 floats and ints is realistic for most apps. More
objects in the free lists could keep too many pymalloced areas occupied.

Christian


From lists at cheimes.de  Mon Feb 11 02:38:09 2008
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 11 Feb 2008 02:38:09 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47AB02F9.1010501@bullseye.andymac.org>
References: <47AB02F9.1010501@bullseye.andymac.org>
Message-ID: <foo9i1$sn6$1@ger.gmane.org>

I've done my own profiling with a different script. I was able to verify
Andrews results. The pymalloc approach makes int creation slightly
slower and has almost no effect on floats.

The creation of 1000 times a list of 1000 ints (range(1000)) is about
20msec slower. It almost doubles the time for a trivial test "for i in
range(1000): range(1000)" but that's an artificial test.


Current allocation schema
-------------------------

for i in range(1000): [float(x) for x in range(1000)]
10 loops, best of 3: 760 msec per loop

for i in range(1000): range(1000)
10 loops, best of 3: 27 msec per loop

for i in range(1000): [x for x in range(1000)]"
10 loops, best of 3: 218 msec per loop


Without a free list
-------------------

for i in range(1000): [float(x) for x in range(1000)]
10 loops, best of 3: 792 msec per loop

for i in range(1000): range(1000)"
10 loops, best of 3: 51.5 msec per loop

for i in range(1000): [x for x in range(1000)]
10 loops, best of 3: 241 msec per loop


With a fixed free list of 2,500 objects each
--------------------------------------------

for i in range(1000): [float(x) for x in range(1000)]"
10 loops, best of 3: 736 msec per loop

for i in range(1000): range(1000)"
10 loops, best of 3: 25 msec per loop

for i in range(1000): [x for x in range(1000)]"
10 loops, best of 3: 198 msec per loop


As you can clearly see an approach with a small free list in a fixed
size array like static PyFloatObject *free_list[PyFloat_MAXFREELIST] is
even faster than block allocation. A small free list with 80 objects
each would speed up the creation of floats and ints a bit *and* result
in a quicker return of memory to the OS.

Christian


From jcea at argo.es  Mon Feb 11 03:45:11 2008
From: jcea at argo.es (Jesus Cea)
Date: Mon, 11 Feb 2008 03:45:11 +0100
Subject: [Python-Dev] Confused about test_bsddb failures on Mac OS X
In-Reply-To: <18351.24744.567487.334137@montanaro-dyndns-org.local>
References: <18351.20913.536072.226982@montanaro-dyndns-org.local>	<ca471dc20802101222lc7f3279u7cac7a4efed96860@mail.gmail.com>
	<18351.24744.567487.334137@montanaro-dyndns-org.local>
Message-ID: <47AFB6B7.6090808@argo.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

skip at pobox.com wrote:
|     Guido> I recall seeing this too, though my memory is fuzzy. I believe
|     Guido> there's a temp file or directory left behind from a
previous run
|     Guido> that you need to delete.
|
| Thanks.  I zapped my build directory then reran
|
|     configure ;; make ;; make test
|
| Seems to be working better now.

Feel free to post a bug in the tracker. I would look at it.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
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

iQCVAwUBR6+2sJlgi5GaxT1NAQLXfwQAjR43q2FYNta1g2CfkzKGWMMSXSA4Z/vv
/dlmkK0iDxLZ9MhVAYefDPEoCyOA408Sh4xzpXgRu9QjXCxBRqu4HFa4Oe3bfV2Y
mHlAmWaUtC+MhdL+tWYzQq63uR+llZVZwyqQNPve3ylZ/USfyy89defd7BFotnM5
r4V3FAcv/i4=
=FZs/
-----END PGP SIGNATURE-----

From oliphant.travis at ieee.org  Mon Feb 11 20:34:27 2008
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Mon, 11 Feb 2008 13:34:27 -0600
Subject: [Python-Dev] Error in PEP3118?
In-Reply-To: <fn832p$ebb$1@ger.gmane.org>
References: <47905DAE.9020802@ctypes.org> <fn7p9u$7rh$1@ger.gmane.org>
	<fn832p$ebb$1@ger.gmane.org>
Message-ID: <foq804$1iq$1@ger.gmane.org>

Thomas Heller wrote:
> Travis Oliphant schrieb:
> 
>>
>> The intent of the struct syntax is to handle describing memory.  The 
>> point is not to replicate how the C-compiler deals with statically 
>> defined N-D arrays.  Thus, even though the struct syntax allows 
>> *communicating* the intent of a contiguous block of memory inside a 
>> structure as an N-d array, the fundamental memory block is the 
>> equivalent of a 1-d array in C.
>>
>> So, I think the example is correct (and intentional).
> 
> Sorry, I do not think so.  If you use a 2-d array in the example, you
> must describe it correctly.  The difference between this pep and the old
> buffer interface is that the pep allows to describe both how the compiler
> sees the memory block plus the size and layout of the memory block, while
> the old buffer interface only describes single-segment memory blocks.
> And 'double data[16][4]' *is* a single memory block containing a 2-d array,
> and *not* an array of pointers.
> 

I don't understand what you mean by "must describe it correctly".   The 
size and layout of the memory block description of the PEP is not 
supposed to be dependent on the C-compiler.  It should also be able to 
define memory as used in Fortran, C#, a file, or whatever.  So, I don't 
understand the insistence that the example use C-specific 2-d array syntax.

The example as indicated is correct.  It is true that the 2-d nature of 
the block of data is only known by Python in this example.  You could 
argue that it would be more informative by showing the C-equivalent 
structure as a 2-d array.  However, it would also create the possibility 
of confusion by implying an absolute relationship between the C-compiler 
and the type description.

Your insistence that the example is incorrect makes me wonder what point 
is not being communicated between us.  Clearly there is overlap between 
C structure syntax and the PEP syntax, but the PEP type syntax allows 
for describing data in ways that the C compiler doesn't.

I'd rather steer people away from statically defined arrays in C and 
don't want to continually explain how they are subtly different.

My perception is that you are seeing too much of a connection between 
the C-compiler and the PEP description of memory.   Perhaps that's not 
it, and I'm missing something else.

Best regards,


-Travis O.


From dalcinl at gmail.com  Mon Feb 11 22:27:07 2008
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Mon, 11 Feb 2008 18:27:07 -0300
Subject: [Python-Dev] Error in PEP3118?
In-Reply-To: <foq804$1iq$1@ger.gmane.org>
References: <47905DAE.9020802@ctypes.org> <fn7p9u$7rh$1@ger.gmane.org>
	<fn832p$ebb$1@ger.gmane.org> <foq804$1iq$1@ger.gmane.org>
Message-ID: <e7ba66e40802111327g27ca28b2n8a6bef2e51dd02bc@mail.gmail.com>

On 2/11/08, Travis Oliphant <oliphant.travis at ieee.org> wrote:
> My perception is that you are seeing too much of a connection between
> the C-compiler and the PEP description of memory.   Perhaps that's not
> it, and I'm missing something else.
>

Travis, all this make me believe that (perhaps) the 'format'
specification in the new buffer interface is missing the 'C' or 'F'
ordering in the case of a countiguos block. I'm missing something? Or
should we always assume a 'C' ordering?


-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

From greg.ewing at canterbury.ac.nz  Tue Feb 12 00:06:39 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 12 Feb 2008 12:06:39 +1300
Subject: [Python-Dev] Error in PEP3118?
In-Reply-To: <foq804$1iq$1@ger.gmane.org>
References: <47905DAE.9020802@ctypes.org> <fn7p9u$7rh$1@ger.gmane.org>
	<fn832p$ebb$1@ger.gmane.org> <foq804$1iq$1@ger.gmane.org>
Message-ID: <47B0D4FF.9020604@canterbury.ac.nz>

Travis Oliphant wrote:
> You could 
> argue that it would be more informative by showing the C-equivalent 
> structure as a 2-d array.  However, it would also create the possibility 
> of confusion by implying an absolute relationship between the C-compiler 
> and the type description.

Just to check on something here -- does the C standard
guarantee that

    int a[16][4];

and

    int b[64];

have the same memory layout, or is it allowed to insert
padding at the ends of the rows or something?

If they are guaranteed to have the same layout, then I'd
agree that the example is correct, but perhaps somewhat
confusing.

It might help to add a note to the effect that this
example is meant to illustrate that the descriptor doesn't
have to exactly match the C description, as long as it
describes the same memory layout.

--
Greg

From greg.ewing at canterbury.ac.nz  Tue Feb 12 00:42:17 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 12 Feb 2008 12:42:17 +1300
Subject: [Python-Dev] Error in PEP3118?
In-Reply-To: <e7ba66e40802111327g27ca28b2n8a6bef2e51dd02bc@mail.gmail.com>
References: <47905DAE.9020802@ctypes.org> <fn7p9u$7rh$1@ger.gmane.org>
	<fn832p$ebb$1@ger.gmane.org> <foq804$1iq$1@ger.gmane.org>
	<e7ba66e40802111327g27ca28b2n8a6bef2e51dd02bc@mail.gmail.com>
Message-ID: <47B0DD59.1020001@canterbury.ac.nz>

Lisandro Dalcin wrote:
> Travis, all this make me believe that (perhaps) the 'format'
> specification in the new buffer interface is missing the 'C' or 'F'
> ordering in the case of a countiguos block.

Not strictly necessary, since you can always reverse the
indices when dealing with Fortran if need be.

You would have to do that anyway when accessing the array
from C, so it's probably better to have the description
always match the C ordering.

(Makes things a bit harder for those people writing their
Python extensions in Fortran, of course. :-)

--
Greg

From doug.napoleone at gmail.com  Sat Feb  9 07:48:57 2008
From: doug.napoleone at gmail.com (Douglas Napoleone)
Date: Sat, 9 Feb 2008 01:48:57 -0500
Subject: [Python-Dev] svn repo out of disk?
Message-ID: <f08f4fbb0802082248v71def7dewebbb0bec89485317@mail.gmail.com>

Not sure if this is effecting the core svn repository or not, but the
conference software (also hosted at svn.python.org) is reporting that
the disk is full:

Transmitting file data ....svn: Commit failed (details follow):
svn: Can't create directory '/data/repos/conference/db/transactions/557-1.txn':
No space left on device

I have not seen anything on the list about this, but then again, there
was room at 7pm EST, so I might be the first to notice it.

I fear this could be effecting more than just the pycon software, and
figured people would want to be forewarned.

(Also if someone could fix the problem somehow I would be ever grateful. ;-)

    -Doug Napoleone

From steve at holdenweb.com  Tue Feb 12 04:14:42 2008
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 11 Feb 2008 22:14:42 -0500
Subject: [Python-Dev] svn repo out of disk?
In-Reply-To: <f08f4fbb0802082248v71def7dewebbb0bec89485317@mail.gmail.com>
References: <f08f4fbb0802082248v71def7dewebbb0bec89485317@mail.gmail.com>
Message-ID: <47B10F22.1040404@holdenweb.com>

Douglas Napoleone wrote:
> Not sure if this is effecting the core svn repository or not, but the
> conference software (also hosted at svn.python.org) is reporting that
> the disk is full:
> 
> Transmitting file data ....svn: Commit failed (details follow):
> svn: Can't create directory '/data/repos/conference/db/transactions/557-1.txn':
> No space left on device
> 
> I have not seen anything on the list about this, but then again, there
> was room at 7pm EST, so I might be the first to notice it.
> 
> I fear this could be effecting more than just the pycon software, and
> figured people would want to be forewarned.
> 
> (Also if someone could fix the problem somehow I would be ever grateful. ;-)
> 
Doug:

You may not be aware that this issue occurred a couple of days ago, and 
Martin von L?wis applied (what appears to be a temporary) fix by 
deleting files. Looks like we need to be a little more aggressive with 
that policy until the replacement machine (due int he next month or two) 
arrives.

Or perhaps we should just add a new disk immediately and relocate some 
stuff?

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 Feb 12 05:04:36 2008
From: aahz at pythoncraft.com (Aahz)
Date: Mon, 11 Feb 2008 20:04:36 -0800
Subject: [Python-Dev] svn repo out of disk?
In-Reply-To: <47B10F22.1040404@holdenweb.com>
References: <f08f4fbb0802082248v71def7dewebbb0bec89485317@mail.gmail.com>
	<47B10F22.1040404@holdenweb.com>
Message-ID: <20080212040436.GA15773@panix.com>

On Mon, Feb 11, 2008, Steve Holden wrote:
> Douglas Napoleone wrote:
>>
>> Not sure if this is effecting the core svn repository or not, but the
>> conference software (also hosted at svn.python.org) is reporting that
>> the disk is full:
>> 
>> [...]
>
> Doug:
> 
> You may not be aware that this issue occurred a couple of days ago, [...]

Steve:

You may not be aware that Doug sent his message a couple of days ago; it
was simply delayed in transit.

(Not that I wasn't confused myself until I looked at the Date: header.)
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of     
indirection."  --Butler Lampson

From python at rcn.com  Tue Feb 12 07:52:30 2008
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 11 Feb 2008 22:52:30 -0800
Subject: [Python-Dev] New math functions
Message-ID: <00fe01c86d43$d73acad0$6800a8c0@RaymondLaptop1>

Was some thought given to possibly adding these as
float methods instead of as separate functions?

     float.isinf()
     float.isnan()

Also, it would be useful to have a new method, float.is_integer().  This would be better than the current approach where we make the 
test:  if x == floor(x).


Raymond 

From steve at holdenweb.com  Tue Feb 12 13:22:44 2008
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 12 Feb 2008 07:22:44 -0500
Subject: [Python-Dev] svn repo out of disk?
In-Reply-To: <20080212040436.GA15773@panix.com>
References: <f08f4fbb0802082248v71def7dewebbb0bec89485317@mail.gmail.com>	<47B10F22.1040404@holdenweb.com>
	<20080212040436.GA15773@panix.com>
Message-ID: <fos32g$gnj$1@ger.gmane.org>

Aahz wrote:
> On Mon, Feb 11, 2008, Steve Holden wrote:
>> Douglas Napoleone wrote:
>>> Not sure if this is effecting the core svn repository or not, but the
>>> conference software (also hosted at svn.python.org) is reporting that
>>> the disk is full:
>>>
>>> [...]
>> Doug:
>>
>> You may not be aware that this issue occurred a couple of days ago, [...]
> 
> Steve:
> 
> You may not be aware that Doug sent his message a couple of days ago; it
> was simply delayed in transit.
> 
> (Not that I wasn't confused myself until I looked at the Date: header.)

[smacks head]
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From guido at python.org  Tue Feb 12 19:10:53 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 12 Feb 2008 10:10:53 -0800
Subject: [Python-Dev] Preventing merges into Py3k
Message-ID: <ca471dc20802121010i3bddd22bq2ed73537d67c443@mail.gmail.com>

On Feb 12, 2008 9:44 AM, thomas.heller <python-3000-checkins at python.org> wrote:
> Author: thomas.heller
> Date: Tue Feb 12 18:44:23 2008
> New Revision: 60746
>
> Modified:
>    python/branches/py3k/Modules/_ctypes/_ctypes.c
> Log:
> Revert the last svnmerge (r60681) from trunk to _ctypes.c, it should
> not have been merged as was noticed in the commit message.

There is a way to prevent merging a particular revision by instructing
svnmerge properly. I believe the syntax is svnmerge block (svnmerge
help block will explain you more).

Christian has been using this -- Christian, care to post a detailed example?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From python at rcn.com  Wed Feb 13 00:23:50 2008
From: python at rcn.com (Raymond Hettinger)
Date: Tue, 12 Feb 2008 18:23:50 -0500 (EST)
Subject: [Python-Dev] Mutable sequence .sort() signature
Message-ID: <20080212182350.AGV12384@ms19.lnh.mail.rcn.net>

[Kurt]
> Looking at the various py3k docs and mail lists, etc. I just can't
> find the specification and discussion of the signature change 
> eliminating the comparison function (so far)!

There is a note Misc/NEWS and I believe the 2-to-3 folks are looking
at a conversion. The Py3.0 docs have the new signature (same as
the old one but it no longer accepts a cmp function and to prevent
accidents keyword arguments are required). I'm not sure where else
to document it.

> Does it come up in -3 warnings?

It doesn't, but it wouldn't be hard to add one.


Raymond
Raymond

From goodger at python.org  Wed Feb 13 03:08:55 2008
From: goodger at python.org (David Goodger)
Date: Tue, 12 Feb 2008 21:08:55 -0500
Subject: [Python-Dev] PyCon: deadline for hotel reservations and early-bird
 registration coming soon!
Message-ID: <47B25137.70707@python.org>

If you haven't registered for PyCon yet, now is the time!  The
early-bird registration deadline is February 20, one week away.  After
that, the price for registration will be going up.

     http://us.pycon.org/2008/registration/

The deadline for hotel reservations at the conference rate is also
February 20.  Act now, because the regular rate is considerably
higher!

     http://us.pycon.org/2008/registration/hotel/

A reminder to tutorial and talk speakers: you are responsible for your
own registration and hotel reservations.  So don't delay!

PyCon 2008: March 14-16, 2008 (& tutorials March 13, & sprints March 17-20)

David Goodger
PyCon 2008 Chair

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/python-dev/attachments/20080212/4541565e/attachment.pgp 

From kbk at shore.net  Wed Feb 13 03:39:39 2008
From: kbk at shore.net (Kurt B. Kaiser)
Date: Tue, 12 Feb 2008 21:39:39 -0500
Subject: [Python-Dev] Mutable sequence .sort() signature
In-Reply-To: <20080212182350.AGV12384@ms19.lnh.mail.rcn.net> (Raymond
	Hettinger's message of "Tue, 12 Feb 2008 18:23:50 -0500 (EST)")
References: <20080212182350.AGV12384@ms19.lnh.mail.rcn.net>
Message-ID: <878x1pk2ac.fsf@hydra.hampton.thirdcreek.com>

Raymond Hettinger <python at rcn.com> writes:

> [Kurt]
>> Looking at the various py3k docs and mail lists, etc. I just can't
>> find the specification and discussion of the signature change 
>> eliminating the comparison function (so far)!
>
> There is a note Misc/NEWS and I believe the 2-to-3 folks are looking
> at a conversion. The Py3.0 docs have the new signature (same as
> the old one but it no longer accepts a cmp function and to prevent
> accidents keyword arguments are required). 

Yes, I see you changed those docs.  But I think we need to give better
notice that this is one of the py3k incompatibilities.

> I'm not sure where else to document it.

I'd say in PEP3100.  Here's a patch:

http://bugs.python.org/issue2092

-- 
KBK

From python at rcn.com  Wed Feb 13 04:01:34 2008
From: python at rcn.com (Raymond Hettinger)
Date: Tue, 12 Feb 2008 22:01:34 -0500 (EST)
Subject: [Python-Dev] Odom
Message-ID: <20080212220134.AGV40937@ms19.lnh.mail.rcn.net>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: odom1.py
Type: text/x-python
Size: 2983 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20080212/67618c2d/attachment.py 

From guido at python.org  Wed Feb 13 04:36:51 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 12 Feb 2008 19:36:51 -0800
Subject: [Python-Dev] Mutable sequence .sort() signature
In-Reply-To: <878x1pk2ac.fsf@hydra.hampton.thirdcreek.com>
References: <20080212182350.AGV12384@ms19.lnh.mail.rcn.net>
	<878x1pk2ac.fsf@hydra.hampton.thirdcreek.com>
Message-ID: <ca471dc20802121936v7cd16c78ueea848a19b086339@mail.gmail.com>

Also, pretty prominent, in the what's new in 3.0 doc.

On Feb 12, 2008 6:39 PM, Kurt B. Kaiser <kbk at shore.net> wrote:
> Raymond Hettinger <python at rcn.com> writes:
>
> > [Kurt]
> >> Looking at the various py3k docs and mail lists, etc. I just can't
> >> find the specification and discussion of the signature change
> >> eliminating the comparison function (so far)!
> >
> > There is a note Misc/NEWS and I believe the 2-to-3 folks are looking
> > at a conversion. The Py3.0 docs have the new signature (same as
> > the old one but it no longer accepts a cmp function and to prevent
> > accidents keyword arguments are required).
>
> Yes, I see you changed those docs.  But I think we need to give better
> notice that this is one of the py3k incompatibilities.
>
> > I'm not sure where else to document it.
>
> I'd say in PEP3100.  Here's a patch:
>
> http://bugs.python.org/issue2092
>
> --
> KBK
>
> _______________________________________________
> 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 kbk at shore.net  Wed Feb 13 05:10:02 2008
From: kbk at shore.net (Kurt B. Kaiser)
Date: Tue, 12 Feb 2008 23:10:02 -0500
Subject: [Python-Dev] Mutable sequence .sort() signature
In-Reply-To: <ca471dc20802121936v7cd16c78ueea848a19b086339@mail.gmail.com>
	(Guido van Rossum's message of "Tue, 12 Feb 2008 19:36:51 -0800")
References: <20080212182350.AGV12384@ms19.lnh.mail.rcn.net>
	<878x1pk2ac.fsf@hydra.hampton.thirdcreek.com>
	<ca471dc20802121936v7cd16c78ueea848a19b086339@mail.gmail.com>
Message-ID: <87wsp9ijj9.fsf@hydra.hampton.thirdcreek.com>

"Guido van Rossum" <guido at python.org> writes:

> Also, pretty prominent, in the what's new in 3.0 doc.

By 'prominent', are you suggesting putting it near the bottom of the
"Common Stumbling Blocks" section, as opposed to the "Other Language
Changes" section?

I can work up a short patch.

-- 
KBK

From guido at python.org  Wed Feb 13 05:19:27 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 12 Feb 2008 20:19:27 -0800
Subject: [Python-Dev] Mutable sequence .sort() signature
In-Reply-To: <87wsp9ijj9.fsf@hydra.hampton.thirdcreek.com>
References: <20080212182350.AGV12384@ms19.lnh.mail.rcn.net>
	<878x1pk2ac.fsf@hydra.hampton.thirdcreek.com>
	<ca471dc20802121936v7cd16c78ueea848a19b086339@mail.gmail.com>
	<87wsp9ijj9.fsf@hydra.hampton.thirdcreek.com>
Message-ID: <ca471dc20802122019h36b29019h1257f00dd90039c8@mail.gmail.com>

On Feb 12, 2008 8:10 PM, Kurt B. Kaiser <kbk at shore.net> wrote:
> "Guido van Rossum" <guido at python.org> writes:
>
> > Also, pretty prominent, in the what's new in 3.0 doc.
>
> By 'prominent', are you suggesting putting it near the bottom of the
> "Common Stumbling Blocks" section, as opposed to the "Other Language
> Changes" section?
>
> I can work up a short patch.

I think that's a good start. Andrew Kuchling can always move it later
if that section becomes too crowded or uneven.

I suggest you just check this in, and also the PEP 3100 patch.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From andymac at bullseye.apana.org.au  Wed Feb 13 08:02:55 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Wed, 13 Feb 2008 17:02:55 +1000
Subject: [Python-Dev] [Fwd: Re:  int/float freelists vs pymalloc]
Message-ID: <47B2961F.5070305@bullseye.andymac.org>

[fwd as reply was intended for python-dev]

Christian Heimes wrote:
> Andrew MacIntyre wrote:
>> I tried a LIFO stack implementation (though I won't claim to have done it
>> well), and found it slightly slower than no freelist at all. The
>> advantage of such an approach is that the known size of the stack makes
>> deallocating excess objects easy (and thus no need for
>> sys.compact_free_list() ).
> 
> I've tried a single linked free list myself. I used the ob_type field to
> daisy chain the int and float objects. Although the code was fairly
> short it was slightly slower than an attempt without a free list at all.
> pymalloc is fast. It's very hard to beat it though.

I'm speculating that CPU cache effects can make these differences.  The
performance of the current trunk float freelist is depressing, given that
the same strategy works so well for ints.

I seem to recall Tim Peters paying a lot of attention to cache effects
when he went over the PyMalloc code before the 2.3 release, which would
contribute to its performance.

> A fixed size LIFO array like PyFloatObject
> *free_list[PyFloat_MAXFREELIST] increased the speed slightly. IMHO a
> value of about 80-200 floats and ints is realistic for most apps. More
> objects in the free lists could keep too many pymalloced areas occupied.

I tested the updated patch you added to issue 2039.  With the int
freelist set to 500 and the float freelist set to 100, its about the same
as the no-freelist version for my tests, but PyBench shows the simple
float arithmetic to be about 10% better.

I'm inclined to set the int LIFO a bit larger than you suggest, simply as
ints are so commonly used - hence the value of 500 I used.  Floats are
much less common by comparison.  Even an int LIFO of 500 is only going to
tie up ~8kB on a 32bit box (~16kB on 64bit), which is insignificant
enough that I can't see a need for a compaction routine.

A 200 entry float LIFO would only account for ~4kB on 32bit (~8kB on
64bit).

I'd like to think that these changes could be considered fixes for
performance bugs so that they could be applied for 2.5.2, but I doubt
that will fly.

Cheers,
Andrew.

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

From lists at cheimes.de  Wed Feb 13 08:23:47 2008
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 13 Feb 2008 08:23:47 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47B2584A.30704@bullseye.andymac.org>
References: <47AB02F9.1010501@bullseye.andymac.org>	<fofesd$2pd$1@ger.gmane.org>	<47AC40E9.2060505@bullseye.andymac.org>	<47AC9F69.6020404@cheimes.de>	<47ACE628.60607@bullseye.andymac.org>
	<foo9i1$sn6$2@ger.gmane.org> <47B2584A.30704@bullseye.andymac.org>
Message-ID: <47B29B03.3030402@cheimes.de>

Andrew MacIntyre wrote:
> I seem to recall Tim Peters paying a lot of attention to cache effects
> when he went over the PyMalloc code before the 2.3 release, which would
> contribute to its performance.

Well, I guess we have to ask Uncle Tim on this matter and ask for his
opinion. I've no experience with optimization on the level of CPU cache
lines. But it sounds interesting. Does somebody have an advice for some
articles or a good book?

> I tested the updated patch you added to issue 2039.  With the int
> freelist set to 500 and the float freelist set to 100, its about the same
> as the no-freelist version for my tests, but PyBench shows the simple
> float arithmetic to be about 10% better.
> 
> I'm inclined to set the int LIFO a bit larger than you suggest, simply as
> ints are so commonly used - hence the value of 500 I used.  Floats are
> much less common by comparison.  Even an int LIFO of 500 is only going to
> tie up ~8kB on a 32bit box (~16kB on 64bit), which is insignificant
> enough that I can't see a need for a compaction routine.
> 
> A 200 entry float LIFO would only account for ~4kB on 32bit (~8kB on
> 64bit).

I added some profiling code to lists and dicts. Increasing the free list
size didn't make a difference for lists and dicts. I used 200 instead of
80 for the free list size and the ratio of reuse / allocation increased
minimal.

Every entry in the free list costs 4 bytes for the pointer and 16 bytes
for the int or float object on 32bit including padding on 8byte address
boundaries. For 500 objects that's about 9kb which isn't a big deal
nowadays. But - andere there is always a but - every object may keep a
4kb arena alive.

Unless a program is creating and destroying lots of ints at once a
larger number doesn't make a performance difference. I'd stick to 80,
maybe 120 for ints for now.

> I'd like to think that these changes could be considered fixes for
> performance bugs so that they could be applied for 2.5.2, but I doubt
> that will fly.

Not a chance ;)

Christian

From mal at egenix.com  Wed Feb 13 10:52:36 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 13 Feb 2008 10:52:36 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47B2961F.5070305@bullseye.andymac.org>
References: <47B2961F.5070305@bullseye.andymac.org>
Message-ID: <47B2BDE4.5020007@egenix.com>

On 2008-02-13 08:02, Andrew MacIntyre wrote:
> Christian Heimes wrote:
>> Andrew MacIntyre wrote:
>>> I tried a LIFO stack implementation (though I won't claim to have done it
>>> well), and found it slightly slower than no freelist at all. The
>>> advantage of such an approach is that the known size of the stack makes
>>> deallocating excess objects easy (and thus no need for
>>> sys.compact_free_list() ).
>> I've tried a single linked free list myself. I used the ob_type field to
>> daisy chain the int and float objects. Although the code was fairly
>> short it was slightly slower than an attempt without a free list at all.
>> pymalloc is fast. It's very hard to beat it though.
> 
> I'm speculating that CPU cache effects can make these differences.  The
> performance of the current trunk float freelist is depressing, given that
> the same strategy works so well for ints.
> 
> I seem to recall Tim Peters paying a lot of attention to cache effects
> when he went over the PyMalloc code before the 2.3 release, which would
> contribute to its performance.
> 
>> A fixed size LIFO array like PyFloatObject
>> *free_list[PyFloat_MAXFREELIST] increased the speed slightly. IMHO a
>> value of about 80-200 floats and ints is realistic for most apps. More
>> objects in the free lists could keep too many pymalloced areas occupied.
> 
> I tested the updated patch you added to issue 2039.  With the int
> freelist set to 500 and the float freelist set to 100, its about the same
> as the no-freelist version for my tests, but PyBench shows the simple
> float arithmetic to be about 10% better.
> 
> I'm inclined to set the int LIFO a bit larger than you suggest, simply as
> ints are so commonly used - hence the value of 500 I used.  Floats are
> much less common by comparison.  Even an int LIFO of 500 is only going to
> tie up ~8kB on a 32bit box (~16kB on 64bit), which is insignificant
> enough that I can't see a need for a compaction routine.
> 
> A 200 entry float LIFO would only account for ~4kB on 32bit (~8kB on
> 64bit).

It is difficult to tell what good limits for free lists should
be. This depends a lot on the application focus, e.g. a financial
application is going to need lots of floats, while a word
processor or parser will need more integers.

I think the main difference between the current free list
implementation and Christian's patches is that the current
implementation bypasses pymalloc altogether and allocates
the objects directly using the system malloc().

The objects in the free list then cannot keep artificially keep
pymalloc pools alive.

Furthermore, the current free list implementation works
by allocating 1k chunks of memory for more than just one
object whenever it finds that the free list is empty.

Christian's patches and your free list removal patch, cause
all allocations to be done via pymalloc. Christian's free
list can also result in nearly empty pymalloc pools to stay
alive due to the use of a linked list rather than an
array of objects.

Finally (and I don't know if you've missed that), the integer
implementation uses sharing for small integers. In the current
implementation all integers between -5 and 257 are only ever
allocated once and then reused whenever an integer in this
range is needed. The shared integers are not subject to any
of the extra free list handling or pymalloc overhead.

This results in a significant boost, since integers in this
range are *very* common and also causes the comparison between
integers and floats to become biased - floats don't have
this optimization.

I still think that dropping the free lists can be worthwhile,
but pymalloc would need to get further optimizations to give
better performance for often requested size classes (the 16 byte
class on 32bit architectures, the 24 byte class on 64bit
architectures).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 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 andymac at bullseye.apana.org.au  Wed Feb 13 12:56:31 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Wed, 13 Feb 2008 21:56:31 +1000
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47B29B03.3030402@cheimes.de>
References: <47AB02F9.1010501@bullseye.andymac.org>	<fofesd$2pd$1@ger.gmane.org>	<47AC40E9.2060505@bullseye.andymac.org>	<47AC9F69.6020404@cheimes.de>	<47ACE628.60607@bullseye.andymac.org>
	<foo9i1$sn6$2@ger.gmane.org> <47B2584A.30704@bullseye.andymac.org>
	<47B29B03.3030402@cheimes.de>
Message-ID: <47B2DAEF.5040003@bullseye.andymac.org>

Christian Heimes wrote:
> Andrew MacIntyre wrote:

>> I tested the updated patch you added to issue 2039.  With the int
>> freelist set to 500 and the float freelist set to 100, its about the same
>> as the no-freelist version for my tests, but PyBench shows the simple
>> float arithmetic to be about 10% better.
>>
>> I'm inclined to set the int LIFO a bit larger than you suggest, simply as
>> ints are so commonly used - hence the value of 500 I used.  Floats are
>> much less common by comparison.  Even an int LIFO of 500 is only going to
>> tie up ~8kB on a 32bit box (~16kB on 64bit), which is insignificant
>> enough that I can't see a need for a compaction routine.
>>
>> A 200 entry float LIFO would only account for ~4kB on 32bit (~8kB on
>> 64bit).
> 
> I added some profiling code to lists and dicts. Increasing the free list
> size didn't make a difference for lists and dicts. I used 200 instead of
> 80 for the free list size and the ratio of reuse / allocation increased
> minimal.
> 
> Every entry in the free list costs 4 bytes for the pointer and 16 bytes
> for the int or float object on 32bit including padding on 8byte address
> boundaries. For 500 objects that's about 9kb which isn't a big deal
> nowadays. But - andere there is always a but - every object may keep a
> 4kb arena alive.

The 4kB entities are "pools" (for allocation size classes); arenas are
the 256kB chunks of memory PyMalloc gets from the platform malloc.  One
active allocation in any size class from a pool in an arena will prevent
release of an arena.

> Unless a program is creating and destroying lots of ints at once a
> larger number doesn't make a performance difference. I'd stick to 80,
> maybe 120 for ints for now.

My thinking was that the price (& I was forgetting that the 12 byte int
object still gets a 16 byte allocation) was small enough that being
generous minimises surprises in production code; after all, we've been 
doing this research with synthetic microbenchmarks.

When you get right down to it, the object freelist offers such a small 
gain that its real value is in the noise in many cases despite being 
measurable.

After all, PyMalloc is nothing but a highly optimised package of 
freelists with the malloc()/realloc()/free() API...  It just does a bit
more book-keeping than the simple freelists used for ints and floats 
(which predate PyMalloc being added to the source tree, let alone being
enabled by default).

I'm not that interested in debating the detail of exactly how big the
prospective LIFO freelists are - I just want to see the situation
resolved with maximum utilisation of memory for minimum performance 
penalty.  To that end, +1 from me for accepting your revised patch 
against issue 2039.  In addition, unless there are other reasons to
retain it, I would be suggesting that the freelist compaction
infrastructure you introduced in r60567 be removed for lack of practical 
utility (assuming acceptance of your patch).

Cheers,
Andrew.

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

From eric+python-dev at trueblade.com  Wed Feb 13 13:12:23 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Wed, 13 Feb 2008 07:12:23 -0500
Subject: [Python-Dev] Why is there to Lib/test/test_int.py?
Message-ID: <47B2DEA7.6060103@trueblade.com>

I want to add test cases for int.__format__(), and I went looking for 
Lib/test/test_int.py.  I've added tests into Lib/test/test_long.py, so I 
assumed there was an int version, but no.

Is there any particular reason for that, and are there int tests 
elsewhere?  If not, I'll add test_int.py, but I want to make sure that's 
the right thing to do.

Thanks.
Eric.

From mal at egenix.com  Wed Feb 13 13:15:10 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 13 Feb 2008 13:15:10 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47B2DAEF.5040003@bullseye.andymac.org>
References: <47AB02F9.1010501@bullseye.andymac.org>	<fofesd$2pd$1@ger.gmane.org>	<47AC40E9.2060505@bullseye.andymac.org>	<47AC9F69.6020404@cheimes.de>	<47ACE628.60607@bullseye.andymac.org>	<foo9i1$sn6$2@ger.gmane.org>
	<47B2584A.30704@bullseye.andymac.org>	<47B29B03.3030402@cheimes.de>
	<47B2DAEF.5040003@bullseye.andymac.org>
Message-ID: <47B2DF4E.201@egenix.com>

On 2008-02-13 12:56, Andrew MacIntyre wrote:
> I'm not that interested in debating the detail of exactly how big the
> prospective LIFO freelists are - I just want to see the situation
> resolved with maximum utilisation of memory for minimum performance 
> penalty.  To that end, +1 from me for accepting your revised patch 
> against issue 2039.  In addition, unless there are other reasons to
> retain it, I would be suggesting that the freelist compaction
> infrastructure you introduced in r60567 be removed for lack of practical 
> utility (assuming acceptance of your patch).

If we're down to voting, here's my vote:

+1 on removing the freelists from ints and floats, but not the
   small int sharing optimization

+1 on focusing on improving pymalloc to handle int and float
   object allocations even better

-1 on changing the freelist implementations to use pymalloc for
   allocation of the freelist members instead of malloc, since
   this would potentially lead to pools (and arenas) being held alive
   by just a few objects - in the worst case a whole arena (256kB)
   for just one int object (14 bytes on 32bit platforms).

Eventually, all freelists should be removed, unless there's a
significant performance loss.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 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 eric+python-dev at trueblade.com  Wed Feb 13 14:28:47 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Wed, 13 Feb 2008 08:28:47 -0500
Subject: [Python-Dev] Adding __format__ to classic classes
Message-ID: <47B2F08F.60802@trueblade.com>

When backporting PEP 3101, do we want to add __format__ to classic 
classes?  If so, could someone give me a pointer on how to implement 
this?  I don't see where to hook it up.

Thanks.
Eric.

From amk at amk.ca  Wed Feb 13 14:42:59 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Wed, 13 Feb 2008 08:42:59 -0500
Subject: [Python-Dev] Mutable sequence .sort() signature
In-Reply-To: <ca471dc20802122019h36b29019h1257f00dd90039c8@mail.gmail.com>
References: <20080212182350.AGV12384@ms19.lnh.mail.rcn.net>
	<878x1pk2ac.fsf@hydra.hampton.thirdcreek.com>
	<ca471dc20802121936v7cd16c78ueea848a19b086339@mail.gmail.com>
	<87wsp9ijj9.fsf@hydra.hampton.thirdcreek.com>
	<ca471dc20802122019h36b29019h1257f00dd90039c8@mail.gmail.com>
Message-ID: <20080213134259.GB6832@amk-desktop.matrixgroup.net>

On Tue, Feb 12, 2008 at 08:19:27PM -0800, Guido van Rossum wrote:
> [on the 'What's New in 3.0' document]
> I think that's a good start. Andrew Kuchling can always move it later
> if that section becomes too crowded or uneven.

I won't be able to work on the 3.0 document in time for 3.0 final
(assuming that's in the next year) because I'm too busy with work, 2.x
tasks, applications, conference-related things, etc.  If someone wants
to take it over for 3.0, now's your chance!

--amk

From andymac at bullseye.apana.org.au  Wed Feb 13 15:28:24 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Thu, 14 Feb 2008 00:28:24 +1000
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47B2DF4E.201@egenix.com>
References: <47AB02F9.1010501@bullseye.andymac.org>	<fofesd$2pd$1@ger.gmane.org>	<47AC40E9.2060505@bullseye.andymac.org>	<47AC9F69.6020404@cheimes.de>	<47ACE628.60607@bullseye.andymac.org>	<foo9i1$sn6$2@ger.gmane.org>	<47B2584A.30704@bullseye.andymac.org>	<47B29B03.3030402@cheimes.de>	<47B2DAEF.5040003@bullseye.andymac.org>
	<47B2DF4E.201@egenix.com>
Message-ID: <47B2FE88.5090503@bullseye.andymac.org>

M.-A. Lemburg wrote:
> On 2008-02-13 12:56, Andrew MacIntyre wrote:
>> I'm not that interested in debating the detail of exactly how big the
>> prospective LIFO freelists are - I just want to see the situation
>> resolved with maximum utilisation of memory for minimum performance 
>> penalty.  To that end, +1 from me for accepting your revised patch 
>> against issue 2039.  In addition, unless there are other reasons to
>> retain it, I would be suggesting that the freelist compaction
>> infrastructure you introduced in r60567 be removed for lack of practical 
>> utility (assuming acceptance of your patch).
> 
> If we're down to voting, here's my vote:
> 
> +1 on removing the freelists from ints and floats, but not the
>    small int sharing optimization
> 
> +1 on focusing on improving pymalloc to handle int and float
>    object allocations even better
> 
> -1 on changing the freelist implementations to use pymalloc for
>    allocation of the freelist members instead of malloc, since
>    this would potentially lead to pools (and arenas) being held alive
>    by just a few objects - in the worst case a whole arena (256kB)
>    for just one int object (14 bytes on 32bit platforms).
> 
> Eventually, all freelists should be removed, unless there's a
> significant performance loss.
> 

Sigh...  things are never as simple as they seem...

Prompted by your comment about the small int sharing, which I was aware 
of and was not addressing because I was assuming that its value was 
unimpeachable, I've been doing some more testing with this and the
freelists.

I don't have time to write it up tonight, but I've concluded that my 
original test scripts and other tests weren't showing the real
performance of the various approaches.  Platform (architecture, compiler
etc) oddities & differences complicate life too...

Cheers,
Andrew.

-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

From lists at cheimes.de  Wed Feb 13 17:02:28 2008
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 13 Feb 2008 17:02:28 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47B2DF4E.201@egenix.com>
References: <47AB02F9.1010501@bullseye.andymac.org>	<fofesd$2pd$1@ger.gmane.org>	<47AC40E9.2060505@bullseye.andymac.org>	<47AC9F69.6020404@cheimes.de>	<47ACE628.60607@bullseye.andymac.org>	<foo9i1$sn6$2@ger.gmane.org>
	<47B2584A.30704@bullseye.andymac.org>	<47B29B03.3030402@cheimes.de>
	<47B2DAEF.5040003@bullseye.andymac.org> <47B2DF4E.201@egenix.com>
Message-ID: <47B31494.80708@cheimes.de>

M.-A. Lemburg wrote:
> +1 on removing the freelists from ints and floats, but not the
>    small int sharing optimization
> 
> +1 on focusing on improving pymalloc to handle int and float
>    object allocations even better
> 
> -1 on changing the freelist implementations to use pymalloc for
>    allocation of the freelist members instead of malloc, since
>    this would potentially lead to pools (and arenas) being held alive
>    by just a few objects - in the worst case a whole arena (256kB)
>    for just one int object (14 bytes on 32bit platforms).
> 
> Eventually, all freelists should be removed, unless there's a
> significant performance loss.

The small ints (and small longs in py3k) should definitely stay. They
make a huge speed impact and they reduce the memory usage a tiny bit, too.

I like to keep the free lists for basic types, too. They bring a
measurable speedup. My profiling has shown that the small free lists
safe about 70% malloc and PyObject_INIT() calls for lists. In Python 3.0
the long free list increases the general speed of int operations by 10%+.

+1 on replacing int's and float's block allocation schema
   with pymalloc

+1 on keeping small int optimization

+1 on focusing on improving pymalloc to handle int and float
   object allocations even better

+1 on adding a small int, float and long (py3k only) free
   list with about 80 to 160 objects each

+1 for MvL's idea to compact all free lists during a full
   gc sweep. Every type with a free list gets a new function
   PySpam_ClearFreeList() which frees all items in the type's
   free list.

The latter counteracts the potential issue with arenas.

By the way objects are always aligned at 8 byte address boundaries. A 12
or 4 bytes object occupies 16 bytes.

Christian


From guido at python.org  Wed Feb 13 18:19:43 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 13 Feb 2008 09:19:43 -0800
Subject: [Python-Dev] Why is there to Lib/test/test_int.py?
In-Reply-To: <47B2DEA7.6060103@trueblade.com>
References: <47B2DEA7.6060103@trueblade.com>
Message-ID: <ca471dc20802130919h6cb3181q26bcfa682469b39a@mail.gmail.com>

I think most int tests are probably in test_types.py.

If you were to create test_int.py now it would probably interfere with
the renaming of test_long.py to test_int.py in the py3k branch
(eventually).

On Feb 13, 2008 4:12 AM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> I want to add test cases for int.__format__(), and I went looking for
> Lib/test/test_int.py.  I've added tests into Lib/test/test_long.py, so I
> assumed there was an int version, but no.
>
> Is there any particular reason for that, and are there int tests
> elsewhere?  If not, I'll add test_int.py, but I want to make sure that's
> the right thing to do.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Wed Feb 13 18:21:07 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 13 Feb 2008 09:21:07 -0800
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <47B2F08F.60802@trueblade.com>
References: <47B2F08F.60802@trueblade.com>
Message-ID: <ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>

On Feb 13, 2008 5:28 AM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> When backporting PEP 3101, do we want to add __format__ to classic
> classes?  If so, could someone give me a pointer on how to implement
> this?  I don't see where to hook it up.

You just have to get the '__format__' attribute and call it if it
exists. Isn't that how you do it for new-style classes too?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From asmodai at in-nomine.org  Wed Feb 13 18:24:05 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Wed, 13 Feb 2008 18:24:05 +0100
Subject: [Python-Dev] Small configure typo?
Message-ID: <20080213172405.GO28991@nexus.in-nomine.org>

With zsh when I try to autocomplete the ./configure options I get this:

_arguments:comparguments:303: invalid option definition:
--enable-universalsdk[SDKDIR][Build against Mac OS X 10.4u SDK (ppc/i386)]

Should this be: --enable-universalsdk[=SDKDIR] ? (Note the = )

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
For wouldst thou not carve at my Soul with thine sword of Supreme Truth?

From eric+python-dev at trueblade.com  Wed Feb 13 18:48:25 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Wed, 13 Feb 2008 12:48:25 -0500
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>
References: <47B2F08F.60802@trueblade.com>
	<ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>
Message-ID: <47B32D69.5060406@trueblade.com>

Guido van Rossum wrote:
> On Feb 13, 2008 5:28 AM, Eric Smith <eric+python-dev at trueblade.com> wrote:
>> When backporting PEP 3101, do we want to add __format__ to classic
>> classes?  If so, could someone give me a pointer on how to implement
>> this?  I don't see where to hook it up.
> 
> You just have to get the '__format__' attribute and call it if it
> exists. Isn't that how you do it for new-style classes too?
> 

I'm thinking that I need to add a __format__ to the "most base" old 
style class, similar to how I added it for object itself (in 
object_methods[]).  As I currently have it in 2.6, I can call __format__ 
on a new style class, but not a classic class:

$ ./python.exe
Python 2.6a0 (trunk:60757M, Feb 13 2008, 09:14:18)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

 >>> class newstyle(object): pass
...
 >>> class oldstyle: pass
...

 >>> newstyle().__format__('')
'<__main__.newstyle object at 0x3d4d90>'

 >>> oldstyle().__format__('')
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
AttributeError: oldstyle instance has no attribute '__format__'

 >>>

So my question is, to what do I need to add __format__ so that classic 
classes will have a default implementation?

My knowledge of how classic classes are implemented is weak, so I don't 
know where to add this.

Eric.



From guido at python.org  Wed Feb 13 19:30:13 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 13 Feb 2008 10:30:13 -0800
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <47B32D69.5060406@trueblade.com>
References: <47B2F08F.60802@trueblade.com>
	<ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>
	<47B32D69.5060406@trueblade.com>
Message-ID: <ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>

On Feb 13, 2008 9:48 AM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> Guido van Rossum wrote:
> > On Feb 13, 2008 5:28 AM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> >> When backporting PEP 3101, do we want to add __format__ to classic
> >> classes?  If so, could someone give me a pointer on how to implement
> >> this?  I don't see where to hook it up.
> >
> > You just have to get the '__format__' attribute and call it if it
> > exists. Isn't that how you do it for new-style classes too?
> >
>
> I'm thinking that I need to add a __format__ to the "most base" old
> style class, similar to how I added it for object itself (in
> object_methods[]).  As I currently have it in 2.6, I can call __format__
> on a new style class, but not a classic class:
>
> $ ./python.exe
> Python 2.6a0 (trunk:60757M, Feb 13 2008, 09:14:18)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>
>  >>> class newstyle(object): pass
> ...
>  >>> class oldstyle: pass
> ...
>
>  >>> newstyle().__format__('')
> '<__main__.newstyle object at 0x3d4d90>'
>
>  >>> oldstyle().__format__('')
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> AttributeError: oldstyle instance has no attribute '__format__'
>
>  >>>
>
> So my question is, to what do I need to add __format__ so that classic
> classes will have a default implementation?
>
> My knowledge of how classic classes are implemented is weak, so I don't
> know where to add this.

Ah, I see.

There is no root class of the classic class hierarchy (that's why
we're nixing it in 3.0 :-).

The customary pattern, used everywhere from len() to setattr(), is to
first check for an (instance) attribute with a special name
(__format__), and if that isn't found, to use a hard-coded fallback
implementation. For len() the fallback raises an exception; for
setattr() it puts the value in the instance __dict__.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From brett at python.org  Wed Feb 13 20:17:33 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 13 Feb 2008 11:17:33 -0800
Subject: [Python-Dev] Small configure typo?
In-Reply-To: <20080213172405.GO28991@nexus.in-nomine.org>
References: <20080213172405.GO28991@nexus.in-nomine.org>
Message-ID: <bbaeab100802131117u1665434bv5a0c79c0b622a168@mail.gmail.com>

On Feb 13, 2008 9:24 AM, Jeroen Ruigrok van der Werven
<asmodai at in-nomine.org> wrote:
> With zsh when I try to autocomplete the ./configure options I get this:
>
> _arguments:comparguments:303: invalid option definition:
> --enable-universalsdk[SDKDIR][Build against Mac OS X 10.4u SDK (ppc/i386)]
>
> Should this be: --enable-universalsdk[=SDKDIR] ? (Note the = )
>

Thanks, Jeroen! That bug has been bothering me for ages but I could
never figure out what was upsetting zsh. Figures it was something
simple. =)

Fixed in r60765 on the trunk and r60766 for 2.5.

-Brett


> --
> Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
> ????? ?????? ??? ?? ??????
> http://www.in-nomine.org/ | http://www.rangaku.org/
> For wouldst thou not carve at my Soul with thine sword of Supreme Truth?
> _______________________________________________
> 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 asmodai at in-nomine.org  Wed Feb 13 20:50:46 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Wed, 13 Feb 2008 20:50:46 +0100
Subject: [Python-Dev] __new__ deprecation
Message-ID: <20080213195046.GT28991@nexus.in-nomine.org>

People,

where can I find rationale/background on the __new__ deprecation warning in
2.6 (and I assume it's totally different in 3.0)?

I could not find anything about it in
http://docs.python.org/dev/3.0/whatsnew/3.0.html or
http://docs.python.org/dev/whatsnew/2.6.html

Cheers,

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
Teachers open the door, but you must enter by yourself. -Chinese Proverb

From guido at python.org  Wed Feb 13 20:55:15 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 13 Feb 2008 11:55:15 -0800
Subject: [Python-Dev] __new__ deprecation
In-Reply-To: <20080213195046.GT28991@nexus.in-nomine.org>
References: <20080213195046.GT28991@nexus.in-nomine.org>
Message-ID: <ca471dc20802131155n29116242j660195956f68780@mail.gmail.com>

What __new__ deprecation warning?

On Feb 13, 2008 11:50 AM, Jeroen Ruigrok van der Werven
<asmodai at in-nomine.org> wrote:
> People,
>
> where can I find rationale/background on the __new__ deprecation warning in
> 2.6 (and I assume it's totally different in 3.0)?
>
> I could not find anything about it in
> http://docs.python.org/dev/3.0/whatsnew/3.0.html or
> http://docs.python.org/dev/whatsnew/2.6.html
>
> Cheers,
>
> --
> Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
> $B%$%'%k!<%s(B $B%i%&%U%m%C%/(B $B%t%!%s(B $B%G%k(B $B%&%'%k%t%'%s(B
> http://www.in-nomine.org/ | http://www.rangaku.org/
> Teachers open the door, but you must enter by yourself. -Chinese Proverb
> _______________________________________________
> 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 eric+python-dev at trueblade.com  Wed Feb 13 21:07:48 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Wed, 13 Feb 2008 15:07:48 -0500
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>
References: <47B2F08F.60802@trueblade.com>	
	<ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>	
	<47B32D69.5060406@trueblade.com>
	<ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>
Message-ID: <47B34E14.6070902@trueblade.com>

Guido van Rossum wrote:
> On Feb 13, 2008 9:48 AM, Eric Smith <eric+python-dev at trueblade.com> wrote:
>> Guido van Rossum wrote:
>>> On Feb 13, 2008 5:28 AM, Eric Smith <eric+python-dev at trueblade.com> wrote:
>>>> When backporting PEP 3101, do we want to add __format__ to classic
>>>> classes?  If so, could someone give me a pointer on how to implement
>>>> this?  I don't see where to hook it up.
>>> You just have to get the '__format__' attribute and call it if it
>>> exists. Isn't that how you do it for new-style classes too?
>>>
>> I'm thinking that I need to add a __format__ to the "most base" old
>> style class, similar to how I added it for object itself (in
>> object_methods[]).  As I currently have it in 2.6, I can call __format__
>> on a new style class, but not a classic class:
>>
>> $ ./python.exe
>> Python 2.6a0 (trunk:60757M, Feb 13 2008, 09:14:18)
>> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>>
>>  >>> class newstyle(object): pass
>> ...
>>  >>> class oldstyle: pass
>> ...
>>
>>  >>> newstyle().__format__('')
>> '<__main__.newstyle object at 0x3d4d90>'
>>
>>  >>> oldstyle().__format__('')
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in <module>
>> AttributeError: oldstyle instance has no attribute '__format__'
>>
>>  >>>
>>
>> So my question is, to what do I need to add __format__ so that classic
>> classes will have a default implementation?
>>
>> My knowledge of how classic classes are implemented is weak, so I don't
>> know where to add this.
> 
> Ah, I see.
> 
> There is no root class of the classic class hierarchy (that's why
> we're nixing it in 3.0 :-).
> 
> The customary pattern, used everywhere from len() to setattr(), is to
> first check for an (instance) attribute with a special name
> (__format__), and if that isn't found, to use a hard-coded fallback
> implementation. For len() the fallback raises an exception; for
> setattr() it puts the value in the instance __dict__.
> 


Much to my surprise, this already works:

 >>> format(oldstyle(), '+^50s')
'+++++<__main__.oldstyle instance at 0x3d91f8>+++++'
 >>>

So I guess it's a moot point.  I'm using the same code as I use in 3.0, 
where I call:
   meth = _PyType_Lookup(Py_TYPE(value), format_str);
where format_str is "__format__" interned.  And I'm getting a value back 
for old style classes.

Eric.

From martin at v.loewis.de  Wed Feb 13 20:57:19 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 13 Feb 2008 20:57:19 +0100
Subject: [Python-Dev] 2.5.2 freeze upcoming
Message-ID: <47B34B9F.80206@v.loewis.de>

The 2.5 maintenance branch will be frozen tomorrow (Thursday)
around 7:00 UTC. Please don't make any changes to the branch
after that point unless you are directly involved in the release
process.

If there are any issues that you think should be considered
before the 2.5.2 release, please assign them to me with high
priority.

Regards,
Martin

From daniel at stutzbachenterprises.com  Wed Feb 13 21:09:57 2008
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Wed, 13 Feb 2008 14:09:57 -0600
Subject: [Python-Dev] Mutable sequence .sort() signature
In-Reply-To: <878x1pk2ac.fsf@hydra.hampton.thirdcreek.com>
References: <20080212182350.AGV12384@ms19.lnh.mail.rcn.net>
	<878x1pk2ac.fsf@hydra.hampton.thirdcreek.com>
Message-ID: <eae285400802131209r41e6b1e7xbf3b15cb803baf3d@mail.gmail.com>

On Feb 12, 2008 8:39 PM, Kurt B. Kaiser <kbk at shore.net> wrote:

> I'd say in PEP3100.  Here's a patch:
>
> http://bugs.python.org/issue2092
>

The suggested patch does not actually point to any discussion or rationale
for why this change was made; it just contains a pointer to this thread
(which is not very useful).  So, while I hate to open a can of worms: but
what's the rationale here?

Without the cmp argument, what's the concise way to spell something like
"sort a list of floats by absolute value"?  It'd be nice to have a stock
example to help users rewrite their code to work with 3.0.

-- 
Daniel Stutzbach, Ph.D.             President, Stutzbach Enterprises LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080213/6a1f3c16/attachment-0001.htm 

From guido at python.org  Wed Feb 13 21:11:20 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 13 Feb 2008 12:11:20 -0800
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <47B34E14.6070902@trueblade.com>
References: <47B2F08F.60802@trueblade.com>
	<ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>
	<47B32D69.5060406@trueblade.com>
	<ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>
	<47B34E14.6070902@trueblade.com>
Message-ID: <ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>

On Feb 13, 2008 12:07 PM, Eric Smith <eric+python-dev at trueblade.com> wrote:
>
> Guido van Rossum wrote:
> > On Feb 13, 2008 9:48 AM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> >> Guido van Rossum wrote:
> >>> On Feb 13, 2008 5:28 AM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> >>>> When backporting PEP 3101, do we want to add __format__ to classic
> >>>> classes?  If so, could someone give me a pointer on how to implement
> >>>> this?  I don't see where to hook it up.
> >>> You just have to get the '__format__' attribute and call it if it
> >>> exists. Isn't that how you do it for new-style classes too?
> >>>
> >> I'm thinking that I need to add a __format__ to the "most base" old
> >> style class, similar to how I added it for object itself (in
> >> object_methods[]).  As I currently have it in 2.6, I can call __format__
> >> on a new style class, but not a classic class:
> >>
> >> $ ./python.exe
> >> Python 2.6a0 (trunk:60757M, Feb 13 2008, 09:14:18)
> >> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> >> Type "help", "copyright", "credits" or "license" for more information.
> >>
> >>  >>> class newstyle(object): pass
> >> ...
> >>  >>> class oldstyle: pass
> >> ...
> >>
> >>  >>> newstyle().__format__('')
> >> '<__main__.newstyle object at 0x3d4d90>'
> >>
> >>  >>> oldstyle().__format__('')
> >> Traceback (most recent call last):
> >>    File "<stdin>", line 1, in <module>
> >> AttributeError: oldstyle instance has no attribute '__format__'
> >>
> >>  >>>
> >>
> >> So my question is, to what do I need to add __format__ so that classic
> >> classes will have a default implementation?
> >>
> >> My knowledge of how classic classes are implemented is weak, so I don't
> >> know where to add this.
> >
> > Ah, I see.
> >
> > There is no root class of the classic class hierarchy (that's why
> > we're nixing it in 3.0 :-).
> >
> > The customary pattern, used everywhere from len() to setattr(), is to
> > first check for an (instance) attribute with a special name
> > (__format__), and if that isn't found, to use a hard-coded fallback
> > implementation. For len() the fallback raises an exception; for
> > setattr() it puts the value in the instance __dict__.
> >
>
>
> Much to my surprise, this already works:
>
>  >>> format(oldstyle(), '+^50s')
> '+++++<__main__.oldstyle instance at 0x3d91f8>+++++'
>  >>>
>
> So I guess it's a moot point.  I'm using the same code as I use in 3.0,
> where I call:
>    meth = _PyType_Lookup(Py_TYPE(value), format_str);
> where format_str is "__format__" interned.  And I'm getting a value back
> for old style classes.
>
> Eric.

But now try overriding __format__().  The 3.0 code uses
_PyType_Lookup() which is not traversing the class dicts for classic
classes, so it won't find __format__ overrides.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Wed Feb 13 21:14:33 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 13 Feb 2008 12:14:33 -0800
Subject: [Python-Dev] Mutable sequence .sort() signature
In-Reply-To: <eae285400802131209r41e6b1e7xbf3b15cb803baf3d@mail.gmail.com>
References: <20080212182350.AGV12384@ms19.lnh.mail.rcn.net>
	<878x1pk2ac.fsf@hydra.hampton.thirdcreek.com>
	<eae285400802131209r41e6b1e7xbf3b15cb803baf3d@mail.gmail.com>
Message-ID: <ca471dc20802131214w4b521eb8ve7a713f8fba913c3@mail.gmail.com>

On Feb 13, 2008 12:09 PM, Daniel Stutzbach
<daniel at stutzbachenterprises.com> wrote:
> Without the cmp argument, what's the concise way to spell something like
> "sort a list of floats by absolute value"?  It'd be nice to have a stock
> example to help users rewrite their code to work with 3.0.

L.sort(key=abs)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From asmodai at in-nomine.org  Wed Feb 13 21:19:18 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Wed, 13 Feb 2008 21:19:18 +0100
Subject: [Python-Dev] __new__ deprecation
In-Reply-To: <ca471dc20802131155n29116242j660195956f68780@mail.gmail.com>
References: <20080213195046.GT28991@nexus.in-nomine.org>
	<ca471dc20802131155n29116242j660195956f68780@mail.gmail.com>
Message-ID: <20080213201918.GV28991@nexus.in-nomine.org>

-On [20080213 21:02], Guido van Rossum (guido at python.org) wrote:
>What __new__ deprecation warning?

Yes, sorry, I realized after sending that it might be a bit obtuse.

With 2.6:

DeprecationWarning: object.__new__() takes no parameters
  return object.__new__(cls, uri)

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
I am the impossibility...

From djarb at highenergymagic.org  Wed Feb 13 21:28:57 2008
From: djarb at highenergymagic.org (Daniel Arbuckle)
Date: Wed, 13 Feb 2008 12:28:57 -0800
Subject: [Python-Dev] Py3k and asyncore/asynchat
Message-ID: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com>

A while back, I volunteered to update asyncore and asynchat for py3k.
I posted a patch, and in response to feedback posted a more
complicated patch+modification.

Both versions have been languishing at
http://bugs.python.org/issue1563 for a couple of months now without
any further feedback or action. I need some more experienced member of
the community to take some sort of action: reviews and suggestions are
welcome, as is advice about which version I should continue on with.
Committing the patch would also be acceptable :)

From eric+python-dev at trueblade.com  Wed Feb 13 22:42:11 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Wed, 13 Feb 2008 16:42:11 -0500
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>
References: <47B2F08F.60802@trueblade.com>	
	<ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>	
	<47B32D69.5060406@trueblade.com>	
	<ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>	
	<47B34E14.6070902@trueblade.com>
	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>
Message-ID: <47B36433.9040905@trueblade.com>

Guido van Rossum wrote:
>> Much to my surprise, this already works:
>>
>>  >>> format(oldstyle(), '+^50s')
>> '+++++<__main__.oldstyle instance at 0x3d91f8>+++++'
>>  >>>
>>
>> So I guess it's a moot point.  I'm using the same code as I use in 3.0,
>> where I call:
>>    meth = _PyType_Lookup(Py_TYPE(value), format_str);
>> where format_str is "__format__" interned.  And I'm getting a value back
>> for old style classes.
>>
>> Eric.
> 
> But now try overriding __format__().  The 3.0 code uses
> _PyType_Lookup() which is not traversing the class dicts for classic
> classes, so it won't find __format__ overrides.
> 

Okay, I see and understand that issue.  But looking at len or getattr, I 
don't see how to generalize it to __format__.  __len__ and __getattr__ 
have special support in the classes, with cl_getattr, tp_getattr, etc.

I hate to be dense, but could you point me to some code that does 
something similar but looks up the method by name?

Thanks for your time.
Eric.

From ncoghlan at gmail.com  Wed Feb 13 23:09:36 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 14 Feb 2008 08:09:36 +1000
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <47B36433.9040905@trueblade.com>
References: <47B2F08F.60802@trueblade.com>		<ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>		<47B32D69.5060406@trueblade.com>		<ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>		<47B34E14.6070902@trueblade.com>	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>
	<47B36433.9040905@trueblade.com>
Message-ID: <47B36AA0.501@gmail.com>

Eric Smith wrote:
> I hate to be dense, but could you point me to some code that does 
> something similar but looks up the method by name?

I was going to suggest __enter__/__exit__, but that code relies mainly 
on existing opcodes and just does an attribute lookup rather than 
explicitly bypassing the instance dictionary.

However, the source code for cPickle may provide some ideas (when it 
looks up _reduce__/__getstate__/etc).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From eric+python-dev at trueblade.com  Wed Feb 13 23:20:26 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Wed, 13 Feb 2008 17:20:26 -0500
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <47B36AA0.501@gmail.com>
References: <47B2F08F.60802@trueblade.com>		<ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>		<47B32D69.5060406@trueblade.com>		<ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>		<47B34E14.6070902@trueblade.com>	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>
	<47B36433.9040905@trueblade.com> <47B36AA0.501@gmail.com>
Message-ID: <47B36D2A.5060405@trueblade.com>

Nick Coghlan wrote:
> Eric Smith wrote:
>> I hate to be dense, but could you point me to some code that does 
>> something similar but looks up the method by name?
> 
> I was going to suggest __enter__/__exit__, but that code relies mainly 
> on existing opcodes and just does an attribute lookup rather than 
> explicitly bypassing the instance dictionary.
> 
> However, the source code for cPickle may provide some ideas (when it 
> looks up _reduce__/__getstate__/etc).

Those do look promising.  Thanks!
Eric.


From guido at python.org  Wed Feb 13 23:39:46 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 13 Feb 2008 14:39:46 -0800
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <47B36D2A.5060405@trueblade.com>
References: <47B2F08F.60802@trueblade.com>
	<ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>
	<47B32D69.5060406@trueblade.com>
	<ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>
	<47B34E14.6070902@trueblade.com>
	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>
	<47B36433.9040905@trueblade.com> <47B36AA0.501@gmail.com>
	<47B36D2A.5060405@trueblade.com>
Message-ID: <ca471dc20802131439p1f56e5abpf6abad16a8930610@mail.gmail.com>

On Feb 13, 2008 2:20 PM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> Nick Coghlan wrote:
> > Eric Smith wrote:
> >> I hate to be dense, but could you point me to some code that does
> >> something similar but looks up the method by name?
> >
> > I was going to suggest __enter__/__exit__, but that code relies mainly
> > on existing opcodes and just does an attribute lookup rather than
> > explicitly bypassing the instance dictionary.
> >
> > However, the source code for cPickle may provide some ideas (when it
> > looks up _reduce__/__getstate__/etc).
>
> Those do look promising.  Thanks!

Or look in classobject.c itself; e.g. instance_str().
-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Wed Feb 13 23:47:53 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 13 Feb 2008 14:47:53 -0800
Subject: [Python-Dev] __new__ deprecation
In-Reply-To: <20080213201918.GV28991@nexus.in-nomine.org>
References: <20080213195046.GT28991@nexus.in-nomine.org>
	<ca471dc20802131155n29116242j660195956f68780@mail.gmail.com>
	<20080213201918.GV28991@nexus.in-nomine.org>
Message-ID: <ca471dc20802131447o71191492g678686c6dcf48b96@mail.gmail.com>

The message means just what it says. :-) There's no point in calling
object.__new__() with more than a class parameter, and any code that
did so was just dumping those args into a black hole.

The only time when it makes sense for object.__new__() to ignore extra
arguments is when it's not being overridden, but __init__ *is* being
overridden -- then you have a completely default __new__ and the
checking of constructor arguments is relegated to __init__.

The purpose of all this is to catch the error in a call like
object(42) which (again) passes an argument that is not used. This is
often a symptom of a bug in your program.

--Guido

On Feb 13, 2008 12:19 PM, Jeroen Ruigrok van der Werven
<asmodai at in-nomine.org> wrote:
> -On [20080213 21:02], Guido van Rossum (guido at python.org) wrote:
> >What __new__ deprecation warning?
>
> Yes, sorry, I realized after sending that it might be a bit obtuse.
>
> With 2.6:
>
> DeprecationWarning: object.__new__() takes no parameters
>   return object.__new__(cls, uri)
>
> --
> Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
> $B%$%'%k!<%s(B $B%i%&%U%m%C%/(B $B%t%!%s(B $B%G%k(B $B%&%'%k%t%'%s(B
> http://www.in-nomine.org/ | http://www.rangaku.org/
> I am the impossibility...
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From eric+python-dev at trueblade.com  Wed Feb 13 23:57:46 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Wed, 13 Feb 2008 17:57:46 -0500
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <ca471dc20802131439p1f56e5abpf6abad16a8930610@mail.gmail.com>
References: <47B2F08F.60802@trueblade.com>	
	<ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>	
	<47B32D69.5060406@trueblade.com>	
	<ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>	
	<47B34E14.6070902@trueblade.com>	
	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>	
	<47B36433.9040905@trueblade.com> <47B36AA0.501@gmail.com>	
	<47B36D2A.5060405@trueblade.com>
	<ca471dc20802131439p1f56e5abpf6abad16a8930610@mail.gmail.com>
Message-ID: <47B375EA.1070901@trueblade.com>

Guido van Rossum wrote:
> On Feb 13, 2008 2:20 PM, Eric Smith <eric+python-dev at trueblade.com> wrote:
>> Nick Coghlan wrote:
>>> Eric Smith wrote:
>>>> I hate to be dense, but could you point me to some code that does
>>>> something similar but looks up the method by name?
>>> I was going to suggest __enter__/__exit__, but that code relies mainly
>>> on existing opcodes and just does an attribute lookup rather than
>>> explicitly bypassing the instance dictionary.
>>>
>>> However, the source code for cPickle may provide some ideas (when it
>>> looks up _reduce__/__getstate__/etc).
>> Those do look promising.  Thanks!
> 
> Or look in classobject.c itself; e.g. instance_str().

It uses a static helper function instance_getattr(), which while it 
looks like what I want, I can't get to.

So I've come up with the following.  I haven't checked for leaks yet, 
but at least it appears to do what I want, for both classic and 
new-style classes.  I'm still porting over test cases from 3.0, so I'm 
not convinced this is correct, yet.

/* Check for a __format__ method. */
meth = PyObject_GetAttr(value, str__format__);
if (meth)
     result = PyObject_CallFunctionObjArgs(meth, spec, NULL);
else {
     meth = _PyType_Lookup(Py_TYPE(value), str__format__);
     if (meth)
         result = PyObject_CallFunctionObjArgs(meth, value, spec, NULL);
     else {
	PyErr_Format(PyExc_TypeError,
		 "Type %.100s doesn't define __format__",
		 Py_TYPE(value)->tp_name);
         goto done;
     }
}



From brett at python.org  Thu Feb 14 00:29:33 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 13 Feb 2008 15:29:33 -0800
Subject: [Python-Dev] Error in post-revprop-change hook in svn
Message-ID: <bbaeab100802131529v1415d26fsd69b5c3e867d1ca4@mail.gmail.com>

I mistyped Jeroen's name so I edited the log message. But I got the
following error message in the process::

  svn: 'post-revprop-change' hook failed; no error output available

The change still occurred, though. Anybody with access to the svn
hooks know what is going on?

-Brett

From greg.ewing at canterbury.ac.nz  Thu Feb 14 00:47:33 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 14 Feb 2008 12:47:33 +1300
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47B31494.80708@cheimes.de>
References: <47AB02F9.1010501@bullseye.andymac.org>
	<fofesd$2pd$1@ger.gmane.org> <47AC40E9.2060505@bullseye.andymac.org>
	<47AC9F69.6020404@cheimes.de> <47ACE628.60607@bullseye.andymac.org>
	<foo9i1$sn6$2@ger.gmane.org> <47B2584A.30704@bullseye.andymac.org>
	<47B29B03.3030402@cheimes.de> <47B2DAEF.5040003@bullseye.andymac.org>
	<47B2DF4E.201@egenix.com> <47B31494.80708@cheimes.de>
Message-ID: <47B38195.4060906@canterbury.ac.nz>

Christian Heimes wrote:
> By the way objects are always aligned at 8 byte address boundaries. A 12
> or 4 bytes object occupies 16 bytes.

Maybe pymalloc should be enhanced so it can cope with
certain odd-sized objects, such as 12 bytes?

-- 
Greg

From guido at python.org  Thu Feb 14 01:03:27 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 13 Feb 2008 16:03:27 -0800
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <47B375EA.1070901@trueblade.com>
References: <47B2F08F.60802@trueblade.com> <47B32D69.5060406@trueblade.com>
	<ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>
	<47B34E14.6070902@trueblade.com>
	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>
	<47B36433.9040905@trueblade.com> <47B36AA0.501@gmail.com>
	<47B36D2A.5060405@trueblade.com>
	<ca471dc20802131439p1f56e5abpf6abad16a8930610@mail.gmail.com>
	<47B375EA.1070901@trueblade.com>
Message-ID: <ca471dc20802131603q2592a5acr4d55c3809b942201@mail.gmail.com>

On Feb 13, 2008 2:57 PM, Eric Smith <eric+python-dev at trueblade.com> wrote:
>
> Guido van Rossum wrote:
> > On Feb 13, 2008 2:20 PM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> >> Nick Coghlan wrote:
> >>> Eric Smith wrote:
> >>>> I hate to be dense, but could you point me to some code that does
> >>>> something similar but looks up the method by name?
> >>> I was going to suggest __enter__/__exit__, but that code relies mainly
> >>> on existing opcodes and just does an attribute lookup rather than
> >>> explicitly bypassing the instance dictionary.
> >>>
> >>> However, the source code for cPickle may provide some ideas (when it
> >>> looks up _reduce__/__getstate__/etc).
> >> Those do look promising.  Thanks!
> >
> > Or look in classobject.c itself; e.g. instance_str().
>
> It uses a static helper function instance_getattr(), which while it
> looks like what I want, I can't get to.

Well, it just implements PyObject_GetAttr for classic class instances...

> So I've come up with the following.  I haven't checked for leaks yet,
> but at least it appears to do what I want, for both classic and
> new-style classes.  I'm still porting over test cases from 3.0, so I'm
> not convinced this is correct, yet.
>
> /* Check for a __format__ method. */
> meth = PyObject_GetAttr(value, str__format__);
> if (meth)
>      result = PyObject_CallFunctionObjArgs(meth, spec, NULL);
> else {

You'd need PyErr_Clear() here the way this is written. But the
following call is redundant -- if that _PyType_Lookup() call finds
something, PyObject_GetAttr() will have found that too (or something
else).

>      meth = _PyType_Lookup(Py_TYPE(value), str__format__);
>      if (meth)
>          result = PyObject_CallFunctionObjArgs(meth, value, spec, NULL);
>      else {
>         PyErr_Format(PyExc_TypeError,
>                  "Type %.100s doesn't define __format__",
>                  Py_TYPE(value)->tp_name);
>          goto done;
>      }
> }

Since PyObject_GetAttr() sets an AttributeError exception already, I
question the benefit of setting a different exception.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From eric+python-dev at trueblade.com  Thu Feb 14 02:31:06 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Wed, 13 Feb 2008 20:31:06 -0500
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <ca471dc20802131603q2592a5acr4d55c3809b942201@mail.gmail.com>
References: <47B2F08F.60802@trueblade.com> <47B32D69.5060406@trueblade.com>	
	<ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>	
	<47B34E14.6070902@trueblade.com>	
	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>	
	<47B36433.9040905@trueblade.com> <47B36AA0.501@gmail.com>	
	<47B36D2A.5060405@trueblade.com>	
	<ca471dc20802131439p1f56e5abpf6abad16a8930610@mail.gmail.com>	
	<47B375EA.1070901@trueblade.com>
	<ca471dc20802131603q2592a5acr4d55c3809b942201@mail.gmail.com>
Message-ID: <47B399DA.1030902@trueblade.com>

[slight mailer problem, this might show up as a dupe.  sorry]
Guido van Rossum wrote:
> On Feb 13, 2008 2:57 PM, Eric Smith <eric+python-dev at trueblade.com> wrote:
>> Guido van Rossum wrote:
>>> On Feb 13, 2008 2:20 PM, Eric Smith <eric+python-dev at trueblade.com> wrote:
>>>> Nick Coghlan wrote:
>>>>> However, the source code for cPickle may provide some ideas (when it
>>>>> looks up _reduce__/__getstate__/etc).
>>>> Those do look promising.  Thanks!
>>> Or look in classobject.c itself; e.g. instance_str().
>> It uses a static helper function instance_getattr(), which while it
>> looks like what I want, I can't get to.
> 
> Well, it just implements PyObject_GetAttr for classic class instances...
> 
>> So I've come up with the following.  I haven't checked for leaks yet,
>> but at least it appears to do what I want, for both classic and
>> new-style classes.  I'm still porting over test cases from 3.0, so I'm
>> not convinced this is correct, yet.
>>
>> /* Check for a __format__ method. */
>> meth = PyObject_GetAttr(value, str__format__);
>> if (meth)
>>      result = PyObject_CallFunctionObjArgs(meth, spec, NULL);
>> else {
> 
> You'd need PyErr_Clear() here the way this is written. 

Okay.

> But the
> following call is redundant -- if that _PyType_Lookup() call finds
> something, PyObject_GetAttr() will have found that too (or something
> else).
> 
>>      meth = _PyType_Lookup(Py_TYPE(value), str__format__);
>>      if (meth)
>>          result = PyObject_CallFunctionObjArgs(meth, value, spec, NULL);
>>      else {
>>         PyErr_Format(PyExc_TypeError,
>>                  "Type %.100s doesn't define __format__",
>>                  Py_TYPE(value)->tp_name);
>>          goto done;
>>      }
>> }

Yes, but what's the "or something else", and is it the right thing?  Are
you saying I should call _PyType_Lookup first?  But that's how I
started: if I do it that way, I can't override __format__ in a classic
class.  As the code stands (PyObject_GetAttr then _PyType_Lookup), it's
definitely true that _PyType_Lookup will succeed when PyObject_GetAttr
will have failed.

Or should the logic be:
if is-new-style-class(Py_TYPE(value)):
    lookup method with _PyType_Lookup(Py_TYPE(value))
else:
    lookup method with PyObject_GetAttr(value)

And if so, how to test for "is-new-style-class"?

Sorry to be wasting your time, but I'm don't understand all of the
issues trying to support both new and classic classes in C.  I think
I'll get the rest of PEP 3101 working, then come back to this issue.
It's pretty well contained.  I'll spend some time understanding
classobject.c's implementation.  It just seems like it shouldn't be this
hard to call a method (if it exists), given an instance.

I think my confusion leads to this problem (if in fact it's a problem):
>>> format(object, '')
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: __format__() takes exactly 1 argument (0 given)
>>> format(object(), '')
'<object object at 0x307408>'
>>> ^D

Which works in the py3k branch.

> Since PyObject_GetAttr() sets an AttributeError exception already, I
> question the benefit of setting a different exception.

Agreed.



From andymac at bullseye.apana.org.au  Thu Feb 14 03:36:56 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Thu, 14 Feb 2008 12:36:56 +1000
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47B31494.80708@cheimes.de>
References: <47AB02F9.1010501@bullseye.andymac.org>	<fofesd$2pd$1@ger.gmane.org>	<47AC40E9.2060505@bullseye.andymac.org>	<47AC9F69.6020404@cheimes.de>	<47ACE628.60607@bullseye.andymac.org>	<foo9i1$sn6$2@ger.gmane.org>	<47B2584A.30704@bullseye.andymac.org>	<47B29B03.3030402@cheimes.de>	<47B2DAEF.5040003@bullseye.andymac.org>
	<47B2DF4E.201@egenix.com> <47B31494.80708@cheimes.de>
Message-ID: <47B3A948.2060503@bullseye.andymac.org>

Christian Heimes wrote:

> By the way objects are always aligned at 8 byte address boundaries. A 12
> or 4 bytes object occupies 16 bytes.

No, with PyMalloc a 4 byte object occupies 8 bytes (see the comments at
the top of Objects/obmalloc.c).

Cheers,
Andrew.

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

From janssen at parc.com  Thu Feb 14 03:52:48 2008
From: janssen at parc.com (Bill Janssen)
Date: Wed, 13 Feb 2008 18:52:48 PST
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com> 
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com>
Message-ID: <08Feb13.185256pst."58696"@synergy1.parc.xerox.com>

It's a big patch, but I'll try applying it to the current py3k branch
-- does it apply? -- and try a few things with it.  I'm concerned
about how well it behaves with things like Medusa (which probably
needs its own py3k update).

Bill

From guido at python.org  Thu Feb 14 05:09:58 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 13 Feb 2008 20:09:58 -0800
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <47B399DA.1030902@trueblade.com>
References: <47B2F08F.60802@trueblade.com> <47B34E14.6070902@trueblade.com>
	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>
	<47B36433.9040905@trueblade.com> <47B36AA0.501@gmail.com>
	<47B36D2A.5060405@trueblade.com>
	<ca471dc20802131439p1f56e5abpf6abad16a8930610@mail.gmail.com>
	<47B375EA.1070901@trueblade.com>
	<ca471dc20802131603q2592a5acr4d55c3809b942201@mail.gmail.com>
	<47B399DA.1030902@trueblade.com>
Message-ID: <ca471dc20802132009t1b0b5688w4c5fbdaa25365490@mail.gmail.com>

Try this:

if (PyInstance_Check(obj)) {
  bound_method = PyObject_GetAttr(obj,  str__format__);
  if (!bound_method)
  return NULL;
  <call it passing only the format string>
  Py_DECREF(bound_method);
  return <whatever the call returned>
}
else {
  do it the py3k way;
}


On Feb 13, 2008 5:31 PM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> [slight mailer problem, this might show up as a dupe.  sorry]
> Guido van Rossum wrote:
> > On Feb 13, 2008 2:57 PM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> >> Guido van Rossum wrote:
> >>> On Feb 13, 2008 2:20 PM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> >>>> Nick Coghlan wrote:
> >>>>> However, the source code for cPickle may provide some ideas (when it
> >>>>> looks up _reduce__/__getstate__/etc).
> >>>> Those do look promising.  Thanks!
> >>> Or look in classobject.c itself; e.g. instance_str().
> >> It uses a static helper function instance_getattr(), which while it
> >> looks like what I want, I can't get to.
> >
> > Well, it just implements PyObject_GetAttr for classic class instances...
> >
> >> So I've come up with the following.  I haven't checked for leaks yet,
> >> but at least it appears to do what I want, for both classic and
> >> new-style classes.  I'm still porting over test cases from 3.0, so I'm
> >> not convinced this is correct, yet.
> >>
> >> /* Check for a __format__ method. */
> >> meth = PyObject_GetAttr(value, str__format__);
> >> if (meth)
> >>      result = PyObject_CallFunctionObjArgs(meth, spec, NULL);
> >> else {
> >
> > You'd need PyErr_Clear() here the way this is written.
>
> Okay.
>
> > But the
> > following call is redundant -- if that _PyType_Lookup() call finds
> > something, PyObject_GetAttr() will have found that too (or something
> > else).
> >
> >>      meth = _PyType_Lookup(Py_TYPE(value), str__format__);
> >>      if (meth)
> >>          result = PyObject_CallFunctionObjArgs(meth, value, spec, NULL);
> >>      else {
> >>         PyErr_Format(PyExc_TypeError,
> >>                  "Type %.100s doesn't define __format__",
> >>                  Py_TYPE(value)->tp_name);
> >>          goto done;
> >>      }
> >> }
>
> Yes, but what's the "or something else", and is it the right thing?  Are
> you saying I should call _PyType_Lookup first?  But that's how I
> started: if I do it that way, I can't override __format__ in a classic
> class.  As the code stands (PyObject_GetAttr then _PyType_Lookup), it's
> definitely true that _PyType_Lookup will succeed when PyObject_GetAttr
> will have failed.
>
> Or should the logic be:
> if is-new-style-class(Py_TYPE(value)):
>     lookup method with _PyType_Lookup(Py_TYPE(value))
> else:
>     lookup method with PyObject_GetAttr(value)
>
> And if so, how to test for "is-new-style-class"?
>
> Sorry to be wasting your time, but I'm don't understand all of the
> issues trying to support both new and classic classes in C.  I think
> I'll get the rest of PEP 3101 working, then come back to this issue.
> It's pretty well contained.  I'll spend some time understanding
> classobject.c's implementation.  It just seems like it shouldn't be this
> hard to call a method (if it exists), given an instance.
>
> I think my confusion leads to this problem (if in fact it's a problem):
> >>> format(object, '')
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> TypeError: __format__() takes exactly 1 argument (0 given)
> >>> format(object(), '')
> '<object object at 0x307408>'
> >>> ^D
>
> Which works in the py3k branch.
>
> > Since PyObject_GetAttr() sets an AttributeError exception already, I
> > question the benefit of setting a different exception.
>
> Agreed.
>
>
>
> _______________________________________________
> 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 jyasskin at gmail.com  Thu Feb 14 06:25:09 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Wed, 13 Feb 2008 21:25:09 -0800
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <47B36433.9040905@trueblade.com>
References: <47B2F08F.60802@trueblade.com>
	<ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>
	<47B32D69.5060406@trueblade.com>
	<ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>
	<47B34E14.6070902@trueblade.com>
	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>
	<47B36433.9040905@trueblade.com>
Message-ID: <5d44f72f0802132125m3b785edap198125dfe636e48b@mail.gmail.com>

On Feb 13, 2008 1:42 PM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> Guido van Rossum wrote:
> >> Much to my surprise, this already works:
> >>
> >>  >>> format(oldstyle(), '+^50s')
> >> '+++++<__main__.oldstyle instance at 0x3d91f8>+++++'
> >>  >>>
> >>
> >> So I guess it's a moot point.  I'm using the same code as I use in 3.0,
> >> where I call:
> >>    meth = _PyType_Lookup(Py_TYPE(value), format_str);
> >> where format_str is "__format__" interned.  And I'm getting a value back
> >> for old style classes.
> >>
> >> Eric.
> >
> > But now try overriding __format__().  The 3.0 code uses
> > _PyType_Lookup() which is not traversing the class dicts for classic
> > classes, so it won't find __format__ overrides.
> >
>
> Okay, I see and understand that issue.  But looking at len or getattr, I
> don't see how to generalize it to __format__.  __len__ and __getattr__
> have special support in the classes, with cl_getattr, tp_getattr, etc.
>
> I hate to be dense, but could you point me to some code that does
> something similar but looks up the method by name?

I'm not sure if it'll be exactly analogous, but you might look at
__trunc__ and math.trunc for inspiration.

-- 
Namast?,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

From jyasskin at gmail.com  Thu Feb 14 06:26:36 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Wed, 13 Feb 2008 21:26:36 -0800
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <5d44f72f0802132125m3b785edap198125dfe636e48b@mail.gmail.com>
References: <47B2F08F.60802@trueblade.com>
	<ca471dc20802130921v2ac5e36drcb111b6af20b4cd4@mail.gmail.com>
	<47B32D69.5060406@trueblade.com>
	<ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>
	<47B34E14.6070902@trueblade.com>
	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>
	<47B36433.9040905@trueblade.com>
	<5d44f72f0802132125m3b785edap198125dfe636e48b@mail.gmail.com>
Message-ID: <5d44f72f0802132126k27324472pe80312f183c8c963@mail.gmail.com>

Oops, sorry for the spam. I didn't see that there were already answers
in the rest of the thread. :-(

On Feb 13, 2008 9:25 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> On Feb 13, 2008 1:42 PM, Eric Smith <eric+python-dev at trueblade.com> wrote:
> > Guido van Rossum wrote:
> > >> Much to my surprise, this already works:
> > >>
> > >>  >>> format(oldstyle(), '+^50s')
> > >> '+++++<__main__.oldstyle instance at 0x3d91f8>+++++'
> > >>  >>>
> > >>
> > >> So I guess it's a moot point.  I'm using the same code as I use in 3.0,
> > >> where I call:
> > >>    meth = _PyType_Lookup(Py_TYPE(value), format_str);
> > >> where format_str is "__format__" interned.  And I'm getting a value back
> > >> for old style classes.
> > >>
> > >> Eric.
> > >
> > > But now try overriding __format__().  The 3.0 code uses
> > > _PyType_Lookup() which is not traversing the class dicts for classic
> > > classes, so it won't find __format__ overrides.
> > >
> >
> > Okay, I see and understand that issue.  But looking at len or getattr, I
> > don't see how to generalize it to __format__.  __len__ and __getattr__
> > have special support in the classes, with cl_getattr, tp_getattr, etc.
> >
> > I hate to be dense, but could you point me to some code that does
> > something similar but looks up the method by name?
>
> I'm not sure if it'll be exactly analogous, but you might look at
> __trunc__ and math.trunc for inspiration.
>
> --
> Namast?,
> Jeffrey Yasskin
> http://jeffrey.yasskin.info/
>



-- 
Namast?,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

From djarb at highenergymagic.org  Thu Feb 14 07:01:09 2008
From: djarb at highenergymagic.org (Daniel Arbuckle)
Date: Wed, 13 Feb 2008 22:01:09 -0800
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <-7020806336625574275@unknownmsgid>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com>
	<-7020806336625574275@unknownmsgid>
Message-ID: <ddd408be0802132201u6e25100wf81d0ed9908a47d@mail.gmail.com>

They applied when posted them, but subsequent patches seem to have
broken them. I've now posted updated patches that apply cleanly
against revision 60780.

On Feb 13, 2008 6:52 PM, Bill Janssen <janssen at parc.com> wrote:
> It's a big patch, but I'll try applying it to the current py3k branch
> -- does it apply? -- and try a few things with it.  I'm concerned
> about how well it behaves with things like Medusa (which probably
> needs its own py3k update).
>
> Bill
>

From martin at v.loewis.de  Thu Feb 14 07:24:30 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 14 Feb 2008 07:24:30 +0100
Subject: [Python-Dev] Error in post-revprop-change hook in svn
In-Reply-To: <bbaeab100802131529v1415d26fsd69b5c3e867d1ca4@mail.gmail.com>
References: <bbaeab100802131529v1415d26fsd69b5c3e867d1ca4@mail.gmail.com>
Message-ID: <47B3DE9E.9070304@v.loewis.de>

> I mistyped Jeroen's name so I edited the log message. But I got the
> following error message in the process::
> 
>   svn: 'post-revprop-change' hook failed; no error output available
> 
> The change still occurred, though. Anybody with access to the svn
> hooks know what is going on?

I have no clue. I believe it would have been

/data/repos/projects/hooks/mailer.py propchange /data/repos/projects 
60765 brett.cannon svn:log

but when I ran that just now, it worked fine, and the message got
sent.

Regards,
Martin

From lists at cheimes.de  Thu Feb 14 08:32:47 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 14 Feb 2008 08:32:47 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47B3A948.2060503@bullseye.andymac.org>
References: <47AB02F9.1010501@bullseye.andymac.org>	<fofesd$2pd$1@ger.gmane.org>	<47AC40E9.2060505@bullseye.andymac.org>	<47AC9F69.6020404@cheimes.de>	<47ACE628.60607@bullseye.andymac.org>	<foo9i1$sn6$2@ger.gmane.org>	<47B2584A.30704@bullseye.andymac.org>	<47B29B03.3030402@cheimes.de>	<47B2DAEF.5040003@bullseye.andymac.org>	<47B2DF4E.201@egenix.com>
	<47B31494.80708@cheimes.de> <47B3A948.2060503@bullseye.andymac.org>
Message-ID: <fp0qrd$sn1$1@ger.gmane.org>

Andrew MacIntyre wrote:
>> By the way objects are always aligned at 8 byte address boundaries. A 12
>> or 4 bytes object occupies 16 bytes.
> 
> No, with PyMalloc a 4 byte object occupies 8 bytes (see the comments at
> the top of Objects/obmalloc.c).

I know. It's a typo. It should read "12 or 14 byte object".

Christian


From eric+python-dev at trueblade.com  Thu Feb 14 12:41:58 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 14 Feb 2008 06:41:58 -0500
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <ca471dc20802132009t1b0b5688w4c5fbdaa25365490@mail.gmail.com>
References: <47B2F08F.60802@trueblade.com> <47B34E14.6070902@trueblade.com>	
	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>	
	<47B36433.9040905@trueblade.com> <47B36AA0.501@gmail.com>	
	<47B36D2A.5060405@trueblade.com>	
	<ca471dc20802131439p1f56e5abpf6abad16a8930610@mail.gmail.com>	
	<47B375EA.1070901@trueblade.com>	
	<ca471dc20802131603q2592a5acr4d55c3809b942201@mail.gmail.com>	
	<47B399DA.1030902@trueblade.com>
	<ca471dc20802132009t1b0b5688w4c5fbdaa25365490@mail.gmail.com>
Message-ID: <47B42906.4030908@trueblade.com>

Guido van Rossum wrote:
> Try this:
> 
> if (PyInstance_Check(obj)) {
>   bound_method = PyObject_GetAttr(obj,  str__format__);
>   if (!bound_method)
>   return NULL;
>   <call it passing only the format string>
>   Py_DECREF(bound_method);
>   return <whatever the call returned>
> }
> else {
>   do it the py3k way;
> }

Yes!  I had converged on something similar.  Also, in the !bound_method 
branch, I convert using str() or unicode() to get the same behavior as 
object.__format__.

I have one more question, which I'll start in another thread.

Eric.

From eric+python-dev at trueblade.com  Thu Feb 14 13:16:03 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 14 Feb 2008 07:16:03 -0500
Subject: [Python-Dev] Calling a builtin from C code;
	PEP 3101 format() builtin
Message-ID: <47B43103.7050209@trueblade.com>

While implementing "".format(), I need to call the builtin format()
function, which I've already implemented (in
bltinmodule.c:builtin_format()).  In the py3k branch, I just hardcoded
the same functionality into "".format(), which seems like the wrong 
thing to do, given how complex the code is.

I see 2 approaches:

1: exposing builtin_format(), probably giving it another name 
(PyObject_Format?) and moving it somewhere other than bltinmodule.c.

2: Instead of calling the C code directly, lookup "format" in Python's
builtins, and call it.  This, I think, would allow you to override the
global format() function if you wanted to modify the behavior (although
I can't think of any use case for wanting to do that).

I don't see where either behavior is specified in the PEP.

If option 2 is preferred, could someone give me a pointer to how to find 
a builtin function from C code?

Thanks.




From g.brandl at gmx.net  Thu Feb 14 13:27:34 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 14 Feb 2008 13:27:34 +0100
Subject: [Python-Dev] Calling a builtin from C code;
	PEP 3101 format() builtin
In-Reply-To: <47B43103.7050209@trueblade.com>
References: <47B43103.7050209@trueblade.com>
Message-ID: <fp1c3c$lki$1@ger.gmane.org>

Eric Smith schrieb:
> While implementing "".format(), I need to call the builtin format()
> function, which I've already implemented (in
> bltinmodule.c:builtin_format()).  In the py3k branch, I just hardcoded
> the same functionality into "".format(), which seems like the wrong 
> thing to do, given how complex the code is.
> 
> I see 2 approaches:
> 
> 1: exposing builtin_format(), probably giving it another name 
> (PyObject_Format?) and moving it somewhere other than bltinmodule.c.
> 
> 2: Instead of calling the C code directly, lookup "format" in Python's
> builtins, and call it.  This, I think, would allow you to override the
> global format() function if you wanted to modify the behavior (although
> I can't think of any use case for wanting to do that).
> 
> I don't see where either behavior is specified in the PEP.
> 
> If option 2 is preferred, could someone give me a pointer to how to find 
> a builtin function from C code?

I don't know which option Guido prefers, but for looking up a function
from the builtins, look at Python/import.c:PyImport_Import which does
this with __import__.

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 ncoghlan at gmail.com  Thu Feb 14 14:14:01 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 14 Feb 2008 23:14:01 +1000
Subject: [Python-Dev] Calling a builtin from C code;
 PEP 3101 format() builtin
In-Reply-To: <47B43103.7050209@trueblade.com>
References: <47B43103.7050209@trueblade.com>
Message-ID: <47B43E99.4060906@gmail.com>

Eric Smith wrote:
> I see 2 approaches:
> 
> 1: exposing builtin_format(), probably giving it another name 
> (PyObject_Format?) and moving it somewhere other than bltinmodule.c.
> 
> 2: Instead of calling the C code directly, lookup "format" in Python's
> builtins, and call it.  This, I think, would allow you to override the
> global format() function if you wanted to modify the behavior (although
> I can't think of any use case for wanting to do that).
> 
> I don't see where either behavior is specified in the PEP.

abstract.h/abstract.c is where most of the PyObject_* functions live, so 
that would be a likely location if we do go with option 1.

Given that the formatting PEP goes to great lengths to describe how to 
make your own custom formatters, I'd be inclined to favour option 1 myself.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From gnewsg at gmail.com  Thu Feb 14 14:42:46 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Thu, 14 Feb 2008 05:42:46 -0800 (PST)
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <08Feb13.185256pst."58696"@synergy1.parc.xerox.com>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com> 
	<08Feb13.185256pst."58696"@synergy1.parc.xerox.com>
Message-ID: <95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com>

asyncore and asynchat are in a difficult position right now since a
lot of patches for both modules are pending and no decisions are
taken.
In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which
is the most important one since it includes a lot of fixes for other
reported issues (e.g. 1740572, 1736101, 909005).
As I said in 1563, IMHO your patch could be reviewed and eventually
committed only after 1736190 and others are committed and 2.x related
problems are solved.
Converting the code to 3.0 should be the last step also because my
perception is that your patch changes too much of the existing code:
a new iterator_producer, a different collect_incoming_data() behavior,
name mangling of internal variables and others.
...A lot of stuff which could be included in a second time.

I'm going to inform Josiah Carlson about this topic since he should be
the most experienced one about asyncore and asynchat.


On 14 Feb, 03:52, Bill Janssen <jans... at parc.com> wrote:
> It's a big patch, but I'll try applying it to the current py3k branch
> -- does it apply? -- and try a few things with it. ?I'm concerned
> about how well it behaves with things like Medusa (which probably
> needs its own py3k update).
>
> Bill
> _______________________________________________
> Python-Dev mailing list
> Python-... at python.orghttp://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv...

From gnewsg at gmail.com  Thu Feb 14 14:55:24 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Thu, 14 Feb 2008 05:55:24 -0800 (PST)
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com> 
	<08Feb13.185256pst."58696"@synergy1.parc.xerox.com>
	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com>
Message-ID: <29e4910a-e75a-4f23-b2ac-ddedd0827eb8@s12g2000prg.googlegroups.com>

(wrong quoting: obvioulsly I was talking to Daniel)

From gnewsg at gmail.com  Thu Feb 14 15:07:31 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Thu, 14 Feb 2008 06:07:31 -0800 (PST)
Subject: [Python-Dev] 2.5.2 freeze upcoming
In-Reply-To: <47B34B9F.80206@v.loewis.de>
References: <47B34B9F.80206@v.loewis.de>
Message-ID: <49e92505-1c72-482b-96c9-7724945b42c7@v67g2000hse.googlegroups.com>

Since I can't change issue assignment I reply here.
Issue 1745035 (which is still open) should concern 2.5.2.

On 13 Feb, 20:57, "Martin v. L?wis" <mar... at v.loewis.de> wrote:
> The 2.5 maintenance branch will be frozen tomorrow (Thursday)
> around 7:00 UTC. Please don't make any changes to the branch
> after that point unless you are directly involved in the release
> process.
>
> If there are any issues that you think should be considered
> before the 2.5.2 release, please assign them to me with high
> priority.
>
> Regards,
> Martin
> _______________________________________________
> Python-Dev mailing list
> Python-... at python.orghttp://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv...

From fdrake at acm.org  Thu Feb 14 15:27:52 2008
From: fdrake at acm.org (Fred Drake)
Date: Thu, 14 Feb 2008 09:27:52 -0500
Subject: [Python-Dev] 2.5.2 freeze upcoming
In-Reply-To: <47B34B9F.80206@v.loewis.de>
References: <47B34B9F.80206@v.loewis.de>
Message-ID: <602BFA19-5971-49A0-A191-494384F89C1E@acm.org>

On Feb 13, 2008, at 2:57 PM, Martin v. L?wis wrote:
> The 2.5 maintenance branch will be frozen tomorrow (Thursday)
> around 7:00 UTC. Please don't make any changes to the branch
> after that point unless you are directly involved in the release
> process.

The documentation packages have been uploaded to python.org.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From facundobatista at gmail.com  Thu Feb 14 16:12:49 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 14 Feb 2008 13:12:49 -0200
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com>
	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com>
Message-ID: <e04bdf310802140712v4b2e1a82q897a5dc3abd84a1@mail.gmail.com>

2008/2/14, Giampaolo Rodola' <gnewsg at gmail.com>:

> asyncore and asynchat are in a difficult position right now since a
>  lot of patches for both modules are pending and no decisions are
>  taken.
>  In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which
>  is the most important one since it includes a lot of fixes for other
>  reported issues (e.g. 1740572, 1736101, 909005).

I took a look to some of these in other opportunity, and IIRC, the
main issue here is exactly what you say: lots of issues with problem
*and* fixes, but some decisions needs to be taken.

No decision taken, the pile of issues (and real problems behind them)
accumulate through time. I think it's a good idea to bring this
discussion here, and with luck a result will come up regarding them.

So, it would be great if you (please) summarize here the problems
behind those issues and the decisions that must be taken... Thanks!

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From gnewsg at gmail.com  Thu Feb 14 16:36:55 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Thu, 14 Feb 2008 07:36:55 -0800 (PST)
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <e04bdf310802140712v4b2e1a82q897a5dc3abd84a1@mail.gmail.com>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com> 
	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com> 
	<e04bdf310802140712v4b2e1a82q897a5dc3abd84a1@mail.gmail.com>
Message-ID: <fcabf485-a74c-405d-991b-71a27986144a@i12g2000prf.googlegroups.com>

Ok, I'll try to take a look at all asyncore/chat reports and try to
summarize them by splitting patches which solve bugs and patches which
add enhancements or functionalities.


On 14 Feb, 16:12, "Facundo Batista" <facundobati... at gmail.com> wrote:
> 2008/2/14, Giampaolo Rodola' <gne... at gmail.com>:
>
> > asyncore and asynchat are in a difficult position right now since a
> > ?lot of patches for both modules are pending and no decisions are
> > ?taken.
> > ?In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which
> > ?is the most important one since it includes a lot of fixes for other
> > ?reported issues (e.g. 1740572, 1736101, 909005).
>
> I took a look to some of these in other opportunity, and IIRC, the
> main issue here is exactly what you say: lots of issues with problem
> *and* fixes, but some decisions needs to be taken.
>
> No decision taken, the pile of issues (and real problems behind them)
> accumulate through time. I think it's a good idea to bring this
> discussion here, and with luck a result will come up regarding them.
>
> So, it would be great if you (please) summarize here the problems
> behind those issues and the decisions that must be taken... Thanks!
>
> Regards,
>
> --
> . ? ?Facundo
>
> Blog:http://www.taniquetil.com.ar/plog/
> PyAr:http://www.python.org/ar/
> _______________________________________________
> Python-Dev mailing list
> Python-... at python.orghttp://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv...

From djarb at highenergymagic.org  Thu Feb 14 16:44:55 2008
From: djarb at highenergymagic.org (Daniel Arbuckle)
Date: Thu, 14 Feb 2008 07:44:55 -0800
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <29e4910a-e75a-4f23-b2ac-ddedd0827eb8@s12g2000prg.googlegroups.com>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com>
	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com>
	<29e4910a-e75a-4f23-b2ac-ddedd0827eb8@s12g2000prg.googlegroups.com>
Message-ID: <ddd408be0802140744r7f61383bqfbfef592eb96ae8e@mail.gmail.com>

First of all, you're conflating my two possible patches.

One patch just addresses the problem of strings and bytes, as GvR
asked me to do, and adds an 8-line class called iterator_producer that
adapts iterators into producers. The patch doesn't change how the
module works at all, and iterator_producer is not invoked anywhere
within the code; it's purely for user convenience. I consider this the
primary patch and would like to focus attention there if possible.

The other patch combines the string and bytes fix with a porting of
1736190 and the other things you complain about, most of which scratch
personal itches. If the patches you mention are actually going to be
applied, then this patch isn't the way to go, and I'll maybe submit
parts of it as separate patches. If they're just going to waste away
in the bug tracker, though, this patch should be seriously considered.

I'm quite willing to re-construct my string and bytes patch against a
version of py3k in which the pre-existing patches are already applied.
There needs to be forward progress, though: If nothing at all gets
done, asyncore is going to be removed from the standard lib. I don't
want to see that happen.

On Thu, Feb 14, 2008 at 5:55 AM, Giampaolo Rodola' <gnewsg at gmail.com> wrote:
> (wrong quoting: obvioulsly I was talking to Daniel)
>
>
> _______________________________________________
>  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/djarb%40highenergymagic.org
>

From ronaldoussoren at mac.com  Thu Feb 14 17:21:39 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 14 Feb 2008 17:21:39 +0100
Subject: [Python-Dev] test_decimal failure on OSX 10.3
Message-ID: <85CC8D1E-F005-42DA-93F7-E9DDD89D27F0@mac.com>

Hi,

I've just filed issue2114 (http://bugs.python.org/issue2114) because  
test_decimal.py fails on OSX 10.3 with Python 2.5.2c1 (using the  
python.org build that will be released soon). The same test passes on  
OSX 10.4 and 10.5 (both Intel and PPC) using the exact same binaries.

IIRC the 2.5.1 release had no unexpected test failures on OSX 10.3, so  
this is a regression in that regard.

Ronald

From dickinsm at gmail.com  Thu Feb 14 17:48:21 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Thu, 14 Feb 2008 11:48:21 -0500
Subject: [Python-Dev] test_decimal failure on OSX 10.3
In-Reply-To: <85CC8D1E-F005-42DA-93F7-E9DDD89D27F0@mac.com>
References: <85CC8D1E-F005-42DA-93F7-E9DDD89D27F0@mac.com>
Message-ID: <5c6f2a5d0802140848r684eee95me4ec1526e26915b8@mail.gmail.com>

On Thu, Feb 14, 2008 at 11:21 AM, Ronald Oussoren <ronaldoussoren at mac.com>
wrote:

> Hi,
>
> I've just filed issue2114 (http://bugs.python.org/issue2114) because
> test_decimal.py fails on OSX 10.3 with Python 2.5.2c1.


It looks like you've got a file Lib/test/decimaltestdata/normalize.decTest
(or possible Normalize.decTest).  This file shouldn't be present in the
distribution (it's outdated).

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080214/89e6ce78/attachment.htm 

From ronaldoussoren at mac.com  Thu Feb 14 17:59:59 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 14 Feb 2008 17:59:59 +0100
Subject: [Python-Dev] test_decimal failure on OSX 10.3
In-Reply-To: <5c6f2a5d0802140848r684eee95me4ec1526e26915b8@mail.gmail.com>
References: <85CC8D1E-F005-42DA-93F7-E9DDD89D27F0@mac.com>
	<5c6f2a5d0802140848r684eee95me4ec1526e26915b8@mail.gmail.com>
Message-ID: <E3059560-38E8-4877-A5E4-75ABB8E74993@mac.com>


On 14 Feb, 2008, at 17:48, Mark Dickinson wrote:

> On Thu, Feb 14, 2008 at 11:21 AM, Ronald Oussoren <ronaldoussoren at mac.com 
> > wrote:
> Hi,
>
> I've just filed issue2114 (http://bugs.python.org/issue2114) because
> test_decimal.py fails on OSX 10.3 with Python 2.5.2c1.
>
> It looks like you've got a file Lib/test/decimaltestdata/ 
> normalize.decTest (or possible Normalize.decTest).  This file  
> shouldn't be present in the distribution (it's outdated).

That fixed the problem (or rather, doing a clean reinstall instead of  
an upgrade install).

Thanks,

  Ronald

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080214/a8ee4255/attachment.htm 

From gnewsg at gmail.com  Thu Feb 14 18:09:38 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Thu, 14 Feb 2008 09:09:38 -0800 (PST)
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <fcabf485-a74c-405d-991b-71a27986144a@i12g2000prf.googlegroups.com>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com> 
	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com> 
	<e04bdf310802140712v4b2e1a82q897a5dc3abd84a1@mail.gmail.com> 
	<fcabf485-a74c-405d-991b-71a27986144a@i12g2000prf.googlegroups.com>
Message-ID: <d0e5b945-1b88-4a72-8f1e-47dfba50eff1@s12g2000prg.googlegroups.com>

On 14 Feb, 16:36, "Giampaolo Rodola'" <gne... at gmail.com> wrote:
> Ok, I'll try to take a look at all asyncore/chat reports and try to
> summarize them by splitting patches which solve bugs and patches which
> add enhancements or functionalities.
>
> On 14 Feb, 16:12, "Facundo Batista" <facundobati... at gmail.com> wrote:
>
>
>
> > 2008/2/14, Giampaolo Rodola' <gne... at gmail.com>:
>
> > > asyncore and asynchat are in a difficult position right now since a
> > > ?lot of patches for both modules are pending and no decisions are
> > > ?taken.
> > > ?In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which
> > > ?is the most important one since it includes a lot of fixes for other
> > > ?reported issues (e.g. 1740572, 1736101, 909005).
>
> > I took a look to some of these in other opportunity, and IIRC, the
> > main issue here is exactly what you say: lots of issues with problem
> > *and* fixes, but some decisions needs to be taken.
>
> > No decision taken, the pile of issues (and real problems behind them)
> > accumulate through time. I think it's a good idea to bring this
> > discussion here, and with luck a result will come up regarding them.
>
> > So, it would be great if you (please) summarize here the problems
> > behind those issues and the decisions that must be taken... Thanks!
>
> > Regards,
>
> > --
> > . ? ?Facundo
>
> > Blog:http://www.taniquetil.com.ar/plog/
> > PyAr:http://www.python.org/ar/



=== Patches for existing issues ===

- 1736190 which includes fixes for the following issues among other
improvements:
  - 1063924 (asyncore should handle ECONNRESET in send())
  - 1736101 (asyncore should handle ECONNABORTED in recv())
  - 760475 (handle_error() should call handle_close() instead of
close())
  - 1740572 (refill_buffer() should call handle_close() rather than
close())
  - 777588 (wrong "connection refused" behavior on Windows)
  - 889153 (wrong connect() behavior)
  - 953599 (asyncore misses socket closes when poll is used)
  - 1025525 (asyncore.file_dispatcher should not take fd as argument)

- 1519 (async_chat.__init__() and asyncore.dispatcher.__init__
parameters inconsistency)
- 1541 (Bad OOB data management when using asyncore with
select.poll())
- 2073 (asynchat push always sends 512 bytes (ignoring
ac_out_buffer_size))


=== Open issues with no patches (need review) ===

- 658749 (asyncore connect() and winsock errors)
- 1161031 (neverending warnings from asyncore)


=== Enhancements & new features ===

- 1641 (add delayed calls feature)
- 1563 (conversion to py3k and some other changes)


IMHO the first thing to do should be modifying 1736190 patch to fix
the minor issues came out in comments 52767 (re-add simple_producer
and fifo classes) and 57581 (look at what is specified in
ac_out_buffer_size) and then commit it.
I've used that same modified asynchat version in my pyftpdlib project
and I can tell that it works pretty good.
I guess that Josiah Carlson could do that pretty quickly if he has
time to do so.

Independently from all a nice thing to do would be adding tests for
many asyncore/chat behaviors which currently aren't covered by the
test suite.
It could be very useful to know if behaviors between different commits
remain the same, hence it would be better working on that (the test
suite) before committing 1736190.


-- Giampaolo

From nas at arctrix.com  Thu Feb 14 20:50:31 2008
From: nas at arctrix.com (Neil Schemenauer)
Date: Thu, 14 Feb 2008 19:50:31 +0000 (UTC)
Subject: [Python-Dev] int/float freelists vs pymalloc
References: <47AB02F9.1010501@bullseye.andymac.org>
	<fofesd$2pd$1@ger.gmane.org>
	<47AC40E9.2060505@bullseye.andymac.org>
	<47AC9F69.6020404@cheimes.de> <47ACE628.60607@bullseye.andymac.org>
	<foo9i1$sn6$2@ger.gmane.org> <47B2584A.30704@bullseye.andymac.org>
	<47B29B03.3030402@cheimes.de>
	<47B2DAEF.5040003@bullseye.andymac.org>
	<47B2DF4E.201@egenix.com> <47B31494.80708@cheimes.de>
Message-ID: <fp2627$o8e$1@ger.gmane.org>

Christian Heimes <lists at cheimes.de> wrote:
> +1 on focusing on improving pymalloc to handle int and float
>    object allocations even better

I wonder if the int and float types could use a faster internal
pymalloc interface.  I can't remember the details but I seem to
recall that pymalloc must jump through some hoops in order to be
safely called from code that used to call PyMem_New, etc.  I think
locking was one problem but there might be others.

  Neil


From martin at v.loewis.de  Thu Feb 14 22:25:37 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 14 Feb 2008 22:25:37 +0100
Subject: [Python-Dev] 2.5.2 freeze upcoming
In-Reply-To: <49e92505-1c72-482b-96c9-7724945b42c7@v67g2000hse.googlegroups.com>
References: <47B34B9F.80206@v.loewis.de>
	<49e92505-1c72-482b-96c9-7724945b42c7@v67g2000hse.googlegroups.com>
Message-ID: <47B4B1D1.2000206@v.loewis.de>

> Since I can't change issue assignment I reply here.
> Issue 1745035 (which is still open) should concern 2.5.2.

Thanks for pointing that out. As the release candidate
has been produced already, it's too late for this specific
patch to go into 2.5.2. Maybe we can consider it for 2.5.3.

Regards,
Martin

From martin at v.loewis.de  Thu Feb 14 22:29:31 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 14 Feb 2008 22:29:31 +0100
Subject: [Python-Dev] RELEASED Python 2.5.2, release candidate 1
Message-ID: <47B4B2BB.1060206@v.loewis.de>

On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.5.2 (release candidate 1).

This is the second bugfix release of Python 2.5. Python 2.5 is now in
bugfix-only mode; no new features are being added. According to the
release notes, over 100 bugs and patches have been addressed since
Python 2.5.1, many of them improving the stability of the interpreter,
and improving its portability.

For more information on Python 2.5.2, including download links for
various platforms, release notes, and known issues, please see:

   http://www.python.org/2.5.2/

Highlights of this new release include:

   Bug fixes. According to the release notes, at least 100 have been fixed.

Highlights of the previous major Python release (2.5) are available
from the Python 2.5 page, at

   http://www.python.org/2.5/highlights.html

Enjoy this release,
Martin

Martin v. Loewis
martin at v.loewis.de
Python Release Manager
(on behalf of the entire python-dev team)

From greg.ewing at canterbury.ac.nz  Thu Feb 14 23:36:38 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 15 Feb 2008 11:36:38 +1300
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <47B399DA.1030902@trueblade.com>
References: <47B2F08F.60802@trueblade.com> <47B32D69.5060406@trueblade.com>
	<ca471dc20802131030h104abb09yca5fa319fd80a13e@mail.gmail.com>
	<47B34E14.6070902@trueblade.com>
	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>
	<47B36433.9040905@trueblade.com> <47B36AA0.501@gmail.com>
	<47B36D2A.5060405@trueblade.com>
	<ca471dc20802131439p1f56e5abpf6abad16a8930610@mail.gmail.com>
	<47B375EA.1070901@trueblade.com>
	<ca471dc20802131603q2592a5acr4d55c3809b942201@mail.gmail.com>
	<47B399DA.1030902@trueblade.com>
Message-ID: <47B4C276.9000504@canterbury.ac.nz>

Eric Smith wrote:
> Are you saying I should call _PyType_Lookup first?

No, I think he's saying that you don't need to call
_PyType_Lookup at all, because anything that it could
find will also be found by PyObject_GetAttr.

So just call PyObject_GetAttr and it should Just Work.

--
Greg

From greg.ewing at canterbury.ac.nz  Fri Feb 15 00:01:16 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 15 Feb 2008 12:01:16 +1300
Subject: [Python-Dev] Calling a builtin from C code;
 PEP 3101 format() builtin
In-Reply-To: <47B43103.7050209@trueblade.com>
References: <47B43103.7050209@trueblade.com>
Message-ID: <47B4C83C.1030708@canterbury.ac.nz>

Eric Smith wrote:

> 1: exposing builtin_format(), probably giving it another name 
> (PyObject_Format?) and moving it somewhere other than bltinmodule.c.

PyObject_Format sounds more like an API for invoking the
__format__ lookup mechanism. Maybe something like
PyObject_DefaultFormat would be better.

--
Greg

From guido at python.org  Fri Feb 15 00:12:18 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 14 Feb 2008 15:12:18 -0800
Subject: [Python-Dev] Adding __format__ to classic classes
In-Reply-To: <47B4C276.9000504@canterbury.ac.nz>
References: <47B2F08F.60802@trueblade.com>
	<ca471dc20802131211k2c8dd9e8nc3f31dd8c74b4e38@mail.gmail.com>
	<47B36433.9040905@trueblade.com> <47B36AA0.501@gmail.com>
	<47B36D2A.5060405@trueblade.com>
	<ca471dc20802131439p1f56e5abpf6abad16a8930610@mail.gmail.com>
	<47B375EA.1070901@trueblade.com>
	<ca471dc20802131603q2592a5acr4d55c3809b942201@mail.gmail.com>
	<47B399DA.1030902@trueblade.com> <47B4C276.9000504@canterbury.ac.nz>
Message-ID: <ca471dc20802141512j97911a6of6464469cf6b83da@mail.gmail.com>

On Thu, Feb 14, 2008 at 2:36 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Eric Smith wrote:
>  > Are you saying I should call _PyType_Lookup first?
>
>  No, I think he's saying that you don't need to call
>  _PyType_Lookup at all, because anything that it could
>  find will also be found by PyObject_GetAttr.
>
>  So just call PyObject_GetAttr and it should Just Work.

In case you missed the final result, that turned out to be wrong too:
format(object, "") dies when you do it that way. We debugged this very
same issue about a year ago, and that's where the _PyType_Lookup call
was found to be the solution. GetAttr should only be used for classic
class instances (PyInstance_Check()).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From eric+python-dev at trueblade.com  Fri Feb 15 03:27:39 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 14 Feb 2008 21:27:39 -0500
Subject: [Python-Dev] Calling a builtin from C code;
 PEP 3101 format() builtin
In-Reply-To: <47B4C83C.1030708@canterbury.ac.nz>
References: <47B43103.7050209@trueblade.com>
	<47B4C83C.1030708@canterbury.ac.nz>
Message-ID: <47B4F89B.9090506@trueblade.com>

Greg Ewing wrote:
> Eric Smith wrote:
> 
>> 1: exposing builtin_format(), probably giving it another name 
>> (PyObject_Format?) and moving it somewhere other than bltinmodule.c.
> 
> PyObject_Format sounds more like an API for invoking the
> __format__ lookup mechanism. Maybe something like
> PyObject_DefaultFormat would be better.

I see it like:
PyObject_Str(o) gives you str(o),
PyObject_Unicode(o) gives you unicode(o)
so
PyObject_Format(o, spec) give you format(o, spec).

All 3 of them do things with __special__ methods.

Eric.


From josiah.carlson at gmail.com  Fri Feb 15 03:24:04 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Thu, 14 Feb 2008 18:24:04 -0800
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <d0e5b945-1b88-4a72-8f1e-47dfba50eff1@s12g2000prg.googlegroups.com>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com>
	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com>
	<e04bdf310802140712v4b2e1a82q897a5dc3abd84a1@mail.gmail.com>
	<fcabf485-a74c-405d-991b-71a27986144a@i12g2000prf.googlegroups.com>
	<d0e5b945-1b88-4a72-8f1e-47dfba50eff1@s12g2000prg.googlegroups.com>
Message-ID: <e6511dbf0802141824nf396efbte722a49f877cfc16@mail.gmail.com>

Hey everyone,

Sorry I haven't been available for this recently, I've been working
far too much (10-14 hours/day, 6 days/week, since November) to really
do any "fun" programming.  Also, sorry for top-posting.

As I stated 2+ and 6+ months ago, the patches I submitted 9+ months
ago work (I've been using them in my own projects without issue).  The
only issue with the bugfix/rearrangement that I last heard about with
regards to the 2.x stuff was that I removed a class that no one was
using in the wild, which I believe Giampaolo added in a subsequent
patch in the last couple months.

My suggestion:
1. Apply the most recent fixes to 2.6 asyncore/asynchat that Giampaolo
has updated.
1.a. Figure out what the hell is up with OOB data, how to handle it,
and stop making it use handle_expt().
2. Use the 2.x -> 3.x tool to convert the fixes over.
3. Apply any 3.x specific fixes (for string/bytes, etc.) to the 3.x
branch as necessary (make them global constants in both 2.x and 3.x so
that they are easy to track).
4. Consider enhancements to 2.6 if they aren't to big, consider
slightly larger enhancements to 3.x. *

 - Josiah

* Scheduled tasks are not a valid enhancement for either; anyone who
wants them can trivially add them with their own asyncore.loop()
variant and call asyncore.poll() as necessary (I did it in about 15
lines in the summer of 2002, I hope others can do better now).  If you
want my opinion on other async-related features, feel free to email me
directly (use the gmail address you see here, then it ends up in my
inbox, not the overflowing python folder).

On Thu, Feb 14, 2008 at 9:09 AM, Giampaolo Rodola' <gnewsg at gmail.com> wrote:
> On 14 Feb, 16:36, "Giampaolo Rodola'" <gne... at gmail.com> wrote:
>  > Ok, I'll try to take a look at all asyncore/chat reports and try to
>  > summarize them by splitting patches which solve bugs and patches which
>  > add enhancements or functionalities.
>  >
>  > On 14 Feb, 16:12, "Facundo Batista" <facundobati... at gmail.com> wrote:
>  >
>  >
>  >
>  > > 2008/2/14, Giampaolo Rodola' <gne... at gmail.com>:
>  >
>  > > > asyncore and asynchat are in a difficult position right now since a
>  > > >  lot of patches for both modules are pending and no decisions are
>  > > >  taken.
>  > > >  In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which
>  > > >  is the most important one since it includes a lot of fixes for other
>  > > >  reported issues (e.g. 1740572, 1736101, 909005).
>  >
>  > > I took a look to some of these in other opportunity, and IIRC, the
>  > > main issue here is exactly what you say: lots of issues with problem
>  > > *and* fixes, but some decisions needs to be taken.
>  >
>  > > No decision taken, the pile of issues (and real problems behind them)
>  > > accumulate through time. I think it's a good idea to bring this
>  > > discussion here, and with luck a result will come up regarding them.
>  >
>  > > So, it would be great if you (please) summarize here the problems
>  > > behind those issues and the decisions that must be taken... Thanks!
>  >
>  > > Regards,
>  >
>  > > --
>  > > .    Facundo
>  >
>  > > Blog:http://www.taniquetil.com.ar/plog/
>  > > PyAr:http://www.python.org/ar/
>
>
>
>  === Patches for existing issues ===
>
>  - 1736190 which includes fixes for the following issues among other
>  improvements:
>   - 1063924 (asyncore should handle ECONNRESET in send())
>   - 1736101 (asyncore should handle ECONNABORTED in recv())
>   - 760475 (handle_error() should call handle_close() instead of
>  close())
>   - 1740572 (refill_buffer() should call handle_close() rather than
>  close())
>   - 777588 (wrong "connection refused" behavior on Windows)
>   - 889153 (wrong connect() behavior)
>   - 953599 (asyncore misses socket closes when poll is used)
>   - 1025525 (asyncore.file_dispatcher should not take fd as argument)
>
>  - 1519 (async_chat.__init__() and asyncore.dispatcher.__init__
>  parameters inconsistency)
>  - 1541 (Bad OOB data management when using asyncore with
>  select.poll())
>  - 2073 (asynchat push always sends 512 bytes (ignoring
>  ac_out_buffer_size))
>
>
>  === Open issues with no patches (need review) ===
>
>  - 658749 (asyncore connect() and winsock errors)
>  - 1161031 (neverending warnings from asyncore)
>
>
>  === Enhancements & new features ===
>
>  - 1641 (add delayed calls feature)
>  - 1563 (conversion to py3k and some other changes)
>
>
>  IMHO the first thing to do should be modifying 1736190 patch to fix
>  the minor issues came out in comments 52767 (re-add simple_producer
>  and fifo classes) and 57581 (look at what is specified in
>  ac_out_buffer_size) and then commit it.
>  I've used that same modified asynchat version in my pyftpdlib project
>  and I can tell that it works pretty good.
>  I guess that Josiah Carlson could do that pretty quickly if he has
>  time to do so.
>
>  Independently from all a nice thing to do would be adding tests for
>  many asyncore/chat behaviors which currently aren't covered by the
>  test suite.
>  It could be very useful to know if behaviors between different commits
>  remain the same, hence it would be better working on that (the test
>  suite) before committing 1736190.
>
>
>  -- Giampaolo
>

From lists at cheimes.de  Fri Feb 15 11:01:33 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 15 Feb 2008 11:01:33 +0100
Subject: [Python-Dev] New math functions
In-Reply-To: <00fe01c86d43$d73acad0$6800a8c0@RaymondLaptop1>
References: <00fe01c86d43$d73acad0$6800a8c0@RaymondLaptop1>
Message-ID: <47B562FD.90109@cheimes.de>

Raymond Hettinger wrote:
> Was some thought given to possibly adding these as
> float methods instead of as separate functions?
> 
>      float.isinf()
>      float.isnan()
> 
> Also, it would be useful to have a new method, float.is_integer().  This would be better than the current approach where we make the 
> test:  if x == floor(x).

No, I haven't thought about it. I could add isinf (or better is_inf?) to
the float type but the methods in the math and cmath module should stay
as well. They can also deal with complex and integer numbers.

+1 for is_integer

static PyObject *
float_is_integer(PyObject *v)
{
	double x = PyFloat_AsDouble(v);
	PyObject *o;
	
	if (x == -1.0 && PyErr_Occurred())
		return NULL;
	if (!Py_IS_FINITE(x))
		Py_RETURN_FALSE;
	PyFPE_START_PROTECT("is_integer", return 0)
	o = (floor(x) == x) ? Py_True : Py_False;
	PyFPE_END_PROTECT(x)
	if (errno != 0) {
		PyErr_SetFromErrno(errno == ERANGE ? PyExc_OverflowError :
						     PyExc_ValueError);
		return NULL;
	}
	Py_INCREF(o);
	return o;
}


Christian

From dickinsm at gmail.com  Fri Feb 15 14:27:05 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Fri, 15 Feb 2008 08:27:05 -0500
Subject: [Python-Dev] New math functions
In-Reply-To: <00fe01c86d43$d73acad0$6800a8c0@RaymondLaptop1>
References: <00fe01c86d43$d73acad0$6800a8c0@RaymondLaptop1>
Message-ID: <5c6f2a5d0802150527r3ae358d8n28a265615bf36701@mail.gmail.com>

On Tue, Feb 12, 2008 at 1:52 AM, Raymond Hettinger <python at rcn.com> wrote:

> Also, it would be useful to have a new method, float.is_integer().  This
> would be better than the current approach where we make the
> test:  if x == floor(x).
>

How common is this test?  Given the inexact nature of floating-point
arithmetic, checking whether a float is exactly an integer seems like
something that one might actually want to discourage, just like comparing
two floats for equality.

Also, what about having float.is_finite, as a quicker way to spell "not
isinf(x) and not isnan(x)"

+1 on making these methods of float;  they're fundamental properties.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080215/b1643f1d/attachment.htm 

From amk at amk.ca  Fri Feb 15 15:24:14 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Fri, 15 Feb 2008 09:24:14 -0500
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <e6511dbf0802141824nf396efbte722a49f877cfc16@mail.gmail.com>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com>
	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com>
	<e04bdf310802140712v4b2e1a82q897a5dc3abd84a1@mail.gmail.com>
	<fcabf485-a74c-405d-991b-71a27986144a@i12g2000prf.googlegroups.com>
	<d0e5b945-1b88-4a72-8f1e-47dfba50eff1@s12g2000prg.googlegroups.com>
	<e6511dbf0802141824nf396efbte722a49f877cfc16@mail.gmail.com>
Message-ID: <20080215142414.GA6805@amk-desktop.matrixgroup.net>

On Thu, Feb 14, 2008 at 06:24:04PM -0800, Josiah Carlson wrote:
> 1.a. Figure out what the hell is up with OOB data, how to handle it,
> and stop making it use handle_expt().

Does OOB data actually need to be supported?  For a long time TCP
implementations usually had buggy OOB implementations because it was
so rarely used; for all I know, that's still the case.  Maybe the
feature should just be dropped.

--amk

From jon+python-dev at unequivocal.co.uk  Fri Feb 15 15:28:32 2008
From: jon+python-dev at unequivocal.co.uk (Jon Ribbens)
Date: Fri, 15 Feb 2008 14:28:32 +0000
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <20080215142414.GA6805@amk-desktop.matrixgroup.net>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com>
	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com>
	<e04bdf310802140712v4b2e1a82q897a5dc3abd84a1@mail.gmail.com>
	<fcabf485-a74c-405d-991b-71a27986144a@i12g2000prf.googlegroups.com>
	<d0e5b945-1b88-4a72-8f1e-47dfba50eff1@s12g2000prg.googlegroups.com>
	<e6511dbf0802141824nf396efbte722a49f877cfc16@mail.gmail.com>
	<20080215142414.GA6805@amk-desktop.matrixgroup.net>
Message-ID: <20080215142832.GC13291@snowy.squish.net>

On Fri, Feb 15, 2008 at 09:24:14AM -0500, A.M. Kuchling wrote:
> On Thu, Feb 14, 2008 at 06:24:04PM -0800, Josiah Carlson wrote:
> > 1.a. Figure out what the hell is up with OOB data, how to handle it,
> > and stop making it use handle_expt().
> 
> Does OOB data actually need to be supported?  For a long time TCP
> implementations usually had buggy OOB implementations because it was
> so rarely used; for all I know, that's still the case.  Maybe the
> feature should just be dropped.

Only if you're happy to make it impossible to implement some protocols
using asyncore.

From ndbecker2 at gmail.com  Fri Feb 15 15:52:29 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 15 Feb 2008 09:52:29 -0500
Subject: [Python-Dev] New math functions
References: <00fe01c86d43$d73acad0$6800a8c0@RaymondLaptop1>
	<5c6f2a5d0802150527r3ae358d8n28a265615bf36701@mail.gmail.com>
Message-ID: <fp48vd$143$1@ger.gmane.org>

Mark Dickinson wrote:

> On Tue, Feb 12, 2008 at 1:52 AM, Raymond Hettinger <python at rcn.com> wrote:
> 
>> Also, it would be useful to have a new method, float.is_integer().  This
>> would be better than the current approach where we make the
>> test:  if x == floor(x).
>>
> 
> How common is this test?  Given the inexact nature of floating-point
> arithmetic, checking whether a float is exactly an integer seems like
> something that one might actually want to discourage, just like comparing
> two floats for equality.
> 
> Also, what about having float.is_finite, as a quicker way to spell "not
> isinf(x) and not isnan(x)"
> 
> +1 on making these methods of float;  they're fundamental properties.
> 
> Mark

Yes, and I don't know if this was mentioned, but should add to complex also.

isfinite (complex_x):
        return isfinite (x.real) and isfinite (x.imag)


From status at bugs.python.org  Fri Feb 15 18:06:11 2008
From: status at bugs.python.org (Tracker)
Date: Fri, 15 Feb 2008 18:06:11 +0100 (CET)
Subject: [Python-Dev] Summary of Tracker Issues
Message-ID: <20080215170611.CE5BE78173@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (02/08/08 - 02/15/08)
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.


 1720 open (+39) / 12232 closed (+13) / 13952 total (+52)

Open issues with patches:   449

Average duration of open issues: 745 days.
Median duration of open issues: 1081 days.

Open Issues Breakdown
   open  1695 (+37)
pending    25 ( +2)

Issues Created Or Reopened (53)
_______________________________

PYO file permission problem                                      02/08/08
       http://bugs.python.org/issue2051    created  stocker81                
                                                                               

Lack of difflib.HtmlDiff unicode support                         02/08/08
       http://bugs.python.org/issue2052    created  josephoenix              
                                                                               

IDLE - standardize dialogs                                       02/09/08
       http://bugs.python.org/issue2053    created  taleinat                 
       patch                                                                   

add ftp-tls support to ftplib - RFC 4217                         02/09/08
       http://bugs.python.org/issue2054    created  gregory.p.smith          
       easy                                                                    

test_fcntl.py converted to unittest                              02/09/08
       http://bugs.python.org/issue2055    created  giampaolo.rodola         
       patch                                                                   

install command rejects --compiler option                        02/10/08
CLOSED http://bugs.python.org/issue2056    created  kermode                  
                                                                               

difflib: add patch capability                                    02/10/08
       http://bugs.python.org/issue2057    created  techtonik                
                                                                               

reduce tarfile memory footprint                                  02/10/08
       http://bugs.python.org/issue2058    created  lars.gustaebel           
       patch                                                                   

OptionMenu class is defined both in Tkinter and Tix              02/10/08
       http://bugs.python.org/issue2059    created  isandler                 
                                                                               

python2.6 -3 gives "warning: callable() not supported in 3.x" on 02/10/08
       http://bugs.python.org/issue2060    created  eopadoan                 
                                                                               

IDLE - autocompletion to support alternate patch separators      02/10/08
       http://bugs.python.org/issue2061    created  taleinat                 
       patch                                                                   

IDLE - autocompletion logic optimization                         02/10/08
       http://bugs.python.org/issue2062    created  taleinat                 
       patch                                                                   

os.times() utime and stime exchanged on windows                  02/11/08
CLOSED http://bugs.python.org/issue2063    created  kcwu                     
       patch                                                                   

List of Dicts problem                                            02/11/08
CLOSED http://bugs.python.org/issue2064    created  sunaluak                 
                                                                               

trunk version does not compile with vs8 and vc6                  02/11/08
       http://bugs.python.org/issue2065    created  amaury.forgeotdarc       
                                                                               

Adding new CNS11643, a *huge* charset, support in cjkcodecs      02/11/08
       http://bugs.python.org/issue2066    created  hyeshik.chang            
                                                                               

file.__exit__ does not call subclass' close method               02/11/08
       http://bugs.python.org/issue2067    created  belopolsky               
                                                                               

SimpleXMLRPCServer documentation about  rpc_paths might be wrong 02/11/08
       http://bugs.python.org/issue2072    created  schwarz                  
                                                                               

asynchat push always sends 512 bytes (ignoring ac_out_buffer_siz 02/11/08
       http://bugs.python.org/issue2073    created  mkc                      
                                                                               

pprint._safe_repr() unsafe on ordering differently types objects 02/12/08
       http://bugs.python.org/issue2074    created  percivall                
                                                                               

Float number comparision problem                                 02/12/08
CLOSED http://bugs.python.org/issue2075    created  tsxy                     
                                                                               

xmlrpclib closes connection after each call                      02/12/08
       http://bugs.python.org/issue2076    created  erno                     
                                                                               

Interpreter crash on shutdown                                    02/12/08
       http://bugs.python.org/issue2077    created  rupert.summerton         
                                                                               

CSV Sniffer does not function properly on single column .csv fil 02/12/08
       http://bugs.python.org/issue2078    created  jplaverdure              
                                                                               

UserDict documentation typo                                      02/12/08
       http://bugs.python.org/issue2079    created  gsf                      
                                                                               

Syntax for property set method                                   02/12/08
CLOSED http://bugs.python.org/issue2085    created  LambertDW                
                                                                               

__import__ with fromlist=[''] causes double initialization of mo 02/12/08
       http://bugs.python.org/issue2090    created  hauser                   
                                                                               

file accepts 'rU+' as a mode                                     02/12/08
       http://bugs.python.org/issue2091    created  brett.cannon             
                                                                               

PEP-3100 should reflect removal of 'cmp' parameter in sort() and 02/13/08
CLOSED http://bugs.python.org/issue2092    created  kbk                      
                                                                               

Reporting bugs page refers to old site                           02/13/08
CLOSED http://bugs.python.org/issue2096    created  Yinon                    
                                                                               

typo in exception-handling tutorial                              02/13/08
CLOSED http://bugs.python.org/issue2097    created  Yinon                    
                                                                               

unclear error message on bug reporting                           02/13/08
CLOSED http://bugs.python.org/issue2099    created  Yinon                    
                                                                               

unit test UnicodeWarning                                         02/13/08
       http://bugs.python.org/issue2100    created  JosephArmbruster         
                                                                               

xml.dom documentation doesn't match implementation               02/13/08
       http://bugs.python.org/issue2101    created  stefan                   
                                                                               

New style vs. old style classes __ror__()  operator overloading  02/13/08
       http://bugs.python.org/issue2102    created  calvin                   
                                                                               

__x should be _x in documentation of property()                  02/13/08
CLOSED http://bugs.python.org/issue2103    created  bgailer                  
                                                                               

?                                                                02/14/08
CLOSED http://bugs.python.org/issue2109    created  susanna                  
                                                                               

Implement __format__ for Decimal                                 02/14/08
       http://bugs.python.org/issue2110    created  facundobatista           
                                                                               

mmap segfaults when trying to write a block opened with PROT_REA 02/14/08
       http://bugs.python.org/issue2111    created  therve                   
                                                                               

mmap.error should be a subclass of EnvironmentError and not a di 02/14/08
       http://bugs.python.org/issue2112    created  therve                   
       patch, easy                                                             

Bad interaction between signal and subprocess                    02/14/08
       http://bugs.python.org/issue2113    created  piro                     
                                                                               

test_decimal failure on OSX 10.3                                 02/14/08
CLOSED http://bugs.python.org/issue2114    created  ronaldoussoren           
                                                                               

__slots__ make attribute setting 10x slower                      02/14/08
       http://bugs.python.org/issue2115    created  jyasskin                 
                                                                               

weakref copy module interaction                                  02/14/08
       http://bugs.python.org/issue2116    created  rharris                  
                                                                               

smtplib.SMTP() raises socket.error rather than SMTPConnectError  02/14/08
       http://bugs.python.org/issue2118    created  stranger4good            
                                                                               

Empty test                                                       02/14/08
CLOSED http://bugs.python.org/issue2119    created  loewis                   
                                                                               

broken links in advocacy HOWTO                                   02/15/08
       http://bugs.python.org/issue2120    created  salty-horse              
                                                                               

complex constructor doesn't accept string with nan and inf       02/15/08
       http://bugs.python.org/issue2121    created  tiran                    
                                                                               

mmap.flush does not check for errors on windows                  02/15/08
       http://bugs.python.org/issue2122    created  schmir                   
                                                                               

ctypes pointer not always keeping target alive                   02/15/08
       http://bugs.python.org/issue2123    created  arigo                    
                                                                               

xml.sax and xml.dom fetch DTDs by default                        02/15/08
       http://bugs.python.org/issue2124    created  akuchling                
                                                                               

[patch] Read support for Records in msilib                       02/15/08
       http://bugs.python.org/issue2125    created  flub                     
                                                                               

test_sqlite fails on OSX G5 arch if test_ctypes is run           02/10/08
       http://bugs.python.org/issue1581906 reopened skip.montanaro           
                                                                               



Issues Now Closed (29)
______________________

Probable extra semicolon in Py_LeaveRecursiveCall macro            63 days
       http://bugs.python.org/issue1595    loewis                   
                                                                               

IDLE messes around with sys.exitfunc                               58 days
       http://bugs.python.org/issue1647    kbk                      
                                                                               

Force WINVER 0x0500 (Windows 2000)                                 43 days
       http://bugs.python.org/issue1706    tiran                    
                                                                               

Three bugs of FCICreate (PC/_msi.c)                                39 days
       http://bugs.python.org/issue1736    loewis                   
       patch                                                                   

IDLE fails to launch                                               39 days
       http://bugs.python.org/issue1743    kbk                      
                                                                               

infinite loop in httplib                                           14 days
       http://bugs.python.org/issue1966    loewis                   
       patch, easy                                                             

asyncore loop lacks timers and work tasks                          10 days
       http://bugs.python.org/issue2006    facundobatista           
                                                                               

Turn NamedTemporaryFile into a context manager                      5 days
       http://bugs.python.org/issue2021    ncoghlan                 
       patch                                                                   

Class instance attributes that are property() should appear in _    1 days
       http://bugs.python.org/issue2040    tiran                    
                                                                               

IDLE - Restart Shell & Run Module                                   3 days
       http://bugs.python.org/issue2049    taleinat                 
       patch                                                                   

install command rejects --compiler option                           0 days
       http://bugs.python.org/issue2056    loewis                   
                                                                               

os.times() utime and stime exchanged on windows                     2 days
       http://bugs.python.org/issue2063    georg.brandl             
       patch                                                                   

List of Dicts problem                                               0 days
       http://bugs.python.org/issue2064    tiran                    
                                                                               

Float number comparision problem                                    0 days
       http://bugs.python.org/issue2075    amaury.forgeotdarc       
                                                                               

Syntax for property set method                                      0 days
       http://bugs.python.org/issue2085    georg.brandl             
                                                                               

PEP-3100 should reflect removal of 'cmp' parameter in sort() and    1 days
       http://bugs.python.org/issue2092    kbk                      
                                                                               

Reporting bugs page refers to old site                              0 days
       http://bugs.python.org/issue2096    facundobatista           
                                                                               

typo in exception-handling tutorial                                 0 days
       http://bugs.python.org/issue2097    facundobatista           
                                                                               

unclear error message on bug reporting                              0 days
       http://bugs.python.org/issue2099    facundobatista           
                                                                               

__x should be _x in documentation of property()                     0 days
       http://bugs.python.org/issue2103    marketdickinson          
                                                                               

?                                                                   0 days
       http://bugs.python.org/issue2109    amaury.forgeotdarc       
                                                                               

test_decimal failure on OSX 10.3                                    1 days
       http://bugs.python.org/issue2114    ronaldoussoren           
                                                                               

Empty test                                                          0 days
       http://bugs.python.org/issue2119    loewis                   
                                                                               

virtual IO for embedding Py in server                            2358 days
       http://bugs.python.org/issue456086  draghuram                
                                                                               

Uninstall target in makefile                                     2112 days
       http://bugs.python.org/issue549764  draghuram                
                                                                               

Embedded python thread crashes                                   1018 days
       http://bugs.python.org/issue1193099 amaury.forgeotdarc       
                                                                               

Spurious Tabnanny error                                           511 days
       http://bugs.python.org/issue1562716 kbk                      
                                                                               

simple moves freeze IDLE                                          497 days
       http://bugs.python.org/issue1571112 kbk                      
                                                                               

0.0 and -0.0 identified, with surprising results                  339 days
       http://bugs.python.org/issue1678380 marketdickinson          
       patch                                                                   



Top Issues Most Discussed (10)
______________________________

 25 Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.       56 days
open    http://bugs.python.org/issue1682   

 11 Adding new CNS11643, a *huge* charset, support in cjkcodecs        4 days
open    http://bugs.python.org/issue2066   

  9 Force WINVER 0x0500 (Windows 2000)                                43 days
closed  http://bugs.python.org/issue1706   

  8 trunk version does not compile with vs8 and vc6                    4 days
open    http://bugs.python.org/issue2065   

  7 __slots__ make attribute setting 10x slower                        1 days
open    http://bugs.python.org/issue2115   

  6 test_decimal failure on OSX 10.3                                   1 days
closed  http://bugs.python.org/issue2114   

  6 IDLE - autocompletion logic optimization                           5 days
open    http://bugs.python.org/issue2062   

  6 shutil.destinsrc returns wrong result when source path matches     7 days
open    http://bugs.python.org/issue2047   

  5 Inheriting from ABCs makes classes slower.                        38 days
open    http://bugs.python.org/issue1762   

  4 __x should be _x in documentation of property()                    0 days
closed  http://bugs.python.org/issue2103   




From theller at ctypes.org  Fri Feb 15 18:57:17 2008
From: theller at ctypes.org (Thomas Heller)
Date: Fri, 15 Feb 2008 18:57:17 +0100
Subject: [Python-Dev] Error in PEP3118?
In-Reply-To: <foq804$1iq$1@ger.gmane.org>
References: <47905DAE.9020802@ctypes.org>
	<fn7p9u$7rh$1@ger.gmane.org>	<fn832p$ebb$1@ger.gmane.org>
	<foq804$1iq$1@ger.gmane.org>
Message-ID: <fp4jps$dq6$1@ger.gmane.org>

Travis Oliphant schrieb:
> Thomas Heller wrote:
>> Travis Oliphant schrieb:
>> 
>>> So, I think the example is correct (and intentional).
>> 
>> Sorry, I do not think so.  If you use a 2-d array in the example, you
>> must describe it correctly.  The difference between this pep and the old
> 
> I don't understand what you mean by "must describe it correctly".   The 
[...]

Travis,  it seems anyone except me understands what you say and thinks it
is fine.  So, IMO it would be best to live with this misunderstanding and
close the discussion.

Thanks and sorry about the confusion,
Thomas


From gnewsg at gmail.com  Fri Feb 15 20:45:14 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Fri, 15 Feb 2008 11:45:14 -0800 (PST)
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <20080215142832.GC13291@snowy.squish.net>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com> 
	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com> 
	<e04bdf310802140712v4b2e1a82q897a5dc3abd84a1@mail.gmail.com> 
	<fcabf485-a74c-405d-991b-71a27986144a@i12g2000prf.googlegroups.com> 
	<d0e5b945-1b88-4a72-8f1e-47dfba50eff1@s12g2000prg.googlegroups.com> 
	<e6511dbf0802141824nf396efbte722a49f877cfc16@mail.gmail.com> 
	<20080215142414.GA6805@amk-desktop.matrixgroup.net>
	<20080215142832.GC13291@snowy.squish.net>
Message-ID: <ac031ea8-ad55-4608-b900-904286a19411@s37g2000prg.googlegroups.com>

On 15 Feb, 03:24, "Josiah Carlson" <josiah.carl... at gmail.com> wrote:

> As I stated 2+ and 6+ months ago, the patches I submitted 9+ months
> ago work (I've been using them in my own projects without issue).  The
> only issue with the bugfix/rearrangement that I last heard about with
> regards to the 2.x stuff was that I removed a class that no one was
> using in the wild, which I believe Giampaolo added in a subsequent
> patch in the last couple months.

I provided the patch for the other issue (look at what is specified in
ac_out_buffer_size) but I didn't re-add fifo and simple_producer
classes.
What should be done here? Re-add or discard them?
However, I will send to you by e-mail the modified asynchat version.
It is based on your patch therefore a first commit could be finally
done.

> My suggestion:
> 1. Apply the most recent fixes to 2.6 asyncore/asynchat that Giampaolo
> has updated.
> 1.a. Figure out what the hell is up with OOB data, how to handle it,
> and stop making it use handle_expt().

If we want to leave OOB untouched shouldn't handle_expt be the right
place where manage such kind of events?
Alternatively we could also remove the OOB management at all (e.g.
Twisted does that by ignoring such kind of data).
OOB could be actually useful to implement some protocols such as FTP
(in details ABOR and STAT commands which require OOB data) but it
would be probably better not having it than having it but not
implemented properly.
I am saying this also because later or soonish we might need to care
of epoll and kqueue (http://bugs.python.org/issue1657).

> * Scheduled tasks are not a valid enhancement for either; anyone who
> wants them can trivially add them with their own asyncore.loop()
> variant and call asyncore.poll() as necessary (I did it in about 15
> lines in the summer of 2002, I hope others can do better now).  If you
> want my opinion on other async-related features, feel free to email me
> directly (use the gmail address you see here, then it ends up in my
> inbox, not the overflowing python folder).

How's your solution? Could you post it here or send it to me by mail?
IMO scheduled tasks is a very important feature for implementing a lot
of interesting stuff like connection timeouts and bandwidth
throttling.
A lot of people have to learn/use Twisted just because of that.
Moreover I think that Bill Janssen could need that feature to make the
ssl module work with asyncore.


PS - I have been reading this mailing list for a short time therefore
I have no clue whether or not someone has ever thought about including
the Twisted core - only itself - in Python stdlib.

From josiah.carlson at gmail.com  Fri Feb 15 21:11:31 2008
From: josiah.carlson at gmail.com (Josiah Carlson)
Date: Fri, 15 Feb 2008 12:11:31 -0800
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <ac031ea8-ad55-4608-b900-904286a19411@s37g2000prg.googlegroups.com>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com>
	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com>
	<e04bdf310802140712v4b2e1a82q897a5dc3abd84a1@mail.gmail.com>
	<fcabf485-a74c-405d-991b-71a27986144a@i12g2000prf.googlegroups.com>
	<d0e5b945-1b88-4a72-8f1e-47dfba50eff1@s12g2000prg.googlegroups.com>
	<e6511dbf0802141824nf396efbte722a49f877cfc16@mail.gmail.com>
	<20080215142414.GA6805@amk-desktop.matrixgroup.net>
	<20080215142832.GC13291@snowy.squish.net>
	<ac031ea8-ad55-4608-b900-904286a19411@s37g2000prg.googlegroups.com>
Message-ID: <e6511dbf0802151211p4fa9bc7ah97b49eb3c1d26889@mail.gmail.com>

Twisted core has been proposed, but I believe the consensus was that
it wasn't desirable, generally.

I'm also pretty sure that people learn twisted because everyone learns
twisted.  It's one of those buzz-words ;).

As for task scheduling, I believe it was something like...

import asyncore
import time
import heapq

tasks = []

def schedule(delta, callme):
    heapq.heappush(tasks, (time.time()+delta, callme))

def loop_with_schedule(timeout=30):
    while 1:
        now = time.time()
        while tasks and tasks[0][0] < now:
            callme = heapq.heappop(tasks)[1]
            try:
                callme()
            except (KeyboardInterrupt, SystemExit):
                raise
            except:
                #do something useful
                pass
        thistimeout = timeout
        if tasks:
            thistimeout = max(min(thistimeout, tasks[0][0]-now), 0)

        asyncore.poll(timeout=thistimeout)

 - Josiah


On Fri, Feb 15, 2008 at 11:45 AM, Giampaolo Rodola' <gnewsg at gmail.com> wrote:
> On 15 Feb, 03:24, "Josiah Carlson" <josiah.carl... at gmail.com> wrote:
>
>  > As I stated 2+ and 6+ months ago, the patches I submitted 9+ months
>  > ago work (I've been using them in my own projects without issue).  The
>  > only issue with the bugfix/rearrangement that I last heard about with
>  > regards to the 2.x stuff was that I removed a class that no one was
>  > using in the wild, which I believe Giampaolo added in a subsequent
>  > patch in the last couple months.
>
>  I provided the patch for the other issue (look at what is specified in
>  ac_out_buffer_size) but I didn't re-add fifo and simple_producer
>  classes.
>  What should be done here? Re-add or discard them?
>  However, I will send to you by e-mail the modified asynchat version.
>  It is based on your patch therefore a first commit could be finally
>  done.
>
>
>  > My suggestion:
>  > 1. Apply the most recent fixes to 2.6 asyncore/asynchat that Giampaolo
>  > has updated.
>
> > 1.a. Figure out what the hell is up with OOB data, how to handle it,
>  > and stop making it use handle_expt().
>
>  If we want to leave OOB untouched shouldn't handle_expt be the right
>  place where manage such kind of events?
>  Alternatively we could also remove the OOB management at all (e.g.
>  Twisted does that by ignoring such kind of data).
>  OOB could be actually useful to implement some protocols such as FTP
>  (in details ABOR and STAT commands which require OOB data) but it
>  would be probably better not having it than having it but not
>  implemented properly.
>  I am saying this also because later or soonish we might need to care
>  of epoll and kqueue (http://bugs.python.org/issue1657).
>
>
>  > * Scheduled tasks are not a valid enhancement for either; anyone who
>  > wants them can trivially add them with their own asyncore.loop()
>  > variant and call asyncore.poll() as necessary (I did it in about 15
>  > lines in the summer of 2002, I hope others can do better now).  If you
>  > want my opinion on other async-related features, feel free to email me
>  > directly (use the gmail address you see here, then it ends up in my
>  > inbox, not the overflowing python folder).
>
>  How's your solution? Could you post it here or send it to me by mail?
>  IMO scheduled tasks is a very important feature for implementing a lot
>  of interesting stuff like connection timeouts and bandwidth
>  throttling.
>  A lot of people have to learn/use Twisted just because of that.
>  Moreover I think that Bill Janssen could need that feature to make the
>  ssl module work with asyncore.
>
>
>  PS - I have been reading this mailing list for a short time therefore
>  I have no clue whether or not someone has ever thought about including
>  the Twisted core - only itself - in Python stdlib.
>
>
> _______________________________________________
>  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 janssen at parc.com  Fri Feb 15 21:36:46 2008
From: janssen at parc.com (Bill Janssen)
Date: Fri, 15 Feb 2008 12:36:46 PST
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <e6511dbf0802151211p4fa9bc7ah97b49eb3c1d26889@mail.gmail.com> 
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com>
	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com>
	<e04bdf310802140712v4b2e1a82q897a5dc3abd84a1@mail.gmail.com>
	<fcabf485-a74c-405d-991b-71a27986144a@i12g2000prf.googlegroups.com>
	<d0e5b945-1b88-4a72-8f1e-47dfba50eff1@s12g2000prg.googlegroups.com>
	<e6511dbf0802141824nf396efbte722a49f877cfc16@mail.gmail.com>
	<20080215142414.GA6805@amk-desktop.matrixgroup.net>
	<20080215142832.GC13291@snowy.squish.net>
	<ac031ea8-ad55-4608-b900-904286a19411@s37g2000prg.googlegroups.com>
	<e6511dbf0802151211p4fa9bc7ah97b49eb3c1d26889@mail.gmail.com>
Message-ID: <08Feb15.123656pst."58696"@synergy1.parc.xerox.com>

I think we should just replace the current "loop" with this (and add
the "schedule" function).  Then other folks won't have to figure out
how the module works and write their own loop.  I'll be happy to update
the documentation to document it.

Bill

> Twisted core has been proposed, but I believe the consensus was that
> it wasn't desirable, generally.
> 
> I'm also pretty sure that people learn twisted because everyone learns
> twisted.  It's one of those buzz-words ;).
> 
> As for task scheduling, I believe it was something like...
> 
> import asyncore
> import time
> import heapq
> 
> tasks = []
> 
> def schedule(delta, callme):
>     heapq.heappush(tasks, (time.time()+delta, callme))
> 
> def loop_with_schedule(timeout=30):
>     while 1:
>         now = time.time()
>         while tasks and tasks[0][0] < now:
>             callme = heapq.heappop(tasks)[1]
>             try:
>                 callme()
>             except (KeyboardInterrupt, SystemExit):
>                 raise
>             except:
>                 #do something useful
>                 pass
>         thistimeout = timeout
>         if tasks:
>             thistimeout = max(min(thistimeout, tasks[0][0]-now), 0)
> 
>         asyncore.poll(timeout=thistimeout)
> 
>  - Josiah
> 
> 
> On Fri, Feb 15, 2008 at 11:45 AM, Giampaolo Rodola' <gnewsg at gmail.com> wrote:
> > On 15 Feb, 03:24, "Josiah Carlson" <josiah.carl... at gmail.com> wrote:
> >
> >  > As I stated 2+ and 6+ months ago, the patches I submitted 9+ months
> >  > ago work (I've been using them in my own projects without issue).  The
> >  > only issue with the bugfix/rearrangement that I last heard about with
> >  > regards to the 2.x stuff was that I removed a class that no one was
> >  > using in the wild, which I believe Giampaolo added in a subsequent
> >  > patch in the last couple months.
> >
> >  I provided the patch for the other issue (look at what is specified in
> >  ac_out_buffer_size) but I didn't re-add fifo and simple_producer
> >  classes.
> >  What should be done here? Re-add or discard them?
> >  However, I will send to you by e-mail the modified asynchat version.
> >  It is based on your patch therefore a first commit could be finally
> >  done.
> >
> >
> >  > My suggestion:
> >  > 1. Apply the most recent fixes to 2.6 asyncore/asynchat that Giampaolo
> >  > has updated.
> >
> > > 1.a. Figure out what the hell is up with OOB data, how to handle it,
> >  > and stop making it use handle_expt().
> >
> >  If we want to leave OOB untouched shouldn't handle_expt be the right
> >  place where manage such kind of events?
> >  Alternatively we could also remove the OOB management at all (e.g.
> >  Twisted does that by ignoring such kind of data).
> >  OOB could be actually useful to implement some protocols such as FTP
> >  (in details ABOR and STAT commands which require OOB data) but it
> >  would be probably better not having it than having it but not
> >  implemented properly.
> >  I am saying this also because later or soonish we might need to care
> >  of epoll and kqueue (http://bugs.python.org/issue1657).
> >
> >
> >  > * Scheduled tasks are not a valid enhancement for either; anyone who
> >  > wants them can trivially add them with their own asyncore.loop()
> >  > variant and call asyncore.poll() as necessary (I did it in about 15
> >  > lines in the summer of 2002, I hope others can do better now).  If you
> >  > want my opinion on other async-related features, feel free to email me
> >  > directly (use the gmail address you see here, then it ends up in my
> >  > inbox, not the overflowing python folder).
> >
> >  How's your solution? Could you post it here or send it to me by mail?
> >  IMO scheduled tasks is a very important feature for implementing a lot
> >  of interesting stuff like connection timeouts and bandwidth
> >  throttling.
> >  A lot of people have to learn/use Twisted just because of that.
> >  Moreover I think that Bill Janssen could need that feature to make the
> >  ssl module work with asyncore.
> >
> >
> >  PS - I have been reading this mailing list for a short time therefore
> >  I have no clue whether or not someone has ever thought about including
> >  the Twisted core - only itself - in Python stdlib.
> >
> >
> > _______________________________________________
> >  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
> >
> _______________________________________________
> 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/janssen%40parc.com



From gnewsg at gmail.com  Fri Feb 15 21:55:40 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Fri, 15 Feb 2008 12:55:40 -0800 (PST)
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <08Feb15.123656pst."58696"@synergy1.parc.xerox.com>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com> 
	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com> 
	<e04bdf310802140712v4b2e1a82q897a5dc3abd84a1@mail.gmail.com> 
	<fcabf485-a74c-405d-991b-71a27986144a@i12g2000prf.googlegroups.com> 
	<d0e5b945-1b88-4a72-8f1e-47dfba50eff1@s12g2000prg.googlegroups.com> 
	<e6511dbf0802141824nf396efbte722a49f877cfc16@mail.gmail.com> 
	<20080215142414.GA6805@amk-desktop.matrixgroup.net>
	<20080215142832.GC13291@snowy.squish.net> 
	<ac031ea8-ad55-4608-b900-904286a19411@s37g2000prg.googlegroups.com> 
	<e6511dbf0802151211p4fa9bc7ah97b49eb3c1d26889@mail.gmail.com> 
	<08Feb15.123656pst."58696"@synergy1.parc.xerox.com>
Message-ID: <d6f07f1e-f13a-4334-aef8-eb19ed9b8c03@i29g2000prf.googlegroups.com>

On 15 Feb, 21:36, Bill Janssen <jans... at parc.com> wrote:
> I think we should just replace the current "loop" with this (and add
> the "schedule" function). ?Then other folks won't have to figure out
> how the module works and write their own loop. ?I'll be happy to update
> the documentation to document it.
>
> Bill

I'm -1.
This does not permit to reset, cancel or "re-schedule" the scheduled
tasks.
Something like a connection timeout after a certain time of client's
inactivity would not be possible to implement.

From jjb5 at cornell.edu  Fri Feb 15 22:05:18 2008
From: jjb5 at cornell.edu (Joel Bender)
Date: Fri, 15 Feb 2008 16:05:18 -0500
Subject: [Python-Dev] Py3k and asyncore/asynchat
In-Reply-To: <08Feb15.123656pst."58696"@synergy1.parc.xerox.com>
References: <ddd408be0802131228p600ffaceq4a22f6ef98a8be3@mail.gmail.com>	<95d2b6e8-2524-4464-b5a9-c4d56e5f4318@t16g2000hsc.googlegroups.com>	<e04bdf310802140712v4b2e1a82q897a5dc3abd84a1@mail.gmail.com>	<fcabf485-a74c-405d-991b-71a27986144a@i12g2000prf.googlegroups.com>	<d0e5b945-1b88-4a72-8f1e-47dfba50eff1@s12g2000prg.googlegroups.com>	<e6511dbf0802141824nf396efbte722a49f877cfc16@mail.gmail.com>	<20080215142414.GA6805@amk-desktop.matrixgroup.net>	<20080215142832.GC13291@snowy.squish.net>	<ac031ea8-ad55-4608-b900-904286a19411@s37g2000prg.googlegroups.com>	<e6511dbf0802151211p4fa9bc7ah97b49eb3c1d26889@mail.gmail.com>
	<08Feb15.123656pst."58696"@synergy1.parc.xerox.com>
Message-ID: <47B5FE8E.2060901@cornell.edu>

Bill Janssen wrote:
> I think we should just replace the current "loop" with this (and add
> the "schedule" function).  Then other folks won't have to figure out
> how the module works and write their own loop.

Having beaten my way down this road of broken glass, I would like args 
and kwargs if you are adding this:

     def schedule(delta, fn, *args, **kwargs):
         heap.heappush(tasks, (time.time()+delta, (fn, args, kwargs)))

         ...

         callme[0](*callme[1], **callme[2])


Joel

From eric at trueblade.com  Fri Feb 15 00:35:08 2008
From: eric at trueblade.com (Eric Smith)
Date: Thu, 14 Feb 2008 18:35:08 -0500
Subject: [Python-Dev] Calling a builtin from C code;
 PEP 3101 format() builtin
In-Reply-To: <47B4C83C.1030708@canterbury.ac.nz>
References: <47B43103.7050209@trueblade.com>
	<47B4C83C.1030708@canterbury.ac.nz>
Message-ID: <47B4D02C.10207@trueblade.com>

Greg Ewing wrote:
> Eric Smith wrote:
> 
>> 1: exposing builtin_format(), probably giving it another name 
>> (PyObject_Format?) and moving it somewhere other than bltinmodule.c.
> 
> PyObject_Format sounds more like an API for invoking the
> __format__ lookup mechanism. Maybe something like
> PyObject_DefaultFormat would be better.

I see it like:
PyObject_Str(o) gives you str(o),
PyObject_Unicode(o) gives you unicode(o)
so
PyObject_Format(o, spec) give you format(o, spec).

All 3 of them do things with __special__ methods.

Eric.

From eric+python-dev at trueblade.com  Sat Feb 16 01:18:37 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Fri, 15 Feb 2008 19:18:37 -0500
Subject: [Python-Dev] Calling a builtin from C code;
 PEP 3101 format() builtin
In-Reply-To: <47B4D02C.10207@trueblade.com>
References: <47B43103.7050209@trueblade.com>	<47B4C83C.1030708@canterbury.ac.nz>
	<47B4D02C.10207@trueblade.com>
Message-ID: <47B62BDD.9080805@trueblade.com>

Eric Smith wrote:
> Greg Ewing wrote:
>> Eric Smith wrote:
>>
>>> 1: exposing builtin_format(), probably giving it another name 
>>> (PyObject_Format?) and moving it somewhere other than bltinmodule.c.
>> PyObject_Format sounds more like an API for invoking the
>> __format__ lookup mechanism. Maybe something like
>> PyObject_DefaultFormat would be better.
> 
> I see it like:
> PyObject_Str(o) gives you str(o),
> PyObject_Unicode(o) gives you unicode(o)
> so
> PyObject_Format(o, spec) give you format(o, spec).
> 
> All 3 of them do things with __special__ methods.

Having heard no objections, I'm going to call this PyObject_Format and 
put it in abstract.c.

Eric.

From python at rcn.com  Sat Feb 16 02:30:47 2008
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 15 Feb 2008 20:30:47 -0500 (EST)
Subject: [Python-Dev] dir() and __all__
Message-ID: <20080215203047.AHA87475@ms19.lnh.mail.rcn.net>

Should dir(module) use __all__ when defined?

>>> dir(Queue)
['Empty', 'Full', 'LifoQueue', 'PriorityQueue', 'Queue', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '_time', 'deque', 'heapq']

>>> Queue.__all__
['Empty', 'Full', 'Queue', 'PriorityQueue', 'LifoQueue']

I like the second one better.


Raymond

From guido at python.org  Sat Feb 16 02:48:47 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 15 Feb 2008 17:48:47 -0800
Subject: [Python-Dev] dir() and __all__
In-Reply-To: <20080215203047.AHA87475@ms19.lnh.mail.rcn.net>
References: <20080215203047.AHA87475@ms19.lnh.mail.rcn.net>
Message-ID: <ca471dc20802151748u7ffb2f21iaf77eb48056a8b13@mail.gmail.com>

It's not consistent with what dir() of a class or instance does though.

-1.

On Fri, Feb 15, 2008 at 5:30 PM, Raymond Hettinger <python at rcn.com> wrote:
> Should dir(module) use __all__ when defined?
>
>  >>> dir(Queue)
>  ['Empty', 'Full', 'LifoQueue', 'PriorityQueue', 'Queue', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '_time', 'deque', 'heapq']
>
>  >>> Queue.__all__
>  ['Empty', 'Full', 'Queue', 'PriorityQueue', 'LifoQueue']
>
>  I like the second one better.
>
>
>  Raymond
>  _______________________________________________
>  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 skip at pobox.com  Sat Feb 16 03:15:54 2008
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 15 Feb 2008 20:15:54 -0600
Subject: [Python-Dev] dir() and __all__
In-Reply-To: <ca471dc20802151748u7ffb2f21iaf77eb48056a8b13@mail.gmail.com>
References: <20080215203047.AHA87475@ms19.lnh.mail.rcn.net>
	<ca471dc20802151748u7ffb2f21iaf77eb48056a8b13@mail.gmail.com>
Message-ID: <18358.18266.680212.159276@montanaro-dyndns-org.local>


    Guido> It's not consistent with what dir() of a class or instance does
    Guido> though.  -1.

Agreed.  The only official use I'm aware of is to restrict what is imported
when you execute

    from mod import *

    Raymond> >>> Queue.__all__
    Raymond> ['Empty', 'Full', 'Queue', 'PriorityQueue', 'LifoQueue']

    >> I like the second one better.

How would you easily ask an object for all its attributes?

Skip

From steve at holdenweb.com  Sat Feb 16 03:34:24 2008
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 15 Feb 2008 21:34:24 -0500
Subject: [Python-Dev] dir() and __all__
In-Reply-To: <ca471dc20802151748u7ffb2f21iaf77eb48056a8b13@mail.gmail.com>
References: <20080215203047.AHA87475@ms19.lnh.mail.rcn.net>
	<ca471dc20802151748u7ffb2f21iaf77eb48056a8b13@mail.gmail.com>
Message-ID: <47B64BB0.20900@holdenweb.com>

Maybe classes should have __all__ too, then the people who complain 
about not being able to declare private class attributes could be 
pointed at that.

regards
  Steve

Guido van Rossum wrote:
> It's not consistent with what dir() of a class or instance does though.
> 
> -1.
> 
> On Fri, Feb 15, 2008 at 5:30 PM, Raymond Hettinger <python at rcn.com> wrote:
>> Should dir(module) use __all__ when defined?
>>
>>  >>> dir(Queue)
>>  ['Empty', 'Full', 'LifoQueue', 'PriorityQueue', 'Queue', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '_time', 'deque', 'heapq']
>>
>>  >>> Queue.__all__
>>  ['Empty', 'Full', 'Queue', 'PriorityQueue', 'LifoQueue']
>>
>>  I like the second one better.
>>
>>
>>  Raymond
>>  _______________________________________________
>>  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
>>
> 
> 
> 


-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/

From steve at holdenweb.com  Sat Feb 16 03:34:24 2008
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 15 Feb 2008 21:34:24 -0500
Subject: [Python-Dev] dir() and __all__
In-Reply-To: <ca471dc20802151748u7ffb2f21iaf77eb48056a8b13@mail.gmail.com>
References: <20080215203047.AHA87475@ms19.lnh.mail.rcn.net>
	<ca471dc20802151748u7ffb2f21iaf77eb48056a8b13@mail.gmail.com>
Message-ID: <47B64BB0.20900@holdenweb.com>

Maybe classes should have __all__ too, then the people who complain 
about not being able to declare private class attributes could be 
pointed at that.

regards
  Steve

Guido van Rossum wrote:
> It's not consistent with what dir() of a class or instance does though.
> 
> -1.
> 
> On Fri, Feb 15, 2008 at 5:30 PM, Raymond Hettinger <python at rcn.com> wrote:
>> Should dir(module) use __all__ when defined?
>>
>>  >>> dir(Queue)
>>  ['Empty', 'Full', 'LifoQueue', 'PriorityQueue', 'Queue', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '_time', 'deque', 'heapq']
>>
>>  >>> Queue.__all__
>>  ['Empty', 'Full', 'Queue', 'PriorityQueue', 'LifoQueue']
>>
>>  I like the second one better.
>>
>>
>>  Raymond
>>  _______________________________________________
>>  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
>>
> 
> 
> 


-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From python at rcn.com  Sat Feb 16 04:18:59 2008
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 15 Feb 2008 19:18:59 -0800
Subject: [Python-Dev] dir() and __all__
References: <20080215203047.AHA87475@ms19.lnh.mail.rcn.net>
	<ca471dc20802151748u7ffb2f21iaf77eb48056a8b13@mail.gmail.com>
Message-ID: <001e01c8704a$ad54b640$6800a8c0@RaymondLaptop1>

[Raymond]
>> Should dir(module) use __all__ when defined?

[GvR]
> It's not consistent with what dir() of a class or instance does though.
> 
> -1.

Perhaps there is another solution. Have dir() exclude objects
which are modules.  For example, dir(logging) would exclude
sys, os, types, time, string, cStringIO, and traceback.


Raymond

From dickinsm at gmail.com  Sat Feb 16 04:53:14 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Fri, 15 Feb 2008 22:53:14 -0500
Subject: [Python-Dev] trunk-math
Message-ID: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>

Dear all,
I'd like to draw your attention to some of the work that's been going on in
the trunk-math branch.  Christian Heimes and I have been working on various
aspects of Python mathematics, and we're hoping to get at least some of this
work into Python 2.6/3.0.  Most of the changes are completed or nearly
complete, and 2.6/3.0 isn't very far away, so it seems like a good time to
try to get some feedback from python-dev.

Here's an overview of the changes (overview originally written by Christian,
edited and augmented by me.  I hope Christian will step in and correct me if
I misrepresent him or his work here.)  Many of the changes were motivated by
Christian's work (already in the trunk) in making infinities and nans more
accessible and portable for Python users. (See issue #1640.)

* Structural reorganization: there are new files Include/pymath.h and
Objects/pymath.c with math-related definitions and replacement functions for
platforms without copysign, log1p, hypot and inverse hyperbolic functions.

* New math functions: inverse hyperbolic functions (acosh, asinh, atanh).

* New float methods: is_finite, is_inf, is_integer and is_nan.

* New cmath functions: phase, polar and rect, isinf and isnan.

* New complex method: is_finite.

* Work on math and cmath functions to make them handle special values
(infinities and nans) and floating-point exceptions according to the C99
standard.   The general philosophy follows the ideas put forth by Tim Peters
and co. many moons ago. and repeated in the issue #1640 thread more
recently:  where the C99 standard (or IEEE 754) specifies raising 'invalid'
or 'divide-by-zero' Python should raise a ValueError.  Where the C99
standard specifies raising 'overflow' Python should raise OverflowError.
 'underflow' and 'inexact' flags are ignored.  From a user's perspective,
this means that infinities and nans are never produced by math or cmath
operations on finite values (but see below).  sqrt(-1) will always raise
ValueError, instead of returning a NaN.  See issue #711019 and the resulting
warning at the bottom of the math module documentation.   Although
complex_abs doesn't live in cmathmodule.c, it was also fixed up this way.

* The cmath module has been rescued:  it's no longer numerically unsound
(see issue #1381).  For the majority of functions (sin, cos, tan, sinh,
cosh, tanh, asin, acos, atan, asinh, acosh, atanh, exp, sqrt) the real and
imaginary parts of the results are always within a few ulps of the true
values.  (In extensive but non-exhaustive testing I haven't found errors of
more than 5 ulps in either the real or imaginary parts for these functions.)
 For log and log10 the errors can be larger when the argument has absolute
value close to 1; this seems pretty much unavoidable without using
multiple-precision arithmetic.  pow and two-argument log are less accurate;
again, this is essentially unavoidable without adding hundreds of extra
lines of code.

* Many more tests. In addition to a handful of extra test_* methods in
test_math and test_cmath, there are over 1700 testcases (in a badly-named
file Lib/test/cmath.ctest) for the cmath and math functions, with a testcase
format inspired in no small part by the decimal .decTest file format.  Most
of the testcase values were produced independently of Python using MPFR and
interval arithmetic (C code available on request);  some were created by
hand.

* There's a per-thread state for division operator. In IEEE 754 mode 1./0.
and 1.%0. return INF and 0./0. NAN. The contextlib has a new
context "ieee754" and the math lib set_ieee754/get_ieee754 (XXX better place
for the functions?)

Some notes:

* We've used the C99 standard (especially Annex F and Annex G) as a
reference for deciding what the math and cmath functions should do, wherever
possible. It seems to make sense to choose to follow some standard,
essentially so that all the hard decisions have been thought through
thoroughly by a group of experts.  Two obvious choices are the C99 standard
and IEEE 754(r); for almost all math issues the two say essentially the same
thing.  C99 has the advantage that it includes specifications for complex
math, while IEEE 754(r) does not.  (Actually, I've been using draft version
N1124 of the C99 standard, not the standard itself, since I'm too cheap to
pay up for a genuine version. Google 'N1124' for a copy.)

* I'm offering to act as long-term maintainer for the cmath module, if
that's useful.

* The most interesting and exciting feature, by far (in my opinion) is the
last one.  By way of introduction, here's a snippet from Tim Peters, in a
comp.lang.python posting (
http://mail.python.org/pipermail/python-list/2005-July/330745.html),
answering a question from Michael Hudson about 1e300*1e300 and inf/inf.

"I believe Python should raise exceptions in these cases by default,
because, as above, they correspond to the overflow and invalid-operation
signals respectively, and Python should raise exceptions on the overflow,
invalid-operation, and divide-by-0 signals by default. But I also believe
Python _dare not_ do so unless it also supplies sane machinery for disabling
traps on specific signals (along the lines of the relevant standards here).
Many serious numeric programmers would be livid, and justifiably so, if they
couldn't get non-stop mode back. The most likely x-platfrom accident so far
is that they've been getting non-stop mode in Python since its beginning."

Christian has found a simple, elegant and practical way to make it possible
for Python to raise these exceptions by default, while also allowing serious
numeric users access to non-stop mode---i.e., a mode that generates inf from
1/0 instead of raising a Python exception.  (I had a much more elaborate
plan in mind, involving a thread-local context similar to Decimal's, with
control over individual traps and flags.  Christian's solution is far more
practical.)  The idea is that any arithmetic operating under a "with
ieee754:" acts like arithmetic on an IEEE 754 platform with no traps
enabled:  invalid operations like sqrt(-1) produce a nan, division by zero
produces an infinity, etc.  No Python exceptions related to floating-point
are raised.

See the thread started by Neal Becker at
http://mail.python.org/pipermail/python-list/2008-February/477064.html,
entitled "Turn off ZeroDivisionError?" for a recent discussion of these
issues.

I fear that the per-thread state change seems like something where a PEP
might be necessary; it's also not clear right now that Christian and I have
exactly the same goals here (discussion is ongoing).  But I hope that the
rest of the changes are uncontroversial enough to merit consideration for
possible inclusion in 2.6/3.0.

Thoughts?

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080215/1cc88a88/attachment-0001.htm 

From guido at python.org  Sat Feb 16 05:20:09 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 15 Feb 2008 20:20:09 -0800
Subject: [Python-Dev] dir() and __all__
In-Reply-To: <001e01c8704a$ad54b640$6800a8c0@RaymondLaptop1>
References: <20080215203047.AHA87475@ms19.lnh.mail.rcn.net>
	<ca471dc20802151748u7ffb2f21iaf77eb48056a8b13@mail.gmail.com>
	<001e01c8704a$ad54b640$6800a8c0@RaymondLaptop1>
Message-ID: <ca471dc20802152020w8fe6ddfyfbbb577a03460915@mail.gmail.com>

I'm not sure which use case you're after here, but I doubt it's what
dir() was designed to do. dir() is meant to attempt to give you all
attributes for which getattr() will succeed, barring dynamic overrides
of __getattr[ibute]__.

On Fri, Feb 15, 2008 at 7:18 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Raymond]
>
> >> Should dir(module) use __all__ when defined?
>
>  [GvR]
>
> > It's not consistent with what dir() of a class or instance does though.
>  >
>  > -1.
>
>  Perhaps there is another solution. Have dir() exclude objects
>  which are modules.  For example, dir(logging) would exclude
>  sys, os, types, time, string, cStringIO, and traceback.
>
>
>  Raymond
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From steve at holdenweb.com  Sat Feb 16 05:39:28 2008
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 15 Feb 2008 23:39:28 -0500
Subject: [Python-Dev] trunk-math
In-Reply-To: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
References: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
Message-ID: <47B66900.4040004@holdenweb.com>

Mark Dickinson wrote:
> Dear all,
> 
> I'd like to draw your attention to some of the work that's been going on 
> in the trunk-math branch.  Christian Heimes and I have been working on 
> various aspects of Python mathematics, and we're hoping to get at least 
> some of this work into Python 2.6/3.0.  Most of the changes are 
> completed or nearly complete, and 2.6/3.0 isn't very far away, so it 
> seems like a good time to try to get some feedback from python-dev.
> 
> Here's an overview of the changes (overview originally written by 
> Christian, edited and augmented by me.  I hope Christian will step in 
> and correct me if I misrepresent him or his work here.)  Many of the 
> changes were motivated by Christian's work (already in the trunk) in 
> making infinities and nans more accessible and portable for Python 
> users. (See issue #1640.)
> 
> * Structural reorganization: there are new files Include/pymath.h and 
> Objects/pymath.c with math-related definitions and replacement functions 
> for platforms without copysign, log1p, hypot and inverse hyperbolic 
> functions.
> 
> * New math functions: inverse hyperbolic functions (acosh, asinh, atanh).
> 
> * New float methods: is_finite, is_inf, is_integer and is_nan.
> 
> * New cmath functions: phase, polar and rect, isinf and isnan.
> 
> * New complex method: is_finite.
> 
> * Work on math and cmath functions to make them handle special values 
> (infinities and nans) and floating-point exceptions according to the C99 
> standard.   The general philosophy follows the ideas put forth by Tim 
> Peters and co. many moons ago. and repeated in the issue #1640 thread 
> more recently:  where the C99 standard (or IEEE 754) specifies raising 
> 'invalid' or 'divide-by-zero' Python should raise a ValueError.  Where 
> the C99 standard specifies raising 'overflow' Python should raise 
> OverflowError.  'underflow' and 'inexact' flags are ignored.  From a 
> user's perspective, this means that infinities and nans are never 
> produced by math or cmath operations on finite values (but see below). 
>  sqrt(-1) will always raise ValueError, instead of returning a NaN.  See 
> issue #711019 and the resulting warning at the bottom of the math module 
> documentation.   Although complex_abs doesn't live in cmathmodule.c, it 
> was also fixed up this way.
> 
> * The cmath module has been rescued:  it's no longer numerically unsound 
> (see issue #1381).  For the majority of functions (sin, cos, tan, sinh, 
> cosh, tanh, asin, acos, atan, asinh, acosh, atanh, exp, sqrt) the real 
> and imaginary parts of the results are always within a few ulps of the 
> true values.  (In extensive but non-exhaustive testing I haven't found 
> errors of more than 5 ulps in either the real or imaginary parts for 
> these functions.)  For log and log10 the errors can be larger when the 
> argument has absolute value close to 1; this seems pretty much 
> unavoidable without using multiple-precision arithmetic.  pow and 
> two-argument log are less accurate; again, this is essentially 
> unavoidable without adding hundreds of extra lines of code.
> 
> * Many more tests. In addition to a handful of extra test_* methods in 
> test_math and test_cmath, there are over 1700 testcases (in a 
> badly-named file Lib/test/cmath.ctest) for the cmath and math functions, 
> with a testcase format inspired in no small part by the decimal .decTest 
> file format.  Most of the testcase values were produced independently of 
> Python using MPFR and interval arithmetic (C code available on request); 
>  some were created by hand.
> 
> * There's a per-thread state for division operator. In IEEE 754 mode 
> 1./0. and 1.%0. return INF and 0./0. NAN. The contextlib has a new 
> context "ieee754" and the math lib set_ieee754/get_ieee754 (XXX better 
> place for the functions?)
> 
> Some notes:
> 
> * We've used the C99 standard (especially Annex F and Annex G) as a 
> reference for deciding what the math and cmath functions should do, 
> wherever possible. It seems to make sense to choose to follow some 
> standard, essentially so that all the hard decisions have been thought 
> through thoroughly by a group of experts.  Two obvious choices are the 
> C99 standard and IEEE 754(r); for almost all math issues the two say 
> essentially the same thing.  C99 has the advantage that it includes 
> specifications for complex math, while IEEE 754(r) does not.  (Actually, 
> I've been using draft version N1124 of the C99 standard, not the 
> standard itself, since I'm too cheap to pay up for a genuine version. 
> Google 'N1124' for a copy.)
> 
> * I'm offering to act as long-term maintainer for the cmath module, if 
> that's useful.
> 
> * The most interesting and exciting feature, by far (in my opinion) is 
> the last one.  By way of introduction, here's a snippet from Tim Peters, 
> in a comp.lang.python posting 
> (http://mail.python.org/pipermail/python-list/2005-July/330745.html), 
> answering a question from Michael Hudson about 1e300*1e300 and inf/inf.
> 
> "I believe Python should raise exceptions in these cases by default, 
> because, as above, they correspond to the overflow and invalid-operation 
> signals respectively, and Python should raise exceptions on the 
> overflow, invalid-operation, and divide-by-0 signals by default. But I 
> also believe Python _dare not_ do so unless it also supplies sane 
> machinery for disabling traps on specific signals (along the lines of 
> the relevant standards here). Many serious numeric programmers would be 
> livid, and justifiably so, if they couldn't get non-stop mode back. The 
> most likely x-platfrom accident so far is that they've been getting 
> non-stop mode in Python since its beginning."
> 
> Christian has found a simple, elegant and practical way to make it 
> possible for Python to raise these exceptions by default, while also 
> allowing serious numeric users access to non-stop mode---i.e., a mode 
> that generates inf from 1/0 instead of raising a Python exception.  (I 
> had a much more elaborate plan in mind, involving a thread-local context 
> similar to Decimal's, with control over individual traps and flags. 
>  Christian's solution is far more practical.)  The idea is that any 
> arithmetic operating under a "with ieee754:" acts like arithmetic on an 
> IEEE 754 platform with no traps enabled:  invalid operations like 
> sqrt(-1) produce a nan, division by zero produces an infinity, etc.  No 
> Python exceptions related to floating-point are raised.
> 
> See the thread started by Neal Becker 
> at http://mail.python.org/pipermail/python-list/2008-February/477064.html, 
> entitled "Turn off ZeroDivisionError?" for a recent discussion of these 
> issues.
> 
> I fear that the per-thread state change seems like something where a PEP 
> might be necessary; it's also not clear right now that Christian and I 
> have exactly the same goals here (discussion is ongoing).  But I hope 
> that the rest of the changes are uncontroversial enough to merit 
> consideration for possible inclusion in 2.6/3.0.
> 
> Thoughts?
> 
Only one: if this stunning plethora of improvements is likely to benefit 
by you and Christian having access to published standards I will happily 
champion a PSF-sponsored purchase, and would anticipate little argument.

Plus, thank you both very much for putting the effort in to satisfy 
numerical calculation requirements in an elegant and practical way. The 
immense amount of hard work involved should not go unrecognized.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From dickinsm at gmail.com  Sat Feb 16 05:43:21 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Fri, 15 Feb 2008 23:43:21 -0500
Subject: [Python-Dev] trunk-math
In-Reply-To: <ca471dc20802152032l2b77b6fdnbccdb2f62d74bff3@mail.gmail.com>
References: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
	<ca471dc20802152032l2b77b6fdnbccdb2f62d74bff3@mail.gmail.com>
Message-ID: <5c6f2a5d0802152043lfc43cc9l8f66e17bab0523a5@mail.gmail.com>

Apologies for the bad formatting.  Here's a repost with shorter lines.

Dear all,

I'd like to draw your attention to some of the work that's been going on in
the trunk-math branch.  Christian Heimes and I have been working on various
aspects of Python mathematics, and we're hoping to get at least some of this
work into Python 2.6/3.0.  Most of the changes are completed or nearly
complete, and 2.6/3.0 isn't very far away, so it seems like a good time to
try to get some feedback from python-dev.

Here's an overview of the changes (overview originally written by Christian,
edited and augmented by me.  I hope Christian will step in and correct me if
I misrepresent him or his work here.)  Many of the changes were motivated by
Christian's work (already in the trunk) in making infinities and nans more
accessible and portable for Python users. (See issue #1640.)

* Structural reorganization: there are new files Include/pymath.h and
Objects/pymath.c with math-related definitions and replacement functions for
platforms without copysign, log1p, hypot and inverse hyperbolic functions.

* New math functions: inverse hyperbolic functions (acosh, asinh, atanh).

* New float methods: is_finite, is_inf, is_integer and is_nan.

* New cmath functions: phase, polar and rect, isinf and isnan.

* New complex method: is_finite.

* Work on math and cmath functions to make them handle special values
(infinities and nans) and floating-point exceptions according to the C99
standard.   The general philosophy follows the ideas put forth by Tim Peters
and co. many moons ago. and repeated in the issue #1640 thread more
recently:  where the C99 standard (or IEEE 754) specifies raising 'invalid'
or 'divide-by-zero' Python should raise a ValueError.  Where the C99
standard specifies raising 'overflow' Python should raise OverflowError.
'underflow' and 'inexact' flags are ignored.  From a user's perspective,
this means that infinities and nans are never produced by math or cmath
operations on finite values (but see below).  sqrt(-1) will always raise
ValueError, instead of returning a NaN.  See issue #711019 and the resulting
warning at the bottom of the math module documentation.   Although
complex_abs doesn't live in cmathmodule.c, it was also fixed up this way.

* The cmath module has been rescued:  it's no longer numerically unsound
(see issue #1381).  For the majority of functions (sin, cos, tan, sinh,
cosh, tanh, asin, acos, atan, asinh, acosh, atanh, exp, sqrt) the real and
imaginary parts of the results are always within a few ulps of the true
values.  (In extensive but non-exhaustive testing I haven't found errors of
more than 5 ulps in either the real or imaginary parts for these functions.)
For log and log10 the errors can be larger when the argument has absolute
value close to 1; this seems pretty much unavoidable without using
multiple-precision arithmetic.  pow and two-argument log are less accurate;
again, this is essentially unavoidable without adding hundreds of extra
lines of code.

* Many more tests. In addition to a handful of extra test_* methods in
test_math and test_cmath, there are over 1700 testcases (in a badly-named
file Lib/test/cmath.ctest) for the cmath and math functions, with a testcase
format inspired in no small part by the decimal .decTest file format.  Most
of the testcase values were produced independently of Python using MPFR and
interval arithmetic (C code available on request);  some were created by
hand.

* There's a per-thread state for division operator. In IEEE 754 mode 1./0.
and 1.%0. return INF and 0./0. NAN. The contextlib has a new context
"ieee754" and the math lib set_ieee754/get_ieee754 (XXX better place for the
functions?)

Some notes:

* We've used the C99 standard (especially Annex F and Annex G) as a
reference for deciding what the math and cmath functions should do, wherever
possible. It seems to make sense to choose to follow some standard,
essentially so that all the hard decisions have been thought through
thoroughly by a group of experts.  Two obvious choices are the C99 standard
and IEEE 754(r); for almost all math issues the two say essentially the same
thing.  C99 has the advantage that it includes specifications for complex
math, while IEEE 754(r) does not.  (Actually, I've been using draft version
N1124 of the C99 standard, not the standard itself, since I'm too cheap to
pay up for a genuine version. Google 'N1124' for a copy.)

* I'm offering to act as long-term maintainer for the cmath module, if
that's useful.

* The most interesting and exciting feature, by far (in my opinion) is the
last one.  By way of introduction, here's a snippet from Tim Peters, in a
comp.lang.python posting
(http://mail.python.org/pipermail/python-list/2005-July/330745.html),
answering a question from Michael Hudson about 1e300*1e300 and inf/inf.

"I believe Python should raise exceptions in these cases by default,
because, as above, they correspond to the overflow and invalid-operation
signals respectively, and Python should raise exceptions on the overflow,
invalid-operation, and divide-by-0 signals by default. But I also believe
Python _dare not_ do so unless it also supplies sane machinery for disabling
traps on specific signals (along the lines of the relevant standards here).
Many serious numeric programmers would be livid, and justifiably so, if they
couldn't get non-stop mode back. The most likely x-platfrom accident so far
is that they've been getting non-stop mode in Python since its beginning."

Christian has found a simple, elegant and practical way to make it possible
for Python to raise these exceptions by default, while also allowing serious
numeric users access to non-stop mode---i.e., a mode that generates inf from
1/0 instead of raising a Python exception.  (I had a much more elaborate
plan in mind, involving a thread-local context similar to Decimal's, with
control over individual traps and flags.  Christian's solution is far more
practical.)  The idea is that any arithmetic operating under a "with
ieee754:" acts like arithmetic on an IEEE 754 platform with no traps
enabled:  invalid operations like sqrt(-1) produce a nan, division by zero
produces an infinity, etc.  No Python exceptions related to floating-point
are raised.

See the thread started by Neal Becker
at<http://mail.python.org/pipermail/python-list/2008-February/477064.html>
http://mail.python.org/pipermail/python-list/2008-February/477064.html
entitled "Turn off ZeroDivisionError?" for a recent discussion of these
issues.

I fear that the per-thread state change seems like something where a PEP
might be necessary; it's also not clear right now that Christian and I have
exactly the same goals here (discussion is ongoing).  But I hope that the
rest of the changes are uncontroversial enough to merit consideration for
possible inclusion in 2.6/3.0.

Thoughts?

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080215/f5fafcee/attachment-0001.htm 

From aahz at pythoncraft.com  Sat Feb 16 05:49:18 2008
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 15 Feb 2008 20:49:18 -0800
Subject: [Python-Dev] dir() and __all__
In-Reply-To: <001e01c8704a$ad54b640$6800a8c0@RaymondLaptop1>
References: <20080215203047.AHA87475@ms19.lnh.mail.rcn.net>
	<ca471dc20802151748u7ffb2f21iaf77eb48056a8b13@mail.gmail.com>
	<001e01c8704a$ad54b640$6800a8c0@RaymondLaptop1>
Message-ID: <20080216044918.GB29083@panix.com>

On Fri, Feb 15, 2008, Raymond Hettinger wrote:
>
> [Raymond]
> >> Should dir(module) use __all__ when defined?
> 
> [GvR]
> > It's not consistent with what dir() of a class or instance does though.
> > 
> > -1.
> 
> Perhaps there is another solution. Have dir() exclude objects which
> are modules.  For example, dir(logging) would exclude sys, os, types,
> time, string, cStringIO, and traceback.

-1

I see what you're getting at, but I think this level of introspection
breakage is a Bad Idea.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of     
indirection."  --Butler Lampson

From thomas at python.org  Sat Feb 16 07:39:07 2008
From: thomas at python.org (Thomas Wouters)
Date: Sat, 16 Feb 2008 07:39:07 +0100
Subject: [Python-Dev] dir() and __all__
In-Reply-To: <001e01c8704a$ad54b640$6800a8c0@RaymondLaptop1>
References: <20080215203047.AHA87475@ms19.lnh.mail.rcn.net>
	<ca471dc20802151748u7ffb2f21iaf77eb48056a8b13@mail.gmail.com>
	<001e01c8704a$ad54b640$6800a8c0@RaymondLaptop1>
Message-ID: <9e804ac0802152239t49e7812dh72f7c4370164359@mail.gmail.com>

On Sat, Feb 16, 2008 at 4:18 AM, Raymond Hettinger <python at rcn.com> wrote:

> [Raymond]
> >> Should dir(module) use __all__ when defined?
>
> [GvR]
> > It's not consistent with what dir() of a class or instance does though.
> >
> > -1.
>
> Perhaps there is another solution. Have dir() exclude objects
> which are modules.  For example, dir(logging) would exclude
> sys, os, types, time, string, cStringIO, and traceback.


Don't forget that that would mean dir(os) would no longer show 'path'.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080216/46934e68/attachment.htm 

From ncoghlan at gmail.com  Sat Feb 16 11:18:23 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 16 Feb 2008 20:18:23 +1000
Subject: [Python-Dev] trunk-math
In-Reply-To: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
References: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
Message-ID: <47B6B86F.7070307@gmail.com>

Mark Dickinson wrote:
> * There's a per-thread state for division operator. In IEEE 754 mode 
> 1./0. and 1.%0. return INF and 0./0. NAN. The contextlib has a new 
> context "ieee754" and the math lib set_ieee754/get_ieee754 (XXX better 
> place for the functions?)

I would put the context manager in the math module as well. contextlib 
is intended for generic context related tools (like nested() and 
closing() that don't have a more topical home.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Sat Feb 16 15:33:37 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 17 Feb 2008 00:33:37 +1000
Subject: [Python-Dev] trunk-math
In-Reply-To: <47B6BB2D.7050402@cheimes.de>
References: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
	<47B6B86F.7070307@gmail.com> <47B6BB2D.7050402@cheimes.de>
Message-ID: <47B6F441.4090403@gmail.com>

Christian Heimes wrote:
> Nick Coghlan wrote:
>> I would put the context manager in the math module as well. contextlib
>> is intended for generic context related tools (like nested() and
>> closing() that don't have a more topical home.
> 
> I'll reimplement the ieee754 context manager in C once the feature gets
> accepted. For the experimental branch it was much easier to write it in
> Python.

Sounds like a good plan to me - I was just pointing out that contextlib 
didn't really make sense as a long term home for the functionality.

For what it's worth, I'm +1 on the improvements to math and cmath, but 
keep in mind that I'm not an active user of either module (I use Python 
for coordination tasks rather than number crunching).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Sat Feb 16 15:37:21 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 17 Feb 2008 00:37:21 +1000
Subject: [Python-Dev] Error in PEP3118?
In-Reply-To: <47B0D4FF.9020604@canterbury.ac.nz>
References: <47905DAE.9020802@ctypes.org>
	<fn7p9u$7rh$1@ger.gmane.org>	<fn832p$ebb$1@ger.gmane.org>
	<foq804$1iq$1@ger.gmane.org> <47B0D4FF.9020604@canterbury.ac.nz>
Message-ID: <47B6F521.20505@gmail.com>

Greg Ewing wrote:
> It might help to add a note to the effect that this
> example is meant to illustrate that the descriptor doesn't
> have to exactly match the C description, as long as it
> describes the same memory layout.

This sounds like a good idea to me. I doubt Thomas will be the last 
person to miss the distinction between how the C compiler thinks the 
memory is arranged (just a simple list of values) and how the 
application interprets that memory (a 2-dimensional array).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ndbecker2 at gmail.com  Sat Feb 16 15:58:47 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sat, 16 Feb 2008 09:58:47 -0500
Subject: [Python-Dev] trunk-math
References: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
Message-ID: <fp6tn8$d34$1@ger.gmane.org>

This sounds great!  Thank you for your effort.  Let me know if I can help
(perhaps some testing?)


From eric+python-dev at trueblade.com  Sun Feb 17 00:05:51 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Sat, 16 Feb 2008 18:05:51 -0500
Subject: [Python-Dev] Backporting PEP 3101 to 2.6
In-Reply-To: <47878D98.1020601@trueblade.com>
References: <47861E4A.4020006@trueblade.com>
	<47865CA6.2070400@trueblade.com>	<ca471dc20801101008w44be148csfe98fbd0f36b439a@mail.gmail.com>	<47878559.4090401@gmail.com>
	<47878D98.1020601@trueblade.com>
Message-ID: <47B76C4F.4030709@trueblade.com>

Eric Smith wrote:
>> Guido van Rossum wrote:
>>> For data types whose output uses only ASCII, would it be acceptable if
>>> they always returned an 8-bit string and left it up to the caller to
>>> convert it to Unicode? This would apply to all numeric types. (The
>>> date/time types have a strftime() style API which means the user must
>>> be able to specifiy Unicode.)

I'm finally getting around to finishing this up.  The approach I've 
taken for int, long, and float, is that they take either unicode or str 
format specifiers, and always return str results.  The builtin format() 
deals with converting str to unicode, if the format specifier was 
originally unicode.  This all works great.  It allows me to easily 
implement both ''.format and u''.format taking int, long, and float 
parameters.

I'm now working on datetime.  The __format__ method is really just a 
wrapper around strftime.  I was assuming (or rather hoping) that 
strftime does the right thing with unicode and str (unicode in = unicode 
out, str in = str out).  But it turns out strftime doesn't accept unicode:

$ ./python
Python 2.6a0 (trunk:60845M, Feb 15 2008, 21:09:57)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import datetime
 >>> datetime.date.today().strftime('%y')
'08'
 >>> datetime.date.today().strftime(u'%y')
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: strftime() argument 1 must be str, not unicode

As part of this task, I'm really not up to the job of changing strftime 
to support both str and unicode inputs.  So I think I'll put all of the 
__format__ code in place to support it if and when strftime supports 
unicode.  In the meantime, it won't be possible for u''.format to work 
with datetime objects.

 >>> 'year: {0:%y}'.format(datetime.date.today())
'year: 08'
 >>> u'year: {0:%y}'.format(datetime.date.today())
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: strftime() argument 1 must be str, not unicode

The bad error message is a result of __format__ passing on unicode to 
strftime.

There are, of course, various ugly ways to work around this involving 
nested format calls.

Maybe I'll extend strftime to unicode for the PyCon sprint.

Eric.


From amauryfa at gmail.com  Sun Feb 17 00:12:42 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Sun, 17 Feb 2008 00:12:42 +0100
Subject: [Python-Dev] Py_CLEAR to avoid crashes
Message-ID: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>

Hello,

I think I found a prolific vein of potential crashes throughout the
python interpreter.
The idea is inspired from the discussion Issue1020188 and is quite
simple: find a Py_DECREF(xxx->yyy), where xxx represents any kind of
Python object, and craft a __del__ method so that the same function is
recursively called with the same object.

I recently submitted corrections for 3 problems found this way. Here
are two more examples of this method:

#====================================
class Special:
    def __del__(self):
        print a.args

class MyException(BaseException):
    def __init__(self):
        global a
        a = self
        BaseException.__init__(self, Special(), 0)
        BaseException.__init__(self, "other", 1)

MyException() # segfault
#====================================
import sys
class Special2(str):
    def __del__(self):
        f.__init__("@temp", "w")

f = file(Special2("@temp"), "w")
f.__init__("@temp", "w")  # segfault
#====================================

Issue1020188 (which is still open btw) deals with member reset to
NULL; but any modification of the pointer is potentially concerned.

And the correction is always the same: use Py_CLEAR, or a similar
construction that detach the value from the structure before
defcref'ing it.

I think it would help a lot of code if we had a safe standard way to
set struct members from C. A macro like the following:
    Py_SETREF(lvalue, newobj)
(whatever its name) would perform the assignment and expand to code
equivalent to:
    PyObject* oldobj = lvalue;
    Py_INCREF(newobj);
    lvalue = newobj;
    Py_DECREF(oldobj);

I am currently searching for all places that could benefit of this,
but I am not sure to find a test case for every potential crash.
Most of the time, it is very unlikely that "normal" python code can
fall in these traps (who calls f.__init__ in a __del__ method?), with
the exception of the one corrected by r60871.

Should we however intensively search and correct all of them?
Is there a clever way to prevent these problems globally, for example
by delaying finalizers "just a little"?

-- 
Amaury Forgeot d'Arc

From ncoghlan at gmail.com  Sun Feb 17 01:09:48 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 17 Feb 2008 10:09:48 +1000
Subject: [Python-Dev] Backporting PEP 3101 to 2.6
In-Reply-To: <47B76C4F.4030709@trueblade.com>
References: <47861E4A.4020006@trueblade.com>	<47865CA6.2070400@trueblade.com>	<ca471dc20801101008w44be148csfe98fbd0f36b439a@mail.gmail.com>	<47878559.4090401@gmail.com>	<47878D98.1020601@trueblade.com>
	<47B76C4F.4030709@trueblade.com>
Message-ID: <47B77B4C.2010703@gmail.com>

Eric Smith wrote:
> The bad error message is a result of __format__ passing on unicode to 
> strftime.
> 
> There are, of course, various ugly ways to work around this involving 
> nested format calls.

I don't know if this fits your definition of "ugly workaround", but what 
if datetime.__format__ did something like:

   def __format__(self, spec):
     encoding = None
     if isinstance(spec, unicode):
         encoding = 'utf-8'
         spec = spec.encode(encoding)
     result = strftime(spec, self)
     if encoding is not None:
         result = result.decode(encoding)
     return result

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From nd at perlig.de  Sun Feb 17 01:41:58 2008
From: nd at perlig.de (=?iso-8859-1?q?Andr=E9_Malo?=)
Date: Sun, 17 Feb 2008 01:41:58 +0100
Subject: [Python-Dev] Backporting PEP 3101 to 2.6
In-Reply-To: <47B77B4C.2010703@gmail.com>
References: <47861E4A.4020006@trueblade.com> <47B76C4F.4030709@trueblade.com>
	<47B77B4C.2010703@gmail.com>
Message-ID: <200802170141.58754@news.perlig.de>

* Nick Coghlan wrote:

> Eric Smith wrote:
> > The bad error message is a result of __format__ passing on unicode to
> > strftime.
> >
> > There are, of course, various ugly ways to work around this involving
> > nested format calls.
>
> I don't know if this fits your definition of "ugly workaround", but what
> if datetime.__format__ did something like:
>
>    def __format__(self, spec):
>      encoding = None
>      if isinstance(spec, unicode):
>          encoding = 'utf-8'
>          spec = spec.encode(encoding)
>      result = strftime(spec, self)
>      if encoding is not None:
>          result = result.decode(encoding)
>      return result

Note that hardcoding utf-8 is a bad guess here as strftime(3) emits locale 
strings, so decoding will easily fail.

I guess, a clean and complete solution (besides re-implementing the whole 
thing) would be to resolve each single format character with strftime, 
decode according to the locale and re-assemble the result string piece by 
piece. Doh!

nd
-- 
> [...] wei? jemand zuf?llig, was der Tag DIV ausgeschrieben bedeutet?
DIVerses. Benannt nach all dem unstrukturierten Zeug, was die Leute da
so reinpacken und dann absolut positionieren ...
                           -- Florian Hartig und Lars Kasper in dciwam

From brett at python.org  Sun Feb 17 01:50:01 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 16 Feb 2008 16:50:01 -0800
Subject: [Python-Dev] Py_CLEAR to avoid crashes
In-Reply-To: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
Message-ID: <bbaeab100802161650t503956dcydf9fe465c4c584a9@mail.gmail.com>

On Feb 16, 2008 3:12 PM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> Hello,
>
> I think I found a prolific vein of potential crashes throughout the
> python interpreter.
> The idea is inspired from the discussion Issue1020188 and is quite
> simple: find a Py_DECREF(xxx->yyy), where xxx represents any kind of
> Python object, and craft a __del__ method so that the same function is
> recursively called with the same object.
>
> I recently submitted corrections for 3 problems found this way. Here
> are two more examples of this method:
>
> #====================================
> class Special:
>     def __del__(self):
>         print a.args
>
> class MyException(BaseException):
>     def __init__(self):
>         global a
>         a = self
>         BaseException.__init__(self, Special(), 0)
>         BaseException.__init__(self, "other", 1)
>
> MyException() # segfault
> #====================================
> import sys
> class Special2(str):
>     def __del__(self):
>         f.__init__("@temp", "w")
>
> f = file(Special2("@temp"), "w")
> f.__init__("@temp", "w")  # segfault
> #====================================
>
> Issue1020188 (which is still open btw) deals with member reset to
> NULL; but any modification of the pointer is potentially concerned.
>
> And the correction is always the same: use Py_CLEAR, or a similar
> construction that detach the value from the structure before
> defcref'ing it.
>
> I think it would help a lot of code if we had a safe standard way to
> set struct members from C. A macro like the following:
>     Py_SETREF(lvalue, newobj)
> (whatever its name) would perform the assignment and expand to code
> equivalent to:
>     PyObject* oldobj = lvalue;
>     Py_INCREF(newobj);
>     lvalue = newobj;
>     Py_DECREF(oldobj);
>
> I am currently searching for all places that could benefit of this,
> but I am not sure to find a test case for every potential crash.
> Most of the time, it is very unlikely that "normal" python code can
> fall in these traps (who calls f.__init__ in a __del__ method?), with
> the exception of the one corrected by r60871.
>

Testing C code like this can be tough. Usually the crasher is used as
the test in hopes that any fix is general enough that if it fails that
same crasher will rear its ugly head again.

> Should we however intensively search and correct all of them?

I think it's fine to.

> Is there a clever way to prevent these problems globally, for example
> by delaying finalizers "just a little"?

Beats me.

-Brett

From eric+python-dev at trueblade.com  Sun Feb 17 03:36:53 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Sat, 16 Feb 2008 21:36:53 -0500
Subject: [Python-Dev] Backporting PEP 3101 to 2.6
In-Reply-To: <200802170141.58754@news.perlig.de>
References: <47861E4A.4020006@trueblade.com>
	<47B76C4F.4030709@trueblade.com>	<47B77B4C.2010703@gmail.com>
	<200802170141.58754@news.perlig.de>
Message-ID: <47B79DC5.9020507@trueblade.com>

Andr? Malo wrote:

> I guess, a clean and complete solution (besides re-implementing the whole 
> thing) would be to resolve each single format character with strftime, 
> decode according to the locale and re-assemble the result string piece by 
> piece. Doh!

That's along the lines of what I was thinking.  strftime already does 
some of this to support %[zZ].

But now that I look at time.strftime in py3k, it's converting the entire 
unicode string to a char string with PyUnicode_AsString, then converting 
back with PyUnicode_Decode.


From ncoghlan at gmail.com  Sun Feb 17 08:02:42 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 17 Feb 2008 17:02:42 +1000
Subject: [Python-Dev] Py_CLEAR to avoid crashes
In-Reply-To: <bbaeab100802161650t503956dcydf9fe465c4c584a9@mail.gmail.com>
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
	<bbaeab100802161650t503956dcydf9fe465c4c584a9@mail.gmail.com>
Message-ID: <47B7DC12.7050302@gmail.com>

Brett Cannon wrote:
> On Feb 16, 2008 3:12 PM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
>> Is there a clever way to prevent these problems globally, for example
>> by delaying finalizers "just a little"?
> 
> Beats me.

Finalizers can be delayed 'just a little' with a macro called Py_CLEAR ;)

(in other words, what Amaury is doing already is the best solution I am 
aware of)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From nd at perlig.de  Sun Feb 17 10:26:21 2008
From: nd at perlig.de (=?iso-8859-1?q?Andr=E9_Malo?=)
Date: Sun, 17 Feb 2008 10:26:21 +0100
Subject: [Python-Dev] Backporting PEP 3101 to 2.6
In-Reply-To: <47B79DC5.9020507@trueblade.com>
References: <47861E4A.4020006@trueblade.com>
	<200802170141.58754@news.perlig.de>
	<47B79DC5.9020507@trueblade.com>
Message-ID: <200802171026.22218@news.perlig.de>

* Eric Smith wrote:

> Andr? Malo wrote:
> > I guess, a clean and complete solution (besides re-implementing the
> > whole thing) would be to resolve each single format character with
> > strftime, decode according to the locale and re-assemble the result
> > string piece by piece. Doh!
>
> That's along the lines of what I was thinking.  strftime already does
> some of this to support %[zZ].
>
> But now that I look at time.strftime in py3k, it's converting the entire
> unicode string to a char string with PyUnicode_AsString, then converting
> back with PyUnicode_Decode.

Looks wrong to me, too... :-)

nd
-- 
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~  # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord(  #             Andr? Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see;  #  http://www.perlig.de/ ;

From lists at cheimes.de  Sun Feb 17 17:57:51 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 17 Feb 2008 17:57:51 +0100
Subject: [Python-Dev] Use Python 3.0 syntax for except and raise?
Message-ID: <fp9p2p$ivb$1@ger.gmane.org>

Good evening everybody!

I like to run the 2to3 tool with raise and except fixers over the 2.6
sources. The raise fixer changes "raise Exception, msg" to "raise
Exception(msg)" and the except fixer replaces "except Exception, err" by
"except Exception as err". In my humble opinion the Python stdlib should
give proper examples how write good code.

During the migration period from the 2.x series to 3.x we have two
obvious ways to write code. Let's stick to the new and preferred way.

Oh and please use the new syntax for patches, too. It makes my job with
svnmerge a little bit easier.

Thanks!

Christian


From dickinsm at gmail.com  Sun Feb 17 18:46:07 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sun, 17 Feb 2008 12:46:07 -0500
Subject: [Python-Dev] trunk-math
In-Reply-To: <fp6tn8$d34$1@ger.gmane.org>
References: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
	<fp6tn8$d34$1@ger.gmane.org>
Message-ID: <5c6f2a5d0802170946r7d047049q7923e1535f622a0@mail.gmail.com>

An update:  after some discussion, we're planning a PEP for the "with
ieee754" and related ideas, perhaps aimed at Python 3.1;  there are lots of
difficult decisions to be made, and plenty that would benefit from community
feedback.  In the meantime, we'll get the rest of the fixes/additions tidied
up in trunk-math, and hope for their inclusion in 2.6/3.0.
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080217/1f6cc820/attachment.htm 

From jyasskin at gmail.com  Sun Feb 17 18:46:55 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Sun, 17 Feb 2008 09:46:55 -0800
Subject: [Python-Dev] Use Python 3.0 syntax for except and raise?
In-Reply-To: <fp9p2p$ivb$1@ger.gmane.org>
References: <fp9p2p$ivb$1@ger.gmane.org>
Message-ID: <5d44f72f0802170946t21513cd8n83e869cfd07f344b@mail.gmail.com>

Sounds good to me. Along those lines, shall we work on fixing warnings
that -3 raises in the regression test suite?

On Feb 17, 2008 8:57 AM, Christian Heimes <lists at cheimes.de> wrote:
> Good evening everybody!
>
> I like to run the 2to3 tool with raise and except fixers over the 2.6
> sources. The raise fixer changes "raise Exception, msg" to "raise
> Exception(msg)" and the except fixer replaces "except Exception, err" by
> "except Exception as err". In my humble opinion the Python stdlib should
> give proper examples how write good code.
>
> During the migration period from the 2.x series to 3.x we have two
> obvious ways to write code. Let's stick to the new and preferred way.
>
> Oh and please use the new syntax for patches, too. It makes my job with
> svnmerge a little bit easier.
>
> Thanks!
>
> Christian
>
> _______________________________________________
> 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/jyasskin%40gmail.com
>



-- 
Namast?,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

From dickinsm at gmail.com  Sun Feb 17 18:48:25 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sun, 17 Feb 2008 12:48:25 -0500
Subject: [Python-Dev] trunk-math
In-Reply-To: <5c6f2a5d0802170946r7d047049q7923e1535f622a0@mail.gmail.com>
References: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
	<fp6tn8$d34$1@ger.gmane.org>
	<5c6f2a5d0802170946r7d047049q7923e1535f622a0@mail.gmail.com>
Message-ID: <5c6f2a5d0802170948m1f2bbcb0k1dd13d01213fc8e2@mail.gmail.com>

Aargh.  Extra long lines again.  Here's a repost.

An update:  after some discussion, we're planning a PEP for the "with
ieee754"
and related ideas, perhaps aimed at Python 3.1;  there are lots of difficult
decisions to be made, and plenty that would benefit from community feedback.

In the meantime, we'll get the rest of the fixes/additions tidied up in
trunk-math,
and hope for their inclusion in 2.6/3.0.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080217/f042ada7/attachment.htm 

From jyasskin at gmail.com  Sun Feb 17 19:14:29 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Sun, 17 Feb 2008 10:14:29 -0800
Subject: [Python-Dev] Py_CLEAR to avoid crashes
In-Reply-To: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
Message-ID: <5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>

On Feb 16, 2008 3:12 PM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> Should we however intensively search and correct all of them?
> Is there a clever way to prevent these problems globally, for example
> by delaying finalizers "just a little"?

A simple way to do this would be to push objects whose refcounts had
reached 0 onto a list instead of finalizing them immediately, and have
PyEval_EvalFrameEx periodically swap in a new to-delete list and
delete the objects on the old one. A linked list would cost an extra
pointer in PyObject_HEAD, but a growable array would only cost
allocations, which would be amortized over the allocations of the
objects you're deleting, so that's probably the way to go. A
fixed-size queue that just delayed finalization by a constant number
of objects would usually work without any allocations, but there would
sometimes be single finalizers that recursively freed too many other
objects, which would defeat the delay.

Jeffrey

From g.brandl at gmx.net  Sun Feb 17 19:17:19 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 17 Feb 2008 19:17:19 +0100
Subject: [Python-Dev] Use Python 3.0 syntax for except and raise?
In-Reply-To: <fp9p2p$ivb$1@ger.gmane.org>
References: <fp9p2p$ivb$1@ger.gmane.org>
Message-ID: <fp9tn5$1ns$1@ger.gmane.org>

Christian Heimes schrieb:
> Good evening everybody!
> 
> I like to run the 2to3 tool with raise and except fixers over the 2.6
> sources. The raise fixer changes "raise Exception, msg" to "raise
> Exception(msg)" and the except fixer replaces "except Exception, err" by
> "except Exception as err". In my humble opinion the Python stdlib should
> give proper examples how write good code.
> 
> During the migration period from the 2.x series to 3.x we have two
> obvious ways to write code. Let's stick to the new and preferred way.
> 
> Oh and please use the new syntax for patches, too. It makes my job with
> svnmerge a little bit easier.

You'd have to exempt modules mentioned in PEP 291 though.

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 python at rcn.com  Sun Feb 17 20:42:09 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 17 Feb 2008 11:42:09 -0800
Subject: [Python-Dev] Use Python 3.0 syntax for except and raise?
References: <fp9p2p$ivb$1@ger.gmane.org>
Message-ID: <003301c8719d$30247940$6800a8c0@RaymondLaptop1>

[Christian Heimes]
> I like to run the 2to3 tool with raise and except fixers over the 2.6
> sources. The raise fixer changes "raise Exception, msg" to "raise
> Exception(msg)" and the except fixer replaces "except Exception, err" by
> "except Exception as err".

+1  The new syntax so much better that we should do this even if 3.0 did not exist.

There are some modules like Decimal that make a promise to run on earlier
versions of Python.  In those cases only the first change (backwards compatible)
should be made.  Our 5,000 line Decimal package will need to wait for 3.0 to
use the except/as form :-(

Raymond

From dickinsm at gmail.com  Sun Feb 17 20:58:17 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sun, 17 Feb 2008 14:58:17 -0500
Subject: [Python-Dev] Use Python 3.0 syntax for except and raise?
In-Reply-To: <003301c8719d$30247940$6800a8c0@RaymondLaptop1>
References: <fp9p2p$ivb$1@ger.gmane.org>
	<003301c8719d$30247940$6800a8c0@RaymondLaptop1>
Message-ID: <5c6f2a5d0802171158xc3c895cy34e5104d1d576535@mail.gmail.com>

On Feb 17, 2008 2:42 PM, Raymond Hettinger <python at rcn.com> wrote:

> There are some modules like Decimal that make a promise to run on earlier
> versions of Python.  In those cases only the first change (backwards
> compatible)
> should be made.  Our 5,000 line Decimal package will need to wait for 3.0to
> use the except/as form :-(
>

Not a problem.  Decimal doesn't use "except Exception, err" anywhere
in those 5000 lines, as far as I can tell! :-)

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080217/75d68362/attachment.htm 

From dickinsm at gmail.com  Sun Feb 17 20:52:03 2008
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sun, 17 Feb 2008 11:52:03 -0800 (PST)
Subject: [Python-Dev] Use Python 3.0 syntax for except and raise?
In-Reply-To: <003301c8719d$30247940$6800a8c0@RaymondLaptop1>
References: <fp9p2p$ivb$1@ger.gmane.org>
	<003301c8719d$30247940$6800a8c0@RaymondLaptop1>
Message-ID: <f04a79d9-f6a4-442e-9c70-5908a2ea6492@c33g2000hsd.googlegroups.com>

On Feb 17, 2:42?pm, "Raymond Hettinger" <pyt... at rcn.com> wrote:
> There are some modules like Decimal that make a promise to run on earlier
> versions of Python. ?In those cases only the first change (backwards compatible)
> should be made. ?Our 5,000 line Decimal package will need to wait for 3.0 to
> use the except/as form :-(

It looks to me as though Decimal doesn't use "except Exception, err"
anywhere in those 5000 lines.
:-)

Mark

From martin at v.loewis.de  Sun Feb 17 21:29:24 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 17 Feb 2008 21:29:24 +0100
Subject: [Python-Dev] Py_CLEAR to avoid crashes
In-Reply-To: <5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
	<5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>
Message-ID: <47B89924.8070000@v.loewis.de>

Jeffrey Yasskin wrote:
> On Feb 16, 2008 3:12 PM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
>> Should we however intensively search and correct all of them?
>> Is there a clever way to prevent these problems globally, for example
>> by delaying finalizers "just a little"?
> 
> A simple way to do this would be to push objects whose refcounts had
> reached 0 onto a list instead of finalizing them immediately, and have
> PyEval_EvalFrameEx periodically swap in a new to-delete list and
> delete the objects on the old one.

-1. This would only soften the problem in a shallow way. It should still
be possible to create cases where the final cleanup of the object comes
"too early", e.g. when some caller of PyEval_EvalFrameEx still carries
a pointer to some object that got deleted, and then still some code can
get hold of the then-deleted object. It will just be more difficult to
trigger such crashes, depending on the period in which objects are
cleaned.

The only sane way to never touch deleted objects is to have no 
references to them on heap anymore, and to not touch stack references
after the DECREF.

Regards,
Martin

From greg.ewing at canterbury.ac.nz  Sun Feb 17 22:51:31 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 18 Feb 2008 10:51:31 +1300
Subject: [Python-Dev] Py_CLEAR to avoid crashes
In-Reply-To: <47B89924.8070000@v.loewis.de>
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
	<5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>
	<47B89924.8070000@v.loewis.de>
Message-ID: <47B8AC63.7050106@canterbury.ac.nz>

Martin v. L?wis wrote:
> when some caller of PyEval_EvalFrameEx still carries
> a pointer to some object that got deleted, and then still some code can
> get hold of the then-deleted object.

I seem to have missed the beginning of this discussion.
I don't see what the problem is here. If a caller needs
a pointer to an object, shouldn't it be holding a
counted reference to it?

--
Greg

From facundobatista at gmail.com  Mon Feb 18 12:22:23 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Mon, 18 Feb 2008 09:22:23 -0200
Subject: [Python-Dev] Small RFEs and the Bug Tracker
Message-ID: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>

Hi!

Don't now if always, or in the last few months where I've been
following the issues more closely, but I found that are appearing a
lot of small RFEs in the tracker.

These normally are small but not trivial things. In most cases when I
read them I think "Mmm, yes... it won't hurt to have it, but it's not
so important, and definitively not my itch to scratch". See, for
example, this [1] one, that ask for a factorial method in the
integers.

Normally these RFEs stay there for a long time, unless they're clearly
negative, because they don't raise any discussion.

OTOH, we have a PEP for feature requests [2]. I quote part of it:

"""
    This PEP was created to allow us to close bug reports that are really
    feature requests.  Marked as Open, they distract from the list of real
    bugs (which should ideally be less than a page).  Marked as Closed, they
    tend to be forgotten.  The procedure now is:  if a bug report is really
    a feature request, add the feature request to this PEP; mark the bug as
    "feature request", "later", and "closed"; and add a comment to the bug
    saying that this is the case (mentioning the PEP explicitly).
"""

This is still valid? Should we start moving RFEs to this PEP and
closing their issues in the tracker?

Or should we try to get more discussion regarding these RFEs? Maybe,
for example, a weekly digest where the latests RFEs added are sent to
python-dev, so we can actually say "no way" and close them, or say
"nice" and *then* moving them to the PEP (this has the risk of nobody
saying anything, and to stay in the same position as before).

What do you think? Opinions?

Thank you very much!

Regards,

[1] http://bugs.python.org/issue2138
[2] http://www.python.org/dev/peps/pep-0042/

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From eric+python-dev at trueblade.com  Mon Feb 18 12:12:11 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Mon, 18 Feb 2008 06:12:11 -0500
Subject: [Python-Dev] Different float formatting on Windows and Linux
Message-ID: <47B9680B.3000609@trueblade.com>

The tests for float.__format__ are breaking on Windows, because of this 
issue: http://bugs.python.org/issue1600.  Basically, Windows is using 3 
digits for exponents < 100, and Linux (and at least MacOS) are using 2.

The patch attached to the issue proposes changing all platforms to use 
at least 3 digits.  It affects both '%' formatting and __format__ 
formatting.  Altering all float formatting involving exponents is a 
pretty big change to make, and I want to get opinions here before making 
this change.

Guido's comments in the issue are supportive, and I agree that the 
consistency would be good.  I'm just concerned about changing the output 
for existing code.

I suppose another option would be to modify Windows to use 2 digits for 
exponents < 100.  I guess it just depends on whose output you want to break!

I think the options are:
1: Do nothing.  Adapt the tests to deal with the differences.
2: Force 3 characters for exponents < 100.
3: Force 2 characters for exponents < 100.

Eric.

From ncoghlan at gmail.com  Mon Feb 18 13:36:53 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 18 Feb 2008 22:36:53 +1000
Subject: [Python-Dev] Py_CLEAR to avoid crashes
In-Reply-To: <47B8AC63.7050106@canterbury.ac.nz>
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>	<5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>	<47B89924.8070000@v.loewis.de>
	<47B8AC63.7050106@canterbury.ac.nz>
Message-ID: <47B97BE5.3040005@gmail.com>

Greg Ewing wrote:
> Martin v. L?wis wrote:
>> when some caller of PyEval_EvalFrameEx still carries
>> a pointer to some object that got deleted, and then still some code can
>> get hold of the then-deleted object.
> 
> I seem to have missed the beginning of this discussion.
> I don't see what the problem is here. If a caller needs
> a pointer to an object, shouldn't it be holding a
> counted reference to it?

The problem is calls to Py_DECREF(self->attr) where some of the code 
invoked by __del__ manages to find a way back around to reference 
self->attr and gets access to a half-deleted object.

Amaury fixed a few of these recently by replacing the Py_DECREF calls 
with Py_CLEAR calls (and added the relevant pathological destructors to 
the test suite), but was wondering if there was a way to be more 
systematic about fixing them. About the only idea I have is to grep the 
source for all calls to Py_DECREF that contain a pointer deference and 
manually check them to see if they should use Py_CLEAR instead.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From hsoft at hardcoded.net  Mon Feb 18 13:38:44 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Mon, 18 Feb 2008 13:38:44 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
Message-ID: <2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>

On 2/18/08, Facundo Batista <facundobatista at gmail.com> wrote:
> Hi!
>
> Don't now if always, or in the last few months where I've been
> following the issues more closely, but I found that are appearing a
> lot of small RFEs in the tracker.
>
> These normally are small but not trivial things. In most cases when I
> read them I think "Mmm, yes... it won't hurt to have it, but it's not
> so important, and definitively not my itch to scratch". See, for
> example, this [1] one, that ask for a factorial method in the
> integers.
>
> Normally these RFEs stay there for a long time, unless they're clearly
> negative, because they don't raise any discussion.
>
> OTOH, we have a PEP for feature requests [2]. I quote part of it:
>
> """
>     This PEP was created to allow us to close bug reports that are really
>     feature requests.  Marked as Open, they distract from the list of real
>     bugs (which should ideally be less than a page).  Marked as Closed, they
>     tend to be forgotten.  The procedure now is:  if a bug report is really
>     a feature request, add the feature request to this PEP; mark the bug as
>     "feature request", "later", and "closed"; and add a comment to the bug
>     saying that this is the case (mentioning the PEP explicitly).
> """
>
> This is still valid? Should we start moving RFEs to this PEP and
> closing their issues in the tracker?
>
> Or should we try to get more discussion regarding these RFEs? Maybe,
> for example, a weekly digest where the latests RFEs added are sent to
> python-dev, so we can actually say "no way" and close them, or say
> "nice" and *then* moving them to the PEP (this has the risk of nobody
> saying anything, and to stay in the same position as before).
>
> What do you think? Opinions?
>
> Thank you very much!
>
> Regards,
>
> [1] http://bugs.python.org/issue2138
> [2] http://www.python.org/dev/peps/pep-0042/
>
> --
> .    Facundo
>
> Blog: http://www.taniquetil.com.ar/plog/
> PyAr: http://www.python.org/ar/
> _______________________________________________
> 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/hsoft%40hardcoded.net
>

Personally, I think that a bug tracker is a good place to keep RFE,
not a PEP. I think that the PEP would tend to be cluttered with RFE
nobody cares about forever. So the clutter can never be cleaned unless
someone takes the responsibility to mercilessly remove them.

What I really think should be done is first to get rid of all these 8+
months old issues, and then have a kind of system that after 8 months,
an issue goes back in "dying mode" where it surfaces back with a
message "Does anyone have any reason to believe this issue should
still be alive?" If there is no answer after a week, the issue is
closed.

--
Virgil

From nas at arctrix.com  Mon Feb 18 17:29:42 2008
From: nas at arctrix.com (Neil Schemenauer)
Date: Mon, 18 Feb 2008 16:29:42 +0000 (UTC)
Subject: [Python-Dev] Py_CLEAR to avoid crashes
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
	<5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>
	<47B89924.8070000@v.loewis.de> <47B8AC63.7050106@canterbury.ac.nz>
	<47B97BE5.3040005@gmail.com>
Message-ID: <fpcbpm$4f6$1@ger.gmane.org>

Nick Coghlan <ncoghlan at gmail.com> wrote:
> The problem is calls to Py_DECREF(self->attr) where some of the code 
> invoked by __del__ manages to find a way back around to reference 
> self->attr and gets access to a half-deleted object.

Don't you mean "__del__ manages to find a way back around to self"?
If so, how can that happen?  If such a reference path exists, the
reference count of self should not be zero.  I don't understand why
Py_CLEAR is necessary outside of tp_clear functions.

  Neil


From amauryfa at gmail.com  Mon Feb 18 17:48:57 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Mon, 18 Feb 2008 17:48:57 +0100
Subject: [Python-Dev] Py_CLEAR to avoid crashes
In-Reply-To: <fpcbpm$4f6$1@ger.gmane.org>
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
	<5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>
	<47B89924.8070000@v.loewis.de> <47B8AC63.7050106@canterbury.ac.nz>
	<47B97BE5.3040005@gmail.com> <fpcbpm$4f6$1@ger.gmane.org>
Message-ID: <e27efe130802180848t57b61f1fw17ae908b0fe9f5c9@mail.gmail.com>

Hello,
Neil Schemenauer wrote:
> Nick Coghlan <ncoghlan at gmail.com> wrote:
> > The problem is calls to Py_DECREF(self->attr) where some of the code
> > invoked by __del__ manages to find a way back around to reference
> > self->attr and gets access to a half-deleted object.
>
> Don't you mean "__del__ manages to find a way back around to self"?
> If so, how can that happen?  If such a reference path exists, the
> reference count of self should not be zero.  I don't understand why
> Py_CLEAR is necessary outside of tp_clear functions.

Of course we are speaking of different objects.

For example, in exception.c, BaseException_init() starts with the instruction:
    Py_DECREF(self->args);
this may call __del__ on self->args, which can execute arbitrary
python code - including access to the now-invalid "args" member of the
exception.

class S:
  def __del__(self):
     print e.args

e = BaseException(1, S())
e.__init__("hello")   # segfault

-- 
Amaury Forgeot d'Arc

From asmodai at in-nomine.org  Mon Feb 18 19:21:32 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Mon, 18 Feb 2008 19:21:32 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
Message-ID: <20080218182132.GM81956@nexus.in-nomine.org>

-On [20080218 13:38], Virgil Dupras (hsoft at hardcoded.net) wrote:
>Personally, I think that a bug tracker is a good place to keep RFE,
>not a PEP. I think that the PEP would tend to be cluttered with RFE
>nobody cares about forever. So the clutter can never be cleaned unless
>someone takes the responsibility to mercilessly remove them.

A bug tracker is a much better way of registering such information. It also
can be easier referenced in the future since even though when it is closed,
the debate and other stuff will remain in the tracker's tickets for
posterity. :)

PEP: -1
tracker: +1

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
But Time, keeps flowing like a river (on and on)...

From amauryfa at gmail.com  Mon Feb 18 20:11:16 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Mon, 18 Feb 2008 20:11:16 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <20080218182132.GM81956@nexus.in-nomine.org>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
Message-ID: <e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>

Jeroen Ruigrok van der Werven wrote:
> -On [20080218 13:38], Virgil Dupras (hsoft at hardcoded.net) wrote:
> >Personally, I think that a bug tracker is a good place to keep RFE,
> >not a PEP. I think that the PEP would tend to be cluttered with RFE
> >nobody cares about forever. So the clutter can never be cleaned unless
> >someone takes the responsibility to mercilessly remove them.
>
> A bug tracker is a much better way of registering such information. It also
> can be easier referenced in the future since even though when it is closed,
> the debate and other stuff will remain in the tracker's tickets for
> posterity. :)
>
> PEP: -1
> tracker: +1

I agree. Then we can set some status/keyword when the subject of a RFE
is accepted by core developers, saying "if someone proposes a patch,
it has a chance to be reviewed and applied".
It may incite occasional contributors to work on some of these tasks,
confident that their work will not be thrown away in two seconds.

-- 
Amaury Forgeot d'Arc

From jyasskin at gmail.com  Mon Feb 18 20:20:35 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Mon, 18 Feb 2008 11:20:35 -0800
Subject: [Python-Dev] Py_CLEAR to avoid crashes
In-Reply-To: <47B89924.8070000@v.loewis.de>
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
	<5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>
	<47B89924.8070000@v.loewis.de>
Message-ID: <5d44f72f0802181120q3f6f9caaoce3496410ed4f0fc@mail.gmail.com>

On Feb 17, 2008 12:29 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Jeffrey Yasskin wrote:
> > On Feb 16, 2008 3:12 PM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> >> Should we however intensively search and correct all of them?
> >> Is there a clever way to prevent these problems globally, for example
> >> by delaying finalizers "just a little"?
> >
> > A simple way to do this would be to push objects whose refcounts had
> > reached 0 onto a list instead of finalizing them immediately, and have
> > PyEval_EvalFrameEx periodically swap in a new to-delete list and
> > delete the objects on the old one.
>
> -1. This would only soften the problem in a shallow way. It should still
> be possible to create cases where the final cleanup of the object comes
> "too early", e.g. when some caller of PyEval_EvalFrameEx still carries
> a pointer to some object that got deleted, and then still some code can
> get hold of the then-deleted object. It will just be more difficult to
> trigger such crashes, depending on the period in which objects are
> cleaned.

Right. Changing introducing these bugs from "easy" to "possible"
sounds like an improvement. Making them harder to trigger has both
good and bad effects: they're harder to exploit and harder to
reproduce. If we delete on every iteration, it only costs a couple
memory accesses more, and should eliminate most of the
non-determinism.

Anyway, I saw an approach like this work well on a server I used to
work on, but there were differences. In particular, there was no way
to call a function to trigger deletions; you had to return out to the
main loop, which made it a little more reliable than it would be in
Python. I suspect it would still fix nearly all of the bugs Amaury is
finding since Py_DECREF would no longer return control to the
interpreter, but I could be wrong.

> The only sane way to never touch deleted objects is to have no
> references to them on heap anymore, and to not touch stack references
> after the DECREF.
>
> Regards,
> Martin
>



-- 
Namast?,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

From brett at python.org  Mon Feb 18 21:41:42 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 18 Feb 2008 12:41:42 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
Message-ID: <bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>

On Feb 18, 2008 11:11 AM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> Jeroen Ruigrok van der Werven wrote:
> > -On [20080218 13:38], Virgil Dupras (hsoft at hardcoded.net) wrote:
> > >Personally, I think that a bug tracker is a good place to keep RFE,
> > >not a PEP. I think that the PEP would tend to be cluttered with RFE
> > >nobody cares about forever. So the clutter can never be cleaned unless
> > >someone takes the responsibility to mercilessly remove them.
> >
> > A bug tracker is a much better way of registering such information. It also
> > can be easier referenced in the future since even though when it is closed,
> > the debate and other stuff will remain in the tracker's tickets for
> > posterity. :)
> >
> > PEP: -1
> > tracker: +1
>
> I agree. Then we can set some status/keyword when the subject of a RFE
> is accepted by core developers, saying "if someone proposes a patch,
> it has a chance to be reviewed and applied".
> It may incite occasional contributors to work on some of these tasks,
> confident that their work will not be thrown away in two seconds.

My issue with keeping the RFEs in the tracker as they are is that it
artificially inflates the open issue count. Python does not have over
1,700 open bugs.

So I have no issue with keeping the RFEs in the tracker, at some point
I do want to change how they are represnted so that they are a
separate things from issues representing bugs and patches.

-Brett

From asmodai at in-nomine.org  Mon Feb 18 21:52:56 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Mon, 18 Feb 2008 21:52:56 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
Message-ID: <20080218205256.GO81956@nexus.in-nomine.org>

-On [20080218 21:41], Brett Cannon (brett at python.org) wrote:
>My issue with keeping the RFEs in the tracker as they are is that it
>artificially inflates the open issue count. Python does not have over
>1,700 open bugs.

An issue does not necessarily mean the same as bug. :)

Is it a bug tracker you have or an issue tracker? If the former, agreed, if
the latter then it makes sense to track RFEs in the tracker.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
And every word upon your spiralling cross is but a misled sun, a bitter
 loss...

From greg at krypto.org  Mon Feb 18 21:54:22 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Mon, 18 Feb 2008 12:54:22 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
Message-ID: <52dc1c820802181254r49a0c1f6t64f11161ece652dd@mail.gmail.com>

> > >
> > > PEP: -1
> > > tracker: +1
> >
> > I agree. Then we can set some status/keyword when the subject of a RFE
> > is accepted by core developers, saying "if someone proposes a patch,
> > it has a chance to be reviewed and applied".
> > It may incite occasional contributors to work on some of these tasks,
> > confident that their work will not be thrown away in two seconds.
>
> My issue with keeping the RFEs in the tracker as they are is that it
> artificially inflates the open issue count. Python does not have over
> 1,700 open bugs.
>
> So I have no issue with keeping the RFEs in the tracker, at some point
> I do want to change how they are represnted so that they are a
> separate things from issues representing bugs and patches.
>
> -Brett


Sure but thats merely a tracker problem.  Change your count to bugs not
marked as a rfe / feature-request and you've got your real count.  Tracker
entries for rfes are much better than a languid document.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080218/0c7d88f8/attachment.htm 

From ndbecker2 at gmail.com  Mon Feb 18 21:59:34 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Mon, 18 Feb 2008 15:59:34 -0500
Subject: [Python-Dev] trunk-math
References: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
Message-ID: <fpcrjm$3nf$2@ger.gmane.org>

There is a post on boost (http://boost.org) about floating point utilities
that are being considered for review.  This seems to have a lot of overlap
with python needs.  I haven't reviewed this myself, but boost code is meant
to be quite portable.  Here is the link:

http://tinyurl.com/2gg4z3






From hsoft at hardcoded.net  Mon Feb 18 21:47:58 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Mon, 18 Feb 2008 21:47:58 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
Message-ID: <2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>

On 2/18/08, Brett Cannon <brett at python.org> wrote:
> On Feb 18, 2008 11:11 AM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> > Jeroen Ruigrok van der Werven wrote:
> > > -On [20080218 13:38], Virgil Dupras (hsoft at hardcoded.net) wrote:
> > > >Personally, I think that a bug tracker is a good place to keep RFE,
> > > >not a PEP. I think that the PEP would tend to be cluttered with RFE
> > > >nobody cares about forever. So the clutter can never be cleaned unless
> > > >someone takes the responsibility to mercilessly remove them.
> > >
> > > A bug tracker is a much better way of registering such information. It also
> > > can be easier referenced in the future since even though when it is closed,
> > > the debate and other stuff will remain in the tracker's tickets for
> > > posterity. :)
> > >
> > > PEP: -1
> > > tracker: +1
> >
> > I agree. Then we can set some status/keyword when the subject of a RFE
> > is accepted by core developers, saying "if someone proposes a patch,
> > it has a chance to be reviewed and applied".
> > It may incite occasional contributors to work on some of these tasks,
> > confident that their work will not be thrown away in two seconds.
>
> My issue with keeping the RFEs in the tracker as they are is that it
> artificially inflates the open issue count. Python does not have over
> 1,700 open bugs.
>
> So I have no issue with keeping the RFEs in the tracker, at some point
> I do want to change how they are represnted so that they are a
> separate things from issues representing bugs and patches.
>
> -Brett

Which is why I propose to have a mechanism to close bugs and RFE
nobody cares about. over *1000* out of those 1700 open issues are 6+
months old.

Virgil

From steve at holdenweb.com  Mon Feb 18 22:10:39 2008
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 18 Feb 2008 16:10:39 -0500
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <20080218205256.GO81956@nexus.in-nomine.org>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<20080218205256.GO81956@nexus.in-nomine.org>
Message-ID: <47B9F44F.7010905@holdenweb.com>

Jeroen Ruigrok van der Werven wrote:
> -On [20080218 21:41], Brett Cannon (brett at python.org) wrote:
>> My issue with keeping the RFEs in the tracker as they are is that it
>> artificially inflates the open issue count. Python does not have over
>> 1,700 open bugs.
> 
> An issue does not necessarily mean the same as bug. :)
> 
> Is it a bug tracker you have or an issue tracker? If the former, agreed, if
> the latter then it makes sense to track RFEs in the tracker.
> 
Certainly, but since some issues *are* bugs we might need to refine our 
analysis somewhat. It would be better to have a bug report which omitted 
issues of type "rfe". As far as I can see open issues of all other types 
would be properly classified as bugs.

There there's the Status field. I understand "open" and "closed", but 
what's the semantic of "pending". Is it awaiting triage, awaiting status 
assignment, or what?

I quite like Django's "triage stage", see

http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&group=stage&order=priority

The stages availabele appear to be "Accepted", "Someday/Maybe", "Design 
decision needed", "Ready for checkin" and "Unreviewed". OK. maybe 
"triage" wasn't such a good name for for a four-state condition, but it 
serves a useful purpose and helps people understand what the ultimate 
fate of issues they raise might be.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/

From steve at holdenweb.com  Mon Feb 18 22:10:39 2008
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 18 Feb 2008 16:10:39 -0500
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <20080218205256.GO81956@nexus.in-nomine.org>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<20080218205256.GO81956@nexus.in-nomine.org>
Message-ID: <47B9F44F.7010905@holdenweb.com>

Jeroen Ruigrok van der Werven wrote:
> -On [20080218 21:41], Brett Cannon (brett at python.org) wrote:
>> My issue with keeping the RFEs in the tracker as they are is that it
>> artificially inflates the open issue count. Python does not have over
>> 1,700 open bugs.
> 
> An issue does not necessarily mean the same as bug. :)
> 
> Is it a bug tracker you have or an issue tracker? If the former, agreed, if
> the latter then it makes sense to track RFEs in the tracker.
> 
Certainly, but since some issues *are* bugs we might need to refine our 
analysis somewhat. It would be better to have a bug report which omitted 
issues of type "rfe". As far as I can see open issues of all other types 
would be properly classified as bugs.

There there's the Status field. I understand "open" and "closed", but 
what's the semantic of "pending". Is it awaiting triage, awaiting status 
assignment, or what?

I quite like Django's "triage stage", see

http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&group=stage&order=priority

The stages availabele appear to be "Accepted", "Someday/Maybe", "Design 
decision needed", "Ready for checkin" and "Unreviewed". OK. maybe 
"triage" wasn't such a good name for for a four-state condition, but it 
serves a useful purpose and helps people understand what the ultimate 
fate of issues they raise might be.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From steve at holdenweb.com  Mon Feb 18 22:15:33 2008
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 18 Feb 2008 16:15:33 -0500
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>
Message-ID: <fpcshr$6ce$2@ger.gmane.org>

Virgil Dupras wrote:
> On 2/18/08, Brett Cannon <brett at python.org> wrote:
[...]
>> So I have no issue with keeping the RFEs in the tracker, at some point
>> I do want to change how they are represnted so that they are a
>> separate things from issues representing bugs and patches.
>>
>> -Brett
> 
> Which is why I propose to have a mechanism to close bugs and RFE
> nobody cares about. over *1000* out of those 1700 open issues are 6+
> months old.
> 
I'm not sure we should be throwing RFE's away with such casual abandon 
just because nobody had time to pay them any attention in six months - 
nor bugs neither, come to that.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From greg at krypto.org  Mon Feb 18 22:22:17 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Mon, 18 Feb 2008 13:22:17 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <fpcshr$6ce$2@ger.gmane.org>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>
	<fpcshr$6ce$2@ger.gmane.org>
Message-ID: <52dc1c820802181322x385cef6ay7362984a0cec7624@mail.gmail.com>

> > Which is why I propose to have a mechanism to close bugs and RFE
> > nobody cares about. over *1000* out of those 1700 open issues are 6+
> > months old.
> >
> I'm not sure we should be throwing RFE's away with such casual abandon
> just because nobody had time to pay them any attention in six months -
> nor bugs neither, come to that.


+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080218/c686ff4f/attachment-0001.htm 

From hsoft at hardcoded.net  Mon Feb 18 22:29:19 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Mon, 18 Feb 2008 22:29:19 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <fpcshr$6ce$2@ger.gmane.org>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>
	<fpcshr$6ce$2@ger.gmane.org>
Message-ID: <2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>

On 2/18/08, Steve Holden <steve at holdenweb.com> wrote:
> I'm not sure we should be throwing RFE's away with such casual abandon
> just because nobody had time to pay them any attention in six months -
> nor bugs neither, come to that.

Well, we have to evaluate the chances of our older tickets to come to
completion. I'm of the opinion that ticket getting older have very
small chances of ever being completed. RFE for python 2.4 are likely
to be irrelevant. old bugs are likely to already be fixed. Maybe we
could run a statistical analysis to compute the chances of a ticket
that have seen no activity for 8 months to ever be successfully
completed? How many successful tickets to we have that had a 8+ months
gap between activity? Or maybe we could just clean out the 400 tickets
that are 2+ years old? What are the chances for a 2 years old ticket
to be completed?

-- 
Virgil

From g.brandl at gmx.net  Mon Feb 18 22:39:04 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 18 Feb 2008 22:39:04 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47B9F44F.7010905@holdenweb.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<20080218205256.GO81956@nexus.in-nomine.org>
	<47B9F44F.7010905@holdenweb.com>
Message-ID: <fpctov$bba$1@ger.gmane.org>

Steve Holden schrieb:
> Jeroen Ruigrok van der Werven wrote:
>> -On [20080218 21:41], Brett Cannon (brett at python.org) wrote:
>>> My issue with keeping the RFEs in the tracker as they are is that it
>>> artificially inflates the open issue count. Python does not have over
>>> 1,700 open bugs.
>> 
>> An issue does not necessarily mean the same as bug. :)
>> 
>> Is it a bug tracker you have or an issue tracker? If the former, agreed, if
>> the latter then it makes sense to track RFEs in the tracker.
>> 
> Certainly, but since some issues *are* bugs we might need to refine our 
> analysis somewhat. It would be better to have a bug report which omitted 
> issues of type "rfe". As far as I can see open issues of all other types 
> would be properly classified as bugs.
> 
> There there's the Status field. I understand "open" and "closed", but 
> what's the semantic of "pending". Is it awaiting triage, awaiting status 
> assignment, or what?

It's a leftover from SF.net. There it had the feature that pending items
were closed automatically after two weeks if no further activity took
place.

For the new tracker, we should really decide about a "pending" policy,
or implement the feature too.

Georg


From steve at holdenweb.com  Mon Feb 18 22:36:51 2008
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 18 Feb 2008 16:36:51 -0500
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>	<fpcshr$6ce$2@ger.gmane.org>
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
Message-ID: <fpctpp$atu$1@ger.gmane.org>

Virgil Dupras wrote:
> On 2/18/08, Steve Holden <steve at holdenweb.com> wrote:
>> I'm not sure we should be throwing RFE's away with such casual abandon
>> just because nobody had time to pay them any attention in six months -
>> nor bugs neither, come to that.
> 
> Well, we have to evaluate the chances of our older tickets to come to
> completion. I'm of the opinion that ticket getting older have very
> small chances of ever being completed. RFE for python 2.4 are likely
> to be irrelevant. old bugs are likely to already be fixed. Maybe we
> could run a statistical analysis to compute the chances of a ticket
> that have seen no activity for 8 months to ever be successfully
> completed? How many successful tickets to we have that had a 8+ months
> gap between activity? Or maybe we could just clean out the 400 tickets
> that are 2+ years old? What are the chances for a 2 years old ticket
> to be completed?
> 
But the decision shouldn't be made on the age of the ticket, rather on 
the (continued?) validity of the information it contains.

I appreciate the desire to "keep the issue tracker clean", but I think 
human intelligence needs to be applied to the task, not just a 
date-based cutoff.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From hsoft at hardcoded.net  Mon Feb 18 22:48:19 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Mon, 18 Feb 2008 22:48:19 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <fpctpp$atu$1@ger.gmane.org>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>
	<fpcshr$6ce$2@ger.gmane.org>
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
	<fpctpp$atu$1@ger.gmane.org>
Message-ID: <2a70578d0802181348ya98b812ya933edce23259dae@mail.gmail.com>

On 2/18/08, Steve Holden <steve at holdenweb.com> wrote:
> I appreciate the desire to "keep the issue tracker clean", but I think
> human intelligence needs to be applied to the task, not just a
> date-based cutoff.

Personally, the bug count doesn't bother me. I was just responding to
Brett's concerns about the high issue count, saying that having the
issue tracker keep track of the RFE is not what makes that count so
high. I'm ok with the status quo.

Virgil

From python at rcn.com  Mon Feb 18 22:56:23 2008
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 18 Feb 2008 13:56:23 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>	<fpcshr$6ce$2@ger.gmane.org><2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
	<fpctpp$atu$1@ger.gmane.org>
Message-ID: <006e01c87279$1b39a0f0$6800a8c0@RaymondLaptop1>

[Steve Holden]
 > I appreciate the desire to "keep the issue tracker clean", but I think 
> human intelligence needs to be applied to the task, not just a 
> date-based cutoff.

I concur.  The older bug reports are ones that have survived
past human-based clean-up efforts.  They were left open as
a reminder, as a todo, to await time or decision by a module
author, or it wasn't clear how to solve valid report.

IIRC, there are some for regexes that would take the time
of the one or two people supporting that module and the
request would cover a not urgently needed corner cases
(like handling empty matches or speeding-up badly
designed regexes).  Those bug reports and rfes are
valid and should be left open unless a module author
decides that re's won't support the request.


Raymond

From nas at arctrix.com  Mon Feb 18 22:52:14 2008
From: nas at arctrix.com (Neil Schemenauer)
Date: Mon, 18 Feb 2008 15:52:14 -0600
Subject: [Python-Dev] Py_CLEAR to avoid crashes
In-Reply-To: <e27efe130802180848t57b61f1fw17ae908b0fe9f5c9@mail.gmail.com>
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
	<5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>
	<47B89924.8070000@v.loewis.de> <47B8AC63.7050106@canterbury.ac.nz>
	<47B97BE5.3040005@gmail.com> <fpcbpm$4f6$1@ger.gmane.org>
	<e27efe130802180848t57b61f1fw17ae908b0fe9f5c9@mail.gmail.com>
Message-ID: <20080218215213.GA12253@arctrix.com>

On Mon, Feb 18, 2008 at 05:48:57PM +0100, Amaury Forgeot d'Arc wrote:
> For example, in exception.c, BaseException_init() starts with the instruction:
>     Py_DECREF(self->args);
> this may call __del__ on self->args

Ah, I understand now.  We are not talking about tp_dealloc methods
(the GC takes great pains to avoid this scenario).  However, any
object that calls Py_DECREF outside of its tp_dealloc method must be
prepared for finalizers to access it in arbitrary ways.

That sucks.  Most Py_DECREF calls are probably okay but it's going
to be hard to find the ones that are not.  I can't think of anything
we can do to make this trap harder to fall into.  Even using
Py_CLEAR as a blunt tool is not a total solution. You could still
end up with a null pointer dereference if the code is not written
carefully.

  Neil

From guido at python.org  Tue Feb 19 00:44:28 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 18 Feb 2008 15:44:28 -0800
Subject: [Python-Dev] Use Python 3.0 syntax for except and raise?
In-Reply-To: <fp9p2p$ivb$1@ger.gmane.org>
References: <fp9p2p$ivb$1@ger.gmane.org>
Message-ID: <ca471dc20802181544l545cab19vf355344a74d093b9@mail.gmail.com>

I don't know if you're done with this already, but there's a lot of
experience suggesting such sweeps are quite dangerous. In the past,
whenever a sweep across the entire stdlib was done, it's always caused
a few breakages, some of which didn't get caught until the next
release.

Things to worry about with these two changes:

raise X, y -> raise X(y): this is incorrect if y is a tuple; *only* if
it's a tuple, the correct translation is raise X(*y). But 2to3 can't
know that (unless the tuple is written out in place).

except X as y: in 3.0 this has different semantics -- y is explicitly
deleted at the end of the except block. I don't know if this is also
the semantics implemented in 2.6 (I think it should be), but again
this can cause som equite subtle breakages that are hard to catch
automatically.

And since both of these are about exceptions, there's a high
likelihood that some occurrences are not reached by a unittest.

IOW, while I'm not dead set against it (I agree with your motivation
in principle) I worry that in practice it may destabilize things., and
would prefer a different approach where these things are only changed
when someone is revising the module anyway.

--Guido

On Feb 17, 2008 8:57 AM, Christian Heimes <lists at cheimes.de> wrote:
> Good evening everybody!
>
> I like to run the 2to3 tool with raise and except fixers over the 2.6
> sources. The raise fixer changes "raise Exception, msg" to "raise
> Exception(msg)" and the except fixer replaces "except Exception, err" by
> "except Exception as err". In my humble opinion the Python stdlib should
> give proper examples how write good code.
>
> During the migration period from the 2.x series to 3.x we have two
> obvious ways to write code. Let's stick to the new and preferred way.
>
> Oh and please use the new syntax for patches, too. It makes my job with
> svnmerge a little bit easier.
>
> Thanks!
>
> Christian
>
> _______________________________________________
> 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  Tue Feb 19 00:56:43 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 19 Feb 2008 00:56:43 +0100
Subject: [Python-Dev] Py_CLEAR to avoid crashes
In-Reply-To: <20080218215213.GA12253@arctrix.com>
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>	<5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>	<47B89924.8070000@v.loewis.de>
	<47B8AC63.7050106@canterbury.ac.nz>	<47B97BE5.3040005@gmail.com>
	<fpcbpm$4f6$1@ger.gmane.org>	<e27efe130802180848t57b61f1fw17ae908b0fe9f5c9@mail.gmail.com>
	<20080218215213.GA12253@arctrix.com>
Message-ID: <47BA1B3B.1060300@v.loewis.de>

> That sucks.  Most Py_DECREF calls are probably okay but it's going
> to be hard to find the ones that are not.

Methinks that

egrep 'DECREF\([a-zA-Z0-9_]->[a-zA-Z0-9_]+\)' */*.c

gives a good overview - you should never DECREF a variable on heap.
In the trunk, this command finds 36 candidates. Now, some of them
are in tp_dealloc methods, so they shouldn't cause problems - but
it can't hurt to replace them with Py_CLEAR, either.

Regards,
Martin

From nas at arctrix.com  Tue Feb 19 00:59:26 2008
From: nas at arctrix.com (Neil Schemenauer)
Date: Mon, 18 Feb 2008 23:59:26 +0000 (UTC)
Subject: [Python-Dev] Py_CLEAR to avoid crashes
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
	<5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>
	<47B89924.8070000@v.loewis.de> <47B8AC63.7050106@canterbury.ac.nz>
	<47B97BE5.3040005@gmail.com> <fpcbpm$4f6$1@ger.gmane.org>
	<e27efe130802180848t57b61f1fw17ae908b0fe9f5c9@mail.gmail.com>
	<20080218215213.GA12253@arctrix.com>
Message-ID: <fpd64t$6k4$1@ger.gmane.org>

I wrote:
> Most Py_DECREF calls are probably okay but it's going to be hard
> to find the ones that are not.

I suppose Py_DECREF is not the only source of trouble.  Many calls
to the Python API can end up calling arbitrary user code (via
__getattr__, __getitem__, etc.).  Whenever an object does that, it
must be prepared to be accessed from user code.  I'm guessing there
are many subtle bugs of this nature lurking.  Py_DECREF is perhaps
the most common though.  Maybe renaming it to
Py_DECREF_AND_RUN_EVIL_USER_CODE would help. ;-)

  Neil


From martin at v.loewis.de  Tue Feb 19 01:00:20 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 19 Feb 2008 01:00:20 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>	<fpcshr$6ce$2@ger.gmane.org>
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
Message-ID: <47BA1C14.7090906@v.loewis.de>

> Well, we have to evaluate the chances of our older tickets to come to
> completion. I'm of the opinion that ticket getting older have very
> small chances of ever being completed. RFE for python 2.4 are likely
> to be irrelevant.

Do you have any facts to base this theory on?

Two years for a bug report is *nothing*. Ten years, and I would start
to worry that it might never get implemented.

Regards,
Martin

From martin at v.loewis.de  Tue Feb 19 01:02:42 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 19 Feb 2008 01:02:42 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
Message-ID: <47BA1CA2.5060007@v.loewis.de>

> This is still valid? Should we start moving RFEs to this PEP and
> closing their issues in the tracker?

As other have indicated - PEP 42 was a mistake (IMO).

> Or should we try to get more discussion regarding these RFEs? Maybe,
> for example, a weekly digest where the latests RFEs added are sent to
> python-dev, so we can actually say "no way" and close them, or say
> "nice" and *then* moving them to the PEP (this has the risk of nobody
> saying anything, and to stay in the same position as before).
> 
> What do you think? Opinions?

If you think this could help, sure, but I doubt it would.

I personally don't worry about these. If you don't want to see them,
filter them out (roundup is very good at custom searches).

Regards,
Martin

From jimjjewett at gmail.com  Mon Feb 18 22:13:05 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 18 Feb 2008 16:13:05 -0500
Subject: [Python-Dev] Py_CLEAR to avoid crashes
Message-ID: <fb6fbf560802181313p738ab746yaf7dce3fd4a984a5@mail.gmail.com>

> A simple way to do this would be to push objects whose
> refcounts had reached 0 onto a list instead of finalizing them
> immediately, and have PyEval_EvalFrameEx periodically swap
> in a new to-delete list and delete the objects on the old one.

Some of the memory management threads discussed something similar to
this, and pointed to IBM papers on Java.  By adding states like
"tenatively finalizable", the cost of using multiple processors was
reduced.

The down side is that objects which could be released (and recycled)
immediately won't be -- which slows down a fair number of real-world
programs that are used to the CPython refcount model.  If the resource
not being immediately released is scarce (such as file handles), it
gets even worse.

-jJ

From daniel at stutzbachenterprises.com  Tue Feb 19 01:13:24 2008
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Mon, 18 Feb 2008 19:13:24 -0500
Subject: [Python-Dev] Py_CLEAR to avoid crashes
In-Reply-To: <20080218215213.GA12253@arctrix.com>
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>
	<5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>
	<47B89924.8070000@v.loewis.de> <47B8AC63.7050106@canterbury.ac.nz>
	<47B97BE5.3040005@gmail.com> <fpcbpm$4f6$1@ger.gmane.org>
	<e27efe130802180848t57b61f1fw17ae908b0fe9f5c9@mail.gmail.com>
	<20080218215213.GA12253@arctrix.com>
Message-ID: <eae285400802181613k18676c99o9f9f06a98e4a9e18@mail.gmail.com>

On Feb 18, 2008 4:52 PM, Neil Schemenauer <nas at arctrix.com> wrote:

> That sucks.  Most Py_DECREF calls are probably okay but it's going
> to be hard to find the ones that are not.  I can't think of anything
> we can do to make this trap harder to fall into.  Even using
> Py_CLEAR as a blunt tool is not a total solution. You could still
> end up with a null pointer dereference if the code is not written
> carefully.
>

Container types (particularly lists) go through great lengths to postpone
object deletion.  For example, to delete a slice from a list all of the
items must be copied to a temporary array, then the list object's pointers
are modified, then all the Py_DECREF's are called just before returning.

I have always seen this as a robustness versus efficiency issue.  It's
theoretically possible to set things up so that reference counter decrements
are actually postponed until after the C method/slot returns, but it's
slower than doing it immediately.  I wonder if adding support for postponed
decrements (without making it mandatory) would at least make the trap harder
to fall into.

For example:

- maintain a global array of pending decrefs
- before calling into any C method/slot, save the index of the current
end-of-array (in a local C variable on the stack)
- call the C method, which may call Py_DECREF_LATER(x) to append x to the
global array
- when the C method returns, decref anything newly appended to the array

The array would grow and shrink just as a list does (O(1) amortized time to
add/remove a pointer).

This would simplify a number of places in listobject.c as well as remove the
need for Py_TRASHCAN_*.  It would be entirely optional, so anyone who is
very careful and wants the speed of Py_DECREF can have it.  Also, the
deferment is very brief, since the decrefs occur right after the C method
returns.

The downside is having to store and check the global array length on every C
method call (basically 3 machine instructions).  The machine instructions
aren't so bad, but I'm not sure about the effects on the CPU cache.

So, like I said, a robustness versus performance trade-off. :-(

-- 
Daniel Stutzbach, Ph.D.             President, Stutzbach Enterprises LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080218/37575de3/attachment.htm 

From martin at v.loewis.de  Tue Feb 19 01:17:50 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 19 Feb 2008 01:17:50 +0100
Subject: [Python-Dev] Py_CLEAR to avoid crashes
In-Reply-To: <fpd64t$6k4$1@ger.gmane.org>
References: <e27efe130802161512g53c34333y9c8a7c8f082e5349@mail.gmail.com>	<5d44f72f0802171014p61f8fa2od925b0a1216526d7@mail.gmail.com>	<47B89924.8070000@v.loewis.de>
	<47B8AC63.7050106@canterbury.ac.nz>	<47B97BE5.3040005@gmail.com>
	<fpcbpm$4f6$1@ger.gmane.org>	<e27efe130802180848t57b61f1fw17ae908b0fe9f5c9@mail.gmail.com>	<20080218215213.GA12253@arctrix.com>
	<fpd64t$6k4$1@ger.gmane.org>
Message-ID: <47BA202E.1040702@v.loewis.de>

>> Most Py_DECREF calls are probably okay but it's going to be hard
>> to find the ones that are not.
> 
> I suppose Py_DECREF is not the only source of trouble.  Many calls
> to the Python API can end up calling arbitrary user code (via
> __getattr__, __getitem__, etc.).  Whenever an object does that, it
> must be prepared to be accessed from user code.  I'm guessing there
> are many subtle bugs of this nature lurking.  Py_DECREF is perhaps
> the most common though.  Maybe renaming it to
> Py_DECREF_AND_RUN_EVIL_USER_CODE would help. ;-)

But that's unrelated to this issue. In those other cases, the refcount
won't be zero, so the object is still there.

Regards,
Martin

From rwgk at yahoo.com  Tue Feb 19 01:20:22 2008
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 18 Feb 2008 16:20:22 -0800 (PST)
Subject: [Python-Dev] Different float formatting on Windows and Linux
Message-ID: <110156.5455.qm@web31112.mail.mud.yahoo.com>

> The tests for float.__format__ are breaking on Windows, because of this 
> issue: http://bugs.python.org/issue1600.  Basically, Windows is using 3 
> digits for exponents < 100, and Linux (and at least MacOS) are using 2.

Yes, this is very annoying and I once lost of lot of time because of the
Windows difference.

> I think the options are:
> 1: Do nothing.  Adapt the tests to deal with the differences.
> 2: Force 3 characters for exponents < 100.
> 3: Force 2 characters for exponents < 100.

I'd go for 3. Rationale: this change will mostly affect scientific code,
which is mostly developed and used on Unix systems.

Thanks for taking care if this nuisance!

Ralf




From tjreedy at udel.edu  Tue Feb 19 02:17:22 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 18 Feb 2008 20:17:22 -0500
Subject: [Python-Dev] Different float formatting on Windows and Linux
References: <47B9680B.3000609@trueblade.com>
Message-ID: <fpdan2$k8i$1@ger.gmane.org>


"Eric Smith" <eric+python-dev at trueblade.com> wrote in message 
news:47B9680B.3000609 at trueblade.com...
| The tests for float.__format__ are breaking on Windows, because of this
| issue: http://bugs.python.org/issue1600.  Basically, Windows is using 3
| digits for exponents < 100, and Linux (and at least MacOS) are using 2.
|
| The patch attached to the issue proposes changing all platforms to use
| at least 3 digits.  It affects both '%' formatting and __format__
| formatting.  Altering all float formatting involving exponents is a
| pretty big change to make, and I want to get opinions here before making
| this change.
|
| Guido's comments in the issue are supportive, and I agree that the
| consistency would be good.  I'm just concerned about changing the output
| for existing code.
|
| I suppose another option would be to modify Windows to use 2 digits for
| exponents < 100.  I guess it just depends on whose output you want to 
break!
|
| I think the options are:
| 1: Do nothing.  Adapt the tests to deal with the differences.
| 2: Force 3 characters for exponents < 100.
| 3: Force 2 characters for exponents < 100.

Since you posted this, Mark Dickensom added a comment to the tracker that 3 
conforms to C99.  If so, go with that.  In any case, consistency would be 
nice.

tjr




From hsoft at hardcoded.net  Tue Feb 19 08:52:15 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Tue, 19 Feb 2008 08:52:15 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BA1C14.7090906@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>
	<fpcshr$6ce$2@ger.gmane.org>
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
	<47BA1C14.7090906@v.loewis.de>
Message-ID: <2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>

On 2/19/08, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > Well, we have to evaluate the chances of our older tickets to come to
> > completion. I'm of the opinion that ticket getting older have very
> > small chances of ever being completed. RFE for python 2.4 are likely
> > to be irrelevant.
>
> Do you have any facts to base this theory on?
>
> Two years for a bug report is *nothing*. Ten years, and I would start
> to worry that it might never get implemented.

No, I don't, which is why I would find it interesting to run some
queries on the roundup database to have completion statistics for low
activity tickets. Is is possible to get a copy of that db somehow?

Virgil

From martin at v.loewis.de  Tue Feb 19 09:00:23 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 19 Feb 2008 09:00:23 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>	<fpcshr$6ce$2@ger.gmane.org>	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>	<47BA1C14.7090906@v.loewis.de>
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
Message-ID: <47BA8C97.1000300@v.loewis.de>

> No, I don't, which is why I would find it interesting to run some
> queries on the roundup database to have completion statistics for low
> activity tickets. Is is possible to get a copy of that db somehow?

I would rather not make it available, as it contains certain 
privacy-related information that we need to withhold. If you provide
some SQL statement or Python script that you want me to run on the
server - that should be possible.

Regards,
Martin

From lists at cheimes.de  Tue Feb 19 10:28:14 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 19 Feb 2008 10:28:14 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47B9F44F.7010905@holdenweb.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<20080218205256.GO81956@nexus.in-nomine.org>
	<47B9F44F.7010905@holdenweb.com>
Message-ID: <fpe7fe$qr4$1@ger.gmane.org>

Steve Holden wrote:
> There there's the Status field. I understand "open" and "closed", but 
> what's the semantic of "pending". Is it awaiting triage, awaiting status 
> assignment, or what?

I've used pending for two states. For one I've put an issue on pending
state when it was fixed on the trunk but we haven't decided if the bugs
needs to be fixed in 2.5 as well. I've also set old bugs as pending to
give the op a change to reopen the bug within a month.

Christian


From hsoft at hardcoded.net  Tue Feb 19 10:42:02 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Tue, 19 Feb 2008 10:42:02 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BA8C97.1000300@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>
	<fpcshr$6ce$2@ger.gmane.org>
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
	<47BA1C14.7090906@v.loewis.de>
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
Message-ID: <2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>

On 2/19/08, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > No, I don't, which is why I would find it interesting to run some
> > queries on the roundup database to have completion statistics for low
> > activity tickets. Is is possible to get a copy of that db somehow?
>
> I would rather not make it available, as it contains certain
> privacy-related information that we need to withhold. If you provide
> some SQL statement or Python script that you want me to run on the
> server - that should be possible.

Hum, Roundup has a rather nice little API to it's issues. Here we go.
It would be nice to have stats for 360 days as well.

#!/usr/bin/env python
# I'm building this out of a demo db of roundup, and it doesn't have a
"Resolution", so
# I'm doing guesswork here. It shouldn't be very hard to modify the
script to fit the
# python db.
PATH_TO_TRACKER = 'demo'
ACTIVITY_DAY_THRESHOLD = 180

import roundup.instance

def has_large_activity_gap(issue, db):
    for first, second in zip(issue.messages, issue.messages[1:]):
        date1 = db.msg.getnode(first).date
        date2 = db.msg.getnode(second).date
        if date2.differenceDate(date1).as_seconds() >=
ACTIVITY_DAY_THRESHOLD * 3600:
            return True
    return False

tracker = roundup.instance.Tracker(PATH_TO_TRACKER)
db = tracker.open()
closed_status = db.status.lookup('chatting')
resolution2count = {}
for resolution_id in db.resolution.getnodeids():
    resolution2count[resolution_id] = 0
closed_issues = (db.issue.getnode(issue_id) for issue_id in
db.issue.find(status=closed_status))
low_activity_issues = (issue for issue in closed_issues if
has_large_activity_gap(issue, db))
for issue in low_activity_issues:
    resolution2count[issue.resolution] += 1
print 'Low activity tickets (%d days) broken down per resolution
status:' % ACTIVITY_DAY_THRESHOLD
print
for resolution_id, count in resolution2count.items():
    resolution = db.resolution.getnode(resolution_id)
    print '%s\t%d' % (resolution.name, count)

From hsoft at hardcoded.net  Tue Feb 19 10:44:23 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Tue, 19 Feb 2008 10:44:23 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>
	<fpcshr$6ce$2@ger.gmane.org>
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
	<47BA1C14.7090906@v.loewis.de>
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
Message-ID: <2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>

On 2/19/08, Virgil Dupras <hsoft at hardcoded.net> wrote:
> closed_status = db.status.lookup('chatting')

Oops, replace 'chatting' with 'closed'

Virgil

From gnewsg at gmail.com  Tue Feb 19 10:54:26 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Tue, 19 Feb 2008 01:54:26 -0800 (PST)
Subject: [Python-Dev] ssl - how to switch back to a plain text socket?
Message-ID: <1b443341-46a7-4741-858f-b4e99ab2cc9d@72g2000hsu.googlegroups.com>

Hi all,
I'm trying to extend the base ftplib module to add SSL/TLS support as
described in RFC-4217 (see also issue 2054).
RFC-4217 defines a certain command ("CCC") which permit to return to a
plain text socket state without closing the connection.
That is useful since that, being FTP a port-hopping protocol (i.e.
data channels may use a random port chosen during the communication),
firewalls need to read passing packets to allow the secondary data
connections.

I've read through ssl.py but I didn't notice anything useful.
It seems that ssl.SSLSocket class does not provide any method/facility
to switch back to a plain text socket state.

From ncoghlan at gmail.com  Tue Feb 19 12:01:44 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 19 Feb 2008 21:01:44 +1000
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
Message-ID: <47BAB718.4050000@gmail.com>

Brett Cannon wrote:
> My issue with keeping the RFEs in the tracker as they are is that it
> artificially inflates the open issue count. Python does not have over
> 1,700 open bugs.

That's a problem with our status reporting, not with the fact that there 
are RFE's in the issue tracker ;)

Adding a 'bug' keyword to go along with the existing 'rfe' keyword might 
have some merit, allowing separate stats to be reported for 'rfe', 'bug' 
and 'uncategorised' (neither the 'bug' nor the 'rfe' keywords have been 
set).

It may also be interesting to separate out the documentation bugs (based 
on the existing category field), as while those are traps for the unwary 
and need to be fixed, they're easy to deal with once you realise that 
the documentation is wrong.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Tue Feb 19 12:05:07 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 19 Feb 2008 21:05:07 +1000
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <fpe7fe$qr4$1@ger.gmane.org>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<20080218205256.GO81956@nexus.in-nomine.org>	<47B9F44F.7010905@holdenweb.com>
	<fpe7fe$qr4$1@ger.gmane.org>
Message-ID: <47BAB7E3.9000001@gmail.com>

Christian Heimes wrote:
> Steve Holden wrote:
>> There there's the Status field. I understand "open" and "closed", but 
>> what's the semantic of "pending". Is it awaiting triage, awaiting status 
>> assignment, or what?
> 
> I've used pending for two states. For one I've put an issue on pending
> state when it was fixed on the trunk but we haven't decided if the bugs
> needs to be fixed in 2.5 as well. I've also set old bugs as pending to
> give the op a change to reopen the bug within a month.

I've used pending for the former case as well (i.e. when I wanted a 
verdict from the release manager on whether or not to backport a 
particular fix to 2.5, but didn't want the issue hanging around as open 
when I had already fixed it for the trunk).

We really do need to write some of this down in an information track PEP 
so we're all using the same values to mean the same thing...

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From aahz at pythoncraft.com  Tue Feb 19 16:41:54 2008
From: aahz at pythoncraft.com (Aahz)
Date: Tue, 19 Feb 2008 07:41:54 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BAB718.4050000@gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<47BAB718.4050000@gmail.com>
Message-ID: <20080219154154.GA21548@panix.com>

On Tue, Feb 19, 2008, Nick Coghlan wrote:
> Brett Cannon wrote:
>>
>> My issue with keeping the RFEs in the tracker as they are is that it
>> artificially inflates the open issue count. Python does not have over
>> 1,700 open bugs.
> 
> That's a problem with our status reporting, not with the fact that there 
> are RFE's in the issue tracker ;)

+1 -- speaking as someone who has done lots of tech support, I'm a big
fan of the "one database" system.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of     
indirection."  --Butler Lampson

From jjb5 at cornell.edu  Tue Feb 19 16:53:43 2008
From: jjb5 at cornell.edu (Joel Bender)
Date: Tue, 19 Feb 2008 10:53:43 -0500
Subject: [Python-Dev] Optional positional-only parameters (was Re:
	[Python-3000] PEP 3102)
In-Reply-To: <47BAB438.9050504@gmail.com>
References: <20080214174812.AGY90177@ms19.lnh.mail.rcn.net>	<ca471dc20802141513i1f62c9d9mea4deb8d16f10b65@mail.gmail.com>	<f9c7d49c-2807-4f5d-9a97-017de341dbda@60g2000hsy.googlegroups.com>	<47B9DEF9.2070606@acm.org>	<6AF2BB12-ECFE-4B32-A6F8-DE589C49E213@gmail.com>	<aac2c7cb0802181729x4c5ee5f4tc85daa67c6ac379b@mail.gmail.com>
	<47BAB438.9050504@gmail.com>
Message-ID: <47BAFB87.5000507@cornell.edu>

Nick Coghlan wrote:

> We've also veered fairly far off topic for the Py3k list - further ideas 
> for positional-only argument syntax or decorators should probably be 
> kicked around on python-ideas rather than here or python-dev.

For a function specification like this:

     def f(w, x=1, *, y, z=2): ...

My preference is for w and x to be positional only, w is required; y and 
z are keyword only, y is required.

I personally like the idea that for functions like range([start,] stop 
[,step]) that the function describes which combinations of positional 
functions are allowed.  An alternative would be overloading, which I 
would use, albeit rarely:

     def _range(x, y, z): ...
     def range(y): return _range(None, y, None)
     def range(x, y): return _range(x, y, None)
     def range(x, y, z): return _range(x, y, z)

As for this relative nonsense:

     def test([arg1=1, [[*arg2,] arg3=3,]] arg4): ...

Someday I'll dig around in the interpreter enough to make this work, 
just to see what it would be like.  But not today.

 > Another use would be allowing the '_cache trick' with a varargs
 > function, i.e.
 >
 > def f(*args, _cache={}):
 > 	...
 >
 > Personally I don't like this trick though...

My preference for defining persistent variables with a local scope would 
be to introduce a "local" or "static" keyword like "global":

     def f(*args):
         static cache={}
         ...

But I'm sure that that has been discussed before.


Joel

From janssen at parc.com  Tue Feb 19 17:42:04 2008
From: janssen at parc.com (Bill Janssen)
Date: Tue, 19 Feb 2008 08:42:04 PST
Subject: [Python-Dev] ssl - how to switch back to a plain text socket?
In-Reply-To: <1b443341-46a7-4741-858f-b4e99ab2cc9d@72g2000hsu.googlegroups.com>
References: <1b443341-46a7-4741-858f-b4e99ab2cc9d@72g2000hsu.googlegroups.com>
Message-ID: <08Feb19.084213pst."58696"@synergy1.parc.xerox.com>

> I've read through ssl.py but I didn't notice anything useful.
> It seems that ssl.SSLSocket class does not provide any method/facility
> to switch back to a plain text socket state.

I suggest using socket.dup(sslsock) to simply create a non-encrypted
copy of the socket, and switch to using that copy.  There's no way to
"unwrap" an SSLSocket.

Bill

From oliphant.travis at ieee.org  Tue Feb 19 18:10:31 2008
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Tue, 19 Feb 2008 11:10:31 -0600
Subject: [Python-Dev] Error in PEP3118?
In-Reply-To: <e7ba66e40802111327g27ca28b2n8a6bef2e51dd02bc@mail.gmail.com>
References: <47905DAE.9020802@ctypes.org>
	<fn7p9u$7rh$1@ger.gmane.org>	<fn832p$ebb$1@ger.gmane.org>
	<foq804$1iq$1@ger.gmane.org>
	<e7ba66e40802111327g27ca28b2n8a6bef2e51dd02bc@mail.gmail.com>
Message-ID: <fpf2i8$3tp$1@ger.gmane.org>

Lisandro Dalcin wrote:
> On 2/11/08, Travis Oliphant <oliphant.travis at ieee.org> wrote:
>> My perception is that you are seeing too much of a connection between
>> the C-compiler and the PEP description of memory.   Perhaps that's not
>> it, and I'm missing something else.
>>
> 
> Travis, all this make me believe that (perhaps) the 'format'
> specification in the new buffer interface is missing the 'C' or 'F'
> ordering in the case of a countiguos block. I'm missing something? Or
> should we always assume a 'C' ordering?

There is an ability to specify 'F' for the overall buffer.   In the 
description of each element, however, (i.e. in the struct-syntax), the 
multi-dimensional character is always communicated in 'C' order 
(last-dimension varies the fastest).

I thought about adding the ability to specify the multi-dimensional 
order as 'F' in the struct-syntax for each element, but felt against it 
as you can simulate 'F' order by thinking of the array in transpose 
fashion:  i.e.  your 3x5 Fortran-order array is really a 5x3 (C-order 
array).

Of course, the same is true on the larger scale when we are talking 
about multi-dimensional arrays of "elements," but on that level 
connecting with Fortran libraries is much more common and so we have 
found the help useful in NumPy.

-Travis O.


From g.brandl at gmx.net  Tue Feb 19 19:37:25 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 19 Feb 2008 19:37:25 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BAB718.4050000@gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<47BAB718.4050000@gmail.com>
Message-ID: <fpf7gb$mdq$1@ger.gmane.org>

Nick Coghlan schrieb:
> Brett Cannon wrote:
>> My issue with keeping the RFEs in the tracker as they are is that it
>> artificially inflates the open issue count. Python does not have over
>> 1,700 open bugs.
> 
> That's a problem with our status reporting, not with the fact that there 
> are RFE's in the issue tracker ;)
> 
> Adding a 'bug' keyword to go along with the existing 'rfe' keyword might 
> have some merit, allowing separate stats to be reported for 'rfe', 'bug' 
> and 'uncategorised' (neither the 'bug' nor the 'rfe' keywords have been 
> set).

Problem is, we don't have an 'rfe' keyword anymore :)

Georg


From facundobatista at gmail.com  Tue Feb 19 21:22:52 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Tue, 19 Feb 2008 18:22:52 -0200
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <fpf7gb$mdq$1@ger.gmane.org>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<47BAB718.4050000@gmail.com> <fpf7gb$mdq$1@ger.gmane.org>
Message-ID: <e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>

2008/2/19, Georg Brandl <g.brandl at gmx.net>:

>
> Problem is, we don't have an 'rfe' keyword anymore :)
>

Shall we grow one again?

What would happen with PEP 42? will it be deprecated?

-- 

.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From lists at cheimes.de  Tue Feb 19 21:41:52 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 19 Feb 2008 21:41:52 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<47BAB718.4050000@gmail.com>
	<fpf7gb$mdq$1@ger.gmane.org>
	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
Message-ID: <47BB3F10.9020004@cheimes.de>

Facundo Batista wrote:
> What would happen with PEP 42? will it be deprecated?

It seems 42 isn't the answer at all. What a shame. *scnr* :)

Christian



From amcnabb at mcnabbs.org  Tue Feb 19 21:30:08 2008
From: amcnabb at mcnabbs.org (Andrew McNabb)
Date: Tue, 19 Feb 2008 13:30:08 -0700
Subject: [Python-Dev] trunk-math
In-Reply-To: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
References: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
Message-ID: <20080219203008.GB22841@mcnabbs.org>

On Fri, Feb 15, 2008 at 10:53:14PM -0500, Mark Dickinson wrote:
>    * New float methods: is_finite, is_inf, is_integer and is_nan.
>    * New cmath functions: phase, polar and rect, isinf and isnan.
>    * New complex method: is_finite.

This may be a dumb question, but is there any particular reason that the
float methods are "is_inf" and "is_nan" but the cmath methods are
"isinf" and "isnan"?

Anyway, this all looks very useful.  Thanks.

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.python.org/pipermail/python-dev/attachments/20080219/271d08b8/attachment-0001.pgp 

From guido at python.org  Tue Feb 19 22:12:53 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 19 Feb 2008 13:12:53 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<47BAB718.4050000@gmail.com> <fpf7gb$mdq$1@ger.gmane.org>
	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
Message-ID: <ca471dc20802191312t667b0e16g66d021250b52bd09@mail.gmail.com>

On Feb 19, 2008 12:22 PM, Facundo Batista <facundobatista at gmail.com> wrote:
> 2008/2/19, Georg Brandl <g.brandl at gmx.net>:
>
> > Problem is, we don't have an 'rfe' keyword anymore :)
>
> Shall we grow one again?

Isn't the RFE type field enough?

> What would happen with PEP 42? will it be deprecated?

I think it wasn't experiment that doesn't seem to have worked all that well.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From dalke at dalkescientific.com  Tue Feb 19 22:38:19 2008
From: dalke at dalkescientific.com (Andrew Dalke)
Date: Tue, 19 Feb 2008 22:38:19 +0100
Subject: [Python-Dev] small Grammar questions
Message-ID: <d78db4cd0802191338m1f220630pda4666c7c087c794@mail.gmail.com>

I'm finishing up a PLY lexer and parser for the current CVS version of
the Python grammar.  As part of it I've been testing a lot of dark
corners in the grammar definition and implementation.  Python 2.5 has
some small and rare problems which I'm pleased to note have been
pretty much fixed in Python 2.6.

I have two questions about the grammar definition.  Here's a
difference between 2.5 and 2.6.

% cat x.py
c = "This is 'c'"
def spam((a) = c):
  print a
spam()

% python2.5 x.py
This is 'c'
% python2.6 x.py
  File "x.py", line 2
    def spam((a) = c):
SyntaxError: non-default argument follows default argument


I don't understand why that's changed.  This shouldn't be a
SyntaxError and there is no non-default argument following the default
argument.

Note that this is still valid

>>> def spam((a,) = c):
...   pass
...

I think 2.6 is incorrect.  According to the documentation at
  http://docs.python.org/ref/function.html

defparameter	::=	parameter ["=" expression]
sublist	::=	parameter ("," parameter)* [","]
parameter	::=	identifier | "(" sublist ")"
funcname	::=	identifier


Second question is about trailing commas in list comprehension.  I
don't understand why the commented out line is not allowed.

[x for x in 1]
#[x for x in 1,]  # This isn't legal
[x for x in 1,2]
[x for x in 1,2,]
[x for x in 1,2,3]

The Grammar file says

# Backward compatibility cruft to support:
# [ x for x in lambda: True, lambda: False if x() ]
# even while also allowing:
# lambda x: 5 if x else 2
# (But not a mix of the two)
testlist_safe: old_test [(',' old_test)+ [',']]

but if I change it to also allow

    testlist_safe : old_test ','

then PLY still doesn't report any ambiguities in the grammar and I
can't find an expression that exhibits a problem.

Could someone here enlighten me?

                                Andrew
                                dalke at dalkescientific.com

From martin at v.loewis.de  Tue Feb 19 23:47:09 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 19 Feb 2008 23:47:09 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BAB7E3.9000001@gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<20080218205256.GO81956@nexus.in-nomine.org>	<47B9F44F.7010905@holdenweb.com>	<fpe7fe$qr4$1@ger.gmane.org>
	<47BAB7E3.9000001@gmail.com>
Message-ID: <47BB5C6D.3060301@v.loewis.de>

> We really do need to write some of this down in an information track PEP 
> so we're all using the same values to mean the same thing...

There is actually an official meaning to pending: An issue marked 
pending will get automatically closed by the tracker after some period
of time (which used to be two weeks on SF). The tracker will add a 
message that the issue was closed because of inactivity.

Unfortunately, that feature is not yet implemented.

Regards,
Martin

From musiccomposition at gmail.com  Tue Feb 19 23:47:45 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Tue, 19 Feb 2008 16:47:45 -0600
Subject: [Python-Dev] Nosy lists on issue tracker.
Message-ID: <1afaf6160802191447x30d9ca97s63551f20a381efc@mail.gmail.com>

Hi,
What is the policy regarding nosy lists? Is it appropriate it add people to
it besides oneself? As I cannot assign items, I'm sometimes tempted to add
someone relevant to the list. (ie Should I add Georg to documentation
related issues?)

Thanks for your patience,
Benjamin

-- 
Benjamin Peterson
Composer, Clarinetist, Programmer, Wikipedian, Food enthusiast, and
full-time student
"Nothing is more beautiful than an oboe; unless it's a chicken stuck in a
vacuum cleaner"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080219/849638ae/attachment.htm 

From martin at v.loewis.de  Tue Feb 19 23:49:00 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 19 Feb 2008 23:49:00 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<47BAB718.4050000@gmail.com>
	<fpf7gb$mdq$1@ger.gmane.org>
	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
Message-ID: <47BB5CDC.60705@v.loewis.de>

>> Problem is, we don't have an 'rfe' keyword anymore :)
>>
> 
> Shall we grow one again?

What's wrong with the rfe type? Why does it have to be a keyword?

Regards,
Martin

From martin at v.loewis.de  Tue Feb 19 23:58:26 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 19 Feb 2008 23:58:26 +0100
Subject: [Python-Dev] ssl - how to switch back to a plain text socket?
In-Reply-To: <08Feb19.084213pst."58696"@synergy1.parc.xerox.com>
References: <1b443341-46a7-4741-858f-b4e99ab2cc9d@72g2000hsu.googlegroups.com>
	<08Feb19.084213pst."58696"@synergy1.parc.xerox.com>
Message-ID: <47BB5F12.4040706@v.loewis.de>

> I suggest using socket.dup(sslsock) to simply create a non-encrypted
> copy of the socket, and switch to using that copy.  There's no way to
> "unwrap" an SSLSocket.

But shouldn't there be a way to invoke SSL_shutdown? You need to get
the close_notify alert message sent, IIUC.

Regards,
Martin

From martin at v.loewis.de  Wed Feb 20 00:06:22 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 20 Feb 2008 00:06:22 +0100
Subject: [Python-Dev] Nosy lists on issue tracker.
In-Reply-To: <1afaf6160802191447x30d9ca97s63551f20a381efc@mail.gmail.com>
References: <1afaf6160802191447x30d9ca97s63551f20a381efc@mail.gmail.com>
Message-ID: <47BB60EE.5020305@v.loewis.de>

> What is the policy regarding nosy lists? Is it appropriate it add people 
> to it besides oneself? As I cannot assign items, I'm sometimes tempted 
> to add someone relevant to the list. (ie Should I add Georg to 
> documentation related issues?)

I would find it appropriate. In theory, there should be auto-assignment,
but that isn't really implemented, and I don't know whether Georg would
want to be auto-assigned Documentation or Sphinx issues.

It would also be possible to grant users the permission to assign, but
given the experience on SF, I'd rather not (users tend to assign their
issues to core developers in the hopes of expediting processing of
the issue, not realizing that assignment often impedes processing).

Regards,
Martin

From brett at python.org  Wed Feb 20 00:29:23 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 19 Feb 2008 15:29:23 -0800
Subject: [Python-Dev] small Grammar questions
In-Reply-To: <d78db4cd0802191338m1f220630pda4666c7c087c794@mail.gmail.com>
References: <d78db4cd0802191338m1f220630pda4666c7c087c794@mail.gmail.com>
Message-ID: <bbaeab100802191529o610aabc8p4282c84584010b58@mail.gmail.com>

On Feb 19, 2008 1:38 PM, Andrew Dalke <dalke at dalkescientific.com> wrote:
> I'm finishing up a PLY lexer and parser for the current CVS version of
> the Python grammar.  As part of it I've been testing a lot of dark
> corners in the grammar definition and implementation.  Python 2.5 has
> some small and rare problems which I'm pleased to note have been
> pretty much fixed in Python 2.6.
>
> I have two questions about the grammar definition.  Here's a
> difference between 2.5 and 2.6.
>
> % cat x.py
> c = "This is 'c'"
> def spam((a) = c):
>   print a
> spam()
>
> % python2.5 x.py
> This is 'c'
> % python2.6 x.py
>   File "x.py", line 2
>     def spam((a) = c):
> SyntaxError: non-default argument follows default argument
>
>
> I don't understand why that's changed.  This shouldn't be a
> SyntaxError and there is no non-default argument following the default
> argument.
>

The error might be odd, but I don't see why that should be allowed
syntax. Having a parameter surrounded by a parentheses like that makes
no sense in a context of a place where arbitrary expressions are not
allowed.

> Note that this is still valid
>
> >>> def spam((a,) = c):
> ...   pass
> ...
>
> I think 2.6 is incorrect.  According to the documentation at
>   http://docs.python.org/ref/function.html
>
> defparameter    ::=     parameter ["=" expression]
> sublist ::=     parameter ("," parameter)* [","]
> parameter       ::=     identifier | "(" sublist ")"
> funcname        ::=     identifier

Looking at Grammar/Grammar, the relevant rules are::

  parameters: '(' [varargslist] ')'
  varargslist: ((fpdef ['=' test] ',')*
              ('*' NAME [',' '**' NAME] | '**' NAME) |
              fpdef ['=' test] (',' fpdef ['=' test])* [','])
  fpdef: NAME | '(' fplist ')'
  fplist: fpdef (',' fpdef)* [',']

>From what I can tell the grammar does not prevent it. But it is
possible that during AST creation or bytecode compilation a specific
check is made that is throwing the exception...

And checking Python.ast.c:672 seems to suggest it is something the AST
is doing. I don't have time to dig deeper, but if you tried ``svn
blame`` and found out when that line was added the log message give
some clues as to why this is occurring.

>
>
> Second question is about trailing commas in list comprehension.  I
> don't understand why the commented out line is not allowed.
>
> [x for x in 1]
> #[x for x in 1,]  # This isn't legal
> [x for x in 1,2]
> [x for x in 1,2,]
> [x for x in 1,2,3]
>
> The Grammar file says
>
> # Backward compatibility cruft to support:
> # [ x for x in lambda: True, lambda: False if x() ]
> # even while also allowing:
> # lambda x: 5 if x else 2
> # (But not a mix of the two)
> testlist_safe: old_test [(',' old_test)+ [',']]
>
> but if I change it to also allow
>
>     testlist_safe : old_test ','
>
> then PLY still doesn't report any ambiguities in the grammar and I
> can't find an expression that exhibits a problem.
>
> Could someone here enlighten me?
>

Are you asking why the decision was made to make the expression
illegal, or why the grammar is flagging it is wrong?

-Brett

From dalke at dalkescientific.com  Wed Feb 20 00:58:26 2008
From: dalke at dalkescientific.com (Andrew Dalke)
Date: Wed, 20 Feb 2008 00:58:26 +0100
Subject: [Python-Dev] small Grammar questions
In-Reply-To: <bbaeab100802191529o610aabc8p4282c84584010b58@mail.gmail.com>
References: <d78db4cd0802191338m1f220630pda4666c7c087c794@mail.gmail.com>
	<bbaeab100802191529o610aabc8p4282c84584010b58@mail.gmail.com>
Message-ID: <d78db4cd0802191558g32d989ffxe807789477581ef6@mail.gmail.com>

On Feb 19, 2008 1:38 PM, Andrew Dalke <dalke at dalkescientific.com> wrote:
> def spam((a) = c):
>   print a

On Feb 20, 2008 12:29 AM, Brett Cannon <brett at python.org> wrote:
> The error might be odd, but I don't see why that should be allowed
> syntax. Having a parameter surrounded by a parentheses like that makes
> no sense in a context of a place where arbitrary expressions are not
> allowed.

I'm fine with that.  This is a corner that no one but language lawyers
will care about.  The thing is, the online documentation and the
Grammar file allow it, as did Python 2.5.

In any case, the error message is not helpful.

> From what I can tell the grammar does not prevent it. But it is
> possible that during AST creation or bytecode compilation a specific
> check is made that is throwing the exception...

In my code it's during AST generation...  Your pointer to ast.c:672
was helpful.  It's stuff  jeremy.hylton did in r54415.  Now I have to
figure out how Python's internal ASTs work..  Which might take a
while.

> Are you asking why the decision was made to make the expression
> illegal, or why the grammar is flagging it is wrong?

Why it's illegal.  Supporting a comma doesn't seem to make anything
ambiguous, but PLY's LALR(1) might handle things that Python itself
doesn't and I don't have the experience to tell.

There are other places where the grammar definition allows syntax that
is rejected later on.  Those I can justify by saying it's easier to
define the grammar that way (hence f(1+1=2) is legal grammar but
illegal Python), or to produce better error messages (like "from .a
import *").

But this one prohibiting [x for x in 1,] I can't figure out.


       Andrew
       dalke at dalkescientific.com

From stephen at xemacs.org  Wed Feb 20 01:24:10 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 20 Feb 2008 09:24:10 +0900
Subject: [Python-Dev] Nosy lists on issue tracker.
In-Reply-To: <47BB60EE.5020305@v.loewis.de>
References: <1afaf6160802191447x30d9ca97s63551f20a381efc@mail.gmail.com>
	<47BB60EE.5020305@v.loewis.de>
Message-ID: <87odacwk45.fsf@uwakimon.sk.tsukuba.ac.jp>

"Martin v. L?wis" writes:

 > > What is the policy regarding nosy lists? Is it appropriate it add people 
 > > to it besides oneself? As I cannot assign items, I'm sometimes tempted 
 > > to add someone relevant to the list. (ie Should I add Georg to 
 > > documentation related issues?)
 > 
 > I would find it appropriate.

My personal feeling is that it depends on the person.  Some people may
be prefer to "pull" their issues by searching the tracker regularly,
or to read the regular Tracker reports.

Overall, in my own project I want developers to think of the tracker
as their friend, as an aid to getting the work done that they want
done, rather than as a proxy nanny looking out for user interests.
The problem of looking out for user interests is important, but IMO a
nanny tracker would be counterproductive (nb I have no experience to
back that up).  I intend to address that by further encouraging
developers to "own" the users' problems.

 > In theory, there should be auto-assignment, but that isn't really
 > implemented, and I don't know whether Georg would want to be
 > auto-assigned Documentation or Sphinx issues.

I haven't looked closely at the Python tracker, but I noticed that you
have a "busybody" detector.  I thought that requesting to be on the
nosy list was what this detector was for?


From janssen at parc.com  Wed Feb 20 02:54:29 2008
From: janssen at parc.com (Bill Janssen)
Date: Tue, 19 Feb 2008 17:54:29 PST
Subject: [Python-Dev] ssl - how to switch back to a plain text socket?
In-Reply-To: <47BB5F12.4040706@v.loewis.de> 
References: <1b443341-46a7-4741-858f-b4e99ab2cc9d@72g2000hsu.googlegroups.com>
	<08Feb19.084213pst."58696"@synergy1.parc.xerox.com>
	<47BB5F12.4040706@v.loewis.de>
Message-ID: <08Feb19.175434pst."58696"@synergy1.parc.xerox.com>

> But shouldn't there be a way to invoke SSL_shutdown? You need to get
> the close_notify alert message sent, IIUC.

Perhaps that would be nice, but switching to plain-text use of the
socket can be coordinated outside the SSL protocol.  I had an accessor
for SSL_shutdown, in an earlier version, but there were semantic
conflicts with the socket shutdown() method, and I didn't think anyone
would use it anyway :-).

Bill

From steve at holdenweb.com  Wed Feb 20 03:08:07 2008
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 19 Feb 2008 21:08:07 -0500
Subject: [Python-Dev] small Grammar questions
In-Reply-To: <d78db4cd0802191558g32d989ffxe807789477581ef6@mail.gmail.com>
References: <d78db4cd0802191338m1f220630pda4666c7c087c794@mail.gmail.com>	<bbaeab100802191529o610aabc8p4282c84584010b58@mail.gmail.com>
	<d78db4cd0802191558g32d989ffxe807789477581ef6@mail.gmail.com>
Message-ID: <fpg225$hm9$1@ger.gmane.org>

Andrew Dalke wrote:
> On Feb 19, 2008 1:38 PM, Andrew Dalke <dalke at dalkescientific.com> wrote:
>> def spam((a) = c):
>>   print a
> 
> On Feb 20, 2008 12:29 AM, Brett Cannon <brett at python.org> wrote:
[..]
>> Are you asking why the decision was made to make the expression
>> illegal, or why the grammar is flagging it is wrong?
> 
> Why it's illegal.  Supporting a comma doesn't seem to make anything
> ambiguous, but PLY's LALR(1) might handle things that Python itself
> doesn't and I don't have the experience to tell.
> 
It's illegal, in short, because formal parameters can be names or 
tuples, and a parenthesized expression (albeit one containing only a 
single term) is neither.

You could argue that parenthesizing a name shouldn't turn it into a 
value, but to me there does seem to be a significant difference between 
a and (a) - in Algol 68 terms, the former can be dereferenced 
automatically while the latter cannot.

It's a pretty fine hair to split, though.

> There are other places where the grammar definition allows syntax that
> is rejected later on.  Those I can justify by saying it's easier to
> define the grammar that way (hence f(1+1=2) is legal grammar but
> illegal Python), or to produce better error messages (like "from .a
> import *").
> 
> But this one prohibiting [x for x in 1,] I can't figure out.
> 
The one that surprised me was the legality of

     def eggs((a, )=c):
         pass

That just seems like unpacking-abuse to me.

You might argue that c might be a singleton tuple, though that is known 
when the definition is processed, but there's no way you can say the 
same of a float.

Python 2.5.1 (r251:54863, May 18 2007, 16:56:43)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> def eggs((a, )=2.1):
...   pass
...
 >>>

Oops. 'def eggs((a, )=(2.1, )):' I'd have gone for, but your example 
just seems broken. You really *have* been poking around in little-known 
crevices, haven't you?

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From facundobatista at gmail.com  Wed Feb 20 03:08:24 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Wed, 20 Feb 2008 00:08:24 -0200
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BB5CDC.60705@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<47BAB718.4050000@gmail.com> <fpf7gb$mdq$1@ger.gmane.org>
	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
	<47BB5CDC.60705@v.loewis.de>
Message-ID: <e04bdf310802191808m4f55cae6j2393bdc0eacd4748@mail.gmail.com>

2008/2/19, "Martin v. L?wis" <martin at v.loewis.de>:

> >> Problem is, we don't have an 'rfe' keyword anymore :)
> >
> > Shall we grow one again?
>
> What's wrong with the rfe type? Why does it have to be a keyword?

For me, none. I'm just trying to converge the mail thread to a result, :)

As far as I can see, the place to keep a RFE is the Issue tracker, and
in the future we should decide if we deprecate the PEP 42 and move
those items to the tracker.

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From steve at holdenweb.com  Wed Feb 20 03:15:35 2008
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 19 Feb 2008 21:15:35 -0500
Subject: [Python-Dev] small Grammar questions
In-Reply-To: <fpg225$hm9$1@ger.gmane.org>
References: <d78db4cd0802191338m1f220630pda4666c7c087c794@mail.gmail.com>	<bbaeab100802191529o610aabc8p4282c84584010b58@mail.gmail.com>	<d78db4cd0802191558g32d989ffxe807789477581ef6@mail.gmail.com>
	<fpg225$hm9$1@ger.gmane.org>
Message-ID: <fpg2g4$hm9$2@ger.gmane.org>

Steve Holden wrote:
[...]
> The one that surprised me was the legality of
> 
>      def eggs((a, )=c):
>          pass
> 
> That just seems like unpacking-abuse to me.
> 
Needless to say, a call that tries to *use* the default value fails 
horribly, as the parameter form does require an iterable:

 >>> def eggs((a, )=2.1):
...   pass
...
 >>> eggs()
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<stdin>", line 1, in eggs
TypeError: 'float' object is not iterable
 >>> eggs((2.1, ))
 >>>

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From martin at v.loewis.de  Wed Feb 20 04:57:52 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 20 Feb 2008 04:57:52 +0100
Subject: [Python-Dev] ssl - how to switch back to a plain text socket?
In-Reply-To: <08Feb19.175434pst."58696"@synergy1.parc.xerox.com>
References: <1b443341-46a7-4741-858f-b4e99ab2cc9d@72g2000hsu.googlegroups.com>	<08Feb19.084213pst."58696"@synergy1.parc.xerox.com>	<47BB5F12.4040706@v.loewis.de>
	<08Feb19.175434pst."58696"@synergy1.parc.xerox.com>
Message-ID: <47BBA540.8020105@v.loewis.de>

> Perhaps that would be nice, but switching to plain-text use of the
> socket can be coordinated outside the SSL protocol.  I had an accessor
> for SSL_shutdown, in an earlier version, but there were semantic
> conflicts with the socket shutdown() method, and I didn't think anyone
> would use it anyway :-).

IIUC, RFC 4217 mandates that a TLS shutdown is exchanged (although they
apparently didn't read the TLS spec when they wrote the RFC, as the
TLS RFC doesn't seem to have a protocol primitive called TLSShutdow()).
If the protocol mandates it, coordinating switching to plain-text 
outside the SSL protocol is no option, no?

Regards,
Martin

From martin at v.loewis.de  Wed Feb 20 05:00:23 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 20 Feb 2008 05:00:23 +0100
Subject: [Python-Dev] Nosy lists on issue tracker.
In-Reply-To: <87odacwk45.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <1afaf6160802191447x30d9ca97s63551f20a381efc@mail.gmail.com>	<47BB60EE.5020305@v.loewis.de>
	<87odacwk45.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <47BBA5D7.1080504@v.loewis.de>

> I haven't looked closely at the Python tracker, but I noticed that you
> have a "busybody" detector.  I thought that requesting to be on the
> nosy list was what this detector was for?

No. We also have a mailing list (python-bugs) to which any tracker 
change is mailed. That's the busybody list.

Regards,
Martin

From dalke at dalkescientific.com  Wed Feb 20 05:07:02 2008
From: dalke at dalkescientific.com (Andrew Dalke)
Date: Wed, 20 Feb 2008 05:07:02 +0100
Subject: [Python-Dev] small Grammar questions
In-Reply-To: <fpg225$hm9$1@ger.gmane.org>
References: <d78db4cd0802191338m1f220630pda4666c7c087c794@mail.gmail.com>
	<bbaeab100802191529o610aabc8p4282c84584010b58@mail.gmail.com>
	<d78db4cd0802191558g32d989ffxe807789477581ef6@mail.gmail.com>
	<fpg225$hm9$1@ger.gmane.org>
Message-ID: <d78db4cd0802192007h6f32fecaqe13bb9ce2b737655@mail.gmail.com>

Okay, my conclusion is

  def f((a)=5)

is wrong, and the code should be changed to report a better error
message.  I'll file a bug against that.

and I'm going with Brett suggestion that

  [x for x in 1,]

is not supported because it's almost certainly a programming error.  I
think therefore the comment in the Grammar file is distracting.  As
comments can be.


On Feb 20, 2008 3:08 AM, Steve Holden <steve at holdenweb.com> wrote:
> The one that surprised me was the legality of
>
>      def eggs((a, )=c):
>          pass
>
> That just seems like unpacking-abuse to me.

Yep.  Here's another abuse, since I can't figure when someone needs a
destructuring del statement.

>>> class X(object): pass
...
>>> X.a = 123
>>> X.b = "hello"
>>> X.c = 9.801
>>> X.a, X.b, X.c
(123, 'hello', 9.8010000000000002)
>>> del (X.a, (X.b, (X.c,)))
>>> X.a, X.b, X.c
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'X' has no attribute 'a'
>>>

Is this going to be possible in Python3k?

> You really *have* been poking around in little-known crevices, haven't you?

Like this bug from 2.5, fixed in 2.6

>>> from __future__ import with_statement
>>> with f(x=5, 6):
...   pass
...
ValueError: field context_expr is required for With

  :)

        Andrew
        dalke at dalkescientific.com

From brett at python.org  Wed Feb 20 05:37:09 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 19 Feb 2008 20:37:09 -0800
Subject: [Python-Dev] small Grammar questions
In-Reply-To: <fpg2g4$hm9$2@ger.gmane.org>
References: <d78db4cd0802191338m1f220630pda4666c7c087c794@mail.gmail.com>
	<bbaeab100802191529o610aabc8p4282c84584010b58@mail.gmail.com>
	<d78db4cd0802191558g32d989ffxe807789477581ef6@mail.gmail.com>
	<fpg225$hm9$1@ger.gmane.org> <fpg2g4$hm9$2@ger.gmane.org>
Message-ID: <bbaeab100802192037w1749a7fbga01e8a065167d686@mail.gmail.com>

On Feb 19, 2008 6:15 PM, Steve Holden <steve at holdenweb.com> wrote:
> Steve Holden wrote:
> [...]
> > The one that surprised me was the legality of
> >
> >      def eggs((a, )=c):
> >          pass
> >
> > That just seems like unpacking-abuse to me.
> >
> Needless to say, a call that tries to *use* the default value fails
> horribly, as the parameter form does require an iterable:
>
>  >>> def eggs((a, )=2.1):
> ...   pass
> ...
>  >>> eggs()
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "<stdin>", line 1, in eggs
> TypeError: 'float' object is not iterable
>  >>> eggs((2.1, ))
>
>  >>>

And this is another reason why they will not appear in Python 3.0.

-Brett

From janssen at parc.com  Wed Feb 20 06:08:58 2008
From: janssen at parc.com (Bill Janssen)
Date: Tue, 19 Feb 2008 21:08:58 PST
Subject: [Python-Dev] ssl - how to switch back to a plain text socket?
In-Reply-To: <47BBA540.8020105@v.loewis.de> 
References: <1b443341-46a7-4741-858f-b4e99ab2cc9d@72g2000hsu.googlegroups.com>
	<08Feb19.084213pst."58696"@synergy1.parc.xerox.com>
	<47BB5F12.4040706@v.loewis.de>
	<08Feb19.175434pst."58696"@synergy1.parc.xerox.com>
	<47BBA540.8020105@v.loewis.de>
Message-ID: <08Feb19.210901pst."58696"@synergy1.parc.xerox.com>

> IIUC, RFC 4217 mandates that a TLS shutdown is exchanged (although they
> apparently didn't read the TLS spec when they wrote the RFC, as the

I'm pretty dubious about section 5 there.  I don't think reverting to
a plaintext state, once you've been in TLS, happens in real life to
real connections being used for FTP.

Bill

From fdrake at acm.org  Wed Feb 20 06:49:16 2008
From: fdrake at acm.org (Fred Drake)
Date: Wed, 20 Feb 2008 00:49:16 -0500
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <20080218182132.GM81956@nexus.in-nomine.org>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
Message-ID: <D99DD9CE-A18B-4F8D-861A-919EEBA05C93@acm.org>

On Feb 18, 2008, at 1:21 PM, Jeroen Ruigrok van der Werven wrote:
> A bug tracker is a much better way of registering such information.  
> It also
> can be easier referenced in the future since even though when it is  
> closed,
> the debate and other stuff will remain in the tracker's tickets for
> posterity. :)
>
> PEP: -1
> tracker: +1


I agree with Jeroen completely on this.  Using a PEP for this is just  
plain silly.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From g.brandl at gmx.net  Wed Feb 20 08:05:04 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 20 Feb 2008 08:05:04 +0100
Subject: [Python-Dev] Nosy lists on issue tracker.
In-Reply-To: <1afaf6160802191447x30d9ca97s63551f20a381efc@mail.gmail.com>
References: <1afaf6160802191447x30d9ca97s63551f20a381efc@mail.gmail.com>
Message-ID: <fpgja8$sas$1@ger.gmane.org>

Benjamin Peterson schrieb:
> Hi,
> What is the policy regarding nosy lists? Is it appropriate it add people 
> to it besides oneself? As I cannot assign items, I'm sometimes tempted 
> to add someone relevant to the list. (ie Should I add Georg to 
> documentation related issues?)

In my case, yes please.

Georg


From lists at cheimes.de  Wed Feb 20 08:40:47 2008
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 20 Feb 2008 08:40:47 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BB5CDC.60705@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<47BAB718.4050000@gmail.com>	<fpf7gb$mdq$1@ger.gmane.org>	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
	<47BB5CDC.60705@v.loewis.de>
Message-ID: <fpglhv$2cf$1@ger.gmane.org>

Martin v. L?wis wrote:
> What's wrong with the rfe type? Why does it have to be a keyword?

For one it's the name. Personally I didn't know the meaning of RFE until
I googled it.

Christian


From qgallet at gmail.com  Wed Feb 20 09:25:19 2008
From: qgallet at gmail.com (Quentin Gallet-Gilles)
Date: Wed, 20 Feb 2008 09:25:19 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <fpglhv$2cf$1@ger.gmane.org>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>
	<20080218182132.GM81956@nexus.in-nomine.org>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<47BAB718.4050000@gmail.com> <fpf7gb$mdq$1@ger.gmane.org>
	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
	<47BB5CDC.60705@v.loewis.de> <fpglhv$2cf$1@ger.gmane.org>
Message-ID: <8b943f2b0802200025h6fa7fb03q13bacde16b0cbd82@mail.gmail.com>

On Wed, Feb 20, 2008 at 8:40 AM, Christian Heimes <lists at cheimes.de> wrote:

> Martin v. L?wis wrote:
> > What's wrong with the rfe type? Why does it have to be a keyword?
>
> For one it's the name. Personally I didn't know the meaning of RFE until
> I googled it.
>

I agree, the name is a bit confusing when you're not used to it.
Also I find that, by definition, RFE and feature requests are not exactly
the same. There's a thin line between a new feature and an enhancement that
is supposed to fill a gap/improve things. Should they really be treated the
same way ?

Quentin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080220/0bf54a31/attachment.htm 

From ncoghlan at gmail.com  Wed Feb 20 10:27:41 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 20 Feb 2008 19:27:41 +1000
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BB5CDC.60705@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<47BAB718.4050000@gmail.com>	<fpf7gb$mdq$1@ger.gmane.org>	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
	<47BB5CDC.60705@v.loewis.de>
Message-ID: <47BBF28D.4060706@gmail.com>

Martin v. L?wis wrote:
>>> Problem is, we don't have an 'rfe' keyword anymore :)
>>>
>> Shall we grow one again?
> 
> What's wrong with the rfe type? Why does it have to be a keyword?

It must have changed since I last looked at a feature request on the 
tracker - using a type rather than keyword is fine by me.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From andymac at bullseye.apana.org.au  Wed Feb 20 13:56:21 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Wed, 20 Feb 2008 22:56:21 +1000
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47B2FE88.5090503@bullseye.andymac.org>
References: <47AB02F9.1010501@bullseye.andymac.org>	<fofesd$2pd$1@ger.gmane.org>	<47AC40E9.2060505@bullseye.andymac.org>	<47AC9F69.6020404@cheimes.de>	<47ACE628.60607@bullseye.andymac.org>	<foo9i1$sn6$2@ger.gmane.org>	<47B2584A.30704@bullseye.andymac.org>	<47B29B03.3030402@cheimes.de>	<47B2DAEF.5040003@bullseye.andymac.org>	<47B2DF4E.201@egenix.com>
	<47B2FE88.5090503@bullseye.andymac.org>
Message-ID: <47BC2375.2070307@bullseye.andymac.org>

Andrew MacIntyre wrote:
> M.-A. Lemburg wrote:
>> If we're down to voting, here's my vote:
>>
>> +1 on removing the freelists from ints and floats, but not the
>>    small int sharing optimization
>>
>> +1 on focusing on improving pymalloc to handle int and float
>>    object allocations even better
>>
>> -1 on changing the freelist implementations to use pymalloc for
>>    allocation of the freelist members instead of malloc, since
>>    this would potentially lead to pools (and arenas) being held alive
>>    by just a few objects - in the worst case a whole arena (256kB)
>>    for just one int object (14 bytes on 32bit platforms).
>>
>> Eventually, all freelists should be removed, unless there's a
>> significant performance loss.
 >
> Sigh...  things are never as simple as they seem...
> 
> Prompted by your comment about the small int sharing, which I was aware 
> of and was not addressing because I was assuming that its value was 
> unimpeachable, I've been doing some more testing with this and the
> freelists.
> 
> I don't have time to write it up tonight, but I've concluded that my 
> original test scripts and other tests weren't showing the real
> performance of the various approaches.  Platform (architecture, compiler
> etc) oddities & differences complicate life too...

I've now written up my testing and attached the write-up to issue 2039
(http://bugs.python.org/issue2039).

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

From gnewsg at gmail.com  Wed Feb 20 13:51:21 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Wed, 20 Feb 2008 04:51:21 -0800 (PST)
Subject: [Python-Dev] ssl - how to switch back to a plain text socket?
In-Reply-To: <08Feb19.210901pst."58696"@synergy1.parc.xerox.com>
References: <1b443341-46a7-4741-858f-b4e99ab2cc9d@72g2000hsu.googlegroups.com>
	<08Feb19.084213pst."58696"@synergy1.parc.xerox.com>
	<47BB5F12.4040706@v.loewis.de> 
	<08Feb19.175434pst."58696"@synergy1.parc.xerox.com>
	<47BBA540.8020105@v.loewis.de> 
	<08Feb19.210901pst."58696"@synergy1.parc.xerox.com>
Message-ID: <b9873c80-7b84-4070-b0f1-4a3c707aeb57@q33g2000hsh.googlegroups.com>

On 20 Feb, 06:08, Bill Janssen <jans... at parc.com> wrote:
> I suggest using socket.dup(sslsock) to simply create a non-encrypted
> copy of the socket, and switch to using that copy.  There's no way to
> "unwrap" an SSLSocket.

It does not seem to work:

 File "C:\python26\lib\ssl.py", line 115, in read
   return self._sslobj.read(len)
ssl.SSLError: [Errno 1] _ssl.c:1276: error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number


> > IIUC, RFC 4217 mandates that a TLS shutdown is exchanged (although they
> > apparently didn't read the TLS spec when they wrote the RFC, as the
>
> I'm pretty dubious about section 5 there.  I don't think reverting to
> a plaintext state, once you've been in TLS, happens in real life to
> real connections being used for FTP.
>
> Bill

I'm not sure, I've seen more than one library and server supporting
the CCC command.
For example proftpd and tnftpd servers support it.

From aahz at pythoncraft.com  Wed Feb 20 15:15:08 2008
From: aahz at pythoncraft.com (Aahz)
Date: Wed, 20 Feb 2008 06:15:08 -0800
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47BC2375.2070307@bullseye.andymac.org>
References: <47AC40E9.2060505@bullseye.andymac.org>
	<47AC9F69.6020404@cheimes.de> <47ACE628.60607@bullseye.andymac.org>
	<foo9i1$sn6$2@ger.gmane.org> <47B2584A.30704@bullseye.andymac.org>
	<47B29B03.3030402@cheimes.de>
	<47B2DAEF.5040003@bullseye.andymac.org> <47B2DF4E.201@egenix.com>
	<47B2FE88.5090503@bullseye.andymac.org>
	<47BC2375.2070307@bullseye.andymac.org>
Message-ID: <20080220141508.GA19668@panix.com>

On Wed, Feb 20, 2008, Andrew MacIntyre wrote:
>
> I've now written up my testing and attached the write-up to issue 2039
> (http://bugs.python.org/issue2039).

Nice work!  Too often we (generic we) don't try to re-simplify code.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of     
indirection."  --Butler Lampson

From amk at amk.ca  Wed Feb 20 17:03:06 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Wed, 20 Feb 2008 11:03:06 -0500
Subject: [Python-Dev] Reminder: bug day on Saturday
Message-ID: <20080220160306.GA8632@amk-desktop.matrixgroup.net>

We have a bug day this Saturday.  Join us on IRC and let's see how
many issues we can clear up.

http://wiki.python.org/moin/PythonBugDay for more.

There are currently 69 bugs marked as 'easy', which is probably more
than enough, but if you see anything that's suitable for a new
developer, please mark it.

--amk


From ijmorlan at cs.uwaterloo.ca  Wed Feb 20 17:32:54 2008
From: ijmorlan at cs.uwaterloo.ca (Isaac Morland)
Date: Wed, 20 Feb 2008 11:32:54 -0500 (EST)
Subject: [Python-Dev] New math functions
In-Reply-To: <5c6f2a5d0802150527r3ae358d8n28a265615bf36701@mail.gmail.com>
References: <00fe01c86d43$d73acad0$6800a8c0@RaymondLaptop1>
	<5c6f2a5d0802150527r3ae358d8n28a265615bf36701@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0802201114290.260@core.cs.uwaterloo.ca>

On Fri, 15 Feb 2008, Mark Dickinson wrote:

> On Tue, Feb 12, 2008 at 1:52 AM, Raymond Hettinger <python at rcn.com> wrote:
>
>> Also, it would be useful to have a new method, float.is_integer().  This
>> would be better than the current approach where we make the
>> test:  if x == floor(x).
>
> How common is this test?  Given the inexact nature of floating-point
> arithmetic, checking whether a float is exactly an integer seems like
> something that one might actually want to discourage, just like comparing
> two floats for equality.

Depending on the nature of the computations that produced the float 
result, there may be no problem with the result being different from the 
mathematical result.  For example, if you are adding up a bunch of 
multiples of 1/2, a sufficient condition for an exact result is that the 
(mathematical) total of the absolute values of the numbers isn't too big.

After such a computation, meeting the given condition, checking for an 
integer result is guaranteed to be meaningful and to match what is 
mathematically wanted.

I can't say how often one needs to check a float for being an integer.  I 
believe that "x == floor(x)" is equivalent to "not (x % 1)" which also 
generalizes to checking for an exact multiple of values other than 1.

I suspect, but do not have evidence, that circumstances in which it is 
useful to check for an integer are likely to be ones in which there is a 
better-than-usual chance of getting precise float results.  How often are 
you going to check the output of sin() for being an integer?  But on the 
other hand pitfalls will occur if we, for example, replace 1/2 in my 
example with 1/10, since these are not generally representable in float 
format.

Isaac Morland			CSCF Web Guru
DC 2554C, x36650		WWW Software Specialist

From janssen at parc.com  Wed Feb 20 17:39:47 2008
From: janssen at parc.com (Bill Janssen)
Date: Wed, 20 Feb 2008 08:39:47 PST
Subject: [Python-Dev] ssl - how to switch back to a plain text socket?
In-Reply-To: <b9873c80-7b84-4070-b0f1-4a3c707aeb57@q33g2000hsh.googlegroups.com>
References: <1b443341-46a7-4741-858f-b4e99ab2cc9d@72g2000hsu.googlegroups.com>
	<08Feb19.084213pst."58696"@synergy1.parc.xerox.com>
	<47BB5F12.4040706@v.loewis.de>
	<08Feb19.175434pst."58696"@synergy1.parc.xerox.com>
	<47BBA540.8020105@v.loewis.de>
	<08Feb19.210901pst."58696"@synergy1.parc.xerox.com>
	<b9873c80-7b84-4070-b0f1-4a3c707aeb57@q33g2000hsh.googlegroups.com>
Message-ID: <08Feb20.083947pst."58696"@synergy1.parc.xerox.com>

> > I suggest using socket.dup(sslsock) to simply create a non-encrypted
> > copy of the socket, and switch to using that copy.  There's no way to
> > "unwrap" an SSLSocket.
> 
> It does not seem to work:
> 
>  File "C:\python26\lib\ssl.py", line 115, in read
>    return self._sslobj.read(len)
> ssl.SSLError: [Errno 1] _ssl.c:1276: error:1408F10B:SSL
> routines:SSL3_GET_RECORD:wrong version number

You're still reading from the _sslobj.  Don't do that.  Read from the
non-encrypted copy, instead.

Though I don't believe you'll be able to implement the CCC command
this way; the spec specifically says to do the TLS shutdown, and
there's no way to emulate it.

> I'm not sure, I've seen more than one library and server supporting
> the CCC command.
> For example proftpd and tnftpd servers support it.

But does anyone use it?

Bill

From martin at v.loewis.de  Wed Feb 20 21:36:04 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 20 Feb 2008 21:36:04 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <8b943f2b0802200025h6fa7fb03q13bacde16b0cbd82@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<47BAB718.4050000@gmail.com>
	<fpf7gb$mdq$1@ger.gmane.org>	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>	<47BB5CDC.60705@v.loewis.de>
	<fpglhv$2cf$1@ger.gmane.org>
	<8b943f2b0802200025h6fa7fb03q13bacde16b0cbd82@mail.gmail.com>
Message-ID: <47BC8F34.4020601@v.loewis.de>

> I agree, the name is a bit confusing when you're not used to it.

Renaming it is easy. To the native speakers reading it: What should
it be called? (please try to come up with something shorter than
"request for enhancement")

> Also I find that, by definition, RFE and feature requests are not 
> exactly the same. There's a thin line between a new feature and an 
> enhancement that is supposed to fill a gap/improve things. Should they 
> really be treated the same way ?

I don't understand the difference. Can you please explain it? Are there
features that are not enhancements (and if so, why would anybody request
them), or are there enhancements which are not features? Are they 
entirely disjoint sets of things?

Regards,
Martin

From brett at python.org  Wed Feb 20 21:37:42 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 12:37:42 -0800
Subject: [Python-Dev] Reminder: bug day on Saturday
In-Reply-To: <20080220160306.GA8632@amk-desktop.matrixgroup.net>
References: <20080220160306.GA8632@amk-desktop.matrixgroup.net>
Message-ID: <bbaeab100802201237r51f5f130ne6531ec1c2050428@mail.gmail.com>

On Feb 20, 2008 8:03 AM, A.M. Kuchling <amk at amk.ca> wrote:
> We have a bug day this Saturday.  Join us on IRC and let's see how
> many issues we can clear up.
>
> http://wiki.python.org/moin/PythonBugDay for more.
>
> There are currently 69 bugs marked as 'easy', which is probably more
> than enough, but if you see anything that's suitable for a new
> developer, please mark it.

How about marking already submitted patches as easy to get help
reviewing? For instance, there are a bunch of test rewrites to move
old tests to unittest where it would be rather nice to have another
pair of eyes make sure that the tests are thorough enough.

-Brett

From brett at python.org  Wed Feb 20 21:39:01 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 12:39:01 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BC8F34.4020601@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<47BAB718.4050000@gmail.com> <fpf7gb$mdq$1@ger.gmane.org>
	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
	<47BB5CDC.60705@v.loewis.de> <fpglhv$2cf$1@ger.gmane.org>
	<8b943f2b0802200025h6fa7fb03q13bacde16b0cbd82@mail.gmail.com>
	<47BC8F34.4020601@v.loewis.de>
Message-ID: <bbaeab100802201239w224fb604s39343cccc2d2633@mail.gmail.com>

On Feb 20, 2008 12:36 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > I agree, the name is a bit confusing when you're not used to it.
>
> Renaming it is easy. To the native speakers reading it: What should
> it be called? (please try to come up with something shorter than
> "request for enhancement")
>

"feature request"?

> > Also I find that, by definition, RFE and feature requests are not
> > exactly the same. There's a thin line between a new feature and an
> > enhancement that is supposed to fill a gap/improve things. Should they
> > really be treated the same way ?
>
> I don't understand the difference. Can you please explain it? Are there
> features that are not enhancements (and if so, why would anybody request
> them), or are there enhancements which are not features? Are they
> entirely disjoint sets of things?
>

The differences are so minimal that it feels like squabbling over
minute semantics.

-Brett

From martin at v.loewis.de  Wed Feb 20 21:41:07 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 20 Feb 2008 21:41:07 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BBF28D.4060706@gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<47BAB718.4050000@gmail.com>	<fpf7gb$mdq$1@ger.gmane.org>	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>	<47BB5CDC.60705@v.loewis.de>
	<47BBF28D.4060706@gmail.com>
Message-ID: <47BC9063.5080004@v.loewis.de>

> It must have changed since I last looked at a feature request on the 
> tracker - using a type rather than keyword is fine by me.

I'm fairly certain the rfe type was there ever since the switchover
(at least that's what subversion says: the rfe type was added along
with all other types in r52825, on 2006-11-23).

Regards,
Martin

From guido at python.org  Wed Feb 20 21:43:09 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 20 Feb 2008 12:43:09 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <bbaeab100802201239w224fb604s39343cccc2d2633@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<47BAB718.4050000@gmail.com> <fpf7gb$mdq$1@ger.gmane.org>
	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
	<47BB5CDC.60705@v.loewis.de> <fpglhv$2cf$1@ger.gmane.org>
	<8b943f2b0802200025h6fa7fb03q13bacde16b0cbd82@mail.gmail.com>
	<47BC8F34.4020601@v.loewis.de>
	<bbaeab100802201239w224fb604s39343cccc2d2633@mail.gmail.com>
Message-ID: <ca471dc20802201243k3fc751b5j734fafe392cd8032@mail.gmail.com>

On Feb 20, 2008 12:39 PM, Brett Cannon <brett at python.org> wrote:
> On Feb 20, 2008 12:36 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > > I agree, the name is a bit confusing when you're not used to it.
> >
> > Renaming it is easy. To the native speakers reading it: What should
> > it be called? (please try to come up with something shorter than
> > "request for enhancement")
>
> "feature request"?

+1

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From amk at amk.ca  Wed Feb 20 21:43:59 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Wed, 20 Feb 2008 15:43:59 -0500
Subject: [Python-Dev] Reminder: bug day on Saturday
In-Reply-To: <bbaeab100802201237r51f5f130ne6531ec1c2050428@mail.gmail.com>
References: <20080220160306.GA8632@amk-desktop.matrixgroup.net>
	<bbaeab100802201237r51f5f130ne6531ec1c2050428@mail.gmail.com>
Message-ID: <20080220204359.GB13172@amk-desktop.matrixgroup.net>

On Wed, Feb 20, 2008 at 12:37:42PM -0800, Brett Cannon wrote:
> How about marking already submitted patches as easy to get help
> reviewing? For instance, there are a bunch of test rewrites to move
> old tests to unittest where it would be rather nice to have another
> pair of eyes make sure that the tests are thorough enough.

Sure, go ahead and mark those, too.  Though not all patches are easy
to review, test improvements are likely to be OK.

--amk

From draghuram at gmail.com  Wed Feb 20 21:41:51 2008
From: draghuram at gmail.com (Raghuram Devarakonda)
Date: Wed, 20 Feb 2008 15:41:51 -0500
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <bbaeab100802201239w224fb604s39343cccc2d2633@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<47BAB718.4050000@gmail.com> <fpf7gb$mdq$1@ger.gmane.org>
	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
	<47BB5CDC.60705@v.loewis.de> <fpglhv$2cf$1@ger.gmane.org>
	<8b943f2b0802200025h6fa7fb03q13bacde16b0cbd82@mail.gmail.com>
	<47BC8F34.4020601@v.loewis.de>
	<bbaeab100802201239w224fb604s39343cccc2d2633@mail.gmail.com>
Message-ID: <2c51ecee0802201241l38027978pca3df8884983c78f@mail.gmail.com>

>  > Renaming it is easy. To the native speakers reading it: What should
>  > it be called? (please try to come up with something shorter than
>  > "request for enhancement")
>  >
>
>  "feature request"?

How about calling it just "enhancement"?

From martin at v.loewis.de  Wed Feb 20 22:03:33 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 20 Feb 2008 22:03:33 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <ca471dc20802201243k3fc751b5j734fafe392cd8032@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	
	<47BAB718.4050000@gmail.com> <fpf7gb$mdq$1@ger.gmane.org>	
	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>	
	<47BB5CDC.60705@v.loewis.de> <fpglhv$2cf$1@ger.gmane.org>	
	<8b943f2b0802200025h6fa7fb03q13bacde16b0cbd82@mail.gmail.com>	
	<47BC8F34.4020601@v.loewis.de>	
	<bbaeab100802201239w224fb604s39343cccc2d2633@mail.gmail.com>
	<ca471dc20802201243k3fc751b5j734fafe392cd8032@mail.gmail.com>
Message-ID: <47BC95A5.9030807@v.loewis.de>

Guido van Rossum wrote:
> On Feb 20, 2008 12:39 PM, Brett Cannon <brett at python.org> wrote:
>> On Feb 20, 2008 12:36 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>>> I agree, the name is a bit confusing when you're not used to it.
>>> Renaming it is easy. To the native speakers reading it: What should
>>> it be called? (please try to come up with something shorter than
>>> "request for enhancement")
>> "feature request"?

I already had it at enhancement :-)

In any case, by BDFL pronouncement, it's "feature request" now.

http://bugs.python.org/issue_type6

(as an aside - can anybody tell me how to suppress link/unlink
notifications in the history of each issue_type? I don't think
we need them (unlike the reverse link's history, i.e. the
history of the issue's type field))


Regards,
Martin


From gnewsg at gmail.com  Wed Feb 20 22:55:33 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Wed, 20 Feb 2008 13:55:33 -0800 (PST)
Subject: [Python-Dev] ssl - how to switch back to a plain text socket?
In-Reply-To: <08Feb20.083947pst."58696"@synergy1.parc.xerox.com>
References: <1b443341-46a7-4741-858f-b4e99ab2cc9d@72g2000hsu.googlegroups.com>
	<08Feb19.084213pst."58696"@synergy1.parc.xerox.com>
	<47BB5F12.4040706@v.loewis.de> 
	<08Feb19.175434pst."58696"@synergy1.parc.xerox.com>
	<47BBA540.8020105@v.loewis.de> 
	<08Feb19.210901pst."58696"@synergy1.parc.xerox.com>
	<b9873c80-7b84-4070-b0f1-4a3c707aeb57@q33g2000hsh.googlegroups.com>
	<08Feb20.083947pst."58696"@synergy1.parc.xerox.com>
Message-ID: <85fb7594-4e9c-487d-849e-12b6c247bfac@p43g2000hsc.googlegroups.com>

On 20 Feb, 17:39, Bill Janssen <jans... at parc.com> wrote:

> > I'm not sure, I've seen more than one library and server supporting
> > the CCC command.
> > For example proftpd and tnftpd servers support it.
>
> But does anyone use it?
>

It is useful to permit passive connection behind firewall devices.
This is what proftpd documentation says about it:

--- quote ---
The CCC command makes an encrypted control channel revert back to an
unencrypted channel. This helps to solve data connection problems in
situations where network equipment (such as firewalls, routers, NAT)
peek at the control channel in order to see which ports open. By
sending the CCC command and unecrypting the control channel, the
network equipment can once again peek at the commands (i.e. PORT and
EPRT) in the control channel. Since the CCC command must come after
the client has logged in, the USER and PASS commands on the control
channel will still be protected by SSL/TLS.
--- /quote ---

From qgallet at gmail.com  Wed Feb 20 23:02:58 2008
From: qgallet at gmail.com (Quentin Gallet-Gilles)
Date: Wed, 20 Feb 2008 23:02:58 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BC8F34.4020601@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>
	<47BAB718.4050000@gmail.com> <fpf7gb$mdq$1@ger.gmane.org>
	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>
	<47BB5CDC.60705@v.loewis.de> <fpglhv$2cf$1@ger.gmane.org>
	<8b943f2b0802200025h6fa7fb03q13bacde16b0cbd82@mail.gmail.com>
	<47BC8F34.4020601@v.loewis.de>
Message-ID: <8b943f2b0802201402r4c639347x7b354a6c36a2af37@mail.gmail.com>

I consider a feature request something like asking a factorial method (
http://bugs.python.org/issue2138). As for the RFE, (from Wikipedia) "while
not technically a bug, it is often tracked in the same manner as a bug as it
represents a failure to meet expected behavior, or simply out of
convenience".

But on second thought, I realize I'm really splitting hairs here. It's not
worth treating them separately, I'm perfectly fine with the "feature
request" type :-)

Quentin


On Wed, Feb 20, 2008 at 9:36 PM, "Martin v. L?wis" <martin at v.loewis.de>
wrote:

> > I agree, the name is a bit confusing when you're not used to it.
>
> Renaming it is easy. To the native speakers reading it: What should
> it be called? (please try to come up with something shorter than
> "request for enhancement")
>
> > Also I find that, by definition, RFE and feature requests are not
> > exactly the same. There's a thin line between a new feature and an
> > enhancement that is supposed to fill a gap/improve things. Should they
> > really be treated the same way ?
>
> I don't understand the difference. Can you please explain it? Are there
> features that are not enhancements (and if so, why would anybody request
> them), or are there enhancements which are not features? Are they
> entirely disjoint sets of things?
>
> Regards,
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080220/7e4be90e/attachment.htm 

From ncoghlan at gmail.com  Wed Feb 20 23:25:21 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 21 Feb 2008 08:25:21 +1000
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BC9063.5080004@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802180438v2d43af08w79de4dac95496289@mail.gmail.com>	<20080218182132.GM81956@nexus.in-nomine.org>	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	<47BAB718.4050000@gmail.com>	<fpf7gb$mdq$1@ger.gmane.org>	<e04bdf310802191222i7c259bebya9a6407c769f8a2e@mail.gmail.com>	<47BB5CDC.60705@v.loewis.de>
	<47BBF28D.4060706@gmail.com> <47BC9063.5080004@v.loewis.de>
Message-ID: <47BCA8D1.4090705@gmail.com>

Martin v. L?wis wrote:
>> It must have changed since I last looked at a feature request on the 
>> tracker - using a type rather than keyword is fine by me.
> 
> I'm fairly certain the rfe type was there ever since the switchover
> (at least that's what subversion says: the rfe type was added along
> with all other types in r52825, on 2006-11-23).

Perhaps we had duplication between the type and the keyword then? It's 
also possible I'm just misremembering and actually thinking of a 
completely different bug tracker that had nothing to do with Python.

It's a bit of a moot point now anyway.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From martin at v.loewis.de  Thu Feb 21 00:48:48 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 21 Feb 2008 00:48:48 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	
	<e27efe130802181111r6998ec0cgf3cdbec75088c17a@mail.gmail.com>	
	<bbaeab100802181241s162f586esb3f6f44c51b988a6@mail.gmail.com>	
	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>	
	<fpcshr$6ce$2@ger.gmane.org>	
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>	
	<47BA1C14.7090906@v.loewis.de>	
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>	
	<47BA8C97.1000300@v.loewis.de>	
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
Message-ID: <47BCBC60.8090808@v.loewis.de>

Virgil Dupras wrote:
> On 2/19/08, Virgil Dupras <hsoft at hardcoded.net> wrote:
>> closed_status = db.status.lookup('chatting')
> 
> Oops, replace 'chatting' with 'closed'

Ok, I ran the script. It said

Low activity tickets (180 days) broken down per resolution status:

- no selection -        547
wont fix        423
works for me    194
accepted        1233
fixed   2257
duplicate       176
later   49
invalid 275
postponed       20
out of date     304
remind  5
rejected        448

Attached is the updated script.

Notice that a day has more than 3600 seconds. With

if date2.differenceDate(date1).as_seconds() >= ACTIVITY_DAY_THRESHOLD * 
24 * 3600

it gives

- no selection -        118
wont fix        189
works for me    62
accepted        310
fixed   611
duplicate       75
later   17
invalid 73
postponed       6
out of date     193
remind  1
rejected        180


Regards,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: count.py
Type: text/x-python
Size: 1451 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20080221/c944f987/attachment.py 

From hsoft at hardcoded.net  Thu Feb 21 08:59:51 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Thu, 21 Feb 2008 08:59:51 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BCBC60.8090808@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>
	<fpcshr$6ce$2@ger.gmane.org>
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
	<47BA1C14.7090906@v.loewis.de>
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
Message-ID: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>

On 2/21/08, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>  - no selection -        118
>  wont fix        189
>  works for me    62
>  accepted        310
>  fixed   611
>  duplicate       75
>  later   17
>  invalid 73
>  postponed       6
>  out of date     193
>  remind  1
>  rejected        180

Thanks for running it. The rate is better than I expected, so I was
wrong in my assumption.

What would be the difference between accepted and fixed for a closed ticket?

Virgil

From hsoft at hardcoded.net  Thu Feb 21 12:30:25 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Thu, 21 Feb 2008 12:30:25 +0100
Subject: [Python-Dev] Unit Test Guide
Message-ID: <2a70578d0802210330oe973e87gf314a190f0880ae6@mail.gmail.com>

Hi devs,

Being a python dev newbie, I look in http://www.python.org/dev/ for
some guide to write unit tests in python and I can't find any.
Specifically, I'd like to know about files managements in tests. Is
every test expected to clean after itself, or is there an automatic
cleanup mechanism in place? Even more specifically, I'd like to create
a test for the proposed patch in http://bugs.python.org/issue2127 so I
need to create a subdir with non-ascii character in it, then connect
to a db in it. So, do I need to do the cleanup in the test? Is there a
special path I can write to that will automatically be cleaned up? If
not, wouldn't it be a good idea to have one?

I guess I could find the answer in regrtest.py, but frankly, this unit
is a little bit overwhelming.

If there is no guide, am I the only one to think it would be a good
idea to have one (Yeah, I could volunteer to write it)?

Virgil

From hsoft at hardcoded.net  Thu Feb 21 13:22:20 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Thu, 21 Feb 2008 13:22:20 +0100
Subject: [Python-Dev] Unit Test Guide
In-Reply-To: <2a70578d0802210330oe973e87gf314a190f0880ae6@mail.gmail.com>
References: <2a70578d0802210330oe973e87gf314a190f0880ae6@mail.gmail.com>
Message-ID: <2a70578d0802210422m3a50b8a7se78439f8e5d0f441@mail.gmail.com>

On 2/21/08, Virgil Dupras <hsoft at hardcoded.net> wrote:
> Hi devs,
>
>  Being a python dev newbie, I look in http://www.python.org/dev/ for
>  some guide to write unit tests in python and I can't find any.
>  Specifically, I'd like to know about files managements in tests. Is
>  every test expected to clean after itself, or is there an automatic
>  cleanup mechanism in place? Even more specifically, I'd like to create
>  a test for the proposed patch in http://bugs.python.org/issue2127 so I
>  need to create a subdir with non-ascii character in it, then connect
>  to a db in it. So, do I need to do the cleanup in the test? Is there a
>  special path I can write to that will automatically be cleaned up? If
>  not, wouldn't it be a good idea to have one?
>
>  I guess I could find the answer in regrtest.py, but frankly, this unit
>  is a little bit overwhelming.
>
>  If there is no guide, am I the only one to think it would be a good
>  idea to have one (Yeah, I could volunteer to write it)?
>
>
>  Virgil
>

Oops, nevermind I ended up finding it at
http://docs.python.org/lib/module-test.html and
http://docs.python.org/lib/module-test.testsupport.html. I didn't
expect to find it in the Python documentation itself. Sorry. Might I
suggest adding a link to it in http://www.python.org/dev/?

Virgil

From guido at python.org  Thu Feb 21 16:31:38 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 21 Feb 2008 07:31:38 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<fpcshr$6ce$2@ger.gmane.org>
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
	<47BA1C14.7090906@v.loewis.de>
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
Message-ID: <ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>

On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras <hsoft at hardcoded.net> wrote:
> On 2/21/08, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>  >  - no selection -        118
>  >  wont fix        189
>  >  works for me    62
>  >  accepted        310
>  >  fixed   611
>  >  duplicate       75
>  >  later   17
>  >  invalid 73
>  >  postponed       6
>  >  out of date     193
>  >  remind  1
>  >  rejected        180
>
>  Thanks for running it. The rate is better than I expected, so I was
>  wrong in my assumption.
>
>  What would be the difference between accepted and fixed for a closed ticket?

I don't know what others do, but I use accepted for a patch submission
and fixed for a bug report.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From gnewsg at gmail.com  Thu Feb 21 16:43:58 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Thu, 21 Feb 2008 07:43:58 -0800 (PST)
Subject: [Python-Dev] Unit Test Guide
In-Reply-To: <2a70578d0802210330oe973e87gf314a190f0880ae6@mail.gmail.com>
References: <2a70578d0802210330oe973e87gf314a190f0880ae6@mail.gmail.com>
Message-ID: <02e23208-c0ec-4998-b73f-7b571a73264f@41g2000hsc.googlegroups.com>

On 21 Feb, 12:30, "Virgil Dupras" <hs... at hardcoded.net> wrote:
> Hi devs,
>

> Specifically, I'd like to know about files managements in tests. Is
> every test expected to clean after itself, or is there an automatic
> cleanup mechanism in place?

I have usually seen a lot of tests implemented like this:


from test.test_support import TESTFN, unlink
import unittest

class TestCase(unittest.TestCase):

    def setUp(self):
        self.file = None

    def tearDown(self):
        if self.file is not None:
            self.file.close()
        unlink(TESTFN)

    def test_something(self):
        self.file = open(TESTFN, 'r')
        ...


> Even more specifically, I'd like to create
> a test for the proposed patch inhttp://bugs.python.org/issue2127so I
> need to create a subdir with non-ascii character in it, then connect
> to a db in it. So, do I need to do the cleanup in the test? Is there a
> special path I can write to that will automatically be cleaned up?

I don't think so.
You could create a directory in setUp method by using tempfile.mkdtemp
and then remove it in tearDown.

> I guess I could find the answer in regrtest.py, but frankly, this unit
> is a little bit overwhelming.
>
> If there is no guide, am I the only one to think it would be a good
> idea to have one (Yeah, I could volunteer to write it)?

Don't know whether Lib/test/readme.txt could be considered a guide but
it contains a lot of useful information for developers.


Hope this helps a little

From guido at python.org  Thu Feb 21 16:46:15 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 21 Feb 2008 07:46:15 -0800
Subject: [Python-Dev] Unit Test Guide
In-Reply-To: <02e23208-c0ec-4998-b73f-7b571a73264f@41g2000hsc.googlegroups.com>
References: <2a70578d0802210330oe973e87gf314a190f0880ae6@mail.gmail.com>
	<02e23208-c0ec-4998-b73f-7b571a73264f@41g2000hsc.googlegroups.com>
Message-ID: <ca471dc20802210746u4f665136j2dabcda7e46bf8e9@mail.gmail.com>

On Thu, Feb 21, 2008 at 7:43 AM, Giampaolo Rodola' <gnewsg at gmail.com> wrote:
> On 21 Feb, 12:30, "Virgil Dupras" <hs... at hardcoded.net> wrote:
>  > Hi devs,
>  >
>
>
> > Specifically, I'd like to know about files managements in tests. Is
>  > every test expected to clean after itself, or is there an automatic
>  > cleanup mechanism in place?
>
>  I have usually seen a lot of tests implemented like this:
>
>
>  from test.test_support import TESTFN, unlink
>  import unittest
>
>  class TestCase(unittest.TestCase):
>
>     def setUp(self):
>         self.file = None
>
>     def tearDown(self):
>         if self.file is not None:
>             self.file.close()
>         unlink(TESTFN)
>
>     def test_something(self):
>         self.file = open(TESTFN, 'r')
>         ...
>
>
>
>  > Even more specifically, I'd like to create
>  > a test for the proposed patch inhttp://bugs.python.org/issue2127so I
>
> > need to create a subdir with non-ascii character in it, then connect
>  > to a db in it. So, do I need to do the cleanup in the test? Is there a
>  > special path I can write to that will automatically be cleaned up?
>
>  I don't think so.
>  You could create a directory in setUp method by using tempfile.mkdtemp
>  and then remove it in tearDown.

Specifically, clean it up with shutil.rmtree()

>  > I guess I could find the answer in regrtest.py, but frankly, this unit
>  > is a little bit overwhelming.
>  >
>  > If there is no guide, am I the only one to think it would be a good
>  > idea to have one (Yeah, I could volunteer to write it)?
>
>  Don't know whether Lib/test/readme.txt could be considered a guide but
>  it contains a lot of useful information for developers.
>
>
>  Hope this helps a little
>
>
> _______________________________________________
>  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 amk at amk.ca  Thu Feb 21 16:47:12 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Thu, 21 Feb 2008 10:47:12 -0500
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
References: <2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>
	<fpcshr$6ce$2@ger.gmane.org>
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
	<47BA1C14.7090906@v.loewis.de>
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
Message-ID: <20080221154712.GA5835@amk-desktop.matrixgroup.net>

On Thu, Feb 21, 2008 at 08:59:51AM +0100, Virgil Dupras wrote:
> Thanks for running it. The rate is better than I expected, so I was
> wrong in my assumption.
> 
> What would be the difference between accepted and fixed for a closed ticket?

'accepted' is probably used more for patches, while 'fixed' is more
likely to be used for a bug report.

--amk

From facundobatista at gmail.com  Thu Feb 21 16:48:39 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 21 Feb 2008 12:48:39 -0300
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BCBC60.8090808@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>
	<fpcshr$6ce$2@ger.gmane.org>
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
	<47BA1C14.7090906@v.loewis.de>
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
Message-ID: <e04bdf310802210748q2ad2a3d0kdcf129b1032489d9@mail.gmail.com>

2008/2/20, "Martin v. L?wis" <martin at v.loewis.de>:

>  - no selection -        118
>  wont fix        189
>  works for me    62
>  accepted        310
>  fixed   611
>  duplicate       75
>  later   17
>  invalid 73
>  postponed       6
>  out of date     193
>  remind  1
>  rejected        180

This is the result for the "open" status issues? I guess not, because
the rejected, fixed, etc, should be closed.

Could you run this again, please, but filtering by "open" tickets?

Thanks!

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From steve at holdenweb.com  Thu Feb 21 16:50:20 2008
From: steve at holdenweb.com (Steve Holden)
Date: Thu, 21 Feb 2008 10:50:20 -0500
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	
	<fpcshr$6ce$2@ger.gmane.org>	
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>	
	<47BA1C14.7090906@v.loewis.de>	
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>	
	<47BA8C97.1000300@v.loewis.de>	
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>	
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>	
	<47BCBC60.8090808@v.loewis.de>	
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
Message-ID: <47BD9DBC.2030106@holdenweb.com>

Guido van Rossum wrote:
> On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras <hsoft at hardcoded.net> wrote:
>> On 2/21/08, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>  >  - no selection -        118
>>  >  wont fix        189
>>  >  works for me    62
>>  >  accepted        310
>>  >  fixed   611
>>  >  duplicate       75
>>  >  later   17
>>  >  invalid 73
>>  >  postponed       6
>>  >  out of date     193
>>  >  remind  1
>>  >  rejected        180
>>
>>  Thanks for running it. The rate is better than I expected, so I was
>>  wrong in my assumption.
>>
>>  What would be the difference between accepted and fixed for a closed ticket?
> 
> I don't know what others do, but I use accepted for a patch submission
> and fixed for a bug report.
> 
That sounds eminently sensible. So sensible there should be 
documentation that tells us to do that. Drat it, where's Brett Cannon 
when you need him? :-)

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/

From hsoft at hardcoded.net  Thu Feb 21 16:53:53 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Thu, 21 Feb 2008 16:53:53 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802210748q2ad2a3d0kdcf129b1032489d9@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<fpcshr$6ce$2@ger.gmane.org>
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
	<47BA1C14.7090906@v.loewis.de>
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<e04bdf310802210748q2ad2a3d0kdcf129b1032489d9@mail.gmail.com>
Message-ID: <2a70578d0802210753p2561dec8uaca77a9f6459d9e3@mail.gmail.com>

On 2/21/08, Facundo Batista <facundobatista at gmail.com> wrote:
> This is the result for the "open" status issues? I guess not, because
>  the rejected, fixed, etc, should be closed.
>
>  Could you run this again, please, but filtering by "open" tickets?

I don't see why would want to run this query on open tickets. What
would it tell you? How many old issue there is? You can already know
that with a simple search. The goal of this script is to know the
resolution of tickets that had a 6+ month gap in their activity.

Virgil

From ncoghlan at gmail.com  Thu Feb 21 16:55:26 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 22 Feb 2008 01:55:26 +1000
Subject: [Python-Dev] Unit Test Guide
In-Reply-To: <2a70578d0802210422m3a50b8a7se78439f8e5d0f441@mail.gmail.com>
References: <2a70578d0802210330oe973e87gf314a190f0880ae6@mail.gmail.com>
	<2a70578d0802210422m3a50b8a7se78439f8e5d0f441@mail.gmail.com>
Message-ID: <47BD9EEE.1040806@gmail.com>

Virgil Dupras wrote:
> On 2/21/08, Virgil Dupras <hsoft at hardcoded.net> wrote:
>> Hi devs,
>>
>>  Being a python dev newbie, I look in http://www.python.org/dev/ for
>>  some guide to write unit tests in python and I can't find any.
>>  Specifically, I'd like to know about files managements in tests. Is
>>  every test expected to clean after itself, or is there an automatic
>>  cleanup mechanism in place? Even more specifically, I'd like to create
>>  a test for the proposed patch in http://bugs.python.org/issue2127 so I
>>  need to create a subdir with non-ascii character in it, then connect
>>  to a db in it. So, do I need to do the cleanup in the test? Is there a
>>  special path I can write to that will automatically be cleaned up? If
>>  not, wouldn't it be a good idea to have one?

The tempfile module provides some useful tools for making individual 
files that clean themselves up, but individual tests are currently 
pretty much left to fend for themselves as far as cleaning up temporary 
directories. This can be done using the setUp/tearDown methods of the 
test case (as Giampaolo described), or more directly using context 
managers (that latter is obviously only common in tests added for 2.6/3.0)

Something to consider would be to relocate the temp_dir() context 
manager from test_cmd_line_script [1] to test.test_support and use that. 
That context manager should be able to clean up for you no matter what 
you put in the temporary directory. The major downside of that approach 
is that test_support would end up depending on yet more modules being 
available for import (shutil and tempfile in this case), which isn't 
hugely desirable for test infrastructure). A way around that may be to 
guard the imports and define a dummy context manager that raises 
TestSkipped if either import fails.

(If you do come up with a patch to relocate temp_dir(), put it up as a 
separate tracker item and add me to the nosy list for it)

> Oops, nevermind I ended up finding it at
> http://docs.python.org/lib/module-test.html and
> http://docs.python.org/lib/module-test.testsupport.html. I didn't
> expect to find it in the Python documentation itself. Sorry. Might I
> suggest adding a link to it in http://www.python.org/dev/?

Sounds like a good idea to me too.

Cheers,
Nick.

[1] 
http://svn.python.org/projects/python/trunk/Lib/test/test_cmd_line_script.py


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From facundobatista at gmail.com  Thu Feb 21 16:58:32 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 21 Feb 2008 12:58:32 -0300
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <2a70578d0802210753p2561dec8uaca77a9f6459d9e3@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>
	<47BA1C14.7090906@v.loewis.de>
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<e04bdf310802210748q2ad2a3d0kdcf129b1032489d9@mail.gmail.com>
	<2a70578d0802210753p2561dec8uaca77a9f6459d9e3@mail.gmail.com>
Message-ID: <e04bdf310802210758w3f26e3b3re573f9b298ee3f56@mail.gmail.com>

2008/2/21, Virgil Dupras <hsoft at hardcoded.net>:

> I don't see why would want to run this query on open tickets. What
>  would it tell you? How many old issue there is? You can already know
>  that with a simple search. The goal of this script is to know the
>  resolution of tickets that had a 6+ month gap in their activity.

In the context of what to do with RFEs (my original question), if keep
them in the tracker, or removing them from there and putting them in
the PEP, I want to see this distribution in the actually opened
tickets (as they're disturbed or not by the RFEs).

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From greg at krypto.org  Thu Feb 21 16:59:29 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Thu, 21 Feb 2008 07:59:29 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BD9DBC.2030106@holdenweb.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<47BA1C14.7090906@v.loewis.de>
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
Message-ID: <52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>

On 2/21/08, Steve Holden <steve at holdenweb.com> wrote:
>
> Guido van Rossum wrote:
> > On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras <hsoft at hardcoded.net>
> wrote:
>
> >>  What would be the difference between accepted and fixed for a closed
> ticket?
> >
> > I don't know what others do, but I use accepted for a patch submission
> > and fixed for a bug report.
> >
>
> That sounds eminently sensible. So sensible there should be
> documentation that tells us to do that. Drat it, where's Brett Cannon
> when you need him? :-)


I'm always faced with a tiny quandry when closing a fixed bug that had a
patch to fix it attached because both seem to apply.  ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080221/62d44368/attachment.htm 

From facundobatista at gmail.com  Thu Feb 21 17:06:50 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 21 Feb 2008 13:06:50 -0300
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
Message-ID: <e04bdf310802210806q60ab9165rb4c552d1215e47a4@mail.gmail.com>

2008/2/21, Gregory P. Smith <greg at krypto.org>:

> > That sounds eminently sensible. So sensible there should be
> > documentation that tells us to do that. Drat it, where's Brett Cannon
> > when you need him? :-)
>
> I'm always faced with a tiny quandry when closing a fixed bug that had a
> patch to fix it attached because both seem to apply.  ;-)

Yeap, and I'm sure I ave a % of wrongly marked issues when closing, :p.

Anyway, if a patch, and a bug, and a RFE, etc, are all "issues", IMHO
is cluttering the fact that we have two or three denominations to
"this issue was ok and we executed the proper actions to close it".

Everything in this aspect would be simpler if we have one word for
what I just meant.

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From hsoft at hardcoded.net  Thu Feb 21 17:14:16 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Thu, 21 Feb 2008 17:14:16 +0100
Subject: [Python-Dev] Unit Test Guide
In-Reply-To: <47BD9EEE.1040806@gmail.com>
References: <2a70578d0802210330oe973e87gf314a190f0880ae6@mail.gmail.com>
	<2a70578d0802210422m3a50b8a7se78439f8e5d0f441@mail.gmail.com>
	<47BD9EEE.1040806@gmail.com>
Message-ID: <2a70578d0802210814vbec9df8xa641bb7053a61068@mail.gmail.com>

On 2/21/08, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Virgil Dupras wrote:
>  > On 2/21/08, Virgil Dupras <hsoft at hardcoded.net> wrote:
>  >> Hi devs,
>  >>
>  >>  Being a python dev newbie, I look in http://www.python.org/dev/ for
>  >>  some guide to write unit tests in python and I can't find any.
>  >>  Specifically, I'd like to know about files managements in tests. Is
>  >>  every test expected to clean after itself, or is there an automatic
>  >>  cleanup mechanism in place? Even more specifically, I'd like to create
>  >>  a test for the proposed patch in http://bugs.python.org/issue2127 so I
>  >>  need to create a subdir with non-ascii character in it, then connect
>  >>  to a db in it. So, do I need to do the cleanup in the test? Is there a
>  >>  special path I can write to that will automatically be cleaned up? If
>  >>  not, wouldn't it be a good idea to have one?
>
>
> The tempfile module provides some useful tools for making individual
>  files that clean themselves up, but individual tests are currently
>  pretty much left to fend for themselves as far as cleaning up temporary
>  directories. This can be done using the setUp/tearDown methods of the
>  test case (as Giampaolo described), or more directly using context
>  managers (that latter is obviously only common in tests added for 2.6/3.0)
>
>  Something to consider would be to relocate the temp_dir() context
>  manager from test_cmd_line_script [1] to test.test_support and use that.
>  That context manager should be able to clean up for you no matter what
>  you put in the temporary directory. The major downside of that approach
>  is that test_support would end up depending on yet more modules being
>  available for import (shutil and tempfile in this case), which isn't
>  hugely desirable for test infrastructure). A way around that may be to
>  guard the imports and define a dummy context manager that raises
>  TestSkipped if either import fails.
>
>  (If you do come up with a patch to relocate temp_dir(), put it up as a
>  separate tracker item and add me to the nosy list for it)

What do you people think about this issue I just opened?

http://bugs.python.org/issue2156

From lists at cheimes.de  Thu Feb 21 18:14:37 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 21 Feb 2008 18:14:37 +0100
Subject: [Python-Dev] Unit Test Guide
In-Reply-To: <ca471dc20802210746u4f665136j2dabcda7e46bf8e9@mail.gmail.com>
References: <2a70578d0802210330oe973e87gf314a190f0880ae6@mail.gmail.com>	<02e23208-c0ec-4998-b73f-7b571a73264f@41g2000hsc.googlegroups.com>
	<ca471dc20802210746u4f665136j2dabcda7e46bf8e9@mail.gmail.com>
Message-ID: <fpkbht$d2m$1@ger.gmane.org>

Guido van Rossum wrote:
>>  I don't think so.
>>  You could create a directory in setUp method by using tempfile.mkdtemp
>>  and then remove it in tearDown.
> 
> Specifically, clean it up with shutil.rmtree()

And make sure you have closed all files before you rmtree() the
directory. Otherwise the unit test *will* fail on Windows.

Christian


From barry at python.org  Thu Feb 21 18:15:00 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 21 Feb 2008 12:15:00 -0500
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <20080221162115.C59541E4021@bag.python.org>
References: <20080221162115.C59541E4021@bag.python.org>
Message-ID: <BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 21, 2008, at 11:21 AM, skip.montanaro wrote:

> Author: skip.montanaro
> Date: Thu Feb 21 17:21:15 2008
> New Revision: 60919
>
> Modified:
>   peps/trunk/pep-0008.txt
> Log:
> Replace "looks ugly" with a hopefully more concrete explanation of  
> why line
> wrapping is bad - it disrupts the visual structure of the code.
>
>
> Modified: peps/trunk/pep-0008.txt
> = 
> = 
> = 
> = 
> = 
> = 
> = 
> = 
> ======================================================================
> --- peps/trunk/pep-0008.txt	(original)
> +++ peps/trunk/pep-0008.txt	Thu Feb 21 17:21:15 2008
> @@ -77,10 +77,11 @@
>
>     There are still many devices around that are limited to 80  
> character
>     lines; plus, limiting windows to 80 characters makes it possible  
> to have
> -    several windows side-by-side.  The default wrapping on such  
> devices looks
> -    ugly.  Therefore, please limit all lines to a maximum of 79  
> characters.
> -    For flowing long blocks of text (docstrings or comments),  
> limiting the
> -    length to 72 characters is recommended.
> +    several windows side-by-side.  The default wrapping on such  
> devices
> +    disrupts the visual structure of the code, making it more  
> difficult to
> +    understand.  Therefore, please limit all lines to a maximum of 79
> +    characters.  For flowing long blocks of text (docstrings or  
> comments),
> +    limiting the length to 72 characters is recommended.

Why should docstrings and comments be limited to 72 characters when  
code is limited to 79 characters?  I ask because there is an ongoing  
debate at my company about this.

Personally, I see no justification for it, and further, it's a pita to  
support automatically because tools like Emacs only have one auto- 
wrapping variable (fill-column).  Emacs doesn't know that it should  
fill comments and docstrings different than code lines, so you have to  
do a bunch of manual crud to support these guidelines.

I recommend removing the guideline of 72 characters, and just say  
everything, code, comments, and docstrings should be no wider than 79  
characters.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR72xlXEjvBPtnXfVAQKEdAP/f1xnvn6jw04yyhSZfqA6HdgnYnpnYPAl
S4ixszL8phg6KRq8CD2ceskY8TocDg+GG6c//M+jihRRzXMXHW/1Lfp/6syqAd1d
vkWaUffaSK4rReMiEG0EmFZmYwaJA660RU0YBnv1d1Idpexj4Y/kIgfgou9OkWDY
iJO+efk93Xc=
=qYfT
-----END PGP SIGNATURE-----

From guido at python.org  Thu Feb 21 18:30:45 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 21 Feb 2008 09:30:45 -0800
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
Message-ID: <ca471dc20802210930q654b4791p3c0588d374603e6@mail.gmail.com>

On Thu, Feb 21, 2008 at 9:15 AM, Barry Warsaw <barry at python.org> wrote:
>  Why should docstrings and comments be limited to 72 characters when
>  code is limited to 79 characters?  I ask because there is an ongoing
>  debate at my company about this.

People in your company have too much time on their hands. :-)

>  Personally, I see no justification for it, and further, it's a pita to
>  support automatically because tools like Emacs only have one auto-
>  wrapping variable (fill-column).  Emacs doesn't know that it should
>  fill comments and docstrings different than code lines, so you have to
>  do a bunch of manual crud to support these guidelines.
>
>  I recommend removing the guideline of 72 characters, and just say
>  everything, code, comments, and docstrings should be no wider than 79
>  characters.

I'm fine with getting rid of this, but since that originally comes
from me, here's my justification. Somehow my Emacs usually defaults to
72 for its fill column. That means that when I reflow text in a block
comment or docstring, it'll use this limit. OTOH I don't use anything
to automatically fold long code lines: when they start wrapping I
manually decide on the best place to break it (and my windows are
typically 80 chars wide so I can have several side by side(*)).

However there are occasions where I manually format docstrings or
comments, and then I will again use 79 as the limit.

(*) When is Emacs going to fix the bug where it decides to fold a line
that's exactly as wide as the window? This 79 business is really
silly, and had to impose on people using other editors.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From rrr at ronadam.com  Thu Feb 21 18:33:37 2008
From: rrr at ronadam.com (Ron Adam)
Date: Thu, 21 Feb 2008 11:33:37 -0600
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
Message-ID: <47BDB5F1.2000901@ronadam.com>



Barry Warsaw wrote:

> Why should docstrings and comments be limited to 72 characters when  
> code is limited to 79 characters?  I ask because there is an ongoing  
> debate at my company about this.

I'm not sure if this is the main reason, but when using pydoc to view 
docstrings, the 72 character width allows for the added indent in class and 
method sections.

Ron

From rrr at ronadam.com  Thu Feb 21 18:33:37 2008
From: rrr at ronadam.com (Ron Adam)
Date: Thu, 21 Feb 2008 11:33:37 -0600
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
Message-ID: <47BDB5F1.2000901@ronadam.com>



Barry Warsaw wrote:

> Why should docstrings and comments be limited to 72 characters when  
> code is limited to 79 characters?  I ask because there is an ongoing  
> debate at my company about this.

I'm not sure if this is the main reason, but when using pydoc to view 
docstrings, the 72 character width allows for the added indent in class and 
method sections.

Ron


From martin at v.loewis.de  Thu Feb 21 20:52:07 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 21 Feb 2008 20:52:07 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	
	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>	
	<fpcshr$6ce$2@ger.gmane.org>	
	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>	
	<47BA1C14.7090906@v.loewis.de>	
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>	
	<47BA8C97.1000300@v.loewis.de>	
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>	
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>	
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
Message-ID: <47BDD667.5020301@v.loewis.de>

> What would be the difference between accepted and fixed for a closed ticket?

As Guido says: a bug gets fixed, a patch gets accepted. This was copied 
over from SF, but it makes sense to me and everybody seems to be 
following it.

Regards,
Martin

From martin at v.loewis.de  Thu Feb 21 20:55:52 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 21 Feb 2008 20:55:52 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802210806q60ab9165rb4c552d1215e47a4@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>	
	<47BA8C97.1000300@v.loewis.de>	
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>	
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>	
	<47BCBC60.8090808@v.loewis.de>	
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>	
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>	
	<47BD9DBC.2030106@holdenweb.com>	
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<e04bdf310802210806q60ab9165rb4c552d1215e47a4@mail.gmail.com>
Message-ID: <47BDD748.3000407@v.loewis.de>

> Everything in this aspect would be simpler if we have one word for
> what I just meant.

If you think it should be fixed, please submit a report in the meta
tracker, ideally specifying precisely how you want to see it changed.

It's possible to "retire" objects in Roundup: certain resolution values
would still be present and referenced by issues that use it, but they
would not appear anymore in the drop-down list.

Regards,
Martin

From g.brandl at gmx.net  Thu Feb 21 21:24:24 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 21 Feb 2008 21:24:24 +0100
Subject: [Python-Dev] Nosy lists on issue tracker.
In-Reply-To: <47BB60EE.5020305@v.loewis.de>
References: <1afaf6160802191447x30d9ca97s63551f20a381efc@mail.gmail.com>
	<47BB60EE.5020305@v.loewis.de>
Message-ID: <fpkmlj$2i7$1@ger.gmane.org>

Martin v. L?wis schrieb:
>> What is the policy regarding nosy lists? Is it appropriate it add people 
>> to it besides oneself? As I cannot assign items, I'm sometimes tempted 
>> to add someone relevant to the list. (ie Should I add Georg to 
>> documentation related issues?)
> 
> I would find it appropriate. In theory, there should be auto-assignment,
> but that isn't really implemented, and I don't know whether Georg would
> want to be auto-assigned Documentation or Sphinx issues.

If there was auto-assignment, I'd opt in for those groups :)

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 martin at v.loewis.de  Thu Feb 21 21:25:12 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 21 Feb 2008 21:25:12 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802210748q2ad2a3d0kdcf129b1032489d9@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802181247o25c52b62h26578fb13d961abc@mail.gmail.com>	<fpcshr$6ce$2@ger.gmane.org>	<2a70578d0802181329m4c1a1494tb0d7b306a03e4895@mail.gmail.com>	<47BA1C14.7090906@v.loewis.de>	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>	<47BA8C97.1000300@v.loewis.de>	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>	<47BCBC60.8090808@v.loewis.de>
	<e04bdf310802210748q2ad2a3d0kdcf129b1032489d9@mail.gmail.com>
Message-ID: <47BDDE28.3000502@v.loewis.de>

> This is the result for the "open" status issues? I guess not, because
> the rejected, fixed, etc, should be closed.
> 
> Could you run this again, please, but filtering by "open" tickets?

Here you go

- no selection -        381
wont fix        2
works for me    0
accepted        4
fixed   2
duplicate       0
later   6
invalid 0
postponed       0
out of date     1
remind  0
rejected        0

As Virgil expected: it's not very meaningful, but it's what you've asked
for.

Regards,
Martin

From brett at python.org  Thu Feb 21 22:14:21 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 21 Feb 2008 13:14:21 -0800
Subject: [Python-Dev] Unit Test Guide
In-Reply-To: <02e23208-c0ec-4998-b73f-7b571a73264f@41g2000hsc.googlegroups.com>
References: <2a70578d0802210330oe973e87gf314a190f0880ae6@mail.gmail.com>
	<02e23208-c0ec-4998-b73f-7b571a73264f@41g2000hsc.googlegroups.com>
Message-ID: <bbaeab100802211314x64da53etd0e8978a579ab718@mail.gmail.com>

On Thu, Feb 21, 2008 at 7:43 AM, Giampaolo Rodola' <gnewsg at gmail.com> wrote:
> On 21 Feb, 12:30, "Virgil Dupras" <hs... at hardcoded.net> wrote:
>  > Hi devs,
>  >
>
>
> > Specifically, I'd like to know about files managements in tests. Is
>  > every test expected to clean after itself, or is there an automatic
>  > cleanup mechanism in place?
>
>  I have usually seen a lot of tests implemented like this:
>
>
>  from test.test_support import TESTFN, unlink
>  import unittest
>
>  class TestCase(unittest.TestCase):
>
>     def setUp(self):
>         self.file = None
>
>     def tearDown(self):
>         if self.file is not None:
>             self.file.close()
>         unlink(TESTFN)
>
>     def test_something(self):
>         self.file = open(TESTFN, 'r')
>         ...
>

test.test_support contains all of the various test-helping code that
is not in unittest or doctest.

>
>
>  > Even more specifically, I'd like to create
>  > a test for the proposed patch inhttp://bugs.python.org/issue2127so I
>
> > need to create a subdir with non-ascii character in it, then connect
>  > to a db in it. So, do I need to do the cleanup in the test? Is there a
>  > special path I can write to that will automatically be cleaned up?
>
>  I don't think so.
>  You could create a directory in setUp method by using tempfile.mkdtemp
>  and then remove it in tearDown.
>
>
>  > I guess I could find the answer in regrtest.py, but frankly, this unit
>  > is a little bit overwhelming.
>  >
>  > If there is no guide, am I the only one to think it would be a good
>  > idea to have one (Yeah, I could volunteer to write it)?
>
>  Don't know whether Lib/test/readme.txt could be considered a guide but
>  it contains a lot of useful information for developers.

A more appropriate doc is on the todo list to write.

-Brett

From brett at python.org  Thu Feb 21 22:17:54 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 21 Feb 2008 13:17:54 -0800
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
Message-ID: <bbaeab100802211317t7d0b2371ld8e70fc615d49868@mail.gmail.com>

On Thu, Feb 21, 2008 at 9:15 AM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>
>
>  On Feb 21, 2008, at 11:21 AM, skip.montanaro wrote:
>
>  > Author: skip.montanaro
>  > Date: Thu Feb 21 17:21:15 2008
>  > New Revision: 60919
>  >
>  > Modified:
>  >   peps/trunk/pep-0008.txt
>  > Log:
>  > Replace "looks ugly" with a hopefully more concrete explanation of
>  > why line
>  > wrapping is bad - it disrupts the visual structure of the code.
>  >
>  >
>  > Modified: peps/trunk/pep-0008.txt
>  > =
>  > =
>  > =
>  > =
>  > =
>  > =
>  > =
>  > =
>  > ======================================================================
>  > --- peps/trunk/pep-0008.txt   (original)
>  > +++ peps/trunk/pep-0008.txt   Thu Feb 21 17:21:15 2008
>  > @@ -77,10 +77,11 @@
>  >
>  >     There are still many devices around that are limited to 80
>  > character
>  >     lines; plus, limiting windows to 80 characters makes it possible
>  > to have
>  > -    several windows side-by-side.  The default wrapping on such
>  > devices looks
>  > -    ugly.  Therefore, please limit all lines to a maximum of 79
>  > characters.
>  > -    For flowing long blocks of text (docstrings or comments),
>  > limiting the
>  > -    length to 72 characters is recommended.
>  > +    several windows side-by-side.  The default wrapping on such
>  > devices
>  > +    disrupts the visual structure of the code, making it more
>  > difficult to
>  > +    understand.  Therefore, please limit all lines to a maximum of 79
>  > +    characters.  For flowing long blocks of text (docstrings or
>  > comments),
>  > +    limiting the length to 72 characters is recommended.
>
>  Why should docstrings and comments be limited to 72 characters when
>  code is limited to 79 characters?  I ask because there is an ongoing
>  debate at my company about this.
>
>  Personally, I see no justification for it, and further, it's a pita to
>  support automatically because tools like Emacs only have one auto-
>  wrapping variable (fill-column).  Emacs doesn't know that it should
>  fill comments and docstrings different than code lines, so you have to
>  do a bunch of manual crud to support these guidelines.
>
>  I recommend removing the guideline of 72 characters, and just say
>  everything, code, comments, and docstrings should be no wider than 79
>  characters.

+1 from me. I know having a separate line break rule just for PEPs and
such is a pain as I am having to constantly look down at the column
number to know when I have run afoul of this.

-Brett

From brett at python.org  Thu Feb 21 22:21:50 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 21 Feb 2008 13:21:50 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BD9DBC.2030106@holdenweb.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<47BA1C14.7090906@v.loewis.de>
	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
Message-ID: <bbaeab100802211321l1b125232ic325128a7d48c84d@mail.gmail.com>

On Thu, Feb 21, 2008 at 7:50 AM, Steve Holden <steve at holdenweb.com> wrote:
> Guido van Rossum wrote:
>  > On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras <hsoft at hardcoded.net> wrote:
>  >> On 2/21/08, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>  >>  >  - no selection -        118
>  >>  >  wont fix        189
>  >>  >  works for me    62
>  >>  >  accepted        310
>  >>  >  fixed   611
>  >>  >  duplicate       75
>  >>  >  later   17
>  >>  >  invalid 73
>  >>  >  postponed       6
>  >>  >  out of date     193
>  >>  >  remind  1
>  >>  >  rejected        180
>  >>
>  >>  Thanks for running it. The rate is better than I expected, so I was
>  >>  wrong in my assumption.
>  >>
>  >>  What would be the difference between accepted and fixed for a closed ticket?
>  >
>  > I don't know what others do, but I use accepted for a patch submission
>  > and fixed for a bug report.
>  >
>  That sounds eminently sensible. So sensible there should be
>  documentation that tells us to do that. Drat it, where's Brett Cannon
>  when you need him? :-)

Trying to get his sprint intro talk lined up for PyCon while dealing
with the stdlib reorg. =)

-Brett

From brett at python.org  Thu Feb 21 22:24:33 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 21 Feb 2008 13:24:33 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802210806q60ab9165rb4c552d1215e47a4@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<e04bdf310802210806q60ab9165rb4c552d1215e47a4@mail.gmail.com>
Message-ID: <bbaeab100802211324p8b01f8p5c22ea143b9e8454@mail.gmail.com>

On Thu, Feb 21, 2008 at 8:06 AM, Facundo Batista
<facundobatista at gmail.com> wrote:
> 2008/2/21, Gregory P. Smith <greg at krypto.org>:
>
>
>  > > That sounds eminently sensible. So sensible there should be
>  > > documentation that tells us to do that. Drat it, where's Brett Cannon
>  > > when you need him? :-)
>  >
>  > I'm always faced with a tiny quandry when closing a fixed bug that had a
>  > patch to fix it attached because both seem to apply.  ;-)
>
>  Yeap, and I'm sure I ave a % of wrongly marked issues when closing, :p.
>
>  Anyway, if a patch, and a bug, and a RFE, etc, are all "issues", IMHO
>  is cluttering the fact that we have two or three denominations to
>  "this issue was ok and we executed the proper actions to close it".
>
>  Everything in this aspect would be simpler if we have one word for
>  what I just meant.

Something like "handle" or "resolved". An issue is an issue and we
wanting a single way to say the issue was closed because what is was
about was handled seems reasonable.

-Brett

From jml at mumak.net  Thu Feb 21 23:21:15 2008
From: jml at mumak.net (Jonathan Lange)
Date: Fri, 22 Feb 2008 09:21:15 +1100
Subject: [Python-Dev] Unit Test Guide
In-Reply-To: <02e23208-c0ec-4998-b73f-7b571a73264f@41g2000hsc.googlegroups.com>
References: <2a70578d0802210330oe973e87gf314a190f0880ae6@mail.gmail.com>
	<02e23208-c0ec-4998-b73f-7b571a73264f@41g2000hsc.googlegroups.com>
Message-ID: <d06a5cd30802211421i6c97566crcadaaa4319786d51@mail.gmail.com>

On Fri, Feb 22, 2008 at 2:43 AM, Giampaolo Rodola' <gnewsg at gmail.com> wrote:
> On 21 Feb, 12:30, "Virgil Dupras" <hs... at hardcoded.net> wrote:
>  > Hi devs,
>  >
>
>
> > Specifically, I'd like to know about files managements in tests. Is
>  > every test expected to clean after itself, or is there an automatic
>  > cleanup mechanism in place?
>
>  I have usually seen a lot of tests implemented like this:
>
>
>  from test.test_support import TESTFN, unlink
>  import unittest
>
>  class TestCase(unittest.TestCase):
>
>     def setUp(self):
>         self.file = None
>
>     def tearDown(self):
>         if self.file is not None:
>             self.file.close()
>         unlink(TESTFN)
>
>     def test_something(self):
>         self.file = open(TESTFN, 'r')
>         ...
>

This is a little off-topic but FWIW, bzrlib.tests.TestCase and
Twisted's TestCase have a nice helper method called 'addCleanup' that
adds a nullary callable to a stack of callable that get popped off and
run at the start of tearDown.

That would allow your example to be rewritten as:


from test.test_support import TESTFN, unlink
import unittest

class TestCase(unittest.TestCase):

   def open_file(self, filename, mode):
       opened_file = open(filename, mode)
       def close_and_delete():
           opened_file.close()
           unlink(filename)
       self.addCleanup(close_and_delete)
       return opened_file

   def test_something(self):
       file = self.open_file(TESTFN, 'r')
       ...

This isn't any shorter, but now you can open as many files as you
want. It also keeps clutter out of setUp and tearDown.

jml

From eric+python-dev at trueblade.com  Thu Feb 21 23:26:09 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 21 Feb 2008 17:26:09 -0500
Subject: [Python-Dev] Backporting PEP 3127 to trunk
Message-ID: <47BDFA81.8000805@trueblade.com>

I'm going to work on backporting PEP 3127, specifically the hex, oct(), 
and bin() builtins.  I have bin() completed, and I'll check it in 
shortly.  oct() will require a future import.  Does anyone have any 
pointers for implementing this?  I understand (and have completed) 
adding the future import, but what I don't understand is how to modify 
the behavior of oct() for only the module where the future import is 
execute.  Any rough ideas or pointers to existing code that does 
something similar would be helpful.  I also need a name for the future 
import statement.

Also, I notice in py3k that __hex__ and __oct__ have vanished, and 
instead hex() and oct() just uses the __index__ machinery to produce a 
number, then converts that to a string.  So I'm thinking that maybe we 
could use the same future import statement that controls oct()'s 
behavior to also switch hex() and oct() to the py3k behavior.  Or, maybe 
we should use a different future import?  Or, I guess, not do this at 
all.  But I think it's a good idea.

I guess another issue is changing hex()'s behavior of adding a trailing 
L for longs.  I don't really see the value in this, and maybe it should 
also change with a future import statement.

For bin(), I just used the py3k behavior, and didn't implement a __bin__ 
method.  I'm also not adding a trailing L for longs.  I think that makes 
the most sense.

Eric.


From guido at python.org  Thu Feb 21 23:31:00 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 21 Feb 2008 14:31:00 -0800
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <47BDFA81.8000805@trueblade.com>
References: <47BDFA81.8000805@trueblade.com>
Message-ID: <ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>

I wonder if, in order to change the behavior of various built-in
functions, it wouldn't be easier to be able to write

from future_builtins import oct, hex  # and who knows what else

Agreed with your approach for bin().

On Thu, Feb 21, 2008 at 2:26 PM, Eric Smith
<eric+python-dev at trueblade.com> wrote:
> I'm going to work on backporting PEP 3127, specifically the hex, oct(),
>  and bin() builtins.  I have bin() completed, and I'll check it in
>  shortly.  oct() will require a future import.  Does anyone have any
>  pointers for implementing this?  I understand (and have completed)
>  adding the future import, but what I don't understand is how to modify
>  the behavior of oct() for only the module where the future import is
>  execute.  Any rough ideas or pointers to existing code that does
>  something similar would be helpful.  I also need a name for the future
>  import statement.
>
>  Also, I notice in py3k that __hex__ and __oct__ have vanished, and
>  instead hex() and oct() just uses the __index__ machinery to produce a
>  number, then converts that to a string.  So I'm thinking that maybe we
>  could use the same future import statement that controls oct()'s
>  behavior to also switch hex() and oct() to the py3k behavior.  Or, maybe
>  we should use a different future import?  Or, I guess, not do this at
>  all.  But I think it's a good idea.
>
>  I guess another issue is changing hex()'s behavior of adding a trailing
>  L for longs.  I don't really see the value in this, and maybe it should
>  also change with a future import statement.
>
>  For bin(), I just used the py3k behavior, and didn't implement a __bin__
>  method.  I'm also not adding a trailing L for longs.  I think that makes
>  the most sense.
>
>  Eric.
>
>  _______________________________________________
>  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 python at rcn.com  Fri Feb 22 00:23:20 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 21 Feb 2008 18:23:20 -0500 (EST)
Subject: [Python-Dev] Backporting PEP 3127 to trunk
Message-ID: <20080221182320.AHJ31576@ms19.lnh.mail.rcn.net>

[Eric Smith]
> I'm going to work on backporting PEP 3127, specifically 
>the hex, oct(), and bin() builtins.

IMO, these should not be backported. They are strongly
associated with 3.0's new literal syntax.  They don't
don't really fit in with 2.6 and don't make 2.6 any more
attractive.


Raymond

From eric+python-dev at trueblade.com  Fri Feb 22 00:37:40 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 21 Feb 2008 18:37:40 -0500
Subject: [Python-Dev] Backporting PEP 3101 to 2.6
In-Reply-To: <200802171026.22218@news.perlig.de>
References: <47861E4A.4020006@trueblade.com>
	<200802170141.58754@news.perlig.de>
	<47B79DC5.9020507@trueblade.com>
	<200802171026.22218@news.perlig.de>
Message-ID: <47BE0B44.1000103@trueblade.com>

Andr? Malo wrote:
> * Eric Smith wrote:
>> But now that I look at time.strftime in py3k, it's converting the entire
>> unicode string to a char string with PyUnicode_AsString, then converting
>> back with PyUnicode_Decode.
> 
> Looks wrong to me, too... :-)
> 
> nd

I don't understand Unicode encoding/decoding well enough to describe 
this bug, but I admit it looks suspicious.  Could someone who does 
understand it open a bug against 3.0 (hopefully with an example that fails)?

The bug should also mention that 2.6 avoids this problem entirely by not 
supporting unicode with strftime or datetime.__format__, but 2.6 could 
probably leverage whatever solution is developed for 3.0.

Thanks.


From musiccomposition at gmail.com  Sat Feb 16 04:29:23 2008
From: musiccomposition at gmail.com (Benjamin)
Date: Fri, 15 Feb 2008 19:29:23 -0800 (PST)
Subject: [Python-Dev] dir() and __all__
In-Reply-To: <001e01c8704a$ad54b640$6800a8c0@RaymondLaptop1>
References: <20080215203047.AHA87475@ms19.lnh.mail.rcn.net> 
	<ca471dc20802151748u7ffb2f21iaf77eb48056a8b13@mail.gmail.com> 
	<001e01c8704a$ad54b640$6800a8c0@RaymondLaptop1>
Message-ID: <393b06d8-d128-4bb3-8287-3f566f8ca855@p43g2000hsc.googlegroups.com>



On Feb 15, 9:18 pm, "Raymond Hettinger" <pyt... at rcn.com> wrote:
> [Raymond]
>
> >> Should dir(module) use __all__ when defined?
>
> [GvR]
>
> > It's not consistent with what dir() of a class or instance does though.
>
> > -1.
>
> Perhaps there is another solution. Have dir() exclude objects
> which are modules.  For example, dir(logging) would exclude
> sys, os, types, time, string, cStringIO, and traceback.
Are you proposing just a list those modules or all module objects?
Excluding all modules would endanger __init__.py modules which
imported modules from their package.
>
> Raymond
> _______________________________________________
> Python-Dev mailing list
> Python-... at python.orghttp://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv...

From christian at cheimes.de  Sat Feb 16 11:30:05 2008
From: christian at cheimes.de (Christian Heimes)
Date: Sat, 16 Feb 2008 11:30:05 +0100
Subject: [Python-Dev] trunk-math
In-Reply-To: <47B6B86F.7070307@gmail.com>
References: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
	<47B6B86F.7070307@gmail.com>
Message-ID: <47B6BB2D.7050402@cheimes.de>

Nick Coghlan wrote:
> I would put the context manager in the math module as well. contextlib
> is intended for generic context related tools (like nested() and
> closing() that don't have a more topical home.

I'll reimplement the ieee754 context manager in C once the feature gets
accepted. For the experimental branch it was much easier to write it in
Python.

Christian

From Vladimir.Marangozov at t-online.de  Tue Feb 19 12:37:45 2008
From: Vladimir.Marangozov at t-online.de (Vladimir Marangozov)
Date: Tue, 19 Feb 2008 12:37:45 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
Message-ID: <000001c872eb$d974a340$022efea9@ESII9100>


May I chime in? :-)

Gents, the current implementation of Python's memory management
is really fine and most problems it used to have in the past
have been fixed in recent years (at least the ones I know of).

Probably the only one left, indeed, is the potential unbounded
growth of int/float objects' freelists (beyond the shared cache
of small ints).  Yet, this seems to be a questionable problem
because any change in the freelists' management will invariably
slow down their allocation.  By how much, I don't know, but
whether you fallback to pymalloc above a certain threshold or
use something else, the change will have a generic perf hit.

The explanation is simple: you can't beat the free list scheme
performance when you have frequent short bursts of allocations
and deallocations, which is the typical Python pattern observed
on New() & DECREF() calls.

BTW if you have 2 AMD combos showing speedups noone can explain
in an obvious way, then it's a cache effect.

Optimizing pymalloc for non-standard byte-sizes is a no go, and
although I've seen suggestions for further optimizations tailored
to ints and floats, I haven't seen anyone spelling out what that
optimization of pymalloc would consist of.

MAL's suggestion to preallocate a pymalloc pool cache for certain
object sizes is something I actually implemented in the earliest
versions of pymalloc, but eventually dropped in favor of the
current dynamic, on-request allocation because pre-allocating pools
(and initializing the free lists) costs time and in general leads
to degraded performance in the average case.  I can't perf this
now to prove it, but that was very clear at the time when I wrote
the original stuff and applied the regression test on it.

So I would kindly suggest to get down to the only problem (if any)
which is the uncontrolled growth of the specialized freelists, the
shared int cache notwithstanding.  If you can limit a degenerative
growth without a noticeable generic perf sacrifice, that would
sound like an improvement to me, but so far I haven't seen any
convincing arguments.

And, of course, if the int/float freelist scheme was a real issue
we would have probably heard of it by now in a very sound way.

Vladimir


From skip.montanaro at gmail.com  Fri Feb 22 01:55:38 2008
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Thu, 21 Feb 2008 18:55:38 -0600
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <bbaeab100802211317t7d0b2371ld8e70fc615d49868@mail.gmail.com>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
	<bbaeab100802211317t7d0b2371ld8e70fc615d49868@mail.gmail.com>
Message-ID: <60bb7ceb0802211655y2ea30938y7a64bda9c55ac4e4@mail.gmail.com>

Why not just skip the specifics except to say < 80 characters for all
lines?  Don't mention 72, 79 or any other number than 80:

      Maximum Line Length

	There are still many devices around that are limited to 80 character
	lines; plus, limiting windows to 80 characters makes it possible to have
	several windows side-by-side.  The default wrapping on such devices
	disrupts the visual structure of the code, making it more difficult to
	understand.  Therefore, please limit all lines to less than 80
	characters.

	...

Skip

From python at rcn.com  Fri Feb 22 02:17:13 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 21 Feb 2008 20:17:13 -0500 (EST)
Subject: [Python-Dev] dir() and __all__
Message-ID: <20080221201713.AHJ43736@ms19.lnh.mail.rcn.net>

[Benjamin]
> Are you proposing just a list those modules 
> or all module objects? 

The idea is dead.  Guido specified that the 
dir() function returns a list of names for
which hasattr() will succeed.

I only brought this up because a colleague was
using dir() on modules to find-out about the API.
He was thrown-off by some of the entries in dir(logging).


Raymond

From eric+python-dev at trueblade.com  Fri Feb 22 03:21:00 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 21 Feb 2008 21:21:00 -0500
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <20080221182320.AHJ31576@ms19.lnh.mail.rcn.net>
References: <20080221182320.AHJ31576@ms19.lnh.mail.rcn.net>
Message-ID: <47BE318C.5000205@trueblade.com>

Raymond Hettinger wrote:
> [Eric Smith]
>> I'm going to work on backporting PEP 3127, specifically 
>> the hex, oct(), and bin() builtins.
> 
> IMO, these should not be backported. They are strongly
> associated with 3.0's new literal syntax.  They don't
> don't really fit in with 2.6 and don't make 2.6 any more
> attractive.

I'm just going by what's on the spreadsheet.  I assumed that these were 
all vetted.

http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg&gid=2

Speaking for myself, these features are generally useful, and are so 
even without the new integer literal syntax.  Their existence would make 
2.6 more attractive to me.

Eric.

From python at rcn.com  Fri Feb 22 03:54:06 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 21 Feb 2008 21:54:06 -0500 (EST)
Subject: [Python-Dev] Backporting PEP 3127 to trunk
Message-ID: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net>

[Eric Smith]
> Speaking for myself, these features are generally useful,
> and are so even without the new integer literal syntax.

I'm curious how these are useful to you in Py2.6 where
they are not invertible.  In Py3.0, we can count on

  x == int(bin(x), 2)
  x == eval(bin(x))

I don't see how these could work in Py2.6 without
changing the parser and changing the int() function.

Why would you ever want to create a string like
'0o144' when there is no way to convert the string
back into a value?  

Having both 0123 and 0o123 in the same version of
language will create a confused mess, IMO.

We should draw the line on Py3.0 backports whenever
the two different models would be conflated 
(i.e. str/unicode vs bytes/text or 0123 vs 0o123).


Raymond


  

From eric+python-dev at trueblade.com  Fri Feb 22 04:02:30 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 21 Feb 2008 22:02:30 -0500
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net>
References: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net>
Message-ID: <47BE3B46.1080006@trueblade.com>

Raymond Hettinger wrote:
> [Eric Smith]
>> Speaking for myself, these features are generally useful,
>> and are so even without the new integer literal syntax.
> 
> I'm curious how these are useful to you in Py2.6 where
> they are not invertible.  In Py3.0, we can count on
> 
>   x == int(bin(x), 2)
>   x == eval(bin(x))
> 
> I don't see how these could work in Py2.6 without
> changing the parser and changing the int() function.
> 
> Why would you ever want to create a string like
> '0o144' when there is no way to convert the string
> back into a value?  

Because I need to output the values, for debugging and other purposes. 
I have no need to eval something I've bin'd, so I don't need them to be 
invertible.  Same with hex.

I realize I could just write these functions myself in Python, and not 
use the builtins.  But I don't see the drawback of them being in 2.6.

Eric.


From nnorwitz at gmail.com  Fri Feb 22 05:47:33 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 21 Feb 2008 20:47:33 -0800
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <47BDFA81.8000805@trueblade.com>
References: <47BDFA81.8000805@trueblade.com>
Message-ID: <ee2a432c0802212047y6a6e4c7eld491d8aba7c32a2a@mail.gmail.com>

On Thu, Feb 21, 2008 at 2:26 PM, Eric Smith
<eric+python-dev at trueblade.com> wrote:
> I'm going to work on backporting PEP 3127, specifically the hex, oct(),
>  and bin() builtins.  I have bin() completed, and I'll check it in
>  shortly.  oct() will require a future import.  Does anyone have any
>  pointers for implementing this?  I understand (and have completed)
>  adding the future import, but what I don't understand is how to modify
>  the behavior of oct() for only the module where the future import is
>  execute.  Any rough ideas or pointers to existing code that does
>  something similar would be helpful.

See co_flags in PyCodeObject in Include/code.h.  When you are
compiling the code objects, you have access to the future flags.
These (can) get baked into the code objects when they are created.
You will need to make a new CO_* macro (0x10000 is the next available
after CO_FUTURE_WITH_STATEMENT).

In the past future imports have typically affected the parser or
semantics of the VM (e.g., future division).  In your case, you need
something different.  Thomas Wouters had a somewhat similar problem
when changing dict methods.  In his case though, he output different
op codes for the interpreter to execute to call the proper methods
(*).  You could use a similar trick here.  However, if you were doing
that, it begs the question of why not do as Guido suggests and just
replace the builtins.

If you only stored the info in the co_flags of code objects, the only
way I know of would be to access the callers frame and get its
co_flags.  This is yucky.  For example, what if oct() was called from
C code?

I think Guido's suggestion makes the most sense.  My description above
is just so people know what needs to be done, not a recommendation
that it ought to be done.

n

(*) - e.g. STORE_VIEWATTR in
http://svn.python.org/projects/python/branches/twouters-dictviews-backport/Python/ceval.c
http://svn.python.org/projects/python/branches/twouters-dictviews-backport/Python/compile.c

From nnorwitz at gmail.com  Fri Feb 22 05:56:20 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 21 Feb 2008 20:56:20 -0800
Subject: [Python-Dev] Unit Test Guide
In-Reply-To: <02e23208-c0ec-4998-b73f-7b571a73264f@41g2000hsc.googlegroups.com>
References: <2a70578d0802210330oe973e87gf314a190f0880ae6@mail.gmail.com>
	<02e23208-c0ec-4998-b73f-7b571a73264f@41g2000hsc.googlegroups.com>
Message-ID: <ee2a432c0802212056k1a78f46ck8f67e3faee0b6a89@mail.gmail.com>

On Thu, Feb 21, 2008 at 7:43 AM, Giampaolo Rodola' <gnewsg at gmail.com> wrote:
>
>  I have usually seen a lot of tests implemented like this:
>
>  from test.test_support import TESTFN, unlink
>  import unittest
>
>  class TestCase(unittest.TestCase):
>
>     def setUp(self):
>         self.file = None
>
>     def tearDown(self):
>         if self.file is not None:
>             self.file.close()
>         unlink(TESTFN)
>
>     def test_something(self):
>         self.file = open(TESTFN, 'r')
>         ...

Yes, but this is not as robust as it could be.  It's better to also
unlink/rmtree in the setUp.  That way if the file doesn't get cleaned
up (interpreter crash, KeyboardInterrupt, file not closed on Windows,
exception in tearDown, etc), the test won't fail on the next run or
the next test that assumes TESTFN doesn't exist won't fail.

n

From amauryfa at gmail.com  Fri Feb 22 09:01:27 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Fri, 22 Feb 2008 09:01:27 +0100
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <60bb7ceb0802211655y2ea30938y7a64bda9c55ac4e4@mail.gmail.com>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
	<bbaeab100802211317t7d0b2371ld8e70fc615d49868@mail.gmail.com>
	<60bb7ceb0802211655y2ea30938y7a64bda9c55ac4e4@mail.gmail.com>
Message-ID: <e27efe130802220001ua07c105lec3daafd61689a05@mail.gmail.com>

Skip Montanaro wrote:
> Why not just skip the specifics except to say < 80 characters for all
>  lines?  Don't mention 72, 79 or any other number than 80:

I often run "svn diff" in a console limited to 80 characters.
Because of the leading "+", lines longer than 78 wrap, and the output
is more difficult to read.

-- 
Amaury Forgeot d'Arc

From kristjan at ccpgames.com  Fri Feb 22 10:19:20 2008
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Fri, 22 Feb 2008 09:19:20 +0000
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <e27efe130802220001ua07c105lec3daafd61689a05@mail.gmail.com>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
	<bbaeab100802211317t7d0b2371ld8e70fc615d49868@mail.gmail.com>
	<60bb7ceb0802211655y2ea30938y7a64bda9c55ac4e4@mail.gmail.com>
	<e27efe130802220001ua07c105lec3daafd61689a05@mail.gmail.com>
Message-ID: <4E9372E6B2234D4F859320D896059A950FB09B2A5A@exchis.ccp.ad.local>

And this is then compounded if you then proceed to diff those diff outputs.
Maybe we should just use vertical spacing?

> -----Original Message-----
> From: python-dev-bounces+kristjan=ccpgames.com at python.org
> [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On Behalf
> Of Amaury Forgeot d'Arc
> Sent: Friday, February 22, 2008 08:01
> To: Skip Montanaro
> Cc: python-dev Dev
> Subject: Re: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-
> 0008.txt
>
> Skip Montanaro wrote:
> > Why not just skip the specifics except to say < 80 characters for all
> >  lines?  Don't mention 72, 79 or any other number than 80:
>
> I often run "svn diff" in a console limited to 80 characters.
> Because of the leading "+", lines longer than 78 wrap, and the output
> is more difficult to read.
>


From andymac at bullseye.apana.org.au  Fri Feb 22 11:14:55 2008
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Fri, 22 Feb 2008 20:14:55 +1000
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <000001c872eb$d974a340$022efea9@ESII9100>
References: <000001c872eb$d974a340$022efea9@ESII9100>
Message-ID: <47BEA09F.7020607@bullseye.andymac.org>

Vladimir Marangozov wrote:
> May I chime in? :-)

Please do!

> Gents, the current implementation of Python's memory management
> is really fine and most problems it used to have in the past
> have been fixed in recent years (at least the ones I know of).
 >
> Probably the only one left, indeed, is the potential unbounded
> growth of int/float objects' freelists (beyond the shared cache
> of small ints).  Yet, this seems to be a questionable problem
> because any change in the freelists' management will invariably
> slow down their allocation.  By how much, I don't know, but
> whether you fallback to pymalloc above a certain threshold or
> use something else, the change will have a generic perf hit.

The performance hit is there, but my testing indicates its mostly not
dramatic (& when its dramatic it only shows in microbenchmarks...).
For me, "dramatic" is more than 10% gain/loss in non-trivial benchmarks.

> The explanation is simple: you can't beat the free list scheme
> performance when you have frequent short bursts of allocations
> and deallocations, which is the typical Python pattern observed
> on New() & DECREF() calls.

I never expected that it could be beaten.  I set out to find out how
close simple alloc/dealloc via PyMalloc was to the freelists,  and my
testing suggests its pretty close, to the point that only the int & tuple
freelists have IMO a clear-cut claim to retention.

> BTW if you have 2 AMD combos showing speedups noone can explain
> in an obvious way, then it's a cache effect.

Figured as much.  No-one with an intel CPU (or a different compiler) has
as yet offered any equivalent test results - I would very much like to
see them, but I'm not prepared ATM to buy another box to find out...

> Optimizing pymalloc for non-standard byte-sizes is a no go, and
> although I've seen suggestions for further optimizations tailored
> to ints and floats, I haven't seen anyone spelling out what that
> optimization of pymalloc would consist of.

I figured Tim Peters would have done pretty much anything that could have
been done when he polished PyMalloc up for default use in 2.3.

> MAL's suggestion to preallocate a pymalloc pool cache for certain
> object sizes is something I actually implemented in the earliest
> versions of pymalloc, but eventually dropped in favor of the
> current dynamic, on-request allocation because pre-allocating pools
> (and initializing the free lists) costs time and in general leads
> to degraded performance in the average case.  I can't perf this
> now to prove it, but that was very clear at the time when I wrote
> the original stuff and applied the regression test on it.

Good to know that alley has been checked and found a dead end.

> So I would kindly suggest to get down to the only problem (if any)
> which is the uncontrolled growth of the specialized freelists, the
> shared int cache notwithstanding.  If you can limit a degenerative
> growth without a noticeable generic perf sacrifice, that would
> sound like an improvement to me, but so far I haven't seen any
> convincing arguments.

Christian's compaction routine will get the job done, but IMO it should
be (as he himself has proposed) called from gc.collect() rather than
callable as a function in sys.

> And, of course, if the int/float freelist scheme was a real issue
> we would have probably heard of it by now in a very sound way.

Not much noise has been made here, but I've come across 2 separate
complaints in different mailing lists in the last month (one of the
complainants had some hope that gc.collect() might help...)  Is it a
deafening roar?  No, but I doubt the volume will do anything but
increase...

Regards,
Andrew.

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

From ncoghlan at gmail.com  Fri Feb 22 11:36:51 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 22 Feb 2008 20:36:51 +1000
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<47BA1C14.7090906@v.loewis.de>	<2a70578d0802182352n4d7cabeeud4757ecdef488246@mail.gmail.com>	<47BA8C97.1000300@v.loewis.de>	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>	<47BCBC60.8090808@v.loewis.de>	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
Message-ID: <47BEA5C3.6050006@gmail.com>

Gregory P. Smith wrote:
> I'm always faced with a tiny quandry when closing a fixed bug that had a 
> patch to fix it attached because both seem to apply.  ;-)

I try to use 'fixed' for those, with my closure comment indicating 
whether the fix used the attached patch (or a variant thereof) or 
something completely different.

Combining 'fixed' and 'accepted' into something generic like 'resolved' 
is no good, since 'not a bug' is also a resolution from our point of 
view, even if the original author of the issue may not particularly like 
the answer :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From facundobatista at gmail.com  Fri Feb 22 12:29:25 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 22 Feb 2008 08:29:25 -0300
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <bbaeab100802211324p8b01f8p5c22ea143b9e8454@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<e04bdf310802210806q60ab9165rb4c552d1215e47a4@mail.gmail.com>
	<bbaeab100802211324p8b01f8p5c22ea143b9e8454@mail.gmail.com>
Message-ID: <e04bdf310802220329i25702935h70ab0afca05bbce2@mail.gmail.com>

2008/2/21, Brett Cannon <brett at python.org>:

> Something like "handle" or "resolved". An issue is an issue and we
>  wanting a single way to say the issue was closed because what is was
>  about was handled seems reasonable.

+1 to resolved.

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From facundobatista at gmail.com  Fri Feb 22 12:34:24 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 22 Feb 2008 08:34:24 -0300
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BDD748.3000407@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<e04bdf310802210806q60ab9165rb4c552d1215e47a4@mail.gmail.com>
	<47BDD748.3000407@v.loewis.de>
Message-ID: <e04bdf310802220334kf7e8f90i9c7d5935f8a06d4a@mail.gmail.com>

2008/2/21, "Martin v. L?wis" <martin at v.loewis.de>:

>  It's possible to "retire" objects in Roundup: certain resolution values
>  would still be present and referenced by issues that use it, but they
>  would not appear anymore in the drop-down list.

We can go one step further: If we change "fixed" and "accepted" as
"resolved" (for example), we can change all the values directly in the
database, so they all appear as "resolved" now.

I don't want to propose anything specific regarding words, I'm just
saying that having eleven options to close an issue are too many if we
want to keep consistency.

Note that they're not clear enough to make them obvious, otherwise the
consensus in this thread would have been faster, ;)

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From facundobatista at gmail.com  Fri Feb 22 12:31:01 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 22 Feb 2008 08:31:01 -0300
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BEA5C3.6050006@gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
Message-ID: <e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>

2008/2/22, Nick Coghlan <ncoghlan at gmail.com>:

>  Combining 'fixed' and 'accepted' into something generic like 'resolved'
>  is no good, since 'not a bug' is also a resolution from our point of
>  view, even if the original author of the issue may not particularly like
>  the answer :)

First two definitions of "resolve" from the American Heritage dict:

  1. To make a firm decision about.
  2. To cause (a person) to reach a decision.

I think it applies quite well.

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From ncoghlan at gmail.com  Fri Feb 22 12:57:16 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 22 Feb 2008 21:57:16 +1000
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	
	<47BA8C97.1000300@v.loewis.de>	
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>	
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>	
	<47BCBC60.8090808@v.loewis.de>	
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>	
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>	
	<47BD9DBC.2030106@holdenweb.com>	
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>	
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
Message-ID: <47BEB89C.6080300@gmail.com>

Facundo Batista wrote:
> First two definitions of "resolve" from the American Heritage dict:
> 
>   1. To make a firm decision about.
>   2. To cause (a person) to reach a decision.
> 
> I think it applies quite well.

It only tells you that a resolution was reached, not what that 
resolution was.

"Resolution: resolved" is meaningless repetition - what matters is *how* 
the issue was resolved, and simply saying 'resolved' doesn't tell 
anybody that. 'Fixed', 'accepted', 'invalid', 'rejected' , etc are 
resolutions since they give you some idea of how the issue was resolved 
- the only thing missing is a definition of just how they should be used.*

Now, dropping 'later', 'postponed' and 'remind' from the list of 
available resolutions is something I could wholeheartedly support. If we 
want to postpone something to a later release, we should put an 
appropriate entry in the version list.

My stab at definitions for the other resolutions:

   # Feature request resolutions
   accepted - feature request accepted (possibly via attached patch)
   rejected - feature request rejected

   # Bug report resolutions
   fixed - reported bug fixed (possibly via attached patch)
   invalid - reported behaviour is intentional and not a bug
   works for me - bug could not be replicated from bug report
   out of date - bug is already fixed in later Python version
   wont fix - valid bug, but not fixable in CPython (very rare)

   # Common resolutions
   duplicate - same as another issue (refer to other issue in a comment)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From facundobatista at gmail.com  Fri Feb 22 13:28:09 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 22 Feb 2008 09:28:09 -0300
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BEB89C.6080300@gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
Message-ID: <e04bdf310802220428x15ffbed6h465dc9d34728dc01@mail.gmail.com>

2008/2/22, Nick Coghlan <ncoghlan at gmail.com>:

>  Now, dropping 'later', 'postponed' and 'remind' from the list of
>  available resolutions is something I could wholeheartedly support. If we
>  want to postpone something to a later release, we should put an
>  appropriate entry in the version list.
>
>  My stab at definitions for the other resolutions:
>
>    # Feature request resolutions
>    accepted - feature request accepted (possibly via attached patch)
>    rejected - feature request rejected
>
>    # Bug report resolutions
>    fixed - reported bug fixed (possibly via attached patch)
>    invalid - reported behaviour is intentional and not a bug
>    works for me - bug could not be replicated from bug report
>    out of date - bug is already fixed in later Python version
>    wont fix - valid bug, but not fixable in CPython (very rare)
>
>    # Common resolutions
>    duplicate - same as another issue (refer to other issue in a comment)

Fair enough.

There's missing one use case: how we mark an issue that is not such?
I'm talking about issues opened without an explanation, nothing saying
what is wrong, or which behaviour is strange or wrong for the original
poster, etc. Those issues that you want to answer "go back and learn
how to explain yourself".

Thanks!

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From ziade.tarek at gmail.com  Fri Feb 22 15:56:22 2008
From: ziade.tarek at gmail.com (=?UTF-8?Q?Tarek_Ziad=C3=A9?=)
Date: Fri, 22 Feb 2008 06:56:22 -0800 (PST)
Subject: [Python-Dev]  Tomorrow's bug day and issue #1858
Message-ID: <15634227.post@talk.nabble.com>


Hello,

I have prepared a request for enhancement for distutils, together with its
patch that also adds more tests for the package.

This was discussed in catalog-sig, and explained here :
http://wiki.python.org/moin/EnhancedPyPI (see pypirc section). I have
followed Brett Cannon's slides to make the patch on the 2.6 trunk (great doc
thanks!). 

I would like to propose this rfe tomorrow at the bug day, amongst other bugs
I can try to work on.

But I don't know if I should propose it here first since it was previously
discussed on catalog-sig,
so here it is :)

Regards

Tarek Ziad?

 
-- 
View this message in context: http://www.nabble.com/Tomorrow%27s-bug-day-and-issue--1858-tp15634227p15634227.html
Sent from the Python - python-dev mailing list archive at Nabble.com.


From g.brandl at gmx.net  Fri Feb 22 17:05:49 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 22 Feb 2008 17:05:49 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BEB89C.6080300@gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>		<47BA8C97.1000300@v.loewis.de>		<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>		<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>		<47BCBC60.8090808@v.loewis.de>		<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>		<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>		<47BD9DBC.2030106@holdenweb.com>		<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>		<47BEA5C3.6050006@gmail.com>	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
Message-ID: <fpmrso$ngn$1@ger.gmane.org>

Nick Coghlan schrieb:
> Facundo Batista wrote:
>> First two definitions of "resolve" from the American Heritage dict:
>> 
>>   1. To make a firm decision about.
>>   2. To cause (a person) to reach a decision.
>> 
>> I think it applies quite well.
> 
> It only tells you that a resolution was reached, not what that 
> resolution was.
> 
> "Resolution: resolved" is meaningless repetition - what matters is *how* 
> the issue was resolved, and simply saying 'resolved' doesn't tell 
> anybody that. 'Fixed', 'accepted', 'invalid', 'rejected' , etc are 
> resolutions since they give you some idea of how the issue was resolved 
> - the only thing missing is a definition of just how they should be used.*
> 
> Now, dropping 'later', 'postponed' and 'remind' from the list of 
> available resolutions is something I could wholeheartedly support. If we 
> want to postpone something to a later release, we should put an 
> appropriate entry in the version list.

+1

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  Fri Feb 22 17:12:16 2008
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 22 Feb 2008 10:12:16 -0600
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <e27efe130802220001ua07c105lec3daafd61689a05@mail.gmail.com>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
	<bbaeab100802211317t7d0b2371ld8e70fc615d49868@mail.gmail.com>
	<60bb7ceb0802211655y2ea30938y7a64bda9c55ac4e4@mail.gmail.com>
	<e27efe130802220001ua07c105lec3daafd61689a05@mail.gmail.com>
Message-ID: <18366.62560.100720.755828@montanaro-dyndns-org.local>


    >> Why not just skip the specifics except to say < 80 characters for all
    >> lines?  Don't mention 72, 79 or any other number than 80:

    Amaury> I often run "svn diff" in a console limited to 80 characters.
    Amaury> Because of the leading "+", lines longer than 78 wrap, and the
    Amaury> output is more difficult to read.

There will always be certain cases which present probems.  I use "svn
annotate" from time-to-time which adds an even wider margin to the left.
In those situations I either grin and bear it or stretch my window enough to
view it without wrapping.

Skip

From phd at phd.pp.ru  Fri Feb 22 17:16:35 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Fri, 22 Feb 2008 19:16:35 +0300
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <18366.62560.100720.755828@montanaro-dyndns-org.local>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
	<bbaeab100802211317t7d0b2371ld8e70fc615d49868@mail.gmail.com>
	<60bb7ceb0802211655y2ea30938y7a64bda9c55ac4e4@mail.gmail.com>
	<e27efe130802220001ua07c105lec3daafd61689a05@mail.gmail.com>
	<18366.62560.100720.755828@montanaro-dyndns-org.local>
Message-ID: <20080222161635.GE11564@phd.pp.ru>

On Fri, Feb 22, 2008 at 10:12:16AM -0600, skip at pobox.com wrote:
> I use "svn
> annotate" from time-to-time which adds an even wider margin to the left.
> In those situations I either grin and bear it or stretch my window enough to
> view it without wrapping.

   svn blame | less -S

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  Fri Feb 22 17:17:45 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 22 Feb 2008 08:17:45 -0800
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net>
References: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net>
Message-ID: <ca471dc20802220817s51062111r30dff8bd654f9d25@mail.gmail.com>

On Thu, Feb 21, 2008 at 6:54 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Eric Smith]
>
> > Speaking for myself, these features are generally useful,
>  > and are so even without the new integer literal syntax.
>
>  I'm curious how these are useful to you in Py2.6 where
>  they are not invertible.  In Py3.0, we can count on
>
>   x == int(bin(x), 2)
>   x == eval(bin(x))
>
>  I don't see how these could work in Py2.6 without
>  changing the parser and changing the int() function.

And it needn't work. Nobody actually ever *uses* eval() on repr()
output (well, practically nobody :-).

>  Why would you ever want to create a string like
>  '0o144' when there is no way to convert the string
>  back into a value?
>
>  Having both 0123 and 0o123 in the same version of
>  language will create a confused mess, IMO.

I don't see why. 2.6 already has b'...' as an alias for '...', and
'except E as v' as an alias for 'except E, v'.

>  We should draw the line on Py3.0 backports whenever
>  the two different models would be conflated
>  (i.e. str/unicode vs bytes/text or 0123 vs 0o123).

I draw the line differently. Backports are absolutely not allowed to
break working code that used to work in 2.5. Apart from that, there is
no great harm in 2.6 supporting both the old and the new way. After
all we already have lots of places where Python 2.x supports an old
and a new way (e.g. string exceptions up to 2.5, classic classes, old
and rich comparisons).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From aahz at pythoncraft.com  Fri Feb 22 17:18:02 2008
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 22 Feb 2008 08:18:02 -0800
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <47BEA09F.7020607@bullseye.andymac.org>
References: <000001c872eb$d974a340$022efea9@ESII9100>
	<47BEA09F.7020607@bullseye.andymac.org>
Message-ID: <20080222161802.GA7354@panix.com>

On Fri, Feb 22, 2008, Andrew MacIntyre wrote:
> Vladimir Marangozov wrote:
>> 
>> And, of course, if the int/float freelist scheme was a real issue
>> we would have probably heard of it by now in a very sound way.
> 
> Not much noise has been made here, but I've come across 2 separate
> complaints in different mailing lists in the last month (one of the
> complainants had some hope that gc.collect() might help...)  Is it a
> deafening roar?  No, but I doubt the volume will do anything but
> increase...

Actually, it's a regular issue that crops up on c.l.py, but almost
always in the context of range(bignum).  Because there's an easy
workaround and Python 3.0 changes the semantics of range(), there hasn't
been much clamor to fix it.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of     
indirection."  --Butler Lampson

From aahz at pythoncraft.com  Fri Feb 22 17:20:26 2008
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 22 Feb 2008 08:20:26 -0800
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <18366.62560.100720.755828@montanaro-dyndns-org.local>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
	<bbaeab100802211317t7d0b2371ld8e70fc615d49868@mail.gmail.com>
	<60bb7ceb0802211655y2ea30938y7a64bda9c55ac4e4@mail.gmail.com>
	<e27efe130802220001ua07c105lec3daafd61689a05@mail.gmail.com>
	<18366.62560.100720.755828@montanaro-dyndns-org.local>
Message-ID: <20080222162026.GB7354@panix.com>

On Fri, Feb 22, 2008, skip at pobox.com wrote:
>
> 
>     >> Why not just skip the specifics except to say < 80 characters for all
>     >> lines?  Don't mention 72, 79 or any other number than 80:
> 
>     Amaury> I often run "svn diff" in a console limited to 80 characters.
>     Amaury> Because of the leading "+", lines longer than 78 wrap, and the
>     Amaury> output is more difficult to read.
> 
> There will always be certain cases which present probems.  I use "svn
> annotate" from time-to-time which adds an even wider margin to the left.
> In those situations I either grin and bear it or stretch my window enough to
> view it without wrapping.

Yes, but svn/cvs diff is a particularly common use case.  I agree with
Amaury.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of     
indirection."  --Butler Lampson

From guido at python.org  Fri Feb 22 17:28:43 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 22 Feb 2008 08:28:43 -0800
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <20080222162026.GB7354@panix.com>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
	<bbaeab100802211317t7d0b2371ld8e70fc615d49868@mail.gmail.com>
	<60bb7ceb0802211655y2ea30938y7a64bda9c55ac4e4@mail.gmail.com>
	<e27efe130802220001ua07c105lec3daafd61689a05@mail.gmail.com>
	<18366.62560.100720.755828@montanaro-dyndns-org.local>
	<20080222162026.GB7354@panix.com>
Message-ID: <ca471dc20802220828s326fd695g9a8d8bff4bb78500@mail.gmail.com>

On Fri, Feb 22, 2008 at 8:20 AM, Aahz <aahz at pythoncraft.com> wrote:
> On Fri, Feb 22, 2008, skip at pobox.com wrote:
>  >
>  >
>  >     >> Why not just skip the specifics except to say < 80 characters for all
>  >     >> lines?  Don't mention 72, 79 or any other number than 80:
>  >
>  >     Amaury> I often run "svn diff" in a console limited to 80 characters.
>  >     Amaury> Because of the leading "+", lines longer than 78 wrap, and the
>  >     Amaury> output is more difficult to read.
>  >
>  > There will always be certain cases which present probems.  I use "svn
>  > annotate" from time-to-time which adds an even wider margin to the left.
>  > In those situations I either grin and bear it or stretch my window enough to
>  > view it without wrapping.
>
>  Yes, but svn/cvs diff is a particularly common use case.  I agree with
>  Amaury.

-1. There's just no way that 78 is enforceable. At Google, sticking to
80 is a continuous battle, and we use 2-space indents!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From python at rcn.com  Fri Feb 22 18:06:34 2008
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 22 Feb 2008 09:06:34 -0800
Subject: [Python-Dev] Backporting PEP 3127 to trunk
References: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net>
	<ca471dc20802220817s51062111r30dff8bd654f9d25@mail.gmail.com>
Message-ID: <000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>

[GvR]
>. After
> all we already have lots of places where Python 2.x supports an old
> and a new way (e.g. string exceptions up to 2.5, classic classes, old
> and rich comparisons).

I thought the whole point of 3.0 was a recognition that all that 
doubling-up was a bad thing and to be rid of it.  Why make the
situation worse?  ISTM that we need two versions of oct() like
we need a hole in the head.  Heck, there's potentially a case to be
made that we don't need oct() at all.  IIRC, unix permissions like
0666 were the only use case that surfaced.

Also, I thought that the only reason you allowed b'' to be an alias for ''
in 2.6 was that it was the only way 2-to-3 converter would work.
That same rationale doesn't seem to apply here. I don't really see
why the necessity of b'' should be seen as opening the flood gates
to backport everything without regard to whether it makes Py2.6 better.


Raymond

From status at bugs.python.org  Fri Feb 22 18:06:15 2008
From: status at bugs.python.org (Tracker)
Date: Fri, 22 Feb 2008 18:06:15 +0100 (CET)
Subject: [Python-Dev] Summary of Tracker Issues
Message-ID: <20080222170615.831E078263@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (02/15/08 - 02/22/08)
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.


 1732 open (+27) / 12258 closed (+11) / 13990 total (+38)

Open issues with patches:   456

Average duration of open issues: 742 days.
Median duration of open issues: 1095 days.

Open Issues Breakdown
   open  1708 (+27)
pending    24 ( +0)

Issues Created Or Reopened (39)
_______________________________

libffi needs an update to support mips64, arm and armeabi on lin 02/21/08
       http://bugs.python.org/issue1292    reopened theller                   
                                                                               

BaseHTTPServer.py fails long POST from IE                        02/16/08
       http://bugs.python.org/issue2126    created  juneaftn                  
                                                                               

sqlite3 docs should mention utf8 requirement                     02/16/08
       http://bugs.python.org/issue2127    created  resolve1                  
                                                                               

sys.argv is wrong for unicode strings                            02/16/08
       http://bugs.python.org/issue2128    created  giovannibajo              
                                                                               

Link error of gethostbyaddr and gethostname in Python Manuals (t 02/16/08
       http://bugs.python.org/issue2129    created  juneaftn                  
                                                                               

[feature-request] Please add bool data type to "optparse" module 02/16/08
       http://bugs.python.org/issue2130    created  Technologov               
       easy                                                                    

"codecs" module on Windows uses incorrect end-of-line, wiriting  02/16/08
CLOSED http://bugs.python.org/issue2131    created  Technologov               
                                                                               

Blocking sockets take entirely too long to timeout               02/17/08
       http://bugs.python.org/issue2132    created  khiltd                    
                                                                               

a typo in pydoc.py causes modules to be cyan instead of white    02/17/08
CLOSED http://bugs.python.org/issue2133    created  elliotth                  
                                                                               

function generate_tokens at tokenize.py yields wrong token for c 02/17/08
       http://bugs.python.org/issue2134    created  gpolo                     
       patch                                                                   

Restructure import.c into PEP 302 importer objects               02/17/08
       http://bugs.python.org/issue2135    created  dgreiman                  
       patch                                                                   

urllib2 basic auth handler doesn't handle realm names in single- 02/18/08
       http://bugs.python.org/issue2136    created  varmaa                    
                                                                               

test_crasher in test_struct uses 8 GB memory on 64 bit systems   02/18/08
CLOSED http://bugs.python.org/issue2137    created  schmir                    
                                                                               

Factorial                                                        02/18/08
       http://bugs.python.org/issue2138    created  dtorp                     
                                                                               

sqlite3 module needs upgrading                                   02/18/08
CLOSED http://bugs.python.org/issue2139    created  carloverre                
                                                                               

calculation bug in long() function                               02/18/08
CLOSED http://bugs.python.org/issue2140    created  must21                    
                                                                               

Pydoc interactive browser misses some docs                       02/18/08
       http://bugs.python.org/issue2141    created  moreilcon                 
                                                                               

naive use of ''.join(difflib.unified_diff(...)) results in bogus 02/18/08
       http://bugs.python.org/issue2142    created  trentm                    
       patch                                                                   

smtplib.SSLFakeFile hangs forever if "\n" is not encountered     02/19/08
       http://bugs.python.org/issue2143    created  giampaolo.rodola          
                                                                               

os.environ should inherit dict                                   02/19/08
       http://bugs.python.org/issue2144    created  benjamin.peterson         
                                                                               

ctypes.util.find_library(): posix .so without SONAME             02/20/08
       http://bugs.python.org/issue2145    created  haypo                     
                                                                               

ctypes: support double for calling function                      02/20/08
CLOSED http://bugs.python.org/issue2146    created  haypo                     
                                                                               

int operations no longer overflow                                02/20/08
       http://bugs.python.org/issue2147    created  nnorwitz                  
                                                                               

nis module not supporting group aliases                          02/20/08
       http://bugs.python.org/issue2148    created  ernstp                    
                                                                               

Queue.maxsize, __init__() accepts any value as maxsize           02/20/08
CLOSED http://bugs.python.org/issue2149    created  zanella                   
                                                                               

Broken Link to New Style Classes Documentation                   02/21/08
CLOSED http://bugs.python.org/issue2150    created  passage                   
                                                                               

no way to get http result status from urllib                     02/21/08
CLOSED http://bugs.python.org/issue2151    created  phr                       
                                                                               

make sqlite.Row hashable correctly                               02/21/08
       http://bugs.python.org/issue2152    created  theller                   
       patch                                                                   

unittest.py modernization                                        02/21/08
       http://bugs.python.org/issue2153    created  vdupras                   
       patch                                                                   

doc: better detection of python snippets for highliting          02/21/08
CLOSED http://bugs.python.org/issue2154    created  amaury.forgeotdarc        
       patch                                                                   

optparse.OptionGroup with_statement context handling             02/21/08
       http://bugs.python.org/issue2155    created  hoffman                   
                                                                               

TestCase.tmpdir(), TestCase.mock()                               02/21/08
CLOSED http://bugs.python.org/issue2156    created  vdupras                   
                                                                               

sqlite numeric type conversion problems                          02/21/08
       http://bugs.python.org/issue2157    created  wrobell                   
                                                                               

confusing exception when opening a filename with nonprintable ch 02/21/08
       http://bugs.python.org/issue2158    created  irving                    
                                                                               

dbmmodule inquiry function is performance prohibitive            02/22/08
       http://bugs.python.org/issue2159    created  johansen                  
                                                                               

Document PyImport_GetImporter                                    02/22/08
       http://bugs.python.org/issue2160    created  belopolsky                
       patch                                                                   

STORE_LOCAL byte code is not documented                          02/22/08
       http://bugs.python.org/issue2161    created  troeger                   
                                                                               

unittest.findTestCases undocumented                              02/22/08
       http://bugs.python.org/issue2162    created  slinkp                    
                                                                               

test_socket is flakey                                            02/22/08
       http://bugs.python.org/issue2163    created  gvanrossum                
       easy                                                                    



Issues Now Closed (32)
______________________

SimpleHTTPServer doesn't understand // at beginning of path anym  140 days
       http://bugs.python.org/issue1224    facundobatista            
       easy                                                                    

IDLE - Fix several highlighting bugs                              112 days
       http://bugs.python.org/issue1334    kbk                       
       patch                                                                   

IDLE hangs if os.spwanv command is given                           66 days
       http://bugs.python.org/issue1599    kbk                       
                                                                               

Remove cmp parameter to list.sort() and builtin.sorted()           39 days
       http://bugs.python.org/issue1771    LeWiemann                 
                                                                               

unhelpful error when calling "python <dirname>"                    33 days
       http://bugs.python.org/issue1877    belopolsky                
       easy                                                                    

Add inspect.isgenerator                                            26 days
       http://bugs.python.org/issue1916    facundobatista            
       easy                                                                    

IDLE - make ScriptBinding event handlers return 'break'             7 days
       http://bugs.python.org/issue2050    kbk                       
       patch                                                                   

UserDict documentation typo                                         9 days
       http://bugs.python.org/issue2079    georg.brandl              
                                                                               

mmap.error should be a subclass of EnvironmentError and not a di    3 days
       http://bugs.python.org/issue2112    facundobatista            
       patch, easy                                                             

test_decimal failure on OSX 10.3                                    5 days
       http://bugs.python.org/issue2114    ronaldoussoren            
                                                                               

__slots__ make attribute setting 10x slower                         1 days
       http://bugs.python.org/issue2115    amaury.forgeotdarc        
                                                                               

broken links in advocacy HOWTO                                      1 days
       http://bugs.python.org/issue2120    georg.brandl              
                                                                               

"codecs" module on Windows uses incorrect end-of-line, wiriting     1 days
       http://bugs.python.org/issue2131    lemburg                   
                                                                               

a typo in pydoc.py causes modules to be cyan instead of white       0 days
       http://bugs.python.org/issue2133    georg.brandl              
                                                                               

test_crasher in test_struct uses 8 GB memory on 64 bit systems      1 days
       http://bugs.python.org/issue2137    schmir                    
                                                                               

sqlite3 module needs upgrading                                      1 days
       http://bugs.python.org/issue2139    loewis                    
                                                                               

calculation bug in long() function                                  0 days
       http://bugs.python.org/issue2140    must21                    
                                                                               

ctypes: support double for calling function                         1 days
       http://bugs.python.org/issue2146    theller                   
                                                                               

Queue.maxsize, __init__() accepts any value as maxsize              1 days
       http://bugs.python.org/issue2149    rhettinger                
                                                                               

Broken Link to New Style Classes Documentation                      0 days
       http://bugs.python.org/issue2150    georg.brandl              
                                                                               

no way to get http result status from urllib                        0 days
       http://bugs.python.org/issue2151    georg.brandl              
                                                                               

doc: better detection of python snippets for highliting             0 days
       http://bugs.python.org/issue2154    georg.brandl              
       patch                                                                   

TestCase.tmpdir(), TestCase.mock()                                  0 days
       http://bugs.python.org/issue2156    purcell                   
                                                                               

TelnetPopen3, TelnetBase, Expect split                           1795 days
       http://bugs.python.org/issue708007  tiran                     
       patch                                                                   

unblock signals in threads                                       1361 days
       http://bugs.python.org/issue960406  gvanrossum                
       patch                                                                   

reindent.py strips execute permission on Unix                    1215 days
       http://bugs.python.org/issue1050828 facundobatista            
                                                                               

Source code encoding in IDLE console                             1196 days
       http://bugs.python.org/issue1061803 kbk                       
       patch                                                                   

semaphore errors from Python 2.3.x on AIX 5.2                    1125 days
       http://bugs.python.org/issue1106262 akuchling                 
                                                                               

list comprehension scope                                         1120 days
       http://bugs.python.org/issue1110705 stutzbach                 
                                                                               

subprocess fails on GetStdHandle in interactive GUI              1094 days
       http://bugs.python.org/issue1124861 dserodio                  
                                                                               

Python 2.4 causes BitTorrent 3.4.2 failure                       1066 days
       http://bugs.python.org/issue1167397 akuchling                 
                                                                               

subprocess.Popen inside thread locks the thread in some case (2.  765 days
       http://bugs.python.org/issue1404925 gregory.p.smith           
       patch, easy                                                             



Top Issues Most Discussed (10)
______________________________

 15 Queue.maxsize, __init__() accepts any value as maxsize             1 days
closed  http://bugs.python.org/issue2149   

 13 Factorial                                                          4 days
open    http://bugs.python.org/issue2138   

  8 xml.sax and xml.dom fetch DTDs by default                          7 days
open    http://bugs.python.org/issue2124   

  8 Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.       63 days
open    http://bugs.python.org/issue1682   

  7 os.environ should inherit dict                                     3 days
open    http://bugs.python.org/issue2144   

  7 str.format() produces different output on different platforms (   72 days
open    http://bugs.python.org/issue1600   

  6 TestCase.tmpdir(), TestCase.mock()                                 0 days
closed  http://bugs.python.org/issue2156   

  6 "codecs" module on Windows uses incorrect end-of-line, wiriting    1 days
closed  http://bugs.python.org/issue2131   

  6 xmlrpclib can no longer marshal Fault objects                    248 days
open    http://bugs.python.org/issue1739842

  5 confusing exception when opening a filename with nonprintable c    1 days
open    http://bugs.python.org/issue2158   




From rhamph at gmail.com  Fri Feb 22 18:16:36 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Fri, 22 Feb 2008 10:16:36 -0700
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BEB89C.6080300@gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
Message-ID: <aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>

On Fri, Feb 22, 2008 at 4:57 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>    # Feature request resolutions
>    accepted - feature request accepted (possibly via attached patch)
>    rejected - feature request rejected

Can we make the names a little longer?  "feature accepted" and
"feature rejected" are more obvious than simply "accepted" and
"rejected".  Same for some of the bug ones.


>    # Bug report resolutions
>    fixed - reported bug fixed (possibly via attached patch)
>    invalid - reported behaviour is intentional and not a bug
>    works for me - bug could not be replicated from bug report
>    out of date - bug is already fixed in later Python version
>    wont fix - valid bug, but not fixable in CPython (very rare)
>
>    # Common resolutions
>    duplicate - same as another issue (refer to other issue in a comment)


-- 
Adam Olsen, aka Rhamphoryncus

From guido at python.org  Fri Feb 22 18:19:51 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 22 Feb 2008 09:19:51 -0800
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
References: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net>
	<ca471dc20802220817s51062111r30dff8bd654f9d25@mail.gmail.com>
	<000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
Message-ID: <ca471dc20802220919o3a68d4e4obc864455dec1ad9b@mail.gmail.com>

On Fri, Feb 22, 2008 at 9:06 AM, Raymond Hettinger <python at rcn.com> wrote:
> [GvR]
>
> >. After
>  > all we already have lots of places where Python 2.x supports an old
>  > and a new way (e.g. string exceptions up to 2.5, classic classes, old
>  > and rich comparisons).
>
>  I thought the whole point of 3.0 was a recognition that all that
>  doubling-up was a bad thing and to be rid of it.  Why make the
>  situation worse?  ISTM that we need two versions of oct() like
>  we need a hole in the head.

Raymond, I am getting really sick and tired of your strong language
like this. It feels like a personal attack to me, over and over.

You seem to be the only one advocating 2.6 stay lean and mean (except
of course when *you* want something new). I don't want to go over this
discussion again. I've drawn the line at breaking code that works
under 2.5; you need to be satisfied with that.

> Heck, there's potentially a case to be
>  made that we don't need oct() at all.  IIRC, unix permissions like
>  0666 were the only use case that surfaced.
>
>  Also, I thought that the only reason you allowed b'' to be an alias for ''
>  in 2.6 was that it was the only way 2-to-3 converter would work.
>  That same rationale doesn't seem to apply here. I don't really see
>  why the necessity of b'' should be seen as opening the flood gates
>  to backport everything without regard to whether it makes Py2.6 better.

Again with the colorful language. Nobody is opening floodgates.

Enough said or I start using colorful language myself.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From steve at holdenweb.com  Fri Feb 22 18:22:11 2008
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 22 Feb 2008 12:22:11 -0500
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
References: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net>	<ca471dc20802220817s51062111r30dff8bd654f9d25@mail.gmail.com>
	<000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
Message-ID: <47BF04C3.9090603@holdenweb.com>

Raymond Hettinger wrote:
> [GvR]
>> . After
>> all we already have lots of places where Python 2.x supports an old
>> and a new way (e.g. string exceptions up to 2.5, classic classes, old
>> and rich comparisons).
> 
> I thought the whole point of 3.0 was a recognition that all that 
> doubling-up was a bad thing and to be rid of it.  Why make the
> situation worse?  ISTM that we need two versions of oct() like
> we need a hole in the head.  Heck, there's potentially a case to be
> made that we don't need oct() at all.  IIRC, unix permissions like
> 0666 were the only use case that surfaced.
> 
> Also, I thought that the only reason you allowed b'' to be an alias for ''
> in 2.6 was that it was the only way 2-to-3 converter would work.
> That same rationale doesn't seem to apply here. I don't really see
> why the necessity of b'' should be seen as opening the flood gates
> to backport everything without regard to whether it makes Py2.6 better.
> 
It certainly doesn't seem to have the same urgency for cases where 2to3 
can unambiguously do the right thing.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/

From steve at holdenweb.com  Fri Feb 22 18:22:11 2008
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 22 Feb 2008 12:22:11 -0500
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
References: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net>	<ca471dc20802220817s51062111r30dff8bd654f9d25@mail.gmail.com>
	<000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
Message-ID: <47BF04C3.9090603@holdenweb.com>

Raymond Hettinger wrote:
> [GvR]
>> . After
>> all we already have lots of places where Python 2.x supports an old
>> and a new way (e.g. string exceptions up to 2.5, classic classes, old
>> and rich comparisons).
> 
> I thought the whole point of 3.0 was a recognition that all that 
> doubling-up was a bad thing and to be rid of it.  Why make the
> situation worse?  ISTM that we need two versions of oct() like
> we need a hole in the head.  Heck, there's potentially a case to be
> made that we don't need oct() at all.  IIRC, unix permissions like
> 0666 were the only use case that surfaced.
> 
> Also, I thought that the only reason you allowed b'' to be an alias for ''
> in 2.6 was that it was the only way 2-to-3 converter would work.
> That same rationale doesn't seem to apply here. I don't really see
> why the necessity of b'' should be seen as opening the flood gates
> to backport everything without regard to whether it makes Py2.6 better.
> 
It certainly doesn't seem to have the same urgency for cases where 2to3 
can unambiguously do the right thing.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From dalcinl at gmail.com  Fri Feb 22 18:28:52 2008
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Fri, 22 Feb 2008 14:28:52 -0300
Subject: [Python-Dev] trunk-math
In-Reply-To: <5c6f2a5d0802152043lfc43cc9l8f66e17bab0523a5@mail.gmail.com>
References: <5c6f2a5d0802151953l3fa5ec4blddc4e27f17f6031c@mail.gmail.com>
	<ca471dc20802152032l2b77b6fdnbccdb2f62d74bff3@mail.gmail.com>
	<5c6f2a5d0802152043lfc43cc9l8f66e17bab0523a5@mail.gmail.com>
Message-ID: <e7ba66e40802220928p6a5a06c3kc121233d0f153a1d@mail.gmail.com>

On 2/16/08, Mark Dickinson <dickinsm at gmail.com> wrote:
> * New float methods: is_finite, is_inf, is_integer and is_nan.

Just a question... is_integer or is_integral?


-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

From martin at v.loewis.de  Fri Feb 22 18:47:52 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 22 Feb 2008 18:47:52 +0100
Subject: [Python-Dev] int/float freelists vs pymalloc
In-Reply-To: <000001c872eb$d974a340$022efea9@ESII9100>
References: <000001c872eb$d974a340$022efea9@ESII9100>
Message-ID: <47BF0AC8.1040306@v.loewis.de>

> And, of course, if the int/float freelist scheme was a real issue
> we would have probably heard of it by now in a very sound way.

As Aahz says: people run into this problem frequently, and then report it.

Regards,
Martin

From martin at v.loewis.de  Fri Feb 22 18:53:37 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 22 Feb 2008 18:53:37 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802220334kf7e8f90i9c7d5935f8a06d4a@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>	<47BCBC60.8090808@v.loewis.de>	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>	<47BD9DBC.2030106@holdenweb.com>	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>	<e04bdf310802210806q60ab9165rb4c552d1215e47a4@mail.gmail.com>	<47BDD748.3000407@v.loewis.de>
	<e04bdf310802220334kf7e8f90i9c7d5935f8a06d4a@mail.gmail.com>
Message-ID: <47BF0C21.10907@v.loewis.de>

> We can go one step further: If we change "fixed" and "accepted" as
> "resolved" (for example), we can change all the values directly in the
> database, so they all appear as "resolved" now.
> 
> I don't want to propose anything specific regarding words, I'm just
> saying that having eleven options to close an issue are too many if we
> want to keep consistency.

I'd like to point out that there is only one way to close an issue:
set it to "closed" state.

What you (and everybody else) here is talking about the resolution
(i.e. an indication how the issue was resolved). If you propose that 
there is only one possible resolution, namely "resolved", then
wouldn't it be best to remove the resolution entirely?

> Note that they're not clear enough to make them obvious, otherwise the
> consensus in this thread would have been faster, ;)

Right. I wish this discussion had taken place before the tracker
switchover.

Regards,
Martin

From fumanchu at aminus.org  Fri Feb 22 18:45:58 2008
From: fumanchu at aminus.org (Robert Brewer)
Date: Fri, 22 Feb 2008 09:45:58 -0800
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
References: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net><ca471dc20802220817s51062111r30dff8bd654f9d25@mail.gmail.com>
	<000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
Message-ID: <F1962646D3B64642B7C9A06068EE1E6402401426@ex10.hostedexchange.local>

Raymond Hettinger wrote:
> I thought the whole point of 3.0 was a recognition that all that
> doubling-up was a bad thing and to be rid of it.  Why make the
> situation worse?  ISTM that we need two versions of oct() like
> we need a hole in the head.  Heck, there's potentially a case to be
> made that we don't need oct() at all.  IIRC, unix permissions like
> 0666 were the only use case that surfaced.

Postgres bytea coercion is a frequent use case for oct() in my world.
But I agree we don't need two versions.


Robert Brewer
fumanchu at aminus.org


From martin at v.loewis.de  Fri Feb 22 19:01:43 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 22 Feb 2008 19:01:43 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>	<47BCBC60.8090808@v.loewis.de>	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>	<47BD9DBC.2030106@holdenweb.com>	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>	<47BEA5C3.6050006@gmail.com>	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
Message-ID: <47BF0E07.1070809@v.loewis.de>

> Can we make the names a little longer?

Somebody really needs to take lead here. I won't change
anything unless somebody tells me precisely what to do,
so I can blame somebody. Messages like this (which I
picked just arbitrarily) I will ignore wrt. specific
action. Of course I *can* make the names a little
longer - it's a thirty-second edit. The question is
whether I should.

Again, taking your message just arbitrarily. The same
remark applies to anything else declared as a proposal -
I can only act on specifications, not on proposals.

Regards,
Martin

From martin at v.loewis.de  Fri Feb 22 18:56:15 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 22 Feb 2008 18:56:15 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>	<47BA8C97.1000300@v.loewis.de>	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>	<47BCBC60.8090808@v.loewis.de>	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>	<47BD9DBC.2030106@holdenweb.com>	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
Message-ID: <47BF0CBF.9000704@v.loewis.de>

> First two definitions of "resolve" from the American Heritage dict:
> 
>   1. To make a firm decision about.
>   2. To cause (a person) to reach a decision.
> 
> I think it applies quite well.

That's why the entire field is called "Resolution". "duplicate",
"invalid", "out of date", "wont fix" and "works for me" are also
firm decisions.

("later", "postponed", and "remind" might not be firm decisions -
they were just inherited from SF).

Regards,
Martin


From skip at pobox.com  Fri Feb 22 19:25:52 2008
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 22 Feb 2008 12:25:52 -0600
Subject: [Python-Dev] boilerplate.tex
In-Reply-To: <20080222182003.GA28173@python.psfb.org>
References: <20080222182003.GA28173@python.psfb.org>
Message-ID: <18367.5040.232357.35633@montanaro-dyndns-org.local>

This message has been popping up in the buildbot mails for several days:

    > Conflict detected in commontex/boilerplate.tex.  Doc build skipped.

I have no idea what it means.  I don't see it within the core distribution.
Can someone take a look at this?

Skip

From eric+python-dev at trueblade.com  Fri Feb 22 19:14:51 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Fri, 22 Feb 2008 13:14:51 -0500
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <F1962646D3B64642B7C9A06068EE1E6402401426@ex10.hostedexchange.local>
References: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net><ca471dc20802220817s51062111r30dff8bd654f9d25@mail.gmail.com>	<000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
	<F1962646D3B64642B7C9A06068EE1E6402401426@ex10.hostedexchange.local>
Message-ID: <47BF111B.6030802@trueblade.com>

Robert Brewer wrote:
> Raymond Hettinger wrote:
>> I thought the whole point of 3.0 was a recognition that all that
>> doubling-up was a bad thing and to be rid of it.  Why make the
>> situation worse?  ISTM that we need two versions of oct() like
>> we need a hole in the head.  Heck, there's potentially a case to be
>> made that we don't need oct() at all.  IIRC, unix permissions like
>> 0666 were the only use case that surfaced.
> 
> Postgres bytea coercion is a frequent use case for oct() in my world.
> But I agree we don't need two versions.

Unless you're trying to write code to work with both 2.6 and 3.0.

From g.brandl at gmx.net  Fri Feb 22 20:15:05 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 22 Feb 2008 20:15:05 +0100
Subject: [Python-Dev] boilerplate.tex
In-Reply-To: <18367.5040.232357.35633@montanaro-dyndns-org.local>
References: <20080222182003.GA28173@python.psfb.org>
	<18367.5040.232357.35633@montanaro-dyndns-org.local>
Message-ID: <fpn6vk$1ec$1@ger.gmane.org>

skip at pobox.com schrieb:
> This message has been popping up in the buildbot mails for several days:
> 
>     > Conflict detected in commontex/boilerplate.tex.  Doc build skipped.
> 
> I have no idea what it means.  I don't see it within the core distribution.
> Can someone take a look at this?

Neal will have to fix it locally in his checkout. The message is generated by
his automatic doc building script.

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 eric+python-dev at trueblade.com  Fri Feb 22 20:30:30 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Fri, 22 Feb 2008 14:30:30 -0500
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>
References: <47BDFA81.8000805@trueblade.com>
	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>
Message-ID: <47BF22D6.9030600@trueblade.com>

Guido van Rossum wrote:
> I wonder if, in order to change the behavior of various built-in
> functions, it wouldn't be easier to be able to write
> 
> from future_builtins import oct, hex  # and who knows what else

This makes sense to me, especially if we have a 2to3 fixer which removes 
this line.  I'll work on implementing future_builtins.


From gnewsg at gmail.com  Fri Feb 22 20:57:56 2008
From: gnewsg at gmail.com (Giampaolo Rodola')
Date: Fri, 22 Feb 2008 11:57:56 -0800 (PST)
Subject: [Python-Dev] ssl - how to switch back to a plain text socket?
In-Reply-To: <85fb7594-4e9c-487d-849e-12b6c247bfac@p43g2000hsc.googlegroups.com>
References: <1b443341-46a7-4741-858f-b4e99ab2cc9d@72g2000hsu.googlegroups.com>
	<08Feb19.084213pst."58696"@synergy1.parc.xerox.com>
	<47BB5F12.4040706@v.loewis.de> 
	<08Feb19.175434pst."58696"@synergy1.parc.xerox.com>
	<47BBA540.8020105@v.loewis.de> 
	<08Feb19.210901pst."58696"@synergy1.parc.xerox.com>
	<b9873c80-7b84-4070-b0f1-4a3c707aeb57@q33g2000hsh.googlegroups.com>
	<08Feb20.083947pst."58696"@synergy1.parc.xerox.com>
	<85fb7594-4e9c-487d-849e-12b6c247bfac@p43g2000hsc.googlegroups.com>
Message-ID: <1dec9d27-2bc4-4aa3-8a7d-e97ccaea57af@e60g2000hsh.googlegroups.com>

I provided a patch for adding TLS support to ftplib: http://bugs.python.org/issue2054
Bill, could you please take a look at it?

From greg.ewing at canterbury.ac.nz  Fri Feb 22 21:04:05 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 23 Feb 2008 09:04:05 +1300
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
References: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net>
	<ca471dc20802220817s51062111r30dff8bd654f9d25@mail.gmail.com>
	<000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
Message-ID: <47BF2AB5.3070104@canterbury.ac.nz>

Raymond Hettinger wrote:
> ISTM that we need two versions of oct() like
> we need a hole in the head.

I don't know about oct(), but I found hex() to be quite useful
the other day when I was using the interactive interpreter to
to some hex calculations. It would have been quite tedious
having to say "%x".format(_) or some such all the time to
see the results in hex.

An alternative might be to have some variable that can be
set to control the format of numbers printed by the interactive
shell.

--
Greg

From janssen at parc.com  Fri Feb 22 21:28:49 2008
From: janssen at parc.com (Bill Janssen)
Date: Fri, 22 Feb 2008 12:28:49 PST
Subject: [Python-Dev] ssl - how to switch back to a plain text socket?
In-Reply-To: <1dec9d27-2bc4-4aa3-8a7d-e97ccaea57af@e60g2000hsh.googlegroups.com>
References: <1b443341-46a7-4741-858f-b4e99ab2cc9d@72g2000hsu.googlegroups.com>
	<08Feb19.084213pst."58696"@synergy1.parc.xerox.com>
	<47BB5F12.4040706@v.loewis.de>
	<08Feb19.175434pst."58696"@synergy1.parc.xerox.com>
	<47BBA540.8020105@v.loewis.de>
	<08Feb19.210901pst."58696"@synergy1.parc.xerox.com>
	<b9873c80-7b84-4070-b0f1-4a3c707aeb57@q33g2000hsh.googlegroups.com>
	<08Feb20.083947pst."58696"@synergy1.parc.xerox.com>
	<85fb7594-4e9c-487d-849e-12b6c247bfac@p43g2000hsc.googlegroups.com>
	<1dec9d27-2bc4-4aa3-8a7d-e97ccaea57af@e60g2000hsh.googlegroups.com>
Message-ID: <08Feb22.122855pst."58696"@synergy1.parc.xerox.com>

It's on my list.

Bill

From Martin.vonLoewis at hpi.uni-potsdam.de  Fri Feb 22 21:17:16 2008
From: Martin.vonLoewis at hpi.uni-potsdam.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 22 Feb 2008 21:17:16 +0100
Subject: [Python-Dev] [ANN] Python 2.5.2 released
Message-ID: <47BF2DCC.4040400@hpi.uni-potsdam.de>

On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.5.2 (FINAL).

This is the second bugfix release of Python 2.5. Python 2.5 is now in
bugfix-only mode; no new features are being added. According to the
release notes, over 100 bugs and patches have been addressed since
Python 2.5.1, many of them improving the stability of the interpreter,
and improving its portability.

This is a production release of Python, and should be a painless
upgrade from 2.5.1 or 2.5. Since the release candidate, we have backed
out test cases that were incorrect on 64-bit systems, and fixed
another stability problem. See the release notes for more.

For more information on Python 2.5.2, including download links for
various platforms, release notes, and known issues, please see:

   http://www.python.org/2.5.2/

Highlights of this new release include:

   Bug fixes. According to the release notes, at least 100 have been fixed.

Highlights of the previous major Python release (2.5) are available
from the Python 2.5 page, at

   http://www.python.org/2.5/highlights.html

Enjoy this release,
Martin

Martin v. Loewis
martin at v.loewis.de
Python Release Manager
(on behalf of the entire python-dev team)

From martin at v.loewis.de  Fri Feb 22 22:00:46 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 22 Feb 2008 22:00:46 +0100
Subject: [Python-Dev] [ANN] Python 2.5.2 released
In-Reply-To: <47BF2DCC.4040400@hpi.uni-potsdam.de>
References: <47BF2DCC.4040400@hpi.uni-potsdam.de>
Message-ID: <47BF37FE.2000407@v.loewis.de>

> On behalf of the Python development team and the Python community, I'm
> happy to announce the release of Python 2.5.2 (FINAL).

As a bug day is upcoming, I'm now thawing the 2.5 branch.

2.5.3 should be released in ca. 6 month, or shortly after
2.6 final (whatever happens earlier); if it follows 2.6,
it would be the last bugfix release for 2.5 (with security
releases still possible).

I'm still working on source-only releases of 2.4 and 2.3.

Regards,
Martin


From fumanchu at aminus.org  Fri Feb 22 22:04:31 2008
From: fumanchu at aminus.org (Robert Brewer)
Date: Fri, 22 Feb 2008 13:04:31 -0800
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <47BF111B.6030802@trueblade.com>
References: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net><ca471dc20802220817s51062111r30dff8bd654f9d25@mail.gmail.com>	<000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
	<F1962646D3B64642B7C9A06068EE1E6402401426@ex10.hostedexchange.local>
	<47BF111B.6030802@trueblade.com>
Message-ID: <F1962646D3B64642B7C9A06068EE1E6402401660@ex10.hostedexchange.local>

Eric Smith wrote:
> Robert Brewer wrote:
> > Raymond Hettinger wrote:
> >> I thought the whole point of 3.0 was a recognition that all that
> >> doubling-up was a bad thing and to be rid of it.  Why make the
> >> situation worse?  ISTM that we need two versions of oct() like
> >> we need a hole in the head.  Heck, there's potentially a case to be
> >> made that we don't need oct() at all.  IIRC, unix permissions like
> >> 0666 were the only use case that surfaced.
> >
> > Postgres bytea coercion is a frequent use case for oct() in my
world.
> > But I agree we don't need two versions.
> 
> Unless you're trying to write code to work with both 2.6 and 3.0.

Who would try that when PEP 3000 says (in bold type no less):

    There is no requirement that Python 2.6 code will run unmodified
    on Python 3.0. Not even a subset.

? And why should python-dev support such people?


Robert Brewer
fumanchu at aminus.org


From brett at python.org  Fri Feb 22 22:06:05 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 13:06:05 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BF0E07.1070809@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
	<47BF0E07.1070809@v.loewis.de>
Message-ID: <bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>

On Fri, Feb 22, 2008 at 10:01 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > Can we make the names a little longer?
>
>  Somebody really needs to take lead here. I won't change
>  anything unless somebody tells me precisely what to do,
>  so I can blame somebody. Messages like this (which I
>  picked just arbitrarily) I will ignore wrt. specific
>  action. Of course I *can* make the names a little
>  longer - it's a thirty-second edit. The question is
>  whether I should.
>
>  Again, taking your message just arbitrarily. The same
>  remark applies to anything else declared as a proposal -
>  I can only act on specifications, not on proposals.

I think Martin is right that someone needs to take the lead and do a
complete review of how issues are handled. That way we can do a change
in one big batch to something that works better for Python.

I have always planned to take the lead on this, but it will have to
wait until probably Python 3.0 is out the door. If someone else wants
to go through and really look at how we handle issues and propose a
new schema that's fine by me.

-Brett

From bh at intevation.de  Fri Feb 22 21:42:01 2008
From: bh at intevation.de (Bernhard Herzog)
Date: Fri, 22 Feb 2008 21:42:01 +0100
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <47BF2AB5.3070104@canterbury.ac.nz> (Greg Ewing's message of
	"Sat, 23 Feb 2008 09:04:05 +1300")
References: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net>
	<ca471dc20802220817s51062111r30dff8bd654f9d25@mail.gmail.com>
	<000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
	<47BF2AB5.3070104@canterbury.ac.nz>
Message-ID: <s9zir0glo4m.fsf@thoe.hq.intevation.de>

Greg Ewing <greg.ewing at canterbury.ac.nz> writes:

> I don't know about oct(), but I found hex() to be quite useful
> the other day when I was using the interactive interpreter to
> to some hex calculations. It would have been quite tedious
> having to say "%x".format(_) or some such all the time to
> see the results in hex.
>
> An alternative might be to have some variable that can be
> set to control the format of numbers printed by the interactive
> shell.

Something like this?

>>> import sys
>>> import __builtin__
>>> def myhook(o):
...     if isinstance(o, int):
...             print hex(o)
...     else:
...             print repr(o)
...     __builtin__._ = o
...
>>> sys.displayhook = myhook
>>> 123
0x7b


   Bernhard

From facundobatista at gmail.com  Fri Feb 22 22:21:15 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 22 Feb 2008 19:21:15 -0200
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
	<47BF0E07.1070809@v.loewis.de>
	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
Message-ID: <e04bdf310802221321u1bc0f34br78a170afbe096785@mail.gmail.com>

2008/2/22, Brett Cannon <brett at python.org>:

> I think Martin is right that someone needs to take the lead and do a
>  complete review of how issues are handled. That way we can do a change
>  in one big batch to something that works better for Python.

+1

What about a couple of hours in the Python Core sprinting in a month?
I won't be there (in that specific sprint), but I trust your decision.

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From amk at amk.ca  Fri Feb 22 22:28:42 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Fri, 22 Feb 2008 16:28:42 -0500
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
References: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
	<47BF0E07.1070809@v.loewis.de>
	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
Message-ID: <20080222212842.GA13545@amk-desktop.matrixgroup.net>

On Fri, Feb 22, 2008 at 01:06:05PM -0800, Brett Cannon wrote:
> I think Martin is right that someone needs to take the lead and do a
> complete review of how issues are handled. That way we can do a change
> in one big batch to something that works better for Python.

Are we, as a development community, really running into problems with
how we handle bugs?  There are certainly small cleanups possible, such
as dropping the 'postponed' and 'later' resolutions that we don't seem
to use very much, but the flow seems reasonably efficient to me.

I suggest just updating PEP 3 to actually describe the life cycle we
currently follow.

--amk

From brett at python.org  Fri Feb 22 22:29:29 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 13:29:29 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802221321u1bc0f34br78a170afbe096785@mail.gmail.com>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
	<47BF0E07.1070809@v.loewis.de>
	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
	<e04bdf310802221321u1bc0f34br78a170afbe096785@mail.gmail.com>
Message-ID: <bbaeab100802221329r5801d015pb1a5fa57c6baf47f@mail.gmail.com>

On Fri, Feb 22, 2008 at 1:21 PM, Facundo Batista
<facundobatista at gmail.com> wrote:
> 2008/2/22, Brett Cannon <brett at python.org>:
>
>
>  > I think Martin is right that someone needs to take the lead and do a
>  >  complete review of how issues are handled. That way we can do a change
>  >  in one big batch to something that works better for Python.
>
>  +1
>
>  What about a couple of hours in the Python Core sprinting in a month?
>  I won't be there (in that specific sprint), but I trust your decision.

Maybe. Could possibly take an hour or so after a lunch and just have
everyone at the sprint give feedback or something.

But my personal priorities for the sprint is being a good sprint coach
first, and finish getting my bootstrap of my import rewrite second.

-Brett

From jdennis at redhat.com  Fri Feb 22 22:23:58 2008
From: jdennis at redhat.com (John Dennis)
Date: Fri, 22 Feb 2008 16:23:58 -0500
Subject: [Python-Dev] Unicode <--> UTF-8 in CPython extension modules
Message-ID: <47BF3D6E.2070301@redhat.com>

I've uncovered what seems to me to a problem with python Unicode
string objects passed to extension modules. Or perhaps it's revealing
a misunderstanding on my part :-) So I would like to get some
clarification.

Extension modules written in C receive strings from python via the
PyArg_ParseTuple family. Most extension modules use the 's' or 's#'
format parameter.

Many C libraries in Linux use the UTF-8 encoding.

The 's' format when passed a Unicode object will encode the string
according to the default encoding which is immutably set to 'ascii' in
site.py. Thus a C library expecting UTF-8 which uses the 's' format in
PyArg_ParseTuple will get an encoding error when passed a Unicode
string which contains any code points outside the ascii range.

Now my questions:

* Is the use of the 's' or 's*' format parameter in an extension
   binding expecting UTF-8 fundamentally broken and not expected to
   work?  Instead should the binding be using a format conversion which
   specifies the desired encoding, e.g. 'es' or 'es#'?

* The extension modules could successfully use the 's' or 's#' format
   conversion in a UTF-8 environment if the default encoding was
   UTF-8. Changing the default encoding to UTF-8 would in one easy
   stroke "fix" most extension modules, right? Why is the default
   encoding 'ascii' in UTF-8 environments and why is the default
   encoding prohibited from being changed from ascii?

* Did Python 2.5 introduce anything which now makes this issue visible
   whereas before it was masked by some other behavior?

Summary:

Python programs which use Unicode string objects for their i18n and
which "link" to C libraries expecting UTF-8 but which have a CPython
binding which only uses 's' or 's#' formats programs seem to often
fail with encoding errors. However, I have yet to see a CPython
binding which does explicitly define it's encoding requirements. This
suggests to me I either do not understand the issue in it's entirety
or many CPython bindings in Linux UTF-8 environments are broken with
respect to their i18n handling and the problem is currently
not addressed.

-- 
John Dennis <jdennis at redhat.com>

From brett at python.org  Fri Feb 22 22:34:00 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 13:34:00 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <20080222212842.GA13545@amk-desktop.matrixgroup.net>
References: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
	<47BF0E07.1070809@v.loewis.de>
	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
	<20080222212842.GA13545@amk-desktop.matrixgroup.net>
Message-ID: <bbaeab100802221334t6f241b33oc66709ec97de69f3@mail.gmail.com>

On Fri, Feb 22, 2008 at 1:28 PM, A.M. Kuchling <amk at amk.ca> wrote:
> On Fri, Feb 22, 2008 at 01:06:05PM -0800, Brett Cannon wrote:
>  > I think Martin is right that someone needs to take the lead and do a
>  > complete review of how issues are handled. That way we can do a change
>  > in one big batch to something that works better for Python.
>
>  Are we, as a development community, really running into problems with
>  how we handle bugs?  There are certainly small cleanups possible, such
>  as dropping the 'postponed' and 'later' resolutions that we don't seem
>  to use very much, but the flow seems reasonably efficient to me.
>

It's reasonable, but I wonder if it could be better. I am not sure as
I have not had that much time to sit down and really think it through.
I do know, though, that I like how Django has it structured:
http://www.djangoproject.com/documentation/contributing/#ticket-triage
.

-Brett

From eric+python-dev at trueblade.com  Fri Feb 22 22:42:32 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Fri, 22 Feb 2008 16:42:32 -0500
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <F1962646D3B64642B7C9A06068EE1E6402401660@ex10.hostedexchange.local>
References: <20080221215406.AHJ52307@ms19.lnh.mail.rcn.net><ca471dc20802220817s51062111r30dff8bd654f9d25@mail.gmail.com>	<000d01c87575$4807bff0$6800a8c0@RaymondLaptop1>
	<F1962646D3B64642B7C9A06068EE1E6402401426@ex10.hostedexchange.local>
	<47BF111B.6030802@trueblade.com>
	<F1962646D3B64642B7C9A06068EE1E6402401660@ex10.hostedexchange.local>
Message-ID: <47BF41C8.3020305@trueblade.com>

Robert Brewer wrote:
> Eric Smith wrote:
>> Robert Brewer wrote:
>>> Postgres bytea coercion is a frequent use case for oct() in my
> world.
>>> But I agree we don't need two versions.
>> Unless you're trying to write code to work with both 2.6 and 3.0.
> 
> Who would try that when PEP 3000 says (in bold type no less):
> 
>     There is no requirement that Python 2.6 code will run unmodified
>     on Python 3.0. Not even a subset.
> 
> ?

Yes, but it also describes the "recommended development model for a 
project that needs to support Python 2.6 and 3.0 simultaneously".  That 
is to run 2to3 on 2.6 code (which is -3 clean), and not edit the 
resulting code.  I'm trying to enable that for code which wants to use 
some (small) 3.0 features.  I don't see the harm in that.

I think this means that the existing oct and hex builtins should raise a 
-3 warning.  The future_builtins version would not raise a warning.

Eric.

From stephen at xemacs.org  Sat Feb 23 00:03:34 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 23 Feb 2008 08:03:34 +0900
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BF0CBF.9000704@v.loewis.de>
References: <e04bdf310802180322g412a6309la776603307e9df75@mail.gmail.com>
	<47BA8C97.1000300@v.loewis.de>
	<2a70578d0802190142t1798ffd1w2e8d8ff77f452631@mail.gmail.com>
	<2a70578d0802190144w31ceab9yc97d430f9e2c1c95@mail.gmail.com>
	<47BCBC60.8090808@v.loewis.de>
	<2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>
	<47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BF0CBF.9000704@v.loewis.de>
Message-ID: <87pruoh9vd.fsf@uwakimon.sk.tsukuba.ac.jp>

"Martin v. L?wis" writes:

 > That's why the entire field is called "Resolution". "duplicate",
 > "invalid", "out of date", "wont fix" and "works for me" are also
 > firm decisions.
 > 
 > ("later", "postponed", and "remind" might not be firm decisions -
 > they were just inherited from SF).

These latter three are not resolutions, and IMO should be removed.
Items with those "resolutions" should be considered still active (or
perhaps "pending" auto-closure).

Specifically, the "name" field of the corresponding items in the
relevant class should be edited so that in legacy issues containing
them they are displayed as "- not yet resolved -" or "- no selection -".
(I'm not sure it's wise, or even possible, for multiple items to have
identical names, though.  If not, they can be uniquified in some way.)

Then these items should be retired so that they won't appear at all in
menus.

From nnorwitz at gmail.com  Sat Feb 23 00:07:35 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Fri, 22 Feb 2008 15:07:35 -0800
Subject: [Python-Dev] boilerplate.tex
In-Reply-To: <fpn6vk$1ec$1@ger.gmane.org>
References: <20080222182003.GA28173@python.psfb.org>
	<18367.5040.232357.35633@montanaro-dyndns-org.local>
	<fpn6vk$1ec$1@ger.gmane.org>
Message-ID: <ee2a432c0802221507o59fe7971j2e2cf286fc445a05@mail.gmail.com>

On Fri, Feb 22, 2008 at 11:15 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> skip at pobox.com schrieb:
>
> > This message has been popping up in the buildbot mails for several days:
>  >
>  >     > Conflict detected in commontex/boilerplate.tex.  Doc build skipped.
>  >
>  > I have no idea what it means.  I don't see it within the core distribution.
>  > Can someone take a look at this?
>
>  Neal will have to fix it locally in his checkout. The message is generated by
>  his automatic doc building script.

Yeah, I fixed it.  I have an outstanding change that is set to today
so the docs show the correct date.  But when I release is made, a
conflict arises, so I have to fix manually each time the file is
modified.

n

From martin at v.loewis.de  Sat Feb 23 00:26:07 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 23 Feb 2008 00:26:07 +0100
Subject: [Python-Dev] Unicode <--> UTF-8 in CPython extension modules
In-Reply-To: <47BF3D6E.2070301@redhat.com>
References: <47BF3D6E.2070301@redhat.com>
Message-ID: <47BF5A0F.7070302@v.loewis.de>

> I've uncovered what seems to me to a problem with python Unicode
> string objects passed to extension modules. Or perhaps it's revealing
> a misunderstanding on my part :-) So I would like to get some
> clarification.

It seems to me that there is indeed one or more misunderstandings
on your part. Please discuss them on comp.lang.python.

> Extension modules written in C receive strings from python via the
> PyArg_ParseTuple family. Most extension modules use the 's' or 's#'
> format parameter.
> 
> Many C libraries in Linux use the UTF-8 encoding.
> 
> The 's' format when passed a Unicode object will encode the string
> according to the default encoding which is immutably set to 'ascii' in
> site.py. Thus a C library expecting UTF-8 which uses the 's' format in
> PyArg_ParseTuple will get an encoding error when passed a Unicode
> string which contains any code points outside the ascii range.

The C library isn't expecting  using the 's' format. A Python module
wrapping the C library is. So whatever conversion is necessary should
be done by that Python module.

> Now my questions:
> 
> * Is the use of the 's' or 's*' format parameter in an extension
>    binding expecting UTF-8 fundamentally broken and not expected to
>    work?  Instead should the binding be using a format conversion which
>    specifies the desired encoding, e.g. 'es' or 'es#'?

Yes. Alternatively, require the callers to pass UTF-8 byte strings,
not Unicode strings.

> * The extension modules could successfully use the 's' or 's#' format
>    conversion in a UTF-8 environment if the default encoding was
>    UTF-8. Changing the default encoding to UTF-8 would in one easy
>    stroke "fix" most extension modules, right?

Wrong. This assumes that "most" libraries do indeed specify their
APIs in terms of UTF-8. I don't think that is a fact; not in the world
of 2008.

> Why is the default
>    encoding 'ascii' in UTF-8 environments and why is the default
>    encoding prohibited from being changed from ascii?

There are several reasons, all off-topic for python-dev.
ASCII was considered the most safe assumption: when
converting between byte and Unicode strings in the absence of an
encoding specification, you can't assume anything but ASCII
(technically, not even that, as the bytes may be EBCDIC, but ASCII
is safe for the majority of the systems - unlike UTF-8).
The encoding can't be changed because that would break hash().

> * Did Python 2.5 introduce anything which now makes this issue visible
>    whereas before it was masked by some other behavior?

I don't know. Can you please be a bit more specific (on 
comp.lang.python) where you suspect such a change?

Regards,
Martin

From barry at python.org  Sat Feb 23 00:45:23 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 22 Feb 2008 18:45:23 -0500
Subject: [Python-Dev] Python 2.6 and 3.0
Message-ID: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

I've volunteered to be the release manager for Python 2.6 and 3.0.   
It's been several years since I've RM'd a Python release, and I'm  
happy to do it again (he says while the medication is still  
working :).  I would like to get the next alpha releases of both  
versions out before Pycon, so I propose next Friday, February 29 for  
both.

Guido reminded me that we released Python 1.6 and 2.0 together and it  
makes sense to both of us to do the same for Python 2.6 and 3.0.  I  
don't think it will be that much more work (for me at least :) to  
release them in lockstep, so I think we should try it.  I won't try to  
sync their pre-release version numbers except at the milestones (e.g.  
first beta, release candidates, final releases).

I propose to change PEP 361 to outline the release schedule for both  
Python 2.6 and 3.0.  I'm hoping we can work out a more definite  
schedule at Pycon, but for now I want to at least describe the  
lockstep release schedule and the Feb 29 date.

I'd also like for us to consider doing regular monthly releases.   
Several other FLOSS projects I'm involved with are doing this to very  
good success.  The nice thing is that everyone knows well in advance  
when the next release is going to happen, and so all developers and  
users know what to expect and what is needed from them.

I'd like to propose that we do a joint release the last Friday of  
every month.  For the alphas, it's basically what's in svn.  This  
gives us some time to experiment with the process out and see if we  
like it enough to keep it going through the betas and final releases.

Comments?
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR79ek3EjvBPtnXfVAQJrmQP+KAzy0lSzake2BZsVxErD0kpFQJM+Iij0
qN86wjH0NoqARMfYKVA6eUzEY8vZPu7sJl+SjCOmhnE/KP+l/ArOdis5smiSKwQI
klL4XKd/qdorTMqQ9mWgA0DeBb0Asvln9y64nxzNqgve+36q9j6ytPuRey1GjSI5
nVWoJDb3WsM=
=4SRa
-----END PGP SIGNATURE-----

From walters at verbum.org  Sat Feb 23 00:46:38 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 22 Feb 2008 18:46:38 -0500
Subject: [Python-Dev] Unicode <--> UTF-8 in CPython extension modules
In-Reply-To: <47BF3D6E.2070301@redhat.com>
References: <47BF3D6E.2070301@redhat.com>
Message-ID: <faa16b610802221546s75412576pa6db50cd5235f4f4@mail.gmail.com>

On Fri, Feb 22, 2008 at 4:23 PM, John Dennis <jdennis at redhat.com> wrote:

>  Python programs which use Unicode string objects for their i18n and
>  which "link" to C libraries expecting UTF-8 but which have a CPython
>  binding which only uses 's' or 's#' formats programs seem to often
>  fail with encoding errors.

One thing to be aware of is that PyGTK+ actually sets the Python
Unicode object encoding to UTF-8.

http://bugzilla.gnome.org/show_bug.cgi?id=132040

I mention this because PyGTK is a very popular library related to
Python and Linux.  So currently if you "import gtk", then libraries
which are using UTF-8 (as you say, the vast majority) will work with
Python unicode objects unmodified.

From barry at python.org  Sat Feb 23 00:47:19 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 22 Feb 2008 18:47:19 -0500
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <ca471dc20802220828s326fd695g9a8d8bff4bb78500@mail.gmail.com>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
	<bbaeab100802211317t7d0b2371ld8e70fc615d49868@mail.gmail.com>
	<60bb7ceb0802211655y2ea30938y7a64bda9c55ac4e4@mail.gmail.com>
	<e27efe130802220001ua07c105lec3daafd61689a05@mail.gmail.com>
	<18366.62560.100720.755828@montanaro-dyndns-org.local>
	<20080222162026.GB7354@panix.com>
	<ca471dc20802220828s326fd695g9a8d8bff4bb78500@mail.gmail.com>
Message-ID: <BECDF9A6-960B-4ADD-8DAD-2002D105143B@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 22, 2008, at 11:28 AM, Guido van Rossum wrote:

> On Fri, Feb 22, 2008 at 8:20 AM, Aahz <aahz at pythoncraft.com> wrote:
>> On Fri, Feb 22, 2008, skip at pobox.com wrote:
>>>
>>>
>>>>> Why not just skip the specifics except to say < 80 characters  
>>>>> for all
>>>>> lines?  Don't mention 72, 79 or any other number than 80:
>>>
>>>    Amaury> I often run "svn diff" in a console limited to 80  
>>> characters.
>>>    Amaury> Because of the leading "+", lines longer than 78 wrap,  
>>> and the
>>>    Amaury> output is more difficult to read.
>>>
>>> There will always be certain cases which present probems.  I use  
>>> "svn
>>> annotate" from time-to-time which adds an even wider margin to the  
>>> left.
>>> In those situations I either grin and bear it or stretch my window  
>>> enough to
>>> view it without wrapping.
>>
>> Yes, but svn/cvs diff is a particularly common use case.  I agree  
>> with
>> Amaury.
>
> -1. There's just no way that 78 is enforceable. At Google, sticking to
> 80 is a continuous battle, and we use 2-space indents!

At my last job, I had a hard enough time getting people to stick with / 
any/ limit!  I even saw lines > 120 characters!  Fortunately, we made  
a workable compromise; the C code could be whatever and the Python  
code had to be PEP 8. :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR79fB3EjvBPtnXfVAQLBNAP7BD1FG5bOjkP0iys2r6f6nK98D9XZhK3J
Qm+Cjm6tmnqEv92R9rEVYOIH0KE21oGhJFliOccYZzuE0WFPk9T6KXrRIAmggBrf
ZtAwcj//0dfkq/7XGWwKgx9B7BoCymyyKGo16svj/jGeBQM6dLSoKUP+Fbw6zJEF
n04bAwAqFp0=
=3kW3
-----END PGP SIGNATURE-----

From barry at python.org  Sat Feb 23 00:49:09 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 22 Feb 2008 18:49:09 -0500
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <47BDB5F1.2000901@ronadam.com>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
	<47BDB5F1.2000901@ronadam.com>
Message-ID: <2E45E94F-2248-4C5C-B3E9-2E7363EB19B8@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 21, 2008, at 12:33 PM, Ron Adam wrote:

> Barry Warsaw wrote:
>
>> Why should docstrings and comments be limited to 72 characters when
>> code is limited to 79 characters?  I ask because there is an ongoing
>> debate at my company about this.
>
> I'm not sure if this is the main reason, but when using pydoc to view
> docstrings, the 72 character width allows for the added indent in  
> class and
> method sections.

Interesting.  Maybe because I almost always put doctests in separate  
files, I don't run into this too much.  Having an indent of 4 for  
doctest code never really bothers me too much.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR79fdnEjvBPtnXfVAQKL0gP8DiLPO6bQEIwvcg9M7ke9Dl8QYMf3+KSV
TY7o20ogh54mnm66YElJ3HFU1iomOx6CsP0gNJ2mioKCJj3iBAdGKmPb0KhJKiDa
bLZc0y2Pmzw//ePspkIGZrEjDm8vps5A/iRGF58tnMdYg6f/OzfJPAmGNo6rzOl8
pI27IxE4XX4=
=Xe/I
-----END PGP SIGNATURE-----

From barry at python.org  Sat Feb 23 00:53:48 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 22 Feb 2008 18:53:48 -0500
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <ca471dc20802210930q654b4791p3c0588d374603e6@mail.gmail.com>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
	<ca471dc20802210930q654b4791p3c0588d374603e6@mail.gmail.com>
Message-ID: <CFD6B26D-928C-448B-A8B5-6C8393693397@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 21, 2008, at 12:30 PM, Guido van Rossum wrote:

> On Thu, Feb 21, 2008 at 9:15 AM, Barry Warsaw <barry at python.org>  
> wrote:
>> Why should docstrings and comments be limited to 72 characters when
>> code is limited to 79 characters?  I ask because there is an ongoing
>> debate at my company about this.
>
> People in your company have too much time on their hands. :-)

C'mon, bike shedding is so much fun! :)

>> Personally, I see no justification for it, and further, it's a pita  
>> to
>> support automatically because tools like Emacs only have one auto-
>> wrapping variable (fill-column).  Emacs doesn't know that it should
>> fill comments and docstrings different than code lines, so you have  
>> to
>> do a bunch of manual crud to support these guidelines.
>>
>> I recommend removing the guideline of 72 characters, and just say
>> everything, code, comments, and docstrings should be no wider than 79
>> characters.
>
> I'm fine with getting rid of this, but since that originally comes
> from me, here's my justification. Somehow my Emacs usually defaults to
> 72 for its fill column. That means that when I reflow text in a block
> comment or docstring, it'll use this limit. OTOH I don't use anything
> to automatically fold long code lines: when they start wrapping I
> manually decide on the best place to break it (and my windows are
> typically 80 chars wide so I can have several side by side(*)).

I do the same thing sometimes too.

> However there are occasions where I manually format docstrings or
> comments, and then I will again use 79 as the limit.

Yep.

> (*) When is Emacs going to fix the bug where it decides to fold a line
> that's exactly as wide as the window? This 79 business is really
> silly, and had to impose on people using other editors.

In 50 years, our grandchildren will be writing code with brain  
implants and displays burned right into their retina, and they'll / 
still/ be subject to 79 characters.  I laugh every time I think that  
they'll have no idea why it is, but they'll still be unable to change  
it. :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR79gjHEjvBPtnXfVAQLn/AQApsNQ7KvoBM6wJgKUDHkS97Sd0qTYeRCy
qjFQE/hUtAGebqic3fcAEP3ASPp12fOnBpOWOxm0aQURoDdTi+ClTsXp6v/1aztf
9yC1xT3BH022Te82d3vLgRhixxregHZ+5i8ravb3Tb/xdUa3gouql+DyJw8tEAek
MGMdcrqoEfE=
=FiB+
-----END PGP SIGNATURE-----

From brett at python.org  Sat Feb 23 00:54:52 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 15:54:52 -0800
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
Message-ID: <bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>

On Fri, Feb 22, 2008 at 3:45 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  Hi everyone,
>
>  I've volunteered to be the release manager for Python 2.6 and 3.0.
>  It's been several years since I've RM'd a Python release, and I'm
>  happy to do it again (he says while the medication is still
>  working :).

Can the PSF buy you more of the meds? =)

>  I would like to get the next alpha releases of both
>  versions out before Pycon, so I propose next Friday, February 29 for
>  both.
>

Since they are just alphas, sure. Not like I am going to make any
earth-shattering changes that soon.

>  Guido reminded me that we released Python 1.6 and 2.0 together and it
>  makes sense to both of us to do the same for Python 2.6 and 3.0.  I
>  don't think it will be that much more work (for me at least :) to
>  release them in lockstep, so I think we should try it.  I won't try to
>  sync their pre-release version numbers except at the milestones (e.g.
>  first beta, release candidates, final releases).
>
>  I propose to change PEP 361 to outline the release schedule for both
>  Python 2.6 and 3.0.  I'm hoping we can work out a more definite
>  schedule at Pycon, but for now I want to at least describe the
>  lockstep release schedule and the Feb 29 date.
>
>  I'd also like for us to consider doing regular monthly releases.
>  Several other FLOSS projects I'm involved with are doing this to very
>  good success.  The nice thing is that everyone knows well in advance
>  when the next release is going to happen, and so all developers and
>  users know what to expect and what is needed from them.
>
>  I'd like to propose that we do a joint release the last Friday of
>  every month.  For the alphas, it's basically what's in svn.  This
>  gives us some time to experiment with the process out and see if we
>  like it enough to keep it going through the betas and final releases.
>
>  Comments?

If you want to do monthly alphas, go for it! But if you are going to
do that frequently is a source release going to make more sense than
doing binary builds?

-Brett

From barry at python.org  Sat Feb 23 00:55:40 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 22 Feb 2008 18:55:40 -0500
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <20080222162026.GB7354@panix.com>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
	<bbaeab100802211317t7d0b2371ld8e70fc615d49868@mail.gmail.com>
	<60bb7ceb0802211655y2ea30938y7a64bda9c55ac4e4@mail.gmail.com>
	<e27efe130802220001ua07c105lec3daafd61689a05@mail.gmail.com>
	<18366.62560.100720.755828@montanaro-dyndns-org.local>
	<20080222162026.GB7354@panix.com>
Message-ID: <600EABB0-D02B-4612-9821-2B4F587A708B@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 22, 2008, at 11:20 AM, Aahz wrote:

> On Fri, Feb 22, 2008, skip at pobox.com wrote:
>>
>>
>>>> Why not just skip the specifics except to say < 80 characters for  
>>>> all
>>>> lines?  Don't mention 72, 79 or any other number than 80:
>>
>>    Amaury> I often run "svn diff" in a console limited to 80  
>> characters.
>>    Amaury> Because of the leading "+", lines longer than 78 wrap,  
>> and the
>>    Amaury> output is more difficult to read.
>>
>> There will always be certain cases which present probems.  I use "svn
>> annotate" from time-to-time which adds an even wider margin to the  
>> left.
>> In those situations I either grin and bear it or stretch my window  
>> enough to
>> view it without wrapping.
>
> Yes, but svn/cvs diff is a particularly common use case.  I agree with
> Amaury.

My main concern is that we have only one line length limit for  
everything.  If we want that to be 78 or 72 or whatever, okay (though  
I still think 79 works well :) but I don't see much point in there  
being more than one limit.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR79g/HEjvBPtnXfVAQJCCQP/Qd7nWrSC3Wm6Y4+dPgv0ls1Td3ZTuf7n
ZzE6cIiV0h2tgKsS+olRHE2e/ttKNVRask2FPrhUClj4eXG6k3bVU/KsH9JR4wjH
Ha1ayDb74ZHqqdSZKrKCcsak5fismBv2Vsn8aDI3eslzFVEd0FF1dU+qQYf/m3je
2gjt9Fx6wYU=
=6WAr
-----END PGP SIGNATURE-----

From mal at egenix.com  Sat Feb 23 01:06:25 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat, 23 Feb 2008 01:06:25 +0100
Subject: [Python-Dev] Unicode <--> UTF-8 in CPython extension modules
In-Reply-To: <faa16b610802221546s75412576pa6db50cd5235f4f4@mail.gmail.com>
References: <47BF3D6E.2070301@redhat.com>
	<faa16b610802221546s75412576pa6db50cd5235f4f4@mail.gmail.com>
Message-ID: <47BF6381.9030409@egenix.com>

On 2008-02-23 00:46, Colin Walters wrote:
> On Fri, Feb 22, 2008 at 4:23 PM, John Dennis <jdennis at redhat.com> wrote:
> 
>>  Python programs which use Unicode string objects for their i18n and
>>  which "link" to C libraries expecting UTF-8 but which have a CPython
>>  binding which only uses 's' or 's#' formats programs seem to often
>>  fail with encoding errors.
> 
> One thing to be aware of is that PyGTK+ actually sets the Python
> Unicode object encoding to UTF-8.
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=132040
> 
> I mention this because PyGTK is a very popular library related to
> Python and Linux.  So currently if you "import gtk", then libraries
> which are using UTF-8 (as you say, the vast majority) will work with
> Python unicode objects unmodified.

Are you suggesting that John should rely on a bug in some 3rd party
extension instead of fixing the Python extension to use "es#" where
needed ?

There's a good reason why we don't allow setting the default
encoding outside site.py.

Trying to play tricks to change the default encoding later on
will only cause problems, e.g. the cached default encoded versions
of Unicode objects will then use different encodings - the one set
in site.py and later the ones with the new encoding. As a result,
all kind of weird things can happen.

Using the Python Unicode C API really isn't all that hard and it's
well documented too, so please use it instead of trying to design
software based on workarounds.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 23 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 python at rcn.com  Sat Feb 23 01:29:32 2008
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 22 Feb 2008 19:29:32 -0500 (EST)
Subject: [Python-Dev] Python 2.6 and 3.0
Message-ID: <20080222192932.AHK93803@ms19.lnh.mail.rcn.net>

[Barry]
> I'd also like for us to consider doing regular monthly releases. 

+1

From jdennis at redhat.com  Sat Feb 23 01:50:32 2008
From: jdennis at redhat.com (John Dennis)
Date: Fri, 22 Feb 2008 19:50:32 -0500
Subject: [Python-Dev] Unicode <--> UTF-8 in CPython extension modules
In-Reply-To: <faa16b610802221546s75412576pa6db50cd5235f4f4@mail.gmail.com>
References: <47BF3D6E.2070301@redhat.com>
	<faa16b610802221546s75412576pa6db50cd5235f4f4@mail.gmail.com>
Message-ID: <47BF6DD8.8080800@redhat.com>

Colin Walters wrote:
> On Fri, Feb 22, 2008 at 4:23 PM, John Dennis <jdennis at redhat.com> wrote:
> 
>>  Python programs which use Unicode string objects for their i18n and
>>  which "link" to C libraries expecting UTF-8 but which have a CPython
>>  binding which only uses 's' or 's#' formats programs seem to often
>>  fail with encoding errors.
> 
> One thing to be aware of is that PyGTK+ actually sets the Python
> Unicode object encoding to UTF-8.
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=132040
> 
> I mention this because PyGTK is a very popular library related to
> Python and Linux.  So currently if you "import gtk", then libraries
> which are using UTF-8 (as you say, the vast majority) will work with
> Python unicode objects unmodified.

Thank you Colin, your input was very helpful. The fact PyGTK's i18n 
handling worked was the counter example which made me doubt my analysis 
was correct but I can see from the Gnome bug report and Martin's 
subsequent comment that the analysis was sound. It had perplexed me 
enormously why in some circumstances i18n handling worked but failed in 
others. Apparently it was a side effect of importing gtk, a problem 
exacerbated when either the sequence of imports or the complete set of 
imports was not taken into account.

I am aware of other python bindings (libxml2 is one example) which share 
the same mistake of not using the 'es' family of format conversions when 
the underlying library is UTF-8. At least I now understand why 
incorrectly coded bindings in some circumstances produced correct 
results when logic dictated they shouldn't.

-- 
John Dennis <jdennis at redhat.com>

From lists at cheimes.de  Sat Feb 23 01:55:06 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 23 Feb 2008 01:55:06 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <20080222212842.GA13545@amk-desktop.matrixgroup.net>
References: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>	<47BD9DBC.2030106@holdenweb.com>	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>	<47BEA5C3.6050006@gmail.com>	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>	<47BEB89C.6080300@gmail.com>	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>	<47BF0E07.1070809@v.loewis.de>	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
	<20080222212842.GA13545@amk-desktop.matrixgroup.net>
Message-ID: <47BF6EEA.3020006@cheimes.de>

A.M. Kuchling wrote:
> Are we, as a development community, really running into problems with
> how we handle bugs?  There are certainly small cleanups possible, such
> as dropping the 'postponed' and 'later' resolutions that we don't seem
> to use very much, but the flow seems reasonably efficient to me.

We have over 1,700 open issues - bug reports, feature requests and
patches - in our bug tracker. In my humble opinion it's a sure sign for
a problem.

Christian

From guido at python.org  Sat Feb 23 02:05:26 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 22 Feb 2008 17:05:26 -0800
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BF6EEA.3020006@cheimes.de>
References: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
	<47BF0E07.1070809@v.loewis.de>
	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
	<20080222212842.GA13545@amk-desktop.matrixgroup.net>
	<47BF6EEA.3020006@cheimes.de>
Message-ID: <ca471dc20802221705p68f1df96t3a91b4d4d873b31d@mail.gmail.com>

On Fri, Feb 22, 2008 at 4:55 PM, Christian Heimes <lists at cheimes.de> wrote:
> We have over 1,700 open issues - bug reports, feature requests and
> patches - in our bug tracker. In my humble opinion it's a sure sign for
> a problem.

I don't think so. I think it's a sign of healthy software. Now, if
there were 1700 *serious* bugs, we'd have a problem. :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From rrr at ronadam.com  Sat Feb 23 02:47:40 2008
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 22 Feb 2008 19:47:40 -0600
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <2E45E94F-2248-4C5C-B3E9-2E7363EB19B8@python.org>
References: <20080221162115.C59541E4021@bag.python.org>	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>	<47BDB5F1.2000901@ronadam.com>
	<2E45E94F-2248-4C5C-B3E9-2E7363EB19B8@python.org>
Message-ID: <47BF7B3C.3040006@ronadam.com>



Barry Warsaw wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Feb 21, 2008, at 12:33 PM, Ron Adam wrote:
> 
>> Barry Warsaw wrote:
>>
>>> Why should docstrings and comments be limited to 72 characters when
>>> code is limited to 79 characters?  I ask because there is an ongoing
>>> debate at my company about this.
>> I'm not sure if this is the main reason, but when using pydoc to view
>> docstrings, the 72 character width allows for the added indent in  
>> class and
>> method sections.
> 
> Interesting.  Maybe because I almost always put doctests in separate  
> files, I don't run into this too much.  Having an indent of 4 for  
> doctest code never really bothers me too much.

I think the 72 character limit refers to the length of the doc string, not 
the length of the line.

Pydoc, ie...the help() function, strips leading white space off and then 
adds it's own margin, 4 characters for function doc strings, and 8 
characters with a vertical bar for class method doc strings.

Longer than 72 character doc strings in class methods wrap and break up the 
output of the help function.

Ron











From rrr at ronadam.com  Sat Feb 23 02:47:40 2008
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 22 Feb 2008 19:47:40 -0600
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <2E45E94F-2248-4C5C-B3E9-2E7363EB19B8@python.org>
References: <20080221162115.C59541E4021@bag.python.org>	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>	<47BDB5F1.2000901@ronadam.com>
	<2E45E94F-2248-4C5C-B3E9-2E7363EB19B8@python.org>
Message-ID: <47BF7B3C.3040006@ronadam.com>



Barry Warsaw wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Feb 21, 2008, at 12:33 PM, Ron Adam wrote:
> 
>> Barry Warsaw wrote:
>>
>>> Why should docstrings and comments be limited to 72 characters when
>>> code is limited to 79 characters?  I ask because there is an ongoing
>>> debate at my company about this.
>> I'm not sure if this is the main reason, but when using pydoc to view
>> docstrings, the 72 character width allows for the added indent in  
>> class and
>> method sections.
> 
> Interesting.  Maybe because I almost always put doctests in separate  
> files, I don't run into this too much.  Having an indent of 4 for  
> doctest code never really bothers me too much.

I think the 72 character limit refers to the length of the doc string, not 
the length of the line.

Pydoc, ie...the help() function, strips leading white space off and then 
adds it's own margin, 4 characters for function doc strings, and 8 
characters with a vertical bar for class method doc strings.

Longer than 72 character doc strings in class methods wrap and break up the 
output of the help function.

Ron











From amk at amk.ca  Sat Feb 23 03:40:19 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Fri, 22 Feb 2008 21:40:19 -0500
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BF6EEA.3020006@cheimes.de>
References: <47BD9DBC.2030106@holdenweb.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
	<47BF0E07.1070809@v.loewis.de>
	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
	<20080222212842.GA13545@amk-desktop.matrixgroup.net>
	<47BF6EEA.3020006@cheimes.de>
Message-ID: <20080223024019.GA9199@amk.local>

On Sat, Feb 23, 2008 at 01:55:06AM +0100, Christian Heimes wrote:
> We have over 1,700 open issues - bug reports, feature requests and
> patches - in our bug tracker. In my humble opinion it's a sure sign for
> a problem.

Sure, but is that because the bug life cycle is sub-optimal, or
because we don't have enough people handling bugs?  

I think for a long time we haven't been actively recruiting new
developers, and the pool of people with commit privileges remained
about the same.  Some committers go away, and some get caught up in
other projects, so the number of people who actually do work is much
smaller.  I think that's the primary problem to solve, and the bug
life cycle is much less significant.

I'm not against changing the bug cycle, just doubtful that changing it
will be a magic bullet for reducing the size of our backlog.

--amk

From brett at python.org  Sat Feb 23 04:46:20 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 19:46:20 -0800
Subject: [Python-Dev] Please sign up for the PyCon sprint if you are
	attending!
Message-ID: <bbaeab100802221946x3510d6b3lf714e342afd3959e@mail.gmail.com>

With the PyCon sprint approaching I would like all attendees to be
signed up on the wiki page for the sprint:
http://wiki.python.org/moin/PyCon2008/SprintSignups/Python . I am
going to be using that list to send out an email about what is exactly
expected of people in terms of setup ahead of time, etc.

And even if you do know what you are doing, I still would appreciate
people adding themselves so I can have a head count. That will let the
sprint coordinators make sure we have a space big enough for us.

-Brett

From ncoghlan at gmail.com  Sat Feb 23 06:40:54 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 23 Feb 2008 15:40:54 +1000
Subject: [Python-Dev] Proposed revision of PEP 3 (using the issue tracker)
Message-ID: <47BFB1E6.1020700@gmail.com>

I've attached a proposed revision of PEP 3 below. Feedback would be 
appreciated, and once we have a reasonable consensus that it accurately 
describes our current processes I can check it in and Martin can update 
the tracker to reflect any changes.

It is intentional that the current non-resolution resolutions like 
'later' are missing - I think those should definitely be retired.

I also left out the 'compile error' type - I would prefer to see the 
Compiler added to the Components list so we can attach feature requests 
to it as well as bugs.

One question I did have is whether or not access to 'security' type 
issues is automatically limited to a small subset of the developers.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pep-0003.txt
Url: http://mail.python.org/pipermail/python-dev/attachments/20080223/02d73e30/attachment-0001.txt 

From tjreedy at udel.edu  Sat Feb 23 07:55:09 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 23 Feb 2008 01:55:09 -0500
Subject: [Python-Dev] Proposed revision of PEP 3 (using the issue
	tracker)
References: <47BFB1E6.1020700@gmail.com>
Message-ID: <fpog0a$cta$1@ger.gmane.org>


"Nick Coghlan" <ncoghlan at gmail.com> wrote in message 
news:47BFB1E6.1020700 at gmail.com...
| *invalid*
|  the reported bug was either not described clearly enough to be 
reproduced,
|  or is actually the intended behaviour
|
| *works for me*
|  the reported bug could not be replicated by the developers

This strikes me as a near duuplicate of 'invalid'.  Do we really need this?

| *out of date*
|  the reported bug applies only to versions of Python which are no longer
|  supported, or the bug has already been fixed in all versions where it is
|  possible to fix it (some fixes require new features and hence cannot be
|  backported to maintenance branches)

This is another form of 'invalid' though more different than 'works for 
me'.  But does anyone really care other than this being a holdover from SF?

It seems to me that 'fixed', 'invalid', and 'duplicate' (of valid report) 
seem a good enough resolution of closed bug reports.

Thanks for a definite proposal that we can discuss and pass on to Martin.

tjr




From martin at v.loewis.de  Sat Feb 23 08:48:09 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 23 Feb 2008 08:48:09 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BF6EEA.3020006@cheimes.de>
References: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>	<ca471dc20802210731n513cdeddq2b609473c51323f4@mail.gmail.com>	<47BD9DBC.2030106@holdenweb.com>	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>	<47BEA5C3.6050006@gmail.com>	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>	<47BEB89C.6080300@gmail.com>	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>	<47BF0E07.1070809@v.loewis.de>	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>	<20080222212842.GA13545@amk-desktop.matrixgroup.net>
	<47BF6EEA.3020006@cheimes.de>
Message-ID: <47BFCFB9.20906@v.loewis.de>

> We have over 1,700 open issues - bug reports, feature requests and
> patches - in our bug tracker. In my humble opinion it's a sure sign for
> a problem.

As a historical record: people said the same thing when there were 500 
and 1000 open issues. 5 years from now, when we have 5000 open issues,
you will look back to the good old days when we were below 2000 :-)

Regards,
Martin

From martin at v.loewis.de  Sat Feb 23 08:50:50 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 23 Feb 2008 08:50:50 +0100
Subject: [Python-Dev] Proposed revision of PEP 3 (using the issue
	tracker)
In-Reply-To: <47BFB1E6.1020700@gmail.com>
References: <47BFB1E6.1020700@gmail.com>
Message-ID: <47BFD05A.9020703@v.loewis.de>

> One question I did have is whether or not access to 'security' type 
> issues is automatically limited to a small subset of the developers.

No. Reports requiring privacy should be sent to security at python.org

Regards,
Martin

From martin at v.loewis.de  Sat Feb 23 08:56:47 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 23 Feb 2008 08:56:47 +0100
Subject: [Python-Dev] Proposed revision of PEP 3 (using the
	issue	tracker)
In-Reply-To: <fpog0a$cta$1@ger.gmane.org>
References: <47BFB1E6.1020700@gmail.com> <fpog0a$cta$1@ger.gmane.org>
Message-ID: <47BFD1BF.8000703@v.loewis.de>

Terry Reedy wrote:
> "Nick Coghlan" <ncoghlan at gmail.com> wrote in message 
> news:47BFB1E6.1020700 at gmail.com...
> | *invalid*
> |  the reported bug was either not described clearly enough to be 
> reproduced,
> |  or is actually the intended behaviour
> |
> | *works for me*
> |  the reported bug could not be replicated by the developers
> 
> This strikes me as a near duuplicate of 'invalid'.  Do we really need this?

In the past, "invalid" was used when the behavior reported could be 
reproduced, and was the intended behavior. "works for me" was used when
the steps to reproduce it were clearly spelled out - just the outcome
was different from what the reporter claimed it to be. Possible causes
could be platform differences, or that the bug had been fixed meanwhile;
in either case, the original report might have been valid.


> | *out of date*
> |  the reported bug applies only to versions of Python which are no longer
> |  supported, or the bug has already been fixed in all versions where it is
> |  possible to fix it (some fixes require new features and hence cannot be
> |  backported to maintenance branches)
> 
> This is another form of 'invalid' though more different than 'works for 
> me'.  But does anyone really care other than this being a holdover from SF?

One issue to consider is also politeness. People sometimes complain that
they feel treated unfair if their report is declared "invalid" - they
surely believed it was a valid report, at the time they made it.

Regards,
Martin

From hsoft at hardcoded.net  Sat Feb 23 11:07:25 2008
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Sat, 23 Feb 2008 11:07:25 +0100
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <47BF6EEA.3020006@cheimes.de>
References: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<52dc1c820802210759j20b99e9anac4fe98a43e3e5b@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
	<47BF0E07.1070809@v.loewis.de>
	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
	<20080222212842.GA13545@amk-desktop.matrixgroup.net>
	<47BF6EEA.3020006@cheimes.de>
Message-ID: <2a70578d0802230207k3d020bd1tdb802a76bbfdf3f8@mail.gmail.com>

On 2/23/08, Christian Heimes <lists at cheimes.de> wrote:
> We have over 1,700 open issues - bug reports, feature requests and
>  patches - in our bug tracker. In my humble opinion it's a sure sign for
>  a problem.

There is also 12000 closed tickets, with 1200 of them having been
closed in the last 6 months (well, having had activity in the last 6
month, but I guess that's almost equivalent).

The number of issues (open or closed) that have been created in the
last 6 months is about 1050.

The flow seems healthy to me.

Virgil

From g.brandl at gmx.net  Sat Feb 23 11:57:35 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 23 Feb 2008 11:57:35 +0100
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <47BF22D6.9030600@trueblade.com>
References: <47BDFA81.8000805@trueblade.com>	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>
	<47BF22D6.9030600@trueblade.com>
Message-ID: <fpou6q$dd7$1@ger.gmane.org>

Eric Smith schrieb:
> Guido van Rossum wrote:
>> I wonder if, in order to change the behavior of various built-in
>> functions, it wouldn't be easier to be able to write
>> 
>> from future_builtins import oct, hex  # and who knows what else
> 
> This makes sense to me, especially if we have a 2to3 fixer which removes 
> this line.  I'll work on implementing future_builtins.

Will the future map and filter also belong there (and if they are imported
from future_builtins, 2to3 won't put a list() around them)?

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 facundobatista at gmail.com  Sat Feb 23 12:13:51 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Sat, 23 Feb 2008 09:13:51 -0200
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <2a70578d0802230207k3d020bd1tdb802a76bbfdf3f8@mail.gmail.com>
References: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
	<47BF0E07.1070809@v.loewis.de>
	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
	<20080222212842.GA13545@amk-desktop.matrixgroup.net>
	<47BF6EEA.3020006@cheimes.de>
	<2a70578d0802230207k3d020bd1tdb802a76bbfdf3f8@mail.gmail.com>
Message-ID: <e04bdf310802230313h1526abd3w94411cc0f0725380@mail.gmail.com>

2008/2/23, Virgil Dupras <hsoft at hardcoded.net>:

>
>  The flow seems healthy to me.
>

What I don't see healthy is that we have, per week, around 30 issues
more open (30 is the difference between those closed, and the new
ones).

So, the curve is always going up... fast.

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From steve at holdenweb.com  Sat Feb 23 13:09:11 2008
From: steve at holdenweb.com (Steve Holden)
Date: Sat, 23 Feb 2008 07:09:11 -0500
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802230313h1526abd3w94411cc0f0725380@mail.gmail.com>
References: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>	<47BEA5C3.6050006@gmail.com>	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>	<47BEB89C.6080300@gmail.com>	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>	<47BF0E07.1070809@v.loewis.de>	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>	<20080222212842.GA13545@amk-desktop.matrixgroup.net>	<47BF6EEA.3020006@cheimes.de>	<2a70578d0802230207k3d020bd1tdb802a76bbfdf3f8@mail.gmail.com>
	<e04bdf310802230313h1526abd3w94411cc0f0725380@mail.gmail.com>
Message-ID: <fpp2di$o46$1@ger.gmane.org>

Facundo Batista wrote:
> 2008/2/23, Virgil Dupras <hsoft at hardcoded.net>:
> 
>>  The flow seems healthy to me.
>>
> 
> What I don't see healthy is that we have, per week, around 30 issues
> more open (30 is the difference between those closed, and the new
> ones).
> 
> So, the curve is always going up... fast.
> 
As Andrew says, the only way to "fix" this, if you think it needs 
fixing, is to recruit new developers and encourage all developers to 
treat outstanding issues as a higher priority than they currently do.

Guido is happy with the current issue count, and relatively few of them 
are serious. Andrew has been organizing regular bug days. If the count 
keeps going up that's as much a measure of the increase in use as it is 
anything else.

I do think it would be a good idea to have a crew continually working to 
address the outstanding issues, but it isn't glamorous work and the fact 
remains that you need a significant understanding of the ecosphere to 
fix things in a sanitary way that's acceptable to committers. It would 
be good to address that issue (shoud we put it in the tracker?), but it 
would take significant efforts in evangelism and training. Most 
developers would rather just write code ...

Enlarging the pool of committers too quickly probably puts quality 
control at risk, something I'd be loath to see happen given Python's 
excellent record in this respect.

A larger team (not necessarily all committers) could help us improve 
quality and reduce the issue count. Deleting issues purely on grounds of 
age is simply throwing away useful information to reduce a numeric 
metric that doesn't really relate directly to quality, and quality 
assurance is the real point of having the tracker.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From facundobatista at gmail.com  Sat Feb 23 13:26:35 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Sat, 23 Feb 2008 10:26:35 -0200
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <fpp2di$o46$1@ger.gmane.org>
References: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
	<47BF0E07.1070809@v.loewis.de>
	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
	<20080222212842.GA13545@amk-desktop.matrixgroup.net>
	<47BF6EEA.3020006@cheimes.de>
	<2a70578d0802230207k3d020bd1tdb802a76bbfdf3f8@mail.gmail.com>
	<e04bdf310802230313h1526abd3w94411cc0f0725380@mail.gmail.com>
	<fpp2di$o46$1@ger.gmane.org>
Message-ID: <e04bdf310802230426v135128afsa908220a5e3e5e8f@mail.gmail.com>

2008/2/23, Steve Holden <steve at holdenweb.com>:

>  A larger team (not necessarily all committers) could help us improve
>  quality and reduce the issue count. Deleting issues purely on grounds of

Exactly, that's why I love Python bug days.. and I'm pushing this hard
in Argentina!

In the January one, two new argentinian developers worked closing
issues, and today a new one is jumping on the train. Also, we did a
small bug day, in a Python Camping in Argentina, where we closed 4 or
5 issues, and two more guys learned the whole process (more on this
event on other post).

This evangelization is very important, IMO.

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From mwm at mired.org  Sat Feb 23 07:11:44 2008
From: mwm at mired.org (Mike Meyer)
Date: Sat, 23 Feb 2008 01:11:44 -0500
Subject: [Python-Dev] [Python-checkins] r60919 - peps/trunk/pep-0008.txt
In-Reply-To: <CFD6B26D-928C-448B-A8B5-6C8393693397@python.org>
References: <20080221162115.C59541E4021@bag.python.org>
	<BEC4EBCA-7C8F-4D4B-BFCE-8FC174820254@python.org>
	<ca471dc20802210930q654b4791p3c0588d374603e6@mail.gmail.com>
	<CFD6B26D-928C-448B-A8B5-6C8393693397@python.org>
Message-ID: <20080223011144.7a442231@bhuda.mired.org>

On Fri, 22 Feb 2008 18:53:48 -0500 Barry Warsaw <barry at python.org> wrote: now is
> In 50 years, our grandchildren will be writing code with brain  
> implants and displays burned right into their retina, and they'll / 
> still/ be subject to 79 characters.  I laugh every time I think that  
> they'll have no idea why it is, but they'll still be unable to change  
> it. :)

There are reasons (other than antiquated media formats) for a coding
standard to mandate a line length of 70-80 characters: to improve the
readability of the source code. Depending on who (and how) you ask,
the most comfortable line length for people to read will vary some,
but 70 characters is close to the maximum you'll get, because it gets
harder to track back across the page as lines get longer. While code
is so ragged that that's probably not as much of a problem, comments
aren't. Formatting those to a max of ~70 characters makes them easy to
read. Formatting your program so that block comments and code are
about the same makes optimal use of the display space.

Whether the readability issue has anything to do with why 80 column
cards dominated the industry (some were as short as 24 columns, and I
could swear I saw a reference to 120-column cards *somewhere*) is left
as an exercise for the reader.

	 <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.


From eric+python-dev at trueblade.com  Sat Feb 23 15:06:36 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Sat, 23 Feb 2008 09:06:36 -0500
Subject: [Python-Dev] future_builtins (was: Backporting PEP 3127 to trunk)
In-Reply-To: <fpou6q$dd7$1@ger.gmane.org>
References: <47BDFA81.8000805@trueblade.com>	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>	<47BF22D6.9030600@trueblade.com>
	<fpou6q$dd7$1@ger.gmane.org>
Message-ID: <47C0286C.2040103@trueblade.com>

Georg Brandl wrote:
> Eric Smith schrieb:
>> Guido van Rossum wrote:
>>> I wonder if, in order to change the behavior of various built-in
>>> functions, it wouldn't be easier to be able to write
>>>
>>> from future_builtins import oct, hex  # and who knows what else
>> This makes sense to me, especially if we have a 2to3 fixer which removes 
>> this line.  I'll work on implementing future_builtins.
> 
> Will the future map and filter also belong there (and if they are imported
> from future_builtins, 2to3 won't put a list() around them)?

I can certainly do the mechanics of adding the new versions of map and 
filter to future_builtins, if it's seen as desirable.

Maybe we could have 2to3 not put list() around map and filter, if 
there's been an import of future_builtins.  I realize that there are 
pathological cases where 2to3 doesn't know that a usage of map or filter 
would really be the generator version from future_builtins, as opposed 
to the actual list-producing builtins.  But would it be good enough to 
take an import of future_builtins as a hint that the author was aware 
that 2to3 wasn't going to change map and filter?

Still an open issue in my mind is adding a -3 warning to oct and hex, 
and now conceivably map and filter.  Would that be going too far?

Eric.

From guido at python.org  Sat Feb 23 16:34:30 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 23 Feb 2008 07:34:30 -0800
Subject: [Python-Dev] Backporting PEP 3127 to trunk
In-Reply-To: <fpou6q$dd7$1@ger.gmane.org>
References: <47BDFA81.8000805@trueblade.com>
	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>
	<47BF22D6.9030600@trueblade.com> <fpou6q$dd7$1@ger.gmane.org>
Message-ID: <ca471dc20802230734i200477efw5cf7eb2dfe51d4ab@mail.gmail.com>

On Sat, Feb 23, 2008 at 2:57 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> Eric Smith schrieb:
>
>
> > Guido van Rossum wrote:
>  >> I wonder if, in order to change the behavior of various built-in
>  >> functions, it wouldn't be easier to be able to write
>  >>
>  >> from future_builtins import oct, hex  # and who knows what else
>  >
>  > This makes sense to me, especially if we have a 2to3 fixer which removes
>  > this line.  I'll work on implementing future_builtins.
>
>  Will the future map and filter also belong there (and if they are imported
>  from future_builtins, 2to3 won't put a list() around them)?

Good idea, on both counts! These an just be imported from itertools
anyway (except they should be wrapped in something that rejects a None
function).

And zip() ditto.

I suggest that if you don't implement this right away (while the bug
day is still on :), you at least add a feature request to the issue
tracker, marked easy.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Sat Feb 23 17:06:39 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 23 Feb 2008 08:06:39 -0800
Subject: [Python-Dev] future_builtins (was: Backporting PEP 3127 to
	trunk)
In-Reply-To: <47C0286C.2040103@trueblade.com>
References: <47BDFA81.8000805@trueblade.com>
	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>
	<47BF22D6.9030600@trueblade.com> <fpou6q$dd7$1@ger.gmane.org>
	<47C0286C.2040103@trueblade.com>
Message-ID: <ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>

I don't think a -3 warning for oct or hex would do any good.

I do think map() and filter() should issue a warning under -3 when the
first arg is None. (Or does 2to3 detect this now?)

On Sat, Feb 23, 2008 at 6:06 AM, Eric Smith
<eric+python-dev at trueblade.com> wrote:
> Georg Brandl wrote:
>  > Eric Smith schrieb:
>  >> Guido van Rossum wrote:
>  >>> I wonder if, in order to change the behavior of various built-in
>  >>> functions, it wouldn't be easier to be able to write
>  >>>
>  >>> from future_builtins import oct, hex  # and who knows what else
>  >> This makes sense to me, especially if we have a 2to3 fixer which removes
>  >> this line.  I'll work on implementing future_builtins.
>  >
>  > Will the future map and filter also belong there (and if they are imported
>  > from future_builtins, 2to3 won't put a list() around them)?
>
>  I can certainly do the mechanics of adding the new versions of map and
>  filter to future_builtins, if it's seen as desirable.
>
>  Maybe we could have 2to3 not put list() around map and filter, if
>  there's been an import of future_builtins.  I realize that there are
>  pathological cases where 2to3 doesn't know that a usage of map or filter
>  would really be the generator version from future_builtins, as opposed
>  to the actual list-producing builtins.  But would it be good enough to
>  take an import of future_builtins as a hint that the author was aware
>  that 2to3 wasn't going to change map and filter?
>
>  Still an open issue in my mind is adding a -3 warning to oct and hex,
>  and now conceivably map and filter.  Would that be going too far?
>
>  Eric.
>  _______________________________________________
>  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 eric+python-dev at trueblade.com  Sat Feb 23 18:01:35 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Sat, 23 Feb 2008 12:01:35 -0500
Subject: [Python-Dev] future_builtins
In-Reply-To: <ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>
References: <47BDFA81.8000805@trueblade.com>	
	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>	
	<47BF22D6.9030600@trueblade.com> <fpou6q$dd7$1@ger.gmane.org>	
	<47C0286C.2040103@trueblade.com>
	<ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>
Message-ID: <47C0516F.8050605@trueblade.com>

Guido van Rossum wrote:
> I don't think a -3 warning for oct or hex would do any good.

I'm curious as to why.  oct and hex have different behavior in 3.0, 
which is what I thought -3 was for.  hex might be overkill, as the only 
differences are the "L" and the __hex__ behavior.  But oct is always 
different.

From guido at python.org  Sat Feb 23 20:11:39 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 23 Feb 2008 11:11:39 -0800
Subject: [Python-Dev] future_builtins
In-Reply-To: <47C0516F.8050605@trueblade.com>
References: <47BDFA81.8000805@trueblade.com>
	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>
	<47BF22D6.9030600@trueblade.com> <fpou6q$dd7$1@ger.gmane.org>
	<47C0286C.2040103@trueblade.com>
	<ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>
	<47C0516F.8050605@trueblade.com>
Message-ID: <ca471dc20802231111w2e8895d9i25fd80e6c46bdbf4@mail.gmail.com>

On Sat, Feb 23, 2008 at 9:01 AM, Eric Smith
<eric+python-dev at trueblade.com> wrote:
> Guido van Rossum wrote:
>  > I don't think a -3 warning for oct or hex would do any good.
>
>  I'm curious as to why.  oct and hex have different behavior in 3.0,
>  which is what I thought -3 was for.  hex might be overkill, as the only
>  differences are the "L" and the __hex__ behavior.  But oct is always
>  different.

Well, yeah, but what are you going to do about it? Not use oct()? I
expect that *most* programs using oct() or hex() will work just as
well under 3.0; typically the output is just printed, not parsed or
otherwise further processed.

I think -3 should only warn about things where it's easy to modify the
code so that it continues to work under 2.6 but will also work under
3.0. Forcing people to use "%o" just to get rid of the warning doesn't
make sense to me.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From eric+python-dev at trueblade.com  Sat Feb 23 20:34:23 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Sat, 23 Feb 2008 14:34:23 -0500
Subject: [Python-Dev] future_builtins
In-Reply-To: <ca471dc20802231111w2e8895d9i25fd80e6c46bdbf4@mail.gmail.com>
References: <47BDFA81.8000805@trueblade.com>	
	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>	
	<47BF22D6.9030600@trueblade.com> <fpou6q$dd7$1@ger.gmane.org>	
	<47C0286C.2040103@trueblade.com>	
	<ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>	
	<47C0516F.8050605@trueblade.com>
	<ca471dc20802231111w2e8895d9i25fd80e6c46bdbf4@mail.gmail.com>
Message-ID: <47C0753F.8090905@trueblade.com>

Guido van Rossum wrote:
> On Sat, Feb 23, 2008 at 9:01 AM, Eric Smith
> <eric+python-dev at trueblade.com> wrote:
>> Guido van Rossum wrote:
>>  > I don't think a -3 warning for oct or hex would do any good.
>>
>>  I'm curious as to why.  oct and hex have different behavior in 3.0,
>>  which is what I thought -3 was for.  hex might be overkill, as the only
>>  differences are the "L" and the __hex__ behavior.  But oct is always
>>  different.
> 
> Well, yeah, but what are you going to do about it? Not use oct()? I
> expect that *most* programs using oct() or hex() will work just as
> well under 3.0; typically the output is just printed, not parsed or
> otherwise further processed.
> 
> I think -3 should only warn about things where it's easy to modify the
> code so that it continues to work under 2.6 but will also work under
> 3.0. Forcing people to use "%o" just to get rid of the warning doesn't
> make sense to me.
> 

My thinking wast that using code that run under -3 without warnings 
would work exactly the same under 3.0, after running through 2to3.  So 
if oct() gave me a warning, I'd switch to the future_builtins version, 
and do whatever it took to get my program running again under 2.6 (which 
might involve not caring that the output changed from 2.5 to 2.6). 
Maybe it's wishful thinking.  I'm not too worried about this specific 
case, either.



From guido at python.org  Sat Feb 23 21:52:23 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 23 Feb 2008 12:52:23 -0800
Subject: [Python-Dev] future_builtins
In-Reply-To: <47C0753F.8090905@trueblade.com>
References: <47BDFA81.8000805@trueblade.com>
	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>
	<47BF22D6.9030600@trueblade.com> <fpou6q$dd7$1@ger.gmane.org>
	<47C0286C.2040103@trueblade.com>
	<ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>
	<47C0516F.8050605@trueblade.com>
	<ca471dc20802231111w2e8895d9i25fd80e6c46bdbf4@mail.gmail.com>
	<47C0753F.8090905@trueblade.com>
Message-ID: <ca471dc20802231252p516d16f1y4185abfd2f726cf8@mail.gmail.com>

On Sat, Feb 23, 2008 at 11:34 AM, Eric Smith
<eric+python-dev at trueblade.com> wrote:
> Guido van Rossum wrote:
>  > On Sat, Feb 23, 2008 at 9:01 AM, Eric Smith
>  > <eric+python-dev at trueblade.com> wrote:
>  >> Guido van Rossum wrote:
>  >>  > I don't think a -3 warning for oct or hex would do any good.
>  >>
>  >>  I'm curious as to why.  oct and hex have different behavior in 3.0,
>  >>  which is what I thought -3 was for.  hex might be overkill, as the only
>  >>  differences are the "L" and the __hex__ behavior.  But oct is always
>  >>  different.
>  >
>  > Well, yeah, but what are you going to do about it? Not use oct()? I
>  > expect that *most* programs using oct() or hex() will work just as
>  > well under 3.0; typically the output is just printed, not parsed or
>  > otherwise further processed.
>  >
>  > I think -3 should only warn about things where it's easy to modify the
>  > code so that it continues to work under 2.6 but will also work under
>  > 3.0. Forcing people to use "%o" just to get rid of the warning doesn't
>  > make sense to me.

>  My thinking wast that using code that run under -3 without warnings
>  would work exactly the same under 3.0, after running through 2to3.

That's wishful thinking. :)

> So if oct() gave me a warning, I'd switch to the future_builtins version,
>  and do whatever it took to get my program running again under 2.6 (which
>  might involve not caring that the output changed from 2.5 to 2.6).
>  Maybe it's wishful thinking.  I'm not too worried about this specific
>  case, either.

I think practicality says we should not warn about this.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From facundobatista at gmail.com  Sat Feb 23 22:22:37 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Sat, 23 Feb 2008 19:22:37 -0200
Subject: [Python-Dev] Mutex module
Message-ID: <e04bdf310802231322lf5b770erc1620032054a4519@mail.gmail.com>

Hi!

In today's bug day, an Argentinian colleague called my attention over
the issue 1746071.

This issue is about mutex:

"""The mutex module defines a class that allows mutual-exclusion via
acquiring and releasing locks. It does not require (or imply)
threading or multi-tasking, though it could be useful for those
purposes."""

The problem here is that mutex is NOT thread safe! Even when it says
in the docs that it could be useful for threading!

"Ok, let's make this mutex to be thread-safe", I thought, and my
colleague reviewed the proposed patch, even finding and submitting a
correction to it.

But two points prevented me for further work here:

- It has not test cases at all

- It does something that could be easily done (today) using parts from
the threading module.

There're some comments in that issue that points towards a deprecation
of this module.

So, I'm asking here. Is it still working in 3k? What are the plans
here? What do you think about this module? Is somebody using it?

Thank you all! Regards,

[1] http://bugs.python.org/issue1746071
[2] http://docs.python.org/dev/library/mutex.html

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From guido at python.org  Sat Feb 23 22:26:31 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 23 Feb 2008 13:26:31 -0800
Subject: [Python-Dev] Fwd:  Mutex module
In-Reply-To: <ca471dc20802231326q2e7bb261pcb35643ef463ae92@mail.gmail.com>
References: <e04bdf310802231322lf5b770erc1620032054a4519@mail.gmail.com>
	<ca471dc20802231326q2e7bb261pcb35643ef463ae92@mail.gmail.com>
Message-ID: <ca471dc20802231326n2136581cp88c038169345767f@mail.gmail.com>

---------- Forwarded message ----------
From: Guido van Rossum <guido at python.org>
Date: Sat, Feb 23, 2008 at 1:26 PM
Subject: Re: [Python-Dev] Mutex module
To: Facundo Batista <facundobatista at gmail.com>


According to the docstring it's only meant to be used with sched.py.
 Please don't try to make it work with threads! Maybe this needs to be
 moved into a "simulations" package in 3.0?



 On Sat, Feb 23, 2008 at 1:22 PM, Facundo Batista
 <facundobatista at gmail.com> wrote:
 > Hi!
 >
 > In today's bug day, an Argentinian colleague called my attention over
 > the issue 1746071.
 >
 > This issue is about mutex:
 >
 > """The mutex module defines a class that allows mutual-exclusion via
 > acquiring and releasing locks. It does not require (or imply)
 > threading or multi-tasking, though it could be useful for those
 > purposes."""
 >
 > The problem here is that mutex is NOT thread safe! Even when it says
 > in the docs that it could be useful for threading!
 >
 > "Ok, let's make this mutex to be thread-safe", I thought, and my
 > colleague reviewed the proposed patch, even finding and submitting a
 > correction to it.
 >
 > But two points prevented me for further work here:
 >
 > - It has not test cases at all
 >
 > - It does something that could be easily done (today) using parts from
 > the threading module.
 >
 > There're some comments in that issue that points towards a deprecation
 > of this module.
 >
 > So, I'm asking here. Is it still working in 3k? What are the plans
 > here? What do you think about this module? Is somebody using it?
 >
 > Thank you all! Regards,
 >
 > [1] http://bugs.python.org/issue1746071
 > [2] http://docs.python.org/dev/library/mutex.html
 >
 > --
 > .    Facundo
 >
 > Blog: http://www.taniquetil.com.ar/plog/
 > PyAr: http://www.python.org/ar/
 > _______________________________________________
 > 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/)



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From facundobatista at gmail.com  Sat Feb 23 22:30:05 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Sat, 23 Feb 2008 19:30:05 -0200
Subject: [Python-Dev] Fwd: Mutex module
In-Reply-To: <ca471dc20802231326n2136581cp88c038169345767f@mail.gmail.com>
References: <e04bdf310802231322lf5b770erc1620032054a4519@mail.gmail.com>
	<ca471dc20802231326q2e7bb261pcb35643ef463ae92@mail.gmail.com>
	<ca471dc20802231326n2136581cp88c038169345767f@mail.gmail.com>
Message-ID: <e04bdf310802231330x4757316v4123bfa02abc73e6@mail.gmail.com>

2008/2/23, Guido van Rossum <guido at python.org>:

>  According to the docstring it's only meant to be used with sched.py.
>   Please don't try to make it work with threads! Maybe this needs to be
>   moved into a "simulations" package in 3.0?

Ok, I'll close the issue with this, and forward this mail to the
stdlib reorg for proper handling.

Thank you!

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From facundobatista at gmail.com  Sat Feb 23 22:46:25 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Sat, 23 Feb 2008 19:46:25 -0200
Subject: [Python-Dev] Fwd: Mutex module
In-Reply-To: <e04bdf310802231330x4757316v4123bfa02abc73e6@mail.gmail.com>
References: <e04bdf310802231322lf5b770erc1620032054a4519@mail.gmail.com>
	<ca471dc20802231326q2e7bb261pcb35643ef463ae92@mail.gmail.com>
	<ca471dc20802231326n2136581cp88c038169345767f@mail.gmail.com>
	<e04bdf310802231330x4757316v4123bfa02abc73e6@mail.gmail.com>
Message-ID: <e04bdf310802231346x13655bf2pfecbcc0ab9bac551@mail.gmail.com>

2008/2/23, Facundo Batista <facundobatista at gmail.com>:

> Ok, I'll close the issue with this, and forward this mail to the
>  stdlib reorg for proper handling.

1. Done

2. It was already taken care of in the stdlib reorg sheet (it will be
removed, or at least its api hidden, in 3.0)

Thank you!

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From stephen at xemacs.org  Sun Feb 24 00:06:10 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 24 Feb 2008 08:06:10 +0900
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <e04bdf310802230313h1526abd3w94411cc0f0725380@mail.gmail.com>
References: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<47BEA5C3.6050006@gmail.com>
	<e04bdf310802220331k3b688c88qa0b785f01b43a03e@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
	<47BF0E07.1070809@v.loewis.de>
	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
	<20080222212842.GA13545@amk-desktop.matrixgroup.net>
	<47BF6EEA.3020006@cheimes.de>
	<2a70578d0802230207k3d020bd1tdb802a76bbfdf3f8@mail.gmail.com>
	<e04bdf310802230313h1526abd3w94411cc0f0725380@mail.gmail.com>
Message-ID: <87y79bff31.fsf@uwakimon.sk.tsukuba.ac.jp>

Facundo Batista writes:
 > 2008/2/23, Virgil Dupras <hsoft at hardcoded.net>:

 > >  The flow seems healthy to me.

+1

 > What I don't see healthy is that we have, per week, around 30 issues
 > more open (30 is the difference between those closed, and the new
 > ones).
 > 
 > So, the curve is always going up... fast.

This merely means that Python users are applying Python to problems
that the current set of developers never imagined.  As long as the
flow of solved issues is increasing, that's a symptom of strength, not
weakness.

If that curve ever turns down, it means that users are giving up on
Python as a tool for solving ever harder problems.  That's where it
gets scarey.

From nnorwitz at gmail.com  Sun Feb 24 00:26:04 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sat, 23 Feb 2008 15:26:04 -0800
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
Message-ID: <ee2a432c0802231526k4e3241f3x1900b4e65c4058e7@mail.gmail.com>

+1 to everything -- n

On Fri, Feb 22, 2008 at 3:45 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  Hi everyone,
>
>  I've volunteered to be the release manager for Python 2.6 and 3.0.
>  It's been several years since I've RM'd a Python release, and I'm
>  happy to do it again (he says while the medication is still
>  working :).  I would like to get the next alpha releases of both
>  versions out before Pycon, so I propose next Friday, February 29 for
>  both.
>
>  Guido reminded me that we released Python 1.6 and 2.0 together and it
>  makes sense to both of us to do the same for Python 2.6 and 3.0.  I
>  don't think it will be that much more work (for me at least :) to
>  release them in lockstep, so I think we should try it.  I won't try to
>  sync their pre-release version numbers except at the milestones (e.g.
>  first beta, release candidates, final releases).
>
>  I propose to change PEP 361 to outline the release schedule for both
>  Python 2.6 and 3.0.  I'm hoping we can work out a more definite
>  schedule at Pycon, but for now I want to at least describe the
>  lockstep release schedule and the Feb 29 date.
>
>  I'd also like for us to consider doing regular monthly releases.
>  Several other FLOSS projects I'm involved with are doing this to very
>  good success.  The nice thing is that everyone knows well in advance
>  when the next release is going to happen, and so all developers and
>  users know what to expect and what is needed from them.
>
>  I'd like to propose that we do a joint release the last Friday of
>  every month.  For the alphas, it's basically what's in svn.  This
>  gives us some time to experiment with the process out and see if we
>  like it enough to keep it going through the betas and final releases.
>
>  Comments?
>  - -Barry
>
>  -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v1.4.8 (Darwin)
>
>  iQCVAwUBR79ek3EjvBPtnXfVAQJrmQP+KAzy0lSzake2BZsVxErD0kpFQJM+Iij0
>  qN86wjH0NoqARMfYKVA6eUzEY8vZPu7sJl+SjCOmhnE/KP+l/ArOdis5smiSKwQI
>  klL4XKd/qdorTMqQ9mWgA0DeBb0Asvln9y64nxzNqgve+36q9j6ytPuRey1GjSI5
>  nVWoJDb3WsM=
>  =4SRa
>  -----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/nnorwitz%40gmail.com
>

From facundobatista at gmail.com  Sun Feb 24 00:32:51 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Sat, 23 Feb 2008 21:32:51 -0200
Subject: [Python-Dev] Small RFEs and the Bug Tracker
In-Reply-To: <87y79bff31.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <2a70578d0802202359r13b2e3e6w7d2b72ef94b0b767@mail.gmail.com>
	<47BEB89C.6080300@gmail.com>
	<aac2c7cb0802220916o87717bcr7c707b393221c024@mail.gmail.com>
	<47BF0E07.1070809@v.loewis.de>
	<bbaeab100802221306j57bacdb4q645292f61eb30773@mail.gmail.com>
	<20080222212842.GA13545@amk-desktop.matrixgroup.net>
	<47BF6EEA.3020006@cheimes.de>
	<2a70578d0802230207k3d020bd1tdb802a76bbfdf3f8@mail.gmail.com>
	<e04bdf310802230313h1526abd3w94411cc0f0725380@mail.gmail.com>
	<87y79bff31.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <e04bdf310802231532j13a797aco51183e3ded51579@mail.gmail.com>

2008/2/23, Stephen J. Turnbull <stephen at xemacs.org>:

>  If that curve ever turns down, it means that users are giving up on
>  Python as a tool for solving ever harder problems.  That's where it
>  gets scarey.

It depends. If that happens because no new issues are found, maybe (it
could happen also that Python gets more and more solid).

But if we solve more issues than which are opened, that is good too, :)

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From ndbecker2 at gmail.com  Sun Feb 24 01:55:53 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sat, 23 Feb 2008 19:55:53 -0500
Subject: [Python-Dev] can't set attributes of built-in/extension type
Message-ID: <fpqfap$etu$1@ger.gmane.org>

There is some discussion on this subject, archived here:
http://permalink.gmane.org/gmane.comp.python.general/560661

I wonder if anyone could shed some light on this subject?

(Or, help me understand, what is the difference between a type that I create
using python C api and a python class?)


From guido at python.org  Sun Feb 24 02:04:04 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 23 Feb 2008 17:04:04 -0800
Subject: [Python-Dev] can't set attributes of built-in/extension type
In-Reply-To: <fpqfap$etu$1@ger.gmane.org>
References: <fpqfap$etu$1@ger.gmane.org>
Message-ID: <ca471dc20802231704m5b035c5ela258fd85d8687e3e@mail.gmail.com>

On Sat, Feb 23, 2008 at 4:55 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> There is some discussion on this subject, archived here:
>  http://permalink.gmane.org/gmane.comp.python.general/560661
>
>  I wonder if anyone could shed some light on this subject?
>
>  (Or, help me understand, what is the difference between a type that I create
>  using python C api and a python class?)

This is prohibited intentionally to prevent accidental fatal changes
to built-in types (fatal to parts of the code that you never though
of). Also, it is done to prevent the changes to affect different
interpreters residing in the address space, since built-in types
(unlike user-defined classes) are shared between all such
interpreters.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From nnorwitz at gmail.com  Sun Feb 24 02:59:41 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sat, 23 Feb 2008 17:59:41 -0800
Subject: [Python-Dev] future_builtins (was: Backporting PEP 3127 to
	trunk)
In-Reply-To: <ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>
References: <47BDFA81.8000805@trueblade.com>
	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>
	<47BF22D6.9030600@trueblade.com> <fpou6q$dd7$1@ger.gmane.org>
	<47C0286C.2040103@trueblade.com>
	<ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>
Message-ID: <ee2a432c0802231759r4a7c70ebm7e020c89f1fdf37b@mail.gmail.com>

On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <guido at python.org> wrote:
>
>  I do think map() and filter() should issue a warning under -3 when the
>  first arg is None. (Or does 2to3 detect this now?)

What's wrong with filter(None, seq)?  That currently works in 3k:

>>> filter(None, range(5))
<itertools.ifilter object at 0x2b5be60da450>
>>> [x for x in _]
[1, 2, 3, 4]

(Side note, shouldn't we change the names for filter/map?)

n

From martin at v.loewis.de  Sun Feb 24 05:49:09 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 24 Feb 2008 05:49:09 +0100
Subject: [Python-Dev] can't set attributes of built-in/extension type
In-Reply-To: <fpqfap$etu$1@ger.gmane.org>
References: <fpqfap$etu$1@ger.gmane.org>
Message-ID: <47C0F745.2050408@v.loewis.de>

> (Or, help me understand, what is the difference between a type that I create
> using python C api and a python class?)

Grepping for the specific error message would have answered that 
question: Python (new-style) classes have the Py_TPFLAGS_HEAPTYPE
set, types declared as static structs in C don't.

Regards,
Martin

From ncoghlan at gmail.com  Sun Feb 24 06:57:34 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 24 Feb 2008 15:57:34 +1000
Subject: [Python-Dev] Proposed revision of PEP 3 (using
	the	issue	tracker)
In-Reply-To: <47BFD1BF.8000703@v.loewis.de>
References: <47BFB1E6.1020700@gmail.com> <fpog0a$cta$1@ger.gmane.org>
	<47BFD1BF.8000703@v.loewis.de>
Message-ID: <47C1074E.7060100@gmail.com>

Martin v. L?wis wrote:
> One issue to consider is also politeness. People sometimes complain that
> they feel treated unfair if their report is declared "invalid" - they
> surely believed it was a valid report, at the time they made it.

I agree with Martin for both of these - 'works for me' and 'out of date' 
convey additional information to the originator of the bug, even if they 
don't make a signifcant difference from a development point of view.

I'd prefer to keep an outright 'invalid' for the cases where the 
reporter was either genuinely wrong about the intended behaviour, or 
where the bug report itself is manifestly inadequate (e.g. "I tried to 
do xyz and it broke" with no further details).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From rrr at ronadam.com  Sun Feb 24 07:17:20 2008
From: rrr at ronadam.com (Ron Adam)
Date: Sun, 24 Feb 2008 00:17:20 -0600
Subject: [Python-Dev] Proposed revision of PEP 3 (using the issue
	tracker)
In-Reply-To: <47C1074E.7060100@gmail.com>
References: <47BFB1E6.1020700@gmail.com>
	<fpog0a$cta$1@ger.gmane.org>	<47BFD1BF.8000703@v.loewis.de>
	<47C1074E.7060100@gmail.com>
Message-ID: <47C10BF0.1080501@ronadam.com>



Nick Coghlan wrote:
> Martin v. L?wis wrote:
>> One issue to consider is also politeness. People sometimes complain that
>> they feel treated unfair if their report is declared "invalid" - they
>> surely believed it was a valid report, at the time they made it.
> 
> I agree with Martin for both of these - 'works for me' and 'out of date' 
> convey additional information to the originator of the bug, even if they 
> don't make a signifcant difference from a development point of view.

The term 'works for me' can be confused with 'solution/patch works for me'. 
  I've generally seen the phrase 'works for me' to mean agreement of a 
proposed action of some sort.

Maybe something along the lines of 'can not reproduce' would be better?


Ron



> I'd prefer to keep an outright 'invalid' for the cases where the 
> reporter was either genuinely wrong about the intended behaviour, or 
> where the bug report itself is manifestly inadequate (e.g. "I tried to 
> do xyz and it broke" with no further details).
> 
> Cheers,
> Nick.
> 

From rrr at ronadam.com  Sun Feb 24 07:17:20 2008
From: rrr at ronadam.com (Ron Adam)
Date: Sun, 24 Feb 2008 00:17:20 -0600
Subject: [Python-Dev] Proposed revision of PEP 3 (using the issue
	tracker)
In-Reply-To: <47C1074E.7060100@gmail.com>
References: <47BFB1E6.1020700@gmail.com>
	<fpog0a$cta$1@ger.gmane.org>	<47BFD1BF.8000703@v.loewis.de>
	<47C1074E.7060100@gmail.com>
Message-ID: <47C10BF0.1080501@ronadam.com>



Nick Coghlan wrote:
> Martin v. L?wis wrote:
>> One issue to consider is also politeness. People sometimes complain that
>> they feel treated unfair if their report is declared "invalid" - they
>> surely believed it was a valid report, at the time they made it.
> 
> I agree with Martin for both of these - 'works for me' and 'out of date' 
> convey additional information to the originator of the bug, even if they 
> don't make a signifcant difference from a development point of view.

The term 'works for me' can be confused with 'solution/patch works for me'. 
  I've generally seen the phrase 'works for me' to mean agreement of a 
proposed action of some sort.

Maybe something along the lines of 'can not reproduce' would be better?


Ron



> I'd prefer to keep an outright 'invalid' for the cases where the 
> reporter was either genuinely wrong about the intended behaviour, or 
> where the bug report itself is manifestly inadequate (e.g. "I tried to 
> do xyz and it broke" with no further details).
> 
> Cheers,
> Nick.
> 


From brett at python.org  Sun Feb 24 08:15:46 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 23 Feb 2008 23:15:46 -0800
Subject: [Python-Dev] Proposed revision of PEP 3 (using the issue
	tracker)
In-Reply-To: <47C10BF0.1080501@ronadam.com>
References: <47BFB1E6.1020700@gmail.com> <fpog0a$cta$1@ger.gmane.org>
	<47BFD1BF.8000703@v.loewis.de> <47C1074E.7060100@gmail.com>
	<47C10BF0.1080501@ronadam.com>
Message-ID: <bbaeab100802232315g6fe6e66ev372df4fdb7e300d9@mail.gmail.com>

On Sat, Feb 23, 2008 at 10:17 PM, Ron Adam <rrr at ronadam.com> wrote:
>
>
>  Nick Coghlan wrote:
>  > Martin v. L?wis wrote:
>  >> One issue to consider is also politeness. People sometimes complain that
>  >> they feel treated unfair if their report is declared "invalid" - they
>  >> surely believed it was a valid report, at the time they made it.
>  >
>  > I agree with Martin for both of these - 'works for me' and 'out of date'
>  > convey additional information to the originator of the bug, even if they
>  > don't make a signifcant difference from a development point of view.
>
>  The term 'works for me' can be confused with 'solution/patch works for me'.
>   I've generally seen the phrase 'works for me' to mean agreement of a
>  proposed action of some sort.
>
>  Maybe something along the lines of 'can not reproduce' would be better?

I have to agree with Ron. I honestly thought "works for me" meant the
solution worked. Something less ambiguous would be nice.

-Brett

From greg.ewing at canterbury.ac.nz  Sun Feb 24 08:35:51 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 24 Feb 2008 20:35:51 +1300
Subject: [Python-Dev] can't set attributes of built-in/extension type
In-Reply-To: <fpqfap$etu$1@ger.gmane.org>
References: <fpqfap$etu$1@ger.gmane.org>
Message-ID: <47C11E57.3040905@canterbury.ac.nz>

Neal Becker wrote:
> (Or, help me understand, what is the difference between a type that I create
> using python C api and a python class?)

Classes that you create in Python have a __dict__ attribute
holding a dictionary for arbitrary attributes to go in.

Most types defined in C don't bother providing a __dict__,
since one doesn't normally need to add arbitrary
attributes to them, and the overhead would be almost
completely wasted.

-- 
Greg

From steve at holdenweb.com  Sun Feb 24 14:32:49 2008
From: steve at holdenweb.com (Steve Holden)
Date: Sun, 24 Feb 2008 08:32:49 -0500
Subject: [Python-Dev] Proposed revision of PEP 3 (using the issue
	tracker)
In-Reply-To: <bbaeab100802232315g6fe6e66ev372df4fdb7e300d9@mail.gmail.com>
References: <47BFB1E6.1020700@gmail.com>
	<fpog0a$cta$1@ger.gmane.org>	<47BFD1BF.8000703@v.loewis.de>
	<47C1074E.7060100@gmail.com>	<47C10BF0.1080501@ronadam.com>
	<bbaeab100802232315g6fe6e66ev372df4fdb7e300d9@mail.gmail.com>
Message-ID: <47C17201.3040701@holdenweb.com>

Brett Cannon wrote:
> On Sat, Feb 23, 2008 at 10:17 PM, Ron Adam <rrr at ronadam.com> wrote:
>>
>>  Nick Coghlan wrote:
>>  > Martin v. L?wis wrote:
>>  >> One issue to consider is also politeness. People sometimes complain that
>>  >> they feel treated unfair if their report is declared "invalid" - they
>>  >> surely believed it was a valid report, at the time they made it.
>>  >
>>  > I agree with Martin for both of these - 'works for me' and 'out of date'
>>  > convey additional information to the originator of the bug, even if they
>>  > don't make a signifcant difference from a development point of view.
>>
>>  The term 'works for me' can be confused with 'solution/patch works for me'.
>>   I've generally seen the phrase 'works for me' to mean agreement of a
>>  proposed action of some sort.
>>
>>  Maybe something along the lines of 'can not reproduce' would be better?
> 
> I have to agree with Ron. I honestly thought "works for me" meant the
> solution worked. Something less ambiguous would be nice.
> 
+1 for "cannot reproduce".

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From lists at cheimes.de  Sun Feb 24 14:45:29 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 24 Feb 2008 14:45:29 +0100
Subject: [Python-Dev] Proposed revision of PEP 3 (using the issue
	tracker)
In-Reply-To: <47C17201.3040701@holdenweb.com>
References: <47BFB1E6.1020700@gmail.com>	<fpog0a$cta$1@ger.gmane.org>	<47BFD1BF.8000703@v.loewis.de>	<47C1074E.7060100@gmail.com>	<47C10BF0.1080501@ronadam.com>	<bbaeab100802232315g6fe6e66ev372df4fdb7e300d9@mail.gmail.com>
	<47C17201.3040701@holdenweb.com>
Message-ID: <fprsdp$s99$1@ger.gmane.org>

Steve Holden wrote:
> +1 for "cannot reproduce".

"cannot reproduce" is ambiguous in a slightly different, more family
oriented manner ... :]

Christian


From steve at shrogers.com  Sun Feb 24 14:44:32 2008
From: steve at shrogers.com (Steven H. Rogers)
Date: Sun, 24 Feb 2008 06:44:32 -0700
Subject: [Python-Dev] Proposed revision of PEP 3 (using the
	issue	tracker)
In-Reply-To: <47C10BF0.1080501@ronadam.com>
References: <47BFB1E6.1020700@gmail.com>	<fpog0a$cta$1@ger.gmane.org>	<47BFD1BF.8000703@v.loewis.de>	<47C1074E.7060100@gmail.com>
	<47C10BF0.1080501@ronadam.com>
Message-ID: <47C174C0.5060804@shrogers.com>

Ron Adam wrote:
> Nick Coghlan wrote:
>   
>> Martin v. L?wis wrote:
>>     
>>> One issue to consider is also politeness. People sometimes complain that
>>> they feel treated unfair if their report is declared "invalid" - they
>>> surely believed it was a valid report, at the time they made it.
>>>       
>> I agree with Martin for both of these - 'works for me' and 'out of date' 
>> convey additional information to the originator of the bug, even if they 
>> don't make a signifcant difference from a development point of view.
>>     
>
> The term 'works for me' can be confused with 'solution/patch works for me'. 
>   I've generally seen the phrase 'works for me' to mean agreement of a 
> proposed action of some sort.
>
> Maybe something along the lines of 'can not reproduce' would be better?
>
>   
+1 for 'can not reproduce' or perhaps 'can not duplicate'

# Steve


From lists at cheimes.de  Sun Feb 24 15:19:02 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 24 Feb 2008 15:19:02 +0100
Subject: [Python-Dev] Python 2.6 and 3.0
In-Reply-To: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
Message-ID: <47C17CD6.1040707@cheimes.de>

Barry Warsaw wrote:
> I'd also like for us to consider doing regular monthly releases.
> Several other FLOSS projects I'm involved with are doing this to very
> good success.  The nice thing is that everyone knows well in advance
> when the next release is going to happen, and so all developers and
> users know what to expect and what is needed from them.
> 
> I'd like to propose that we do a joint release the last Friday of
> every month.  For the alphas, it's basically what's in svn.  This
> gives us some time to experiment with the process out and see if we
> like it enough to keep it going through the betas and final releases.

Thanks for volunteering for the job, Barry!

+1 for release early, release often but I want to point out a resource
issue that may speak against a monthly release cycle. The Windows
binaries still require a large amount of attention and human
interaction. The last Windows binaries were build by me and I spent half
the night ironing out issues and testing the installers. As far as I
know the team only Martin and I have the infrastructure and tools to
build the Windows binaries.

We could cut down the time requirements by shipping only normal binaries
instead of PGO (profile guided optimization) binaries. IMHO we could
also skip the AMD64 builds until we have reached beta stage. But it's
still going to cost either Martin or me the better half of a Friday night.

I won't have time to assist with the Windows builds next Friday. I'm
more than busy with personal life and job interviews. Hopefully I'm
going to find a job that allows me to work on the Python core as much as
during the past few months.


That's for the Windows builds. Now I have a list of bugs and features I
like to see fixed / applied before the next release:

http://bugs.python.org/issue1692335 Fix exception pickling: Move initial
args assignment to BaseException.__new__

http://bugs.python.org/issue1792 (trivial performance patch for marshal)

http://bugs.python.org/issue1569 MS VCRT redist issue. IIRC Martin had a
working solution for it in his sandbox.

http://bugs.python.org/issue1657 my kqueue and epoll patch, just needs
another review

Christian

From ndbecker2 at gmail.com  Sun Feb 24 15:49:48 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 24 Feb 2008 09:49:48 -0500
Subject: [Python-Dev] can't set attributes of built-in/extension type
References: <fpqfap$etu$1@ger.gmane.org>
	<ca471dc20802231704m5b035c5ela258fd85d8687e3e@mail.gmail.com>
Message-ID: <fps06d$7nc$1@ger.gmane.org>

Guido van Rossum wrote:

> On Sat, Feb 23, 2008 at 4:55 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
>> There is some discussion on this subject, archived here:
>>  http://permalink.gmane.org/gmane.comp.python.general/560661
>>
>>  I wonder if anyone could shed some light on this subject?
>>
>>  (Or, help me understand, what is the difference between a type that I
>>  create using python C api and a python class?)
> 
> This is prohibited intentionally to prevent accidental fatal changes
> to built-in types (fatal to parts of the code that you never though
> of). Also, it is done to prevent the changes to affect different
> interpreters residing in the address space, since built-in types
> (unlike user-defined classes) are shared between all such
> interpreters.
> 

Thanks for the info.

I'm still curious.  What if I wanted to create a 'real' python class using
python c-api?  How is that done?


From guido at python.org  Sun Feb 24 18:11:25 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 24 Feb 2008 09:11:25 -0800
Subject: [Python-Dev] can't set attributes of built-in/extension type
In-Reply-To: <fps06d$7nc$1@ger.gmane.org>
References: <fpqfap$etu$1@ger.gmane.org>
	<ca471dc20802231704m5b035c5ela258fd85d8687e3e@mail.gmail.com>
	<fps06d$7nc$1@ger.gmane.org>
Message-ID: <ca471dc20802240911k7dfdc4bnbd72c85213bea334@mail.gmail.com>

On Sun, Feb 24, 2008 at 6:49 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
>
> Guido van Rossum wrote:
>
>  > On Sat, Feb 23, 2008 at 4:55 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
>  >> There is some discussion on this subject, archived here:
>  >>  http://permalink.gmane.org/gmane.comp.python.general/560661
>  >>
>  >>  I wonder if anyone could shed some light on this subject?
>  >>
>  >>  (Or, help me understand, what is the difference between a type that I
>  >>  create using python C api and a python class?)
>  >
>  > This is prohibited intentionally to prevent accidental fatal changes
>  > to built-in types (fatal to parts of the code that you never though
>  > of). Also, it is done to prevent the changes to affect different
>  > interpreters residing in the address space, since built-in types
>  > (unlike user-defined classes) are shared between all such
>  > interpreters.
>  >
>
>  Thanks for the info.
>
>  I'm still curious.  What if I wanted to create a 'real' python class using
>  python c-api?  How is that done?

Use PyObject_Call() or one of its friends to call PyType_Type with the
appropriate arguments (a name, a tuple of base classes, and a dict of
methods etc.). This is the same as calling type(name, bases,
namespace) from Python. The type object will be on the heap and fully
mutable.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From barry at python.org  Sun Feb 24 18:51:24 2008
From: barry at python.org (Barry Warsaw)
Date: Sun, 24 Feb 2008 12:51:24 -0500
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
Message-ID: <6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 22, 2008, at 6:54 PM, Brett Cannon wrote:

>> Hi everyone,
>>
>> I've volunteered to be the release manager for Python 2.6 and 3.0.
>> It's been several years since I've RM'd a Python release, and I'm
>> happy to do it again (he says while the medication is still
>> working :).
>
> Can the PSF buy you more of the meds? =)

Depends on the jurisdiction. :)

>> I would like to get the next alpha releases of both
>> versions out before Pycon, so I propose next Friday, February 29 for
>> both.
>>
>
> Since they are just alphas, sure. Not like I am going to make any
> earth-shattering changes that soon.

Cool.

>> Guido reminded me that we released Python 1.6 and 2.0 together and it
>> makes sense to both of us to do the same for Python 2.6 and 3.0.  I
>> don't think it will be that much more work (for me at least :) to
>> release them in lockstep, so I think we should try it.  I won't try  
>> to
>> sync their pre-release version numbers except at the milestones (e.g.
>> first beta, release candidates, final releases).
>>
>> I propose to change PEP 361 to outline the release schedule for both
>> Python 2.6 and 3.0.  I'm hoping we can work out a more definite
>> schedule at Pycon, but for now I want to at least describe the
>> lockstep release schedule and the Feb 29 date.
>>
>> I'd also like for us to consider doing regular monthly releases.
>> Several other FLOSS projects I'm involved with are doing this to very
>> good success.  The nice thing is that everyone knows well in advance
>> when the next release is going to happen, and so all developers and
>> users know what to expect and what is needed from them.
>>
>> I'd like to propose that we do a joint release the last Friday of
>> every month.  For the alphas, it's basically what's in svn.  This
>> gives us some time to experiment with the process out and see if we
>> like it enough to keep it going through the betas and final releases.
>>
>> Comments?
>
> If you want to do monthly alphas, go for it! But if you are going to
> do that frequently is a source release going to make more sense than
> doing binary builds?

It very well might.  See Christian Heimes's follow up re: Windows  
builds.  OTOH, I'm okay if at least for the alphas, the binary builds  
lag behind the source releases, though I'd like to get the process as  
streamlined as possible.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8GunXEjvBPtnXfVAQIP0AQAo5F2tH1vXWbMAFGARZN576xopbQXSokX
uVNXbeg5yjopCx38sHb5OCbublyIDOO8/2ubuuQ6uvAOJc3Br4BuMGHoC5ymQGqf
6pZYZLf4YUGLqFlYOB/huXpJPfH98RJJnK99zA8IQh4B7pN4xg14MF22gGij3Ybt
z2hoy1EbYEk=
=hW7b
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Sun Feb 24 19:57:41 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 24 Feb 2008 19:57:41 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
Message-ID: <47C1BE25.9050300@v.loewis.de>

> It very well might.  See Christian Heimes's follow up re: Windows  
> builds.  OTOH, I'm okay if at least for the alphas, the binary builds  
> lag behind the source releases, though I'd like to get the process as  
> streamlined as possible.

I can continue to provide Windows binaries if desired.

Regards,
Martin

From asmodai at in-nomine.org  Sun Feb 24 21:16:13 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Sun, 24 Feb 2008 21:16:13 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C1BE25.9050300@v.loewis.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>
Message-ID: <20080224201613.GL66273@nexus.in-nomine.org>

-On [20080224 19:57], "Martin v. L?wis" (martin at v.loewis.de) wrote:
>I can continue to provide Windows binaries if desired.

If need be, I can help testing the build infrastructure since I have access
to various releases of Visual Studio as well.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
What's in a name? That which we call a rose by any other name would
smell as sweet...

From collinw at gmail.com  Sun Feb 24 23:30:46 2008
From: collinw at gmail.com (Collin Winter)
Date: Sun, 24 Feb 2008 14:30:46 -0800
Subject: [Python-Dev] future_builtins (was: Backporting PEP 3127 to
	trunk)
In-Reply-To: <ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>
References: <47BDFA81.8000805@trueblade.com>
	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>
	<47BF22D6.9030600@trueblade.com> <fpou6q$dd7$1@ger.gmane.org>
	<47C0286C.2040103@trueblade.com>
	<ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>
Message-ID: <43aa6ff70802241430hf87c7a3r38f397feabd6d890@mail.gmail.com>

On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <guido at python.org> wrote:
> I don't think a -3 warning for oct or hex would do any good.
>
>  I do think map() and filter() should issue a warning under -3 when the
>  first arg is None. (Or does 2to3 detect this now?)

2to3 does detect that: it will turn map(None, foo) into list(foo).

>  On Sat, Feb 23, 2008 at 6:06 AM, Eric Smith
>  <eric+python-dev at trueblade.com> wrote:
>  > Georg Brandl wrote:
>  >  > Eric Smith schrieb:
>  >  >> Guido van Rossum wrote:
>  >  >>> I wonder if, in order to change the behavior of various built-in
>  >  >>> functions, it wouldn't be easier to be able to write
>  >  >>>
>  >  >>> from future_builtins import oct, hex  # and who knows what else
>  >  >> This makes sense to me, especially if we have a 2to3 fixer which removes
>  >  >> this line.  I'll work on implementing future_builtins.
>  >  >
>  >  > Will the future map and filter also belong there (and if they are imported
>  >  > from future_builtins, 2to3 won't put a list() around them)?
>  >
>  >  I can certainly do the mechanics of adding the new versions of map and
>  >  filter to future_builtins, if it's seen as desirable.
>  >
>  >  Maybe we could have 2to3 not put list() around map and filter, if
>  >  there's been an import of future_builtins.  I realize that there are
>  >  pathological cases where 2to3 doesn't know that a usage of map or filter
>  >  would really be the generator version from future_builtins, as opposed
>  >  to the actual list-producing builtins.  But would it be good enough to
>  >  take an import of future_builtins as a hint that the author was aware
>  >  that 2to3 wasn't going to change map and filter?
>  >
>  >  Still an open issue in my mind is adding a -3 warning to oct and hex,
>  >  and now conceivably map and filter.  Would that be going too far?
>  >
>  >  Eric.
>  >  _______________________________________________
>  >  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/collinw%40gmail.com
>

From collinw at gmail.com  Sun Feb 24 23:35:01 2008
From: collinw at gmail.com (Collin Winter)
Date: Sun, 24 Feb 2008 14:35:01 -0800
Subject: [Python-Dev] Use Python 3.0 syntax for except and raise?
In-Reply-To: <ca471dc20802181544l545cab19vf355344a74d093b9@mail.gmail.com>
References: <fp9p2p$ivb$1@ger.gmane.org>
	<ca471dc20802181544l545cab19vf355344a74d093b9@mail.gmail.com>
Message-ID: <43aa6ff70802241435lb1f9372r788be40bfceb7add@mail.gmail.com>

On Mon, Feb 18, 2008 at 3:44 PM, Guido van Rossum <guido at python.org> wrote:
> I don't know if you're done with this already, but there's a lot of
>  experience suggesting such sweeps are quite dangerous. In the past,
>  whenever a sweep across the entire stdlib was done, it's always caused
>  a few breakages, some of which didn't get caught until the next
>  release.
>
>  Things to worry about with these two changes:
>
>  raise X, y -> raise X(y): this is incorrect if y is a tuple; *only* if
>  it's a tuple, the correct translation is raise X(*y). But 2to3 can't
>  know that (unless the tuple is written out in place).

Yep. That's something I'd eventually like to correct by adding an
interactive mode (if 2to3 is unsure about a given fix, it can ask the
user). It's on my todo list for PyCon.

Collin Winter

>  except X as y: in 3.0 this has different semantics -- y is explicitly
>  deleted at the end of the except block. I don't know if this is also
>  the semantics implemented in 2.6 (I think it should be), but again
>  this can cause som equite subtle breakages that are hard to catch
>  automatically.
>
>  And since both of these are about exceptions, there's a high
>  likelihood that some occurrences are not reached by a unittest.
>
>  IOW, while I'm not dead set against it (I agree with your motivation
>  in principle) I worry that in practice it may destabilize things., and
>  would prefer a different approach where these things are only changed
>  when someone is revising the module anyway.
>
>  --Guido
>
>
>  On Feb 17, 2008 8:57 AM, Christian Heimes <lists at cheimes.de> wrote:
>
>
> > Good evening everybody!
>  >
>  > I like to run the 2to3 tool with raise and except fixers over the 2.6
>  > sources. The raise fixer changes "raise Exception, msg" to "raise
>  > Exception(msg)" and the except fixer replaces "except Exception, err" by
>  > "except Exception as err". In my humble opinion the Python stdlib should
>  > give proper examples how write good code.
>  >
>  > During the migration period from the 2.x series to 3.x we have two
>  > obvious ways to write code. Let's stick to the new and preferred way.
>  >
>  > Oh and please use the new syntax for patches, too. It makes my job with
>  > svnmerge a little bit easier.
>  >
>  > Thanks!
>  >
>  > Christian
>  >
>  > _______________________________________________
>  > 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/collinw%40gmail.com
>

From mhammond at skippinet.com.au  Sun Feb 24 23:58:56 2008
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 25 Feb 2008 09:58:56 +1100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <20080224201613.GL66273@nexus.in-nomine.org>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>	<47C1BE25.9050300@v.loewis.de>
	<20080224201613.GL66273@nexus.in-nomine.org>
Message-ID: <01a101c87738$da592b90$8f0b82b0$@com.au>

Jeroen Ruigrok van der Werven:
> -On [20080224 19:57], "Martin v. Lwis" (martin at v.loewis.de) wrote:
> >I can continue to provide Windows binaries if desired.
> 
> If need be, I can help testing the build infrastructure since I have
> access
> to various releases of Visual Studio as well.

Me too - I still regularly build the svn version of Python, and although I don't regularly turn them into .MSI files, I'm confident I could learn how to do that ;)  I understand that over time the binary process will need some tweaking, but in the general case, I expect that turning the crank for a test build needn't be that much or a burden. I expect the biggest problem is that I could no longer ignore certain extensions I don't care about, such as Tk.

Cheers,

Mark


From fuzzyman at voidspace.org.uk  Mon Feb 25 00:23:00 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 24 Feb 2008 23:23:00 +0000
Subject: [Python-Dev] Downloads Page
Message-ID: <47C1FC54.20900@voidspace.org.uk>

Hello all,

The downloads page on python.org shows 2.5.1 as the latest release:

http://python.org/download/

Michael

From skip at pobox.com  Mon Feb 25 02:26:41 2008
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 24 Feb 2008 19:26:41 -0600
Subject: [Python-Dev] Downloads Page
In-Reply-To: <47C1FC54.20900@voidspace.org.uk>
References: <47C1FC54.20900@voidspace.org.uk>
Message-ID: <18370.6481.829725.506571@montanaro-dyndns-org.local>


    Michael> The downloads page on python.org shows 2.5.1 as the latest
    Michael> release:

    Michael> http://python.org/download/

Thanks.  I just checked in a change.  I'm not sure how long it takes to
update the website, but it should be fairly soon.

Skip

From nnorwitz at gmail.com  Mon Feb 25 03:27:40 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sun, 24 Feb 2008 18:27:40 -0800
Subject: [Python-Dev] optimizing out local variables
Message-ID: <ee2a432c0802241827p7c9e2e30m70cea5ad65d4f9ff@mail.gmail.com>

Short description (see http://bugs.python.org/issue2181 for the patch
and more details):

Optimize code like:
   x = any_expression
   return x

to:
   return any_expression

The local variable x is no longer set before returning.  Is this
appropriate for .pyc generation or should it only be done for .pyo
files?

n

From tjreedy at udel.edu  Mon Feb 25 03:46:46 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 24 Feb 2008 21:46:46 -0500
Subject: [Python-Dev] Proposed revision of PEP 3 (usingthe	issue	tracker)
References: <47BFB1E6.1020700@gmail.com>
	<fpog0a$cta$1@ger.gmane.org><47BFD1BF.8000703@v.loewis.de>
	<47C1074E.7060100@gmail.com>
Message-ID: <fpta6i$3u6$1@ger.gmane.org>


"Nick Coghlan" <ncoghlan at gmail.com> wrote in message 
news:47C1074E.7060100 at gmail.com...
|Martin v. L?wis wrote:
|> One issue to consider is also politeness. People sometimes complain that
|> they feel treated unfair if their report is declared "invalid" - they
|> surely believed it was a valid report, at the time they made it.

|I agree with Martin for both of these - 'works for me' and 'out of date'
|convey additional information to the originator of the bug, even if they
|don't make a signifcant difference from a development point of view.

It seems to me that the place to convey real information to the originator 
is in the closing comment -- as the PEP requires. "Works for me' can hardly 
work if we cannot agree on the meaning.  And why is its usage restricted to 
'developers' as opposes to 'reviewers' like me?

In any case, I have a more radical proposal:  drop the disposition field 
altogether and split the 'closed' status into two.  First, closed because 
we have completed a non-empty set of actions (changes); in other words, 
'finished'.  Second, closed because we decide not to do anything; in other 
words, 'rejected'.

This proposal eliminates altogether the impoliteness of 'invalid'. 
'Invalid' is an possibly debateble opinion (even though backed by facts) 
about the originators issue.  'Rejected' is a non-debateble and truthful 
statement of a decision to not act.

This proposal also eliminates the the redundancy between a non-empty 
disposition and the 'closed' status implied by such.  It is not uncommon 
for people to mark a disposition and explain the reason for closure while 
leaving the status as 'open'.  Or to close and explain and leave the 
disposition blank.

Terry Jan Reedy




From amk at amk.ca  Mon Feb 25 03:52:01 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Sun, 24 Feb 2008 21:52:01 -0500
Subject: [Python-Dev] February bug day outcome
Message-ID: <20080225025201.GA5852@amk.local>

Yesterday's bug day was another success, closing 48 issues.  Several
committers were there: Facundo Bastista, Georg Brandl, and Christian
Heimes.  Facundo organized a local group of participants, and we
committed a number of contributions from new people.

Should we have one next month?  The PyCon sprint will fall on Monday
through Thursday, and few people not at PyCon will be available during
the work week.  OTOH, if we scheduled a bug day for the 29th, that's
two weeks after the conference, and we may have recovered from our
PyCon burnout at that point.  What do people think?

--amk




From brett at python.org  Mon Feb 25 03:53:51 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 24 Feb 2008 18:53:51 -0800
Subject: [Python-Dev] optimizing out local variables
In-Reply-To: <ee2a432c0802241827p7c9e2e30m70cea5ad65d4f9ff@mail.gmail.com>
References: <ee2a432c0802241827p7c9e2e30m70cea5ad65d4f9ff@mail.gmail.com>
Message-ID: <bbaeab100802241853i6496de6cg65641da5728c0304@mail.gmail.com>

On Sun, Feb 24, 2008 at 6:27 PM, Neal Norwitz <nnorwitz at gmail.com> wrote:
> Short description (see http://bugs.python.org/issue2181 for the patch
>  and more details):
>
>  Optimize code like:
>    x = any_expression
>    return x
>
>  to:
>    return any_expression
>
>  The local variable x is no longer set before returning.  Is this
>  appropriate for .pyc generation or should it only be done for .pyo
>  files?

I don't see how this is any more aggressive than what the peepholer
already does, so I see no issue with it being used in .pyc files.

-Brett

From guido at python.org  Mon Feb 25 03:54:03 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 24 Feb 2008 18:54:03 -0800
Subject: [Python-Dev] optimizing out local variables
In-Reply-To: <ee2a432c0802241827p7c9e2e30m70cea5ad65d4f9ff@mail.gmail.com>
References: <ee2a432c0802241827p7c9e2e30m70cea5ad65d4f9ff@mail.gmail.com>
Message-ID: <ca471dc20802241854r5566596aw84e93f6d8d5c70c4@mail.gmail.com>

Let's only do it for -O; the optimization may interfere with debugging the code.

On Sun, Feb 24, 2008 at 6:27 PM, Neal Norwitz <nnorwitz at gmail.com> wrote:
> Short description (see http://bugs.python.org/issue2181 for the patch
>  and more details):
>
>  Optimize code like:
>    x = any_expression
>    return x
>
>  to:
>    return any_expression
>
>  The local variable x is no longer set before returning.  Is this
>  appropriate for .pyc generation or should it only be done for .pyo
>  files?
>
>  n
>  _______________________________________________
>  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  Mon Feb 25 03:57:14 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 24 Feb 2008 18:57:14 -0800
Subject: [Python-Dev] future_builtins (was: Backporting PEP 3127 to
	trunk)
In-Reply-To: <ee2a432c0802231759r4a7c70ebm7e020c89f1fdf37b@mail.gmail.com>
References: <47BDFA81.8000805@trueblade.com>
	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>
	<47BF22D6.9030600@trueblade.com> <fpou6q$dd7$1@ger.gmane.org>
	<47C0286C.2040103@trueblade.com>
	<ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>
	<ee2a432c0802231759r4a7c70ebm7e020c89f1fdf37b@mail.gmail.com>
Message-ID: <ca471dc20802241857v21852101wc2c7ae68b3cb406e@mail.gmail.com>

On Sat, Feb 23, 2008 at 5:59 PM, Neal Norwitz <nnorwitz at gmail.com> wrote:
> On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <guido at python.org> wrote:
>  >
>  >  I do think map() and filter() should issue a warning under -3 when the
>  >  first arg is None. (Or does 2to3 detect this now?)
>
>  What's wrong with filter(None, seq)?  That currently works in 3k:
>
>  >>> filter(None, range(5))
>  <itertools.ifilter object at 0x2b5be60da450>
>  >>> [x for x in _]
>  [1, 2, 3, 4]

But that's a bug -- it's been spec'ed that this will stop working.
(Can't remember where, perhaps PEP 3100?)

>  (Side note, shouldn't we change the names for filter/map?)

Huh? What? Why?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From nnorwitz at gmail.com  Mon Feb 25 04:02:21 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sun, 24 Feb 2008 19:02:21 -0800
Subject: [Python-Dev] future_builtins (was: Backporting PEP 3127 to
	trunk)
In-Reply-To: <ca471dc20802241857v21852101wc2c7ae68b3cb406e@mail.gmail.com>
References: <47BDFA81.8000805@trueblade.com>
	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>
	<47BF22D6.9030600@trueblade.com> <fpou6q$dd7$1@ger.gmane.org>
	<47C0286C.2040103@trueblade.com>
	<ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>
	<ee2a432c0802231759r4a7c70ebm7e020c89f1fdf37b@mail.gmail.com>
	<ca471dc20802241857v21852101wc2c7ae68b3cb406e@mail.gmail.com>
Message-ID: <ee2a432c0802241902w52610c25qc91e7ea85984f942@mail.gmail.com>

On Sun, Feb 24, 2008 at 6:57 PM, Guido van Rossum <guido at python.org> wrote:
> On Sat, Feb 23, 2008 at 5:59 PM, Neal Norwitz <nnorwitz at gmail.com> wrote:
>  > On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <guido at python.org> wrote:
>  >  >
>  >  >  I do think map() and filter() should issue a warning under -3 when the
>  >  >  first arg is None. (Or does 2to3 detect this now?)
>  >
>  >  What's wrong with filter(None, seq)?  That currently works in 3k:
>  >
>  >  >>> filter(None, range(5))
>  >  <itertools.ifilter object at 0x2b5be60da450>
>  >  >>> [x for x in _]
>  >  [1, 2, 3, 4]
>
>  But that's a bug -- it's been spec'ed that this will stop working.
>  (Can't remember where, perhaps PEP 3100?)

I looked in 3100 and didn't see it.

>  >  (Side note, shouldn't we change the names for filter/map?)
>
>  Huh? What? Why?

The function name returned by repr: itertools.ifilter.

n

From nnorwitz at gmail.com  Mon Feb 25 04:06:42 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sun, 24 Feb 2008 19:06:42 -0800
Subject: [Python-Dev] February bug day outcome
In-Reply-To: <20080225025201.GA5852@amk.local>
References: <20080225025201.GA5852@amk.local>
Message-ID: <ee2a432c0802241906v5bb72ae1k6fe6d31026a0d088@mail.gmail.com>

On Sun, Feb 24, 2008 at 6:52 PM, A.M. Kuchling <amk at amk.ca> wrote:
> Yesterday's bug day was another success, closing 48 issues.  Several
>  committers were there: Facundo Bastista, Georg Brandl, and Christian
>  Heimes.  Facundo organized a local group of participants, and we
>  committed a number of contributions from new people.
>
>  Should we have one next month?  The PyCon sprint will fall on Monday
>  through Thursday, and few people not at PyCon will be available during
>  the work week.  OTOH, if we scheduled a bug day for the 29th, that's
>  two weeks after the conference, and we may have recovered from our
>  PyCon burnout at that point.  What do people think?

I'd rather push it out to mid-month assuming Barry starts releasing
alphas at the end of each month.  That should provide some time to
stabalize.  Any one see the buildbots recently? :-(
http://www.python.org/dev/buildbot/all/

n

From guido at python.org  Mon Feb 25 05:01:56 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 24 Feb 2008 20:01:56 -0800
Subject: [Python-Dev] future_builtins (was: Backporting PEP 3127 to
	trunk)
In-Reply-To: <ee2a432c0802241902w52610c25qc91e7ea85984f942@mail.gmail.com>
References: <47BDFA81.8000805@trueblade.com>
	<ca471dc20802211431t633eacc0h54c1735b9c252b5b@mail.gmail.com>
	<47BF22D6.9030600@trueblade.com> <fpou6q$dd7$1@ger.gmane.org>
	<47C0286C.2040103@trueblade.com>
	<ca471dc20802230806o58a1fa6dy1d968f32fd63def7@mail.gmail.com>
	<ee2a432c0802231759r4a7c70ebm7e020c89f1fdf37b@mail.gmail.com>
	<ca471dc20802241857v21852101wc2c7ae68b3cb406e@mail.gmail.com>
	<ee2a432c0802241902w52610c25qc91e7ea85984f942@mail.gmail.com>
Message-ID: <ca471dc20802242001q73d24c65vf0dbddc18f32bd56@mail.gmail.com>

On Sun, Feb 24, 2008 at 7:02 PM, Neal Norwitz <nnorwitz at gmail.com> wrote:
> On Sun, Feb 24, 2008 at 6:57 PM, Guido van Rossum <guido at python.org> wrote:
>  > On Sat, Feb 23, 2008 at 5:59 PM, Neal Norwitz <nnorwitz at gmail.com> wrote:
>  >  > On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <guido at python.org> wrote:
>  >  >  >
>  >  >  >  I do think map() and filter() should issue a warning under -3 when the
>  >  >  >  first arg is None. (Or does 2to3 detect this now?)
>  >  >
>  >  >  What's wrong with filter(None, seq)?  That currently works in 3k:
>  >  >
>  >  >  >>> filter(None, range(5))
>  >  >  <itertools.ifilter object at 0x2b5be60da450>
>  >  >  >>> [x for x in _]
>  >  >  [1, 2, 3, 4]
>  >
>  >  But that's a bug -- it's been spec'ed that this will stop working.
>  >  (Can't remember where, perhaps PEP 3100?)
>
>  I looked in 3100 and didn't see it.

Hm. Well, it's still the plan.

>  >  >  (Side note, shouldn't we change the names for filter/map?)
>  >
>  >  Huh? What? Why?
>
>  The function name returned by repr: itertools.ifilter.

I see. Yes, that's a bug. You could say that the way map and filter
are implemented in py3k at the moment is a prototype.

I'll file bugs for both of these.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From greg at krypto.org  Mon Feb 25 05:39:53 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Sun, 24 Feb 2008 20:39:53 -0800
Subject: [Python-Dev] optimizing out local variables
In-Reply-To: <ca471dc20802241854r5566596aw84e93f6d8d5c70c4@mail.gmail.com>
References: <ee2a432c0802241827p7c9e2e30m70cea5ad65d4f9ff@mail.gmail.com>
	<ca471dc20802241854r5566596aw84e93f6d8d5c70c4@mail.gmail.com>
Message-ID: <52dc1c820802242039g4135740dxb4fe3b34de094c09@mail.gmail.com>

On 2/24/08, Guido van Rossum <guido at python.org> wrote:
>
> Let's only do it for -O; the optimization may interfere with debugging the
> code.


Does anyone ever actually bother to use -O?

On Sun, Feb 24, 2008 at 6:27 PM, Neal Norwitz <nnorwitz at gmail.com> wrote:
>
> > Short description (see http://bugs.python.org/issue2181 for the patch
> >  and more details):
> >
> >  Optimize code like:
> >    x = any_expression
> >    return x
> >
> >  to:
> >    return any_expression
> >
> >  The local variable x is no longer set before returning.  Is this
> >  appropriate for .pyc generation or should it only be done for .pyo
> >  files?
> >
> >  n
> >  _______________________________________________
> >  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/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080224/d9ceb721/attachment.htm 

From facundobatista at gmail.com  Mon Feb 25 13:09:57 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Mon, 25 Feb 2008 10:09:57 -0200
Subject: [Python-Dev] February bug day outcome
In-Reply-To: <20080225025201.GA5852@amk.local>
References: <20080225025201.GA5852@amk.local>
Message-ID: <e04bdf310802250409m7e77a186oc0d7bde4a3c98e1d@mail.gmail.com>

2008/2/25, A.M. Kuchling <amk at amk.ca>:

>  Should we have one next month?  The PyCon sprint will fall on Monday
>  through Thursday, and few people not at PyCon will be available during
>  the work week.  OTOH, if we scheduled a bug day for the 29th, that's
>  two weeks after the conference, and we may have recovered from our
>  PyCon burnout at that point.  What do people think?

I'd try to avoid that weekend and the next one, because of PyWeek:

  http://www.pyweek.org/6/

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From facundobatista at gmail.com  Mon Feb 25 13:23:36 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Mon, 25 Feb 2008 10:23:36 -0200
Subject: [Python-Dev] Buildbots for trunk are all red
Message-ID: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>

All fail in test_compiler.py.

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From lists at cheimes.de  Mon Feb 25 14:16:14 2008
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 25 Feb 2008 14:16:14 +0100
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
Message-ID: <fpuf2u$6se$1@ger.gmane.org>

Facundo Batista wrote:
> All fail in test_compiler.py.

Thomas Herve has worked out a patch: http://bugs.python.org/issue2177

Christian


From lists at cheimes.de  Mon Feb 25 15:48:29 2008
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 25 Feb 2008 15:48:29 +0100
Subject: [Python-Dev] optimizing out local variables
In-Reply-To: <52dc1c820802242039g4135740dxb4fe3b34de094c09@mail.gmail.com>
References: <ee2a432c0802241827p7c9e2e30m70cea5ad65d4f9ff@mail.gmail.com>	<ca471dc20802241854r5566596aw84e93f6d8d5c70c4@mail.gmail.com>
	<52dc1c820802242039g4135740dxb4fe3b34de094c09@mail.gmail.com>
Message-ID: <47C2D53D.6010701@cheimes.de>

Gregory P. Smith wrote:
> On 2/24/08, Guido van Rossum <guido at python.org> wrote:
>> Let's only do it for -O; the optimization may interfere with debugging the
>> code.
> 
> 
> Does anyone ever actually bother to use -O?

People may start bothering to use -O when it's giving them a speedup for
real. How does -O affect Python code nowadays? IIRC it set __debug__ to
false and removes asserts from the byte code.

Christian

From lists at cheimes.de  Mon Feb 25 16:01:21 2008
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 25 Feb 2008 16:01:21 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <01a101c87738$da592b90$8f0b82b0$@com.au>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>	<47C1BE25.9050300@v.loewis.de>	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
Message-ID: <47C2D841.2030501@cheimes.de>

Mark Hammond wrote:
> Me too - I still regularly build the svn version of Python, and although I don't regularly turn them into .MSI files, I'm confident I could learn how to do that ;)  I understand that over time the binary process will need some tweaking, but in the general case, I expect that turning the crank for a test build needn't be that much or a burden. I expect the biggest problem is that I could no longer ignore certain extensions I don't care about, such as Tk.

It's not too hard. Tkinter, bsddb and friends are explained in
PCbuild/README.txt. You should be able to compile them in less than half
an hour.

For the MSI installers you also need Python 2.5, your pywin32 package
and some additional tools like the help compiler and cabarc.exe.

Martin:
Have you solved the problem with the VS CRT redist
(http://bugs.python.org/issue1569)? Maybe Mark is able to assist you.

Christian

From asmodai at in-nomine.org  Mon Feb 25 16:44:43 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Mon, 25 Feb 2008 16:44:43 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C2D841.2030501@cheimes.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>
	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
	<47C2D841.2030501@cheimes.de>
Message-ID: <20080225154443.GP66273@nexus.in-nomine.org>

-On [20080225 16:02], Christian Heimes (lists at cheimes.de) wrote:
>For the MSI installers you also need Python 2.5, your pywin32 package
>and some additional tools like the help compiler and cabarc.exe.

Have you looked at http://wix.sourceforge.net/ ?

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
What good will it be for a man if he gains the whole world, yet forfeits
his soul?

From lists at cheimes.de  Mon Feb 25 17:06:12 2008
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 25 Feb 2008 17:06:12 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <20080225154443.GP66273@nexus.in-nomine.org>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>
	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
	<47C2D841.2030501@cheimes.de>
	<20080225154443.GP66273@nexus.in-nomine.org>
Message-ID: <47C2E774.2040205@cheimes.de>

Jeroen Ruigrok van der Werven wrote:
> Have you looked at http://wix.sourceforge.net/ ?

WiX looks interesting but I'm neither in the position to change the
installer nor do I have a strong opinion. It's Martin's area of expertise.

On the one hand a XML based MSI generator could be easier to maintain.
On the other hand it would introduce another dependency to a 3rd party
tool and things may get complicated if we leave the road. Automation
tools tend to make common things really easy but special and uncommon
stuff really hard.

Christian

From amk at amk.ca  Mon Feb 25 18:06:55 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Mon, 25 Feb 2008 12:06:55 -0500
Subject: [Python-Dev] February bug day outcome
In-Reply-To: <ee2a432c0802241906v5bb72ae1k6fe6d31026a0d088@mail.gmail.com>
References: <20080225025201.GA5852@amk.local>
	<ee2a432c0802241906v5bb72ae1k6fe6d31026a0d088@mail.gmail.com>
Message-ID: <20080225170655.GA13127@amk-desktop.matrixgroup.net>

On Sun, Feb 24, 2008 at 07:06:42PM -0800, Neal Norwitz wrote:
> I'd rather push it out to mid-month assuming Barry starts releasing
> alphas at the end of each month.  That should provide some time to
> stabalize.  Any one see the buildbots recently? :-(
> http://www.python.org/dev/buildbot/all/

I've fixed a failure caused by test_curses.py.  The test_compiler
failure is due to the backporting of class decorators in rev. 60978;
compiler/ast.py is out of the date, and the rest of compiler/
doubtless needs updating to actually support class decorators.

--amk


From facundobatista at gmail.com  Mon Feb 25 19:09:59 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Mon, 25 Feb 2008 16:09:59 -0200
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <fpuf2u$6se$1@ger.gmane.org>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
Message-ID: <e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>

2008/2/25, Christian Heimes <lists at cheimes.de>:

> Thomas Herve has worked out a patch: http://bugs.python.org/issue2177

After reviewing, testing and etc, I commited it. Let's see the buildbots! :)

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From fuzzyman at voidspace.org.uk  Mon Feb 25 20:04:42 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 25 Feb 2008 19:04:42 +0000
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C2E774.2040205@cheimes.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>	<47C1BE25.9050300@v.loewis.de>	<20080224201613.GL66273@nexus.in-nomine.org>	<01a101c87738$da592b90$8f0b82b0$@com.au>	<47C2D841.2030501@cheimes.de>	<20080225154443.GP66273@nexus.in-nomine.org>
	<47C2E774.2040205@cheimes.de>
Message-ID: <47C3114A.9020100@voidspace.org.uk>

Christian Heimes wrote:
> Jeroen Ruigrok van der Werven wrote:
>   
>> Have you looked at http://wix.sourceforge.net/ ?
>>     
>
> WiX looks interesting but I'm neither in the position to change the
> installer nor do I have a strong opinion. It's Martin's area of expertise.
>
> On the one hand a XML based MSI generator could be easier to maintain.
> On the other hand it would introduce another dependency to a 3rd party
> tool and things may get complicated if we leave the road. Automation
> tools tend to make common things really easy but special and uncommon
> stuff really hard.
>   

We build all our installers at Resolver Systems using Wix - dynamically 
generating parts of the templates and doing all sorts of weird and 
wonderful stuff (creating shortcuts, setting registry entries, testing 
dependencies, conditional includes in the installers and so on).

Michael Foord


> Christian
> _______________________________________________
> 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 facundobatista at gmail.com  Mon Feb 25 21:03:31 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Mon, 25 Feb 2008 18:03:31 -0200
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
Message-ID: <e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>

2008/2/25, Facundo Batista <facundobatista at gmail.com>:

> 2008/2/25, Christian Heimes <lists at cheimes.de>:
>
>  > Thomas Herve has worked out a patch: http://bugs.python.org/issue2177
>
> After reviewing, testing and etc, I commited it. Let's see the buildbots! :)

Some are green, now, but others still are in red, failing in
test_shelve.py, because of errors like this:

======================================================================
ERROR: test_get (test.test_shelve.TestAsciiFileShelve)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/test/mapping_tests.py",
line 271, in test_get
    self.assert_(d.get(self.other.keys()[0]) is None)
  File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/shelve.py",
line 104, in get
    if key in self.dict:
TypeError: argument of type 'dbm.dbm' is not iterable

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From barry at python.org  Mon Feb 25 21:53:58 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 25 Feb 2008 15:53:58 -0500
Subject: [Python-Dev] February bug day outcome
In-Reply-To: <ee2a432c0802241906v5bb72ae1k6fe6d31026a0d088@mail.gmail.com>
References: <20080225025201.GA5852@amk.local>
	<ee2a432c0802241906v5bb72ae1k6fe6d31026a0d088@mail.gmail.com>
Message-ID: <45C4D68A-C36E-45E8-9ADC-9F0121AAB8B4@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 24, 2008, at 10:06 PM, Neal Norwitz wrote:

> On Sun, Feb 24, 2008 at 6:52 PM, A.M. Kuchling <amk at amk.ca> wrote:
>> Yesterday's bug day was another success, closing 48 issues.  Several
>> committers were there: Facundo Bastista, Georg Brandl, and Christian
>> Heimes.  Facundo organized a local group of participants, and we
>> committed a number of contributions from new people.
>>
>> Should we have one next month?  The PyCon sprint will fall on Monday
>> through Thursday, and few people not at PyCon will be available  
>> during
>> the work week.  OTOH, if we scheduled a bug day for the 29th, that's
>> two weeks after the conference, and we may have recovered from our
>> PyCon burnout at that point.  What do people think?
>
> I'd rather push it out to mid-month assuming Barry starts releasing
> alphas at the end of each month.  That should provide some time to
> stabalize.  Any one see the buildbots recently? :-(
> http://www.python.org/dev/buildbot/all/

That's a really good idea.  At least for the alpha's I would like to  
have a policy that the monthly release goes out unless

1) There are critical bugs open for 2.6 and/or 3.0
2) The important buildbots are red (maybe)

In either case, it should probably be a priority for bug day to repair  
those failures.

On #1, I don't think there's a way to get roundup to give me exactly  
that report, e.g. all critical open bugs on both 2.6 and 3.0.  Maybe  
I'm missing something, but given my intent, I'd find that useful.  I  
know I can get search for each Python version independently, so that's  
good enough for now.  Right now, I believe there are no critical bugs  
open on either version.

On #2, clearly we can't wait for greens across the board, so which  
platforms are important enough to hold up a monthly release?  I'd say  
something representative of the source release and each of the binary  
releases we make, so maybe:

2.6: source = x86 gentoo trunk, windows = x86 xp-4 trunk, mac = g4 osx. 
4 trunk
3.0: source = x86 gentoo 3.0, windows = x86 xp-4 3.0, mac g4 osx.4 3.0

Unfortunately, basing release status on buildbot health doesn't look  
very encouraging. :(

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8Mq53EjvBPtnXfVAQK9UwP/WFnuMNS3P93iO2z6sAMph9FXe733ErBW
6rey9i6EV1+P+iafzvA1V2d1tls166/JXmdz8VnGQI8ZmAWimzYgs4LsmKogeUCr
Ttrioc4ZKMT2EWPUwzEQatzcbdgG3gpt+imJHT+KrIgMvSLFmLJiwH36f/Jk/rKS
Bv6TYL1AO9g=
=AFix
-----END PGP SIGNATURE-----

From barry at python.org  Mon Feb 25 22:07:11 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 25 Feb 2008 16:07:11 -0500
Subject: [Python-Dev] Python 2.6 and 3.0
In-Reply-To: <47C17CD6.1040707@cheimes.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<47C17CD6.1040707@cheimes.de>
Message-ID: <8E45F999-6B4B-43A4-AD9A-54D2D1570732@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 24, 2008, at 9:19 AM, Christian Heimes wrote:

> Barry Warsaw wrote:
>> I'd also like for us to consider doing regular monthly releases.
>> Several other FLOSS projects I'm involved with are doing this to very
>> good success.  The nice thing is that everyone knows well in advance
>> when the next release is going to happen, and so all developers and
>> users know what to expect and what is needed from them.
>>
>> I'd like to propose that we do a joint release the last Friday of
>> every month.  For the alphas, it's basically what's in svn.  This
>> gives us some time to experiment with the process out and see if we
>> like it enough to keep it going through the betas and final releases.
>
> Thanks for volunteering for the job, Barry!
>
> +1 for release early, release often but I want to point out a resource
> issue that may speak against a monthly release cycle. The Windows
> binaries still require a large amount of attention and human
> interaction. The last Windows binaries were build by me and I spent  
> half
> the night ironing out issues and testing the installers. As far as I
> know the team only Martin and I have the infrastructure and tools to
> build the Windows binaries.

 From the follow ups, it sounds like others can pitch in here.  A  
question though: is it reasonable to hold up the monthly release  
because a binary build we're going to make available can't be done at  
the same time?

My preference (at least for the alphas) is "no".  If we can make a  
source release, and if we can build a binary release from exactly the  
same revision, then we should go ahead and release.  I'd rather get  
the alpha out there and in people's hands.

We'll almost certainly be stricter for the candidates, finals, and  
maybe betas.

> We could cut down the time requirements by shipping only normal  
> binaries
> instead of PGO (profile guided optimization) binaries. IMHO we could
> also skip the AMD64 builds until we have reached beta stage. But it's
> still going to cost either Martin or me the better half of a Friday  
> night.

Dang.  I actually don't know how long it's going to take me to do the  
source release, but I hope it's no more than 3 or 4 hours.

> I won't have time to assist with the Windows builds next Friday. I'm
> more than busy with personal life and job interviews. Hopefully I'm
> going to find a job that allows me to work on the Python core as  
> much as
> during the past few months.

When's the PSF gonna start hiring? :)

> That's for the Windows builds. Now I have a list of bugs and  
> features I
> like to see fixed / applied before the next release:
>
> http://bugs.python.org/issue1692335 Fix exception pickling: Move  
> initial
> args assignment to BaseException.__new__
>
> http://bugs.python.org/issue1792 (trivial performance patch for  
> marshal)
>
> http://bugs.python.org/issue1569 MS VCRT redist issue. IIRC Martin  
> had a
> working solution for it in his sandbox.
>
> http://bugs.python.org/issue1657 my kqueue and epoll patch, just needs
> another review

So, as I mentioned in my last reply, I'm planning to only allow  
critical bugs (as described in roundup) hold up the release.  Right  
now there are no critical bugs open.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8MuAHEjvBPtnXfVAQJ4JQP9F8AijArF8KhyxC7lp0ePDBGphgZjq7h8
9vZZ13oGOCtED/6M4bGDaZWrI1LEcj3iuf61Kdk6KwaeAi3dnGHkrP1XOTxZbLcz
8euKbC8JhBHan/A4SO4+xzxx4ZI9vCMRQqe+sLOQJsE9vH+4UMU1FDrhROxYwLbb
aG0+fzGPdzA=
=zpPQ
-----END PGP SIGNATURE-----

From barry at python.org  Mon Feb 25 22:07:25 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 25 Feb 2008 16:07:25 -0500
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C1BE25.9050300@v.loewis.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>
Message-ID: <4CE13670-0F86-444E-9F3F-B94AEA9B8295@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 24, 2008, at 1:57 PM, Martin v. L?wis wrote:

>> It very well might.  See Christian Heimes's follow up re: Windows   
>> builds.  OTOH, I'm okay if at least for the alphas, the binary  
>> builds  lag behind the source releases, though I'd like to get the  
>> process as  streamlined as possible.
>
> I can continue to provide Windows binaries if desired.

Great, thanks!
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8MuDXEjvBPtnXfVAQJeJwP/R8MMAhOsyRtpxIISEUoqMGDJksI5EtVM
PcsxNO1p0MGcHfm5lNg0YNYwxsfc/0ghkRbsidegvcyN6BZWgHSaA7I0O1cBTG1x
R4eNmLJBWCOcJNmTGgxCA7G8eEHTNTxneaQ0APO+yQbbHS/eyGGMcmFldNMkDqNO
ycqikt0XiWI=
=M3eC
-----END PGP SIGNATURE-----

From therve at free.fr  Mon Feb 25 22:03:41 2008
From: therve at free.fr (=?ISO-8859-1?Q?Thomas_Herv=E9?=)
Date: Mon, 25 Feb 2008 22:03:41 +0100
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>	<fpuf2u$6se$1@ger.gmane.org>	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
Message-ID: <47C32D2D.1030206@free.fr>

Facundo Batista a ?crit :
> 2008/2/25, Facundo Batista <facundobatista at gmail.com>:
>
>   
>> 2008/2/25, Christian Heimes <lists at cheimes.de>:
>>
>>  > Thomas Herve has worked out a patch: http://bugs.python.org/issue2177
>>
>> After reviewing, testing and etc, I commited it. Let's see the buildbots! :)
>>     
>
> Some are green, now, but others still are in red, failing in
> test_shelve.py, because of errors like this:
>
> ======================================================================
> ERROR: test_get (test.test_shelve.TestAsciiFileShelve)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/test/mapping_tests.py",
> line 271, in test_get
>     self.assert_(d.get(self.other.keys()[0]) is None)
>   File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/shelve.py",
> line 104, in get
>     if key in self.dict:
> TypeError: argument of type 'dbm.dbm' is not iterable
>   
Hello,

I've worked on that problem during the bug day. I've open a ticket with 
a patch at http://bugs.python.org/issue2168.

-- 
Thomas

From martin at v.loewis.de  Mon Feb 25 23:02:18 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 25 Feb 2008 23:02:18 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C2D841.2030501@cheimes.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>	<47C1BE25.9050300@v.loewis.de>	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
	<47C2D841.2030501@cheimes.de>
Message-ID: <47C33AEA.2010600@v.loewis.de>

> Have you solved the problem with the VS CRT redist
> (http://bugs.python.org/issue1569)? Maybe Mark is able to assist you.

No, I still haven't found a solution. I do want to use the merge
module; anything else probably isn't going to work.

Regards,
Martin

From martin at v.loewis.de  Mon Feb 25 23:02:36 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 25 Feb 2008 23:02:36 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <20080225154443.GP66273@nexus.in-nomine.org>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>
	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
	<47C2D841.2030501@cheimes.de>
	<20080225154443.GP66273@nexus.in-nomine.org>
Message-ID: <47C33AFC.8010307@v.loewis.de>

>> For the MSI installers you also need Python 2.5, your pywin32 package
>> and some additional tools like the help compiler and cabarc.exe.
> 
> Have you looked at http://wix.sourceforge.net/ ?

Yes.

Martin


From martin at v.loewis.de  Mon Feb 25 23:06:11 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 25 Feb 2008 23:06:11 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C2E774.2040205@cheimes.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>
	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
	<47C2D841.2030501@cheimes.de>
	<20080225154443.GP66273@nexus.in-nomine.org>
	<47C2E774.2040205@cheimes.de>
Message-ID: <47C33BD3.5040003@v.loewis.de>

> On the one hand a XML based MSI generator could be easier to maintain.

I've looked at it, and I seriously doubt that. In WiX, you need to
specify a fixed file list (perhaps with wildcards; I'm unsure). This
will be tricky for Python, where the list of files to be installed
changes all the time.

You *need* to have a turing-complete packing language (such as Python).

> On the other hand it would introduce another dependency to a 3rd party
> tool and things may get complicated if we leave the road. Automation
> tools tend to make common things really easy but special and uncommon
> stuff really hard.

Exactly so. When I started with MSI generation, and tried what comes
with Visual Studio, and found it unusable - it did not support Itanium,
and could not be changed to support it.

Regards,
Martin

From larry.bugbee at boeing.com  Mon Feb 25 23:20:42 2008
From: larry.bugbee at boeing.com (Bugbee, Larry)
Date: Mon, 25 Feb 2008 14:20:42 -0800
Subject: [Python-Dev] Python 2.6 and 3.0  ...and applink.c?
In-Reply-To: <mailman.5325.1203745263.9266.python-dev@python.org>
References: <mailman.5325.1203745263.9266.python-dev@python.org>
Message-ID: <9418DB6C0B9D434190E54A78E931C3D1036F8BDE@XCH-NW-7V1.nw.nos.boeing.com>

Hi Barry,

A question....  Do you know if OpenSSL's applink.c will be included in
the Windows builds?  If so, and I hope it is, great!  

If not, I'd like to encourage its inclusion.  Doing so will permit
Python to be used with OpenSSL 0.9.8x on Windows platforms without a
user trying to find somebody with the right compiler to rebuild a Python
for him/her.  This is needed for M2Crypto, or any other OpenSSL wrapper
for that matter.  A lot more can be said here, but in the interest of
brevity... ;-)  

applink.c is perhaps two dozen links and some error codes, and is benign
for those not calling these APIs.  applink.c may be found in
<openssl_source_dir>/ms and the one line include stmt that would be
added to <py-src>/Modules/python.c is:
    #include "<path_to>/applink.c"
That's it.

And the OpenSSL FAQ: http://www.openssl.org/support/faq.html#PROG2   

Tx, Larry



From barry at python.org  Mon Feb 25 23:45:27 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 25 Feb 2008 17:45:27 -0500
Subject: [Python-Dev] Python 2.6 and 3.0  ...and applink.c?
In-Reply-To: <9418DB6C0B9D434190E54A78E931C3D1036F8BDE@XCH-NW-7V1.nw.nos.boeing.com>
References: <mailman.5325.1203745263.9266.python-dev@python.org>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BDE@XCH-NW-7V1.nw.nos.boeing.com>
Message-ID: <A5F58BCE-9203-4C0C-9082-E453EC8A339A@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Larry,

On Feb 25, 2008, at 5:20 PM, Bugbee, Larry wrote:

> A question....  Do you know if OpenSSL's applink.c will be included in
> the Windows builds?  If so, and I hope it is, great!

Honestly, I have no idea!  I don't have any Windows machines so really  
have no way of testing this either.  Maybe one of the other Windows  
gurus on this list can answer the question.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8NFB3EjvBPtnXfVAQKZ1wP8Dv1aMdcbLM2NqpbWDdZLoeL7+91zVfTk
VvyQzm4JkTjQtSVs/2ngHPjoIW3fNp6frQAwaf3pWICdyMj1OUXe/dRdhNaOwb44
guv5kIHtJmty3BHLJWUlFEC0IheWLRJuJhu0dz95E8jc21hEES7wVxg8jAwPcLqV
3TbscCqD+UI=
=6qOy
-----END PGP SIGNATURE-----

From db3l.net at gmail.com  Mon Feb 25 23:50:36 2008
From: db3l.net at gmail.com (David Bolen)
Date: Mon, 25 Feb 2008 17:50:36 -0500
Subject: [Python-Dev] Python 2.6 and 3.0
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>
	<4CE13670-0F86-444E-9F3F-B94AEA9B8295@python.org>
Message-ID: <m2skzgr6pv.fsf@valheru.db3l.homeip.net>

Barry Warsaw <barry at python.org> writes:

> On Feb 24, 2008, at 1:57 PM, Martin v. L?wis wrote:
>
>>> It very well might.  See Christian Heimes's follow up re: Windows   
>>> builds.  OTOH, I'm okay if at least for the alphas, the binary  
>>> builds  lag behind the source releases, though I'd like to get the  
>>> process as  streamlined as possible.
>>
>> I can continue to provide Windows binaries if desired.
>
> Great, thanks!

Note that my buildbot is still also building MSIs each night based on
the svn head for 2.5, 2.6 and 3.0, and uploading them back to
python.org (viewable at http://www.python.org/dev/daily-msi).

So at least for an alpha based on the current SVN trunk, that might be
an easy place to grab a binary snapshot from, unless I'm missing
something.

Conversely, the machine is there to make builds upon request, I
presume, depending on the master configuration.  I know Martin set the
current scheme up.

-- David



From nnorwitz at gmail.com  Tue Feb 26 00:45:19 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Mon, 25 Feb 2008 15:45:19 -0800
Subject: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
In-Reply-To: <9418DB6C0B9D434190E54A78E931C3D1036F8BDE@XCH-NW-7V1.nw.nos.boeing.com>
References: <mailman.5325.1203745263.9266.python-dev@python.org>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BDE@XCH-NW-7V1.nw.nos.boeing.com>
Message-ID: <ee2a432c0802251545u42f46c4fhcba9112b8fc184ac@mail.gmail.com>

On Mon, Feb 25, 2008 at 2:20 PM, Bugbee, Larry <larry.bugbee at boeing.com> wrote:
> Hi Barry,
>
>  A question....  Do you know if OpenSSL's applink.c will be included in
>  the Windows builds?  If so, and I hope it is, great!
>
>  If not, I'd like to encourage its inclusion.

The best way to encourage its inclusion is with a patch. :-)

n

From nnorwitz at gmail.com  Tue Feb 26 06:04:55 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Mon, 25 Feb 2008 21:04:55 -0800
Subject: [Python-Dev] February bug day outcome
In-Reply-To: <45C4D68A-C36E-45E8-9ADC-9F0121AAB8B4@python.org>
References: <20080225025201.GA5852@amk.local>
	<ee2a432c0802241906v5bb72ae1k6fe6d31026a0d088@mail.gmail.com>
	<45C4D68A-C36E-45E8-9ADC-9F0121AAB8B4@python.org>
Message-ID: <ee2a432c0802252104g36b09364t16a4720d54f3a991@mail.gmail.com>

On Mon, Feb 25, 2008 at 12:53 PM, Barry Warsaw <barry at python.org> wrote:
>
>  That's a really good idea.  At least for the alpha's I would like to
>  have a policy that the monthly release goes out unless
>
>  1) There are critical bugs open for 2.6 and/or 3.0
>  2) The important buildbots are red (maybe)
>
>  In either case, it should probably be a priority for bug day to repair
>  those failures.
>
>  On #2, clearly we can't wait for greens across the board, so which
>  platforms are important enough to hold up a monthly release?  I'd say
>  something representative of the source release and each of the binary
>  releases we make, so maybe:
>
>  2.6: source = x86 gentoo trunk, windows = x86 xp-4 trunk, mac = g4 osx.
>  4 trunk
>  3.0: source = x86 gentoo 3.0, windows = x86 xp-4 3.0, mac g4 osx.4 3.0
>
>  Unfortunately, basing release status on buildbot health doesn't look
>  very encouraging. :(

It's been pretty bad the last month or so.  Although it's getting
better now.  I would recommend these are the golden bots based on what
have traditionally been fairly stable help expose errors:

  sparc solaris10
  amd64 gentoo (this is really an ubuntu 6.10 box)
  x86 gentoo (*)
  g4 os x (this one has svn problems from time to time which is odd
given that it is the only box colocated with the svn server)
  some win xp box (#4 wfm, i think that has been the most stable recently)
  ia64 ubuntu
  ppc debian (this may be ubuntu also)
  ppc64 debian (ditto)

The biggest challenge will be having svn work on all the machines.
The tests are getting more stable.  I worked on many of them.  There
are still issues from time to time, but at this point I think more are
caused by bad checkins.  Sometimes these machines go away, if they are
unavailable at time of release, so be it.

If we can get more people watching the buildbots and ping those
responsible for a failure, we can keep the red to a minimum.  If we
can fix the ~5 flaky tests, we will be in good shape.  If we can fix
the svn problems, we'll be in great shape.  Nearly all of the flaky
tests are due to networking problems.  Sometimes transient conditions
like the host is unavailable, others due to races.

(*) x86 gentoo should not be used for 3.0.  There is a problem with
signal 32 that causes it to rarely work.  I don't know the cause or
how to fix this.

n

From asmodai at in-nomine.org  Tue Feb 26 07:31:04 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Tue, 26 Feb 2008 07:31:04 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C33AEA.2010600@v.loewis.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>
	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
	<47C2D841.2030501@cheimes.de> <47C33AEA.2010600@v.loewis.de>
Message-ID: <20080226063104.GU66273@nexus.in-nomine.org>

-On [20080225 23:03], "Martin v. L?wis" (martin at v.loewis.de) wrote:
>No, I still haven't found a solution. I do want to use the merge
>module; anything else probably isn't going to work.

I updated the ticket with some links to how to approach this issue.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
To conquer fear is the beginning of wisdom...

From asmodai at in-nomine.org  Tue Feb 26 07:35:08 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Tue, 26 Feb 2008 07:35:08 +0100
Subject: [Python-Dev] February bug day outcome
In-Reply-To: <ee2a432c0802252104g36b09364t16a4720d54f3a991@mail.gmail.com>
References: <20080225025201.GA5852@amk.local>
	<ee2a432c0802241906v5bb72ae1k6fe6d31026a0d088@mail.gmail.com>
	<45C4D68A-C36E-45E8-9ADC-9F0121AAB8B4@python.org>
	<ee2a432c0802252104g36b09364t16a4720d54f3a991@mail.gmail.com>
Message-ID: <20080226063508.GV66273@nexus.in-nomine.org>

-On [20080226 06:05], Neal Norwitz (nnorwitz at gmail.com) wrote:
>  sparc solaris10
>  amd64 gentoo (this is really an ubuntu 6.10 box)
>  x86 gentoo (*)
>  g4 os x (this one has svn problems from time to time which is odd
>given that it is the only box colocated with the svn server)
>  some win xp box (#4 wfm, i think that has been the most stable recently)
>  ia64 ubuntu
>  ppc debian (this may be ubuntu also)
>  ppc64 debian (ditto)

Might make sense to add at least one BSD box to the mix, generally when 1
BSD build works it should be quite similar on the rest. The above is a bit
heavy on the Linux (glibc) side and will not really expose problems on that
front aside from the commercial Solaris and OS X.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
The spirit indeed is willing, but the flesh is weak...

From nnorwitz at gmail.com  Tue Feb 26 07:45:09 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Mon, 25 Feb 2008 22:45:09 -0800
Subject: [Python-Dev] February bug day outcome
In-Reply-To: <20080226063508.GV66273@nexus.in-nomine.org>
References: <20080225025201.GA5852@amk.local>
	<ee2a432c0802241906v5bb72ae1k6fe6d31026a0d088@mail.gmail.com>
	<45C4D68A-C36E-45E8-9ADC-9F0121AAB8B4@python.org>
	<ee2a432c0802252104g36b09364t16a4720d54f3a991@mail.gmail.com>
	<20080226063508.GV66273@nexus.in-nomine.org>
Message-ID: <ee2a432c0802252245h6c3e63bela7f219cabe7016de@mail.gmail.com>

On Mon, Feb 25, 2008 at 10:35 PM, Jeroen Ruigrok van der Werven
<asmodai at in-nomine.org> wrote:
> -On [20080226 06:05], Neal Norwitz (nnorwitz at gmail.com) wrote:
>  >  sparc solaris10
>  >  amd64 gentoo (this is really an ubuntu 6.10 box)
>  >  x86 gentoo (*)
>  >  g4 os x (this one has svn problems from time to time which is odd
>  >given that it is the only box colocated with the svn server)
>  >  some win xp box (#4 wfm, i think that has been the most stable recently)
>  >  ia64 ubuntu
>  >  ppc debian (this may be ubuntu also)
>  >  ppc64 debian (ditto)
>
>  Might make sense to add at least one BSD box to the mix, generally when 1
>  BSD build works it should be quite similar on the rest. The above is a bit
>  heavy on the Linux (glibc) side and will not really expose problems on that
>  front aside from the commercial Solaris and OS X.

I agree with the theory.  However, we have only a single BSD box
currently working and it has been flaky.  Primarily test_smtplib has
been failing sporadically on it.  For example:

test test_smtplib failed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Lib/test/test_smtplib.py",
line 375, in testBasic
    smtp = smtplib.SMTP(HOST, PORT, local_hostname='localhost', timeout=3)
  File "/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Lib/smtplib.py",
line 237, in __init__
    (code, msg) = self.connect(host, port)
  File "/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Lib/smtplib.py",
line 294, in connect
    (code, msg) = self.getreply()
  File "/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Lib/smtplib.py",
line 335, in getreply
    line = self.file.readline()
  File "/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Lib/socket.py",
line 369, in readline
    data = self._sock.recv(self._rbufsize)
timeout: timed out

Ugh.  I just looked at the test and see all the sleeps.  I'll speed
this test up by using events which will also hopefully reduce the
flakiness.  It currently takes 28 seconds.  That should be decreased
significantly.

n

From lists at cheimes.de  Tue Feb 26 00:50:19 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 26 Feb 2008 00:50:19 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C33AEA.2010600@v.loewis.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>	<47C1BE25.9050300@v.loewis.de>	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
	<47C2D841.2030501@cheimes.de> <47C33AEA.2010600@v.loewis.de>
Message-ID: <47C3543B.8060303@cheimes.de>

Martin v. L?wis wrote:
> No, I still haven't found a solution. I do want to use the merge
> module; anything else probably isn't going to work.

Da...ng
Didn't you prepare a new MSI installer for 3.0a2 that includes the VS
Redist MSM for X86? I vaguely remember that you've replaced my installer
with a new one.

The issue should be resolved before Python 2.6 and 3.0 are reaching beta
stage. Maybe we can get some help from outside?

Christian


From lists at cheimes.de  Tue Feb 26 00:58:32 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 26 Feb 2008 00:58:32 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C33BD3.5040003@v.loewis.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>
	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
	<47C2D841.2030501@cheimes.de>
	<20080225154443.GP66273@nexus.in-nomine.org>
	<47C2E774.2040205@cheimes.de> <47C33BD3.5040003@v.loewis.de>
Message-ID: <47C35628.6060200@cheimes.de>

Martin v. L?wis wrote:
> I've looked at it, and I seriously doubt that. In WiX, you need to
> specify a fixed file list (perhaps with wildcards; I'm unsure). This
> will be tricky for Python, where the list of files to be installed
> changes all the time.
>
> You *need* to have a turing-complete packing language (such as Python).

You are most likely right. A pure XML based solution ain't going to work
for Python. But how about a mixed solution?

    XML templates -> Python fu -> WiX XML -> MSI

We take some XML templates, modify them from Python and add the files.
Finalliy we let WiX create the MSI installer from the resulting XML file.

What do you think?

> Exactly so. When I started with MSI generation, and tried what comes
> with Visual Studio, and found it unusable - it did not support
> Itanium, and could not be changed to support it.

Yeah, been there, got frustrated, went back :/

Christian


From lists at cheimes.de  Tue Feb 26 01:11:26 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 26 Feb 2008 01:11:26 +0100
Subject: [Python-Dev] Python 2.6 and 3.0
In-Reply-To: <8E45F999-6B4B-43A4-AD9A-54D2D1570732@python.org>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<47C17CD6.1040707@cheimes.de>
	<8E45F999-6B4B-43A4-AD9A-54D2D1570732@python.org>
Message-ID: <47C3592E.2080704@cheimes.de>

Barry Warsaw wrote:
> From the follow ups, it sounds like others can pitch in here.  A
> question though: is it reasonable to hold up the monthly release because
> a binary build we're going to make available can't be done at the same
> time?
> 
> My preference (at least for the alphas) is "no".  If we can make a
> source release, and if we can build a binary release from exactly the
> same revision, then we should go ahead and release.  I'd rather get the
> alpha out there and in people's hands.
> 
> We'll almost certainly be stricter for the candidates, finals, and maybe
> betas.

I agree. It's not reasonable to hold of alphas because the Windows
binaries may be released a few days later. Do we need official Windows
binaries for alphas at all? Martin's buildbot creates nightly Windows
builds. We could point users to the nightly builds and ask them to test
the version.

> Dang.  I actually don't know how long it's going to take me to do the
> source release, but I hope it's no more than 3 or 4 hours.

I guess it's less than 2 hours. You can prepare most of the work like
the announcements a couple of days earlier. I (perhaps naively) assume
you have to smack the whip to get everything in place, do the svn cp to
tag, svn export, tar cz, tar xzf && ./configure && make && make test
dance and upload the tar.gz. Am I missing something important? :]

> When's the PSF gonna start hiring? :)

Dunno :) But I'm probably the last in a long line of Python core
developers to get hired. Don't forget I'm still fresh and a junior core
developer. *jk*

> So, as I mentioned in my last reply, I'm planning to only allow critical
> bugs (as described in roundup) hold up the release.  Right now there are
> no critical bugs open.

#1569 is critical but not important enough to stop an alpha. As I said
in the other mail it should be fixed for the first beta and must be
fixed for the first rc.

Christian


From asmodai at in-nomine.org  Tue Feb 26 09:07:12 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Tue, 26 Feb 2008 09:07:12 +0100
Subject: [Python-Dev] February bug day outcome
In-Reply-To: <ee2a432c0802252245h6c3e63bela7f219cabe7016de@mail.gmail.com>
References: <20080225025201.GA5852@amk.local>
	<ee2a432c0802241906v5bb72ae1k6fe6d31026a0d088@mail.gmail.com>
	<45C4D68A-C36E-45E8-9ADC-9F0121AAB8B4@python.org>
	<ee2a432c0802252104g36b09364t16a4720d54f3a991@mail.gmail.com>
	<20080226063508.GV66273@nexus.in-nomine.org>
	<ee2a432c0802252245h6c3e63bela7f219cabe7016de@mail.gmail.com>
Message-ID: <20080226080712.GW66273@nexus.in-nomine.org>

-On [20080226 08:09], Neal Norwitz (nnorwitz at gmail.com) wrote:
>I agree with the theory.  However, we have only a single BSD box
>currently working and it has been flaky.  Primarily test_smtplib has
>been failing sporadically on it.  For example:

What are the requirements for a build box? I have both a a 6.3-STABLE AMD
Athlon XP 2200+ and an FreeBSD 7-PRERELEASE (STABLE once released) amd64 box
I can let compile. The 6.3 box can do it (almost) continuously. I can
probably add an Intel Pentium 4 6.3-STABLE box as well.

I can probably get NetBSD build bots up as well, just need to ask some
people for appropriate access.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/
We shape clay into a pot, but it is the emptiness inside that holds
whatever we want...

From nnorwitz at gmail.com  Tue Feb 26 09:17:30 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Tue, 26 Feb 2008 00:17:30 -0800
Subject: [Python-Dev] February bug day outcome
In-Reply-To: <20080226080712.GW66273@nexus.in-nomine.org>
References: <20080225025201.GA5852@amk.local>
	<ee2a432c0802241906v5bb72ae1k6fe6d31026a0d088@mail.gmail.com>
	<45C4D68A-C36E-45E8-9ADC-9F0121AAB8B4@python.org>
	<ee2a432c0802252104g36b09364t16a4720d54f3a991@mail.gmail.com>
	<20080226063508.GV66273@nexus.in-nomine.org>
	<ee2a432c0802252245h6c3e63bela7f219cabe7016de@mail.gmail.com>
	<20080226080712.GW66273@nexus.in-nomine.org>
Message-ID: <ee2a432c0802260017m499910ap4e82918f60608969@mail.gmail.com>

On Tue, Feb 26, 2008 at 12:07 AM, Jeroen Ruigrok van der Werven
<asmodai at in-nomine.org> wrote:
> -On [20080226 08:09], Neal Norwitz (nnorwitz at gmail.com) wrote:
>  >I agree with the theory.  However, we have only a single BSD box
>  >currently working and it has been flaky.  Primarily test_smtplib has
>  >been failing sporadically on it.  For example:
>
>  What are the requirements for a build box? I have both a a 6.3-STABLE AMD

No requirements in particular.  See http://wiki.python.org/moin/BuildBot
Pretty much it should have good network connectivity and someone we
can contact who can administer the box.  For example, in the past we
have had to have ports opened up so the tests can pass.  Possibly we
might want to get different version of libraries installed to test
with (e.g., berkeley db v 4.x).

>  Athlon XP 2200+ and an FreeBSD 7-PRERELEASE (STABLE once released) amd64 box
>  I can let compile. The 6.3 box can do it (almost) continuously. I can
>  probably add an Intel Pentium 4 6.3-STABLE box as well.

These boxes are fine and faster than half the current machines.

>  I can probably get NetBSD build bots up as well, just need to ask some
>  people for appropriate access.

It would be best if we get configurations we don't already have.  We
have no NetBSD boxes.  We have one FreeBSD (6.2 supposedly), although
it's 32-bit.

n

From mhammond at skippinet.com.au  Tue Feb 26 10:09:06 2008
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 26 Feb 2008 20:09:06 +1100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C35628.6060200@cheimes.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>
	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
	<47C2D841.2030501@cheimes.de>
	<20080225154443.GP66273@nexus.in-nomine.org>
	<47C2E774.2040205@cheimes.de> <47C33BD3.5040003@v.loewis.de>
	<47C35628.6060200@cheimes.de>
Message-ID: <02cf01c87857$4d19bf40$e74d3dc0$@com.au>

> Martin v. L?wis wrote:
> > I've looked at it, and I seriously doubt that. In WiX, you need to
> > specify a fixed file list (perhaps with wildcards; I'm unsure). This
> > will be tricky for Python, where the list of files to be installed
> > changes all the time.
> >
> > You *need* to have a turing-complete packing language (such as
> Python).
> 
> You are most likely right. A pure XML based solution ain't going to
> work
> for Python. But how about a mixed solution?
> 
>     XML templates -> Python fu -> WiX XML -> MSI
> 
> We take some XML templates, modify them from Python and add the files.
> Finalliy we let WiX create the MSI installer from the resulting XML
> file.
> 
> What do you think?

I'm inclined to agree with Martin that WiX doesn't offer us much value (it
offers value in many places though - just not for our requirements given
Martin's msilib).  I believe that once we know how to solve a particular
problem, it would not be significantly easier to implement using WiX than it
would using the current infrastructure.  My problem is still getting my head
around various MSI issues at any level (eg, bdist_msi needs some tweaking to
allow for different releases of the same "package" to be recognized as such,
but I'm not sure what MSI concept I'm dealing with yet...)

WiX is an excellent inspiration though - if a WiX example can be found for
something, it should be a significant help in implementing it via msilib.

Cheers,

Mark



From lists at cheimes.de  Tue Feb 26 10:24:59 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 26 Feb 2008 10:24:59 +0100
Subject: [Python-Dev] Python 2.6 and 3.0  ...and applink.c?
In-Reply-To: <9418DB6C0B9D434190E54A78E931C3D1036F8BDE@XCH-NW-7V1.nw.nos.boeing.com>
References: <mailman.5325.1203745263.9266.python-dev@python.org>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BDE@XCH-NW-7V1.nw.nos.boeing.com>
Message-ID: <47C3DAEB.1050102@cheimes.de>

Bugbee, Larry wrote:
> Hi Barry,
> 
> A question....  Do you know if OpenSSL's applink.c will be included in
> the Windows builds?  If so, and I hope it is, great!  
> 
> If not, I'd like to encourage its inclusion.  Doing so will permit
> Python to be used with OpenSSL 0.9.8x on Windows platforms without a
> user trying to find somebody with the right compiler to rebuild a Python
> for him/her.  This is needed for M2Crypto, or any other OpenSSL wrapper
> for that matter.  A lot more can be said here, but in the interest of
> brevity... ;-)  

I don't understand how applink is going to help you. The SSL libs are
statically linked into the _ssl extension DLL.

Christian

From facundobatista at gmail.com  Tue Feb 26 12:22:29 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Tue, 26 Feb 2008 09:22:29 -0200
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <47C32D2D.1030206@free.fr>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
Message-ID: <e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>

2008/2/25, Thomas Herv? <therve at free.fr>:

>  I've worked on that problem during the bug day. I've open a ticket with
>  a patch at http://bugs.python.org/issue2168.

Most of the buildbots are green now!!!

Thank you all! This community is as awesome as Python itself, ;)

Three remains in red, though:

- Alpha Tru64: test_smtplib.py is flaky, and _ssl.c is not compiled
correctly. Neil is hunting this, I think.

- X86 XP-3: seems to crash after test_bsddb3.py.

- X86 XP-4: idem. For this two, how can be tried if the bsddb lib in
those windows is correctly installed?

Thanks again.

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From barry at python.org  Tue Feb 26 13:28:20 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 26 Feb 2008 07:28:20 -0500
Subject: [Python-Dev] Python 2.6 and 3.0
In-Reply-To: <47C3592E.2080704@cheimes.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<47C17CD6.1040707@cheimes.de>
	<8E45F999-6B4B-43A4-AD9A-54D2D1570732@python.org>
	<47C3592E.2080704@cheimes.de>
Message-ID: <7DC2E52B-1F40-4DFB-9680-5410DD9E854E@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 25, 2008, at 7:11 PM, Christian Heimes wrote:

> Barry Warsaw wrote:
>> From the follow ups, it sounds like others can pitch in here.  A
>> question though: is it reasonable to hold up the monthly release  
>> because
>> a binary build we're going to make available can't be done at the  
>> same
>> time?
>>
>> My preference (at least for the alphas) is "no".  If we can make a
>> source release, and if we can build a binary release from exactly the
>> same revision, then we should go ahead and release.  I'd rather get  
>> the
>> alpha out there and in people's hands.
>>
>> We'll almost certainly be stricter for the candidates, finals, and  
>> maybe
>> betas.
>
> I agree. It's not reasonable to hold of alphas because the Windows
> binaries may be released a few days later. Do we need official Windows
> binaries for alphas at all? Martin's buildbot creates nightly Windows
> builds. We could point users to the nightly builds and ask them to  
> test
> the version.

That would be find with me.  Where are those Windows binaries  
available for download from?

>> Dang.  I actually don't know how long it's going to take me to do the
>> source release, but I hope it's no more than 3 or 4 hours.
>
> I guess it's less than 2 hours. You can prepare most of the work like
> the announcements a couple of days earlier. I (perhaps naively) assume
> you have to smack the whip to get everything in place, do the svn cp  
> to
> tag, svn export, tar cz, tar xzf && ./configure && make && make test
> dance and upload the tar.gz. Am I missing something important? :]

Dunno yet!  It's been years since I did a release and I really want to  
check out Anthony's welease tool this time.  I may not have time  
before Friday to look at this though.

>> When's the PSF gonna start hiring? :)
>
> Dunno :) But I'm probably the last in a long line of Python core
> developers to get hired. Don't forget I'm still fresh and a junior  
> core
> developer. *jk*

:)

>> So, as I mentioned in my last reply, I'm planning to only allow  
>> critical
>> bugs (as described in roundup) hold up the release.  Right now  
>> there are
>> no critical bugs open.
>
> #1569 is critical but not important enough to stop an alpha. As I said
> in the other mail it should be fixed for the first beta and must be
> fixed for the first rc.

It's not marked critical in roundup, and that's the only thing I'm  
going by!  But it doesn't seem critical in the sense that it should  
hold up the alpha release, IMO.

Cheers,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8QF5nEjvBPtnXfVAQJhrgP/Xz3IQrlCB9QPGsMGIL+xG3I5t+aThNg6
4n/bMjt4DRzTCRiNBjUllyCb5+VtPfTZu2wFVdi5I7NLMDG4WI4jfDGZlhvodbHW
TPG/7bN/ykx9yE1hUPI5X+Kqrg0lG7Tbp9Zev5eHJCMwParSVu+hfWqD48+1bQqw
JGfzz8AlqE0=
=PQgE
-----END PGP SIGNATURE-----

From barry at python.org  Tue Feb 26 14:56:09 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 26 Feb 2008 08:56:09 -0500
Subject: [Python-Dev] Buildbot health (was Re:  February bug day outcome)
In-Reply-To: <ee2a432c0802252104g36b09364t16a4720d54f3a991@mail.gmail.com>
References: <20080225025201.GA5852@amk.local>
	<ee2a432c0802241906v5bb72ae1k6fe6d31026a0d088@mail.gmail.com>
	<45C4D68A-C36E-45E8-9ADC-9F0121AAB8B4@python.org>
	<ee2a432c0802252104g36b09364t16a4720d54f3a991@mail.gmail.com>
Message-ID: <03233D15-5DBF-4976-9C91-6E188A41B76B@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 26, 2008, at 12:04 AM, Neal Norwitz wrote:
>
> It's been pretty bad the last month or so.  Although it's getting
> better now.  I would recommend these are the golden bots based on what
> have traditionally been fairly stable help expose errors:
>
>  sparc solaris10
>  amd64 gentoo (this is really an ubuntu 6.10 box)
>  x86 gentoo (*)
>  g4 os x (this one has svn problems from time to time which is odd
> given that it is the only box colocated with the svn server)
>  some win xp box (#4 wfm, i think that has been the most stable  
> recently)
>  ia64 ubuntu
>  ppc debian (this may be ubuntu also)
>  ppc64 debian (ditto)

Cool, thanks for this list.

> The biggest challenge will be having svn work on all the machines.
> The tests are getting more stable.  I worked on many of them.  There
> are still issues from time to time, but at this point I think more are
> caused by bad checkins.  Sometimes these machines go away, if they are
> unavailable at time of release, so be it.
>
> If we can get more people watching the buildbots and ping those
> responsible for a failure, we can keep the red to a minimum.  If we
> can fix the ~5 flaky tests, we will be in good shape.  If we can fix
> the svn problems, we'll be in great shape.  Nearly all of the flaky
> tests are due to networking problems.  Sometimes transient conditions
> like the host is unavailable, others due to races.
>
> (*) x86 gentoo should not be used for 3.0.  There is a problem with
> signal 32 that causes it to rarely work.  I don't know the cause or
> how to fix this.

All of the 3.0 buildbots are currently red.  Both test_cProfile and  
test_profile fail consistently for me on x86 Ubuntu Gutsy and Intel OS  
X 10.5.2.  It looks like the buildbots are failing here too -- does  
anybody have time to fix these two tests?

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8QaeXEjvBPtnXfVAQITQQQAlcjymy7ZV9y6cq4bFNM9/55CBj35ahOz
M9S31WkxJgisk6q3ebS1NzQIAp7V1FeS14TZD0TYwYEAgDxQHQ/xJeB9RB63feNX
DaJUa6zTPFY7lBvaOWJ8SMp5yvlwnbzykbh52tsKiikCUqFCjU6IC/p7ieebqadF
UJxbVZ9nTdM=
=Py4H
-----END PGP SIGNATURE-----

From spotter at cs.columbia.edu  Sun Feb 24 19:02:44 2008
From: spotter at cs.columbia.edu (Shaya Potter)
Date: Sun, 24 Feb 2008 13:02:44 -0500
Subject: [Python-Dev] getpass and stdin
Message-ID: <47C1B144.4020701@cs.columbia.edu>

[please cc me on responses]

I was wondering if getpass could be changed to enable piped stdin to work.

For instance, the getmail program can read my email password in via 
stdin using getpass functionality.

However, if I do

echo password | getmail4

it will fail due to stdin not being a terminal and therefore not being 
able to do a old = termios.tcgetattr(fd) on it.

 From what I can tell, the point of this is to only to prevent echoing 
the password, which isn't a problem in the echo case I give (especially 
if using bash, then it wont even be on the cmdline when run from a 
script as it's a builtin, script can also read in the password and store 
it in memory).

currently the code is

-----
def unix_getpass(prompt='Password: '):
     """Prompt for a password, with echo turned off.

     Restore terminal settings at end.
     """

     try:
         fd = sys.stdin.fileno()
     except:
         return default_getpass(prompt)

     old = termios.tcgetattr(fd)     # a copy to save
     new = old[:]

     new[3] = new[3] & ~termios.ECHO # 3 == 'lflags'
     try:
         termios.tcsetattr(fd, termios.TCSADRAIN, new)
         passwd = _raw_input(prompt)
     finally:
         termios.tcsetattr(fd, termios.TCSADRAIN, old)

     sys.stdout.write('\n')
     return passwd
-----

it would seem that if the tcgetattr() line is moved into the initial 
try, my echo case would work as expected (as it would fail, but be 
caught and then just run default_getpass() (which should just read it 
from stdin).

Is there any reason not to do it this way?

From christian at cheimes.de  Tue Feb 26 15:13:54 2008
From: christian at cheimes.de (Christian Heimes)
Date: Tue, 26 Feb 2008 15:13:54 +0100
Subject: [Python-Dev] Python 2.6 and 3.0
In-Reply-To: <7DC2E52B-1F40-4DFB-9680-5410DD9E854E@python.org>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<47C17CD6.1040707@cheimes.de>
	<8E45F999-6B4B-43A4-AD9A-54D2D1570732@python.org>
	<47C3592E.2080704@cheimes.de>
	<7DC2E52B-1F40-4DFB-9680-5410DD9E854E@python.org>
Message-ID: <47C41EA2.4070508@cheimes.de>

Barry Warsaw wrote:
> That would be find with me.  Where are those Windows binaries available
> for download from?

The Windows builds are hidden in the development section. It took me 10
minutes to find them because I was searching in the download section and
for nightly builds. The *daily* builds are available at
http://www.python.org/dev/daily-msi/

Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/python-dev/attachments/20080226/e9756b6b/attachment.pgp 

From larry.bugbee at boeing.com  Tue Feb 26 18:09:00 2008
From: larry.bugbee at boeing.com (Bugbee, Larry)
Date: Tue, 26 Feb 2008 09:09:00 -0800
Subject: [Python-Dev] Python 2.6 and 3.0  ...and applink.c?
In-Reply-To: <9418DB6C0B9D434190E54A78E931C3D1036F8BE7@XCH-NW-7V1.nw.nos.boeing.com>
References: <47C3DAEB.1050102@cheimes.de>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BE7@XCH-NW-7V1.nw.nos.boeing.com>
Message-ID: <9418DB6C0B9D434190E54A78E931C3D1036F8BE8@XCH-NW-7V1.nw.nos.boeing.com>

> I don't understand how applink is going to help you. The SSL libs are
statically linked > into the _ssl extension DLL.

I personally have not used _ssl but on quick inspection I don't see any
of the crypto algorithms implemented, AES, ECDSA, etc.  What if we want
to encrypt or sign content using OpenSSL?  We'd import M2Crypto but when
we go to load the key we'll get an OPENSSL_Applink error.  Likewise for
OpenSSL with xmlsec. 

Larry

PS: This problem applies to vanilla builds of Python on Windows only
when Microsoft tools and libraries are used to build Python.  It does
not apply to cygwin or mingw where gcc is used.  Likewise, it does not
apply to other platforms, only Windows.

From adlaiff6 at gmail.com  Tue Feb 26 18:17:32 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Tue, 26 Feb 2008 12:17:32 -0500
Subject: [Python-Dev] getpass and stdin
In-Reply-To: <47C1B144.4020701@cs.columbia.edu>
References: <47C1B144.4020701@cs.columbia.edu>
Message-ID: <cc7430500802260917p67d54c6by4e9fd911e1dc5a3e@mail.gmail.com>

On Sun, Feb 24, 2008 at 1:02 PM, Shaya Potter <spotter at cs.columbia.edu> wrote:
> [please cc me on responses]
>
>  I was wondering if getpass could be changed to enable piped stdin to work.
>
>  For instance, the getmail program can read my email password in via
>  stdin using getpass functionality.
>
>  However, if I do
>
>  echo password | getmail4
>
>  it will fail due to stdin not being a terminal and therefore not being
>  able to do a old = termios.tcgetattr(fd) on it.
>
>   From what I can tell, the point of this is to only to prevent echoing
>  the password, which isn't a problem in the echo case I give (especially
>  if using bash, then it wont even be on the cmdline when run from a
>  script as it's a builtin, script can also read in the password and store
>  it in memory).
>
>  currently the code is
>
>  -----
>  def unix_getpass(prompt='Password: '):
>      """Prompt for a password, with echo turned off.
>
>      Restore terminal settings at end.
>      """
>
>      try:
>          fd = sys.stdin.fileno()
>      except:
>          return default_getpass(prompt)
>
>      old = termios.tcgetattr(fd)     # a copy to save
>      new = old[:]
>
>      new[3] = new[3] & ~termios.ECHO # 3 == 'lflags'
>      try:
>          termios.tcsetattr(fd, termios.TCSADRAIN, new)
>          passwd = _raw_input(prompt)
>      finally:
>          termios.tcsetattr(fd, termios.TCSADRAIN, old)
>
>      sys.stdout.write('\n')
>      return passwd
>  -----
>
>  it would seem that if the tcgetattr() line is moved into the initial
>  try, my echo case would work as expected (as it would fail, but be
>  caught and then just run default_getpass() (which should just read it
>  from stdin).
>
>  Is there any reason not to do it this way?

It's certainly possible to have getpass() read from stdin
automatically, but it's traditionally understood that having it read
from a tty is much, much better.  Suppose your program were meant to
use getpass, and then read a file from stdin.  Now, all of a sudden,
you miss the first line of the file, and it becomes your password, for
no particular reason.  getpass() works the way it does because it's
been working that way in C for decades.

If you really want to maintain a 'configuration file' for your
password, or have it available on command line, try adding an option
like -p <PASSWD> or -p <PASSFILE> to whatever program you're writing.

-- 
Cheers,
Leif

From spotter at cs.columbia.edu  Tue Feb 26 18:43:59 2008
From: spotter at cs.columbia.edu (Shaya Potter)
Date: Tue, 26 Feb 2008 12:43:59 -0500
Subject: [Python-Dev] getpass and stdin
In-Reply-To: <cc7430500802260917p67d54c6by4e9fd911e1dc5a3e@mail.gmail.com>
References: <47C1B144.4020701@cs.columbia.edu>
	<cc7430500802260917p67d54c6by4e9fd911e1dc5a3e@mail.gmail.com>
Message-ID: <47C44FDF.2050704@cs.columbia.edu>

Leif Walsh wrote:
> On Sun, Feb 24, 2008 at 1:02 PM, Shaya Potter <spotter at cs.columbia.edu> wrote:
>> [please cc me on responses]
>>
>>  I was wondering if getpass could be changed to enable piped stdin to work.
>>
>>  For instance, the getmail program can read my email password in via
>>  stdin using getpass functionality.
>>
>>  However, if I do
>>
>>  echo password | getmail4
>>
>>  it will fail due to stdin not being a terminal and therefore not being
>>  able to do a old = termios.tcgetattr(fd) on it.
>>
>>   From what I can tell, the point of this is to only to prevent echoing
>>  the password, which isn't a problem in the echo case I give (especially
>>  if using bash, then it wont even be on the cmdline when run from a
>>  script as it's a builtin, script can also read in the password and store
>>  it in memory).
>>
>>  currently the code is
>>
>>  -----
>>  def unix_getpass(prompt='Password: '):
>>      """Prompt for a password, with echo turned off.
>>
>>      Restore terminal settings at end.
>>      """
>>
>>      try:
>>          fd = sys.stdin.fileno()
>>      except:
>>          return default_getpass(prompt)
>>
>>      old = termios.tcgetattr(fd)     # a copy to save
>>      new = old[:]
>>
>>      new[3] = new[3] & ~termios.ECHO # 3 == 'lflags'
>>      try:
>>          termios.tcsetattr(fd, termios.TCSADRAIN, new)
>>          passwd = _raw_input(prompt)
>>      finally:
>>          termios.tcsetattr(fd, termios.TCSADRAIN, old)
>>
>>      sys.stdout.write('\n')
>>      return passwd
>>  -----
>>
>>  it would seem that if the tcgetattr() line is moved into the initial
>>  try, my echo case would work as expected (as it would fail, but be
>>  caught and then just run default_getpass() (which should just read it
>>  from stdin).
>>
>>  Is there any reason not to do it this way?
> 
> It's certainly possible to have getpass() read from stdin
> automatically, but it's traditionally understood that having it read
> from a tty is much, much better.  Suppose your program were meant to
> use getpass, and then read a file from stdin.  Now, all of a sudden,
> you miss the first line of the file, and it becomes your password, for
> no particular reason.  getpass() works the way it does because it's
> been working that way in C for decades.
> 
> If you really want to maintain a 'configuration file' for your
> password, or have it available on command line, try adding an option
> like -p <PASSWD> or -p <PASSFILE> to whatever program you're writing.

the -p <PASSWD> option is not good on multi user systems
the -p <PASSFILE> option is not particularly good on NFS based systems 
(have to trust every user on every machine with access to NFS share)

and now, assuming what you say is part of the design behind the code

what's the point of this part of the code

 >>      try:
 >>          fd = sys.stdin.fileno()
 >>      except:
 >>          return default_getpass(prompt)
 >>

i.e. the exception handler, default_getpass() is always going to read 
from stdin at the end of the day.

     line = sys.stdin.readline()

I'm assuming I'm missing something

From janssen at parc.com  Tue Feb 26 19:12:07 2008
From: janssen at parc.com (Bill Janssen)
Date: Tue, 26 Feb 2008 10:12:07 PST
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com> 
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
Message-ID: <08Feb26.101217pst."58696"@synergy1.parc.xerox.com>

> - Alpha Tru64: test_smtplib.py is flaky, and _ssl.c is not compiled
> correctly. Neil is hunting this, I think.

Last time we looked at the _ssl problem, the machine had an
out-of-date installation of OpenSSL.  Don't know if that ever got
rectified; I just crossed that buildbot off my list :-).

Bill

From adlaiff6 at gmail.com  Tue Feb 26 19:13:14 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Tue, 26 Feb 2008 13:13:14 -0500
Subject: [Python-Dev] getpass and stdin
In-Reply-To: <47C44FDF.2050704@cs.columbia.edu>
References: <47C1B144.4020701@cs.columbia.edu>
	<cc7430500802260917p67d54c6by4e9fd911e1dc5a3e@mail.gmail.com>
	<47C44FDF.2050704@cs.columbia.edu>
Message-ID: <cc7430500802261013o76c0f7d7s22c355645568383a@mail.gmail.com>

On Tue, Feb 26, 2008 at 12:43 PM, Shaya Potter <spotter at cs.columbia.edu> wrote:
>  the -p <PASSWD> option is not good on multi user systems
>  the -p <PASSFILE> option is not particularly good on NFS based systems
>  (have to trust every user on every machine with access to NFS share)

You seem somehow both worried about security, yet too lazy to type in
your password.  I think at some point, one of those concerns is going
to have to give.

>  and now, assuming what you say is part of the design behind the code
>
>  what's the point of this part of the code
>
>
>   >>      try:
>   >>          fd = sys.stdin.fileno()
>   >>      except:
>   >>          return default_getpass(prompt)
>   >>
>
>  i.e. the exception handler, default_getpass() is always going to read
>  from stdin at the end of the day.
>
>      line = sys.stdin.readline()
>
>  I'm assuming I'm missing something

Sorry, I only know my way around the libc version of getpass(), not
the python one.  In that version, typically we try to open /dev/tty
for reading, and if that fails, we fall back to stdin.  I presume
that's what's going on here, but the first line appears to be getting
stdin anyway, so I'm no longer sure.  That said, why don't you just
use default_getpass() in your code, if it reads from stdin to begin
with?

-- 
Cheers,
Leif

From janssen at parc.com  Tue Feb 26 19:14:17 2008
From: janssen at parc.com (Bill Janssen)
Date: Tue, 26 Feb 2008 10:14:17 PST
Subject: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
In-Reply-To: <9418DB6C0B9D434190E54A78E931C3D1036F8BE8@XCH-NW-7V1.nw.nos.boeing.com>
References: <47C3DAEB.1050102@cheimes.de>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BE7@XCH-NW-7V1.nw.nos.boeing.com>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BE8@XCH-NW-7V1.nw.nos.boeing.com>
Message-ID: <08Feb26.101423pst."58696"@synergy1.parc.xerox.com>

> I personally have not used _ssl but on quick inspection I don't see any
> of the crypto algorithms implemented, AES, ECDSA, etc.  What if we want
> to encrypt or sign content using OpenSSL?

I suggested adding a class which gives you access to those.  I think
it's a good idea, and that serious use of SSL will require signing
eventually.  If you'd like to submit an RFE, particularly an RFE with
a patch which includes a test case, that would move things along
smartly.

Bill

From larry.bugbee at boeing.com  Tue Feb 26 17:55:06 2008
From: larry.bugbee at boeing.com (Bugbee, Larry)
Date: Tue, 26 Feb 2008 08:55:06 -0800
Subject: [Python-Dev] Python 2.6 and 3.0  ...and applink.c?
In-Reply-To: <47C3DAEB.1050102@cheimes.de>
References: <mailman.5325.1203745263.9266.python-dev@python.org>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BDE@XCH-NW-7V1.nw.nos.boeing.com>
	<47C3DAEB.1050102@cheimes.de>
Message-ID: <9418DB6C0B9D434190E54A78E931C3D1036F8BE7@XCH-NW-7V1.nw.nos.boeing.com>

> I don't understand how applink is going to help you. The SSL libs are
statically linked > into the _ssl extension DLL.

I personally have not used _ssl but on quick inspection I don't see any
of the crypto algorithms implemented, AES, ECDSA, etc.  What if we want
to encrypt or sign content using OpenSSL?  We'd import M2Crypto but when
we go to load the key we'll get an OPENSSL_Applink error.  Likewise for
OpenSSL with xmlsec. 

Larry

From spotter at cs.columbia.edu  Tue Feb 26 19:18:29 2008
From: spotter at cs.columbia.edu (Shaya Potter)
Date: Tue, 26 Feb 2008 13:18:29 -0500
Subject: [Python-Dev] getpass and stdin
In-Reply-To: <cc7430500802261013o76c0f7d7s22c355645568383a@mail.gmail.com>
References: <47C1B144.4020701@cs.columbia.edu>	
	<cc7430500802260917p67d54c6by4e9fd911e1dc5a3e@mail.gmail.com>	
	<47C44FDF.2050704@cs.columbia.edu>
	<cc7430500802261013o76c0f7d7s22c355645568383a@mail.gmail.com>
Message-ID: <47C457F5.8030303@cs.columbia.edu>

Leif Walsh wrote:
> On Tue, Feb 26, 2008 at 12:43 PM, Shaya Potter <spotter at cs.columbia.edu> wrote:
>>  the -p <PASSWD> option is not good on multi user systems
>>  the -p <PASSFILE> option is not particularly good on NFS based systems
>>  (have to trust every user on every machine with access to NFS share)
> 
> You seem somehow both worried about security, yet too lazy to type in
> your password.  I think at some point, one of those concerns is going
> to have to give.

I want to run a program within a bash script, essentially daemonize a 
program that doesn't have a daemon mode.

#!/bin/sh

echo "What Is Your Passsword: "
stty_orig=`stty -g`
stty -echo
read -r PASSWORD
stty $stty_orig

TIMEOUT=600

while [ 1 ]
do
	echo $PASSWORD | program
	sleep $TIMEOUT
done

>>  and now, assuming what you say is part of the design behind the code
>>
>>  what's the point of this part of the code
>>
>>
>>   >>      try:
>>   >>          fd = sys.stdin.fileno()
>>   >>      except:
>>   >>          return default_getpass(prompt)
>>   >>
>>
>>  i.e. the exception handler, default_getpass() is always going to read
>>  from stdin at the end of the day.
>>
>>      line = sys.stdin.readline()
>>
>>  I'm assuming I'm missing something
> 
> Sorry, I only know my way around the libc version of getpass(), not
> the python one.  In that version, typically we try to open /dev/tty
> for reading, and if that fails, we fall back to stdin.  I presume
> that's what's going on here, but the first line appears to be getting
> stdin anyway, so I'm no longer sure.  That said, why don't you just
> use default_getpass() in your code, if it reads from stdin to begin
> with?

not my code, someone elses program, I can modify it, but that's a pain, 
was mostly wondering if it could be changed at the python level (or at 
least understand why python made the decision it did, sort of understand 
the eating stdin aspect)

From adlaiff6 at gmail.com  Tue Feb 26 19:20:09 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Tue, 26 Feb 2008 13:20:09 -0500
Subject: [Python-Dev] getpass and stdin
In-Reply-To: <47C457F5.8030303@cs.columbia.edu>
References: <47C1B144.4020701@cs.columbia.edu>
	<cc7430500802260917p67d54c6by4e9fd911e1dc5a3e@mail.gmail.com>
	<47C44FDF.2050704@cs.columbia.edu>
	<cc7430500802261013o76c0f7d7s22c355645568383a@mail.gmail.com>
	<47C457F5.8030303@cs.columbia.edu>
Message-ID: <cc7430500802261020r53c3323dvce383facb79c4a3c@mail.gmail.com>

On Tue, Feb 26, 2008 at 1:18 PM, Shaya Potter <spotter at cs.columbia.edu> wrote:
>  I want to run a program within a bash script, essentially daemonize a
>  program that doesn't have a daemon mode.
>
>  #!/bin/sh
>
>  echo "What Is Your Passsword: "
>  stty_orig=`stty -g`
>  stty -echo
>  read -r PASSWORD
>  stty $stty_orig
>
>  TIMEOUT=600
>
>  while [ 1 ]
>  do
>         echo $PASSWORD | program

So...why won't `program -p $PASSWORD' work here?

>         sleep $TIMEOUT
>  done

-- 
Cheers,
Leif

From lists at cheimes.de  Tue Feb 26 19:25:53 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 26 Feb 2008 19:25:53 +0100
Subject: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
In-Reply-To: <08Feb26.101423pst."58696"@synergy1.parc.xerox.com>
References: <47C3DAEB.1050102@cheimes.de>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BE7@XCH-NW-7V1.nw.nos.boeing.com>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BE8@XCH-NW-7V1.nw.nos.boeing.com>
	<08Feb26.101423pst."58696"@synergy1.parc.xerox.com>
Message-ID: <47C459B1.60806@cheimes.de>

Bill Janssen wrote:
[snip]

Do you have an opinion on the initial proposal of applink.c? The
proposal does neither seem harmful nor problematic but I also don't see
how it is going to help the op.

Christian

From charlesc-lists-python-dev at pyropus.ca  Tue Feb 26 19:48:55 2008
From: charlesc-lists-python-dev at pyropus.ca (Charles Cazabon)
Date: 26 Feb 2008 12:48:55 -0600
Subject: [Python-Dev] [OT] Re: getpass and stdin
In-Reply-To: <47C457F5.8030303@cs.columbia.edu>
References: <47C1B144.4020701@cs.columbia.edu>
	<cc7430500802260917p67d54c6by4e9fd911e1dc5a3e@mail.gmail.com>
	<47C44FDF.2050704@cs.columbia.edu>
	<cc7430500802261013o76c0f7d7s22c355645568383a@mail.gmail.com>
	<47C457F5.8030303@cs.columbia.edu>
Message-ID: <20080226184855.GA19862@pyropus.ca>

Shaya Potter <spotter at cs.columbia.edu> wrote:
> Leif Walsh wrote:
> > On Tue, Feb 26, 2008 at 12:43 PM, Shaya Potter <spotter at cs.columbia.edu> wrote:
> >>  the -p <PASSWD> option is not good on multi user systems
> >>  the -p <PASSFILE> option is not particularly good on NFS based systems
> >>  (have to trust every user on every machine with access to NFS share)
> > 
> > You seem somehow both worried about security, yet too lazy to type in
> > your password.  I think at some point, one of those concerns is going
> > to have to give.

That was exactly what I've been telling this user on the getmail mailing list
for the last week.  Apologies that he's decided to bother you with it.

Charles
-- 
------------------------------------------------------------------
Charles Cazabon             <charlesc-lists-python-dev at pyropus.ca>
Software, consulting, and services available at http://pyropus.ca/
------------------------------------------------------------------

From janssen at parc.com  Tue Feb 26 19:53:22 2008
From: janssen at parc.com (Bill Janssen)
Date: Tue, 26 Feb 2008 10:53:22 PST
Subject: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
In-Reply-To: <47C459B1.60806@cheimes.de> 
References: <47C3DAEB.1050102@cheimes.de>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BE7@XCH-NW-7V1.nw.nos.boeing.com>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BE8@XCH-NW-7V1.nw.nos.boeing.com>
	<08Feb26.101423pst."58696"@synergy1.parc.xerox.com>
	<47C459B1.60806@cheimes.de>
Message-ID: <08Feb26.105323pst."58696"@synergy1.parc.xerox.com>

> Bill Janssen wrote:
> [snip]
> 
> Do you have an opinion on the initial proposal of applink.c? The
> proposal does neither seem harmful nor problematic but I also don't see
> how it is going to help the op.
> 
> Christian

I know nothing about it -- it's a Windows thing.  But reading the note
at http://www.openssl.org/support/faq.html, I can see why Windows
developers might like to have it:

``Note that debug and release libraries are NOT interchangeable. If you
built OpenSSL with /MD your application must use /MD and cannot use
/MDd.

``As per 0.9.8 the above limitation is eliminated for .DLLs. OpenSSL
.DLLs compiled with some specific run-time option [we insist on the
default /MD] can be deployed with application compiled with different
option or even different compiler. But there is a catch! Instead of
re-compiling OpenSSL toolkit, as you would have to with prior
versions, you have to compile small C snippet with compiler and/or
options of your choice. The snippet gets installed as
<install-root>/include/openssl/applink.c and should be either added to
your application project or simply #include-d in one [and only one] of
your application source files. Failure to link this shim module into
your application manifests itself as fatal "no OPENSSL_Applink"
run-time error. An explicit reminder is due that in this situation
[mixing compiler options] it is as important to add CRYPTO_malloc_init
prior first call to OpenSSL.''

Bill



From larry.bugbee at boeing.com  Tue Feb 26 19:54:55 2008
From: larry.bugbee at boeing.com (Bugbee, Larry)
Date: Tue, 26 Feb 2008 10:54:55 -0800
Subject: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
In-Reply-To: <08Feb26.101423pst."58696"@synergy1.parc.xerox.com>
References: <47C3DAEB.1050102@cheimes.de>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BE7@XCH-NW-7V1.nw.nos.boeing.com>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BE8@XCH-NW-7V1.nw.nos.boeing.com>
	<08Feb26.101423pst."58696"@synergy1.parc.xerox.com>
Message-ID: <9418DB6C0B9D434190E54A78E931C3D1036F8BEC@XCH-NW-7V1.nw.nos.boeing.com>

I appreciate the gesture but...

At this juncture I'd prefer to see OpenSSL access to crypto APIs remain
an external library like M2Crypto, at least until the Python community
is willing to do a full implementation of all OpenSSL APIs.  ...and
maintain it.

Larry


-----Original Message-----
From: Bill Janssen [mailto:janssen at parc.com] 
Sent: Tuesday, February 26, 2008 10:14 AM
To: Bugbee, Larry
Cc: Christian Heimes; python-dev at python.org
Subject: Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c? 

> I personally have not used _ssl but on quick inspection I don't see 
> any of the crypto algorithms implemented, AES, ECDSA, etc.  What if we

> want to encrypt or sign content using OpenSSL?

I suggested adding a class which gives you access to those.  I think
it's a good idea, and that serious use of SSL will require signing
eventually.  If you'd like to submit an RFE, particularly an RFE with a
patch which includes a test case, that would move things along smartly.

Bill

From spotter at cs.columbia.edu  Tue Feb 26 20:14:56 2008
From: spotter at cs.columbia.edu (Shaya Potter)
Date: Tue, 26 Feb 2008 14:14:56 -0500
Subject: [Python-Dev] [OT] Re: getpass and stdin
In-Reply-To: <20080226184855.GA19862@pyropus.ca>
References: <47C1B144.4020701@cs.columbia.edu>	<cc7430500802260917p67d54c6by4e9fd911e1dc5a3e@mail.gmail.com>	<47C44FDF.2050704@cs.columbia.edu>	<cc7430500802261013o76c0f7d7s22c355645568383a@mail.gmail.com>	<47C457F5.8030303@cs.columbia.edu>
	<20080226184855.GA19862@pyropus.ca>
Message-ID: <47C46530.3030407@cs.columbia.edu>

Charles Cazabon wrote:
> Shaya Potter <spotter at cs.columbia.edu> wrote:
>> Leif Walsh wrote:
>>> On Tue, Feb 26, 2008 at 12:43 PM, Shaya Potter <spotter at cs.columbia.edu> wrote:
>>>>  the -p <PASSWD> option is not good on multi user systems
>>>>  the -p <PASSFILE> option is not particularly good on NFS based systems
>>>>  (have to trust every user on every machine with access to NFS share)
>>> You seem somehow both worried about security, yet too lazy to type in
>>> your password.  I think at some point, one of those concerns is going
>>> to have to give.
> 
> That was exactly what I've been telling this user on the getmail mailing list
> for the last week.  Apologies that he's decided to bother you with it.

actually,

1) I am willing to type in the password, which is obvious to anyone who 
can read a simple script.  That just doesn't work for a program you want 
to run in the background to type it in every time.

2) I was trying to understand why python made it's design decision, I 
don't need you apologizing for me trying to understand that (and I do 
ave a better understanding now)

For those who want the background to make up their own minds about why I 
asked.

Charles is the author of a program called getmail that is used for 
fetching email. - generally to fetch email you need a password.

getmail will either read a passowrd in via getpass() or read it from a 
file.  however,  storing the password in a file is out of the question 
in this case (NFS), but reading the password in is fine, I'm not 
concerned with a threat of it being read out of memory.

However, getmail doesn't have a daemon mode, charles recommends using 
the password in a file + cron, which I'd be fine with if I could store 
the password in a file.  However, as I can't, I wanted to daemonize it 
via a script (already posted), that reads in a password from stdin and 
passes it to getmail via its stdout and getmail's stdin.

However, that doesn't work with getpass() which getmail uses, and 
Charles isn't willing to change his program (it's his program he's 
allowed to do with it what he wants).

I cam here after examining the python code and being confused by it and 
wanting to understand the design decision that went into it, as I sort 
of do now as I said in my last real email on the subject "understand the 
eating stdin aspect"

That's it.  Personally, I debated sending this email (don't need to 
waste people's time), but I don't appreciate being called out in public 
as Charles did when in truth while my question was spurred on by getmail 
it was something I was generally interested in understanding as well.

From martin at v.loewis.de  Tue Feb 26 21:13:14 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 26 Feb 2008 21:13:14 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <02cf01c87857$4d19bf40$e74d3dc0$@com.au>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>
	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
	<47C2D841.2030501@cheimes.de>
	<20080225154443.GP66273@nexus.in-nomine.org>
	<47C2E774.2040205@cheimes.de> <47C33BD3.5040003@v.loewis.de>
	<47C35628.6060200@cheimes.de>
	<02cf01c87857$4d19bf40$e74d3dc0$@com.au>
Message-ID: <47C472DA.1070708@v.loewis.de>

> My problem is still getting my head
> around various MSI issues at any level (eg, bdist_msi needs some tweaking to
> allow for different releases of the same "package" to be recognized as such,
> but I'm not sure what MSI concept I'm dealing with yet...)

Don't hesitate to ask here. Not sure what problem you are talking to 
specifically, but I guess you are asking for "upgrade codes"; there is
also upgrade codes and package codes.

Each package file should have its own unique *package? code, mere 
rebuilding should generate a new one. msilib does that correctly.
A package code code can be installed at most once on a system.

Related packages for the same software should share a *product* code.
Rebuilding should not change the package code (but might in msilib;
I'd have to check). Again, installer enforces that a specific package
code can only be installed once on a system. Python assigns a
separate product code for each bug fix release. Product codes
are most useful for uninstallation, e.g. to uninstall Python 2.5.1,
do

   msiexec /x {31800004-6386-4999-a519-518f2d78d8f0}

Use separate product codes if you want to allow for simultaneous
versions.

Subsequent versions of the same product should share an *upgrade*
code. MSI will check the Upgrade table, to see whether a package
with the same upgrade code (but a different product code) is
already installed, and if so, whether the version range matches.
If the installed product is newer, it will refuse to install the
older one. If the installed product is older, it will perform
an "upgrade installation", which involves uninstalling the older
version (possibly on a file-by-file basis), and possibly
migrating the feature selections.

Python uses a single upgrade code (until 2.5.2, which introduces
a separate upgrade code for Win64). It then uses version ranges
to make 2.5.2 an upgrade of 2.5.1 and 2.5.0, but not of 2.4.2
(say), essentially causing only one bug fix release per 2.5.x
to be installed on the system, but allowing simultaneous
installation of 2.5 and 2.4 (say). With 2.5.2, simultaneous
installation of Win64 and Win32 releases on a single system becomes
possible - which also requires to assign separate product codes
to Win64, namely

    2.5.2, Win32: 6b976adf-8ae8-434e-b282-a06c7f624d2f
    2.5.2, Win64: 6b976adf-8ae8-434e-b282-a06c7f624d20

> WiX is an excellent inspiration though - if a WiX example can be found for
> something, it should be a significant help in implementing it via msilib.

The current challenge is merge modules: How can I merge the VC msm into
the Python MSI (including support for SxS).

Regards,
Martin

From martin at v.loewis.de  Tue Feb 26 21:26:20 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 26 Feb 2008 21:26:20 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C3543B.8060303@cheimes.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>	<47C1BE25.9050300@v.loewis.de>	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
	<47C2D841.2030501@cheimes.de> <47C33AEA.2010600@v.loewis.de>
	<47C3543B.8060303@cheimes.de>
Message-ID: <47C475EC.1020004@v.loewis.de>

>> No, I still haven't found a solution. I do want to use the merge
>> module; anything else probably isn't going to work.
> 
> Da...ng
> Didn't you prepare a new MSI installer for 3.0a2 that includes the VS
> Redist MSM for X86? I vaguely remember that you've replaced my installer
> with a new one.

Right. I produced a package that ships the CRT, but not by using the
merge module. Instead, I arranged to include sufficient copies of the
manifest file to make it work in the non-admin installation (and yes,
you do need to install multiple copies of it - just see the 3.0a2 MSI
file).

> The issue should be resolved before Python 2.6 and 3.0 are reaching beta
> stage. Maybe we can get some help from outside?

Perhaps. I'm confident that I can find a solution when I get the time;
I'm not so confident that I can find the time, though. Of course, I 
would prefer if the outside help would propose something better than
"switch to this completely different technology; it may work" (unless
a complete working solution is presented in that other technology, and
as long as that other technology still creates MSI files with
free-as-in-beer tools).

In any case, contributions are welcome.

Regards,
Martin

From adlaiff6 at gmail.com  Tue Feb 26 21:32:03 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Tue, 26 Feb 2008 15:32:03 -0500
Subject: [Python-Dev] [OT] Re: getpass and stdin
In-Reply-To: <47C46530.3030407@cs.columbia.edu>
References: <47C1B144.4020701@cs.columbia.edu>
	<cc7430500802260917p67d54c6by4e9fd911e1dc5a3e@mail.gmail.com>
	<47C44FDF.2050704@cs.columbia.edu>
	<cc7430500802261013o76c0f7d7s22c355645568383a@mail.gmail.com>
	<47C457F5.8030303@cs.columbia.edu> <20080226184855.GA19862@pyropus.ca>
	<47C46530.3030407@cs.columbia.edu>
Message-ID: <cc7430500802261232tc3875e3l9485dfbdb456af5e@mail.gmail.com>

On Tue, Feb 26, 2008 at 2:14 PM, Shaya Potter <spotter at cs.columbia.edu> wrote:
> 1) I am willing to type in the password, which is obvious to anyone who
> can read a simple script.  That just doesn't work for a program you want
> to run in the background to type it in every time.

I recommend you just hack on this getmail program and give it a daemon
mode.  That shouldn't be too large of a task, and it will certainly be
more secure (and you can even commit your changes as a new feature!).
Otherwise, your best bet is probably, as Charles said, making the
passfile work for you (maybe play with nfs and see if you can get it
to hide things...I'm no wizard with it, but I'm willing to bet it's
possible).

> INTERNET DRAMA

Let's just not continue this, shall we?

-- 
Cheers,
Leif

From martin at v.loewis.de  Tue Feb 26 21:35:10 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 26 Feb 2008 21:35:10 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C35628.6060200@cheimes.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>
	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>
	<47C2D841.2030501@cheimes.de>
	<20080225154443.GP66273@nexus.in-nomine.org>
	<47C2E774.2040205@cheimes.de> <47C33BD3.5040003@v.loewis.de>
	<47C35628.6060200@cheimes.de>
Message-ID: <47C477FE.3000301@v.loewis.de>

> What do you think?

Feel free to try it out. I'm skeptical that it will be a better overall
solution than the current one - the main difference would be that, 
rather than me being the only one who can realistically change the
packaging chain, it would be you who is the only one - which, in 
principle, would be fine with me.

I believe you need deep inside knowledge of the MSI database format
for WiX, just as you do for using the automation API. I think I could
learn WiX fairly quickly after all these years of learning MSI in the
first place. I think the WiX designers did right in tying WiX so close
to the MSI data model, but it means that WiX makes package creation not
simpler - merely more productive for the experienced user (who I
hesitate to call WiXers :-)

In any case, when you work with WiX, I'm sure you'll gain a lot of
expert knowledge on Windows packaging. Depending on your job situation,
that might pay some day :-)

Regards,
Martin

From spotter at cs.columbia.edu  Tue Feb 26 21:42:38 2008
From: spotter at cs.columbia.edu (Shaya Potter)
Date: Tue, 26 Feb 2008 15:42:38 -0500
Subject: [Python-Dev] [OT] Re: getpass and stdin
In-Reply-To: <cc7430500802261232tc3875e3l9485dfbdb456af5e@mail.gmail.com>
References: <47C1B144.4020701@cs.columbia.edu>	
	<cc7430500802260917p67d54c6by4e9fd911e1dc5a3e@mail.gmail.com>	
	<47C44FDF.2050704@cs.columbia.edu>	
	<cc7430500802261013o76c0f7d7s22c355645568383a@mail.gmail.com>	
	<47C457F5.8030303@cs.columbia.edu>
	<20080226184855.GA19862@pyropus.ca>	
	<47C46530.3030407@cs.columbia.edu>
	<cc7430500802261232tc3875e3l9485dfbdb456af5e@mail.gmail.com>
Message-ID: <47C479BE.8010702@cs.columbia.edu>

Leif Walsh wrote:
> On Tue, Feb 26, 2008 at 2:14 PM, Shaya Potter <spotter at cs.columbia.edu> wrote:
>> 1) I am willing to type in the password, which is obvious to anyone who
>> can read a simple script.  That just doesn't work for a program you want
>> to run in the background to type it in every time.
> 
> I recommend you just hack on this getmail program and give it a daemon
> mode.  That shouldn't be too large of a task, and it will certainly be
> more secure (and you can even commit your changes as a new feature!).
> Otherwise, your best bet is probably, as Charles said, making the
> passfile work for you (maybe play with nfs and see if you can get it
> to hide things...I'm no wizard with it, but I'm willing to bet it's
> possible).

I don't disagree (though nfs will never work, think root exploit on 
another machine, squash_root doesn't help).  I wasn't posting here about 
how to change getmail (I can make those changes easily), the issue was 
simply understanding python's getpass().  Which you answered my question 
on, so thank you.

From martin at v.loewis.de  Tue Feb 26 21:54:34 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 26 Feb 2008 21:54:34 +0100
Subject: [Python-Dev] Python 2.6 and 3.0  ...and applink.c?
In-Reply-To: <9418DB6C0B9D434190E54A78E931C3D1036F8BDE@XCH-NW-7V1.nw.nos.boeing.com>
References: <mailman.5325.1203745263.9266.python-dev@python.org>
	<9418DB6C0B9D434190E54A78E931C3D1036F8BDE@XCH-NW-7V1.nw.nos.boeing.com>
Message-ID: <47C47C8A.9020701@v.loewis.de>

> If not, I'd like to encourage its inclusion.  Doing so will permit
> Python to be used with OpenSSL 0.9.8x on Windows platforms without a
> user trying to find somebody with the right compiler to rebuild a Python
> for him/her.  This is needed for M2Crypto, or any other OpenSSL wrapper
> for that matter.  A lot more can be said here, but in the interest of
> brevity... ;-)  
> 
> applink.c is perhaps two dozen links and some error codes, and is benign
> for those not calling these APIs.  applink.c may be found in
> <openssl_source_dir>/ms and the one line include stmt that would be
> added to <py-src>/Modules/python.c is:
>     #include "<path_to>/applink.c"
> That's it.

As others said: please post a patch.

I do believe that this it's *not* that. Including it in python.c does
not help the least. Including it in pythonxy.dll may help.

However, somebody would have to produce a patch, and a test case,
and verify that the problem occurs without the patch, and is solved
with the patch.

Regards,
Martin

From mwm at mired.org  Tue Feb 26 22:01:06 2008
From: mwm at mired.org (Mike Meyer)
Date: Tue, 26 Feb 2008 16:01:06 -0500
Subject: [Python-Dev] [OT] Re: getpass and stdin
In-Reply-To: <cc7430500802261232tc3875e3l9485dfbdb456af5e@mail.gmail.com>
References: <47C1B144.4020701@cs.columbia.edu>
	<cc7430500802260917p67d54c6by4e9fd911e1dc5a3e@mail.gmail.com>
	<47C44FDF.2050704@cs.columbia.edu>
	<cc7430500802261013o76c0f7d7s22c355645568383a@mail.gmail.com>
	<47C457F5.8030303@cs.columbia.edu>
	<20080226184855.GA19862@pyropus.ca>
	<47C46530.3030407@cs.columbia.edu>
	<cc7430500802261232tc3875e3l9485dfbdb456af5e@mail.gmail.com>
Message-ID: <20080226160106.0371b634@bhuda.mired.org>

On Tue, 26 Feb 2008 15:32:03 -0500 "Leif Walsh" <adlaiff6 at gmail.com> wrote:
> On Tue, Feb 26, 2008 at 2:14 PM, Shaya Potter <spotter at cs.columbia.edu> wrote:
> > 1) I am willing to type in the password, which is obvious to anyone who
> > can read a simple script.  That just doesn't work for a program you want
> > to run in the background to type it in every time.
> 
> I recommend you just hack on this getmail program and give it a daemon
> mode.  That shouldn't be too large of a task, and it will certainly be
> more secure (and you can even commit your changes as a new feature!).
> Otherwise, your best bet is probably, as Charles said, making the
> passfile work for you (maybe play with nfs and see if you can get it
> to hide things...I'm no wizard with it, but I'm willing to bet it's
> possible).

Actually, the easiest thing is probably to use a "file" that's not
really a file, like /dev/stdin or <(cat -),

      <mike

-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

From martin at v.loewis.de  Tue Feb 26 22:09:48 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 26 Feb 2008 22:09:48 +0100
Subject: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
In-Reply-To: <47C459B1.60806@cheimes.de>
References: <47C3DAEB.1050102@cheimes.de>	<9418DB6C0B9D434190E54A78E931C3D1036F8BE7@XCH-NW-7V1.nw.nos.boeing.com>	<9418DB6C0B9D434190E54A78E931C3D1036F8BE8@XCH-NW-7V1.nw.nos.boeing.com>	<08Feb26.101423pst."58696"@synergy1.parc.xerox.com>
	<47C459B1.60806@cheimes.de>
Message-ID: <47C4801C.2000105@v.loewis.de>

> Do you have an opinion on the initial proposal of applink.c? The
> proposal does neither seem harmful nor problematic but I also don't see
> how it is going to help the op.

The specific change isn't going to help. What could help is the 
inclusion of applink.c into dl_nt.c.

This is not about somehow exposing SSL routines to other libraries, but
about exposing CRT stuff to openssl, specifically stdin/stdout/stderr,
fprintf, fgets, fwrite, fsetmod, feof, ferror, clearerr, fileno, _open,
_read, _write, _lseek, _close.

Actually, re-reading OpenSSL, adding it to python.exe (and probably
pythonw.exe) would help: They do GetModuleHandle(NULL) (which is the
handle to the executable), then GetProcAddress for OPENSSL_Applink.

So I think it's harmless and could help, except for the maintenance
burden of having to update our local copy of applink.c every time
OpenSSL adds a new slot to their applink table (which they should
rarely do).

Of course, the entire approach breaks in cases where Python gets
embedded: if, e.g., IIS loads the Python interpreter as a COM
scripting host, it would be the IIS executable which would have
to include applink.c :-) As IIS doesn't, extension modules that
link with their own OpenSSL will continue to produce a warning
about the missing applink when they run in the context of a COM
server (or some other Python embedding).

Regards,
Martin

From martin at v.loewis.de  Tue Feb 26 22:14:39 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 26 Feb 2008 22:14:39 +0100
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>	<fpuf2u$6se$1@ger.gmane.org>	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
Message-ID: <47C4813F.2080403@v.loewis.de>

> - X86 XP-4: idem. For this two, how can be tried if the bsddb lib in
> those windows is correctly installed?

They check out bsddb from subversion, see Tools/buildbot/external.
If you don't trust that they did so correctly, edit the script to
remove bsddb, check that in, wait for them to delete it, then revert
the script, check in again, and see how they build it.

Regards,
Martin

From martin at v.loewis.de  Tue Feb 26 22:19:00 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 26 Feb 2008 22:19:00 +0100
Subject: [Python-Dev] Python 2.6 and 3.0
In-Reply-To: <47C41EA2.4070508@cheimes.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>	<47C17CD6.1040707@cheimes.de>	<8E45F999-6B4B-43A4-AD9A-54D2D1570732@python.org>	<47C3592E.2080704@cheimes.de>	<7DC2E52B-1F40-4DFB-9680-5410DD9E854E@python.org>
	<47C41EA2.4070508@cheimes.de>
Message-ID: <47C48244.4060404@v.loewis.de>

> The Windows builds are hidden in the development section. It took me 10
> minutes to find them because I was searching in the download section and
> for nightly builds. The *daily* builds are available at
> http://www.python.org/dev/daily-msi/

The builds occur 11:00 UTC (2.5), 12:00 UTC (2.6) and 13:00 UTC (3.0).
What that's at day or at night depends on where you live :-)

Regards,
Martin

From facundobatista at gmail.com  Tue Feb 26 22:52:39 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Tue, 26 Feb 2008 19:52:39 -0200
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <47C4813F.2080403@v.loewis.de>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
Message-ID: <e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>

2008/2/26, "Martin v. L?wis" <martin at v.loewis.de>:

> They check out bsddb from subversion, see Tools/buildbot/external.
>  If you don't trust that they did so correctly, edit the script to
>  remove bsddb, check that in, wait for them to delete it, then revert
>  the script, check in again, and see how they build it.

No, I wasn't aware of this mechanisms at all. I don't even know how to
build Python in a Windows...

Anyway, I don't think it's a bad checkout or something, as the same
error happens in two different machines.

I don't know, :(

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From brett at python.org  Tue Feb 26 23:04:47 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 26 Feb 2008 14:04:47 -0800
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
Message-ID: <bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>

On Tue, Feb 26, 2008 at 1:52 PM, Facundo Batista
<facundobatista at gmail.com> wrote:
> 2008/2/26, "Martin v. L?wis" <martin at v.loewis.de>:
>
>
>  > They check out bsddb from subversion, see Tools/buildbot/external.
>  >  If you don't trust that they did so correctly, edit the script to
>  >  remove bsddb, check that in, wait for them to delete it, then revert
>  >  the script, check in again, and see how they build it.
>
>  No, I wasn't aware of this mechanisms at all. I don't even know how to
>  build Python in a Windows...
>
>  Anyway, I don't think it's a bad checkout or something, as the same
>  error happens in two different machines.
>
>  I don't know, :(

Or we can get rid of bsddb and not have the problem anymore. =)

-Brett

From larry.bugbee at boeing.com  Tue Feb 26 23:06:20 2008
From: larry.bugbee at boeing.com (Bugbee, Larry)
Date: Tue, 26 Feb 2008 14:06:20 -0800
Subject: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
In-Reply-To: <47C4801C.2000105@v.loewis.de>
References: <47C3DAEB.1050102@cheimes.de>	<9418DB6C0B9D434190E54A78E931C3D1036F8BE7@XCH-NW-7V1.nw.nos.boeing.com>	<9418DB6C0B9D434190E54A78E931C3D1036F8BE8@XCH-NW-7V1.nw.nos.boeing.com>	<08Feb26.101423pst."58696"@synergy1.parc.xerox.com>
	<47C459B1.60806@cheimes.de> <47C4801C.2000105@v.loewis.de>
Message-ID: <9418DB6C0B9D434190E54A78E931C3D1036F8BED@XCH-NW-7V1.nw.nos.boeing.com>

I won't pretend to know where the *best* place to put the include is, but python.c was suggested to me some time ago.  Just so you know, we tried putting the include in some C code that is part of M2Crypto and it did not work because, as we discovered, the applink table needs to be part of main().  

Extending that thought...  If somebody wanted to somehow embed python is part of the same process in their program as with perhaps IIS, I submit it would not be part of main() and therefore benign.

Now, I would like very much to be in a position to experiment with all the combinations and prepare a patch that worked, but I do not have the requisite Microsoft toolset.  I primarily work with gcc under OSX, Linux, cygwin/mingw.  

This last raises a curiosity question.  Is there a reason why Python.exe cannot be built using gcc instead of Visual Studio?  Would not requiring the same VS version cause a problem in the field if someone were to receive an extension but had their Python built using a different version of VS?  It seems building everything with gcc would get around the problem of having to match VS versions.  ...or are we dependent on some specific Microsoft library?  I dunno, I gotta ask.

Larry


  -----Original Message-----
  From: "Martin v. L?wis" [mailto:martin at v.loewis.de] 
  Sent: Tuesday, February 26, 2008 1:10 PM
  To: Christian Heimes
  Cc: Bill Janssen; Bugbee, Larry; python-dev at python.org
  Subject: Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
  
  > Do you have an opinion on the initial proposal of applink.c? 
  > The proposal does neither seem harmful nor problematic but I 
  > also don't see how it is going to help the op.
  
  The specific change isn't going to help. What could help is the 
  inclusion of applink.c into dl_nt.c.
  
  This is not about somehow exposing SSL routines to other 
  libraries, but about exposing CRT stuff to openssl, 
  specifically stdin/stdout/stderr, fprintf, fgets, fwrite, 
  fsetmod, feof, ferror, clearerr, fileno, _open, _read, _write, 
  _lseek, _close.
  
  Actually, re-reading OpenSSL, adding it to python.exe (and 
  probably pythonw.exe) would help: They do GetModuleHandle(NULL) 
  (which is the handle to the executable), then GetProcAddress 
  for OPENSSL_Applink.
  
  So I think it's harmless and could help, except for the 
  maintenance burden of having to update our local copy of 
  applink.c every time OpenSSL adds a new slot to their applink 
  table (which they should rarely do).
  
  Of course, the entire approach breaks in cases where Python 
  gets embedded: if, e.g., IIS loads the Python interpreter as 
  a COM scripting host, it would be the IIS executable which 
  would have to include applink.c :-) As IIS doesn't, extension 
  modules that link with their own OpenSSL will continue to 
  produce a warning about the missing applink when they run in 
  the context of a COM server (or some other Python embedding).
  
  Regards,
  Martin
  

From fdrake at acm.org  Tue Feb 26 23:14:04 2008
From: fdrake at acm.org (Fred Drake)
Date: Tue, 26 Feb 2008 17:14:04 -0500
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
Message-ID: <D13966CC-3466-419C-9806-1FE416FF30DF@acm.org>

On Feb 26, 2008, at 5:04 PM, Brett Cannon wrote:
> Or we can get rid of bsddb and not have the problem anymore. =)


+1 for fewer problems.  :)


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From christian at cheimes.de  Tue Feb 26 23:42:42 2008
From: christian at cheimes.de (Christian Heimes)
Date: Tue, 26 Feb 2008 23:42:42 +0100
Subject: [Python-Dev] Python 2.6 and 3.0
In-Reply-To: <47C48244.4060404@v.loewis.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>	<47C17CD6.1040707@cheimes.de>	<8E45F999-6B4B-43A4-AD9A-54D2D1570732@python.org>	<47C3592E.2080704@cheimes.de>	<7DC2E52B-1F40-4DFB-9680-5410DD9E854E@python.org>
	<47C41EA2.4070508@cheimes.de> <47C48244.4060404@v.loewis.de>
Message-ID: <47C495E2.2090705@cheimes.de>

Martin v. L?wis wrote:
>> The Windows builds are hidden in the development section. It took me 10
>> minutes to find them because I was searching in the download section and
>> for nightly builds. The *daily* builds are available at
>> http://www.python.org/dev/daily-msi/
>
> The builds occur 11:00 UTC (2.5), 12:00 UTC (2.6) and 13:00 UTC (3.0).
> What that's at day or at night depends on where you live :-)

Trust me, the day and night cycle of our sun can be unrelated to the day
and night cycle of my life. I define morning as the time span after my
first coffee. I sometimes work until dawn so technically speaking 11:00
UTC could fit my definition of nightly build. :)

Christian

From phd at phd.pp.ru  Tue Feb 26 23:55:42 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Wed, 27 Feb 2008 01:55:42 +0300
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
Message-ID: <20080226225542.GA12912@phd.pp.ru>

On Tue, Feb 26, 2008 at 02:04:47PM -0800, Brett Cannon wrote:
> Or we can get rid of bsddb and not have the problem anymore. =)

   +1 for smaller stdlib and fewer problems.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From greg at krypto.org  Wed Feb 27 06:46:04 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Tue, 26 Feb 2008 21:46:04 -0800
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
Message-ID: <52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>

On 2/26/08, Brett Cannon <brett at python.org> wrote:
>
> On Tue, Feb 26, 2008 at 1:52 PM, Facundo Batista
> <facundobatista at gmail.com> wrote:
> > 2008/2/26, "Martin v. L?wis" <martin at v.loewis.de>:
> >
> >
> >  > They check out bsddb from subversion, see Tools/buildbot/external.
> >  >  If you don't trust that they did so correctly, edit the script to
> >  >  remove bsddb, check that in, wait for them to delete it, then revert
> >  >  the script, check in again, and see how they build it.
> >
> >  No, I wasn't aware of this mechanisms at all. I don't even know how to
> >  build Python in a Windows...
> >
> >  Anyway, I don't think it's a bad checkout or something, as the same
> >  error happens in two different machines.
> >
> >  I don't know, :(
>
> Or we can get rid of bsddb and not have the problem anymore. =)
>
> -Brett


-1

Using that logic I prefer just getting rid of Windows to stop having these
problems.  That'd solve the ssl applink issue and msi installer building
issue as well. =P

My opinion on bsddb as a standard library module is based mostly on "its
always been there" and a vague memory of the last time this came up I
thought people piped up saying they liked batteries being included,
including bsddb and sqlite, but I don't have a handy reference to that email
thread.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080226/d6ae002d/attachment-0001.htm 

From brett at python.org  Wed Feb 27 08:47:47 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 26 Feb 2008 23:47:47 -0800
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>
Message-ID: <bbaeab100802262347q6c151ecsf028976f70c4fc80@mail.gmail.com>

On Tue, Feb 26, 2008 at 9:46 PM, Gregory P. Smith <greg at krypto.org> wrote:
>
>
>
> On 2/26/08, Brett Cannon <brett at python.org> wrote:
> > On Tue, Feb 26, 2008 at 1:52 PM, Facundo Batista
> > <facundobatista at gmail.com> wrote:
> > > 2008/2/26, "Martin v. L?wis" <martin at v.loewis.de>:
> > >
> > >
> > >  > They check out bsddb from subversion, see Tools/buildbot/external.
> > >  >  If you don't trust that they did so correctly, edit the script to
> > >  >  remove bsddb, check that in, wait for them to delete it, then revert
> > >  >  the script, check in again, and see how they build it.
> > >
> > >  No, I wasn't aware of this mechanisms at all. I don't even know how to
> > >  build Python in a Windows...
> > >
> > >  Anyway, I don't think it's a bad checkout or something, as the same
> > >  error happens in two different machines.
> > >
> > >  I don't know, :(
> >
> > Or we can get rid of bsddb and not have the problem anymore. =)
> >
> > -Brett
>
> -1
>
> Using that logic I prefer just getting rid of Windows to stop having these
> problems.  That'd solve the ssl applink issue and msi installer building
> issue as well. =P
>

=) Well, we can't have all our dreams come true.

> My opinion on bsddb as a standard library module is based mostly on "its
> always been there" and a vague memory of the last time this came up I
> thought people piped up saying they liked batteries being included,
> including bsddb and sqlite, but I don't have a handy reference to that email
> thread.

Well, in my opinion "batteries included" is great, but not when one of
the batteries consistently acts up and requires a good shake to get
working again. The bsddb module has consistent reliability issues when
it comes to testing (and I suspect it has more to do with Sleepycat
than the bindings). I know I am tired of getting buildbot errors
saying that the bsddb tests died more consistently than most tests
over their history. And I did some work on porting bsddb over to
Python 3.0 and it was painful.

Anyway, I am not pushing for this now. Any major removal plans will go
through the stdlib-sig first and require justification before I even
attempt to seriously suggest something beyond a joking line in an
email (in other words, no one needs to worry about anything right
now).

-Brett

From brett at python.org  Wed Feb 27 08:56:47 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 26 Feb 2008 23:56:47 -0800
Subject: [Python-Dev] Getting a second review on a rewrite of test_logging
Message-ID: <bbaeab100802262356v5488a149g15cc95ae6bafe1b3@mail.gmail.com>

I think over a week ago I applied some GHOP work that turned
test_logging into a doctest, but it turns out it is still flaky.
Luckily Antoine Pitrou rewrote test_logging using unittest and seems
to have made it more sound.

But before I replace test_logging again (especially with a more
dramatic change) I would like to get a second pair of eyes on the
patch as I really don't know the logging package that well.

It's issue 1740 (http://bugs.python.org/issue1740). If you happen to
know the logging package I would really appreciate it if you could
give the patch a look.

-Brett

From panrui2006 at gmail.com  Wed Feb 27 12:30:53 2008
From: panrui2006 at gmail.com (panrui pan)
Date: Wed, 27 Feb 2008 19:30:53 +0800
Subject: [Python-Dev] hello
Message-ID: <1ffd2be0802270330t296ea326uf6f8d6394d17dd8e@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080227/00036bf6/attachment.htm 

From ndbecker2 at gmail.com  Wed Feb 27 13:49:18 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 27 Feb 2008 07:49:18 -0500
Subject: [Python-Dev] download python-2.6 docs?
Message-ID: <fq3m8f$kqh$1@ger.gmane.org>

http://docs.python.org/dev/download.html

I want a pdf.  The above link says:
"To download an archive containing all the documents for this version of
Python in one of various formats, follow one of links in this table. "

But there are no links.


From amk at amk.ca  Wed Feb 27 15:13:22 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Wed, 27 Feb 2008 09:13:22 -0500
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>
Message-ID: <20080227141322.GA5871@amk-desktop.matrixgroup.net>

On Tue, Feb 26, 2008 at 09:46:04PM -0800, Gregory P. Smith wrote:
> My opinion on bsddb as a standard library module is based mostly on "its
> always been there" and a vague memory of the last time this came up I
> thought people piped up saying they liked batteries being included,
> including bsddb and sqlite, but I don't have a handy reference to that email
> thread.

Looking at the July 2000 python-dev archive, it was added in the
lead-up for Python 2.0 because the bsddb185 module was becoming
increasingly difficult to support; fewer and fewer platforms were
including it, I think.  So we included the BerkeleyDB wrapper which
was backward-compatible and provided much lower-level access.  I think
BerkeleyDB was also the only stdlib database that included
transactional features until sqlite was included.  It's disappointing
that the API has gotten so complicated and that a few releases have
been broken.

Doing a code search finds a fair number of users of the module: Zope's
BDBStorage, Mailman 2.x's archiver, 4Suite, PyTone, OuterSpace,
Chandler, BioPython.

--amk

From nnorwitz at gmail.com  Wed Feb 27 16:43:08 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Wed, 27 Feb 2008 07:43:08 -0800
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <bbaeab100802262347q6c151ecsf028976f70c4fc80@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>
	<bbaeab100802262347q6c151ecsf028976f70c4fc80@mail.gmail.com>
Message-ID: <ee2a432c0802270743q3a17b5ecs6a4da4cfd24aadcd@mail.gmail.com>

On Tue, Feb 26, 2008 at 11:47 PM, Brett Cannon <brett at python.org> wrote:
>
>  Well, in my opinion "batteries included" is great, but not when one of
>  the batteries consistently acts up and requires a good shake to get
>  working again. The bsddb module has consistent reliability issues when
>  it comes to testing (and I suspect it has more to do with Sleepycat
>  than the bindings). I know I am tired of getting buildbot errors
>  saying that the bsddb tests died more consistently than most tests
>  over their history.

I agree that bsddb has been a pain.  It's about 1 of 10 tests that
fill that category.  I've been working on reducing these problems
(recently: test_bsddb3, test_smptlib, test_xmlrpclib, and I'm sure
there are others I forgot).  Rather than remove modules, it would be
more productive if we fixed the flaky tests.  Then we wouldn't have to
ignore failures, we could trust the buildbots.  test_urllib*net tests
still fail regularly, I think because some hosts aren't available from
time to time.  Can someone look into making test_urllib*net more
robust?

We also need to make the tests more robust.  By fixing test_smtplib, I
sped it up by over 99% while making it more robust.  Any test that
uses threads and sleeps (really just sleeps) needs to be fixed
similarly.  Can someone find which tests still use sleep?

n

From theller at ctypes.org  Wed Feb 27 16:57:40 2008
From: theller at ctypes.org (Thomas Heller)
Date: Wed, 27 Feb 2008 16:57:40 +0100
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <ee2a432c0802270743q3a17b5ecs6a4da4cfd24aadcd@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>	<47C32D2D.1030206@free.fr>	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>	<47C4813F.2080403@v.loewis.de>	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>	<bbaeab100802262347q6c151ecsf028976f70c4fc80@mail.gmail.com>
	<ee2a432c0802270743q3a17b5ecs6a4da4cfd24aadcd@mail.gmail.com>
Message-ID: <fq419k$15d$1@ger.gmane.org>

Neal Norwitz schrieb:
> On Tue, Feb 26, 2008 at 11:47 PM, Brett Cannon <brett at python.org> wrote:
>>
>>  Well, in my opinion "batteries included" is great, but not when one of
>>  the batteries consistently acts up and requires a good shake to get
>>  working again. The bsddb module has consistent reliability issues when
>>  it comes to testing (and I suspect it has more to do with Sleepycat
>>  than the bindings). I know I am tired of getting buildbot errors
>>  saying that the bsddb tests died more consistently than most tests
>>  over their history.
> 
> I agree that bsddb has been a pain.  It's about 1 of 10 tests that
> fill that category.  I've been working on reducing these problems
> (recently: test_bsddb3, test_smptlib, test_xmlrpclib, and I'm sure
> there are others I forgot).  Rather than remove modules, it would be
> more productive if we fixed the flaky tests.  Then we wouldn't have to
> ignore failures, we could trust the buildbots.

Maybe the flaky tests could be moved towards the end?  This way we could
at least see if the other tests work.

Thomas


From martin at v.loewis.de  Wed Feb 27 20:28:26 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 27 Feb 2008 20:28:26 +0100
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <fq419k$15d$1@ger.gmane.org>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>	<47C32D2D.1030206@free.fr>	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>	<47C4813F.2080403@v.loewis.de>	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>	<bbaeab100802262347q6c151ecsf028976f70c4fc80@mail.gmail.com>	<ee2a432c0802270743q3a17b5ecs6a4da4cfd24aadcd@mail.gmail.com>
	<fq419k$15d$1@ger.gmane.org>
Message-ID: <47C5B9DA.6010105@v.loewis.de>

> Maybe the flaky tests could be moved towards the end?  This way we could
> at least see if the other tests work.

It's intentional that the tests run in a random order.

Regards,
Martin

From tnelson at onresolve.com  Wed Feb 27 21:12:08 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Wed, 27 Feb 2008 12:12:08 -0800
Subject: [Python-Dev] Adding a new Windows x64 buildbot
Message-ID: <87D3F9C72FBF214DB39FA4E3FE618CDC6E160CEDC3@EXMBX04.exchhosting.com>

Hi,

I've got a Windows Server 2008 x64 server I'd like to contribute as a buildbot.  As per the recommendation on http://wiki.python.org/moin/BuildBot, it sounds like I'm looking for Martin, Anthony or Neal to sort me out with slave credentials.  Feel free to drop me a line!

Regards,

    Trent.

From tnelson at onresolve.com  Wed Feb 27 21:26:19 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Wed, 27 Feb 2008 12:26:19 -0800
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <47C475EC.1020004@v.loewis.de>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>
	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>
	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>
	<47C1BE25.9050300@v.loewis.de>	<20080224201613.GL66273@nexus.in-nomine.org>
	<01a101c87738$da592b90$8f0b82b0$@com.au>	<47C2D841.2030501@cheimes.de>
	<47C33AEA.2010600@v.loewis.de>
	<47C3543B.8060303@cheimes.de>,<47C475EC.1020004@v.loewis.de>
Message-ID: <87D3F9C72FBF214DB39FA4E3FE618CDC6E160CEDC4@EXMBX04.exchhosting.com>

> (unless a complete working solution is presented in that other technology,
> and as long as that other technology still creates MSI files with free-as-in-beer tools).

Just out of interest, what's the reason for enforcing that the installer must be an MSI?  Or, rather, if I were to present an alternative .exe installer that ticks all of the above boxes, exceeds the capabilities of the current installer and above all is easier to extend and maintain -- would that be a non-starter because it's not an MSI?

    Trent.

From martin at v.loewis.de  Wed Feb 27 21:56:12 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 27 Feb 2008 21:56:12 +0100
Subject: [Python-Dev] [Python-3000] Python 2.6 and 3.0
In-Reply-To: <87D3F9C72FBF214DB39FA4E3FE618CDC6E160CEDC4@EXMBX04.exchhosting.com>
References: <54334B67-3CD3-436D-BFEE-E358CF31A270@python.org>	<bbaeab100802221554t55527c27w98084751b233316e@mail.gmail.com>	<6D7348BC-EF35-4639-BBB5-83C8C7410EC6@python.org>	<47C1BE25.9050300@v.loewis.de>	<20080224201613.GL66273@nexus.in-nomine.org>	<01a101c87738$da592b90$8f0b82b0$@com.au>	<47C2D841.2030501@cheimes.de>	<47C33AEA.2010600@v.loewis.de>	<47C3543B.8060303@cheimes.de>,
	<47C475EC.1020004@v.loewis.de>
	<87D3F9C72FBF214DB39FA4E3FE618CDC6E160CEDC4@EXMBX04.exchhosting.com>
Message-ID: <47C5CE6C.8020602@v.loewis.de>

>> (unless a complete working solution is presented in that other
>> technology, and as long as that other technology still creates MSI
>> files with free-as-in-beer tools).
> 
> Just out of interest, what's the reason for enforcing that the
> installer must be an MSI?  Or, rather, if I were to present an
> alternative .exe installer that ticks all of the above boxes, exceeds
> the capabilities of the current installer and above all is easier to
> extend and maintain -- would that be a non-starter because it's not
> an MSI?

Not necessarily - it is just very hard to provide the same features
as MSI, but with a different tool. It seems that most tools have given
up the battle against MSI, and now provide just another layer on top
of MSI (just as my msilib does, or WiX).

Regards,
Martin


From fdrake at acm.org  Thu Feb 28 04:45:53 2008
From: fdrake at acm.org (Fred Drake)
Date: Wed, 27 Feb 2008 22:45:53 -0500
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <20080227141322.GA5871@amk-desktop.matrixgroup.net>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>
	<20080227141322.GA5871@amk-desktop.matrixgroup.net>
Message-ID: <CCD0F39F-1EB9-4379-9107-391EBEF33664@acm.org>

On Feb 27, 2008, at 9:13 AM, A.M. Kuchling wrote:
> Doing a code search finds a fair number of users of the module: Zope's
> BDBStorage, ...


The BDBStorage is long gone at this point.  Few are so unfortunate as  
to remember it (though a few who may just might be on this list).  :-)


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From barry at python.org  Thu Feb 28 20:01:47 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 28 Feb 2008 14:01:47 -0500
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <CCD0F39F-1EB9-4379-9107-391EBEF33664@acm.org>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<fpuf2u$6se$1@ger.gmane.org>
	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>
	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>
	<20080227141322.GA5871@amk-desktop.matrixgroup.net>
	<CCD0F39F-1EB9-4379-9107-391EBEF33664@acm.org>
Message-ID: <82B93F45-64B6-4371-80D4-A5AD96A3D87B@python.org>

On Feb 27, 2008, at 10:45 PM, Fred Drake wrote:

> On Feb 27, 2008, at 9:13 AM, A.M. Kuchling wrote:
>> Doing a code search finds a fair number of users of the module:  
>> Zope's
>> BDBStorage, ...
>
> The BDBStorage is long gone at this point.  Few are so unfortunate as
> to remember it (though a few who may just might be on this list).  :-)

Age related memory loss has its upside, I guess.

-B


From lists at cheimes.de  Thu Feb 28 20:49:46 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 28 Feb 2008 20:49:46 +0100
Subject: [Python-Dev] Code freeze?
Message-ID: <47C7105A.20908@cheimes.de>

Hey Barry!

When are you planing to freeze the code of the trunk and branches/py3k
for the upcoming alpha releases? I'll merge the last modifications from
2.6 to 3.0 in a couple of minutes. All tests on Linux are looking good,
except for the two profile tests on 3.0. I'm going to test Windows later.

Christian

From lists at cheimes.de  Thu Feb 28 21:00:54 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 28 Feb 2008 21:00:54 +0100
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <CCD0F39F-1EB9-4379-9107-391EBEF33664@acm.org>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>	<fpuf2u$6se$1@ger.gmane.org>	<e04bdf310802251009u4d4af742t37da916fc0445e50@mail.gmail.com>	<e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>	<47C32D2D.1030206@free.fr>	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>	<47C4813F.2080403@v.loewis.de>	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>	<20080227141322.GA5871@amk-desktop.matrixgroup.net>
	<CCD0F39F-1EB9-4379-9107-391EBEF33664@acm.org>
Message-ID: <47C712F6.9040809@cheimes.de>

Fred Drake wrote:
> The BDBStorage is long gone at this point.  Few are so unfortunate as  
> to remember it (though a few who may just might be on this list).  :-)

Oh yeah ... ZODB4 and BDBStorage ... a dark chapter starting with high
hopes and ending in tragedy ... Several projects like Zope and
Subversion worked hard on a a Berkeley DB backend but in the end all
projects had the same fate.

A few years ago in G?teborg/SE during lunch Jim explained me the reasons
for the cancellation. As far as I remember the conversation he used some
words I dare not to repeat in public. Some kids may read the Python dev
list. :)

Christian

From arkanes at gmail.com  Thu Feb 28 21:03:51 2008
From: arkanes at gmail.com (Chris Mellon)
Date: Thu, 28 Feb 2008 14:03:51 -0600
Subject: [Python-Dev] [Python-3000] Code freeze?
In-Reply-To: <47C7105A.20908@cheimes.de>
References: <47C7105A.20908@cheimes.de>
Message-ID: <4866bea60802281203p29caa500q53de0ddb6fb92a82@mail.gmail.com>

On Thu, Feb 28, 2008 at 1:49 PM, Christian Heimes <lists at cheimes.de> wrote:
> Hey Barry!
>
>  When are you planing to freeze the code of the trunk and branches/py3k
>  for the upcoming alpha releases? I'll merge the last modifications from
>  2.6 to 3.0 in a couple of minutes. All tests on Linux are looking good,
>  except for the two profile tests on 3.0. I'm going to test Windows later.
>

Would a call for third-party module maintainer updates be justified?
pysqlite in particular has advanced a couple versions since 2.5, and
it'd be nice if the latest made it into 2.6.

From jtauber at jtauber.com  Thu Feb 28 21:14:56 2008
From: jtauber at jtauber.com (James Tauber)
Date: Thu, 28 Feb 2008 15:14:56 -0500
Subject: [Python-Dev] Google Summer of Code 2008
Message-ID: <1204229696.17465.1239689307@webmail.messagingengine.com>

The Google Summer of Code is on again and I've been asked to coordinate
the PSF's involvement.

You can find out more about GSoC at http://code.google.com/soc/2008/

There is also a page on the Python wiki:
http://wiki.python.org/moin/SummerOfCode

Although the PSF does act as an umbrella organization for a number of
different projects, we'd like to give as much opportunity as possible
for students to work on core Python development.

At this stage it would be great if you could start thinking about
potential projects and/or whether you would be willing to be a mentor.

Two mailing lists have been set up:

http://mail.python.org/mailman/listinfo/soc2008-mentors
http://mail.python.org/mailman/listinfo/soc2008-general

If you are interested in being a mentor, please join both lists.
The mentor list requires approval and the archive is private. The
general list is for anyone interested in the summer of code and all
potential mentors, potential students and interested lurkers should
join.

Let me know if you have any questions.

James
-- 
  James Tauber               http://jtauber.com/
  journeyman of some    http://jtauber.com/blog/


From phd at phd.pp.ru  Thu Feb 28 21:19:40 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Thu, 28 Feb 2008 23:19:40 +0300
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <47C712F6.9040809@cheimes.de>
References: <e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>
	<20080227141322.GA5871@amk-desktop.matrixgroup.net>
	<CCD0F39F-1EB9-4379-9107-391EBEF33664@acm.org>
	<47C712F6.9040809@cheimes.de>
Message-ID: <20080228201940.GA23104@phd.pp.ru>

On Thu, Feb 28, 2008 at 09:00:54PM +0100, Christian Heimes wrote:
> Oh yeah ... ZODB4 and BDBStorage ... a dark chapter starting with high
> hopes and ending in tragedy ... Several projects like Zope and
> Subversion worked hard on a a Berkeley DB backend but in the end all
> projects had the same fate.
> 
> A few years ago in Geteborg/SE during lunch Jim explained me the reasons
> for the cancellation. As far as I remember the conversation he used some
> words I dare not to repeat in public. Some kids may read the Python dev
> list. :)

   Sorry, can I ask an additional question? These words - what they were
about? about the architecture of BDBStorage and Subversion, or about the
very BerkeleyDB, or about what?

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From lists at cheimes.de  Thu Feb 28 21:23:41 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 28 Feb 2008 21:23:41 +0100
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <ca471dc20802281219q267bbcc4u2e5e15c84123fbbb@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>	
	<47C32D2D.1030206@free.fr>	
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>	
	<47C4813F.2080403@v.loewis.de>	
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>	
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>	
	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>	
	<20080227141322.GA5871@amk-desktop.matrixgroup.net>	
	<CCD0F39F-1EB9-4379-9107-391EBEF33664@acm.org>	
	<47C712F6.9040809@cheimes.de>
	<ca471dc20802281219q267bbcc4u2e5e15c84123fbbb@mail.gmail.com>
Message-ID: <47C7184D.4020309@cheimes.de>

Guido van Rossum wrote:
> Correction: the subversion BerkeleyDB backend is still very much alive
> and kicking. There were some early issues (they did things that
> SleepyCat told them not to do :-) but it was corrected and it's still
> working fine for several large users.

Thanks for the correction! It seems my information is a bit outdated.
Several years ago we have moved most or all subversion repositories to
fsfs because we had major issue with the Berkeley backend. I haven't
used the bdb backend since then.

Christian

From guido at python.org  Thu Feb 28 21:26:53 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 28 Feb 2008 12:26:53 -0800
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <47C7184D.4020309@cheimes.de>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>
	<20080227141322.GA5871@amk-desktop.matrixgroup.net>
	<CCD0F39F-1EB9-4379-9107-391EBEF33664@acm.org>
	<47C712F6.9040809@cheimes.de>
	<ca471dc20802281219q267bbcc4u2e5e15c84123fbbb@mail.gmail.com>
	<47C7184D.4020309@cheimes.de>
Message-ID: <ca471dc20802281226m76fc94b7ibafbb738ac1030c2@mail.gmail.com>

On Thu, Feb 28, 2008 at 12:23 PM, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum wrote:
>  > Correction: the subversion BerkeleyDB backend is still very much alive
>  > and kicking. There were some early issues (they did things that
>  > SleepyCat told them not to do :-) but it was corrected and it's still
>  > working fine for several large users.
>
>  Thanks for the correction! It seems my information is a bit outdated.
>  Several years ago we have moved most or all subversion repositories to
>  fsfs because we had major issue with the Berkeley backend. I haven't
>  used the bdb backend since then.

This was the fault of the svn developers, not of BerkeleyDB. And svn
has fixed the issues.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From lists at cheimes.de  Thu Feb 28 21:29:51 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 28 Feb 2008 21:29:51 +0100
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <ca471dc20802281226m76fc94b7ibafbb738ac1030c2@mail.gmail.com>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>	
	<47C4813F.2080403@v.loewis.de>	
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>	
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>	
	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>	
	<20080227141322.GA5871@amk-desktop.matrixgroup.net>	
	<CCD0F39F-1EB9-4379-9107-391EBEF33664@acm.org>	
	<47C712F6.9040809@cheimes.de>	
	<ca471dc20802281219q267bbcc4u2e5e15c84123fbbb@mail.gmail.com>	
	<47C7184D.4020309@cheimes.de>
	<ca471dc20802281226m76fc94b7ibafbb738ac1030c2@mail.gmail.com>
Message-ID: <47C719BF.7090603@cheimes.de>

Guido van Rossum wrote:
> This was the fault of the svn developers, not of BerkeleyDB. And svn
> has fixed the issues.

I got that in your last mail ;)

Christian


From guido at python.org  Thu Feb 28 21:19:08 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 28 Feb 2008 12:19:08 -0800
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <47C712F6.9040809@cheimes.de>
References: <e04bdf310802250423o7e8b5ccbu6d0b48af468583e1@mail.gmail.com>
	<47C32D2D.1030206@free.fr>
	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>
	<47C4813F.2080403@v.loewis.de>
	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>
	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>
	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>
	<20080227141322.GA5871@amk-desktop.matrixgroup.net>
	<CCD0F39F-1EB9-4379-9107-391EBEF33664@acm.org>
	<47C712F6.9040809@cheimes.de>
Message-ID: <ca471dc20802281219q267bbcc4u2e5e15c84123fbbb@mail.gmail.com>

Correction: the subversion BerkeleyDB backend is still very much alive
and kicking. There were some early issues (they did things that
SleepyCat told them not to do :-) but it was corrected and it's still
working fine for several large users.

On Thu, Feb 28, 2008 at 12:00 PM, Christian Heimes <lists at cheimes.de> wrote:
> Fred Drake wrote:
>  > The BDBStorage is long gone at this point.  Few are so unfortunate as
>  > to remember it (though a few who may just might be on this list).  :-)
>
>  Oh yeah ... ZODB4 and BDBStorage ... a dark chapter starting with high
>  hopes and ending in tragedy ... Several projects like Zope and
>  Subversion worked hard on a a Berkeley DB backend but in the end all
>  projects had the same fate.
>
>  A few years ago in G?teborg/SE during lunch Jim explained me the reasons
>  for the cancellation. As far as I remember the conversation he used some
>  words I dare not to repeat in public. Some kids may read the Python dev
>  list. :)
>
>  Christian
>
>
> _______________________________________________
>  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 lists at cheimes.de  Thu Feb 28 21:37:55 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 28 Feb 2008 21:37:55 +0100
Subject: [Python-Dev] Buildbots for trunk are all red
In-Reply-To: <20080228201940.GA23104@phd.pp.ru>
References: <e04bdf310802251203w9b48a75qcaa1b03508e654dd@mail.gmail.com>	<47C32D2D.1030206@free.fr>	<e04bdf310802260322i5b44b12r65efef8cd74a846e@mail.gmail.com>	<47C4813F.2080403@v.loewis.de>	<e04bdf310802261352n6a32183el389095f92e551355@mail.gmail.com>	<bbaeab100802261404w7c670070tfb3997cd2351c097@mail.gmail.com>	<52dc1c820802262146n7b7c211dk973eb44390a4b8f7@mail.gmail.com>	<20080227141322.GA5871@amk-desktop.matrixgroup.net>	<CCD0F39F-1EB9-4379-9107-391EBEF33664@acm.org>	<47C712F6.9040809@cheimes.de>
	<20080228201940.GA23104@phd.pp.ru>
Message-ID: <47C71BA3.6030107@cheimes.de>

Oleg Broytmann wrote:
>    Sorry, can I ask an additional question? These words - what they were
> about? about the architecture of BDBStorage and Subversion, or about the
> very BerkeleyDB, or about what?

I don't know all details and it was several years ago so some of my
saying may not be correct. I wasn't involved in the project. Please
contact Jim Fulton from Zope Corp if you are interested in more details.

More than 5 years ago Zope Corp was working on a Berkeley DB backend for
ZODB. It was more of a marketing decision to show large companies that
ZODB is using a well known database instead of a self made one. The
project failed due to problems with the Berkeley db. I vaguely remember
something with transactions and speed ...

Christian

From barry at python.org  Thu Feb 28 21:51:13 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 28 Feb 2008 15:51:13 -0500
Subject: [Python-Dev] Code freeze?
In-Reply-To: <47C7105A.20908@cheimes.de>
References: <47C7105A.20908@cheimes.de>
Message-ID: <00E337B6-FFC8-43C8-BA9F-142725954320@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 28, 2008, at 2:49 PM, Christian Heimes wrote:

> Hey Barry!

Hi Christian!

> When are you planing to freeze the code of the trunk and branches/py3k
> for the upcoming alpha releases? I'll merge the last modifications  
> from
> 2.6 to 3.0 in a couple of minutes. All tests on Linux are looking  
> good,
> except for the two profile tests on 3.0. I'm going to test Windows  
> later.

Okay, let's go ahead and make it official.

I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern  
(UTC-5) time or 2300 UTC.  Let's freeze the tree one hour prior to  
that: 2200 UTC Friday 29-Feb-2008.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8cewnEjvBPtnXfVAQJSpQP/aWjpFbTAETdHGnp0IOEagaXNojwJEBBl
llFAE6FQI+WjPxNDAG6Y8T0y4kdiBVubMA7yfp+wXZdn+zpO/4D5OtBVeAoGVjLj
Tg1Ws1Y2uEf7Ah4lRqLya1tfgO+rnKJ38vsCit58XACYVGKWDpD0mVu+An7+6Jmj
rtlEjwGpvFQ=
=jIiD
-----END PGP SIGNATURE-----

From barry at python.org  Thu Feb 28 21:55:26 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 28 Feb 2008 15:55:26 -0500
Subject: [Python-Dev] [Python-3000] Code freeze?
In-Reply-To: <4866bea60802281203p29caa500q53de0ddb6fb92a82@mail.gmail.com>
References: <47C7105A.20908@cheimes.de>
	<4866bea60802281203p29caa500q53de0ddb6fb92a82@mail.gmail.com>
Message-ID: <8C97586F-C049-4574-817C-34EB4D4C0C7A@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 28, 2008, at 3:03 PM, Chris Mellon wrote:

> On Thu, Feb 28, 2008 at 1:49 PM, Christian Heimes <lists at cheimes.de>  
> wrote:
>> Hey Barry!
>>
>> When are you planing to freeze the code of the trunk and branches/ 
>> py3k
>> for the upcoming alpha releases? I'll merge the last modifications  
>> from
>> 2.6 to 3.0 in a couple of minutes. All tests on Linux are looking  
>> good,
>> except for the two profile tests on 3.0. I'm going to test Windows  
>> later.
>>
>
> Would a call for third-party module maintainer updates be justified?
> pysqlite in particular has advanced a couple versions since 2.5, and
> it'd be nice if the latest made it into 2.6.

There's still plenty of time for stuff to make it into 2.6 -- this is  
only an alpha release!  I encourage people to get their changes in now  
if they want them reflected in the next alphas, but I intend to cut  
the release from whatever's in svn at 2300 UTC tomorrow.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8cfvnEjvBPtnXfVAQJKSwP+M5RzAFsQ3fNSwwYzRa+j3EaocwLgWJ+i
QVLxALoH+ha6yWQDmdQJCvm4H+DPBSnz9o/ejuJ3Wuhf9TEIWBLjuwB1rM8qm7mB
blaaNVV9eOXfORjlQ3PvwGblfwmGMGFUKfTuta8BZqkxtEzNKL5tDvgVdx98rbTV
VEyfj7ap3BM=
=dsql
-----END PGP SIGNATURE-----

From lists at cheimes.de  Thu Feb 28 22:15:04 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 28 Feb 2008 22:15:04 +0100
Subject: [Python-Dev] Code freeze?
In-Reply-To: <00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
References: <47C7105A.20908@cheimes.de>
	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
Message-ID: <47C72458.8090306@cheimes.de>

Barry Warsaw wrote:
> Okay, let's go ahead and make it official.
> 
> I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern
> (UTC-5) time or 2300 UTC.  Let's freeze the tree one hour prior to
> that: 2200 UTC Friday 29-Feb-2008.

Linux is looking good. I've fixed some minor Windows issue in the last
30 minutes. I found one strange behavior. Some tests were failing
because iter(fileobj) where fileobj is a tempfile._TemporaryFileWrapper
failed. Apparently iter() doesn't use __getattr__ to acquire the
__iter__ method. Is this behavior deliberately?

Christian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/python-dev/attachments/20080228/948cd274/attachment.pgp 

From eric+python-dev at trueblade.com  Thu Feb 28 22:03:28 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 28 Feb 2008 16:03:28 -0500
Subject: [Python-Dev] [Python-3000] Code freeze?
In-Reply-To: <00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
References: <47C7105A.20908@cheimes.de>
	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
Message-ID: <47C721A0.6060802@trueblade.com>

Barry Warsaw wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Feb 28, 2008, at 2:49 PM, Christian Heimes wrote:
> 
>> Hey Barry!
> 
> Hi Christian!
> 
>> When are you planing to freeze the code of the trunk and branches/py3k
>> for the upcoming alpha releases? I'll merge the last modifications  
>> from
>> 2.6 to 3.0 in a couple of minutes. All tests on Linux are looking  
>> good,
>> except for the two profile tests on 3.0. I'm going to test Windows  
>> later.
> 
> Okay, let's go ahead and make it official.
> 
> I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern  
> (UTC-5) time or 2300 UTC.  Let's freeze the tree one hour prior to  
> that: 2200 UTC Friday 29-Feb-2008.

Argh!  I was going to check the last of the PEP 3127 changes in tonight, 
but I won't make it by 6 pm EST.  I have them finished, but no tests 
written, so I'm not comfortable checking them in yet.  I guess it's no 
big deal that they slip until the next alpha.

Eric.


From stephen at xemacs.org  Thu Feb 28 23:07:04 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 29 Feb 2008 07:07:04 +0900
Subject: [Python-Dev] Code freeze?
In-Reply-To: <00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
References: <47C7105A.20908@cheimes.de>
	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
Message-ID: <87hcfsloqf.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern  
 > (UTC-5) time or 2300 UTC.  Let's freeze the tree one hour prior to  
 > that: 2200 UTC Friday 29-Feb-2008.

Is that enough time for the buildbots to do their thing and for you to
look at the page?

Alterntaively, I guess you could just suggest that people check the
buildbot page for their platforms before downloading ....




From barry at python.org  Thu Feb 28 23:07:03 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 28 Feb 2008 17:07:03 -0500
Subject: [Python-Dev] [Python-3000] Code freeze?
In-Reply-To: <47C721A0.6060802@trueblade.com>
References: <47C7105A.20908@cheimes.de>
	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
	<47C721A0.6060802@trueblade.com>
Message-ID: <59F9E6AD-3FED-498B-960A-5CD0426FB409@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 28, 2008, at 4:03 PM, Eric Smith wrote:

> Barry Warsaw wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> On Feb 28, 2008, at 2:49 PM, Christian Heimes wrote:
>>> Hey Barry!
>> Hi Christian!
>>> When are you planing to freeze the code of the trunk and branches/ 
>>> py3k
>>> for the upcoming alpha releases? I'll merge the last  
>>> modifications  from
>>> 2.6 to 3.0 in a couple of minutes. All tests on Linux are looking   
>>> good,
>>> except for the two profile tests on 3.0. I'm going to test  
>>> Windows  later.
>> Okay, let's go ahead and make it official.
>> I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern   
>> (UTC-5) time or 2300 UTC.  Let's freeze the tree one hour prior to   
>> that: 2200 UTC Friday 29-Feb-2008.
>
> Argh!  I was going to check the last of the PEP 3127 changes in  
> tonight, but I won't make it by 6 pm EST.  I have them finished, but  
> no tests written, so I'm not comfortable checking them in yet.  I  
> guess it's no big deal that they slip until the next alpha.

Sorry, I notice my message might not have been clear.  As of this  
writing, you have 23 hours and 54 minute before code freeze :).

Code freeze: 2200 UTC 29-Feb-2008
Alpha making: 2300 UTC 29-Feb-2008

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8cwh3EjvBPtnXfVAQLRSAP/XalWCb1ArFUxoa0OQlA0T7Rw7Si3AFYu
mXRTlU0kqptiYDiHYbPaQwzFwI3xgUBCG5qUnFFq3PCLrxmd6ilYcWAhErSGmxOS
PAWfmrxZElAxqXHviOPQw5dlnoD8JhDudArgn74zRHHluazZYR4r+fCvN8fV0gKc
zRDt8Owdwng=
=uCn6
-----END PGP SIGNATURE-----

From barry at python.org  Thu Feb 28 23:09:45 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 28 Feb 2008 17:09:45 -0500
Subject: [Python-Dev] Code freeze?
In-Reply-To: <87hcfsloqf.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <47C7105A.20908@cheimes.de>
	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
	<87hcfsloqf.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <476595E7-1350-40F1-8E64-EB4EB64F69DB@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 28, 2008, at 5:07 PM, Stephen J. Turnbull wrote:

> Barry Warsaw writes:
>
>> I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern
>> (UTC-5) time or 2300 UTC.  Let's freeze the tree one hour prior to
>> that: 2200 UTC Friday 29-Feb-2008.
>
> Is that enough time for the buildbots to do their thing and for you to
> look at the page?

I don't know, but we'll find out!  The first time (in years) will be a  
bit of a trial-and-error for me.  I can always get dinner in the  
middle of it. :)

> Alterntaively, I guess you could just suggest that people check the
> buildbot page for their platforms before downloading ....

Yes, good idea.  I'm only going to cut source tarballs for the alphas.

- -Barry


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8cxKXEjvBPtnXfVAQLgqwQAiiQUL1lhQM6EmYr8bvZNW2h97ziKGtpf
mVTiNOCJZ1xZ6vKkcmR3Asd+Cwm7B2eT+sVLEpq+Z6tbki+7o0wXC4V6h/ar+zMz
dQcR0QdwM218hioOiIVhtZXbWUTLGndWVviKBcoOdw6qwTbWFspCMV0+FEzdiNUN
V0bDUjn4zkI=
=uPib
-----END PGP SIGNATURE-----

From eric+python-dev at trueblade.com  Fri Feb 29 00:31:45 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Thu, 28 Feb 2008 18:31:45 -0500
Subject: [Python-Dev] [Python-3000] Code freeze?
In-Reply-To: <59F9E6AD-3FED-498B-960A-5CD0426FB409@python.org>
References: <47C7105A.20908@cheimes.de>
	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
	<47C721A0.6060802@trueblade.com>
	<59F9E6AD-3FED-498B-960A-5CD0426FB409@python.org>
Message-ID: <47C74461.20103@trueblade.com>

Barry Warsaw wrote:
>>> Okay, let's go ahead and make it official.
>>> I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern  
>>> (UTC-5) time or 2300 UTC.  Let's freeze the tree one hour prior to  
>>> that: 2200 UTC Friday 29-Feb-2008.
>>
>> Argh!  I was going to check the last of the PEP 3127 changes in 
>> tonight, but I won't make it by 6 pm EST.  I have them finished, but 
>> no tests written, so I'm not comfortable checking them in yet.  I 
>> guess it's no big deal that they slip until the next alpha.
> 
> Sorry, I notice my message might not have been clear.  As of this 
> writing, you have 23 hours and 54 minute before code freeze :).
> 
> Code freeze: 2200 UTC 29-Feb-2008
> Alpha making: 2300 UTC 29-Feb-2008

Your message was clear, it's my reading comprehension that is low.  Now 
you've removed my excuse for not getting this done.  To the keyboard!

Eric.


From facundobatista at gmail.com  Fri Feb 29 01:55:29 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 28 Feb 2008 22:55:29 -0200
Subject: [Python-Dev] Google Summer of Code 2008
In-Reply-To: <1204229696.17465.1239689307@webmail.messagingengine.com>
References: <1204229696.17465.1239689307@webmail.messagingengine.com>
Message-ID: <e04bdf310802281655w3fdbba5dp39b7bd661b3cf928@mail.gmail.com>

2008/2/28, James Tauber <jtauber at jtauber.com>:

> The Google Summer of Code is on again and I've been asked to coordinate
>  the PSF's involvement.

These are great news, specially the second one, :)

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From tnelson at onresolve.com  Fri Feb 29 08:58:57 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Thu, 28 Feb 2008 23:58:57 -0800
Subject: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Message-ID: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>

Howdy,

I'm going through the motions of getting my newly added build slave in a half decent state.  The external.bat and external-amd64.bat files needed the following in order to build db-4.4.20:

Index: external.bat
===================================================================
--- external.bat        (revision 61125)
+++ external.bat        (working copy)
@@ -10,7 +10,8 @@
 @rem Sleepycat db
 if not exist db-4.4.20 svn export http://svn.python.org/projects/external/db-4.4.20
 if not exist db-4.4.20\build_win32\debug\libdb44sd.lib (
-   vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static
+   devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln
+   devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static
 )

 @rem OpenSSL


(This is against trunk, same thing would apply to py3k I guess, given that we're using %VS90COMNTOOLS%vsvars32.bat there too.)

Regards,

        Trent.


--
http://www.onresolve.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: external.bat.patch
Type: application/octet-stream
Size: 589 bytes
Desc: external.bat.patch
Url : http://mail.python.org/pipermail/python-dev/attachments/20080228/629c199f/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: external-amd64.bat.patch
Type: application/octet-stream
Size: 707 bytes
Desc: external-amd64.bat.patch
Url : http://mail.python.org/pipermail/python-dev/attachments/20080228/629c199f/attachment-0003.obj 

From theller at ctypes.org  Fri Feb 29 09:59:23 2008
From: theller at ctypes.org (Thomas Heller)
Date: Fri, 29 Feb 2008 09:59:23 +0100
Subject: [Python-Dev] Fixing buildbot/external(-amd64).bat files on
	Windows
In-Reply-To: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>
References: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>
Message-ID: <fq8hh7$oot$3@ger.gmane.org>

Trent Nelson schrieb:
> Howdy,
> 
> I'm going through the motions of getting my newly added build slave in a half decent state.  The external.bat and external-amd64.bat files needed the following in order to build db-4.4.20:
> 
> Index: external.bat
> ===================================================================
> --- external.bat        (revision 61125)
> +++ external.bat        (working copy)
> @@ -10,7 +10,8 @@
>  @rem Sleepycat db
>  if not exist db-4.4.20 svn export http://svn.python.org/projects/external/db-4.4.20
>  if not exist db-4.4.20\build_win32\debug\libdb44sd.lib (
> -   vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static
> +   devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln
> +   devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static
>  )
> 
>  @rem OpenSSL

This change is fine by me (if it works ;-).  Do you have commit rights, or do you want me
to check it in?

> 
> 
> (This is against trunk, same thing would apply to py3k I guess, given that we're using %VS90COMNTOOLS%vsvars32.bat there too.)

I guess it will be merged automatically by Christian.

Thomas


From theller at ctypes.org  Fri Feb 29 10:06:42 2008
From: theller at ctypes.org (Thomas Heller)
Date: Fri, 29 Feb 2008 10:06:42 +0100
Subject: [Python-Dev] Fixing buildbot/external(-amd64).bat files on
	Windows
In-Reply-To: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>
References: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>
Message-ID: <fq8huu$sf5$1@ger.gmane.org>

Trent Nelson schrieb:
> Howdy,
> 
> I'm going through the motions of getting my newly added build slave in a half decent state.

I think the buildbot should have a name different from 'x86 XP'.
(Martin, Neal?)

Thomas


From scott+python-dev at scottdial.com  Fri Feb 29 09:57:47 2008
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Fri, 29 Feb 2008 03:57:47 -0500
Subject: [Python-Dev] Code freeze?
In-Reply-To: <476595E7-1350-40F1-8E64-EB4EB64F69DB@python.org>
References: <47C7105A.20908@cheimes.de>	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>	<87hcfsloqf.fsf@uwakimon.sk.tsukuba.ac.jp>
	<476595E7-1350-40F1-8E64-EB4EB64F69DB@python.org>
Message-ID: <47C7C90B.5040707@scottdial.com>

Barry Warsaw wrote:
>> Alterntaively, I guess you could just suggest that people check the
>> buildbot page for their platforms before downloading ....
> 
> Yes, good idea.  I'm only going to cut source tarballs for the alphas.
> 

I apologize for having doubt in your plan, and I can certainly 
appreciate the work you will be doing as release manager. But..

I don't understand who these alpha releases are supposed to be for, and 
who they will serve. When I first saw this plan, I thought "ok, you're 
the man.." But now I wonder even more if they are only going to be 
source tarballs. Who is the intended audience of these alphas? It seems 
like cutting only source tarballs is targeting developers, and if that 
is the case, I wonder if you have misplaced your motivations.

I'm not sure what developer outside of the core community would want to 
work with something missing key features and released fairly 
arbitrarily. Ok, I grant you that it's a monthly cycle, but there are no 
feature milestones involved, so it's fairly arbitrary from a utility 
standpoint; it's not clear to me that we are even worrying about all of 
the buildbots being green before releasing.

More to the point, I don't know why a developer wouldn't just checkout 
from SVN in any case. Certainly if they are going to help root out bugs, 
then we would like them to be using the trunk if possible. I fear that 
once an alpha is 2 weeks old, we will start saying "please check if its 
still a problem on the trunk."

A mild concern is how this effects checkins with individuals either 
trying to meet a deadline or even wait until after an alpha release to 
checkin a large change. I'm not sure this will happen, but having 
releases scheduled without feature milestones attached certainly changes 
the environment for work to be done in.

I guess I am hoping to understand better how these alphas serve us. 
Again, I apologize if that sounded judgmental, but I wanted to make sure 
that releasing alphas was the best plan. And again, I appreciate your 
enthusiasm and effort.

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu

From lists at cheimes.de  Fri Feb 29 10:30:22 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 29 Feb 2008 10:30:22 +0100
Subject: [Python-Dev] Fixing buildbot/external(-amd64).bat files on
	Windows
In-Reply-To: <fq8hh7$oot$3@ger.gmane.org>
References: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>
	<fq8hh7$oot$3@ger.gmane.org>
Message-ID: <fq8jbf$1hn$1@ger.gmane.org>

Thomas Heller wrote:
> I guess it will be merged automatically by Christian.

I won't have time today. Sorry

Christian


From tnelson at onresolve.com  Fri Feb 29 10:50:49 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Fri, 29 Feb 2008 01:50:49 -0800
Subject: [Python-Dev] Fixing buildbot/external(-amd64).bat files
	on	Windows
In-Reply-To: <fq8huu$sf5$1@ger.gmane.org>
References: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>
	<fq8huu$sf5$1@ger.gmane.org>
Message-ID: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C617@EXMBX04.exchhosting.com>

> > I'm going through the motions of getting my newly added build slave
> in a half decent state.
>
> I think the buildbot should have a name different from 'x86 XP'.
> (Martin, Neal?)
>
> Thomas

Yeah, I've dropped Martin a note regarding this.  The community bots refer to Windows Server 2003 boxes as just that, so perhaps a rename to 'x86 Windows Server 2008' is appropriate.  FWIW as it's a 64-bit box, I'm hoping to get a slave set up for 'x64 Windows Server 2008' as well.

(As far as I can see, the x64/x86 nature of the slave is dictated by the master, correct?  i.e. I can't tweak/clone this myself?)

        Trent.

From lists at cheimes.de  Fri Feb 29 10:56:52 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 29 Feb 2008 10:56:52 +0100
Subject: [Python-Dev] Fixing buildbot/external(-amd64).bat files on
	Windows
In-Reply-To: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>
References: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>
Message-ID: <fq8kt4$6a2$1@ger.gmane.org>

Trent Nelson wrote:
> -   vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static
> +   devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln
> +   devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static

The upgrade is requires only once. It probably belongs next to the
checkout or svn up and not in the build section.

Christian


From g.brandl at gmx.net  Fri Feb 29 11:21:47 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 29 Feb 2008 11:21:47 +0100
Subject: [Python-Dev] Code freeze?
In-Reply-To: <47C7C90B.5040707@scottdial.com>
References: <47C7105A.20908@cheimes.de>	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>	<87hcfsloqf.fsf@uwakimon.sk.tsukuba.ac.jp>	<476595E7-1350-40F1-8E64-EB4EB64F69DB@python.org>
	<47C7C90B.5040707@scottdial.com>
Message-ID: <fq8mbo$cb2$1@ger.gmane.org>

Scott Dial schrieb:
> Barry Warsaw wrote:
>>> Alterntaively, I guess you could just suggest that people check the
>>> buildbot page for their platforms before downloading ....
>> 
>> Yes, good idea.  I'm only going to cut source tarballs for the alphas.
>> 
> 
> I apologize for having doubt in your plan, and I can certainly 
> appreciate the work you will be doing as release manager. But..
> 
> I don't understand who these alpha releases are supposed to be for, and 
> who they will serve. When I first saw this plan, I thought "ok, you're 
> the man.." But now I wonder even more if they are only going to be 
> source tarballs. Who is the intended audience of these alphas? It seems 
> like cutting only source tarballs is targeting developers, and if that 
> is the case, I wonder if you have misplaced your motivations.
> 
> I'm not sure what developer outside of the core community would want to 
> work with something missing key features and released fairly 
> arbitrarily. Ok, I grant you that it's a monthly cycle, but there are no 
> feature milestones involved, so it's fairly arbitrary from a utility 
> standpoint; it's not clear to me that we are even worrying about all of 
> the buildbots being green before releasing.
> 
> More to the point, I don't know why a developer wouldn't just checkout 
> from SVN in any case. Certainly if they are going to help root out bugs, 
> then we would like them to be using the trunk if possible. I fear that 
> once an alpha is 2 weeks old, we will start saying "please check if its 
> still a problem on the trunk."

For one thing, releases generate "news", meaning that people will be made
aware that things are moving, that Python is well underway to its next
major versions, and maybe will be more inclined to look at what's new,
or check out a release.

For some people, the label "alpha X" is more acceptable than "SVN version",
even for projects whose SVN trunk is generally quite stable as is the
case with Python.

Even if that's the only thing accomplished by the alpha releases, they do
not do any harm.

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 mail at timgolden.me.uk  Fri Feb 29 11:28:37 2008
From: mail at timgolden.me.uk (Tim Golden)
Date: Fri, 29 Feb 2008 10:28:37 +0000
Subject: [Python-Dev] Code freeze?
In-Reply-To: <fq8mbo$cb2$1@ger.gmane.org>
References: <47C7105A.20908@cheimes.de>	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>	<87hcfsloqf.fsf@uwakimon.sk.tsukuba.ac.jp>	<476595E7-1350-40F1-8E64-EB4EB64F69DB@python.org>	<47C7C90B.5040707@scottdial.com>
	<fq8mbo$cb2$1@ger.gmane.org>
Message-ID: <47C7DE55.9010301@timgolden.me.uk>

Georg Brandl wrote:
> For one thing, releases generate "news", meaning that people will be made
> aware that things are moving, that Python is well underway to its next
> major versions, and maybe will be more inclined to look at what's new,
> or check out a release.

I'd like to second that point of view: there's a kind of psychology of
the web which presumes that a lack of activity on a project's release
page indicates a defunct project. Even though you'd have to be really
quite perverse to suggest that Python is stagnant, the fact of being
able to announce to the world at large: "we're cutting our first 2.6
alpha release this Friday" is a clear indication that things are
happening in the Python world. Even if, as an earlier poster suggested,
all you're really doing is tagging a particular revision of your
Subversion tree.

TJG


From ncoghlan at gmail.com  Fri Feb 29 12:39:22 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 29 Feb 2008 21:39:22 +1000
Subject: [Python-Dev] [Python-3000] Code freeze?
In-Reply-To: <47C72458.8090306@cheimes.de>
References: <47C7105A.20908@cheimes.de>	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
	<47C72458.8090306@cheimes.de>
Message-ID: <47C7EEEA.3080405@gmail.com>

Christian Heimes wrote:
> Barry Warsaw wrote:
>> Okay, let's go ahead and make it official.
>>
>> I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern
>> (UTC-5) time or 2300 UTC.  Let's freeze the tree one hour prior to
>> that: 2200 UTC Friday 29-Feb-2008.
> 
> Linux is looking good. I've fixed some minor Windows issue in the last
> 30 minutes. I found one strange behavior. Some tests were failing
> because iter(fileobj) where fileobj is a tempfile._TemporaryFileWrapper
> failed. Apparently iter() doesn't use __getattr__ to acquire the
> __iter__ method. Is this behavior deliberately?

The interpreter is actually permitted to bypass the instance when 
looking up magic methods. Whether it does or not is implementation 
dependent - even CPython varies its behaviour depending on the specific 
circumstance (e.g. the translation of with statements to bytecode ends 
up using normal GET_ATTR opcodes, so those will see __enter__ and 
__exit__ methods on instances, but most of the magic method lookups from 
C code bypass the instance and go straight to the relevant tp_* slot).

I'd call this behaviour a bug in _TemporaryFileWrapper, since it's 
delegation trick in __getattr__ isn't guaranteed to work for the magic 
methods. I'm actually becoming less and less enamoured of that shortcut 
every day - given that we've already had to spell out the file method 
and property delegation for SpooledTemporaryFile in 2.6, I'm tempted to 
start spelling it out for _TemporaryFileWrapper as well.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From barry at python.org  Fri Feb 29 13:00:44 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Feb 2008 07:00:44 -0500
Subject: [Python-Dev] Code freeze?
In-Reply-To: <fq8mbo$cb2$1@ger.gmane.org>
References: <47C7105A.20908@cheimes.de>	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>	<87hcfsloqf.fsf@uwakimon.sk.tsukuba.ac.jp>	<476595E7-1350-40F1-8E64-EB4EB64F69DB@python.org>
	<47C7C90B.5040707@scottdial.com> <fq8mbo$cb2$1@ger.gmane.org>
Message-ID: <44FA87F7-324E-4D2A-9005-820195A4F423@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 29, 2008, at 5:21 AM, Georg Brandl wrote:

> Scott Dial schrieb:
>> Barry Warsaw wrote:
>>>> Alterntaively, I guess you could just suggest that people check the
>>>> buildbot page for their platforms before downloading ....
>>>
>>> Yes, good idea.  I'm only going to cut source tarballs for the  
>>> alphas.
>>>
>>
>> I apologize for having doubt in your plan, and I can certainly
>> appreciate the work you will be doing as release manager. But..
>>
>> I don't understand who these alpha releases are supposed to be for,  
>> and
>> who they will serve.
>
> For one thing, releases generate "news", meaning that people will be  
> made
> aware that things are moving, that Python is well underway to its next
> major versions, and maybe will be more inclined to look at what's new,
> or check out a release.

I completely agree.

There's another very important aspect of doing alpha releases, and  
that is to debug the /process/ of releasing.  I need to see how far  
we've come in the years since I RM'd last.  How smoothly we can  
coordinate all the various players?  What does it take to update the  
website?  Where are the glitches in the process that slows everything  
down or blocks certain steps?  What is the state of the tools, and is  
there anything else we can automate?

I also want to see if sticking to the monthly cycle can make us all  
work more productively as a community, so that we know when bugs need  
to be fixed in order to show up in the next release, and so on.

Think of it this way: the alphas are for /us/ as much as for our users.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8fz7XEjvBPtnXfVAQI0zgQAnp8nva5qxIoN4ocr7uNXeNxJ+BdP2lMA
8GN1kv3R/+9ny6h/iakfyE0lt1hvHP+uchchd4zo1CWQ390h1W8eR0SpzbubRYFP
Bvdnup7K1zSSGe0ILGoa6Zv8VCYI4vET0PsxM+bkhj8NblwQQu1xUcc6CnYBtapM
c9TwZum/ODg=
=A2cs
-----END PGP SIGNATURE-----

From ncoghlan at gmail.com  Fri Feb 29 13:39:42 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 29 Feb 2008 22:39:42 +1000
Subject: [Python-Dev] Code freeze?
In-Reply-To: <44FA87F7-324E-4D2A-9005-820195A4F423@python.org>
References: <47C7105A.20908@cheimes.de>	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>	<87hcfsloqf.fsf@uwakimon.sk.tsukuba.ac.jp>	<476595E7-1350-40F1-8E64-EB4EB64F69DB@python.org>	<47C7C90B.5040707@scottdial.com>
	<fq8mbo$cb2$1@ger.gmane.org>
	<44FA87F7-324E-4D2A-9005-820195A4F423@python.org>
Message-ID: <47C7FD0E.3090306@gmail.com>

Barry Warsaw wrote:
> Think of it this way: the alphas are for /us/ as much as for our users.

In that vein, I think the monthly alphas may also help as a means for 
setting personal deadlines for things we're working on. "Implement for 
2.6" is a bit of a wishy-washy deadline at some vague point in the 
future - it doesn't provide much impetus to sit down and spend an 
afternoon or evening getting it done. "Implement for next 2.6 alpha, 
which will be cut in 3 weeks, 2 days and 16 hours" is a real concrete 
target that can be aimed for (even if I'm the only person that knows I'm 
aiming for it for a given bug fix or feature).

It should also motivate at least a monthly review of the buildbot 
status, and is already motivating a push towards making the buildbots a 
more reliable indicator of the health of the source tree.

Sure, they may mostly be internal milestones (with third parties waiting 
for a feature-complete alpha or the first beta), but I think there is a 
decent chance the approach will turn out to be beneficial.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From barry at python.org  Fri Feb 29 13:57:13 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Feb 2008 07:57:13 -0500
Subject: [Python-Dev] Code freeze?
In-Reply-To: <47C7FD0E.3090306@gmail.com>
References: <47C7105A.20908@cheimes.de>	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>	<87hcfsloqf.fsf@uwakimon.sk.tsukuba.ac.jp>	<476595E7-1350-40F1-8E64-EB4EB64F69DB@python.org>	<47C7C90B.5040707@scottdial.com>
	<fq8mbo$cb2$1@ger.gmane.org>
	<44FA87F7-324E-4D2A-9005-820195A4F423@python.org>
	<47C7FD0E.3090306@gmail.com>
Message-ID: <7FF2D914-8120-487E-A962-D306CA53F888@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 29, 2008, at 7:39 AM, Nick Coghlan wrote:

> Barry Warsaw wrote:
>> Think of it this way: the alphas are for /us/ as much as for our  
>> users.
>
> In that vein, I think the monthly alphas may also help as a means  
> for setting personal deadlines for things we're working on.  
> "Implement for 2.6" is a bit of a wishy-washy deadline at some vague  
> point in the future - it doesn't provide much impetus to sit down  
> and spend an afternoon or evening getting it done. "Implement for  
> next 2.6 alpha, which will be cut in 3 weeks, 2 days and 16 hours"  
> is a real concrete target that can be aimed for (even if I'm the  
> only person that knows I'm aiming for it for a given bug fix or  
> feature).
>
> It should also motivate at least a monthly review of the buildbot  
> status, and is already motivating a push towards making the  
> buildbots a more reliable indicator of the health of the source tree.
>
> Sure, they may mostly be internal milestones (with third parties  
> waiting for a feature-complete alpha or the first beta), but I think  
> there is a decent chance the approach will turn out to be beneficial.

That's my hope too!
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8gBKnEjvBPtnXfVAQK5egP+JgrZd68JtkyhLOGhcd0aBjhQEJM4e2FO
HcRION8EeI4jhg5KQWOt/KmP6CBLblGq50RFI0afsLaJVapk4U6MFTB0LQus3LgX
myd0zK5egu+sblFfKFfe5mMKn5T1Mx5HCLuOE4g3uwuFtdddsGMvYwCyqjm3smq1
T38bbujy234=
=xSv1
-----END PGP SIGNATURE-----

From tnelson at onresolve.com  Fri Feb 29 15:18:20 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Fri, 29 Feb 2008 06:18:20 -0800
Subject: [Python-Dev] Fixing buildbot/external(-amd64).bat files
	on	Windows
In-Reply-To: <fq8kt4$6a2$1@ger.gmane.org>
References: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>
	<fq8kt4$6a2$1@ger.gmane.org>
Message-ID: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C67C@EXMBX04.exchhosting.com>

Christian Heimes:
> Trent Nelson wrote:
> > -   vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug
> /project db_static
> > +   devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln
> > +   devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug
> /project db_static
>
> The upgrade is requires only once. It probably belongs next to the
> checkout or svn up and not in the build section.

Makes sense.  So we're looking at something like:

@rem Sleepycat db
if not exist db-4.4.20 (
    svn export http://svn.python.org/projects/external/db-4.4.20
    devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln
)
if not exist db-4.4.20\build_win32\debug\libdb44sd.lib (
    devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug
)

I'll test this when I get to work and report back.

        Trent.


--
http://www.onresolve.com


From theller at ctypes.org  Fri Feb 29 15:25:15 2008
From: theller at ctypes.org (Thomas Heller)
Date: Fri, 29 Feb 2008 15:25:15 +0100
Subject: [Python-Dev] Fixing buildbot/external(-amd64).bat files on
	Windows
In-Reply-To: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C67C@EXMBX04.exchhosting.com>
References: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>	<fq8kt4$6a2$1@ger.gmane.org>
	<87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C67C@EXMBX04.exchhosting.com>
Message-ID: <fq94ka$1ki$1@ger.gmane.org>

Trent Nelson schrieb:
> Christian Heimes:
>> Trent Nelson wrote:
>> > -   vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug
>> /project db_static
>> > +   devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln
>> > +   devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug
>> /project db_static
>>
>> The upgrade is requires only once. It probably belongs next to the
>> checkout or svn up and not in the build section.
> 
> Makes sense.  So we're looking at something like:
> 
> @rem Sleepycat db
> if not exist db-4.4.20 (
>     svn export http://svn.python.org/projects/external/db-4.4.20
>     devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln
> )
> if not exist db-4.4.20\build_win32\debug\libdb44sd.lib (
>     devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug
> )
> 
> I'll test this when I get to work and report back.

Great.

What's the difference between these two?

  vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug

  devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug

Thomas


From ncoghlan at gmail.com  Fri Feb 29 15:30:39 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 01 Mar 2008 00:30:39 +1000
Subject: [Python-Dev] [Python-3000] Code freeze?
In-Reply-To: <fq908c$gaq$1@ger.gmane.org>
References: <47C7105A.20908@cheimes.de>	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>	<47C72458.8090306@cheimes.de>	<47C7EEEA.3080405@gmail.com>
	<fq908c$gaq$1@ger.gmane.org>
Message-ID: <47C8170F.2050003@gmail.com>

Christian Heimes wrote:
> Is this documented somewhere? The docs say "See the
> :meth:`__getattribute__` method below for a way to actually get total
> control over attribute access.".

I just checked, and the restriction is now documented in the development 
docs in the section on special methods at [1]. It was backported from 
the Py3k docs and isn't part of the docs for 2.5 or earlier versions.

The gist is that special methods *must* be defined directly on a 
new-style class in order for the interpreter to reliably access them, 
but defining them on a new-style instance *may* still affect the 
interpreter's behaviour in some cases (but won't necessarily do so).

In composing this response, I also realised why the new tempfile tests 
worked for me before I checked them in: I was testing it on the trunk, 
where _TemporaryFileWrapper is a classic class. Special method lookup on 
classic classes doesn't include the 'direct-to-type' optimisation, so 
those tests work with the tempfile module as written on 2.x.

Unfortunately, proxies like _TemporaryFileWrapper that rely on 
__getattr__ to provide special methods simply won't work properly when 
implemented as new-style classes - for that, they need to spell out the 
overridden special methods the way SpooledTemporaryFile does.

I think we may need a -3 warning that detects situations where "__*__" 
attributes are retrieved via a __getattr__ implementation on a classic 
class - classes being used that way have a very high chance of breaking 
when ported to 3.0 and I can't see any possible way for 2to3 to detect them.

Cheers,
Nick.

[1]
http://docs.python.org/dev/reference/datamodel.html#special-method-names

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From lists at cheimes.de  Fri Feb 29 15:50:19 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 29 Feb 2008 15:50:19 +0100
Subject: [Python-Dev] Fixing buildbot/external(-amd64).bat files on
	Windows
In-Reply-To: <fq94ka$1ki$1@ger.gmane.org>
References: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>	<fq8kt4$6a2$1@ger.gmane.org>	<87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C67C@EXMBX04.exchhosting.com>
	<fq94ka$1ki$1@ger.gmane.org>
Message-ID: <fq963b$72o$1@ger.gmane.org>

Thomas Heller wrote:
> What's the difference between these two?
> 
>   vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug
> 
>   devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug

Devenv is the name of the VS GUI executable but it can *also* be used as
a CLI to build stuff. devenv doesn't work for Express Edition.

vcbuild seems to be the preferred CLI app to build a project but it's
limited. I think it doesn't support /upgrade.

MvL probably has a better answer ;)

Christian


From lists at cheimes.de  Fri Feb 29 15:54:39 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 29 Feb 2008 15:54:39 +0100
Subject: [Python-Dev] Code freeze?
In-Reply-To: <47C8170F.2050003@gmail.com>
References: <47C7105A.20908@cheimes.de>	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>	<47C72458.8090306@cheimes.de>	<47C7EEEA.3080405@gmail.com>	<fq908c$gaq$1@ger.gmane.org>
	<47C8170F.2050003@gmail.com>
Message-ID: <47C81CAF.6070004@cheimes.de>

Nick Coghlan wrote:
> In composing this response, I also realised why the new tempfile tests 
> worked for me before I checked them in: I was testing it on the trunk, 
> where _TemporaryFileWrapper is a classic class. Special method lookup on 
> classic classes doesn't include the 'direct-to-type' optimisation, so 
> those tests work with the tempfile module as written on 2.x.

tempfile is also using different implementation for TemporaryFile on
Win32. On Windows it's an alias for NamedTemporaryFile while on Unix
it's using a file descriptor of an unlinked file.

Christian

From tnelson at onresolve.com  Fri Feb 29 17:01:15 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Fri, 29 Feb 2008 08:01:15 -0800
Subject: [Python-Dev] Fixing buildbot/external(-amd64).bat files
	on	Windows
In-Reply-To: <fq963b$72o$1@ger.gmane.org>
References: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>
	<fq8kt4$6a2$1@ger.gmane.org>
	<87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C67C@EXMBX04.exchhosting.com>
	<fq94ka$1ki$1@ger.gmane.org>,<fq963b$72o$1@ger.gmane.org>
Message-ID: <87D3F9C72FBF214DB39FA4E3FE618CDC6E160CEDD5@EXMBX04.exchhosting.com>

Christian Heimes:
> Thomas Heller wrote:
> > What's the difference between these two?
> >
> >   vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug
> >
> >   devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug
>
> Devenv is the name of the VS GUI executable but it can *also* be used as
> a CLI to build stuff. devenv doesn't work for Express Edition.
>
> vcbuild seems to be the preferred CLI app to build a project but it's
> limited. I think it doesn't support /upgrade.

Hummm.  My answer would be more along the lines of "devenv works, vcbuild doesn't" ;-)

S:\buildbots\python\trunk.nelson-windows\db-4.4.20\build_win32>vcbuild Berkeley_DB.sln /build Debug /project db_static
Microsoft (R) Visual C++ Project Builder - Command Line Version 9.00.21022
Copyright (C) Microsoft Corporation. All rights reserved.
vcbuild.exe : warning VCBLD6002: invalid option /build specified.  The option was ignored.
vcbuild.exe : warning VCBLD6002: invalid option /project specified.  The option was ignored.
vcbuild.exe : warning VCBLD6002: invalid option db_static specified.  The option was ignored.
vcbuild.exe : error VCBLD0006: invalid configuration name: DEBUG.

Compare this to:

S:\buildbots\python\trunk.nelson-windows\db-4.4.20\build_win32>devenv Berkeley_DB.sln /build Debug /project db_static
Microsoft (R) Visual Studio Version 9.0.21022.8.
Copyright (C) Microsoft Corp. All rights reserved.
========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

I don't know how the existing vcbuild line ever worked, given the following output from vcbuild /?:

Usage: vcbuild [options] [project|solution] [config|$ALL]



    Trent.


From lists at cheimes.de  Fri Feb 29 17:05:35 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 29 Feb 2008 17:05:35 +0100
Subject: [Python-Dev] Fixing buildbot/external(-amd64).bat files on
	Windows
In-Reply-To: <87D3F9C72FBF214DB39FA4E3FE618CDC6E160CEDD5@EXMBX04.exchhosting.com>
References: <87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C60B@EXMBX04.exchhosting.com>	<fq8kt4$6a2$1@ger.gmane.org>	<87D3F9C72FBF214DB39FA4E3FE618CDC6E1657C67C@EXMBX04.exchhosting.com>	<fq94ka$1ki$1@ger.gmane.org>,
	<fq963b$72o$1@ger.gmane.org>
	<87D3F9C72FBF214DB39FA4E3FE618CDC6E160CEDD5@EXMBX04.exchhosting.com>
Message-ID: <fq9agf$orn$1@ger.gmane.org>

Trent Nelson wrote:
> S:\buildbots\python\trunk.nelson-windows\db-4.4.20\build_win32>devenv Berkeley_DB.sln /build Debug /project db_static
> Microsoft (R) Visual Studio Version 9.0.21022.8.
> Copyright (C) Microsoft Corp. All rights reserved.
> ========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
> 
> I don't know how the existing vcbuild line ever worked, given the following output from vcbuild /?:
> 
> Usage: vcbuild [options] [project|solution] [config|$ALL]

Try:

vcbuild /useenv db_static.vcproj "Debug|Win32"

Christian


From status at bugs.python.org  Fri Feb 29 18:06:14 2008
From: status at bugs.python.org (Tracker)
Date: Fri, 29 Feb 2008 18:06:14 +0100 (CET)
Subject: [Python-Dev] Summary of Tracker Issues
Message-ID: <20080229170614.C9C3F7810A@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (02/22/08 - 02/29/08)
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.


 1711 open (+34) / 12326 closed (+13) / 14037 total (+47)

Open issues with patches:   457

Average duration of open issues: 741 days.
Median duration of open issues: 1110 days.

Open Issues Breakdown
   open  1690 (+34)
pending    21 ( +0)

Issues Created Or Reopened (50)
_______________________________

sqlite numeric type conversion problems                          02/27/08
       http://bugs.python.org/issue2157    reopened ghaering                  
       patch                                                                   

dl broken on non-ILP32 platforms                                 02/22/08
CLOSED http://bugs.python.org/issue2164    created  notting                   
                                                                               

Fix for test_logging                                             02/23/08
CLOSED http://bugs.python.org/issue2165    created  therve                    
                                                                               

pydistutils.cfg won't be found on Windows                        02/23/08
       http://bugs.python.org/issue2166    created  tarek                     
                                                                               

Remove unused imports                                            02/23/08
CLOSED http://bugs.python.org/issue2167    created  calvin                    
       patch                                                                   

gdbm needs to be iterable                                        02/23/08
CLOSED http://bugs.python.org/issue2168    created  therve                    
       patch                                                                   

Adding DOCTYPE and "html", "body" tags to SimpleHTTPServer       02/23/08
CLOSED http://bugs.python.org/issue2169    created  ajaksu2                   
                                                                               

rewrite of minidom.Node.normalize                                02/23/08
       http://bugs.python.org/issue2170    created  maltehelmert              
                                                                               

Add map, filter, zip to future_builtins                          02/24/08
       http://bugs.python.org/issue2171    created  georg.brandl              
                                                                               

Add doc-string to UserDict and DictMixin                         02/24/08
       http://bugs.python.org/issue2172    created  belopolsky                
       patch                                                                   

Python fails silently on bad locale                              02/24/08
       http://bugs.python.org/issue2173    created  motteneder                
                                                                               

xml.sax.xmlreader does not support the InputSource protocol      02/24/08
       http://bugs.python.org/issue2174    created  ygale                     
                                                                               

Expat sax parser silently ignores the InputSource protocol       02/24/08
       http://bugs.python.org/issue2175    created  ygale                     
                                                                               

Undocumented lastrowid attribute i sqlite3 cursor class          02/24/08
       http://bugs.python.org/issue2176    created  bukaj                     
                                                                               

Update compiler module to handle class decorators                02/24/08
CLOSED http://bugs.python.org/issue2177    created  therve                    
       patch                                                                   

Problems with Belarusian Latin locale                            02/24/08
       http://bugs.python.org/issue2178    created  booxter                   
                                                                               

with should be as fast as try/finally                            02/24/08
       http://bugs.python.org/issue2179    created  jyasskin                  
                                                                               

tokenize: mishandles line joining                                02/25/08
       http://bugs.python.org/issue2180    created  jaredgrubb                
                                                                               

optimize out local variables at end of function                  02/25/08
       http://bugs.python.org/issue2181    created  nnorwitz                  
       patch, patch                                                            

tokenize: does not allow CR for a newline                        02/25/08
       http://bugs.python.org/issue2182    created  jaredgrubb                
                                                                               

optimize list comprehensions                                     02/25/08
       http://bugs.python.org/issue2183    created  nnorwitz                  
       patch, patch                                                            

Speed up Thread.start()                                          02/25/08
CLOSED http://bugs.python.org/issue2184    created  jyasskin                  
       patch, patch                                                            

code objects should conserve memory                              02/25/08
       http://bugs.python.org/issue2185    created  nnorwitz                  
       patch, patch                                                            

map and filter shouldn't support None as first argument (in Py3k 02/25/08
       http://bugs.python.org/issue2186    created  gvanrossum                
       patch, easy                                                             

map and filter objects shouldn't call themselves itertools.imap  02/25/08
       http://bugs.python.org/issue2187    created  gvanrossum                
       easy                                                                    

[patch] urllib2 hint - disabled ProxyHandler()                   02/25/08
       http://bugs.python.org/issue2188    created  techtonik                 
                                                                               

urllib.quote() throws KeyError when passed an iterator           02/25/08
       http://bugs.python.org/issue2189    created  djc                       
                                                                               

MozillaCookieJar ignore HttpOnly cookies                         02/25/08
       http://bugs.python.org/issue2190    created  douyuan                   
       patch                                                                   

SubProcess Startup error                                         02/25/08
CLOSED http://bugs.python.org/issue2191    created  madhusudan.sk             
                                                                               

error with backslash as last character in raw string             02/25/08
CLOSED http://bugs.python.org/issue2192    created  aka                       
                                                                               

Cookie Colon Name Bug                                            02/26/08
       http://bugs.python.org/issue2193    created  BM                        
                                                                               

Tiny patch to docs                                               02/26/08
CLOSED http://bugs.python.org/issue2194    created  tim.golden                
       patch                                                                   

urlparse() does not handle URLs with port numbers properly       02/26/08
       http://bugs.python.org/issue2195    created  gawain                    
                                                                               

Fix hasattr's exception problems                                 02/26/08
       http://bugs.python.org/issue2196    created  benjamin.peterson         
       patch                                                                   

Further simplify dict literal bytecode                           02/27/08
       http://bugs.python.org/issue2197    created  belopolsky                
       patch                                                                   

code_hash() can be the same for different code objects           02/27/08
       http://bugs.python.org/issue2198    created  sdeibel                   
                                                                               

cPickle error with gtk GEnum classes                             02/28/08
       http://bugs.python.org/issue2199    created  pyscripter                
                                                                               

find_executable fails to find .bat files on win32                02/28/08
       http://bugs.python.org/issue2200    created  abbot                     
                                                                               

Documentation Section 4.4                                        02/28/08
CLOSED http://bugs.python.org/issue2201    created  str8lazy                  
                                                                               

urllib2 fails against IIS 6.0 (No support for MD5-sess auth)     02/28/08
       http://bugs.python.org/issue2202    created  bwmcadams                 
       easy                                                                    

ssl module getpeercert returns empty dict when cert_reqs=ssl.CER 02/28/08
       http://bugs.python.org/issue2203    created  mryden                    
                                                                               

document ConfigParser behaviour when a file has same section mul 02/28/08
       http://bugs.python.org/issue2204    created  draghuram                 
                                                                               

os.times() returns incorrect value                               02/29/08
CLOSED http://bugs.python.org/issue2205    created  kwatch                    
       patch                                                                   

critical memory leak in hashlib.md5                              02/29/08
CLOSED http://bugs.python.org/issue2206    created  agateriver                
                                                                               

Bug in Sphinx highlighting when pygments not available           02/29/08
       http://bugs.python.org/issue2207    created  tim.golden                
       patch                                                                   

Patch to doc/make.bat to allow non-standard HTML Help location   02/29/08
       http://bugs.python.org/issue2208    created  tim.golden                
       patch                                                                   

mailbox module doesn't support compressed mbox                   02/29/08
       http://bugs.python.org/issue2209    created  jae                       
                                                                               

Nested module import clutters package namespace                  02/29/08
       http://bugs.python.org/issue2210    created  ruediger.kupper           
                                                                               

Enhance file.readlines by making line separator selectable       02/27/08
       http://bugs.python.org/issue1152248 reopened rhettinger                
                                                                               

thread + import => crashes?                                      02/24/08
       http://bugs.python.org/issue1720705 reopened ncoghlan                  
                                                                               



Issues Now Closed (73)
______________________

Test issue                                                        177 days
       http://bugs.python.org/issue1064    loewis                    
       patch                                                                   

race in SocketServer.ForkingMixIn.collect_children                161 days
       http://bugs.python.org/issue1183    jyasskin                  
       patch                                                                   

test_resource fails on recent linux systems                       129 days
       http://bugs.python.org/issue1291    akuchling                 
       easy                                                                    

Embedded python reinitialization                                  127 days
       http://bugs.python.org/issue1306    tiran                     
                                                                               

os.path.exists(os.devnull) regression on windows                  124 days
       http://bugs.python.org/issue1311    akuchling                 
                                                                               

BaseHTTPServer hard-codes Content-Type for error messages          92 days
       http://bugs.python.org/issue1492    georg.brandl              
       easy                                                                    

Problem with httplib and Content-Length: -1                        71 days
       http://bugs.python.org/issue1627    georg.brandl              
       easy                                                                    

Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.        70 days
       http://bugs.python.org/issue1682    jyasskin                  
       patch                                                                   

Backport of PEP 3129 "class decorators"                            46 days
       http://bugs.python.org/issue1759    tiran                     
       patch                                                                   

Inheriting from ABCs makes classes slower.                         51 days
       http://bugs.python.org/issue1762    jyasskin                  
                                                                               

ConfigParser: add_section('DEFAULT') causes duplicate sections.    44 days
       http://bugs.python.org/issue1781    facundobatista            
       patch, easy                                                             

msilib.add_data() takes exactly three parameters                   40 days
       http://bugs.python.org/issue1825    georg.brandl              
       patch, easy                                                             

operator.attrgetter() should accept dotted attribute paths         40 days
       http://bugs.python.org/issue1826    georg.brandl              
       easy                                                                    

unhelpful error when calling "python <dirname>"                    34 days
       http://bugs.python.org/issue1877    ncoghlan                  
       easy                                                                    

increase parser stack limit                                        33 days
       http://bugs.python.org/issue1881    tiran                     
                                                                               

Document that with is slower than try/finally                      33 days
       http://bugs.python.org/issue1910    jyasskin                  
       easy                                                                    

[patch] syslogmodule: Release GIL when calling syslog(3)           26 days
       http://bugs.python.org/issue1957    tiran                     
       patch, easy                                                             

Slight adjustment to sphinx print-media stylesheet                 25 days
       http://bugs.python.org/issue1964    georg.brandl              
       patch                                                                   

io.StringIO allows any parameter                                   25 days
       http://bugs.python.org/issue1986    georg.brandl              
                                                                               

PYO file permission problem                                        15 days
       http://bugs.python.org/issue2051    tiran                     
                                                                               

file.__exit__ does not call subclass' close method                 12 days
       http://bugs.python.org/issue2067    schmir                    
                                                                               

SimpleXMLRPCServer documentation about  rpc_paths might be wrong   12 days
       http://bugs.python.org/issue2072    akuchling                 
                                                                               

xml.dom documentation doesn't match implementation                 10 days
       http://bugs.python.org/issue2101    georg.brandl              
       easy                                                                    

Implement __format__ for Decimal                                   15 days
       http://bugs.python.org/issue2110    marketdickinson           
       patch                                                                   

[feature-request] Please add bool data type to "optparse" module    7 days
       http://bugs.python.org/issue2130    facundobatista            
       easy                                                                    

os.environ should inherit dict                                      4 days
       http://bugs.python.org/issue2144    belopolsky                
       patch                                                                   

Queue.maxsize, __init__() accepts any value as maxsize              3 days
       http://bugs.python.org/issue2149    benjamin.peterson         
                                                                               

STORE_LOCAL byte code is not documented                             1 days
       http://bugs.python.org/issue2161    georg.brandl              
                                                                               

test_socket is flakey                                               3 days
       http://bugs.python.org/issue2163    gvanrossum                
       easy                                                                    

dl broken on non-ILP32 platforms                                    0 days
       http://bugs.python.org/issue2164    loewis                    
                                                                               

Fix for test_logging                                                0 days
       http://bugs.python.org/issue2165    georg.brandl              
                                                                               

Remove unused imports                                               0 days
       http://bugs.python.org/issue2167    tiran                     
       patch                                                                   

gdbm needs to be iterable                                           2 days
       http://bugs.python.org/issue2168    rhettinger                
       patch                                                                   

Adding DOCTYPE and "html", "body" tags to SimpleHTTPServer          5 days
       http://bugs.python.org/issue2169    akuchling                 
                                                                               

Update compiler module to handle class decorators                   1 days
       http://bugs.python.org/issue2177    facundobatista            
       patch                                                                   

Speed up Thread.start()                                             3 days
       http://bugs.python.org/issue2184    jyasskin                  
       patch, patch                                                            

SubProcess Startup error                                            0 days
       http://bugs.python.org/issue2191    madhusudan.sk             
                                                                               

error with backslash as last character in raw string                1 days
       http://bugs.python.org/issue2192    aka                       
                                                                               

Tiny patch to docs                                                  0 days
       http://bugs.python.org/issue2194    georg.brandl              
       patch                                                                   

Documentation Section 4.4                                           0 days
       http://bugs.python.org/issue2201    str8lazy                  
                                                                               

os.times() returns incorrect value                                  1 days
       http://bugs.python.org/issue2205    georg.brandl              
       patch                                                                   

critical memory leak in hashlib.md5                                 0 days
       http://bugs.python.org/issue2206    georg.brandl              
                                                                               

os.spawnv(P_WAIT, ...) on Linux doesn't handle EINTR             1838 days
       http://bugs.python.org/issue686667  facundobatista            
                                                                               

urllib2 doesn't handle urls without scheme                       1735 days
       http://bugs.python.org/issue745097  facundobatista            
                                                                               

Applets don't work on 10.1                                       1667 days
       http://bugs.python.org/issue781445  akuchling                 
                                                                               

Module-specific PDFs                                             1632 days
       http://bugs.python.org/issue800929  akuchling                 
                                                                               

More obvious indication of __reduce__ documentation.             1572 days
       http://bugs.python.org/issue835521  akuchling                 
                                                                               

catch invalid chunk length in httplib read routine               1465 days
       http://bugs.python.org/issue900744  georg.brandl              
       patch                                                                   

long <-> byte-string conversion                                  1430 days
       http://bugs.python.org/issue923643  marketdickinson           
       patch                                                                   

[PATCH] tty needs a way to restore the terminal mode.            1161 days
       http://bugs.python.org/issue1088077 facundobatista            
                                                                               

need siginterrupt()  on Linux - impossible to do timeouts        1159 days
       http://bugs.python.org/issue1089358 facundobatista            
       patch                                                                   

Memory leak in socket.py on Mac OS X                             1152 days
       http://bugs.python.org/issue1092502 akuchling                 
                                                                               

curses.initscr - initscr exit w/o env(TERM) set                  1109 days
       http://bugs.python.org/issue1119331 akuchling                 
                                                                               

descrintro describes __new__ and __init__ behavior wrong         1106 days
       http://bugs.python.org/issue1123716 facundobatista            
                                                                               

doctest should support -m                                        1087 days
       http://bugs.python.org/issue1156430 georg.brandl              
                                                                               

PEP 328 and Python 2.4 error                                     1089 days
       http://bugs.python.org/issue1157255 facundobatista            
                                                                               

import statement likely to crash if module launches threads      1058 days
       http://bugs.python.org/issue1175194 georg.brandl              
                                                                               

datetime/xmlrpclib.DateTime comparison                            858 days
       http://bugs.python.org/issue1330538 akuchling                 
       patch                                                                   

Remove usage of UserDict from os.py                               818 days
       http://bugs.python.org/issue1367711 loewis                    
       patch, easy                                                             

imaplib causes excessive fragmentation for large documents        792 days
       http://bugs.python.org/issue1389051 akuchling                 
       patch, easy                                                             

httplib patch to make _read_chunked() more robust                 764 days
       http://bugs.python.org/issue1411097 georg.brandl              
       patch                                                                   

normalize function in minidom unlinks empty child nodes           736 days
       http://bugs.python.org/issue1433694 akuchling                 
       easy                                                                    

httplib: read/_read_chunked failes with ValueError sometime       654 days
       http://bugs.python.org/issue1486335 georg.brandl              
                                                                               

Add "methodcaller" to the operator module                         619 days
       http://bugs.python.org/issue1506171 georg.brandl              
                                                                               

ConfigParser: whitespace leading comment lines                    499 days
       http://bugs.python.org/issue1576208 facundobatista            
                                                                               

popen() slow on AIX due to large FOPEN_MAX value                  449 days
       http://bugs.python.org/issue1607087 georg.brandl              
       patch                                                                   

Speed up PyArg_ParseTupleAndKeywords() and improve error msg      333 days
       http://bugs.python.org/issue1691070 tiran                     
       patch                                                                   

glibc error: corrupted double linked list (CPython 2.5.1)         285 days
       http://bugs.python.org/issue1718942 facundobatista            
                                                                               

Allow interpreter to execute a zip file                            96 days
       http://bugs.python.org/issue1739468 ncoghlan                  
       patch                                                                   

"%d" format handling for long values                              244 days
       http://bugs.python.org/issue1742669 facundobatista            
       patch                                                                   

class mutex doesn't do anything atomically                        237 days
       http://bugs.python.org/issue1746071 facundobatista            
       patch, easy                                                             

poll() on cygwin sometimes fails [PATCH]                          214 days
       http://bugs.python.org/issue1759997 georg.brandl              
                                                                               

Minor corrections to smtplib                                      190 days
       http://bugs.python.org/issue1776581 facundobatista            
       patch                                                                   



Top Issues Most Discussed (10)
______________________________

 45 os.times() is bogus                                             1243 days
open    http://bugs.python.org/issue1040026

 16 simple patch, improving unreachable bytecode removing            116 days
open    http://bugs.python.org/issue1394   

 14 map and filter shouldn't support None as first argument (in Py3    5 days
open    http://bugs.python.org/issue2186   

 14 os.environ should inherit dict                                     4 days
closed  http://bugs.python.org/issue2144   

 10 thread + import => crashes?                                        5 days
open    http://bugs.python.org/issue1720705

  8 Add VS CRT redist to the MSI installer                            84 days
open    http://bugs.python.org/issue1569   

  8 Bug in range() function for large values                          91 days
open    http://bugs.python.org/issue1533   

  7 Restructure import.c into PEP 302 importer objects                12 days
open    http://bugs.python.org/issue2135   

  7 Distutils default exclude doesn't match top level .svn           280 days
open    http://bugs.python.org/issue1725737

  6 optimize out local variables at end of function                    5 days
open    http://bugs.python.org/issue2181   




From g.brandl at gmx.net  Fri Feb 29 19:13:34 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 29 Feb 2008 19:13:34 +0100
Subject: [Python-Dev] download python-2.6 docs?
In-Reply-To: <fq3m8f$kqh$1@ger.gmane.org>
References: <fq3m8f$kqh$1@ger.gmane.org>
Message-ID: <fq9i0a$mvs$1@ger.gmane.org>

Neal Becker schrieb:
> http://docs.python.org/dev/download.html
> 
> I want a pdf.  The above link says:
> "To download an archive containing all the documents for this version of
> Python in one of various formats, follow one of links in this table. "
> 
> But there are no links.

Unfortunately, we haven't yet worked out a procedure to build downloadable
packages for the development docs. I'll try to work on that this weekend.

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 eric+python-dev at trueblade.com  Fri Feb 29 19:08:24 2008
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Fri, 29 Feb 2008 13:08:24 -0500
Subject: [Python-Dev] [Python-3000] Code freeze?
In-Reply-To: <59F9E6AD-3FED-498B-960A-5CD0426FB409@python.org>
References: <47C7105A.20908@cheimes.de>
	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
	<47C721A0.6060802@trueblade.com>
	<59F9E6AD-3FED-498B-960A-5CD0426FB409@python.org>
Message-ID: <47C84A18.5030602@trueblade.com>

Barry Warsaw wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Feb 28, 2008, at 4:03 PM, Eric Smith wrote:
> 
>> Barry Warsaw wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> On Feb 28, 2008, at 2:49 PM, Christian Heimes wrote:
>>>> Hey Barry!
>>> Hi Christian!
>>>> When are you planing to freeze the code of the trunk and branches/py3k
>>>> for the upcoming alpha releases? I'll merge the last modifications  
>>>> from
>>>> 2.6 to 3.0 in a couple of minutes. All tests on Linux are looking  
>>>> good,
>>>> except for the two profile tests on 3.0. I'm going to test Windows  
>>>> later.
>>> Okay, let's go ahead and make it official.
>>> I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern  
>>> (UTC-5) time or 2300 UTC.  Let's freeze the tree one hour prior to  
>>> that: 2200 UTC Friday 29-Feb-2008.
>>
>> Argh!  I was going to check the last of the PEP 3127 changes in 
>> tonight, but I won't make it by 6 pm EST.  I have them finished, but 
>> no tests written, so I'm not comfortable checking them in yet.  I 
>> guess it's no big deal that they slip until the next alpha.
> 
> Sorry, I notice my message might not have been clear.  As of this 
> writing, you have 23 hours and 54 minute before code freeze :).
> 
> Code freeze: 2200 UTC 29-Feb-2008
> Alpha making: 2300 UTC 29-Feb-2008

It turns out I'm not going to make this first alpha with the rest of the 
PEP 3127 changes.  The code doesn't handle all combinations of (int, 
long) and (str, unicode).  I'll get it finished before the next alpha.

Eric.

From stephen at xemacs.org  Fri Feb 29 19:59:03 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 01 Mar 2008 03:59:03 +0900
Subject: [Python-Dev] Code freeze?
In-Reply-To: <47C7C90B.5040707@scottdial.com>
References: <47C7105A.20908@cheimes.de>
	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
	<87hcfsloqf.fsf@uwakimon.sk.tsukuba.ac.jp>
	<476595E7-1350-40F1-8E64-EB4EB64F69DB@python.org>
	<47C7C90B.5040707@scottdial.com>
Message-ID: <873arblhc8.fsf@uwakimon.sk.tsukuba.ac.jp>

Not speaking for Barry or anyone else but myself.  This is an
explanation of how I understand the process and why I welcome it.

Scott Dial writes:

 > I don't understand who these alpha releases are supposed to be for, and 
 > who they will serve.

An alpha test is internal.  It is comprised of those tests the
developers working on the product (and/or an affiliated QA department)
can imagine.

Similarly, an alpha release is of, by, and for the developers.

 > I'm not sure what developer outside of the core community would
 > want to work with something missing key features and released
 > fairly arbitrarily.

Developers outside of the core community are not targeted.  That said,
how do you know that key features are missing?  Part of the point of a
release is that it says "*this stuff* is working".  I want *my* key
feature to be part of "this stuff", not *your* key feature.  Given "my
feature," I download to give the team feedback as early as possible.
Lacking yours, you don't.  Next alpha, presumably our roles will be
reversed.

 > More to the point, I don't know why a developer wouldn't just checkout 
 > from SVN in any case. Certainly if they are going to help root out bugs, 
 > then we would like them to be using the trunk if possible. I fear that 
 > once an alpha is 2 weeks old, we will start saying "please check if its 
 > still a problem on the trunk."

Software development in practice is a matter of "take two steps back,
then three steps forward."  The point of an alpha release is to
checkpoint what is a regression, and what is a temporary "feature"
introduced by new development.  The latter is admissible on the trunk,
but the goal should be none from one alpha to the next.  In other
words, a bug introduced by new development should be fixed by the next
alpha.  If it can't be, the developer misjudged the timing of the
merge to mainline; it wasn't ready yet.

 > A mild concern is how this effects checkins with individuals either 
 > trying to meet a deadline or even wait until after an alpha release to 
 > checkin a large change. I'm not sure this will happen, but having 
 > releases scheduled without feature milestones attached certainly changes 
 > the environment for work to be done in.

Scheduling feature milestones assumes that people put priority on
those features at a given time.  Barry can't assume that yet.  Once
the rhythm is established, Barry can start asking for, and some people
will start volunteering, milestone commitments for given releases.

I think that it probably is desirable to to put that deadline pressure
on.  Individuals who rush to get their work in, and cause alpha-to-
alpha regressions, can be advised to wait in the future in similar
circumstances.  Once the rhythm is established, people can expect that
alphas will be consistently increasing in features and consistently
decreasing in defects.  If that's not true, something's wrong with the
process, and the team needs to step back and do something about it.

But in the nature of software development, *monotone improvement is
not something you want to, or even can, impose on the trunk at all
points in time*.

From barry at python.org  Fri Feb 29 20:23:26 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Feb 2008 14:23:26 -0500
Subject: [Python-Dev] [Python-3000] Code freeze?
In-Reply-To: <47C84A18.5030602@trueblade.com>
References: <47C7105A.20908@cheimes.de>
	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
	<47C721A0.6060802@trueblade.com>
	<59F9E6AD-3FED-498B-960A-5CD0426FB409@python.org>
	<47C84A18.5030602@trueblade.com>
Message-ID: <5B7CA66C-E966-4308-9FD6-4AD7A47D0D19@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 29, 2008, at 1:08 PM, Eric Smith wrote:

> Barry Warsaw wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> On Feb 28, 2008, at 4:03 PM, Eric Smith wrote:
>>> Barry Warsaw wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>> On Feb 28, 2008, at 2:49 PM, Christian Heimes wrote:
>>>>> Hey Barry!
>>>> Hi Christian!
>>>>> When are you planing to freeze the code of the trunk and  
>>>>> branches/py3k
>>>>> for the upcoming alpha releases? I'll merge the last  
>>>>> modifications  from
>>>>> 2.6 to 3.0 in a couple of minutes. All tests on Linux are  
>>>>> looking  good,
>>>>> except for the two profile tests on 3.0. I'm going to test  
>>>>> Windows  later.
>>>> Okay, let's go ahead and make it official.
>>>> I plan on cutting the alphas for 2.6 and 3.0 at about 6pm  
>>>> Eastern  (UTC-5) time or 2300 UTC.  Let's freeze the tree one  
>>>> hour prior to  that: 2200 UTC Friday 29-Feb-2008.
>>>
>>> Argh!  I was going to check the last of the PEP 3127 changes in  
>>> tonight, but I won't make it by 6 pm EST.  I have them finished,  
>>> but no tests written, so I'm not comfortable checking them in  
>>> yet.  I guess it's no big deal that they slip until the next alpha.
>> Sorry, I notice my message might not have been clear.  As of this  
>> writing, you have 23 hours and 54 minute before code freeze :).
>> Code freeze: 2200 UTC 29-Feb-2008
>> Alpha making: 2300 UTC 29-Feb-2008
>
> It turns out I'm not going to make this first alpha with the rest of  
> the PEP 3127 changes.  The code doesn't handle all combinations of  
> (int, long) and (str, unicode).  I'll get it finished before the  
> next alpha.

No problem Eric.  You know when the next alpha is coming out anyway. :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8hbrnEjvBPtnXfVAQKRvgP/Qe5/vCtHPX5LKklLTtcD4pnR/AtRs/V2
/VNeqkvXnr4Ooe8LwNKFMo4Yy0pdvjEQbLR/FGKojG2JIJ0kXyE2ObQXFsKCKAxV
TCr8ZPeh5wqGLYuJAXtTz/UJzf5CzkgbKY9p32u5yy5qXiP7rgGpi8JvSZJKN3cP
bApx/pGyNdU=
=GaSZ
-----END PGP SIGNATURE-----

From barry at python.org  Fri Feb 29 20:33:34 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Feb 2008 14:33:34 -0500
Subject: [Python-Dev] [Python-3000]  Code freeze?
In-Reply-To: <873arblhc8.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <47C7105A.20908@cheimes.de>
	<00E337B6-FFC8-43C8-BA9F-142725954320@python.org>
	<87hcfsloqf.fsf@uwakimon.sk.tsukuba.ac.jp>
	<476595E7-1350-40F1-8E64-EB4EB64F69DB@python.org>
	<47C7C90B.5040707@scottdial.com>
	<873arblhc8.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <079EC957-A3D3-48F9-8A77-A8BEB402E749@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 29, 2008, at 1:59 PM, Stephen J. Turnbull wrote:

> I think that it probably is desirable to to put that deadline pressure
> on.  Individuals who rush to get their work in, and cause alpha-to-
> alpha regressions, can be advised to wait in the future in similar
> circumstances.  Once the rhythm is established, people can expect that
> alphas will be consistently increasing in features and consistently
> decreasing in defects.  If that's not true, something's wrong with the
> process, and the team needs to step back and do something about it.

I agree, and what I already think is broken about our process is that  
changes can land that break the buildbots.  Ideally, this should never  
happen, but our build/test environment has two flaws.  First, it's  
retroactive not proactive.  Second, the tests themselves are not  
always stable.

Given the wide range of platforms and the volunteer nature of the  
buildbot farm, I don't think there's much right now that we can do  
about the second point.  We can do things to mitigate it though, such  
as take a majority-success approach, or give more weight to more  
stable platforms and buildbots.

The second one is tougher because more work on the process is  
necessary, and it would change our workflow for committing changes to  
the tree.  Even with its faults, I'm a big fan of PQM <https://launchpad.net/pqm 
 > though that's not something I think we're ready for.  The bigger  
question though is whether we as a development community would change  
the way we work so that nothing lands if it doesn't pass all the  
tests.  We'd be trading some inconvenience (and administrative  
headaches) for better overall quality and always-releasable guarantees.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8heD3EjvBPtnXfVAQIj/gP/dyf1oavy7y4gTrKHi+j/m+0y4DJstIDf
Fh2MhqExWtCX6V8M3mOn46uRwStwtz9+TUEznNEC8xsxq734GtVyi9Vw6cLpmZQ6
uQp+IBT+nkqNz3sDd8N/ewAGPBO5Ml2m+yn+rfi2XaT5Vfi5akSR/aDwJKGC71fL
8IaWHo5XKEM=
=JQMb
-----END PGP SIGNATURE-----

From medhat.gayed at gmail.com  Fri Feb 29 00:42:49 2008
From: medhat.gayed at gmail.com (Medhat Gayed)
Date: Thu, 28 Feb 2008 23:42:49 +0000 (UTC)
Subject: [Python-Dev] Python XML Validator
Message-ID: <loom.20080228T233005-604@post.gmane.org>

I tested and tried a few XML validators but none of them is able to successfully
validate a string of xml (not a file just a string) to programatically be able
to validate messages of xml that flow in and out of the different systems.
Teh validators I used were XSV, oNVDL and lxml, can we implement a pure python
module for validating strings of xml using XML Schema (not DTD).

lxml is good but not written in python and difficult to install and didn't work
on MacOS X.
XSV very poor documentation and only validates xml files not strings.
oNVDL not writtem in python and only validates xml files not strings.