[Python-Dev] Pronouncement needed in issue9675

[Larry Hastings]

Hi--sorry to be a little late to the discussion.  I'm the putz who 
backported capsules (and monkeyed with CObject) for 2.7.


On 09/27/2010 07:44 PM, Jesus Cea wrote:
> http://bugs.python.org/issue9675
>
> Long history sort: Python 2.7 backported Capsule support and
> (incorrectly, in my opinion) marked CObject as deprecated.
>    

Not strictly true.  CObject is marked with a "Pending Deprecation" 
warning.  But this is still turned into an error by -We.

> All C modules in the stdlib were updated to Capsule (with a CObject
> compatibility layer), except BSDDB, because this change was done late in
> the cycle, the proposed patch was buggy (solvable) and a pronouncement
> was done that CObject was not actually deprecated.
>    

I did the stdlib conversion from CObjects to capsules.  I was told it'd 
be improper for me to convert bsddb to capsules because it's externally 
maintained (by you!).  You and I discussed converting bsddb to capsules 
for 2.7 at the very last minute but it didn't happen.

> Since I think that adopting Capsule in BSDDB for 2.7.1 would break the
> API compatibility (maybe the CObject proxy would solve this), and since
> a previous pronouncement was done abour CObject not-deprecated in 2.7.x,
> I would like comments.
>    

By "CObject proxy" I assume you mean CObject support for opening 
capsules.  Specifically: PyCObject_AsVoidPtr()--and therefore functions 
that call it, such as PyCObject_Import()--understand capsules.  So yes, 
if the bsddb that shipped with Python 2.7.1 used a capsule, external 
users /should/ work unchanged.  I further theorize that external callers 
would continue to work fine even if they'd been compiled against 
previous versions of Python (though I admit I've never tried it).



On 09/28/2010 06:49 AM, Guido van Rossum wrote:
> My guess is that the warning was added to 2.7 before it was clear that 
> there would never be a 2.8.

I understood at the time how unlikely it is that there will ever be a 
2.8.  I'm just that paranoid/crazy.  Even if the Python core dev 
community never release a 2.7 (or 2.8) external luddites might, and I 
wanted my foot in the door.


I'm fine with changing the warning so it's only active with -3.  I still 
want it left as a PendingDeprecationWarning; PyErr_WarnPy3k() issues a 
DeprecationWarning, and it'd be inappropriate to upgrade it to that.  
(Though if there ever is a 2.8 (crosses self) maybe we could drop the -3 
requirement then?)  I'd be willing to contribute this change.  I'd be 
happy to convert every use of PendingDeprecationWarning, or just the one 
in cobject.c, either way.


Sorry about all the wailing and gnashing of teeth,


/larry/