[issue40663] Wrong generated annotation on subscripting

Batuhan Taskaya added the comment: $ python3.8 Python 3.8.0+ (heads/3.8:b9e5547f58, Nov 28 2019, 19:18:03) [GCC 9.2.1 20191008] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from __future__

[issue40663] Wrong generated annotation on subscripting

Change by Batuhan Taskaya : -- components: +Interpreter Core type: -> behavior versions: +Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issu

[issue40663] Wrong generated annotation on subscripting

Change by Batuhan Taskaya : -- pull_requests: +19492 pull_request: https://github.com/python/cpython/pull/20191 ___ Python tracker <https://bugs.python.org/issue40

[issue40663] Wrong generated annotation on subscripting

Change by Batuhan Taskaya : -- pull_requests: +19493 pull_request: https://github.com/python/cpython/pull/20192 ___ Python tracker <https://bugs.python.org/issue40

[issue40528] Improve / Clear ASDL generator

Change by Batuhan Taskaya : -- pull_requests: +19494 pull_request: https://github.com/python/cpython/pull/20193 ___ Python tracker <https://bugs.python.org/issue40

[issue42454] Move slice creation to the compiler for constants

Batuhan Taskaya added the comment: One thing to add, the proposed implementation also optimizes extended slices (mostly used in scientific stacks) such as [:, 1]. -- ___ Python tracker <https://bugs.python.org/issue42

[issue42454] Move slice creation to the compiler for constants

Batuhan Taskaya added the comment: > By leaving slices unhashable, and accounting for their presence in > code.__hash__, we get both the performance improvement and full backwards > compatibility. I thought about using code.__hash__ in the first place, but the compiler's un

[issue42454] Move slice creation to the compiler for constants

Batuhan Taskaya added the comment: > I have to say that I feel that this will complicate things too much. Part of > the appeal of this change is how straightforward and maintainable is. > Fiddling with code objects lowers the watermark. Agreed. And I'd go for either making s

[issue42525] Optimize class/module level annotation

Batuhan Taskaya added the comment: Would it require a substantial amount of changes? If so, I don't think this is a critical optimization since nearly-all of class definitions happens on the module level and evaluated on the import time only once. -- nosy: +BTa

[issue42525] Optimize class/module level annotation

Batuhan Taskaya added the comment: > For instance, we have such code: But what about this, what would the bytecode will look like in this case (where the annotations don't exactly follow each other?) a: int T = TypeVar('T') b: T b1: Gen[T] X = TypeVar('X') c:

[issue42525] Optimize class/module level annotation

Change by Batuhan Taskaya : -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue42525> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42116] Inspect library ignore comments at the end of a function (inspect.getsource)

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue42116> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36541] Make lib2to3 grammar better match Python, support the := walrus

Batuhan Taskaya added the comment: I don't see the point of augmenting the ast.parse, since we already have variants of proper CST implementations outside the core python. Such as github.com/davidhalter/parso/ or LibCST. Also for basic refactorings, it is so easy to use tokens fo

[issue36541] Make lib2to3 grammar better match Python, support the := walrus

Batuhan Taskaya added the comment: > Every piece of code that uses either lib2to3 or a parser derived from it > (including parso and LibCST) will eventually not be able to upgrade the > parser because PEG can handle grammars that LL(k) can't. Since these projects are external

[issue36541] Make lib2to3 grammar better match Python, support the := walrus

Batuhan Taskaya added the comment: > Parsing support for `f(**mapping)` support is indeed still missing. > > as lib2to3 is pending deprecation at this point, i'm not going to work on > this. anyone is welcome to pick it up. modifying the lib2to3 grammar, and > any rela

[issue28964] AST literal_eval exceptions provide no information about line number

Batuhan Taskaya added the comment: > Usually literal_eval() is used with short one-line input. For what large > documents do you use it? I kind of agree with Serhiy on this, nearly every use case I've encountered was simple, single-line expression. Though, by seeing Irit's p

[issue42422] Py_Decref on value crash the interpreter in Python/ceval.c:1104

Batuhan Taskaya added the comment: > I would be happy to update and fix it instead if you think it's better that > way. Please let me know, it will be great to see my first submission being > treated. Yes, please. That seems mo

[issue42561] better error reporting in ast

Change by Batuhan Taskaya : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42561> ___ ___ Python-bugs-list

[issue42561] better error reporting in ast

