I think that was started as pep 457: https://www.python.org/dev/peps/pep-0457/ (Syntax For Positional-Only Parameters) Still informal.
+1, it's likely possible to backport it to previous version using a decorator and faking __signature__. -- M On Tue, Feb 28, 2017 at 2:03 PM, Yury Selivanov <yselivanov...@gmail.com> wrote: > I'm +0.5 to add positional-only parameters. > > Pros: > > * A lot of people don't know what '/' currently means in > functions signatures rendered by `help` and docs. Because > it's not a real syntax, it's really hard to find what it > means. > > * Some APIs do look better with positional-only parameters, > especially functions with one argument. > > * We already have this feature half-implemented: some > builtin methods have positional-only arguments, > inspect.signature API supports it already. > > Cons: > > * Function declarations will become a bit more complex, > making a bump in Python learning curve. > > * Performance? I'm not sure if adding another set of checks > will make a huge impact, but we'll need to benchmark this. > > Yury > > > > On 2017-02-28 4:17 PM, Victor Stinner wrote: >> >> Hi, >> >> For technical reasons, many functions of the Python standard libraries >> implemented in C have positional-only parameters. Example: >> ------- >> $ ./python >> Python 3.7.0a0 (default, Feb 25 2017, 04:30:32) >>>>> >>>>> help(str.replace) >> >> replace(self, old, new, count=-1, /) # <== notice "/" at the end >> ... >>>>> >>>>> "a".replace("x", "y") # ok >> >> 'a' >> >>>>> "a".replace(old="x", new="y") # ERR! >> >> TypeError: replace() takes at least 2 arguments (0 given) >> ------- >> >> When converting the methods of the builtin str type to the internal >> "Argument Clinic" tool (tool to generate the function signature, >> function docstring and the code to parse arguments in C), I asked if >> we should add support for keyword arguments in str.replace(). The >> answer was quick: no! It's a deliberate design choice. >> >> Quote of Yury Selivanov's message: >> """ >> I think Guido explicitly stated that he doesn't like the idea to >> always allow keyword arguments for all methods. I.e. `str.find('aaa')` >> just reads better than `str.find(needle='aaa')`. Essentially, the idea >> is that for most of the builtins that accept one or two arguments, >> positional-only parameters are better. >> """ >> http://bugs.python.org/issue29286#msg285578 >> >> I just noticed a module on PyPI to implement this behaviour on Python >> functions: >> >> https://pypi.python.org/pypi/positional >> >> My question is: would it make sense to implement this feature in >> Python directly? If yes, what should be the syntax? Use "/" marker? >> Use the @positional() decorator? >> >> Do you see concrete cases where it's a deliberate choice to deny >> passing arguments as keywords? >> >> Don't you like writing int(x="123") instead of int("123")? :-) (I know >> that Serhiy Storshake hates the name of the "x" parameter of the int >> constructor ;-)) >> >> By the way, I read that "/" marker is unknown by almost all Python >> developers, and [...] syntax should be preferred, but >> inspect.signature() doesn't support this syntax. Maybe we should fix >> signature() and use [...] format instead? >> >> Replace "replace(self, old, new, count=-1, /)" with "replace(self, >> old, new[, count=-1])" (or maybe even not document the default >> value?). >> >> Python 3.5 help (docstring) uses "S.replace(old, new[, count])". >> >> Victor >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ > > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/