On 6/17/2022 10:53 AM, Chris Angelico wrote:
The only two possible behaviours are:
1) It does the single obvious thing: n defaults to the length of items, and items defaults to an empty tuple. 2) It raises UnboundLocalError if you omit n. ... Would you prefer that I simply mandate that it be permitted, and then a future version of Python changes it to be an exception? Or the other way around? Because I could do that. Maybe it would reduce the arguments. Pun intended, and I am not apologizing for it.
A third option would be that it's a syntax error for you to define such a function. This would be my preferred approach. This way, you can always assign semantics in the future. Sure, there are some cases you might want to support with the as-specified undefined behavior, but I don't think that's a good design. If CPython 3.x works a certain way (especially if there's a test for it), you can be sure that other implementations will work the same way, and you can be sure that you can never change the behavior in the future. No amount of "but we said it was undefined" will allow us to change such behavior. It would be like 3.7 saying "yeah, we said dicts are ordered in 3.6 but you shouldn't count on it, so we're going to make them unordered in 3.7". It would just never happen. That all said, I'm still -1 on this PEP, for reasons I won't rehash. Eric