[issue36949] WeakSet.__repr__ and __str__ do not show contents of the set

Change by Batuhan : -- keywords: +patch pull_requests: +13326 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue36949> ___ _

[issue20410] Argument Clinic: add 'self' return converter

Batuhan added the comment: Doesn't clinic have a `self_converter` class? https://github.com/python/cpython/blame/master/Tools/clinic/clinic.py#L3465 -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/is

[issue23012] RuntimeError: settrace/setprofile function gets lost

Change by Batuhan : -- versions: +Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue23012> ___ ___ Python-bugs-list mailing list Unsub

[issue23012] RuntimeError: settrace/setprofile function gets lost

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

[issue23012] RuntimeError: settrace/setprofile function gets lost

Batuhan added the comment: I try to track down this. sys_settrace calls PyEval_SetTrace with trace_trampoline and the function given to it. The trace_trampoline is important because it checks the result and if result is NULL (for example like f() recursion in your code) it sets

[issue36962] Cant sort ModuleInfo instances

Batuhan added the comment: You're right. I am thinking implementing 4 sequence methods (contains/len/iter/getitem) and set a depraction warning for them. We can remove this methods in next relase On Sun, May 19, 2019, 2:37 PM Eric V. Smith wrote: > > Eric V. Smith added

[issue36962] Cant sort ModuleInfo instances

Batuhan added the comment: Can you review the PR, i implemented it there. -- ___ Python tracker <https://bugs.python.org/issue36962> ___ ___ Python-bugs-list m

[issue27737] email.header.Header.encode() crashes with IndexError on spaces only value

Change by Batuhan : -- pull_requests: +13390 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue27737> ___ ___ Python-bugs-lis

[issue20443] __code__. co_filename should always be an absolute path

Change by Batuhan : -- keywords: +patch pull_requests: +13441 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue20443> ___ _

[issue31006] typing.NamedTuple should add annotations to its constructor (__new__) parameters.

Batuhan added the comment: IMHO this issue can be closed with this commit (https://github.com/python/typing/commit/435b29470c7d3e87055531f65681bee9746ab999) -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue31

[issue19666] Format string for ASCII unicode or bytes-like object as readonly buffer

Batuhan added the comment: Don't we need to discuss it more before triage it as "patch required"? -- nosy: +BTaskaya ___ Python tracker <https://bugs.pyt

[issue35476] _imp_create_dynamic_impl() does not clear error.

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

[issue35476] _imp_create_dynamic_impl() does not clear error.

Batuhan added the comment: Can you give me the case so i can reproduce this and test it. -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue35

[issue33326] Convert collections (cmp_op, hasconst, hasname and others) in opcode module to more optimal type

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

[issue37680] distutils appends LDFLAGS environment variable before object file names

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

[issue37830] continue in finally with return in try results with segfault

New submission from Batuhan : When you try to put a return statement with the iterated value inside of try/finally and if you have continue in finally it will result with segfault. def simple(): for number in range(2): try: return number finally

[issue37830] continue in finally with return in try results with segfault

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

[issue37830] continue in finally with return in try results with segfault

Change by Batuhan : -- versions: +Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37830> ___ ___ Python-bugs-list mailing list Unsub

[issue37830] continue in finally with return in try results with segfault

Batuhan added the comment: Raising an error can handle this because it is impossible to reach to return so we can declare this as an illegal syntax? -- ___ Python tracker <https://bugs.python.org/issue37

[issue37830] continue in finally with return in try results with segfault

Batuhan added the comment: I closed the my PR in favor of Serhiy's PR. On Mon, Aug 12, 2019, 9:18 PM Serhiy Storchaka wrote: > > Change by Serhiy Storchaka : > > > -- > pull_requests: +14953 > pull_request: https://github.com

[issue36764] Types module doesn't have a type for _abc_data

New submission from Batuhan : Types module doesn't have a type for _abc_data -- messages: 341180 nosy: isidentical priority: normal severity: normal status: open title: Types module doesn't have a type for _abc_data ___ Python track

[issue36764] Types module doesn't have a type for _abc_data

Batuhan added the comment: I'm working on a project that is a custom byte code interpreter for some extended types. I needed ABCData there and i thought types module already has that, but i was wrong so i added. Isn't types module exposing some types that are implementation deta

[issue36764] Types module doesn't have a type for _abc_data

Batuhan added the comment: > I still don't understand why you need _abc_data. I'm using it both for comparisons which needed to build an abstract base class and typing. Currently there are 2 ways, i need to create a dummy abc and put type() calls everywhere or i need to set a c

[issue36764] Types module doesn't have a type for _abc_data

Batuhan added the comment: It is based on default behavior of cpython. It tries to import _abc first instead of _py_abc and this type targets c implementation. -- ___ Python tracker <https://bugs.python.org/issue36

[issue36764] Types module doesn't have a type for _abc_data

Batuhan added the comment: We can try to obtain the type of ABCData and if we can't (if py_abc is used) we can set ABCData to NotImplemented. On Wed, May 1, 2019, 2:56 PM Batuhan wrote: > > Batuhan added the comment: > > It is based on default behavior of cpython. It tri

[issue22964] dbm.open(..., "x")

Batuhan added the comment: Python directly passes flags to gdbm (or whatever the dbm interface is). gdbm_open((char *)file, 0, flags, mode, NULL)) # _gdbmmodule.c:76 I dont think it is good idea to wrap gdbm for just a flag. -- nosy: +BTaskaya

