[Python-Dev] PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors
PEP 663 is presented below for your viewing pleasure. Comments, questions, and concerns are welcome. PEP: 663 Title: Improving and Standardizing Enum str(), repr(), and format() behaviors Version: $Revision$ Last-Modified: $Date$ Author: Ethan Furman Discussions-To: python-dev@python.org Status: Draft Type: Informational Content-Type: text/x-rst Created: 23-Feb-2013 Python-Version: 3.11 Post-History: 20-Jul-2021 10-Sep-2021 Resolution: Abstract Now that we have a few years experience with Enum usage it is time to update the ``repr()``, ``str()``, and ``format()`` of the various enumerations by their intended purpose. Motivation == The addition of ``StrEnum`` with its requirement to have its ``str()`` be its ``value`` is inconsistent with other provided Enum's ``str``. Having the ``str()`` of ``IntEnum`` and ``IntFlag`` not be the value causes bugs and extra work when replacing existing constants. Having the ``str()`` and ``format()`` of an enum member be different can be confusing. The iteration of ``Flag`` members, which directly affects their ``repr()``, is inelegant at best, and buggy at worst. Rationale = Enums are becoming more common in the standard library; being able to recognize enum members by their ``repr()``, and having that ``repr()`` be easy to parse, is useful and can save time and effort in understanding and debugging code. However, the enums with mixed-in data types (``IntEnum``, ``IntFlag``, and the new ``StrEnum``) need to be more backwards compatible with the constants they are replacing -- specifically, ``str(replacement_enum_member) == str(original_constant)`` should be true (and the same for ``format()``). IntEnum, IntFlag, and StrEnum should be as close to a drop-in replacement of existing integer and string constants as is possible. Towards that goal, the str() output of each should be its inherent value; e.g. if ``Color`` is an ``IntEnum``:: >>> Color.RED >>> str(Color.RED) '1' >>> format(Color.RED) '1' Note that format() already produces the correct output in 3.10, only str() needs updating. As much as possible, the ``str()`, ``repr()``, and ``format()`` of enum members should be standardized across the stardard library. The repr() of Flag currently includes aliases, which it should not; fixing that will, of course, already change its ``repr()`` in certain cases. Specification = There a three broad categories of enum usage: - standard: Enum or Flag a new enum class is created, and the members are used as ``class.member_name`` - drop-in replacement: IntEnum, IntFlag, StrEnum a new enum class is created which also subclasses ``int`` or ``str`` and uses ``int.__str__`` or ``str.__str__``; the ``repr`` can be changed by using the ``global_enum`` decorator - user-mixed enums and flags the user creates their own integer-, float-, str-, whatever-enums instead of using enum.IntEnum, etc. Some sample enums:: # module: tools.py class Hue(Enum): # or IntEnum LIGHT = -1 NORMAL = 0 DARK = +1 class Color(Flag): # or IntFlag RED = 1 GREEN = 2 BLUE = 4 class Grey(int, Enum): # or (int, Flag) BLACK = 0 WHITE = 1 Using the above enumerations, the following table shows the old and new behavior, while the last shows the final result: +-+--+-++---+---++---+ | type | enum repr() | enum str() | enum format() | flag repr() | flag str() | flag format() | +-+--+-++---+---++---+ | standard| 3.10 | || | | Color.RED|GREEN| Color.RED|GREEN | | +--+-++---+---++---+ | | new | || | | Color.RED|Color.GREEN | Color.RED|Color.GREEN | +-+--+-++---+---++---+ +-+--+-++---+---++---+ | user mixed | 3.10 | || 1 || | 1 | | +--+-++---+---++---+ | | new | ||
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2021-09-03 - 2021-09-10) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7376 (-33) closed 49524 (+105) total 56900 (+72) Open issues with patches: 2929 Issues opened (53) == #36550: Avoid creating AttributeError exceptions in the debugger https://bugs.python.org/issue36550 reopened by iritkatriel #45083: Need to use the exception class qualname when rendering except https://bugs.python.org/issue45083 reopened by vstinner #45089: [sqlite3] the trace callback does not raise exceptions on erro https://bugs.python.org/issue45089 reopened by petr.viktorin #45096: Update Tools/freeze to make use of Tools/scripts/freeze_module https://bugs.python.org/issue45096 opened by eric.snow #45098: asyncio.CancelledError should contain more information on canc https://bugs.python.org/issue45098 opened by dreamsorcerer #45099: asyncio.Task's documentation says that loop arg is removed whe https://bugs.python.org/issue45099 opened by jack1142 #45100: Improve help() by making typing.overload() information accessi https://bugs.python.org/issue45100 opened by rhettinger #45101: Small inconsistency in usage message between the python and sh https://bugs.python.org/issue45101 opened by kiendang #45103: IDLE: make configdialog font page survive font failures https://bugs.python.org/issue45103 opened by terry.reedy #45105: Incorrect handling of unicode character \U00010900 https://bugs.python.org/issue45105 opened by maxbachmann #45107: Improve LOAD_METHOD specialization https://bugs.python.org/issue45107 opened by kj #45108: frame.f_lasti points at DICT_MERGE instead of CALL_FUNCTION_EX https://bugs.python.org/issue45108 opened by alexmojaki #45109: pipes seems designed for bytes but is str-only https://bugs.python.org/issue45109 opened by rtollert #45110: argparse repeats itself when formatting help metavars https://bugs.python.org/issue45110 opened by forest #45112: Python exception object is different after pickle.dumps and pi https://bugs.python.org/issue45112 opened by yonghengzero #45113: [subinterpreters][C API] Add a new function to create PyStruct https://bugs.python.org/issue45113 opened by shihai1991 #45114: bad example for os.stat https://bugs.python.org/issue45114 opened by harridu #45116: Performance regression 3.10b1 and later on Windows https://bugs.python.org/issue45116 opened by neonene #45119: test_signal.test_itimer_virtual() failed on AMD64 Fedora Rawhi https://bugs.python.org/issue45119 opened by vstinner #45120: Windows cp encodings "UNDEFINED" entries update https://bugs.python.org/issue45120 opened by rafaelblsilva #45121: Calling super().__init__ in subclasses of typing.Protocol rais https://bugs.python.org/issue45121 opened by hauntsaninja #45122: Remove PyCode_New and PyCode_NewWithPosOnlyArgs https://bugs.python.org/issue45122 opened by gvanrossum #45125: Improve tests and docs of how `pickle` works with `SharedMemor https://bugs.python.org/issue45125 opened by sobolevn #45126: [sqlite3] cleanup and harden Connection and Cursor __init__ https://bugs.python.org/issue45126 opened by erlendaasland #45127: Code objects can contain unmarshallable objects https://bugs.python.org/issue45127 opened by petr.viktorin #45128: test_multiprocessing fails sporadically on the release artifac https://bugs.python.org/issue45128 opened by pablogsal #45130: shlex.join() does not accept pathlib.Path objects https://bugs.python.org/issue45130 opened by nyuszika7h #45131: `venv` ??? `ensurepip` may read local `setup.cfg` and fail mys https://bugs.python.org/issue45131 opened by nutjob4life #45134: Protocol dealloc not called if Server is closed https://bugs.python.org/issue45134 opened by MarkReedZ #45135: dataclasses.asdict() incorrectly calls __deepcopy__() on value https://bugs.python.org/issue45135 opened by tfish2 #45138: [sqlite3] expand bound values in traced statements when possib https://bugs.python.org/issue45138 opened by erlendaasland #45139: Docs: add source directive for minor translation simplificatio https://bugs.python.org/issue45139 opened by Jean_Abou_Samra #45140: strict_timestamps for PyZipFile https://bugs.python.org/issue45140 opened by sakcheen #45141: mailcap.getcaps() from given file(s) https://bugs.python.org/issue45141 opened by pacien #45143: ipaddress multicast v6 RFC documentation correction https://bugs.python.org/issue45143 opened by hanugit #45145: Case of headers in urllib.request.Request https://bugs.python.org/issue45145 opened by emphoeller #45146: Add a possibility for asyncio.Condition to determine the count https://bugs.python.org/issue45146 opened by mykola-mokhnach #45149: Cover directory and zipfile execution in __main__ module docs https://bugs.python.org/issue45149 opened by ncoghlan #45150: Add a file_digest() function
[Python-Dev] Re: PEP 467 feedback from the Steering Council
Ethan Furman writes: > `int.from_bytes` methods, and is an appropriate name for the target > domain (where bytes are treated as characters). The relevant domains treat bytes as bytes. It's frequently useful (and dare I say "Pythonic"?) for *programmers* to take advantage of the mnemonic of treating 95 of the bytes as the ASCII encoding of characters. It follows that it's good sense for protocol designers to restrict themselves to that alphabet for their magic numbers. But standards themselves make clear that these protocols handle *octets* (historically, "byte" was too ambiguous for network protocols!), not characters or ints that happen to fit into 8 bits. The "control characters" aren't really characters even when they're syntactically significant, some of them are not significant unless combined in a particular order (CRLF), and of course the bytes 0x80-0xFF are never treated as characters. As far as I can see, the "programmers' mnemonic" interpretation gets us everything we really want in this area. We should avoid the idea that "bytes are treated as characters" because they aren't, and because that way lies the madness that incited the upheaval of Python 3 in the first place. ___ 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/DCSW7WLND6SZ6CGV4BZXP6QEOS2MZ7FA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Spam from Daniel Scott
Hi, For 1 or 2 years, I'm getting spam messages from "Daniel Scott". It started with empty replies to multiple Python mailing lists. Mailing list owners: please block his email address. I never ever saw any useless message from this name (sorry if a real Daniel Scott plans to contribute to Python and will be blocked by mistake). Today, I got an email to my @python.org email account. And "Daniel Scott" also commented a closed issue: "I left you to see conduct on phython assigned." https://github.com/python/cpython/pull/23734#issuecomment-916568696 SPAM SPAM SPAM SPAM SPAM SPAM SPAM What can we do to reduce the spam? For GitHub, I reported the comment as a spam: (o) I want to report abusive content or behavior => I want to report SPAM, a user that is disrupting me or my organization's experience on GitHub, or a user who is using my personal information without my permission ==> A user's profile or repository is SPAM. In the comment, I added a link to this email :-) "Daniel": Please stop what you are doing and try to find a better way to use your free time. Thanks! Victor -- 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/MOOL5KWUKG2ZODH2MFTQOFNULMN5M227/ Code of Conduct: http://python.org/psf/codeofconduct/