[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Stephen J. Turnbull]

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 is poor design.
 > >
 > They are similar. We're removing stuff from an edge in both
 > cases. The only difference is whether input is treated as a
 > character set or as a raw substring.

That is true.  However, the rule of thumb (due to Guido, IIRC) is if
the parameter is normally going to be a literal constant, and there
are few such constants (like <= 3), put them in the name of the
function rather than as values for an optional parameter.  Overloading
doesn't save much, if any, typing in this case.

That's why we have strip, rstrip, and lstrip in the first place,
although nowadays we'd likely spell the modifiers out (and maybe use
start/end rather than left/right, which I would guess force BIDI users
to translate to start/end on the fly).

Steve
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/56MCGZR4AHLCG6UWV5TOEYH2PNS52SNO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Cameron Simpson]

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 similar. We're removing stuff from an edge in both cases. The 
only difference is whether input is treated as a character set or as a 
raw substring.


That is not the only difference. strip() does not just remove a 
character from the set provided (as a str). It removes as many of them 
as there are; that is why "foo.ext".strip(".ext") can actually be quite 
misleading to someone looking for a suffix remover - it often looks like 
it did the right thing.


By contrast, cutprefix/cutsuffix (or stripsuffix, whatever) remove only 
_one_ instance of the affix.


To my mind they are quite different, which is the basis of my personal 
dislike of reusing the word "strip". Just extending "strip()" with a 
funky new affix mode would be even worse, since it can _still_ be 
misleading if the caller omited the special mode.


Cheers,
Cameron Simpson 
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/E4XEFKAWBHHOYAGBQUIUZHGB3J4HXBSJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Eric V. Smith]

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 characters) as a pointer, it may
become harder to keep the same behavior for "x is y" where x and y are
strings.

Are you suggesting that it could become impossible to write this
function:

 def myself(o):
 return o

and not be able to rely on "o is myself(o)"? That seems... a pretty
nasty breaking change for the language.

Other way around - because strings are immutable, their identity isn't
supposed to matter, so it's possible that functions that currently
return the exact same object in some cases may in the future start
returning a different object with the same value.

Right now, in CPython, with no tagged pointers, we return the full
existing pointer wherever we can, as that saves us a data copy. With
tagged pointers, the pointer storage effectively *is* the instance, so
you can't really replicate that existing "copy the reference not the
storage" behaviour any more.

That said, it's also possible that identity for tagged pointers would
be value based (similar to the effect of the small integer cache and
string interning), in which case the entire question would become
moot.

Either way, the PEP shouldn't be specifying that a new object *must*
be returned, and it also shouldn't be specifying that the same object
*can't* be returned.


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.


Eric

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/JHM7T6JZU56PWYRJDG45HMRBXE3CBXMX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Victor Stinner]

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 ["a", "b", "c"]:
>  if s.startwith(prefix):
>  s = s.cutprefix(prefix)
>  break
>
> The latter seems to be harder for users to implement through other means, and 
> it's the
> behavior that test_concurrent_futures.py has implemented now, so maybe that's 
> what we
> want.

I expect that "FooBar".cutprefix(("Foo", "Bar")) returns "Bar". IMO
it's consistent with "FooFoo".cutprefix("Foo") which only returns
"Foo" and not "":
https://www.python.org/dev/peps/pep-0616/#remove-multiple-copies-of-a-prefix

If you want to remove both prefixes,
"FooBar".cutprefix("Foo").cutprefix("Bar") should be called to get "".


> Also, it seems more elegant to me to accept variadic arguments, rather than a 
> single
> tuple of arguments. Is it worth it to match the related-but-not-the-same API 
> of
> "startswith" if it makes for uglier Python? My gut reaction is to prefer the 
> varargs, but
> maybe someone has a different perspective.

I suggest to accept a tuple of strings:

str.cutprefix(("prefix1", "prefix2"))

To be consistent with startswith():

str.startswith(("prefix1", "prefix2"))

cutprefix() and startswith() can be used together and so I would
prefer to have the same API:

prefixes = ("context: ", "ctx:")
has_prefix = False
if line.startswith(prefixes):
line = line.cutprefix(prefixes)
has_prefix = True

A different API would look more surprising, no? Compare it to:

prefixes = ("context: ", "ctx:")
has_prefix = False
if line.startswith(prefixes):
line = line.cutprefix(*prefixes)# <== HERE
has_prefix = True