Batuhan Taskaya added the comment: This is a duplicate of issue 28964 -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue42561> ___ ___ Pytho

[issue42611] PEP 594

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue42611> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42609] Eval with too high string multiplication crashes newer Python versions

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue42609> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31861] add aiter() and anext() functions

Batuhan Taskaya added the comment: I don't have anything to add to this beside the name choice is safe and won't clash with anything (but honestly I would prefer it to be discussed on the ML before implementing something after 3 years). I checked a limited dataset to search for

[issue28964] AST literal_eval exceptions provide no information about line number

Batuhan Taskaya added the comment: I'm +0 on this (even though we only had 2 users wanting this, the implementation seems very trivial). @serhiy.storchaka, @pablogsal any opinions? -- keywords: +gsoc -patch nosy: +pablogsal ___ Python tr

[issue28964] AST literal_eval exceptions provide no information about line number

Change by Batuhan Taskaya : -- keywords: +patch -gsoc ___ Python tracker <https://bugs.python.org/issue28964> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42693] "if 0:" lines are traced; they didn't use to be

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue42693> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue42246> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

New submission from Batuhan Taskaya : Since the annotations are processed just like all other expressions in the symbol table, the generated entries for functions etc. This would result with def foo(): for number in range(5): foo: (yield number) return number foo

[issue41960] Add globalns and localns to the inspect.signature and inspect.Signature.from_callable

Batuhan Taskaya added the comment: > It's been a while, I've lost context for this idea. What problem are you > trying to solve here? Are there issues where people have reported problems > that this would allow them to solve? Context: https://github.com/python

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

Batuhan Taskaya added the comment: This is another side effect of processing annotations (at the symbol table construction stage) (and I would assume there are a few more cases like this); def foo(): outer_var = 1 def bar(): inner_var: outer_var = T return bar

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

Batuhan Taskaya added the comment: > So I don't feel as strongly about that. Just to note, since I believe the solution for all this might be the same (not processing annotations at all, since they will be compiled to strings in the later stage). If we go down on that route, it

[issue41960] Add globalns and localns to the inspect.signature and inspect.Signature.from_callable

Batuhan Taskaya added the comment: New changeset eee1c7745ab4eb4f75153e71aaa2a62018b7625a by Batuhan Taskaya in branch 'master': bpo-41960: Add globalns and localns parameters to inspect.signature and Signature.from_callable (GH-22583) https://github.com/python/cpyt

[issue41960] Add globalns and localns to the inspect.signature and inspect.Signature.from_callable

Change by Batuhan Taskaya : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

Batuhan Taskaya added the comment: > I propose to close that gap, and establish an API which would allow to parse > token stream (iterable) into an AST. An initial implementation for CPython > can (and likely should) be naive, making a loop thru surface program > representation

