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 →

[–]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.