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>:
--
keywords: +patch
pull_requests: +4501
stage: -> patch review
___
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>
___
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:
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:
> 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
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:
... 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:
(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:
> 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:
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
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:
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
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
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.
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>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27051>
___
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
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
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
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:
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:
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 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
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +brett.cannon, haypo, serhiy.storchaka, yselivanov
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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:
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:
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
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:
> 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:
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:
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
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:
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
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
assignee: -> levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
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>
___
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
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:
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>:
--
pull_requests: +1475
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28556>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30145>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30196>
___
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
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)
--
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
assignee: -> levkivskyi
stage: -> needs patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
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>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29974>
___
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>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29922>
___
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>:
--
pull_requests: +667
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24796>
___
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>
___
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:
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>:
--
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 this is fixed on master, but the problem still appears on 3.6
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +547
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28810>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +538
___
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>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29727>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +395
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29638>
___
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:
> 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
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:
> 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
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:
> 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: +387
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29638>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +243
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28556>
___
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
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +237
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28556>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +217
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28810>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +201
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28810>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +200
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26213>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26213>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29546>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29581>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11339>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29481>
___
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 tho
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
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/i
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/i
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 rang
Ivan Levkivskyi added the comment:
I have found one typo (see Rietveld), otherwise LGTM.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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
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)). Str
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
401 - 500 of 689 matches
Mail list logo
