[issue11105] Compiling recursive Python ASTs crash the interpreter

Change by Batuhan Taskaya : -- components: +Interpreter Core -None priority: low -> normal title: Compiling evil ast crashes interpreter -> Compiling recursive Python ASTs crash the interpreter versions: +Python 3.11, Python 3.9 ___ Python t

[issue44278] Improve syntax error message for assigning to "..."

Batuhan Taskaya added the comment: I think this is a duplicate of issue 44273. -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue44

[issue44273] Assigning to Ellipsis should be the same as assigning to __debug__

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

[issue44194] Folding ''.join() into f-strings

Batuhan Taskaya added the comment: > 1. It can be a str subclass with an overridden __format__. In this case the > result will be different. Thanks! Though this should be possible to do, so not a blocker for suggestion (if I am not missing something) > 2. If it is a str subclas

[issue44207] Add a version number to Python functions

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

[issue44194] Folding ''.join() into f-strings

Batuhan Taskaya added the comment: > We should check on a real-world benchmark instead of a micro benchmark. It is a pretty-targeted optimization, so I don't expect it to speed up the macro benchmarks. Though that shouldn't be a blocker for small, targeted optimizati

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

Batuhan Taskaya added the comment: > May I ask, is this going forward? I installed 3.11-dev, it's not there > (though __future__ claims it should be). I understand if it isn't done yet, > just want to know if there's risk it will be postponed again (or even given > up).

[issue44194] Folding ''.join() into f-strings

New submission from Batuhan Taskaya : Since strings are immutable types, we could fold some operation on top of them. Serhiy has done some work on issue 28307 regarding folding `str % args` combination, which I think we can extend even further. One simple example that I daily encounter

[issue44187] Implement infrastructure for quickening and specializing

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

[issue44142] ast.unparse: visually better code generation

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

[issue44142] ast.unparse: visually better code generation

