[issue35717] enum.Enum error on sys._getframe(2)

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue35717> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35631] Improve typing docs wrt abstract/concrete collection types

Ivan Levkivskyi added the comment: I think this can be closed now. Whether to merge doc-fix backport to now security-only 3.6 branch is up to Ned. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Pytho

[issue35631] Improve typing docs wrt abstract/concrete collection types

Ivan Levkivskyi added the comment: New changeset 31ec52a9afedd77e36a3ddc31c4c45664b8ac410 by Ivan Levkivskyi (Ville Skyttä) in branch 'master': bpo-35631: Improve typing docs wrt abstract/concrete collection types (GH-11396) https://github.com/python/cpython/commit

[issue35631] Improve typing docs wrt abstract/concrete collection types

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue35631> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35540] dataclasses.asdict breaks with defaultdict fields

Change by Ivan Levkivskyi : -- nosy: +levkivskyi __ Python tracker <https://bugs.python.org/issue35540> __ ___ Python-bugs-list mailing list Unsub

[issue35341] Add generic version of OrderedDict to typing module

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

[issue35341] Add generic version of OrderedDict to typing module

Ivan Levkivskyi added the comment: New changeset 68b56d02ef20479b87c65e523cf3dec1b7b77d40 by Ivan Levkivskyi (Ismo Toijala) in branch 'master': bpo-35341: Add generic version of OrderedDict to typing (GH-10850) https://github.com/python/cpython/commit/68b56d02ef20479b87c65e523cf3dec1b7b77d40

[issue35190] collections.abc.Sequence cannot be used to test whether a class provides a particular interface (doc issue)

Ivan Levkivskyi added the comment: I would propose to keep this one open as a superseding https://bugs.python.org/issue23864 and close the latter (assuming we are not going to make all classes protocols, we I think we really shouldn't, and instead we should improve the docs

[issue35341] Add generic version of OrderedDict to typing module

Ivan Levkivskyi added the comment: Also typing is technically still provisional, we can backport this to previous versions (at least to 3.7). -- ___ Python tracker <https://bugs.python.org/issue35

[issue35341] Add generic version of OrderedDict to typing module

Ivan Levkivskyi added the comment: Yes, since we already have `DefaultDict`, `Counter`, and `ChainMap` from collections, we can also add `OrderedDict`. -- ___ Python tracker <https://bugs.python.org/issue35

[issue34921] NoReturn not allowed by get_type_hints when future import annotations is used

Ivan Levkivskyi added the comment: New changeset f71a5922916abd6cc7bf7d99ed4715b6e96e5981 by Ivan Levkivskyi (Ismo Toijala) in branch '3.7': bpo-34921: Allow escaped NoReturn in get_type_hints (GH-9750) (GH-10772) https://github.com/python/cpython/commit

[issue33211] lineno and col_offset are wrong on function definitions with decorators

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

[issue33416] Add endline and endcolumn to every AST node

Ivan Levkivskyi added the comment: issue22616 is a bit different (proposing line/column ranges instead of just endline/endcolumn). I am happy to close this one in favor of issue22616 if we agree that we will go with endline/endcolumn. I can't guarantee, but likely I will work on this during

[issue34995] functools.cached_property does not maintain the wrapped method's __isabstractmethod__

Ivan Levkivskyi added the comment: I am with Inada-san actually. I would go as far as saying that @cached_property @abstractmethod def something(): ... should unconditionally raise on definition. Mostly because this is just misleading. This declaration doesn't guarantee

[issue35232] Add `module`/`qualname` arguments to make_dataclass for picklability

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue35232> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35190] collections.abc.Sequence cannot be used to test whether a class provides a particular interface

