[issue25967] Devguide: add 2to3 to the "Changing CPython's Grammar" checklist

Ezio Melotti added the comment: Fixed, thanks for the patch! -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker ___ ___

[issue19251] bitwise ops for bytes of equal length

Changes by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue26086] Bug in standardmodule os

Changes by Eryk Sun : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker ___ ___ Python-

[issue26086] Bug in standardmodule os

Eryk Sun added the comment: The "yield from" syntax was added in Python 3.3, so somehow you're using the 3.5 standard library with either an old 3.x or 2.x version. The older version shouldn't use 3.5's standard library, unless you have either PYTHONHOME or PYTHONPATH defined. Generally neithe

[issue23942] Explain naming of the patch files in the bug tracker

Martin Panter added the comment: I guess if people wonder about this, you could at least say the naming doesn’t matter very much for the review system. If I am generating my own patches, I try to name them with one or two concise words describing the particular solution, and then insert “.v2”,

[issue25994] File descriptor leaks in os.scandir()

Martin Panter added the comment: Guido are you saying in the following code, the “finally” message is not guaranteed to be printed out? Or just that you cannot limit a ResourceWarning to garbage collection? def g(): try: yield "item" finally: # Run at exhaustion, close(

[issue25887] awaiting on coroutine more than once should be an error

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' coroutines. 2. Calling 'send

[issue25887] awaiting on coroutine more than once should be an error

Brett Cannon 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. -- ___ Python tracker

[issue25887] awaiting on coroutine more than once should be an error

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. Fine with me to have "coroutine was already awaited on". -- ___

[issue25888] awaiting on coroutine that is being awaited should be an error

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")` will be

[issue25887] awaiting on coroutine more than once should be an error

Nick Coghlan added the comment: The patch looks good to me, but I'd like to see the error message convey two points: - the coroutine has already terminated (regardless of how that happened) - the calling code attempted to resume it anyway That is, something like "Cannot resume terminated corout

[issue25994] File descriptor leaks in os.scandir()

Guido van Rossum added the comment: It was a bit more subtle. I think like this: def f(): with some_lock: yield 0 yield 1 def g(): with another_lock: it = f() for i in it: raise We determined that another_lock was freed *before* some_lock. T

[issue25888] awaiting on coroutine that is being awaited should be an error

Martin Panter added the comment: Missing word in a comment on the review -- nosy: +martin.panter ___ Python tracker ___ ___ Python-bug

[issue25994] File descriptor leaks in os.scandir()

Martin Panter added the comment: Okay I understand. You have to explicitly call the close() method if you want a generator to be cleaned up properly, which parallels how Serhiy’s proposal would be used. -- ___ Python tracker

[issue25887] awaiting on coroutine more than once should be an error

Martin Panter added the comment: The patch looks like it adds checks for the special generator-like send() etc methods, but I was expecting __await__() to also (or instead) do this check. That way you wouldn’t have to break the iterator protocol by the iterator not raising StopIteration a seco

[issue26082] functools.lru_cache user specified cachedict support

Josh Rosenberg added the comment: Given that lru_cache uses the cache dict in very specific ways, supporting arbitrary mapping types would be extremely hard. Among other things: 1. The C code uses the concrete dict APIs (including private APIs) that would not work on arbitrary mappings that do

[issue25887] awaiting on coroutine more than once should be an error

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 'send', 'throw' etc on corout

[issue25486] Resurrect inspect.getargspec() in 3.6

Martin Panter added the comment: Now the documentation says it will be removed in 3.6. I guess the 3.5 documentation also needs updating. -- nosy: +martin.panter ___ Python tracker

[issue24712] Docs page's sidebar vibrates on mouse wheel scroll on Chrome.

Mike Taylor added the comment: I can reproduce on Chrome and Firefox Nightly -- Carol, if I'd like to write a patch where would I do that? I see https://github.com/python/pythondotorg, but am not sure that's the right repo. Thanks! -- nosy: +Mike Taylor __

[issue25887] awaiting on coroutine more than once should be an error

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

[issue25991] readline example eventually consumes all memory

Martin Panter added the comment: Thanks Ezio for handling this. Ignore my previous comment; I missed the key word “example” :) -- ___ Python tracker ___

