From brett at python.org  Sun May  4 00:16:58 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 3 May 2008 15:16:58 -0700
Subject: [stdlib-sig] Getting simplejson 1.9 into the stdlib
Message-ID: <bbaeab100805031516g6ec36c8ex8678b1abe4f85f4a@mail.gmail.com>

http://bugs.python.org/issue2750 holds the issue to get simplejson 1.9
into the stdlib as the new 'json' module. I am going to give this SIG
a week to go through the code and such before I announce on
python-dev. The todo list is:

* Get it building in the core.
* Make sure the tests are good and run without issue.
* Convert the docs (the docstrings are already in reST, so it should
mostly be a copy-and-paste job with some added markup).
* Verify the code is PEP 7/PEP 8 compatible.
* Convert to 3.0.

The build and test steps are the most critical as the rest can occur
in parallel once the code is in svn.

People who want to claim a step just update the issue.

-Brett

From christian at cheimes.de  Sun May  4 13:55:34 2008
From: christian at cheimes.de (Christian Heimes)
Date: Sun, 04 May 2008 13:55:34 +0200
Subject: [stdlib-sig] Getting simplejson 1.9 into the stdlib
In-Reply-To: <bbaeab100805031516g6ec36c8ex8678b1abe4f85f4a@mail.gmail.com>
References: <bbaeab100805031516g6ec36c8ex8678b1abe4f85f4a@mail.gmail.com>
Message-ID: <481DA436.2000001@cheimes.de>

Brett Cannon schrieb:
> http://bugs.python.org/issue2750 holds the issue to get simplejson 1.9
> into the stdlib as the new 'json' module. I am going to give this SIG
> a week to go through the code and such before I announce on
> python-dev. The todo list is:
> 
> * Get it building in the core.
> * Make sure the tests are good and run without issue.
> * Convert the docs (the docstrings are already in reST, so it should
> mostly be a copy-and-paste job with some added markup).
> * Verify the code is PEP 7/PEP 8 compatible.
> * Convert to 3.0.

Brett, Benjamin and I worked on the json package yesterday. The code is
in
bzr+ssh://pythonbzr at code.python.org/python/users/brett/issue2750-simplejson/

I mostly worked on the C extension with the json speedups:

* Added file as Modules/_json.c
* Added build steps to setup.py, PC/config.c and all four pythoncore
projects for VS 6.0 to 9.0.
* Removed code to support Python versions before 2,5
* Slightly arranged code for PEP 7 compatibility
* Changed Python code so that the C implementation is available as
c_function and the pure Python one as py_function
* Added tests to verify Python uses the optimized functions

The code runs w/o errors or ref leaks on Mac OS X and Linux x86 as UCS2
and UCS4 build. The Windows tests are passing, too.

Christian

From brett at python.org  Mon May  5 22:25:58 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 5 May 2008 13:25:58 -0700
Subject: [stdlib-sig] Getting simplejson 1.9 into the stdlib
In-Reply-To: <bbaeab100805031516g6ec36c8ex8678b1abe4f85f4a@mail.gmail.com>
References: <bbaeab100805031516g6ec36c8ex8678b1abe4f85f4a@mail.gmail.com>
Message-ID: <bbaeab100805051325r1ff2c1e8qf65c18bddaa4861e@mail.gmail.com>

r62734 has added the 'json' package to the trunk. Only thing left to
do is to port it to 3.0.

-Brett

On Sat, May 3, 2008 at 3:16 PM, Brett Cannon <brett at python.org> wrote:
> http://bugs.python.org/issue2750 holds the issue to get simplejson 1.9
>  into the stdlib as the new 'json' module. I am going to give this SIG
>  a week to go through the code and such before I announce on
>  python-dev. The todo list is:
>
>  * Get it building in the core.
>  * Make sure the tests are good and run without issue.
>  * Convert the docs (the docstrings are already in reST, so it should
>  mostly be a copy-and-paste job with some added markup).
>  * Verify the code is PEP 7/PEP 8 compatible.
>  * Convert to 3.0.
>
>  The build and test steps are the most critical as the rest can occur
>  in parallel once the code is in svn.
>
>  People who want to claim a step just update the issue.
>
>  -Brett
>

From alexandre at peadrop.com  Tue May  6 00:35:30 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Mon, 5 May 2008 18:35:30 -0400
Subject: [stdlib-sig] Removing the deprecated sre module?
Message-ID: <acd65fa20805051535q2fc52bfaja612d5ecf5afcb72@mail.gmail.com>

Hi,

I know that the deadline for module removal is now passed, but I think
we forgot to decide what should happen to the deprecated sre module:

>>> import sre
:1: DeprecationWarning: The sre module is deprecated, please import re.
>>> help(sre)
...
DESCRIPTION
    This file is only retained for backwards compatibility.
    It will be removed in the future.  sre was moved to re in version 2.5.
...

Currently, the sre module is just a stub that imports the re module.
So, I don't think removing in Py3k will cause any problem.

Cheers,
-- Alexandre

From brett at python.org  Tue May  6 01:22:18 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 5 May 2008 16:22:18 -0700
Subject: [stdlib-sig] Removing the deprecated sre module?
In-Reply-To: <acd65fa20805051535q2fc52bfaja612d5ecf5afcb72@mail.gmail.com>
References: <acd65fa20805051535q2fc52bfaja612d5ecf5afcb72@mail.gmail.com>
Message-ID: <bbaeab100805051622i6e32a56sb69d4a64cdc34483@mail.gmail.com>

On Mon, May 5, 2008 at 3:35 PM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
> Hi,
>
>  I know that the deadline for module removal is now passed, but I think
>  we forgot to decide what should happen to the deprecated sre module:
>
>  >>> import sre
>  :1: DeprecationWarning: The sre module is deprecated, please import re.
>  >>> help(sre)
>  ...
>  DESCRIPTION
>     This file is only retained for backwards compatibility.
>     It will be removed in the future.  sre was moved to re in version 2.5.
>  ...
>
>  Currently, the sre module is just a stub that imports the re module.
>  So, I don't think removing in Py3k will cause any problem.

I just added it to to the PEP for removal.

-Brett

From christian at cheimes.de  Thu May  8 00:50:11 2008
From: christian at cheimes.de (Christian Heimes)
Date: Thu, 08 May 2008 00:50:11 +0200
Subject: [stdlib-sig] Removing the deprecated sre module?
In-Reply-To: <bbaeab100805051622i6e32a56sb69d4a64cdc34483@mail.gmail.com>
References: <acd65fa20805051535q2fc52bfaja612d5ecf5afcb72@mail.gmail.com>
	<bbaeab100805051622i6e32a56sb69d4a64cdc34483@mail.gmail.com>
Message-ID: <48223223.1010505@cheimes.de>

Brett Cannon schrieb:
> I just added it to to the PEP for removal.

Who is going to rewrite json.scanner? It's using sre.

Christian

From musiccomposition at gmail.com  Thu May  8 01:12:16 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 7 May 2008 18:12:16 -0500
Subject: [stdlib-sig] Removing the deprecated sre module?
In-Reply-To: <acd65fa20805051535q2fc52bfaja612d5ecf5afcb72@mail.gmail.com>
References: <acd65fa20805051535q2fc52bfaja612d5ecf5afcb72@mail.gmail.com>
Message-ID: <1afaf6160805071612w1d77e22bhfba02b19b46bd946@mail.gmail.com>

On Mon, May 5, 2008 at 5:35 PM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
>  Currently, the sre module is just a stub that imports the re module.
>  So, I don't think removing in Py3k will cause any problem.

Is this just the sre.py module? Does it include sre_constants,
sre_compile, and sre_parse?


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From alexandre at peadrop.com  Thu May  8 03:03:43 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Wed, 7 May 2008 21:03:43 -0400
Subject: [stdlib-sig] Removing the deprecated sre module?
In-Reply-To: <48223223.1010505@cheimes.de>
References: <acd65fa20805051535q2fc52bfaja612d5ecf5afcb72@mail.gmail.com>
	<bbaeab100805051622i6e32a56sb69d4a64cdc34483@mail.gmail.com>
	<48223223.1010505@cheimes.de>
Message-ID: <acd65fa20805071803p51ff9d63y2322768043f6ebd8@mail.gmail.com>

On Wed, May 7, 2008 at 6:50 PM, Christian Heimes <christian at cheimes.de> wrote:
> Brett Cannon schrieb:
>
> > I just added it to to the PEP for removal.
>
>  Who is going to rewrite json.scanner? It's using sre.
>
>  Christian
>

