On Sun, 22 Mar 2020 at 15:13, Cameron Simpson <[email protected]> wrote: > > On 21Mar2020 12:45, Eric V. Smith <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/NDRZ4G2S2GG74UYBCZ46N7QPL3SFFO5K/ Code of Conduct: http://python.org/psf/codeofconduct/
