[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
First off, thank you for being so patient -- trying to champion a PEP can be exhausting. On 03/26/2020 05:22 PM, Dennis Sweeney wrote: Ethan Furman wrote: 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? I should clarify: by "when working with subclasses" I meant "when str.removeprefix() is called on a subclass that does not override removeprefix", and in that case it should return a base str. Okay. 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. I was only saying that the new methods should match 20 other methods in the str API by always returning a base str Okay. If ``return self[:]`` in the PEP is too closely linked to "must call user-supplied ``__getitem__`` methods" for it not to be true, and so you're suggesting ``return self`` is more faithful, I can understand. So now if I understand the dilemma up to this point we have: Benefits of writing ``return self`` in the PEP: a - Makes it clear that the optimization of not copying is allowed b - Makes it clear that ``self.__class__.__getitem__`` isn't used Benefits of writing ``return self[:]`` in the PEP: c - Makes it clear that returning self is an implementation detail d - For subclasses not overriding ``__getitem__`` (the majority of cases), makes it clear that this method will return a base str like the other str methods. Did I miss anything? The only thing you missed is that, for me at least, points A, C, and D are not at all clear from the example code. If I wanted to be explicit about the return type being `str` I would write: return str(self) # subclasses are coerced to str -- ~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/XWVJNFN5O3BZQ6YQQEWHMOGRWST3MY6M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
> 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? I should clarify: by "when working with subclasses" I meant "when str.removeprefix() is called on a subclass that does not override removeprefix", and in that case it should return a base str. I was not taking a stance on how the methods should be overridden, and I'm not sure there are many use cases where it should be. > 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. I was only saying that the new methods should match 20 other methods in the str API by always returning a base str (the exceptions being format, format_map, and (r)partition for some reason). I did not mean to suggest that they should ever call user-supplied ``__getitem__`` code -- I don't think they need to. I haven't found anyone trying to use ``str`` as a mixin class/ABC, and it seems that this would be very difficult to do given that none of its methods currently rely on ``self.__class__.__getitem__``. If ``return self[:]`` in the PEP is too closely linked to "must call user-supplied ``__getitem__`` methods" for it not to be true, and so you're suggesting ``return self`` is more faithful, I can understand. So now if I understand the dilemma up to this point we have: Benefits of writing ``return self`` in the PEP: - Makes it clear that the optimization of not copying is allowed - Makes it clear that ``self.__class__.__getitem__`` isn't used Benefits of writing ``return self[:]`` in the PEP: - Makes it clear that returning self is an implementation detail - For subclasses not overriding ``__getitem__`` (the majority of cases), makes it clear that this method will return a base str like the other str methods. Did I miss anything? All the best, Dennis ___ 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/EQVVXMC7XQJSQIHEB7ND2OLWBQLC7QYM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: sys.trace without alert or remove trace by C
Hi, I understand that you are looking for PyEval_SetTrace(NULL, NULL) to unregister a trace function set previously. Maybe the documentation should be enhanced to explain that. Do you want to propose a PR to enhance the doc? https://docs.python.org/dev/c-api/init.html?highlight=pyeval_settrace#c.PyEval_SetTrace Victor Le jeu. 26 mars 2020 à 22:47, Leandro Müller a écrit : > > Hello. > I need to remove the trace on thread, but I tried to run sys.settrace(None) > and return alert on console. > I didn't find any soluction to remove by C, example PyEval_SetTrace(Py_None, > obj), but it not works. > > Are there any soluction to remove without alert or by C? > C is better for me. > > Thanks. > > Att. > > Leandro Müller > > ___ > 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/HJNC3UOXDBOYF6XJ3MFJX647WKCICK7P/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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/ZXF3YXLZHG5JTLYOYDIPDLMDJ2Y3G4VM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] sys.trace without alert or remove trace by C
Hello. I need to remove the trace on thread, but I tried to run sys.settrace(None) and return alert on console. I didn't find any soluction to remove by C, example PyEval_SetTrace(Py_None, obj), but it not works. Are there any soluction to remove without alert or by C? C is better for me. Thanks. Att. Leandro Müller ___ 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/HJNC3UOXDBOYF6XJ3MFJX647WKCICK7P/ 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 06:53 PM, Ivan Pozdeev via Python-Dev wrote: 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. Before Enum, the repr for socket.AF_UNIX was: 1 Not very useful for debugging. 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. Whether it's or it has light-years more information than it used to (okay, maybe only light-minutes ;) ) Finding the definition, as opposed to merely a reference, is required for step 3). Before Enum, if you had tried to find AF_UNIX and did a full Lib/*.py search you would have found some comments and a couple lines of code -- never a definition. And that's assuming you made the leap from 1 to AF_UNIX. You should add searching for from ... import * to your debugging list, because then you'll find: from _socket import * 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). Finding the implementation might be a bit trickier with `socket.AF_UNIX', however: $ grep AddressFamily.AF_UNIX *.py ...(crickets)... $ grep socket.AF_UNIX *.py smtplib.py:self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) socketserver.py:address_family = socket.AF_UNIX socketserver.py:address_family = socket.AF_UNIX webbrowser.py:s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) Considering that stdlib Enums are almost all globally unique, and Enums created with _convert *are* globally unique, I think seeing the module instead of the class name is more helpful. Speaking of which, adding help() to your debugging list would also be, um, helpful: --> help(socket.AF_UNIX) Help on AddressFamily in module socket object: class AddressFamily(enum.IntEnum) | AddressFamily(value, names=None, *, module=None, qualname=None, type=None, start=1) | | An enumeration. | | ... As a reminder, the change under discussion only affects enums created from globally unique constants using the Enum._convert helper utility. -- ~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/C55F5N4JHPCRLXJRDN5CGXYRZEARI2JT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
Am 26.03.20 um 06:28 schrieb Cameron Simpson: 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. As a full stack developer with terrible memory, I agree. JavaScript also uses trim() like Python's strip(), and this would quickly get confusing. - Sebastian ___ 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/RNVBORUJDVWBQPELPSPYMNHBVLCZ4B5B/ 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 11:59, Serhiy Storchaka wrote: 26.03.20 01:35, Ivan Pozdeev via Python-Dev пише: 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. AF_UNIX is and always was available from the socket module. It is not incidental. AddressFamily is an implementation detail, it is just a way to add fanny repr and other properties to this constant. In any case the information about AddressFamily and its members will be kept in the help output. See my earlier replies to Chris Angelico why showing the implementation matters for repr() and how this misrepresentation breaks the documented repr() standard and debugging. ___ 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/NNBYZBV7YAXKSSNDZIHK54F3XGBSFZMV/ Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan -- 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/GDHGBSQAPMWPNDJY4R6DH2IGN3LXPNHF/ 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 01:35, Ivan Pozdeev via Python-Dev пише: 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. AF_UNIX is and always was available from the socket module. It is not incidental. AddressFamily is an implementation detail, it is just a way to add fanny repr and other properties to this constant. In any case the information about AddressFamily and its members will be kept in the help output. ___ 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/NNBYZBV7YAXKSSNDZIHK54F3XGBSFZMV/ 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 01:04, Cameron Simpson пише: 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). module_name.RED can have only one value. It cannot be 4 and 7 at the same time. If you have an example of conflict, please report it on the bug tracker. 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. No, it is not a socket-module-specific change. No, it is not a general change affecting all enum. It is only about Enum._convert_(). ___ 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/55TGCHSWUR6IPLKRPB4FGDH5ZZZDN7DD/ 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__``. If we write class MyStr(str): def __getitem__(self, key): raise ZeroDivisionError() then all of the assertions from before still pass, so in fact *none* of the methods rely on ``__getitem__``. As of now ``str`` does not behave as an ABC at all. But it's an interesting proposal to essentially make it an ABC. Although it makes me curious what all of the different reasons people actually have for subclassing ``str``. All of the examples I found in the stdlib were either (1) contrived test cases (2) strings (e.g. grammar tokens) with some extra attributes along for the ride, or (3) string-based enums. None of types (2) or (3) ever overrode ``__getitem__``, so it doesn't feel like that common of a use case. > 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__. Making sure I understand: would you prefer the PEP to say ``return self`` rather than ``return self[:]``? I never had the intention of ``self[:]`` meaning "this must have exactly the behavior of ``self.__getitem__(slice(None, None))`` regardless of type", but I can understand if that's how you're saying it could be interpreted. ___ 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/A64Q6BXTXJYNTA4NX2GHBMOG6FPZUCZP/ Code of Conduct: http://python.org/psf/codeofconduct/