You mean the sre_parse, sre_compile and sre_constants, right? Because
the sre module is currently empty (it just imports stuff from re).

-- Alexandre

From musiccomposition at gmail.com  Thu May  8 03:06:54 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 7 May 2008 20:06:54 -0500
Subject: [stdlib-sig] Removing the deprecated sre module?
In-Reply-To: <acd65fa20805071803p51ff9d63y2322768043f6ebd8@mail.gmail.com>
References: <acd65fa20805051535q2fc52bfaja612d5ecf5afcb72@mail.gmail.com>
	<bbaeab100805051622i6e32a56sb69d4a64cdc34483@mail.gmail.com>
	<48223223.1010505@cheimes.de>
	<acd65fa20805071803p51ff9d63y2322768043f6ebd8@mail.gmail.com>
Message-ID: <1afaf6160805071806l6b1df800x68eb567ebe62d64@mail.gmail.com>

On Wed, May 7, 2008 at 8:03 PM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
> On Wed, May 7, 2008 at 6:50 PM, Christian Heimes <christian at cheimes.de> wrote:
>  >  Who is going to rewrite json.scanner? It's using sre.
>  >
>  >  Christian
>  >
>
>  You mean the sre_parse, sre_compile and sre_constants, right? Because
>  the sre module is currently empty (it just imports stuff from re).

Yes.



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From alexandre at peadrop.com  Thu May  8 03:20:57 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Wed, 7 May 2008 21:20:57 -0400
Subject: [stdlib-sig] Removing the deprecated sre module?
In-Reply-To: <1afaf6160805071612w1d77e22bhfba02b19b46bd946@mail.gmail.com>
References: <acd65fa20805051535q2fc52bfaja612d5ecf5afcb72@mail.gmail.com>
	<1afaf6160805071612w1d77e22bhfba02b19b46bd946@mail.gmail.com>
Message-ID: <acd65fa20805071820s2e04dcc3obf3ec8e2956dd888@mail.gmail.com>

On Wed, May 7, 2008 at 7:12 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> On Mon, May 5, 2008 at 5:35 PM, Alexandre Vassalotti
>  <alexandre at peadrop.com> wrote:
>
> >  Currently, the sre module is just a stub that imports the re module.
>  >  So, I don't think removing in Py3k will cause any problem.
>
>  Is this just the sre.py module? Does it include sre_constants,
>  sre_compile, and sre_parse?
>

I was talking only about the sre module stub, not the other sre_*
modules. These are still needed (e.g., sre_constants is used to
generate the Modules/sre_constants.h header).

Anyway, would it be a good idea to move the re and sre_* modules into
their own package?

   re -> re.__init__
   sre_compile -> re._compile
   sre_constants -> re._constants
   sre_parse -> re._parse

-- Alexandre

From brett at python.org  Thu May  8 04:48:41 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 8 May 2008 04:48:41 +0200
Subject: [stdlib-sig] Removing the deprecated sre module?
In-Reply-To: <acd65fa20805071820s2e04dcc3obf3ec8e2956dd888@mail.gmail.com>
References: <acd65fa20805051535q2fc52bfaja612d5ecf5afcb72@mail.gmail.com>
	<1afaf6160805071612w1d77e22bhfba02b19b46bd946@mail.gmail.com>
	<acd65fa20805071820s2e04dcc3obf3ec8e2956dd888@mail.gmail.com>
Message-ID: <bbaeab100805071948v676dd17gc4046e76ec20cf0f@mail.gmail.com>

On Wed, May 7, 2008 at 6:20 PM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
> On Wed, May 7, 2008 at 7:12 PM, Benjamin Peterson
>  <musiccomposition at gmail.com> wrote:
>  > On Mon, May 5, 2008 at 5:35 PM, Alexandre Vassalotti
>  >  <alexandre at peadrop.com> wrote:
>  >
>  > >  Currently, the sre module is just a stub that imports the re module.
>  >  >  So, I don't think removing in Py3k will cause any problem.
>  >
>  >  Is this just the sre.py module? Does it include sre_constants,
>  >  sre_compile, and sre_parse?
>  >
>
>  I was talking only about the sre module stub, not the other sre_*
>  modules. These are still needed (e.g., sre_constants is used to
>  generate the Modules/sre_constants.h header).
>
>  Anyway, would it be a good idea to move the re and sre_* modules into
>  their own package?
>
>    re -> re.__init__
>    sre_compile -> re._compile
>    sre_constants -> re._constants
>    sre_parse -> re._parse

That's a possibility, although this will have to go past python-dev at
this point since the PEP has already been accepted.

-Brett

From musiccomposition at gmail.com  Mon May 12 04:10:56 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 11 May 2008 21:10:56 -0500
Subject: [stdlib-sig] gestalt, too?
Message-ID: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>

I don't see gestalt on PEP 3108, but it is a Mac module.

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From ronaldoussoren at mac.com  Mon May 12 13:42:36 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 12 May 2008 13:42:36 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
Message-ID: <7F52EFD9-7D38-4F55-8C2F-7C3EBB56796F@mac.com>


On 12 May, 2008, at 4:10, Benjamin Peterson wrote:

> I don't see gestalt on PEP 3108, but it is a Mac module.

The only user in the stdlib is platform.py, and that could use a  
simple ctypes wrapper instead (like the one attached below)

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pygestalt.py
Type: text/x-python-script
Size: 459 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/stdlib-sig/attachments/20080512/94ac0411/attachment.bin>
-------------- next part --------------

>
>
> -- 
> Cheers,
> Benjamin Peterson
> "There's no place like 127.0.0.1."
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig


From mal at egenix.com  Tue May 13 11:23:23 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 13 May 2008 11:23:23 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
Message-ID: <48295E0B.6050303@egenix.com>

On 2008-05-12 04:10, Benjamin Peterson wrote:
> I don't see gestalt on PEP 3108, but it is a Mac module.

I'm not sure what to make of that comment. What are you suggesting ?

gestalt is used on Macs to access system information. platform.py
uses and probably a lot of Mac apps as well.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 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 ronaldoussoren at mac.com  Tue May 13 11:38:16 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 13 May 2008 11:38:16 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <48295E0B.6050303@egenix.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
Message-ID: <E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>


On 13 May, 2008, at 11:23, M.-A. Lemburg wrote:

> On 2008-05-12 04:10, Benjamin Peterson wrote:
>> I don't see gestalt on PEP 3108, but it is a Mac module.
>
> I'm not sure what to make of that comment. What are you suggesting ?
>
> gestalt is used on Macs to access system information. platform.py
> uses and probably a lot of Mac apps as well.

PEP3108 proposes to drop all of Lib/plat-mac and Mac/Modules.

I'm definitely in favor of dropping the Carbon bindings, but I'm -0 on  
dropping gestalt as it is a trivial module that's used by bits of the  
standard library.

Ronald


From mal at egenix.com  Tue May 13 11:58:01 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 13 May 2008 11:58:01 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
Message-ID: <48296629.4020602@egenix.com>

On 2008-05-13 11:38, Ronald Oussoren wrote:
> 
> On 13 May, 2008, at 11:23, M.-A. Lemburg wrote:
> 
>> On 2008-05-12 04:10, Benjamin Peterson wrote:
>>> I don't see gestalt on PEP 3108, but it is a Mac module.
>>
>> I'm not sure what to make of that comment. What are you suggesting ?
>>
>> gestalt is used on Macs to access system information. platform.py
>> uses and probably a lot of Mac apps as well.
> 
> PEP3108 proposes to drop all of Lib/plat-mac and Mac/Modules.
> 
> I'm definitely in favor of dropping the Carbon bindings, but I'm -0 on 
> dropping gestalt as it is a trivial module that's used by bits of the 
> standard library.

Thanks, I didn't realize that *all* of Lib/plat-mac was targeted
for removal.

I think that those modules which make sense on Mac OS X should
be moved to Lib/plat-darwin/, ie. gestalt.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 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 ronaldoussoren at mac.com  Tue May 13 12:09:15 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 13 May 2008 12:09:15 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <48296629.4020602@egenix.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
	<48296629.4020602@egenix.com>
Message-ID: <80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>


On 13 May, 2008, at 11:58, M.-A. Lemburg wrote:

