Re: [Python-Dev] Handling deprecations in the face of PEP 384

2012-04-21 Thread Brett Cannon
On Sat, Apr 21, 2012 at 20:54, Eric Snow wrote: > On Sat, Apr 21, 2012 at 4:17 PM, Brett Cannon wrote: > > On Sat, Apr 21, 2012 at 12:10, Barry Warsaw wrote: > >> Strictly speaking, I do think you need to deprecate the APIs. I like > >> Nick's > >> suggestion to make them C wrappers which just

Re: [Python-Dev] Handling deprecations in the face of PEP 384

2012-04-21 Thread Eric Snow
On Sat, Apr 21, 2012 at 4:17 PM, Brett Cannon wrote: > On Sat, Apr 21, 2012 at 12:10, Barry Warsaw wrote: >> Strictly speaking, I do think you need to deprecate the APIs.  I like >> Nick's >> suggestion to make them C wrappers which just call back into Python. > > > That was my plan, but the amou

Re: [Python-Dev] Handling deprecations in the face of PEP 384

2012-04-21 Thread Brett Cannon
On Sat, Apr 21, 2012 at 12:10, Barry Warsaw wrote: > On Apr 20, 2012, at 09:59 PM, Brett Cannon wrote: > > >As I clean up Python/import.c and move much of its functionality into > >Lib/imp.py, I am about to run into some stuff that was not kept private to > >the file. Specifically, I have PyImpor

Re: [Python-Dev] Handling deprecations in the face of PEP 384

2012-04-21 Thread Brett Cannon
On Sat, Apr 21, 2012 at 16:55, "Martin v. Löwis" wrote: > > From my reading of PEP 384 that means I would need to at least deprecate > > PyImport_getMagicTag(), correct (assuming I follow through with this; I > > might not bother)? > > All that PEP 384 gives you is that you MAY deprecate certain

Re: [Python-Dev] Handling deprecations in the face of PEP 384

2012-04-21 Thread Martin v. Löwis
> From my reading of PEP 384 that means I would need to at least deprecate > PyImport_getMagicTag(), correct (assuming I follow through with this; I > might not bother)? All that PEP 384 gives you is that you MAY deprecate certain API (namely, all API not guaranteed as stable). If an API is not i

Re: [Python-Dev] Handling deprecations in the face of PEP 384

2012-04-21 Thread Barry Warsaw
On Apr 20, 2012, at 09:59 PM, Brett Cannon wrote: >As I clean up Python/import.c and move much of its functionality into >Lib/imp.py, I am about to run into some stuff that was not kept private to >the file. Specifically, I have PyImport_GetMagicTag() and NullImporter_Type >which I would like to c

Re: [Python-Dev] Handling deprecations in the face of PEP 384

2012-04-20 Thread Nick Coghlan
On Sat, Apr 21, 2012 at 12:16 PM, Guido van Rossum wrote: > Yeah, PyImporter_GetMagicTag() looks like a public API, parallel with > PyImporter_GetMagicNumber(). Maybe it was accidentally not documented? > I'm not sure when it was introduced. Should we even deprecate it? I'd > say do the same thing

Re: [Python-Dev] Handling deprecations in the face of PEP 384

2012-04-20 Thread Guido van Rossum
On Fri, Apr 20, 2012 at 6:59 PM, Brett Cannon wrote: > As I clean up Python/import.c and move much of its functionality into > Lib/imp.py, I am about to run into some stuff that was not kept private to > the file. Specifically, I have PyImport_GetMagicTag() and NullImporter_Type > which I would li

[Python-Dev] Handling deprecations in the face of PEP 384

2012-04-20 Thread Brett Cannon
As I clean up Python/import.c and move much of its functionality into Lib/imp.py, I am about to run into some stuff that was not kept private to the file. Specifically, I have PyImport_GetMagicTag() and NullImporter_Type which I would like to chop out and move to Lib/imp.py. >From my reading of PE