I am -1 for the optional parameters and grouping stuff - no need to make complicated stuff easier to do just because "range" semantics is strange to start with. (And one can implement a range-like funciton explictly parsing the parameters if needed be.)
As for the "/" delimiting positional only parameters - I think it would be nice to have. -but just that - mandatory positional only parameters. Apart from that, I could not figure if the PEP covers a situation where the name of a positional-only parameter is passed in as a kwarg - def a([b],/,**kw): print (b) does calling "a(b=5)" should raise a TypeError, or put "5" in """kw["b"]""" and leave "b" as "undefined" ? js -><- On 8 October 2013 22:31, Benjamin Peterson <benja...@python.org> wrote: > 2013/10/8 Larry Hastings <la...@hastings.org>: >> This PEP proposes a backwards-compatible syntax that should >> permit implementing any builtin in pure Python code. > > This is rather too strong. You can certainly implement them; you just > have to implement the argument parsing yourself. Python's > call/signature syntax is already extremely expressive, and resolving > call arguments to formal parameters is already a complicated (and > slow) process. Implementing functions with such strange argument > semantics is hardly common enough to justify the whole grouping syntax > proposed in this PEP. -1 to that. I think I can live with "/", but > YANGTNI still. > > > > -- > Regards, > Benjamin > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
