[Python-Dev] PEP 384 final review (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Mon Nov 29 21:36:46 CET 2010
- Previous message: [Python-Dev] PEP 384 final review
- Next message: [Python-Dev] PEP 291 versus Python 3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This is probably an issue independent of the PEP but there appear to be a lot of exposed typedefs for various type slots and other function signatures that don't start with the Py prefix (i.e. getter, setter, unaryfunc and friends).
It's indeed independent: the names don't actually affect the ABI, but the API. Changing them is possible later without risking binary compatibility.
Python.h shouldn't be leaking unprefixed names like that. We certainly shouldn't be enshrining them in the stable ABI without adding prefixes first.
The stable ABI isn't actually enshrining them - what gets enshrined is the value of the typedefs, not their names.
I don't mind renaming them, though. I see a number of different cases:
- struct names. I don't see a problem to have "typedef struct PyFoo PyFoo" I vaguely recall that there had been compiler problems with that construct at some point, but to my knowledge, they are past, and this is actually both well-formed C and well-formed C++.
- function pointer type names
- "various" other types
For the struct types, in particular for the ones which already have a typedef, I think renaming them should be possible right away. Applications that break should be able to use the typedef instead, and continue to work with older releases.
For the function pointer type names, caution is necessary. We cannot remove them, since it would break a lot of code. I also think that some smart naming scheme would be desirable that makes the names all sound right, yet allows easy mapping from the existing types. Once such a scheme is added, we should have a graceful deprecation procedure, such as:
- release A: add typedefs in addition to existing pointer types, deprecate pointer types in documentation
- release B>A: make the old names somehow conditional (e.g. put them all into a header file rename3.h, or some such)
- release C>B: remove rename3.h
For the other rest, I think many of them are considered internal (of course, they shouldn't appear in the ABI then at all). Renaming them right away might be fine.
Regards, Martin
- Previous message: [Python-Dev] PEP 384 final review
- Next message: [Python-Dev] PEP 291 versus Python 3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]