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