[Python-Dev] Re: [Patch #102170] move getopt() to Py_GetOpt() and use it unconditionally
Thu, 2 Nov 2000 23:51:52 +0100
On Wed, Nov 01, 2000 at 09:00:43PM -0800, email@example.com wrote:
> Accepted and assigned back to Thomas.
> Guido approved of this "in theory" before, so go for it!
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
Thomas Wouters <firstname.lastname@example.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!