On Sun, 22 Mar 2020 at 15:13, Cameron Simpson <c...@cskk.id.au> wrote: > > On 21Mar2020 12:45, Eric V. Smith <e...@trueblade.com> wrote: > >On 3/21/2020 12:39 PM, Victor Stinner wrote: > >>Well, if CPython is modified to implement tagged pointers and supports > >>storing a short strings (a few latin1 characters) as a pointer, it may > >>become harder to keep the same behavior for "x is y" where x and y are > >>strings. > > Are you suggesting that it could become impossible to write this > function: > > def myself(o): > return o > > and not be able to rely on "o is myself(o)"? That seems... a pretty > nasty breaking change for the language.
Other way around - because strings are immutable, their identity isn't supposed to matter, so it's possible that functions that currently return the exact same object in some cases may in the future start returning a different object with the same value. Right now, in CPython, with no tagged pointers, we return the full existing pointer wherever we can, as that saves us a data copy. With tagged pointers, the pointer storage effectively *is* the instance, so you can't really replicate that existing "copy the reference not the storage" behaviour any more. That said, it's also possible that identity for tagged pointers would be value based (similar to the effect of the small integer cache and string interning), in which case the entire question would become moot. Either way, the PEP shouldn't be specifying that a new object *must* be returned, and it also shouldn't be specifying that the same object *can't* be returned. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NDRZ4G2S2GG74UYBCZ46N7QPL3SFFO5K/ Code of Conduct: http://python.org/psf/codeofconduct/
