[issue45361] Provide a more convenient way to set an exception as "active", from Python code

Guido van Rossum added the comment: In a brief off-line chat we concluded that the desired API would be closer to PyErr_Restore(). -- ___ Python tracker <https://bugs.python.org/issue45

[issue14757] INCA: Inline Caching meets Quickening in Python 3.3

Change by Guido van Rossum : -- Removed message: https://bugs.python.org/msg403481 ___ Python tracker <https://bugs.python.org/issue14757> ___ ___ Python-bug

[issue14757] INCA: Inline Caching meets Quickening in Python 3.3

Guido van Rossum added the comment: Followup: https://github.com/faster-cpython/ideas/issues/93 New paper: https://arxiv.org/abs/2109.02958 -- ___ Python tracker <https://bugs.python.org/issue14

[issue14757] INCA: Inline Caching meets Quickening in Python 3.3

Guido van Rossum added the comment: See GitHub.com/faster-cpython/ideas/issues/93 for a belated follow-up. -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue14

[issue29410] Moving to SipHash-1-3

Guido van Rossum added the comment: Victor: > I expect even more interesting speedup with bytes string longer than 6k > bytes. And I'm quite sure that it's common that people manipulates long > strings in Python :-) But do they use them as dict keys? AFAIK strings aren&

[issue29410] Moving to SipHash-1-3

Guido van Rossum added the comment: Worth revisiting? -- ___ Python tracker <https://bugs.python.org/issue29410> ___ ___ Python-bugs-list mailing list Unsub

[issue29410] Moving to SipHash-1-3

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue29410> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45272] 'os.path' should not be a frozen module

Guido van Rossum added the comment: It was a comment about my general lack of understanding of how the importlib bootstrap process works. I should probably start reading the docstrings before complaining more. :-) -- ___ Python tracker <ht

[issue45272] 'os.path' should not be a frozen module

Guido van Rossum added the comment: I'm trying to understand the proposed solution, "have _imp.is_frozen() check the module in sys.modules." Does that mean it would do a dict lookup first? Maybe you should do that in the caller instead? importlib/_bootstrap.py calls it a few

[issue45361] Provide a more convenient way to set an exception as "active", from Python code

Guido van Rossum added the comment: Do you think the API you're looking for is available at the C level? Like PyErr_SetExcInfo()? -- ___ Python tracker <https://bugs.python.org/is

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: Whoa. os.path is not always an alias for posixpath, is it? -- ___ Python tracker <https://bugs.python.org/issue45

[issue45378] Can't find "map" with search on docs.python.org

Guido van Rossum added the comment: > I'm surprised no one else noticed this until now. Most people probably just use Google and read whatever comes up. I was looking whether the official docs for map mentioned that map is actually an iterator class. (Th

[issue45378] Can't find "map" with search on docs.python.org

New submission from Guido van Rossum : I was looking for the docs for 'map' and tried to use the search box on docs.python.org. This gave a lot of things whose name started with or contained 'map', but the entry for the builtin map() function was hidden really far dow

[issue45352] Move documentation for typed generic forms of standard collections to collections.abc

Guido van Rossum added the comment: I'm not against additional tutorial for typing. But the standard library manual is supposed to be a complete reference. There is enough variation between different generic types (e.g. are the parameters covariant?) that ought to be documented. I

[issue45352] Move documentation for typed generic forms of standard collections to collections.abc

Guido van Rossum added the comment: > Where are capabilities like "list[str]" and "dict[str, list[int]]" going to > be documented? I think those should go with the individual types as well. AFter all, it's specific to the type how many parameters it has an

[issue45352] Move documentation for typed generic forms of standard collections to collections.abc

