> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