> On 2008-05-13 11:38, Ronald Oussoren wrote:
>> On 13 May, 2008, at 11:23, M.-A. Lemburg wrote:
>>> On 2008-05-12 04:10, Benjamin Peterson wrote:
>>>> I don't see gestalt on PEP 3108, but it is a Mac module.
>>>
>>> I'm not sure what to make of that comment. What are you suggesting ?
>>>
>>> gestalt is used on Macs to access system information. platform.py
>>> uses and probably a lot of Mac apps as well.
>> PEP3108 proposes to drop all of Lib/plat-mac and Mac/Modules.
>> I'm definitely in favor of dropping the Carbon bindings, but I'm -0  
>> on dropping gestalt as it is a trivial module that's used by bits  
>> of the standard library.
>
> Thanks, I didn't realize that *all* of Lib/plat-mac was targeted
> for removal.
>
> I think that those modules which make sense on Mac OS X should
> be moved to Lib/plat-darwin/, ie. gestalt.

Why? Technically speaking "darwin" is yet another platform: the open- 
source unixy bits of OSX. I'd prefer to keep plat-mac, but one that's  
much smaller than the current tree.

Ronald

From mal at egenix.com  Tue May 13 12:30:31 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 13 May 2008 12:30:31 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>	<48295E0B.6050303@egenix.com>	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
Message-ID: <48296DC7.7020604@egenix.com>

On 2008-05-13 12:09, Ronald Oussoren wrote:
> 
> On 13 May, 2008, at 11:58, M.-A. Lemburg wrote:
> 
>> On 2008-05-13 11:38, Ronald Oussoren wrote:
>>> On 13 May, 2008, at 11:23, M.-A. Lemburg wrote:
>>>> On 2008-05-12 04:10, Benjamin Peterson wrote:
>>>>> I don't see gestalt on PEP 3108, but it is a Mac module.
>>>>
>>>> I'm not sure what to make of that comment. What are you suggesting ?
>>>>
>>>> gestalt is used on Macs to access system information. platform.py
>>>> uses and probably a lot of Mac apps as well.
>>> PEP3108 proposes to drop all of Lib/plat-mac and Mac/Modules.
>>> I'm definitely in favor of dropping the Carbon bindings, but I'm -0 
>>> on dropping gestalt as it is a trivial module that's used by bits of 
>>> the standard library.
>>
>> Thanks, I didn't realize that *all* of Lib/plat-mac was targeted
>> for removal.
>>
>> I think that those modules which make sense on Mac OS X should
>> be moved to Lib/plat-darwin/, ie. gestalt.
> 
> Why? Technically speaking "darwin" is yet another platform: the 
> open-source unixy bits of OSX. I'd prefer to keep plat-mac, but one 
> that's much smaller than the current tree.

Well, if you fire up Python on Mac OS X 10.4, you get:

Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on *darwin*

OTOH, sys.path still has both plat-mac and plat-darwin on it.
Probably for historic reasons, I guess.