Guido van Rossum added the comment: I think we should go ahead and duplicate the documentation in collections.abc (and in a few other places -- PEP 585 lists some builtins, some in contextlib, some in re). Then we won't have to worry about what happens when the typing module is slimmed

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: Serhiy: > I propose an opposite change -- take data known at compile time (name, > qualname and annotations). I'm confused by your phrase "take data" -- do you mean remove these? Or wht do you propose we do with them? > It will ma

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: And it's most definitely 3.11, not 3.9. (Did you mean to change a different issue?) -- versions: +Python 3.11 -Python 3.9 ___ Python tracker <https://bugs.python.org/is

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: @santhu_reddy12, why did you assign this to the Parser category? IMO this issue is clearly in the Build category. (We haven't met, I assume you have triage permissions?) -- ___ Python tracker &

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: Not so fast. I'm not in favor of (c) co_doc either any more (for the reasons you state). I would go for (b), a CO_DOCSTRING flag plus co_consts[0]. I expect that co_consts sharing to be a very minor benefit, but you could easily count this with an

[issue45211] Useful (expensive) information is discarded in getpath.c.

Guido van Rossum added the comment: Shouldn't we just close the issue and the unused PR? Otherwise we'll just have yet another vague bpo issue that doesn't have anything particularly actionable -- "there's some code that could be refactored" is not enough of

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: The plan is to add __file__ back, based on where the stdlib lives (we won’t do any stat() calls for frozen files). -- ___ Python tracker <https://bugs.python.org/issue45

[issue45283] Top / function argument level ClassVar should not be allowed during `get_type_hints()`

Guido van Rossum added the comment: Hm. IMO it is up to static type checkers to reject bad use of types. The runtime should be relaxed so type checkers can develop new features assigning new semantics to such constructs. -- nosy: +gvanrossum

[issue43760] The DISPATCH() macro is not as efficient as it could be (move PyThreadState.use_tracing)

Guido van Rossum added the comment: Ah, I think the docs need to be clarified a bit. Here's what I was missing: The key thing to know here is that there are *three* state variables; `c_tracefunc`, `c_profilefunc` (on the thread state), and `use_tracing` (on the C frame). Nor

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: I'm still torn about the need for a __file__ attribute. Assuming it's more likely that people write code that *reads* stdlib source for some reason (maybe printing more context for error messages) than *writing* it (which would be truly str

[issue45026] More compact range iterator

Guido van Rossum added the comment: May the best PR win. :-) -- ___ Python tracker <https://bugs.python.org/issue45026> ___ ___ Python-bugs-list mailin

[issue44807] typing.Protocol silently overrides __init__ method of delivered class

Guido van Rossum added the comment: I wonder if part of the problem here isn't that protocols are primarily focused on instances, where the __init__ method is explicitly *not* considered part of the type. IIRC supporting protocols for classes was an afterthought. That said you have m

[issue24076] sum() several times slower on Python 3 64-bit

Guido van Rossum added the comment: Sounds good, you have my blessing. -- ___ Python tracker <https://bugs.python.org/issue24076> ___ ___ Python-bugs-list mailin

[issue24076] sum() several times slower on Python 3 64-bit

Guido van Rossum added the comment: The patch looks fine, but it looks a bit like benchmark chasing. Is the speed of builtin sum() of a sequence of integers important enough to do this bit of inlining? (It may break if we change the internals of Py_Long, as Mark Shannon has been wanting to

[issue45116] Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue45116> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43760] The DISPATCH() macro is not as efficient as it could be (move PyThreadState.use_tracing)

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue43760> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45026] More compact range iterator

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue45026> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24165] Free list for single-digits ints

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue24165> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24138] Speed up range() by caching and modifying long objects

