On Wed, 25 Mar 2020 at 00:42, Dennis Sweeney
wrote:
>
> 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@pyth
Walter Dörwald writes:
> A `find()` that supports multiple search strings (and returns the
> leftmost position where a search string can be found) is a great help in
> implementing some kind of tokenizer:
In other words, you want the equivalent of Emacs's "(search-forward
(regexp-opt list-of
On 2020-03-23 17:43, Stefan Behnel wrote:
As (first-time) BDFL delegate, I accept PEP 573 for Python 3.9,
"Module State Access from C Extension Methods"
https://www.python.org/dev/peps/pep-0573/
Petr, Nick, Eric and Marcel, thank you for your work and intensive
discussions on this PEP, and also
On 25 Mar 2020, at 9:48, Stephen J. Turnbull wrote:
Walter Dörwald writes:
A `find()` that supports multiple search strings (and returns the
leftmost position where a search string can be found) is a great help
in
implementing some kind of tokenizer:
In other words, you want the equivalent
I'm removing the tuple feature from this PEP. So now, if I understand
correctly, I don't think there's disagreement about behavior, just about
how that behavior should be summarized in Python code.
Ethan Furman wrote:
> > It appears that in CPython, self[:] is self is true for base
> > str
> > o
On 3/25/2020 8:12 AM, Petr Viktorin wrote:
On 2020-03-23 17:43, Stefan Behnel wrote:
As (first-time) BDFL delegate, I accept PEP 573 for Python 3.9,
"Module State Access from C Extension Methods"
https://www.python.org/dev/peps/pep-0573/
Petr, Nick, Eric and Marcel, thank you for your work and
On 3/25/2020 1:36 PM, Dennis Sweeney wrote:
I'm removing the tuple feature from this PEP. So now, if I understand
correctly, I don't think there's disagreement about behavior, just about
how that behavior should be summarized in Python code.
I think that's right.
Ethan Furman wrote:
It appears
I've said a few times that I think it would be good if the behavior were
defined /in terms of __getitem__/'s behavior. If the rough behavior is this:
def removeprefix(self, prefix):
if self.startswith(prefix):
return self[len(prefix):]
else:
return self[:]
Then you can shi
Dennis Sweeney wrote:
---
It appears that in CPython, self[:] is self is true for base
str objects, so I think return self[:] is consistent with (1) the
premise that returning self is an implementation detail that is
neither mandated nor forbidden, and (2) the premise that the
I was surprised by the following behavior:
class MyStr(str):
def __getitem__(self, key):
if isinstance(key, slice) and key.start is key.stop is key.end:
return self
return type(self)(super().__getitem__(key))
my_foo = MyStr("foo")
MY_FO
I imagine it's an implementation detail of which ones depend on __getitem__.
The only methods that would be reasonably amenable to a guarantee like
"always returns the same thing as __getitem__" would be (l|r|)strip(),
split(), splitlines(), and .partition(), because they only work with
subsets of
Serhiy had the idea of having Enum._convert also modify the __str__ and
__repr__ of newly created enumerations to display the module name instead
of the enumeration name (https://bugs.python.org/msg325007):
--> socket.AF_UNIX
==>
--> print(socket.AF_UNIX)
AddressFamily.AF_UNIX==> s
On 25Mar2020 12:54, Ethan Furman wrote:
Serhiy had the idea of having Enum._convert also modify the __str__ and
__repr__ of newly created enumerations to display the module name instead
of the enumeration name (https://bugs.python.org/msg325007):
--> socket.AF_UNIX
==>
--> print(socket.AF
26.03.20 00:08, Cameron Simpson пише:
I think a more "Python normal" module might have multiple enum classes,
maybe with overlapping names.
Do you have any examples of more "Python normal" modules? We discuss
here the behavior of the private method Enum._convert_() used
exclusively in the std
On Tue, Mar 24, 2020 at 07:14:16PM +0100, Victor Stinner wrote:
> I would prefer to raise ValueError("empty separator") to avoid any
> risk of confusion. I'm not sure that str.cutprefix("") or
> str.cutsuffix("") does make any sense.
They make as much sense as any other null-operation, such as su
On 26Mar2020 00:35, Serhiy Storchaka wrote:
26.03.20 00:08, Cameron Simpson пише:
I think a more "Python normal" module might have multiple enum
classes, maybe with overlapping names.
Do you have any examples of more "Python normal" modules?
Unfortunately no because I am not yet using enums
I'm skeptical about anything that hides an object's "true nature": this is a major landmine in diagnostics because it lies to you about what
you are looking at and where to look for its implementation.
E. g. in this case, AF_UNIX is a member of some entity called "AddressFamily" -- so I would se
On Thu, Mar 26, 2020 at 10:38 AM Ivan Pozdeev via Python-Dev
wrote:
>
> I'm skeptical about anything that hides an object's "true nature": this is a
> major landmine in diagnostics because it lies to you about what
> you are looking at and where to look for its implementation.
>
> E. g. in this c
On 03/25/2020 12:54 PM, Ethan Furman wrote:
--> socket.AF_UNIX
==>
--> print(socket.AF_UNIX)
AddressFamily.AF_UNIX ==> socket.AF_UNIX
An important point I should have included -- the definition of
AddressFamily:
IntEnum._convert_(
'AddressFamily',
__name
On 26.03.2020 2:41, Chris Angelico wrote:
On Thu, Mar 26, 2020 at 10:38 AM Ivan Pozdeev via Python-Dev
wrote:
I'm skeptical about anything that hides an object's "true nature": this is a
major landmine in diagnostics because it lies to you about what
you are looking at and where to look for
On Thu, Mar 26, 2020 at 12:08 PM Ivan Pozdeev via Python-Dev
wrote:
>
>
> On 26.03.2020 2:41, Chris Angelico wrote:
> > On Thu, Mar 26, 2020 at 10:38 AM Ivan Pozdeev via Python-Dev
> > wrote:
> >> I'm skeptical about anything that hides an object's "true nature": this is
> >> a major landmine in
On 26.03.2020 4:10, Chris Angelico wrote:
On Thu, Mar 26, 2020 at 12:08 PM Ivan Pozdeev via Python-Dev
wrote:
On 26.03.2020 2:41, Chris Angelico wrote:
On Thu, Mar 26, 2020 at 10:38 AM Ivan Pozdeev via Python-Dev
wrote:
I'm skeptical about anything that hides an object's "true nature": this
On 24Mar2020 18:49, 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*".
I reiterate my huge -1 on "trim" because it will confuse e
On 25Mar2020 08:14, Paul Moore wrote:
[...] The issue for me is how the function
should behave with a list of affixes if one is a prefix of another,
e.g.,removeprefix(('Test', 'Tests')). The empty string case is just
one form of that. The behaviour should be defined clearly, and while I
imagine
24 matches
Mail list logo
