[Python-Dev] Re: [Patch #102170] move getopt() to Py_GetOpt() and use it unconditionally

Guido van Rossum guido@python.org
Thu, 02 Nov 2000 08:51:14 -0500


> 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/)