Yury Selivanov added the comment:
Uploading a new patch: sorted imports; added a unittest that exceptions in
loop.call_soon aren't breaking Task.__init__.
--
Added file: http://bugs.python.org/file45248/ctask3.patch
___
Python tracker
Yury Selivanov added the comment:
> Why isfuture() is moved, and asyncio.coroutine uses
> base_futures.isfuture() instead of futures.isfuture()?
Import cycles:
- `_asyncio` module is now being imported from `futures.py`
- and `_asyncio` is now imported from `tasks.py`;
- and `ta
Yury Selivanov added the comment:
> - and `tasks.py` imports `futures.py` to have `isfuture`.
And tasks.py also imports coroutines.py (which was importing futures.py),
making the cycle even worse. Anyways, I don't see a problem in moving a
function or two that everybody uses into a
Yury Selivanov added the comment:
I've committed the patch with a few touchups:
* Applied code-review feedback.
* We now use AC for all methods, including Task._repr_info, Task._step, etc.
See [1].
* I fixed the Task to be fully subclassable; users can override Task._step and
Task._w
Yury Selivanov added the comment:
> Can you please do it Yury?
Yes, Elvis and I will be the editors of What's New this year anyways ;)
--
___
Python tracker
<http://bugs.python.org
Yury Selivanov added the comment:
> Python 3.6 & default don't compile on Windows because of the change:
Pushed a fix for that.
--
___
Python tracker
<http://bugs.python
Yury Selivanov added the comment:
Looks like that Windows buildbot is green now. Closing.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
New submission from Yury Selivanov:
loop.call_soon is the central function of asyncio. Everything goes through it.
Current design of asyncio.loop.call_soon makes the following checks:
1. [debug mode] check that the loop is not closed
2. [debug mode] check that we are calling call_soon from
Changes by Yury Selivanov :
--
keywords: +patch
Added file: http://bugs.python.org/file45339/call_soon.patch
___
Python tracker
<http://bugs.python.org/issue28
Yury Selivanov added the comment:
> IIRC haypo added the check because people called `.call_later()` with
> coroutine instead of callback very often.
We'll update asyncio docs in 3.6 with a tutorial to focus on coroutines (not on
low-level event loop). This should leave the
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file45340/call_soon2.patch
___
Python tracker
<http://bugs.python.org/issue28600>
___
___
Python-bugs-list m
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file45341/call_soon3.patch
___
Python tracker
<http://bugs.python.org/issue28600>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
> LGTM
Will commit this soon.
> maybe make dirty hack and check hasattr(callback, 'send') ?
If you schedule a coroutine object it will fail anyways, because it's not
callable.
--
___
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
type: -> performance
___
Python tracker
<http://bugs.python
Yury Selivanov added the comment:
Guido, Andrew, thanks for reviews!
I've fixed some unittests before committing the patch.
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
> Looks like I forgot about this. My final fix still hasn't been applied, so
> the code in Py3.4+ is incorrect now.
Left a question in code review
--
___
Python tracker
<http://bugs.python.
Yury Selivanov added the comment:
+# Wake up the loop if the finalizer was called from
+# a different thread.
+self._write_to_self()
Yeah, looks like shutdown_asyncgens somehow ended up in 3.5 branch (there's no
harm in it being there). I'l
Yury Selivanov added the comment:
Serhiy, I think you forgot to attach the patch.
aiter_wrapper shouldn't ever receive tuples, so it should be fine with
PyErr_SetObject.
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
> No, this cannot be tested from the Python level.
Stefan, could you please upload a C program that showcases the bug you're
trying to fix?
--
___
Python tracker
<http://bugs.python.org
New submission from Yury Selivanov:
Proxy for https://github.com/python/asyncio/pull/452
--
assignee: yselivanov
components: asyncio
messages: 280064
nosy: gvanrossum, yselivanov
priority: normal
severity: normal
stage: resolved
status: open
title: Make get_event_loop() return the
Changes by Yury Selivanov :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue28613>
___
___
Python-bugs-list
Yury Selivanov added the comment:
I think I have a patch for this here: https://github.com/python/asyncio/pull/456
--
___
Python tracker
<http://bugs.python.org/issue28
Changes by Yury Selivanov :
--
title: Add a server_side keyword parameter to create_connection -> Add
loop.connect_accepted_socket
___
Python tracker
<http://bugs.python.org/issu
New submission from Yury Selivanov:
In short:
isfuture(unittest.mock.Mock()) should be False
isfuture(unittest.mock.Mock(Future)) should be True
This issue is a proxy for https://github.com/python/asyncio/pull/455
--
assignee: yselivanov
components: asyncio
messages: 280241
nosy
Changes by Yury Selivanov :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue28634>
___
___
Python-bugs-list
Changes by Yury Selivanov :
--
assignee: docs@python -> yselivanov
___
Python tracker
<http://bugs.python.org/issue28635>
___
___
Python-bugs-list mai
Yury Selivanov added the comment:
See https://github.com/python/asyncio/pull/452. I believe that the issue is not
resolved (almost).
What's left is documenting how to use get_event_loop and when to use
explicit/implicit loop passing.
Closing this issue. Will open a new one fo
Yury Selivanov added the comment:
Thank you! Will merge it tomorrow.
--
assignee: -> yselivanov
components: +Library (Lib) -asyncio
nosy: -gvanrossum
versions: -Python 3.5
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
This patch introduced multiple refleaks in test_asyncgen.
--
nosy: +yselivanov
resolution: fixed ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/i
Changes by Yury Selivanov :
--
nosy: +larry, ned.deily
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue26801>
___
___
Py
Yury Selivanov added the comment:
Ah, never mind, the commit message has a wrong issue number:
Issue #26801: Added C implementation of asyncio.Future.
Closing this one, will re-open #26081.
--
priority: release blocker -> normal
resolution: -> fixed
status: open -&g
Yury Selivanov added the comment:
This patch introduced multiple refleaks in test_asyncgen.
--
priority: normal -> release blocker
resolution: fixed ->
status: closed -> open
___
Python tracker
<http://bugs.python.or
Changes by Yury Selivanov :
--
priority: release blocker -> normal
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
Merged! Thank you, Justin.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: +Python 3.5
___
Python tracker
<http://bugs.python.or
Changes by Yury Selivanov :
--
assignee: yselivanov
components: Interpreter Core
nosy: haypo, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Drop __aiter__ compatibility layer from 3.7
type: behavior
versions: Python 3.7
New submission from Yury Selivanov:
As discussed in issue #27243, we want to drop __aiter__ compatibility layer in
Python 3.7. Please take a look at the attached patch (I'll inc importlib's
magic before committing).
--
keywords: +patch
Added file: http://bugs.python.org
Yury Selivanov added the comment:
The patch is causing refleaks:
test_ast leaked [98, 98, 98] references, sum=294
test_code leaked [2, 2, 2] references, sum=6
Please review the attached patch fixing that. Please review.
--
nosy: +benjamin.peterson, larry, ned.deily
Yury Selivanov added the comment:
Thanks, Paul. I'm adding Elvis to the nosy list, he's the main editor of What's
New in 3.6.
--
nosy: +Elvis.Pranskevichus, yselivanov
___
Python tracker
<http://bugs.pyt
Yury Selivanov added the comment:
Looks like the attached patch also fixes
test_trace leaked [12, 12, 12] references, sum=36
--
___
Python tracker
<http://bugs.python.org/issue27
Yury Selivanov added the comment:
Elvis, please take a look at http://bugs.python.org/issue28641
--
___
Python tracker
<http://bugs.python.org/issue28635>
___
___
Yury Selivanov added the comment:
> Interesting, what tests in test_ast leak? I expected that this branch is
> executed in rare circumstances.
The test that tests it all :) test_stdlib_validates
--
___
Python tracker
<http://bugs.p
Yury Selivanov added the comment:
Thanks for the review, Serhiy!
--
priority: release blocker -> normal
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Yury Selivanov:
Looks like we have a refleak somewhere in the system that typing.py is exposing.
The following code exposes the refleak:
def test_refleak(self):
T = typing.TypeVar('T')
class C(typing.Generic[T], typing.Mapping[int, str]): ...
Yury Selivanov added the comment:
> Could it be related to leaks in objects with empty __slots__? See issue24379
> for details.
Not sure... Do we have a test/patch for objects-with-empty-slots bug?
--
___
Python tracker
<http://bugs.p
Yury Selivanov added the comment:
Serhiy, maybe you know how to fix this?
--
nosy: +serhiy.storchaka
versions: +Python 3.7 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
Because the following works without a problem:
class F:
__slots__ = ('__name__', )
f = F()
f.__name__ = ''
This bug with __qualname__ is why _GeneratorWrapper in types.py doe
Yury Selivanov added the comment:
Attached patch (slots_gc.patch) makes objects with empty slots tracked by GC:
class A: __slots__ = ()
gc.is_tracked(A()) == False # before
gc.is_tracked(A()) == True # with the patch
This doesn't fix the refleak though.
--
keywords: +
Yury Selivanov added the comment:
I removed all slots from typing.py, the refleak is still there.
--
___
Python tracker
<http://bugs.python.org/issue28
Yury Selivanov added the comment:
Wow. In default CPython branch, with no modifications, test_typing.py simply
crashes in debug mode:
yury@ysmbp ~/dev/py/cpython $ ./python.exe -m test -R3:3 test_typing
Run tests sequentially
0:00:00 [1/1] test_typing
beginning 6 repetitions
123456
.test
Yury Selivanov added the comment:
The problem is that functools.lru_cache is used in _tp_cache. If I remove type
caching, the original "refleak" is fixed.
--
___
Python tracker
<http://bugs.python.o
Yury Selivanov added the comment:
Even more reduced test case:
def test_refleak(self):
T = typing.TypeVar('T')
typing.Generic[T]
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.o
New submission from Yury Selivanov:
The attached patch does the trick. I'm not sure if this should be fixed in 3.6.
--
components: Interpreter Core
files: slots_gc.patch
keywords: patch
messages: 280427
nosy: gvanrossum, serhiy.storchaka, yselivanov
priority: normal
severity: n
Yury Selivanov added the comment:
Josh, Serhiy,
I've created an issue for tracking empty slots types: #28651.
This issue is about typing.py using functools.lru_cache for internal cache That
is what causing the refleaks, and inability of test_typing.py to be run in
refleak hunting
Yury Selivanov added the comment:
> Good sleuthing! So the bug is in _lru_cache?
I don't think it's a bug of lru_cache. It stores strong references for
arguments and return value of the decorated function (which btw isn't
documented). I don't think it's possibl
Yury Selivanov added the comment:
> Does that patch fix the refleak completely or only partially?
I tried to empty the cache in test_typing.BaseTestCase.setUp and tearDown; this
doesn't fix all refleaks.
Do we have some other caches in t
Yury Selivanov added the comment:
> Yury, _tp_cache should be the only one (of course most generic classes have
> _abc_cache since GenericMeta inherits from ABCMeta)
Then there is at least one more bug not related to lru_cache (or any kind of
cache in typing).
And it's not classes
Yury Selivanov added the comment:
So this patch has no impact on typing.py. Moreover, it's incomplete and fails
test_gc tests, which can be fixed but not in 3.6.
--
versions: -Python 3.6
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
Serhiy's patch typing-clear-caches.patch looks good, we should apply it (fixing
the code style a little bit).
--
___
Python tracker
<http://bugs.python.org/is
New submission from Yury Selivanov:
Proxy for https://github.com/python/asyncio/pull/453
--
assignee: yselivanov
components: asyncio
messages: 280448
nosy: gvanrossum, yselivanov
priority: normal
severity: normal
stage: resolved
status: open
title: Make loop methods reject socket kinds
Changes by Yury Selivanov :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue28652>
___
___
Python-bugs-list
Changes by Yury Selivanov :
--
Removed message: http://bugs.python.org/msg280422
___
Python tracker
<http://bugs.python.org/issue24379>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
With all commits pushed, test_typing still seems to leak. Ivan, do you have
time to see what's going on?
test_typing leaked [125, 125, 125] references, sum=375
test_typing leaked [49, 49, 49] memory blocks, su
Yury Selivanov added the comment:
The specific test that leaks is test_extended_generic_rules_eq
--
___
Python tracker
<http://bugs.python.org/issue28649>
___
___
Yury Selivanov added the comment:
Ivan, this is the part of the test that leaks:
def test_extended_generic_rules_eq(self):
T = TypeVar('T')
U = TypeVar('U')
with self.assertRaises(TypeError):
Call
Yury Selivanov added the comment:
Oh. This is a bug in C implementation of functools.lru_cache. I'll take a look.
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
reflesk with only functools:
def test_lru_type_error(self):
@functools.lru_cache(maxsize=None)
def foo(o):
raise TypeError
with self.assertRaises(TypeError):
foo
Yury Selivanov added the comment:
Found it, will open a separate issue.
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Yury Selivanov:
The attached patch fixes a refleak in functools.lru_cache.
--
components: Library (Lib)
files: refleak.patch
keywords: patch
messages: 280468
nosy: gvanrossum, larry, ned.deily, serhiy.storchaka, yselivanov
priority: release blocker
severity: normal
Yury Selivanov added the comment:
See http://bugs.python.org/issue28653 for details.
--
___
Python tracker
<http://bugs.python.org/issue28649>
___
___
Python-bug
Yury Selivanov added the comment:
> FWIW, if I comment out this code
Oh boy... This is something else. Please re-open #28649 explaining that it now
leaks with pure-Python lru_cache. Could you please take a look at it?
--
___
Python tracker
&l
Yury Selivanov added the comment:
> It seems to be unrelated to typing.py
Wow. I can reproduce refleaks in test_typing, but not in test_functools. This
is weird.
--
___
Python tracker
<http://bugs.python.org/issu
Changes by Yury Selivanov :
--
stage: commit review -> needs patch
___
Python tracker
<http://bugs.python.org/issue28653>
___
___
Python-bugs-list mai
Yury Selivanov added the comment:
> Anyway, this is not urgent
Not so sure, a refleak in pure-python version kind of scares me. It can be a
bug in the core.
--
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
Ivan, I think I figured it out, I'll close this one and reopen the typing one.
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
title: refleak in functools.lru_cache -> refleak in C fu
Yury Selivanov added the comment:
So Ivan made an interesting observation: if we use Python version of
functools.lru_cache, typing tests start to leak like crazy:
beginning 6 repetitions
123456
..
test_typing leaked [24980, 24980, 24980] references, sum=74940
I
Yury Selivanov added the comment:
> But why is this so different from the C implementation of lru_cache?
I don't know. Maybe C version of lru cache creates a bit less pressure on GC.
BTW, if I set maxsize=10 for typing lru_cache, test_generic_forward_ref
crashes in refleak-t
Yury Selivanov added the comment:
>> But why is this so different from the C implementation of lru_cache?
> I don't know. Maybe C version of lru cache creates a bit less pressure on GC.
Actually test/refleak.py now cleans up typing's lru cache & calls
"gc.collect(
Yury Selivanov added the comment:
> Segfault or traceback?
Traceback. I should have said failed, not crashed :(
> I'm not sure a crash the Python version of
lru_cache with maxsize=10 is high on my list of worries.
The problem is that the test fails depending on cache size,
Yury Selivanov added the comment:
Good work, Ivan!
> Those two seem to fix everything, I tried various cache sizes with both C and
> Python versions of lru_cache and found no refleaks.
Speaking of lru_cache: typing currently doesn't configure maxsize, which means
that the cache is
Yury Selivanov added the comment:
Thank you Guido and Ivan!
> Yury, when you're happy with the situation can you close this issue?
I'll close it now, will reopen if something comes up.
--
resolution: -> fixed
status: open -> closed
___
Yury Selivanov added the comment:
Closing this one.
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
type: -> enhancement
___
Python tracker
<http://bugs.python
Yury Selivanov added the comment:
Can we commit this to 3.6 too?
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue28618>
___
___
Python-bug
Yury Selivanov added the comment:
I'll go through whatsnew on Monday, fixing errors etc.
--
___
Python tracker
<http://bugs.python.org/issue28635>
___
___
Changes by Yury Selivanov :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue28703>
___
___
Python-bugs-list
New submission from Yury Selivanov:
Proxy for https://github.com/python/asyncio/pull/459
--
assignee: yselivanov
components: asyncio
messages: 280886
nosy: gvanrossum, yselivanov
priority: normal
severity: normal
stage: resolved
status: open
title: Fix asyncio.iscoroutinefunction to
Changes by Yury Selivanov :
--
assignee: yselivanov
components: asyncio
nosy: gvanrossum, yselivanov
priority: normal
severity: normal
stage: resolved
status: open
title: Fix create_unix_server to support Path-like objects (PEP 519)
type: behavior
versions: Python 3.6, Python 3.7
New submission from Yury Selivanov:
Proxy for https://github.com/python/asyncio/pull/462
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
New submission from Yury Selivanov:
This patch adds collections.abc.AsyncGenerator (closely modelled after
collections.abc.Generator).
Ned, is it OK if this goes into 3.6? This is something I completely forgot to
do as part of PEP 525. This ABC is needed for asynchronous generators compiled
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file45513/agen_abc.patch
___
Python tracker
<http://bugs.python.org/issue28720>
___
___
Python-bugs-list m
Changes by Yury Selivanov :
Removed file: http://bugs.python.org/file45512/agen_abc.patch
___
Python tracker
<http://bugs.python.org/issue28720>
___
___
Python-bugs-list m
New submission from Yury Selivanov:
1. aclose() should not propagate StopAsyncIteration:
async def agen():
try:
yield
except:
pass
gen = agen()
await agen.asend(None)
await agen.aclose() # <- this shouldn't raise StopAsyncIteration
2. athrow(
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Yury Selivanov :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue28721>
___
___
Python-bugs-list
Yury Selivanov added the comment:
Thanks Ned. I went ahead and committed the patch.
--
___
Python tracker
<http://bugs.python.org/issue28720>
___
___
Python-bug
Yury Selivanov added the comment:
This isn't a bug. Python doesn't magically unwind awaitables, you have to do
that yourself:
async def two():
await (await one())
Broadly speaking, returning awaitables from coroutines is an anti-pattern.
Closing this one. Feel free to re-o
New submission from Yury Selivanov:
Can f-strings be used as docstrings?
Right now:
class Foo:
f'spam'
Foo.__doc__ is None
I couldn't find that f-strings cannot be used as docstrings in neither PEP 498
not in the 3.6 documentation, so I suppos
Yury Selivanov added the comment:
> IMO it would be simpler do disallow all f-strings as docstrings.
How exactly you want to disallow them? Raise SyntaxError? If you don't raise
anything, then the behaviour is just confusing -- the interpreter parses them,
but __doc__ is None.
I th
New submission from Yury Selivanov:
The PEP should document the "single '}' is not allowed" error.
--
assignee: docs@python
components: Documentation
messages: 281173
nosy: docs@python, eric.smith, yselivanov
priority: normal
severity: normal
status: open
title: PE
3001 - 3098 of 3098 matches
Mail list logo
