[issue43463] typing.get_type_hints with TYPE_CHECKING imports / getting hints for single argument

Guido van Rossum added the comment: Hey Larry, it would seem that PEP 649 as currently specified would make it impossible to access annotations via the inspect module in cases where x.__annotations__ raises (because one of the annotations references an undefined variable). I really think

[issue43817] Add typing.get_annotations()

Guido van Rossum added the comment: Also, for crosslinking, see issue43463. -- ___ Python tracker <https://bugs.python.org/issue43817> ___ ___ Python-bugs-list m

[issue43817] Add typing.get_annotations()

Guido van Rossum added the comment: Putting it in inspect makes sense then. -- ___ Python tracker <https://bugs.python.org/issue43817> ___ ___ Python-bugs-list m

[issue43463] typing.get_type_hints with TYPE_CHECKING imports / getting hints for single argument

Guido van Rossum added the comment: If the NameError were to leave behind a marker wrapping the string, that might allow the best of both worlds -- errors don't pass *silently* (an error value is returned) and you can still inspect the other annota

[issue43463] typing.get_type_hints with TYPE_CHECKING imports / getting hints for single argument

Guido van Rossum added the comment: I thought Jelle’s solution would avoid code bloat — a dedicated opcode. It can do whatever is decided. -- nosy: +Guido.van.Rossum ___ Python tracker <https://bugs.python.org/issue43

[issue43837] Operator precedence documentation could be more clear

Guido van Rossum added the comment: I defer to Raymond on this. Honestly without looking at the website I don’t even recall whether “higher precedence” means “binds more tightly” or the opposite. :-) So maybe we should change the terminology while we’re at it. -- nosy

[issue41559] Add support for PEP 612 (Parameter Specification Variables) to typing.py

Guido van Rossum added the comment: Yeah, like this idea. Let’s get this in before beta 1. -- nosy: +Guido.van.Rossum ___ Python tracker <https://bugs.python.org/issue41

[issue38908] Troubles with @runtime_checkable protocols

Guido van Rossum added the comment: Hi Kevin, If you want to work on this, could you come up with some test cases that try to explore edge cases for this behavior? Ideally some that already pass, and some that currently don't pass (because of the limitation mentioned by Ivan). It'

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Guido van Rossum added the comment: Actually I believe a real case was reported on python-dev. I think it is not clean that the boundary between numbers and identifiers is so fluid. -- nosy: +Guido.van.Rossum ___ Python tracker <ht

[issue43892] Make match patterns explicit in the AST

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

[issue43892] Make match patterns explicit in the AST

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

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

Guido van Rossum added the comment: So the question is, whether anyone actually writes `x: ' str'`. Does the fix satisfy a real need? If it does, why don't we change compile(x, ..., 'eval') as you suggested in your second comment? -- _

[issue40222] "Zero cost" exception handling

Guido van Rossum added the comment: I like Serhiy’s idea. BTW, what are the three POP_TOP op codes in a row popping? -- nosy: +Guido.van.Rossum ___ Python tracker <https://bugs.python.org/issue40

[issue43908] array.array should remain immutable

New submission from Guido van Rossum : Hi Victor, Sorry for making this a deferred blocker. I recall that we had a brief discussion somewhere about an accidental change to the array.array type -- this is now a heap type (Py_TPFLAGS_HEAPTYPE is set), and as a consequence it is no longer

[issue43908] array.array should remain immutable

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

