> But, aside from that, I think I would want to go much further than this > _if_ I put time in redesigning PyArg_Parse. I would first like to take > inventory of all the problems there are with PyArg_Parse, and then see > whether we can design something that will solve most or all of these > issues, without being overly complex in everyday use. > > And before I embark on that journey I would first like to have a group > of people willing to put effort into this, plus the go-ahead of Guido > (there's little point in designing a new mechanism if there is no > chance of it being adopted as the general case, especially if this new > mechanism may need a new PyMethodDef flag or some such thing). +1 on a redesign of PyArg_Parse. Though I don't want to hold up the 2.3a1 release. > As a kickoff, here are some of my gripes about PyArg_Parse. (I can't spend too much time not paying attention to the Zope3 sprintathon, so I'll try to read these later. Chances are I agree. Surely the format characters are a big mess.) --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