On Mon, Mar 23, 2020 at 6:01 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> > This is now a draft PEP, and being (has been?) discussed on python-dev
> --
> > time to go there is you want more input.
>
> They don't, and it's a "idea" separate from the PEP.
Sure, then ple
On 3/23/20 3:31 PM, Andrew Barnert via Python-ideas wrote:
> On Mar 23, 2020, at 04:51, Chris Angelico wrote:
>> Right, which is why for a proposal like this, it's best to start with
>> the simple and straight-forward option of case sensitivity and precise
>> matching. Removing a prefix of "a\u030
Christopher Barker writes:
> This is now a draft PEP, and being (has been?) discussed on python-dev --
> time to go there is you want more input.
They don't, and it's a "idea" separate from the PEP. Python is not
going to change the semantics of str from array of code points to
array of charac
On Mar 23, 2020, at 12:40, Chris Angelico wrote:
>
> On Tue, Mar 24, 2020 at 6:31 AM Andrew Barnert wrote:
>>
>>> On Mar 23, 2020, at 04:51, Chris Angelico wrote:
>>>
>>> Right, which is why for a proposal like this, it's best to start with
>>> the simple and straight-forward option of case
Folks,
This is now a draft PEP, and being (has been?) discussed on python-dev --
time to go there is you want more input.
https://mail.python.org/archives/list/python-...@python.org/thread/WFEWPAOVXOGY7UDXSKMYLVWBCFSHI3VT/
-CHB
On Mon, Mar 23, 2020 at 12:37 PM Chris Angelico wrote:
> On Tue,
On Tue, Mar 24, 2020 at 6:31 AM Andrew Barnert wrote:
>
> On Mar 23, 2020, at 04:51, Chris Angelico wrote:
> >
> > Right, which is why for a proposal like this, it's best to start with
> > the simple and straight-forward option of case sensitivity and precise
> > matching. Removing a prefix of "a
On Mar 23, 2020, at 04:51, Chris Angelico wrote:
>
> Right, which is why for a proposal like this, it's best to start with
> the simple and straight-forward option of case sensitivity and precise
> matching. Removing a prefix of "a\u0301" will not remove a leading
> "\xe1" and vice versa (just as
On Mon, Mar 23, 2020 at 10:40 PM Richard Damon wrote:
>
> On 3/23/20 4:33 AM, Chris Angelico wrote:
> > On Mon, Mar 23, 2020 at 7:06 PM Alex Hall wrote:
> >> I think I'm missing something, why is case insensitivity a mess?
> >>
> > Because there are many characters that case fold in strange ways.
On 3/23/20 4:33 AM, Chris Angelico wrote:
> On Mon, Mar 23, 2020 at 7:06 PM Alex Hall wrote:
>> I think I'm missing something, why is case insensitivity a mess?
>>
> Because there are many characters that case fold in strange ways.
> "ıIiİ".casefold() == 'ıiii̇' which means that lowercase dotless
On Mon, Mar 23, 2020 at 7:06 PM Alex Hall wrote:
>
> I think I'm missing something, why is case insensitivity a mess?
>
Because there are many characters that case fold in strange ways.
"ıIiİ".casefold() == 'ıiii̇' which means that lowercase dotless ı
doesn't casefold to the same thing that upper
I think I'm missing something, why is case insensitivity a mess?
On Mon, Mar 23, 2020 at 9:32 AM Chris Angelico wrote:
> On Mon, Mar 23, 2020 at 5:06 PM Steve Barnes
> wrote:
> >
> > I personally think that there is a better case for an ignore_case flag –
> the number of times that I have been
On Mon, Mar 23, 2020 at 5:06 PM Steve Barnes wrote:
>
> I personally think that there is a better case for an ignore_case flag – the
> number of times that I have been caught out with [‘a.doc’, ‘b.Doc’, ‘c.DOC’]
> especially on MS platforms.
>
Case insensitivity is a mess. I think it'd be a lot
: [Python-ideas] Re: New explicit methods to trim strings
Stephen J. Turnbull wrote:
> The only cases I can remember are files named things like
> "thesis.doc.doc" in GUI environments. ;-)
For edge cases like that, something like
`"thesis.doc.doc".removesuffix(".doc
Stephen J. Turnbull wrote:
> The only cases I can remember are files named things like
> "thesis.doc.doc" in GUI environments. ;-)
For edge cases like that, something like
`"thesis.doc.doc".removesuffix(".doc").removesuffix(".doc")` should
suffice, no? It may not be the cleanest looking solution,
Paul Moore writes:
> I've needed to remove one prefix/suffix. I've never needed to remove
> more than one.
The only cases I can remember are files named things like
"thesis.doc.doc" in GUI environments. ;-)
___
Python-ideas mailing list -- python-idea
On Sun, 22 Mar 2020 at 17:58, Guido van Rossum wrote:
>
> On Sun, Mar 22, 2020 at 9:54 AM Christopher Barker
> wrote:
>>
>> On Sun, Mar 22, 2020 at 2:08 AM Barry Scott wrote:
>>>
>>> >>> Should `-+-+-+Spam'.stripprefix('-+') remove just the first occurence?
>>> >>> All of them? Does it need
On Sun, Mar 22, 2020 at 9:54 AM Christopher Barker
wrote:
> On Sun, Mar 22, 2020 at 2:08 AM Barry Scott
> wrote:
>
>> >>> Should `-+-+-+Spam'.stripprefix('-+') remove just the first
>> occurence? All of them? Does it need a 'count' parameter?
>> >> The only ways to use this function without c
On Sun, Mar 22, 2020 at 10:08 AM Chris Angelico wrote:
> > I imagine that the count=1 is the most common use case for replace()
> anyway,
> >
>
> Do you mean "other than not specifying the count",
yes, that -- most common use case for using count at all.
I'm suggesting that if -1 and 1 were th
On Mon, Mar 23, 2020 at 3:53 AM Christopher Barker wrote:
>
> On Sun, Mar 22, 2020 at 2:08 AM Barry Scott wrote:
>>
>> >>> Should `-+-+-+Spam'.stripprefix('-+') remove just the first occurence?
>> >>> All of them? Does it need a 'count' parameter?
>> >> The only ways to use this function with
On Sun, Mar 22, 2020 at 2:08 AM Barry Scott wrote:
> >>> Should `-+-+-+Spam'.stripprefix('-+') remove just the first
> occurence? All of them? Does it need a 'count' parameter?
> >> The only ways to use this function without counting is remove 1 prefix
> or remove all.
>
I imagine that the co
> On 19 Mar 2020, at 22:12, Rob Cliffe wrote:
>
>
> On 18/03/2020 20:16, Barry Scott wrote:
>>
>>> On 18 Mar 2020, at 18:03, Rob Cliffe via Python-ideas
>>> wrote:
>>>
>>> Consider that the start or end of a string may contain repetitions of an
>>> affix.
>>>
>>> Should `-+-+-+Spam'.str
Well, str.replace has a count parameter. Presumably people use it (even
if by accidentally discovering that without it, it replaces all
occurrences when they only wanted one replaced).
On 18/03/2020 18:44, Alex Hall wrote:
Just the first occurrence. The vast majority of the time, that's what
> On 18 Mar 2020, at 18:03, Rob Cliffe via Python-ideas
> wrote:
>
> Consider that the start or end of a string may contain repetitions of an
> affix.
>
> Should `-+-+-+Spam'.stripprefix('-+') remove just the first occurence? All
> of them? Does it need a 'count' parameter?
The only wa
str.replace is in the opposite situation:
1. People usually want to replace everything. When I search for uses of
replace in code, I can't find any uses of the count parameter.
2. People are more likely to accidentally notice that everything is
being replaced the string being replaced
Just the first occurrence. The vast majority of the time, that's what
people want to do, and they will usually forget to add a 'count' parameter.
Many people probably wouldn't even know it exists. It would be disastrous
if code did the correct thing 99.9% of the time but occasionally silently
mutil
Consider that the start or end of a string may contain repetitions of an
affix.
Should `-+-+-+Spam'.stripprefix('-+') remove just the first occurence?
All of them? Does it need a 'count' parameter?
[all modulo bikeshedding on the names of course]
Rob Cliffe
__
On 07Mar2020 17:51, Christopher Barker wrote:
On Sat, Mar 7, 2020 at 4:36 PM Cameron Simpson wrote:
>Go's Trim strips multiple characters, but, as far as I can tell from
>the docs, TrimPrefix and TrimSuffix strip a single prefix/suffix
>string.
And right there is the confusion I'd rather avoi
On 2020-03-08 01:51, Christopher Barker wrote:
> On Sat, Mar 7, 2020 at 4:36 PM Cameron Simpson wrote:
>
>> Go's Trim strips multiple characters, but, as far as I can tell from
>> the docs, TrimPrefix and TrimSuffix strip a single prefix/suffix
>> string.
>
> And right there is the confusion I'd
On Sat, Mar 7, 2020 at 4:36 PM Cameron Simpson wrote:
> >Go's Trim strips multiple characters, but, as far as I can tell from
> >the docs, TrimPrefix and TrimSuffix strip a single prefix/suffix
> >string.
>
> And right there is the confusion I'd rather avoid. I'd like the affix
> stuff to have a
On 08Mar2020 00:17, MRAB wrote:
On 2020-03-07 23:01, Cameron Simpson wrote:
I'm somewhat against "strip" in the name, because Python's plain
"strip"
methods act like PHP and Go trim methods: they strip multiple
characters, not fixed strings.
My own preference (and personal library use) is cut
On 2020-03-07 23:01, Cameron Simpson wrote:
On 07Mar2020 08:26, Guido van Rossum wrote:
Maybe. FWIW, I looked at what a few other languages offer, and found
that
in Go, they use Trim(s, chars) for our s.strip(chars), and they have
separate TrimPrefix and TrimSuffix methods. That seems the best
On Sun, Mar 8, 2020 at 10:10 AM Christopher Barker wrote:
>
> On Sat, Mar 7, 2020 at 3:01 PM Cameron Simpson wrote:
>>
>> Like yours, they return the original object if unchanged.
>
>
> that makes me uncomfortable, but I guess as srings are mutable (an may be
> interned, why not?)
>
> Do the oth
On Sat, Mar 7, 2020 at 3:01 PM Cameron Simpson wrote:
> Like yours, they return the original object if unchanged.
that makes me uncomfortable, but I guess as srings are mutable (an may be
interned, why not?)
Do the other string methods return themselves if there is no change?
As for the "requ
On Fri, Mar 6, 2020 at 5:54 PM Guido van Rossum wrote:
>
> (Since bytes may be used for file names I think they should get this new
> capability too.)
>
>>
>> I don’t really care one way or another, but is it really still the case
>> that bytes need to be used for filenames? For uses other than j
On 07Mar2020 08:26, Guido van Rossum wrote:
Maybe. FWIW, I looked at what a few other languages offer, and found
that
in Go, they use Trim(s, chars) for our s.strip(chars), and they have
separate TrimPrefix and TrimSuffix methods. That seems the best solution of
the bunch, so I am now okay with
On 07Mar2020 15:31, Alex Hall wrote:
I've defined functions like this in my own utility library and I use them
all the time, so I think they're very useful and would like to seem them
built in. But I have two functions for each end:
def strip_optional_suffix(string, suffix):
"""
>>> strip
On Sat, Mar 7, 2020 at 7:06 AM Ethan Furman wrote:
> On 03/07/2020 05:31 AM, Alex Hall wrote:
>
> > I've defined functions like this in my own utility library and I use them
> > all the time, so I think they're very useful and would like to seem them
> > built in. But I have two functions for e
On 03/07/2020 05:31 AM, Alex Hall wrote:
I've defined functions like this in my own utility library and I use them
all the time, so I think they're very useful and would like to seem them
built in. But I have two functions for each end:
def strip_optional_suffix(string, suffix):
...
def
I've defined functions like this in my own utility library and I use them
all the time, so I think they're very useful and would like to seem them
built in. But I have two functions for each end:
def strip_optional_suffix(string, suffix):
"""
>>> strip_optional_suffix('abcdef', 'def')
On 03/06/2020 04:03 PM, Steven D'Aprano wrote:
On Thu, Mar 05, 2020 at 12:45:28PM -0800, Andrew Barnert via Python-ideas wrote:
Well, I like the idea if someone can come up with a good naming
scheme—something that at least reminds me which function is the “set
of chars” stripper and which the
On Fri, Mar 6, 2020 at 5:46 PM Christopher Barker
wrote:
>
> (Since bytes may be used for file names I think they should get this new
> capability too.)
>
> I don’t really care one way or another, but is it really still the case
> that bytes need to be used for filenames? For uses other than just
(Since bytes may be used for file names I think they should get this new
capability too.)
I don’t really care one way or another, but is it really still the case
that bytes need to be used for filenames? For uses other than just passing
them around?
Sigh.
In any case, while it’s fine to consider
On 03/06/2020 04:07 PM, Steven D'Aprano wrote:
On Fri, Mar 06, 2020 at 03:33:49PM -0800, Ethan Furman wrote:
I think we should have a `stripstr()` as an alias for strip, and a new
`stripchr()`.
Shouldn't they be the other way around?
`strip` removes chars from a set of chars; the proposed m
This will only need a PEP if the eventual proposal is controversial. :-)
Someone (Andrew Barnert?) has claimed that another name, like cut or trim,
would be too confusing. I’m not sure I agree. I think strip_prefix is more
confusing, and stripstr or strstrip would unnecessarily cut off the option
On Fri, Mar 06, 2020 at 03:33:49PM -0800, Ethan Furman wrote:
> I think we should have a `stripstr()` as an alias for strip, and a new
> `stripchr()`.
Shouldn't they be the other way around?
`strip` removes chars from a set of chars; the proposed method will
remove a prefix/suffix.
> And I'm
On Thu, Mar 05, 2020 at 12:45:28PM -0800, Andrew Barnert via Python-ideas wrote:
> Well, I like the idea if someone can come up with a good naming
> scheme—something that at least reminds me which function is the “set
> of chars” stripper and which the “substring” stripper,
You've been a Python
On 03/06/2020 02:59 PM, Guido van Rossum wrote:
On Fri, Mar 6, 2020 at 2:19 PM Steven D'Aprano wrote:
Can we just fix this?
Obviously there will be a month of bike-shedding arguments about the
names *wink* but can we at least agree that this is a genuine source of
confusion and a useful addit
Yes.
On Fri, Mar 6, 2020 at 2:19 PM Steven D'Aprano wrote:
> Can we just fix this? The lack of an obvious way to delete a prefix or
> suffix is a continual pain point for users of the language. We've just
> had yet another bug report from some poor user who misunderstood the
> lstrip method:
>
>
Can we just fix this? The lack of an obvious way to delete a prefix or
suffix is a continual pain point for users of the language. We've just
had yet another bug report from some poor user who misunderstood the
lstrip method:
https://bugs.python.org/issue39880
More examples:
https://bugs.pyth
On Mar 5, 2020, at 08:27, Christopher Barker wrote:
>
>> On Wed, Mar 4, 2020 at 8:13 PM Andrew Barnert via Python-ideas
>> wrote:
>
>> Sorry, I thought I was replying to something from today, not a year ago.
>
> Which is fine — that conversation kind of petered out anyway, and I think
> revi
On Wed, Mar 4, 2020 at 8:13 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> Sorry, I thought I was replying to something from today, not a year ago.
Which is fine — that conversation kind of petered out anyway, and I think
reviving it is a fine idea.
It sounds like you at
Sorry, I thought I was replying to something from today, not a year ago. My
mail client decided that all old messages I didn’t read at the time were
suddenly brand new additions to the thread, and I didn’t look at the dates. :)
Sent from my iPhone
> On Mar 4, 2020, at 19:21, Andrew Barnert via
On Mar 30, 2019, at 12:30, MRAB wrote:
>
> I'd much prefer .lcut/.rcut to .cut_prefix/.cut_suffix, to match
> .lstrip/.rstrip.
I agree that we should use either l/r or something to do with start/end. We
already have two different ways to say left/start and right/end on the str
methods; addin
Thanks. I was wondering what happened to that idea.
I’d like to see it revived, it seems a perfectly reasonable addition to the
string object to me.
And now you’ve written a prototype, there’s a straightforward proposal.
-CHB
On Wed, Mar 4, 2020 at 4:54 PM Cameron Simpson wrote:
> On 03Apr201
On 03Apr2019 14:54, Steven D'Aprano wrote:
Now imagine it's five years from now, and you're using Python 3.11, and
you came across code somebody (possibly even you!) wrote:
ifname = ifname.cutsuffix(':')
Would you say "Damn, I wish that method had never been added!" and
replace it with the
55 matches
Mail list logo
