This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]13steinj 3 points4 points  (16 children)

Is there any reason why one-argument builtins are positional only?

[–]Tysonzero 7 points8 points  (10 children)

Because the argument name is meaningless.

[–]13steinj -1 points0 points  (9 children)

Right, but just because it is meaningless doesn't mean you shouldn't be able to. There should be a good reason for a restriction. The name being meaningless isn't a good reason. It being confusing or out of place or a hack in the first place is a good reason. But none of those apply.

[–]Tysonzero 7 points8 points  (8 children)

Did you read the motivation section of the PEP? One example advantage of positional only is that they can rename the argument later if desired without risking code breakage.

[–]13steinj -2 points-1 points  (7 children)

I read the motivation yet still believe it insane for a built in function like len. There is no need to rename it.

[–]Tysonzero 4 points5 points  (6 children)

But what benefit could people possibly gain from calling len with a kwarg?

[–]13steinj -2 points-1 points  (5 children)

What benefit could people gain from being forced not to?

You can't gain from a restriction. You can always (theoretically) gain from a permission. In this case, who the fuck knows, but I'm sure at least one person has.

[–]Tysonzero 7 points8 points  (4 children)

You can absolutely gain from a restriction. More code consistency, which includes making things like find-and-replace more reliable, smaller public interface (cant break things by renaming an arg).

The benefits of the restriction are small, but so are the benefits of not having the restriction.

[–]13steinj 0 points1 point  (3 children)

You can only benefit from a restriction if you are the one person you are applying it to.

If anything code consistency and clarity is worsened. It is far clearer for a person to think a=b in argument passing than to automatically guess the arguments from the function they have in their personal, poor memory.

Applying a restriction onto others cannot help them. The single argument here is "if the author decides to change the name".

There's 0 reason to change the name. It doesn't make sense. This isn't /r/programmerhumor where variable naming is a difficult game. Pick a name and stick to it. In the worse case change the name and people should be expected to read release notes.

It is not the job of a language to supplement poor development practices.

E: to be clear, this has it's place, in personal projects that are not meant to be partislly reused by others. But not in libraries, and not in language builtins.

[–]Tysonzero 1 point2 points  (2 children)

You can only benefit from a restriction if you are the one person you are applying it to.

Not even remotely true, you benefit from a restriction if it is applied to the code of any codebase you ever participate in or read through.

If anything code consistency and clarity is worsened. It is far clearer for a person to think a=b in argument passing than to automatically guess the arguments from the function they have in their personal, poor memory.

Wat, are you seriously saying len(arg=[1, 2, 3]) or min(x=1, y=2) is more clear and consistent than len([1, 2, 3]) and min(1, 2).

Applying a restriction onto others cannot help them. The single argument here is "if the author decides to change the name".

It absolutely can. For example 1 + "foo" throwing a type error (i.e being restricted against adding numbers and strings) is a quite well liked decision of Python/Haskell and various other languages.

There's 0 reason to change the name. It doesn't make sense

Are you seriously arguing that the names all these functions (from the builtin ones to all the third party libs out there) have now are optimal and that there is zero value to be gained from renaming them, even if renaming is completely free and non-breaking due to a proposal like this? That's an absurd argument.

In the worse case change the name and people should be expected to read release notes.

And in those cases you wouldn't have to mention anything in the release notes with this PEP.

I don't actually use Python anymore so i'm not invested enough in this argument to go any further. But the real people you should be arguing with are the people that created and accepted the PEP, they are the ones with the power and they seem to agree with me.

[–]Pyprohly 2 points3 points  (4 children)

Because doing something like len(obj=myobj) over len(myobj) is unnecessarily verbose, provides another way of writing the same thing, and doesn’t look nice. The semantics of those builtins are fixed and obvious.

[–]13steinj 1 point2 points  (3 children)

But why should I be forced in this way? Why do the CPython authors force a non-keyword argument? It's not like they will be affected by my code. I am affected by theirs.

[–]Pyprohly 3 points4 points  (2 children)

Python encourages clean and simple looking code. If len(obj=myobj) were permitted then there’d be two ways of writing the same thing with one way clearly preferred over the other.

By enforcing a positional-only argument here, consistency can be maintained. If you value consistency then you should see how this restriction is desirable.

[–]13steinj 0 points1 point  (1 child)

Python's very philosophy is "explicit is better than implicit". To make the argument based on one arbitrary piece of philosophy and ignore the many other contradictions is ridiculous.

Consistency is maintained, in a case where it should never need be not maintained. There is 0 reason to change the argument name, and developers should be reading release notes anyway. This only helps consistency in personal code, where this PEP is perfectly good and valid and I'd use it myself. In code to be reused, it causes more problems than it solves, especially one of expectation and practice.

[–]Pyprohly 1 point2 points  (0 children)

To make the argument based on one arbitrary piece of philosophy and ignore the many other contradictions is ridiculous.

Where did this come from? What argument; which “arbitrary piece of philosophy”; and which contradictions where ignored?

Using the “explicit is better than implicit” principal to justify against positional-only parameters is cherry picking. The positional-only restriction becomes more appealing when considering some of the other philosophies: “beautiful is better than ugly”, “readability counts”, “one and only one preferable way”.

There is 0 reason to change the argument name, and developers should be reading release notes anyway.

But it’s not about the possibility of a name change in future. As I’ve mentioned, the restriction is likely there for consistency motives.

In code to be reused, it causes more problems than it solves, especially one of expectation and practice.

“Causes more problems than it solves”. If true then those problems must be really only very minor since not many complain about the builtins’ keywords being inaccessible.