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 chop

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 in

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 mar...@v.loewis.de 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

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 ba...@python.org 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

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 br...@python.org wrote: On Sat, Apr 21, 2012 at 12:10, Barry Warsaw ba...@python.org 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

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 ericsnowcurren...@gmail.comwrote: On Sat, Apr 21, 2012 at 4:17 PM, Brett Cannon br...@python.org wrote: On Sat, Apr 21, 2012 at 12:10, Barry Warsaw ba...@python.org wrote: Strictly speaking, I do think you need to deprecate the APIs. I like Nick's

[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

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 br...@python.org 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

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 gu...@python.org 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