Ivan Levkivskyi added the comment: The separation may look arbitrary, but the idea is quite simple. Only those classes with few methods support structural checks. Those classes have few independent abstract methods (or even just one method), while in classes with large APIs like `Sequence

[issue35119] Customizing module attribute access example raises RecursionError

Change by Ivan Levkivskyi : -- nosy: -miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue35119] Customizing module attribute access example raises RecursionError

Ivan Levkivskyi added the comment: New changeset 0bee3c36d406e47fa9f99cfc1e07b701512c4f3f by Ivan Levkivskyi (Denis Osipov) in branch 'master': bpo-35119: Fix RecursionError in example of customizing module attribute access. (GH-10323) https://github.com/python/cpython/commit

[issue35119] Customizing module attribute access example raises RecursionError

Ivan Levkivskyi added the comment: Ah, sorry, I didn't understand this was a documentation issue. Please feel free to submit a PR that fixes the example to use `super().__setattr__()`. -- resolution: not a bug -> stage: resolved -> needs patch status: closed -

[issue35143] Annotations future requires unparse, but not accessible from Python

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue35143> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35119] Customizing module attribute access example raises RecursionError

Ivan Levkivskyi added the comment: Yes, this is expected, you should use ``super().__setattr__()``. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

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

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

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Ivan Levkivskyi added the comment: Serhiy, thanks for benchmarks and good suggestions! > If make NewType a class, I would make the repr looking like a call This is a nice idea, it indeed looks better. We can probably also use `_type_repr()` helper for the argument (for consiste

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

Ivan Levkivskyi added the comment: New changeset c8a8d6b347d5a6899feb7c810d28f22f3cb151b8 by Ivan Levkivskyi (Sebastian Rittau) in branch 'master': bpo-35089: Don't mention typing.io and typing.re (GH-10173) https://github.com/python/cpython/commit/c8a8d6b347d5a6899feb7c810d28f22f3cb151b8

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing

Ivan Levkivskyi added the comment: OK, so now we have two "competing" PRs. I think I like Serhiy's PR a bit more, since it is simpler. I would propose to look at benchmarks and then decide. Are there any other factors I am missing for choosing one or othe

[issue34939] Possibly spurious SyntaxError: annotated name can't be global

Ivan Levkivskyi added the comment: I think we can just go ahead and allow this. If there is a volunteer, please go ahead, otherwise I will try to find time for this myself. -- ___ Python tracker <https://bugs.python.org/issue34

[issue34939] Possibly spurious SyntaxError: annotated name can't be global

Ivan Levkivskyi added the comment: Hm, I think this should be allowed. The formulation in the docs is not very clear, but the wording in the PEP clarifies the intention. Indeed, only annotations at the same scope with global declarations should be prohibited. So I think this is a bug

[issue34921] NoReturn not allowed by get_type_hints when future import annotations is used

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

[issue34921] NoReturn not allowed by get_type_hints when future import annotations is used

Ivan Levkivskyi added the comment: New changeset 5eea0ad50c32d38909ff4e29309e2cc3c6ccb2c0 by Ivan Levkivskyi (Noah Wood) in branch 'master': bpo-34921: Allow escaped NoReturn in get_type_hints (GH-9750) https://github.com/python/cpython/commit/5eea0ad50c32d38909ff4e29309e2cc3c6ccb2c0

[issue34776] Postponed annotations break inspection of dataclasses

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue34776> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34700] typing.get_type_hints doesn't know about typeshed

Change by Ivan Levkivskyi : -- assignee: -> levkivskyi ___ Python tracker <https://bugs.python.org/issue34700> ___ ___ Python-bugs-list mailing list Un

[issue34700] typing.get_type_hints doesn't know about typeshed

Ivan Levkivskyi added the comment: I think there is also a fourth option: add a flag to `get_type_hints()` that will guard evaluation of forward references, as proposed in https://github.com/python/typing/issues/508. If the evaluation of a "forward reference" raises an error, th

[issue34760] Regression in abc in combination with passing a function to issubclass

Ivan Levkivskyi added the comment: OK, lets close this for now. We will see if there are any other situations. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue34760] Regression in abc in combination with passing a function to issubclass

Ivan Levkivskyi added the comment: This was a conscious decision (i.e we decided that the old inconsistency is a bug). See https://bugs.python.org/issue33018 for previous discussion. What is your use case? If it is critical, we can reconsider

[issue34363] dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple

Ivan Levkivskyi added the comment: > [..] but I think it's the best we can do. It's consistent with any other > class derived from tuple or list: [...] I agree with this argument. Sorry for delay with my response and thank you Eric for taking care about this

[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

Ivan Levkivskyi added the comment: > but even then types in the typing could themselves implement > `__instancecheck__` and `__subclasscheck__` and retain the old behavior. It doesn't work that way. `__instancecheck__` and `__subclasscheck__` tweaks the behaviour of superclas

[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

Ivan Levkivskyi added the comment: It was a deliberate decision. You can find some motivation in PEP 560, and yes we used provisional status here. It was a hard decision, but we decided that giving up few percent of backwards compatibility is a reasonable price for up to 5x performance

[issue34499] Extend registering of single-dispatch functions to parametrized generic pseudo-types

Ivan Levkivskyi added the comment: TBH, I don't like this idea. Consider this situation: @singledispatch def what(x: Iterable) -> None: print('general case') @what.register def _(x: Sequence[int]) -> None: print('special case') what(['is',

[issue34499] Extend registering of single-dispatch functions to parametrized generic pseudo-types

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue34499> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34498] Python 3.7 breaks on singledispatch_function.register(pseudo_type), which Python 3.6 accepted

Ivan Levkivskyi added the comment: > Could we revert abstract types in `typing` to respond True to > `isinstance(..., type)` again? No, making them classes will cause significant performance penalty (I don't remember numbers now, but importing `typing` may be twice slower)

[issue34498] Python 3.7 breaks on singledispatch_function.register(pseudo_type), which Python 3.6 accepted

Ivan Levkivskyi added the comment: This is why we have 4 months of betas :-) On one hand making objects in `typing` module not classes was intentional, but on another hand this use case looks totally fine. I would say we could update the check in `functools` to accept more things. I am

[issue34422] __name__ not available for classes in typing module

Change by Ivan Levkivskyi : -- Removed message: https://bugs.python.org/msg323770 ___ Python tracker <https://bugs.python.org/issue34422> ___ ___ Python-bug

[issue34422] __name__ not available for classes in typing module

Ivan Levkivskyi added the comment: This is an intentional change. It would be a bad idea to use `__name__` instead of what is currently `_name`, because semantics is subtly different. Also the fact that types in typing module used to be actual class objects was an implementation detail

[issue34422] __name__ not available for classes in typing module

Ivan Levkivskyi added the comment: Oh I just re-read my comment and there are so many typos that I will write a new one, sorry. -- ___ Python tracker <https://bugs.python.org/issue34

[issue34422] __name__ not available for classes in typing module

Ivan Levkivskyi added the comment: This is an intentional change. It would be a bad idea to use `_name` instead of `__name__`, because semantics is subtly different. Also the fact that type in typing object used to be actual class object was an implementation detail (also typing is still

[issue34363] dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple

Ivan Levkivskyi added the comment: Eric, I like your solution. It is probably not perfect, but at least it solves the existing problem without introducing obvious problems. Neil, your way will not work since named tuples don't have NamedTuple in their MROs: CustomNT.mro == (CustomNT, tuple

[issue34363] dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple

Ivan Levkivskyi added the comment: The problem with this solution is that it may brea (relatively common) use case of tuple valued fields, e.g.: >>> tuple(*[x for x in a]) Traceback (most recent call last): File "", line 1, in TypeError: tuple expected at most

[issue34363] dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple

Ivan Levkivskyi added the comment: OK, so the crux of the bug is this difference: >>> a = (1, 2) >>> tuple(x for x in a) (1, 2) >>> NamedTupleAttribute(x for x in a) NamedTupleAttribute(example= at 0x10e2e52a0>) A potential solution would be to either

[issue34363] dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue34363> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34254] Include type annotations in error messages for better errors

Ivan Levkivskyi added the comment: FWIW I am rather -1 on this. More detailed errors messages are always good, but in the proposed form it looks more like a distraction. I think just showing a fully qualified name of the function would be both more concise and more informative, since

[issue34336] Don't promote possibility to omit Optional on optional/defaulted arguments

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

[issue34336] Don't promote possibility to omit Optional on optional/defaulted arguments

Ivan Levkivskyi added the comment: New changeset 336c945858055059a65134d4c501a85037d70d99 by Ivan Levkivskyi (Ville Skyttä) in branch 'master': bpo-34336: Don't promote possibility to leave out typing.Optional (#8677) https://github.com/python/cpython/commit

[issue32752] no information about accessing typing.Generic type arguments

Ivan Levkivskyi added the comment: > 3.7 is less convenient and less consistent Taking into account that internal API is something one should never use, I don't think these terms apply here. Anyway, we will provide some helpers for external use in one of the next relea

[issue33758] Unexpected success of test_get_type_hints_modules_forwardref in test_typing

Ivan Levkivskyi added the comment: Oh yes, this is a "stateful" bug. It will not appear if run in isolation. Btw, the underlying bug will be worse with `from __future__ import annotations`, so it would make sense to fix this sooner than later. -- nosy: +lu

[issue5945] PyMapping_Check returns 1 for lists

Change by Ivan Levkivskyi : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.o

[issue33668] Wrong behavior of help function on module

Ivan Levkivskyi added the comment: Adding Yury as an inspect expert. I don't think this is something urgent, we can probably postpone this to 3.7.1. -- nosy: +yselivanov ___ Python tracker <https://bugs.python.org/issue33

[issue33668] Wrong behavior of help function on module

Ivan Levkivskyi added the comment: Hm, replacing the return with a random string, this leads to another crash: Traceback (most recent call last): File "", line 1, in File "/Users/ilevkivskyi/src/cpython/Lib/_sitebuiltins.py", line 103, in __call__ return pydo

[issue33652] Improve pickling of typing types

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: I think this can be closed now. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bu

[issue33652] Improve pickling of typing types

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset 97b523db7c79c18c48516fba9410014d9896abc4 by Ivan Levkivskyi (Serhiy Storchaka) in branch 'master': bpo-33652: Remove __getstate__ and __setstate__ methods in typing. (GH-7144) https://github.com/python/cpython/

[issue33652] Improve pickling of typing types

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Yes, these are just legacy from times when TypeVars were serialized by value, not by identity like now. I think it should be safe to remove them. Would you like to make a PR? -- ___

[issue33652] Improve pickling of typing types

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset 09f3221fbbf72692308149054e4f7668b08b22eb by Ivan Levkivskyi (Serhiy Storchaka) in branch 'master': bpo-33652: Improve pickle support in the typing module. (GH-7123) https://github.com/python/cpython/

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset 717204ffcccfe04a34b6c4a52f0e844fde3cdebe by Ivan Levkivskyi (Andrés Delfino) in branch '3.6': [3.6] bpo-32769: A new take on annotations/type hinting glossary entries (GH-6829) (GH-7128) https://github.com/python/c

[issue33649] asyncio docs overhaul

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33649> ___

[issue33624] Implement subclass hooks for asyncio abstract classes

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33624> ___

[issue33616] typing.NoReturn is undocumented

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bu

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset 6e33f810c9e3a549c9379f24cf1d1752c29195f0 by Ivan Levkivskyi (Andrés Delfino) in branch 'master': bpo-32769: A new take on annotations/type hinting glossary entries (GH-6829) https://github.com/python/cpython/

[issue33616] typing.NoReturn is undocumented

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- keywords: +patch pull_requests: +6746 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue33421] Missing documentation for typing.AsyncContextManager

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: This is now fixed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bu

[issue33569] dataclasses InitVar does not maintain any type info

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33569> ___

[issue33616] typing.NoReturn is undocumented

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33616> ___

[issue28556] typing.py upgrades

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset 09ca5906b7d1619b7efed0bebb6f3c424fe3d83b by Ivan Levkivskyi (Miss Islington (bot)) in branch '3.7': bpo-28556: Don't simplify unions at runtime (GH-6841) (GH-6979) https://github.com/python/cpython/

[issue28556] typing.py upgrades

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset f65e31fee3b55dfb6ed5398179d5c5d6b502dee5 by Ivan Levkivskyi in branch 'master': bpo-28556: Don't simplify unions at runtime (GH-6841) https://github.com/python/cpython/commit/f65e31fee3b55dfb6ed5398179d5c5d6b5

[issue28556] typing.py upgrades

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +6624 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28556> ___

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Yes, local annotations are important and should be mentioned (maybe even with an example). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: What I think Guido might mean is that some type annotations are not strictly speaking type hints. For example, `dataclasses.InitVar`, is not really a type, it is just a way to indicate how constructor should be constructed. I cou

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > ... but annotations are a slightly more general concept because they may be > used for other purposes than to indicate the type of a variable ... Yes, I agree. -- ___ Python

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Yes, all this also applies to 3.6. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Maybe we can consider backporting this to 3.7? Andrés, if you think it makes sense, you can cherry-pick the commit and open a PR against 3.7 branch. -- ___ Python tracke

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset f2290fb19a9b1a5fbeef0971016f72683e8cd1ad by Ivan Levkivskyi (Andrés Delfino) in branch 'master': bpo-32769: Write annotation entry for glossary (GH-6657) https://github.com/python/cpython/

[issue33421] Missing documentation for typing.AsyncContextManager

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33421> ___

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33453> ___

[issue28556] typing.py upgrades

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +6446 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28556> ___

[issue28556] typing.py upgrades

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +6445 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28556> ___

[issue33420] [typing] __origin__ invariant broken

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: This is now fixed on master by https://github.com/python/cpython/commit/43d12a6bd82bd09ac189069fe1eb40cdbc10a58c (the comment is updated). -- resolution: -> fixed stage: -> resolved status: op

[issue28556] typing.py upgrades

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset 43d12a6bd82bd09ac189069fe1eb40cdbc10a58c by Ivan Levkivskyi in branch 'master': bpo-28556: Minor fixes for typing module (GH-6732) https://github.com/python/cpython/commit/43d12a6bd82bd09ac189069fe1eb40cdbc

[issue28556] typing.py upgrades

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +6423 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28556> ___

[issue32717] Document PEP 560

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bu

[issue32717] Document PEP 560

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset bd5f96581bf23f6d05fc106996428a8043b6b084 by Ivan Levkivskyi in branch 'master': bpo-32717: Document PEP 560 (GH-6726) https://github.com/python/cpython/commit/bd5f96581bf23f6d05fc106996428a8043

[issue32717] Document PEP 560

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- keywords: +patch pull_requests: +6419 stage: needs patch -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue3692] improper scope in list comprehension, when used in class declaration

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > Bug or not this is not going to change without a PEP, so I'm not sure it's a > good idea to keep this issue open. I agree this requires a PEP. I would like to keep this open as a place for pre-PEP discussions among thos

[issue33315] Allow queue.Queue to be used in type annotations

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- assignee: -> levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue33420] __origin__ invariant broken

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Yes, the comment needs to be updated, but as you said, no guaranties about undocumented dunder attribute. We tried to preserve as much of the API as possible in 3.7 after PEP 560, but something needs to be sacrificed (espe

[issue33315] Allow queue.Queue to be used in type annotations

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > Could you please product a draft PR showing how that would work? It might not be accepted right away but it would be useful to have. It is not 100% clear to whom this was addressed. Anyway, Semyon, if you don't have time, t

[issue33416] Add endline and endcolumn to every AST node

New submission from Ivan Levkivskyi <levkivs...@gmail.com>: Some Python tools (in particular I am interested in type checkers) will benefit from knowing where a given expression ends to indicate/highlight location of an error in the source code. Other tools and IDEs may have also some

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

Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue7> ___

[issue3692] improper scope in list comprehension, when used in class declaration

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: See https://bugs.python.org/issue33346 for yet another example where implicit function scope complicates life. -- ___ Python tracker <rep...@bugs.python.org> <https://

[issue33346] Syntax error with async generator inside dictionary comprehension

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: My guess this is a consequence of the implicit function scope in comprehensions, see https://bugs.python.org/issue3692 I would say a proper solution would be to drop the implicit function scope in favour of other mech

[issue3692] improper scope in list comprehension, when used in class declaration

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Mariatta, > While I understand why it behaves the way it is now, but it seems wrong > behavior. Perhaps we should look into finding a solution. I am all in favour of dropping implicit function scope in comprehensions (mo

[issue33315] Allow queue.Queue to be used in type annotations

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: I think this issue appeared previously on typing tracker. The current recommendation is to escape problematic annotations with quotes: q: 'Queue[int]' I don't think it will be added to typing, because following this way

[issue33211] lineno and col_offset are wrong on function definitions with decorators

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > I was hoping to see if this was seen as a reasonable patch that might be > accepted. I didn't look carefully but superficially it looks reasonable, so it is worth trying. > Also, while I think it would be nice, I

<    1   2   3   4   5   6   7   >