I'm not sure why it doesn't special-case it to "".join() One reason might be because you'd have to read the entire iterator to know if it really was only strings. So there are concerns with generators which complicate things a fair bit
On Thu, 17 Jun 2021, 12:12 am Chris Angelico,
On Thu, Jun 17, 2021 at 9:04 AM Christopher Barker
wrote: The performance error for strings should be considered an anomaly, not a feature to be extended to anything that could be used, or misused, with non-linear behaviour.
I’m pretty sure that using sum with strings was a real issue in real
code before it was disallowed.
But the irony is that strings in the cPython interpreter have an
optimization that makes it actually work fine :-(
That *can* make it work. It doesn't always. There are limitations on the optimization.
I’d rather remove the error for strings than add more Type limitations.
I'm not sure why it doesn't special-case it to "".join() instead of erroring out, but presumably there's a good reason. Given that it can't easily be done in a cross-interpreter efficient way, it's better to have people do things in the reliable way rather than depend on a CPython implementation detail. For instance, this code will probably work in CPython:
def modify_file(fn): data = open(fn).read() mutate(data) open(fn, "w").write(data)
But we don't do that, because it won't be reliable on all interpreters.
Are *all* Python interpreters going to be required to optimize strings the way CPython does? If not, it's better to not encourage code to rely on it.
ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3QQSVN... Code of Conduct: http://python.org/psf/codeofconduct/