[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On Tue, Mar 24, 2020 at 04:53:55PM +0100, Walter Dörwald wrote: > But for `cutprefix()` (or whatever it's going to be called). I'm +1 on > supporting multiple prefixes. For ambiguous cases, IMHO the most > straight forward option would be to chop off the first prefix found. The Zen of Python has something to say about guessing in the face of ambiguity. -- Steven ___ 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/B6VA7OGD7PCIG67OELV2B4ZQK6KFT4Z2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
Thanks for the pointers to emails.
Ethan Furman: "This is why replace() still only takes a single
substring to match and this isn't supported: (...)"
Hum ok, it makes sense. I agree that we can start with only accepting
str (reject tuple), and maybe reconsider the idea of accepting a tuple
of str later.
Please move the idea in Rejected Ideas, but try also to summarize the
reasons why the idea was rejected. I saw:
* surprising result for empty prefix/suffix
* surprising result for "FooBar text".cutprefix(("Foo", "FooBar"))
* issue with unordered sequence like set: only accept tuple which is ordered
* str.replace() only accepts str.replace(str, str) to avoid these
issues: the idea of accepting str.replace(tuple of str, str) or
variant was rejected multiple times. XXX does someone have references
to past discussions? I found https://bugs.python.org/issue33647 which
is a little bit different.
You may mention re.sub() as an existing efficient solution for the
complex cases.
I have to confess that I had to think twice when I wrote my example
line.cutsuffix(("\r\n", "\r", "\n")). Did I write suffixes in the
correct order to get what I expect? :-) "\r\n" starts with "\r".
Victor
Le mer. 25 mars 2020 à 01:44, Dennis Sweeney
a écrit :
>
> There were at least two comments suggesting keeping it to one affix at a time:
>
> https://mail.python.org/archives/list/python-dev@python.org/message/GPXSIDLKTI6WKH5EKJWZEG5KR4AQ6P3J/
>
> https://mail.python.org/archives/list/python-dev@python.org/message/EDWFPEGQBPTQTVZV5NDRC2DLSKCXVJPZ/
>
> But I didn't see any big objections to the rest of the PEP, so I think maybe
> we keep it restricted for now.
> ___
> 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/QBCB2QMUMYBLPXHB6VKIKFK7OODYVKX5/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/XVKF24TEJOCNUTK5IOXJIUOBBC6BNT5K/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On 03/24/2020 06:10 PM, Victor Stinner wrote: Ethan Furman: "This is why replace() still only takes a single substring to match and this isn't supported: (...)" Correction: The above quote belongs to Steven D'Aprano. -- ~Ethan~ ___ 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/62SRLYGK74JGUNVQ4WS63HQOQBW3LOUS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
There were at least two comments suggesting keeping it to one affix at a time: https://mail.python.org/archives/list/python-dev@python.org/message/GPXSIDLKTI6WKH5EKJWZEG5KR4AQ6P3J/ https://mail.python.org/archives/list/python-dev@python.org/message/EDWFPEGQBPTQTVZV5NDRC2DLSKCXVJPZ/ But I didn't see any big objections to the rest of the PEP, so I think maybe we keep it restricted for now. ___ 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/QBCB2QMUMYBLPXHB6VKIKFK7OODYVKX5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
Le mer. 25 mars 2020 à 00:29, Dennis Sweeney
a écrit :
> Lastly, since the issue of multiple prefixes/suffixes is more controversial
> and seems that it would not affect how the single-affix cases would work, I
> can remove that from this PEP and allow someone else with a stronger opinion
> about it to propose and defend a set of semantics in a different PEP. Is
> there any objection to deferring this to a different PEP?
name.cutsuffix(('Mixin', 'Tests', 'Test')) is used in the "Motivating
examples from the Python standard library" section. It looks like a
nice usage of this feature. You added "There were many other such
examples in the stdlib."
What do you mean by controversial? I proposed to raise an empty if the
prefix/suffix is empty to make cutsuffix(("", "suffix")) less
surprising. But I'm also fine if you keep this behavior, since
startswith/endswith accepts an empty string, and someone wrote that
accepting an empty prefix/suffix is an useful feature.
Or did someone write that cutprefix/cutsuffix must not accept a tuple
of strings? (I'm not sure that I was able to read carefully all
emails.)
I like the ability to pass multiple prefixes and suffixes because it
makes the method similar to lstrip(), rstrip(), strip(), startswith(),
endswith() with all accepts multiple "values" (characters to remove,
prefixes, suffixes).
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/IBPEMCBGC5GXUH7BWZPYGWS22WFICN6L/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On 3/24/2020 7:21 PM, Dennis Sweeney wrote: It seems that there is a consensus on the names ``removeprefix`` and ``removesuffix``. I will update the PEP accordingly. I'll also simplify sample Python implementation to primarily reflect *intent* over strict type-checking correctness, and I'll adjust the accompanying commentary accordingly. Lastly, since the issue of multiple prefixes/suffixes is more controversial and seems that it would not affect how the single-affix cases would work, I can remove that from this PEP and allow someone else with a stronger opinion about it to propose and defend a set of semantics in a different PEP. Is there any objection to deferring this to a different PEP? No objection. I think that's a good idea. 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/LPTDYL6ZX47D26B4TGZWR5K6I5PWX77U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
It seems that there is a consensus on the names ``removeprefix`` and ``removesuffix``. I will update the PEP accordingly. I'll also simplify sample Python implementation to primarily reflect *intent* over strict type-checking correctness, and I'll adjust the accompanying commentary accordingly. Lastly, since the issue of multiple prefixes/suffixes is more controversial and seems that it would not affect how the single-affix cases would work, I can remove that from this PEP and allow someone else with a stronger opinion about it to propose and defend a set of semantics in a different PEP. Is there any objection to deferring this to a different PEP? All the best, Dennis ___ 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/5JJ5YDUPCLVYSCCFOI4MQG64SLY22HU5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On 25/03/20 9:14 am, Dennis Sweeney wrote: I think my confusion is about just how precise this sort of "reference implementation" should be. Should it behave with ``str`` and ``tuple`` subclasses exactly how it would when implemented? No, I don't think so. The purpose of a Python implementation of a proposed feature is to get the intended semantics across, not to reproduce all the quirks of an imagined C implementation. If you were to bake these details into a Python reference implementation, you would be implying that these are *intended* restrictions, which (unless I misunderstand) is not what you are intending. (Back when yield-fron was being designed, I described the intended semantics in prose, and gave an approximate Python equivalent, which went through several revisions as we thrashed out exactly how the feature should behave. But I don't think it ever exactly matched all the details of the actual implementation, nor was it intended to. The prose turned out to be much more readable, anway.:-) -- Greg ___ 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/RD72YLECP7WTXVQBRPHECMGHFQGHWYSO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
Dennis Sweeney wrote: Steven D'Aprano wrote: Dennis Sweeney wrote: I think then maybe it would be preferred to use the something like the following in the PEP: def cutprefix(self, prefix, /): if isinstance(prefix, str): if self.startswith(prefix): return self[len(prefix):] return self[:] Didn't we have a discussion about not mandating a copy when nothing changes? For strings, I'd just return self. It is only bytearray that requires a copy to be made. It appears that in CPython, ``self[:] is self`` is true for base ``str`` objects, so I think ``return self[:]`` is consistent with (1) the premise that returning self is an implementation detail that is neither mandated nor forbidden, and (2) the premise that the methods should return base ``str`` objects even when called on ``str`` subclasses. The Python interpreter in my head sees `self[:]` and returns a copy. A note that says a `str` is returned would be more useful than trying to exactly mirror internal details in the Python "roughly equivalent" code. elif isinstance(prefix, tuple): for option in prefix: if self.startswith(option): return self[len(option):] I'd also remove the entire multiple substrings feature, for reasons I've already given. "Compatibility with startswith" is not a good reason to add this feature and you haven't established any good use-cases for it. A closer analog is str.replace(substring, ''), and after almost 30 years of real-world experience, that method still only takes a single substring, not a tuple. The ``test_concurrent_futures.py`` example seemed to be a good use case to me. I agree that it would be good to see how common that actually is though. But it seems to me that any alternative behavior, e.g. repeated removal, could be implemented by a user on top of the remove-only-the-first-found behavior or by fluently chaining multiple method calls. Maybe you're right that it's too complex, but I think it's at least worth discussing. I agree with Steven -- a tuple of options is not necessary for the affix removal methods. -- ~Ethan~ ___ 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/EDWFPEGQBPTQTVZV5NDRC2DLSKCXVJPZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
> -1 on "cut*" (feels too much like what .partition() does) > -0 on "trim*" (this is the name used in .NET instead of "strip", so I > foresee new confusion) > +1 on "remove*" (because this is exactly what it does) I'm also most strongly in favor of "remove*" (out of the above options). I'm opposed to cut*, mainly because it's too ambiguous in comparison to other options such as "remove*" and "replace*", which would do a much better job of explaining the operation performed. Without the .NET conflict, I would normally be +1 on "trim*" as well; with it in mind though, I'd lower it down to +0. Personally, I don't consider a conflict in a different ecosystem enough to lower it down to -0, but it still has some influence on my preference. So far, the consensus seems to be in favor of "remove*" with several +1s and no arguments against it (as far as I can tell), whereas the other options have been rather controversial. On Tue, Mar 24, 2020 at 3:38 PM Steve Dower wrote: > On 24Mar2020 1849, Brett Cannon wrote: > > -1 on "cut*" because my brain keeps reading it as "cute". > > +1 on "trim*" as it is clear what's going on and no confusion with > preexisting methods. > > +1 on "remove*" for the same reasons as "trim*". > > > > And if no consensus is reached in this thread for a name I would assume > the SC is going to ultimately decide on the name if the PEP is accepted as > the burden of being known as "the person who chose _those_ method names on > str" is more than any one person should have bear. ;) > > -1 on "cut*" (feels too much like what .partition() does) > -0 on "trim*" (this is the name used in .NET instead of "strip", so I > foresee new confusion) > +1 on "remove*" (because this is exactly what it does) > > Cheers, > Steve > ___ > 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/KVU75BNXIUBIOYM6ZJSPZSKNRS7Y6CYU/ > 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/EHK7WWVFUOMSD7NJDLOM7S5JKXK6WE3Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
Hello, On Tue, 24 Mar 2020 22:51:55 +0100 Victor Stinner wrote: > > === config.something === > > # If you'd like to remove some prefix from your lines, set it here > > REMOVE_PREFIX = "" > > == > > > > === src.py === > > ... > > line = line.cutprefix(config.REMOVE_PREFIX) > > ... > > == > > Just use: > > if config.REMOVE_PREFIX: > line = line.cutprefix(config.REMOVE_PREFIX) Or even just: if line.startswith(config.REMOVE_PREFIX): line = line[len(config.REMOVE_PREFIX):] But the point taken - indeed, any confusing, inconsistent behavior can be fixed on users' side with more if's, once they discover it. -- Best regards, Paul mailto:pmis...@gmail.com ___ 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/WBPUTU2U5OC6M5GN32GOIJQQGMXLVPAC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On Tue, Mar 24, 2020 at 2:53 PM Ethan Furman wrote: > On 03/24/2020 01:37 PM, Eric V. Smith wrote: > > On 3/24/2020 3:30 PM, Steve Dower wrote: > >> On 24Mar2020 1849, Brett Cannon wrote: > >>> -1 on "cut*" because my brain keeps reading it as "cute". > >>> +1 on "trim*" as it is clear what's going on and no confusion with > preexisting methods. > >>> +1 on "remove*" for the same reasons as "trim*". > >>> > >>> And if no consensus is reached in this thread for a name I would > assume the SC is going to ultimately decide on the name if the PEP is > accepted as the burden of being known as "the person who chose _those_ > method names on str" is more than any one person should have bear. ;) > >> > >> -1 on "cut*" (feels too much like what .partition() does) > >> -0 on "trim*" (this is the name used in .NET instead of "strip", so I > foresee new confusion) > >> +1 on "remove*" (because this is exactly what it does) > I think name choice is easier if you write the documentation first: cutprefix - Removes the specified prefix. trimprefix - Removes the specified prefix. stripprefix - Removes the specified prefix. removeprefix - Removes the specified prefix. Duh. :) ___ 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/45YMVG53WMKN66JXZV7VO2LPFQ5W3Z4F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
Le mar. 24 mars 2020 à 20:06, Paul Sokolovsky a écrit : > === config.something === > # If you'd like to remove some prefix from your lines, set it here > REMOVE_PREFIX = "" > == > > === src.py === > ... > line = line.cutprefix(config.REMOVE_PREFIX) > ... > == Just use: if config.REMOVE_PREFIX: line = line.cutprefix(config.REMOVE_PREFIX) Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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/VUMXNEHLDNKOIAFXVV6CPSRBSAEB5AEI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Moving threadstate to thread-local storage.
Hi Mark, Le mar. 24 mars 2020 à 21:05, Mark Shannon a écrit : > A native thread can only have one Python thread at a time, and must > switch using the PyThreadState_Swap() API. Right. > So, I think the answer is yes. Nice. > Do you have a specific example or testcase? I don't know well the C API of subinterpreters. Usually, I look at _testcapi.run_in_subinterp(). This function is used by multiple unit tests checking the behavior of subinterpreters. -- My expectation is that the different ways to get the current Python thread state works as expected. PyThreadState *tstate = PyThreadState_Get(); /* PyThreadState_GET() is an alias to PyThreadState_Get() */ PyThreadState *tstate = _PyThreadState_GET(); I also expect that tstate->interp is the current interpreter. What is the behavior when the GIL is released? Is tstate equal to NULL when the GIL is released? -- The less clear part is the PyGILState API: PyThreadState *tstate = PyGILState_GetThisThreadState(); Does it return the current Pyhon thread state and is tstate->interp the current interpreter? Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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/LTJKUVFL5YDUBGGIN7NMASB6SVQOTGNS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
Steven D'Aprano wrote: > On Tue, Mar 24, 2020 at 08:14:33PM -, Dennis Sweeney wrote: > > I think then maybe it would be preferred to > > use the something like the following in the PEP: > > def cutprefix(self, prefix, /): > > if isinstance(prefix, str): > > if self.startswith(prefix): > > return self[len(prefix):] > > return self[:] > > > > Didn't we have a discussion about not mandating a copy when nothing > changes? For strings, I'd just return self. It is only bytearray that > requires a copy to be made. It appears that in CPython, ``self[:] is self`` is true for base ``str`` objects, so I think ``return self[:]`` is consistent with (1) the premise that returning self is an implementation detail that is neither mandated nor forbidden, and (2) the premise that the methods should return base ``str`` objects even when called on ``str`` subclasses. > > elif isinstance(prefix, tuple): > > for option in prefix: > > if self.startswith(option): > > return self[len(option):] > > > > I'd also remove the entire multiple substrings feature, for reasons I've > already given. "Compatibility with startswith" is not a good reason to > add this feature and you haven't established any good use-cases for it. > A closer analog is str.replace(substring, ''), and after almost 30 years > of real-world experience, that method still only takes a single > substring, not a tuple. The ``test_concurrent_futures.py`` example seemed to be a good use case to me. I agree that it would be good to see how common that actually is though. But it seems to me that any alternative behavior, e.g. repeated removal, could be implemented by a user on top of the remove-only-the-first-found behavior or by fluently chaining multiple method calls. Maybe you're right that it's too complex, but I think it's at least worth discussing. ___ 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/TRTHGTLOEQXSYYXKQ6RFEXMGDI7O57EL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On 03/24/2020 01:37 PM, Eric V. Smith wrote: On 3/24/2020 3:30 PM, Steve Dower wrote: On 24Mar2020 1849, Brett Cannon wrote: -1 on "cut*" because my brain keeps reading it as "cute". +1 on "trim*" as it is clear what's going on and no confusion with preexisting methods. +1 on "remove*" for the same reasons as "trim*". And if no consensus is reached in this thread for a name I would assume the SC is going to ultimately decide on the name if the PEP is accepted as the burden of being known as "the person who chose _those_ method names on str" is more than any one person should have bear. ;) -1 on "cut*" (feels too much like what .partition() does) -0 on "trim*" (this is the name used in .NET instead of "strip", so I foresee new confusion) +1 on "remove*" (because this is exactly what it does) I actually prefer "without*" because it seems more descriptive, but I don't expect it to get any traction. So "remove" would get my +1. I still think "strip" is the most optimal, as strip, stripprefix, and stripsuffix would all be together -- but if that's not going to happen, "remove" is good. +2 on "strip" ;-) +1 on "remove" -- ~Ethan~ ___ 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/EZLFUTAFMD6PCSVHK7M6L6G2HEXVENXG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On 3/24/2020 3:30 PM, Steve Dower wrote: On 24Mar2020 1849, Brett Cannon wrote: -1 on "cut*" because my brain keeps reading it as "cute". +1 on "trim*" as it is clear what's going on and no confusion with preexisting methods. +1 on "remove*" for the same reasons as "trim*". And if no consensus is reached in this thread for a name I would assume the SC is going to ultimately decide on the name if the PEP is accepted as the burden of being known as "the person who chose _those_ method names on str" is more than any one person should have bear. ;) -1 on "cut*" (feels too much like what .partition() does) -0 on "trim*" (this is the name used in .NET instead of "strip", so I foresee new confusion) +1 on "remove*" (because this is exactly what it does) I actually prefer "without*" because it seems more descriptive, but I don't expect it to get any traction. So "remove" would get my +1. 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/KQNVH74JAZBXLD6YNQSHRQ6UEIKTTMVQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On Tue, Mar 24, 2020 at 11:55 AM Brett Cannon wrote: > -1 on "cut*" because my brain keeps reading it as "cute". > +1 on "trim*" as it is clear what's going on and no confusion with > preexisting methods. > +1 on "remove*" for the same reasons as "trim*". > > And if no consensus is reached in this thread for a name I would assume > the SC is going to ultimately decide on the name if the PEP is accepted as > the burden of being known as "the person who chose _those_ method names on > str" is more than any one person should have bear. ;) > "raymondLuxuryYacht*" pronounced Throatwobbler Mangrove it is! Never fear, the entire stdlib is full of naming inconsistencies and questionable choices accumulated over time. Whatever is chosen will be lost in the noise and people will happily use it. The original PEP mentioned that trim had a different use in PHP which is why I suggest avoiding that one. I don't know how much crossover there actually is between PHP and Python programmers these days outside of FB. -gps * https://montypython.fandom.com/wiki/Raymond_Luxury-Yacht ___ > 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/Z7TK4C5PPECBRTCTPKCJEABFM62TDYWW/ > 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/XC5GLSUXP6RNKEDFDGWLBSKT4TPSP5GU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On Tue, Mar 24, 2020 at 08:14:33PM -, Dennis Sweeney wrote: > I think then maybe it would be preferred to > use the something like the following in the PEP: > > def cutprefix(self, prefix, /): > if isinstance(prefix, str): > if self.startswith(prefix): > return self[len(prefix):] > return self[:] Didn't we have a discussion about not mandating a copy when nothing changes? For strings, I'd just return `self`. It is only bytearray that requires a copy to be made. > elif isinstance(prefix, tuple): > for option in prefix: > if self.startswith(option): > return self[len(option):] I'd also remove the entire multiple substrings feature, for reasons I've already given. "Compatibility with startswith" is not a good reason to add this feature and you haven't established any good use-cases for it. A closer analog is str.replace(substring, ''), and after almost 30 years of real-world experience, that method still only takes a single substring, not a tuple. -- Steven ___ 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/4CL4G4OY2DREUVSOHCYFDLCWGBQ6ULLD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On Tue, Mar 24, 2020 at 08:14:33PM -, Dennis Sweeney wrote: > I think my confusion is about just how precise this sort of "reference > implementation" should be. Should it behave with ``str`` and ``tuple`` > subclasses exactly how it would when implemented? If so, I would expect the > following to work: I think that for the purposes of a relatively straight-forward PEP like this, you should start simple and only add complexity if needed to resolve questions. The Python implementation ought to show the desired semantics, not try to be an exact translation of the C code. Think of the Python equivalents in the itertools docs: https://docs.python.org/3/library/itertools.html See for example: https://www.python.org/dev/peps/pep-0584/#reference-implementation https://www.python.org/dev/peps/pep-0572/#appendix-b-rough-code-translations-for-comprehensions You already state that the methods will show "roughly the following behavior", so there's no expectation that it will be precisely what the real methods do. Aim for clarity over emulation of unusual corner cases. The reference implementation is informative not prescriptive. -- Steven ___ 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/F5Z24BQF5MNHL6BPIQGGIXGH23ZEREFA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
I think my confusion is about just how precise this sort of "reference
implementation" should be. Should it behave with ``str`` and ``tuple``
subclasses exactly how it would when implemented? If so, I would expect the
following to work:
class S(str): __len__ = __getitem__ = __iter__ = None
class T(tuple): __len__ = __getitem__ = __iter__ = None
x = str.cutprefix("FooBar", T(("a", S("Foo"), 17)))
assert x == "Bar"
assert type(x) is str
and so I think the ``str.__getitem__(self, slice(str.__len__(prefix), None))``
monstrosity would be the most technically correct, unless I'm missing
something. But I've never seen Python code so ugly. And I suppose this is a
slippery slope -- should it also guard against people redefining ``len = lambda
x: 5`` and ``str = list`` in the global scope? Clearly not. I think then maybe
it would be preferred to use the something like the following in the PEP:
def cutprefix(self, prefix, /):
if isinstance(prefix, str):
if self.startswith(prefix):
return self[len(prefix):]
return self[:]
elif isinstance(prefix, tuple):
for option in prefix:
if self.startswith(option):
return self[len(option):]
return self[:]
else:
raise TypeError()
def cutsuffix(self, suffix):
if isinstance(suffix, str):
if self.endswith(suffix):
return self[:len(self)-len(suffix)]
return self[:]
elif isinstance(suffix, tuple):
for option in suffix:
if self.endswith(option):
return self[:len(self)-len(option)]
return self[:]
else:
raise TypeError()
The above would fail the assertions as written before, but would pass them for
subclasses ``class S(str): pass`` and ``class T(tuple): pass`` that do not
override any dunder methods. Is this an acceptable compromise if it appears
alongside a clarifying sentence like the following?
These methods should always return base ``str`` objects, even when called
on ``str`` subclasses.
I'm looking for guidance as to whether that's an appropriate level of precision
for a PEP. If so, I'll make that change.
All the best,
Dennis
___
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/PV6ANJL7KN4VHPSNPZSAZGQCEWHEKYG2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Moving threadstate to thread-local storage.
On 24/03/2020 5:26 pm, Victor Stinner wrote: Does it work with subinterepreters? Especially when a native thread has two Python thread states of two different interpreters. A native thread can only have one Python thread at a time, and must switch using the PyThreadState_Swap() API. So, I think the answer is yes. Do you have a specific example or testcase? Victor Le mar. 24 mars 2020 à 16:36, Mark Shannon a écrit : Hi, As an experiment, I thought I would try moving the thread state (what you get from _PyThreadState_GET() ) to TLS. https://github.com/python/cpython/compare/master...markshannon:threadstate_in_tls It works, passing all the tests, and seems sound. It is a small patch (< 50 lines) and doesn't increase the overall code size. My branch is GCC/Clang only, so will need a bit of extra code for Windows. It should only need a few more lines; I haven't done it as I don't have a Windows machine to test it on. This is a *much* cleaner approach to removing the global variable than adding lots of extra parameters all over the place. Cheers, Mark. ___ 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/RPSTDB6AEMIACJFZKCKIRFTVLAJQLAS2/ 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/HMPBCYJOA7X4RNHHWYJYEPSHZFCORICM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On 24Mar2020 1849, Brett Cannon wrote: -1 on "cut*" because my brain keeps reading it as "cute". +1 on "trim*" as it is clear what's going on and no confusion with preexisting methods. +1 on "remove*" for the same reasons as "trim*". And if no consensus is reached in this thread for a name I would assume the SC is going to ultimately decide on the name if the PEP is accepted as the burden of being known as "the person who chose _those_ method names on str" is more than any one person should have bear. ;) -1 on "cut*" (feels too much like what .partition() does) -0 on "trim*" (this is the name used in .NET instead of "strip", so I foresee new confusion) +1 on "remove*" (because this is exactly what it does) Cheers, Steve ___ 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/KVU75BNXIUBIOYM6ZJSPZSKNRS7Y6CYU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
Hello,
On Tue, 24 Mar 2020 19:14:16 +0100
Victor Stinner wrote:
[]
> The behavior of tuple containing an empty string is a little bit
> surprising.
>
> cutsuffix("Hello World", ("", " World")) returns "Hello World",
> whereas cutsuffix("Hello World", (" World", "")) returns "Hello".
>
> cutprefix() has a the same behavior: the first empty strings stops the
> loop and returns the string unchanged.
>
> I would prefer to raise ValueError("empty separator") to avoid any
> risk of confusion. I'm not sure that str.cutprefix("") or
> str.cutsuffix("") does make any sense.
str.cutprefix("")/str.cutsuffix("") definitely makes sense, e.g.:
=== config.something ===
# If you'd like to remove some prefix from your lines, set it here
REMOVE_PREFIX = ""
==
=== src.py ===
...
line = line.cutprefix(config.REMOVE_PREFIX)
...
==
Now one may ask whether str.cutprefix(("", "nonempty")) makes sense.
A response can be "the more complex functionality, the more complex
and confusing corner cases there're to handle".
[]
--
Best regards,
Paul mailto:pmis...@gmail.com
___
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/3M23LCIYMJ4TEQ6GNMHD4NJKTYBMDGGZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
-1 on "cut*" because my brain keeps reading it as "cute". +1 on "trim*" as it is clear what's going on and no confusion with preexisting methods. +1 on "remove*" for the same reasons as "trim*". And if no consensus is reached in this thread for a name I would assume the SC is going to ultimately decide on the name if the PEP is accepted as the burden of being known as "the person who chose _those_ method names on str" is more than any one person should have bear. ;) ___ 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/Z7TK4C5PPECBRTCTPKCJEABFM62TDYWW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
Hi Dennis,
Thanks for the updated PEP, it looks way better! I love the ability to
pass a tuple of strings ;-)
--
The behavior of tuple containing an empty string is a little bit surprising.
cutsuffix("Hello World", ("", " World")) returns "Hello World",
whereas cutsuffix("Hello World", (" World", "")) returns "Hello".
cutprefix() has a the same behavior: the first empty strings stops the
loop and returns the string unchanged.
I would prefer to raise ValueError("empty separator") to avoid any
risk of confusion. I'm not sure that str.cutprefix("") or
str.cutsuffix("") does make any sense.
"abc".startswith("") and "abc".startswith(("", "a")) are true, but
that's fine since startswith() doesn't modify the string. Moreover, we
cannot change the behavior now :-) But for new methods, we can try to
design them correctly to avoid any risk of confusion.
--
It reminds me https://bugs.python.org/issue28029: "".replace("", s, n)
now returns s instead of an empty string for all non-zero n. The
behavior changes in Python 3.9.
There are also discussions about "abc".split("") and
re.compile("").split("abc"). str.split() raises ValueError("empty
separator") whereas re.split returns ['', 'a', 'b', 'c', ''] which can
be (IMO) surprising.
See also https://bugs.python.org/issue28937 "str.split(): allow
removing empty strings (when sep is not None)".
Note: on the other wise, str.strip("") is accepted and returns the
string unmodified. But this method doesn't accept a tuple of
substrings. It's different than cutprefix/cutsuffix.
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/JF22AARPSQSRNFOIAHEILIBDNMSGMYWA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Moving threadstate to thread-local storage.
Does it work with subinterepreters? Especially when a native thread has two Python thread states of two different interpreters. Victor Le mar. 24 mars 2020 à 16:36, Mark Shannon a écrit : > > Hi, > > As an experiment, I thought I would try moving the thread state (what > you get from _PyThreadState_GET() ) to TLS. > > https://github.com/python/cpython/compare/master...markshannon:threadstate_in_tls > > It works, passing all the tests, and seems sound. > > It is a small patch (< 50 lines) and doesn't increase the overall code size. > > My branch is GCC/Clang only, so will need a bit of extra code for > Windows. It should only need a few more lines; I haven't done it as I > don't have a Windows machine to test it on. > > This is a *much* cleaner approach to removing the global variable than > adding lots of extra parameters all over the place. > > > Cheers, > Mark. > ___ > 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/RPSTDB6AEMIACJFZKCKIRFTVLAJQLAS2/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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/AE3PGPFNI7SJL3VZYI5356TIVGAXG76F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On 24 Mar 2020, at 2:42, Steven D'Aprano wrote:
On Sun, Mar 22, 2020 at 10:25:28PM -, Dennis Sweeney wrote:
Changes:
- More complete Python implementation to match what the type
checking in the C implementation would be
- Clarified that returning ``self`` is an optimization
- Added links to past discussions on Python-Ideas and Python-Dev
- Specified ability to accept a tuple of strings
I am concerned about that tuple of strings feature.
[...]
Aside from those questions about the reference implementation, I am
concerned about the feature itself. No other string method that
returns
a modified copy of the string takes a tuple of alternatives.
* startswith and endswith do take a tuple of (pre/suff)ixes, but they
don't return a modified copy; they just return a True or False flag;
* replace does return a modified copy, and only takes a single
substring at a time;
* find/index/partition/split etc don't accept multiple substrings
to search for.
That makes startswith/endswith the unusual ones, and we should be
conservative before emulating them.
Actually I would like for other string methods to gain the ability to
search for/chop off multiple substrings too.
A `find()` that supports multiple search strings (and returns the
leftmost position where a search string can be found) is a great help in
implementing some kind of tokenizer:
```python
def tokenize(source, delimiter):
lastpos = 0
while True:
pos = source.find(delimiter, lastpos)
if pos == -1:
token = source[lastpos:].strip()
if token:
yield token
break
else:
token = source[lastpos:pos].strip()
if token:
yield token
yield source[pos]
lastpos = pos + 1
print(list(tokenize(" [ 1, 2, 3] ", ("[", ",", "]"
```
This would output `['[', '1', ',', '2', ',', '3', ']']` if `str.find()`
supported multiple substring.
Of course to be really usable `find()` would have to return **which**
substring was found, which would make the API more complicated (and
somewhat incompatible with the existing `find()`).
But for `cutprefix()` (or whatever it's going to be called). I'm +1 on
supporting multiple prefixes. For ambiguous cases, IMHO the most
straight forward option would be to chop off the first prefix found.
[...]
Servus,
Walter
___
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/3MYYK6AINVTVCNVYC53FEB4T3LQGPWSC/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Moving threadstate to thread-local storage.
Hi, As an experiment, I thought I would try moving the thread state (what you get from _PyThreadState_GET() ) to TLS. https://github.com/python/cpython/compare/master...markshannon:threadstate_in_tls It works, passing all the tests, and seems sound. It is a small patch (< 50 lines) and doesn't increase the overall code size. My branch is GCC/Clang only, so will need a bit of extra code for Windows. It should only need a few more lines; I haven't done it as I don't have a Windows machine to test it on. This is a *much* cleaner approach to removing the global variable than adding lots of extra parameters all over the place. Cheers, Mark. ___ 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/RPSTDB6AEMIACJFZKCKIRFTVLAJQLAS2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Jump on C by PyEval_SetTrace Python 3.7.7 - SOLUTION
On 3/23/20 11:17 PM, Leandro Müller wrote: Hello Victor Stinner. Thanks. Your tip helped me a lot. I understood that I need to get position on bycode of the line. So I create the funcion to get position inside of the bycode. Now I can to jump the correct position on trace. frame->f_lasti = checkBycodePosition(frame->f_code, 11); There are cases where it is invalid to change f_lineno to avoid a python stack corruption. See the comments of the f_lineno setter frame_setlineno() in Objects/frameobject.c, the comments at the start of the function and inside the code itself. Xavier ___ 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/J55XW45WYEI4F5BUX43OQGPDC7S22MCO/ Code of Conduct: http://python.org/psf/codeofconduct/