The difference is even more visible is you pass directly the prefixes:
.cutprefix("context: ", "ctx:")
vs
.cutprefix(("context: ", "ctx:"))

Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/JTFKF2ASUR5QV3I73O72RHYL5S72OGDW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Paul Ganssle]

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 this case. It adds unnecessary complexity for subclass
implementers to need to re-implement these two additional methods, and I
can see no obvious reason why this behavior would be necessary, since
these methods can be implemented in terms of string slicing.

Even if you wanted to use `str`-specific optimizations in C that aren't
available if you are constrained to use the subclass's __getitem__, it's
inexpensive to add a "PyUnicode_CheckExact(self)" check to hit a "fast
path" that doesn't use slice.

I think defining this in terms of string slicing makes the most sense
(and, notably, slice itself returns `str` unless explicitly overridden,
the default is for it to return `str` anyway...).

Either way, it would be nice to see the rationale included in the PEP
somewhere.

Best,
Paul

On 3/22/20 7:16 AM, Eric V. Smith wrote:
> 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 characters) as a pointer, it
> may
> become harder to keep the same behavior for "x is y" where x and y
> are
> strings.
>>> Are you suggesting that it could become impossible to write this
>>> function:
>>>
>>>  def myself(o):
>>>  return o
>>>
>>> and not be able to rely on "o is myself(o)"? That seems... a pretty
>>> nasty breaking change for the language.
>> Other way around - because strings are immutable, their identity isn't
>> supposed to matter, so it's possible that functions that currently
>> return the exact same object in some cases may in the future start
>> returning a different object with the same value.
>>
>> Right now, in CPython, with no tagged pointers, we return the full
>> existing pointer wherever we can, as that saves us a data copy. With
>> tagged pointers, the pointer storage effectively *is* the instance, so
>> you can't really replicate that existing "copy the reference not the
>> storage" behaviour any more.
>>
>> That said, it's also possible that identity for tagged pointers would
>> be value based (similar to the effect of the small integer cache and
>> string interning), in which case the entire question would become
>> moot.
>>
>> Either way, the PEP shouldn't be specifying that a new object *must*
>> be returned, and it also shouldn't be specifying that the same object
>> *can't* be returned.
>
> 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.
>
> Eric
>
> ___
> 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
> https://mail.python.org/archives/list/python-dev@python.org/message/JHM7T6JZU56PWYRJDG45HMRBXE3CBXMX/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: OpenPGP digital signature
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/RTQWEE4KZYIIXL3HK3C6IJ2ATQ6CM7PG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proliferation of tstate arguments.

[Victor Stinner]

Le sam. 21 mars 2020 à 04:14, Stephen J. Turnbull
 a écrit :
> But ... this sounds to me like work that should be done on a branch.
>
> I'm sure you considered that, but I also expect others will feel the
> same way.  Perhaps this is a good opportunity to document why it's not
> being done on a branch.

For almost every small changes that I wanted to write, I had to push
many small "refactoring" changes to "prepare" the code base for that.
I mean that while I'm doing the changes that I want to do, I had to
fix dozens of bugs which didn't impact anyone else before because
subinterpreters were not properly isolated. For example, to be able to
make small integer singletons per-interpreters, I had to fix the code
to initialize builtins and sys modules to make them really isolated
from the main interpreter.

One of the practical issue that I had is that when a subinterpreter
leaked references, previously it was ignored since we basically ignore
references which are never released at exit. We only care of
differences before/after running an unit test when using "python3 -m
test -R 3:3 (...)". But when I *fixed* the implementation of
subinterpreters, suddenly, very old bugs became visible.

What I'm trying to say is that "fixing" the implementation of
subinterpreters require a deep refactoing of Python internals which
cannot be done in a few small changes. Maintaining a branch in a fork
of the Git project is likely to become too hard to maintain (rebase
the branch).

Moreover, I like to push small commits which are easy to understand,
easy to review and easy to revert if needed.

If we build a giant branch, what would be the outcome? Merge 1 year of
work as a single commit? Currently, all commits of a pull request are
almost squashed into a single large commit.


>  > There are still too many functions which don't work properly with
>  > subinterpreters. There are still a few design issues that needs to
>  > be addressed.
>
> Are subinterpreters in use in production?

Yes. it's used for many years in production by Apache mod_wsgi project
for example.


>  If so, and especially if
> these use cases are unpatched vs. master, that would be justification
> for pushing to master since you are clearly fixing problems with
> subinterpreter use.

