On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote:
I'm not sure what the point of this long spiel about floats and str.upper was.
Half a dozen short paragraphs is a long spiel? Sorry, this isn't Twitter, and sorry for not discussing complicated technical debates using a maximum of 140 characters :-) The point is that you made a statement about the "underlying core principle" being that programs should fail loudly on error. You asked if people disagreed. That depends on what you mean by an error, and it depends on whether the cost of failing loudly is better or worse than doing something else.
No one thinks that zip should always be strict. The feature would be optional and let people choose conveniently between loud failure and silent truncation.
We're not really debating whether or not people should be permitted to verify the length of input to zip. They have always been able to do this. We're debating whether or not this functionality is important enough to be in the stdlib or a builtin, and if so, what API it ought to have.
But I question whether *enough* people need it *often enough* to make it a builtin, or to put a flag on plain zip.
Well, let's add some data about people needing it.
Nicely collected. Especially since you have found that my own opinion on this seems to have changed over the years. What can I say? Opinions change, and my opinion may change again in the future.
- Is it complicated to get right? No.
I would say yes. Look at the SO question for example. The asker wrote a long, slow, complicated solution and had to ask if it was good enough.
On its own this is evidence that it should be a recipe in itertools. Not every Python programmer who can't put put together a six line solution out of the tools in itertools is evidence that it should be built-in. I'm sure that I've built some pretty hairy and unnecessarily complicated and fragile code in the past, and by "past" I include yesterday :-) Should my inability to write a function well mean that it needs to be added to the builtins? I don't think so. There's a vocal group of people who want to strip the stdlib down to bare essentials (whatever that means!). We don't need to agree with that to nevertheless agree to be cautious about adding new things to the language. [...]
I think a major factor here is laziness. I'm pretty sure that sometimes I've wanted this kind of strict check, just for better peace of mind, but the thought of one of the solutions above feels like too much effort.
Right, this is a very important point. "Put it on PyPI" is often just a way to dismiss a proposal. Hardly anyone is going to add a third-party dependency from some unknown individual with just one function. We're not like the node.js community and their one-liner external dependencies :-) But adding a well-known dependency with dozens of functions, like more-itertools, that is a viable solution for many people. That pushes the balance towards "just use more-itertools". On the third hand, Brandt's ast bug pushes the balance slightly back towards "put it in the stdlib". (If these decisions were easy, we wouldn't have long debates on Python-Ideas about them.)
I don't want to add a third party dependency just for this. I don't want to read someone else's solution (e.g. on SO) which doesn't have tests and try to evaluate if it's correct.
Yes, but that's true for every and any function. Does everything need to be a builtin, because we are lazy and don't want to use third party dependencies or test SO code before using it? Clearly not. So we have to ask why *this* function is more important than the thousands of other functions on SO and in third-party libraries that it should be a builtin.
The problem is that no one really *needs* this check. You *can* do without it.
"Nobody needs this, therefore it should be a builtin" is a pretty unusual argument. If this is of marginal usefulness, do we really need to bloat the builtins with it? Put it in itertools next to zip_longest. Those who need it can import it. -- Steven