Guido van Rossum added the comment: (Never mind, that should have gone to https://bugs.python.org/issue24165, which is the integer freelist -- conclusion there in 2015 was also that it didn't do much.) -- ___ Python tracker &

[issue24138] Speed up range() by caching and modifying long objects

Guido van Rossum added the comment: Should we try the free list for integers again? -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue24

[issue24076] sum() several times slower on Python 3 64-bit

Guido van Rossum added the comment: @Stefan > FWIW, a PGO build of Py3.7 is now about 20% *faster* here than my Ubuntu > 16/04 system Python 2.7 Does that mean we can close this issue? Or do I misunderstand what you are comparing? 32 vs. 64 bits? PGO vs. non-PGO? OTOH on my Mac I

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: > It would be nice to freeze argparse.py and its dependencies. For > command-line tools, startup time is important. I quickly checked, and argparse has at least these dependencies: argparse re enum types operator functools collections keyword r

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: BTW, why does the script still run Programs/_freeze_module over all the modules to be frozen? Isn't that up to the Makefile or its Windows equivalent? -- ___ Python tracker <https://bugs.python.org/is

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: (Ah, now I recall how the $(srcdir) mechanism works again. Generated files do *not* have a $(srcdir) prefix, since they are generated in the destination directory. Hence the fix for the buildbot failure a few days ago. I take back my skepticism about that

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: FWIW, Python/frozen_modules/__hello__.h is still in the repo somehow. -- ___ Python tracker <https://bugs.python.org/issue45

[issue45188] De-couple the Windows builds from freezing modules.

Guido van Rossum added the comment: We can once GH-28375 lands. -- ___ Python tracker <https://bugs.python.org/issue45188> ___ ___ Python-bugs-list mailin

[issue21736] Add __file__ attribute to frozen modules

Guido van Rossum added the comment: > Note that the filename information is already available in the > code object's co_filename attribute. Hm, in the latest (3.11) main that's not true -- co_filename is set to something like "". And that's about right, since

[issue45188] De-couple the Windows builds from freezing modules.

Guido van Rossum added the comment: I tried this: - remove the generated .h files - touched dictobject.c - touched dictobject.h After each step I tried to rebuild. Each case the compilation of frozen.c failed and then the build stopped, so apparently the .h files weren't generated

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: I would move "default to "on" (except if actually running out of the source tree)" to the "maybe" category. I left a few comments in other deps. I think we should start by turning this on by default in PGO builds. Separate

[issue45186] Marshal output isn't completely deterministic.

Guido van Rossum added the comment: I would propose that marshal internally make an extra pass over its input in order to determine which objects are referenced multiple times. This will speed up reading marshalled data (in addition to addressing the reproducibility issue with debug builds

[issue45188] De-couple the Windows builds from freezing modules.

Guido van Rossum added the comment: Is this now done? I.e. can we now drop the frozen .h files from the repo? -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue45

[issue45211] Useful (expensive) information is discarded in getpath.c.

Guido van Rossum added the comment: Honestly I find it debatable whether we're doing anyone a favor by publishing the __file__ of the corresponding stdlib file for frozen modules. There will be situations where this points to the wrong file, and editing the file will not have an e

[issue43893] typing.get_type_hints does not accept type annotations with leading whitespaces

Change by Guido van Rossum : -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: If you reduce the number of modules being frozen you could probably manage to land this (or most of it) before tackling those other issues. -- ___ Python tracker <https://bugs.python.org/issue45

[issue45109] pipes seems designed for bytes but is str-only

Guido van Rossum added the comment: I think that module is probably a relic from the Python 1 days… -- ___ Python tracker <https://bugs.python.org/issue45

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

Guido van Rossum added the comment: We're not (yet) trying to optimize the code being executed (we should perhaps add an issue about class creation to https://github.com/faster-cpython/ideas). I agree that marshal is very fast already; I doubt the extra cost of wordcode would pay off

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

Guido van Rossum added the comment: Raymond, I am super grateful that you are showing us the assembly language. That's the kind of thing we need to do more of if we want to be successful. (In this case I'm not surprised by the outcome, but I have never studied x86 assembly and

[issue45122] Remove PyCode_New and PyCode_NewWithPosOnlyArgs

Guido van Rossum added the comment: Da-woods, can you take care of that? -- ___ Python tracker <https://bugs.python.org/issue45122> ___ ___ Python-bugs-list m

[issue20115] NUL bytes in commented lines

Guido van Rossum added the comment: Serhiy’s comment from 2014-01-04 gives the answer. It’s different reading from a file than from a string. And only “python x.py” still reads from a file. -- ___ Python tracker <https://bugs.python.org/issue20

[issue20115] NUL bytes in commented lines

Guido van Rossum added the comment: Which part puzzles you? I see that you tried >>> #\0 This does not contain a null byte, just three characters: a hash, a backslash, and a digit zero. -- ___ Python tracker <https://bugs.python.or

[issue45122] Remove PyCode_New and PyCode_NewWithPosOnlyArgs

Guido van Rossum added the comment: That sounds like a good plan (note that alpha 1 will go out around Oct 4). I left an issue for Cython: https://github.com/cython/cython/issues/4365 -- ___ Python tracker <https://bugs.python.org/issue45

[issue45122] Remove PyCode_New and PyCode_NewWithPosOnlyArgs

Guido van Rossum added the comment: PS. It would be nice to also update Cython, which is the only thing that uses these C APIs. -- ___ Python tracker <https://bugs.python.org/issue45

[issue45122] Remove PyCode_New and PyCode_NewWithPosOnlyArgs

New submission from Guido van Rossum : This is up for grabs. For reference, the Steering Council approved getting rid of these two C APIs without honoring the customary two-release deprecation period required by PEP 387. For reference see https://github.com/python/steering-council/issues/75

[issue44863] Allow TypedDict to inherit from Generics

Guido van Rossum added the comment: Since this primarily affects static type checkers such as mypy, Pyre and pyright, it’s best to discuss it on typing-sig. -- ___ Python tracker <https://bugs.python.org/issue44

[issue44863] Allow TypedDict to inherit from Generics

Guido van Rossum added the comment: Updating an existing (standards track) PEP significantly is not traditional. I recommend writing a new PEP. On Sun, Sep 5, 2021 at 01:24 Ken Jin wrote: > > Ken Jin added the comment: > > Guido, OP has kindly written a mini PEP for this. Do yo

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: Let's wait until Mark Shannon is back from vacation (another week). Note that class docstrings *are* contained in the class body code object -- there's executable code equivalent to __doc__ = "this is the docstring" But I agree i

[issue45056] compiler: Unnecessary None in co_consts

Guido van Rossum added the comment: Since we're not changing the magic number, wheels created for rc1 will still work with the final 3.10 (and vice versa!) -- creating a wheel or PYC file just will produce a different sequence of bytes, but there are other things that do that. Then

[issue45056] compiler: Unnecessary None in co_consts

Guido van Rossum added the comment: Are you sure? I know we're really close to the release, but I'd much rather change the PYC format during the RC cycle than once we're doing bugfix releases. I don't think we've ever changed the magic number between bugfix releases

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: I am still not convinced that it's a good idea to put the docstring in the surrounding code object. I'd like to be able to see it when I introspect a code object, not just when introspecting a function object (I may be analyzing code only, and

[issue23864] doc: issubclass without registration only works for "one-trick pony" collections ABCs.

Guido van Rossum added the comment: Maybe issue45024 is also connected? (It also seems to relate to hasattr() logic.) -- ___ Python tracker <https://bugs.python.org/issue23

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

Guido van Rossum added the comment: We can add to the 3.10 docs that it is deprecated without any code change. And in 3.11 we can add a warning. -- ___ Python tracker <https://bugs.python.org/issue40

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

Guido van Rossum added the comment: How come the deprecation didn't happen in 3.10? Were people just not interested? -- ___ Python tracker <https://bugs.python.org/is

[issue44091] traceback & inspect modules should verify that the .py source file matches the one that the running process is using

Guido van Rossum added the comment: All legit cases, I agree, but are they worth the considerable work? -- ___ Python tracker <https://bugs.python.org/issue44

[issue44091] traceback & inspect modules should verify that the .py source file matches the one that the running process is using

Guido van Rossum added the comment: This sounds like a project requiring a considerable amount of plumbing to get the info from where it's available to where it's needed. For example, importlib reads the PYC file, checks the header, and then passes the rest of the file to mar

[issue39452] Improve the __main__ module documentation

Guido van Rossum added the comment: You're right, I'm being inconsistent. :-( I withdraw my objection. There are cases where sys.exit() is easier than returning an exit code, e.g. when the error is discovered deep inside some other code. But it's probably better to ra

[issue21736] Add __file__ attribute to frozen modules

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue21736> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45055] Fresh build on Windows fails the first time for zlib.c

Guido van Rossum added the comment: I've seen it a few times. I don't do this that often, but since I've discovered "git worktree" this has occurred to me a few times (can't recall if it was every time, but today wasn't the first). I'm totally

[issue45056] compiler: Unnecessary None in co_consts

Guido van Rossum added the comment: I wonder what the 3.10 compiler does different to cause this -- in 3.9 that extra None is not in co_consts. (Note: Mark is on vacation for 2 weeks.) -- nosy: +Mark.Shannon, gvanrossum ___ Python tracker <ht

[issue45055] Fresh build on Windows fails the first time for zlib.c

New submission from Guido van Rossum : When I make a fresh checkout of the main branch on Windows and type "pcbuild\build" it starts downloading some distributions (e.g. sqlite) and then starts building. Fine. But at some point there's a whole bunch of errors that seem to com

[issue45019] Freezing modules has manual steps but could be automated.

Guido van Rossum added the comment: Is this ready to close? -- ___ Python tracker <https://bugs.python.org/issue45019> ___ ___ Python-bugs-list mailin

[issue39452] Improve the __main__ module documentation

Guido van Rossum added the comment: Thanks, the rewrite is great! I have one nit: did you consider which of these two idioms is better? if __name__ == "__main__": main() vs. if __name__ == "__main__": sys.exit(main()) Your docs seem to promote the second,

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

Guido van Rossum added the comment: Thanks! This comes right in time, because we're working on freezing many more modules, and modules containing frozen sets didn't have a consistent frozen representation. Now they do! (See issue45019, issue45020) -- nosy: +

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: I think we shouldn't change *which* code object contains the docstring (changing anything about that is likely to disturb someone's workflow in a way that's hard to fix) -- only how PyFunction_New finds that docstring in the code object

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: FWIW, I'd be okay with doing the -X flag in a separate PR. -- ___ Python tracker <https://bugs.python.org/is

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: > At this point, here are the open questions I'm seeing: > + The editing-stdlib-.py-files problem: [...] > + Compatibility: [...] ? + Penalty for too many frozen modules: [...] > FWIW, I think the ideal mechanism for a dev build wil

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: [Gregory Szorc] > What do you set __file__ to? [...] Exactly. I think it should not be set, just like it's not set for builtin modules. > I have some observations about the implications of this. I typed up a long > comment but then re

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: > FWIW, I asked Ned Batchelder about this and he said this approach > ("fullcoverage" [1]) was added to support running coverage on the stdlib. > [...] The docs you pointed out in [3] (where it talks about a *horrible hack yo

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: Why all the hating on docstrings? What have docstrings done wrong? I know there's the -OO flag that strips docstrings, but it doesn't work well and I think it was a mistake. -- ___ Python track

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: Gregor, thanks for sharing your experience! I guess freezing the entire stdlib instead of just a smattering of modules (like we do here) exacerbated the problems in your case. Builtin modules (such as sys or time) don't have a __file__ attribute e

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: > I'd like to remove docstring from code object at all. > func.__doc__ can be set by MAKE_FUNCTION or STORE_ATTR. You'd just be moving the problem though -- the docstring would have be included in the co_consts array of the surrounding cod

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: > Since nobody's said so in so many words (so far in this thread anyway): the > prototype from Jeethu Rao in 2018 was a different technology than what Eric > is doing. The "Programs/_freeze_importlib.c" Eric's playing with

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: Adding Larry in case he remembers more color. (Larry: the key question here is whether some version of this (like the one I've been working on, or a simpler one that Eric has prepared) is viable, given that any time someone works on one of the froz

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: The plot thickens. By searching my extensive GMail archives for Jeethu Rao I found an email from Sept. 14 to python-dev by Larry Hastings titled "Store startup modules as C structures for 20%+ startup speed improvement?" It references an issu

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: We should ask Neil S. for the issue where Larry introduced this. That might have some discussion. But if I had to guess, it’s confusing that you can see *Python* source that you can’t edit (or rather, where editing doesn’t get reflected in the next Python

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: > The big time consumer is turning marshal'ed code objects back > into Python objects, though. If that could be made faster by > e.g. using a more efficient storage format such as one which is > platform dependent, it'd be a much bigger

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: I noticed nedbat un-nosied himself. Probably he didn't realize you were calling him out because it's possible this would affect coverage.py? -- ___ Python tracker <https://bugs.python.o

[issue45017] move opcode-related logic from modulefinder to dis

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue45017> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Guido van Rossum added the comment: So let’s add that in a separate PR. -- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue24234> ___ ___

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Guido van Rossum added the comment: What about __bytes__? -- ___ Python tracker <https://bugs.python.org/issue24234> ___ ___ Python-bugs-list mailing list Unsub

[issue44915] Python keywords as string keys in TypedDict

Guido van Rossum added the comment: Unfortunately you can’t use Python keywords in such positions and we have no plans to fix this. Serhiy’s workaround is the best you can do. -- resolution: -> wont fix stage: -> resolved status: open -&g

[issue44926] typing.get_type_hints() raises for type aliases with forward references

Guido van Rossum added the comment: New changeset 16b9be4861e007ad483611ba0479feb2b90ea783 by Maximilian Hils in branch 'main': bpo-44926: `get_type_hints`: Add note about type aliases with forward refs (#27859) https://github.com/python/cpyt

[issue44957] typing docs: Mention PEP 604 syntax more prominently

Guido van Rossum added the comment: Thanks to both of you!! -- ___ Python tracker <https://bugs.python.org/issue44957> ___ ___ Python-bugs-list mailin

[issue44957] typing docs: Mention PEP 604 syntax more prominently

Guido van Rossum added the comment: Ken, this sounds like a good idea. Can you help? -- nosy: +gvanrossum, kj ___ Python tracker <https://bugs.python.org/issue44

[issue44921] dict subclassing is slow

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue44921> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44926] typing.get_type_hints() raises for type aliases with forward references

Guido van Rossum added the comment: We could mention this in the docs for one or more of the following: - type aliases (old or new syntax) - forward references - get_type_hints() Ken Jin, can you guide Maximilian towards a successful doc update PR

<    1   2   3   4   5   6   7   8   9   10   >