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.pyt
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29922>
___
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 automatical
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
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/i
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
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
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17792>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29593>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +667
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24796>
___
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
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +538
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28810>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +547
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28810>
___
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.p
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +387
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29638>
___
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 (n
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +395
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29638>
___
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,
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 chan
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +394
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29638>
___
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.
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__(). Mak
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29727>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29974>
___
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/librar
Ivan Levkivskyi added the comment:
> Do you have any idea?
Unfortunately no.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
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
n
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
assignee: -> levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
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
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&qu
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
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
assignee: -> levkivskyi
stage: -> needs patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
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)
--
___
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.or
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30196>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30145>
___
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
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
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: ->
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
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
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30463>
___
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
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
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
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/i
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +2140
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28556>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +1475
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28556>
___
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 -&g
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
keywords: +patch
pull_requests: +3543
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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]
(fo
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
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
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 'collectio
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
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +brett.cannon, haypo, serhiy.storchaka, yselivanov
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +4068
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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 tracke
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.pyt
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: -levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue10544>
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
keywords: +patch
pull_requests: +4501
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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
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(awa
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
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.or
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, _tog
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
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.pyt
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/issu
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 e
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
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 som
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
assignee: levkivskyi ->
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +4621
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28556>
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +4800
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32226>
___
Ivan Levkivskyi <levkivs...@gmail.com> 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 <rep.
Ivan Levkivskyi <levkivs...@gmail.com> 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
Ivan Levkivskyi <levkivs...@gmail.com> 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/
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32320>
___
Ivan Levkivskyi <levkivs...@gmail.com> 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 obje
Ivan Levkivskyi <levkivs...@gmail.com> 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/5364b5cd7571f2dfa75acd37b388c14ac3
Ivan Levkivskyi <levkivs...@gmail.com> 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 i
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.
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.
New submission from Ivan Levkivskyi <levkivs...@gmail.com>:
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
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
keywords: +patch
pull_requests: +4635
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Oops something wrong happened.
--
nosy: +gvanrossum
stage: patch review ->
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Ivan Levkivskyi <levkivs...@gmail.com> 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
<
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
keywords: +patch
pull_requests: +4634
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
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 type
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
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: Pyth
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32216>
___
Ivan Levkivskyi <levkivs...@gmail.com> 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
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32284>
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32162>
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27051>
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue23551>
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
assignee: -> levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> Bug or not this is not going to change without a PEP, so I'm not sure it's a
> good idea to keep this issue open.
I agree this requires a PEP. I would like to keep this open as a place for
pre-PEP discussions among thos
201 - 300 of 680 matches
Mail list logo