[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

Batuhan Taskaya added the comment: > That's exactly the implementation in the patch now submitted against this > issue. But that's the patch for CPython, the motive of the proposal here is > to establish a standard API call for *Python*, which different implementation

[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

Batuhan Taskaya added the comment: Thank you for your patch though! -- ___ Python tracker <https://bugs.python.org/issue42729> ___ ___ Python-bugs-list mailin

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

New submission from Batuhan Taskaya : PEP 526 classifies everything but simple, unparenthesized names (a.b, (a), a[b]) as complex targets. The way the we handle annotations for them right now is, doing literally nothing but evaluating every part of it (just pushing the name to the stack, and

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

Batuhan Taskaya added the comment: I have a patch ready to go, but I'd prefer to block this issue until issue 42737 is resolved/decided. -- ___ Python tracker <https://bugs.python.org/is

[issue28964] AST literal_eval exceptions provide no information about line number

Batuhan Taskaya added the comment: New changeset 586f3dbe15139cafb2a6ffb82cea146906561844 by Irit Katriel in branch 'master': bpo-28964: add line number of node (if available) to ast.literal_eval error messages (GH-23677) https://github.com/python/cpyt

[issue28964] AST literal_eval exceptions provide no information about line number

Change by Batuhan Taskaya : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42687] tokenize module does not recognize Barry as FLUFL

Batuhan Taskaya added the comment: I concur with Terry. -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue42687> ___ ___ Python-bugs-list m

[issue42748] test_asdl_parser: load_module() method is deprecated

New submission from Batuhan Taskaya : Running test_asdl_parser raises a deprecation warning: 0:00:26 load avg: 1.05 [ 23/426] test_asdl_parser :283: DeprecationWarning: the load_module() method is deprecated and slated for removal in Python 3.12; use exec_module() instead probably related

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

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +22799 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23952 ___ Python tracker <https://bugs.python.org/issu

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

Batuhan Taskaya added the comment: > It will still perform run-time check which was an initial intention. Well, at least from my personal perspective, I'd expect all annotations to behave like strings regardless of their targets. -- __

[issue42748] test_asdl_parser: load_module() method is deprecated

Batuhan Taskaya added the comment: New changeset 0b281f94b9e5f117d774a1e4e834e797b2b21438 by Dong-hee Na in branch 'master': bpo-42748: test_asdl_parser now uses exec_module instead of load_module (#23954) https://github.com/python/cpython/commit/0b281f94b9e5f117d774a1e4e834e7

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

Batuhan Taskaya added the comment: One thing to note here, currently Pablo and I are trying to bring annotation unparsing from the compiler to the parser in issue 41967. If we do so, the annotations won't cause any side effects on the symbol table generation. -- nosy: +pabl

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

Batuhan Taskaya added the comment: > Do we still need to represent annotation as a subtree in AST? Or make it just > a string? Possibly, we will just represent them as Constant()s. See issue 41967 -- ___ Python tracker <https://bugs.p

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

Batuhan Taskaya added the comment: I think we should still evaluate the targets (even though the sole purpose of this is just having a hint, the yield example seems serious), will update my patch accordingly. -- ___ Python tracker <ht

[issue42754] Unpacking of literals inside other literals should be optimised away by the compiler

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue42754> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42754] Unpacking of literals inside other literals should be optimised away by the compiler

Batuhan Taskaya added the comment: We could possibly fold this at the AST optimizer, though I am not sure whether this worths anything as an optimization since it is a real obscure pattern. I've only found 2 occurrences (both from a test set on a relatively ~big dataset of source

[issue42754] Unpacking of literals inside other literals should be optimised away by the compiler

Change by Batuhan Taskaya : -- Removed message: https://bugs.python.org/msg383911 ___ Python tracker <https://bugs.python.org/issue42754> ___ ___ Python-bug

[issue42754] Unpacking of literals inside other literals should be optimised away by the compiler

Batuhan Taskaya added the comment: We could possibly fold this at the AST optimizer, though I am not sure whether this worths anything as an optimization since it is a real obscure pattern. I've only found 2 occurrences (both from the test suite of black) on a relatively ~big datas

[issue42454] Move slice creation to the compiler for constants

Batuhan Taskaya added the comment: I've given this another shot, but even though I was able to create a patch that preserved slices as (type(slice), start, stop, step) tuples in the consts_cache, this final optimization prevented me to finalize it; 😃https://github.com/python/cpython

[issue42455] Add decorator_factory function to functools module

Batuhan Taskaya added the comment: I also agree with Raymond's opinion, and from the point that it didn't get much attention I'd assume not many people need it. So count me as -1 -- nosy: +BTaskaya ___ Python tracker <https

[issue42837] Symbol table incorrectly identifies code as a generator, when 'yield' occurs in an annotation

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue42837> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42837] Symbol table incorrectly identifies code as a generator, when 'yield' occurs in an annotation

Batuhan Taskaya added the comment: Well even though I still don't understand 'how this issue is different than issue42725', I don't think you actually fix the symbol table; see this one: https://bugs.python.org/msg383659 Annotations still have side effects on the symbo

[issue42920] How to add end_lineno in pyclbr?

Batuhan Taskaya added the comment: It is actually much easier now, considering that we are operating on the AST instead of the token stream. You probably only have to add a new field to Function/Class classes for end_lineno and access .end_lineno attribute here just like how we do for

[issue42927] Inline cache for slots

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue42927> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Batuhan Taskaya added the comment: > The use of nonlocal variables in an annotation will be a syntax error in > Python 3.10 What is the reasoning for forbidding nonlocal variables (https://bugs.python.org/msg383659), can't we just treat them like regular variables and leave t

[issue40176] unterminated string literal tokenization error messages could be better

Change by Batuhan Taskaya : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.10 -Python 3.9 ___ Python tracker <https://bugs.python.or

[issue43014] tokenize spends a lot of time in `re.compile(...)`

Batuhan Taskaya added the comment: New changeset 15bd9efd01e44087664e78bf766865a6d2e06626 by Anthony Sottile in branch 'master': bpo-43014: Improve performance of tokenize.tokenize by 20-30% https://github.com/python/cpython/commit/15bd9efd01e44087664e78bf766865a6d2e06626 -

[issue43014] tokenize spends a lot of time in `re.compile(...)`

Change by Batuhan Taskaya : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42128] Structural Pattern Matching (PEP 634)

Batuhan Taskaya added the comment: > @BTaskaya, do you think you'll have time to open a PR with your AST validator > this weekend? It looks good to me (assuming tests pass). Unfortunately not. I believe it still lacks tests for invalid cases, but other than that should work. If

[issue42128] Structural Pattern Matching (PEP 634)

Change by Batuhan Taskaya : -- pull_requests: +23539 pull_request: https://github.com/python/cpython/pull/24771 ___ Python tracker <https://bugs.python.org/issue42

[issue43417] ast.unparse: Simplify buffering logic

New submission from Batuhan Taskaya : Currently, buffer is just an instance-level list that is used in various places to avoid directly writing stuff into the real source buffer, though the design is pretty complicated and hard to use. There are various use cases (like omitting the empty

[issue43417] ast.unparse: Simplify buffering logic

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +23540 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24772 ___ Python tracker <https://bugs.python.org/issu

[issue40680] thread_cputime isn't supported by AIX5

Batuhan Taskaya added the comment: Does AIX 5.3 officially supported by IBM? As far as I can locate, it is deprecated long time ago. -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue40

[issue40680] thread_cputime isn't supported by AIX5

Batuhan Taskaya added the comment: My source: https://www.ibm.com/support/pages/aix-support-lifecycle-information -- ___ Python tracker <https://bugs.python.org/issue40

[issue40681] shelve.open() should accept pathlib.Path

Batuhan Taskaya added the comment: Duplicate of bpo-40563 -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue40681> ___ ___ Python-bugs-list m

[issue38870] Expose ast.unparse in the ast module

Change by Batuhan Taskaya : -- pull_requests: +19528 pull_request: https://github.com/python/cpython/pull/20240 ___ Python tracker <https://bugs.python.org/issue38

[issue40697] add fissix as a lib2to3 alternative

Batuhan Taskaya added the comment: Does / Will this project actively maintained? From what I can tell from the numerical stats (such as commit dates and star counts), it is not very much used and I'm afraid it doesn't look very active. -- nosy: +BTaskaya,

[issue40696] "await" hangs in Python3.9.0b1.

Batuhan Taskaya added the comment: > Is this a separate bug? So maybe the issue is that the new code is letting > things get into this state. Some of my changes added new chaining in various > places, so that would fit (but still investigating). Looks like there isn't a recu

[issue40715] Pegen: dict unpacking inside dict comprehension

New submission from Batuhan Taskaya : >>> {**{} for a in [1]} ValueError: field 'key' is required for DictComp should be >>> {**{} for a in [1]} File "", line 1 {**{} for a in [1]} ^ SyntaxError: dict unpacking cannot be used in dict comprehen

[issue40715] Pegen: dict unpacking inside dict comprehension

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +19567 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20292 ___ Python tracker <https://bugs.python.org/issu

[issue40716] Pegen: improve error messages for unparenthesized from imports with trailing comma

New submission from Batuhan Taskaya : $ python Python 3.10.0a0 (heads/bpo-x:f2947e354c, May 21 2020, 18:54:57) [GCC 9.2.1 20191008] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from

[issue40176] unterminated string literal tokenization error messages could be better

Change by Batuhan Taskaya : -- pull_requests: +19569 pull_request: https://github.com/python/cpython/pull/20294 ___ Python tracker <https://bugs.python.org/issue40

[issue40716] Pegen: improve error messages for unparenthesized from imports with trailing comma

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +19570 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20294 ___ Python tracker <https://bugs.python.org/issu

[issue40176] unterminated string literal tokenization error messages could be better

Change by Batuhan Taskaya : -- pull_requests: -19569 ___ Python tracker <https://bugs.python.org/issue40176> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40334] PEP 617: new PEG-based parser

Change by Batuhan Taskaya : -- pull_requests: +19571 pull_request: https://github.com/python/cpython/pull/20296 ___ Python tracker <https://bugs.python.org/issue40

[issue40726] ast.Call end_lineno is defined and returns None

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue40726> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40726] ast.Call end_lineno is defined and returns None

Batuhan Taskaya added the comment: This is because the 'end_lineno' and 'end_col_offset' are declared as optional attributes in the ASDL spec. The commit 'b7e9525f9c7ef02a1d2ad8253afdeb733b0951d4' made all optional fields and attrib

[issue40726] ast.Call end_lineno is defined and returns None

Batuhan Taskaya added the comment: See here for the complete spec: https://docs.python.org/3.9/library/ast.html#abstract-grammar -- ___ Python tracker <https://bugs.python.org/issue40

[issue40726] ast.Call end_lineno is defined and returns None

Change by Batuhan Taskaya : -- nosy: +serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue40726> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40726] ast.Call end_lineno is defined and returns None

