The slash "/" as used in the documentation
tjreedy at udel.edu
Mon Feb 11 02:50:03 EST 2019
On 2/10/2019 11:32 PM, Ian Kelly wrote:
> On Sun, Feb 10, 2019 at 9:34 AM Chris Angelico <rosuav at 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
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
'*' 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
More information about the Python-list