From p.f.moore at gmail.com  Thu Apr  3 13:10:40 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 3 Apr 2008 12:10:40 +0100
Subject: [stdlib-sig] [Python-3000] Types and classes
In-Reply-To: <ca471dc20804021652k425e0647ve1522855296f2636@mail.gmail.com>
References: <1cb725390804021457j76179af5y89c84335f65aa454@mail.gmail.com>
	<ca471dc20804021520l6476a070h6b9145c1cf16c678@mail.gmail.com>
	<1afaf6160804021534y5ef9636dnf22a2a06d450e294@mail.gmail.com>
	<ca471dc20804021551p76394ec2h5b060735930239e6@mail.gmail.com>
	<1afaf6160804021558l484185dfsa603591a4bc6eb35@mail.gmail.com>
	<ca471dc20804021601x2a497717p4680dd89594c1168@mail.gmail.com>
	<1afaf6160804021604t1f0a0514q41621479d3c33172@mail.gmail.com>
	<ca471dc20804021609j535c54c8h76c5d75ddf992e5a@mail.gmail.com>
	<1cb725390804021645t1604a6dck27038741c76b32ca@mail.gmail.com>
	<ca471dc20804021652k425e0647ve1522855296f2636@mail.gmail.com>
Message-ID: <79990c6b0804030410h7f1480fr35f5984e02be3ef5@mail.gmail.com>

On 03/04/2008, Guido van Rossum <guido at python.org> wrote:
> On Wed, Apr 2, 2008 at 4:45 PM, Paul Prescod <paul at prescod.net> wrote:
> > Also, could the types module be renamed "builtin_classes" or
> >  "core_classes" or something like that? It was always a weird name
> >  because it wasn't if it contained all of the types in a Python
> >  distribution. Just a set of core-to-the-implementation ones.
>
> That's up to the stdlib reorg committee; my position has been for a
> long time that there shouldn't be a types module at all.

*If* it's to be renamed (which I have no strong opinion on) would
making it sys.classes (or sys.types) be plausible? With the "sys =
core" connotation, I find this better than an underscored name.

Paul.

From brett at python.org  Thu Apr  3 13:21:22 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 3 Apr 2008 13:21:22 +0200
Subject: [stdlib-sig] [Python-3000] Types and classes
In-Reply-To: <79990c6b0804030410h7f1480fr35f5984e02be3ef5@mail.gmail.com>
References: <1cb725390804021457j76179af5y89c84335f65aa454@mail.gmail.com>
	<1afaf6160804021534y5ef9636dnf22a2a06d450e294@mail.gmail.com>
	<ca471dc20804021551p76394ec2h5b060735930239e6@mail.gmail.com>
	<1afaf6160804021558l484185dfsa603591a4bc6eb35@mail.gmail.com>
	<ca471dc20804021601x2a497717p4680dd89594c1168@mail.gmail.com>
	<1afaf6160804021604t1f0a0514q41621479d3c33172@mail.gmail.com>
	<ca471dc20804021609j535c54c8h76c5d75ddf992e5a@mail.gmail.com>
	<1cb725390804021645t1604a6dck27038741c76b32ca@mail.gmail.com>
	<ca471dc20804021652k425e0647ve1522855296f2636@mail.gmail.com>
	<79990c6b0804030410h7f1480fr35f5984e02be3ef5@mail.gmail.com>
Message-ID: <bbaeab100804030421g270b1554ybc9d2b2d1c6d7080@mail.gmail.com>

On Thu, Apr 3, 2008 at 1:10 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 03/04/2008, Guido van Rossum <guido at python.org> wrote:
>  > On Wed, Apr 2, 2008 at 4:45 PM, Paul Prescod <paul at prescod.net> wrote:
>  > > Also, could the types module be renamed "builtin_classes" or
>  > >  "core_classes" or something like that? It was always a weird name
>  > >  because it wasn't if it contained all of the types in a Python
>  > >  distribution. Just a set of core-to-the-implementation ones.
>  >
>  > That's up to the stdlib reorg committee; my position has been for a
>  > long time that there shouldn't be a types module at all.
>
>  *If* it's to be renamed (which I have no strong opinion on) would
>  making it sys.classes (or sys.types) be plausible? With the "sys =
>  core" connotation, I find this better than an underscored name.

Not without taking a proper look at the sys module and how it should
potentially be changed. It has become too much of a dumping ground for
stuff in my opinion. There could definitely stand to be more of a
separation between interpreter info and the current platform. Or even
information versus changing what the interpreter can do.

But I am about to propose the removal of the 'types' module anyway, so
I am not feeling very invested in this. =)

-Brett

From brett at python.org  Thu Apr  3 13:24:28 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 3 Apr 2008 13:24:28 +0200
Subject: [stdlib-sig] proposed removal: the types module
Message-ID: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>

You can just call 'type' on something to get the type needed. And
practically all of the types listed are easy to get from some object
lying about that is of the proper type. Plus Guido supports its
removal. =)

-Brett

From mal at egenix.com  Thu Apr  3 13:39:42 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 03 Apr 2008 13:39:42 +0200
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
Message-ID: <47F4C1FE.7050603@egenix.com>

On 2008-04-03 13:24, Brett Cannon wrote:
> You can just call 'type' on something to get the type needed. 

Well, yes, but that's just what the types module does, isn't it ?

It's really just a more practical way of getting at the type
object than having to create a temporary object just to get
at the type object.

For basic types you don't need it (e.g. int, float, str, etc.),
but there are quite a few types in Python that don't have a
builtin constructor, e.g. methods, modules, instances, etc.

I also don't know how a 2to3 tool would handle such a removal.
It would have to remove the "import types" or "from types import
BuiltinMethodType", then add helper code to get at the type object and
then use the generated code in all places that need the type
object.

-1 on removing it, since it would not help in any way.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 03 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 barry at python.org  Thu Apr  3 14:03:27 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 3 Apr 2008 08:03:27 -0400
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <47F4C1FE.7050603@egenix.com>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
	<47F4C1FE.7050603@egenix.com>
Message-ID: <B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>

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

On Apr 3, 2008, at 7:39 AM, M.-A. Lemburg wrote:
> On 2008-04-03 13:24, Brett Cannon wrote:
>> You can just call 'type' on something to get the type needed.
>
> Well, yes, but that's just what the types module does, isn't it ?
>
> It's really just a more practical way of getting at the type
> object than having to create a temporary object just to get
> at the type object.
>
> For basic types you don't need it (e.g. int, float, str, etc.),
> but there are quite a few types in Python that don't have a
> builtin constructor, e.g. methods, modules, instances, etc.

Plus, there are a few types in there that are difficult or impossible  
to get from Python.

- -1 unless you can find another place to stash such types.

- -Barry

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

iQCVAwUBR/THkHEjvBPtnXfVAQIR8AP/T4LFcI75JudY69L9boSXtLd1l18Br2+H
OnhBceeeibouFGelyqS09tP+HnTrYLo/wUsROpQ7QRG9MukECXiZ9LFyLtC41ESH
jCbPT8nbeHjmkL4N5ym5DU+JWWZBZfDxzWp7khvYk5G4lqznWGuOnAvBNKnwHCyd
YDhntCCIGo8=
=ZjTI
-----END PGP SIGNATURE-----

From barry at python.org  Thu Apr  3 14:12:19 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 3 Apr 2008 08:12:19 -0400
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <47F4C8BB.8000903@cheimes.de>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>	<47F4C1FE.7050603@egenix.com>
	<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>
	<47F4C8BB.8000903@cheimes.de>
Message-ID: <6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>

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

On Apr 3, 2008, at 8:08 AM, Christian Heimes wrote:
> Barry Warsaw schrieb:
>> Plus, there are a few types in there that are difficult or impossible
>> to get from Python.
>>
>> -1 unless you can find another place to stash such types.
>
> ModuleType -> imp.module
> exception related types -> traceback module
> Function, method and code types -> sys module
> remaining stuff -> inspect

Actually, inspect.types might be a good place to put them all.

- -Barry

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

iQCVAwUBR/TJo3EjvBPtnXfVAQJDygQAmoXKq99jeRB5K6O4mVyPkErrbZCi2K72
Kh4mKC65UmGv+GhhUQTlO96e87xKh1p29kS/ajILGDoBfj62WVJ/ZxkEivrSN9ge
Gw6PmA6HbsP/UUArreLsIOcVDeLEw9Zwfb4m/aQqycJM206DfvLwAhLerLaBYaPm
qzhOIG3hS7E=
=qCy8
-----END PGP SIGNATURE-----

From mal at egenix.com  Thu Apr  3 14:14:26 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 03 Apr 2008 14:14:26 +0200
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <47F4C8BB.8000903@cheimes.de>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>	<47F4C1FE.7050603@egenix.com>	<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>
	<47F4C8BB.8000903@cheimes.de>
Message-ID: <47F4CA22.5080500@egenix.com>

On 2008-04-03 14:08, Christian Heimes wrote:
> Barry Warsaw schrieb:
>> Plus, there are a few types in there that are difficult or impossible  
>> to get from Python.
>>
>> -1 unless you can find another place to stash such types.
> 
> ModuleType -> imp.module
> exception related types -> traceback module
> Function, method and code types -> sys module
> remaining stuff -> inspect
> 
> ?

Now that sounds easy to remember... ;-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 03 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 musiccomposition at gmail.com  Thu Apr  3 14:49:23 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Thu, 3 Apr 2008 07:49:23 -0500
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
	<47F4C1FE.7050603@egenix.com>
	<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>
	<47F4C8BB.8000903@cheimes.de>
	<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>
Message-ID: <1afaf6160804030549k2dacacs6704383bc3c733c2@mail.gmail.com>

On Thu, Apr 3, 2008 at 7:12 AM, Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Apr 3, 2008, at 8:08 AM, Christian Heimes wrote:
> > Barry Warsaw schrieb:
> >> Plus, there are a few types in there that are difficult or impossible
> >> to get from Python.
> >>
> >> -1 unless you can find another place to stash such types.
> >
> > ModuleType -> imp.module
> > exception related types -> traceback module
> > Function, method and code types -> sys module
> > remaining stuff -> inspect

+1 for removing. I agree with Guido. Types should be with their associated
functionality and not in some arbitrary module.

I think the above example is good is good except for dumping all the
interpreter stuff into sys. sys is already clogged with tons of low-level,
interpreter specific functions. What we need is a new module: interpreter
(or something). I want to move all those functions like _getframe,
getrefcount, get/setrecursionlimit, etc from sys there. FrameType,
CodeType... will also fit nicely in there.

Also, I think the ListType, DictType, and SetType should go into
collections.

>
>
> Actually, inspect.types might be a good place to put them all.
>
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iQCVAwUBR/TJo3EjvBPtnXfVAQJDygQAmoXKq99jeRB5K6O4mVyPkErrbZCi2K72
> Kh4mKC65UmGv+GhhUQTlO96e87xKh1p29kS/ajILGDoBfj62WVJ/ZxkEivrSN9ge
> Gw6PmA6HbsP/UUArreLsIOcVDeLEw9Zwfb4m/aQqycJM206DfvLwAhLerLaBYaPm
> qzhOIG3hS7E=
> =qCy8
> -----END PGP SIGNATURE-----
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080403/1c3e06a0/attachment.htm 

From facundobatista at gmail.com  Thu Apr  3 16:14:40 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 3 Apr 2008 11:14:40 -0300
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
	<47F4C1FE.7050603@egenix.com>
	<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>
	<47F4C8BB.8000903@cheimes.de>
	<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>
Message-ID: <e04bdf310804030714l278150es1ddea491ed918cdd@mail.gmail.com>

2008/4/3, Barry Warsaw <barry at python.org>:

> > ModuleType -> imp.module
>  > exception related types -> traceback module
>  > Function, method and code types -> sys module
>  > remaining stuff -> inspect
>
>  Actually, inspect.types might be a good place to put them all.

-0 to have all types distributed in every module.

If you need those types to be there, the "type" module could be a
proxy to those, just to not repeat code.

But having them all in a single module is something explorable and
easy to document.

However, we could distribute them in a thousand modules, but we could
put in the Library Reference, in builtin types, the list of all, how
to use them, and from where import them...

Regards,

-- 
.    Facundo

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

From steven.bethard at gmail.com  Thu Apr  3 16:25:32 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Thu, 3 Apr 2008 08:25:32 -0600
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
	<47F4C1FE.7050603@egenix.com>
	<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>
	<47F4C8BB.8000903@cheimes.de>
	<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>
Message-ID: <d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>

Barry Warsaw schrieb:
> Plus, there are a few types in there that are difficult or impossible
> to get from Python.

On Thu, Apr 3, 2008 at 6:12 AM, Barry Warsaw <barry at python.org> wrote:
>  Actually, inspect.types might be a good place to put them all.

+1 on inspect.types. If you really need to check for things like
MethodType, instead of simply hasattr(obj, '__call__'), then you're
really doing inspect-style code whether you've admitted it to yourself
yet or not. ;-)

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
 --- Bucky Katt, Get Fuzzy

From jnoller at gmail.com  Thu Apr  3 16:32:24 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Thu, 3 Apr 2008 10:32:24 -0400
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
	<47F4C1FE.7050603@egenix.com>
	<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>
	<47F4C8BB.8000903@cheimes.de>
	<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>
	<d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>
Message-ID: <4222a8490804030732g43b76b93h5dca4cbee90d7798@mail.gmail.com>

On Thu, Apr 3, 2008 at 10:25 AM, Steven Bethard
<steven.bethard at gmail.com> wrote:
> Barry Warsaw schrieb:
>  > Plus, there are a few types in there that are difficult or impossible
>  > to get from Python.
>
>
> On Thu, Apr 3, 2008 at 6:12 AM, Barry Warsaw <barry at python.org> wrote:
>  >  Actually, inspect.types might be a good place to put them all.
>
>  +1 on inspect.types. If you really need to check for things like
>  MethodType, instead of simply hasattr(obj, '__call__'), then you're
>  really doing inspect-style code whether you've admitted it to yourself
>  yet or not. ;-)
>
>  Steve

+1 on inspect.types as well. It makes sense to put it there.

-jesse

From christian at cheimes.de  Thu Apr  3 16:38:22 2008
From: christian at cheimes.de (Christian Heimes)
Date: Thu, 03 Apr 2008 16:38:22 +0200
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <4222a8490804030732g43b76b93h5dca4cbee90d7798@mail.gmail.com>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>	
	<47F4C1FE.7050603@egenix.com>	
	<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>	
	<47F4C8BB.8000903@cheimes.de>	
	<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>	
	<d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>
	<4222a8490804030732g43b76b93h5dca4cbee90d7798@mail.gmail.com>
Message-ID: <47F4EBDE.9060501@cheimes.de>

Jesse Noller schrieb:
> On Thu, Apr 3, 2008 at 10:25 AM, Steven Bethard
> <steven.bethard at gmail.com> wrote:
>> Barry Warsaw schrieb:
>>  > Plus, there are a few types in there that are difficult or impossible
>>  > to get from Python.
>>
>>
>> On Thu, Apr 3, 2008 at 6:12 AM, Barry Warsaw <barry at python.org> wrote:
>>  >  Actually, inspect.types might be a good place to put them all.
>>
>>  +1 on inspect.types. If you really need to check for things like
>>  MethodType, instead of simply hasattr(obj, '__call__'), then you're
>>  really doing inspect-style code whether you've admitted it to yourself
>>  yet or not. ;-)
>>
>>  Steve
> 
> +1 on inspect.types as well. It makes sense to put it there.

For your information:

Guido doesn't like grab bag modules, see http://bugs.python.org/issue1605

Christian

From steven.bethard at gmail.com  Thu Apr  3 16:41:45 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Thu, 3 Apr 2008 08:41:45 -0600
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <47F4EBDE.9060501@cheimes.de>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
	<47F4C1FE.7050603@egenix.com>
	<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>
	<47F4C8BB.8000903@cheimes.de>
	<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>
	<d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>
	<4222a8490804030732g43b76b93h5dca4cbee90d7798@mail.gmail.com>
	<47F4EBDE.9060501@cheimes.de>
Message-ID: <d11dcfba0804030741v54d12e3bg34b15df4114cd3f6@mail.gmail.com>

On Thu, Apr 3, 2008 at 8:38 AM, Christian Heimes <christian at cheimes.de> wrote:
> Jesse Noller schrieb:
>
>
> > On Thu, Apr 3, 2008 at 10:25 AM, Steven Bethard
>  > <steven.bethard at gmail.com> wrote:
>  >> Barry Warsaw schrieb:
>  >>  > Plus, there are a few types in there that are difficult or impossible
>  >>  > to get from Python.
>  >>
>  >>
>  >> On Thu, Apr 3, 2008 at 6:12 AM, Barry Warsaw <barry at python.org> wrote:
>  >>  >  Actually, inspect.types might be a good place to put them all.
>  >>
>  >>  +1 on inspect.types. If you really need to check for things like
>  >>  MethodType, instead of simply hasattr(obj, '__call__'), then you're
>  >>  really doing inspect-style code whether you've admitted it to yourself
>  >>  yet or not. ;-)
>  >>
>  >>  Steve
>  >
>  > +1 on inspect.types as well. It makes sense to put it there.
>
>  For your information:
>
>  Guido doesn't like grab bag modules, see http://bugs.python.org/issue1605

This wouldn't be adding a grab bag module. It would be refusing to
remove an existing grab bag module.

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
 --- Bucky Katt, Get Fuzzy

From solipsis at pitrou.net  Thu Apr  3 16:43:04 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 03 Apr 2008 16:43:04 +0200
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
Message-ID: <1207233784.7848.1.camel@fsol>


Le jeudi 03 avril 2008 ? 13:24 +0200, Brett Cannon a ?crit :
> You can just call 'type' on something to get the type needed. And
> practically all of the types listed are easy to get from some object
> lying about that is of the proper type. Plus Guido supports its
> removal. =)

I don't see the point. It's not like using the types modules is
considered dangerous, or unsafe, or very bad practice. It's not like
there is a really better replacement, either. And I don't think
maintenance of the types module is a huge burden ;)




From mal at egenix.com  Thu Apr  3 17:09:45 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 03 Apr 2008 17:09:45 +0200
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <47F4EBDE.9060501@cheimes.de>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>		<47F4C1FE.7050603@egenix.com>		<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>		<47F4C8BB.8000903@cheimes.de>		<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>		<d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>	<4222a8490804030732g43b76b93h5dca4cbee90d7798@mail.gmail.com>
	<47F4EBDE.9060501@cheimes.de>
Message-ID: <47F4F339.9090605@egenix.com>

On 2008-04-03 16:38, Christian Heimes wrote:
> Jesse Noller schrieb:
>> On Thu, Apr 3, 2008 at 10:25 AM, Steven Bethard
>> <steven.bethard at gmail.com> wrote:
>>> Barry Warsaw schrieb:
>>>  > Plus, there are a few types in there that are difficult or impossible
>>>  > to get from Python.
>>>
>>>
>>> On Thu, Apr 3, 2008 at 6:12 AM, Barry Warsaw <barry at python.org> wrote:
>>>  >  Actually, inspect.types might be a good place to put them all.
>>>
>>>  +1 on inspect.types. If you really need to check for things like
>>>  MethodType, instead of simply hasattr(obj, '__call__'), then you're
>>>  really doing inspect-style code whether you've admitted it to yourself
>>>  yet or not. ;-)
>>>
>>>  Steve
>> +1 on inspect.types as well. It makes sense to put it there.
> 
> For your information:
> 
> Guido doesn't like grab bag modules, see http://bugs.python.org/issue1605

The idea to spread type objects across several different modules
is just not practical.

If you want to test for built-in types that are used by the interpreter,
then you want to look in *one central place* for the type object - not
in a gazillion different modules.

You're looking for the type object and don't want to worry about
whether this type object could be used in the context of a web
request, number crunching or counting beans.

E.g. where would you look for an Ellipsis type object, or a
memoryview, where does the iterator type object fit and what
about the traceback type object ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 03 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 jyasskin at gmail.com  Thu Apr  3 19:01:42 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Thu, 3 Apr 2008 10:01:42 -0700
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <47F4F339.9090605@egenix.com>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
	<47F4C1FE.7050603@egenix.com>
	<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>
	<47F4C8BB.8000903@cheimes.de>
	<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>
	<d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>
	<4222a8490804030732g43b76b93h5dca4cbee90d7798@mail.gmail.com>
	<47F4EBDE.9060501@cheimes.de> <47F4F339.9090605@egenix.com>
Message-ID: <5d44f72f0804031001r6a7b21f3x19137548fba10331@mail.gmail.com>

On Thu, Apr 3, 2008 at 8:09 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2008-04-03 16:38, Christian Heimes wrote:
>  > Jesse Noller schrieb:
>  >> On Thu, Apr 3, 2008 at 10:25 AM, Steven Bethard
>  >> <steven.bethard at gmail.com> wrote:
>  >>> Barry Warsaw schrieb:
>  >>>  > Plus, there are a few types in there that are difficult or impossible
>  >>>  > to get from Python.
>  >>>
>  >>>
>  >>> On Thu, Apr 3, 2008 at 6:12 AM, Barry Warsaw <barry at python.org> wrote:
>  >>>  >  Actually, inspect.types might be a good place to put them all.
>  >>>
>  >>>  +1 on inspect.types. If you really need to check for things like
>  >>>  MethodType, instead of simply hasattr(obj, '__call__'), then you're
>  >>>  really doing inspect-style code whether you've admitted it to yourself
>  >>>  yet or not. ;-)
>  >>>
>  >>>  Steve
>  >> +1 on inspect.types as well. It makes sense to put it there.
>  >
>  > For your information:
>  >
>  > Guido doesn't like grab bag modules, see http://bugs.python.org/issue1605
>
>  The idea to spread type objects across several different modules
>  is just not practical.
>
>  If you want to test for built-in types that are used by the interpreter,
>  then you want to look in *one central place* for the type object - not
>  in a gazillion different modules.
>
>  You're looking for the type object and don't want to worry about
>  whether this type object could be used in the context of a web
>  request, number crunching or counting beans.
>
>  E.g. where would you look for an Ellipsis type object, or a

Just to pick one, try "type(...)". It's generally clearer to take an
example of what you want and ask for its type, than to look in the
types module.

>  memoryview, where does the iterator type object fit and what
>  about the traceback type object ?
>
>
>  --
>  Marc-Andre Lemburg
>  eGenix.com
>
>  Professional Python Services directly from the Source  (#1, Apr 03 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
>  _______________________________________________
>
>
> stdlib-sig mailing list
>  stdlib-sig at python.org
>  http://mail.python.org/mailman/listinfo/stdlib-sig
>



-- 
Namast?,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

From facundobatista at gmail.com  Thu Apr  3 19:14:54 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 3 Apr 2008 14:14:54 -0300
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <5d44f72f0804031001r6a7b21f3x19137548fba10331@mail.gmail.com>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
	<47F4C1FE.7050603@egenix.com>
	<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>
	<47F4C8BB.8000903@cheimes.de>
	<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>
	<d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>
	<4222a8490804030732g43b76b93h5dca4cbee90d7798@mail.gmail.com>
	<47F4EBDE.9060501@cheimes.de> <47F4F339.9090605@egenix.com>
	<5d44f72f0804031001r6a7b21f3x19137548fba10331@mail.gmail.com>
Message-ID: <e04bdf310804031014uf6b9c5evab9b616032b50eef@mail.gmail.com>

2008/4/3, Jeffrey Yasskin <jyasskin at gmail.com>:

> Just to pick one, try "type(...)". It's generally clearer to take an
>  example of what you want and ask for its type, than to look in the
>  types module.

How?

For example, I have this very complex class:

>>> class C:
...     def met(self):
...             pass
...
>>> c = C()


I want, from outside to create a new method in it. So, I do the following:

>>> t = type(c.met)
>>> t()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: method expected 2 arguments, got 0


Ouch, it wasn't so easy. I realize myself I need to read the docs.
Where should I look for those docs and/or examples?

Regards,

-- 
.    Facundo

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

From barry at python.org  Thu Apr  3 19:22:05 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 3 Apr 2008 13:22:05 -0400
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <47F4F339.9090605@egenix.com>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>		<47F4C1FE.7050603@egenix.com>		<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>		<47F4C8BB.8000903@cheimes.de>		<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>		<d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>	<4222a8490804030732g43b76b93h5dca4cbee90d7798@mail.gmail.com>
	<47F4EBDE.9060501@cheimes.de> <47F4F339.9090605@egenix.com>
Message-ID: <78C3240B-26F7-453C-90EA-77E362A07CA4@python.org>

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

On Apr 3, 2008, at 11:09 AM, M.-A. Lemburg wrote:
>
> The idea to spread type objects across several different modules
> is just not practical.
>
> If you want to test for built-in types that are used by the  
> interpreter,
> then you want to look in *one central place* for the type object - not
> in a gazillion different modules.

Exactly right.

- -Barry

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

iQCVAwUBR/USQHEjvBPtnXfVAQJoyQQAmxV0r6LnU+dpn6nLzrOaepE+dnUPsk9E
rqsh9LZnOt1/0mLr3lFSvBPurfMyzC9gKniTUuuviOJtlUuZsFNYteu63F55vRx2
HCqeF7cZUI9my03RlRKxEuJtgW0ueYHAURQxcAkFya69tCIgOqJIUNAxDaqGaPiN
7oGcN2ovri0=
=XemO
-----END PGP SIGNATURE-----

From steven.bethard at gmail.com  Thu Apr  3 19:46:30 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Thu, 3 Apr 2008 11:46:30 -0600
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
Message-ID: <d11dcfba0804031046v292c7f76o93a11188215eaee3@mail.gmail.com>

On Thu, Apr 3, 2008 at 5:24 AM, Brett Cannon <brett at python.org> wrote:
> You can just call 'type' on something to get the type needed. And
>  practically all of the types listed are easy to get from some object
>  lying about that is of the proper type. Plus Guido supports its
>  removal. =)

