3 ms·
Also uses / in the method signatures with no indication of what it means. This article doesn't either. Apparently "It signifies the end of the positional only
by emmelaich 2y ago
Also uses / in the method signatures with no indication of what it means.
This article doesn't either.
Apparently "It signifies the end of the positional only parameters, parameters you cannot use as keyword parameters."
Which is redundant for most functions as they only have positional parameters.
- hermitdev 2y ago> Which is redundant for most functions as they only have positional parameters. Huh? This is not true. def foo(a, b, c): ... This can be invoked as either `foo(1, 2, 3)` or `foo(c=3, b=2, a=1)`: >>> def foo(a, b, c): ... print(f"{a=}") ... print(f"{b=}") ... print(f"{c=}") ... >>> foo(1, 2, 3) a=1 b=2 c=3 >>> foo(c=3, b=2, a=1) a=1 b=2 c=3 >>>
- emmelaich 2y agoHelp on built-in function sin in module math: sin(x, /) Return the sine of x (measured in radians). >>> math.sin(x=2) ~~~~~~~~^^^^^ TypeError: math.sin() takes no keyword arguments / is used everwhere and it's usually just noise. Unexplained noise.
- mananaysiempre 2y agoIt is often used for builtins, because emulating the default Python behaviour of accepting arguments both by position and by name is a pain with the Python/C API. (There are other use cases for positional-only arguments, such as accepting an arbitrary function and an arbitrary set of arguments to call it with at the same time—for example, to invoke it in a new coroutine—but they are pretty rare.) This pecularity of most builtin functions has been there since before Python 3 was a thing, it’s just been undocumented and difficult to emulate in Python before this syntax was introduced. As for unexplained noise—well, all other parts of the function declaration syntax aren’t explained either. You’re expected to know the function declaration syntax in order to read help on individual function declarations; that’s what the syntax reference is for.
- aftbit 2y agoOoh that feature was new to me. See PEP 570[1] for more details. My personal opinion is that this is not something that any code should do... but I'm not the BDFL! 1: https://peps.python.org/pep-0570/ https://peps.python.org/pep-0570/
- mananaysiempre 2y agoOne case where this is very desirable: def spawn_coroutine(func, /, *args, **kwargs): # func can itself have a parameter called 'func' and nothing breaks # we could have the user provide the thunk themselves but that’s inconvenient def thunk(): return func(*args, **kwargs) # put thunk on some sort of task queue... But, as the PEP points out, sometimes you just don’t want the parameter names to be part of your public contract, and it’s nice to have a way to express that.
- deleted 2y ago[deleted]
- masklinn 2y ago> Which is redundant for most functions as they only have positional parameters. It would not need to exist if that were the case. The “default” in Python is that a parameter can be passed both positionally and by keyword. Until Python 3.8, the only way to have positional only parameters in pure Python was to use *args and unpack them yourself.
- thaumasiotes 2y agoWhy does it need to exist even though that's not the case? What's the advantage of stopping someone from naming the parameter when they pass it in?
- apple1417 2y agoReading the PEP for adding it, it seems primarily concerned with mirroring how the C builtins generally don't allow it, for performance. https://peps.python.org/pep-0570/#rationale https://peps.python.org/pep-0570/#rationale That being said, you can find quite a lot of uses in the modules written in Python - though I'm not going to pretend I can tell you the reasoning for all them. grep "/\s*[,)]" /usr/lib/python3.13/ --recursive --include "*.py" --exclude-dir site-packages In my own code, the main use I've found is that they don't "reserve" a slot in kwargs - this is totally valid code: def func(x, /, **kwargs): print(x, kwargs) func(1, x=2) You could've worked around it by taking a dict before, but it's just a lot friendlier being able to take args as normal.
- rtpg 2y agoI did not know that about kwargs! Very interesting and useful to be kind of pedantic and not have unintentional conflicts at that level
- masklinn 2y ago> What's the advantage of stopping someone from naming the parameter when they pass it in? There are cases where a parameter name is worthless on the calling side, this is especially common for unary or binary functions. In that case, the ability to name the parameter on the call site just constrains the implementation, and the overrides (in the case of methods).
- rat87 2y agoIt's not redundant because regular python parameters without a / in the list can be called by name even if they don't have default values. The author may intend them to be positional only but some callers might call them by name and you might break them when you refactor the parameter names, positional only avoids that. Some people dislike positional only parameters but they're already used in a number of stdlib functions written in c so it makes sense to be able to write replacement with the same semantics in pure python as well as being able to express signatures for the c function
- emmelaich 2y agoThat is simply and obviously not true. See my example for math.sin above.
- emmelaich 2y agoMy major point still stands. 1. It's useless noise for something like help(math.sin). 2. It's everywhere and not well documented. Ironical for a help system! Damn it's been hard to improve Python's help system. Python2 didn't have an entry for re.MatchObject. When I mentioned this on irc #python the response was to just google it. Talk about not getting the point. help() should help.
- chthonicdaemon 2y agoIt is not useless noise for something like `help(math.sin)`. The signature displayed by help is `sin(x, /)`, which tells you that `sin(x=1)` will fail. If the signature had just been `sin(x)` then `sin(x=1)` would work.
- emmelaich 2y agoOK you're right. But it wouldn't even have occurred to me to try sin(x=2) until I read sibling comment.
- adammarples 2y agoI guess that's because you don't know how function arguments work in python but that's not really the fault of the help documentation
- emmelaich 2y agoAstonishing. As if help() cannot be improved and this is not a 'fault'.
- throwaway127482 2y agohelp() should not have to re-teach you the syntax of the language every time you look up an individual help topic, though. Even though this "/" stuff is uncommonly used, it seems like it should have its own help topic. Otherwise, this means that help() has to re-explain every piece of syntax that might be considered "uncommonly used", which is kind of hard to draw a line for.
- _Algernon_ 2y agoThe default for python function is that params can be specified as either positional or keyword. / makes params before it positional only while * makes params after it keyword only.