[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

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

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

[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: +6445 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28556> ___

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

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

[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

[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

[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: 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: 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: 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>: -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bu

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

[issue33649] asyncio docs overhaul

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

[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

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

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

[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

[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

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/

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

[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? -- ___

[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

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

[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

[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

[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

[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

[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

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

[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

[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

[issue28936] test_global_err_then_warn in test_syntax is no longer valid

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > Is it correct that the parameter can be annotated in the function body? I agree with Guido, this is rather a task for type checkers. -- ___ Python tracker <rep...@bugs.python

[issue32471] Add an UML class diagram to the collections.abc module documentation

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

[issue32473] Readibility of ABCMeta._dump_registry()

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

[issue32513] dataclasses: make it easier to use user-supplied special methods

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

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: @Eric > I'm closing this, and will open another issue to raise an error for: ... I think we also need a separate issue for not overriding __repr__ etc, if '__repr__' in cls

[issue32550] STORE_ANNOTATION bytecode is unnecessary and can be removed.

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: There are several corner cases. For example consider this code: >>> class C: ... del __annotations__ ... x: int Currently this correctly raises NameError, with your replacement it will instead stick {'x': int

[issue32550] STORE_ANNOTATION bytecode is unnecessary and can be removed.

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: There is also another corner case to consider: class C: exec('x: int') assert C.__annotations__ == {'x': int} assert __annotations__ == {} I am not sure this one will be covered correctly. But the main argument here is s

[issue32225] Implement PEP 562: module __getattr__ and __dir__

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > BTW, would you update the PEP status to Final? Good point, here is the PR https://github.com/python/peps/pull/554 -- ___ Python tracker <rep...@bugs.python.org> <https

[issue32226] Implement PEP 560: Core support for typing module and generic types

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Serhiy, I am sorry for a delay, I have recently moved to another country, this is why I have not much time. I will try to work on this weekend. Here are some points where you can be helpful: * Make a short documentat

[issue32226] Implement PEP 560: Core support for typing module and generic types

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: https://github.com/python/typing/issues/512 and https://github.com/python/typing/issues/511 are first issue (they are closely related to each other). This is not directly related to PEP 560, but changes in typing b

[issue32226] Implement PEP 560: Core support for typing module and generic types

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: I think all the critical things have been implemented/fixed. There are unfortunately no docs yet (my fault), also there are two bugs related to PEP 560, but they are not new, they also exist in Python 3.6. I am however m

[issue32227] singledispatch support for type annotations

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > Do you think it should be added to the What's New? page for 3.7? I leave this up to Łukasz. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue32226] Implement PEP 560: Core support for typing module and generic types

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: OK, I will close this issue, and open separate issues for documentation, Union, etc. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Pyth

[issue32717] Document PEP 560

New submission from Ivan Levkivskyi <levkivs...@gmail.com>: This should include: * Short documentation PR for `__mro_entry__` and `__base_subclass__` methods. * The `__class_getitem__` C API calling convention (with motivation, many classes are implemented in C but are generic in nature

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: This is a rather small change, so probably it would be easier to discuss it in a PR. -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

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

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: There is a third party library on PyPI called typing_inspect that provides thin wrappers around internal APIs to get lots of useful information about generics and other special types in typing. If there will be more request

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: I wanted to say implicitly that I like the idea, and that we should figure out details in a PR. But of course if someone is against this, then we should wait with a PR. -- nosy: +gvan

[issue31333] Implement ABCMeta in C

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > Isn't 800 lines of C code too high price for speeding up ABCs creation? 800 lines of C code is not something hard to notice, so I suppose the answer is obvious for all people involved in the work on PR :-) > ...this c

[issue31333] Implement ABCMeta in C

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset 3fb813d2c67fe28cc98ae51e53a6890294b6e423 by Ivan Levkivskyi (Terry Jan Reedy) in branch 'master': bpo-31333: Fix typo in whatsnew/3.7.rst (GH-5744) https://github.com/python/cpython/

[issue32873] Pickling of typing types

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Here is the situation for 3.6 and before: Generic classes are all actual class objects, so they are pickled as immutable. However this creates a problem, parameterized generics, such as `List[int]` _cannot_ be pickled in 3.6 and

[issue25988] collections.abc.Indexable

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset 0442de5ad7835814d60f46c22a22942abb101aef by Ivan Levkivskyi in branch '3.7': bpo-25988: Emit a warning when use or import ABCs from 'collections'. (GH-5734) https://github.com/python/cpython/

[issue31333] Implement ABCMeta in C

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset 38928992885d8a04b7188abdba3b04f350bde32d by Ivan Levkivskyi in branch '3.7': bpo-31333: Re-implement ABCMeta in C (GH-5733) https://github.com/python/cpython/commit/38928992885d8a04b7188abdba3b04f350

[issue28339] "TypeError: Parameterized generics cannot be used with class or instance checks" in test_functools after importing typing module

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: FWIW, this is fixed in 3.7 by PEP 560. I don't think we will be able to get rid of `sys._getframe` workaround on 3.6, so I propose to just close this. -- dependencies: -Provide a way to check for *real* typing.Union ins

[issue31333] Implement ABCMeta in C

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset 03e3c340a0156891a036d6dbdb9e348108826255 by Ivan Levkivskyi in branch 'master': bpo-31333: Re-implement ABCMeta in C (#5273) https://github.com/python/cpython/commit/03e3c340a0156891a036d6dbdb9e348108

[issue31333] Implement ABCMeta in C

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

[issue32162] typing.Generic breaks __init_subclass__

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: FWIW, this is fixed in 3.7 by PEP 560, providing a separate fix for 3.6 is not easy, and you have a good workaround, so I propose to close this issue. -- resolution: -> fixed stage: -> resolved status: op

[issue31333] Implement ABCMeta in C

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

[issue25988] collections.abc.Indexable

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

[issue32380] functools.singledispatch interacts poorly with methods

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: I have also noticed this problem and I like the idea. It appeared some time ago on python-ideas, but no one has written a patch. -- nosy: +levkivskyi ___ Python tracke

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: A possible question here is should we give an error for any non-callable name in `__dict__` which is not in `__annotations__` or only for `Field`s? After some thinking I am actually leaning towards the first option. -

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > I'm not sure I understand the distinction. Initially I thought about only flagging code like this: @dataclass class C: x = field() But not this: @dataclass class C: x = 42 Now I think we should probably flag both

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > I liked the original design better, where things without annotations would > just be ignored. What changed? With the original proposal the ignored variables without annotations will behave as class variables. Thi

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Just to clarify the previous comment, I still think that flagging this @dataclass class C: x = field() is important, since simply ignoring a ``field()`` will be too confusing (especially for ``attrs`` users). The previous c

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > There is no real conflict with PEP 526 though. PEP 526 introduces ClassVar so > the type checker can be made to understand. PEP 557 allows omitting ClassVar > in case you don't care about type checkers. So I think

[issue32873] Pickling of typing types

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: I am sick now, so can't work on this. There is a small chance I will be able to work on this issue this week. Is it possible to fix this in 3.7b3? -- ___ Python tracke

[issue32873] Pickling of typing types

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Thank you, Ned! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[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

[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

[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

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

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

[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

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

[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

[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

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

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

[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

[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

[issue32226] Implement PEP 560: Core support for typing module and generic types

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: New changeset d911e40e788fb679723d78b6ea11cabf46caed5a by Ivan Levkivskyi in branch 'master': bpo-32226: PEP 560: improve typing module (#4906) https://github.com/python/cpython/commit/d911e40e788fb679723d78b6ea11cabf46

[issue31333] Implement ABCMeta in C

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

[issue28980] ResourceWarning when imorting antigravity in 3.6

Ivan Levkivskyi <levkivs...@gmail.com> added the comment: I have not seen this for quite some time so I'm closing this as fixed. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.

<    1   2   3   4   5   6   7   >