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 i
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.
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 ch
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
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 thi
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 bra
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
foun
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.o
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
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 lik
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 ab
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 self
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 function
> 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 o
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 returnin
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 imple
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.
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
19 matches
Mail list logo