Yes, I'm fixing real bugs ;-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/VPSA5VYAEOUTFEBAHBU2R4V57GXDS7HJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Victor Stinner]

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
foundations of a PEP are settled. Or always create two threads per
PEP: one for bikeshedding only, one for otherthing else :-D

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/IEKQRYMI4QSS3XHSQ73KDFEKJN6E4FJZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Victor Stinner]

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 python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WZDQJKEZTR3TTKEVF3MDAP6FCI4SMRDU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Victor Stinner]

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 I do is to open a Python REPL and I type: len("prefix")
and copy-paste the result :-)

Passing directly the length is a risk of mistake. What if I write
line[7:] and it works most of the time because of a space, but
sometimes the space is omitted randomly and the application fails?

--

The lazy approach is:

if line.startswith("prefix"): line = line[len("prefix"):]

Such code makes my "micro-optimizer hearth" bleeding since I know that
Python is stupid and calls len() at runtime, the compiler is unable to
optimize it (sadly for good reasons, len name can be overriden)  :-(

=> line.cutprefix("prefix") is more efficient! ;-) It's also also shorter.

Victor

Le dim. 22 mars 2020 à 17:02, Paul Ganssle  a écrit :
>
> 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 this case. It adds unnecessary complexity for subclass
> implementers to need to re-implement these two additional methods, and I
> can see no obvious reason why this behavior would be necessary, since
> these methods can be implemented in terms of string slicing.
>
> Even if you wanted to use `str`-specific optimizations in C that aren't
> available if you are constrained to use the subclass's __getitem__, it's
> inexpensive to add a "PyUnicode_CheckExact(self)" check to hit a "fast
> path" that doesn't use slice.
>
> I think defining this in terms of string slicing makes the most sense
> (and, notably, slice itself returns `str` unless explicitly overridden,
> the default is for it to return `str` anyway...).
>
> Either way, it would be nice to see the rationale included in the PEP
> somewhere.
>
> Best,
> Paul
>
> On 3/22/20 7:16 AM, Eric V. Smith wrote:
> > 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 characters) as a pointer, it
> > may
> > become harder to keep the same behavior for "x is y" where x and y
> > are
> > strings.
> >>> Are you suggesting that it could become impossible to write this
> >>> function:
> >>>
> >>>  def myself(o):
> >>>  return o
> >>>
> >>> and not be able to rely on "o is myself(o)"? That seems... a pretty
> >>> nasty breaking change for the language.
> >> Other way around - because strings are immutable, their identity isn't
> >> supposed to matter, so it's possible that functions that currently
> >> return the exact same object in some cases may in the future start
> >> returning a different object with the same value.
> >>
> >> Right now, in CPython, with no tagged pointers, we return the full
> >> existing pointer wherever we can, as that saves us a data copy. With
> >> tagged pointers, the pointer storage effectively *is* the instance, so
> >> you can't really replicate that existing "copy the reference not the
> >> storage" behaviour any more.
> >>
> >> That said, it's also possible that identity for tagged pointers would
> >> be value based (similar to the effect of the small integer cache and
> >> string interning), in which case the entire question would become
> >> moot.
> >>
> >> Either way, the PEP shouldn't be specifying that a new object *must*
> >> be returned, and it also shouldn't be specifying that the same object
> >> *can't* be returned.
> >
> > 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.
> >
> > Eric
> >
> > ___
> > 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
> > https://mail.python.org/archives/list/python-dev@python.org/message/JHM7T6JZU56PWYRJDG45HMRBXE3CBXMX/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> 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 
> https://mail.python.org/archives/list/python-dev@python.org/message/RTQWEE4KZYIIXL3HK3C6IJ2ATQ6

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Paul Ganssle]

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 like replace, the methods will
> raise a TypeError if any of self, pre or suf is not an instace of str,
> and will cast subclasses of str to builtin str objects.

I think the rationale for these differences is not made entirely clear,
specifically the "and will cast subclasses of str to builtin str
objects" part.

I think it would be best to define the truncation in terms of
__getitem__ - possibly with the caveat that implementations are allowed
(but not required) to return `self` unchanged if no match is found.

Best,
Paul

P.S. Dennis - just noticed in this reply that there is a typo in the PEP
- s/instace/instance

