Sorry, I think I accidentally left out a clause here - I meant that the rationale for /always returning a 'str'/ (as opposed to returning a subclass) is missing, it just says in the PEP:
> The only difference between the real implementation and the above is > that, as with other string methods like replace, the methods will > raise a TypeError if any of self, pre or suf is not an instace of str, > and will cast subclasses of str to builtin str objects. I think the rationale for these differences is not made entirely clear, specifically the "and will cast subclasses of str to builtin str objects" part. I think it would be best to define the truncation in terms of __getitem__ - possibly with the caveat that implementations are allowed (but not required) to return `self` unchanged if no match is found. Best, Paul P.S. Dennis - just noticed in this reply that there is a typo in the PEP - s/instace/instance On 3/22/20 12:15 PM, Victor Stinner wrote: > tl; dr A method implemented in C is more efficient than hand-written > pure-Python code, and it's less error-prone > > I don't think if it has already been said previously, but I hate > having to compute manually the string length when writing: > > if line.startswith("prefix"): line = line[6:] > > Usually what I do is to open a Python REPL and I type: len("prefix") > and copy-paste the result :-) > > Passing directly the length is a risk of mistake. What if I write > line[7:] and it works most of the time because of a space, but > sometimes the space is omitted randomly and the application fails? > > -- > > The lazy approach is: > > if line.startswith("prefix"): line = line[len("prefix"):] > > Such code makes my "micro-optimizer hearth" bleeding since I know that > Python is stupid and calls len() at runtime, the compiler is unable to > optimize it (sadly for good reasons, len name can be overriden) :-( > > => line.cutprefix("prefix") is more efficient! ;-) It's also also shorter. > > Victor > > Le dim. 22 mars 2020 à 17:02, Paul Ganssle <p...@ganssle.io> a écrit : >> I don't see any rationale in the PEP or in the python-ideas thread >> (admittedly I didn't read the whole thing, I just Ctrl + F-ed "subclass" >> there). Is this just for consistency with other methods like .casefold? >> >> I can understand why you'd want it to be consistent, but I think it's >> misguided in this case. It adds unnecessary complexity for subclass >> implementers to need to re-implement these two additional methods, and I >> can see no obvious reason why this behavior would be necessary, since >> these methods can be implemented in terms of string slicing. >> >> Even if you wanted to use `str`-specific optimizations in C that aren't >> available if you are constrained to use the subclass's __getitem__, it's >> inexpensive to add a "PyUnicode_CheckExact(self)" check to hit a "fast >> path" that doesn't use slice. >> >> I think defining this in terms of string slicing makes the most sense >> (and, notably, slice itself returns `str` unless explicitly overridden, >> the default is for it to return `str` anyway...). >> >> Either way, it would be nice to see the rationale included in the PEP >> somewhere. >> >> Best, >> Paul >> >> On 3/22/20 7:16 AM, Eric V. Smith wrote: >>> On 3/22/2020 1:42 AM, Nick Coghlan wrote: >>>> 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. >>> Agreed. I think the PEP should say that a str will be returned (in the >>> event of a subclass, assuming that's what we decide), but if the >>> argument is exactly a str, that it may or may not return the original >>> object. >>> >>> Eric >>> >>> _______________________________________________ >>> 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/JHM7T6JZU56PWYRJDG45HMRBXE3CBXMX/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >> _______________________________________________ >> 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/RTQWEE4KZYIIXL3HK3C6IJ2ATQ6CM7PG/ >> Code of Conduct: http://python.org/psf/codeofconduct/ > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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/6563MZW5CPYLR6ESMIVYOS32BZ2PAFDJ/ Code of Conduct: http://python.org/psf/codeofconduct/