[issue25486] Resurrect inspect.getargspec() in 3.6

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 ___

[issue25486] Resurrect inspect.getargspec() in 3.6

Roundup Robot added the comment: New changeset 36a54e30bcbd by Yury Selivanov in branch '3.5': Issue #25486: Drop "removed in 3.6" wording from inspect.getargspec docs. https://hg.python.org/cpython/rev/36a54e30bcbd New changeset 4f1a0e5deca6 by Yury Selivanov in branch 'default': Merge 3.5 (iss

[issue21955] ceval.c: implement fast path for integers with a single digit

Zach Byrne added the comment: Anybody still looking at this? I can take another stab at it if it's still in scope. -- ___ Python tracker ___

[issue25887] awaiting on coroutine more than once should be an error

Martin Panter added the comment: If the coroutine-iterator is going to raise RuntimeError rather than StopIteration, do you think the __await__() documentation should be clarified? IMO “yield from coroutine_iterator” migh

[issue25887] awaiting on coroutine more than once should be an error

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 next() raising th

[issue21955] ceval.c: implement fast path for integers with a single digit

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 were slower?

[issue25887] awaiting on coroutine more than once should be an error

Nick Coghlan added the comment: Good point about having "await" in the error message to make it more obvious what it's referring to in the "awaiting twice" case. I'll tender "Cannot await previously awaited coroutine" as one final alternative, but if you don't like that, I can cope with "Corou

[issue21955] ceval.c: implement fast path for integers with a single digit

Zach Byrne added the comment: > Can you figure why unpack_sequence and other benchmarks were slower? I didn't look really closely, A few of the slower ones were floating point heavy, which would incur the slow path penalty, but I can dig into unpack_sequence. -- __

[issue26087] PEP 0373 should be updated

New submission from Chi Hsuan Yen: Current PEP 0373 lists Python 2.7.11 as a future release, and there's no information about Python 2.7.12. Please update it, thanks! -- assignee: docs@python components: Documentation messages: 258063 nosy: Chi Hsuan Yen, docs@python priority: normal se

[issue25887] awaiting on coroutine more than once should be an error

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 "was", btw?) is less of all evil IMHO. -- ___

[issue25887] awaiting on coroutine more than once should be an error

Nick Coghlan added the comment: Sorry, dropping the "was" was a typo (I should have copied & pasted it instead of rewriting). >From the point of view of the error message, the reason I changed my >suggestion was because I liked your idea of optimising it for the "only using >await" case and t

[issue25887] awaiting on coroutine more than once should be an error

Martin Panter added the comment: Isn’t the combined point of this issue and Issue 25888 to make it only legal to “await” a coroutine instance that has not yet been started? Perhaps “Cannot [re]start terminated coroutine” would be better. -- ___ Pyth

[issue25887] awaiting on coroutine more than once should be an error

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 because I liked y

[issue25887] awaiting on coroutine more than once should be an error

Nick Coghlan added the comment: I expect whatever message we use will become a Stack Overflow question in fairly short order, so "good enough" is almost certainly good enough here, and I'm massively overthinking the problem :) However, combining my last suggestion with a variant of Martin's wo

[issue25887] awaiting on coroutine more than once should be an error

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 ___

[issue25348] Update pgo_build.bat to use --pgo flag for regrtest

Roundup Robot added the comment: New changeset 113c524aed93 by Zachary Ware in branch '2.7': Issue #25348: Add --pgo and --pgo-job flags to PCbuild\build.bat https://hg.python.org/cpython/rev/113c524aed93 New changeset 01ab138f4133 by Zachary Ware in branch '3.5': Issue #25348: Add --pgo and --p

[issue25348] Update pgo_build.bat to use --pgo flag for regrtest

Zachary Ware added the comment: Thanks for the review, Steve. -- assignee: brett.cannon -> zach.ware ___ Python tracker ___ ___ Python

[issue25788] fileinput.hook_encoded has no way to pass arguments to codecs

Terry J. Reedy added the comment: fileinput is in Python, hence the source is in Lib. Online version is https://hg.python.org/cpython/file/tip/Lib/fileinput.py https://hg.python.org/cpython/file/tip/Lib/test/test_fileinput.py Patching openhook itself looks trivial. A test is the hard part. Lau

<    1   2