On 3/22/20 12:15 PM, Victor Stinner wrote:
> 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 I do is to open a Python REPL and I type: len("prefix")
> and copy-paste the result :-)
>
> Passing directly the length is a risk of mistake. What if I write
> line[7:] and it works most of the time because of a space, but
> sometimes the space is omitted randomly and the application fails?
>
> --
>
> The lazy approach is:
>
> if line.startswith("prefix"): line = line[len("prefix"):]
>
> Such code makes my "micro-optimizer hearth" bleeding since I know that
> Python is stupid and calls len() at runtime, the compiler is unable to
> optimize it (sadly for good reasons, len name can be overriden)  :-(
>
> => line.cutprefix("prefix") is more efficient! ;-) It's also also shorter.
>
> Victor
>
> Le dim. 22 mars 2020 à 17:02, Paul Ganssle  a écrit :
>> 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 this case. It adds unnecessary complexity for subclass
>> implementers to need to re-implement these two additional methods, and I
>> can see no obvious reason why this behavior would be necessary, since
>> these methods can be implemented in terms of string slicing.
>>
>> Even if you wanted to use `str`-specific optimizations in C that aren't
>> available if you are constrained to use the subclass's __getitem__, it's
>> inexpensive to add a "PyUnicode_CheckExact(self)" check to hit a "fast
>> path" that doesn't use slice.
>>
>> I think defining this in terms of string slicing makes the most sense
>> (and, notably, slice itself returns `str` unless explicitly overridden,
>> the default is for it to return `str` anyway...).
>>
>> Either way, it would be nice to see the rationale included in the PEP
>> somewhere.
>>
>> Best,
>> Paul
>>
>> On 3/22/20 7:16 AM, Eric V. Smith wrote:
>>> 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 characters) as a pointer, it
>>> may
>>> become harder to keep the same behavior for "x is y" where x and y
>>> are
>>> strings.
> Are you suggesting that it could become impossible to write this
> function:
>
>  def myself(o):
>  return o
>
> and not be able to rely on "o is myself(o)"? That seems... a pretty
> nasty breaking change for the language.
 Other way around - because strings are immutable, their identity isn't
 supposed to matter, so it's possible that functions that currently
 return the exact same object in some cases may in the future start
 returning a different object with the same value.

 Right now, in CPython, with no tagged pointers, we return the full
 existing pointer wherever we can, as that saves us a data copy. With
 tagged pointers, the pointer storage effectively *is* the instance, so
 you can't really replicate that existing "copy the reference not the
 storage" behaviour any more.

 That said, it's also possible that identity for tagged pointers would
 be value based (similar to the effect of the small integer cache and
 string interning), in which case the entire question would become
 moot.

 Either way, the PEP shouldn't be specifying that a new object *must*
 be returned, and it also shouldn't be specifying that the same object
 *can't

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Eric V. Smith]

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 above is 
that, as with other string methods like replace, the methods will 
raise a TypeError if any of self, pre or suf is not an instace of 
str, and will cast subclasses of str to builtin str objects.


I think the rationale for these differences is not made entirely 
clear, specifically the "and will cast subclasses of str to builtin 
str objects" part.
Agreed. I don't understand the rationale, either. If we stick with it, 
it should definitely be stated. And if we don't, that reason should be 
explained, too.


Eric

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/B4AGI7TJU5HC7VMYEO7VK63LTDMU7Q4M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[MRAB]

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"?
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/UL3SAVB3RGFTRFERG3J3VQNPQBXWTV7G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Guido van Rossum]

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 self if the class is exactly str is *just* an optimization
-- it must not be mandated nor ruled out.

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 a subclass
instance.

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

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/ZZTY3OCJFZTZM74MVWRYL23LFJGNKICU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Mike Miller]

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 functions.)


To jump on the bikeshed, trimprefix and trimsuffix are the best I've read so 
far, due to the definitions of the words in English.


Though often used interchangeably, when I think of "strip" I think of removing 
multiple things, somewhat indiscriminately with an arm motion, which is how the 
functions currently work.  e.g. "strip paint", "strip clothes":


https://www.dictionary.com/browse/strip
to take away or remove

When I think of trim, I think more of a single cut of higher precision with 
scissors.  e.g. "trim hair", "trim branches":


https://www.dictionary.com/browse/trim
to put into a neat or orderly condition by clipping…


Which is what this method would do.  That trim matches Go is a small but decent 
benefit.  Another person warned against inconsistency with PHP, but don't think 
PHP should be considered for design guidance, IMHO.  Perhaps as an example of 
what not to do, which happily is in agreement with the above.


