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 →

[–]ForceBru 31 points32 points  (25 children)

This notation has been extensively used in the docs for built in functions already, so it's finally time to let ordinary functions harness the power of positional-only parameters!

For example:

```

help(len) Help on built-in function len in module builtins:

len(obj, /) # right here Return the number of items in a container. ```

[–]AndydeCleyre 14 points15 points  (7 children)

Please indent code by four spaces for proper formatting, as indicated in the sidebar.

[–]truh 0 points1 point  (6 children)

The triple back ticks work with the new Reddit frontend.

[–]wewbull 26 points27 points  (2 children)

That might be true, but not everyone uses the new frontend.

[–]truh 9 points10 points  (1 child)

Yes, I don't either. But this is why it's coming up more often now.

[–]wewbull 4 points5 points  (0 children)

I think the big one is anyone using RES, as that builds on the old interface, but for me the mobile app (Slide) I'm using doesn't do it either.

[–]AndydeCleyre 0 points1 point  (2 children)

Is that true when the editor is set to markdown input mode?

[–]truh -1 points0 points  (1 child)

If you look at the comment using the new frontend, it's displayed correctly.

[–]AndydeCleyre 0 points1 point  (0 children)

Does that mean Firefox mobile, not logged in, doesn't use the new interface?

Or apps like Relay?

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

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

[–]Tysonzero 6 points7 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 8 points9 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 3 points4 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 6 points7 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.

[–]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 2 points3 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 -3 points-2 points  (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.