On Sat, 21 Mar 2020 at 13:15, Stephen J. Turnbull
wrote:
> That makes a lot of sense, as a strategy for doing the work. It
> should be pretty straightforward to convert the tstate argument to a
> thread-local tstate.
Note that the thread locals are already there, as that's how the
public API alr
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 `with_s
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 t
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 b
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 seem
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 that
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 python
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.
> As written in the PEP preface, the very reason for the PEP is that people
> are continuously tryin
> In this case, being in line with the existing string API method names
take priority over PEP 8, e.g. splitlines, startswith, endswith,
splitlines, etc.
Oops, I just realized that I wrote "splitlines" twice there. I guess that
goes to show how much I use that specific method in comparison to the
Ivan Pozdeez wrote:
> I must note that names conforming to
https://www.python.org/dev/peps/pep-0008/#function-and-variable-names would
be "strip_prefix" and "strip_suffix".
In this case, being in line with the existing string API method names take
priority over PEP 8, e.g. splitlines, startswith,
On Sat, Mar 21, 2020 at 8:38 PM Guido van Rossum wrote:
> It's not great, and I actually think that "stripprefix" and "stripsuffix"
are reasonable.
> [explanation snipped]
Thinking a bit more, I could also get behind "removeprefix" and
"removesuffix".
--
--Guido van Rossum (python.org/~guido)
*
On 22.03.2020 6:38, Guido van Rossum wrote:
On Sat, Mar 21, 2020 at 6:46 PM Nick Coghlan mailto:ncogh...@gmail.com>> wrote:
On Sat., 21 Mar. 2020, 11:19 am Nathaniel Smith, mailto:n...@pobox.com>> wrote:
On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
mailto:sweeney.dennis..
On 20.03.2020 21:52, Dennis Sweeney wrote:
Browser Link: https://www.python.org/dev/peps/pep-0616/
PEP: 616
Title: String methods to remove prefixes and suffixes
Author: Dennis Sweeney
Sponsor: Eric V. Smith
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 19-Mar-2020
Py
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
allow a naming convenience to dictate that the behavior should
On Sat, Mar 21, 2020 at 6:46 PM Nick Coghlan wrote:
> On Sat., 21 Mar. 2020, 11:19 am Nathaniel Smith, wrote:
>
>> On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
>> wrote:
>> > This is a proposal to add two new methods, ``cutprefix`` and
>> > ``cutsuffix``, to the APIs of Python's various stri
> But Dennis, welcome to the wonderful world of change proposals, where
> you will experience insane amounts of pushback and debate on the
> finest points of bikeshedding, whether or not people actually even
> support the proposal at all...
Lol -- thanks!
In my mind, another reason that I like in
On 21/03/2020 20:16, Ned Batchelder wrote:
On 3/21/20 12:51 PM, Rob Cliffe via Python-Dev wrote:
On 21/03/2020 16:15, Eric V. Smith wrote:
On 3/21/2020 11:20 AM, Ned Batchelder wrote:
On 3/20/20 9:34 PM, Cameron Simpson wrote:
On 20Mar2020 13:57, Eric Fahlgren wrote:
On Fri, Mar 20, 2020
On Sun, Mar 22, 2020 at 1:02 PM Nathaniel Smith wrote:
>
> On Sat, Mar 21, 2020 at 11:35 AM Steven D'Aprano wrote:
> >
> > On Fri, Mar 20, 2020 at 06:18:20PM -0700, Nathaniel Smith wrote:
> > > On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
> > > wrote:
> > > > This is a proposal to add two new
Nick Coghlan wrote:
> The example where the new function was used instead of a questionable use
of replace gave me an idea, though: what if the new functions were
"replacestart()" and "replaceend()"?
>
> * uses "start" and "with" for consistency with the existing checks
> * substring based, like th
On Sat, Mar 21, 2020 at 11:35 AM Steven D'Aprano wrote:
>
> On Fri, Mar 20, 2020 at 06:18:20PM -0700, Nathaniel Smith wrote:
> > On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
> > wrote:
> > > This is a proposal to add two new methods, ``cutprefix`` and
> > > ``cutsuffix``, to the APIs of Python
On Sat., 21 Mar. 2020, 11:19 am Nathaniel Smith, wrote:
> On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
> wrote:
> > This is a proposal to add two new methods, ``cutprefix`` and
> > ``cutsuffix``, to the APIs of Python's various string objects.
>
> The names should use "start" and "end" instea
Even then, it seems that prefix is an established computer science term:
[1] https://en.wikipedia.org/wiki/Substring#Prefix
[2] Cormen, Thomas H.; Leiserson, Charles E.; Rivest, Ronald L. (1990).
Introduction to Algorithms (1st ed.). Chapter 15.4: Longest common subsequence
And a quick search re
Hi Victor. I accidentally created a new thread, but I intended everything below
as a response:
Thanks for the review!
> In short, I propose:
> def cutprefix(self: str, prefix: str, /) -> str:
> if self.startswith(prefix) and prefix:
> return self[len(prefix):]
> else:
>
On 3/21/20 12:51 PM, Rob Cliffe via Python-Dev wrote:
On 21/03/2020 16:15, Eric V. Smith wrote:
On 3/21/2020 11:20 AM, Ned Batchelder wrote:
On 3/20/20 9:34 PM, Cameron Simpson wrote:
On 20Mar2020 13:57, Eric Fahlgren wrote:
On Fri, Mar 20, 2020 at 11:56 AM Dennis Sweeney
wrote:
If ``s`
On Sun, Mar 22, 2020 at 5:41 AM Steven D'Aprano wrote:
>
> On Fri, Mar 20, 2020 at 06:18:20PM -0700, Nathaniel Smith wrote:
> > On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
> > wrote:
> > > This is a proposal to add two new methods, ``cutprefix`` and
> > > ``cutsuffix``, to the APIs of Python'
On 21 Mar 2020, at 19:09, Steven D'Aprano wrote:
On Sat, Mar 21, 2020 at 12:15:21PM -0400, Eric V. Smith wrote:
On 3/21/2020 11:20 AM, Ned Batchelder wrote:
Why be so prescriptive? The semantics of these functions should be
about what the resulting string contains. Leave it to implementors
On 21/03/2020 16:15, Eric V. Smith wrote:
On 3/21/2020 11:20 AM, Ned Batchelder wrote:
On 3/20/20 9:34 PM, Cameron Simpson wrote:
On 20Mar2020 13:57, Eric Fahlgren wrote:
On Fri, Mar 20, 2020 at 11:56 AM Dennis Sweeney
wrote:
If ``s`` is one these objects, and ``s`` has ``pre`` as a pref
On 3/21/2020 2:09 PM, Steven D'Aprano wrote:
On Sat, Mar 21, 2020 at 12:15:21PM -0400, Eric V. Smith wrote:
On 3/21/2020 11:20 AM, Ned Batchelder wrote:
Why be so prescriptive? The semantics of these functions should be
about what the resulting string contains. Leave it to implementors to
deci
On Fri, Mar 20, 2020 at 06:18:20PM -0700, Nathaniel Smith wrote:
> On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
> wrote:
> > This is a proposal to add two new methods, ``cutprefix`` and
> > ``cutsuffix``, to the APIs of Python's various string objects.
>
> The names should use "start" and "end
On Sat, Mar 21, 2020 at 12:15:21PM -0400, Eric V. Smith wrote:
> On 3/21/2020 11:20 AM, Ned Batchelder wrote:
> >Why be so prescriptive? The semantics of these functions should be
> >about what the resulting string contains. Leave it to implementors to
> >decide when it is OK to return self or
> So far, my second go-round is proceeding better (fingers crossed). I
> have added a new slot to the _frame struct (f_cellvars), initialized
> once at creation, then referenced elsewhere. I'm also rerunning the
> test suite more frequently. Once I've tweaked everything, all that
> will remain (in
On 3/21/2020 12:50 PM, Victor Stinner wrote:
In that case, the PEP should advice to use .startwith() or .endswith()
explicitly if the caller requires to know if the string is going to be
modified. Example:
modified = False
# O(n) complexity where n=len("prefix:")
if line.startswith("prefix:"):
In that case, the PEP should advice to use .startwith() or .endswith()
explicitly if the caller requires to know if the string is going to be
modified. Example:
modified = False
# O(n) complexity where n=len("prefix:")
if line.startswith("prefix:"):
line = line.cutprefix("prefix: ")
modifi
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 are
strings.
Good point. And I guess it's
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 are
strings.
Victor
Le sam. 21 mars 2020 à 17:23, Eric V. Smith a écrit :
>
> On 3/21/2
On 3/21/2020 11:20 AM, Ned Batchelder wrote:
On 3/20/20 9:34 PM, Cameron Simpson wrote:
On 20Mar2020 13:57, Eric Fahlgren wrote:
On Fri, Mar 20, 2020 at 11:56 AM Dennis Sweeney
wrote:
If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then
``s.cutprefix(pre)`` returns a copy
On 3/20/20 9:34 PM, Cameron Simpson wrote:
On 20Mar2020 13:57, Eric Fahlgren wrote:
On Fri, Mar 20, 2020 at 11:56 AM Dennis Sweeney
wrote:
If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then
``s.cutprefix(pre)`` returns a copy of ``s`` in which that prefix has
been remove
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 the proposed
> methods
Correct, but I don'
On Fri, 20 Mar 2020 19:24:22 +0100
Victor Stinner wrote:
>
> One good example is Py_AddPendingCall(). The documentation says that
> it's safe to call it without holding the GIL. Except that right now,
> there is no reliable way to get the correct interpreter in this case
> (correct me if I'm wron
On 20/03/2020 22:21, Victor Stinner wrote:
Motivating examples from the Python standard library
The examples below demonstrate how the proposed methods can make code
one or more of the following: (...)
IMO there are too many examples. For
On Fri, Mar 20, 2020 at 11:27 AM Victor Stinner wrote:
> I would prefer to continue to experiment passing tstate explicitly in
> internal C APIs until most blocker issues will be fixed. Once early
> work on running two subinterpreters in parallel will start working
> (one "GIL" per interpreter), I
45 matches
Mail list logo
