[Patrick K. O'Brien] > ... > * Is there any reason to not expand the scope of getargspec()? No -- go for it. > * For builtin functions whose arguments cannot be determined (at > least not that I know of) Those implemented in C are indeed hopeless; I expect that's all of them. > what should getargspec() do? Should it raise an error or return empty > values? What does it do now? Don't rock the boot needlessly <wink>. > * For a bound method, should getargspec() include the first argument > (usually self) since Python passes that value implicitly? Unfortunately, Python is inconsistent about this. On the one hand, >>> x = [] >>> push = x.append >>> push() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: append() takes exactly one argument (0 given) >>> On the other, >>> class X(list): ... def append(self, item): ... pass ... >>> push = X().append >>> push() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: append() takes exactly 2 arguments (1 given) >>> I care about matching the error msgs because error msgs are a prime trigger for looking up help. OTOH, when the error msgs are inconsistent, you can't win. I'd count self, myself, as you can only suck the signature out of Python-defined callables, and those seem consistent about reporting the "real" number of arguments required. > Perhaps there should be a optional argument to toggle this. Bleech. no-time-for-more-ly y'rs - tim
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