Either way, I'm -1 on removing the gestalt API, since it's needed
by platform.py and there doesn't appear to be an alternative for getting
at certain config information on Mac OS (but don't really care whether
it's implemented as C module or using ctypes ;-).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 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 santagada at gmail.com  Tue May 13 13:03:19 2008
From: santagada at gmail.com (Leonardo Santagada)
Date: Tue, 13 May 2008 08:03:19 -0300
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <48296DC7.7020604@egenix.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>	<48295E0B.6050303@egenix.com>	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<48296DC7.7020604@egenix.com>
Message-ID: <C0B4ADE6-BA6C-488C-AC61-DA71B68B0C91@gmail.com>


On 13/05/2008, at 07:30, M.-A. Lemburg wrote:
> Either way, I'm -1 on removing the gestalt API, since it's needed
> by platform.py and there doesn't appear to be an alternative for  
> getting
> at certain config information on Mac OS (but don't really care whether
> it's implemented as C module or using ctypes ;-).


What happened to the idea of making it a ctypes module? I'm very much  
in favor to all non performance critical parts of python be in a more  
portable and easier to maintain code.

--
Leonardo Santagada







From ronaldoussoren at mac.com  Tue May 13 13:25:07 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 13 May 2008 13:25:07 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <C0B4ADE6-BA6C-488C-AC61-DA71B68B0C91@gmail.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<48296DC7.7020604@egenix.com>
	<C0B4ADE6-BA6C-488C-AC61-DA71B68B0C91@gmail.com>
Message-ID: <BA888D59-C47D-4656-9584-EEA9B04926FE@mac.com>


On 13 May, 2008, at 13:03, Leonardo Santagada wrote:

>
> On 13/05/2008, at 07:30, M.-A. Lemburg wrote:
>> Either way, I'm -1 on removing the gestalt API, since it's needed
>> by platform.py and there doesn't appear to be an alternative for  
>> getting
>> at certain config information on Mac OS (but don't really care  
>> whether
>> it's implemented as C module or using ctypes ;-).
>
>
> What happened to the idea of making it a ctypes module?

AFAIK there is are no such plans.

> I'm very much in favor to all non performance critical parts of  
> python be in a more portable and easier to maintain code.

I'm -1 on rewriting it as a ctypes module. The existing C  
implementation works just fine, rewriting it in Python is just more  
work without clear advantages.

If you want to play with ctypes on OSX: look into replacing the  
Carbon.File usage in the modules plistlib and binhex by ctypes  
wrappers (both to remove the dependency on the now-deprecated Carbon  
bindings).

Ronald




>
>
> --
> Leonardo Santagada
>
>
>
>
>
>
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig


From brett at python.org  Tue May 13 20:45:15 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 13 May 2008 20:45:15 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
Message-ID: <bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>

On Tue, May 13, 2008 at 3:09 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
>  On 13 May, 2008, at 11:58, M.-A. Lemburg wrote:
>
>
> > On 2008-05-13 11:38, Ronald Oussoren wrote:
> >
> > > On 13 May, 2008, at 11:23, M.-A. Lemburg wrote:
> > >
> > > > On 2008-05-12 04:10, Benjamin Peterson wrote:
> > > >
> > > > > I don't see gestalt on PEP 3108, but it is a Mac module.
> > > > >
> > > >
> > > > I'm not sure what to make of that comment. What are you suggesting ?
> > > >
> > > > gestalt is used on Macs to access system information. platform.py
> > > > uses and probably a lot of Mac apps as well.
> > > >
> > > PEP3108 proposes to drop all of Lib/plat-mac and Mac/Modules.
> > > I'm definitely in favor of dropping the Carbon bindings, but I'm -0 on
> dropping gestalt as it is a trivial module that's used by bits of the
> standard library.
> > >
> >
> > Thanks, I didn't realize that *all* of Lib/plat-mac was targeted
> > for removal.
> >
> > I think that those modules which make sense on Mac OS X should
> > be moved to Lib/plat-darwin/, ie. gestalt.
> >
>
>  Why? Technically speaking "darwin" is yet another platform: the open-source
> unixy bits of OSX. I'd prefer to keep plat-mac, but one that's much smaller
> than the current tree.

At the moment, both directories and all files (including gestalt) have
been removed, so whomever adds the file back can choose the directory.
=)

-Brett

From mal at egenix.com  Tue May 13 21:08:37 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 13 May 2008 21:08:37 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>	<48295E0B.6050303@egenix.com>	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>	<48296629.4020602@egenix.com>	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>
Message-ID: <4829E735.60007@egenix.com>

On 2008-05-13 20:45, Brett Cannon wrote:
> On Tue, May 13, 2008 at 3:09 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>>  On 13 May, 2008, at 11:58, M.-A. Lemburg wrote:
>>
>>
>>> On 2008-05-13 11:38, Ronald Oussoren wrote:
>>>
>>>> On 13 May, 2008, at 11:23, M.-A. Lemburg wrote:
>>>>
>>>>> On 2008-05-12 04:10, Benjamin Peterson wrote:
>>>>>
>>>>>> I don't see gestalt on PEP 3108, but it is a Mac module.
>>>>>>
>>>>> I'm not sure what to make of that comment. What are you suggesting ?
>>>>>
>>>>> gestalt is used on Macs to access system information. platform.py
>>>>> uses and probably a lot of Mac apps as well.
>>>>>
>>>> PEP3108 proposes to drop all of Lib/plat-mac and Mac/Modules.
>>>> I'm definitely in favor of dropping the Carbon bindings, but I'm -0 on
>> dropping gestalt as it is a trivial module that's used by bits of the
>> standard library.
>>> Thanks, I didn't realize that *all* of Lib/plat-mac was targeted
>>> for removal.
>>>
>>> I think that those modules which make sense on Mac OS X should
>>> be moved to Lib/plat-darwin/, ie. gestalt.
>>>
>>  Why? Technically speaking "darwin" is yet another platform: the open-source
>> unixy bits of OSX. I'd prefer to keep plat-mac, but one that's much smaller
>> than the current tree.
> 
> At the moment, both directories and all files (including gestalt) have
> been removed, so whomever adds the file back can choose the directory.
> =)

Not really: the Lib/plat-<platform> names are taken from uname,
so they would have to go into a Lib/plat-darwin for Mac OS X.

I'm not sure, but could imaging that Mac OS 9 and below returned
'mac' for uname, which would then have been the reason to have
that directory.

Perhaps Jack could shed some light on this ?!

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 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 brett at python.org  Tue May 13 23:00:10 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 13 May 2008 14:00:10 -0700
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <BA888D59-C47D-4656-9584-EEA9B04926FE@mac.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<48296DC7.7020604@egenix.com>
	<C0B4ADE6-BA6C-488C-AC61-DA71B68B0C91@gmail.com>
	<BA888D59-C47D-4656-9584-EEA9B04926FE@mac.com>
Message-ID: <bbaeab100805131400w1425c0aj9487e55c07ce0e99@mail.gmail.com>

On Tue, May 13, 2008 at 4:25 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
>  On 13 May, 2008, at 13:03, Leonardo Santagada wrote:
>
>
> >
> > On 13/05/2008, at 07:30, M.-A. Lemburg wrote:
> >
> > > Either way, I'm -1 on removing the gestalt API, since it's needed
> > > by platform.py and there doesn't appear to be an alternative for getting
> > > at certain config information on Mac OS (but don't really care whether
> > > it's implemented as C module or using ctypes ;-).
> > >
> >
> >
> > What happened to the idea of making it a ctypes module?
> >
>
>  AFAIK there is are no such plans.
>
>
>
> > I'm very much in favor to all non performance critical parts of python be
> in a more portable and easier to maintain code.
> >
>
>  I'm -1 on rewriting it as a ctypes module. The existing C implementation
> works just fine, rewriting it in Python is just more work without clear
> advantages.
>

Then why did you attach a ctypes implementation two days ago?

-Brett

From ronaldoussoren at mac.com  Wed May 14 17:31:50 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 14 May 2008 17:31:50 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>
Message-ID: <135D1942-B913-45B4-BF09-19B4FF6386DD@mac.com>


On 13 May, 2008, at 20:45, Brett Cannon wrote:
>
> At the moment, both directories and all files (including gestalt) have
> been removed, so whomever adds the file back can choose the directory.
> =)

That won't be me, I barely have time to work on Python at the moment  
and am focussing all time I have on ensuring that Python2.6 will be  
the best possible release on OSX.

How did you change platform? That module uses gestalt to calculate the  
osx platform version and architecture.

Ronald

From ronaldoussoren at mac.com  Wed May 14 17:33:32 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 14 May 2008 17:33:32 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <bbaeab100805131400w1425c0aj9487e55c07ce0e99@mail.gmail.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<48296DC7.7020604@egenix.com>
	<C0B4ADE6-BA6C-488C-AC61-DA71B68B0C91@gmail.com>
	<BA888D59-C47D-4656-9584-EEA9B04926FE@mac.com>
	<bbaeab100805131400w1425c0aj9487e55c07ce0e99@mail.gmail.com>
Message-ID: <5C8C03C2-F988-490F-8F6A-656453BBAB45@mac.com>


On 13 May, 2008, at 23:00, Brett Cannon wrote:

> On Tue, May 13, 2008 at 4:25 AM, Ronald Oussoren <ronaldoussoren at mac.com 
> > wrote:
>>
>> On 13 May, 2008, at 13:03, Leonardo Santagada wrote:
>>
>>
>>>
>>> On 13/05/2008, at 07:30, M.-A. Lemburg wrote:
>>>
>>>> Either way, I'm -1 on removing the gestalt API, since it's needed
>>>> by platform.py and there doesn't appear to be an alternative for  
>>>> getting
>>>> at certain config information on Mac OS (but don't really care  
>>>> whether
>>>> it's implemented as C module or using ctypes ;-).
>>>>
>>>
>>>
>>> What happened to the idea of making it a ctypes module?
>>>
>>
>> AFAIK there is are no such plans.
>>
>>
>>
>>> I'm very much in favor to all non performance critical parts of  
>>> python be
>> in a more portable and easier to maintain code.
>>>
>>
>> I'm -1 on rewriting it as a ctypes module. The existing C  
>> implementation
>> works just fine, rewriting it in Python is just more work without  
>> clear
>> advantages.
>>
>
> Then why did you attach a ctypes implementation two days ago?

To show that adding it would be easy. That version is completely  
untested an not compatible with the C version, fixing those issues  
takes time and I have no intention to do those changes.

Ronald


From brett at python.org  Wed May 14 22:07:53 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 14 May 2008 13:07:53 -0700
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <135D1942-B913-45B4-BF09-19B4FF6386DD@mac.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>
	<135D1942-B913-45B4-BF09-19B4FF6386DD@mac.com>
Message-ID: <bbaeab100805141307s20618c6bw1a9c3bed94888cdf@mail.gmail.com>

On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> On 13 May, 2008, at 20:45, Brett Cannon wrote:
>>
>> At the moment, both directories and all files (including gestalt) have
>> been removed, so whomever adds the file back can choose the directory.
>> =)
>
> That won't be me, I barely have time to work on Python at the moment and am
> focussing all time I have on ensuring that Python2.6 will be the best
> possible release on OSX.
>
> How did you change platform? That module uses gestalt to calculate the osx
> platform version and architecture.
>

It looks like Benjamin didn't change it. The unit tests still passed,
though, possibly because platform.mac_ver() has a fallback if the
gestalt import failed.

I will create an issue to add back in gestalt. What about that little
module for urllib to get proxy info? How is that coming along?

-Brett

From ronaldoussoren at mac.com  Thu May 15 08:20:16 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 15 May 2008 08:20:16 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <bbaeab100805141307s20618c6bw1a9c3bed94888cdf@mail.gmail.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>
	<135D1942-B913-45B4-BF09-19B4FF6386DD@mac.com>
	<bbaeab100805141307s20618c6bw1a9c3bed94888cdf@mail.gmail.com>
Message-ID: <15224AEB-4D95-45A4-B101-D0BB4D724B09@mac.com>


On 14 May, 2008, at 22:07, Brett Cannon wrote:

> On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren <ronaldoussoren at mac.com 
> > wrote:
>>
>> On 13 May, 2008, at 20:45, Brett Cannon wrote:
>>>
>>> At the moment, both directories and all files (including gestalt)  
>>> have
>>> been removed, so whomever adds the file back can choose the  
>>> directory.
>>> =)
>>
>> That won't be me, I barely have time to work on Python at the  
>> moment and am
>> focussing all time I have on ensuring that Python2.6 will be the best
>> possible release on OSX.
>>
>> How did you change platform? That module uses gestalt to calculate  
>> the osx
>> platform version and architecture.
>>
>
> It looks like Benjamin didn't change it. The unit tests still passed,
> though, possibly because platform.mac_ver() has a fallback if the
> gestalt import failed.

I guess I'll have to find some time to add some unittests for  
platform.mac_ver then ;-)

>
>
> I will create an issue to add back in gestalt. What about that little
> module for urllib to get proxy info? How is that coming along?

That's already committed in the trunk, I guess it will be merged in  
py3k later on.

Ronald


From brett at python.org  Thu May 15 09:35:07 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 15 May 2008 00:35:07 -0700
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <15224AEB-4D95-45A4-B101-D0BB4D724B09@mac.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>
	<135D1942-B913-45B4-BF09-19B4FF6386DD@mac.com>
	<bbaeab100805141307s20618c6bw1a9c3bed94888cdf@mail.gmail.com>
	<15224AEB-4D95-45A4-B101-D0BB4D724B09@mac.com>
Message-ID: <bbaeab100805150035q1dd5d0f1xa392693b2be3f523@mail.gmail.com>

