Please consider adding underscores to the names: remove_prefix() and
remove_suffix().
The latter method causes a mental hiccup when first read as removes-uffix,
forcing mental backtracking to get to remove-suffix. We had a similar problem
with addinfourl initially being read as add-in-four-l
Congrats Dennis! I hope your PR lands soon.
On Mon, Apr 20, 2020 at 12:40 PM Eric V. Smith wrote:
> Congratulations, Dennis!
>
> Not 10 minutes ago I was writing code that could have used this
> functionality. And I got it wrong on my first attempt! I'm looking
> forward to it in 3.9.
>
> Eric
Congratulations, Dennis!
Not 10 minutes ago I was writing code that could have used this
functionality. And I got it wrong on my first attempt! I'm looking
forward to it in 3.9.
Eric
On 4/20/2020 2:26 PM, Victor Stinner wrote:
Hi,
The Python Steering Council accepts the PEP 616 "String
On Thu., 2 Apr. 2020, 8:30 am Victor Stinner, wrote:
> I suggest you to wait one more week to let other people comment the
> PEP. After this delay, if you consider that the PEP is ready for
> pronouncement, you can submit it to the Steering Council, right.
>
Note that the submission to the
On Sat., 28 Mar. 2020, 8:39 am Guido van Rossum, wrote:
> On Fri, Mar 27, 2020 at 3:29 PM Dennis Sweeney <
> sweeney.dennis...@gmail.com> wrote:
>
>> > If I saw that in a code review I'd flag it for non-obviousness. One
>> should
>> > use 'string != new_string' unless there is severe pressure to
I suggest you to wait one more week to let other people comment the
PEP. After this delay, if you consider that the PEP is ready for
pronouncement, you can submit it to the Steering Council, right.
Victor
Le mer. 1 avr. 2020 à 21:56, Dennis Sweeney
a écrit :
>
> Hello all,
>
> It seems that
Hello all,
It seems that most of the discussion has settled down, but I didn't quite
understand from reading PEP 1 what the next step should be -- is this an
appropriate time to open an issue on the Steering Council GitHub repository
requesting pronouncement on PEP 616?
Best,
Dennis
My intent is to help people like me to follow the discussion on the
PEP. There are more than 100 messages, it's hard to follow PEP
updates.
Victor
Le dim. 29 mars 2020 à 14:55, Rob Cliffe via Python-Dev
a écrit :
>
>
>
> On 28/03/2020 17:02, Victor Stinner wrote:
> > What do you think of adding
On 28/03/2020 17:02, Victor Stinner wrote:
What do you think of adding a Version History section which lists most
important changes since your proposed the first version of the PEP? I
recall:
* Version 3: don't accept tuple
* Version 2: Rename cutprefix/cutsuffix to removeprefix/removesuffix,
Sure -- I can add in a short list of those major changes.
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
On 3/26/2020 9:10 PM, Ethan Furman wrote:
First off, thank you for being so patient -- trying to champion a PEP
can be exhausting.
On 03/26/2020 05:22 PM, Dennis Sweeney wrote:
So now if I understand the dilemma up to this point we have:
Benefits of writing ``return self`` in the PEP:
a
What do you think of adding a Version History section which lists most
important changes since your proposed the first version of the PEP? I
recall:
* Version 3: don't accept tuple
* Version 2: Rename cutprefix/cutsuffix to removeprefix/removesuffix,
accept tuple
* Version 1: initial version
For
PEP 616 -- String methods to remove prefixes and suffixes
is available here: https://www.python.org/dev/peps/pep-0616/
Changes:
- Only accept single affixes, not tuples
- Make the specification more concise
- Make fewer stylistic prescriptions for usage
- Fix typos
A reference implementation
On Fri, Mar 27, 2020 at 3:29 PM Dennis Sweeney
wrote:
> > > One may also continue using ``startswith()``
> > > and ``endswith()``
> > > methods for control flow instead of testing the lengths as above.
> > >
> > > That's worse, in a sense, since "foofoobar".removeprefix("foo") returns
> >
> > One may also continue using ``startswith()``
> > and ``endswith()``
> > methods for control flow instead of testing the lengths as above.
> >
> > That's worse, in a sense, since "foofoobar".removeprefix("foo") returns
> "foobar" which still starts with "foo".
I meant that startswith might be
On Fri, Mar 27, 2020 at 1:55 PM Dennis Sweeney
wrote:
> I like how that would take the pressure off of the Python sample. How's
> something like this?
>
> Specification
> =
>
> The builtin ``str`` class will gain two new methods which will behave
> as follows when
I like how that would take the pressure off of the Python sample. How's
something like this?
Specification
=
The builtin ``str`` class will gain two new methods which will behave
as follows when ``type(self) is str``::
def removeprefix(self: str, prefix:
How about just presenting pseudo code with the caveat that that's for the
base str and bytes classes only, and then stipulating that for subclasses
the return value is still a str/bytes/bytearray instance, and leaving it at
that? After all the point of the Python code is to show what the C code
I was trying to start with the the intended behavior of the str class, then
move on to generalizing to other classes, because I think completing a single
example and *then* generalizing is an instructional style that's easier to
digest, whereas intermixing all of the examples at once can get
I appreciate the input and attention to detail!
Using the ``str()`` constructor was sort of what I had thought originally, and
that's why I had gone overboard with "casting" in one iteration of the sample
code. When I realized that this isn't quite "casting" and that ``__str__`` can
be
On Wed, Mar 25, 2020 at 5:42 PM Dennis Sweeney
wrote:
> I'm removing the tuple feature from this PEP. So now, if I understand
> correctly, I don't think there's disagreement about behavior, just about
> how that behavior should be summarized in Python code.
> [...]
> return (the original
On Sun, Mar 22, 2020 at 05:00:10AM -, Dennis Sweeney wrote:
> I like "removeprefix" and "removesuffix". My only concern before had
> been length, but three more characters than "cut***fix" is a small
> price to pay for clarity.
I personally rely on auto-complete of my editor while writing.
First off, thank you for being so patient -- trying to champion a PEP can be
exhausting.
On 03/26/2020 05:22 PM, Dennis Sweeney wrote:
Ethan Furman wrote:
I don't understand that list bit -- surely, if I'm bothering to implement
removeprefix and removesuffix in my subclass, I would also
> I don't understand that list bit -- surely, if I'm bothering to implement
> removeprefix and removesuffix in my subclass, I would also want
> to
> return self to keep my subclass? Why would I want to go through the extra
> overhead of either calling my own __getitem__ method, or have the
>
Am 26.03.20 um 06:28 schrieb Cameron Simpson:
On 24Mar2020 18:49, 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*".
I
> I imagine it's an implementation detail of which ones depend on
> ``__getitem__``.
If we write
class MyStr(str):
def __getitem__(self, key):
raise ZeroDivisionError()
then all of the assertions from before still pass, so in fact *none* of
the methods rely on
On 25Mar2020 08:14, Paul Moore wrote:
[...] The issue for me is how the function
should behave with a list of affixes if one is a prefix of another,
e.g.,removeprefix(('Test', 'Tests')). The empty string case is just
one form of that. The behaviour should be defined clearly, and while I
imagine
On 24Mar2020 18:49, 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*".
I reiterate my huge -1 on "trim" because it will confuse
On Tue, Mar 24, 2020 at 07:14:16PM +0100, Victor Stinner wrote:
> 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.
They make as much sense as any other null-operation, such as
I imagine it's an implementation detail of which ones depend on __getitem__.
The only methods that would be reasonably amenable to a guarantee like
"always returns the same thing as __getitem__" would be (l|r|)strip(),
split(), splitlines(), and .partition(), because they only work with
subsets
I was surprised by the following behavior:
class MyStr(str):
def __getitem__(self, key):
if isinstance(key, slice) and key.start is key.stop is key.end:
return self
return type(self)(super().__getitem__(key))
my_foo = MyStr("foo")
Dennis Sweeney wrote:
---
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
I've said a few times that I think it would be good if the behavior were
defined /in terms of __getitem__/'s behavior. If the rough behavior is this:
def removeprefix(self, prefix):
if self.startswith(prefix):
return self[len(prefix):]
else:
return self[:]
Then you can
On 3/25/2020 1:36 PM, Dennis Sweeney wrote:
I'm removing the tuple feature from this PEP. So now, if I understand
correctly, I don't think there's disagreement about behavior, just about
how that behavior should be summarized in Python code.
I think that's right.
Ethan Furman wrote:
It
I'm removing the tuple feature from this PEP. So now, if I understand
correctly, I don't think there's disagreement about behavior, just about
how that behavior should be summarized in Python code.
Ethan Furman wrote:
> > It appears that in CPython, self[:] is self is true for base
> > str
> >
On 25 Mar 2020, at 9:48, Stephen J. Turnbull wrote:
Walter Dörwald writes:
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:
In other words, you want the
Walter Dörwald writes:
> 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:
In other words, you want the equivalent of Emacs's "(search-forward
(regexp-opt
On Wed, 25 Mar 2020 at 00:42, Dennis Sweeney
wrote:
>
> 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/
>
>
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
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
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
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
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
>
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
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.
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
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
> -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
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)
> > ...
> > ==
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
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
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
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
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
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
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):
>
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
>
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
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
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".
>
>
-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
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", ("
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
On 24/03/20 3:43 pm, Dennis Sweeney wrote:
This was an attempt to ensure no one can do funny business with tuple
or str subclassing. I was trying to emulate the ``PyTuple_Check``
followed by ``PyTuple_GET_SIZE`` and ``PyTuple_GET_ITEM`` that are
done by the C implementation of
Steven D'Aprano wrote:
> Having confirmed that prefix is a tuple, you call tuple() to
> make a copy of it in order to iterate over it. Why?
>
> Having confirmed that option is a string, you call str() on
> it to (potentially) make a copy. Why?
This was an attempt to ensure no one can do funny
This should be fixed 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
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
Cameron Simpson writes:
> As a diversion, _are_ there use cases where an empty affix is useful or
> reasonable or likely?
In the "raise on failure" design,
"aba".cutsuffix('.doc')
raises,
"aba".cutsuffix('.doc', '')
returns "aba".
BTW, since I'm here, thanks for your discussion of
On 22Mar2020 23:33, Rob Cliffe wrote:
Sorry, another niggle re handling an empty affix: With your Python
implementation,
'aba'.cutprefix(('', 'a')) == 'aba'
'aba'.cutsuffix(('', 'a')) == 'ab'
This seems surprising.
That surprises me too. I expect the first matching affix to be used. It
is
Sorry, another niggle re handling an empty affix: With your Python
implementation,
'aba'.cutprefix(('', 'a')) == 'aba'
'aba'.cutsuffix(('', 'a')) == 'ab'
This seems surprising.
Rob Gadfly Cliffe
On 22/03/2020 23:23, Dennis Sweeney wrote:
Much appreciated! I will add that single quote and
On 3/23/2020 12:02 PM, Rhodri James wrote:
On 23/03/2020 14:50, Dan Stromberg wrote:
I tend to be mistrustful of code that tries to guess the best thing
to do,
when something expected isn't found.
How about:
def cutprefix(self: str, pre: str, raise_on_no_match: bool=False, /)
-> str:
On 23/03/2020 14:50, Dan Stromberg wrote:
On Fri, Mar 20, 2020 at 3:28 PM Victor Stinner wrote:
The builtin ``str`` class will gain two new methods with roughly the
following behavior::
def cutprefix(self: str, pre: str, /) -> str:
if self.startswith(pre):
return
On Fri, Mar 20, 2020 at 3:28 PM Victor Stinner wrote:
> > The builtin ``str`` class will gain two new methods with roughly the
> > following behavior::
> >
> > def cutprefix(self: str, pre: str, /) -> str:
> > if self.startswith(pre):
> > return self[len(pre):]
> >
Much appreciated! I will add that single quote and change those snippets to::
>>> s = 'FooBar' * 100 + 'Baz'
>>> prefixes = ('Bar', 'Foo')
>>> while len(s) != len(s := s.cutprefix(prefixes)): pass
>>> s
'Baz'
and::
>>> s = 'FooBar' * 100 + 'Baz'
>>> prefixes = ('Bar', 'Foo')
>>> while
On 22/03/2020 22:25, Dennis Sweeney wrote:
Here's an updated version.
Online: https://www.python.org/dev/peps/pep-0616/
Source: https://raw.githubusercontent.com/python/peps/master/pep-0616.rst
Changes:
- More complete Python implementation to match what the type checking in
the C
Here's an updated version.
Online: https://www.python.org/dev/peps/pep-0616/
Source: https://raw.githubusercontent.com/python/peps/master/pep-0616.rst
Changes:
- More complete Python implementation to match what the type checking in
the C implementation would be
- Clarified that
> And we *have* to decide that it returns a plain str instance if called
> on a subclass instance (unless overridden, of course) since the base
> class (str) won't know the signature of the subclass constructor.
> That's also why all other str methods return an instance of plain str
> when called
On 2020-03-21 20:38, Guido van Rossum wrote:
It's not great, and I actually think that "stripprefix" and "stripsuffix" are
reasonable. (I found that in Go, everything we call "strip" is called "Trim",
and there are "TrimPrefix" and "TrimSuffix" functions that correspond to the PEP
616
On Sun, Mar 22, 2020 at 4:20 AM Eric V. Smith wrote:
> 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.
>
Yes. Returning
On 2020-03-22 05:00, Dennis Sweeney wrote:
I like "removeprefix" and "removesuffix". My only concern before had been length, but
three more characters than "cut***fix" is a small price to pay for clarity.
How about "dropprefix" and "dropsuffix"?
___
On 3/22/2020 12:25 PM, Paul Ganssle wrote:
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
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
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
Dennis: please add references to past discussions in python-ideas and
python-dev. Link to the first email of each thread in these lists.
Victor
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
Le dim. 22 mars 2020 à 06:07, Gregory P. Smith a écrit :
> Nice PEP! That this discussion wound up in the NP-complete "naming things"
> territory as the main topic right from the start/prefix/beginning speaks
> highly of it. :)
Maybe we should have a rule to disallow bikeshedding until the
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
Le dim. 22 mars 2020 à 01:45, Dennis Sweeney
a écrit :
> For accepting multiple prefixes, I can't tell if there's a consensus about
> whether
> ``s = s.cutprefix("a", "b", "c")`` should be the same as
>
> for prefix in ["a", "b", "c"]:
> s = s.cutprefix(prefix)
>
> or
>
> for prefix in
On 3/22/2020 1:42 AM, Nick Coghlan wrote:
On Sun, 22 Mar 2020 at 15:13, Cameron Simpson wrote:
On 21Mar2020 12:45, Eric V. Smith 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
On 22Mar2020 08:10, Ivan Pozdeev wrote:
On 22.03.2020 7:46, Steven D'Aprano wrote:
On Sun, Mar 22, 2020 at 06:57:52AM +0300, Ivan Pozdeev via Python-Dev wrote:
Does it need to be separate methods?
Yes.
Overloading a single method to do two dissimilar things is poor design.
They are
Ivan Pozdeev via Python-Dev writes:
>
> On 22.03.2020 7:46, Steven D'Aprano wrote:
> > On Sun, Mar 22, 2020 at 06:57:52AM +0300, Ivan Pozdeev via Python-Dev
> > wrote:
> >
> >> Does it need to be separate methods?
> > Yes.
> >
> > Overloading a single method to do two dissimilar things
On Sun, 22 Mar 2020 at 15:13, Cameron Simpson wrote:
>
> On 21Mar2020 12:45, Eric V. Smith 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
My 2c on the naming:
'start' and 'end' in 'startswith' and 'endswith' are verbs, whereas we're
looking for a noun if we want to cut/strip/trim a string. You can use
'start' and 'end' as nouns for this case but 'prefix' and 'suffix' seems a
more obvious choice in English to me.
Pathlib has
On Sun, 22 Mar 2020 at 14:01, Dennis Sweeney
wrote:
>
> Is there a proven use case for anything other than the empty string as the
> replacement? I prefer your "replacewhatever" to another "stripwhatever" name,
> and I think it's clear and nicely fits the behavior you proposed. But should
> we
On 21Mar2020 14:17, mus...@posteo.org wrote:
On Fri, 20 Mar 2020 20:49:12 -
"Dennis Sweeney" wrote:
exactly same way (as a character set) in each case. Looking at how
the argument is used, I'd argue that ``lstrip``/``rstrip``/``strip``
are much more similar to each other than they are to
On 21Mar2020 14:40, Eric V. Smith wrote:
On 3/21/2020 2:09 PM, Steven D'Aprano wrote:
If you want to know whether a prefix/suffix was removed, there's a
more
reliable way than identity and a cheaper way than O(N) equality. Just
compare the length of the string before and after. If the lengths
On 22.03.2020 7:46, Steven D'Aprano wrote:
On Sun, Mar 22, 2020 at 06:57:52AM +0300, Ivan Pozdeev via Python-Dev wrote:
Does it need to be separate methods?
Yes.
Overloading a single method to do two dissimilar things is poor design.
They are similar. We're removing stuff from an edge in
On 21Mar2020 12:45, Eric V. Smith 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
On 22Mar2020 05:09, Steven D'Aprano wrote:
I agree with Ned -- whether the string object is returned unchanged or
a copy is an implementation decision, not a language decision.
[Eric]
The only reason I can think of is to enable the test above: did a
suffix/prefix removal take place? That
Nice PEP! That this discussion wound up in the NP-complete "naming things"
territory as the main topic right from the start/prefix/beginning speaks
highly of it. :)
The only things left I have to add are (a) agreed on don't specify if it is
a copy or not for str and bytes.. BUT (b) do specify
I like "removeprefix" and "removesuffix". My only concern before had been
length, but three more characters than "cut***fix" is a small price to pay for
clarity.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
1 - 100 of 140 matches
Mail list logo
