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/
