The slash "/" as used in the documentation

[Terry Reedy]

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
> 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