...

Is there a point to adding more cruft to getopt.py now that we're getting Greg Ward's Optik?

Perhaps ease-of-use - people wanting to use GNU getopt style only need to change the function name in their existing application.

...

Also, I happen to hate GNU style getopt. You may call me an old fogey, but I think options should precede other arguments.

That certainly is debatable. However, since the patch is a pure addition, every application author will have to make the choice herself, and no existing application will break.

So I'm a neutral 0 on the patch. --Guido van Rossum (home page: http://www.python.org/~guido/)

pinard@iro.umontreal.ca (François Pinard) writes:

GNU getopt changes once in a while.

In what way? When has it changed last, and what was that change?

Will `getopt.gnu_getopt' track and reflect these changes as they occur? I mean, is it the intent? If yes, the name might be fine. Otherwise, it might be better to name this other `getopt' after some of its properties, instead of using `gnu' as a prefix.

Assuming that bug fixes are made to GNU getopt, it would certainly be reasonable to reflect them in getopt.gnu_getopt.

If GNU it has to be, maybe it should be capitalised? Some existing modules suggest capitals where underlines would probably have been sufficient, maybe we should use capitals where they are more naturally mandated.

Not a big matter for me, but probably worth a thought nevertheless?

I've no opinion on that except that function names are traditionally all lower-case. I'll ask the author of the patch. Regards, Martin

...

Is there a point to adding more cruft to getopt.py now that we're getting Greg Ward's Optik?

Perhaps ease-of-use - people wanting to use GNU getopt style only need to change the function name in their existing application.

...

Also, I happen to hate GNU style getopt. You may call me an old fogey, but I think options should precede other arguments.

That certainly is debatable. However, since the patch is a pure addition, every application author will have to make the choice herself, and no existing application will break.

So I'm a neutral 0 on the patch. --Guido van Rossum (home page: http://www.python.org/~guido/)

pinard@iro.umontreal.ca (François Pinard) writes:

GNU getopt changes once in a while.

In what way? When has it changed last, and what was that change?

Will `getopt.gnu_getopt' track and reflect these changes as they occur? I mean, is it the intent? If yes, the name might be fine. Otherwise, it might be better to name this other `getopt' after some of its properties, instead of using `gnu' as a prefix.

Assuming that bug fixes are made to GNU getopt, it would certainly be reasonable to reflect them in getopt.gnu_getopt.

If GNU it has to be, maybe it should be capitalised? Some existing modules suggest capitals where underlines would probably have been sufficient, maybe we should use capitals where they are more naturally mandated.

Not a big matter for me, but probably worth a thought nevertheless?

I've no opinion on that except that function names are traditionally all lower-case. I'll ask the author of the patch. Regards, Martin