Change by Batuhan Taskaya : -- keywords: +patch nosy: +BTaskaya nosy_count: 5.0 -> 6.0 pull_requests: +19581 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20312 ___ Python tracker <https://bugs.python.org/i

[issue40726] ast.Call end_lineno is defined and returns None

Batuhan Taskaya added the comment: > If nobody works on this I will send a PR to update the rest of AST later > today. :/ I'm terribly sorry for that, I just sent a PR without refreshing the tab. -- ___ Python tracker <https://b

[issue40729] Update the list of auto-generated files in .gitattributes

Change by Batuhan Taskaya : -- nosy: BTaskaya priority: normal severity: normal status: open title: Update the list of auto-generated files in .gitattributes ___ Python tracker <https://bugs.python.org/issue40

[issue40729] Update the list of auto-generated files in .gitattributes

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +19583 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20314 ___ Python tracker <https://bugs.python.org/issu

[issue40726] ast.Call end_lineno is defined and returns None

Batuhan Taskaya added the comment: > setting them to None is going to break a lot of those, if possible I'd > suggest going back to when they were missing 'lineno' and 'col_offset' will never be none, since both are declared as normal integers. But on t

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +19624 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20360 ___ Python tracker <https://bugs.python.org/issu

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- pull_requests: -19624 ___ Python tracker <https://bugs.python.org/issue40344> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- pull_requests: +19625 pull_request: https://github.com/python/cpython/pull/20360 ___ Python tracker <https://bugs.python.org/issue40

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- pull_requests: -19625 ___ Python tracker <https://bugs.python.org/issue40344> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40759] Deprecate the symbol module

