[issue42611] PEP 594

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

[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

[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

[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 more ap

[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 patch I

[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 related c

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

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

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

[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: X d: str Do you prop

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

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

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

[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: > What are the potential benefits or drawbacks for the user? The only potential drawback that I can see is that it prevents you from distinguishing a sequence from mapping by 'accidentally' passing a slice. The major benefit for us

[issue42454] Move slice creation to the compiler for constants

Batuhan Taskaya added the comment: > something[::-1] = something I was thinking this for a while, and this is the actual reason that I didn't propose this until I saw someone's comment under Raymond's tweet about 'slices are not hashable' (https://twitter.com/4skvictor/sta

[issue42454] Move slice creation to the compiler for constants

Batuhan Taskaya added the comment: As a side effect, we also now fold some esoteric cases which are not very common. Like; """ test """[1:-1] We reviewed only optimizing this a while back and decided these are not that common to add a code path. Just wanted t

[issue42454] Move slice creation to the compiler for constants

Batuhan Taskaya added the comment: > I'm slightly concerned about hashability of slice objects. Currently the > slice constructor does not ensure that any slice parameter is a number. You > can do horrible stuff like this: The same thing can be applied to tuples, which are hashab

[issue42454] Move slice creation to the compiler for constants

Change by Batuhan Taskaya : -- nosy: +Mark.Shannon, serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue42454> ___ ___ Python-bugs-list mailin

[issue42454] Move slice creation to the compiler for constants

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

[issue42454] Move slice creation to the compiler for constants

New submission from Batuhan Taskaya : Currently, all the slices are created by the interpreter with BUILD_SLICE preceded by 2/3 LOAD_CONSTS. We can move the slice creation into the compiler and deduce the cost of these 3/4 instructions into a single LOAD_CONST operation where all values

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

Batuhan Taskaya added the comment: > do you think this is too similar to bogus_code_obj.py? That's the only > crasher I can see it being similar to. As far as I assume, yes, that is the generic VM crasher via custom code object execution. I feel its existence is good enough to

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

Batuhan Taskaya added the comment: I'm sorry to interrupt but what is the exact reasoning behind adding a new, (I presume) redundant crasher? There are tons of different ways to crash the interpreter with malformed bytecode, how would adding only one of them bring any good? -- nosy

[issue28002] ast.unparse can't roundtrip some f-strings

Batuhan Taskaya added the comment: Thanks for your efforts Shantanu! -- ___ Python tracker <https://bugs.python.org/issue28002> ___ ___ Python-bugs-list mailin

[issue28002] ast.unparse can't roundtrip some f-strings

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

[issue28002] ast.unparse can't roundtrip some f-strings

Batuhan Taskaya added the comment: New changeset 3763cc1dbdb930f67b443ceed7c44e4feb883b42 by Miss Islington (bot) in branch '3.9': bpo-28002: Roundtrip f-strings with ast.unparse better (GH-19612) (GH-23430) https://github.com/python/cpython/commit/3763cc1dbdb930f67b443ceed7c44e4feb883b42

[issue28002] ast.unparse can't roundtrip some f-strings

Batuhan Taskaya added the comment: New changeset a993e901ebe60c38d46ecb31f771d0b4a206828c by Shantanu in branch 'master': bpo-28002: Roundtrip f-strings with ast.unparse better (#19612) https://github.com/python/cpython/commit/a993e901ebe60c38d46ecb31f771d0b4a206828c

[issue39463] ast.Constant, bytes, and ast.unparse

Batuhan Taskaya added the comment: We added the warnings, and I believe we can close this safely (since there is no intend to change the behavior of ast.unparse) -- resolution: -> not a bug stage: -> resolved status: open -> closed _

[issue42102] Make builtins.callable "generic"

Batuhan Taskaya added the comment: > Sorry, but making builtins.callable generic looks wrong to me. It is a > predicate, not a constructor. If it would be called "iscallable" instead of > "callable" nobody would propose to make it generic, right? It's just a

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

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

[issue16801] Preserve original representation for integers / floats in docstrings

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

[issue16801] Preserve original representation for integers / floats in docstrings

Batuhan Taskaya added the comment: I'm very late to join this thread, but since the Constant() node has now a kind field, we can possibly add this (though I'm not saying we should, depending on whether still this would be a nice addition to clinic docstrings.) 2 options that I can think off

[issue27119] `compile` doesn't compile into an AST object as specified

Batuhan Taskaya added the comment: We've added a reference to the compiler flags into the compile(), see issue 40484 for details. -- resolution: -> duplicate stage: -> resolved status: open -> closed versions: +Python 3.10 -Python 2.7, Python 3.5, Python 3.6, Python 3.

[issue39411] pyclbr rewrite using AST

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

[issue42354] Tuple unpacking with * causes SyntaxError in with ... as ...

Batuhan Taskaya added the comment: Already fixed with GH-22612 -- nosy: +BTaskaya resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42355] symtable: get_namespace doesn't check whether if there are multiple namespaces or no namespaces at all

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

[issue42355] symtable: get_namespace doesn't check whether if there are multiple namespaces or no namespaces at all

New submission from Batuhan Taskaya : >>> table = symtable.symtable("A = 1", "", "exec") >>> table.lookup("A") >>> table.lookup("A").get_namespace() Traceback (most recent call last): File "", line 1, i

[issue42348] Language Reference: Set items

New submission from Batuhan Taskaya : The data types section of the language reference (https://docs.python.org/3.10/reference/datamodel.html#the-standard-type-hierarchy) has this description directly under the Set type (which has 2 childs, set and frozenset). > These represent unorde

[issue42348] Language Reference: Set items

Change by Batuhan Taskaya : -- assignee: -> docs@python components: +Documentation nosy: +docs@python, rhettinger ___ Python tracker <https://bugs.python.org/issu

[issue42086] AST: Document / re-design? the simple constructor nodes from sums

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

[issue39411] pyclbr rewrite using AST

Batuhan Taskaya added the comment: New changeset fa476fe13255d0360f18528e864540d927560f66 by Batuhan Taskaya in branch 'master': bpo-39411: pyclbr rewrite on AST (#18103) https://github.com/python/cpython/commit/fa476fe13255d0360f18528e864540d927560f66

[issue42313] rstrip removes the trailing `e`s.

Batuhan Taskaya added the comment: For 3.9+, you could do exactly what you want with .removesuffix (/.removeprefix) methods; >>> test = "external_e_object" >>> test.removesuffix("_object") 'external_e' -- nosy: +BTaskaya

[issue36310] pygettext3.7 Does Not Recognize gettext Calls Within fstrings

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

[issue36310] pygettext3.7 Does Not Recognize gettext Calls Within fstrings

Batuhan Taskaya added the comment: New changeset bfc6b63102d37ccb58a71711e2342143cd9f4d86 by jack1142 in branch 'master': bpo-36310: Allow pygettext.py to detect calls to gettext in f-strings. (GH-19875) https://github.com/python/cpython/commit/bfc6b63102d37ccb58a71711e2342143cd9f4d86

[issue42295] Error should be flagged if Walrus operator is used for multiple assigment

Change by Batuhan Taskaya : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42295] Error should be flagged if Walrus operator is used for multiple assigment

Batuhan Taskaya added the comment: Due to the precedence of the walrus operator, it is not actually a multiple assignment but rather a tuple of 3 elements with one being the value of the assignment expression. $ python -m ast (a, b := 3, 4) Module( body=[ Expr( value

[issue26584] pyclbr module needs to be more flexible on loader support

Change by Batuhan Taskaya : -- nosy: +BTaskaya, terry.reedy ___ Python tracker <https://bugs.python.org/issue26584> ___ ___ Python-bugs-list mailing list Unsub

[issue41796] _ast module state should be made per interpreter

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

[issue42218] SystemError in compile builtin function

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

[issue42218] SystemError in compile builtin function

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

[issue42206] Pegen: Raise errors occurred by the AST validator

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

[issue39715] Implement __repr__ methods for AST classes

Batuhan Taskaya added the comment: > I suggest to reject this feature request +1 -- ___ Python tracker <https://bugs.python.org/issue39715> ___ ___ Python-

[issue42206] Pegen: Raise errors occurred by the AST validator

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

[issue42206] Pegen: Raise errors occurred by the AST validator

New submission from Batuhan Taskaya : When working on the AST validator, it is unclear that which of the changes caused parser to fail on valid input. I propose to propagate the error and raise it. Current: $ ./python t.py python: Parser/pegen.c:1146: _PyPegen_run_parser: Assertion

[issue42187] Deprecating / removing token.ISTERMINAL/ISNONTERMINAL

Batuhan Taskaya added the comment: > Since there are so few projects, maybe you can just contact them? For NT_OFFSET? -- ___ Python tracker <https://bugs.python.org/issu

[issue42187] Deprecating / removing token.ISTERMINAL/ISNONTERMINAL

Change by Batuhan Taskaya : -- keywords: -3.4regression ___ Python tracker <https://bugs.python.org/issue42187> ___ ___ Python-bugs-list mailing list Unsub

[issue42187] Deprecating / removing token.ISTERMINAL/ISNONTERMINAL

New submission from Batuhan Taskaya : Since the parser & symbol modules are removed, there is no real use case for ISTERMINAL/ISNONTERMINAL since the only input that contains grammar symbols is the input of the tokenize, which all its outputs are terminals. Which restricts the practica

[issue42173] Drop Solaris support

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

[issue38870] Expose ast.unparse in the ast module

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

[issue38870] Expose ast.unparse in the ast module

Batuhan Taskaya added the comment: Well, I'm happy to say that 3.9.0 is finally released with the ast.unparse interface. After tens of PRs, I think it is time for us to move on. For all future bugs, please create a new issue and nosy me. Thanks everyone who has participated this journey

[issue42086] AST: Document / re-design? the simple constructor nodes from sums

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

[issue42086] AST: Document / re-design? the simple constructor nodes from sums

Batuhan Taskaya added the comment: After doing experiments with annotating the operator nodes with position information, it is concluded that it doesn't worth the efforts of changing all occurrences of operators from enum to a struct. Other than that, it was designated that we'll keep

[issue42087] Remove pre-AIX 6.1 dead code paths

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

[issue42086] AST: Document / re-design? the simple constructor nodes from sums

New submission from Batuhan Taskaya : Simple constructors (basically constructors with no fields) are currently 'cached' / pre-created and dispatched. What I mean by that is, when a user parses some code with `ast.parse()` and gets a tree object, all simple constructors with the same value

[issue40680] thread_cputime isn't supported by AIX5

Batuhan Taskaya added the comment: > Also, I can submit changes to remove pre-AIX 6 dead code paths. Should I open > a separate issue for that or reference this one? Yes, please do so. -- ___ Python tracker <https://bugs.python.org/i

[issue42030] Drop support for dynload_aix

Change by Batuhan Taskaya : -- nosy: +BTaskaya, pablogsal ___ Python tracker <https://bugs.python.org/issue42030> ___ ___ Python-bugs-list mailing list Unsub

[issue42000] Small cleanups to AST-related code

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

[issue42000] Small cleanups to AST-related code

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

[issue42000] Small cleanups to AST-related code

Change by Batuhan Taskaya : -- components: Interpreter Core nosy: BTaskaya priority: normal severity: normal status: open title: Small cleanups to AST-related code versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42

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

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

[issue41987] singledispatchmethod raises an error when relying on a forward declaration

Batuhan Taskaya added the comment: AFAIK the normal way of registering types (dispatcher.register()) also requires that registered type be defined at the execution type. I guess, if we are going to support such a thing, we might end up with supporting passing strings into the .register

[issue41987] singledispatchmethod raises an error when relying on a forward declaration

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

[issue41979] PEG parser doesn't accept extended unpacking in with statement

Change by Batuhan Taskaya : -- pull_requests: +21595 pull_request: https://github.com/python/cpython/pull/22612 ___ Python tracker <https://bugs.python.org/issue41

[issue41979] PEG parser doesn't accept extended unpacking in with statement

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

[issue41979] PEG parser doesn't accept extended unpacking in with statement

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

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Batuhan Taskaya added the comment: It is not actually much of a difference; $ cat t.py def func( arg: typing.Callable[ [int, str], str # test ] ): pass import typing print("Annotations: ", func.__annotations__) print("get_type_hints: ", typing

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Batuhan Taskaya added the comment: s/For 516389 annotated arguments/For 516389 arguments/. Example usages; https://search.tree.science/?query=AnnAssign(annotation%20=%20expr(lineno%20=%20not%20~end_lineno)) https://search.tree.science/?query=arg(annotation=expr(lineno%20=%20not%20~end_lineno

[issue41967] Handle annotations in the parser to avoid the need for roundtrip

Batuhan Taskaya added the comment: After scanning 1552 annotated assignments in over 25k python modules (from most populer packages in PyPI) there are only 6 AnnAssign nodes where the annotations are multiline. For 516389 annotated arguments, only 20 of them are multiline annotations

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

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

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

New submission from Batuhan Taskaya : To resolve annotations in local namespaces (and possibly in different contexts), inspect.signature can take globalns and localns parameters. I'm not inclined to add these into the getfullargspec, but I'd appreciate any comments about whether it is a good

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

Batuhan Taskaya added the comment: @gvanrossum should I draft a patch to convert this inspect.signature(callable, *, follow_wrapped=True) (and also things like inspect.Signature.from_callable) into inspect.signature(callable, *, follow_wrapped=True, globalns=None, localns=None) in order

[issue41613] get_type_hints regression for 3.9 and 3.10

Batuhan Taskaya added the comment: Commit 3ff51d425ecd98b7ba5a12ca9f77eda73fbf9f53 set the __builtins__ to None in namedtuple's creation, but the problem is that it is causing harm when the point came to the point of getting type hints on typing.NamedTuple.__new__ (we had a test about

[issue17490] Improve ast.literal_eval test suite coverage

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

[issue41887] ast.literal_eval does not accept strings with leading whitespaces

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

[issue41887] ast.literal_eval does not accept strings with leading whitespaces

Batuhan Taskaya added the comment: Looks like skipping the leading whitespace is an undocumented behavior for eval() introduced back in 1992 (f08ab0ad158f88f05dd923b129d2397e1882be14). I don't think that bringing it to the literal_eval is a good idea, at least after this much of a time

[issue41887] ast.literal_eval does not accept strings with leading whitespaces

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

[issue41848] PEG parser doesn't allow lambda in for_if_clause

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

[issue41780] Generic Alias attributes nor in dir()

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

[issue41780] Generic Alias attributes nor in dir()

Batuhan Taskaya added the comment: Okay, so IIRC if we stop forwarding __class__ (add it as an exception to attr_exceptions) it would return us the original dir(), and also solve the inconsistency of the example you gave; > >>> list.__class__ > > >>> list[int

[issue41780] Generic Alias attributes nor in dir()

Batuhan Taskaya added the comment: > @Batuhan, do you want to look into this? Sure, will check it out! -- ___ Python tracker <https://bugs.python.org/issu

[issue41746] Add optional type information to asdl_seq objects

Batuhan Taskaya added the comment: > That's a possibility, but that would incur in a lot of new extra code, and > some asdl_seq items in the parser contain non-standard types that only PEG > uses, so is not possible to auto-generate them. Well, since the extra code will be auto

[issue41746] Add optional type information to asdl_seq objects

Batuhan Taskaya added the comment: The problem with asdl_seq_int was that it was hard-coded since there was no entity that transpods data between different traversers / node visitors. PR 20193 tries to implement a general-purpose metadata system to eliminate that issue, and can be easily

[issue41746] Add optional type information to asdl_seq objects

Batuhan Taskaya added the comment: We already have a specialized type for int (actually an enumeration); typedef struct { Py_ssize_t size; void *elements[1]; } asdl_seq; typedef struct { Py_ssize_t size; int elements[1]; } asdl_int_seq; Why not just include

[issue41746] Add optional type information to asdl_seq objects

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

[issue41747] dataclasses: generated method's using the wrong qualname

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

[issue41747] dataclasses: generated method's using the wrong qualname

New submission from Batuhan Taskaya : $ cat t.py from dataclasses import dataclass @dataclass class Foo: bar: int Foo() $ python t.py Traceback (most recent call last): File "/home/isidentical/cpython/cpython/t.py", line 7, in Foo() TypeError: __create_fn__..__init__()

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

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

[issue41687] sendfile implementation is not compatible with Solaris

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

[issue41631] _ast module: get_global_ast_state() doesn't work with Mercurial lazy import

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

<    1   2   3   4   5   6   7   >