[issue32162] typing.Generic breaks __init_subclass__
Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29879] typing.Text not available in python 3.5.1
Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- keywords: +patch pull_requests: +4501 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: -levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > How about not posting about this topic for 24 hours. OK, makes sense :-) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Guido, I am not sure about the complete removal, this is probably to radical. What I think we are missing more detailed docs that would be clear about the corner cases. (I already mentioned this in https://bugs.python.org/issue32113) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Yury OK, sorry then this is a misunderstanding from my side. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > Do you understand the difference? Yury, sorry, but what is your problem? Have I said something about that this is bad. Your tone is clearly insulting, and this is not the first time. Maybe it makes sense to have some respect? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Well, after all I am thinking maybe it is indeed makes sense to ban `yield` inside both sync/async and both comprehensions/generator expressions. Since we already have a smörgåsbord of intuitive behaviors. This, _together_ with extensive clarification to the docs and error messages can fix the problem. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: ... but [await x for x in xs] is still valid _only_ inside async def. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: (Of course there should be not [1, 2] in the argument, but a list of some awaitables, otherwise there will be an error later.) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > Remind me what happens when you use `await` in a generator expression that > survives the async function's scope? Awaiting on f([1, 2]) will result in an async generator (even though yield never appears here). Yury explained why this happens in https://bugs.python.org/issue32113 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Nick, > Yury took all this into account when designing the interaction between > `await` and comprehensions (which is why that's in a better state), but for > `yield` we inherited the existing behaviour of any other nested function. Actually the fact that `await` in comprehensions already works right is one of my main arguments that we can also fix `yield`. So I am totally with Serhiy here. -- nosy: +yselivanov ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- assignee: levkivskyi -> ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32113] Strange behavior with await in a generator expression
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: A first simple idea that comes to my mind is special-case async generators/iterators in PyObject_GetIter to say something like: TypeError: asynchronous iterable can't be used where an iterable is expected If it is possible to detect that an async generator is resulting from a generator expression, then we can say: TypeError: asynchronous generator expression can't be used as an iterable -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32113] Strange behavior with await in a generator expression
New submission from Ivan Levkivskyi <levkivs...@gmail.com>: PEP 530 is not very clear about `await` in generator expressions. But when I try it, the error is a bit confusing: >>> async def g(i): ... print(i) ... >>> async def f(): ... result = list(await g(i) for i in range(3)) ... print(result) ... >>> f().send(None) Traceback (most recent call last): File "", line 1, in File "", line 2, in f TypeError: 'async_generator' object is not iterable At the same time a (seemingly) equivalent list comprehension works fine: >>> async def f(): ... result = [await g(i) for i in range(3)] ... print(result) ... >>> f().send(None) 0 1 2 [None, None, None] Traceback (most recent call last): File "", line 1, in StopIteration I would say that the first case should either behave as a second one, or raise a syntax error. Or is it actually an intended behavior? -- components: Interpreter Core messages: 306732 nosy: levkivskyi, yselivanov priority: normal severity: normal status: open title: Strange behavior with await in a generator expression type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32018] inspect.signature does not respect PEP 8
New submission from Ivan Levkivskyi <levkivs...@gmail.com>: The string representation of a function signature with annotations is currently like this: >>> def __init__(self, x: int = 1, y: int = 2) -> None: pass ... >>> import inspect >>> str(inspect.signature(__init__)) '(self, x:str=1, y:int=2) -> None' At the same time PEP 8 says: When combining an argument annotation with a default value, use spaces around the = sign (but only for those arguments that have both an annotation and a default). Yes: def munge(sep: AnyStr = None): ... def munge(input: AnyStr, sep: AnyStr = None, limit=1000): ... No: def munge(input: AnyStr=None): ... def munge(input: AnyStr, limit = 1000): ... I think there should be spaces in the signature repr. -- messages: 306171 nosy: levkivskyi, yselivanov priority: normal severity: normal status: open title: inspect.signature does not respect PEP 8 type: behavior versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31700] one-argument version for Generator.typing
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: Since there is no response for few weeks I assume this works for you. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23551] IDLE to provide menu link to PIP gui.
Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue23551> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27051] Create PIP gui
Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27051> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.org> <https://bugs.python.org/issue28936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28936] test_global_err_then_warn in test_syntax is no longer valid
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: > Am I needed here? As I understand, Serhiy is going to review the PR, so I think no. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28936] test_global_err_then_warn in test_syntax is no longer valid
Ivan Levkivskyi <levkivs...@gmail.com> added the comment: OK, I made a PR with the fix and a test that checks the line number for syntax error (so that the original purpose test_global_err_then_warn is preserved). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28936] test_global_err_then_warn in test_syntax is no longer valid
Change by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +4068 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31700] one-argument version for Generator.typing
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
You can use Iterator type, for example this works in mypy (didn't test in other
type checkers):
def f() -> Iterator[int]:
yield 42
In case you want annotate something specifically as Generator[int, None, None]
(for example to use its .close() method), then you can create a generic alias:
T = TypeVar('T')
Gen = Generator[T, None, None]
def f() -> Gen[int]:
...
this is supported by mypy as well.
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31700>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29966] typing.get_type_hints doesn't really work for classes with ForwardRefs
Ivan Levkivskyi added the comment: This is now fixed (to a reasonable extent) by https://github.com/python/cpython/commit/f350a268a7071ce7d7a5bb86a9b1229782d4963b on master, and backported to 3.6. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29966> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28556] typing.py upgrades
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- keywords: +patch pull_requests: +3543 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31333] Implement ABCMeta in C
Ivan Levkivskyi added the comment: Eric, > the only ABCs in importlib are in importlib.abc (and used by importlib.util). > This does not impact interpreter startup. Hm, indeed, but I see that module 'abc' is in 'sys.modules', probably it is then only used by 'collections.abc'/'_collections_abc'. This means that the influence of 'ABCMeta' on interpreter start-up time will be smaller than I thought. But still start-up times for projects that actively use ABCs will be influenced by 'ABCMeta'. But what do you think about making private ABC caches read-only attributes? (They are not documented) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31333> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31333] Implement ABCMeta in C
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +brett.cannon, haypo, serhiy.storchaka, yselivanov ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31333> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31333] Implement ABCMeta in C
New submission from Ivan Levkivskyi: The idea is that creating ABCs is approximately twice slower than normal classes. Plus there are smaller penalties for various operations with ABCs. This mostly influences the Python interpreter start-up time (because of extensive use of ABCs in importlib), and start-up times of programs that extensively use ABCs. The situation can be improved by rewriting ABCMeta in C. I have a working implementation, but it is far form being ready and still needs some polishing and optimizations (in particular _abc_cache and friends). Already at this stage I have one question (I will add more when they appear while I am finishing the implementation): is it OK to make _abc_cache, _abc_negative_cache, _abc_negative_cache_version, and _abc_registry read-only? The point is that I want to prohibit something like this: MyABC._abc_cache = "Surprise on updating the cache!" thus avoiding many PySet_Check(...) calls. These attributes are not documented and start with underscore. -- components: Extension Modules, Library (Lib) messages: 301198 nosy: barry, levkivskyi priority: normal severity: normal status: open title: Implement ABCMeta in C type: performance versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31333> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31272] typing module conflicts with __slots__-classes
Ivan Levkivskyi added the comment: It is listed in Misc/NEWS as "minor bug fixes" in typing module, I don't think this is something that deserves a separate line in release notes. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31272> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31272] typing module conflicts with __slots__-classes
Ivan Levkivskyi added the comment: I think this is fixed in latest version. I thought it was also backported to Python 3.5.3. What is the version you are using? Could you please try updating to the latest bugfix release? (currently these are 3.5.4 and 3.6.2). -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31272> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
Ivan Levkivskyi added the comment: TBH, I think this is a Sphinx problem, not a Python problem. And concerning ``Tuple`` being an actual class I think this is an implementation detail, so that I am closing this as "won't fix". -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
Ivan Levkivskyi added the comment: > For the end user the fact that this is a class is still hidden I am not sure what you mean by this, but with your PR the rendered docs will literally say ``class typing.Tuple``. > We should probably add a unit test that makes sure all runtime "type" matches > with documentation "type" in the future I already mention, this was not an omission but a deliberate decision, see http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst#newcode444 (and below the same for Callable) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
Ivan Levkivskyi added the comment: Bernát, I would recommend asking this on Sphinx tracker (I also assigned this to docs@python since this seems to be a purely documentation issue). https://github.com/sphinx-doc/sphinx -- assignee: -> docs@python components: +Documentation nosy: +docs@python type: -> enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
Ivan Levkivskyi added the comment: > Do you have any idea? Unfortunately no. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
Ivan Levkivskyi added the comment: > This ticket is about fix objects.inv to have the Tuple in the correct bucket. If you know how to do this without breaking the python docs system (so that Tuple and Callable will not have a "class" prefix on https://docs.python.org/3/library/typing.html) then I think it is OK. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31006] typing.NamedTuple should add annotations to its constructor (__new__) parameters.
Ivan Levkivskyi added the comment: This looks like a reasonable idea, if it is possible to implement this without complications. Would you like to submit a PR at https://github.com/python/typing ? (We have a separate upstream repo for typing while it is provisional.) -- nosy: +levkivskyi stage: -> needs patch type: -> enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
Ivan Levkivskyi added the comment: The fact that it is a class is an implementation detail and may change before Python 3.7 beta (situation is the same for Callable). Guido explicitly doesn't like to "advertise" it as a class yet. Unless he changed his mind, I would propose to close the issue, and instead consider treating this special case in Sphinx. -- nosy: +gvanrossum, levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25988] collections.abc.Indexable
Ivan Levkivskyi added the comment: Names from collections.abc are re-exported to collections for backward compatibility. IIRC Serhiy also wanted to stop re-exporting them. I am not sure whether we need any "deprecation period" for this. -- nosy: +serhiy.storchaka ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25988] collections.abc.Indexable
Ivan Levkivskyi added the comment: Raymond, > The existence of use ABCs like MutableMapping is being drowned-out by > one-trick-ponies. We're developing an unfavorable ratio of theoretical > building blocks versus the practical tools. Why do you think they are "theoretical"? FWIW, a simple search on GitHub for abc.X gives this: Sequence 322K Mapping 267K Iterable 244K Container 99K MutableMapping 77K I don't see any pattern here (although this may be only anecdotal evidence :-) > Other than a feeling of lightness, I don't think this proposal does anything > for us. This proposal makes more sense (and motivation) in the context of static typing, since it is a good way to know how __getitem__ is going to be used -- from its static type. Something typed with Subscriptable[int, T] would accept both Sequence[T] and Mapping[int, T]. The latter two are currently differentiated by __reversed__ (Sequence is Reversible as opposed to Mapping). Concerning an invariant that order of iteration is consistent with indexing by subsequent integers, I think this can't be checked reliably neither statically, nor by any simple runtime isinstance check. For example a subclass can override Indexable.__iter__ and break the iteration order. We can still add it, and rely on user cooperation. Anyway, I am not insisting on adding either Subscriptable nor Indexable, but I think it is important that these things are discussed in view of PEP 544. Alternative proposal would be to add Subscriptable and its subclass Indexable only to typing as protocols (with some special-casing in type checkers for the latter to provide a higher level of contract). (Concerning the name, I think Enumerable sounds better than Indexable, IIUC the idea is to work correctly with enumerate.) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25988] collections.abc.Indexable
Ivan Levkivskyi added the comment: The last few weeks something bothered while working on Protocols PEP: protocols should be ideally compact (and PEP already emphasizes this). However, the only potential candidates for __getitem__ are Sequence and Mapping, that are both quite bulky (half dozen members each). I was thinking about different options like adding BaseMap as a base for Mapping and Sequence that will only have __getitem__. I expect this to be a popular protocol, since often people just need something that can be subscripted. Fortunately I stumbled into this issue. It looks like the optimal way now is: * Have an abstract base class (let's call it BaseMap, although I don't really like this name) in collections.abc that has only __getitem__ method. * It will be inherited by both Sequence and Mapping, but for the purpose of static typing, Sequence[T] will be a subtype of BaseMap[int, T], while Mapping[KT, VT] will be a subtype of BaseMap[KT, VT]. * BaseMap will be contravariant in key, this will solve problems with Mapping (invariant in key), for example a function that expects BaseMap[str, int] will accept Dict[Union[str, unicode], int]. * BaseMap will be a protocol in typing, so that people can extend it depending on their needs (e.g. add a .get() method). Guido, Łukasz if you agree, then I will add this to the Protocols PEP and will make a PR to collections.abc. We need to agree on the name, there are two options now: BaseMap and Indexable. I don't like the second since I would rather have it as a generic alias: Indexable = BaseMap[int, T]. However, BaseMap is also not very good, since I want something more "neutral" between Mapping and Sequence. -- assignee: -> levkivskyi nosy: +levkivskyi, lukasz.langa versions: +Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- assignee: -> levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30619] typing.Union doc incoherence in case a class and its subclass are present
Ivan Levkivskyi added the comment: Yes, you are right. Could you please make a PR at https://github.com/python/cpython/pulls ? -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28556] typing.py upgrades
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +2140 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30518] Import type aliases from another module
Ivan Levkivskyi added the comment: > Block = [int, Tuple[int]] > Blocks = List[Block] These are both invalid type aliases (I have no idea why PyCharm does not flag them, you could report this at PyCharm issue tracker). I am not sure what exactly you want. If you want a list of either integers or tuples of integers, then you should write for example: Block = Union[int, Tuple[int, ...]] Blocks = List[Block] Concerning import, this is definitely not a problem with aliases. What I have noticed is that you write "I have a 'base' module ..." and then "from base_module import ...", if you have a module named base.py, then you should write: from base import Blocks, Tags Or maybe you just have an import cycle... -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30505] Performance of typing._ProtocolMeta._get_protocol_attrs and isinstance
Ivan Levkivskyi added the comment: Thanks for reporting! The runtime implementation of protocol classes will be thoroughly reworked as a part of PEP 544, see also https://github.com/python/typing/pull/417 for a proof of concept runtime implementation. Also, there is another ongoing discussion https://github.com/python/typing/issues/432 about a global refactoring of typing module that will significantly improve performance. Therefore, I would wait with any large PRs until these two stories are settled. If you still want to propose a small PR, you can do this at the upstream typing repo https://github.com/python/typing -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30463] Add __slots__ to ABC convenience class
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30359] A standard convention for annotating a function as returning an (async) context manager?
Ivan Levkivskyi added the comment: Or you can use typing.ContextManager[ret_type] if you like generics (typing.AsyncContextManager will be also added soon). Also this recent discussion seems relevant https://github.com/python/peps/pull/242 and the corresponding thread on python-dev: https://www.mail-archive.com/python-dev@python.org/msg95595.html -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29262] Provide a way to check for *real* typing.Union instances
Ivan Levkivskyi added the comment: The discussed functionality is published as a separate package: https://pypi.python.org/pypi/typing-inspect https://github.com/ilevkivskyi/typing_inspect After the API is settled, some introspection functions may be added directly to typing. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28556] typing.py upgrades
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +1475 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30145] Create a How to or Tutorial documentation for asyncio
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30196] Add __matmul__ to collections.Counter
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30196> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29974] Change typing.TYPE_CHECKING doc example
Ivan Levkivskyi added the comment: > Sorry for making a typo in your last name No problem! This actually happened maaany times with me :-) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29974] Change typing.TYPE_CHECKING doc example
Ivan Levkivskyi added the comment: > 87c07fe9d908d0a2143fcc8369255c6ff3241503 should still be backported to 3.5 > and 3.6 branches so please don't close it yet. Thanks for making backport PRs! (and sorry for closing prematurely) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29727] collections.abc.Reversible doesn't fully support the reversing protocol
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- assignee: -> levkivskyi stage: -> needs patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29974] Change typing.TYPE_CHECKING doc example
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29974] Change typing.TYPE_CHECKING doc example
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29966] typing.get_type_hints doesn't really work for classes with ForwardRefs
Ivan Levkivskyi added the comment: You could try: glob = globals.copy() glob.update(a.__dict__) glob.update(b.__dict__) You can do this automatically following MyClass.__mro__ and then collecting relevant __module__ attributes on bases. However, there is little chance this will be fixed in typing itself. It is difficult to cover all possible cases, so that users should choose custom globals/locals for their needs. -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29966> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29922] error message when __aexit__ is not async
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29922> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28810] Document bytecode changes in 3.6
Ivan Levkivskyi added the comment: Thanks Brett! I think this could be closed now. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24796] Deleting names referencing from enclosed and enclosing scopes
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +667 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24796> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17792] Unhelpful UnboundLocalError due to del'ing of exception target
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29593] Improve UnboundLocalError message for deleted names
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29593> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29116] Make str and bytes error messages on concatenation conform with other sequences
Ivan Levkivskyi added the comment: Something is strange: PRs 709, 723, 724 are shown as open in the "Pull Requests" section on this page. However, all four PRs are already merged. Are other see the same? Shouldn't status be automatically updated? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29116> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24796] Deleting names referencing from enclosed and enclosing scopes
Ivan Levkivskyi added the comment: It looks like it is safe to just remove this line from docs. This code >>> x = 1 >>> def f(): ... global x ... del x ... >>> f() >>> x Works as expected, i.e. raises NameError. (The same happens for nonlocal but with UnboundLocalError.) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24796> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21253] unittest assertSequenceEqual can lead to Difflib.compare() crashing on mostly different sequences
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- versions: +Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28980] ResourceWarning when imorting antigravity in 3.6
Ivan Levkivskyi added the comment: It looks like this is fixed on master, but the problem still appears on 3.6 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29822] inspect.isabstract does not work on abstract base classes during __init_subclass__
Ivan Levkivskyi added the comment: Serhiy, sorry for a distraction, but it looks like here is one more situation where inspect.isabstract is problematic, similar to what was discussed in http://bugs.python.org/issue29638 recently. -- nosy: +levkivskyi, serhiy.storchaka ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28810] Document bytecode changes in 3.6
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +547 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28810] Document bytecode changes in 3.6
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +538 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28810] Document bytecode changes in 3.6
Ivan Levkivskyi added the comment: It looks like there are still few things that are not covered in two open PRs. I will add these in an additional PR in the next few days. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29727] collections.abc.Reversible doesn't fully support the reversing protocol
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29638] Spurious failures in test_collections in releak hunting mode after typing is imported
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +395 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29638] Spurious failures in test_collections in releak hunting mode after typing is imported
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +394 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29638] Spurious failures in test_collections in releak hunting mode after typing is imported
Ivan Levkivskyi added the comment: > Seems this has fixed issue25744. This is interesting, if I remember correctly the relevant typing classes were added only recently. I will take a look at how to back-port this (probably this will require some code changes) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29638] Spurious failures in test_collections in releak hunting mode after typing is imported
Ivan Levkivskyi added the comment: > If you just want to add a workaround in dash_R_cleanup, I think it would be > better to generate the list of all abstract classes and add three typing > classes to it. Yes, I just updated the PR. I have found something else unrelated to typing, this test (in exactly this order): ./python -m test -R 5:5 test_abc test_functools fails with a reproducible pattern: test_functools leaked [0, 3, 1, 0, 0] memory blocks, sum=4 If you are happy with the PR now, we could open two separate issues for possible bug in inspect.isabstract and refleak in test_functools after test_abc. (the latter however might be potentially somehow related to abc caches) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29638] Spurious failures in test_collections in releak hunting mode after typing is imported
Ivan Levkivskyi added the comment: > What if explicitly set __abstractmethods__ = True for these types? Unfortunately this does not help. I think this is because dash_R_cleanup only clears caches for classes in collections.abc.__all__ and their immediate .__subclasses__(). Making this recursive (i.e. also clearing caches of __subclasses__() of __subclasses__() etc) will probably fix the problem (provided we also add __abstractmethods__ = True). However, this looks a bit too complex for me. I would rather add few more typing._cleanups (anyway this failure only happens with typing ABCs) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29638] Spurious failures in test_collections in releak hunting mode after typing is imported
Ivan Levkivskyi added the comment: > Are typing.ChainMap and others actually abstract classes? They are abstract classes in the sense that they are instances of abc.ABCMeta. However, for some reasons inspect checks __flags__ attribute. The latter probably reflects the fact that Deque etc. do not have abstract methods (they still need to be instances of abc.ABCMeta because they need to be generic). I don't think that we need to change behaviour of inspect because it could be backward incompatible. I would either make changes to refleak or typing (adding few more cleanups in either place). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29638] Spurious failures in test_collections in releak hunting mode after typing is imported
Ivan Levkivskyi added the comment: > why not add corresponding clearing methods obj._abc_cache.clear and > obj._abc_negative_cache.clear to typing._cleanups ? OK, this is another possible solution. I didn't think about this, because now typing._cleanups only clear generic caches (not ABC caches). > Why there are problems only with ABC caches of these three types? Normally, ABC caches are cleared in dash_R_cleanup, but I think that the problem is that inspect.isabstract returns False for these three types (unlike other types in typing module), see line 147 in refleak.py: if not isabstract(abc): continue Actually now I think that the code in dash_R_cleanup might not clear some other caches also. So maybe we just need to add all ABC caches to typing._cleanups (just in case). What do you think, Serhiy? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29638] Spurious failures in test_collections in releak hunting mode after typing is imported
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +387 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28556] typing.py upgrades
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +243 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29638] Spurious failures in test_collections in releak hunting mode after typing is imported
New submission from Ivan Levkivskyi:
This command:
./python -c 'import runpy, typing; runpy.run_module("test")' -R 5:5
test_collections
Sometimes gives spurious failures like this:
test_collections leaked [0, 0, 3, -3, 3] memory blocks, sum=3
I think this is because ABC caches of typing.ChainMap, typing.Counter, and
typing.DefaultDict are not cleared by refleak.py/dash_R_cleanup (presumably
because inspect.isabstract returns False on those)
Adding a manual clean-up of these cashes to cleanup_cashes() fixes the "leak".
--
assignee: levkivskyi
components: Tests
messages: 288495
nosy: gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Spurious failures in test_collections in releak hunting mode after
typing is imported
type: resource usage
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29638>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28556] typing.py upgrades
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +237 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28810] Document bytecode changes in 3.6
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +217 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28810] Document bytecode changes in 3.6
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +201 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26213] Document BUILD_*_UNPACK opcodes
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- pull_requests: +200 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26213] Document BUILD_*_UNPACK opcodes
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29546] A more helpful ImportError message
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29546> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta)
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11339] annotation for class being defined
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11339> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque
Changes by Ivan Levkivskyi <levkivs...@gmail.com>: -- nosy: +levkivskyi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29377] Add the 'wrapper_descriptor' type to the types module
Ivan Levkivskyi added the comment: Guido, I attach the full patch now, as you asked. (Initially I was not sure about tests, but now I understand more these types, so that I added even few more tests than in original patch) > Maybe we need to wait for the github migration to complete though? I think it is OK to merge this now, but if it would be easier for you then it is not a problem to wait until GH migration is complete. Manuel, I think that probably the answer is yes, but I would prefer a separate issue for the inspect module. You could open a new issue and mention this one as a dependency. -- Added file: http://bugs.python.org/file46477/combined-patch-full-total.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29377] Add the 'wrapper_descriptor' type to the types module
Ivan Levkivskyi added the comment: Thank you! The new patch LGTM. (I combined two diffs in your patch into one so that it could be understood by Rietveld). Guido, Yury, could one of you please take a look at this? -- nosy: +yselivanov Added file: http://bugs.python.org/file46457/combined-patch.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29262] Provide a way to check for *real* typing.Union instances
Ivan Levkivskyi added the comment: Cross-posting the link to upstream work on this: https://github.com/python/typing/pull/377 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29310] Document typing.NamedTuple default argument syntax
Ivan Levkivskyi added the comment: Thank you! Guido, I think this is ready to be merged. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Ivan Levkivskyi added the comment: > How about fixing CPython to raise SyntaxWarning or even SyntaxError? I think it is better to just fix the issue, i.e. make comprehensions be equivalent to for-loops even if they contain `yield`. (In particular this will lead to [(yield i) for i in range(5)] be SyntaxError outside function). The example of `await` shows that it is possible without leaking the loop variable into enclosing scope. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29310] Document typing.NamedTuple default argument syntax
Ivan Levkivskyi added the comment: I have found one typo (see Rietveld), otherwise LGTM. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29377] Add the 'wrapper_descriptor' type to the types module
Ivan Levkivskyi added the comment: Manuel, thank you for the new patch now everything works. I have few more comments: 1. I have found that there is one more built-in type: type(str.join) gives . Maybe it makes sense to add this one too? 2. Taking into account previous point I withdraw my idea of needing tests here. Sorry for changing opinion twice, but it looks like there are many built-in types that seem to exist just for historical reasons. They might change in future. 3. Please take a look at my review on documentation in Rietveld. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29377] Add the 'wrapper_descriptor' type to the types module
Ivan Levkivskyi added the comment:
> but an isinstance test seems pretty redundant.
Tests are never redundant :-) Just add one-two asserts that you think should be
true about issubclass and isinstance with these types (like
self.assertIsInstance(''.__add__, types.MethodWrapperType)). String
representation on the contrary is less important.
For some reason your patch is still not recognized by review tool. But don't
worry about this, if it will not work, I will try to fix it.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29377>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29377] Add the 'wrapper_descriptor' type to the types module
Ivan Levkivskyi added the comment: Manuel, thank you for a patch! Two comments: 1. Please produce your patch using Mercurial ``hg diff`` command, so that it could be recognized by review tool and merged easily. 2. Your patch should also include few tests (Lib/test/test_types.py) and documentation (Doc/library/types.rst) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
