On Tue, Mar 24, 2020 at 04:53:55PM +0100, Walter Dörwald wrote:
> But for `cutprefix()` (or whatever it's going to be called). I'm +1 on
> supporting multiple prefixes. For ambiguous cases, IMHO the most
> straight forward option would be to chop off the first prefix found.
The Zen of Python
-1 on "cut*" because my brain keeps reading it as "cute".
+1 on "trim*" as it is clear what's going on and no confusion with preexisting
methods.
+1 on "remove*" for the same reasons as "trim*".
And if no consensus is reached in this thread for a name I would assume the SC
is going to
On 3/23/20 11:17 PM, Leandro Müller wrote:
Hello Victor Stinner.
Thanks.
Your tip helped me a lot.
I understood that I need to get position on bycode of the line.
So I create the funcion to get position inside of the bycode.
Now I can to jump the correct position on trace.
frame->f_lasti =
Hi,
As an experiment, I thought I would try moving the thread state (what
you get from _PyThreadState_GET() ) to TLS.
https://github.com/python/cpython/compare/master...markshannon:threadstate_in_tls
It works, passing all the tests, and seems sound.
It is a small patch (< 50 lines) and
On 24 Mar 2020, at 2:42, Steven D'Aprano wrote:
On Sun, Mar 22, 2020 at 10:25:28PM -, Dennis Sweeney wrote:
Changes:
- More complete Python implementation to match what the type
checking in the C implementation would be
- Clarified that returning ``self`` is an optimization
Does it work with subinterepreters? Especially when a native thread
has two Python thread states of two different interpreters.
Victor
Le mar. 24 mars 2020 à 16:36, Mark Shannon a écrit :
>
> Hi,
>
> As an experiment, I thought I would try moving the thread state (what
> you get from
On 24/03/2020 5:26 pm, Victor Stinner wrote:
Does it work with subinterepreters? Especially when a native thread
has two Python thread states of two different interpreters.
A native thread can only have one Python thread at a time, and must
switch using the PyThreadState_Swap() API.
So, I
On Tue, Mar 24, 2020 at 11:55 AM Brett Cannon wrote:
> -1 on "cut*" because my brain keeps reading it as "cute".
> +1 on "trim*" as it is clear what's going on and no confusion with
> preexisting methods.
> +1 on "remove*" for the same reasons as "trim*".
>
> And if no consensus is reached in
I think my confusion is about just how precise this sort of "reference
implementation" should be. Should it behave with ``str`` and ``tuple``
subclasses exactly how it would when implemented? If so, I would expect the
following to work:
class S(str): __len__ = __getitem__ = __iter__ = None
On Tue, Mar 24, 2020 at 08:14:33PM -, Dennis Sweeney wrote:
> I think my confusion is about just how precise this sort of "reference
> implementation" should be. Should it behave with ``str`` and ``tuple``
> subclasses exactly how it would when implemented? If so, I would expect the
>
On 3/24/2020 3:30 PM, Steve Dower wrote:
On 24Mar2020 1849, Brett Cannon wrote:
-1 on "cut*" because my brain keeps reading it as "cute".
+1 on "trim*" as it is clear what's going on and no confusion with
preexisting methods.
+1 on "remove*" for the same reasons as "trim*".
And if no
On Tue, Mar 24, 2020 at 08:14:33PM -, Dennis Sweeney wrote:
> I think then maybe it would be preferred to
> use the something like the following in the PEP:
>
> def cutprefix(self, prefix, /):
> if isinstance(prefix, str):
> if self.startswith(prefix):
>
On 24Mar2020 1849, Brett Cannon wrote:
-1 on "cut*" because my brain keeps reading it as "cute".
+1 on "trim*" as it is clear what's going on and no confusion with preexisting
methods.
+1 on "remove*" for the same reasons as "trim*".
And if no consensus is reached in this thread for a name I
Hi Dennis,
Thanks for the updated PEP, it looks way better! I love the ability to
pass a tuple of strings ;-)
--
The behavior of tuple containing an empty string is a little bit surprising.
cutsuffix("Hello World", ("", " World")) returns "Hello World",
whereas cutsuffix("Hello World", ("
Hello,
On Tue, 24 Mar 2020 19:14:16 +0100
Victor Stinner wrote:
[]
> The behavior of tuple containing an empty string is a little bit
> surprising.
>
> cutsuffix("Hello World", ("", " World")) returns "Hello World",
> whereas cutsuffix("Hello World", (" World", "")) returns "Hello".
>
>
On 03/24/2020 01:37 PM, Eric V. Smith wrote:
On 3/24/2020 3:30 PM, Steve Dower wrote:
On 24Mar2020 1849, Brett Cannon wrote:
-1 on "cut*" because my brain keeps reading it as "cute".
+1 on "trim*" as it is clear what's going on and no confusion with preexisting
methods.
+1 on "remove*" for
Steven D'Aprano wrote:
> On Tue, Mar 24, 2020 at 08:14:33PM -, Dennis Sweeney wrote:
> > I think then maybe it would be preferred to
> > use the something like the following in the PEP:
> > def cutprefix(self, prefix, /):
> > if isinstance(prefix, str):
> > if
On Tue, Mar 24, 2020 at 2:53 PM Ethan Furman wrote:
> On 03/24/2020 01:37 PM, Eric V. Smith wrote:
> > On 3/24/2020 3:30 PM, Steve Dower wrote:
> >> On 24Mar2020 1849, Brett Cannon wrote:
> >>> -1 on "cut*" because my brain keeps reading it as "cute".
> >>> +1 on "trim*" as it is clear what's
Hello,
On Tue, 24 Mar 2020 22:51:55 +0100
Victor Stinner wrote:
> > === config.something ===
> > # If you'd like to remove some prefix from your lines, set it here
> > REMOVE_PREFIX = ""
> > ==
> >
> > === src.py ===
> > ...
> > line = line.cutprefix(config.REMOVE_PREFIX)
> > ...
> > ==
Dennis Sweeney wrote:
Steven D'Aprano wrote:
Dennis Sweeney wrote:
I think then maybe it would be preferred to
use the something like the following in the PEP:
def cutprefix(self, prefix, /):
if isinstance(prefix, str):
if self.startswith(prefix):
return
On 25/03/20 9:14 am, Dennis Sweeney wrote:
I think my confusion is about just how precise this sort of
"reference implementation" should be. Should it behave with ``str``
and ``tuple`` subclasses exactly how it would when implemented?
No, I don't think so. The purpose of a Python
It seems that there is a consensus on the names ``removeprefix`` and
``removesuffix``. I will update the PEP accordingly. I'll also simplify sample
Python implementation to primarily reflect *intent* over strict type-checking
correctness, and I'll adjust the accompanying commentary accordingly.
Thanks for the pointers to emails.
Ethan Furman: "This is why replace() still only takes a single
substring to match and this isn't supported: (...)"
Hum ok, it makes sense. I agree that we can start with only accepting
str (reject tuple), and maybe reconsider the idea of accepting a tuple
of
On 03/24/2020 06:10 PM, Victor Stinner wrote:
Ethan Furman: "This is why replace() still only takes a single
substring to match and this isn't supported: (...)"
Correction: The above quote belongs to Steven D'Aprano.
--
~Ethan~
___
Python-Dev
Hi Mark,
Le mar. 24 mars 2020 à 21:05, Mark Shannon a écrit :
> A native thread can only have one Python thread at a time, and must
> switch using the PyThreadState_Swap() API.
Right.
> So, I think the answer is yes.
Nice.
> Do you have a specific example or testcase?
I don't know well the
> -1 on "cut*" (feels too much like what .partition() does)
> -0 on "trim*" (this is the name used in .NET instead of "strip", so I
> foresee new confusion)
> +1 on "remove*" (because this is exactly what it does)
I'm also most strongly in favor of "remove*" (out of the above options).
I'm
On 3/24/2020 7:21 PM, Dennis Sweeney wrote:
It seems that there is a consensus on the names ``removeprefix`` and
``removesuffix``. I will update the PEP accordingly. I'll also simplify sample
Python implementation to primarily reflect *intent* over strict type-checking
correctness, and I'll
Le mer. 25 mars 2020 à 00:29, Dennis Sweeney
a écrit :
> Lastly, since the issue of multiple prefixes/suffixes is more controversial
> and seems that it would not affect how the single-affix cases would work, I
> can remove that from this PEP and allow someone else with a stronger opinion
>
There were at least two comments suggesting keeping it to one affix at a time:
https://mail.python.org/archives/list/python-dev@python.org/message/GPXSIDLKTI6WKH5EKJWZEG5KR4AQ6P3J/
https://mail.python.org/archives/list/python-dev@python.org/message/EDWFPEGQBPTQTVZV5NDRC2DLSKCXVJPZ/
But I didn't
Le mar. 24 mars 2020 à 20:06, Paul Sokolovsky a écrit :
> === config.something ===
> # If you'd like to remove some prefix from your lines, set it here
> REMOVE_PREFIX = ""
> ==
>
> === src.py ===
> ...
> line = line.cutprefix(config.REMOVE_PREFIX)
> ...
> ==
Just use:
if
30 matches
Mail list logo
