> I'd also be in favour of providing option parsing through getopt > only. If getopt is not enough, extend it (in moderate ways, rather > adding customization mechanisms instead of alternatives, etc). If that > involves incorporating code from Optik, fine. However, I don't think > the standard library should have two modules that do essentially the > same thing; such scenarious will raise question whether one is better > than the other and which of them is maintained. I think Optik provides one key idea that makes it better: an options parser object that can be invoked multiple times and each time returns a new options object whose attributes are variables corresponding to various options. I'd be happy to say that the old getopt.getopt() interface will be deprecated. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4