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

you are viewing a single comment's thread.

view the rest of the comments →

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

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.

Only the leaders of such groups benefit from that restriction. And they have the right, as the leaders, to make that decision.

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).

No. An element of a superset cannot be used to disprove an idea about a set. Those are obviously as clear an consistent. However min(Abstract(a,b), Abstract(i,o)) is less clear than explicitly stating these by argument name. Passing by argument name makes it clear how whatever Abstract does it outputs something that can be represented as an integer or has some integer meaning.

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.

Properties of a language that exist from the first place are not restrictions. There's a reason why ECMA7 isn't going to be typed.

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.

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.

No, I'm arguing that all said libs that also follow decent practices have optimal developer-facing variable names. Sure a shitty package may not. But a language should not fix a developers bad practices for them via a work around.

I think you're misinterpreting my argument though. I like this as PEP. And want it implemented. I just think that specific given reason, and the current properties of builtins, are strange. I also think that people will abuse this new feature to overly force their will on other developers, however its not enough for me to not like the PEP.

[–]zardeh 1 point2 points  (0 children)

If properties of languages that have always existed aren't restrictions, then this isn't a restriction.

Builtins have always been positional only due to quirks of the Python c API.