-Mike

p.s.  +1, I do support this PEP, with or without name change, since some 
mentioned concern over that.

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/PE7KP36HUDXCQX7NYGEXSECOQOMVDZKG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Paul Ganssle]

> 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 a subclass instance.

My suggestion is to rely on __getitem__ here (for subclasses), in which
case we don't actually need to know the subclass constructor. The rough
implementation in the PEP shows how to do it without needing to know the
subclass constructor:

def redbikeshed(self, prefix):
    if self.startswith(pre):
    return self[len(pre):]
    return self[:]

The actual implementation doesn't need to be implemented that way, as
long as the result is always there result of slicing the original
string, it's safe to do so* and more convenient for subclass
implementers (who now only have to implement __getitem__ to get the
affix-trimming functions for free).

One downside to this scheme is that I think it makes getting the type
hinting right more complicated, since the return type of these functions
is basically, "Whatever the return type of self.__getitem__ is", but I
don't think anyone will complain if you write -> str with the
understanding that __getitem__ should return a str or a subtype thereof.

Best,
Paul

*Assuming they haven't messed with __getitem__ to do something
non-standard, but if they've done that I think they've tossed Liskov
substitution out the window and will have to re-implement these methods
if they want them to work.

On 3/22/20 2:03 PM, Guido van Rossum wrote:
> 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 self if the class is exactly str is *just* an
> optimization -- it must not be mandated nor ruled out.
>
> -- 
> --Guido van Rossum (python.org/~guido )
> /Pronouns: he/him //(why is my pronoun here?)/
> 
>
> ___
> 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 
> https://mail.python.org/archives/list/python-dev@python.org/message/ZZTY3OCJFZTZM74MVWRYL23LFJGNKICU/
> Code of Conduct: http://python.org/psf/codeofconduct/


signature.asc
Description: OpenPGP digital signature
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/Y3O7CBHJB4R34TYL7RDEU2TB5OPSNI3H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Dennis Sweeney]

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 returning ``self`` is an optimization
- Added links to past discussions on Python-Ideas and Python-Dev
- Specified ability to accept a tuple of strings
- Shorter abstract section and fewer stdlib examples
- Mentioned 
- Typo and formatting fixes

I didn't change the name because it didn't seem like there was a strong 
consensus for an alternative yet. I liked the suggestions of ``dropprefix`` or 
``removeprefix``.

All the 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 archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RY7GS4GF7OT7CLZVEDSULMY53QZYDN5Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Rob Cliffe via Python-Dev]

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 implementation would be
 - Clarified that returning ``self`` is an optimization
 - Added links to past discussions on Python-Ideas and Python-Dev
 - Specified ability to accept a tuple of strings
 - Shorter abstract section and fewer stdlib examples
 - Mentioned
 - Typo and formatting fixes

I didn't change the name because it didn't seem like there was a strong 
consensus for an alternative yet. I liked the suggestions of ``dropprefix`` or 
``removeprefix``.

All the best,
Dennis
___


Proofreading:

it would not be obvious for users to have to call 
'foobar'.cutprefix(('foo,)) for the common use case of a single prefix.


Missing single quote after the last foo.


s = 'foobar' * 100 + 'bar'
prefixes = ('bar', 'foo')
while len(s) != len(s := s.cutprefix(prefixes)): pass
s

'bar'

or the more obvious and readable alternative:


s = 'foo' * 100 + 'bar'
prefixes = ('bar', 'foo')
while s.startswith(prefixes): s = s.cutprefix(prefixes)
s

'bar'


Er no, in both these examples s is reduced to an empty string.

Best wishes
Rob Cliffe

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/HSCTQB4FVHM54REZEUKE5TRONFM7ZH2Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Dennis Sweeney]

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 s.startswith(prefixes): s = s.cutprefix(prefixes)
 >>> s
 'Baz'
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/QJ54X6WHQQ5HFROSJOLGJF4QMFINMAPY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Jump on C by PyEval_SetTrace Python 3.7.7

[Leandro Müller]

Hi everyone.

I'm trying to make a simple jump on C funcion trace by frame->f_lineno.
Example is simple, but not working.


if (frame->f_lineno == 12){

frame->f_lineno = 8;

}

attached files C and python to run test.
the line 12 I need to jump to line 8.




Att.

Leandro Müller
import importlib
import tracesys
import sys
import os

def teste(): 
print("7") 
print("8")
print("9")
print("10")
print("11")
print("12")
print("13")
print("14")


 
def get_module_to_file( ):
SY_BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)) + 
"/%s" % ("W64"))
SY_BASE_DIR = SY_BASE_DIR.replace("\\", "/") 
path1 = os.path.join(SY_BASE_DIR)
path1 = path1 +  "/check.py" 
filename = os.path.realpath(path1) 
filename = filename.replace("\\", "/")  
filename = filename.replace(SY_BASE_DIR, ".")
return filename

