[Python-Dev] Re: PEP 563 and 649: The Great Compromise
On Sat., Apr. 24, 2021, 20:55 Carl Meyer, wrote: > Hi Larry, > > This is a creative option, but I am optimistic (now that the SC > decision has removed the 3.10 deadline urgency) that we can find a > path forward that is workable for everyone and doesn't require a > permanent compiler feature flag and a language that is permanently > split-brained about annotation semantics. Since I have access to a > real-world large codebase with almost complete adoption of type > annotations (and I care about its import performance), I'm willing to > test PEP 649 on it (can't commit to doing it right away, but within > the next month or so) and see how much import performance is impacted, > and how much of that can be gained back by interning tweaks as > discussed in the other thread. Thanks for the kind offer, Carl! I know I would find it useful in evaluating PEP 649 is we had a real-world perf evaluation like you're offering. My feeling is that if the performance > turns out to be reasonably close in a real codebase, and we can find a > workable solution for `if TYPE_CHECKING`, we should go ahead with PEP > 649: IMO aside from those two issues its semantics are a better fit > for the rest of the language and preferable to PEP 563. > > I do think that a solution to the `if TYPE_CHECKING` problem should be > identified as part of PEP 649. My favorite option there would be a new > form of import that is lazy (the import does not actually occur until > the imported name is loaded at runtime). This has prior art in > previous discussions about "module descriptors"; IIRC Neil Schemenauer > even had a branch a while ago where all module attributes were > modified to behave this way (I might be remembering the details > wrong.) Nope, you're remembering right; it was Neil. I think he started looking at this topic at the core dev sprints when they were hosted at Microsoft (2018?). It also has overlap with use cases served by the existing > `demandimport` library used by hg, and `importlib.util.LazyLoader`, > I'm not sure if it's diverged, but he's solution was originally a copy of importlib.util.LazyLoader, so the approach was the same. although it is strictly more capable because it can work with `from > module import Thing` style imports as well. If there's any interest in > this as a solution to inter-module annotation forward references, I'm > also willing to work on that in the 3.11 timeframe. > I know I would be curious, especially if backwards compatibility can be solved reasonably (for those that haven't lived this, deferred execution historically messes up code relying on import side-effects and trackbacks are weird as they occur at access time instead of at the import statement). -Brett > Carl > ___ > 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/VBG2LXU6OHROQ3NPF373L7W4W23B24DE/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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/NDM5WTHZUJIZSG7VKWTVNFJ7AGIBCWVG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
On Fri, Apr 23, 2021 at 2:45 AM Chris Angelico wrote: > > On Fri, Apr 23, 2021 at 6:25 PM Nathaniel Smith wrote: > > The main possibility that I don't think we've examined fully is to > > make 'except' blocks fire multiple times when there are multiple > > exceptions. > > Vanilla except blocks? Not sure if I'm misunderstanding, but that > could cause some problems. Consider: > > trn.begin() > try: > ... > except BaseException: > trn.rollback() > raise > else: > trn.commit() > > What happens if multiple exceptions get raised? Will the transaction > be rolled back more than once? What gets reraised? > > If I'm completely misunderstanding you here, my apologies. Yeah, you've understood correctly, and you see why I wrote "both the current proposal and the alternative have very complex implications and downsides" :-) A lot depends on the details, too. One possible design is "in general, vanilla except blocks will trigger multiple times, but as a special case, except: and except BaseException: will only fire once, receiving the whole ExceptionGroup as a single exception". (Rationale for making a special case: if you're saying "catch anything, I don't care what", then you obviously didn't intend to do anything in particular with those exceptions, plus this is the only case where the types work.) In that design, your example becomes correct again. Some other interesting cases: # Filters out all OSError's that match the condition, while letting all other OSError's continue try: ... except OSError as exc: if exc.errno != errno.EWHATEVER: raise # If this gets an ExceptionGroup([ValueError, KeyboardInterrupt]), then it logs the ValueError and # then exits with the selected error code try: ... except Exception as exc: logger.log_exception(exc) except KeyboardInterrupt: sys.exit(17) OTOH you can still come up with cases that aren't handled correctly. If you have old 'except' code mixed with new code raising ExceptionGroup, then there's no way to make that do the right thing in *all* cases. By definition, when the 'except' code was written, the author wasn't thinking about ExceptionGroups! So the question is which combination of semantics ends up doing the least harm on average across all sorts of different real-world cases... -n -- Nathaniel J. Smith -- https://vorpus.org ___ 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/3V6YEKHOD5MYLSCPVDB7IYGX4EOO4KWB/ Code of Conduct: http://python.org/psf/codeofconduct/
