[Python-ideas] Re: New explicit methods to trim strings

[Cameron Simpson]

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 avoid. I'd like the affix
stuff to have a different name because it behaves differently.


Different than Go? or than existing Python methods? I think it's pretty
much impossible for Python to remain in sync with other languages, we might
well give up on that.


No, "trim" doing both lots characters or fixed strips depending on 
flavour of name. (And I'm against "trim" because of PHP's "trim" which 
is like our "strip".)



We've got strip, lstrip and rstrip with common "strip multiple

characters" actions. I think fixed affixes are different enough to
warrant a differently spelled name.


That's why folks are suggesting "*prefix" and *suffix" -- the prefix and
suffix make it pretty clear that something different is going on. And I at
least think it's pretty descritive. I"ve lost track of what's on the table,
but:

strip_prefix
strip_suffix

make it clear that it's something different than the other "strip"s,
without gratuitously adding more words for the same thing. And it would
show up alphabetically near "strip", which is also good.


Yeah, they do make it more clear. I like "cutprefix" and "cutsuffix" 
myself.



I'm going to try to refrain from further bike shedding this one -- I'd
rather see something done than get my favorite names :-)


Me too.

Cheers,
Cameron Simpson 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2K2TAZYQKDEAJ6J3672VTBDRTQDPZ36Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[MRAB]

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 rather avoid. I'd like the affix
> stuff to have a different name because it behaves differently.
>
> Different than Go? or than existing Python methods? I think it's 
pretty much impossible for Python to remain in sync with other 
languages, we might well give up on that.

>
>> We've got strip, lstrip and rstrip with common "strip multiple
>> characters" actions. I think fixed affixes are different enough to
>> warrant a differently spelled name.
>
>
> That's why folks are suggesting "*prefix" and *suffix" -- the prefix 
and suffix make it pretty clear that something different is going on. 
And I at least think it's pretty descritive. I"ve lost track of what's 
on the table, but:

>
> strip_prefix
> strip_suffix
>
> make it clear that it's something different than the other "strip"s, 
without gratuitously adding more words for the same thing. And it would 
show up alphabetically near "strip", which is also good.

>
> I'm going to try to refrain from further bike shedding this one -- 
I'd rather see something done than get my favorite names :-)

>
Only bikeshedding I'd do at this point is to go with Guido's suggestion 
to omit the underscores because the other methods don't have any.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KBUWUB623IUH4A2XIOSHXN52QVQN2GIT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Christopher Barker]

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 different name because it behaves differently.
>

Different than Go? or than existing Python methods? I think it's pretty
much impossible for Python to remain in sync with other languages, we might
well give up on that.

We've got strip, lstrip and rstrip with common "strip multiple
> characters" actions. I think fixed affixes are different enough to
> warrant a differently spelled name.
>

That's why folks are suggesting "*prefix" and *suffix" -- the prefix and
suffix make it pretty clear that something different is going on. And I at
least think it's pretty descritive. I"ve lost track of what's on the table,
but:

strip_prefix
strip_suffix

make it clear that it's something different than the other "strip"s,
without gratuitously adding more words for the same thing. And it would
show up alphabetically near "strip", which is also good.

I'm going to try to refrain from further bike shedding this one -- I'd
rather see something done than get my favorite names :-)

-CHB


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FLP6BIDWS5TI4AVSYME4ARRLVB447O7Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Cameron Simpson]

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 cutprefix and cutsuffix.

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 different name because it behaves differently.


We've got strip, lstrip and rstrip with common "strip multiple 
characters" actions. I think fixed affixes are different enough to 
warrant a differently spelled name.


I hope we can agree to at least avoid using the word "trim", for similar 
reasons.


Cheers,
Cameron Simpson 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YBK75HCMVFCNRHEA2PVPZ4J5XM7WLKDC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] prefix/suffix for bytes (was: New explicit methods to trim strings)

[Cameron Simpson]

On 07Mar2020 15:01, Christopher Barker  wrote:

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 just passing

them around?


Yes, Linux in particular does not guarantee that file names are using any
particular encoding (let alone a consistent encoding for different files).
The only two bytes that are special are '\0' and '/'.


I *think* I understand the issues. And I can see that some software would
need to work with filenames as arbitrary bytes. But that doesn't mean that
you can do much with them that way.


Given that the entire UNIX filename API is bytes, I think this isn't 
very true.



I can see filename.split(b'/') for instance, but how could you strip a
prefix or suffix without knowing the encoding?


Well, directly:

   filename.cutsuffix(b'.abc')

