[Python-Dev] Re: PEP 448 review
On 3/29/23 13:23, Brett Cannon wrote: Wow, we are now getting Canadian-specific spam! Since the volume on this mailing list is so low, should we change everyone to be moderated to start and then remove that after they have posted appropriately? Or did this get through by accident? Accident. I set the user to always discard, and then clicked on the green button instead of the yellow one. Green to me says "Do what I asked for." but green to MM3 says "Do what I asked for AND accept the message." -- ~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/SY26KTV3YOZUS5ZGFNBVFUAGV2GV5MLD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 448 review
My apologies for the accidentally accepted spam. If you reply to that original message, please remove the link before sending. Thanks. ;-) -- ~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/ABUAQHFRBCPENJ47ZZ22XBN7JEEQW6TN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: computersmarketing
Gah. Already dealt with. ___ 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/FA7LJYBW3RIBU44JGSHWFDHDT5POXHSE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Switching to Discourse
On 12/9/22 09:20, Barry Warsaw wrote: > The whole shift away from email leaves me calmer and better engaged. There are definitely advantages to the different methods of staying engaged, and which is the best fit definitely depends on the individual. It seems to me the best possible outcome of Discourse vs email is somebody / some company donating the time and/or funding to improve Discourse's and Mailman's abilities to interoperate with each other. (My thanks to the person whose name I cannot remember for improving Discourse's email threading.) -- ~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/BYWROPOOO5454G6PSY3JCHFKFIAIMWPM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Switching to Discourse
On 7/20/22 17:35, Cameron Simpson wrote: > On 18Jul2022 16:53, Joannah Nanjekye wrote: >> My original stand on preferring email stands though due to stable >> standards. > > Several of us use the email mode in Discourse. It works quite well. For > me, both python-dev and the PDO posts land in my "python" local folder. It works, but I wouldn't say "quite well" -- any thread from discourse is one long linear series of replies, and reading them in chronological order means jumping around and trying to figure what is a reply to what. -- ~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/RYSDA5KULGF64CHR6YLAWYZ7VR7W44PA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Switching to Discourse
On 7/15/22 08:37, Petr Viktorin wrote: > And that's exactly why I consume Discourse in mailing list mode, with client-side > filtering in Thunderbird. How do you handle threading? I follow each (sub)thread through to it's end, as it keeps a logical flow, but Discourse has everything linear which means that as I read it the conversation keeps jumping around, making it hard to follow. -- ~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/7ZQABZVBHVSD7C6LZWE7SAEMTCHKAUPK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: About PEPs being discussed on Discourse
On 4/7/22 07:31, Petr Viktorin wrote: On 07. 04. 22 15:59, Victor Stinner wrote: Would it be possible to announce new PEPs on python-dev please? Currently, all PEPs should be announced on python-dev, but not necessarily right after they're published. They should be announced before submitting them to SC, though. By the time a PEP is being submitted, the opportunity to contribute has passed. -- ~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/2SVUWOI2OS7RGWOB7BHZBSTQSVZUQBLG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Descriptions in unittest and avoiding confusion
On 4/4/22 10:52, Coyot Linden (Glenn Glazer) wrote: > On 4/4/22 Guido wondered: >> How did we get from a specific issue with docstrings and the unittest package's test >> reporting to multi-line comments? > > Apologies, as I said earlier, I meant to write multiline /string/, not multiline /comment/ > and it wasn't my intention to derail the thread but rather provide a different use case for > multiline strings which seems, TIL, to be the accepted usage. Guido's point is that your concern is completely unrelated to the unittest docstring display issue, and should have been a new thread. But, hey, we all make mistakes sometimes. :-) -- ~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/LCQY4IHC4HOANTQOMG2POEJU2KKMBOCS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: (no subject)
[woops] ___ 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/NAT7FGQUCSCB2I265P7IR5BATLKHL5FT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] walrus operator and expression
In the following bit of code: while s := input.read(MAXBINSIZE): while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)): s += ns line = binascii.b2a_base64(s) output.write(line) I'm getting this error on the second line: cannot use assignment expressions with expression Can somebody explain why that isn't working? Many thanks. -- ~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/3NONJDUTXANBTINCOZITLHOAUDMJ3H66/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]
[apologies for the late post, just found this in my drafts folder] On 2/7/22 12:49 AM, Stéfane Fermigier wrote: 3. Overall, I think the days where "battery included" was a positive argument are over I strongly disagree. Being able to download something and immediately get something to work and see results is hugely rewarding; on the other hand, having to research, find, compare & contrast available third-party modules (especially for new-comers) can be extremely discouraging. -- ~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/N2F3AC6BFFQ63L3EFJVCQPBBV4MDBNSK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: An unambiguous way of initializing an empty dictionary and set
On 3/13/22 14:49, joao.p.f.batista...@gmail.com wrote:
> Currently:
> l = [] # new empty list
> t = () # new empty tuple
> s = set() # new empty set (no clean and consistent way of initializing regarding the
others) <<<
> d = {} # new empty dictionary
>
> Possible solution:
> s = {} # new empty set
> d = {:} # new empty dictionary (the ":" is a reference to key-value pairs)
>
> Current workaround at least for consistency:
> l = list() # new empty list
> t = tuple() # new empty tuple
> s = set() # new empty set
> d = dict() # new empty dictionary
>
> However, it doesn't feel right to not be able to initialize an empty set as
cleanly and
> consistently as lists, tuples and dictionaries in both forms.
This is a topic better fit to python-ideas.
--
~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/AHUHYKKSVXSAIVYVAMNZDLFJQI4BEJU5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PSA: Linux vulnerability
https://arstechnica.com/information-technology/2022/03/linux-has-been-bitten-by-its-most-high-severity-vulnerability-in-years/ -- ~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/FUJJ2MYILKOT2OFKBY44BZU7VMLAPCPE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype
On 2/10/22 1:45 PM, Brett Cannon wrote: > Protocols would let folks rely on a common Path object API w/o having to require the object > come from pathlib itself or explicitly subclass something (which I admit would be rare, but > there's no reason to artificially constrain this either). Now maybe this is too broad of an > API for people to care, but since protocols are also ABCs it doesn't inherently make things > worse, either. So I would say subclassing Protocol makes sense while still using > abc.abstractmethod for methods people must implement. Brett, when you say Protocol are you referring to static typing? In your earlier email I thought you were referring to building blocks such as _fs_path, or the __iter__ and __next__ protocols. -- ~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/HG6IF2YXGKXLYNZ7NNMZHU3UEQSFEHJ4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python
On 2/9/22 8:40 AM, Pablo Galindo Salgado wrote: > Petr Viktorin wrote: >> Should there be a getter/setter for co_positions? > > We consider the representation of co_postions private, so we don't want (for now) to ad > getters/setters. Isn't the whole point of getters/setters is to allow public access to information, allowing the internal representation of that information to change? However the exception information is store by CPython, it's going to be needed by other frameworks. -- ~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/OX4Q4MROMDNO5MVU35MJ2ARIH4RUB5KZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype
On 2/9/22 6:59 AM, Barney Gale wrote: > Over the last couple of years I've been tidying up the pathlib internals, with a view > towards adding an AbstractPath class to the hierarchy. Users would be able to subclass > AbstractPath to implement other kinds of filesystems: s3, google cloud storage, pandas, > ftp, git, zip and tar files, etc. By implementing some abstract methods (stat(), > iterdir(), open(), etc) they'd benefit from a number of derived methods (is_dir(), > glob(), read_text(), etc). Seems like a reasonable idea. > I've now submitted a PR that adds an initial underscore-prefixed implementation of this class: Why the iniitial underscore? What could change between now and the future? -- ~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/4KPJJEYPOYYDGS2FOL7ZE46XKX2USEZI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: It's now time to deprecate the stdlib urllib module
On 2/6/22 6:08 AM, Victor Stinner wrote: > I propose to deprecate the urllib module in Python 3.11. It would emit > a DeprecationWarning which warn users, so users should consider better > alternatives like urllib3 or httpx: well known modules, better > maintained, more secure, support HTTP/2 (httpx), etc. Besides the needs of pip, round-up, etc., I think we should keep whatever parts of urllib, cgi, cgitb, http, etc., are necessary for basic serving/consuming of web pages for the same reason we ended up keeping the wave module -- it's fun and engaging for a younger audience. Having one computer get information from another is pretty cool. If we need to do some trimming and rearranging of the above modules, that's fine, but I think losing all the functionality would be a mistake. -- ~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/TGENXEKPFCIZUQD63ROCIK2WGAN3F7XL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python
On 2/4/22 6:23 AM, Stefan Behnel wrote: > One recent example is the new error locations in tracebacks, where PEP 657 explicitly lists > the new "co_positions" field in code objects as an implementation detail of CPython. If we > want to implement this in Cython, then there is no other way than to copy these implementation > details pretty verbatimly from CPython and to depend on them. > > https://www.python.org/dev/peps/pep-0657/ > > In this specific case, we're lucky that this can be considered an entirely optional feature that we can separately > disable when users request "public API" mode (let's call it that). Not sure if that's what users want, though. Speaking as a user, I would want Cython to be (in order of preference): - reliable - fast - all the cool Python features and Python to: - make public APIs available for Python features -- ~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/LER6WQX565PNDJYWSZI2KCSXDN7MM624/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Increase of Spammy PRs and PR reviews
On 1/31/22 8:47 AM, Lrupert via Python-Dev wrote: > This gives a bad impression to others about their intentions (constant contribution of trivial > / low quality stuff with little-to-no-gain to achieve a higher number of commits, since it is > a visible metric). Two of us have already commented about the usefulness of those PRs and the fact that they have fixed previously unknown bugs -- those are not trivial, and certainly not low quality. If you have a real concern, show us some examples of these useless PRs, otherwise let it be. -- ~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/EM25XB5XCJP4AG46GUR3ZKZJFCMQOUFQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Increase of Spammy PRs and PR reviews
On 1/29/22 3:14 AM, Lrupert via Python-Dev wrote: > As someone who is watching the python/cpython repository, I'm very used to see lots of traffic. But > lately there have been a surge of spammy PRs which are about the same, generally very trivial subject > but individually fixing each occurrence one by one: > - Add coverage to X (tens of them, as separate PRs) > - Make `test_xxx` executable with direct invocation (tens of them, as separate PRs) > - Lint source with flake8, fix linting errors (stylistic changes) I am aware of the coverage PRs, and I think they are quite useful -- a couple bugs were fixed in one of my modules thanks to that author's efforts to make sure all branches were tested. Likewise, the executable test PRs are useful -- I haven't followed them closely, but at the beginning a few of us asked the author to submit one PR for a handful of related fixes, which makes it easier for reviewers to assess the changes. So those two types are not spam. I am unaware of the stylistic changes -- could you list a few? > And lots of non-committer PR reviews that only approve. I have seen this. Quite irritating. > In the past there were one or two people who would submit typo fixes, but most of them weren't making it continuously. > The situation right now feels much worse than those. As I said earlier, the coverage and executable tests are legitimate, and I welcome them -- they are helping increase the quality of Python's code. -- ~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/TCRMIQ6ZVVDOO3MIVHT5WWUWDEY3A3J3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?
On 1/19/22 1:10 PM, Barry Scott wrote: > On 18 Jan 2022, at 19:59, Pablo Galindo Salgado wrote: >> We considered using colours and other markers such as bold text, but that opens a considerable can of worms with >> detecting in all systems and configurations if that can be done. I have been told that some of these situations are >> quite tricky and is not as easy as checking for tty support. >> > > In the apps I work on as open source and paid work tracebacks are put into log files so that > we can fix the rare bugs. It would not be nice if the traceback module API started providing > text with embedded escape sequences without a way to turn then off in the API. An environment variable would solve this, yes? The default would be using the underlining carets, but an env var could switch that to using color instead. -- ~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/553Z6HJNAJ2N6KTRNTOYM54PD3NRU6FJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?
On 1/18/22 11:59 AM, Pablo Galindo Salgado wrote: > We considered using colours and other markers such as bold text, but that opens a considerable can of worms with > detecting in all systems and configurations if that can be done. I have been told that some of these situations are > quite tricky and is not as easy as checking for tty support. Maybe use an environment variable? -- ~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/TRI25YRCTJSDQKERZM2DHCWOMGXHQA3M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?
On 1/18/22 10:43 AM, Mats Wichmann wrote: > A thought - how about omitting the underline line if the > to-be-underlined part would be the whole line? I would also like that change -- when the underlining is a portion of the whole it's quite useful, but when it's the whole line it's a lot of extra noise. In fact, if I can be permitted to dream for a moment, what would be really nice is using highlighting or bolding or some such and skipping the extra underline lines (where "underlining" means "extra line with pointy hats"). ~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/JYC5D3L6QW7V3ZOWMTBLYIGUQ6UOMS2U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
On 1/8/22 5:46 PM, Steven D'Aprano wrote: > [...] if you hate type annotations because they are unreadable, then you > hate Python because Python is unreadable. Not so. A simple list comprehension is (usually) quite readable, while a triply-nested list comprehension all on one line is not. Similarly, adding type information in between a variable name and its value is not (for me, and apparently others too) readable. Most horribly of all, cluttering a function header with type information is most unreadable. I started using Python at 2.5. It was simple, clean, and elegant. If I had stumbled on it at 3.16 with samples, tutorials, and books all infused with typing clutter (which *looks* like boiler-plate even if it isn't) I wouldn't have given it a second glance. -- ~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/MHS5I56U2BMCGYUILXBZN3DS2PPIGVEK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: facing the issue for remove the value from list (when value is repeated)
Hello! The python-dev list is for developing the next version of Python. For help using Python, please send your question to python-l...@python.org Thanks, and good luck! -- ~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/UED6OIEVBCF2MW4CPIO7EXYS3OTNTQME/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should dataclasses add__set__ (and possibly __get __) descriptors ?
On 12/13/21 3:34 PM, Steven D'Aprano wrote: > I think this may be what you are looking for: [...] Beat me to it. :-) -- ~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/FVJXCOIKNZSFFUWHSNNDCDZS4AER75SI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should dataclasses add__set__ (and possibly __get __) descriptors ?
On 12/12/21 10:43 PM, Vioshim wrote: > Anyways, at the moment that I write this message in python3.10.1, It happens that when making a class with the dataclasses module, this class can't actually be used in Multiple inheritance for Enum purposes, this is mostly to avoid code repetition by having to write the methods over again. > > Here's an example > > from dataclasses import dataclass > from enum import Enum > > @dataclass > class Foo: > a: int = 0 > > class Entries(Foo, Enum): > ENTRY1 = Foo(1) > ENTRY2 = Foo(2) > ENTRY3 = Foo(3) > > > assert Entries.ENTRY1.a == 1 > > This raises AssertionError, due to the values not being defined at that point, What do you mean by this? Here is what I see: --> E = Entries.ENTRY1 --> E Entries(a=Foo(a=1)) --> E.value Foo(a=1) --> E.a Foo(a=1) Looks like both `value` and `a` are set. You're problem is that you said Entries is a Foo, and then you set Enum/Foo instances to also have Foo values. Here's what you need: class Entries(Foo, Enum): ENTRY1 = 1 ENTRY2 = 2 ENTRY3 = 3 Which gives us: --> e = Entries.ENTRY2 --> e Entries(a=2) >>> e.value 2 --> e.a 2 --> isinstance(e, Foo) True -- ~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/OZVCBTO4LSDV564FFBUPGRPU6U3PZZ6V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] multiple inheritance and `__str__`
I ran into an issue today with `str()` not behaving as I thought it should. Given the following test script, what should happen? -- 8< -- class Blah(object): def __str__(self): return 'blah' class Huh(int, Blah): pass class Hah(Blah, int): pass huh = Huh(7) hah = Hah(13) print(huh) print(hah) -- 8< -- I thought I would get: 7 blah and indeed, that is what I got for Pythons 2.7 - 3.7. However, starting with Python 3.8 I started getting: blah blah To say the least, I was surprised. Some searching turned up issue 36793: "Do not define unneeded __str__ equal to __repr__" . As can be seen, `__str__` is needed for inheritance to work properly. Thoughts on reverting that patch? -- ~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/GLHE6CJ3IEHPUTA36YWOF5FSDLYNIOCV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
On 11/26/21 1:13 AM, Paul Moore wrote: > On Fri, 26 Nov 2021 at 05:14, Guido van Rossum wrote: >> >> My memory is also hazy, but I'm quite sure that *in my mind* annotations were >> intended as a compromise between conflicting proposals for *typing*. We didn't >> have agreement on the syntax or semantics, but we did know we wanted to do >> something with types eventually. > > More hazy memories here, but I think the original proposal left open > the possibility of annotations not being types at all - for example, > being docstrings for the arguments, or option names for a "function > call to CLI" tool, etc. I think that some libraries took this approach > (in particular the "CLI builder" idea). I have one such tool. Fortunately for me, I strongly dislike having the annotations inside the function header as it quickly gets difficult for me to read, so I was already using decorator syntax for the annotations. When PEP 484 was accepted I just changed where the annotations were being stored from __annotations__ to my own dunder. -- ~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/VC6NSJ4MXJOTNBKO7OOBSV7JHQ5JBPLO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: AWS Course in Chennai
Sorry for the spam -- one of us must have clicked on the wrong button. :-/ -- ~Ethan~ Moderator ___ 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/W2S53M5PXUG3NJ7W472QPQX5WB4JH5OE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Adding pep-8-casing-compliant aliases for unittest and logging
Woops, wrong list -- please disregard. -- ~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/SU4UOT6GVE4VJUWITFDXUP5TPW2TFCUT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Adding pep-8-casing-compliant aliases for unittest and logging
On 11/11/21 11:53 AM, Matt del Valle wrote: > Okay, so from the replies so far it looks like this is very quickly going into the 'never gonna happen' > dumpster, so in the interests of salvaging *something* out of it: [...] > I just dislike having to settle for 'it's what we've got'. With these two modules in particular, a lot > of the arguments that have been made so far either don't apply or are not as strong (such as the > confusion of having builtins.list, builtins.List and typing.List). Additionally, these are significantly > more ancillary portions of the stdlib than the builtins, much less likely to cause as severe of a > disruption (I personally don't believe a backward-compatible change like this which only adds aliases > would be as disruptive as many people claim, but concede that that's subjective), and much less likely > to have the implementation change so drastically as to want to change out types for factory functions > or vice-versa. > > So perhaps we could narrow the scope of this down to just adding snake_case aliases to the logging and > unittest modules [...] +1 I would happily change all my unittest and logging usage to snake case if those aliases existed. -- ~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/EPUVFEBVIQCTL47IBR73UDGXV7DAC3U2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: containment and the empty container
On 11/9/21 9:02 AM, Guido van Rossum wrote: > On Mon, Nov 8, 2021 at 10:29 PM Ethan Furman wrote: >> The way I see it, the following should hold >> >> empty_flag = RegexFlag(0) >> any_case = RegexFlag.IGNORECASE >> any_case_on_any_line = RegexFlag.IGNORECASE | RegexFlag.MULTILINE >> >> any_case in empty_flag is False >> any_case_on_any_line in empty_flag is False >> >> empty_flag in any_case is False >> empty_flag in any_case_on_any_line is False >> > > The latter two defy all logic. Please don't. Your 'in' operator clearly means "is a subset of", and the empty set > emphatically is a subset of all sets (this is the most basic mainstream set theory you can think of). Thank you everyone for your feedback. As is probably evident, my degree is not is CS nor maths, so I greatly appreciate your thoughts. RegexFlags(0) in any_regex_flags_whatsoever will continue to be True. -- ~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/VTDPADRF7ZGY6OFNC3ZA5NLU7IQTICOZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: containment and the empty container
On 11/8/21 3:09 PM, Steven D'Aprano wrote: > On Mon, Nov 08, 2021 at 01:43:03PM -0800, Ethan Furman wrote: >> SomeFlag.nothing in SomeFlag.something <-- ??? > > I don't think that consistency with other containers is particularly > relevant here. More useful is consistency with other flag objects. You mean from other programming languages? > What's SomeFlag? I presume it is some sort of Enum, or bitset. Yes. > Presumably SomeFlag.nothing is equivalent to a bitset of all zeroes. Yes. > You might have: > > something = 0b11010 > > 0 in something # ??? > 1 in something # False > 2 in something # True > 4 in something # False > 8 in something # True > 16 in something # True > 32 in something # False > > So much is obvious. But what about `3 in something`? > > If that is interpreted as an *all* operation, you get: > > 3 in something --> all(i in something for i in (1, 2)) # False > > but if it is an *any* operation: > > 3 in something --> any(i in something for i in (1, 2)) # True It's an `all()` operation. > *If* that is how you interpret your containment tests, that implies a > natural interpretation for `nothing in something`. The vacuous truth of > all is True, and of any is False: > > 0 in something --> all(i in something for i in ()) # True > 0 in something --> any(i in something for i in ()) # False > > Vacuous truth is not the only possible interpretation. If you have some > other obvious and natural interpretation of `0 in something` then you > probably wouldn't be asking here, but if you did, you could follow that > interpretation. With a good reason to violate the vacuous truth rules, > it would only be a *little* surprising. To rephrase Wikipedia [1]: a vacuously true statement doesn't really say anything. I prefer my truths to actually say something. ;-) I don't know if there's a formal name, but in my mind, if you have something you don't have nothing. If you have a barrel with nothing in it (not even air, just a hard vacuum) then saying you have nothing in that barrel is a true statement; as soon as something is in that barrel, then saying you have nothing in the barrel is a false statement. All of that is academic without a solid (and possibly irritating ;) use-case, so let's look at a different portion of the standard library -- opening files with `os.open()`: Help on built-in function open in module posix: open(path, flags, mode=511, *, dir_fd=None) Open a file for low level IO. Returns a file descriptor (integer). A possible `flags` value (and presumably the default value) is `O_RDONLY` which is `0`. I can imagine an implementation similar to (using integers): if flags == 0: stuff if flags & O_TRUNC == O_TRUNC: stuff if flags & O_RDRW == O_RDRW: stuff # preliminary stuff done return do_open_file(...) If that were converted to use Flag, then the above would still work, but if written anew could become: flags = OpenFlag(flags)# in case older code passes in an integer # ignoring O_RDONLY for now # if O_TRUNC in flags: stuff if O_RDRW in flags: stuff Which is pretty straight-forward. Circling back to O_RDONLY -- in the above snippet we either: - need to remember that that particular flag has an actual value of 0 (and one of the big motivating factors behind Enum was not having to worry about the actual value) and use a different operator: if not flags: if flags == 0: # only works because OpenFlag is an IntFlag for backwards compatibility if flags.value == 0 # works for both Flag and IntFlag or - recognize that a nothing cannot be in a something: # flags is O_RDONLY if O_RDONLY in flags: # true pass # flags is O_RDRW if O_RDONLY in flags: # false pass # flags is O_RDRW | O_TRUNC if O_RDONLY in flags: # false pass -- ~Ethan~ [1] https://en.wikipedia.org/wiki/Vacuous_truth -- last line of first paragraph ___ 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/I5TNPPPZCUCGKRH34NAZIDL6EPUDVVKQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: containment and the empty container
Something to keep in mind as these discussions continue: Enums are already
unusual in several ways:
- the class itself is iterable
- the class itself supports containment checks of its enum members
- the enum members are created, and guaranteed singletons, during class creation
- the enum members are instannces of the class
- calling the class with a value, which in other classes/types would return a
new instance, instead
returns one of the existing enum members, or raises if such a member does not
exist
- and probably other things I'm forgetting at the moment
Flag is a subclass of Enum. Some of its peculiarities:
- bitwise operations are supported, and return a "new" instance of the combined
value
- the "new" instance is also a singleton (so `(F1 | F2) is (F1 | F2) is True`
- the "new" instance is an instance of the Flag class
- flags are iterable -- `list(F1) == [F1]; list(F1 | F2) == [F1, F2]`
- iterating over a Flag only returns the "pure" (aka single-bit) flags, even if
multi-flag instances
have been created (at least, they will in 3.11)
On 11/8/21 8:32 PM, Guido van Rossum wrote:
> On Mon, Nov 8, 2021 at 7:26 PM Ethan Furman wrote:
>>
>> Let's use a concrete example: `re.RegexFlag`
>>
>> ```
>> Help on function match in module re:
>>
>> match(pattern, string, flags=0)
>> Try to apply the pattern at the start of the string, returning
>> a Match object, or None if no match was found.
>> ```
>>
>> In use we have:
>>
>> result = re.match('present', 'who has a presence here?',
re.IGNORECASE|re.DOTALL)
>>
>> Inside `re.match` we have `flags`, but we don't know if `flags` is nothing
(0), a single flag (re.ASCII, maybe) or a
>> group of flags (such as in the example). For me, the obvious way to check
is with:
>>
>> if re.IGNORECASE in flags: # could be re.I in 0, re.I in 2, re.I in
5, etc.
>> ...
>
> Yes.
Note that the 0, 2, and 5 above are representative of the flag value passed in.
>> Now, suppose for the sake of argument that there was a combination of flags
that had its own code path, say
>>
>> weird_case = re.ASCII | re.LOCALE | re.MULTILINE
>>
>> I can see that going two ways:
>>
>> weird_case in flags # if other flags allowed
>>
>
> I would spell this as
>
> if flags & weird_case == weird_case:
> (which BTW works too if `flags` and `weird_case` are sets!)
That is a legitimate way to spell that operation, although sets wouldn't actually work since re.match expects an integer
or a RegexFlag.
>> or
>>
>> weird_case is flags # if no other flags allowed
>>
>
> this should be spelled using `==`, not using `is` (which is reserved for
identity, but here we're comparing values).
Instances of combined flags are also guaranteed singletons, so `is` is fine
(unless we're talking style choices).
>> The idiom that I'm shooting for is using `in` to check for flags:
>>
>> - flag1 in flag1 True
>> - flag1 in (flag1 | flag2) True
>> - flag3 in (flag1 | flag2) True
>
> Did you mean False for this last one?
Nope. flag3 is flag1 | flag2, so the same as (flag1 | flag2) in (flag1 |
flag2). I should probably have made that clearer.
>> - flag3 in flag1 False
>> - flag3 in flag4 False
>
> When `flag` is a single flag bit and `flags` is an unknown combination of
flag bits, you can conceivably
> make it so you can write this as `flag in flags`. But `in` doesn't work when
sets are represented as bits
> in an integer (which is the analogy you're going for?)
Technically, they work just fine. The bits and integers are an implementation detail, but one I suspect many, if not
most, of us are used to.
>> and
>>
>> - flag0 in any flag False
>>
>> - any flag in flag0 False
>
> What is `any flag` here?
Any combinaation of flags, including no flags at all.
>> And, of course, if we want to know if the thing we have is exactly flag1:
>>
>> flag is flag1
>>
>> will tell us.
>
>
> Please use `==` here.
Flags are guaranteed singletons, just like Enums.
>> Does this make sense?
>
> When thinking about sets of flag bits, do you actually visualize them as bits
in an integer?
Yes, but that's an implementation detail (albeit an efficient one).
> That's how I always think of them. Suppose we have three flags, F1, F2 and
F3. Let's write them in binary:
>
> F1 = 0b001
Agreed with all of that. My "weird case" above was in relation to the code used to handle that partic
[Python-Dev] Re: containment and the empty container
Let's use a concrete example: `re.RegexFlag`
```
Help on function match in module re:
match(pattern, string, flags=0)
Try to apply the pattern at the start of the string, returning
a Match object, or None if no match was found.
```
In use we have:
result = re.match('present', 'who has a presence here?',
re.IGNORECASE|re.DOTALL)
Inside `re.match` we have `flags`, but we don't know if `flags` is nothing (0), a single flag (re.ASCII, maybe) or a
group of flags (such as in the example). For me, the obvious way to check is with:
if re.IGNORECASE in flags: # could be re.I in 0, re.I in 2, re.I in 5, etc.
...
Now, suppose for the sake of argument that there was a combination of flags
that had its own code path, say
weird_case = re.ASCII | re.LOCALE | re.MULTILINE
I can see that going two ways:
weird_case in flags # if other flags allowed
or
weird_case is flags # if no other flags allowed
The idiom that I'm shooting for is using `in` to check for flags:
- flag1 in flag1 True
- flag1 in (flag1 | flag2) True
- flag3 in (flag1 | flag2) True
- flag3 in flag1 False
- flag3 in flag4 False
and
- flag0 in any flag False
- any flag in flag0 False
And, of course, if we want to know if the thing we have is exactly flag1:
flag is flag1
will tell us.
Does this make sense?
--
~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/7P552C66N6S3OBLH4UPWINU7TVPFT2Y3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] containment and the empty container
When is an empty container contained by a non-empty container?
For example:
{} in {1:'a', 'b':2] <-- TypeError because of hashability
set() in {1, 2, 'a', 'b'} <-- ditto
[] in ['a', 'b', 1, 2] <-- False
'' in 'a1b2' <-- True
SomeFlag.nothing in SomeFlag.something <-- ???
Personally, I have never had a use for '' in 'some string' being True, and always have to guard against that scenario.
Likewise, if an empty collection of flags is contained by a collection of flags, then that will trip me up as well; on
the other hand, it seems that collections of related flags are often treated as in set theory, where the empty set is a
member of any non-empty set...
So, does Flag adhere to set theory, or is just happenstance that some operators
work the same for both groups?
Can we have `SomeFlag.nothing in SomeFlag.something` be `False`, or would that
be too surprising?
--
~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/DAQV4BQDX6NLPF4PLEZ233FPANNKKIVW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467: Minor bytes and bytearray improvements
On 11/8/21 4:45 AM, Victor Stinner wrote:
> Is it implement "like" ascii(obj).encode("ascii") but with minor
> changes? What changes?
It works like `str()`, but you get ascii-encoded bytes (or an exception if
that's not possible).
The difference with the built-in ascii is the absence of extra quotes and the
`b` indicator when a string is used:
```
>>> u_var = u'abc'
>>> b_var = b'abc'
>>> str(u_var)
'abc'
>>> str(b_var)
"b'abc'"
>>> ascii(b_var)
"b'abc'"
>>> b'%a' % (u_var) # the docs will be updated to refer to %a as "ascii-repr"
b"'abc'" # as it mirrors %r but only returns ascii-encoded bytes
>>> bytes.ascii(u_var)
b'abc'
--
~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/X3XUYTCEM7IWTID2GING62LCEG3XKM7Q/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Oh look, I've been subscribed to python/issues-test-2 notifications again
On 11/4/21 12:21 PM, Brett Cannon wrote: > What notification? (I fully admit I may not have gotten one due to some team I'm in, but I have > no such notification if it happened recently.) I've received 20-30 in the last three or four days. I'm not concerned about it, just providing a data point. -- ~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/LFF2AQPBXJPVNFDBTW6ZVSIO55AYOHVM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 467: Minor bytes and bytearray improvements
The final PEP with SC feedback incorporated and one last addition: `bytes.ascii` as a replacement for the Python 2 idiom
of `str(some_var)` to get the bytes version, and the Python 3 workaround of either the correct
`str(some_var).encode('astii') or the potentially wrong `ascii(some_var).encode('ascii').
The rendered version is at https://www.python.org/dev/peps/pep-0467/
Happy reading!
PEP: 467
Title: Minor API improvements for binary sequences
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan , Ethan Furman
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30-Mar-2014
Python-Version: 3.11
Post-History: 2014-03-30 2014-08-15 2014-08-16 2016-06-07 2016-09-01 2021-04-13
2021-11-03
Abstract
This PEP proposes five small adjustments to the APIs of the ``bytes`` and
``bytearray`` types to make it easier to operate entirely in the binary domain:
* Add ``fromsize`` alternative constructor
* Add ``fromint`` alternative constructor
* Add ``ascii`` alternative constructor
* Add ``getbyte`` byte retrieval method
* Add ``iterbytes`` alternative iterator
Rationale
=
During the initial development of the Python 3 language specification, the
core ``bytes`` type for arbitrary binary data started as the mutable type
that is now referred to as ``bytearray``. Other aspects of operating in
the binary domain in Python have also evolved over the course of the Python
3 series, for example with PEP 461.
Motivation
==
With Python 3 and the split between ``str`` and ``bytes``, one small but
important area of programming became slightly more difficult, and much more
painful -- wire format protocols.
This area of programming is characterized by a mixture of binary data and
ASCII compatible segments of text (aka ASCII-encoded text). The addition of
the new constructors, methods, and iterators will aid both in writing new
wire format code, and in porting any remaining Python 2 wire format code.
Common use-cases include ``dbf`` and ``pdf`` file formats, ``email``
formats, and ``FTP`` and ``HTTP`` communications, among many others.
Proposals
=
Addition of explicit "count and byte initialised sequence" constructors
---
To replace the now discouraged behavior, this PEP proposes the addition of an
explicit ``fromsize`` alternative constructor as a class method on both
``bytes`` and ``bytearray`` whose first argument is the count, and whose
second argument is the fill byte to use (defaults to ``\x00``)::
>>> bytes.fromsize(3)
b'\x00\x00\x00'
>>> bytearray.fromsize(3)
bytearray(b'\x00\x00\x00')
>>> bytes.fromsize(5, b'\x0a')
b'\x0a\x0a\x0a\x0a\x0a'
>>> bytearray.fromsize(5, fill=b'\x0a')
bytearray(b'\x0a\x0a\x0a\x0a\x0a')
``fromsize`` will behave just as the current constructors behave when passed a
single integer, while allowing for non-zero fill values when needed.
Addition of explicit "single byte" constructors
---
As binary counterparts to the text ``chr`` function, this PEP proposes
the addition of an explicit ``fromint`` alternative constructor as a class
method on both ``bytes`` and ``bytearray``::
>>> bytes.fromint(65)
b'A'
>>> bytearray.fromint(65)
bytearray(b'A')
These methods will only accept integers in the range 0 to 255 (inclusive)::
>>> bytes.fromint(512)
Traceback (most recent call last):
File "", line 1, in
ValueError: integer must be in range(0, 256)
>>> bytes.fromint(1.0)
Traceback (most recent call last):
File "", line 1, in
TypeError: 'float' object cannot be interpreted as an integer
The documentation of the ``ord`` builtin will be updated to explicitly note
that ``bytes.fromint`` is the primary inverse operation for binary data, while
``chr`` is the inverse operation for text data, and that ``bytearray.fromint``
also exists.
Behaviorally, ``bytes.fromint(x)`` will be equivalent to the current
``bytes([x])`` (and similarly for ``bytearray``). The new spelling is
expected to be easier to discover and easier to read (especially when used
in conjunction with indexing operations on binary sequence types).
As a separate method, the new spelling will also work better with higher
order functions like ``map``.
These new methods intentionally do NOT offer the same level of general integer
support as the existing ``int.to_bytes`` conversion method, which allows
arbitrarily large integers to be converted to arbitrarily long bytes objects.
The
restriction to only accept positive integers that fit in a single byte means
that no byte order information is needed, and there is no need to handle
negative numbers. The doc
[Python-Dev] PEP 663:
See the latest changes, which are mostly a (hopefully) improved abstract, better tables, and some slight rewordings. Feedback welcome! --- PEP: 663 Title: 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, 02-Nov-2021 Resolution: Abstract Update the ``repr()``, ``str()``, and ``format()`` of the various Enum types to better match their intended purpose. For example, ``IntEnum`` will have its ``str()`` change to match its ``format()``, while a user-mixed int-enum will have its ``format()`` match its ``str()``. In all cases, an enum's ``str()`` and ``format()`` will be the same (unless the user overrides ``format()``). Add a global enum decorator which changes the ``str()`` and ``repr()`` (and ``format()``) of the decorated enum to be a valid global reference: i.e. ``re.IGNORECASE`` instead of . Motivation == 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 addition of ``StrEnum`` with its requirement to have its ``str()`` be its ``value`` is inconsistent with other provided Enum's ``str``. 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, only ``str()`` needs updating. As much as possible, the ``str()``, ``repr()``, and ``format()`` of enum members should be standardized across the standard library. However, up to Python 3.10 several enums in the standard library have a custom ``str()`` and/or ``repr()``. 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: - simple: ``Enum`` or ``Flag`` a new enum class is created with no data type mixins - 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__`` - user-mixed enums and flags the user creates their own integer-, float-, str-, whatever-enums instead of using enum.IntEnum, etc. There are also two styles: - normal: the enumeration members remain in their classes and are accessed as ``classname.membername``, and the class name shows in their ``repr()`` and ``str()`` (where appropriate) - global: the enumeration members are copied into their module's global namespace, and their module name shows in their ``repr()`` and ``str()`` (where appropriate) 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 two tables show the old and new output (blank cells indicate no change): +++-++---+ | style | category | enum repr() | enum str() | enum format() | ++-+--+-++---+ | normal | simple | 3.10 | || | || +--+-++---+ || | new | || | | +-+--+-++---+ |
[Python-Dev] Re: Sinai and Bunimovich stadium Billiard
On 10/23/21 8:01 PM, edivmanci...@gmail.com wrote: > I'm starting now to program with kwant and I'm having problems like: Sorry, you've reached the wrong list -- this one is for the development of Python itself. For general help using Python, subscribe to python-l...@python.org which you can do at https://mail.python.org/mailman/listinfo/python-list Good luck! -- ~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/NQLJZDXQK7BFKBBHHCCF4C5S2JQD6HLU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 except* formatting
On 10/5/21 6:32 PM, MRAB wrote: > On 2021-10-06 02:12, Barry Warsaw wrote: >> What do the PEP authors think about `except group`? Bikeshedding aside, that’s still the best alternative I’ve seen. >> It’s unambiguous, self-descriptive, and can’t be confused with unpacking syntax. >> > +1 +1 -- ~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/5E5OJAE6BZPANHII5QTYZ6KRGUPCS6WX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The Default for python -X frozen_modules.
On 9/27/21 10:50 AM, Guido van Rossum wrote: > So my *actual* proposal (call it #2') is to use a separate compile-time flag, which is set by `./configure > --enable-optimizations` regardless of whether PGO/LTO are possible, and which on Windows can be set by > `PCbuild\build.bat --pgo` (we could add another flag to disable it, but who'd want to?). I think a configure-time flag is the way to go, and I'm happy to have it included with --enable-optimizations. -- ~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/FCEJANFK7477B5IEHJ55BCEN5OBL3BTU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Changing exception text in micro releases
On 9/24/21 6:51 AM, Eric V. Smith wrote: > This is clearly an improvement. My question is: is it okay to backport this to 3.9 and 3.10? I > think we have a rule that it's okay to change the exception text, but I'm not sure how that > applies to micro releases (3.9.x, 3.10.1). "better" != "bug fix", so I wouldn't change it in a micro release. -- ~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/G3EVFK5K3REHNMYYAC2XLBALOUICIDLN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?
Guido: > It's still an iterator, since it duck-types in most cases where an iterator > is required (notably "for", which is the primary use case for the iteration > protocols -- it's in the first sentence of PEP 234's abstract). D'Aprano: > I don't think it duck-types as an iterator. Here's an example: > > class A: > def __init__(self): self.items = [1, 2, 3] > def __next__(self): > try: return self.items.pop() > except IndexError: raise StopIteration > > >>> for item in A(): pass > ... > Traceback (most recent call last): > File "", line 1, in > TypeError: 'A' object is not iterable Guido: > Yes, we all understand that. The reason I invoked "duck typing" is that as > long as you don't use the iterator in a situation where iter() is called > on it, it works fine. I'm confused. - a "broken" iterator should be usable in `for`; - `A` is a broken iterator; but - `A()` is not usable in `for`. What am I missing? -- ~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/ZMDWM7ICFLD5R7URT2ME4WNYBVQZKNUT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors
On 9/13/21 9:55 AM, Jelle Zijlstra wrote: > This table doesn't render properly in https://www.python.org/dev/peps/pep-0663/#specification. > - There are some extra blank lines > - Many cells are blank > - There are two "user mixed" rows and it's not clear how those relate to the mention of "three broad categories" above. The blank cells are the "no change" cells; the blank lines were there to separate the types (removed). I have reworked those tables slightly -- hopefully they make more sense now. -- ~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/WHLX3FSQYE62AEFFVGN6VGYQVWI5BD5J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors
On 9/13/21 9:03 AM, Steve Dower wrote: > You *are* allowed to put some (brief) details in the abstract. No need to avoid spoilers ;) > > As it stands, "it is time" on its own is a really bad reason to change anything. So you're > preemptively making it sound like the PEP has no solid backing. Abstract Update the ``repr()``, ``str()``, and ``format()`` of the various Enum types for consistency and to better match their intended purpose. Better? -- ~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/G23CC3KDI3QZNGEXR7M52TALQLRF3CPQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/9/21 12:04 PM, Terry Reedy wrote: > Except that .to_bytes already exists, and arguably should have had such defaults from the > beginning, making any new function to do the same thing superfluous. New functions aren't always about new functionality; sometimes they are about increased usability. Everything in the PEP can already be accomplished, just not easily: bstr = b'hello world' bchr = bstr.getbyte(7) # proposed bchr = bstr[7:8] # existing for bchr in bstr.iterbytes():# proposed ... for num in bstr: # existing bchr = bytes([bchr]) bchr = bytes.fromint(65) # proposed bchr = bytes([65]) # existing -- ~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/VRZOW3CKHC25I43EIFZO7ZOEOHYBZFNX/ Code of Conduct: http://python.org/psf/codeofconduct/
[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 | | +--+-++---+---+-
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/9/21 12:12 PM, Barry Warsaw wrote: > On Sep 9, 2021, at 10:56, Ethan Furman wrote: >> On 9/9/21 9:37 AM, Barry Warsaw wrote: >> >>> While I think int.to_bytes() is pretty obscure (I knew about it, forgot about it, and learned >>> about it again!) I’m not so sure it’s any less obscure than a proposed bytes.fromint(). >>> >>> So why don’t we just relax int.to_bytes()’s signature to include natural default values: >>> >>> int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False) >>> >>> Then I ought to be able to just do >>> >>> >>> (65).to_bytes() >>> b’A’ >> >> That seems so much worse than >> >> >>> bchr(65) >> b'A' >> >> ;-) > > Maybe, but given that you can *already* do the equivalent of bchr() with: > >>>> (65).to_bytes(1, sys.byteorder) > b'A' > > it seems like a small stretch to make that more usable, and that would outweigh adding a difficult > to understand new builtin. TOOWTDI. FWIW, bchr doesn't feel (much) like a new built-in, but more like a swap from unichr. At any rate, I know the built-in is not going to happen. int.to_bytes() doesn't feel like the One Obvious Way to me, and it certainly doesn't do much for readability in the bytearray case. Instead of `.fromord()` or `.fromint()` (or `int.to_bytes()`), my new favorite name, guaranteed not to change for at least the rest the day, is: bytes.chr() bytearray.chr() - this gets rid of the superflous b in bchr (not needed as the method is on bytes/bytearray) - has a nice symmetry with both the Python 3 chr(), and the answer to "where did the Python 2 chr() go?" question -- ~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/WJOTPVYSPLK4RX2EFO2C4XK6KJ4Y47LE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/9/21 9:37 AM, Barry Warsaw wrote: > While I think int.to_bytes() is pretty obscure (I knew about it, forgot about it, and learned > about it again!) I’m not so sure it’s any less obscure than a proposed bytes.fromint(). > > So why don’t we just relax int.to_bytes()’s signature to include natural default values: > > int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False) > > Then I ought to be able to just do > > >>> (65).to_bytes() > b’A’ That seems so much worse than >>> bchr(65) b'A' ;-) -- ~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/2XY5B7KIODN4Q5EB6HUKVKMVOV7TPJUH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/9/21 8:53 AM, Christopher Barker wrote: > On 9/9/21 7:25 AM, Ethan Furman wrote: >> I'm starting to think the name should be `bytes.bchr` -- it avoids any confusion with the `int.to_bytes` and >> `int.from_bytes` methods, > > are they so different? :-) Yes, they are. Conceptually, one is working with integers, the other with bytestrings (which is either entirely ASCII encoded strings, or a mixture of the two). >> and is an appropriate name for the target domain (where bytes are treated as characters). > > Is that the target domain? Yes. PEP 467*, and PEP 461 before it, are targeting the wire format protocol domain. -- ~Ethan~ * The `fromint/bchr` portion for sure, and the other changes certainly help there although they may have wider uses. PEP 461: https://www.python.org/dev/peps/pep-0461/ ___ 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/U4HOIBFOSQGUGKFI3GGFGBFPNPIQSIH7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/9/21 1:55 AM, Nick Coghlan wrote: > `bytes.fromint` is still the inverse of `ord` for bytes objects, even > without the `bchr` builtin alias. The spelling of the trio is just > `ord`/`bytes.fromint`/`chr` rather than `ord`/`bchr`/`chr`. The fact > the method throws an exception for integers that won't fit in a single > byte is an input data validation feature, not an undesirable > limitation. I'm starting to think the name should be `bytes.bchr` -- it avoids any confusion with the `int.to_bytes` and `int.from_bytes` methods, and is an appropriate name for the target domain (where bytes are treated as characters). -- ~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/LR6GZQEUBD6Q3AULB7ERPHLRCGJSFM4E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/9/21 3:49 AM, Steven D'Aprano wrote: > We're Python programmers. To Python programmers, the int 20 is not a > space character. That's because int 32 is the space character. ;-) -- ~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/6W5QDU6Q62BHTJKZG6TO634QXWD44O2F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/8/21 1:21 PM, Christopher Barker wrote: > NOTE: my objection to “bchr”, whether as a builtin or not is not the functionality, it’s the > name. Equating a byte with a character is a legacy of C ( and Python 2” — in Python 3, they > are completely distinct concepts. No, they aren't. If you are working in a domain that uses ascii encoding (such as many network protocols), then those bytes represent characters -- this is why, for example, %-interpolation was added back to bytes. -- ~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/4BG2BXAE3RGKQEGBHYW4IRLHEB3G6XNR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/7/21 10:39 PM, Steven D'Aprano wrote: > On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote: > >> I think Nick is on board with bytes.fromint() and no bchr(), and my >> sense of the sentiment here is that this would be an acceptable >> resolution for most folks. Ethan, can you reconsider? > > I haven't been completely keeping up with the entire thread, so > apologies if this has already been covered. I assume that the idea is > that bytes.fromint should return a single byte, equivalent to chr() > returning a single character. > > To me, it sounds like should be the opposite of int.from_bytes. > > >>> int.from_bytes(b'Hello world', 'little') > 121404708502361365413651784 > >>> bytes.from_int(121404708502361365413651784, 'little') > # should return b'Hello world' That certainly makes sense to me. At this point, the only reason that would not work is an arbitrary limit of 255 on the input, and the only reason that limit is there is to have `bchr` be the inverse of `ord`. Since `bchr` isn't going to happen, I see no reason to have the 255 limit. `byteorder` can default to None with a requirement of being set when the integer is over 255. -- ~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/44O4B2YOQGHCYUARRGVZ6WL6GRD4PZ5J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Suspension: Marco Sulla
After reviewing the "Problems with dict subclassing performance" thread, I am suspending Marco Sulla from Python-Dev for a period of three months. His behavior became blatantly inappropriate, and rather than apologize he continued taunting those that were trying to help him. Marco took exception to Steven D'Aprano's post, but I see nothing in Steven's post in either style or substance that warrants any moderator attention. -- ~Ethan~ Moderator ___ 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/RHB4HHNARDVBYZFTSXGMFDIVED5SAYAH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] New moderator
Greetings, all! After petitioning the Steering Council I have been added as a moderator for the Python Dev mailing list. I was already the moderator of four other Python lists. My goal as a moderator is to have our forums be civil and within the CoC. I do rely heavily on users to let me know if someone may be crossing the line. For the record, I do feel I can be impartial even when I am the target of attacks -- I don't think I deserve any special treatment, so such things will be handled the same as if any other community member were the target. -- ~Ethan~ Moderator ___ 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/UXDQLENNZRPPTJ2AAVUUP2DPT2KRIEPG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 8/3/21 1:19 PM, Barry Warsaw wrote: > Can you provide some rationale for why you prefer bchr() over .fromint()? - `bchr` directly corresponds with `chr` - `str` has no `fromint` - `bytearray(bchr(int))` is roughly the same as `bytearray.fromint(int)`, but `bchr(int)` for a bytes object is much nicer that `bytes.fromint(int)` - possible confusion between `fromsize` and `fromint` (I know it would get me from time to time) -- ~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/5PDMVAVBELIPG23TOCTLEDA6DWYVYBAC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 7/29/21 3:46 PM, Barry Warsaw wrote: > We’re generally very favorable for adding to Python 3.11 the features and APIs described > in the PEP. We have some requests for changes that we’d like you to consider. > > * The Python-Version in the PEP needs to target Python 3.11 of course. Done. > * We think it would be better if bytes.fromsize()’s second argument was a keyword-enabled or keyword-only argument. We understand the rationale given in the PEP for not doing so, but ultimately we think the readability of (at least allowing) a keyword argument to be more compelling. Some possible options include `fill`, `value`, or `byte`. Done, went with "fill" as an optional keyword argument. > * We all really dislike the word “ord” as in `bytes.fromord()`. We understand the symmetry of this choice, but we also feel like we have an opportunity to make it more understandable, so we recommend `bytes.fromint()` and `bytearray.fromint()`. Done. > * We think the `bchr()` built-in is not necessary. Given the `.fromint()` methods, it’s better not to duplicate the functionality, and everything has a cost. A built-in that exists only for the symmetry described in the PEP is just a little extra complexity for little value. I would rather keep `bchr` and lose the `.fromint()` methods. To get bytes: some_var = bchr(65) vs some_var = bytes.fromint(65) and for bytearrays some_var = bytearray(bchr(65)) vs some_var = bytearray.from_int(65) Let me know if I should drop `.fromint()`. -- ~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/FUGXFVXV3SXPOX66KMAWKAJXIERB3JF4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 558: Defined semantics for locals()
On 7/22/21 1:01 AM, Petr Viktorin wrote:
> On 21. 07. 21 14:18, Nick Coghlan wrote:
>>
>> typedef enum {
>> PyLocals_UNDEFINED = -1;
>> PyLocals_DIRECT_REFERENCE = 0,
>> PyLocals_SHALLOW_COPY = 1
>> } PyLocals_Kind;
>>
>> PyLocals_Kind PyLocals_GetKind(void);
>> PyLocals_Kind PyFrame_GetLocalsKind(PyFrameObject *);
>>
>
> Please don't put the enum in the stable ABI. If we would add another value
and then
> an older extension would receive it, we'd get undefined behavior.
Probably a stupid question, but wouldn't the same thing happen if we didn't use an enum, added another option later, and
on older extension received that newer value?
--
~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/6J5PN5TJ5N3UNJ7UE5UT3NW4CUJ5AGAX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: RFC for PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors
On 7/21/21 5:33 AM, Nick Coghlan wrote: > I don't have any substantive comments on what you're proposing (aside > from "Yes, that sounds reasonable to me"), so my comments below are > just some minor suggested clarifications for the PEP text. Thanks, PEP updated. -- ~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/KGK3P2L26GMKSMLN5RI2FLY4YITZVY2R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] RFC for PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors
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 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; i.e.:: >>> Color.RED >>> str(Color.RED) 1 >>> format(Color.RED) '1' Note that format() already produces the correct output, 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.9 | || | | Color.RED|GREEN| Color.RED|GREEN | | +--+-++---+---++---+ | | new | || | | Color.RED|Color.GREEN | Color.RED|Color.GREEN | +-+--+-++---+---++---+ +-+--+-++---+---++---+ | user mixed | 3.9 | || 1 || | 1 | | +--+-++---+---++---+ | | new | || Grey.WHITE
[Python-Dev] Re: From the SC (was Re: Enum -- last call for comments on 3.10 changes)
On 7/11/21 4:00 PM, Miro Hrončok wrote: > On 07. 07. 21 3:58, Ethan Furman wrote: >> I was unable to revert just the str and repr changes in the time available as many of them were >> integral to fixes and improvements made to Flag. As a result the enum in 3.10 will be the same >> as 3.9 (complete module reversion). > > I see the revert was merged with the "skip news" label. The changelog now mentions the original > change, but not the revert. > > Is it possible to mention this retroactively in the 3.10.0b4 changelog, or is that frozen now? > I think it's important to document this for maintainers of codebases that already adapted their > code to the new behavior with an if Python version >= 3.10 conditional. Thanks for bringing that up, a new news entry has been added. -- ~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/RXFYYX74WVI5ALUNJUL645EANUVFNU6G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [slightly OT] cryptographically strong random.SystemRandom()
On 7/9/21 2:25 PM, Tim Peters wrote: > `secrets` is just a wrapper around `random.SystemRandom`, so the > presence or absence of `secrets` doesn't matter. > > As to SystemRandom, all answers depend on the quality of the platform > os.urandom(), which Python has no control over. See my answer here, > and the comments on it: > > https://stackoverflow.com/questions/20936993/ Good to know, thanks. -- ~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/ZGCYXLN6FS3RUHRWH65EDDS5CDMVDBJH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] [slightly OT] cryptographically strong random.SystemRandom()
Greetings! A question [1] has arisen about the viability of `random.SystemRandom` in Pythons before and after the secrets module was introduced (3.5 I think) -- specifically does it give independent and uniform discrete distribution for cryptographic purposes across CPython 3.x versions? Any help appreciated! -- ~Ethan~ [1] https://stackoverflow.com/q/68319071/208880 ___ 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/JH5BS7FBK3EA4I7NJDD6GG3G56YXMDFC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: From the SC (was Re: Enum -- last call for comments on 3.10 changes)
On 6/29/21 9:50 AM, Barry Warsaw wrote: > the Steering Council strongly suggests that for Python 3.10, the changes in Enum’s > str and repr be reverted back to the Python 3.9 behavior, and that a PEP be written > for Python 3.11. I was unable to revert just the str and repr changes in the time available as many of them were integral to fixes and improvements made to Flag. As a result the enum in 3.10 will be the same as 3.9 (complete module reversion). A PEP will be forthcoming. My apologies and sympathies to those that contributed to the 3.10 enum module -- look for those changes in 3.11. -- ~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/LSTMFAPSPD3BGZ4D6HQFODXZVB3PLYKF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum -- last call for comments on 3.10 changes
On 6/28/21 6:54 AM, Nick Coghlan wrote: > * Enum repr() changing back to the historical behaviour, unless you opt in to the > new behaviour with the global enum decorator: definite +1 here Question for Nick: this behavior is currently in place for stdlib enumerations, and has been since beta 0; are you saying this change should also be put off to 3.11 ? -- ~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/AVNMYCH5PZ7CI6COY6NEZKSXO4VV56CA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Enum -- last call for comments on 3.10 changes
I have spoken with Pablo (3.10 RM), and he agrees that a change to Enum str() in 3.10 and another in 3.11 is less than ideal, so this new thread is to collect comments about Enum and it's str() and repr() and whether the changes take effect in 3.10, 3.11, or both. TL;DR -- sorry, there isn't one. History: As Enum and IntEnum have started proliferating in the stdlib, some of those enumerations have changed the str() and repr() of their members -- for example, in 3.8 re.RegexFlag had its repr() and str() changed to be module.name (re.ASCII) for both instead of () for the repr(); that change made sense because all the members are exported to re's global name space, and they are accessed as `re.ASCII` in existing code. While a good change (in my opinion and with which I had nothing to do), we now have stdlib enumerations with differing str() and repr()s, which is a minor ding against recognizability and usability. Current 3.10 Changes In an effort to standardize the stdlib enums, a new decorator was added: global_enum(). It can be called manually (for example in re.RegexFlag), or automatically by Enum._convert_ (for example in ssl.VerifyFlags). That changed was visually appealing, and I had users wanting that type of output for Enum in general, so after asking for feedback on python-dev and python-ideas (and receiving little) I changed the basic str() and repr() of Enum to: - str(): NAME - repr(): enum.NAME While working on some other bugs/changes in Enum.__format__ and serialization in general, I have come to believe that IntEnum (and IntFlag) should be as near-perfect a drop-in replacement as possible for when they are used to replace existing integer constants (which I believe is their most important use-case). Reverting 3.10 Changes -- I have been increasingly unhappy with the general `Enum.__repr__` change, so while the stdlib global repr() change is staying, Enum, IntEnum, etc., is going back to . Proposed 3.10 Change (for 3.10.0 beta 4) In order to improve the drop-in replacement use-case for IntEnum and IntFlag, I would like to change the str() for those two to be simply the value of the member, as if it was still a plain integer and not part of an enumeration. At that point the only obvious difference would be the repr(), which I think is the most important and useful change as that is what (should) show up in log files, the REPL, etc. This would also make IntEnum and IntFlag consistent with StrEnum as, for other reasons, StrEnum member str()s are the values of the members rather than the names of the members. Note also that this change would not affect user created enumerations that mixed in int on their own. The Question With all the changes currently happening to the str()s and repr()s of the various enums, what are the good reasons to not make this final change now, and instead have one more change in 3.11? -- ~Ethan~ Summary of Enum str()s and repr()s by category | | repr() | str() | format() | stdlib global | re.ASCII | re.ASCII | 256 | Enum | | Color.RED | RED | IntEnum | | 1 | 1 | int, Enum | | Color.RED | 1 (will be RED in 3.12 due to back-compatibility | || constraints which should affect very few people as | || as they are probably using IntEnum instead of mixing | || in int themselves -- comments about this likelihood also | || appreciated) ___ 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/ZMC67QA2JVQJSWSFWRS6IM6ZX4EK277G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] IntEnum, IntFlag, and the stdlib
TL;DR I am considering changing IntEnum and IntFlag's `__str__` to be `int.__str__` IntEnum and IntFlag are becoming more common in the stdlib. They currently show up in * http * re * signal * ssl * socket to name just a few. 3.10 already has some changes to the str() and repr() of enums in general: HTTPStatus -> OK and HTTPStatus.OK instead of HTTPStatus.OK and Enum's that are taking the place of global constants have the repr() further modified: RegexFlag -> ASCII and re.ASCII instead of RegexFlag.ASCII and When Enum was first created we also modified the default JSON encoder to be able to encode int- and float-based enumerations; however, with the continued rise of Python in the world a user stumbled upon a stdlib encoder that we missed: `urllib.parse.urlencode()` (as seen in issue 33025 [1]). IIRC enum.IntEnum (and later enum.IntFlag) were introduced so they could be drop-in replacements for existing integer constants. At the time I didn't fully appreciate how those constants were used in code with regards to str() -- which is to say, changing the str() output can be a breaking change, even inside the stdlib. What I would like to do for the enum module is make any supplied mixed-in enums a little more vanilla: * str() is the mixed-in `__str__`, not the Enum `__str__` * format() is the mixed-in `__format__`, not the Enum `__format__` (this is the current effective behavior already) Other benefits, particularly repr(), would remain. Note that a mixed enum created by a user would have the normal Enum `__str__` and `__format__`. Summary: mixed enums provided in the enum module should maintain the mixed data types `__str__` and `__format__`. Thoughts? -- ~Ethan~ [1] https://bugs.python.org/issue33025 ___ 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/HE36QRXPPQNHGQKYZM3ZTG42EQQRHAIX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: name for new Enum decorator
On 6/6/21 9:14 AM, Irit Katriel via Python-Dev wrote: > On 6 Jun 2021, at 16:58, Andrei Kulakov wrote: >> In Math / CompSci there is a definition that almost exactly matches this: Exact Cover - >> https://en.wikipedia.org/wiki/Exact_cover >> >> The difference is that, IIRC, solving the problem is finding and removing all subsets that are unneeded to create an >> exact cover, so it's kind of arriving at it from a different direction, but 'exact cover' definition itself is a good >> match. > > I’m not sure it’s a quite the same - it doesn’t require that the sets in the cover have cardinality 1, which I think > Ethan does. Well, I'm not sure what "cardinality 1" means, so I don't know if I do or not. :) -- ~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/BMCG6MA3HKYAQC4JARJFXZDOZGCSIPMM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: name for new Enum decorator
On 5/27/21 8:24 PM, Ethan Furman wrote: > So, like the enum.unique decorator that can be used when duplicate names should be an error, > I'm adding a new decorator to verify that a Flag has no missing aliased values that can be > used when the programmer thinks it's appropriate... but I have no idea what to call it. > > Any nominations? Thank you everyone for your ideas! Instead of adding another single-purpose decorator, I'm toying with the idea of adding a general purpose decorator that accepts instructions. Something along the lines of: class EnumChecks(StrEnum): """ various conditions to check an enumeration for """ UNIQUE = "one name per value" CONTINUOUS = "no skipped values" DECOMPOSABLE_ALIASES = "flag aliases must have all bits named" def verify(enumeration, *checks): if UNIQUE in checks: # ensure no duplicates if CONTINUOUS in checks: # ensure no missing values if DECOMPOSABLE_ALIASES in checks: # ensure all multi-flag aliases are composed of named flags 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/DVFOYTEPFNUDXWIYS763XGTCWJ6GFL5U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: name for new Enum decorator
On 5/28/21 12:43 AM, Petr Viktorin wrote: > On 28. 05. 21 5:24, Ethan Furman wrote: >> class FlagWithMasks(IntFlag): >> DEFAULT = 0x0 >> >> FIRST_MASK = 0xF >> FIRST_ROUND = 0x0 >> FIRST_CEIL = 0x1 >> FIRST_TRUNC = 0x2 >> >> SECOND_MASK = 0xF0 >> SECOND_RECALC = 0x00 >> SECOND_NO_RECALC = 0x10 >> >> THIRD_MASK = 0xF00 >> THIRD_DISCARD = 0x000 >> THIRD_KEEP = 0x100 >> >> Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that are aliasing values >> that don't exist, but it seems intentional and not an error. > > Are you looking for a decorator for the whole Enum, or a way to mark individual *values* as masks? The decorator is for whole enum. The issue is not that some values are masks, but whether the absence of named bits covered by the mask is an error. -- ~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/OM5M774MP5QPLFXZ7OVGBPR7ZFB6X35A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] name for new Enum decorator
Greetings! The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements into a decorator instead, and I'm having a hard time thinking up a name. What is the behavior? Well, a name in a flag type can be either canonical (it represents one thing), or aliased (it represents two or more things). To use Color as an example: class Color(Flag): RED = 1# 0001 GREEN = 2 # 0010 BLUE = 4 # 0100 PURPLE = RED | BLUE# 0101 WHITE = RED | GREEN | BLUE # 0111 The flags RED, GREEN, and BLUE are all canonical, while PURPLE and WHITE are aliases for certain flag combinations. But what if we have something like: class Color(Flag): RED = 1# 0001 BLUE = 4 # 0100 WHITE = 7 # 0111 As you see, WHITE is an "alias" for a value that does not exist in the Flag (0010, or 2). That seems like it's probably an error. But what about this? class FlagWithMasks(IntFlag): DEFAULT = 0x0 FIRST_MASK = 0xF FIRST_ROUND = 0x0 FIRST_CEIL = 0x1 FIRST_TRUNC = 0x2 SECOND_MASK = 0xF0 SECOND_RECALC = 0x00 SECOND_NO_RECALC = 0x10 THIRD_MASK = 0xF00 THIRD_DISCARD = 0x000 THIRD_KEEP = 0x100 Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that are aliasing values that don't exist, but it seems intentional and not an error. So, like the enum.unique decorator that can be used when duplicate names should be an error, I'm adding a new decorator to verify that a Flag has no missing aliased values that can be used when the programmer thinks it's appropriate... but I have no idea what to call it. Any nominations? -- ~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/RGZU4QAP4SXVQUJPRJF6FMN45E22U4XL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On 5/20/21 10:47 AM, David Mertz wrote: > On Thu, May 20, 2021 at 6:21 AM Tal Einat wrote: >> I think it's worth preserving the idiom of comparing sentinels using >> `is`, as we do for `None` and other existing sentinel values. It's >> relatively easy to do, such as by using a single-value Enum or by >> using a class with a custom __new__. > > > This only works if: > > a) Unpickling is within a single interpreter session I don't understand. If I pickle a sentinel in session A, then unpickle it in session B, why wouldn't I get the "same" sentinel? > b) Sentinels are explicitly created in imported modules, not as a runtime, user-level creation Why would you ever have a sentinel not always created? Hoping-to-learn-something-new'ly yrs, -- ~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/OLTV44EVHJL3C4AIFPGUINZAZNI3YNNK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On 5/20/21 11:00 AM, Paul Moore wrote: > But it nevertheless feels like a bit of an abuse - the original point > of ellipsis was for indexing, and in particular complex slices like > a[1:20:2, ..., 3:5]. That usage is common in numpy, as I understand > it, Interesting -- do you know what ... means in that context? -- ~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/EKKZP27QJZJD7UA7BXV6TB5EG7NOI2H3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Critique of PEP 657 -- Include Fine Grained Error Locations in Tracebacks
On 5/17/2021 6:13 AM, Mark Shannon wrote: > Where i1, i2 are integers and s1 is a string. > i1 + i2 + s1 > Wouldn't the carets just be under the i2 + s1 portion? -- ~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/YPWW3PIBJDUIETZQOJNHIYR5FNGMOJJ5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On 5/13/21 2:15 AM, Irit Katriel via Python-Dev wrote:
>
> >>> help(traceback.print_exception)
> Help on function print_exception in module traceback:
>
> print_exception(exc, /, value=,
tb= at 0x02825DF09650>, limit=None, file=None,
chain=True)
On 5/13/21 5:37 AM, Eric V. Smith wrote:
>
> The help looks like:
>
> field(*, default=,
>default_factory=,
>init=True, repr=True, hash=None, compare=True, metadata=None)
>
> None of this is particularly awesome, but no one has complained about it yet.
Consider me complaining. ;-)
Looks to me like the default repr for the sentinels is making those helps much less helpful by showing totally
irrelevant information and cluttering up the screen making it harder to see the actually useful bits.
An actual Sentinel class would be helpful:
>>> class Sentinel:
... def __init__(self, repr):
... self.repr = repr
... def __repr__(self):
... return self.repr
...
>>> MISSING = Sentinel('MISSING')
>>> MISSING
MISSING
>>> implicit = Sentinel('')
>>> implicit
Naturally, since sentinels are symbolic names, I think it should go into the enum module. ;-) Although I will concede
that we could just put those five lines into the modules that need it.
--
~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/7S5PU6334ZZXCA3EFV244YZWY27KA3FD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks
On 5/9/21 3:00 AM, M.-A. Lemburg wrote: > BTW: For better readability, I'd also not output the lines > for every stack level in the traceback, but just the last one, > since it's usually clear where the call to the next stack > level happens in the upper ones. Usually, sure -- but in the unusual case those carets at every level can save a lot of time and frustration, and that is the goal of this enhancement, yes? I know I have experienced that ambiguity more than once. -- ~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/NQPGKRKGOECYWHB2FOOHXEMPV3XTO6CU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks
On 5/8/21 1:31 PM, Pablo Galindo Salgado wrote: >> We can't piggy back on -OO as the only way to disable this, it needs to >> have an option of its own. -OO is unusable as code that relies on "doc" >> strings as application data such as http://www.dabeaz.com/ply/ply.html >> exists. > > -OO is the only sensible way to disable the data. There are two things to disable: > > * The data in pyc files > * Printing the exception highlighting Why not put in it -O instead? Then -O means lose asserts and lose fine-grained tracebacks, while -OO continues to also strip out doc strings. -- ~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/BEE4BGUZHXBTVDPOW5R4DC3S463XC3EJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Can't sync cpython main to my fork
On 5/6/21 7:14 AM, Jelle Zijlstra wrote: > Maybe others have different workflows, but I don't see much of a need > for keeping your fork's main branch up to date. I will occasionally do a `git push origin main` just to shut up the messages about being behind/ahead; other than that, I have no idea why I would need origin to be up to date. -- ~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/CCOTW2ILRNTFIXRMWLVWDBT2FBANZ2Q4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] github and dependabot
I have two pull requests against my cpython fork from a dependabot -- what is that, and should I merge them? -- ~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/OTX3F5RQFPTND3UGK2RRFNWDXAFOKXO4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: In what tense should the changelog be written?
On 4/29/21 7:57 PM, Larry Hastings wrote: > When one writes one's "blurb" for the changelog, in what tense should it be? Present tense. :) -- ~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/AM3TQUXVNKGOAEC2GBVNUZAZOCLAD6N3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: stdlib Flag Enums and the "no value" member
On 4/29/21 10:35 AM, Jonathan Goble wrote: > On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote: >> Which raises the question: Do we want to have a standard name for stdlib Flags when no flags are set? > > If you want a flag to represent no flags set, it takes one line to write it yourself, as in this example I copied > verbatim from the docs: > > >>> class Color(Flag): > ... BLACK = 0 > ... RED = auto() > ... BLUE = auto() > ... GREEN = auto() > ... > >>> Color.BLACK > > >>> bool(Color.BLACK) > False Are you suggesting that the standard name for 0 be 'BLACK'? ;-) -- ~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/U365WUWGJBGFVMEXUQUFRPHAONTB7CJP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: stdlib Flag Enums and the "no value" member
On 4/29/21 10:52 AM, Antoine Pitrou wrote: > On Thu, 29 Apr 2021 18:37:29 +0100, MRAB wrote: >> On 2021-04-29 18:19, Ethan Furman wrote: >>> An excerpt from bpo-31369: re.RegexFlag and `__all__` >>> >>> GvR: >>> >>>> One thing I discovered when developing this example: there doesn't seem to be a flag to >>>> represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even though it works >>>> fine at runtime). >>> >>> Which raises the question: Do we want to have a standard name for stdlib Flags when no flags are set? >>> >>> What should we call it? >>> >>> - NONE >>> >>> - ZERO >>> >>> - EMPTY >>> >>> - ??? >>> >> Definitely NONE. At some point I might even add it to the regex module! :-) > > Not to confuse with None, which will not be equal to NONE. Hmm... > > Perhaps NONE_SET or ALL_UNSET? > > (also, why the ALL_CAPS?) Since Enum members are constants, ALL_CAPS is recommended for their naming scheme. -- ~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/WEGL7HPVCLD54QH622WZZLASFIJVE27Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] stdlib Flag Enums and the "no value" member
An excerpt from bpo-31369: re.RegexFlag and `__all__` GvR: > One thing I discovered when developing this example: there doesn't seem to be a flag to > represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even though it works > fine at runtime). Which raises the question: Do we want to have a standard name for stdlib Flags when no flags are set? What should we call it? - NONE - ZERO - EMPTY - ??? -- ~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/ACZOZLWJRW7PTVURJWU3LN6UYVTIBENL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: str() vs format(): trivia question
On 4/20/21 2:11 PM, MRAB wrote:
> On 2021-04-20 20:42, Ethan Furman wrote:
>> The deprecation period will give that user, and others like them, time to
add their own Enum base classes with the
>> `__format__` method they desire.
>
> Couldn't the format accept 'd' if they want an int, i.e. f"{Color.RED:d}"?
Yes, in fact. And that even works now. Thanks!
--
~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/7VUAJMEJVY2K5BO5WKLDCMDGSVBCJC7Q/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: str() vs format(): trivia question
On 4/20/21 12:01 PM, Guido van Rossum wrote:
> On Tue, Apr 20, 2021 at 11:12 AM Ethan Furman wrote:
>> Moving forward, I'm not sure having format() and str() ever be different
>> is a good idea, especially since users who need, for example, Color.RED
>> to be '1' can simply add a `__str__ = int.__str__` to their own custom
>> base IntEnum class and be good to go. If we deprecate the current behavior
>> now we could change it in 3.12.
>>
>> Thoughts?
> So to be clear, that one user wants f"{Color.RED}" to return "1" and not
> " Color.RED" (or something like that). And you want f"{Color.RED}" and
> str(Color.RED) to return the same value. Then together that means that
> str(Color.RED) must also return "1".
>
> Did I get that right? And are you happy with that outcome?
Almost right. They should both return `Color.RED`. Any users who want something different will need to do some work on
their end:
class MyIntEnum(IntEnum):
def __format__ = int.__format__
class Color(MyIntEnum):
RED = 1
format(Color.RED)
# '1'
The deprecation period will give that user, and others like them, time to add their own Enum base classes with the
`__format__` method they desire.
--
~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/GM2T4ATWPDAMYVELXRHJ4OJWNCD2T26Q/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: str() vs format(): trivia question
On 4/20/21 8:46 AM, Guido van Rossum wrote:
I'd guess it is totally up to the object, since str() calls `__str__` and format() calls `__format__`. Of course this
now begs the question whether those enums should perhaps change their `__format__` to match their `__str__`...?
When Enum was designed we made sure and captured `__repr__` and `__str__`, but not `__format__`. So at this point,
`__format__` is the mixed-in data type's -- so `int.__format__` in the case of IntEnum. However, if a user updates the
`__str__` of their Enum, then that will be used in the format:
```python
from enum import IntEnum
class Color(IntEnum):
RED = 1
format(Color.RED)
# '1'
class Color(IntEnum):
RED = 1
def __str__(self):
return 'one'
format(Color.RED)
# 'one'
```
But that
would not suit your purpose. Then again, how would one get the pretty IntEnum-specific representation in a format- or
f-string? I guess f"{flag!s}" would work.
Yup, that does work.
There is at least one user who is depending on `format()` using `int.__format__` because they filed a bug report when I
broke it.
Moving forward, I'm not sure having format() and str() ever be different is a good idea, especially since users who
need, for example, Color.RED to be '1' can simply add a `__str__ = int.__str__` to their own custom base IntEnum class
and be good to go. If we deprecate the current behavior now we could change it in 3.12.
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/FJ3KXKXSYHPZZI7A25LEH4IANXECRIN4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] str() vs format(): trivia question
urllib.urlencode currently uses `str()` on its non-bytes objects before encoding the result. This causes a compatibility break when integer module constants are converted to IntEnum, as `str(IntEnum.MEMBER)` no longer returns the integer representation; however, `format()` does still return the integer representation. The fix is to add a separate branch to check if the argument is an Enum, and use the value if so -- but it got me wondering: in general, are there differences between calling str() vs calling format() on Python objects? -- ~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/24OF6XMFYK4PO2VPY6UFT2S3CBZFNOKB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 563 in light of PEP 649
On 4/19/21 10:51 AM, Larry Hastings wrote:
Something analogous /could/ happen in the PEP 649 branch but currently doesn't. When running Inada Noki's benchmark,
there are a total of nine possible annotations code objects. Except, each function generated by the benchmark has a
unique name, and I incorporate that name into the name given to the code object (f"{function_name}.__co_annotations__").
Since each function name is different, each code object name is different, so each code object /hash/ is different, and
since they aren't /exact/ duplicates they are never consolidated.
I hate anonymous functions, so the name is very important to me. The primary code base I work on does have hundreds of
methods with the same signature -- unfortunately, many of the also have the same name (four levels of super() calls is
not unusual, and all to the same read/write/create parent methods from read/write/create child methods). In such a case
would the name make a meaningful difference?
Or maybe the name can be store when running in debug mode, and not stored with
-O ?
--
~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/XWZUVJSZMUB5Q4FVMKJWP2XK45LRTG7J/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: How about using modern C++ in development of CPython ?
On 4/16/21 10:43 AM, redrad...@gmail.com wrote: Take a look at this video https://www.youtube.com/watch?v=D7Sd8A6_fYU or read some articles ... otherwise I will need to spend too many time providing evidences to you and after all you will probably will reject anyway (because lots of people is biased and they even do not understand that, it is not about you, it is in general) You are the one proposing the change, so it's up to you to provide the evidence for it. If you aren't willing to put in a few hours for that effort, why should we put the weeks and months to port the code over? -- ~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/OBZU7R2ORXXF3FSJL55TX4SRR7G7KZP2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: How about using modern C++ in development of CPython ?
On 4/16/21 10:27 AM, redrad...@gmail.com wrote: Chris Angelico wrote: On Sat, Apr 17, 2021 at 3:20 AM redrad...@gmail.com wrote: The benefits: You will link with high quality libstdc++ with lots of reusable containers without writing your own "buggy" one. C++ is much much more maintainable than pure C. It drastically increase number of contributors that what like writing high quality and maintainable code without reinventing the wheel. Citations please? What exactly do you what ? A list of current Python containers that are already in C++, that work exactly as our C ones do (otherwise, we will have had to add code to make them work as we want, and surely that will introduce bugs). Examples of how C++ is more maintainable. A poll of users that love C++ enough to contribute to CPython because we also use C++, combined with a poll of users currently contributing C code that would stop because they don't know/like C++. We should also have evidence that C++ is available on all supported platforms that we support CPython on. -- ~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/DKC4UKYGLJJQX3N3EOBQYROMHV7FZKMA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Making staticmethod callable, any oposite?
On 4/13/21 6:20 PM, Inada Naoki wrote: Then, does anyone oppose this change? Having staticmethod, etc., be callable would make my code much easier in at least two different projects. Please make this change. -- ~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/U6PSB4NEI4UI3PSOE63CQHBFIP5X555L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP-0467: Minor API improvements for binary sequences
On 4/13/21 3:01 PM, Jelle Zijlstra wrote: Thanks for this PEP! Most of these proposals would make for useful improvements to the language. I have a few pieces of feedback below. El mar, 13 abr 2021 a las 14:14, Ethan Furman escribió: This PEP has been deferred until Python 3.9 at the earliest, as the open This should be 3.10 at least (and even that is pushing it by now). Ah, thanks -- fixed (and fingers crossed for 3.10 -- most of the code/tests are already written). While this does create some duplication, there are valid reasons for it: * the ``bchr`` builtin is to recreate the ``ord``/``chr``/``unichr`` trio from Python 2 under a different naming scheme (however, see the Open Questions section below) * the class method is mainly for the ``bytearray.fromord`` case, with ``bytes.fromord`` added for consistency I don't see an "Open questions" section in this email (only an "Open issues" section talking about memoryview). Fixed (removed reference to Open questions). I don't find the argument for a builtin very persuasive. Why is it important to recreate the Python 2 trio? `bchr` is a more obscure name than `bytes.fromord`. `bytes.fromord` is already short and doesn't require an import, so we don't gain that much from the separate builtin. `chr` and `ord` are builtins, so `bchr` fits right in. `bytes.fromord` is there to mirror `bytearray.fromord` and facilitate duck-typing. What you are doing will affect which one you reach for. For me at least, reading code that contains `bytes.fromord` puts too much emphasis on the type and method, whilst `bchr` has it just right. :-) -- ~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/DX7GTNWYO36QQVNSN3BT3Z6QPG7SRXYA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP-0467: Minor API improvements for binary sequences
Looking for final comments before submitting for SC approval. It would be nice
to finally get this resolved. :)
Full text follows.
---
PEP: 467
Title: Minor API improvements for binary sequences
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan , Ethan Furman
Status: Deferred
Type: Standards Track
Content-Type: text/x-rst
Created: 30-Mar-2014
Python-Version: 3.9
Post-History: 2014-03-30 2014-08-15 2014-08-16 2016-06-07 2016-09-01 2021-04-13
Abstract
During the initial development of the Python 3 language specification, the
core ``bytes`` type for arbitrary binary data started as the mutable type
that is now referred to as ``bytearray``. Other aspects of operating in
the binary domain in Python have also evolved over the course of the Python
3 series.
This PEP proposes five small adjustments to the APIs of the ``bytes`` and
``bytearray`` types to make it easier to operate entirely in the binary domain:
* Discourage passing single integer values to ``bytes`` and ``bytearray``
* Add ``bytes.fromsize`` and ``bytearray.fromsize`` alternative constructors
* Add ``bytes.fromord`` and ``bytearray.fromord`` alternative constructors
* Add ``bytes.getbyte`` and ``bytearray.getbyte`` byte retrieval methods
* Add ``bytes.iterbytes`` and ``bytearray.iterbytes`` alternative iterators
And one built-in::
* ``bchr``
PEP Deferral
This PEP has been deferred until Python 3.9 at the earliest, as the open
questions aren't currently expected to be resolved in time for the Python 3.8
feature addition deadline in May 2019 (if you're keen to see these changes
implemented and are willing to drive that resolution process, contact the PEP
authors).
Proposals
=
Discourage use of current "zero-initialised sequence" behaviour
---
Currently, the ``bytes`` and ``bytearray`` constructors accept an integer
argument and interpret it as meaning to create a zero-initialised sequence
of the given size::
>>> bytes(3)
b'\x00\x00\x00'
>>> bytearray(3)
bytearray(b'\x00\x00\x00')
This PEP proposes to update the documentation to discourage making use of that
input type dependent behaviour in Python 3.10, suggesting to use a new, more
explicit, ``bytes.fromsize(n)`` or ``bytearray.fromsize(n)`` spelling instead
(see next section).
However, the current handling of numeric inputs in the default constructors
would remain in place indefinitely to avoid introducing a compatibility break.
No other changes are proposed to the existing constructors.
Addition of explicit "count and byte initialised sequence" constructors
---
To replace the now discouraged behaviour, this PEP proposes the addition of an
explicit ``fromsize`` alternative constructor as a class method on both
``bytes`` and ``bytearray`` whose first argument is the count, and whose
second argument is the fill byte to use (defaults to ``\x00``)::
>>> bytes.fromsize(3)
b'\x00\x00\x00'
>>> bytearray.fromsize(3)
bytearray(b'\x00\x00\x00')
>>> bytes.fromsize(5, b'\x0a')
b'\x0a\x0a\x0a\x0a\x0a'
>>> bytearray.fromsize(5, b'\x0a')
bytearray(b'\x0a\x0a\x0a\x0a\x0a')
``fromsize`` will behave just as the current constructors behave when passed a
single integer, while allowing for non-zero fill values when needed.
Similar to ``str.center``, ``str.ljust``, and ``str.rjust``, both parameters
would be positional-only with no externally visible name.
Addition of "bchr" function and explicit "single byte" constructors
---
As binary counterparts to the text ``chr`` function, this PEP proposes
the addition of a ``bchr`` function and an explicit ``fromord`` alternative
constructor as a class method on both ``bytes`` and ``bytearray``::
>>> bchr(ord("A"))
b'A'
>>> bchr(ord(b"A"))
b'A'
>>> bytes.fromord(65)
b'A'
>>> bytearray.fromord(65)
bytearray(b'A')
These methods will only accept integers in the range 0 to 255 (inclusive)::
>>> bytes.fromord(512)
Traceback (most recent call last):
File "", line 1, in
ValueError: integer must be in range(0, 256)
>>> bytes.fromord(1.0)
Traceback (most recent call last):
File "", line 1, in
TypeError: 'float' object cannot be interpreted as an integer
While this does create some duplication, there are valid reasons for it:
* the ``bchr`` builtin is to recreate the ``ord``/``chr``/``unichr`` trio from
Py
[Python-Dev] word choices when criticizing [was: Typing syntax and ecosystem]
> You could say [...] or "I deeply think that this was one of the > worst decisions" [...] Not to get too far off topic, but that's not a good choice of words, either. -- ~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/TSJK3GITB2BHPX62CCP345V2UOR6OUUQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: NamedTemporaryFile and context managers
On 4/8/21 1:43 PM, Antoine Pitrou wrote: On Thu, 8 Apr 2021 13:31:26 -0700 Ethan Furman wrote: ```python from tempfile import NamedTemporaryFile with NamedTemporaryFile() as fp: fp.write(b'some data') fp.close() # Windows workaround fp.open() data = fp.read() assert data == 'some_data' ``` The problem is that, even though `fp.open()` is still inside the context manager, the `close()` call deletes the file [2]. To handle this scenario, my proposal is two-fold: 1) stop using the TEMPFILE OS attribute so the OS doesn't delete the file on close 2) add `.open()` to NamedTemporaryFile Instead, you could add a dedicated `.reopen()`? The main hurdle is that on Windows we let the OS manage the lifetime of the file, which means that it is deleted as soon as it is closed. We would need to remove that branch and treat all NamedTemporaryFiles the same. We could add reopen(), but since close() is already there... although I do like the name of `reopen`. -- ~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/2DGIFUS6SU56MP6OWOEJPSWEDR2PL5CS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] NamedTemporaryFile and context managers
In issue14243 [1] there are two issues being tracked: - the difference in opening shared files between posix and Windows - the behavior of closing the underlying file in the middle of NamedTemporaryFile's context management I'd like to address and get feedback on the context management issue. ```python from tempfile import NamedTemporaryFile with NamedTemporaryFile() as fp: fp.write(b'some data') fp = open(fp.name()) data = fp.read() assert data == 'some_data' ``` Occasionally, it is desirable to close and reopen the temporary file in order to read the contents (there are OSes that cannot open a temp file for reading while it is still open for writing). This would look like: ```python from tempfile import NamedTemporaryFile with NamedTemporaryFile() as fp: fp.write(b'some data') fp.close() # Windows workaround fp.open() data = fp.read() assert data == 'some_data' ``` The problem is that, even though `fp.open()` is still inside the context manager, the `close()` call deletes the file [2]. To handle this scenario, my proposal is two-fold: 1) stop using the TEMPFILE OS attribute so the OS doesn't delete the file on close 2) add `.open()` to NamedTemporaryFile A possible side effect of (1) is that temp files may accumulate if the interpreter crashes, but given the file-management abilities in today's software that seems like a minor annoyance at most. The backwards compatibility issue of (1) is that the file is no longer deleted after a manual `close()` -- but why one would call close() and then stay inside the CM, outside of testing, I cannot fathom. [3] So, opinions on modifying NamedTemporaryFile to not delete on close() if inside a CM, and add open() ? -- ~Ethan~ [1] https://bugs.python.org/issue14243 [2] plus, the `.open()` doesn't yet exist [3] feel free to educate me :-) ___ 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/DZNEIRHZ7LVQNQRQ2JL5B4AOC3HH3B6O/ Code of Conduct: http://python.org/psf/codeofconduct/
