On 2/10/2019 11:32 PM, Ian Kelly wrote:
On Sun, Feb 10, 2019 at 9:34 AM Chris Angelico <ros...@gmail.com> wrote:
Do you ACTUALLY want to call math.sin(x=1.234) or is it purely for the
sake of consistency? Aside from questions about the help format, what
is actually lost by the inability to pass those arguments by name?
No, but I wouldn't object to d.get(key='foo', default=12).
I don't see what dict acccess has to do with function calls. But moving on.
It's partly
about consistency, but mostly I was reacting to Terry's comments in
that a) positional-only arguments are a "limitation"
If one thinks of Python's flexible signatures as 'normal', which they
aren't, than positional-only seems like a limitation. (Some other
languages have somewhat similar flexibility.) From a
C/assembler/machine perspective, positional is normal.
and there is no
desire for the rest of Python to match CPython's behavior in this
instance,
For reasons of complexity and speed, without a countervailing argument,
there is no desire to add to C-coded functions a flexibility that will
mostly not be used.
and b) it sounds like a great deal of effort is being spent
on updating all the C function signatures one at a time
It tends to be done a module per PR. I don't know what effort is needed
since I have never done it.
so that the
help string can be updated to a form that is unfamiliar and not
intuitive
'*' is not 'intuitive either. As I said elsewhere, multiple options
were considered. '/' was the favorite because it is 'connected' to '*'
and more intuitive for dividing a list into two sublists.
Any, IDLE, but not help(), adds a comment to explain.
"['/' marks preceding arguments as positional only]"
The downside is that this and a following blank line add 2 lines to a
calltip that is usually 2 lines, making it more obtrusive. And once '/'
is understood, the comment is extra noise. So I am thinking of
condensing it somehow.
and not normally accessible to pure Python functions without
some arm twisting.
In my first response on this thread I explained and demonstrated how to
access signature strings from Python, as done by both help() and IDLE.
Please read if you are concerned about this. There is hardly any extra
difficulty. I did not discuss how to process the signature string
returned by str(signature) nor how to access the information in
Signature objects otherwise, but the str and Signature docs cover these.
It is possible the a sentence about '/' should be added somewhere.
If every function has to be updated anyway, why not
update them by fixing their signatures?
I proposed this once and the answer was that it would be too costly.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
