[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2021-10-15 - 2021-10-22) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7199 (-202) closed 50111 (+289) total 57310 (+87) Open issues with patches: 2841 Issues opened (65) == #19459: Python does not support the GEORGIAN-PS charset https://bugs.python.org/issue19459 reopened by vstinner #40051: Give proper link in help(idlelib/turtledemo/tkinter.sub/test_* https://bugs.python.org/issue40051 reopened by zach.ware #43656: TracebackException or StackSummary.extract with capture_locals https://bugs.python.org/issue43656 reopened by andrei.avk #45434: [C API] Clean-up the Python.h header file https://bugs.python.org/issue45434 reopened by vstinner #45445: Fail if an invalid -X option is provided https://bugs.python.org/issue45445 reopened by pablogsal #45474: [C API] marshal.h must not use FILE* type in the limited C API https://bugs.python.org/issue45474 reopened by petr.viktorin #45491: help() is too noisy for types used like functions https://bugs.python.org/issue45491 opened by rhettinger #45492: stdlib inspect documentation on code.co_names is incorrect https://bugs.python.org/issue45492 opened by Dutcho #45493: str() and repr() of enum different in Python 3.11 from Python https://bugs.python.org/issue45493 opened by Dutcho #45496: Tkinter: test_winfo_rgb failure https://bugs.python.org/issue45496 opened by epaine #45501: [idea] Successfully creating a venv could print a message. https://bugs.python.org/issue45501 opened by mdk #45502: Fix test_shelve and make it discoverable https://bugs.python.org/issue45502 opened by serhiy.storchaka #45503: Several improvement point of gdbm module https://bugs.python.org/issue45503 opened by corona10 #45504: [argparse] Entering a partial config_parser flag works with su https://bugs.python.org/issue45504 opened by swills1 #45505: Remove unneeded ZipFile IO https://bugs.python.org/issue45505 opened by data-ux #45506: Out of source tree builds failing on main - test_importlib oth https://bugs.python.org/issue45506 opened by gregory.p.smith #45507: Small oversight in 3.11 gzip.decompress implementation with re https://bugs.python.org/issue45507 opened by rhpvorderman #45508: Specialize INPLACE_ADD https://bugs.python.org/issue45508 opened by Dennis Sweeney #45509: Gzip header corruption not properly checked. https://bugs.python.org/issue45509 opened by rhpvorderman #45510: Specialize BINARY_SUBTRACT https://bugs.python.org/issue45510 opened by corona10 #45511: input() method limited to 4095 characters on *NIX https://bugs.python.org/issue45511 opened by Romuald #45512: [sqlite3] simplify "isolation level" https://bugs.python.org/issue45512 opened by erlendaasland #45514: Deprecate legacy functions from importlib.resources (importlib https://bugs.python.org/issue45514 opened by jaraco #45517: TarFile.add skips files when tarfile name matches a directory https://bugs.python.org/issue45517 opened by jkinkead #45518: Invalid example for typing https://bugs.python.org/issue45518 opened by bozhiyou #45519: Minor docstring improvement in __contains__ https://bugs.python.org/issue45519 opened by Ivan.Savov #45520: Frozen dataclass deep copy doesn't work with __slots__ https://bugs.python.org/issue45520 opened by jfuruness #45524: Cross-module dataclass inheritance breaks get_type_hints https://bugs.python.org/issue45524 opened by aidan.b.clark #45528: mmap: constants not listed in the documentation https://bugs.python.org/issue45528 opened by goodmami #45530: Improve listobject.c's unsafe_tuple_compare() https://bugs.python.org/issue45530 opened by tim.peters #45531: field "mro" behaves strangely in dataclass https://bugs.python.org/issue45531 opened by finite-state-machine #45533: loop.sock_connect doesn't resolve the address parameter on Win https://bugs.python.org/issue45533 opened by YAtOff #45534: Failing test_exceptions and test_threading https://bugs.python.org/issue45534 opened by aritra1911 #45535: Enum's dir() does not contain inherited members https://bugs.python.org/issue45535 opened by serhiy.storchaka #45539: Negative lookaround assertions sometimes leak capture groups https://bugs.python.org/issue45539 opened by jirkamarsik #45540: module.__package__ and module.__spec__.parent have different s https://bugs.python.org/issue45540 opened by barry #45542: Using multiple comparison operators can cause performance issu https://bugs.python.org/issue45542 opened by akuvfx #45545: chdir __exit__ is not safe https://bugs.python.org/issue45545 opened by ucodery #45546: Unable to pickle enum with nested frozen dataclass? https://bugs.python.org/issue45546 opened by Eric Cousineau #45547: Modernize the importlib loaders https://bugs.python.org/issue45547 opened by FFY00 #45548: Update Modules/Setup https://bugs.python
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Most of the discussion so far has been focused on (?.). Tbh though, I'm more interested in (??) and (??=). Just reading through code, I constantly notice boilerplate like this which could easily be substituted. variable = some_function(...) if variable is None: variable = [] # some default value # a bit better with an assignment expression if (variable := some_function(...)) is None: variable = [] # or worse with an if expression variable = some_function(...) if some_function(...) else [] # also possible with :=, but not much better variable = x if (x := some_function(...)) else [] # using the coalesce operator would be much more readable IMO variable = some_function(...) ?? [] If (?.) and (?[) are rejected / deferred, maybe there is interest in seeing at least (??) and (??=) through? ___ 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/7DED2THUJJPBS556YQ4YHH3TN6WGH2UH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
On Sat, Oct 23, 2021 at 6:20 AM Marc Mueller wrote: > > Most of the discussion so far has been focused on (?.). Tbh though, I'm more > interested in (??) and (??=). Just reading through code, I constantly notice > boilerplate like this which could easily be substituted. > > variable = some_function(...) > if variable is None: > variable = [] # some default value > > # a bit better with an assignment expression > if (variable := some_function(...)) is None: > variable = [] > > # or worse with an if expression > variable = some_function(...) if some_function(...) else [] > # also possible with :=, but not much better > variable = x if (x := some_function(...)) else [] Bear in mind that these last ones are exactly equivalent to the "or" operator, as they'll use the default if you have any falsy value. variable = some_function(...) or [] > # using the coalesce operator would be much more readable IMO > variable = some_function(...) ?? [] > > If (?.) and (?[) are rejected / deferred, maybe there is interest in seeing > at least (??) and (??=) through? I'm actually more interested in a better idiom for non-constant function default arguments, since that's the place where this kind of thing often comes up. A nice ??= operator might help if your default is None, but if you then change the default to be object(), you can't use ??= any more. As a bonus, the docs for such an argument could actually say what the default really is: def bisect_right(a, x, lo=0, hi=len(a), *, key=None): ... except that it'd need some adornment to say that it's late-bound. ChrisA ___ 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/DAD32U6CKSWB3HI322WRKRYYKFNWFPEP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Type annotations, PEP 649 and PEP 563
Larry Hastings wrote: > In Python, if you evaluate an undefined name, Python raises a > NameError. This is so consistent I'm willing to call it a "rule". Would it help the think of the function creation as catching that exception, and then finishing construction with its own version of NaN? ___ 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/KGMXBLE2AP2TBOUBOVCTNFHAVX77ZFLO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Type annotations, PEP 649 and PEP 563
Hello! > This would affect code that expects annotations to always be strings, but such > code would have to be poking directly at function objects (the > __annotations__ attribute), instead of using the advertised ways of getting > at annotations (like typing.get_type_hints()). I would speculate that this is somewhat common to find. What I don't think is common enough to consider is code that directly relies on the annotations being strings. The majority of code will be trying to retrieve the actual underlying types. The potential one script out there in the solarsystem that relies on this can just wrap the result in str(...) to ensure it's in-fact a string. > Keeping the future import and stringified annotations around is certainly > an option, but we’re worried about the cost of the implementation, the > support cost, and the confusion for users (specifically, it is a future > import that will never become the future). If we do keep them, how long > would we keep them around? Should we warn about their use? If we warn about > the future import, is the noise and confusion this generates going to be > worth it? If we don't warn about them, how will we ever be able to turn > them off? I quite particularly like what Łukasz Langa brought up under the header "A better possible future" in their blog post here: https://lukasz.langa.pl/61df599c-d9d8-4938-868b-36b67fdb4448/ (which has been listed in another reply here). I will quote part of the paragraph below (read 2021-10-22; last updated 2021-10-21): > if the library author is fine with DeprecationWarnings, they could keep using > `from __future__ import annotations` until Python 3.13 is released (October > 2023). [...]. > So I would advise marking the old future-import as “pending deprecation” > until 3.13 > and only fully deprecate it then for two releases, so it would > be removed in Python 3.14 (𝛑) in October 2025 when Python 3.9 goes EOL. This seems like the sense of direction in terms of a compromise that I would like to see. > One idea is to rely on linters and IDEs to provide this signal, possibly > with a clear upgrade path for the code (e.g. a 2to3-like fixer for a > specific deprecation). > [...] > This sounds like a reasonably user-friendly approach, but it would require > buy-in from linter/IDE developers, or an officially supported “Python > linter” project that we control. I think this is a nice step in the right direction as you mention test frameworks have had this role so I don't see the issue in also extending this to static analysis tools (static type checkers, linters and IDEs). Couldn't the "Python linter" simply be the current behaviour when you opt-into it? > Is it safe to assume very little code would be poking directly at > __annotations__ attributes of function objects; effectively, to declare them > implementation details and let them not be strings even in code that > currently has the annotations future import? I believe so, see my comments further up in this reply. It was never safe to assume that all annotations were strings (in my opinion on writing good code) and so yes I believe this would be a non-breaking change and could be considered an implementation detail. > Is the performance of PEP 649 and PEP 563 similar enough that we can > outright discount it as a concern? Does anyone actually care about the > overhead of type annotations anymore? Are there other options to alleviate > this potential issue (like a process-wide switch to turn off annotations)? In my opinion this shouldn't warrant any concern as these costs are only on startup of Python. The difference is not enough for me to care at least. > If we do not need to keep PEP 563 support, which would be a lot easier > on code maintenance and our support matrix, do we need to warn about the > semantics change? Can we silently accept (and ignore) the future import > once PEP 649 is in effect? In terms of semver I don't think this causes a breaking change that warrants a major bump. That said this change should be made aware to the broader Python community so that it reaches those who are affected by this change. Have a good weekend ___ 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/K77G435H7QQZ4YZOVXYBMWZLSQKGO3U3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Type annotations, PEP 649 and PEP 563
On Thu, Oct 21, 2021 at 09:36:20PM -0700, Christopher Barker wrote: > On Thu, Oct 21, 2021 at 5:24 PM Steven D'Aprano wrote: > > > Runtime type checkers already have to deal with forward refs that are > > strings, as this is legal, and always will be: > > > > def function(arg:'Spam') -> Any: ... > > > > so we're not putting any extra burden on them. And we had already > > agreed to implicitly use strings for annotations. > > > > I'll take your word for it. However, other runtime uses for annotations may > not already need to support strings as types. > > Pydantic is the classic example. Pydantic supports stringified annotations. https://pydantic-docs.helpmanual.io/usage/postponed_annotations/ Any other runtime annotation tool has to support strings, otherwise the "from __future__ import annotations" directive will have already broken it. If the tool does type-checking, then it should support stringified annotations. They have been a standard part of type-hinting since 2014 and Python 3.5: https://www.python.org/dev/peps/pep-0484/#forward-references Any type-checking tool which does not already support stringified references right now is broken. -- Steve ___ 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/WVVBETE7UZ4WI6HOF7WCNHYOK6HCXRTA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Type annotations, PEP 649 and PEP 563
> Any other runtime annotation tool has to support strings, otherwise the > "from __future__ import annotations" directive will have already broken > it. Exactly- isn’t that it was deferred in 3.10, and may never be implemented? I’ll leave it to the Pydantic developers to discuss that, but they were pretty clear that PEP 563 would break things. If the tool does type-checking, then it should support stringified > annotations. I guess I wasn’t clear — my point was there are uses for annotations that are NOT type checking. And my understanding of what the SC said was that they want those uses to continue to be supported. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/J2UWKGIGKA7IKYBSKL3DNDWPO3AXH7SF/ Code of Conduct: http://python.org/psf/codeofconduct/