It would be really helpful to see the patch that removes use of the
types module from the standard library. I counted over 100 imports of
the types module in the 2.6 standard library. Some of the fixes are
obvious, like::

    if type(etype) is types.ClassType

which in 3.0 should obviously be::

    if isinstance(etype, type)

But other ones are not as obvious to me::

    bdb.py:        if not isinstance(cmd, types.CodeType):
    bdb.py:        if not isinstance(expr, types.CodeType):
    copy.py:    d[types.CodeType] = _deepcopy_atomic
    idlelib/rpc.py:copy_reg.pickle(types.CodeType, pickle_code, unpickle_code)
    inspect.py:    return isinstance(object, types.CodeType)
    trace.py:        if isinstance(c, types.CodeType):

If someone could actually do the conversion, and show the new way to
write these things, I'd feel much more confident on removing the
module.

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
 --- Bucky Katt, Get Fuzzy

From musiccomposition at gmail.com  Thu Apr  3 20:07:12 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Thu, 3 Apr 2008 13:07:12 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
Message-ID: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>

I originally brought this in the discussion about removing types, but it can
be separate.

Through the years, sys has gather a fare share of crud. Much of these new
additions are low-level and CPython specific. I believe the sys module
should strive to be an interpreter neutral, clean module. Hence, I propose
the "interpreter" module. We could move all those internal functions like
_getframe(), get/setrecursionlimit(), get/setcheckinterval(), etc to it.
Also, if we decided to remove the types module, this would be a natural
place for frames and code objects.

I look forward to your comments.

-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080403/429ba6a4/attachment.htm 

From christian at cheimes.de  Fri Apr  4 11:23:34 2008
From: christian at cheimes.de (Christian Heimes)
Date: Fri, 04 Apr 2008 11:23:34 +0200
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <78C3240B-26F7-453C-90EA-77E362A07CA4@python.org>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>		<47F4C1FE.7050603@egenix.com>		<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>		<47F4C8BB.8000903@cheimes.de>		<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>		<d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>	<4222a8490804030732g43b76b93h5dca4cbee90d7798@mail.gmail.com>
	<47F4EBDE.9060501@cheimes.de> <47F4F339.9090605@egenix.com>
	<78C3240B-26F7-453C-90EA-77E362A07CA4@python.org>
Message-ID: <47F5F396.2000207@cheimes.de>

Barry Warsaw schrieb:
> On Apr 3, 2008, at 11:09 AM, M.-A. Lemburg wrote:
> 
>> The idea to spread type objects across several different modules
>> is just not practical.
> 
>> If you want to test for built-in types that are used by the interpreter,
>> then you want to look in *one central place* for the type object - not
>> in a gazillion different modules.
> 
> Exactly right.

Which is exactly what my patch http://bugs.python.org/issue1605
implements, isn't it? And what was rejected by Guido.

Christian

From christian at cheimes.de  Fri Apr  4 11:27:15 2008
From: christian at cheimes.de (Christian Heimes)
Date: Fri, 04 Apr 2008 11:27:15 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
Message-ID: <47F5F473.5050406@cheimes.de>

Benjamin Peterson schrieb:
> I originally brought this in the discussion about removing types, but it can
> be separate.
> 
> Through the years, sys has gather a fare share of crud. Much of these new
> additions are low-level and CPython specific. I believe the sys module
> should strive to be an interpreter neutral, clean module. Hence, I propose
> the "interpreter" module. We could move all those internal functions like
> _getframe(), get/setrecursionlimit(), get/setcheckinterval(), etc to it.
> Also, if we decided to remove the types module, this would be a natural
> place for frames and code objects.

The idea popped up several months ago when we were discussion the future
of the types module. Guido suggested the name 'pyvm'. The module was
meant to contain low level interfaces to the (C)Python virtual machine.

Once the pyvm module is implemented the sys module should only contain
system methods which can be implemented by all flavors of Python.

Christian

From christian at cheimes.de  Fri Apr  4 11:32:49 2008
From: christian at cheimes.de (Christian Heimes)
Date: Fri, 04 Apr 2008 11:32:49 +0200
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <1207233784.7848.1.camel@fsol>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
	<1207233784.7848.1.camel@fsol>
Message-ID: <47F5F5C1.4010402@cheimes.de>

Antoine Pitrou schrieb:
> Le jeudi 03 avril 2008 ? 13:24 +0200, Brett Cannon a ?crit :
>> You can just call 'type' on something to get the type needed. And
>> practically all of the types listed are easy to get from some object
>> lying about that is of the proper type. Plus Guido supports its
>> removal. =)
> 
> I don't see the point. It's not like using the types modules is
> considered dangerous, or unsafe, or very bad practice. It's not like
> there is a really better replacement, either. And I don't think
> maintenance of the types module is a huge burden ;)

It's considered bad practice since isinstance(egg, list) works. It's
still in use because several types aren't directly available via import,
e.g. CodeType.

Christian

From christian at cheimes.de  Fri Apr  4 11:33:24 2008
From: christian at cheimes.de (Christian Heimes)
Date: Fri, 04 Apr 2008 11:33:24 +0200
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <1afaf6160804030549k2dacacs6704383bc3c733c2@mail.gmail.com>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>	
	<47F4C1FE.7050603@egenix.com>	
	<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>	
	<47F4C8BB.8000903@cheimes.de>	
	<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>
	<1afaf6160804030549k2dacacs6704383bc3c733c2@mail.gmail.com>
Message-ID: <47F5F5E4.3060207@cheimes.de>

Benjamin Peterson schrieb:
> Also, I think the ListType, DictType, and SetType should go into
> collections.

Types that are not available as builtins are available through the
collection module. Check out Lib/_abcoll.py. I've added the types a
while ago. For ListType, DictType etc. I'm -1. ListType is list.

### collection related types which are not exposed through builtin ###
## iterators ##
bytes_iterator = type(iter(b''))
bytearray_iterator = type(iter(bytearray()))
#callable_iterator = ???
dict_keyiterator = type(iter({}.keys()))
dict_valueiterator = type(iter({}.values()))
dict_itemiterator = type(iter({}.items()))
list_iterator = type(iter([]))
list_reverseiterator = type(iter(reversed([])))
range_iterator = type(iter(range(0)))
set_iterator = type(iter(set()))
str_iterator = type(iter(""))
tuple_iterator = type(iter(()))
zip_iterator = type(iter(zip()))
## views ##
dict_keys = type({}.keys())
dict_values = type({}.values())
dict_items = type({}.items())
## misc ##
dict_proxy = type(type.__dict__)

From mal at egenix.com  Fri Apr  4 12:00:08 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 04 Apr 2008 12:00:08 +0200
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <47F5F396.2000207@cheimes.de>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>		<47F4C1FE.7050603@egenix.com>		<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>		<47F4C8BB.8000903@cheimes.de>		<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>		<d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>	<4222a8490804030732g43b76b93h5dca4cbee90d7798@mail.gmail.com>	<47F4EBDE.9060501@cheimes.de>
	<47F4F339.9090605@egenix.com>	<78C3240B-26F7-453C-90EA-77E362A07CA4@python.org>
	<47F5F396.2000207@cheimes.de>
Message-ID: <47F5FC28.4010003@egenix.com>

On 2008-04-04 11:23, Christian Heimes wrote:
> Barry Warsaw schrieb:
>> On Apr 3, 2008, at 11:09 AM, M.-A. Lemburg wrote:
>>
>>> The idea to spread type objects across several different modules
>>> is just not practical.
>>> If you want to test for built-in types that are used by the interpreter,
>>> then you want to look in *one central place* for the type object - not
>>> in a gazillion different modules.
>> Exactly right.
> 
> Which is exactly what my patch http://bugs.python.org/issue1605
> implements, isn't it? And what was rejected by Guido.

He gave his -1, we have Barry's, your and my +1 ... that's a net
+2 so far.

His argument that "they should be each be exposed in a a module
(new or existing) that defines other objects (types, functions,
constants, what have you) with a related purpose." results in
the problems I mentioned earlier.

The "related purpose" part is a very fuzzy term and it's not at all
clear where to look for type objects for things that can be used
in multiple contexts.

Also note that the reason for putting the type objects all in one
module is not to "lump them all together", but instead to make the
type object lookup process intuitive and straight forward for
the programmer.

As an example from real life: if you're looking for an apple,
you'd normally go to the local market or supermarket, instead
of trying to find an apple tree where you could pick one.

As compromise, perhaps we should just expose the type objects in
multiple places, ie. in the types module and add aliases to whatever
other modules they seem to fit.

-- 
Marc-Andre Lemburg
eGenix.com

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

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


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

From solipsis at pitrou.net  Fri Apr  4 12:09:41 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 04 Apr 2008 12:09:41 +0200
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <47F5F5C1.4010402@cheimes.de>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
	<1207233784.7848.1.camel@fsol>  <47F5F5C1.4010402@cheimes.de>
Message-ID: <1207303781.7759.2.camel@fsol>


Le vendredi 04 avril 2008 ? 11:32 +0200, Christian Heimes a ?crit :
> It's considered bad practice since isinstance(egg, list) works.

That's because the "list" builtin exists. The types module is useful for
all those types that don't have a builtin name - and will probably never
have - : modules, methods, etc.

cheers

Antoine.



From brett at python.org  Fri Apr  4 12:44:48 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 4 Apr 2008 12:44:48 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <47F5F473.5050406@cheimes.de>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<47F5F473.5050406@cheimes.de>
Message-ID: <bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>

On Fri, Apr 4, 2008 at 11:27 AM, Christian Heimes <christian at cheimes.de> wrote:
> Benjamin Peterson schrieb:
>
> > I originally brought this in the discussion about removing types, but it can
>  > be separate.
>  >
>  > Through the years, sys has gather a fare share of crud. Much of these new
>  > additions are low-level and CPython specific. I believe the sys module
>  > should strive to be an interpreter neutral, clean module. Hence, I propose
>  > the "interpreter" module. We could move all those internal functions like
>  > _getframe(), get/setrecursionlimit(), get/setcheckinterval(), etc to it.
>  > Also, if we decided to remove the types module, this would be a natural
>  > place for frames and code objects.
>
>  The idea popped up several months ago when we were discussion the future
>  of the types module. Guido suggested the name 'pyvm'. The module was
>  meant to contain low level interfaces to the (C)Python virtual machine.
>
>  Once the pyvm module is implemented the sys module should only contain
>  system methods which can be implemented by all flavors of Python.

This is exactly the type of separation I want to see. Unfortunately,
because it would be a new module that means we will have to go through
the typical steps needed to add it and can't rely on 2to3 and the
reorg to handle it.

But I totally support moving CPython-specific stuff to another module.
Probably the best thing to do is write up a proposal of what should go
where, run it past here, and the write up a PEP to present to
python-dev. Then we can introduce the module in 2.6/3.0. Proper
deprecations will be needed in the sys module so that people can
slowly transition to the new module (whether it is named interpreter,
pyvm, or some other name) since the sys module can't obviously just
suddenly drop some methods or attributes.

And do realize this is a chance to change the API so that if a
property-like situation is better than a method call that can be used.

Sound good to people? If so, who wants to take this on?

-Brett

From barry at python.org  Fri Apr  4 13:53:31 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 4 Apr 2008 07:53:31 -0400
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <47F5F396.2000207@cheimes.de>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>		<47F4C1FE.7050603@egenix.com>		<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>		<47F4C8BB.8000903@cheimes.de>		<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>		<d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>	<4222a8490804030732g43b76b93h5dca4cbee90d7798@mail.gmail.com>
	<47F4EBDE.9060501@cheimes.de> <47F4F339.9090605@egenix.com>
	<78C3240B-26F7-453C-90EA-77E362A07CA4@python.org>
	<47F5F396.2000207@cheimes.de>
Message-ID: <1BB4B479-D14B-4573-96EE-080EDC4426FD@python.org>

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

On Apr 4, 2008, at 5:23 AM, Christian Heimes wrote:
> Barry Warsaw schrieb:
>> On Apr 3, 2008, at 11:09 AM, M.-A. Lemburg wrote:
>>
>>> The idea to spread type objects across several different modules
>>> is just not practical.
>>
>>> If you want to test for built-in types that are used by the  
>>> interpreter,
>>> then you want to look in *one central place* for the type object -  
>>> not
>>> in a gazillion different modules.
>>
>> Exactly right.
>
> Which is exactly what my patch http://bugs.python.org/issue1605
> implements, isn't it? And what was rejected by Guido.

Oh well.

BTW, I happen to agree in part with Guido's decision in the bug  
commentary, specifically that abc's not be all grouped together.  But  
I don't agree that the same logic implies that types should be strewn  
throughout the stdlib.  Types and abcs will  be used in completely  
different ways, and it's all about discoverability.

Guido says he's "100% against" this, so I guess another solution has  
to be found.

- -Barry

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

iQCVAwUBR/YWu3EjvBPtnXfVAQKrqgP/ex8IvWscF8pgYV/nqeaCWFGuhsfZFpO7
swivsR6rGIQg6n0tZDyvxtt61YPbURSVL1lbO/rehmeKYPLxNZ3ubEU0ZMpv7pJK
blYBmFgJ/MpPs1aQwZ4iGpydWTG0uGn+7N84if4d6UhspZ9FAfhv/O+oO5s8LWLw
SZv5ZIWqhxw=
=O+hj
-----END PGP SIGNATURE-----

From musiccomposition at gmail.com  Fri Apr  4 15:29:42 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 4 Apr 2008 08:29:42 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<47F5F473.5050406@cheimes.de>
	<bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
Message-ID: <1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>

On Fri, Apr 4, 2008 at 5:44 AM, Brett Cannon <brett at python.org> wrote:

> On Fri, Apr 4, 2008 at 11:27 AM, Christian Heimes <christian at cheimes.de>
> wrote:
> > Benjamin Peterson schrieb:
> >
> > > I originally brought this in the discussion about removing types, but
> it can
> >  > be separate.
> >  >
> >  > Through the years, sys has gather a fare share of crud. Much of these
> new
> >  > additions are low-level and CPython specific. I believe the sys
> module
> >  > should strive to be an interpreter neutral, clean module. Hence, I
> propose
> >  > the "interpreter" module. We could move all those internal functions
> like
> >  > _getframe(), get/setrecursionlimit(), get/setcheckinterval(), etc to
> it.
> >  > Also, if we decided to remove the types module, this would be a
> natural
> >  > place for frames and code objects.
> >
> >  The idea popped up several months ago when we were discussion the
> future
> >  of the types module. Guido suggested the name 'pyvm'. The module was
> >  meant to contain low level interfaces to the (C)Python virtual machine.
> >
> >  Once the pyvm module is implemented the sys module should only contain
> >  system methods which can be implemented by all flavors of Python.
>
> This is exactly the type of separation I want to see. Unfortunately,
> because it would be a new module that means we will have to go through
> the typical steps needed to add it and can't rely on 2to3 and the
> reorg to handle it.
>
> But I totally support moving CPython-specific stuff to another module.
> Probably the best thing to do is write up a proposal of what should go
> where, run it past here, and the write up a PEP to present to
> python-dev. Then we can introduce the module in 2.6/3.0. Proper
> deprecations will be needed in the sys module so that people can
> slowly transition to the new module (whether it is named interpreter,
> pyvm, or some other name) since the sys module can't obviously just
> suddenly drop some methods or attributes.
>
> And do realize this is a chance to change the API so that if a
> property-like situation is better than a method call that can be used.
>
> Sound good to people? If so, who wants to take this on?

If there is further support, I will.

>
>
> -Brett
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080404/7d4994be/attachment.htm 

From christian at cheimes.de  Fri Apr  4 15:37:29 2008
From: christian at cheimes.de (Christian Heimes)
Date: Fri, 04 Apr 2008 15:37:29 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>	
	<47F5F473.5050406@cheimes.de>
	<bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
Message-ID: <47F62F19.6070504@cheimes.de>

Brett Cannon schrieb:
> And do realize this is a chance to change the API so that if a
> property-like situation is better than a method call that can be used.

Python doesn't support module properties :/

> Sound good to people? If so, who wants to take this on?

I can help with the C coding but I won't have time to champion and
implement everything on my own.

Christian

From steven.bethard at gmail.com  Fri Apr  4 17:01:23 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Fri, 4 Apr 2008 09:01:23 -0600
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<47F5F473.5050406@cheimes.de>
	<bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
Message-ID: <d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>

On Fri, Apr 4, 2008 at 11:27 AM, Christian Heimes <christian at cheimes.de> wrote:
>  Once the pyvm module is implemented the sys module should only contain
>  system methods which can be implemented by all flavors of Python.

On Fri, Apr 4, 2008 at 5:44 AM, Brett Cannon <brett at python.org> wrote:
> This is exactly the type of separation I want to see.
[snip]
> Sound good to people? If so, who wants to take this on?

2008/4/4 Benjamin Peterson <musiccomposition at gmail.com>:
> If there is further support, I will.

I don't know how much more further support you need, but I'm 100%
behind the idea. If you need any more help, let me know.

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

From musiccomposition at gmail.com  Fri Apr  4 17:27:20 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 4 Apr 2008 10:27:20 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<47F5F473.5050406@cheimes.de>
	<bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
Message-ID: <1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>

On Fri, Apr 4, 2008 at 10:01 AM, Steven Bethard <steven.bethard at gmail.com>
wrote:

> On Fri, Apr 4, 2008 at 11:27 AM, Christian Heimes <christian at cheimes.de>
> wrote:
> >  Once the pyvm module is implemented the sys module should only contain
> >  system methods which can be implemented by all flavors of Python.
>
> On Fri, Apr 4, 2008 at 5:44 AM, Brett Cannon <brett at python.org> wrote:
> > This is exactly the type of separation I want to see.
> [snip]
> > Sound good to people? If so, who wants to take this on?
>
> 2008/4/4 Benjamin Peterson <musiccomposition at gmail.com>:
> > If there is further support, I will.
>
> I don't know how much more further support you need, but I'm 100%
> behind the idea. If you need any more help, let me know.

I'm starting the PEP now...

>
>
> Steve
> --
> I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
> tiny blip on the distant coast of sanity.
>        --- Bucky Katt, Get Fuzzy
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080404/b568022f/attachment.htm 

From jyasskin at gmail.com  Fri Apr  4 18:16:28 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Fri, 4 Apr 2008 09:16:28 -0700
Subject: [stdlib-sig] proposed removal: the types module
In-Reply-To: <e04bdf310804031014uf6b9c5evab9b616032b50eef@mail.gmail.com>
References: <bbaeab100804030424hcdc47educ428ec8a6d733ecc@mail.gmail.com>
	<B84B5133-6075-4E3A-84A4-FCF1F8415709@python.org>
	<47F4C8BB.8000903@cheimes.de>
	<6497808A-6294-48B6-8D0C-91BB64E38C5C@python.org>
	<d11dcfba0804030725k50ee1dc2g69b48ed37975e30a@mail.gmail.com>
	<4222a8490804030732g43b76b93h5dca4cbee90d7798@mail.gmail.com>
	<47F4EBDE.9060501@cheimes.de> <47F4F339.9090605@egenix.com>
	<5d44f72f0804031001r6a7b21f3x19137548fba10331@mail.gmail.com>
	<e04bdf310804031014uf6b9c5evab9b616032b50eef@mail.gmail.com>
Message-ID: <5d44f72f0804040916x79118277mf9507ee82deda9ef@mail.gmail.com>

On Thu, Apr 3, 2008 at 10:14 AM, Facundo Batista
<facundobatista at gmail.com> wrote:
> 2008/4/3, Jeffrey Yasskin <jyasskin at gmail.com>:
>
>
>  > Just to pick one, try "type(...)". It's generally clearer to take an
>  >  example of what you want and ask for its type, than to look in the
>  >  types module.
>
>  How?
>
>  For example, I have this very complex class:
>
>  >>> class C:
>  ...     def met(self):
>  ...             pass
>  ...
>  >>> c = C()
>
>
>  I want, from outside to create a new method in it. So, I do the following:
>
>  >>> t = type(c.met)
>  >>> t()
>  Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>  TypeError: method expected 2 arguments, got 0
>
>
>  Ouch, it wasn't so easy. I realize myself I need to read the docs.
>  Where should I look for those docs and/or examples?

If you're just looking for a place to stash the documentation,
http://docs.python.org/dev/3.0/library/stdtypes.html#other-built-in-types
looks appropriate.

But looking at Steven's question made me change my mind. It's true
that types.CodeType can be replaced by
type(any_user_defined_function.__code__), but it makes me nervous to
assume that all code objects will always be exactly the same type.
Having a name in a standard place seems more reliable.

-- 
Namast?,
Jeffrey Yasskin

From musiccomposition at gmail.com  Fri Apr  4 18:51:28 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Fri, 4 Apr 2008 11:51:28 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<47F5F473.5050406@cheimes.de>
	<bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
Message-ID: <1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>

On Fri, Apr 4, 2008 at 10:27 AM, Benjamin Peterson <
musiccomposition at gmail.com> wrote:

>
>
> On Fri, Apr 4, 2008 at 10:01 AM, Steven Bethard <steven.bethard at gmail.com>
> wrote:
>
> > On Fri, Apr 4, 2008 at 11:27 AM, Christian Heimes <christian at cheimes.de>
> > wrote:
> > >  Once the pyvm module is implemented the sys module should only
> > contain
> > >  system methods which can be implemented by all flavors of Python.
> >
> > On Fri, Apr 4, 2008 at 5:44 AM, Brett Cannon <brett at python.org> wrote:
> > > This is exactly the type of separation I want to see.
> > [snip]
> > > Sound good to people? If so, who wants to take this on?
> >
> > 2008/4/4 Benjamin Peterson <musiccomposition at gmail.com>:
> > > If there is further support, I will.
> >
> > I don't know how much more further support you need, but I'm 100%
> > behind the idea. If you need any more help, let me know.
>
> I'm starting the PEP now...
>
And here it is: This is my first PEP, so do be brutal with your feedback.

PEP: XXX
Title: The interpreter module
Version: $Revision$
Last-Modified: $Date$
Author: Benjamin Peterson
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 4-April-2008
Python-Version: 3.0


Abstract
========

This PEP proposes a new low-level module for CPython-specific interpreter
functions in order to clean out the sys module and separate general Python
functionality from implementation details.


Rationale
=========

The sys module currently contains functions and data that can be put into
two
major groups:

