Well, I changed everything you wanted changed (use _PyOS_ rather than Py_ as prefix, etc) and I was about to check it in, when I got cold feet. This change is going to break programs embedding or extending python, that rely on getopt() (the C function) being available, one way or another. After this move, that is no longer necessarily true. I got cold feet because of Demo/pysrv/pysrv.c, which just adds the necessary externs for getopt(), optind and optarg, and doesn't bother with #include <getopt.h> or some such.

Before, that would probably always work, depending on which library/archive was searched first, for the getopt() function. It would only break if system-libraries were searched first, for some reason, and the system libraries provide a broken getopt. In all other cases, like there not being a getopt, getopt needing seperate includes or defines, or separate link or compile arguments, the Python getopt would be used, and it would do what was expected (probably, anyway ;)

After the change, people need to use the system getopt(), and do their own hoop-jumping to find out if it's there, how to call it, etc. Now I myself have never written anything that would depend on Python providing getopt(), but that doesn't say anything at all. Is this acceptable breakage ? Or should we go the whole nine yards, make it an official API, document it, and provide backwards-compatible symbols on platforms where getopt used to be used ?

Don't worry -- getopt has never been something offered by Python. It's something assumed to be in the system library, and if it isn't we provide our own -- but we don't provide it for the benefit of those who embed us. (In fact, if Python is embedded, it will not *use* getopt.) We can't even guarantee to provide it, because it's likely already in the system library. (That's why I like that the prefix begins with an underscore -- those are not provided for use by others, only for internal use.) --Guido van Rossum (home page: http://www.python.org/~guido/)

Well, I changed everything you wanted changed (use _PyOS_ rather than Py_ as prefix, etc) and I was about to check it in, when I got cold feet. This change is going to break programs embedding or extending python, that rely on getopt() (the C function) being available, one way or another. After this move, that is no longer necessarily true. I got cold feet because of Demo/pysrv/pysrv.c, which just adds the necessary externs for getopt(), optind and optarg, and doesn't bother with #include <getopt.h> or some such.

Before, that would probably always work, depending on which library/archive was searched first, for the getopt() function. It would only break if system-libraries were searched first, for some reason, and the system libraries provide a broken getopt. In all other cases, like there not being a getopt, getopt needing seperate includes or defines, or separate link or compile arguments, the Python getopt would be used, and it would do what was expected (probably, anyway ;)

After the change, people need to use the system getopt(), and do their own hoop-jumping to find out if it's there, how to call it, etc. Now I myself have never written anything that would depend on Python providing getopt(), but that doesn't say anything at all. Is this acceptable breakage ? Or should we go the whole nine yards, make it an official API, document it, and provide backwards-compatible symbols on platforms where getopt used to be used ?

Don't worry -- getopt has never been something offered by Python. It's something assumed to be in the system library, and if it isn't we provide our own -- but we don't provide it for the benefit of those who embed us. (In fact, if Python is embedded, it will not *use* getopt.) We can't even guarantee to provide it, because it's likely already in the system library. (That's why I like that the prefix begins with an underscore -- those are not provided for use by others, only for internal use.) --Guido van Rossum (home page: http://www.python.org/~guido/)