On Wed, May 14, 2008 at 11:20 PM, Ronald Oussoren
<ronaldoussoren at mac.com> wrote:
>
> On 14 May, 2008, at 22:07, Brett Cannon wrote:
>
>> On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren <ronaldoussoren at mac.com>
>> wrote:
>>>
>>> On 13 May, 2008, at 20:45, Brett Cannon wrote:
>>>>
>>>> At the moment, both directories and all files (including gestalt) have
>>>> been removed, so whomever adds the file back can choose the directory.
>>>> =)
>>>
>>> That won't be me, I barely have time to work on Python at the moment and
>>> am
>>> focussing all time I have on ensuring that Python2.6 will be the best
>>> possible release on OSX.
>>>
>>> How did you change platform? That module uses gestalt to calculate the
>>> osx
>>> platform version and architecture.
>>>
>>
>> It looks like Benjamin didn't change it. The unit tests still passed,
>> though, possibly because platform.mac_ver() has a fallback if the
>> gestalt import failed.
>
> I guess I'll have to find some time to add some unittests for
> platform.mac_ver then ;-)
>
>>
>>
>> I will create an issue to add back in gestalt. What about that little
>> module for urllib to get proxy info? How is that coming along?
>
> That's already committed in the trunk, I guess it will be merged in py3k
> later on.
>

I see the code using ctypes now. Assuming no one blocked the commit
for 3.0, then yes, it will get backported. Although a quick check of
svnmerge-integrated seems to suggest the commit was not backported
during the last merge. Crap. I will have a look.

-Brett

From brett at python.org  Thu May 15 09:39:00 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 15 May 2008 00:39:00 -0700
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <bbaeab100805150035q1dd5d0f1xa392693b2be3f523@mail.gmail.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>
	<135D1942-B913-45B4-BF09-19B4FF6386DD@mac.com>
	<bbaeab100805141307s20618c6bw1a9c3bed94888cdf@mail.gmail.com>
	<15224AEB-4D95-45A4-B101-D0BB4D724B09@mac.com>
	<bbaeab100805150035q1dd5d0f1xa392693b2be3f523@mail.gmail.com>
Message-ID: <bbaeab100805150039m3c1acc91l2161caba5d3c99dc@mail.gmail.com>

On Thu, May 15, 2008 at 12:35 AM, Brett Cannon <brett at python.org> wrote:
> On Wed, May 14, 2008 at 11:20 PM, Ronald Oussoren
> <ronaldoussoren at mac.com> wrote:
>>
>> On 14 May, 2008, at 22:07, Brett Cannon wrote:
>>
>>> On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren <ronaldoussoren at mac.com>
>>> wrote:
>>>>
>>>> On 13 May, 2008, at 20:45, Brett Cannon wrote:
>>>>>
>>>>> At the moment, both directories and all files (including gestalt) have
>>>>> been removed, so whomever adds the file back can choose the directory.
>>>>> =)
>>>>
>>>> That won't be me, I barely have time to work on Python at the moment and
>>>> am
>>>> focussing all time I have on ensuring that Python2.6 will be the best
>>>> possible release on OSX.
>>>>
>>>> How did you change platform? That module uses gestalt to calculate the
>>>> osx
>>>> platform version and architecture.
>>>>
>>>
>>> It looks like Benjamin didn't change it. The unit tests still passed,
>>> though, possibly because platform.mac_ver() has a fallback if the
>>> gestalt import failed.
>>
>> I guess I'll have to find some time to add some unittests for
>> platform.mac_ver then ;-)
>>
>>>
>>>
>>> I will create an issue to add back in gestalt. What about that little
>>> module for urllib to get proxy info? How is that coming along?
>>
>> That's already committed in the trunk, I guess it will be merged in py3k
>> later on.
>>
>
> I see the code using ctypes now. Assuming no one blocked the commit
> for 3.0, then yes, it will get backported. Although a quick check of
> svnmerge-integrated seems to suggest the commit was not backported
> during the last merge. Crap. I will have a look.

So it looks like no one has done a big merge in a little while. If the
code doesn't make it over in the next merge then it will have to be
merged explicitly.

-Brett

From mal at egenix.com  Thu May 15 11:51:13 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 15 May 2008 11:51:13 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <bbaeab100805141307s20618c6bw1a9c3bed94888cdf@mail.gmail.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>	<48295E0B.6050303@egenix.com>	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>	<48296629.4020602@egenix.com>	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>	<bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>	<135D1942-B913-45B4-BF09-19B4FF6386DD@mac.com>
	<bbaeab100805141307s20618c6bw1a9c3bed94888cdf@mail.gmail.com>
Message-ID: <482C0791.5010403@egenix.com>

On 2008-05-14 22:07, Brett Cannon wrote:
> On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>> On 13 May, 2008, at 20:45, Brett Cannon wrote:
>>> At the moment, both directories and all files (including gestalt) have
>>> been removed, so whomever adds the file back can choose the directory.
>>> =)
>> That won't be me, I barely have time to work on Python at the moment and am
>> focussing all time I have on ensuring that Python2.6 will be the best
>> possible release on OSX.
>>
>> How did you change platform? That module uses gestalt to calculate the osx
>> platform version and architecture.
>>
> 
> It looks like Benjamin didn't change it. The unit tests still passed,
> though, possibly because platform.mac_ver() has a fallback if the
> gestalt import failed.
> 
> I will create an issue to add back in gestalt. What about that little
> module for urllib to get proxy info? How is that coming along?

Question: Are we going to leave gestalt in plat-mac/ or move it
to plat-darwin/ ?

This basically maps to the question whether Py3k will still support
Mac OS 9 or not.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 15 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From brett at python.org  Thu May 15 20:33:04 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 15 May 2008 11:33:04 -0700
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <482C0791.5010403@egenix.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>
	<135D1942-B913-45B4-BF09-19B4FF6386DD@mac.com>
	<bbaeab100805141307s20618c6bw1a9c3bed94888cdf@mail.gmail.com>
	<482C0791.5010403@egenix.com>
Message-ID: <bbaeab100805151133k7ab360e5ga07ec28c9b2d3a68@mail.gmail.com>

On Thu, May 15, 2008 at 2:51 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2008-05-14 22:07, Brett Cannon wrote:
>>
>> On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren <ronaldoussoren at mac.com>
>> wrote:
>>>
>>> On 13 May, 2008, at 20:45, Brett Cannon wrote:
>>>>
>>>> At the moment, both directories and all files (including gestalt) have
>>>> been removed, so whomever adds the file back can choose the directory.
>>>> =)
>>>
>>> That won't be me, I barely have time to work on Python at the moment and
>>> am
>>> focussing all time I have on ensuring that Python2.6 will be the best
>>> possible release on OSX.
>>>
>>> How did you change platform? That module uses gestalt to calculate the
>>> osx
>>> platform version and architecture.
>>>
>>
>> It looks like Benjamin didn't change it. The unit tests still passed,
>> though, possibly because platform.mac_ver() has a fallback if the
>> gestalt import failed.
>>
>> I will create an issue to add back in gestalt. What about that little
>> module for urllib to get proxy info? How is that coming along?
>
> Question: Are we going to leave gestalt in plat-mac/ or move it
> to plat-darwin/ ?
>

Well, if we stick with the C version, it should just go into Modules.

> This basically maps to the question whether Py3k will still support
> Mac OS 9 or not.
>

Mac OS 9 support was removed at least a version ago.

-Brett

From mal at egenix.com  Fri May 16 16:55:59 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 16 May 2008 16:55:59 +0200
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <bbaeab100805151133k7ab360e5ga07ec28c9b2d3a68@mail.gmail.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>	<48295E0B.6050303@egenix.com>	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>	<48296629.4020602@egenix.com>	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>	<bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>	<135D1942-B913-45B4-BF09-19B4FF6386DD@mac.com>	<bbaeab100805141307s20618c6bw1a9c3bed94888cdf@mail.gmail.com>	<482C0791.5010403@egenix.com>
	<bbaeab100805151133k7ab360e5ga07ec28c9b2d3a68@mail.gmail.com>
Message-ID: <482DA07F.3080101@egenix.com>

On 2008-05-15 20:33, Brett Cannon wrote:
> On Thu, May 15, 2008 at 2:51 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>> On 2008-05-14 22:07, Brett Cannon wrote:
>>> On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren <ronaldoussoren at mac.com>
>>> wrote:
>>>> On 13 May, 2008, at 20:45, Brett Cannon wrote:
>>>>> At the moment, both directories and all files (including gestalt) have
>>>>> been removed, so whomever adds the file back can choose the directory.
>>>>> =)
>>>> That won't be me, I barely have time to work on Python at the moment and
>>>> am
>>>> focussing all time I have on ensuring that Python2.6 will be the best
>>>> possible release on OSX.
>>>>
>>>> How did you change platform? That module uses gestalt to calculate the
>>>> osx
>>>> platform version and architecture.
>>>>
>>> It looks like Benjamin didn't change it. The unit tests still passed,
>>> though, possibly because platform.mac_ver() has a fallback if the
>>> gestalt import failed.
>>>
>>> I will create an issue to add back in gestalt. What about that little
>>> module for urllib to get proxy info? How is that coming along?
>> Question: Are we going to leave gestalt in plat-mac/ or move it
>> to plat-darwin/ ?
>>
> 
> Well, if we stick with the C version, it should just go into Modules.

