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
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
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
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
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
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
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
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
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
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
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
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
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"?
___
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
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
> 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 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
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
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
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
20 matches
Mail list logo
