On Thu, Jun 17, 2021 at 9:04 AM Christopher Barker <python...@gmail.com> 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-le...@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/3QQSVNJ3DSNQSHNEMJIY6TKX2QDOO7U2/ Code of Conduct: http://python.org/psf/codeofconduct/