[Tim]
> Next question: why isn't builtin_len using METH_OLDARGS instead? Is
> there some advantage to using METH_VARARGS in this case?
[Michael Hudson]
> So you can't do
>
> >>> len(1,2)
> 2
>
> a la list.append, socket.connect pre 2.0? (or was it 1.6?)
If I didn't know better, I'd suspect Python's internal calling conventions
at the start didn't perfectly anticipate all future developements. Among
other things, looks like it's impossible for a METH_OLDARGS function to
distinguish between being called with more than one argument and being
called with a single tuple argument.
> My imprssion is that generally METH_VARARGS is saner than METH_OLDARGS
> (ie. more consistent).
Yes, METH_OLDARGS does appear to, well, suck.
> It seems the proposed METH_O is basically METH_OLDARGS + the
> restriction that there is in fact only one argument, so we save
> a tuple allocation over METH_VARARGS,
Also, and more importantly, save the PyArg_ParseTuple call on the receiving
end.
> but get argument count checking over METH_OLDARGS.
Which is worth getting. I'm back to where I started here:
Do METH_O, convert every "O" function to use it, declare victory, and enjoy
the weekend.
1%-of-the-work-for-80%-of-the-gain-and-an-overall-decrease-in-code-
size-ly y'rs - tim
PS: But today I'll add another: add at least one comment to the code --
this stuff is a bitch to reverse-engineer.
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