[issue23896] lib2to3 doesn't provide a grammar where exec is a function

Change by Batuhan : -- keywords: +patch pull_requests: +13178 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue23896> ___ _

[issue23378] argparse.add_argument action parameter should allow value extend

Change by Batuhan : -- keywords: +patch pull_requests: +13215 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue23378> ___ _

[issue25652] collections.UserString.__rmod__() raises NameError

Change by Batuhan : -- keywords: +patch pull_requests: +13238 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue25652> ___ _

[issue36826] ast_unparser.c doesn't handle := expressions

Batuhan added the comment: I have patch, i'm going to submit it. -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue36826> ___ ___ Pytho

[issue36826] ast_unparser.c doesn't handle := expressions

Change by Batuhan : -- keywords: +patch pull_requests: +13249 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue36826> ___ _

[issue1572968] release GIL while doing I/O operations in the mmap module

Batuhan added the comment: Any news? If a patch is not ready, i can work on a patch too. -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue1572

[issue36713] duplicate method definition in Lib/ctypes/test/test_unicode.py

Change by Batuhan : -- title: uplicate method definition in Lib/ctypes/test/test_unicode.py -> duplicate method definition in Lib/ctypes/test/test_unicode.py ___ Python tracker <https://bugs.python.org/issu

[issue33135] Define field prefixes for the various config structs

Batuhan added the comment: +1 from me. But i dont understand why this issue triaged as "needs patch". Isn't it should be discussed first? -- nosy: +BTaskaya ___ Python tracker <https://bugs.pyt

[issue36567] DOC: manpage directive doesn't create hyperlink

Batuhan added the comment: What is going to be our manpage site? Debian? -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue36567> ___ ___ Pytho

[issue36567] DOC: manpage directive doesn't create hyperlink

Change by Batuhan : -- keywords: +patch pull_requests: +13251 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue36567> ___ _

[issue36567] DOC: manpage directive doesn't create hyperlink

Batuhan added the comment: I sent a proposal with debian default and can be altered through env variable called MANPAGES_URL -- ___ Python tracker <https://bugs.python.org/issue36

[issue36567] DOC: manpage directive doesn't create hyperlink

Batuhan added the comment: *ups propsal = pr -- ___ Python tracker <https://bugs.python.org/issue36567> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44896] AttributeError in ast.unparse

Change by Batuhan Taskaya : -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue44896> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue46073] ast.unparse produces: 'FunctionDef' object has no attribute 'lineno' for valid module

Batuhan Taskaya added the comment: >From the first glance, this seems like a duplicate of bpo-44896. -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issu

[issue46289] AST: FomattedValue conversion's default value should be -1

Batuhan Taskaya added the comment: ASDL technically allows it to be None though neither compiler nor ast.unparse can work with it at this moment. > FormattedValue(expr value, int? conversion, expr? format_spec) https://github.com/python/cpython/blob/b127e70a8a682fe869c22ce04c379bd85a00d

[issue46289] AST: FomattedValue conversion's default value should be -1

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

[issue46289] AST: FomattedValue conversion's default value should be -1

Batuhan Taskaya added the comment: Should we backport this? On Sat, Jan 8, 2022, 12:05 AM miss-islington wrote: > > miss-islington added the > comment: > > > New changeset d382f7ee0b98e4ab6ade9384268f25c06be462ad by Batuhan Taskaya > in branch 'main':

[issue46289] AST: FomattedValue conversion's default value should be -1

Change by Batuhan Taskaya : -- stage: patch review -> resolved status: open -> closed versions: +Python 3.10, Python 3.11 -Python 3.9 ___ Python tracker <https://bugs.python.org/i

[issue46422] Why do we need `dis.Positions`?

Batuhan Taskaya added the comment: The initial aim of the dis.Positions was to provide an interface like AST nodes. So you could do for instr in dis.Bytecode(source): print("located in: ", instr.positions.lineno) instead of for instr in dis.Bytecode(source): if instr