[issue43901] Add an empty annotations dict to all unannotated classes and modules

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

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Guido van Rossum added the comment: Sounds like a plan, I agree that the original design misfired here (we were probably worried about million-line code bases with tens of thousands of classes having to pay the price of tens of thousands of empty dicts, but I now think that was an

[issue42737] PEP 563: drop annotations for complex assign targets

Guido van Rossum added the comment: Hum, there seems to be an actual bug here: even with PEP 563, the annotations for "complex targets" are evaluated. For example: from __future__ import annotations class C: x.y: z.w a: b.c The relevant parts of the disassembly of the co

[issue42737] PEP 563: drop annotations for complex assign targets

Guido van Rossum added the comment: The same thing happens at the module level. However in functions all is well (because inside functions annotations are never evaluated, apparently). It may be as simple as the code forgetting to check the PEP 563 bit when generating code for complex

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Guido van Rossum added the comment: I’d say that best practices for 3.9+ are more useful. There seem to be several contradictions in your remarks, but we’ll get to those in the review. -- nosy: +Guido.van.Rossum ___ Python tracker <ht

[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default in Python 3.11

Guido van Rossum added the comment: I haven't followed this precisely, but I recall that when we first made PEP 563 the default, we had to fix a number of bugs in various library modules (e.g. inspect) that were only apparent when `from __future__ import annotations` was used. I hope

[issue43908] array.array should remain immutable

Guido van Rossum added the comment: Is there going to be a separate PR to actually *set* the IMMUTABLE flag on all built-in type objects? There are many of those. -- ___ Python tracker <https://bugs.python.org/issue43

[issue42725] PEP 563: Should the behavior change for yield/yield from's

Guido van Rossum added the comment: So shouldn't we just rule out some specific bits of syntax in annotations? That can be done after the PEG grammar has accepted them, otherwise we'd end up having a whole new expression-like grammar section that excludes them. I think this is t

[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default in Python 3.11

Guido van Rossum added the comment: I don't like adding a flag. In the PEP-563-by-default world we didn't need a flag. Perhaps once Larry implements inspect.get_annotations() (issue43817) we can make inspect.signature() always

[issue43908] array.array should remain immutable

Guido van Rossum added the comment: Does the test suite pass for apply-to-all.diff? Also, quite a hornet's nest you've uncovered (about __class__ assignment). Would that be fixed better with the IMMUTABLE flag? -- ___ Python track

[issue42725] PEP 563: Should the behavior change for yield/yield from's

Guido van Rossum added the comment: I don’t really care how you do it, I just thought having a whole “expr-without-walrus-or-yield” subgrammar would be tedious. If there is a way to have the “in-an-annotation” flag set during parsing that may be better, I don’t know. Maybe Lysandros has an

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Guido van Rossum added the comment: And that’s a problem. There needs to be a recommendation on what to do for code that spans 3.9 and 3.10. What should users do otherwise? Drop 3.9 as soon as they introduce 3.10 support? Withhold 3.10 support until 3.9 reaches EOL? IOW you can’t just break

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Guido van Rossum added the comment: Functions don't store __annotations__ in their __dict__, it is a separate slot named func_annotations (see funcobject.c). I guess that's because the __dict__ is purely for user-defined function attributes. But perhaps for classes the C equivale

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Guido van Rossum added the comment: So, honestly I don't understand what your concern with the lazy approach is. Was your design based on having a bit in the class/module object (outside its __dict__) saying "I already lazily created one"? Or am I missing something? Also, I&#

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Guido van Rossum added the comment: I think "no user-visible changes" is a pipe dream. Deleting __annotations__ seems fairly pointless so I don't mind changes that are only visible when you do that. -- ___ Python tracker <https

[issue43908] array.array should remain immutable

Guido van Rossum added the comment: My main concern is that types that were immutable in previous Python versions shouldn't become mutable as a surprise side effect of making them heap types. I don't know which types have become mutable this way though. My other concern is that th

[issue43908] array.array should remain immutable

Guido van Rossum added the comment: Let's post the list here and post a brief mention of this issue on python-dev. -- ___ Python tracker <https://bugs.python.org/is

[issue43817] Add inspect.get_annotations()

Guido van Rossum added the comment: I'm not a big user of the inspect module, but I always thought that its use was so that you could look at a function (or other object) *produced by a 3rd party* and learn something about it. Asking for the signature is one such operation, and I

[issue43933] Regression in python3.10 with traceback frame having lineno of -1

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

[issue43908] array.array should remain immutable

Guido van Rossum added the comment: > > Could you please land the new flag and typeobject.c code now? > > I've only got two more questions before I mark it ready for review, > and that's regarding Guido's comment in msg391756: > Should the new flag also take c

[issue42904] get_type_hints does not provide localns for classes

Guido van Rossum added the comment: New changeset 1b1f9852bda85c01ef124858f293e9c13e04ffce by Ken Jin in branch 'master': bpo-42904: Change search order of typing.get_type_hints eval (#25632) https://github.com/python/cpython/commit/1b1f9852bda85c01ef124858f293e9

[issue43908] array.array should remain immutable

Guido van Rossum added the comment: PS. Don't wait for me. I'm going on vacation this Thursday and won't be back until well after the 3.10b1 release is done, and before I go I'm pretty busy already. -- ___ Python tracker <

[issue43908] array.array should remain immutable

Guido van Rossum added the comment: The solution would be bisection -- apply half of the changes from apply-to-all, and see if you still get the errors. Etc. -- ___ Python tracker <https://bugs.python.org/issue43

[issue43817] Add inspect.get_annotations()

Guido van Rossum added the comment: There may be a (deliberate? :-) misunderstanding. When I wrote about "you" inspecting code by a "3rd party" I meant that as a symmetric relationship -- the "you" could be a library and from the library's POV the "3

[issue43908] array.array should remain immutable

Guido van Rossum added the comment: So keep cutting in half until the error disappears? -- ___ Python tracker <https://bugs.python.org/issue43908> ___ ___ Pytho

[issue43817] Add inspect.get_annotations()

Guido van Rossum added the comment: I want to be as short as possible. The user may have annotations because they are using mypy. They may be using a library that calls inspect.signature() on some of their functions to retrieve the parameter names conveniently. All this has worked for years

[issue43817] Add inspect.get_annotations()

Guido van Rossum added the comment: No, I want the *default* not to raise when eval() fails. -- ___ Python tracker <https://bugs.python.org/issue43817> ___ ___

[issue43908] array.array should remain immutable

Guido van Rossum added the comment: Pablo, there seems to be some instability in the tests. Shreyan, Erlend, maybe merging in master would help? -- nosy: +Guido.van.Rossum ___ Python tracker <https://bugs.python.org/issue43

[issue43766] Implement PEP 647 (User-Defined Type Guards) in typing.py

Guido van Rossum added the comment: New changeset 05ab4b60ab3dae61ee75692b6624537d4f3fdf85 by Ken Jin in branch 'master': bpo-43766: Implement PEP 647 (User-Defined Type Guards) in typing.py (#25282) https://github.com/python/cpython/commit/05ab4b60ab3dae61ee75692b662453

[issue43908] array.array should remain immutable

Guido van Rossum added the comment: Sure. What do you think is causing the failures for Shreyan then? (Are you two collaborating?) -- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue43

[issue43766] Implement PEP 647 (User-Defined Type Guards) in typing.py

Guido van Rossum added the comment: New changeset 99fdd782007db86f20aeb302b2ceaf79ce1ae2ba by Ken Jin in branch 'master': bpo-43766: Fix TypeGuard docs (#25660) https://github.com/python/cpython/commit/99fdd782007db86f20aeb302b2ceaf

[issue43908] array.array should remain immutable

Guido van Rossum added the comment: I don't think I've ever successfully managed to complete the test on my Windows 10 box either (not even in "production" mode -- you seem to be using debug mode). I recommend using creating a new PR and having the CI machinery run

[issue43955] Test Failures on Windows 10

Guido van Rossum added the comment: I wonder if these four tests do something that affects all threads? The test driver module runs tests in parallel (if you ask it to run all or most tests, like the default). -- ___ Python tracker <ht

[issue43955] Test Failures on Windows 10

Guido van Rossum added the comment: Can you submit a PR that fixes it? -- ___ Python tracker <https://bugs.python.org/issue43955> ___ ___ Python-bugs-list mailin

[issue43955] Test Failures on Windows 10

Guido van Rossum added the comment: Yes, I also see that pdb prompt. I recommend looking at what different configurations are used by test.libregrtest.main() when no tests are passed on the command line. -- ___ Python tracker <ht

[issue43955] Test Failures on Windows 10

Guido van Rossum added the comment: Doesn't the pdb prompt use the builtin input()? -- ___ Python tracker <https://bugs.python.org/issue43955> ___ ___ Pytho

[issue41559] Add support for PEP 612 (Parameter Specification Variables) to typing.py

Guido van Rossum added the comment: New changeset 859577c24981d6b36960d309f99f7fc810fe75c2 by Ken Jin in branch 'master': bpo-41559: Change PEP 612 implementation to pure Python (#25449) https://github.com/python/cpython/commit/859577c24981d6b36960d309f99f7f

[issue37387] test_compileall fails randomly on Windows when tests are run in parallel

Guido van Rossum added the comment: Well, in the normal course of running multiple Python programs on the same machine, pyc files may be rewritten, and this should not cause crashes. So perhaps there’s a real bug here? -- nosy: +Guido.van.Rossum

[issue41559] Add support for PEP 612 (Parameter Specification Variables) to typing.py

Guido van Rossum added the comment: Thanks for your major contribution, Ken! Agreed, that bugfix can come later. -- ___ Python tracker <https://bugs.python.org/issue41

[issue43908] array.array and re types must be immutable: add Py_TPFLAGS_IMMUTABLETYPE flag

Guido van Rossum added the comment: That is as intended, right? On Thu, Apr 29, 2021 at 07:59 STINNER Victor wrote: > > STINNER Victor added the comment: > > check_set_special_type_attr() is used to prevent setting the following > attributes: > > * __name__ > * __q

[issue43908] array.array should remain immutable: add Py_TPFLAGS_IMMUTABLETYPE flag

Guido van Rossum added the comment: I don’t think we’re waiting for more crazy hacks. On Thu, Apr 29, 2021 at 07:27 STINNER Victor wrote: > > STINNER Victor added the comment: > > > > https://discuss.python.org/t/list-of-built-in-types-converted-to-heap-types/8403 >

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Guido van Rossum added the comment: I'm -0.5 on reusing Name(ctx=Store). The reason we're using that in assignments is that in the past (before the PEG parser) the parser literally used the same grammar for the LHS and RHS of assignments, and a second pass was used to rule o

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Guido van Rossum added the comment: Honestly if someone manages to get a PR in I won’t be a spoilsport. So make me +0.-- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue43

[issue37903] IDLE Shell sidebar.

Guido van Rossum added the comment: Also, presumably most users don’t right click and look for options. They just drag a selection and hit ^C (or cmd-C).-- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue37

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

Guido van Rossum added the comment: Moving the needle on the pyperformance benchmarks is really hard! -- ___ Python tracker <https://bugs.python.org/issue42

[issue44098] Remove ParamSpec from __parameters__ of most typing generics

Guido van Rossum added the comment: New changeset c55ff1b352f8b82184f80d9dea220e832691acfc by Miss Islington (bot) in branch '3.10': bpo-44098: Drop ParamSpec from most ``__parameters__`` in typing generics (GH-26013) (#26091) https://github.com/python/cpyt

[issue38291] Deprecate the typing.io and typing.re pseudo-modules

Guido van Rossum added the comment: I agree, these namespaces were a mistake. Let's start deprecating them (and remove their mention from the docs again). -- versions: -Python 3.10 ___ Python tracker <https://bugs.python.org/is

[issue42109] Use hypothesis for testing the standard library, falling back to stubs

Guido van Rossum added the comment: I would like to have a more thorough discussion about the desirability of using Hypothesis first, since I feel that there is a rather hard "sell" going on. I brought this up in the SC tracker (https://github.com/python/steering-council/issues

[issue42109] Use hypothesis for testing the standard library, falling back to stubs

Guido van Rossum added the comment: Thanks, I will look into that before stirring up more dust. -- nosy: +Guido.van.Rossum ___ Python tracker <https://bugs.python.org/issue42

[issue40452] Tkinter/IDLE: preserve clipboard on closure

Guido van Rossum added the comment: I don't recall anything about that, sorry. -- ___ Python tracker <https://bugs.python.org/issue40452> ___ ___ Pytho

[issue40452] Tkinter/IDLE: preserve clipboard on closure

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

[issue42109] Use hypothesis for testing the standard library, falling back to stubs

Guido van Rossum added the comment: Okay, well, I'm trying to understand minithesis.py, but I am despairing. The shrinking code (really everything in class TestingState) is too much to grok. You can tell from the amount of comments that this is the tour-de-force of the code, bu

[issue42109] Use hypothesis for testing the standard library, falling back to stubs

Guido van Rossum added the comment: Few things incite me quite as much as being told that I'm not supposed to understand something, so now I'm actually making an effort to follow the ECOOP paper. Honestly, it's not too bad (a lot more readable than type theory papers :-). I

[issue42109] Use hypothesis for testing the standard library, falling back to stubs

Guido van Rossum added the comment: It is important to me, because I don't like having a dependency on third-party code that is a black box. Remember that in the end it's not me you have to convince but the SC. -- ___ Python track

[issue44201] REPL requests another line despite syntax error

New submission from Guido van Rossum : This seems a regression from 3.9. >>> foo[x = 1 ... ] File "", line 1 foo[x = 1 ^ SyntaxError: invalid syntax. Maybe you meant '==' or ':=' instead of '='? >>> Note how the synt

[issue44201] REPL requests another line despite syntax error

Change by Guido van Rossum : -- nosy: +lys.nikolaou, pablogsal ___ Python tracker <https://bugs.python.org/issue44201> ___ ___ Python-bugs-list mailing list Unsub

[issue44201] REPL requests another line despite syntax error

Change by Guido van Rossum : -- keywords: +3.10regression ___ Python tracker <https://bugs.python.org/issue44201> ___ ___ Python-bugs-list mailing list Unsub

[issue44201] REPL requests another line despite syntax error

Guido van Rossum added the comment: Could we implement something in the REPL where it refuses to read another line when asked for a token in an error recovery rule? -- ___ Python tracker <https://bugs.python.org/issue44

[issue42109] Use hypothesis for testing the standard library, falling back to stubs

Guido van Rossum added the comment: Having read the parts of the paper that explain shortening, things are making more sense now. I have also successfully contributed type annotations to minithesis! :-) -- ___ Python tracker <ht

[issue44218] Possible Stack Based Buffer Overflow at Programs/_freeze_importlib.c

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

[issue40222] "Zero cost" exception handling

Guido van Rossum added the comment: I think we're waiting here for the release manager to decide, right? Should we roll back the change to PyCode_NewWithPosOnlyArgs() or keep it? Presumably the requested docs aren't the (beta) relea

[issue40222] "Zero cost" exception handling

Guido van Rossum added the comment: Ah, okay. So we're not on the hook to decide this today. :-) -- ___ Python tracker <https://bugs.python.org/is

[issue42109] Use hypothesis for testing the standard library, falling back to stubs

Guido van Rossum added the comment: I withdraw my objection against Hypothetlsis per se. Others should debate whether the 3rd party dependency is okay. -- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue42

[issue43693] Logically merge cell and locals array. They are already contiguous in memory

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

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

Guido van Rossum added the comment: Also at this point it's too late to get this into 3.10 (given that we're still debating this it's clearly not a simple bugfix). -- ___ Python tracker <https://bugs.pyt

[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules

Guido van Rossum added the comment: > What is/was the initial reason to not preserve the MRO for a TypedDict? Hm, I can't say for sure. I believe it had something to do with TypedDict instances being instances of dict at runtime, but I can't actually reconstruct the reaso

[issue44293] PEP 585 breaks inspect.isclass

Guido van Rossum added the comment: Since these are new forms (list[int] previously was an error), does it actually matter? Especially since these are primarily used in annotations. @Joseph Perez, is there a specific library or pattern that is broken by this? FWIW I did think rather

[issue44293] PEP 585 breaks inspect.isclass

Guido van Rossum added the comment: Instead of introspecting types, use this library: https://github.com/ilevkivskyi/typing_inspect -- ___ Python tracker <https://bugs.python.org/issue44

[issue16970] argparse: bad nargs value raises misleading message

Guido van Rossum added the comment: Okay, I trust that this can be closed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue44367] Python Code for WebView2 Exe Testing

Guido van Rossum added the comment: Sorry, this tracker is not for getting help, only for submitting changes to Python itself. Try https://discuss.python.org/c/users/7 instead. -- resolution: -> rejected stage: -> resolved status: open -&g

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

Guido van Rossum added the comment: Yeah, the more I think about it, the more it looks like we should add the special methods -- even if they won't necessarily be called *if the type is exactly 'complex' or 'bytes'*. Now, until we've written and released t

[issue44396] pegen _PyParser_ASTFromFile(): Use-After-Free in syntaxerror()

Guido van Rossum added the comment: Lysandros and Pablo, this *only* occurs when the lexer is reading directly from a file, not when it's reading the same source code from a (bytes) string. All examples are syntax errors (some raise ValueError in the p

[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Updated to vendoed copy to expat 2.4.1

Guido van Rossum added the comment: (From PSRT list, Sebastian:) Please note that the vulnerability fix also added two new functions to the API that would be great to have xml.parsers.expat expose to the users for full control. These are

[issue35089] Remove typing.io and typing.re from documentation

Guido van Rossum added the comment: New changeset 8a76683cfb842e12b57f6d276839f6c68fd94e1a by Sebastian Rittau in branch 'main': bpo-38291: Remove mention of typing.io and typing.re again (GH-26113) https://github.com/python/cpython/commit/8a76683cfb842e12b57f6d276839f6

[issue38291] Deprecate the typing.io and typing.re pseudo-modules

Guido van Rossum added the comment: New changeset 8a76683cfb842e12b57f6d276839f6c68fd94e1a by Sebastian Rittau in branch 'main': bpo-38291: Remove mention of typing.io and typing.re again (GH-26113) https://github.com/python/cpython/commit/8a76683cfb842e12b57f6d276839f6

[issue44392] Py_GenericAlias is not documented

Guido van Rossum added the comment: Hm, maybe it was a mistake to expose this? Remind me what use is made of this from C code? Can we remove this from the stable API during beta? It was never exposed before. -- nosy: +Guido.van.Rossum ___ Python

[issue44392] Py_GenericAlias is not documented

Guido van Rossum added the comment: Hm, but is that what they are doing? I assume that they use stub files, since static type checkers don’t introspect the runtime API. -- ___ Python tracker <https://bugs.python.org/issue44

[issue44392] Py_GenericAlias is not documented

Guido van Rossum added the comment: Maybe the docs then should contain a more-or-less complete example showing how a 3rd party type should use this? -- ___ Python tracker <https://bugs.python.org/issue44

[issue43693] Logically merge cell and locals array. They are already contiguous in memory

Change by Guido van Rossum : -- pull_requests: +25334 pull_request: https://github.com/python/cpython/pull/26749 ___ Python tracker <https://bugs.python.org/issue43

[issue44392] Py_GenericAlias is not documented

Guido van Rossum added the comment: New changeset 6773c3eaa735b5061b4a97f2c730703a32d8c9ff by Ken Jin in branch 'main': bpo-44392: Add Py_GenericAlias to C API docs (GH-26724) https://github.com/python/cpython/commit/6773c3eaa735b5061b4a97f2c73070

[issue44392] Py_GenericAlias is not documented

Guido van Rossum added the comment: Does it need a backport to 3.9 too, since GenericAlias was introduced there? -- ___ Python tracker <https://bugs.python.org/issue44

[issue20115] NUL bytes in commented lines

Guido van Rossum added the comment: Yeah, null bytes should just be rejected. If someone comes up with a fix for this we'll accept it. -- ___ Python tracker <https://bugs.python.org/is

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: > "The one exception is in function calls with *expression after a keyword > argument: f(x=expr2, *expr1)." So the question before us is whether to add this phrase to the docs, or to tweak the compiler to fix it. It is certainly convenie

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: Well, it seems we're stuck -- we can't make the grammar more restrictive (at least, I don't think we should, since it is a backwards incompatibility), so we'll have to live with the exception. Since it is now clear what the rule is, we

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: Looks like Terry accidentally removed Serhiy. Adding him back. -- nosy: +Guido.van.Rossum, serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue23

<    15   16   17   18   19   20   21   22   23   24   >