It was in Mac/Modules/ and I had a look yesterday at getting it
back in there, but the Mac build system looked to complicated to
touch (esp. since gestalt is built as part of the Carbon lib stuff).

Someone else with more knowledge about the Mac build will have to
give it a go.

>> This basically maps to the question whether Py3k will still support
>> Mac OS 9 or not.
>>
> 
> Mac OS 9 support was removed at least a version ago.

So lib-mac/ can basically stay gone or at least the modules
still needed from there should be moved/revived to lib-darwin/.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 16 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 ronaldoussoren at mac.com  Fri May 16 17:19:22 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 16 May 2008 08:19:22 -0700
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <482DA07F.3080101@egenix.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48295E0B.6050303@egenix.com>
	<E918B386-2717-4E14-B0BE-FD6B497C15F8@mac.com>
	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>
	<135D1942-B913-45B4-BF09-19B4FF6386DD@mac.com>
	<bbaeab100805141307s20618c6bw1a9c3bed94888cdf@mail.gmail.com>
	<482C0791.5010403@egenix.com>
	<bbaeab100805151133k7ab360e5ga07ec28c9b2d3a68@mail.gmail.com>
	<482DA07F.3080101@egenix.com>
Message-ID: <1BE289EB-0119-1000-ABEE-EFCBAAC3E8EB-Webmail-10006@mac.com>

 
On Friday, May 16, 2008, at 04:56PM, "M.-A. Lemburg" <mal at egenix.com> wrote:

>> 
>> Well, if we stick with the C version, it should just go into Modules.
>
>It was in Mac/Modules/ and I had a look yesterday at getting it
>back in there, but the Mac build system looked to complicated to
>touch (esp. since gestalt is built as part of the Carbon lib stuff).
>
>Someone else with more knowledge about the Mac build will have to
>give it a go.

Adding it to Modules shouldn't be to hard, the only special thing about
the Mac libraries is that they require and addition link argument: "-framework Carbon".

>
>>> This basically maps to the question whether Py3k will still support
>>> Mac OS 9 or not.
>>>
>> 
>> Mac OS 9 support was removed at least a version ago.
>
>So lib-mac/ can basically stay gone or at least the modules
>still needed from there should be moved/revived to lib-darwin/.

I'm looking into this for python2.6 (although mostly to document
the alternatives). 

Ronald


From brett at python.org  Fri May 16 20:10:53 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 16 May 2008 11:10:53 -0700
Subject: [stdlib-sig] gestalt, too?
In-Reply-To: <1BE289EB-0119-1000-ABEE-EFCBAAC3E8EB-Webmail-10006@mac.com>
References: <1afaf6160805111910u5fd37ed7g5a55975666dc67b2@mail.gmail.com>
	<48296629.4020602@egenix.com>
	<80BAA8B8-DFE1-47C8-8AB3-A3F916994CC7@mac.com>
	<bbaeab100805131145i1535baa0y5d3d3295bb42876b@mail.gmail.com>
	<135D1942-B913-45B4-BF09-19B4FF6386DD@mac.com>
	<bbaeab100805141307s20618c6bw1a9c3bed94888cdf@mail.gmail.com>
	<482C0791.5010403@egenix.com>
	<bbaeab100805151133k7ab360e5ga07ec28c9b2d3a68@mail.gmail.com>
	<482DA07F.3080101@egenix.com>
	<1BE289EB-0119-1000-ABEE-EFCBAAC3E8EB-Webmail-10006@mac.com>
Message-ID: <bbaeab100805161110yf82ee0aq82fe60043399f78e@mail.gmail.com>

On Fri, May 16, 2008 at 8:19 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> On Friday, May 16, 2008, at 04:56PM, "M.-A. Lemburg" <mal at egenix.com> wrote:
>
>>>
>>> Well, if we stick with the C version, it should just go into Modules.
>>
>>It was in Mac/Modules/ and I had a look yesterday at getting it
>>back in there, but the Mac build system looked to complicated to
>>touch (esp. since gestalt is built as part of the Carbon lib stuff).
>>
>>Someone else with more knowledge about the Mac build will have to
>>give it a go.
>
> Adding it to Modules shouldn't be to hard, the only special thing about
> the Mac libraries is that they require and addition link argument: "-framework Carbon".
>

Well, do we want to continue with this Modules sub-directory or should
it just end up in  the Mac directory itself, ala the PC directory and
its extension modules?

>>
>>>> This basically maps to the question whether Py3k will still support
>>>> Mac OS 9 or not.
>>>>
>>>
>>> Mac OS 9 support was removed at least a version ago.
>>
>>So lib-mac/ can basically stay gone or at least the modules
>>still needed from there should be moved/revived to lib-darwin/.
>
> I'm looking into this for python2.6 (although mostly to document
> the alternatives).

Benjamin has a patch up on Issue2854 to add the module back, but I
think it is for adding the code to Modules.

-Brett

From brett at python.org  Mon May 19 21:21:25 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 19 May 2008 12:21:25 -0700
Subject: [stdlib-sig] Changing the 2.6 renames to not break pickle
Message-ID: <bbaeab100805191221q6ad5d3b5le2de06fa8e1e63bc@mail.gmail.com>

Apparently pickle doesn't like the way renames have been handled in
2.6 and people don't want to mess with pickle, so that means the
renames need to change.