[issue46441] Caret points to wrong line on 'return yield 42' in REPL

Change by Batuhan Taskaya : -- nosy: +BTaskaya nosy_count: 3.0 -> 4.0 pull_requests: +28911 pull_request: https://github.com/python/cpython/pull/30720 ___ Python tracker <https://bugs.python.org/issu

[issue46441] Caret points to wrong line on 'return yield 42' in REPL

Batuhan Taskaya added the comment: New changeset 30fb6d073d9ca00dff8e4155c523cdfa63abab6b by Batuhan Taskaya in branch 'main': bpo-46441: Add a boilerplate to test syntax errors in interactive mode (GH-30720) https://github.com/python/cpython/commit/30fb6d073d9ca00dff8e4155c523cd

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

New submission from Batuhan Taskaya : Superseeded by https://github.com/python/core-workflow/issues/425 -- resolution: -> later stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue46212] Avoid temporary `varargs` tuple creation in argument passing

Batuhan Taskaya added the comment: > Note that _PyArg_UnpackKeywordsWithVararg is defined with PyAPI_FUNC. > Changing its argument spec is strictly a backwards incompatible change, IIUC. AFAIK we have committed _PyArg_UnpackKeywordsWithVararg on 3.11 alpha, so I think it should b

[issue46483] `pathlib.PurePath.__class_getitem__` does not return `GenericAlias`

Batuhan Taskaya added the comment: New changeset 1f715d5bd3bc9ff444e109b6bbd13011913681b1 by Nikita Sobolev in branch 'main': bpo-46483: change `PurePath.__class_getitem__` to return `GenericAlias` (GH-30822) https://github.com/python/cpython/commit/1f715d5bd3bc9ff444e109b6bbd130

[issue46422] Why do we need `dis.Positions`?

Batuhan Taskaya added the comment: New changeset 58f3d980989c7346ad792d464c1d749dcec6af63 by Nikita Sobolev in branch 'main': bpo-46422: use `dis.Positions` in `dis.Instruction` (GH-30716) https://github.com/python/cpython/commit/58f3d980989c7346ad792d464c1d74

[issue46520] `ast.unparse` produces syntactically illegal code for identifiers that look like reserved words

Batuhan Taskaya added the comment: Technically, this is a bug on the fact that it breaks the only guarantee of ast.unparse: > Unparse an ast.AST object and generate a string with code that would produce > an equivalent ast.AST object if parsed back with ast.parse(). But I am not

[issue46674] Two if in a row in generators

Batuhan Taskaya added the comment: As Serhiy mentioned, this is a valid syntax. -- nosy: +BTaskaya resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue46719] Call not visited in ast.NodeTransformer

Batuhan Taskaya added the comment: > It looks like calls in function arguments are ignored. Please share a small, self-contained reproducer. >From what I can assume by this message, the problem is that you are not >calling self.generic_visit(node) on the first call you are handlin

[issue46725] Unpacking without parentheses is allowed since 3.9

Batuhan Taskaya added the comment: Since this was already allowed in 3.9 and 3.10 stable relases, and since it is consistent with the RHS of an assignment (something = *a, *b); I'd lean towards keeping it (and maybe fixing the old parser's grammar to reflect that) and docume

[issue29418] inspect.isroutine does not return True for some bound builtin methods

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

[issue29418] inspect.isroutine does not return True for some bound builtin methods

Batuhan Taskaya added the comment: New changeset 02815d939362d4093a95da650e7fbddabf147eb0 by Hakan Çelik in branch 'main': bpo-29418: Add inspect.ismethodwrapper to whatsnew (GH-31377) https://github.com/python/cpython/commit/02815d939362d4093a95da650e7fbddabf147eb0 -

[issue40001] ignore errors in SimpleCookie

Change by Batuhan Taskaya : -- nosy: +BTaskaya nosy_count: 3.0 -> 4.0 pull_requests: +29968 pull_request: https://github.com/python/cpython/pull/19214 ___ Python tracker <https://bugs.python.org/issu

[issue40001] ignore errors in SimpleCookie

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

[issue40001] ignore errors in SimpleCookie

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

[issue44501] Packing constant call arguments

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

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

[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

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

[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

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

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

[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

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

[issue43684] Add combined opcodes

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

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

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

[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

[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

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

[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

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

[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! -- _

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

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

[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

[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

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

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

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

[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

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

[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

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

[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

[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

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

[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

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

[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

[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

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/13de28f17af02563cb8c6d0f6da3c1

[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

[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

[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

<    1   2   3   4   5   6   7   8   9   >