New submission from Batuhan Taskaya : This issue is for tracking possible places where we could generate better code on ast.unparse (better as in more closely to what people are actually writing than our naive implementation). Examples; >>> import ast >>> ast.unparse(

[issue44081] ast.unparse: dont use redundant space separator for lambdas with no parameters

Change by Batuhan Taskaya : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44081> ___ ___ Pyth

[issue42454] Move slice creation to the compiler for constants

Batuhan Taskaya added the comment: I've implemented a new revision that works without making slices hashable. Updating PR 23496 -- ___ Python tracker <https://bugs.python.org/issue42

[issue44081] ast.unparse: dont use redundant space separator for lambdas with no parameters

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

[issue44081] ast.unparse: dont use redundant space separator for lambdas with no parameters

New submission from Batuhan Taskaya : Previously: >>> import ast >>> ast.unparse(ast.parse("lambda: 'hey!'")) "lambda : 'hey!'" Expected: >>> import ast >>> ast.unparse(ast.parse("lambda: 'hey!'")) "lambda: 'hey!'&quo

[issue43417] ast.unparse: Simplify buffering logic

Change by Batuhan Taskaya : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43417> ___ ___ Pyth

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

Change by Batuhan Taskaya : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42725> ___ ___ Pyth

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

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

[issue44063] compiler: does not revert back the end_* locations

Change by Batuhan Taskaya : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44063> ___ ___ Pyth

[issue44063] compiler: does not revert back the end_* locations

Batuhan Taskaya added the comment: New changeset 13de28f17af02563cb8c6d0f6da3c178a4241ff3 by Miss Islington (bot) in branch '3.10': bpo-44063: set the missing end locations on the compiler (GH-25956) (#25972) https://github.com/python/cpython/commit/13de28f17af02563cb8c6d0f6da3c178a4241ff3

[issue44063] compiler: does not revert back the end_* locations

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

[issue44063] compiler: does not revert back the end_* locations

New submission from Batuhan Taskaya : Something that I've stumbled up while working on another patch is that, the compiler doesn't revert the end_lineno and the end_col_offset attributes back unlike regular lineno/col_offset. An example of this problem; ar rcs libpython3.10d.a Modules

[issue43950] Include column offsets for bytecode instructions

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

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

Batuhan Taskaya added the comment: > Batuhan, can this issue be closed? No, I still need to take care of what's new entry. -- ___ Python tracker <https://bugs.python.org/issu

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

Batuhan Taskaya added the comment: New changeset ad106c68eb00f5e4af2f937107baff6141948cee by Batuhan Taskaya in branch 'master': bpo-42725: Render annotations effectless on symbol table with PEP 563 (GH-25583) https://github.com/python/cpython/commit/ad106c68eb00f5e4af2f937107baff6141948cee

[issue43888] GitHub Actions CI/CD `Coverage` job is broken on master

Batuhan Taskaya added the comment: Coverage runs are still failing on the master, and I think at least we should do something like allow failure or other wise github will send notifications for this flaky run. -- nosy: +BTaskaya ___ Python

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

Batuhan Taskaya added the comment: Ah, seems like there is still one open PR. Keeping this up for that... -- resolution: postponed -> status: closed -> open ___ Python tracker <https://bugs.python.org/i

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

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

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

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

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

Batuhan Taskaya added the comment: New changeset 8cc3cfa8afab1651c4f6e9ba43a7ab7f10f64c32 by Batuhan Taskaya in branch 'master': bpo-42737: annotations with complex targets no longer causes any runtime effects (GH-23952) https://github.com/python/cpython/commit

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

Batuhan Taskaya added the comment: > That can be done after the PEG grammar has accepted them But wouldn't we still end up with maintaining a custom flag to see if we are in annotation (e.g a: Something((yield) + 2)) and act upon that which would seem to do a bit messy in the gram

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

Batuhan Taskaya added the comment: > This was easy in my 649 branch; walrus adds locals, and yield / yield from > make it a generator. So the code raises an error if the generated > annotations code object has locals or is a generator. I don't think I had to > do anyt

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

Batuhan Taskaya added the comment: > Hopefully Batuhan has a recollection of what I am thinking of, there was some > significant delay while we figured out what to do about some of these. The major one that I'd recall is that inspect.signature() just uses whatever is in __annotat

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

Batuhan Taskaya added the comment: I've posted an entry on python-dev to collect comments about how we should act (whether just act them as strings on the symbol table or just forbid them completely): https://mail.python.org/archives/list/python-...@python.org/thread

[issue43892] Make match patterns explicit in the AST

Batuhan Taskaya added the comment: > | MatchStar(identifier? target) +1 on MatchStar(). Much more similiar to the existing node names, and also less semantically-named. > attributes (int lineno, int col_offset, int? end_lineno, int? > end_col_offset) I'm n

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

Batuhan Taskaya 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: Yes, that is what this issue is about. This bug only surfaced while doing other stuff and PEP 563 being

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

Batuhan Taskaya added the comment: > Batuhan, can you summarize the argument from the thread? What do you think > yourself? Myself, I'm not sure either way, but it seems okay to remove the > remnant bytecode. I feel like we shouldn't generate code for these annotations at all,

[issue43897] Implement support for validation of pattern matching ASTs

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

[issue42128] Structural Pattern Matching (PEP 634)

Batuhan Taskaya added the comment: > Actually, I didn't see that there are still 2 open linked PRs. I'll wait > until those are merged. I've moved the AST validator to its own separate issue so feel free to close this Brandt! -- ___

[issue42128] Structural Pattern Matching (PEP 634)

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

[issue43897] Implement support for validation of pattern matching ASTs

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

[issue43892] Make match patterns explicit in the AST

Batuhan Taskaya added the comment: > Batuhan, perhaps we should change the linked issue for your AST validator PR > to this one. That way we can close the old catch-all PEP 634 implementation > issue and keep the discussion focused here. I think it might be better as a separ

[issue43897] Implement support for validation of pattern matching ASTs

Change by Batuhan Taskaya : -- dependencies: +Make match patterns explicit in the AST ___ Python tracker <https://bugs.python.org/issue43897> ___ ___ Python-bug

[issue43897] Implement support for validation of pattern matching ASTs

New submission from Batuhan Taskaya : ASTs of case clauses for PEP 636 are not validated through PyAST_Validate right now, which might crash the Python interpreter when compiling some trees that doesn't hold the assumptions of the compiler. -- assignee: BTaskaya messages: 391469 nosy

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

Batuhan Taskaya added the comment: > I think I'd be okay if `foo[bar]: baz` and `foo.bar: baz` (etc.) didn't > generate any bytecode at all. Is that what you're proposing here? If so, and > assuming the code is reasonably straightforward, I'd say go ahead and make a > PR (and c

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

Batuhan Taskaya added the comment: If there is enough interest, I'd like to propose to this before the beta cut -- ___ Python tracker <https://bugs.python.org/issue42

[issue43684] Add combined opcodes

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

[issue43609] ast.unparse-ing a FunctionType gives ambiguous result

Batuhan Taskaya added the comment: > @BTaskaya I've seen this in third party ides and type checker. For example > they are referring to "Union[Callable[[], Union[int, str]], None]" as "() -> > (int | str) | None" where there are parentheses around the ret

[issue43609] ast.unparse-ing a FunctionType gives ambiguous result

Batuhan Taskaya added the comment: Hey @cleoold! Technically the second AST you gave is invalid (fun2), considering that the FunctionType is not an expression; mod = Module(stmt* body, type_ignore* type_ignores) | FunctionType(expr* argtypes, expr returns) expr = BoolOp

[issue43535] Make str.join auto-convert inputs to strings.

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

[issue43563] Use dedicated opcodes to speed up calls/attribute lookups with super() as receiver

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

[issue43521] Allow `ast.unparse` to handle NaNs and empty sets

Batuhan Taskaya added the comment: The reason that we weren't support these cases was there were simply no way achieve them by parsing code so we simply ignored (empty sets etc). Though considering that you have a decent use case in hy, I'd agree that these small additions are viable

[issue43521] Allow `ast.unparse` to handle NaNs and empty sets

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

[issue42128] Structural Pattern Matching (PEP 634)

Batuhan Taskaya added the comment: > @BTaskaya, do you have any interest in helping me iterate on new AST nodes? Sure! -- ___ Python tracker <https://bugs.python.org/issu

[issue42128] Structural Pattern Matching (PEP 634)

Batuhan Taskaya added the comment: > This seams really inconsistent with the rest of the ast, where identifiers > are always wrapped in a ast.Name object. The only other exception to this is > ast.Attribute. import ... as from ... import ... as try: ... except ... as : ..

[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

[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

[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

[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 you'

[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

[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 -- nosy

[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

[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 the

[issue42927] Inline cache for slots

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

[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

[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 symbol table (even though

[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:

[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://bugs.python.

[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/blob

[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 dataset

[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 a test set on a relatively ~big dataset of source code

[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:

[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

[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

[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: +pablogsal

[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/0b281f94b9e5f117d774a1e4e834e797b2b21438

[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. -- ___ Pyt

[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

[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

[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

[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

[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/cpython/commit

[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/issue42

[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

[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

[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 > can i

[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 > re

[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

[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/cpython/commit

[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 ro

[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

[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/cpython/p

[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

[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:

[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:

[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:

[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 tracker

[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 aiter

[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:

<    1   2   3   4   5   6   7   >