Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
On 5/16/2019 8:23 AM, Anders Hovmöller wrote: On 16 May 2019, at 08:50, Serhiy Storchaka wrote: Writing the code that parses args is errorprone and inefficient. There are also other rationales of PEP 570. I've read it. It is unconvincing to me. That's fine. Coredevs don't always agree 100% on every change either. -- Terry Jan Reedy ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
> On 16 May 2019, at 08:50, Serhiy Storchaka wrote: > > 16.05.19 08:46, Anders Hovmöller пише: >> In the general case because of features that until / was introduced was >> unique to functions defined in C. But in the case of the dict constructor >> that's just a weird misfeature. If it did in fact take *args and handled it >> it would be perfectly fine and useful. It would have meant people wouldn't >> have written all those merge() utility functions over the years. And it >> would make dict(a, b) valid syntax instead of the current overly verbose >> dict(**a, **b). >> For / to be a good idea one needs a strong argument for why a function must >> exist that tales a bounded amount of arguments (ie not *args) where calling >> it with the parameters named would be a bad thing. There are certainly cases >> where the names don't add much, like most functions with one argument but >> that is a different thing. > > The dict constructor is just one example. There are around 60 Python > functions in the stdlib which will benefit from adding support of > positional-only arguments. Look at > https://github.com/python/cpython/pull/12620. > > Writing the code that parses args is errorprone and inefficient. > > There are also other rationales of PEP 570. I've read it. It is unconvincing to me. / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
16.05.19 08:46, Anders Hovmöller пише: In the general case because of features that until / was introduced was unique to functions defined in C. But in the case of the dict constructor that's just a weird misfeature. If it did in fact take *args and handled it it would be perfectly fine and useful. It would have meant people wouldn't have written all those merge() utility functions over the years. And it would make dict(a, b) valid syntax instead of the current overly verbose dict(**a, **b). For / to be a good idea one needs a strong argument for why a function must exist that tales a bounded amount of arguments (ie not *args) where calling it with the parameters named would be a bad thing. There are certainly cases where the names don't add much, like most functions with one argument but that is a different thing. The dict constructor is just one example. There are around 60 Python functions in the stdlib which will benefit from adding support of positional-only arguments. Look at https://github.com/python/cpython/pull/12620. Writing the code that parses args is errorprone and inefficient. There are also other rationales of PEP 570. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
> On 15 May 2019, at 21:55, Jonathan Goble wrote: > >> On Wed, May 15, 2019 at 3:45 AM Anders Hovmöller wrote: >> >>> On 15 May 2019, at 07:51, Jonathan Goble wrote: >>> >>> That's not a realistic goal; there are some use cases, including in >>> CPython builtins, that cannot be accomplished without positional-only >>> arguments. For example, the current behavior of the `dict` constructor >>> is to accept both certain iterables as a positional-only argument >>> and/or keyword arguments from which a dict can be created. If the >>> iterable argument was not positional-only, then it would be forced to >>> consume a keyword (even if the caller passes it as a positional >>> argument), meaning that that keyword could never be included in >>> **kwargs and could not become a dict key via keyword arguments. >> >> You lost me. How is this not handled by *args and **kwargs? I think it is. >> "Positional only" isn't needed in this case. > > Because `def func(*args, **kwargs):` obfuscates the true signature, > making `help()` and the `inspect` module less useful and forcing one > to analyze the implementation code or study the docs to understand > what and how many arguments are actually expected. In the general case because of features that until / was introduced was unique to functions defined in C. But in the case of the dict constructor that's just a weird misfeature. If it did in fact take *args and handled it it would be perfectly fine and useful. It would have meant people wouldn't have written all those merge() utility functions over the years. And it would make dict(a, b) valid syntax instead of the current overly verbose dict(**a, **b). For / to be a good idea one needs a strong argument for why a function must exist that tales a bounded amount of arguments (ie not *args) where calling it with the parameters named would be a bad thing. There are certainly cases where the names don't add much, like most functions with one argument but that is a different thing. / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
On Wed, May 15, 2019 at 3:45 AM Anders Hovmöller wrote: > > > On 15 May 2019, at 07:51, Jonathan Goble wrote: > > > > That's not a realistic goal; there are some use cases, including in > > CPython builtins, that cannot be accomplished without positional-only > > arguments. For example, the current behavior of the `dict` constructor > > is to accept both certain iterables as a positional-only argument > > and/or keyword arguments from which a dict can be created. If the > > iterable argument was not positional-only, then it would be forced to > > consume a keyword (even if the caller passes it as a positional > > argument), meaning that that keyword could never be included in > > **kwargs and could not become a dict key via keyword arguments. > > You lost me. How is this not handled by *args and **kwargs? I think it is. > "Positional only" isn't needed in this case. Because `def func(*args, **kwargs):` obfuscates the true signature, making `help()` and the `inspect` module less useful and forcing one to analyze the implementation code or study the docs to understand what and how many arguments are actually expected. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
On Wed, May 15, 2019 at 12:46 AM Anders Hovmöller wrote: > > > > On 15 May 2019, at 07:51, Jonathan Goble wrote: > > > > That's not a realistic goal; there are some use cases, including in > > CPython builtins, that cannot be accomplished without positional-only > > arguments. For example, the current behavior of the `dict` constructor > > is to accept both certain iterables as a positional-only argument > > and/or keyword arguments from which a dict can be created. If the > > iterable argument was not positional-only, then it would be forced to > > consume a keyword (even if the caller passes it as a positional > > argument), meaning that that keyword could never be included in > > **kwargs and could not become a dict key via keyword arguments. > > You lost me. How is this not handled by *args and **kwargs? I think it is. > "Positional only" isn't needed in this case. > > > Additionally, PEP 570 [1], which will add syntax for positional-only > > parameters in Python functions, was accepted by Guido last month. > It was actually a decision of the Python steering council, of which Guido is a member and so am I. > > I know and in my opinion it's a big mistake. It adapts python to a > misfeatures of C extension code instead of making the C extentions play > nice end behave like python. There's actually more to it than that (it actually resolves various bugs we had in the stdlib that have nothing to do with C extension modules). The details can be found in the PEP. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
> On 15 May 2019, at 07:51, Jonathan Goble wrote: > > That's not a realistic goal; there are some use cases, including in > CPython builtins, that cannot be accomplished without positional-only > arguments. For example, the current behavior of the `dict` constructor > is to accept both certain iterables as a positional-only argument > and/or keyword arguments from which a dict can be created. If the > iterable argument was not positional-only, then it would be forced to > consume a keyword (even if the caller passes it as a positional > argument), meaning that that keyword could never be included in > **kwargs and could not become a dict key via keyword arguments. You lost me. How is this not handled by *args and **kwargs? I think it is. "Positional only" isn't needed in this case. > Additionally, PEP 570 [1], which will add syntax for positional-only > parameters in Python functions, was accepted by Guido last month. I know and in my opinion it's a big mistake. It adapts python to a misfeatures of C extension code instead of making the C extentions play nice end behave like python. But obviously it's too late now. / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
On Wed, May 15, 2019 at 1:37 AM Anders Hovmöller wrote: > > > On 15 May 2019, at 03:07, Robert Vanden Eynde wrote: > > > > Currently if one wants to provide positional arguments after keyword > > arguments, it's not possible, one must begin with positional arguments [1] > > or use keyword arguments [2] : > > I'm my opinion the goal should be that there is no such thing as positional > only arguments in python. It's just a bad idea. No r al arguments that can be > both positional or keyword at the call site, or keyword only. Those are good > and make sense. Adding a third option is just added complexity. That's not a realistic goal; there are some use cases, including in CPython builtins, that cannot be accomplished without positional-only arguments. For example, the current behavior of the `dict` constructor is to accept both certain iterables as a positional-only argument and/or keyword arguments from which a dict can be created. If the iterable argument was not positional-only, then it would be forced to consume a keyword (even if the caller passes it as a positional argument), meaning that that keyword could never be included in **kwargs and could not become a dict key via keyword arguments. Additionally, PEP 570 [1], which will add syntax for positional-only parameters in Python functions, was accepted by Guido last month. [1] https://www.python.org/dev/peps/pep-0570/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
Le mer. 15 mai 2019 à 07:37, Anders Hovmöller a écrit : > > > > On 15 May 2019, at 03:07, Robert Vanden Eynde > wrote: > > > > Currently if one wants to provide positional arguments after keyword > arguments, it's not possible, one must begin with positional arguments [1] > or use keyword arguments [2] : > > In my opinion the goal should be that there is no such thing as positional > only arguments in python. It's just a bad idea. No r al arguments that can > be both positional or keyword at the call site, or keyword only. Those are > good and make sense. Adding a third option is just added complexity. > But what if on the call side the user wants to specify y before x but the definition side wanted "positional only args" for performance reason ? On another note, there's no way to specify "positional only arguments" in "pure python" using a syntax used in the documentation like "def f(x, y, /)" (but def f(*args) will do the trick). > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
> On 15 May 2019, at 03:07, Robert Vanden Eynde wrote: > > Currently if one wants to provide positional arguments after keyword > arguments, it's not possible, one must begin with positional arguments [1] or > use keyword arguments [2] : I'm my opinion the goal should be that there is no such thing as positional only arguments in python. It's just a bad idea. No r al arguments that can be both positional or keyword at the call site, or keyword only. Those are good and make sense. Adding a third option is just added complexity. / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
