[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

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

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

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

[issue32873] Pickling of typing types

Ivan Levkivskyi added the comment: New changeset 2a363d2930e29ec6d8a774973ed5a4965f881f5f by Ivan Levkivskyi in branch 'master': bpo-32873: Remove a name hack for generic aliases in typing module (GH-6376) https://github.com/python/cpython/commit/2a363d2930e29ec6d8a774973ed5a4

[issue32873] Pickling of typing types

Change by Ivan Levkivskyi : -- pull_requests: +6088 ___ Python tracker <https://bugs.python.org/issue32873> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32873] Pickling of typing types

Ivan Levkivskyi added the comment: Apparently there is another type with a similar problem -- DefaultDict. Will fix this now. -- ___ Python tracker <https://bugs.python.org/issue32

[issue33207] typing.Generic does not correctly call super().__init_subclass__

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

[issue33207] typing.Generic does not correctly call super().__init_subclass__

Change by Ivan Levkivskyi : -- keywords: +patch pull_requests: +6066 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33207> ___ ___ Py

[issue32162] typing.Generic breaks __init_subclass__

Ivan Levkivskyi added the comment: Thanks Will! I think this is actually a different (although very similar issue). It looks like it is easy to fix. Could you please open a separate issue (and mention it here)? Also could you please provide a typical example when this breaks so that I can

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

Change by Ivan Levkivskyi : -- keywords: +patch pull_requests: +6035 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33188> ___ ___ Py

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

Ivan Levkivskyi added the comment: > If we're going to call new_class in make_dataclass, then we should change the > signature of make_dataclass to have the new_class parameters. Why? I think we should care about what API/signature is reasonable/typical for dataclasses use c

[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class

Ivan Levkivskyi added the comment: https://devguide.python.org/ will help you. -- ___ Python tracker <https://bugs.python.org/issue33190> ___ ___ Python-bug

[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class

Ivan Levkivskyi added the comment: This is not a bug, but a misunderstanding: * First, ABCMeta doesn't have `__prepare__`, it is just `type.__prepare__` * Second, the third argument to `types.new_class` is called `kwds` for a reason. It is not a namespace like in `type` but the s

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

Ivan Levkivskyi added the comment: This is not a bug but an explicit design decision. Generic classes are _static_ typing concept and therefore are not supposed to work freely with _dynamic_ class creation. During discussion of PEP 560 it was decided that there should be at least one way to

[issue32873] Pickling of typing types

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

[issue32873] Pickling of typing types

Ivan Levkivskyi added the comment: New changeset 834940375ae88bc95794226dd8eff1f25fba1cf9 by Ivan Levkivskyi in branch 'master': bpo-32873: Treat type variables and special typing forms as immutable by copy and pickle (GH-6216) https://github.com/python/cpyt

[issue33133] Don't return implicit optional types by get_type_hints

Ivan Levkivskyi added the comment: OK, let us then keep this issue as a remainder that we need to update the runtime behaviour when the static one changes. -- ___ Python tracker <https://bugs.python.org/issue33

[issue32873] Pickling of typing types

Change by Ivan Levkivskyi : -- keywords: +patch pull_requests: +5961 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32873> ___ ___ Py

[issue33133] Don't return implicit optional types by get_type_hints

New submission from Ivan Levkivskyi : Currently this code def f(x: int = None): pass get_type_hints(f) returns {'x': Optional[int]}. I propose to abandon this behaviour. Although there is not yet a definitive decision about this aspect of PEP 484, see https://github.com/pyt

[issue33061] NoReturn missing from __all__ in typing.py

Ivan Levkivskyi added the comment: The typing repo PR is not merged yet, but I am closing this here, the remainder is tracked in typing repo. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracke

[issue33061] NoReturn missing from __all__ in typing.py

Ivan Levkivskyi added the comment: New changeset ac5602746ed39ca6591e98e062e587121ac71371 by Ivan Levkivskyi in branch '3.7': bpo-33061: Add missing 'NoReturn' to __all__ in typing.py (GH-6127) (#6162) https://github.com/python/cpython/commit/ac5602746ed39ca6591e

[issue32505] dataclasses: make field() with no annotation an error

Ivan Levkivskyi added the comment: > you'll notice that's an error? Yes, but there are other scenarios, like using `init=False` or updating existing class definition and forgetting to update call sites (which will still work), etc. What would we lose by not flagging this a

[issue33018] Improve issubclass() error checking and message

Ivan Levkivskyi added the comment: I am closing this for now. We can re-open it later if problems will appear in 3.7. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bug

[issue32999] issubclass(obj, abc.ABC) causes a segfault

Ivan Levkivskyi added the comment: New changeset 5d8bb5d07be2a9205e7059090f0ac5360d36b217 by Ivan Levkivskyi (Miss Islington (bot)) in branch '3.7': bpo-32999: Revert GH-6002 (fc7df0e6) (GH-6189) (GH-6190) https://github.com/python/cpython/commit/5d8bb5d07be2a9205e7059090f0ac5

[issue33018] Improve issubclass() error checking and message

Ivan Levkivskyi added the comment: New changeset 5d8bb5d07be2a9205e7059090f0ac5360d36b217 by Ivan Levkivskyi (Miss Islington (bot)) in branch '3.7': bpo-32999: Revert GH-6002 (fc7df0e6) (GH-6189) (GH-6190) https://github.com/python/cpython/commit/5d8bb5d07be2a9205e7059090f0ac5

[issue33018] Improve issubclass() error checking and message

Ivan Levkivskyi added the comment: New changeset 40472dd42de4f7265d456458cd13ad6894d736db by Ivan Levkivskyi (jab) in branch 'master': bpo-33018: Improve issubclass() error checking and message. (GH-5944) https://github.com/python/cpython/commit/40472dd42de4f7265d456458cd13ad

[issue33018] Improve issubclass() error checking and message

Ivan Levkivskyi added the comment: > Would you merge this into master? OK, I played with this a bit and it looks good. There is however a merge conflict now, and a NEWS item is missing. I will leave a comment in the PR. -- ___ Python trac

[issue32505] dataclasses: make field() with no annotation an error

Ivan Levkivskyi added the comment: Some part of the discussion is in https://bugs.python.org/issue32428 I still think it is important to flag things like this as an error: @dataclass class C: x = field() This is a big bug magnet. Especially taking into account that attrs behave in the

[issue33061] NoReturn missing from __all__ in typing.py

Change by Ivan Levkivskyi : -- pull_requests: +5918 ___ Python tracker <https://bugs.python.org/issue33061> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33061] NoReturn missing from __all__ in typing.py

Ivan Levkivskyi added the comment: I think it makes sense to also fix this in 3.7. I will prepare a backport now. -- ___ Python tracker <https://bugs.python.org/issue33

[issue33077] typing: Unexpected result with value of instance of class inherited from typing.NamedTuple

Ivan Levkivskyi added the comment: > Would it be worthwhile to show an example of a subclass that overrides or > extends __new__? I think yes. I would actually add few examples what could (and maybe also couldn't) be done with n

[issue33018] Improve issubclass() error checking and message

Ivan Levkivskyi added the comment: I am still -1 on changing this in Python 3.7, unless Guido wants this in 3.7, if yes, then we can go ahead. Otherwise, I think we can consider just merging this into master, in this case I would switch to the PR to discuss the details. -- nosy

[issue33061] NoReturn missing from __all__ in typing.py

Ivan Levkivskyi added the comment: New changeset 4573820d2a9156346392838d455e89f33067e9dd by Ivan Levkivskyi (aetracht) in branch 'master': bpo-33061: Add missing 'NoReturn' to __all__ in typing.py (GH-6127) https://github.com/python/cpython/commit/4573820d2a9156346392

[issue33061] NoReturn missing from __all__ in typing.py

New submission from Ivan Levkivskyi : This is clearly a bug. Would you like to make a PR? -- nosy: +levkivskyi ___ Python tracker <https://bugs.python.org/issue33

[issue33061] NoReturn missing from __all__ in typing.py

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

[issue33077] typing: Unexpected result with value of instance of class inherited from typing.NamedTuple

Ivan Levkivskyi added the comment: > Apart from the fact that it's too late, if you had to do it over again, could it be done as a class decorator? Yes, this could be done as a decorator which would replace the original class with a named tuple after inspecting `__annotations__` and `

[issue33077] typing: Unexpected result with value of instance of class inherited from typing.NamedTuple

Ivan Levkivskyi added the comment: I would say it is too late. `typing.NamedTuple` is out there for more than a year and is quite actively used. A search on GitHub shows thousands of files that import `typing.NamedTuple` and a macroscopic fraction of those use it with the class syntax. I

[issue33077] typing: Unexpected result with value of instance of class inherited from typing.NamedTuple

Ivan Levkivskyi added the comment: Yes, this is because subclassing `typing.NamedTuple` is not an actual subclassing, but is just a syntactic sugar for calling `collections.namedtuple`. A discussion about allowing subclassing/extending named tuples previously appeared in https://github.com

[issue33075] typing.NamedTuple does not deduce Optional[] from using None as default field value

Change by Ivan Levkivskyi : -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue33075> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue33075] typing.NamedTuple does not deduce Optional[] from using None as default field value

Change by Ivan Levkivskyi : -- resolution: -> not a bug stage: -> resolved ___ Python tracker <https://bugs.python.org/issue33075> ___ ___ Python-bugs-

[issue33075] typing.NamedTuple does not deduce Optional[] from using None as default field value

Ivan Levkivskyi added the comment: This is actually an intended behaviour. Moreover, the implicit optionality of arguments that default to `None` is deprecated and will be removed in one of the future versions. (Note that since typing module is still provisional, this will likely happen

[issue33018] Improve issubclass() error checking and message

Ivan Levkivskyi added the comment: To be honest I am still undecided on this. In principle, I am OK with status quo, but I am also OK, with the PR that will prohibit non-classes. I am a bit worried that it may break some existing code, so it is probably not for 3.7

[issue32999] issubclass(obj, abc.ABC) causes a segfault

Ivan Levkivskyi added the comment: Serhiy, for example `issubclass(typing.MutableMapping, typing.Mapping)` returns `True` while neither of those two are actual class objects. These relationships are kept mostly so that `typing.*` can be used as a drop-in replacement for `collections.abc

[issue32999] issubclass(obj, abc.ABC) causes a segfault

Ivan Levkivskyi added the comment: Actually, the behaviour when __suclasscheck__ returns True for non-class objects may be used by some code. Even typing module did this, I tried to remove as much as possible of this, but I think there may be few such situations left. Therefore, the patch

[issue32873] Pickling of typing types

Ivan Levkivskyi 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 tracker <https://bugs.python.org/is

[issue32873] Pickling of typing types

Ivan Levkivskyi added the comment: Thank you, Ned! -- ___ Python tracker <https://bugs.python.org/issue32873> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32873] Pickling of typing types

Ivan Levkivskyi 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 before, see https

[issue31333] Implement ABCMeta in C

Ivan Levkivskyi 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/commit/3fb813d2c67fe28cc98ae51e53a689

[issue25988] collections.abc.Indexable

Ivan Levkivskyi 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/commit/0442de5ad7835814d60f

[issue31333] Implement ABCMeta in C

Ivan Levkivskyi 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/38928992885d8a04b7188abdba3b04

[issue25988] collections.abc.Indexable

Change by Ivan Levkivskyi : -- pull_requests: +5515 ___ Python tracker <https://bugs.python.org/issue25988> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31333] Implement ABCMeta in C

Change by Ivan Levkivskyi : -- pull_requests: +5514 ___ Python tracker <https://bugs.python.org/issue31333> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32162] typing.Generic breaks __init_subclass__

Ivan Levkivskyi 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: open -&g

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

Ivan Levkivskyi 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 instances resolution: -&g

[issue31333] Implement ABCMeta in C

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

[issue31333] Implement ABCMeta in C

Ivan Levkivskyi 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/03e3c340a0156891a036d6dbdb9e34

[issue31333] Implement ABCMeta in C

Ivan Levkivskyi 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 can save just several mill

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi 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: +gvanrossum ___ Python tracker

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

Ivan Levkivskyi 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 requests like this, then the most used

[issue32769] Add 'annotations' to the glossary

Ivan Levkivskyi 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 <https://bugs.python.org/issue32

[issue32227] singledispatch support for type annotations

Ivan Levkivskyi 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 <https://bugs.python.org

[issue32717] Document PEP 560

New submission from Ivan Levkivskyi : 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, like numpy.ndarray) in PEP

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

Ivan Levkivskyi 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 ___ Python tracker <https://bug

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

Ivan Levkivskyi 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 because of it will allow to fix them in a

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

Ivan Levkivskyi 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 marking this as high priority, since

[issue31333] Implement ABCMeta in C

Change by Ivan Levkivskyi : -- keywords: +patch pull_requests: +5117 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31333> ___ ___ Py

[issue28980] ResourceWarning when imorting antigravity in 3.6

Ivan Levkivskyi 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 <https://bugs.pyth

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

Ivan Levkivskyi 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/d911e40e788fb679723d78b6ea11ca

[issue32225] Implement PEP 562: module __getattr__ and __dir__

Ivan Levkivskyi 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 <https://bugs.python.org/issu

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

Ivan Levkivskyi 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 speed I thi

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

Ivan Levkivskyi 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} in the module `

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

Ivan Levkivskyi 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 documentation PR for `__mro_entry__` and

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

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

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

Ivan Levkivskyi 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.__dict__. -- ___ Pyth

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

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

[issue32473] Readibility of ABCMeta._dump_registry()

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

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

Ivan Levkivskyi 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 we should stick with >

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

Ivan Levkivskyi 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 comment is about @dataclass

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

Ivan Levkivskyi 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. This "conflicts" with PEP 52

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

Ivan Levkivskyi 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 as errors. > How

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

Ivan Levkivskyi 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. -- nosy: +gvanrossum, levkivskyi

[issue32380] functools.singledispatch interacts poorly with methods

Ivan Levkivskyi 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 tracker <https://bugs.python.org/issue32

[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?

Ivan Levkivskyi added the comment: Stefan, your last example is formally speaking OK, if one reads the "Execution model" literally. The original example is however too ambiguous, so it is good that it triggers an error. I think there is a chance to improve the error message h

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

Change by Ivan Levkivskyi : -- pull_requests: +4800 ___ Python tracker <https://bugs.python.org/issue32226> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32320] Add default value support to collections.namedtuple()

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

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

Ivan Levkivskyi added the comment: Interesting. I have noticed similar when I tried to add a fast loop proposed by Serhiy. It should save at least one pointer comparison for base class, but sometimes it actually led to slow-downs (although very small). How can one fight this kind of problems

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

Ivan Levkivskyi added the comment: New changeset 2b5fd1e9ca9318673989e6ccac2c8acadc3809cd by Ivan Levkivskyi in branch 'master': bpo-32226: Implementation of PEP 560 (core components) (#4732) https://github.com/python/cpython/commit/2b5fd1e9ca9318673989e6ccac2c8a

[issue32225] Implement PEP 562: module __getattr__ and __dir__

Ivan Levkivskyi added the comment: Travis build on master successful, so I am closing this issue. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue32225] Implement PEP 562: module __getattr__ and __dir__

Ivan Levkivskyi added the comment: New changeset 5364b5cd7571f2dfa75acd37b388c14ac33fef73 by Ivan Levkivskyi in branch 'master': bpo-32225: Implementation of PEP 562 (#4731) https://github.com/python/cpython/commit/5364b5cd7571f2dfa75acd37b388c1

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

Ivan Levkivskyi added the comment: Guido, what is your preference for the implementation of ``__class_getitem__``: ``PyObject_GetItem`` (current one) or ``type.__getitem__`` (old one)? Can we just go ahead with the version you like and then re-consider if some objections will appear? I am

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

Ivan Levkivskyi added the comment: > As for __class_getitem__, why not implement type.__getitem__ instead of > hacking PyObject_GetItem()? This question was raised by Mark Shannon on python-dev. Actually, my initial implementation did exactly this, but I didn't like it for two

[issue32284] typing.TextIO and BinaryIO are not aliases of IO[...]

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

[issue32216] Document PEP 557 Data Classes

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

[issue32227] singledispatch support for type annotations

Ivan Levkivskyi added the comment: Idea looks interesting (like a basic runtime @overload). My expectation is that some changes are necessary in mypy for this to work properly. Another (minor) problem is that this creates a circular dependency functools <-> typing. -

[issue32227] singledispatch support for type annotations

Ivan Levkivskyi added the comment: Oops something wrong happened. -- nosy: +gvanrossum stage: patch review -> ___ Python tracker <https://bugs.python.org/issu

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

Change by Ivan Levkivskyi : -- keywords: +patch pull_requests: +4635 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

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

New submission from Ivan Levkivskyi : As discussed before, there will be two PRs. One for the core components, and the second one (large) for typing updates. I will open the first PR shortly. -- nosy: +gvanrossum ___ Python tracker <ht

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

Change by Ivan Levkivskyi : -- assignee: levkivskyi components: Interpreter Core, Library (Lib) nosy: levkivskyi priority: normal severity: normal stage: needs patch status: open title: Implement PEP 560: Core support for typing module and generic types type: enhancement versions

[issue32225] Implement PEP 562: module __getattr__ and __dir__

Change by Ivan Levkivskyi : -- keywords: +patch pull_requests: +4634 ___ Python tracker <https://bugs.python.org/issue32225> ___ ___ Python-bugs-list mailin

[issue32225] Implement PEP 562: module __getattr__ and __dir__

Change by Ivan Levkivskyi : -- assignee: levkivskyi components: Interpreter Core nosy: levkivskyi priority: normal severity: normal stage: patch review status: open title: Implement PEP 562: module __getattr__ and __dir__ type: enhancement versions: Python 3.7

[issue28556] typing.py upgrades

Change by Ivan Levkivskyi : -- pull_requests: +4621 ___ Python tracker <https://bugs.python.org/issue28556> ___ ___ Python-bugs-list mailing list Unsubscribe:

<    1   2   3   4   5   6   7   >