TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Positional-only Parameters for Python

76 pointsby l2dyabout 6 years ago

12 comments

js2about 6 years ago
&gt; Over time, we’ve had a trend of adding unnecessary, low-payoff complexity to the language. Cumulatively, it has greatly increased the mental load for newcomers and for occasional users.<p>I couldn&#x27;t agree more with this sentiment from Raymond Hettinger. I first learned Python starting with 1.5.2, and coming from a background of C and Perl. One of the things that really attracted me to the language was how compact it was. It took no more than an hour to learn most of the language, a day to read the entire spec, and maybe a second day to read the entire standard library documentation. It suffered from virtually no gotchas... nothing crazy like Perl&#x27;s scalar vs list context, etc.<p>I haven&#x27;t had trouble keeping pace with Python and I even probably agree with most of its changes. But this change really seems superfluous. How does it fit into the zen?<p>Can a language ever reach a point of being done?
评论 #19700358 未加载
评论 #19701313 未加载
评论 #19700466 未加载
评论 #19701031 未加载
评论 #19701095 未加载
评论 #19700324 未加载
评论 #19700704 未加载
评论 #19701621 未加载
评论 #19702771 未加载
评论 #19701968 未加载
ak217about 6 years ago
Keyword arguments are safer and more explicit&#x2F;self-documenting. It&#x27;s not clear that further accommodations for positional arguments are needed, except in variadic situations as described in <a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-3102&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-3102&#x2F;</a>. I would argue the use case described in the &quot;background&quot; section constitutes an unsafe level of uncertainty.<p>One important use case for the existing facilities is to take a function whose signature used to contain positionals, and migrate a positional to be a keyword argument without breaking existing uses of the API.<p>I think `&#x2F;` is a poor choice of symbol, too. If such a separator were to be a good idea, it should be <i></i>* <i></i>* by analogy with `*` for separating keyword-only args.
评论 #19700537 未加载
评论 #19700330 未加载
评论 #19700126 未加载
alexbeckerabout 6 years ago
Some people are saying the syntax is ugly, and I agree. But it addresses a real problem in Python: the names of the arguments of your public functions are also part of your public API (since they can be called as kwargs). In my experience, this is rarely desirable and makes fixing bad names unnecessarily hard.
评论 #19700411 未加载
评论 #19702086 未加载
twicabout 6 years ago
This seems pretty nuts. I&#x27;m with Steve Dower here - make all parameters allowed as keyword arguments.<p>Guido&#x27;s objection that &quot;writing len(obj=configurations) is not something we want to encourage&quot; makes not one iota of sense. Allowing it is not encouraging it.<p>There&#x27;s mention of one bug which allegedly could have been fixed with positional-only parameters:<p><a href="https:&#x2F;&#x2F;bugs.python.org&#x2F;issue9137" rel="nofollow">https:&#x2F;&#x2F;bugs.python.org&#x2F;issue9137</a><p>The bug here is that dicts have an update method which you can call two ways, by passing a single dict, or with keyword arguments, and if you try to call the single-dict version using a named parameter, it&#x27;s not clear what should happen, and at one point, for OrderedDict, it could end up throwing an exception.<p>But the mistake here isn&#x27;t confusing parameters, it&#x27;s having a single method that you can call in two different ways. That sort of thing might fly in Perl, but it&#x27;s a source of ambiguity and confusion that, IMHO, is not up to Python&#x27;s standards.
vharuckabout 6 years ago
The arguments for this change undervalue one of my favorite things about Python: developer freedom. The language is versatile to the point of being inefficient, but that lets me adapt it as necessary. Just because they can&#x27;t imagine a situation where this change would be a roadblock doesn&#x27;t mean it won&#x27;t happen. What about building an argument list with a dictionary and then passing it as an expanded dictionary?<p>Also, I don&#x27;t like the idea that package developers&#x27; opinions on what&#x27;s &quot;readable code&quot; outrank mine, when we&#x27;re talking about <i>my</i> code.
ram_rarabout 6 years ago
The more and more I see the direction python is taking, the more it feels like python will eventually become the new Perl. I honestly feel, if Python 2.7+ had &quot;fixed&quot; unicode and included orderedDict (which I guess came after 3.5) I would happily stay with it.
评论 #19702707 未加载
kevin_thibedeauabout 6 years ago
If backward compatibility is a goal, one can&#x27;t make capricious changes to the order of positional args. It seems pointless to make special provisions to prevent named args for the sake of &quot;more flexibility&quot; when positional is decidedly less flexible.<p>You can always opt for dict args if you want to change a signature and maintain backwards compatibility with obsolescent arg names.<p>If I was BDFL this would be a dead issue.
verisimilitudesabout 6 years ago
I do find having keyword parameters for free, as Ada does, to be an interesting feature, but the need to make the parameter names part of the interface is a drawback. Common Lisp separates positional parameters and keywords, but at the cost of some efficiency and yet other drawbacks.<p>In general, though, I don&#x27;t see the issue with always needing to pick good names. It&#x27;s very simple to use single-character names if one needs to, such as for a mathematical function, or simply a procedure where the letters have clear meanings or will likely never be used to start with.<p>Asides from the design features I thought were jokes when I first learned of them, such as one-line lambdas and whatnot, this &#x27;&#x27;beginner&#x27;s language&#x27;&#x27; certainly has a great deal of complicated syntax sugar and other things being added to it.
xisukarabout 6 years ago
In Raku, parameters can be either positional or named parameters (declared with the colon-pair syntax). However, from what I understand, only positional parameters can be passed as positional and named parameters as named. The closest Raku subroutine to Python&#x27;s `def fun(a, b, c=None)` would be:<p><pre><code> sub fun($a, $b, :$c) { } fun(1, 2) # This works! fun(1, 2, 3) # Error: Too many positionals passed... fun(:a(1), :b(2), :c(3)) # Error: Too few positionals passed... fun(:c(3), :a(1), :b(2)) # Same as before fun(:c(3), 1, 2) # This works! </code></pre> Positional parameters are required by default but they can be made optional by providing a default value in the subroutine&#x27;s signature or by placing a `?` right after the parameter. However, much like Python, positional parameters must appear before optional parameters:<p><pre><code> sub fun($b, $a?, :$c) { } fun(1) # This works! </code></pre> On the other hand, named parameter, as evidenced by the first code snippet, are optional. However, they can be made required by placing a `!` right after the parameter:<p><pre><code> sub fun($a, $b, :$c!) { } fun(1, 2) # Error: Required named parameter &#x27;c&#x27; not passed fun(1, 2, :c(3)) # This works! </code></pre> Remaining arguments can be slurped by using slurpy parameters. In its most basic form, slurpy positional parameters are indicated with `A` followed by an array parameter:<p><pre><code> sub fun($a, $b, A@rest) { } </code></pre> However, regardless of the structure of the arguments, they are flatten. This automatic flattening can be avoided by using `AA` instead. Or it can be done conditionally by using `+`: If there&#x27;s a single argument, flaten it. Else, leave them alone.<p>Slurpy named parameters are indicated also with `A` followed by a hash parameter:<p><pre><code> sub fun(:$c, :$d, A%rest) { } </code></pre> Both can be used in conjunction:<p><pre><code> sub fun($a, $b, :$c, :$d, A@rest, A%rest) { } # Or: sub fun($a, $b, A@rest, :$c, :$d, A%rest) { } </code></pre> Edit: HN eats up the asterisks so using `A` to stand for asterisk.
ameliusabout 6 years ago
There is a simple solution to this problem. Just name your parameters like this:<p><pre><code> def fun(parameter1, parameter2, parameter3): a = parameter1 b = parameter2 c = parameter3 ... (rest of function) </code></pre> This also helps the user to see in an eyeblink which position corresponds to which parameter.
r0f1about 6 years ago
Is this a new thing? I thought that was possible in Python already. Look at the numpy documentation: <a href="https:&#x2F;&#x2F;docs.scipy.org&#x2F;doc&#x2F;numpy&#x2F;reference&#x2F;generated&#x2F;numpy.maximum.html" rel="nofollow">https:&#x2F;&#x2F;docs.scipy.org&#x2F;doc&#x2F;numpy&#x2F;reference&#x2F;generated&#x2F;numpy.m...</a>. There, they already use the &#x2F; for positional-only arguments.
评论 #19700379 未加载
twicabout 6 years ago
You can already do:<p><pre><code> def show((a, b, c)): print &#x27;a = %s, b = %s, c = %s&#x27; % (a, b, c) </code></pre> And there&#x27;s no way to pass a, b, and c other than positionally. You can write:<p><pre><code> show((1, 2, 3)) </code></pre> But not:<p><pre><code> show((a=1, b=2, c=3))</code></pre>
评论 #19703364 未加载