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.
Good point. And I guess it's still a problem for interned strings,
since even a copy could be the same object:
s = 'for'
s[:] is 'for'
True
So I now agree with Ned, we shouldn't be prescriptive here, and we
should explicitly say in the PEP that there's no way to tell if the
strip/cut/whatever took place, other than comparing via equality, not
identity.
Unless Victor asserts that a function like myself() above cannot be
relied on to have its return value "is" its passed in value, I disagree.
The beauty of returning the original object on no change is that the
test is O(1) and the criterion is clear. It is easy to document that
stripping an empty affix returns the original string.
I guess a test for len(stripped_string) == len(unstripped_string) is
also O(1), and is less prescriptive. I just don't see the weight to
Ned's characterisation of "a is/is-not b" as overly prescriptive;
returning the same reference as one is given seems nearly the easiest
thing a function can ever do.
Cheers,
Cameron Simpson <[email protected]>
_______________________________________________
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/22RNX6ABI7KATARTGJPHBI3OKAE4XHED/
Code of Conduct: http://python.org/psf/codeofconduct/