So, here is my idea (only need to care about modules that have stuff
to pickle, e.g., don't need to change test.support):

* Rename lib-old to lib-new

* Change the names in lib-new to the new names.

* Change the names in the stdlib to the old names.

* Move the Py3K warnings out of the stubs in lib-new and put them in
the modules directly stored in the stdlib.

* Change the imports in the stubs in lib-new to import the old name
and suppress the Py3K warning (probably use
test.support.catch_warning() with a *very* specific ignore filter).

I think that gets __module__ set to the old module name even when code
is imported with the new name. It should also allow the Py3K warnings
to stick around without causing issues when importing from the new
name or suppressing other Py3K warnings. What do people think?

-Brett

From solipsis at pitrou.net  Mon May 19 22:30:52 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 19 May 2008 22:30:52 +0200
Subject: [stdlib-sig] Changing the 2.6 renames to not break pickle
In-Reply-To: <bbaeab100805191320s3ee71708k7c0eadf3ad8cfe44@mail.gmail.com>
References: <bbaeab100805191221q6ad5d3b5le2de06fa8e1e63bc@mail.gmail.com>
	<1211226514.5892.10.camel@fsol>
	<bbaeab100805191320s3ee71708k7c0eadf3ad8cfe44@mail.gmail.com>
Message-ID: <1211229052.5892.12.camel@fsol>

Le lundi 19 mai 2008 ? 13:20 -0700, Brett Cannon a ?crit :
> On Mon, May 19, 2008 at 12:48 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > Le lundi 19 mai 2008 ? 12:21 -0700, Brett Cannon a ?crit :
> >> I think that gets __module__ set to the old module name even when code
> >> is imported with the new name. It should also allow the Py3K warnings
> >> to stick around without causing issues when importing from the new
> >> name or suppressing other Py3K warnings. What do people think?
> >
> > Are 2.x pickles supposed to be re-usable under py3k?
> 
> No. This is only so that 2.5 pickles work with 2.6.

Ok. But still, it means that help(new_module_name) will display the old
module name in the help contents?



From brett at python.org  Mon May 19 22:47:25 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 19 May 2008 13:47:25 -0700
Subject: [stdlib-sig] Changing the 2.6 renames to not break pickle
In-Reply-To: <1211229052.5892.12.camel@fsol>
References: <bbaeab100805191221q6ad5d3b5le2de06fa8e1e63bc@mail.gmail.com>
	<1211226514.5892.10.camel@fsol>
	<bbaeab100805191320s3ee71708k7c0eadf3ad8cfe44@mail.gmail.com>
	<1211229052.5892.12.camel@fsol>
Message-ID: <bbaeab100805191347w5839df8du1c736e1922e50335@mail.gmail.com>

On Mon, May 19, 2008 at 1:30 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le lundi 19 mai 2008 ? 13:20 -0700, Brett Cannon a ?crit :
>> On Mon, May 19, 2008 at 12:48 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> > Le lundi 19 mai 2008 ? 12:21 -0700, Brett Cannon a ?crit :
>> >> I think that gets __module__ set to the old module name even when code
>> >> is imported with the new name. It should also allow the Py3K warnings
>> >> to stick around without causing issues when importing from the new
>> >> name or suppressing other Py3K warnings. What do people think?
>> >
>> > Are 2.x pickles supposed to be re-usable under py3k?
>>
>> No. This is only so that 2.5 pickles work with 2.6.
>
> Ok. But still, it means that help(new_module_name) will display the old
> module name in the help contents?

Yep, nothing we can do about that without piling on even more support
infrastructure.

-Brett

From alexandre at peadrop.com  Mon May 19 23:23:26 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Mon, 19 May 2008 17:23:26 -0400
Subject: [stdlib-sig] Changing the 2.6 renames to not break pickle
In-Reply-To: <bbaeab100805191221q6ad5d3b5le2de06fa8e1e63bc@mail.gmail.com>
References: <bbaeab100805191221q6ad5d3b5le2de06fa8e1e63bc@mail.gmail.com>
Message-ID: <acd65fa20805191423g500f341y4866c0225d84578d@mail.gmail.com>

On Mon, May 19, 2008 at 3:21 PM, Brett Cannon <brett at python.org> wrote:
> Apparently pickle doesn't like the way renames have been handled in
> 2.6 and people don't want to mess with pickle, so that means the
> renames need to change.
>
> So, here is my idea (only need to care about modules that have stuff
> to pickle, e.g., don't need to change test.support):
>
> * Rename lib-old to lib-new
>
> * Change the names in lib-new to the new names.
>
> * Change the names in the stdlib to the old names.
>
> * Move the Py3K warnings out of the stubs in lib-new and put them in
> the modules directly stored in the stdlib.
>
> * Change the imports in the stubs in lib-new to import the old name
> and suppress the Py3K warning (probably use
> test.support.catch_warning() with a *very* specific ignore filter).
>
> I think that gets __module__ set to the old module name even when code
> is imported with the new name. It should also allow the Py3K warnings
> to stick around without causing issues when importing from the new
> name or suppressing other Py3K warnings. What do people think?
>

Sound fine to me. Although this is going to be mess, it seems to be
our only reasonable choice.

-- Alexandre

From brett at python.org  Tue May 20 00:10:58 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 19 May 2008 15:10:58 -0700
Subject: [stdlib-sig] Changing the 2.6 renames to not break pickle
In-Reply-To: <acd65fa20805191423g500f341y4866c0225d84578d@mail.gmail.com>
References: <bbaeab100805191221q6ad5d3b5le2de06fa8e1e63bc@mail.gmail.com>
	<acd65fa20805191423g500f341y4866c0225d84578d@mail.gmail.com>
Message-ID: <bbaeab100805191510i560e2b37w1bdfe2bed72458a4@mail.gmail.com>

On Mon, May 19, 2008 at 2:23 PM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
> On Mon, May 19, 2008 at 3:21 PM, Brett Cannon <brett at python.org> wrote:
>> Apparently pickle doesn't like the way renames have been handled in
>> 2.6 and people don't want to mess with pickle, so that means the
>> renames need to change.
>>
>> So, here is my idea (only need to care about modules that have stuff
>> to pickle, e.g., don't need to change test.support):
>>
>> * Rename lib-old to lib-new
>>
>> * Change the names in lib-new to the new names.
>>
>> * Change the names in the stdlib to the old names.
>>
>> * Move the Py3K warnings out of the stubs in lib-new and put them in
>> the modules directly stored in the stdlib.
>>
>> * Change the imports in the stubs in lib-new to import the old name
>> and suppress the Py3K warning (probably use
>> test.support.catch_warning() with a *very* specific ignore filter).
>>
>> I think that gets __module__ set to the old module name even when code
>> is imported with the new name. It should also allow the Py3K warnings
>> to stick around without causing issues when importing from the new
>> name or suppressing other Py3K warnings. What do people think?
>>
>
> Sound fine to me. Although this is going to be mess, it seems to be
> our only reasonable choice.

Yes, it will be a pain. I have not exactly been in high spirits since
this came up. But we can move each module on its own so at least it
does not need to be done en-masse.

-Brett

From python at rcn.com  Tue May 20 02:10:05 2008
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 19 May 2008 17:10:05 -0700
Subject: [stdlib-sig] Changing the 2.6 renames to not break pickle
References: <bbaeab100805191221q6ad5d3b5le2de06fa8e1e63bc@mail.gmail.com>
Message-ID: <D440D0F4406141E6999A4BDD9FED9263@RaymondLaptop1>

From: "Brett Cannon" <brett at python.org>
> So, here is my idea (only need to care about modules that have stuff
> to pickle, e.g., don't need to change test.support):
> 
> * Rename lib-old to lib-new
> 
> * Change the names in lib-new to the new names.
> 
> * Change the names in the stdlib to the old names.
> 
> * Move the Py3K warnings out of the stubs in lib-new and put them in
> the modules directly stored in the stdlib.
> 
> * Change the imports in the stubs in lib-new to import the old name
> and suppress the Py3K warning (probably use
> test.support.catch_warning() with a *very* specific ignore filter).

That plan seems harmless enough, but why bother?


> I think that gets __module__ set to the old module name even when code
> is imported with the new name. It should also allow the Py3K warnings
> to stick around without causing issues when importing from the new
> name or suppressing other Py3K warnings. What do people think?

What is the purpose of 2.6 knowing anything about the 3.0 module names?
Since this is the kind of thing that the 2-to-3 converter handles easily,
how does this make my life any easier when porting programs to 3.0?
AFAICT, there is no benefit to me as a programmer, so why bother?


Raymond

From brett at python.org  Tue May 20 02:13:13 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 19 May 2008 17:13:13 -0700
Subject: [stdlib-sig] Changing the 2.6 renames to not break pickle
In-Reply-To: <D440D0F4406141E6999A4BDD9FED9263@RaymondLaptop1>
References: <bbaeab100805191221q6ad5d3b5le2de06fa8e1e63bc@mail.gmail.com>
	<D440D0F4406141E6999A4BDD9FED9263@RaymondLaptop1>
Message-ID: <bbaeab100805191713q4ca454e5ke98aed927a33af0b@mail.gmail.com>

On Mon, May 19, 2008 at 5:10 PM, Raymond Hettinger <python at rcn.com> wrote:
> From: "Brett Cannon" <brett at python.org>
>>
>> So, here is my idea (only need to care about modules that have stuff
>> to pickle, e.g., don't need to change test.support):
>>
>> * Rename lib-old to lib-new
>>
>> * Change the names in lib-new to the new names.
>>
>> * Change the names in the stdlib to the old names.
>>
>> * Move the Py3K warnings out of the stubs in lib-new and put them in
>> the modules directly stored in the stdlib.
>>
>> * Change the imports in the stubs in lib-new to import the old name
>> and suppress the Py3K warning (probably use
>> test.support.catch_warning() with a *very* specific ignore filter).
>
> That plan seems harmless enough, but why bother?

Same reason given on python-dev when you asked this question before.
=) 2.6 is supposed to minimize the differences between 2.x and 3.0 as
much as possible without having to run 2to3. Plus I don't want to have
to change imports in patches between 2.6 and 3.0 if I don't have to.

-Brett

From python at rcn.com  Tue May 20 02:31:11 2008
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 19 May 2008 17:31:11 -0700
Subject: [stdlib-sig] Changing the 2.6 renames to not break pickle
References: <bbaeab100805191221q6ad5d3b5le2de06fa8e1e63bc@mail.gmail.com>
	<D440D0F4406141E6999A4BDD9FED9263@RaymondLaptop1>
	<bbaeab100805191713q4ca454e5ke98aed927a33af0b@mail.gmail.com>
Message-ID: <08DAC767C77D4DA2A44550ED3ED65343@RaymondLaptop1>

From: "Brett Cannon" <brett at python.org>
>>> So, here is my idea (only need to care about modules that have stuff
>>> to pickle, e.g., don't need to change test.support):
>>>
>>> * Rename lib-old to lib-new
>>>
>>> * Change the names in lib-new to the new names.
>>>
>>> * Change the names in the stdlib to the old names.
>>>
>>> * Move the Py3K warnings out of the stubs in lib-new and put them in
>>> the modules directly stored in the stdlib.

I thought we weren't going to put in 3k warnings for anything
that was automatically handled by the 2-to-3 converter.
I remember taking out a few of those warnings at some point
once the converter had been brought up-to-date.

IIRC, the reason is that it makes the -3 option more difficult to use
in that it would give you tons of warnings for things you don't need
to change to get programs working after the 2-to-3 conversion.

The transition was supposed to be:
1. get unittests working in 2.6
2. run 2.6 with the -3 option and do fixups which leave the code running in 2.6 and unittests still passing.
2. run the 2-to-3 converter and verify the unittests still work.

Step two is the only manual step and we want to minimize the number of manual interventions.

>>>
>>> * Change the imports in the stubs in lib-new to import the old name
>>> and suppress the Py3K warning (probably use
>>> test.support.catch_warning() with a *very* specific ignore filter).
>>
>> That plan seems harmless enough, but why bother?
> 
> Same reason given on python-dev when you asked this question before.
> =) 2.6 is supposed to minimize the differences between 2.x and 3.0 as
> much as possible without having to run 2to3.

Put me down for a -1.  ISTM, this does more harm than good.
Nothing good can come from conflating the old and new names in the same code base.
It doesn't make life easier for people learning 2.6, nor for people converting from 2.6,
and especially not for people who already have modules with conflicting names (it's not
have to imagine that some users or third-party apps have a module named queue).

> Plus I don't want to have
> to change imports in patches between 2.6 and 3.0 if I don't have to.

Won't you still have to import libnew, so the effort will be about the same?

It has been said many times that the goal is not have the exact same code run
under both 2.6 and 3.0.  I'm not sure how this is notion is rearing its head again.


Raymond

From brett at python.org  Tue May 20 05:40:32 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 19 May 2008 20:40:32 -0700
Subject: [stdlib-sig] Changing the 2.6 renames to not break pickle
In-Reply-To: <08DAC767C77D4DA2A44550ED3ED65343@RaymondLaptop1>
References: <bbaeab100805191221q6ad5d3b5le2de06fa8e1e63bc@mail.gmail.com>
	<D440D0F4406141E6999A4BDD9FED9263@RaymondLaptop1>
	<bbaeab100805191713q4ca454e5ke98aed927a33af0b@mail.gmail.com>
	<08DAC767C77D4DA2A44550ED3ED65343@RaymondLaptop1>
Message-ID: <bbaeab100805192040w74f30216h6ac06c100b309617@mail.gmail.com>

On Mon, May 19, 2008 at 5:31 PM, Raymond Hettinger <python at rcn.com> wrote:
> From: "Brett Cannon" <brett at python.org>
>>>>
>>>> So, here is my idea (only need to care about modules that have stuff
>>>> to pickle, e.g., don't need to change test.support):
>>>>
>>>> * Rename lib-old to lib-new
>>>>
>>>> * Change the names in lib-new to the new names.
>>>>
>>>> * Change the names in the stdlib to the old names.
>>>>
>>>> * Move the Py3K warnings out of the stubs in lib-new and put them in
>>>> the modules directly stored in the stdlib.
>
> I thought we weren't going to put in 3k warnings for anything
> that was automatically handled by the 2-to-3 converter.
> I remember taking out a few of those warnings at some point
> once the converter had been brought up-to-date.
>
> IIRC, the reason is that it makes the -3 option more difficult to use
> in that it would give you tons of warnings for things you don't need
> to change to get programs working after the 2-to-3 conversion.
>
> The transition was supposed to be:
> 1. get unittests working in 2.6
> 2. run 2.6 with the -3 option and do fixups which leave the code running in
> 2.6 and unittests still passing.
> 2. run the 2-to-3 converter and verify the unittests still work.
>
> Step two is the only manual step and we want to minimize the number of
> manual interventions.
>
>>>>
>>>> * Change the imports in the stubs in lib-new to import the old name
>>>> and suppress the Py3K warning (probably use
>>>> test.support.catch_warning() with a *very* specific ignore filter).
>>>
>>> That plan seems harmless enough, but why bother?
>>
>> Same reason given on python-dev when you asked this question before.
>> =) 2.6 is supposed to minimize the differences between 2.x and 3.0 as
>> much as possible without having to run 2to3.
>
> Put me down for a -1.  ISTM, this does more harm than good.
> Nothing good can come from conflating the old and new names in the same code
> base.
> It doesn't make life easier for people learning 2.6, nor for people
> converting from 2.6,
> and especially not for people who already have modules with conflicting
> names (it's not
> have to imagine that some users or third-party apps have a module named
> queue).
>
>> Plus I don't want to have
>> to change imports in patches between 2.6 and 3.0 if I don't have to.
>
> Won't you still have to import libnew, so the effort will be about the same?
>
> It has been said many times that the goal is not have the exact same code
> run
> under both 2.6 and 3.0.  I'm not sure how this is notion is rearing its head
> again.
>

You know what, we will just do it your way without the new names in
2.6 because my stress level just can't take being bothered with adding
new stubs. We will just revert the patches that applied the new names
in 2.6 and be done with it.

-Brett

From mal at egenix.com  Tue May 20 11:51:06 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 20 May 2008 11:51:06 +0200
Subject: [stdlib-sig] Changing the 2.6 renames to not break pickle
In-Reply-To: <bbaeab100805192040w74f30216h6ac06c100b309617@mail.gmail.com>
References: <bbaeab100805191221q6ad5d3b5le2de06fa8e1e63bc@mail.gmail.com>	<D440D0F4406141E6999A4BDD9FED9263@RaymondLaptop1>	<bbaeab100805191713q4ca454e5ke98aed927a33af0b@mail.gmail.com>	<08DAC767C77D4DA2A44550ED3ED65343@RaymondLaptop1>
	<bbaeab100805192040w74f30216h6ac06c100b309617@mail.gmail.com>
Message-ID: <48329F0A.60009@egenix.com>

On 2008-05-20 05:40, Brett Cannon wrote:
> On Mon, May 19, 2008 at 5:31 PM, Raymond Hettinger <python at rcn.com> wrote:
>> It has been said many times that the goal is not have the exact same code
>> run
>> under both 2.6 and 3.0.  I'm not sure how this is notion is rearing its head
>> again.
>>
> 
> You know what, we will just do it your way without the new names in
> 2.6 because my stress level just can't take being bothered with adding
> new stubs. We will just revert the patches that applied the new names
> in 2.6 and be done with it.

Sorry, Brett for the wasted time and thank you for reverting the
changes.

I'm sure that a lot of Python 2.6 users will make this happy
(even if most will probably never know).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 20 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From brett at python.org  Tue May 20 20:36:52 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 20 May 2008 11:36:52 -0700
Subject: [stdlib-sig] Changing the 2.6 renames to not break pickle
In-Reply-To: <48329F0A.60009@egenix.com>
References: <bbaeab100805191221q6ad5d3b5le2de06fa8e1e63bc@mail.gmail.com>
	<D440D0F4406141E6999A4BDD9FED9263@RaymondLaptop1>
	<bbaeab100805191713q4ca454e5ke98aed927a33af0b@mail.gmail.com>
	<08DAC767C77D4DA2A44550ED3ED65343@RaymondLaptop1>
	<bbaeab100805192040w74f30216h6ac06c100b309617@mail.gmail.com>
	<48329F0A.60009@egenix.com>
Message-ID: <bbaeab100805201136x373c1467m376100b14c680bb3@mail.gmail.com>

On Tue, May 20, 2008 at 2:51 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2008-05-20 05:40, Brett Cannon wrote:
>>
>> On Mon, May 19, 2008 at 5:31 PM, Raymond Hettinger <python at rcn.com> wrote:
>>>
>>> It has been said many times that the goal is not have the exact same code
>>> run
>>> under both 2.6 and 3.0.  I'm not sure how this is notion is rearing its
>>> head
>>> again.
>>>
>>
>> You know what, we will just do it your way without the new names in
>> 2.6 because my stress level just can't take being bothered with adding
>> new stubs. We will just revert the patches that applied the new names
>> in 2.6 and be done with it.
>
> Sorry, Brett for the wasted time and thank you for reverting the
> changes.
>

I actually didn't do any of the renames (been focusing on the
deprecations); Benjamin, Alexandre, and Georg did most of the rename
commits. My stress comes from feeling responsible for the whole
process.

> I'm sure that a lot of Python 2.6 users will make this happy
> (even if most will probably never know).

No, they probably will never know. No one every staid this wasn't a
thankless job.

-Brett