file = get_module_to_file()
# print(file)
# from threading import Thread
# t = Thread(target=teste)
# t.start()

tracesys.sys_settrace("lmuller", "session_login" )
tracesys.add_debug("lmuller", file,8, "lmuller", "session_login" )
teste()
print("fim")
# t = input()
from distutils.core import setup, Extension

module = Extension("tracesys",sources = ["trace.cpp"])
setup(name="Traca Package", version="1.0",description="Trace process",
ext_modules= [module]) 
#include "Python.h"
#include "frameobject.h" 
#include 
#include 
#include 
using namespace std;
typedef struct t_debug
{
char *user_debug;
char *user_console;
char *file;
int line;
char *id_wp;
char *session_login;
char *sessionid;
int *last;

} * st_debug;

static vector *list_debug = new vector();
static vector *list_debug_urgent = new vector();

char *user_console;
char *session_login;
char *sessionid;
static int conta = 0;

char *ReplaceAll(char *str1, const std::string &from, const std::string &to)
{
size_t start_pos = 0;
std::string str = str1;
while ((start_pos = str.find(from, start_pos)) != std::string::npos)
{
str.replace(start_pos, from.length(), to);
start_pos += to.length();
}
char *cstr = new char[str.length() + 1];
strcpy(cstr, str.c_str());

return cstr;
}

char *get_variable_char(PyObject *obj, int position)
{
PyObject *repr = PyObject_Repr(PyTuple_GetItem(obj, position));
PyObject *str = PyUnicode_AsEncodedString(repr, "utf-8", NULL);
char *s = PyBytes_AS_STRING(str);
string st = s;
if (st.length() < 2)
{
return "";
}
st = st.substr(1, st.length() - 2);
s = new char[st.length() + 1];
strcpy(s, st.c_str());
printf("%s \n", s);
return s;
}
int get_variable_int(PyObject *obj, int position)
{

return PyLong_AsLong(PyTuple_GetItem(obj, position));
}

int has_debug_session(char *user_console, char *file, int line, char 
*session_login)
{
int ret = -1;
try
{
size_t size = list_debug->size();
for (size_t i = 0; i < size; i++)
{
t_debug objl = list_debug->at(i);

if (strcmp(objl.user_console, user_console) == 0 &&
strcmp(objl.file, file) == 0 && (objl.line == line) &&
strcmp(objl.session_login, session_login) == 0)

{
ret = 0;
break;
}
}
}
catch (exception &e)
{
cout << "error process " << e.what() << '\n';
}
return ret;
}

int can_debug_session(char *user_c, char *file, int line, char *session_login)
{

try
{
size_t size = list_debug->size();
for (size_t i = 0; i < size; i++)
{
t_debug objl = list_debug->at(i);

if (strcmp(objl.user_console, user_c) == 0 &&
strcmp(objl.user_debug, user_c) == 0 &&
strcmp(objl.file, file) == 0 && (objl.line == line) &&
strcmp(objl.session_login, session_login) == 0)

{
return 0;
}

if (strcmp(objl.user_console, user_c) == 0 &&
!strcmp(objl.user_debug, user_c) == 0 &&
strcmp(objl.file, file) == 0 && (objl.line == line) &&
!strcmp(objl.session_login, session_login) == 0)

{
return 0;
}
}
}
catch (exception &e)
{
cout << "error process " << e.what() << '\n';
}
return -1;
}

int has_debug_urgent(char *sessionid)
{
int ret = -1;
try
{
size_t size = list_debug_urgent->size();
for (size_t i = 0; i < size; i++)
{
st_debug objl = list_debug_urgent->at(i);
if (strcmp(objl->sessionid, sessionid))

{
ret = 0;
break;
}
}
}
catch (exception &e)
{
cout << "error process " << e.what() << '\n';
}
return ret;
}

PyObject *add_debug_urgent(PyObject *mod, PyObject *obj)
{
Py_Initialize();
st_debug dict;
dict-