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

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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

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

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

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

[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

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

[issue28556] typing.py upgrades

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

[issue28556] typing.py upgrades

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

[issue28556] typing.py upgrades

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

[issue33616] typing.NoReturn is undocumented

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

[issue33569] dataclasses InitVar does not maintain any type info

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

[issue33421] Missing documentation for typing.AsyncContextManager

Ivan Levkivskyi added the comment: This is now fixed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue33616] typing.NoReturn is undocumented

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

[issue32769] Add 'annotations' to the glossary

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

[issue33616] typing.NoReturn is undocumented

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

[issue33624] Implement subclass hooks for asyncio abstract classes

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

[issue33649] asyncio docs overhaul

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

[issue32769] Add 'annotations' to the glossary

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

[issue33652] Improve pickling of typing types

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

[issue33652] Improve pickling of typing types

Ivan Levkivskyi 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? -- ___ Python tracker <ht

[issue33652] Improve pickling of typing types

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

[issue33652] Improve pickling of typing types

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

[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

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

[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

[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

[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

[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

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

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

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,

[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

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

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

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

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

[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

[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

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

[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

[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

[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

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

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

[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

[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

[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

[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

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

[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

Change by Ivan Levkivskyi : -- 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: Yes, this is expected, you should use ``super().__setattr__()``. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

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

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

[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

[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

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

[issue28810] Document bytecode changes in 3.6

Ivan Levkivskyi added the comment: SETUP_ANNOTATIONS and STORE_ANNOTATION opcodes are documented in documentation for dis module. Should they be documented also somewhere else? -- nosy: +levkivskyi ___ Python tracker <http://bugs.python.

[issue28869] __module__ attribute is not set correctly for a class created by direct metaclass call

New submission from Ivan Levkivskyi: __module__ attribute is set differently depending on whether a metaclass is explicitly called or invoked in a class statement: >>> A = ABCMeta('A', (), {}) >>> A.__module__ 'abc' >>> class B(metaclas

[issue28869] __module__ attribute is not set correctly for a class created by direct metaclass call

Changes by Ivan Levkivskyi : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue28869> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue28869] __module__ attribute is not set correctly for a class created by direct metaclass call

Ivan Levkivskyi added the comment: > As a matter of fact, A.__module__ in this case is abc.ABCMeta.__module__. A > class body creates a __module__ key, while a direct metaclass call does not. But >>> A = ABCMeta('A', (), {}) >>> ABCMeta.__module__ = '

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

Ivan Levkivskyi added the comment: The failure is fixed now, but it is fixed not in an elegant way (sys._getframe is used). I think this is not urgent. If there are no objections, then I would propose to change priority to normal. -- ___ Python

[issue28936] test_global_err_then_warn in test_syntax is no longer valid

Ivan Levkivskyi added the comment: Serhiy, here is a patch that might be helpful. It detects global-and-parameter errors sooner (when possible). This will cause the following: >>> if 1: ... def error(a): ... global a ... def error2(): ... b = 1 ...

[issue28980] ResourceWarning when imorting antigravity in 3.6

New submission from Ivan Levkivskyi: In 3.6 importing antigravity prints a warning (although it does what it should do): >>> import antigravity /home/ivan/.../Lib/subprocess.py:761: ResourceWarning: subprocess 15501 is still running ResourceWarning, source=self) This is probably r

[issue28936] test_global_err_then_warn in test_syntax is no longer valid

Ivan Levkivskyi added the comment: I don't think this is a bug, but detecting first a SyntaxError that appears textually first might be seen as an improvement. I would say such behaviour seems more intuitive. A possible downside could be a (probably very minor) slow-down of compilatio

[issue28936] test_global_err_then_warn in test_syntax is no longer valid

Ivan Levkivskyi added the comment: Updated patch as proposed by Serhiy. -- Added file: http://bugs.python.org/file45948/syntax-error-order-v2.patch ___ Python tracker <http://bugs.python.org/issue28

[issue29002] typing.AnyStr doc is unclear about python2 unicode support

Changes by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <http://bugs.python.org/issue29002> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29011] No entry Deque in typing.py

Changes by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <http://bugs.python.org/issue29011> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29051] Improve error reporting involving f-strings (PEP 498)

Changes by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <http://bugs.python.org/issue29051> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28702] Confusing error message when None used in expressions, eg. "'NoneType' object has no attribute 'foo'"

Changes by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <http://bugs.python.org/issue28702> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28559] Unclear error message when raising wrong type of exceptions

Changes by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <http://bugs.python.org/issue28559> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29116] Make str and bytes error messages on concatenation conform with other sequences

Changes by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <http://bugs.python.org/issue29116> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29198] AsyncGenerator is missing from typing

Changes by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker <http://bugs.python.org/issue29198> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29246] typing.Union raises RecursionError when comparing Union to other type

Ivan Levkivskyi added the comment: Thank you for catching this corner case! I have made a PR upstream based on your patch: https://github.com/python/typing/pull/350 As I understand the fix will go in 3.6.1 and 3.5.4 -- ___ Python tracker <h

[issue29262] Provide a way to check for *real* typing.Union instances

Ivan Levkivskyi added the comment: In principle, such a function could be added if it is not called ``isinstance``. For example, we could add a helper ``is_union(tp)`` (or maybe also ``is_generic(tp)`` etc). Such function(s) will be simple one-liners wrapping private API in a right way (e.g

[issue29262] Provide a way to check for *real* typing.Union instances

Ivan Levkivskyi added the comment: This will be a bit unusual since ``isinstance`` is typically called for instances (i.e. not types) as in ``isinstance(func, Callable)``. But on the other hand this is probably what one would expect when one sees ``isinstance(tp, Union)``. Thus I am fine with

[issue29262] Provide a way to check for *real* typing.Union instances

Ivan Levkivskyi added the comment: > Maybe we need to take a step back and look at the needs for code that wants > to implement runtime type checking more in general? I would say that the most convenient way for me would be a set of "inspect-style" simple helpers

<    1   2   3   4   5   6   7   >