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

[Thomas Wouters]

On Wed, Nov 01, 2000 at 09:00:43PM -0800, noreply@sourceforge.net wrote:

> Comment:
> 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
used ?

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!