Yury Selivanov added the comment:
Guido, Martin, I've just posted to python-dev about this ticket. Let's see
what others think.
--
___
Python tracker
<http://bugs.python.o
Yury Selivanov added the comment:
Can someone try the patch? I'm fairly confident it should work, and it'd be
great to have it fixed in 3.5.1.
--
priority: high -> release blocker
___
Python tracker
<http://bugs.pytho
Yury Selivanov added the comment:
> Sorry to throw a potential spanner in the works, but I think this introduces
> a dependence on the readline module. Consider what happens when the Completer
> class is used but Readline is not, or even if the “readline” could not be
> imported
Yury Selivanov added the comment:
> At least it is better in 3.5 and only affects one platform now, instead of
> all of them.
No, it affects any platform where CPython is compiled with libedit instead of
readline. And even if it was one platform - OS X is big, bigger than Windows
pr
Changes by Yury Selivanov :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue25660>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Let's not export the Server class -- in uvloop, for instance, I have a
completely different internal implementation of Server (I can't use the one
from asyncio).
--
___
Python tracker
<http://bu
Yury Selivanov added the comment:
> Yeah, I recall this point. The doc points to Server, but Guido didn't
want to expose "implementation details" of Server like sockets.
Different implementations of event loops (Yury gave the good example
of uvloop based on libuv) don't
Yury Selivanov added the comment:
Trying to reproduce without contextstack.
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue25779>
___
___
Pytho
Yury Selivanov added the comment:
Here's a minimal test to reproduce:
import reprlib
def main():
if 0:
yield
raise RuntimeError
m = main()
try:
m.send(None)
except RuntimeError as ex:
ex.__context__ = ex
reprlib.re
New submission from Yury Selivanov:
The below code blocks Python eval loop and makes it unresponsive to signals
(like ^C).
import reprlib
try:
raise RuntimeError
except RuntimeError as ex:
ex.__context__ = ex
reprlib.repr(ex)
--
components: Library
Yury Selivanov added the comment:
Created another issue for the reprlib bug: issue 25781. It appears we don't
even need a generator:
import reprlib
try:
raise RuntimeError
except RuntimeError as ex:
ex.__context__ = ex
reprlib.repr(ex)
Closing thi
Yury Selivanov added the comment:
This isn't a bug of reprlib -- it's something in the core. Will create a
separate issue for this.
try:
raise Exception
except Exception as ex:
ex.__context__ = ex
hasattr(1, 'aa')
--
resolution:
Yury Selivanov added the comment:
It's not even a reprlib bug:
try:
raise Exception
except Exception as ex:
ex.__context__ = ex
hasattr(1, 'aa')
--
___
Python tracker
<http://bugs.pyt
Changes by Yury Selivanov :
--
superseder: infinite loop in reprlib -> CPython hangs on error __context__ set
to the error itself
___
Python tracker
<http://bugs.python.org/issu
New submission from Yury Selivanov:
try:
raise Exception
except Exception as ex:
ex.__context__ = ex
hasattr(1, 'aa')
--
components: Interpreter Core
messages: 255731
nosy: gvanrossum, haypo, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
titl
Changes by Yury Selivanov :
--
nosy: +georg.brandl, larry
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue25782>
___
___
Py
Yury Selivanov added the comment:
> Thanks for chasing this down. Yury, can you suggest a workaround?
I'm not sure how to workaround this :( Hopefully we can fix this in 3.5.1.
--
___
Python tracker
<http://bugs.python.org
Yury Selivanov added the comment:
The bug is in "PyErr_SetObject":
while ((context = PyException_GetContext(o))) {
Py_DECREF(context);
if (context == value) {
PyException_SetContext(o, NULL);
Yury Selivanov added the comment:
Looks like this is the original code committed in CPython in 2ee09afee126.
Patch by Antoine Pitrou.
Antoine, how would you fix this?
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue25
Yury Selivanov added the comment:
Serhiy, good idea, thanks! Please review the attached patch.
Larry, I view this as a very serious bug. Can we ship 3.5.1 with it fixed?
--
keywords: +patch
Added file: http://bugs.python.org/file41212/Issue25782.patch
Yury Selivanov added the comment:
FWIW the bug was identified in issue 25782. I've drafted a patch to fix it,
please review.
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
The question is whether we should raise an exception or not:
ex.__context__ = ex
--
___
Python tracker
<http://bugs.python.org/issue25
Yury Selivanov added the comment:
> Yury, do we need to handle more complicated infinite loops, where "self"
> doesn't actually show up in the loop? Here's an example:
My patch works for your example too. Since it checks for loops in __context__
setter, you s
Yury Selivanov added the comment:
> Should we do the same for __cause__? Is it possible to create __context__ or
> __cause__ loop without assigning these attributes directly?
Yes, let's mirror the __context__ behaviour for __cause__. New patch attached.
Serhiy, Guido,
The new p
Yury Selivanov added the comment:
> Setting it to NULL is one option -- silently ignoring the assignment
(leaving whatever was there) might also be good? In 90% of the cases it
would be the same thing right?
But leaving the old __context__ there will completely mask the bug...
And as for p
New submission from Yury Selivanov:
See http://bugs.python.org/issue25779 and http://bugs.python.org/issue25782 for
details.
--
components: Library (Lib)
messages: 255762
nosy: gvanrossum, ncoghlan, serhiy.storchaka, yselivanov
priority: release blocker
severity: normal
status: open
Yury Selivanov added the comment:
Nick, could you please take a look at the attached patch?
--
keywords: +patch
Added file: http://bugs.python.org/file41216/Issue25786.patch
___
Python tracker
<http://bugs.python.org/issue25
Yury Selivanov added the comment:
Another issue for contextlib: http://bugs.python.org/issue25786
--
___
Python tracker
<http://bugs.python.org/issue25
Yury Selivanov added the comment:
>Don't do that, a few hours (!) is not enough to test a fix. It's too
late after a RC1 for such critical change (exceptions).
Maybe we can add an RC2?
--
___
Python tracker
<http://bugs.pytho
Yury Selivanov added the comment:
> If there is a chain A -> B -> C -> D -> E, after assignment C.__context__ = A
> we will get a chain C -> A -> B -> D -> E. No exception is lost.
What to do when you try to chain "C -> C"?
I'm not sure I like
Yury Selivanov added the comment:
> It's very easy to workaround this issue in pure Python. Why do you want the
> fix *RIGHT NOW*?
Please look at http://bugs.python.org/issue25779. I think we either should fix
this issue, or fix http://bugs.python.org/issue25786 in 3.5.1, since I
Yury Selivanov added the comment:
> Yury, can you help me understand why `hasattr("foo", "bar")` triggers the
> infinite loop there, but not `print("foo")`?
hasattr uses getattr under the hood. getattr raises an AttributeError, and that
triggers PyErr_Se
Yury Selivanov added the comment:
> You closed that one and marked it "not a bug"...?
That particular issue was about asyncio. After reducing it, I created two new
issues -- this one, and another one about another bug in contextlib.
--
_
Yury Selivanov added the comment:
Serhiy, Victor, thank you for your reviews. Another version of the patch is
attached.
--
Added file: http://bugs.python.org/file41219/Issue25782_3.patch
___
Python tracker
<http://bugs.python.org/issue25
Yury Selivanov added the comment:
This cycle leads to infinite unbreakable loop in cpython c internals.
Sent from my iPhone
> On Dec 5, 2015, at 7:44 PM, Larry Hastings wrote:
>
>
> Larry Hastings added the comment:
>
> I don't agree that a reference cycle coun
New submission from Yury Selivanov:
async def foo():
return 123
print(await foo()) # will print 123
print(await foo()) # prints None
print(await foo()) # prints None
The above code illustrates the current behaviour. I propose to change it, so
that second 'await' will
New submission from Yury Selivanov:
This problem was discussed in one of the asyncio issues here:
https://github.com/python/asyncio/issues/288
I propose to raise a RuntimeError if an 'await' expression is used for a
coroutine object that's being awaited on already. This c
Yury Selivanov added the comment:
> OK, but only for await (not for yield from).
Sure, generators will stay untouched (I'll even add a unittest for that, if we
don't have it).
> It should always be valid to create a new coroutine instance. Perhaps you
> meant:
Correct,
Yury Selivanov added the comment:
Gergely, the patch looks alright. Please sign the contributor agreement and
we'll have it merged.
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
Please review the attached patch.
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file41336/Issue25887.patch
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
New patch -- added more tests, made gen_send_ex() to always raise an error if
the genobject is an exhausted coroutine.
--
Added file: http://bugs.python.org/file41337/Issue25887_2.patch
___
Python tracker
<h
Yury Selivanov added the comment:
The patch is attached, please review.
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file41339/Issue25888.patch
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
A new patch is attached. Please review.
I decided to remove the fix for recursive __cause__. Currently, `raise e from
e` doesn't cause any problem, and if we fix the interpreter to raise an
RuntimeError in such cases it will be a backwards incompa
Yury Selivanov added the comment:
This issue is now resolved (see https://github.com/python/asyncio/pull/298)
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Yury Selivanov added the comment:
I think I've fixed all of these:
https://github.com/python/asyncio/commit/cd4fdbb9ccd7c41a4e7c6b416bb2481ab0e21e1c
https://github.com/python/asyncio/commit/1365ac3a37836c6ec50138df8d64a87cdd0ac494
https://github.com/python/asyncio/c
Yury Selivanov added the comment:
I now don't think this is a bug.
In the above example, SubError is instantiated outside of `main` generator.
It's also thrown *into* `main` from the *outside* scope. And __context__
should be set for exceptions that were originated by the cod
Yury Selivanov added the comment:
I closed issue #25683 as "not a bug". So it's just this issue that we need to
fix.
Anyone wants to review the patch? :) Since the code involved here is quite
complex, I don't want to commit this patch witho
Yury Selivanov added the comment:
> My only background here is via the tokenize module, which seems to currently
> behave as described in
> <https://www.python.org/dev/peps/pep-0492/#transition-plan>: async and await
> are either NAME tokens (like ordinary identifiers
Yury Selivanov added the comment:
Ah, I see that issue25580_2.diff does exactly what I proposed. I'm committing
it.
--
keywords: +easy
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
Thanks for the patch!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> enhancement
___
Python tracker
<http://bugs.python
Yury Selivanov added the comment:
Martin, could you please rebase your patch on top of recent cpython default
branch, so that a 'review' link appears?
--
___
Python tracker
<http://bugs.python.o
Yury Selivanov added the comment:
> The documentation should probably also be updated. It has a list of supported
> schemes.
I agree. Gergely, do you want to update your patch?
> I imagine this would have to be taken as a new feature for 3.6+, rather than
> a bug fix.
Since
Yury Selivanov added the comment:
> Serhiy Storchaka added the comment:
>
> The patch LGTM (but I prefer reordering solution).
Serhiy, could you please describe your solution in more detail? An elaborate
example would help. Perhaps I just misunderstand your idea. And thanks for th
Changes by Yury Selivanov :
--
components: +Interpreter Core
nosy: +haypo, yselivanov
stage: -> needs patch
type: -> behavior
versions: +Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/i
Yury Selivanov added the comment:
Maybe instead of releasing the lock in the forked child process, we should try
to acquire the lock in the os.fork() implementation, and then release it?
Otherwise, suppose that a call to getaddrinfo (call #1) takes a long amount of
time. In the middle of it
Changes by Yury Selivanov :
--
nosy: +serhiy.storchaka
___
Python tracker
<http://bugs.python.org/issue25920>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> Now we missed the 3.5.2 deadline.
Did you mean 3.5.1? Or Larry is going to rush 3.5.2 soon?
--
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
> Why are you using 2 threads?
That's a good question.
In any case it looks like self-pipe sock's buffer was overflown because
call_soon_threadsafe was called too many times, and loop._read_from_self
couldn't empty the buffer prompt
Yury Selivanov added the comment:
> Did anyone consider moving these near the “types” module, either directly
> inside, or as a “types.abc” submodule? In my mind, these ABCs would fit
> reasonably well there. They are related to built-in types, but do not have
> built-in na
Changes by Yury Selivanov :
--
assignee: docs@python
components: Documentation
keywords: needs review
nosy: docs@python, r.david.murray, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: document CO_* constants
type: enhancement
versions: Python 3.5
Changes by Yury Selivanov :
--
superseder: -> document CO_* constants
___
Python tracker
<http://bugs.python.org/issue25813>
___
___
Python-bugs-list mai
New submission from Yury Selivanov:
Hi David,
This is a follow up to issue #26010. Please review the attached patch. I've
skipped the CO_NESTED flag since it's no longer used, and CO_OPTIMIZED because
I don't know too much about it.
--
keywords: +patch
A
Yury Selivanov added the comment:
> This is a follow up to issue #26010.
The correct issue # is 25813
--
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
> Perhaps we can also add it back in 3.5.2 since 3.5 is in early stages of its
> maintenance period?
> +1 for adding it to 3.5.2.
I was never removed from 3.5
Python 3.5.1 (default, Dec 13 2015, 16:05:52)
[GCC 4.2.1 Compatible Apple LLVM 7.0
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue26060>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Some info on this:
https://github.com/python/asyncio/issues/282#issuecomment-155957235 Long story
short, Future implemented in C can speedup some asyncio code up to 25%.
I'm attaching a patch with a WIP implementation. There are some failing
asser
New submission from Yury Selivanov:
Some info on this:
https://github.com/python/asyncio/issues/282#issuecomment-155957235 Long story
short, Future implemented in C can speedup some asyncio code up to 25%.
I'm attaching a patch with a WIP implementation. There are some failing
asser
Changes by Yury Selivanov :
--
Removed message: http://bugs.python.org/msg257983
___
Python tracker
<http://bugs.python.org/issue26050>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
Sorry, posted my previous message here by mistake (it was for issue #26081).
--
___
Python tracker
<http://bugs.python.org/issue26
Yury Selivanov added the comment:
Leaving this issue open until we have the docs committed.
--
___
Python tracker
<http://bugs.python.org/issue26050>
___
___
Pytho
Yury Selivanov added the comment:
inspect.getargspec is back to Python 3.6 (it was never removed from <= 3.5,
fwiw)
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
Yury Selivanov added the comment:
Attaching another patch. Please review (I plan to commit it tomorrow in 3.5
and 3.6 branches).
The patch affects generators machinery in the following way:
1. Generators behaviour isn't touched, the patch is only for 'async def'
coroutin
Yury Selivanov added the comment:
> I don't like "coroutine was already awaited". I feel like either "on" should
> be appended to that or another sentence like "coroutine had 'await' called on
> it" or something.
Yury Selivanov added the comment:
Will commit this patch tomorrow to 3.5 and 3.6.
It only affects coroutines (async defs): if an await expression is used on a
coroutine object while it's being already awaited by another coroutine, a
`RuntimeError("coroutine is being awaited already&
Yury Selivanov added the comment:
Nick,
> After all, waiting for the result with "await" is only one way to terminate a
> coroutine - you can also get there with direct calls to next(), send(),
> throw() and close().
Yes, but I expect that almost nobody will use &#x
Yury Selivanov added the comment:
Attaching an updated patch. The RuntimeError says 'coroutine was already
awaited on' for now.
--
Added file: http://bugs.python.org/file41588/Issue25887_4.patch
___
Python tracker
<http://bu
Yury Selivanov added the comment:
> Now the documentation says it will be removed in 3.6. I guess the 3.5
> documentation also needs updating.
Good catch!
--
___
Python tracker
<http://bugs.python.org/i
Yury Selivanov added the comment:
> IMO “yield from coroutine_iterator” might be plausable for some strange
> combination of 3.4 code and a 3.5 coroutine, but I think it would be rare.
> And if you added a check in __await__() then the using “await” wouldn’t need
> to rely on ne
Yury Selivanov added the comment:
> Anybody still looking at this? I can take another stab at it if it's still in
> scope.
There were some visible speedups from your patch -- I think we should merge
this optimization. Can you figure why unpack_sequence and other benchmarks
Yury Selivanov added the comment:
"Cannot await previously awaited coroutine" might be confusing if raised on
"coro.send(..)"-like code...
So far "coroutine was already awaited on" (do you want to drop "wa
Yury Selivanov added the comment:
Oh, choosing a good error message is hard :(
I've a few comments. Sorry, this thread is growing rather rapidly, but please
help me to pick one of them:
> From the point of view of the error message, the reason I changed my
> suggestion was beca
Yury Selivanov added the comment:
>"Cannot reuse already awaited coroutine"
Great, I like it! Thanks Martin and Nick.
Please check out issue #25888 just in case.
--
___
Python tracker
<http://bugs.pytho
New submission from Yury Selivanov:
This issue supersedes issue #6033. I decided to open a new one, since the
patch is about Python 3.6 (not 2.7) and is written from scratch.
The idea is to add new opcodes to avoid instantiation of BoundMethods. The
patch only affects method calls of Python
Yury Selivanov added the comment:
> If you prefer to limit the number of opcodes, you can pass a flag in
> arguments. For example, use 2 bytes for 2 arguments instead of only 1?
I tried two approaches:
1. Push one more leading NULL to the stack in LOAD_METHOD (which makes it push
Changes by Yury Selivanov :
--
superseder: -> Speedup method calls 1.2x
___
Python tracker
<http://bugs.python.org/issue6033>
___
___
Python-bugs-list mai
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue25668>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue26058>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> I like this idea! I like the limitations to positional-only calls. I do think
> that it would be nice if we could speed up C calls too -- today,
> s.startswith('abc') is slower than s[:3] == 'abc' precisely because of the
&g
Changes by Yury Selivanov :
--
nosy: +brett.cannon
___
Python tracker
<http://bugs.python.org/issue26121>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
It looks like this should be fixed in the mock module, as special casing it in
inspect doesn't look right. Unfortunately, I can't review this patch, as I
don't know the mock module internals and I don't think I understand all
conseq
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue26145>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
The docs are correct. See the definition of the "await" expression:
https://docs.python.org/3.6/reference/expressions.html#await-expression
--
nosy: +yselivanov
resolution: -> not a bug
stage: -> resolved
status
Yury Selivanov added the comment:
> Patch version 5: a global counter is now used to set ma_version field of
> dictionaries. The global counter is incremented each time that a dictionary
> is created and each time that a dictionary is modified.
This is great, thank yo
Yury Selivanov added the comment:
The patch looks alright.
Will the following code compile OK? What will it compile to?
if 1:
42
--
___
Python tracker
<http://bugs.python.org/issue26
Changes by Yury Selivanov :
--
assignee: yselivanov
components: Interpreter Core
nosy: yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: implement per-opcode cache in ceval
type: performance
versions: Python 3.6
Yury Selivanov added the comment:
Yeah, I needed a URL of the issue for my email to python-dev ;)
Here's a link to the email, that explains a lot about this patch:
https://mail.python.org/pipermail/python-dev/2016-January/142945.html
The patch is also attached (opcache1.
Changes by Yury Selivanov :
--
nosy: +haypo, ncoghlan
___
Python tracker
<http://bugs.python.org/issue26219>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
dependencies: +PEP 509: Add ma_version to PyDictObject
___
Python tracker
<http://bugs.python.org/issue26219>
___
___
Python-bug
Changes by Yury Selivanov :
--
dependencies: +Speedup method calls 1.2x
___
Python tracker
<http://bugs.python.org/issue26219>
___
___
Python-bugs-list mailin
Yury Selivanov added the comment:
> If you run hg.python.org/benchmarks on Linux it has a flag to measure memory.
Great. I'll re-run the benchmarks. BTW, the latest results are here:
https://gist.github.com/1st1/aed69d63a2ff4de4c7be
--
__
2501 - 2600 of 3098 matches
Mail list logo
