On Wed, Jun 20, 2012 at 12:15 PM, Yury Selivanov <yseliva...@gmail.com> wrote:
> On 2012-06-19, at 10:06 PM, Nick Coghlan wrote:
>> True, the check for name clashes in Signature (and the implied numeric
>> "names") will cover the BoundArguments.parameters case
>
> Nick, I also would like to keep Parameter.name being required.
> I understand that *currently* we have no parameter names specified
> for builtin methods, but we don't have any mechanisms to introspect
> them too.
Sure, so long as the name requirement is enforced at construction time
- the current code will happily accept None as the first argument to
parameter.
> Now, in 3.3 (I hope) we introduce a brand new mechanism, and, probably, in
> 3.4 we have way to define Signatures for builtins. Why not do it right?
> This whole positional-only case is just a weird anachronism of CPython.
No, it's a characteristic of any FFI - not all target languages will
support keyword arguments. CPython just happens to use such an FFI as
part of its implementation (due to the nature of the PyArg_Parse*
APIs).
There have been serious (albeit failed so far) attempts at coming up
with an acceptable language level syntax for positional only arguments
on python-ideas, since they're a useful concept when you want to avoid
name clashes with arbitrary keyword arguments and you *can*
effectively implement them in Python using a nested function call to
get the correct kind of error:
def _positional_only(a, b, c):
return a, b, c
def f(*args, **kwds): # "a", "b", "c" are supported as values in "kwds"
a, b, c = _positional_only(*args)
With PEP 362, we can at least *represent* the above API cleanly, even
though there's still no dedicated syntax:
>>> def _param(name): return Parameter(name, Parameter.POSITIONAL_ONLY)
>>> s = Signature([_param("a"), _param("b"), _param("c"),
Parameter("kwds", Parameter.VAR_KEYWORD])
>>> str(s)
(<a>, <b>, <c>, **kwds)
If a syntax for positional only parameters is ever defined in the
future, then the Signature __str__ implementation can be updated to
use it at the time.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