But more seriously, you're either treating them as bytes with no 
particular encoding and the above just means "remove these 4 bytes" or 
you do know the encoding and are working with strings, so you'd either 
have a string andcut a string, or have bytes and cut the value 
'.abc'.encode(encoding=known_encoding).


Things like listdir are dual mode: call it with a bytes directory name 
and you get bytes results, call it with a string directory name and you 
get string results. There's some funky encoding accomodation in there 
(read the docs, it's a little subtlety to do with returning strings 
which didn't decode cleanly from the underlying bytes).



filename.strip_suffix(b'.txt') would only work for ASCII-compaitble
encodings.


Or b'.txt' is your known bytes encoding of some known string suffix in 
your working encoding.


But like the other string-like bytes methods, I think there's a good 
case for supporting bytes prefixes and suffixes; it is just a matter of 
using the correct bytes affix in the regime you're working in. Might not 
be filenames, either.



There's no way around the fact that you have to make SOME
assumptions about the encoding if you are going to do anything other than
pass it around or work with the b'/' byte.


They needn't be assumptions; all code has some outer context.


And if that's the case, then you
might as well decode and use 'surrogateescape' so the program won't crash.


Ah, I see you've encountered the listdir-return-string stuff already 
then.



Getting OT, but I do wonder if we should continue to support (and therefor
encourage) the use of bytes in inappropriate ways.


I think there's plenty of reasonable bytes actions which look a lot like 
string actions, and are not confusing. Consider this contrived example:


   payload_bytes = packet_bytes.cutprefix(header_bytes)

There was an interesting writeup by a guy involved in the mercurial 
Python 3 port where he discusses the pain which came with the bytes type 
lacking a lot of the string support methods when Python 3 first came 
out. He suggests a lot of things would have gone far smoother with 
these, as Mercurial had a lot of filenames-as-bytes-strings inside. Here 
we are:


   
https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/

Personally I lean the other way, and welcomed the initial lack of 
stringish methods as a good way to uncover bytes mistakenly used for 
strings. But I see his point.


Cheers,
Cameron Simpson 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/A7TYUKFN74XOOD5MJGBDG5GMUGNTEFXR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[MRAB]

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 solution of
the bunch, so I am now okay with using stripprefix and stripsuffix. (Why no
_? Because startswith and endswith don't have one either.)


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 cutprefix and cutsuffix.

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.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/R32PUO3RKEFMF5LCSYVDO2RJFQANDUFP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Chris Angelico]

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 other string methods return themselves if there is no change?
>

Yes. There's no reason not to; it's more efficient to return the same
string, and perfectly safe to do so. Not every method returns itself
when there's no change, but when it's easy to do, they do:

>>> x = "hello world, this is a test"
>>> x.strip("@") is x
True
>>> x.replace("@", "#") is x
True
>>> x.zfill(5) is x
True
>>> x.center(5) is x
True

But:

>>> x.lower() is x
False
>>> x.lower() == x
True

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GGYZZNNOGLRDQ74XCKUI7ZSFWYOGBGNH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Christopher Barker]

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 "required" idea -- an optional keyword only parameter could be
useful, but definitely not the default behavior. That would be incompatible
with all the other string methods. Though personally, I think I'd still
check that a string "follows the rules" I expect outside this function
anyway.

-CHB


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JMTGMM4TLU7T7AMDGIZTM4V3B5GUWVHP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Christopher Barker]

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 just passing
>> them around?
>>
>
> Yes, Linux in particular does not guarantee that file names are using any
> particular encoding (let alone a consistent encoding for different files).
> The only two bytes that are special are '\0' and '/'.
>

I *think* I understand the issues. And I can see that some software would
need to work with filenames as arbitrary bytes. But that doesn't mean that
you can do much with them that way.

I can see filename.split(b'/') for instance, but how could you strip a
prefix or suffix without knowing the encoding?
filename.strip_suffix(b'.txt') would only work for ASCII-compaitble
encodings. There's no way around the fact that you have to make SOME
assumptions about the encoding if you are going to do anything other than
pass it around or work with the b'/' byte. And if that's the case, then you
might as well decode and use 'surrogateescape' so the program won't crash.

Getting OT, but I do wonder if we should continue to support (and therefor
encourage) the use of bytes in inappropriate ways.

I didn't like the name stripstr anyway. :-)
>

Neither do I, so I guess I shouldn't have brought this up ...

-CHB



>>> On Fri, Mar 6, 2020 at 16:10 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 method will
 remove a prefix/suffix.


 > And I'm perfectly okay with bytes() not having those methods.  ;-)

 If heavy users of bytes want these methods, they can request them
 separately. There's no backwards compatibility requirement for new
 string methods to be automatically added to bytes.

 I guess the question now is do we need a PEP?

>>>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WPZPP75NSY2NQH5JR4PPB72PDTUBT3PT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Cameron Simpson]

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 using stripprefix and stripsuffix. (Why no
_? Because startswith and endswith don't have one either.)


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 cutprefix and cutsuffix.

Cheers,
Cameron Simpson 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/24QQVKJAEWCXBK2ANGPUD6HFW5NPR4YM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Cameron Simpson]

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_optional_suffix('abcdef', 'def')
   'abc'
   >>> strip_optional_suffix('abcdef', '123')
   'abcdef'
   """
   if string.endswith(suffix):
   return string[:-len(suffix)]
   return string


My utility library has them too, like this:

   def cutprefix(s, prefix):
 ''' Strip a `prefix` from the front of `s`.
 Return the suffix if `.startswith(prefix)`, else `s`.

 Example:

 >>> abc_def = 'abc.def'
 >>> cutprefix(abc_def, 'abc.')
 'def'
 >>> cutprefix(abc_def, 'zzz.')
 'abc.def'
 >>> cutprefix(abc_def, '.zzz') is abc_def
 True
 '''
 if prefix and s.startswith(prefix):
   return s[len(prefix):]
 return s

   def cutsuffix(s, suffix):
 ''' Strip a `suffix` from the end of `s`.
 Return the prefix if `.endswith(suffix)`, else `s`.

 Example:

 >>> abc_def = 'abc.def'
 >>> cutsuffix(abc_def, '.def')
 'abc'
 >>> cutsuffix(abc_def, '.zzz')
 'abc.def'
 >>> cutsuffix(abc_def, '.zzz') is abc_def
 True
 '''
 if suffix and s.endswith(suffix):
   return s[:-len(suffix)]
 return s

Like yours, they return the original object if unchanged. I think yours 
misbehaved if given an empty suffix, which mine special cases out:


   >>> 'abc'[:-0]
   ''

Cheers,
Cameron Simpson 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/COCNDNFGHLXDEPUMIR4ADIU3LBZY4L4H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Guido van Rossum]

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 each end:
> >
> > def strip_optional_suffix(string, suffix):
> >  ...
> >
> > def strip_required_suffix(string, suffix):
> >  ...
> >
> > And I know that I use the required versions much more often, because
> >  usually if the suffix isn't there that indicates a bug somewhere that I
> >  need to know about. So I'd like to have both the optional and required
> >  versions implemented in this proposal, and if that's too much to add
> then
> >  just the required versions. But I suspect most people will be against
> the
> >  idea.
>
> Against only having the required versions, yes.  However, we do have other
> functions that take an extra parameter to determine whether to raise an
> exception, so perhaps:
>
>  def strip_suffix(string, /, required=False):
>  ...
>

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 using stripprefix and stripsuffix. (Why no
_? Because startswith and endswith don't have one either.)

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QXUHMIYIAELULVB5T75AQXCMMH6I2EAS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Ethan Furman]

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 strip_required_suffix(string, suffix):
 ...

And I know that I use the required versions much more often, because
 usually if the suffix isn't there that indicates a bug somewhere that I
 need to know about. So I'd like to have both the optional and required
 versions implemented in this proposal, and if that's too much to add then
 just the required versions. But I suspect most people will be against the
 idea.


Against only having the required versions, yes.  However, we do have other 
functions that take an extra parameter to determine whether to raise an 
exception, so perhaps:

def strip_suffix(string, /, required=False):
...

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DUZDBUWZQJND4TTVSA6BJAV7UKIDMICC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New explicit methods to trim strings

[Alex Hall]

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')
'abc'
>>> strip_optional_suffix('abcdef', '123')
'abcdef'
"""
if string.endswith(suffix):
return string[:-len(suffix)]
return string


def strip_required_suffix(string, suffix):
"""
>>> strip_required_suffix('abcdef', 'def')
'abc'
>>> strip_required_suffix('abcdef', '123')
Traceback (most recent call last):
...
AssertionError: String ends with 'def', not '123'
"""
if string.endswith(suffix):
return string[:-len(suffix)]
raise AssertionError('String ends with %r, not %r' %
(string[-len(suffix):], suffix))

And I know that I use the required versions much more often, because
usually if the suffix isn't there that indicates a bug somewhere that I
need to know about. So I'd like to have both the optional and required
versions implemented in this proposal, and if that's too much to add then
just the required versions. But I suspect most people will be against the
idea.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DHSLWA24ZLZU42GALCOTTCN33HQOIAXR/
Code of Conduct: http://python.org/psf/codeofconduct/