[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
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@python.org/message/EDWFPEGQBPTQTVZV5NDRC2DLSKCXVJPZ/
>
> But I didn't see any big objections to the rest of the PEP, so I think maybe
> we keep it restricted for now.
That sounds like a good idea. 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 "always remove the longest" is the "obvious" sensible choice,
I am fairly certain there will be other opinions :-) So deferring the
decision for now until we have more experience with the single-affix
form seems perfectly reasonable.
I'm not even sure that switching to multiple affixes later would need
a PEP - it might be fine to add via a simple feature request issue.
But that can be a decision for later, too.
Paul
___
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/4ELRLN2V3OIXD7PPSTMCGMH3METJWS5W/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
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-strings))", which also meets the requirement of returning which string was found (as "(match-string 0)"). Since Python already has a functionally similar API for regexps, we can add a regexp-opt (with appropriate name) method to re, perhaps as .compile_string_list(), and provide a convenience function re.search_string_list() for your application. I'm applying practicality before purity, of course. To some extent we want to encourage simple string approaches, and putting this in regex is not optimal for that. 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/SUUZNXUTB774GWSLPKLPVHN7VK237I2D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 573 (Module State Access from C Extension Methods)
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 to everyone else who got involved on mailing lists, sprints and conferences. It was a long process with several iterations, much thinking, rethinking and cutting down along the way, Python 3.7 *and* 3.8 being missed, but 3.9 now finally being hit. Together with several other improvements to the C-API in the upcoming release, this will help making extension modules less "different" and easier to adapt for subinterpreters. That's great news! Thank you! I'll schedule some time in the coming weeks to get the implementation ready for review. ___ 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/PLNR6FZPDWY6AXLZNLVL445MSHTJOBPW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
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 of Emacs's "(search-forward (regexp-opt list-of-strings))", which also meets the requirement of returning which string was found (as "(match-string 0)"). Sounds like it. I'm not familiar with Emacs. Since Python already has a functionally similar API for regexps, we can add a regexp-opt (with appropriate name) method to re, perhaps as .compile_string_list(), and provide a convenience function re.search_string_list() for your application. If you're using regexps anyway, building the appropriate or-expression shouldn't be a problem. I guess that's what most lexers/tokenizers do anyway. I'm applying practicality before purity, of course. To some extent we want to encourage simple string approaches, and putting this in regex is not optimal for that. Exactly. I'm always a bit hesitant when using regexps, if there's a simpler string approach. Steve Servus, Walter ___ 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/46KMMKYHW7DIDNZFO27GNQCJVILNSQ6Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
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 > > 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 methods should return base > > str objects even when called on str subclasses. > The Python interpreter in my head sees self[:] and returns a copy. > A > note that says a str is returned would be more useful than trying to > exactly mirror internal details in the Python "roughly equivalent" code. I think I'm still in the camp that ``return self[:]`` more precisely prescribes the desired behavior. It would feel strange to me to write ``return self`` and then say "but you don't actually have to return self, and in fact you shouldn't when working with subclasses". To me, it feels like return (the original object unchanged, or a copy of the object, depending on implementation details, but always make a copy when working with subclasses) is well-summarized by return self[:] especially if followed by the text Note that ``self[:]`` might not actually make a copy -- if the affix is empty or not found, and if ``type(self) is str``, then these methods may, but are not required to, make the optimization of returning ``self``. However, when called on instances of subclasses of ``str``, these methods should return base ``str`` objects, not ``self``. ...which is a necessary explanation regardless. Granted, ``return self[:]`` isn't perfect if ``__getitem__`` is overridden, but at the cost of three characters, the Python gains accuracy over both the optional nature of returning ``self`` in all cases and the impossibility (assuming no dunders are overridden) of returning self for subclasses. It also dissuades readers from relying on the behavior of returning self, which we're specifying is an implementation detail. Is that text explanation satisfactory? ___ 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/4E77QD52JCMHSP7O62C57XILLQN6SPCT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 573 (Module State Access from C Extension Methods)
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 intensive discussions on this PEP, and also to everyone else who got involved on mailing lists, sprints and conferences. It was a long process with several iterations, much thinking, rethinking and cutting down along the way, Python 3.7 *and* 3.8 being missed, but 3.9 now finally being hit. Together with several other improvements to the C-API in the upcoming release, this will help making extension modules less "different" and easier to adapt for subinterpreters. That's great news! Thank you! I'll schedule some time in the coming weeks to get the implementation ready for review. Reminder: 3.9.0 beta 1 scheduled for Monday, 2020-05-18 -- Terry Jan Reedy ___ 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/BLCUXYVPAWOFEBGSGUVVXSM7DQXJVPSZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
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 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 methods should return base str objects even when called on str subclasses. The Python interpreter in my head sees self[:] and returns a copy. A note that says a str is returned would be more useful than trying to exactly mirror internal details in the Python "roughly equivalent" code. I think I'm still in the camp that ``return self[:]`` more precisely prescribes the desired behavior. It would feel strange to me to write ``return self`` and then say "but you don't actually have to return self, and in fact you shouldn't when working with subclasses". To me, it feels like return (the original object unchanged, or a copy of the object, depending on implementation details, but always make a copy when working with subclasses) is well-summarized by return self[:] especially if followed by the text Note that ``self[:]`` might not actually make a copy -- if the affix is empty or not found, and if ``type(self) is str``, then these methods may, but are not required to, make the optimization of returning ``self``. However, when called on instances of subclasses of ``str``, these methods should return base ``str`` objects, not ``self``. ...which is a necessary explanation regardless. Granted, ``return self[:]`` isn't perfect if ``__getitem__`` is overridden, but at the cost of three characters, the Python gains accuracy over both the optional nature of returning ``self`` in all cases and the impossibility (assuming no dunders are overridden) of returning self for subclasses. It also dissuades readers from relying on the behavior of returning self, which we're specifying is an implementation detail. Is that text explanation satisfactory? Yes, that makes sense to me. I haven't had time to review the most recent updates, and I'll probably wait until you update it one more time. 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/VE65KII4ZAQV4BR4RACCIOQ27BWRPNYI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
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 shift all the guarantees about whether the subtype is str and whether it might return `self` when the prefix is missing onto the implementation of __getitem__. For CPython's implementation of str, `self[:]` returns `self`, so it's clearly true that __getitem__ is allowed to return `self` in some situations. Subclasses that do not override __getitem__ will return the str base class, and subclasses that /do/ overwrite __getitem__ can choose what they want to do. So someone could make their subclass do this: class MyStr(str): def __getitem__(self, key): if isinstance(key, slice) and key.start is key.stop is key.end is None: return self return type(self)(super().__getitem__(key)) They would then get "removeprefix" and "removesuffix" for free, with the desired semantics and optimizations. If we go with this approach (which again I think is much friendlier to subclassers), that obviates the problem of whether `self[:]` is a good summary of something that can return `self`: since "does the same thing as self[:]" /is/ the behavior it's trying to describe, there's no ambiguity. Best, Paul On 3/25/20 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. > > Ethan Furman 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 methods should return base >>> str objects even when called on str subclasses. >> The Python interpreter in my head sees self[:] and returns a copy. >> A >> note that says a str is returned would be more useful than trying to >> exactly mirror internal details in the Python "roughly equivalent" code. > I think I'm still in the camp that ``return self[:]`` more precisely > prescribes > the desired behavior. It would feel strange to me to write ``return self`` > and then say "but you don't actually have to return self, and in fact > you shouldn't when working with subclasses". To me, it feels like > > return (the original object unchanged, or a copy of the object, > depending on implementation details, > but always make a copy when working with subclasses) > > is well-summarized by > >return self[:] > > especially if followed by the text > > Note that ``self[:]`` might not actually make a copy -- if the affix > is empty or not found, and if ``type(self) is str``, then these methods > may, but are not required to, make the optimization of returning ``self``. > However, when called on instances of subclasses of ``str``, these > methods should return base ``str`` objects, not ``self``. > > ...which is a necessary explanation regardless. Granted, ``return self[:]`` > isn't perfect if ``__getitem__`` is overridden, but at the cost of three > characters, the Python gains accuracy over both the optional nature of > returning ``self`` in all cases and the impossibility (assuming no dunders > are overridden) of returning self for subclasses. It also dissuades readers > from relying on the behavior of returning self, which we're specifying is > an implementation detail. > > Is that text explanation satisfactory? > ___ > 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/4E77QD52JCMHSP7O62C57XILLQN6SPCT/ > 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/GG5BOKPQCP7J5RRWABEYOZDNDTH3UC6T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
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 methods should return base str objects even when called on str subclasses. Ethan Furman wrote: --- The Python interpreter in my head sees self[:] and returns a copy. Dennis Sweeney wrote: --- I think I'm still in the camp that ``return self[:]`` more precisely prescribes the desired behavior. It would feel strange to me to write ``return self`` and then say "but you don't actually have to return self, and in fact you shouldn't when working with subclasses". I don't understand that list bit -- surely, if I'm bothering to implement `removeprefix` and `removesuffix` in my subclass, I would also want to `return self` to keep my subclass? Why would I want to go through the extra overhead of either calling my own `__getitem__` method, or have the `str.__getitem__` method discard my subclass? However, if you are saying that `self[:]` *will* call `self.__class__.__getitem__` so my subclass only has to override `__getitem__` instead of `removeprefix` and `removesuffix`, that I can be happy with. -- ~Ethan~ ___ 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/GTSUGU3CLYGS6R6DPEPNKD4IBN6PESGW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
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_FOO = MyStr("FOO")
My_Foo = MyStr("Foo")
empty = MyStr("")
assert type(my_foo.casefold()) is str
assert type(MY_FOO.capitalize()) is str
assert type(my_foo.center(3)) is str
assert type(my_foo.expandtabs()) is str
assert type(my_foo.join(())) is str
assert type(my_foo.ljust(3)) is str
assert type(my_foo.lower()) is str
assert type(my_foo.lstrip()) is str
assert type(my_foo.replace("x", "y")) is str
assert type(my_foo.split()[0]) is str
assert type(my_foo.splitlines()[0]) is str
assert type(my_foo.strip()) is str
assert type(empty.swapcase()) is str
assert type(My_Foo.title()) is str
assert type(MY_FOO.upper()) is str
assert type(my_foo.zfill(3)) is str
assert type(my_foo.partition("z")[0]) is MyStr
assert type(my_foo.format()) is MyStr
I was under the impression that all of the ``str`` methods exclusively returned
base ``str`` objects. Is there any reason why those two are different, and is
there a reason that would apply to ``removeprefix`` and ``removesuffix`` as
well?
___
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/TVDATHMCK25GT4OTBUBDWG3TBJN6DOKK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
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 the input string.
Most of the other stuff involves constructing new strings and it's
harder to cast them in terms of other "primitive operations" since
strings are immutable.
I suspect that to the extent that the ones that /could/ be implemented
in terms of __getitem__ are returning base strings, it's either because
no one thought about doing it at the time and they used another
mechanism or it was a deliberate choice to be consistent with the other
methods.
I don't see removeprefix and removesuffix explicitly being implemented
in terms of slicing operations as a huge win - you've demonstrated that
someone who wants a persistent string subclass still would need to
override a /lot/ of methods, so two more shouldn't hurt much - I just
think that "consistent with most of the other methods" is a
/particularly/ good reason to avoid explicitly defining these operations
in terms of __getitem__. The /default/ semantics are the same (i.e. if
you don't explicitly change the return type of __getitem__, it won't
change the return type of the remove* methods), and the only difference
is that for all the /other/ methods, it's an implementation detail
whether they call __getitem__, whereas for the remove methods it would
be explicitly documented.
In my ideal world, a lot of these methods would be redefined in terms of
a small set of primitives that people writing subclasses could implement
as a protocol that would allow methods called on the functions to retain
their class, but I think the time for that has passed. Still, I don't
think it would /hurt/ for new methods to be defined in terms of what
primitive operations exist where possible.
Best,
Paul
On 3/25/20 3:09 PM, Dennis Sweeney wrote:
> 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_FOO = MyStr("FOO")
> My_Foo = MyStr("Foo")
> empty = MyStr("")
>
> assert type(my_foo.casefold()) is str
> assert type(MY_FOO.capitalize()) is str
> assert type(my_foo.center(3)) is str
> assert type(my_foo.expandtabs()) is str
> assert type(my_foo.join(())) is str
> assert type(my_foo.ljust(3)) is str
> assert type(my_foo.lower()) is str
> assert type(my_foo.lstrip()) is str
> assert type(my_foo.replace("x", "y")) is str
> assert type(my_foo.split()[0]) is str
> assert type(my_foo.splitlines()[0]) is str
> assert type(my_foo.strip()) is str
> assert type(empty.swapcase()) is str
> assert type(My_Foo.title()) is str
> assert type(MY_FOO.upper()) is str
> assert type(my_foo.zfill(3)) is str
>
> assert type(my_foo.partition("z")[0]) is MyStr
> assert type(my_foo.format()) is MyStr
>
> I was under the impression that all of the ``str`` methods exclusively
> returned base ``str`` objects. Is there any reason why those two are
> different, and is there a reason that would apply to ``removeprefix`` and
> ``removesuffix`` as well?
> ___
> 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/TVDATHMCK25GT4OTBUBDWG3TBJN6DOKK/
> 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/L3ZQLTUWWTNKCWTTSJSOX3ME4EDSS4FR/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
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==> socket.AF_UNIX Thoughts? -- ~Ethan~ ___ 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/GMOJRM4GPJJJSBYFR4RZSDBVB2SYJAM4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
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_UNIX) AddressFamily.AF_UNIX==> socket.AF_UNIX Thoughts? I'm uncomfortable. The socket module is something of a special case because its enums come from the C library constants, which therefore have nice global names like "AF_UNIX" because C is one big namespace; you can infer that they are address family constants from their prefix. I think a more "Python normal" module might have multiple enum classes, maybe with overlapping names. Invented but plausible example: class ANSIColourNames(enum): NORMAL = 0 REVERSE = 7 UNDERLINE = 4 BOLD = 1 BLACK = 30 RED = 31 ... and another: class SpecialNonANSITerminalCOlours(enum): NORMAL = 0 REVERSE = 15 RED = 3 ... i.e. different classes with the same purpose specific enum names inside. If I only got a module name back from __str__ I'd be underwhelmed. I think I'd at least like the behaviour switchable in some way. 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/DXA7DNOSSH7F4UTA2Q2NNT6QGQMVSKDI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
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 stdlib. ___ 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/TZUTDKVFS5SL4472XDSTTBVXIXKRVCVB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
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 subtracting
0 or deleting empty slices from lists.
Every string s is unchanged if you prepend or concatenate the empty
string:
assert s == ''+s == s+''
so removing the empty string should obey the same invariant:
assert s == s.removeprefix('') == s.removesuffix('')
--
Steven
___
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/X7N57XKA3S7TK4W6OUJBCCLDSTERK636/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
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 as much as I should. We discuss here the behavior of the private method Enum._convert_() used exclusively in the stdlib. My concern is basicly that in normal Python usage, the names within a class (and thus the names in an enum) are named to be distinct within the class namespace. So I would not expect the names for particular values to have extra qualification (eg I expect them to be like the "RED" in my two class example - getting "module_name.RED" doesn't inform the user about which class is in use, and since they might reasonably have different concrete values like 4 versus 7 that seems unfortunate). I agree that having the enums from the socket module just recite "socket.AF_UNIX" would be nice. So if those enums overrode the Enum._convert_() method I see no reason to object. However, that only works because those names mirror the C library names, which are already globally unique. So my discomfort is present only if there were a general change affecting all enums, rather than a socket-module-specific change affecting just the enums from the socket module. 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/HATTBNW4JA2EBGT745QQSANG2JKLVM7V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
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 search the code for "AddressFamily" to see what I'm looking at and what else I can do with it. The fact that it's also directly availabe from the `socket` module is incidental: it could be as easily made available from anywhere else -- not even a module. On 25.03.2020 22: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_UNIX) AddressFamily.AF_UNIX ==> socket.AF_UNIX Thoughts? -- ~Ethan~ ___ 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/GMOJRM4GPJJJSBYFR4RZSDBVB2SYJAM4/ Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan ___ 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/M2TLOP7O6JSQK5XXKIS6INUXYDONRWV5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
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 case, AF_UNIX is a member of some entity called "AddressFamily" > -- so I would search the code for "AddressFamily" to see what > I'm looking at and what else I can do with it. The fact that it's also > directly availabe from the `socket` module is incidental: it could be > as easily made available from anywhere else -- not even a module. > But if it's described as socket.AF_UNIX then you know where to go looking for it, and type() can tell you the type if you actually need it. +1 for changing the socket enums; -1 for changing enums in general. ChrisA ___ 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/O4XYZC7FBEO3ELAZGLEUNQY6PDCP7PED/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
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__,
lambda C: C.isupper() and C.startswith('AF_')
)
That last line is filtering the globals from `__name__`* to make the
Enum -- in other words, the member names are already globally unique.
Every usage of `Enum._convert` is like that.
--
~Ethan~
* `__name__` is the module name, which is looked up in `sys.modules`.
___
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/HJBSDMG3DSEAVHNAUIGZTOXMC5BLVLNO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class 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 its implementation. E. g. in this case, AF_UNIX is a member of some entity called "AddressFamily" -- so I would search the code for "AddressFamily" to see what I'm looking at and what else I can do with it. The fact that it's also directly availabe from the `socket` module is incidental: it could be as easily made available from anywhere else -- not even a module. But if it's described as socket.AF_UNIX then you know where to go looking for it, No, I don't. https://docs.python.org/3/library/functions.html#repr sets the standard -- thus the expectation -- for user-defined types: "...otherwise the representation is a string enclosed in angle brackets that contains the name of the type of the object together with additional information often including the name and address of the object" -- which this suggestion would be breaking. By this standard, "socket.AF_UNIX" looks like something defined directly at module level. So I'll be looking for a definition at module level -- and not find it. At which point, I'd suspect shenanigans like a dynamic creation or assignment. Which can be absolutely anywhere! And I'll be looking for the wrong thing still! and type() can tell you the type if you actually needit. That's an additional, unnecessary, nonstandard step that I somehow need to know to make because this is not standard practice, as per above. I do not expect such treachery, I expect repr() to give me truthful and accurate information! And even once I begin expecting it and additionally checking type() of everything that I examine from that point on (since I'll know that Python has crossed the line, I cannot trust repr() of anything any longer), that is lots of extra work, totally unwelcome and uncalled for! All for a tiny benefit, in one niche case. +1 for changing the socket enums; -1 for changing enums in general. ChrisA ___ 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/O4XYZC7FBEO3ELAZGLEUNQY6PDCP7PED/ Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan ___ 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/FSGJ3E43PWQE6NQGU7A5ICHTPQR3UHKR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
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 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 search the code for "AddressFamily" to see > >> what > >> I'm looking at and what else I can do with it. The fact that it's also > >> directly availabe from the `socket` module is incidental: it could be > >> as easily made available from anywhere else -- not even a module. > >> > > But if it's described as socket.AF_UNIX then you know where to go > > looking for it, > > No, I don't. https://docs.python.org/3/library/functions.html#repr sets the > standard -- thus the expectation -- for user-defined types: > "...otherwise the representation is a string enclosed in angle brackets that > contains the name of the type of the object together with > additional information often including the name and address of the object" -- > which this suggestion would be breaking. > > By this standard, "socket.AF_UNIX" looks like something defined directly at > module level. So I'll be looking for a definition at module > level -- and not find it. At which point, I'd suspect shenanigans like a > dynamic creation or assignment. Which can be absolutely anywhere! > And I'll be looking for the wrong thing still! > """For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval()...""" >>> socket.AF_UNIX If the repr were "socket.AF_UNIX", then that would indeed be a string that would yield an object with the same value. The current repr isn't wrong by this definition, but nor is the proposed change. Is it defined at module level? I couldn't care less; all that matters is that it is *accessible* at module level. I don't have to say "socket.AddressFamily.AF_UNIX". ChrisA ___ 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/4Q7SVP6ZXR4SAPMDWYGPH7OWX5YXI44M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
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 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 search the code for "AddressFamily" to see what I'm looking at and what else I can do with it. The fact that it's also directly availabe from the `socket` module is incidental: it could be as easily made available from anywhere else -- not even a module. But if it's described as socket.AF_UNIX then you know where to go looking for it, No, I don't. https://docs.python.org/3/library/functions.html#repr sets the standard -- thus the expectation -- for user-defined types: "...otherwise the representation is a string enclosed in angle brackets that contains the name of the type of the object together with additional information often including the name and address of the object" -- which this suggestion would be breaking. By this standard, "socket.AF_UNIX" looks like something defined directly at module level. So I'll be looking for a definition at module level -- and not find it. At which point, I'd suspect shenanigans like a dynamic creation or assignment. Which can be absolutely anywhere! And I'll be looking for the wrong thing still! """For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval()...""" That clause is for the case without angle brackets. Then repr() must be exactly "socket.AF_INET", full stop. I.e. it will lose the integer value display. socket.AF_UNIX If the repr were "socket.AF_UNIX", then that would indeed be a string that would yield an object with the same value. The current repr isn't wrong by this definition, but nor is the proposed change. Is it defined at module level? I couldn't care less; all that matters is that it is *accessible* at module level. Well, I do care a lot. For diagnostics, this is a critical distinction. An object is defined in one, fixed, place (even if you overwrite module contents, it retains lexical scope) and can be made, dynamically, accessible in any number of completely unrelated places. A diagnostic is always done by the same algorithm: 1) Identify the exact place in code where the problem manifests itself 2) Examine the state of the program at that moment to find out which if the values are wrong 3) Track the wrong value back to its origin Seeing an accurate repr() is required for step 2) -- to immediately detect if it's wrong or not. If a repr() points to a reference rather than definition, I don't really know anything about the object that I'm looking at: that reference could as well be wrong, or could have been wrong at any moment in the past. I.e. such a repr() has negative informativity. Finding the definition, as opposed to merely a reference, is required for step 3). To identify which code could have adversely affected the object's value, I must find both its implementation (for potential internal offenders) and references to it and objects of this type in general (for potential external offenders). I don't have to say "socket.AddressFamily.AF_UNIX". ChrisA ___ 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/4Q7SVP6ZXR4SAPMDWYGPH7OWX5YXI44M/ Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan ___ 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/QXK7NEYVSRVLXGV6TWC42K7BPEZOLVCZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
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 every PHP user who comes to us from the dark side. Over there "trim" means what our "strip" means. I've got (differing) opinions about the others, but "trim" is a big one to me. 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/FCMSA66UPTJV7YDINYJFQCVPO6B67JZN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
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 "always remove the longest" is the "obvious" sensible choice,
I am fairly certain there will be other opinions :-) So deferring the
decision for now until we have more experience with the single-affix
form seems perfectly reasonable.
I'd like to preface this with "I'm fine to implement multiple affixes
later, if at all". That said:
To me "first match" is the _only_ sensible choice. "longest match" can
always be implemented with a "first match" function by sorting on length
if desired.
Also, "longest first" requires the implementation to do a prescan of the
supplied affixes whereas "first match" lets the implementation just
iterate over the choices as supplied.
I'm beginning to think I must again threaten my partner's anecdote about
Netscape Proxy's rule system, which prioritised rules by the lexical
length of their regexp, not their config file order of appearance. That
way lies (and, indeeed, lay) madness.
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/RRWO6NIRC23F3FWEYJYFDUSVL6PTIQ5C/
Code of Conduct: http://python.org/psf/codeofconduct/