1. Data and functions that are available in all Python implementations and
deal
   with the general running of a Python VM.

   - display_hook, stdout, stdin, and stderr
   - flags and warn_options
   - settrace, and setprofile
   - traceback, excepthook
   - etc...


2. Data and function that affect the CPython interpreter.

   - get/setrecursionlimit
   - get/setcheckinterval
   - _getframe and _current_frame
   - getrefcount
   - getdlopenflags

The second collections of items has been steadily increasing over the years
causing clutter in sys.  Guido has even said he doesn't recognize some of
things
in it [#bug-1522]_!

Other implementations have clearly struggled with what to do about the
contents
of sys they can't implement but must to retain compatibility.  For example,
Jython's sys module has dud set/getrecursionlimit functions.  Moving these
items
items off to another module would send a clear message about what functions
need
and need not be implemented.

It has also been proposed that the contents of types module be distributed
across the standard library [#types-removal]_; the interpreter module would
provide an excellent resting place for internal types like frames and code
objects.

Specification
=============

A new builtin module named "interpreter" (see `Naming`_) will be added.  The
functions mentioned in the above list will be moved to it.


Transition Plan
===============

Once implemented in 3.x, the interpreter module will be back-ported to 2.6.
Py3k warnings will be added the the sys functions it replaces.


Open Issues
===========

Naming
------

The author proposes the name "interpreter" for the new module.  "pyvm" has
also
been suggested [#pyvm-name]_.


References
==========

.. [#bug-1522]

   http://bugs.python.org/issue1522

.. [#types-removal]

   http://mail.python.org/pipermail/stdlib-sig/2008-April/000172.html

.. [#pyvm-name]

   http://mail.python.org/pipermail/python-3000/2007-November/011351.html

Copyright
=========

    This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End:


>
>
> >
> > Steve
> > --
> > I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
> > tiny blip on the distant coast of sanity.
> >        --- Bucky Katt, Get Fuzzy
> >
>
>
>
> --
> Cheers,
> Benjamin Peterson




-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080404/7965f3eb/attachment.htm 

From p.f.moore at gmail.com  Fri Apr  4 20:35:52 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 4 Apr 2008 19:35:52 +0100
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<47F5F473.5050406@cheimes.de>
	<bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
Message-ID: <79990c6b0804041135m436a6bf6t70b52fb3c5ebf246@mail.gmail.com>

On 04/04/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:

> And here it is: This is my first PEP, so do be brutal with your feedback.

Looks reasonably good - I can't think of anything particularly brutal.
You should, however, be explicit about precisely where you propose
each entry in sys should go. Saying "etc..." is cheating :-)

Once you list everything, I expect you'll get a much more, shall we
say, "lively" discussion!

But I've no problem with the PEP in principle.

Paul.

From steven.bethard at gmail.com  Fri Apr  4 23:09:48 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Fri, 4 Apr 2008 15:09:48 -0600
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<47F5F473.5050406@cheimes.de>
	<bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
Message-ID: <d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>

On Fri, Apr 4, 2008 at 10:51 AM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
>  PEP: XXX
> Title: The interpreter module
> Version: $Revision$
> Last-Modified: $Date$
> Author: Benjamin Peterson
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 4-April-2008
> Python-Version: 3.0
>
>
> Abstract
> ========
>
> This PEP proposes a new low-level module for CPython-specific interpreter
> functions in order to clean out the sys module and separate general Python
> functionality from implementation details.
>
>
> Rationale
> =========
>
> The sys module currently contains functions and data that can be put into
> two
> major groups:
>
> 1. Data and functions that are available in all Python implementations and
> deal
>     with the general running of a Python VM.
>
>    - display_hook, stdout, stdin, and stderr
>    - flags and warn_options
>    - settrace, and setprofile
>    - traceback, excepthook
>    - etc...
>
>
> 2. Data and function that affect the CPython interpreter.
>
>    - get/setrecursionlimit
>    - get/setcheckinterval
>    - _getframe and _current_frame
>    - getrefcount
>    - getdlopenflags

Why getdlopenflags? That seems general to any Python implementation
that opens dlls (though I believe the dl module is going away in
Python 3, so it may not matter).

Also, maybe settscdump should be moved as well? Its description says
to look at "Python/ceval.c"

Otherwise, it looks pretty good to me.

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
 --- Bucky Katt, Get Fuzzy

From musiccomposition at gmail.com  Sat Apr  5 16:12:10 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 5 Apr 2008 09:12:10 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <79990c6b0804041135m436a6bf6t70b52fb3c5ebf246@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<47F5F473.5050406@cheimes.de>
	<bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
	<79990c6b0804041135m436a6bf6t70b52fb3c5ebf246@mail.gmail.com>
Message-ID: <1afaf6160804050712o13929ea7tdcf845a165924a59@mail.gmail.com>

On Fri, Apr 4, 2008 at 1:35 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 04/04/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
>
> > And here it is: This is my first PEP, so do be brutal with your
> feedback.
>
> Looks reasonably good - I can't think of anything particularly brutal.
> You should, however, be explicit about precisely where you propose
> each entry in sys should go. Saying "etc..." is cheating :-)

I meant everything which wasn't in the second list won't be moved. EIBTI,
though!

>
>
> Once you list everything, I expect you'll get a much more, shall we
> say, "lively" discussion!
>
> But I've no problem with the PEP in principle.
>
> Paul.
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080405/775a8fc5/attachment.htm 

From musiccomposition at gmail.com  Sat Apr  5 16:18:19 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 5 Apr 2008 09:18:19 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<47F5F473.5050406@cheimes.de>
	<bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
	<d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>
Message-ID: <1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>

On Fri, Apr 4, 2008 at 4:09 PM, Steven Bethard <steven.bethard at gmail.com>
wrote:

> On Fri, Apr 4, 2008 at 10:51 AM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
> >  PEP: XXX
> > Title: The interpreter module
> > Version: $Revision$
> > Last-Modified: $Date$
> > Author: Benjamin Peterson
> > Status: Draft
> > Type: Standards Track
> > Content-Type: text/x-rst
> > Created: 4-April-2008
> > Python-Version: 3.0
> >
> >
> > Abstract
> > ========
> >
> > This PEP proposes a new low-level module for CPython-specific
> interpreter
> > functions in order to clean out the sys module and separate general
> Python
> > functionality from implementation details.
> >
> >
> > Rationale
> > =========
> >
> > The sys module currently contains functions and data that can be put
> into
> > two
> > major groups:
> >
> > 1. Data and functions that are available in all Python implementations
> and
> > deal
> >     with the general running of a Python VM.
> >
> >    - display_hook, stdout, stdin, and stderr
> >    - flags and warn_options
> >    - settrace, and setprofile
> >    - traceback, excepthook
> >    - etc...
> >
> >
> > 2. Data and function that affect the CPython interpreter.
> >
> >    - get/setrecursionlimit
> >    - get/setcheckinterval
> >    - _getframe and _current_frame
> >    - getrefcount
> >    - getdlopenflags
>
> Why getdlopenflags? That seems general to any Python implementation
> that opens dlls (though I believe the dl module is going away in
> Python 3, so it may not matter).

I don't think any other implementations do open dynamic libs. Those flags
don't affect the dl module; they define how Python opens C shared libs.

>
>
> Also, maybe settscdump should be moved as well? Its description says
> to look at "Python/ceval.c"
>
Yes.

>
>
> Otherwise, it looks pretty good to me.
>
> Steve
> --
> I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
> tiny blip on the distant coast of sanity.
>  --- Bucky Katt, Get Fuzzy
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080405/b58b08d2/attachment.htm 

From musiccomposition at gmail.com  Sat Apr  5 16:58:04 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 5 Apr 2008 09:58:04 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<47F5F473.5050406@cheimes.de>
	<bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
	<d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>
	<1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>
Message-ID: <1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>

Here's an updated version:

   - display_hook, stdout, stdin, and stderr
   - flags and warn_options
   - settrace, and setprofile
   - traceback, excepthook
   - etc...


2. Data and functions that affect the CPython interpreter.

   - get/setrecursionlimit
   - get/setcheckinterval
   - _getframe and _current_frame
   - getrefcount
   - get/setdlopenflags
   - settscdumps
   - api_version
   - winver
   - dllhandle
   - float_info

The second collections of items has been steadily increasing over the years
causing clutter in sys.  Guido has even said he doesn't recognize some of
things
in it [#bug-1522]_!

Other implementations have clearly struggled with what to do about the
contents
of sys they can't implement but must to retain compatibility.  For example,
Jython's sys module has dud set/getrecursionlimit functions.  Moving these
items
items off to another module would send a clear message about what functions
need
and need not be implemented.

It has also been proposed that the contents of types module be distributed
across the standard library [#types-removal]_; the interpreter module would
provide an excellent resting place for internal types like frames and code
objects.

Specification
=============

A new builtin module named "interpreter" (see `Naming`_) will be added.  The
functions mentioned in the second list above will be moved to it.


Transition Plan
===============

Once implemented in 3.x, the interpreter module will be back-ported to 2.6.
Py3k warnings will be added the the sys functions it replaces.


Open Issues
===========

Naming
------

The author proposes the name "interpreter" for the new module.  "pyvm" has
also
been suggested [#pyvm-name]_.


References
==========

.. [#bug-1522]

   http://bugs.python.org/issue1522

.. [#types-removal]

   http://mail.python.org/pipermail/stdlib-sig/2008-April/000172.html

.. [#pyvm-name]

   http://mail.python.org/pipermail/python-3000/2007-November/011351.html

Copyright
=========

    This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End:


On Sat, Apr 5, 2008 at 9:18 AM, Benjamin Peterson <
musiccomposition at gmail.com> wrote:

>
>
> On Fri, Apr 4, 2008 at 4:09 PM, Steven Bethard <steven.bethard at gmail.com>
> wrote:
>
> > On Fri, Apr 4, 2008 at 10:51 AM, Benjamin Peterson
> > <musiccomposition at gmail.com> wrote:
> > >  PEP: XXX
> > > Title: The interpreter module
> > > Version: $Revision$
> > > Last-Modified: $Date$
> > > Author: Benjamin Peterson
> > > Status: Draft
> > > Type: Standards Track
> > > Content-Type: text/x-rst
> > > Created: 4-April-2008
> > > Python-Version: 3.0
> > >
> > >
> > > Abstract
> > > ========
> > >
> > > This PEP proposes a new low-level module for CPython-specific
> > interpreter
> > > functions in order to clean out the sys module and separate general
> > Python
> > > functionality from implementation details.
> > >
> > >
> > > Rationale
> > > =========
> > >
> > > The sys module currently contains functions and data that can be put
> > into
> > > two
> > > major groups:
> > >
> > > 1. Data and functions that are available in all Python implementations
> > and
> > > deal
> > >     with the general running of a Python VM.
> > >
> > >    - display_hook, stdout, stdin, and stderr
> > >    - flags and warn_options
> > >    - settrace, and setprofile
> > >    - traceback, excepthook
> > >    - etc...
> > >
> > >
> > > 2. Data and function that affect the CPython interpreter.
> > >
> > >    - get/setrecursionlimit
> > >    - get/setcheckinterval
> > >    - _getframe and _current_frame
> > >    - getrefcount
> > >    - getdlopenflags
> >
> > Why getdlopenflags? That seems general to any Python implementation
> > that opens dlls (though I believe the dl module is going away in
> > Python 3, so it may not matter).
>
> I don't think any other implementations do open dynamic libs. Those flags
> don't affect the dl module; they define how Python opens C shared libs.
>
> >
> >
> > Also, maybe settscdump should be moved as well? Its description says
> > to look at "Python/ceval.c"
> >
> Yes.
>
> >
> >
> > Otherwise, it looks pretty good to me.
> >
> > Steve
> > --
> > I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
> > tiny blip on the distant coast of sanity.
> >  --- Bucky Katt, Get Fuzzy
> >
>
>
>
> --
> Cheers,
> Benjamin Peterson




-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080405/5c904aee/attachment-0001.htm 

From brett at python.org  Sat Apr  5 17:37:29 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 5 Apr 2008 17:37:29 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<47F5F473.5050406@cheimes.de>
	<bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
	<d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>
	<1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>
	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
Message-ID: <bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>

On Sat, Apr 5, 2008 at 4:58 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> Here's an updated version:
>
>
>    - display_hook, stdout, stdin, and stderr
>    - flags and warn_options
>    - settrace, and setprofile
>    - traceback, excepthook
>    - etc...
>

You still need to get rid of the "etc.". Beyond being explicit, it
makes it easier for people reviewing the PEP to see what they think
might be better placed in the new module.

-Brett

From musiccomposition at gmail.com  Sat Apr  5 18:13:26 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 5 Apr 2008 11:13:26 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<bbaeab100804040344g21238967i73c8674ec2c1ba3a@mail.gmail.com>
	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
	<d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>
	<1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>
	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>
Message-ID: <1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>

On Sat, Apr 5, 2008 at 10:37 AM, Brett Cannon <brett at python.org> wrote:

> On Sat, Apr 5, 2008 at 4:58 PM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
> > Here's an updated version:
> >
> >
> >    - display_hook, stdout, stdin, and stderr
> >    - flags and warn_options
> >    - settrace, and setprofile
> >    - traceback, excepthook
> >    - etc...
> >
>
> You still need to get rid of the "etc.". Beyond being explicit, it
> makes it easier for people reviewing the PEP to see what they think
> might be better placed in the new module.

PEP: XXX
Title: The interpreter module
Version: $Revision$
Last-Modified: $Date$
Author: Benjamin Peterson
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 4-April-2008
Python-Version: 3.0


Abstract
========

This PEP proposes a new low-level module for CPython-specific interpreter
functions in order to clean out the sys module and separate general Python
functionality from implementation details.


Rationale
=========

The sys module currently contains functions and data that can be put into
two
major groups:

1. Data and functions that are available in all Python implementations and
deal
   with the general running of a Python VM.

   - argv
   - byteorder
   - builtin_module_names, path, and modules
   - subversion, copyright, hexversion, version, and version_info
   - displayhook, __displayhook__
   - excepthook, __excepthook__, exc_info, and exc_clear
   - exec_prefix and prefix
   - executable
   - exit
   - flags, py3kwarning, dont_write_bytecode, and warn_options
   - getfilesystemencoding
   - get/setprofile
   - get/settrace
   - getwindowsversion
   - maxint and maxunicode
   - platform
   - ps1 and ps2
   - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
   - tracebacklimit


2. Data and functions that affect the CPython interpreter.

   - get/setrecursionlimit
   - get/setcheckinterval
   - _getframe and _current_frame
   - getrefcount
   - get/setdlopenflags
   - settscdumps
   - api_version
   - winver
   - dllhandle
   - float_info
   - _compact_freelists
   - _clear_type_cache

The second collections of items has been steadily increasing over the years
causing clutter in sys.  Guido has even said he doesn't recognize some of
things
in it [#bug-1522]_!

Other implementations have clearly struggled with what to do about the
contents
of sys they can't implement but must to retain compatibility.  For example,
Jython's sys module has dud set/getrecursionlimit functions.  Moving these
items
items off to another module would send a clear message about what functions
need
and need not be implemented.

It has also been proposed that the contents of types module be distributed
across the standard library [#types-removal]_; the interpreter module would
provide an excellent resting place for internal types like frames and code
objects.

Specification
=============

A new builtin module named "interpreter" (see `Naming`_) will be added.  The
functions mentioned in the second list above will be moved to it.


Transition Plan
===============

Once implemented in 3.x, the interpreter module will be back-ported to 2.6.
Py3k warnings will be added the the sys functions it replaces.


Open Issues
===========

Naming
------

The author proposes the name "interpreter" for the new module.  "pyvm" has
also
been suggested [#pyvm-name]_.


References
==========

.. [#bug-1522]

   http://bugs.python.org/issue1522

.. [#types-removal]

   http://mail.python.org/pipermail/stdlib-sig/2008-April/000172.html

.. [#pyvm-name]

   http://mail.python.org/pipermail/python-3000/2007-November/011351.html

Copyright
=========

    This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End:


>
>
> -Brett
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080405/bd73e8a4/attachment.htm 

From p.f.moore at gmail.com  Sat Apr  5 21:29:00 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 5 Apr 2008 20:29:00 +0100
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
	<d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>
	<1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>
	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>
	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
Message-ID: <79990c6b0804051229o98c9eh4e028bff6c6aaecb@mail.gmail.com>

On 05/04/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
> 1. Data and functions that are available in all Python implementations and
>    deal with the general running of a Python VM.
[...]
>    - subversion, copyright, hexversion, version, and version_info

subversion seems specific to CPython (and in fact, to the current
development processes for CPython - if we moved to a DVCS like
Mercurial or Bazaar, sys.subversion would have to go, or at least
change meaning significantly).

>    - flags, py3kwarning, dont_write_bytecode, and warn_options

dont_write_bytecode is CPython-specific, aren't they? Jython and
IronPython don't use bytecode files as far as I know.

The rest looks OK to me.
Paul.

From musiccomposition at gmail.com  Sat Apr  5 21:55:13 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 5 Apr 2008 14:55:13 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <79990c6b0804051229o98c9eh4e028bff6c6aaecb@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
	<d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>
	<1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>
	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>
	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
	<79990c6b0804051229o98c9eh4e028bff6c6aaecb@mail.gmail.com>
Message-ID: <1afaf6160804051255j19ddf23ai6ddc09357bc6c379@mail.gmail.com>

On Sat, Apr 5, 2008 at 2:29 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 05/04/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
> > 1. Data and functions that are available in all Python implementations
> and
> >    deal with the general running of a Python VM.
> [...]
> >    - subversion, copyright, hexversion, version, and version_info
>
> subversion seems specific to CPython (and in fact, to the current
> development processes for CPython - if we moved to a DVCS like
> Mercurial or Bazaar, sys.subversion would have to go, or at least
> change meaning significantly).

That's true. I put it there originally because I thought of it as more
general version info, but I can see it moving, too.

>
>
> >    - flags, py3kwarning, dont_write_bytecode, and warn_options
>
> dont_write_bytecode is CPython-specific, aren't they? Jython and
> IronPython don't use bytecode files as far as I know.

I can't speak for IronPython, but Jython writes compiled Java classes
representing the Python. Anyway, I think this should really go in imp.

>
>
> The rest looks OK to me.
> Paul.
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080405/f5980c12/attachment.htm 

From musiccomposition at gmail.com  Sat Apr  5 22:25:08 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 5 Apr 2008 15:25:08 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <fb6fbf560804051300y16fd08f5hd817950c9f09e5e1@mail.gmail.com>
References: <fb6fbf560804051300y16fd08f5hd817950c9f09e5e1@mail.gmail.com>
Message-ID: <1afaf6160804051325r6f7f1b4ele4e7258f6eca3ae1@mail.gmail.com>

On Sat, Apr 5, 2008 at 3:00 PM, Jim Jewett <jimjjewett at gmail.com> wrote:

> How have you decided which attributes are CPython-specific?
> I'm not saying your decisions are wrong, but I find all of them at
> least up for questioning.
>
> Those marked non-CPython-specific
> ============================
>
>   - argv
>
> Does this make sense for embedded python?

Maybe, that doesn't mean it shouldn't be there.

>
>
>   - byteorder
>
> This seems fairly low-level.  I wouldn't expect to need it if working
> strictly at the python level, unless writing wire-protocols *and*
> working with objects larger than bytes.
>
> If you do need it, should text representation (UCS2 vs UCS4 vs UTF8 vs
> bytestrings) be exposed?

It should probably go to platform.

>
>
>   - builtin_module_names, path, and modules
>
> I'm not sure why these three are together.
> What is the builtin_module_names?

Modules which are compiled into the interpreter (like sys and nt, mac, or
posix). Maybe, it should go to interpreter.

>
> sys.path might be an oddball on a database-based system, such as classic
> PalmOS.
>
>   - subversion, copyright, hexversion, version, and version_info
>
> These do seem reasonable; they refer to the executable.  Though even
> then, I wonder if there should be a way to extend it for
> customizations.  ("embedded in XYZ", or "without unicode")
>
>   - displayhook, __displayhook__
>   - excepthook, __excepthook__, exc_info, and exc_clear
>
> Are these required of every implementation?

Every one that wants to work. :)

>
>
>   - exec_prefix and prefix
>   - executable
>   - exit
>
> Are  these?  And do they make sense when embedded?

sys.executable and exec_prefix is allowed to be empty.

>
>
>   - flags, py3kwarning, dont_write_bytecode, and warn_options
>
> Is the bytecode stage itself a crucial part of the langauge?  I had
> thought of the the bytecode as an implementation detail, and so
> whether or not to write it out would seem even more
> implementation-specific.

What the bytecode is and how it is generated is implementation specific.
It's not the fact you're writing it or not.

>
>
>   - getfilesystemencoding
>
> OK; but this seems to interact with text representation and path.
>
>   - get/setprofile
>   - get/settrace
>
> These seem as CPython-specific as anything frame-related.

Jython provides them.

>
>
>   - getwindowsversion
>
> This obviously doesn't make sense on a non-windows machine; why isn't
> it in platform instead of sys?
>
>   - maxint and maxunicode
>
> I'm not sure what value these have.  I assume maxint doesn't include
> longs -- so is it just the maximum efficiently represented integer, or
> is this specific to C extensions, or ..?

The maximum int on the system. Jython provides this.

>
>
> And is maxunicode just roundabout way of figuring out the concrete
> representation (code points) of unicode characters?

It is the max Unicode character  that Python's unicode implementation is
capable of handling. Jython provides this.

>
>
>   - platform
>
> Should this be subsumed by the platform module?

Hmm. I don't know. For basic platform tests, this sure is easy.

>
>
>   - ps1 and ps2
>
> This really seems like a config issue rather than sys.

Yeh, sys is about runtime Python. Besides, it's global to all
implementations.

>
>
>   - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
>
> These, at least, are clear -- to the extent that they make sense.  (In
> some environments, they don't.)
>
>   - tracebacklimit
>
> How is this different from setrecursionlimit?

It defines how many lines of traceback are printed in an exception.

>
>
> Those marked CPython-specific
> =========================
>
>   - get/setrecursionlimit
>   - get/setcheckinterval
>
> These are runtime characteristics, but I don't see them (necessarily)
> being tied to the implementation.  Just returning False to say the
> limit isn't relevant makes sense, and returning some huge number may
> work in practice.  If you care enough to say "Can I recurse 3000
> frames?", that is a legitimate question, and it just so happens that
> Jython should always answer "yes".

Actually, I believe you get a stack overflow before that. It doesn't tell
you that.

>
>
>   - _getframe and _current_frame
>
> I expect the details of a frame may be different with different
> implementations, but is there an implemenation that doesn't have
> frames at all?  (I could imagine that it is a pain to get a frame from
> a compiled version, but the Java tracebacks and introspection need
> something roughly equivalent.)

Well, it's not there now...

>
>
>   - getrefcount
>
> This should probably be in gc, rather that sys.
>
>   - get/setdlopenflags
>   - settscdumps
>   - api_version
>   - winver
>   - dllhandle
>   - float_info
>
> I don't find all of these in 2.5 help(sys), but to the extent I
> understand them, they are about extensions rather the system.  If
> Python under java or  .net did open .dlls or support ffi extensions, I
> would expect a similar API.

Some of them are new in 2.6. Look at those docs.

>
>
>   - _compact_freelists
>   - _clear_type_cache
>
> These should probably be in gc, rather that sys.
>
>
> To summarize my alternative
> ======================
>
> sys -- representing the built system
>
>   - subversion, copyright, hexversion, version, and version_info
>    - builtin_module_names
>    - exec_prefix and prefix
>   - executable
>   - exit
>
> gc -- representing memory management
>
>   - getrefcount
>    - _compact_freelists
>   - _clear_type_cache
>
> platform -- representing the OS environment
>   - getfilesystemencoding
>   - getwindowsversion
>   - platform
>
> runtime -- representing this particular runtime environment

Sys is the runtime environment. We don't need a new module for that.

>
>
>   - argv
>   - path (today's sys.path, not os.path)
>   - modules
>    - displayhook, __displayhook__
>   - excepthook, __excepthook__, exc_info, and exc_clear
>    - flags
>   - py3kwarning, warn_options  (why are these not just in warnings?)
>   - dont_write_bytecode
>   - get/setprofile
>   - get/settrace
>    - ps1 and ps2
>   - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
>
>   - tracebacklimit
>    - get/setrecursionlimit
>   - get/setcheckinterval
>   - _getframe and _current_frame
>
>
> ffi  -- representing bit-level foreign function interface details
> (maybe tied to ctypes?)
>
>   - byteorder
>   - maxint and maxunicode
>   - get/setdlopenflags
>   - settscdumps   # I'm not sure what this one is
>    - api_version
>   - winver
>   - dllhandle
>   - float_info
>
>
> (whehter os and os.path should also be mixed in to the reorg ... is a
> different question.)
>
> -jJ
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080405/30b1fb23/attachment-0001.htm 

From brett at python.org  Sat Apr  5 23:04:29 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 5 Apr 2008 23:04:29 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
	<d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>
	<1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>
	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>
	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
Message-ID: <bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>

On Sat, Apr 5, 2008 at 6:13 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
>
>
>
>
> On Sat, Apr 5, 2008 at 10:37 AM, Brett Cannon <brett at python.org> wrote:
> >
> > On Sat, Apr 5, 2008 at 4:58 PM, Benjamin Peterson
> > <musiccomposition at gmail.com> wrote:
> > > Here's an updated version:
> > >
> > >
> > >    - display_hook, stdout, stdin, and stderr
> > >    - flags and warn_options
> > >    - settrace, and setprofile
> > >    - traceback, excepthook
> > >    - etc...
> > >
> >
> > You still need to get rid of the "etc.". Beyond being explicit, it
> > makes it easier for people reviewing the PEP to see what they think
> > might be better placed in the new module.
>
> PEP: XXX
> Title: The interpreter module
> Version: $Revision$
> Last-Modified: $Date$
> Author: Benjamin Peterson
> Status: Draft
> Type: Standards Track
>  Content-Type: text/x-rst
> Created: 4-April-2008
> Python-Version: 3.0
>
>
> Abstract
> ========
>
> This PEP proposes a new low-level module for CPython-specific interpreter
> functions in order to clean out the sys module and separate general Python
>  functionality from implementation details.
>
>
> Rationale
> =========
>
> The sys module currently contains functions and data that can be put into
> two
> major groups:
>
> 1. Data and functions that are available in all Python implementations and
> deal
>     with the general running of a Python VM.
>
>    - argv
>    - byteorder
>    - builtin_module_names, path, and modules

builtin_module_names is an implementation detail and thus should be moved.

>    - subversion, copyright, hexversion, version, and version_info

Ditto for subversion.

>    - displayhook, __displayhook__
>     - excepthook, __excepthook__, exc_info, and exc_clear
>    - exec_prefix and prefix
>    - executable
>    - exit
>    - flags, py3kwarning, dont_write_bytecode, and warn_options

dont_write_bytecode might be better off in the new module, but then
bytecode is part of the stdlib. I guess it depends on how the other
interpreters view bytecode. They could easily just have it always set
to False.

>    - getfilesystemencoding
>    - get/setprofile
>     - get/settrace
>    - getwindowsversion
>    - maxint and maxunicode
>    - platform
>    - ps1 and ps2
>    - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
>    - tracebacklimit
>

Perhaps we should have sys.interpreter or sys.vm? That way e.g. Jython
no longer has to override sys.platform to specify that VM-specific
changes are in effect?

-Brett

From musiccomposition at gmail.com  Sat Apr  5 23:11:58 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 5 Apr 2008 16:11:58 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
	<d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>
	<1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>
	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>
	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>
Message-ID: <1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>

On Sat, Apr 5, 2008 at 4:04 PM, Brett Cannon <brett at python.org> wrote:

> On Sat, Apr 5, 2008 at 6:13 PM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
> >
> >
> >
> >
> > On Sat, Apr 5, 2008 at 10:37 AM, Brett Cannon <brett at python.org> wrote:
> > >
> > > On Sat, Apr 5, 2008 at 4:58 PM, Benjamin Peterson
> > > <musiccomposition at gmail.com> wrote:
> > > > Here's an updated version:
> > > >
> > > >
> > > >    - display_hook, stdout, stdin, and stderr
> > > >    - flags and warn_options
> > > >    - settrace, and setprofile
> > > >    - traceback, excepthook
> > > >    - etc...
> > > >
> > >
> > > You still need to get rid of the "etc.". Beyond being explicit, it
> > > makes it easier for people reviewing the PEP to see what they think
> > > might be better placed in the new module.
> >
> > PEP: XXX
> > Title: The interpreter module
> > Version: $Revision$
> > Last-Modified: $Date$
> > Author: Benjamin Peterson
> > Status: Draft
> > Type: Standards Track
> >  Content-Type: text/x-rst
> > Created: 4-April-2008
> > Python-Version: 3.0
> >
> >
> > Abstract
> > ========
> >
> > This PEP proposes a new low-level module for CPython-specific
> interpreter
> > functions in order to clean out the sys module and separate general
> Python
> >  functionality from implementation details.
> >
> >
> > Rationale
> > =========
> >
> > The sys module currently contains functions and data that can be put
> into
> > two
> > major groups:
> >
> > 1. Data and functions that are available in all Python implementations
> and
> > deal
> >     with the general running of a Python VM.
> >
> >    - argv
> >    - byteorder
> >    - builtin_module_names, path, and modules
>
> builtin_module_names is an implementation detail and thus should be moved.
>
> >    - subversion, copyright, hexversion, version, and version_info
>
> Ditto for subversion.
>
> >    - displayhook, __displayhook__
> >     - excepthook, __excepthook__, exc_info, and exc_clear
> >    - exec_prefix and prefix
> >    - executable
> >    - exit
> >    - flags, py3kwarning, dont_write_bytecode, and warn_options
>
> dont_write_bytecode might be better off in the new module, but then
> bytecode is part of the stdlib. I guess it depends on how the other
> interpreters view bytecode. They could easily just have it always set
> to False.

What do you think about moving it to imp.

>
>
> >    - getfilesystemencoding
> >    - get/setprofile
> >     - get/settrace
> >    - getwindowsversion
> >    - maxint and maxunicode
> >    - platform
> >    - ps1 and ps2
> >    - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
> >    - tracebacklimit
> >
>
> Perhaps we should have sys.interpreter or sys.vm? That way e.g. Jython
> no longer has to override sys.platform to specify that VM-specific
> changes are in effect?

That's a wonderful idea. Then you wouldn't have to resort to sys.platform
being "java" and such tricks.

>
>
> -Brett
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080405/3fb78be5/attachment.htm 

From cfbolz at gmx.de  Sat Apr  5 23:48:58 2008
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Sat, 05 Apr 2008 23:48:58 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>	<1afaf6160804040629p5d652e85l700c5032af8f940e@mail.gmail.com>	<d11dcfba0804040801r2092d2au38b905515df4a3fe@mail.gmail.com>	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>	<d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>	<1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>
Message-ID: <47F7F3CA.5090003@gmx.de>

Brett Cannon wrote:
[snip]
> Perhaps we should have sys.interpreter or sys.vm? That way e.g. Jython
> no longer has to override sys.platform to specify that VM-specific
> changes are in effect?

FWIW, PyPy has always been using various hacks to figure out what the
underlying implementation is. An official way to get at that info would
be very nice.

Cheers,

Carl Friedrich Bolz

From musiccomposition at gmail.com  Sun Apr  6 02:39:34 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 5 Apr 2008 19:39:34 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <fb6fbf560804051650u51add9e0na0ef0bd5ad426fd@mail.gmail.com>
References: <fb6fbf560804051300y16fd08f5hd817950c9f09e5e1@mail.gmail.com>
	<1afaf6160804051325r6f7f1b4ele4e7258f6eca3ae1@mail.gmail.com>
	<fb6fbf560804051650u51add9e0na0ef0bd5ad426fd@mail.gmail.com>
Message-ID: <1afaf6160804051739q73524988lfe7bb89efe391fc3@mail.gmail.com>

On Sat, Apr 5, 2008 at 6:50 PM, Jim Jewett <jimjjewett at gmail.com> wrote:

> On 4/5/08, Benjamin Peterson <musiccomposition at gmail.com> wrote:
> > On Sat, Apr 5, 2008 at 3:00 PM, Jim Jewett <jimjjewett at gmail.com> wrote:
>
> > > How have you decided which attributes are CPython-specific?
> > > I'm not saying your decisions are wrong, but I find all of them at
> > > least up for questioning.
>
> [trimming most; leaving only the parts where Benjamin commented, *and*
> I disagree with his comments]
>
> > What the bytecode is and how it is generated is
> > implementation specific.
> > It's not the fact you're writing it or not.
>
> I see no reason (other than efficiency or convenience of
> implementation) to even have a bytecode stage.  If you interpret the
> python source directly (as opposed to compiling it, even to bytecode)
> then there is no reason compiled product to save -- and no reason to
> indicate whether it should be saved.

But as of now, (don't quote me on this) all complete Python implementations
write some sort of bytecode.

>
>
> > >   - maxint and maxunicode
> > >
> > > I'm not sure what value these have.  I assume maxint doesn't include
> > > longs -- so is it just the maximum efficiently represented integer, or
> > > is this specific to C extensions, or ..?
> > The maximum int on the system. Jython provides this.
>
> Right, because Jython is based on Java which happens to allow "int" as
> a primitive type instead of requiring Integer objects.  The size of a
> system "int" is an implementation detail (though it has beeen
> effectively standardized for over a decade) that just happens to be
> shared by the two implementations.  The python language doesn't
> specify that anything odd should happen when you do
>
>    x=sys.maxint+1
>
> and the fact that it is represented differently is just an internal
> detail.

It is useful in general Python code, though, because some operations are
constrained by it. This is the max a C int can handle, so if you're
converting some value from Python to C for processing, and your value might
be huge, it's helpful to be able to compare it.

>
>
> > > And is maxunicode just roundabout way of figuring out the concrete
> > > representation (code points) of unicode characters?
> > It is the max Unicode character  that Python's unicode
> > implementation is capable of handling. Jython provides this.
>
> Even worse -- unicode characters are barely ordered, and are supported
> way above 16bits -- it is just an internal implementation detail that
> some physical encodings can't do it without some awkwardness (and the
> possibility of representing invalid values).
>
> (That said, Guido has ruled that the length and slicing of the unicode
> type will continue to be based on the physical code points, rather
> than the abstract characters, so there may be a reason to expose it.
> But is is clearly an implementation limit rather than a desirable part
> of the langauge.)

This is useful also because it tells you whether Python was compiled with
wide Unicode or short Unicode.

>
>
> > >   - ps1 and ps2
>
> > > This really seems like a config issue rather than sys.
> > Yeh, sys is about runtime Python. Besides, it's global to all
> > implementations.
>
> Within the sys exposed to IDLE, it seems to be gone.  (Though I can
> get it from the plain python.)  I expect other environments (ipython?)
> may have their own ideas about which variables are needed to control
> interactivity.

Right, ps1 and ps2 dictate the prompts of the *default* Python interactive
prompt at runtime,  so they should be in sys.

>
>
> > >   - tracebacklimit
> > >
> > > How is this different from setrecursionlimit?
> > It defines how many lines of traceback are printed in an exception.
>
> What I meant is "why are those two in separate sections?"
>
> I think of both tracebacklimit and recursionlimit as implementation
> restrictions.  They violate the language purity in favor of a
> practical benefit.  Since the exact tradeoffs are debatable, there are
> ways to reset them.

I disagree. Every Python implementation is going to have tracebacks, and be
able to handle huge ones. It's generally practical to be able to limit them.
However, not every Python implementation is going to work by frames and
recursion.

>
>
> That Jython still sees practical value in trimming exception displays
> to a readable length, but does not see enough value in restricting
> recursion depth just means that the cost of recursion is less there.
>
> > > If you care enough to say "Can I recurse 3000
> > > frames?", that is a legitimate question, and it just so happens that
> > > Jython should always answer "yes".
> > Actually, I believe you get a stack overflow before that. It doesn't
> tell
> > you that.
>
> Is this because of a limit on the number of stack frames, or because
> of the limit on the stacksize?  If so, that is still correlated with a
> recursion limit (so they can give a heuristic, based on the stack
> size).

It's stack size, but you'd have to talk to the Jython people about that.

>
>
> -jJ
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080405/fafa1811/attachment-0001.htm 

From brett at python.org  Sun Apr  6 10:09:57 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 6 Apr 2008 10:09:57 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<1afaf6160804040827s46afc876g9ce6a2e0dd28bbd4@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
	<d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>
	<1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>
	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>
	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>
	<1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>
Message-ID: <bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>

On Sat, Apr 5, 2008 at 11:11 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
>
>
>
>
> On Sat, Apr 5, 2008 at 4:04 PM, Brett Cannon <brett at python.org> wrote:
> > On Sat, Apr 5, 2008 at 6:13 PM, Benjamin Peterson
> >
> >
> >
> > <musiccomposition at gmail.com> wrote:
> > >
> > >
> > >
> > >
> > > On Sat, Apr 5, 2008 at 10:37 AM, Brett Cannon <brett at python.org> wrote:
> > > >
> > > > On Sat, Apr 5, 2008 at 4:58 PM, Benjamin Peterson
> > > > <musiccomposition at gmail.com> wrote:
> > > > > Here's an updated version:
> > > > >
> > > > >
> > > > >    - display_hook, stdout, stdin, and stderr
> > > > >    - flags and warn_options
> > > > >    - settrace, and setprofile
> > > > >    - traceback, excepthook
> > > > >    - etc...
> > > > >
> > > >
> > > > You still need to get rid of the "etc.". Beyond being explicit, it
> > > > makes it easier for people reviewing the PEP to see what they think
> > > > might be better placed in the new module.
> > >
> > > PEP: XXX
> > > Title: The interpreter module
> > > Version: $Revision$
> > > Last-Modified: $Date$
> > > Author: Benjamin Peterson
> > > Status: Draft
> > > Type: Standards Track
> > >  Content-Type: text/x-rst
> > > Created: 4-April-2008
> > > Python-Version: 3.0
> > >
> > >
> > > Abstract
> > > ========
> > >
> > > This PEP proposes a new low-level module for CPython-specific
> interpreter
> > > functions in order to clean out the sys module and separate general
> Python
> > >  functionality from implementation details.
> > >
> > >
> > > Rationale
> > > =========
> > >
> > > The sys module currently contains functions and data that can be put
> into
> > > two
> > > major groups:
> > >
> > > 1. Data and functions that are available in all Python implementations
> and
> > > deal
> > >     with the general running of a Python VM.
> > >
> > >    - argv
> > >    - byteorder
> > >    - builtin_module_names, path, and modules
> >
> > builtin_module_names is an implementation detail and thus should be moved.
> >
> >
> > >    - subversion, copyright, hexversion, version, and version_info
> >
> > Ditto for subversion.
> >
> >
> > >    - displayhook, __displayhook__
> > >     - excepthook, __excepthook__, exc_info, and exc_clear
> > >    - exec_prefix and prefix
> > >    - executable
> > >    - exit
> > >    - flags, py3kwarning, dont_write_bytecode, and warn_options
> >
> > dont_write_bytecode might be better off in the new module, but then
> > bytecode is part of the stdlib. I guess it depends on how the other
> > interpreters view bytecode. They could easily just have it always set
> > to False.
> What do you think about moving it to imp.
>

Fine by me, but some people still seem to think this is an
implementation detail. Since there is a lack of a clear solution for
this I say make it an Open Issue and wait until python-dev is brought
into this to figure it out.

-Brett

From musiccomposition at gmail.com  Sun Apr  6 14:45:36 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 6 Apr 2008 07:45:36 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<1afaf6160804040951s7b5eec80jc5dcc8597b3894a6@mail.gmail.com>
	<d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>
	<1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>
	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>
	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>
	<1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>
	<bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>
Message-ID: <1afaf6160804060545h907dde6vaef52fd387ad96ff@mail.gmail.com>

On Sun, Apr 6, 2008 at 3:09 AM, Brett Cannon <brett at python.org> wrote:

> On Sat, Apr 5, 2008 at 11:11 PM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
> >
> >
> >
> >
> > On Sat, Apr 5, 2008 at 4:04 PM, Brett Cannon <brett at python.org> wrote:
> > > On Sat, Apr 5, 2008 at 6:13 PM, Benjamin Peterson
> > >
> > >
> > >
> > > <musiccomposition at gmail.com> wrote:
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Apr 5, 2008 at 10:37 AM, Brett Cannon <brett at python.org>
> wrote:
> > > > >
> > > > > On Sat, Apr 5, 2008 at 4:58 PM, Benjamin Peterson
> > > > > <musiccomposition at gmail.com> wrote:
> > > > > > Here's an updated version:
> > > > > >
> > > > > >
> > > > > >    - display_hook, stdout, stdin, and stderr
> > > > > >    - flags and warn_options
> > > > > >    - settrace, and setprofile
> > > > > >    - traceback, excepthook
> > > > > >    - etc...
> > > > > >
> > > > >
> > > > > You still need to get rid of the "etc.". Beyond being explicit, it
> > > > > makes it easier for people reviewing the PEP to see what they
> think
> > > > > might be better placed in the new module.
> > > >
> > > > PEP: XXX
> > > > Title: The interpreter module
> > > > Version: $Revision$
> > > > Last-Modified: $Date$
> > > > Author: Benjamin Peterson
> > > > Status: Draft
> > > > Type: Standards Track
> > > >  Content-Type: text/x-rst
> > > > Created: 4-April-2008
> > > > Python-Version: 3.0
> > > >
> > > >
> > > > Abstract
> > > > ========
> > > >
> > > > This PEP proposes a new low-level module for CPython-specific
> > interpreter
> > > > functions in order to clean out the sys module and separate general
> > Python
> > > >  functionality from implementation details.
> > > >
> > > >
> > > > Rationale
> > > > =========
> > > >
> > > > The sys module currently contains functions and data that can be put
> > into
> > > > two
> > > > major groups:
> > > >
> > > > 1. Data and functions that are available in all Python
> implementations
> > and
> > > > deal
> > > >     with the general running of a Python VM.
> > > >
> > > >    - argv
> > > >    - byteorder
> > > >    - builtin_module_names, path, and modules
> > >
> > > builtin_module_names is an implementation detail and thus should be
> moved.
> > >
> > >
> > > >    - subversion, copyright, hexversion, version, and version_info
> > >
> > > Ditto for subversion.
> > >
> > >
> > > >    - displayhook, __displayhook__
> > > >     - excepthook, __excepthook__, exc_info, and exc_clear
> > > >    - exec_prefix and prefix
> > > >    - executable
> > > >    - exit
> > > >    - flags, py3kwarning, dont_write_bytecode, and warn_options
> > >
> > > dont_write_bytecode might be better off in the new module, but then
> > > bytecode is part of the stdlib. I guess it depends on how the other
> > > interpreters view bytecode. They could easily just have it always set
> > > to False.
> > What do you think about moving it to imp.
> >
>
> Fine by me, but some people still seem to think this is an
> implementation detail. Since there is a lack of a clear solution for
> this I say make it an Open Issue and wait until python-dev is brought
> into this to figure it out.

Ok. Here's another version:

PEP: XXX
Title: Cleaning out sys and the interpreter module
Version: $Revision$
Last-Modified: $Date$
Author: Benjamin Peterson
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 4-April-2008
Python-Version: 3.0


Abstract
========

This PEP proposes a new low-level module for CPython-specific interpreter
functions in order to clean out the sys module and separate general Python
functionality from implementation details.


Rationale
=========

The sys module currently contains functions and data that can be put into
two
major groups:

1. Data and functions that are available in all Python implementations and
deal
   with the general running of a Python VM.

   - argv
   - byteorder
   - builtin_module_names, path, and modules
   - copyright, hexversion, version, and version_info
   - displayhook, __displayhook__
   - excepthook, __excepthook__, exc_info, and exc_clear
   - exec_prefix and prefix
   - executable
   - exit
   - flags, py3kwarning, dont_write_bytecode, and warn_options
   - getfilesystemencoding
   - get/setprofile
   - get/settrace
   - getwindowsversion
   - maxint and maxunicode
   - platform
   - ps1 and ps2
   - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
   - tracebacklimit


2. Data and functions that affect the CPython interpreter.

   - get/setrecursionlimit
   - get/setcheckinterval
   - _getframe and _current_frame
   - getrefcount
   - get/setdlopenflags
   - settscdumps
   - api_version
   - winver
   - dllhandle
   - float_info
   - _compact_freelists
   - _clear_type_cache
   - subversion

The second collections of items has been steadily increasing over the years
causing clutter in sys.  Guido has even said he doesn't recognize some of
things
in it [#bug-1522]_!

Other implementations have clearly struggled with what to do about the
contents
of sys they can't implement but must to retain compatibility.  For example,
Jython's sys module has dud set/getrecursionlimit functions.  Moving these
items
items off to another module would send a clear message about what functions
need
and need not be implemented.

It has also been proposed that the contents of types module be distributed
across the standard library [#types-removal]_; the interpreter module would
provide an excellent resting place for internal types like frames and code
objects.

Specification
=============

A new builtin module named "interpreter" (see `Naming`_) will be added.

The second list of items above will be split into the stdlib as follows:

The interpreter module
    - get/setrecursionlimit
    - get/setcheckinterval
    - _getframe and _current_frame
    - get/setdlopenflags
    - settscdumps
    - api_version
    - winver
    - dllhandle
    - float_info
    - _clear_type_cache
    - subversion

The gc module:
    - getrefcount
    - _compact_freelists


Transition Plan
===============

Once implemented in 3.x, the interpreter module will be back-ported to 2.6.
Py3k warnings will be added the the sys functions it replaces.


Open Issues
===========

What should move?
-----------------

dont_write_bytecode
^^^^^^^^^^^^^^^^^^^^

Some believe that the writing of bytecode is an implementation detail and
should
be moved [#bytecode-issue]_.  The counterargument is that all current,
complete
Python implementations do write some sort of bytecode, so it is valuable to
be
able to disable it.  Also, if it is moved, some wish to put it in the imp
module.


Naming
------

The author proposes the name "interpreter" for the new module.  "pyvm" has
also
been suggested [#pyvm-name]_.


References
==========

.. [#bug-1522]

   http://bugs.python.org/issue1522

.. [#types-removal]

   http://mail.python.org/pipermail/stdlib-sig/2008-April/000172.html

.. [#bytecode-issue]

   http://mail.python.org/pipermail/stdlib-sig/2008-April/000217.html

.. [#pyvm-name]

   http://mail.python.org/pipermail/python-3000/2007-November/011351.html

Copyright
=========

    This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End:


>
>
> -Brett
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080406/0086244f/attachment.htm 

From brett at python.org  Sun Apr  6 17:56:43 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 6 Apr 2008 17:56:43 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804060545h907dde6vaef52fd387ad96ff@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<d11dcfba0804041409o6b8f6546o19258b72689b3cd7@mail.gmail.com>
	<1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>
	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>
	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>
	<1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>
	<bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>
	<1afaf6160804060545h907dde6vaef52fd387ad96ff@mail.gmail.com>
Message-ID: <bbaeab100804060856m6ce1e6a5nb3042a6e66c2cc23@mail.gmail.com>

On Sun, Apr 6, 2008 at 2:45 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:

> 1. Data and functions that are available in all Python implementations and
> deal
>    with the general running of a Python VM.
>
>    - argv
>    - byteorder
>    - builtin_module_names, path, and modules

I still think builtin_module_names should be moved. There is no
guarantee other VMs have a concept of a built-in module.

>     - copyright, hexversion, version, and version_info
>    - displayhook, __displayhook__
>    - excepthook, __excepthook__, exc_info, and exc_clear
>    - exec_prefix and prefix
>    - executable
>    - exit
>    - flags, py3kwarning, dont_write_bytecode, and warn_options
>     - getfilesystemencoding
>    - get/setprofile
>    - get/settrace
>    - getwindowsversion

It seems silly to have Windows-specific stuff like this in the sys
module, but I don't know where else they should go.

>    - maxint and maxunicode
>    - platform
>    - ps1 and ps2
>    - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
>     - tracebacklimit
>
>
> 2. Data and functions that affect the CPython interpreter.
>
>    - get/setrecursionlimit
>    - get/setcheckinterval
>    - _getframe and _current_frame
>    - getrefcount
>    - get/setdlopenflags
>     - settscdumps
>    - api_version
>    - winver
>    - dllhandle
>    - float_info
>    - _compact_freelists
>    - _clear_type_cache
>    - subversion

There is some stuff missing from these lists, e.g., meta_path,
path_importer_cache, path_hooks, call_tracing, etc. You should do a
dir() in sys and fill in the missing attributes into the list.

It's looking good, though!

-Brett

From musiccomposition at gmail.com  Sun Apr  6 18:28:04 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 6 Apr 2008 11:28:04 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <bbaeab100804060856m6ce1e6a5nb3042a6e66c2cc23@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<1afaf6160804050718g5cc7eacfle0aa66fddfb6c704@mail.gmail.com>
	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>
	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>
	<1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>
	<bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>
	<1afaf6160804060545h907dde6vaef52fd387ad96ff@mail.gmail.com>
	<bbaeab100804060856m6ce1e6a5nb3042a6e66c2cc23@mail.gmail.com>
Message-ID: <1afaf6160804060928l7b8e770fo5029da56f8752c1b@mail.gmail.com>

On Sun, Apr 6, 2008 at 10:56 AM, Brett Cannon <brett at python.org> wrote:

> On Sun, Apr 6, 2008 at 2:45 PM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
>
> > 1. Data and functions that are available in all Python implementations
> and
> > deal
> >    with the general running of a Python VM.
> >
> >    - argv
> >    - byteorder
> >    - builtin_module_names, path, and modules
>
> I still think builtin_module_names should be moved. There is no
> guarantee other VMs have a concept of a built-in module.

Done.

>
>
> >     - copyright, hexversion, version, and version_info
> >    - displayhook, __displayhook__
> >    - excepthook, __excepthook__, exc_info, and exc_clear
> >    - exec_prefix and prefix
> >    - executable
> >    - exit
> >    - flags, py3kwarning, dont_write_bytecode, and warn_options
> >     - getfilesystemencoding
> >    - get/setprofile
> >    - get/settrace
> >    - getwindowsversion
>
> It seems silly to have Windows-specific stuff like this in the sys
> module, but I don't know where else they should go.

Indeed, it does. platform is the only one I can think of.

>
>
> >    - maxint and maxunicode
> >    - platform
> >    - ps1 and ps2
> >    - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
> >     - tracebacklimit
> >
> >
> > 2. Data and functions that affect the CPython interpreter.
> >
> >    - get/setrecursionlimit
> >    - get/setcheckinterval
> >    - _getframe and _current_frame
> >    - getrefcount
> >    - get/setdlopenflags
> >     - settscdumps
> >    - api_version
> >    - winver
> >    - dllhandle
> >    - float_info
> >    - _compact_freelists
> >    - _clear_type_cache
> >    - subversion
>
> There is some stuff missing from these lists, e.g., meta_path,
> path_importer_cache, path_hooks, call_tracing, etc. You should do a
> dir() in sys and fill in the missing attributes into the list.

I will do that. I was looking at the 2.6 docs.

>
>
> It's looking good, though!
>
> -Brett
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080406/1fd0d4e1/attachment.htm 

From musiccomposition at gmail.com  Sun Apr  6 18:42:42 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sun, 6 Apr 2008 11:42:42 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804060928l7b8e770fo5029da56f8752c1b@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>
	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>
	<1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>
	<bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>
	<1afaf6160804060545h907dde6vaef52fd387ad96ff@mail.gmail.com>
	<bbaeab100804060856m6ce1e6a5nb3042a6e66c2cc23@mail.gmail.com>
	<1afaf6160804060928l7b8e770fo5029da56f8752c1b@mail.gmail.com>
Message-ID: <1afaf6160804060942r82442afoff02f0e70407c53b@mail.gmail.com>

[snip]

With more comments taken into consideration:

PEP: XXX
Title: Cleaning out sys and the interpreter module
Version: $Revision$
Last-Modified: $Date$
Author: Benjamin Peterson
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 4-April-2008
Python-Version: 3.0


Abstract
========

This PEP proposes a new low-level module for CPython-specific interpreter
functions in order to clean out the sys module and separate general Python
functionality from implementation details.


Rationale
=========

The sys module currently contains functions and data that can be put into
two
major groups:

1. Data and functions that are available in all Python implementations and
deal
   with the general running of a Python VM.

   - argv
   - byteorder
   - path, path_hooks, meta_path, path_importer_cache, and modules
   - copyright, hexversion, version, and version_info
   - displayhook, __displayhook__
   - excepthook, __excepthook__, exc_info, and exc_clear
   - exec_prefix and prefix
   - executable
   - exit
   - flags, py3kwarning, dont_write_bytecode, and warn_options
   - getfilesystemencoding
   - get/setprofile
   - get/settrace, call_tracing
   - getwindowsversion
   - maxint and maxunicode
   - platform
   - ps1 and ps2
   - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
   - tracebacklimit
   - intern


2. Data and functions that affect the CPython interpreter.

   - get/setrecursionlimit
   - get/setcheckinterval
   - _getframe and _current_frame
   - getrefcount
   - get/setdlopenflags
   - settscdumps
   - api_version
   - winver
   - dllhandle
   - float_info
   - _compact_freelists
   - _clear_type_cache
   - subversion
   - builtin_module_names
   - callstats

The second collections of items has been steadily increasing over the years
causing clutter in sys.  Guido has even said he doesn't recognize some of
things
in it [#bug-1522]_!

Other implementations have clearly struggled with what to do about the
contents
of sys they can't implement but must to retain compatibility.  For example,
Jython's sys module has dud set/getrecursionlimit functions.  Moving these
items
items off to another module would send a clear message about what functions
need
and need not be implemented.

It has also been proposed that the contents of types module be distributed
across the standard library [#types-removal]_; the interpreter module would
provide an excellent resting place for internal types like frames and code
objects.

Specification
=============

A new builtin module named "interpreter" (see `Naming`_) will be added.

The second list of items above will be split into the stdlib as follows:

The interpreter module
    - get/setrecursionlimit
    - get/setcheckinterval
    - _getframe and _current_frame
    - get/setdlopenflags
    - settscdumps
    - api_version
    - winver
    - dllhandle
    - float_info
    - _clear_type_cache
    - subversion
    - builtin_module_names
    - callstats

The gc module:
    - getrefcount
    - _compact_freelists


Transition Plan
===============

Once implemented in 3.x, the interpreter module will be back-ported to 2.6.
Py3k warnings will be added the the sys functions it replaces.


Open Issues
===========

What should move?
-----------------

dont_write_bytecode
^^^^^^^^^^^^^^^^^^^^

Some believe that the writing of bytecode is an implementation detail and
should
be moved [#bytecode-issue]_.  The counterargument is that all current,
complete
Python implementations do write some sort of bytecode, so it is valuable to
be
able to disable it.  Also, if it is moved, some wish to put it in the imp
module.


Move to some to imp?
--------------------

It was noted that dont_write_bytecode or maybe builtin_module_names might
fit
nicely in the imp module.


Naming
------

The author proposes the name "interpreter" for the new module.  "pyvm" has
also
been suggested [#pyvm-name]_.


References
==========

.. [#bug-1522]

   http://bugs.python.org/issue1522

.. [#types-removal]

   http://mail.python.org/pipermail/stdlib-sig/2008-April/000172.html

.. [#bytecode-issue]

   http://mail.python.org/pipermail/stdlib-sig/2008-April/000217.html

.. [#pyvm-name]

   http://mail.python.org/pipermail/python-3000/2007-November/011351.html

Copyright
=========

    This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End:


-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080406/1ff5fb3a/attachment.htm 

From mal at egenix.com  Mon Apr  7 17:09:09 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 07 Apr 2008 17:09:09 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1afaf6160804060942r82442afoff02f0e70407c53b@mail.gmail.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>	<1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>	<bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>	<1afaf6160804060545h907dde6vaef52fd387ad96ff@mail.gmail.com>	<bbaeab100804060856m6ce1e6a5nb3042a6e66c2cc23@mail.gmail.com>	<1afaf6160804060928l7b8e770fo5029da56f8752c1b@mail.gmail.com>
	<1afaf6160804060942r82442afoff02f0e70407c53b@mail.gmail.com>
Message-ID: <47FA3915.5060508@egenix.com>

Some comments:

The rational groups the function in two groups and this grouping
makes a lot of sense.

However, your proposal later on doesn't use this rational in any
way.

IMHO, it would be better to keep a "sys" module that exposes everything
you have in group 1 and an implementation specific module "cpython"
that exposes everything you have in group 2.

If an applications needs CPython specific features it would then
import cpython. This would make things easy to see in the source
code and also raise an exception on platforms where this module
is not available, e.g. Jython. The same could be done for
other Python implementations, e.g. have a "jython" module for
Jython specific things, "ironpython" for IronPython, etc.

Introducing a new long name "interpreter" doesn't really help
with resolving the problems you state in the rational and neither
does putting APIs from both groups into that new module :-)

BTW: sys.intern is a CPython implementation detail and needs
to go into group 2.

-- 
Marc-Andre Lemburg
eGenix.com

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

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


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

From solipsis at pitrou.net  Mon Apr  7 17:50:16 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 07 Apr 2008 17:50:16 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <47FA3915.5060508@egenix.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>
	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>
	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>
	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>
	<1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>
	<bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>
	<1afaf6160804060545h907dde6vaef52fd387ad96ff@mail.gmail.com>
	<bbaeab100804060856m6ce1e6a5nb3042a6e66c2cc23@mail.gmail.com>
	<1afaf6160804060928l7b8e770fo5029da56f8752c1b@mail.gmail.com>
	<1afaf6160804060942r82442afoff02f0e70407c53b@mail.gmail.com>
	<47FA3915.5060508@egenix.com>
Message-ID: <1207583416.8516.3.camel@fsol>


Le lundi 07 avril 2008 ? 17:09 +0200, M.-A. Lemburg a ?crit :
> Introducing a new long name "interpreter" doesn't really help
> with resolving the problems you state in the rational and neither
> does putting APIs from both groups into that new module :-)

FWIW, I agree with the naming suggestion. "import cpython" makes things
explicit.




From christian at cheimes.de  Mon Apr  7 17:52:51 2008
From: christian at cheimes.de (Christian Heimes)
Date: Mon, 07 Apr 2008 17:52:51 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <1207583416.8516.3.camel@fsol>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>	<1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>	<bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>	<1afaf6160804060545h907dde6vaef52fd387ad96ff@mail.gmail.com>	<bbaeab100804060856m6ce1e6a5nb3042a6e66c2cc23@mail.gmail.com>	<1afaf6160804060928l7b8e770fo5029da56f8752c1b@mail.gmail.com>	<1afaf6160804060942r82442afoff02f0e70407c53b@mail.gmail.com>	<47FA3915.5060508@egenix.com>
	<1207583416.8516.3.camel@fsol>
Message-ID: <47FA4353.4090204@cheimes.de>

Antoine Pitrou schrieb:
> Le lundi 07 avril 2008 ? 17:09 +0200, M.-A. Lemburg a ?crit :
>> Introducing a new long name "interpreter" doesn't really help
>> with resolving the problems you state in the rational and neither
>> does putting APIs from both groups into that new module :-)
> 
> FWIW, I agree with the naming suggestion. "import cpython" makes things
> explicit.

Yeah, +1 for the name. Explicit is better than implicit.

Christian

From musiccomposition at gmail.com  Mon Apr  7 22:36:56 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Mon, 7 Apr 2008 15:36:56 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <47FA4353.4090204@cheimes.de>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>
	<bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>
	<1afaf6160804060545h907dde6vaef52fd387ad96ff@mail.gmail.com>
	<bbaeab100804060856m6ce1e6a5nb3042a6e66c2cc23@mail.gmail.com>
	<1afaf6160804060928l7b8e770fo5029da56f8752c1b@mail.gmail.com>
	<1afaf6160804060942r82442afoff02f0e70407c53b@mail.gmail.com>
	<47FA3915.5060508@egenix.com> <1207583416.8516.3.camel@fsol>
	<47FA4353.4090204@cheimes.de>
Message-ID: <1afaf6160804071336t4709d14fj138f2477c4618eaa@mail.gmail.com>

On Mon, Apr 7, 2008 at 10:52 AM, Christian Heimes <christian at cheimes.de>
wrote:

> Antoine Pitrou schrieb:
> > Le lundi 07 avril 2008 ? 17:09 +0200, M.-A. Lemburg a ?crit :
> >> Introducing a new long name "interpreter" doesn't really help
> >> with resolving the problems you state in the rational and neither
> >> does putting APIs from both groups into that new module :-)
> >
> > FWIW, I agree with the naming suggestion. "import cpython" makes things
> > explicit.
>
> Yeah, +1 for the name. Explicit is better than implicit.

Ok! reposting relevant portions:

Specification
=============

A new builtin module named "interpreter" (see `Naming`_) will be added.

The second list of items above will be split into the stdlib as follows:

The interpreter module
    - get/setrecursionlimit
    - get/setcheckinterval
    - _getframe and _current_frame
    - get/setdlopenflags
    - settscdumps
    - api_version
    - winver
    - dllhandle
    - float_info
    - _clear_type_cache
    - subversion
    - builtin_module_names
    - callstats
    - intern

The gc module:
    - getrefcount
    - _compact_freelists


Naming
------

The author proposes the name "interpreter" for the new module.  "pyvm"
has also been suggested [#pyvm-name]_.  The name "cpython" was also
well liked [#cpython-name]_.


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



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080407/bb6e5016/attachment.htm 

From cfbolz at gmx.de  Mon Apr  7 22:41:50 2008
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 07 Apr 2008 22:41:50 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <47FA3915.5060508@egenix.com>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>	<1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>	<bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>	<1afaf6160804060545h907dde6vaef52fd387ad96ff@mail.gmail.com>	<bbaeab100804060856m6ce1e6a5nb3042a6e66c2cc23@mail.gmail.com>	<1afaf6160804060928l7b8e770fo5029da56f8752c1b@mail.gmail.com>	<1afaf6160804060942r82442afoff02f0e70407c53b@mail.gmail.com>
	<47FA3915.5060508@egenix.com>
Message-ID: <47FA870E.1050102@gmx.de>

M.-A. Lemburg wrote:
> Some comments:
> 
> The rational groups the function in two groups and this grouping
> makes a lot of sense.
> 
> However, your proposal later on doesn't use this rational in any
> way.
> 
> IMHO, it would be better to keep a "sys" module that exposes everything
> you have in group 1 and an implementation specific module "cpython"
> that exposes everything you have in group 2.
> 
> If an applications needs CPython specific features it would then
> import cpython. This would make things easy to see in the source
> code and also raise an exception on platforms where this module
> is not available, e.g. Jython. The same could be done for
> other Python implementations, e.g. have a "jython" module for
> Jython specific things, "ironpython" for IronPython, etc.

I think the idea is nice, but PyPy couldn't really expose a "pypy"
module, since that is the namespace the implementation itself is living
in. Maybe add a suffix to the implementation name? cpython_vm or so.

Cheers,

Carl Friedrich Bolz


From musiccomposition at gmail.com  Mon Apr  7 23:04:19 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Mon, 7 Apr 2008 16:04:19 -0500
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <47FA870E.1050102@gmx.de>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>
	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>
	<1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>
	<bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>
	<1afaf6160804060545h907dde6vaef52fd387ad96ff@mail.gmail.com>
	<bbaeab100804060856m6ce1e6a5nb3042a6e66c2cc23@mail.gmail.com>
	<1afaf6160804060928l7b8e770fo5029da56f8752c1b@mail.gmail.com>
	<1afaf6160804060942r82442afoff02f0e70407c53b@mail.gmail.com>
	<47FA3915.5060508@egenix.com> <47FA870E.1050102@gmx.de>
Message-ID: <1afaf6160804071404u37e0e90bn7d9de3f1ad917a31@mail.gmail.com>

On Mon, Apr 7, 2008 at 3:41 PM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:

> M.-A. Lemburg wrote:
> > Some comments:
> >
> > The rational groups the function in two groups and this grouping
> > makes a lot of sense.
> >
> > However, your proposal later on doesn't use this rational in any
> > way.
> >
> > IMHO, it would be better to keep a "sys" module that exposes everything
> > you have in group 1 and an implementation specific module "cpython"
> > that exposes everything you have in group 2.
> >
> > If an applications needs CPython specific features it would then
> > import cpython. This would make things easy to see in the source
> > code and also raise an exception on platforms where this module
> > is not available, e.g. Jython. The same could be done for
> > other Python implementations, e.g. have a "jython" module for
> > Jython specific things, "ironpython" for IronPython, etc.
>
> I think the idea is nice, but PyPy couldn't really expose a "pypy"
> module, since that is the namespace the implementation itself is living
> in. Maybe add a suffix to the implementation name? cpython_vm or so.

You can name your implementation specific module anything you want. We're
not forcing anybody else to use our naming scheme! :)

>
>
> Cheers,
>
> Carl Friedrich Bolz
>
>


-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080407/5df8b1e1/attachment.htm 

From jimjjewett at gmail.com  Tue Apr  8 19:42:50 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 8 Apr 2008 13:42:50 -0400
Subject: [stdlib-sig] pypy_vm (was: Proposal: new "interpreter" module)
Message-ID: <fb6fbf560804081042r1beab927jd2f4b078ab2796b1@mail.gmail.com>

"Benjamin Peterson" <musiccomposition at gmail.com> wrote:
>  On Mon, Apr 7, 2008 at 3:41 PM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:

>  > I think the idea is nice, but PyPy couldn't really expose a "pypy"
>  > module, since that is the namespace the implementation itself is living
>  > in. Maybe add a suffix to the implementation name? cpython_vm or so.

>  You can name your implementation specific module anything you want. We're
>  not forcing anybody else to use our naming scheme! :)

Yes and no.

If important information is in the interpreter-specific location, it
would be nice to know where that is.  That could be a specific module
name, but a module-name-pattern might be enough.

    sys.interpreter=cpython (or pypy_js_43, or whatever is chosen)
  <==>
    cpython_vm (or pypy_js_43_vm) is the module for internals


Also note that even the interpreter-specific modules will probably be
somewhat related.  Just because something is implementation-defined
doesn't mean prevent implementations from making similar choices.

For example, even if Jython chooses to limit recursion only through
memory exhaustion, some pypy targets might use exactly the same limits
as standard CPython -- in which case, the obvious names for them to
use will match CPython.

-jJ

From solipsis at pitrou.net  Tue Apr  8 20:06:19 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 08 Apr 2008 20:06:19 +0200
Subject: [stdlib-sig] pypy_vm (was: Proposal: new "interpreter" module)
In-Reply-To: <fb6fbf560804081042r1beab927jd2f4b078ab2796b1@mail.gmail.com>
References: <fb6fbf560804081042r1beab927jd2f4b078ab2796b1@mail.gmail.com>
Message-ID: <1207677979.5803.5.camel@fsol>

Le mardi 08 avril 2008 ? 13:42 -0400, Jim Jewett a ?crit :
> If important information is in the interpreter-specific location, it
> would be nice to know where that is.  That could be a specific module
> name, but a module-name-pattern might be enough.
> 
>     sys.interpreter=cpython (or pypy_js_43, or whatever is chosen)
>   <==>
>     cpython_vm (or pypy_js_43_vm) is the module for internals

Then why not:
sys.interpreter_module = cpython
	<=>  cpython
?sys.interpreter_module = pypy_vm
	<=>  pypy_vm
?sys.interpreter_module = org.baked.beans.jython
	<=>  ?org.?baked.beans.jython :)

ie. those targets which choose to use a "_vm" suffix make it explicit
rather than imposing that naming upon everyone ?

> Also note that even the interpreter-specific modules will probably be
> somewhat related.  Just because something is implementation-defined
> doesn't mean prevent implementations from making similar choices.

I think that's the real problem here, but there is no simple scheme that
will allow us to solve it.




From mal at egenix.com  Tue Apr  8 21:52:34 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 08 Apr 2008 21:52:34 +0200
Subject: [stdlib-sig] Proposal: new "interpreter" module
In-Reply-To: <47FA870E.1050102@gmx.de>
References: <1afaf6160804031107y3e43cf71sfe857af16058ce36@mail.gmail.com>	<1afaf6160804050758v34dc17a4m6e61344a1288c0bb@mail.gmail.com>	<bbaeab100804050837i3878b963i49521d9cc999db76@mail.gmail.com>	<1afaf6160804050913k4efe75d9n477b8135dbe84b2e@mail.gmail.com>	<bbaeab100804051404l69b6c5d5pf791698ca8494647@mail.gmail.com>	<1afaf6160804051411t7fdf000bxe33bdc4dee03f0aa@mail.gmail.com>	<bbaeab100804060109h6a46bcedk48e97706b10f5702@mail.gmail.com>	<1afaf6160804060545h907dde6vaef52fd387ad96ff@mail.gmail.com>	<bbaeab100804060856m6ce1e6a5nb3042a6e66c2cc23@mail.gmail.com>	<1afaf6160804060928l7b8e770fo5029da56f8752c1b@mail.gmail.com>	<1afaf6160804060942r82442afoff02f0e70407c53b@mail.gmail.com>	<47FA3915.5060508@egenix.com>
	<47FA870E.1050102@gmx.de>
Message-ID: <47FBCD02.1020805@egenix.com>

On 2008-04-07 22:41, Carl Friedrich Bolz wrote:
> M.-A. Lemburg wrote:
>> Some comments:
>>
>> The rational groups the function in two groups and this grouping
>> makes a lot of sense.
>>
>> However, your proposal later on doesn't use this rational in any
>> way.
>>
>> IMHO, it would be better to keep a "sys" module that exposes everything
>> you have in group 1 and an implementation specific module "cpython"
>> that exposes everything you have in group 2.
>>
>> If an applications needs CPython specific features it would then
>> import cpython. This would make things easy to see in the source
>> code and also raise an exception on platforms where this module
>> is not available, e.g. Jython. The same could be done for
>> other Python implementations, e.g. have a "jython" module for
>> Jython specific things, "ironpython" for IronPython, etc.
> 
> I think the idea is nice, but PyPy couldn't really expose a "pypy"
> module, since that is the namespace the implementation itself is living
> in. Maybe add a suffix to the implementation name? cpython_vm or so.

Actually, that's not really a problem ... the pypy package
will already expose all the PyPy specific APIs. Looks like
a time-machine was at work ;-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 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  Tue Apr  8 21:58:22 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 08 Apr 2008 21:58:22 +0200
Subject: [stdlib-sig] pypy_vm (was: Proposal: new "interpreter" module)
In-Reply-To: <1207677979.5803.5.camel@fsol>
References: <fb6fbf560804081042r1beab927jd2f4b078ab2796b1@mail.gmail.com>
	<1207677979.5803.5.camel@fsol>
Message-ID: <47FBCE5E.3010900@egenix.com>

On 2008-04-08 20:06, Antoine Pitrou wrote:
> Le mardi 08 avril 2008 ? 13:42 -0400, Jim Jewett a ?crit :
>> If important information is in the interpreter-specific location, it
>> would be nice to know where that is.  That could be a specific module
>> name, but a module-name-pattern might be enough.
>>
>>     sys.interpreter=cpython (or pypy_js_43, or whatever is chosen)
>>   <==>
>>     cpython_vm (or pypy_js_43_vm) is the module for internals
> 
> Then why not:
> sys.interpreter_module = cpython
> 	<=>  cpython
> ?sys.interpreter_module = pypy_vm
> 	<=>  pypy_vm
> ?sys.interpreter_module = org.baked.beans.jython
> 	<=>  ?org.?baked.beans.jython :)
> 
> ie. those targets which choose to use a "_vm" suffix make it explicit
> rather than imposing that naming upon everyone ?

We already have a way to identify the Python implementation and
it works for CPython, IronPython and Jython:

 >>> import platform
 >>> platform.python_implementation()
'CPython'

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 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 jimjjewett at gmail.com  Wed Apr  9 20:43:13 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Wed, 9 Apr 2008 14:43:13 -0400
Subject: [stdlib-sig] platform as part of sys (was pypy_vm)
Message-ID: <fb6fbf560804091143u618dfb1mc9bc12132a83352a@mail.gmail.com>

"M.-A. Lemburg" <mal at egenix.com> wrote:
>  > Le mardi 08 avril 2008 ? 13:42 -0400, Jim Jewett a ?crit :
>  >> If important information is in the interpreter-specific location, it
>  >> would be nice to know where that is.  That could be a specific module
>  >> name, but a module-name-pattern might be enough.

...

>  We already have a way to identify the Python implementation and
>  it works for CPython, IronPython and Jython:

>   >>> import platform
>   >>> platform.python_implementation()
>  'CPython'

Great, assuming that the capitalization is still OK for a module name.

But looking through platform convinced me that it really ought be part
of the sys reorg.  And it provides at least one pattern for dealing
with stuff that doesn't make sense in some interpreter environments.

For example, platform.dist() is defined as returning which *Linux*
distribution is used.  So on windows, the tuple contains empty
strings.  (Though I'm not sure why the libc_ver is also returning
blanks.)

-jJ

From mal at egenix.com  Wed Apr  9 20:58:41 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 09 Apr 2008 20:58:41 +0200
Subject: [stdlib-sig] platform as part of sys (was pypy_vm)
In-Reply-To: <fb6fbf560804091143u618dfb1mc9bc12132a83352a@mail.gmail.com>
References: <fb6fbf560804091143u618dfb1mc9bc12132a83352a@mail.gmail.com>
Message-ID: <47FD11E1.2090108@egenix.com>

On 2008-04-09 20:43, Jim Jewett wrote:
> "M.-A. Lemburg" <mal at egenix.com> wrote:
>>  > Le mardi 08 avril 2008 ? 13:42 -0400, Jim Jewett a ?crit :
>>  >> If important information is in the interpreter-specific location, it
>>  >> would be nice to know where that is.  That could be a specific module
>>  >> name, but a module-name-pattern might be enough.
> 
> ...
> 
>>  We already have a way to identify the Python implementation and
>>  it works for CPython, IronPython and Jython:
> 
>>   >>> import platform
>>   >>> platform.python_implementation()
>>  'CPython'
> 
> Great, assuming that the capitalization is still OK for a module name.

Just apply .lower() if needed. I don't particularly go for the
all_lower_case_use_underscores style module names.

> But looking through platform convinced me that it really ought be part
> of the sys reorg.  And it provides at least one pattern for dealing
> with stuff that doesn't make sense in some interpreter environments.

Whether some of the APIs make sense depends, well, on the platform
you're running on :-)

> For example, platform.dist() is defined as returning which *Linux*
> distribution is used.  So on windows, the tuple contains empty
> strings.  (Though I'm not sure why the libc_ver is also returning
> blanks.)

platform.dist() is an old API. The method to use is
platform.linux_distribution().

Most of the APIs allow passing in default values for the
case where the module cannot determine the correct values.
Most, if not all settings default to empty string, so that
it's easy to detect whether there was a problem or not.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 09 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 Apr 10 22:55:29 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 10 Apr 2008 22:55:29 +0200
Subject: [stdlib-sig] Py3K bsddb name query
In-Reply-To: <200803260715.53293.mark@qtrac.eu>
References: <200803260715.53293.mark@qtrac.eu>
Message-ID: <bbaeab100804101355r1c52fe68q28faddce3d768ee5@mail.gmail.com>

I went ahead and renamed dbm.db to dbm.bsd in the PEP.

-Brett

On Wed, Mar 26, 2008 at 12:15 AM, Mark Summerfield <mark at qtrac.eu> wrote:
> Hi,
>
>  I notice that in PEP 3108 the dbm modules are going to be in package
>  dbm:
>
>     New         Old
>     ----------- --------------------------------------------
>     dbm.tools   anydbm + whichdb
>     dbm.db      db.hash (actually bsd db so presumably using
>                 bsddb.hashopen() behind the scenes?)
>     dbm.ndbm    dbm
>     dbm.dumb    dumbdbm
>     dbm.gnu     gdbm
>
>  This leaves bsddb as a separate package. As far as I can tell bsddb is
>  not so different from the others. I presume (although the documentation
>  for bsddbobject.keys() denies it) that btopen() gives lexicographical
>  ordering and rnopen() give insertion order ordering by keys, whereas
>  hashopen() is unordered like a dict and like the other dbms provided.
>
>  In any case the name dbm.db seems wrong to me (too generic when the
>  others are specific to their dbm type), so at the least shouldn't dbm.db
>  be renamed dbm.bsd?
>
>  If consistency were wanted, dbm.bsd.open() could be a wrapper for
>  dbm.bsd.hashopen() but only with filenname, flag and mode arguments so
>  as to match the other dbms, and with dbm.bsd.hashopen(),
>  dbm.bsd.btopen() and dbm.bsd.rnopen() and the other bsddb-specific
>  functions available in the module as usual?
>
>  --
>  Mark Summerfield, Qtrac Ltd., www.qtrac.eu
>
>  _______________________________________________
>  stdlib-sig mailing list
>  stdlib-sig at python.org
>  http://mail.python.org/mailman/listinfo/stdlib-sig
>

From brett at python.org  Thu Apr 10 22:56:24 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 10 Apr 2008 22:56:24 +0200
Subject: [stdlib-sig] REMINDER: April 15th to get in module removal ideas
Message-ID: <bbaeab100804101356v3eff1cacs8f74ae672c14a7d8@mail.gmail.com>

This is just a friendly reminder that the list of modules/packages to
remove are due by April 15th.

-Brett

From brett at python.org  Thu Apr 10 23:03:25 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 10 Apr 2008 23:03:25 +0200
Subject: [stdlib-sig] Choosing a name for simplejson
Message-ID: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>

So simplejson is going to be added to the stdlib (this came down from
up high, which is why there has not been more of a discussion here).
That means we need to choose a name. Obviously 'json' would work, but
I am not sure if there is something better. Remember, we want simple
so that if someone goes, "I wonder if Python has a JSON module", they
can easily find it (which means no crazy package names).

We might also act as quality control on the source code to make sure
it is up to snuff based on PEP 8.

-Brett

From musiccomposition at gmail.com  Thu Apr 10 23:06:38 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Thu, 10 Apr 2008 16:06:38 -0500
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
Message-ID: <1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>

On Thu, Apr 10, 2008 at 4:03 PM, Brett Cannon <brett at python.org> wrote:
> So simplejson is going to be added to the stdlib (this came down from
>  up high, which is why there has not been more of a discussion here).
>  That means we need to choose a name. Obviously 'json' would work, but
>  I am not sure if there is something better. Remember, we want simple
>  so that if someone goes, "I wonder if Python has a JSON module", they
>  can easily find it (which means no crazy package names).
+1 for "json" or "jsonlib". Simple is better.
>
>  We might also act as quality control on the source code to make sure
>  it is up to snuff based on PEP 8.
I'll have a look.
>
>  -Brett
>  _______________________________________________
>  stdlib-sig mailing list
>  stdlib-sig at python.org
>  http://mail.python.org/mailman/listinfo/stdlib-sig
>



-- 
Cheers,
Benjamin Peterson

From p.f.moore at gmail.com  Thu Apr 10 23:09:33 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 10 Apr 2008 22:09:33 +0100
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>
Message-ID: <79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>

On 10/04/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
> On Thu, Apr 10, 2008 at 4:03 PM, Brett Cannon <brett at python.org> wrote:
>  > So simplejson is going to be added to the stdlib (this came down from
>  >  up high, which is why there has not been more of a discussion here).
>  >  That means we need to choose a name. Obviously 'json' would work, but
>  >  I am not sure if there is something better. Remember, we want simple
>  >  so that if someone goes, "I wonder if Python has a JSON module", they
>  >  can easily find it (which means no crazy package names).
>
> +1 for "json" or "jsonlib". Simple is better.

+1 for json. Let's not have yet another xxxlib format name...

Paul.

From mal at egenix.com  Thu Apr 10 23:31:22 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 10 Apr 2008 23:31:22 +0200
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>
	<79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>
Message-ID: <47FE872A.6070501@egenix.com>

On 2008-04-10 23:09, Paul Moore wrote:
> On 10/04/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
>> On Thu, Apr 10, 2008 at 4:03 PM, Brett Cannon <brett at python.org> wrote:
>>  > So simplejson is going to be added to the stdlib (this came down from
>>  >  up high, which is why there has not been more of a discussion here).
>>  >  That means we need to choose a name. Obviously 'json' would work, but
>>  >  I am not sure if there is something better. Remember, we want simple
>>  >  so that if someone goes, "I wonder if Python has a JSON module", they
>>  >  can easily find it (which means no crazy package names).
>>
>> +1 for "json" or "jsonlib". Simple is better.
> 
> +1 for json. Let's not have yet another xxxlib format name...

While that would be nice, I'm sure there a quite a few apps out there
that already ship their own little version of a JSON library using
that name. "jsonlib" already has an implementation:

http://pypi.python.org/pypi/jsonlib/

BTW: What's bad about "simplejson" ?

Oh, how I wished Python would finally get to use single package
name for its std lib and put everything else under that name, e.g. "py".
Then we could just name it "py.json" and be done with these issues
once and for all.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 10 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 Apr 10 23:52:10 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 10 Apr 2008 14:52:10 -0700
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <47FE872A.6070501@egenix.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>
	<79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>
	<47FE872A.6070501@egenix.com>
Message-ID: <bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>

On Thu, Apr 10, 2008 at 2:31 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>
> On 2008-04-10 23:09, Paul Moore wrote:
>  > On 10/04/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
>  >> On Thu, Apr 10, 2008 at 4:03 PM, Brett Cannon <brett at python.org> wrote:
>  >>  > So simplejson is going to be added to the stdlib (this came down from
>  >>  >  up high, which is why there has not been more of a discussion here).
>  >>  >  That means we need to choose a name. Obviously 'json' would work, but
>  >>  >  I am not sure if there is something better. Remember, we want simple
>  >>  >  so that if someone goes, "I wonder if Python has a JSON module", they
>  >>  >  can easily find it (which means no crazy package names).
>  >>
>  >> +1 for "json" or "jsonlib". Simple is better.
>  >
>  > +1 for json. Let's not have yet another xxxlib format name...
>
>  While that would be nice, I'm sure there a quite a few apps out there
>  that already ship their own little version of a JSON library using
>  that name. "jsonlib" already has an implementation:
>
>  http://pypi.python.org/pypi/jsonlib/
>
>  BTW: What's bad about "simplejson" ?
>

Longer than it needs to be.

>  Oh, how I wished Python would finally get to use single package
>  name for its std lib and put everything else under that name, e.g. "py".
>  Then we could just name it "py.json" and be done with these issues
>  once and for all.

If you want to convince Guido to allow this then that's fine; I'm +0
on the idea myself.

-Brett

From jmillikin at gmail.com  Fri Apr 11 04:27:41 2008
From: jmillikin at gmail.com (John Millikin)
Date: Thu, 10 Apr 2008 19:27:41 -0700
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
Message-ID: <3283f7fe0804101927p77f3f775t1c0c82f6da30cef@mail.gmail.com>

On Thu, Apr 10, 2008 at 2:03 PM, Brett Cannon <brett at python.org> wrote:
> So simplejson is going to be added to the stdlib (this came down from
>  up high, which is why there has not been more of a discussion here).
Do you have a link for this? Last I knew, discussion on which JSON
library to include were still ongoing in python-web-sig.

From jmillikin at gmail.com  Fri Apr 11 07:16:40 2008
From: jmillikin at gmail.com (John Millikin)
Date: Thu, 10 Apr 2008 22:16:40 -0700
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <75AC3673-FF84-4CE7-B9B9-ACA1137925D8@gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<3283f7fe0804101927p77f3f775t1c0c82f6da30cef@mail.gmail.com>
	<75AC3673-FF84-4CE7-B9B9-ACA1137925D8@gmail.com>
Message-ID: <3283f7fe0804102216q1a94ebebr160b75ef4d415764@mail.gmail.com>

On Thu, Apr 10, 2008 at 7:47 PM, Brett C. <bcannon at gmail.com> wrote:
> No link; personal email. Key members of python-dev trump the SIG. =)
>
Very well. Here's an archive of my stdlib-inclusion branch for
jsonlib, with implementations for Python 2.6 and 3.0. If you can,
please include its unit tests and encoding autodetection into whatever
version of simplejson you're working on. Not all of the tests will be
useful, since some test error checking, but most should be applicable.

From jmillikin at gmail.com  Fri Apr 11 07:21:40 2008
From: jmillikin at gmail.com (John Millikin)
Date: Thu, 10 Apr 2008 22:21:40 -0700
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <3283f7fe0804102216q1a94ebebr160b75ef4d415764@mail.gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<3283f7fe0804101927p77f3f775t1c0c82f6da30cef@mail.gmail.com>
	<75AC3673-FF84-4CE7-B9B9-ACA1137925D8@gmail.com>
	<3283f7fe0804102216q1a94ebebr160b75ef4d415764@mail.gmail.com>
Message-ID: <3283f7fe0804102221h4aeb4d05nfe495ae27e9c2db5@mail.gmail.com>

On Thu, Apr 10, 2008 at 10:16 PM, John Millikin <jmillikin at gmail.com> wrote:
> On Thu, Apr 10, 2008 at 7:47 PM, Brett C. <bcannon at gmail.com> wrote:
>  > No link; personal email. Key members of python-dev trump the SIG. =)
>  >
>  Very well. Here's an archive of my stdlib-inclusion branch for
>  jsonlib, with implementations for Python 2.6 and 3.0. If you can,
>  please include its unit tests and encoding autodetection into whatever
>  version of simplejson you're working on. Not all of the tests will be
>  useful, since some test error checking, but most should be applicable.
>

Apparently the mailing list doesn't care for attachments, so the
mentioned archive has been uploaded to
<http://jmillikin.googlepages.com/jsonlib-stdlib.zip>.

From qgallet at gmail.com  Fri Apr 11 08:33:42 2008
From: qgallet at gmail.com (Quentin Gallet-Gilles)
Date: Fri, 11 Apr 2008 04:33:42 -0200
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>
	<79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>
Message-ID: <8b943f2b0804102333u7bdf844et45987d82ba67fe7a@mail.gmail.com>

On Thu, Apr 10, 2008 at 7:09 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 10/04/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
> > On Thu, Apr 10, 2008 at 4:03 PM, Brett Cannon <brett at python.org> wrote:
> >  > So simplejson is going to be added to the stdlib (this came down from
> >  >  up high, which is why there has not been more of a discussion here).
> >  >  That means we need to choose a name. Obviously 'json' would work,
> but
> >  >  I am not sure if there is something better. Remember, we want simple
> >  >  so that if someone goes, "I wonder if Python has a JSON module",
> they
> >  >  can easily find it (which means no crazy package names).
> >
> > +1 for "json" or "jsonlib". Simple is better.
>
> +1 for json. Let's not have yet another xxxlib format name...
>

+1 for json as well. I agree the lib suffix should be avoided whenever
possible.


>
> Paul.
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080411/a29a43a7/attachment-0001.htm 

From christian at cheimes.de  Fri Apr 11 11:50:04 2008
From: christian at cheimes.de (Christian Heimes)
Date: Fri, 11 Apr 2008 11:50:04 +0200
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>
Message-ID: <47FF344C.1000008@cheimes.de>

Benjamin Peterson schrieb:
> +1 for "json" or "jsonlib". Simple is better.

+1 for json, -0 for jsonlib.

Christian

From mal at egenix.com  Fri Apr 11 11:51:13 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 11 Apr 2008 11:51:13 +0200
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>	<79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>	<47FE872A.6070501@egenix.com>
	<bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>
Message-ID: <47FF3491.1090103@egenix.com>

On 2008-04-10 23:52, Brett Cannon wrote:
> On Thu, Apr 10, 2008 at 2:31 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> On 2008-04-10 23:09, Paul Moore wrote:
>>  > On 10/04/2008, Benjamin Peterson <musiccomposition at gmail.com> wrote:
>>  >> On Thu, Apr 10, 2008 at 4:03 PM, Brett Cannon <brett at python.org> wrote:
>>  >>  > So simplejson is going to be added to the stdlib (this came down from
>>  >>  >  up high, which is why there has not been more of a discussion here).
>>  >>  >  That means we need to choose a name. Obviously 'json' would work, but
>>  >>  >  I am not sure if there is something better. Remember, we want simple
>>  >>  >  so that if someone goes, "I wonder if Python has a JSON module", they
>>  >>  >  can easily find it (which means no crazy package names).
>>  >>
>>  >> +1 for "json" or "jsonlib". Simple is better.
>>  >
>>  > +1 for json. Let's not have yet another xxxlib format name...
>>
>>  While that would be nice, I'm sure there a quite a few apps out there
>>  that already ship their own little version of a JSON library using
>>  that name. "jsonlib" already has an implementation:
>>
>>  http://pypi.python.org/pypi/jsonlib/
>>
>>  BTW: What's bad about "simplejson" ?
> 
> Longer than it needs to be.
> 
>>  Oh, how I wished Python would finally get to use single package
>>  name for its std lib and put everything else under that name, e.g. "py".
>>  Then we could just name it "py.json" and be done with these issues
>>  once and for all.
> 
> If you want to convince Guido to allow this then that's fine; I'm +0
> on the idea myself.

In my experience, Guido has shown that he doesn't get convinced by
someone pointing him at a problem - he has to run into the problem
himself.

Now, Python is a community project and its user set is very diverse,
so I'd like to see what the community thinks. If there's a tie, Guido
can break it, but I don't really see why he should be the only one
who's being asked.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 11 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 christian at cheimes.de  Fri Apr 11 11:56:10 2008
From: christian at cheimes.de (Christian Heimes)
Date: Fri, 11 Apr 2008 11:56:10 +0200
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <47FF3491.1090103@egenix.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>	<79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>	<47FE872A.6070501@egenix.com>	<bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>
	<47FF3491.1090103@egenix.com>
Message-ID: <47FF35BA.8050205@cheimes.de>

M.-A. Lemburg schrieb:
> In my experience, Guido has shown that he doesn't get convinced by
> someone pointing him at a problem - he has to run into the problem
> himself.
> 
> Now, Python is a community project and its user set is very diverse,
> so I'd like to see what the community thinks. If there's a tie, Guido
> can break it, but I don't really see why he should be the only one
> who's being asked.

We had the discussion on the Python general list a while ago. Guido and
several other developers were against Java-like namespace packages for
the stdlib.

Christian



From mal at egenix.com  Fri Apr 11 12:13:32 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 11 Apr 2008 12:13:32 +0200
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <47FF35BA.8050205@cheimes.de>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>	<79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>	<47FE872A.6070501@egenix.com>	<bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>	<47FF3491.1090103@egenix.com>
	<47FF35BA.8050205@cheimes.de>
Message-ID: <47FF39CC.7040608@egenix.com>

On 2008-04-11 11:56, Christian Heimes wrote:
> M.-A. Lemburg schrieb:
>> In my experience, Guido has shown that he doesn't get convinced by
>> someone pointing him at a problem - he has to run into the problem
>> himself.
>>
>> Now, Python is a community project and its user set is very diverse,
>> so I'd like to see what the community thinks. If there's a tie, Guido
>> can break it, but I don't really see why he should be the only one
>> who's being asked.
> 
> We had the discussion on the Python general list a while ago. Guido and
> several other developers were against Java-like namespace packages for
> the stdlib.

We've had such discussions on and off several times during the past
8-10 years. So far, the only arguments against moving the whole
Python std lib under a single package (without deeper nesting)
were the following:

  * too much to write

  * hard to change all the code out there

Now that we're going for a transition from 2.x to 3.x, the
second argument no longer applies. 2to3.py can easily change
the imports as necessary (just like it will for the stdlib
reorg in general).

The first argument is not really a strong one, but more a personal
preference. Using a Python package will make it easier for IDEs
to provide auto-complete, so over time

On the plus side, we would finally have the freedom to choose
any generic name we like for Python modules - without causing
problems with existing code outside the std lib, e.g. all
the *lib modules could have the "lib" removed.

And you can finally see whether a module came from the
Python std lib or some other source right in the source
file. Accidental sys.path overrides will no longer happen.

If I've missed any arguments against the py-package idea,
please let me know.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 11 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 p.f.moore at gmail.com  Fri Apr 11 12:42:04 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 11 Apr 2008 11:42:04 +0100
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <47FF39CC.7040608@egenix.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>
	<79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>
	<47FE872A.6070501@egenix.com>
	<bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>
	<47FF3491.1090103@egenix.com> <47FF35BA.8050205@cheimes.de>
	<47FF39CC.7040608@egenix.com>
Message-ID: <79990c6b0804110342s10ce0ae6v6f3ba1f3d1aff7d5@mail.gmail.com>

On 11/04/2008, M.-A. Lemburg <mal at egenix.com> wrote:
> If I've missed any arguments against the py-package idea,
> please let me know.

Nobody has the energy or enthusiasm to push it - write a PEP, create a
2to3 fixer, propose specific renames (ftplib -> py.ftp for example),
gather opinions, summarise arguments, convince Guido, etc etc.

That's the killer.

Paul.

From santagada at gmail.com  Fri Apr 11 13:19:52 2008
From: santagada at gmail.com (Leonardo Santagada)
Date: Fri, 11 Apr 2008 08:19:52 -0300
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <79990c6b0804110342s10ce0ae6v6f3ba1f3d1aff7d5@mail.gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>
	<79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>
	<47FE872A.6070501@egenix.com>
	<bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>
	<47FF3491.1090103@egenix.com> <47FF35BA.8050205@cheimes.de>
	<47FF39CC.7040608@egenix.com>
	<79990c6b0804110342s10ce0ae6v6f3ba1f3d1aff7d5@mail.gmail.com>
Message-ID: <E4EF6134-68CA-415B-9D90-75B5578B2ED6@gmail.com>


On 11/04/2008, at 07:42, Paul Moore wrote:
> On 11/04/2008, M.-A. Lemburg <mal at egenix.com> wrote:
>> If I've missed any arguments against the py-package idea,
>> please let me know.
>
> Nobody has the energy or enthusiasm to push it - write a PEP, create a
> 2to3 fixer, propose specific renames (ftplib -> py.ftp for example),
> gather opinions, summarise arguments, convince Guido, etc etc.

If you do that I think most people would be +1 or at least +0 on it.  
If you think about it it is just a "py." more.

But please take a look at http://codespeak.net/py/dist/misc.html#the-py-std-hook 
  if you are going to change that maybe this should go in also. Then  
you dont need import py.sys to just get py.sys.args in a simple script  
for example. And even in really big python project you get a lot of  
imports to just get one function that is going to be used once in the  
file.


--
Leonardo Santagada





From steven.bethard at gmail.com  Fri Apr 11 17:26:28 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Fri, 11 Apr 2008 09:26:28 -0600
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <E4EF6134-68CA-415B-9D90-75B5578B2ED6@gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>
	<79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>
	<47FE872A.6070501@egenix.com>
	<bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>
	<47FF3491.1090103@egenix.com> <47FF35BA.8050205@cheimes.de>
	<47FF39CC.7040608@egenix.com>
	<79990c6b0804110342s10ce0ae6v6f3ba1f3d1aff7d5@mail.gmail.com>
	<E4EF6134-68CA-415B-9D90-75B5578B2ED6@gmail.com>
Message-ID: <d11dcfba0804110826x72386709s23d050c4a403dc1d@mail.gmail.com>

On Fri, Apr 11, 2008 at 5:19 AM, Leonardo Santagada <santagada at gmail.com> wrote:
>
>  On 11/04/2008, at 07:42, Paul Moore wrote:
>  > On 11/04/2008, M.-A. Lemburg <mal at egenix.com> wrote:
>  >> If I've missed any arguments against the py-package idea,
>  >> please let me know.
>  >
>  > Nobody has the energy or enthusiasm to push it - write a PEP, create a
>  > 2to3 fixer, propose specific renames (ftplib -> py.ftp for example),
>  > gather opinions, summarise arguments, convince Guido, etc etc.
>
>  If you do that I think most people would be +1 or at least +0 on it.
>  If you think about it it is just a "py." more.
>
>  But please take a look at http://codespeak.net/py/dist/misc.html#the-py-std-hook
>   if you are going to change that maybe this should go in also.

If you really want a "py." prefix, then trying to add anything else to
the proposal is a bad idea. It's going to be an uphill battle as it
is. Changing semantics at the same time will almost certainly make
that battle impossible to win.

FWIW, -0 on the "py." prefix. I guess I'm in Guido's situation -- I
haven't ever personally run into the situation where I needed it. I've
never had the desire to name something similar to a stdlib module name
-- probably because at the point when I might, I realize that the
stdlib already has the module I want, named what I expected.

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
 --- Bucky Katt, Get Fuzzy

From solipsis at pitrou.net  Fri Apr 11 18:50:40 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 11 Apr 2008 18:50:40 +0200
Subject: [stdlib-sig] the "py" prefix
In-Reply-To: <d11dcfba0804110826x72386709s23d050c4a403dc1d@mail.gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>
	<79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>
	<47FE872A.6070501@egenix.com>
	<bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>
	<47FF3491.1090103@egenix.com> <47FF35BA.8050205@cheimes.de>
	<47FF39CC.7040608@egenix.com>
	<79990c6b0804110342s10ce0ae6v6f3ba1f3d1aff7d5@mail.gmail.com>
	<E4EF6134-68CA-415B-9D90-75B5578B2ED6@gmail.com>
	<d11dcfba0804110826x72386709s23d050c4a403dc1d@mail.gmail.com>
Message-ID: <1207932640.5820.5.camel@fsol>


With the stricter distinction between absolute and relative imports,
isn't all this discussion a bit obsolete ?

If you want to import the builtin "types" module:
	import types
If you want to import the local "types" module:
	from . import types

I don't see the need for a "py" prefix.



From brett at python.org  Fri Apr 11 20:41:23 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 11 Apr 2008 11:41:23 -0700
Subject: [stdlib-sig] the "py" prefix
In-Reply-To: <1207932640.5820.5.camel@fsol>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<47FE872A.6070501@egenix.com>
	<bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>
	<47FF3491.1090103@egenix.com> <47FF35BA.8050205@cheimes.de>
	<47FF39CC.7040608@egenix.com>
	<79990c6b0804110342s10ce0ae6v6f3ba1f3d1aff7d5@mail.gmail.com>
	<E4EF6134-68CA-415B-9D90-75B5578B2ED6@gmail.com>
	<d11dcfba0804110826x72386709s23d050c4a403dc1d@mail.gmail.com>
	<1207932640.5820.5.camel@fsol>
Message-ID: <bbaeab100804111141u4a71536cjee07fbf03cb3fc6@mail.gmail.com>

On Fri, Apr 11, 2008 at 9:50 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
>  With the stricter distinction between absolute and relative imports,
>  isn't all this discussion a bit obsolete ?
>
>  If you want to import the builtin "types" module:
>         import types
>  If you want to import the local "types" module:
>         from . import types
>
>  I don't see the need for a "py" prefix.

But what if you want to install a third-party library that is named
'types'? ``import types`` will import either from the stdlib or the
third-party library based on sys.path. The thinking for the top-level
'py' namespace is that this situation becomes (basically) impossible.

-Brett

From santagada at gmail.com  Fri Apr 11 20:41:50 2008
From: santagada at gmail.com (Leonardo Santagada)
Date: Fri, 11 Apr 2008 15:41:50 -0300
Subject: [stdlib-sig] Choosing a name for simplejson
In-Reply-To: <d11dcfba0804110826x72386709s23d050c4a403dc1d@mail.gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<1afaf6160804101406j489a996dtf8353ddc986afedd@mail.gmail.com>
	<79990c6b0804101409m3745ea0ew6f06dee1e8f4964b@mail.gmail.com>
	<47FE872A.6070501@egenix.com>
	<bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>
	<47FF3491.1090103@egenix.com> <47FF35BA.8050205@cheimes.de>
	<47FF39CC.7040608@egenix.com>
	<79990c6b0804110342s10ce0ae6v6f3ba1f3d1aff7d5@mail.gmail.com>
	<E4EF6134-68CA-415B-9D90-75B5578B2ED6@gmail.com>
	<d11dcfba0804110826x72386709s23d050c4a403dc1d@mail.gmail.com>
Message-ID: <C172C269-D0FA-46D0-B115-A6B19A39D0A2@gmail.com>


On 11/04/2008, at 12:26, Steven Bethard wrote:
> On Fri, Apr 11, 2008 at 5:19 AM, Leonardo Santagada <santagada at gmail.com 
> > wrote:
>> But please take a look at http://codespeak.net/py/dist/misc.html#the-py-std-hook
>>  if you are going to change that maybe this should go in also.
>
> If you really want a "py." prefix, then trying to add anything else to
> the proposal is a bad idea. It's going to be an uphill battle as it
> is. Changing semantics at the same time will almost certainly make
> that battle impossible to win.


Yes yes you are right sorry to propose that... But probably between  
the two I prefer the py.std hack than to have a "py." for the stdlib.

[]
--
Leonardo Santagada





From mal at egenix.com  Fri Apr 11 22:01:03 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 11 Apr 2008 22:01:03 +0200
Subject: [stdlib-sig] the "py" prefix
In-Reply-To: <bbaeab100804111141u4a71536cjee07fbf03cb3fc6@mail.gmail.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>	<47FE872A.6070501@egenix.com>	<bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>	<47FF3491.1090103@egenix.com>
	<47FF35BA.8050205@cheimes.de>	<47FF39CC.7040608@egenix.com>	<79990c6b0804110342s10ce0ae6v6f3ba1f3d1aff7d5@mail.gmail.com>	<E4EF6134-68CA-415B-9D90-75B5578B2ED6@gmail.com>	<d11dcfba0804110826x72386709s23d050c4a403dc1d@mail.gmail.com>	<1207932640.5820.5.camel@fsol>
	<bbaeab100804111141u4a71536cjee07fbf03cb3fc6@mail.gmail.com>
Message-ID: <47FFC37F.5090107@egenix.com>

On 2008-04-11 20:41, Brett Cannon wrote:
> On Fri, Apr 11, 2008 at 9:50 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>  With the stricter distinction between absolute and relative imports,
>>  isn't all this discussion a bit obsolete ?
>>
>>  If you want to import the builtin "types" module:
>>         import types
>>  If you want to import the local "types" module:
>>         from . import types
>>
>>  I don't see the need for a "py" prefix.
> 
> But what if you want to install a third-party library that is named
> 'types'? ``import types`` will import either from the stdlib or the
> third-party library based on sys.path. The thinking for the top-level
> 'py' namespace is that this situation becomes (basically) impossible.

Exactly.

The problem is not related to relative vs. absolute imports, it's
all about sys.path.

Detecting such situations gets even harder once you start to use
eggs, since they hide away the module names they use insider
their ZIP archives.

Also note that this is not so much a problem for the existing set
of std lib modules since 3rd party packages will of course try to
not conflict with these known names.

However, it becomes an issue as soon as new modules get added to
the std lib or existing ones are renamed.

In such a situation, you have the case that a conflicting module
will already be in use (possibly buried inside some egg on
sys.path) and changing all the code that relies on this
conflicting module will not necessarily be easy.

The "py." prefix would solve these issues once and for all.

Note that these situations are not made up. You can run into
such situations quite easily, e.g. if you run python in a
directory that happens to have a package called "test" with
an __init__.py in it, you suddenly cannot access the Python
stdlib test package anymore.

-- 
Marc-Andre Lemburg
eGenix.com

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

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


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

From solipsis at pitrou.net  Sat Apr 12 12:17:30 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 12 Apr 2008 12:17:30 +0200
Subject: [stdlib-sig] the "py" prefix
In-Reply-To: <47FFC37F.5090107@egenix.com>
References: <bbaeab100804101403s45950776p2c5d834d8e57e5a3@mail.gmail.com>
	<47FE872A.6070501@egenix.com>
	<bbaeab100804101452p2b53292eyc05fb665067bf68c@mail.gmail.com>
	<47FF3491.1090103@egenix.com> <47FF35BA.8050205@cheimes.de>
	<47FF39CC.7040608@egenix.com>
	<79990c6b0804110342s10ce0ae6v6f3ba1f3d1aff7d5@mail.gmail.com>
	<E4EF6134-68CA-415B-9D90-75B5578B2ED6@gmail.com>
	<d11dcfba0804110826x72386709s23d050c4a403dc1d@mail.gmail.com>
	<1207932640.5820.5.camel@fsol>
	<bbaeab100804111141u4a71536cjee07fbf03cb3fc6@mail.gmail.com>
	<47FFC37F.5090107@egenix.com>
Message-ID: <1207995450.5771.5.camel@fsol>

Le vendredi 11 avril 2008 ? 22:01 +0200, M.-A. Lemburg a ?crit :
> In such a situation, you have the case that a conflicting module
> will already be in use (possibly buried inside some egg on
> sys.path) and changing all the code that relies on this
> conflicting module will not necessarily be easy.

Ok, I understand. Sorry for the noise.

Regards

Antoine.



From musiccomposition at gmail.com  Sat Apr 12 18:42:46 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 12 Apr 2008 11:42:46 -0500
Subject: [stdlib-sig] renaming test_support
Message-ID: <1afaf6160804120942h33d4f6bnf297229abd8a13a6@mail.gmail.com>

Hi guys,
I saw in the stdlib-reorg PEP that test.test_support should be renamed
to just test.support. I've done at patch at issue 2621.

-- 
Cheers,
Benjamin Peterson

From brett at python.org  Fri Apr 18 01:40:15 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 17 Apr 2008 16:40:15 -0700
Subject: [stdlib-sig] Making the reorg work
Message-ID: <bbaeab100804171640q221a7d5wcd446b8dea1a2db@mail.gmail.com>

Now that April 15th has past, it's time to start thinking about how
best to handle the reorg. I have some ideas on how to make it all
work.

For 2.6, the modules should be renamed. The old names should be
maintained with stub modules that are kept in some directory, such as
lib-old. This separate directory is needed since some modules are only
changing their case and that will wreak havoc on case-insensitive file
systems. There should also be a Python 3.0 warning about the named
deprecation.

For 3.0, we need a fixer that deals with imports. Using the 'as'
keyword to prevent the code from needing to be changed in any way
would be best. There are probably some fixers already that deal with
import that might be available for tweaking to make it work for this
situation.

While we wait for Guido to pronounce on the PEP (probably late next
week) we can start discussing this and getting stuff lined up. I
personally don't know how much time I will have for this (dealing with
a relationship ending and having to move because of it) so any and all
help I can get for this will be appreciated.

-Brett

From musiccomposition at gmail.com  Fri Apr 18 03:26:58 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Thu, 17 Apr 2008 20:26:58 -0500
Subject: [stdlib-sig] Making the reorg work
In-Reply-To: <bbaeab100804171640q221a7d5wcd446b8dea1a2db@mail.gmail.com>
References: <bbaeab100804171640q221a7d5wcd446b8dea1a2db@mail.gmail.com>
Message-ID: <1afaf6160804171826k239dd2en1cffd8411db2b39@mail.gmail.com>

On Thu, Apr 17, 2008 at 6:40 PM, Brett Cannon <brett at python.org> wrote:
>  For 2.6, the modules should be renamed. The old names should be
>  maintained with stub modules that are kept in some directory, such as
>  lib-old. This separate directory is needed since some modules are only
>  changing their case and that will wreak havoc on case-insensitive file
>  systems. There should also be a Python 3.0 warning about the named
>  deprecation.
So, the following the workflow?
1. svn mv Lib/BadOldName.py Lib/badoldname.py (in trunk)
2. Fix imports in the stdlib and update the docs.
3. Commit and merge into 3.0.
4. (back in trunk) make a file that does a start import (modules with
__all__ will require some more work) in lib-old and gives a py3k
warning
5. Block that revision
>
>  While we wait for Guido to pronounce on the PEP (probably late next
>  week) we can start discussing this and getting stuff lined up. I
>  personally don't know how much time I will have for this (dealing with
>  a relationship ending and having to move because of it) so any and all
>  help I can get for this will be appreciated.
Your word is my command. :)



-- 
Cheers,
Benjamin Peterson

From brett at python.org  Fri Apr 18 03:30:03 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 17 Apr 2008 18:30:03 -0700
Subject: [stdlib-sig] Making the reorg work
In-Reply-To: <1afaf6160804171826k239dd2en1cffd8411db2b39@mail.gmail.com>
References: <bbaeab100804171640q221a7d5wcd446b8dea1a2db@mail.gmail.com>
	<1afaf6160804171826k239dd2en1cffd8411db2b39@mail.gmail.com>
Message-ID: <bbaeab100804171830i64f0309el1478e4ca5abc7cfd@mail.gmail.com>

On Thu, Apr 17, 2008 at 6:26 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> On Thu, Apr 17, 2008 at 6:40 PM, Brett Cannon <brett at python.org> wrote:
>  >  For 2.6, the modules should be renamed. The old names should be
>  >  maintained with stub modules that are kept in some directory, such as
>  >  lib-old. This separate directory is needed since some modules are only
>  >  changing their case and that will wreak havoc on case-insensitive file
>  >  systems. There should also be a Python 3.0 warning about the named
>  >  deprecation.
>  So, the following the workflow?
>  1. svn mv Lib/BadOldName.py Lib/badoldname.py (in trunk)

I think you meant for that to still lead to a good name. =)

>  2. Fix imports in the stdlib and update the docs.
>  3. Commit and merge into 3.0.
>  4. (back in trunk) make a file that does a start import (modules with
>  __all__ will require some more work) in lib-old and gives a py3k
>  warning
>  5. Block that revision

Sounds about right.

-Brett


>
> >
>  >  While we wait for Guido to pronounce on the PEP (probably late next
>  >  week) we can start discussing this and getting stuff lined up. I
>  >  personally don't know how much time I will have for this (dealing with
>  >  a relationship ending and having to move because of it) so any and all
>  >  help I can get for this will be appreciated.
>  Your word is my command. :)
>
>
>
>  --
>  Cheers,
>  Benjamin Peterson
>

From python at rcn.com  Fri Apr 18 03:48:37 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 17 Apr 2008 18:48:37 -0700
Subject: [stdlib-sig] Making the reorg work
References: <bbaeab100804171640q221a7d5wcd446b8dea1a2db@mail.gmail.com>
	<1afaf6160804171826k239dd2en1cffd8411db2b39@mail.gmail.com>
Message-ID: <001a01c8a0f6$53184e80$6800a8c0@RaymondLaptop1>

> So, the following the workflow?
> 1. svn mv Lib/BadOldName.py Lib/badoldname.py (in trunk)
> 2. Fix imports in the stdlib and update the docs.
> 3. Commit and merge into 3.0.
> 4. (back in trunk) make a file that does a start import (modules with
> __all__ will require some more work) in lib-old and gives a py3k
> warning
> 5. Block that revision

6. Make a 2-to-3 converter

From christian at cheimes.de  Sat Apr 19 00:28:11 2008
From: christian at cheimes.de (Christian Heimes)
Date: Sat, 19 Apr 2008 00:28:11 +0200
Subject: [stdlib-sig] Making the reorg work
In-Reply-To: <001a01c8a0f6$53184e80$6800a8c0@RaymondLaptop1>
References: <bbaeab100804171640q221a7d5wcd446b8dea1a2db@mail.gmail.com>	<1afaf6160804171826k239dd2en1cffd8411db2b39@mail.gmail.com>
	<001a01c8a0f6$53184e80$6800a8c0@RaymondLaptop1>
Message-ID: <4809207B.5060107@cheimes.de>

Raymond Hettinger schrieb:
> 6. Make a 2-to-3 converter

We don't need a new 2to3 fixer for every case. We need some generic
fixers that can handle all possible cases.

Christian

From syfou at users.sourceforge.net  Sat Apr 19 08:18:30 2008
From: syfou at users.sourceforge.net (Sylvain Fourmanoit)
Date: Sat, 19 Apr 2008 02:18:30 -0400 (EDT)
Subject: [stdlib-sig] textwrap module and hyphenation
Message-ID: <alpine.LNX.1.10.0804190014130.8762@Turing>

I just noticed the textwrap module in the standard library will break and 
line-wrap hyphenated words given the opportunity:

>>> from textwrap import wrap
>>> wrap('yaba daba-doo', width=10)
['yaba daba-', 'doo']

I have two questions about that:

1) Wouldn't it be worth mentioning this in the Python Library Reference
    (or it is just too obvious)?

2) Wouldn't it be useful to have a simple way to turn it off? Something
    like:

>>> from textwrap import wrap
>>> wrap('yaba daba-doo', width=10, break_hyphenated_words=False)
['yaba', 'daba-doo']

Since proper line-wrapping of hyphenated words is language-dependent and 
can interact with other orthographic and typesetting practices, I think it 
would be nicer to have a documented way to turn it off completely.

Granted, it's not hard to manually do either; on Python 2.5.2 (as well as 
on Python 2.6 r62386), it's just a matter of setting the 
"TextWrapper.wordsep_re" attribute to "re.compile('(\s+)')"...  I 
think having a publicly documented attribute wouldn't hurt anyway.

-- 
Sylvain <syfou at users.sourceforge.net>

The IBM 2250 is impressive ...
if you compare it with a system selling for a tenth its price.
 		-- D. Cohen

From brett at python.org  Sat Apr 19 09:08:58 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 19 Apr 2008 00:08:58 -0700
Subject: [stdlib-sig] textwrap module and hyphenation
In-Reply-To: <alpine.LNX.1.10.0804190014130.8762@Turing>
References: <alpine.LNX.1.10.0804190014130.8762@Turing>
Message-ID: <bbaeab100804190008h1f9e0a7eg8a12ef9ff764301@mail.gmail.com>

On Fri, Apr 18, 2008 at 11:18 PM, Sylvain Fourmanoit
<syfou at users.sourceforge.net> wrote:
> I just noticed the textwrap module in the standard library will break and
>  line-wrap hyphenated words given the opportunity:
>
>  >>> from textwrap import wrap
>  >>> wrap('yaba daba-doo', width=10)
>  ['yaba daba-', 'doo']
>
>  I have two questions about that:
>
>  1) Wouldn't it be worth mentioning this in the Python Library Reference
>     (or it is just too obvious)?
>

I think it is obvious, but patches against the docs mentioning this I
am sure would be welcome.

>  2) Wouldn't it be useful to have a simple way to turn it off? Something
>     like:
>
>  >>> from textwrap import wrap
>  >>> wrap('yaba daba-doo', width=10, break_hyphenated_words=False)
>  ['yaba', 'daba-doo']
>

I personally don't think so as you could easily just walk the list and
just concatenate the hyphenated words. So -0 from me.

And if you do try to pursue this, you might want to try to come up
with a shorter keyword argument name.

-Brett




>  Since proper line-wrapping of hyphenated words is language-dependent and
>  can interact with other orthographic and typesetting practices, I think it
>  would be nicer to have a documented way to turn it off completely.
>
>  Granted, it's not hard to manually do either; on Python 2.5.2 (as well as
>  on Python 2.6 r62386), it's just a matter of setting the
>  "TextWrapper.wordsep_re" attribute to "re.compile('(\s+)')"...  I
>  think having a publicly documented attribute wouldn't hurt anyway.
>
>  --
>  Sylvain <syfou at users.sourceforge.net>
>
>  The IBM 2250 is impressive ...
>  if you compare it with a system selling for a tenth its price.
>                 -- D. Cohen
>  _______________________________________________
>  stdlib-sig mailing list
>  stdlib-sig at python.org
>  http://mail.python.org/mailman/listinfo/stdlib-sig
>

From musiccomposition at gmail.com  Sat Apr 19 21:16:28 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Sat, 19 Apr 2008 14:16:28 -0500
Subject: [stdlib-sig] Making the reorg work
In-Reply-To: <4809207B.5060107@cheimes.de>
References: <bbaeab100804171640q221a7d5wcd446b8dea1a2db@mail.gmail.com>
	<1afaf6160804171826k239dd2en1cffd8411db2b39@mail.gmail.com>
	<001a01c8a0f6$53184e80$6800a8c0@RaymondLaptop1>
	<4809207B.5060107@cheimes.de>
Message-ID: <1afaf6160804191216k31438547ydd28bbc66dc4799a@mail.gmail.com>

On Fri, Apr 18, 2008 at 5:28 PM, Christian Heimes <christian at cheimes.de> wrote:
> Raymond Hettinger schrieb:
>
> > 6. Make a 2-to-3 converter
>
>  We don't need a new 2to3 fixer for every case. We need some generic
>  fixers that can handle all possible cases.
Yep. It *looks* like you can just add it to fix_imports.py.
>
>  Christian
>



-- 
Cheers,
Benjamin Peterson

From solipsis at pitrou.net  Sat Apr 19 21:36:08 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 19 Apr 2008 21:36:08 +0200
Subject: [stdlib-sig] textwrap module and hyphenation
In-Reply-To: <bbaeab100804190008h1f9e0a7eg8a12ef9ff764301@mail.gmail.com>
References: <alpine.LNX.1.10.0804190014130.8762@Turing>
	<bbaeab100804190008h1f9e0a7eg8a12ef9ff764301@mail.gmail.com>
Message-ID: <1208633768.5876.16.camel@fsol>


Le samedi 19 avril 2008 ? 00:08 -0700, Brett Cannon a ?crit :
> On Fri, Apr 18, 2008 at 11:18 PM, Sylvain Fourmanoit
> <syfou at users.sourceforge.net> wrote:
> > I just noticed the textwrap module in the standard library will break and
> >  line-wrap hyphenated words given the opportunity:
> >
> >  >>> from textwrap import wrap
> >  >>> wrap('yaba daba-doo', width=10)
> >  ['yaba daba-', 'doo']

[...]

> I personally don't think so as you could easily just walk the list and
> just concatenate the hyphenated words.

But then the words wouldn't be wrapped properly, would they ?
In the above example, if you join the two strings together, the result
is more than 10 chars long.

I think this feature makes sense, and doesn't really clutter the API.
In the meantime, a workaround is to use other unicode hyphens (*) in
order to get the desired result, e.g.:

>>> print(" | ".join(textwrap.wrap('yaba daba-doo', width=10)))
yaba daba- | doo
?>>> print(" | ".join(textwrap.wrap('yaba daba\u2010doo', width=10)))
yaba | daba??doo


(*) http://www.fileformat.info/info/unicode/char/00ad/index.htm
http://www.fileformat.info/info/unicode/char/2010/index.htm




From brett at python.org  Tue Apr 29 04:30:48 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 28 Apr 2008 19:30:48 -0700
Subject: [stdlib-sig] PEP 3108 - stdlib reorg/cleanup
Message-ID: <bbaeab100804281930h598e5889k88fdb322dd5573a2@mail.gmail.com>

[bcc to stdlib-sig]

After two false starts over the YEARS of trying to cleanup and
reorganize the stdlib, creating a SIG to get this going, having Guido
give the PEP the once-over over the past several days, and creating
two new bugs reports (issues 2715 and 2716), PEP 3108 is finally ready
for public vetting!

While reading this PEP, do remember this is only about either removing
modules, renaming them, or moving them into a package. Additions are
not covered by this PEP!

Also realize all of the right people have been consulted on this stuff
(e.g., the web SIG about the urllib package). So please do not think
that something that seems drastic (e.g., the removal of all
Mac-specific modules) was taken lightly when in fact the proper people
were asked and they were okay with what is going on.

Lastly, I do not want this to turn into a drawn-out thread about how
people think some module should stay because they happen to use it or
suggest some other module to remove. Please think before you propose a
change. I have been through this proposal process for this reorg
before and every time it has gotten way out of control. I do not want
it happen this time.

OK, with all of that out of the way, here is the PEP:
-----------------------------------------------

PEP: 3108
Title: Standard Library Reorganization
Version: $Revision: 62573 $
Last-Modified: $Date: 2008-04-28 17:56:36 -0700 (Mon, 28 Apr 2008) $
Author: Brett Cannon <brett at python.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 01-Jan-2007
Python-Version: 3.0
Post-History:


Abstract
========

Just like the language itself, Python's standard library (stdlib) has
grown over the years to be very rich.  But over time some modules
have lost their need to be included with Python.  There has also been
an introduction of a naming convention for modules since Python's
inception that not all modules follow.

Python 3.0 has presented a chance to remove modules that do not have
long term usefulness.  This chance also allows for the renaming of
modules so that they follow the Python style guide [#pep-0008]_.  This
PEP lists modules that should not be included in Python 3.0 and what
modules need to be renamed.


Modules to Remove
=================

Guido pronounced that "silly old stuff" is to be deleted from the
stdlib for Py3K [#silly-old-stuff]_.  This is open-ended on purpose.
Each module to be removed needs to have a justification as to why it
should no longer be distributed with Python.  This can range from the
module being deprecated in Python 2.x to being for a platform that is
no longer widely used.

This section of the PEP lists the various modules to be removed. Each
subsection represents a different reason for modules to be
removed.  Each module must have a specific justification on top of
being listed in a specific subsection so as to make sure only modules
that truly deserve to be removed are in fact removed.

When a reason mentions how long it has been since a module has been
"uniquely edited", it is in reference to how long it has been since a
checkin was done specifically for the module and not for a change that
applied universally across the entire stdlib.  If an edit time is not
denoted as "unique" then it is the last time the file was edited,
period.

The procedure to thoroughly remove a module is:

#. Remove the module.
#. Remove the tests.
#. Edit ``Modules/Setup.dist`` and ``setup.py`` if needed.
#. Remove the docs (if applicable).
#. Run the regression test suite (using ``-uall``); watch out for
   tests that are skipped because an import failed for the removed
   module.

If a deprecation warning is added to 2.6, it would be better to make
all the changes to 2.6, merge the changes into the 3k branch, then
perform the procedure above.  This will avoid some merge conflicts.


Previously deprecated
---------------------

PEP 4 lists all modules that have been deprecated in the stdlib
[#pep-0004]_.  The specified motivations mirror those listed in
PEP 4. All modules listed
in the PEP at the time of the first alpha release of Python 3.0 will
be removed.

The entire contents of lib-old will also be removed.  These modules
have already been removed from being imported but are kept in the
distribution for Python for users that rely upon the code.

* buildtools

    + Documented as deprecated since Python 2.3 without an explicit
      reason.

* cfmfile

    + Documented as deprecated since Python 2.4 without an explicit
      reason.

* cl

    + Documented as obsolete since Python 2.0 or earlier.
    + Interface to SGI hardware.

* md5

    + Supplanted by the ``hashlib`` module.

* mimetools

    + Documented as obsolete without an explicit reason.

* MimeWriter

    + Supplaned by the ``email`` package.

* mimify

    + Supplanted by the ``email`` package.

* multifile

    + Supplanted by the ``email`` package.

* posixfile

    + Locking is better done by ``fcntl.lockf()``.

* rfc822

    + Supplanted by the ``email`` package.

* sha

    + Supplanted by the ``hashlib`` package.

* sv

    + Documented as obsolete since Python 2.0 or earlier.
    + Interface to obsolete SGI Indigo hardware.

* timing

    + Documented as obsolete since Python 2.0 or earlier.
    + ``time.clock()`` gives better time resolution.


Platform-specific with minimal use
----------------------------------

Python supports many platforms, some of which are not widely held.
And on some of these platforms there are modules that have limited use
to people on those platforms.  Because of their limited usefulness it
would be better to no longer burden the Python development team with
their maintenance.

The module mentioned below are documented. All undocumented modules
for the specified platforms will also be removed.

IRIX
/////
The IRIX operating system is no longer produced [#irix-retirement]_.
Removing all modules from the plat-irix[56] directory has been deemed
reasonable because of this fact.

  + AL/al [done: 3.0]

    - Provides sound support on Indy and Indigo workstations.
    - Both workstations are no longer available.
    - Code has not been uniquely edited in three years.

  + cd [done: 3.0]

    - CD drive control for SGI systems.
    - SGI no longer sells machines with IRIX on them.
    - Code has not been uniquely edited in 14 years.

  + cddb [done: 3.0]

    - Undocumented.

  + cdplayer [done: 3.0]

    - Undocumented.

  + cl/CL/CL_old [done: 3.0]

    - Compression library for SGI systems.
    - SGI no longer sells machines with IRIX on them.
    - Code has not been uniquely edited in 14 years.

  + DEVICE/GL/gl/cgen/cgensuport [done: 3.0]

    - GL access, which is the predecessor to OpenGL.
    - Has not been edited in at least eight years.
    - Third-party libraries provide better support (PyOpenGL [#pyopengl]_).

  + ERRNO [done: 3.0]

    - Undocumented.

  + FILE [done: 3.0]

    - Undocumented.

  + FL/fl/flp [done: 3.0]

    - Wrapper for the FORMS library [#irix-forms]_
    - FORMS has not been edited in 12 years.
    - Library is not widely used.
    - First eight hits on Google are for Python docs for fl.

  + fm [done: 3.0]

    - Wrapper to the IRIS Font Manager library.
    - Only available on SGI machines which no longer come with IRIX.

  + GET [done: 3.0]

    - Undocumented.

  + GLWS [done: 3.0]

    - Undocumented.

  + imgfile [done: 3.0]

    - Wrapper for SGI libimage library for imglib image files
      (``.rgb`` files).
    - Python Imaging Library provdes read-only support [#pil]_.
    - Not uniquely edited in 13 years.

  + IN [done: 3.0]

    - Undocumented.

  + IOCTL [done: 3.0]

    - Undocumented.

  + jpeg [done: 3.0]

    - Wrapper for JPEG (de)compressor.
    - Code not uniquely edited in nine years.
    - Third-party libraries provide better support
      (Python Imaging Library [#pil]_).

  + panel [done: 3.0]

    - Undocumented.

  + panelparser [done: 3.0]

    - Undocumented.

  + readcd [done: 3.0]

    - Undocumented.

  + SV [done: 3.0]

    - Undocumented.

  + torgb [done: 3.0]

    - Undocumented.

  + WAIT [done: 3.0]

    - Undocumented.


Mac-specific modules
////////////////////

The Mac-specific modules are mostly unmaintained (e.g., the bgen
tool used to auto-generate many of the modules has never been
updated to support UCS-4). It is also not Python's place to maintain
such a large amount of OS-specific modules. Thus all modules under
plat-mac are to be removed.

A stub module for proxy access will be provided for use by urllib.

* _builtinSuites

    - Undocumented.
    - Package under lib-scriptpackages.

* Audio_mac

    - Undocumented.

* aepack

    - OSA support is better through third-party modules.

        * Appscript [#appscript]_.

    - Hard-coded endianness which breaks on Intel Macs.
    - Might need to rename if Carbon package dependent.

* aetools

    - See aepack.

* aetypes

    - See aepack.

* applesingle

    - Undocumented.
    - AppleSingle is a binary file format for A/UX.
    - A/UX no longer distributed.

* appletrawmain

    - Undocumented.

* appletrunner

    - Undocumented.

* argvemulator

    - Undocumented.

* autoGIL

    - Very bad model for using Python with the CFRunLoop.

* bgenlocations

    - Undocumented.

* bundlebuilder

    - Undocumented.

* Carbon

    - Carbon development has stopped.
    - Does not support 64-bit systems completely.
    - Dependent on bgen which has never been updated to support UCS-4
      Unicode builds of Python.

* CodeWarrior

    - Undocumented.
    - Package under lib-scriptpackages.

* ColorPicker

    - Better to use Cocoa for GUIs.

* EasyDialogs

    - Better to use Cocoa for GUIs.

* Explorer

    - Undocumented.
    - Package under lib-scriptpackages.

* Finder

    - Undocumented.
    - Package under lib-scriptpackages.


* findertools

    - No longer useful.

* FrameWork

    - Poorly documented.
    - Not updated to support Carbon Events.

* gensuitemodule

    - See aepack.

* ic

* icopen

    - Not needed on OS X.
    - Meant to replace 'open' which is usually a bad thing to do.

* macerrors

    - Undocumented.

* MacOS

    - Would also mean the removal of binhex.

* macostools

* macresource

    - Undocumented.

* MiniAEFrame

    - See aepack.

* Nav

    - Undocumented.

* Netscape

    - Undocumented.
    - Package under lib-scriptpackages.


* pimp

    - Undocumented.

* PixMapWrapper

    - Undocumented.

* StdSuites

    - Undocumented.
    - Package under lib-scriptpackages.

* SystemEvents

    - Undocumented.
    - Package under lib-scriptpackages.

* Terminal

    - Undocumented.
    - Package under lib-scriptpackages.


* terminalcommand

    - Undocumented.

* videoreader

     - No longer used.

* W

     - No longer distributed with Python.


.. _PyObjC: http://pyobjc.sourceforge.net/


Solaris
///////

  + SUNAUDIODEV/sunaudiodev [done: 3.0]

    - Access to the sound card on Sun machines.
    - Code not uniquely edited in over eight years.


Hardly used
------------

Some modules that are platform-independent are hardly used.  This
can be from how easy it is to implement the functionality from scratch
or because the audience for the code is very small.

* audiodev [done: 3.0]

  + Undocumented.
  + Not edited in five years.
  + If removed sunaudio should go as well (also undocumented; not
    edited in over seven years).

* imputil

  + Undocumented.
  + Never updated to support absolute imports.

* mutex

  + Easy to implement using a semaphore and a queue.
  + Cannot block on a lock attempt.
  + Not uniquely edited since its addition 15 years ago.
  + Only useful with the 'sched' module.
  + Not thread-safe.


* stringold [done: 3.0]

  + Function versions of the methods on string objects.
  + Obsolete since Python 1.6.
  + Any functionality not in the string object or module will be moved
    to the string module (mostly constants).

* symtable/_symtable

  + Undocumented.

* toaiff [done: 3.0, moved to Demo]

  + Undocumented.
  + Requires ``sox`` library to be installed on the system.

* user

  + Easily handled by allowing the application specify its own
    module name, check for existence, and import if found.

* new [done: 3.0]

  + Just a rebinding of names from the 'types' module.
  + Can also call ``type`` built-in to get most types easily.
  + Docstring states the module is no longer useful as of revision
    27241 (2002-06-15).

* pure [done: 3.0]

  + Written before Pure Atria was bought by Rational which was then
    bought by IBM (in other words, very old).

* test.testall [done: 3.0]

  + From the days before regrtest.


Obsolete
--------

Becoming obsolete signifies that either another module in the stdlib
or a widely distributed third-party library provides a better solution
for what the module is meant for.

* Bastion/rexec [done: 3.0]

  + Restricted execution / security.
  + Turned off in Python 2.3.
  + Modules deemed unsafe.

* bsddb185 [done: 3.0]

  + Superceded by bsddb3
  + Not built by default.
  + Documentation specifies that the "module should never be used
    directly in new code".

* commands

  + subprocess module replaces it [#pep-0324]_.
  + Remove getstatus(), move rest to subprocess.

* compiler (need to add AST -> bytecode mechanism) [done: 3.0]

  + Having to maintain both the built-in compiler and the stdlib
    package is redundant [#ast-removal]_.
  + The AST created by the compiler is available [#ast]_.
  + Mechanism to compile from an AST needs to be added.

* dircache

  + Negligible use.
  + Easily replicated.

* dl [done: 3.0]

  + ctypes provides better support for same functionality.

* fpformat

  + All functionality is supported by string interpolation.

* htmllib

  + Superceded by HTMLParser.

* ihooks

  + Undocumented.
  + For use with rexec which has been turned off since Python 2.3.

* imageop [done: 3.0]

  + Better support by third-party libraries
    (Python Imaging Library [#pil]_).
  + Unit tests relied on rgbimg and imgfile.
        - rgbimg was removed in Python 2.6.
        - imgfile slated for removal in this PEP. [done: 3.0]

* linuxaudiodev [done: 3.0]

  + Replaced by ossaudiodev.

* mhlib

  + Obsolete mailbox format.

* popen2 [done: 3.0]

  + subprocess module replaces them [#pep-0324]_.

* sched

  + Replaced by threading.Timer.


* sgmllib

  + Does not fully parse SGML.
  + In the stdlib for support to htmllib which is slated for removal.

* stat

  + ``os.stat`` now returns a tuple with attributes.
  + Functions in the module should be made into methods for the object
    returned by os.stat.

* statvfs

  + ``os.statvfs`` now returns a tuple with attributes.

* thread

  + People should use 'threading' instead.

    - Rename 'thread' to _thread.
    - Deprecate dummy_thread and rename _dummy_thread.
    - Move thread.get_ident over to threading.

  + Guido has previously supported the deprecation
    [#thread-deprecation]_.

* urllib

  + Superceded by urllib2.
  + Functionality unique to urllib will be kept in the
    `urllib package`_.

* UserDict [done: 3.0]

  + Not as useful since types can be a superclass.
  + Useful bits moved to the 'collections' module.

* UserList/UserString [done: 3.0]

  + Not useful since types can be a superclass.


Modules to Rename
=================

Along with the stdlib gaining some modules that are no longer
relevant, there is also the issue of naming.  Many modules existed in
the stdlib before PEP 8 came into existence [#pep-0008]_.  This has
led to some naming inconsistencies and namespace bloat that should be
addressed.


PEP 8 violations
----------------

PEP 8 specifies that modules "should have short, all-lowercase names"
where "underscores can be used ... if it improves readability"
[#pep-0008]_.  The use of underscores is discouraged in package names.
The following modules violate PEP 8 and are not somehow being renamed
by being moved to a package.

==================  ==================================================
Current Name        Replacement Name
==================  ==================================================
_winreg             winreg (rename also because module has a public
                    interface and thus should not have a leading
                    underscore)
ConfigParser        configparser
copy_reg            copyreg
PixMapWrapper       pixmapwrapper
Queue               queue
SocketServer        socketserver
==================  ==================================================


Merging C and Python implementations of the same interface
----------------------------------------------------------

Several interfaces have both a Python and C implementation.  While it
is great to have a C implementation for speed with a Python
implementation as fallback, there is no need to expose the two
implementations independently in the stdlib.  For Python 3.0 all
interfaces with two implementations will be merged into a single
public interface.

The C module is to be given a leading underscore to delineate the fact
that it is not the reference implementation (the Python implementation
is).  This means that any semantic difference between the C and Python
versions must be dealt with before Python 3.0 or else the C
implementation will be removed until it can be fixed.

One interface that is not listed below is xml.etree.ElementTree.  This
is an externally maintained module and thus is not under the direct
control of the Python development team for renaming.  See `Open
Issues`_ for a discussion on this.

* pickle/cPickle

  + Rename cPickle to _pickle.
  + Semantic completeness of C implementation *not* verified.

* profile/cProfile

  + Rename cProfile to _profile.
  + Semantic completeness of C implementation *not* verified.

* StringIO/cStringIO [done: 3.0]

  + Add the class to the 'io' module.


No public, documented interface
-------------------------------

There are several modules in the stdlib that have no defined public
interface.  These modules exist as support code for other modules that
are exposed.  Because they are not meant to be used directly they
should be renamed to reflect this fact.

============  ===============================
Current Name  Replacement Name
============  ===============================
markupbase    _markupbase [done: 3.0]
dummy_thread  _dummy_thread [#]_
============  ===============================

.. [#] Assumes ``thread`` is renamed to ``_thread``.


Poorly chosen names
-------------------

A few modules have names that were poorly chosen in hindsight.  They
should be renamed so as to prevent their bad name from perpetuating
beyond the 2.x series.

=================  ===============================
Current Name       Replacement Name
=================  ===============================
repr               reprlib
test.test_support  test.support
=================  ===============================


Grouping of modules
-------------------

As the stdlib has grown, several areas within it have expanded to
include multiple modules (e.g., dbm support). Thus some new packages
make sense where the renaming makes a module's name easier to work
with.


dbm package
///////////

=================  ===============================
Current Name       Replacement Name
=================  ===============================
anydbm             dbm.tools [1]_
dbhash             dbm.bsd
dbm                dbm.ndbm
dumbdm             dbm.dumb
gdbm               dbm.gnu
whichdb            dbm.tools [1]_
=================  ===============================


.. [1] ``dbm.tools`` can combine ``anybdbm`` and ``whichdb`` since the public
       API for both modules has no name conflict and the two modules have
       closely related usage.



html package
////////////

==================  ===============================
Current Name        Replacement Name
==================  ===============================
HTMLParser          html.parser
htmlentitydefs      html.entities
==================  ===============================


http package
////////////

=================  ===============================
Current Name       Replacement Name
=================  ===============================
httplib            http.client
BaseHTTPServer     http.server [2]_
CGIHTTPServer      http.server [2]_
SimpleHTTPServer   http.server [2]_
Cookie             http.cookies
cookielib          http.cookiejar
=================  ===============================

.. [2] The ``http.server`` module can combine the specified modules
       safely as they have no naming conflicts.


tkinter package
///////////////

==================  ===============================
Current Name        Replacement Name
==================  ===============================
Canvas              tkinter.canvas
Dialog              tkinter.dialog
FileDialog          tkinter.filedialog [4]_
FixTk               tkinter._fix
ScrolledText        tkinter.scrolledtext
SimpleDialog        tkinter.simpledialog [5]_
Tix                 tkinter.tix
Tkconstants         tkinter.constants
Tkdnd               tkinter.dnd
Tkinter             tkinter.__init__
tkColorChooser      tkinter.colorchooser
tkCommonDialog      tkinter.commondialog
tkFileDialog        tkinter.filedialog [4]_
tkFont              tkinter.font
tkMessageBox        tkinter.messagebox
tkSimpleDialog      tkinter.simpledialog [5]_
turtle              tkinter.turtle
==================  ===============================

.. [4] ``tkinter.filedialog`` can safely combine ``FileDialog`` and
       ``tkFileDialog`` as there are no naming conflicts.

.. [5] ``tkinter.simpledialog`` can safely combine ``SimpleDialog``
       and ``tkSimpleDialog`` have no naming conflicts.


urllib package
//////////////

Originally this new package was to be named ``url``, but because of
the common use of the name as a variable, it has been deemed better
to keep the name ``urllib`` and instead shift existing modules around
into a new package.

==================  ===============================
Current Name        Replacement Name
==================  ===============================
urllib2             urllib.request
urlparse            urllib.parse
urllib              urllib.parse, urllib.request [6]_
==================  ===============================

.. [6] The quoting-related functions from ``urllib`` will be added
       to ``urllib.parse``. ``urllib.URLOpener`` and
       ``urllib.FancyUrlOpener`` will be added to ``urllib.request``
       as long as the documentation for both modules is updated.


xmlrpc package
//////////////

==================  ===============================
Current Name        Replacement Name
==================  ===============================
xmlrpclib           xmlrpc.client
SimpleXMLRPCServer  xmlrpc.server [3]_
CGIXMLRPCServer     xmlrpc.server [3]_
==================  ===============================

.. [3] The modules being combined into ``xmlrpc.server`` have no
       naming conflicts and thus can safely be merged.


Transition Plan
===============

For modules to be removed
-------------------------

For the removal of modules that are continuing to exist in the Python
2.x series (i.e., not deprecated explicitly in the 2.x series),
``warnings.warn3k()`` will be used to issue a DeprecationWarning.


Renaming of modules
-------------------

For modules that are renamed, stub modules will be created with the
original names and be kept in a directory within the stdlib (e.g. like
how lib-old was once used).  The need to keep the stub modules within
a directory is to prevent naming conflicts with case-insensitive
filesystems in those cases where nothing but the case of the module
is changing.

These stub modules will import the module code based on the new
naming.  The same type of warning being raised by modules being
removed will be raised in the stub modules.

Support in the 2to3 refactoring tool for renames will also be used
[#2to3]_.  Import statements will be rewritten so that only the import
statement and none of the rest of the code needs to be touched.  This
will be accomplished by using the ``as`` keyword in import statements
to bind in the module namespace to the old name while importing based
on the new name.


Open Issues
===========

Renaming of modules maintained outside of the stdlib
----------------------------------------------------

xml.etree.ElementTree not only does not meet PEP 8 naming standards
but it also has an exposed C implementation [#pep-0008]_.  It is an
externally maintained package, though [#pep-0360]_.  A request will be
made for the maintainer to change the name so that it matches PEP 8
and hides the C implementation.


Rejected Ideas
==============

Modules that were originally suggested for removal
--------------------------------------------------

* asynchat/asyncore

  + Josiah Carlson has said he will maintain the modules.

* audioop/sunau/aifc

   + Audio modules where the formats are still used.

* base64/quopri/uu

  + All still widely used.
  + 'codecs' module does not provide as nice of an API for basic
    usage.

* fileinput

  + Useful when having to work with stdin.

* linecache

   + Used internally in several places.

* nis

  + Testimonials from people that new installations of NIS are still
    occurring

* getopt

  + Simpler than optparse.

* repr

  + Useful as a basis for overriding.
  + Used internally.

* telnetlib

  + Really handy for quick-and-dirty remote access.
  + Some hardware supports using telnet for configuration and
    querying.

* Tkinter

  + Would prevent IDLE from existing.
  + No GUI toolkit would be available out of the box.


Introducing a new top-level package
-----------------------------------

It has been suggested that the entire stdlib be placed within its own
package.  This PEP will not address this issue as it has its own
design issues (naming, does it deserve special consideration in import
semantics, etc.).  Everything within this PEP can easily be handled if
a new top-level package is introduced.


Introducing new packages to contain theme-related modules
---------------------------------------------------------

During the writing of this PEP it was noticed that certain themes
appeared in the stdlib.  In the past people have suggested introducing
new packages to help collect modules that share a similar theme (e.g.,
audio).  An Open Issue was created to suggest some new packages to
introduce.

In the end, though, not enough support could be pulled together to
warrant moving forward with the idea.  Instead name simplification has
been chosen as the guiding force for PEPs to create.


References
==========

.. [#pep-0004] PEP 4: Deprecation of Standard Modules
    (http://www.python.org/dev/peps/pep-0004/)

.. [#pep-0008] PEP 8: Style Guide for Python Code
    (http://www.python.org/dev/peps/pep-0008/)

.. [#pep-0324] PEP 324: subprocess -- New process module
    (http://www.python.org/dev/peps/pep-0324/)

.. [#pep-0360] PEP 360: Externally Maintained Packages
    (http://www.python.org/dev/peps/pep-0360/)

.. [#module-index] Python Documentation: Global Module Index
    (http://docs.python.org/modindex.html)

.. [#timing-module] Python Library Reference: Obsolete
    (http://docs.python.org/lib/obsolete-modules.html)

.. [#silly-old-stuff] Python-Dev email: "Py3k release schedule worries"
    (http://mail.python.org/pipermail/python-3000/2006-December/005130.html)

.. [#thread-deprecation] Python-Dev email: Autoloading?
    (http://mail.python.org/pipermail/python-dev/2005-October/057244.html)

.. [#py-dev-summary-2004-11-01] Python-Dev Summary: 2004-11-01
    (http://www.python.org/dev/summary/2004-11-01_2004-11-15/#id10)

.. [#2to3] 2to3 refactoring tool
    (http://svn.python.org/view/sandbox/trunk/2to3/)

.. [#pyopengl] PyOpenGL
    (http://pyopengl.sourceforge.net/)

.. [#pil] Python Imaging Library (PIL)
    (http://www.pythonware.com/products/pil/)

.. [#twisted] Twisted
    (http://twistedmatrix.com/trac/)

.. [#irix-retirement] SGI Press Release:
    End of General Availability for MIPS IRIX Products -- December 2006
    (http://www.sgi.com/support/mips_irix.html)

.. [#irix-forms] FORMS Library by Mark Overmars
    (ftp://ftp.cs.ruu.nl/pub/SGI/FORMS)

.. [#sun-au] Wikipedia: Au file format
    (http://en.wikipedia.org/wiki/Au_file_format)

.. [#appscript] appscript
    (http://appscript.sourceforge.net/)

.. [#ast] _ast module
    (http://docs.python.org/lib/ast.html)

.. [#ast-removal] python-dev email: getting compiler package failures
    (http://mail.python.org/pipermail/python-3000/2007-May/007615.html)


Copyright
=========

This document has been placed in the public domain.



..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
   End: