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

On Wed, Apr 03, 2019 at 09:58:07AM +1100, Cameron Simpson wrote: [...] > Yeah. I was looking at the prefix list from a related article and seeing > "intra" and thinking "intractable". Hacky indeed. That example supports my position that we ought to be cautious about allowing multiple prefixes.

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

On Tue, Apr 02, 2019 at 07:28:01PM +0100, MRAB wrote: [...] > > word[len(prefix) if word.startswith(prefix) else 0:] > > > It could be 'improved' more to: > > word[word.startswith(prefix) and len(prefix) : ] [...] > _Neither_ version copies if the word doesn't start with the prefix. If >

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

On Tue, Apr 2, 2019 at 5:43 PM Eric V. Smith wrote: > PS: I really tried to find a way to use := in this example so I could > put the assignment inside the 'if' statement, but as I think Tim Peters > pointed out, without C's comma operator, you can't. > Conceivably cut_prefix could return None i

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

On 4/2/2019 2:02 PM, Rhodri James wrote: On 02/04/2019 18:55, Stephen J. Turnbull wrote: >> = Me   > 3. My most common use case (not very common at that) is for stripping   > annoying prompts off text-based APIs.  I'm happy using   > .startswith() and string slicing for that, though your point

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

On 02Apr2019 12:23, Paul Moore wrote: On Tue, 2 Apr 2019 at 12:07, Rhodri James wrote: So far we have two slightly dubious use-cases. 1. Stripping file extensions. Personally I find that treating filenames like filenames (i.e. using os.path or (nowadays) pathlib) results in me thinking more

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

On Wed, Apr 3, 2019 at 5:34 AM MRAB wrote: > > The code above contains a subtle bug. > If suffix == '', then word.endswith(suffix) == True, and > word[:-len(suffix)] == word[:-0] == ''. > > Each time I see someone do that, I see more evidence in support of > adding the method. Either that, or it'

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

On 2019-04-02 18:55, Stephen J. Turnbull wrote: Rhodri James writes: Steven d'Aprano writes: > > (That's over a third of this admittedly incomplete list of prefixes.) > > > > I can think of at least one English suffix pair that clash: -ify, -fy. And worse: is "tries" the third person pres

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

On 2019-04-02 19:10, Stephen J. Turnbull wrote: Anders Hovmöller writes: > Removing "file:" prefix: > https://github.com/merijn/dotfiles/blob/43c736c73c5eda413dc7b4615bb679bd43a18d1a/dotfiles/hg-data/hooks/bitbucket.py#L16

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

Anders Hovmöller writes: > Removing "file:" prefix: > https://github.com/merijn/dotfiles/blob/43c736c73c5eda413dc7b4615bb679bd43a18d1a/dotfiles/hg-data/hooks/bitbucket.py#L16 > >

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

On 02/04/2019 18:55, Stephen J. Turnbull wrote: >> = Me > 3. My most common use case (not very common at that) is for stripping > annoying prompts off text-based APIs. I'm happy using > .startswith() and string slicing for that, though your point about > the repeated use of the string to

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

Rhodri James writes: Steven d'Aprano writes: > > (That's over a third of this admittedly incomplete list of prefixes.) > > > > I can think of at least one English suffix pair that clash: -ify, -fy. And worse: is "tries" the third person present tense of "try" or is it the plural of "trie"? P

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

On Sun, Mar 31, 2019 at 3:28 AM Brandt Bucher wrote: > > > An idea worth considering: one can think of the “strip” family of methods > as currently taking an iterable of strings as an argument (since a string > is itself an sequence of strings): > > It would not be a huge logical leap to allow the

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

> On 2 Apr 2019, at 13:23, Paul Moore wrote: > > It would be really helpful if someone could go through the various use > cases presented in this thread and classify them - filename > manipulation, natural language uses, and "other". We could then focus > on the "other" category to get a better

Re: [Python-ideas] PEP-582 and multiple Python versions

OK, I didn't know if this or -dev was more appropriate, so I opted on the safer side in terms of annoying people. I'll post to python-dev. On Mon, Apr 1, 2019 at 2:27 PM Brett Cannon wrote: > I just wanted to warn people that I don't know if any of the authors of > PEP 582 subscribe to python-i

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

On Tue, 2 Apr 2019 at 12:07, Rhodri James wrote: > So far we have two slightly dubious use-cases. > > 1. Stripping file extensions. Personally I find that treating filenames > like filenames (i.e. using os.path or (nowadays) pathlib) results in me > thinking more appropriately about what I'm doin

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

On 02/04/2019 01:52, Steven D'Aprano wrote: Here's a partial list of English prefixes that somebody doing text processing might want to remove to get at the root word: a an ante anti auto circum co com con contra contro de dis en ex extra hyper il im in ir inter intra intro macro micro

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

In your case you probably should use [model.split(".")[1] for model in models] strip_prefix should not be used with file extensions, method for files already exist. On Apr 2 2019, at 5:43 am, David Mertz wrote: > On Mon, Apr 1, 2019 at 8:54 PM Steven D'Aprano (mailto:st...@pearwood.info)> wrote

Re: [Python-ideas] Backward-incompatible changes for Python 4

> It's much simpler to rename April 1 to February 29. That will create a gap of one 1 day beetween shity regular callendar and our new one for 2 month. An algorithm distributing leap seconds near 1 first april, is maybe more complicated but reduce side effect with the world. __

Re: [Python-ideas] Backward-incompatible changes for Python 4

Greg Ewing writes: > In light of that, I propose that the datetime module in Python 4 > be changed so that April 1 does not exist: > > >>> m31 = date(2019, 3, 31) > >>> m31 + timedelta(days = 1) > datetime.date(2019, 4, 2) > > This would remove a large amount of confusion from the worl