[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
25.03.20 21:54, Ethan Furman пише: 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? Thank you for raising this question Ethan. I have several other ideas, maybe not directly related to this. 1. Representation of the value. For IntFlags, values are bit masks, so it is more convenient to represent them as hexidecimals, octals or binaries than decimals. It may be useful for regular enumerations too. It would be nice to have a ways to customize the default representation of the value. For example by setting __value_repr__ = hex. 2. In many case it is more convenient to have a repr in the form Color.RED or even just RED instead of . First, it is shorter and contains all information that you need in the context. It is importatnt if it is a part of the larger object. Second, the result is evaluable, so you can just copy the output and paste it in the Python code, without removing noise. It is especially handy in tests, when you get a collection of enums, or dataclasses with enum fields, or more complex data structure and compare it with expected result. You just write a test, add print() for the actual value, run test, and copy the output as the expected value. So in these cases I want the repr be what the str is now. I do not say that it should be the behavior by default, but maybe change the repr for some stdlib enums for which the literal value is not important? ___ 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/T5KEDKNH473J4IUQ2UYPYDPV5XYT6LTL/ 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 Sat, Mar 28, 2020 at 01:20:11PM +0200, Serhiy Storchaka wrote: > 2. In many case it is more convenient to have a repr in the form > Color.RED or even just RED instead of . +1 -- 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/NSTNFJFOVCJARGDKG2ZX3RXSWCVVYG33/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
What do you think of adding a Version History section which lists most important changes since your proposed the first version of the PEP? I recall: * Version 3: don't accept tuple * Version 2: Rename cutprefix/cutsuffix to removeprefix/removesuffix, accept tuple * Version 1: initial version For example, for my PEP 587, I wrote detailed changes, but I don't think that you should go into the details ;-) https://www.python.org/dev/peps/pep-0587/#version-history Victor Le sam. 28 mars 2020 à 06:11, Dennis Sweeney a écrit : > > PEP 616 -- String methods to remove prefixes and suffixes > is available here: https://www.python.org/dev/peps/pep-0616/ > > Changes: > - Only accept single affixes, not tuples > - Make the specification more concise > - Make fewer stylistic prescriptions for usage > - Fix typos > > A reference implementation GitHub PR is up to date here: > https://github.com/python/cpython/pull/18939 > > Are there any more comments for it before submission? > ___ > 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/UJE3WCQXSZI76IW54D2SKKL6OFQ2VFMA/ > 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/4UKSBWZE2RIP4VPADVHKQRLS7E7OBMTS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On 3/26/2020 9:10 PM, Ethan Furman wrote: 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: 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 That does seem like the better solution, including the comment. 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/43GEOBNJYN22QLYMG2PGN3KDOSQQHR6E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
Sure -- I can add in a short list of those major changes. 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/TKCHV76P3CYYSZDSB3TH3I4UTFCUNKU5/ Code of Conduct: http://python.org/psf/codeofconduct/