New submission from Batuhan Taskaya : Parser is deprecated so there is no need for the 'symbol' module. I think this should be backported to 3.9, so I'm CC-ing @Łukasz. -- components: Library (Lib) messages: 369826 nosy: BTaskaya, lukasz.langa priority: normal severity

[issue40759] Deprecate the symbol module

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +19628 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20364 ___ Python tracker <https://bugs.python.org/issu

[issue40334] PEP 617: new PEG-based parser

Change by Batuhan Taskaya : -- pull_requests: +19631 pull_request: https://github.com/python/cpython/pull/20367 ___ Python tracker <https://bugs.python.org/issue40

[issue40769] Pegen: cover extra surrounding parentheses for invalid annotated assignment

Change by Batuhan Taskaya : -- versions: +Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40769> ___ ___ Python-bugs-list mailin

[issue40769] Pegen: cover extra surrounding parentheses for invalid annotated assignment

New submission from Batuhan Taskaya : $ python -X oldparser Python 3.10.0a0 (heads/bpo-x:f2947e354c, May 21 2020, 18:54:57) [GCC 9.2.1 20191008] on linux Type "help", "copyright", "credits" or "license" for more information. >>> (()): int

[issue40769] Pegen: cover extra surrounding parentheses for invalid annotated assignment

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +19650 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20387 ___ Python tracker <https://bugs.python.org/issu

[issue40769] Pegen: cover extra surrounding parentheses for invalid annotated assignment

Change by Batuhan Taskaya : -- nosy: +gvanrossum, lys.nikolaou, pablogsal ___ Python tracker <https://bugs.python.org/issue40769> ___ ___ Python-bugs-list mailin

[issue40779] incorrect end column for single argument generator function call AST

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue40779> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40779] incorrect end column for single argument generator function call AST

Batuhan Taskaya added the comment: What version are you using, 3.8? -- ___ Python tracker <https://bugs.python.org/issue40779> ___ ___ Python-bugs-list mailin

<    1   2   3   4   5   6   7   >