[issue17927] Argument copied into cell still referenced by frame

Guido van Rossum added the comment: Ok, the deed is done. Thanks for your review, Benjamin! I've reassigned it to you so you can fix up the test if you want to. What would you think of a backport to 3.3? -- assignee: gvanrossum -> benjamin.peterson resolution:

[issue17927] Argument copied into cell still referenced by frame

Guido van Rossum added the comment: Martin Morrison, can you check if my fix (cellfree4.diff) applies cleanly to 3.3? Or if nearly so, could you upload a fixed version here? (Or create a new issue and assign it to me if you can't upload to this

[issue17947] Code, test, and doc review for PEP-0435 Enum

Guido van Rossum added the comment: Sorry everyone, the frame hack needs to stay. This is not negotiable. -- nosy: +gvanrossum ___ Python tracker <http://bugs.python.org/issue17

[issue17959] Alternate approach to aliasing for PEP 435

Changes by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <http://bugs.python.org/issue17959> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17927] Argument copied into cell still referenced by frame

Guido van Rossum added the comment: Benjamin, what do you think of backporting this? -- ___ Python tracker <http://bugs.python.org/issue17927> ___ ___ Python-bug

[issue17959] Alternate approach to aliasing for PEP 435

Guido van Rossum added the comment: I'm with Antoine. Trying to prevent accidental redefinition behavior like Nick proposes feels like un-Pythonic coddling to me, and I expect we'd be closing off some occasionally useful patterns. Please leave well en

[issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code

Guido van Rossum added the comment: This is a silly argument. -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/i

[issue17934] Add a frame method to clear expensive details

Guido van Rossum added the comment: A downside of using this is that some extended traceback printers (such as cgitb.py in the stdlib, or and some things I've seen in web frameworks) won't be able to print the locals. And pdb's pm() function would lose its value too. So

[issue17947] Code, test, and doc review for PEP-0435 Enum

Guido van Rossum added the comment: Here's the promised explanation why I want to keep the getframe hack. I'm sure it won't satisfy everyone, but this will have to do. There are two parts to my argument. TL;DR: (a) by implementing this hack, we will maximize user happines

[issue17963] Deprecate the frame hack for implicitly getting module details

Guido van Rossum added the comment: As I explained in issue 17947, I think that any Python implementation worth its salt should be able to implement sys.get_calling_module_name() (*), at least for the case where the caller is top-level code in a module body. That is a much weaker requirement

[issue17950] Dynamic classes contain non-breakable reference cycles

Guido van Rossum added the comment: I think turning the __mro__ tuple into a getter is fine. As long as this works I'm okay: class C: ... mro = C.__mro__ del C assert mro[0].__name__ == 'C' (The last assert stands in for asserting that the class object must stay alive as lo

[issue17941] namedtuple should support fully qualified name for more portable pickling

Guido van Rossum added the comment: I'd like to propose one slight tweak to the patch. (Also to enum.py.) If no module name was passed and _getframe() fails, can you set the __module__ attribute to something that will cause pickling the object to fail? That would be much better than le

[issue17941] namedtuple should support fully qualified name for more portable pickling

Guido van Rossum added the comment: Great, forget I said anything then. LGTM to the patch, feel free to commit (with update to Misc/NEWS please). -- ___ Python tracker <http://bugs.python.org/issue17

[issue17927] Argument copied into cell still referenced by frame

Guido van Rossum added the comment: Would you mind doing the backport then? -- ___ Python tracker <http://bugs.python.org/issue17927> ___ ___ Python-bugs-list m

[issue17950] Dynamic classes contain non-breakable reference cycles

Guido van Rossum added the comment: Kristjan, it seems you're in over your head. :-) The mro() function is documented here: http://docs.python.org/3/library/stdtypes.html?highlight=mro#class.mro It exists to be called instead of using __mro__ directly; a metaclass can then override wh

[issue17950] Dynamic classes contain non-breakable reference cycles

Guido van Rossum added the comment: Good call. I think it's perfectly fine for you to do this in your custom 2.7 branch. It feels too fragile to adopt the same approach for Python 3.4 though. -- status: open -> closed ___ Python tracke

[issue17683] socket.getsockname() inconsistent return type with AF_UNIX

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <http://bugs.python.org/issue17683> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22641] Use better default context in asyncio

Guido van Rossum added the comment: LGTM. Thanks! -- ___ Python tracker <http://bugs.python.org/issue22641> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22685] memory leak: no transport for pipes by create_subprocess_exec/shell

Guido van Rossum added the comment: Hm... It does look like there's nothing that tells stdout (which is a StreamReader) about its transport. Wabu, could you experiment with a change to asyncio/subprocess.py where SubprocessStreamProtocol.connection_made() calls self.stdout.set_tran

[issue22685] memory leak: no transport for pipes by create_subprocess_exec/shell

Guido van Rossum added the comment: Can you confirm that this patch fixes the problem (without you needing the workaround in your own code)? -- keywords: +patch Added file: http://bugs.python.org/file36989/fix22685.patch ___ Python tracker <h

[issue22685] memory leak: no transport for pipes by create_subprocess_exec/shell

Guido van Rossum added the comment: Victor, do you think this needs a unittest? It seems kind of difficult to test for whether memory fills up (the machine may get wedged if it does :-). On Tue, Oct 21, 2014 at 1:39 PM, wabu wrote: > > wabu added the comment: > > thanks a lot, t

[issue22685] memory leak: no transport for pipes by create_subprocess_exec/shell

Guido van Rossum added the comment: Victor, your fix is identical to mine except for the variable names. I like your version better. :-) So now it's just about the unittest. -- ___ Python tracker <http://bugs.python.org/is

[issue22715] PEP 257: drop the recommendation for a blank line between the class line and the docstring

Guido van Rossum added the comment: I've applied the second version -- rev 9b715d8246db in the peps repo. -- assignee: -> gvanrossum nosy: +gvanrossum resolution: not a bug -> fixed ___ Python tracker <http://bugs.python.

[issue22768] Add a way to get the peer certificate of a SSL Transport

Guido van Rossum added the comment: Maybe transport.get_extra_info('socket').getpeercert(True) would be okay, no patch needed? On Thu, Oct 30, 2014 at 11:56 AM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > > some methods take parameters (like the

[issue22784] test_asyncio fails without the ssl module

Guido van Rossum added the comment: Is something missing from the patch? I don't understand how *not* defining a function can make anything better. Perhaps you need to conditionally skip the test that uses it? -- ___ Python tracker

[issue22784] test_asyncio fails without the ssl module

Guido van Rossum added the comment: OK, them LGTM. -- ___ Python tracker <http://bugs.python.org/issue22784> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5717] os.defpath includes unix /bin on windows

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <http://bugs.python.org/issue5717> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22808] Typo in asyncio-eventloop.rst, time() link is wrong

Guido van Rossum added the comment: LG, can someone commit this? Should be backported to the 3.4 docs as well. -- ___ Python tracker <http://bugs.python.org/issue22

[issue1282] re module needs to support bytes / memoryview well

Guido van Rossum added the comment: Hm, I don't see a reason why the *pattern* should be a bytearray or memoryview, only the string it is searching. But if you fixed it by casting it to bytes I won't stop you. :-) -- ___ Python trac

[issue22841] Avoid to use coroutine with add_signal_handler()

Guido van Rossum added the comment: Applied to upstream tulip, 3.4, and 3.5. Thanks Ludovic! -- ___ Python tracker <http://bugs.python.org/issue22841> ___ ___

[issue22875] asyncio: call_soon() documentation unclear on timing

Guido van Rossum added the comment: "As soon as possible" is constrained by "all callbacks are called from the event loop". Feel free to suggest a doc patch (asyncio docs are in dire need of more help!) -- ___ P

[issue22906] PEP 479: Change StopIteration handling inside generators

Changes by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <http://bugs.python.org/issue22906> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22906] PEP 479: Change StopIteration handling inside generators

Guido van Rossum added the comment: If all examples were just using "raise StopIteration" instead of "return" in a generator I would be very happy. Such code can be trivially fixed by using "return" and the __future__ import will help the eventual transition. It&

[issue22685] memory leak: no transport for pipes by create_subprocess_exec/shell

Guido van Rossum added the comment: Sorry, looks good. On Tue, Nov 25, 2014 at 6:37 AM, STINNER Victor wrote: > > STINNER Victor added the comment: > > > Here is a patch with a simple unit test. > > Can someone review it? If not, I will com

[issue22937] unittest errors can't show locals

Guido van Rossum added the comment: Note that IIRC py.test (a 3rd party module) will show you additional information in the traceback. SO it is definitely possible. -- nosy: +gvanrossum ___ Python tracker <http://bugs.python.org/issue22

[issue22937] unittest errors can't show locals

Guido van Rossum added the comment: Sorry, I missed the part where you said "we can't depend on PyPI". There already is something in the stdlib that may be close enough to what you're looking for -- checkout cgitb.py. The following might even work: import cgitb cgitb

[issue22936] traceback module has no way to show locals

Guido van Rossum added the comment: Check out the cgitb stdlib module. -- nosy: +gvanrossum ___ Python tracker <http://bugs.python.org/issue22936> ___ ___ Pytho

[issue22906] PEP 479: Change StopIteration handling inside generators

Guido van Rossum added the comment: Here's a doc patch for itertools. -- Added file: http://bugs.python.org/file37297/itertoolsdoc.diff ___ Python tracker <http://bugs.python.org/is

[issue21998] asyncio: a new self-pipe should be created in the child process after fork

Guido van Rossum added the comment: Martin, what is the magic call to make in the child (or in the parent pre-fork???) to disable the epoll object in the child without disabling it in the parent? (Perhaps just closing the selector and letting the unregister calls fail would work

[issue21998] asyncio: a new self-pipe should be created in the child process after fork

Guido van Rossum added the comment: How about not doing anything in the parent but in the child, closing the selector and then the event loop? On Mon, Dec 1, 2014 at 1:29 AM, Martin Richard wrote: > > Martin Richard added the comment: > > I said something wrong in my prev

[issue22988] No error when yielding from `finally`

Guido van Rossum added the comment: There is no prohibition in the language against yield in a finally block. It may not be a good idea, but the behavior you see is all as it should be. -- ___ Python tracker <http://bugs.python.org/issue22

[issue22988] No error when yielding from `finally`

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <http://bugs.python.org/issue22988> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22926] asyncio: raise an exception when called from the wrong thread

Guido van Rossum added the comment: Maybe only in debug mode? Getting thread ID or current thread may be expensive. Also it is conceivable that run... is called first from one thread and then from another. Maybe. On Dec 4, 2014 4:47 PM, "STINNER Victor" wrote: > > STINNER

[issue22926] asyncio: raise an exception when called from the wrong thread

Guido van Rossum added the comment: On Thu, Dec 4, 2014 at 7:21 PM, Yury Selivanov wrote: > > Yury Selivanov added the comment: > > > - modify tests to set the event loop to the newly created event loop, > instead of setting it to None > > I'm not sure that this

[issue22926] asyncio: raise an exception when called from the wrong thread

Guido van Rossum added the comment: I'm okay with this approach now. -- ___ Python tracker <http://bugs.python.org/issue22926> ___ ___ Python-bugs-list m

[issue23009] selectors.EpollSelector.select raises exception when nothing to select.

Guido van Rossum added the comment: Please add a comment explaining the complaint from epoll.poll() we're trying to avoid here. I presume Tulip never gets into this state because of the self-pipe. On Mon, Dec 8, 2014 at 8:01 AM, STINNER Victor wrote: > > STINNER Victor added

[issue18305] [patch] Fast sum() for non-numbers

Guido van Rossum added the comment: The example code is a perversion and should not be encouraged. -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/i

[issue22875] asyncio: call_soon() documentation unclear on timing

Guido van Rossum added the comment: Docfix LGTM. On Fri, Dec 12, 2014 at 10:53 PM, Martin Panter wrote: > > > Martin Panter added the comment: > > I have been bitten by this when attempting to implement my own event > loops. Parts of the “asyncio” code itself expects that t

[issue23055] PyUnicode_FromFormatV crasher

New submission from Guido van Rossum: Fix as reported by Guido Vranken on secur...@python.org, with minimal test by me. Needs: - review - port to 3.2--3.5 Questions: - Does my test case cover all changed code? -- assignee: gvanrossum files: vranken.diff keywords: needs review

[issue23055] PyUnicode_FromFormatV crasher

Guido van Rossum added the comment: Thank you for digging into this! I'd say go ahead and update 3.2 and 3.3 too -- these are in security-fix-only mode meaning that we only fix security issues and don't do actual releases. But we still do security bugfixes: for 3.2 until February

[issue23055] PyUnicode_FromFormatV crasher

Guido van Rossum added the comment: I'd be much worried about attack scenarios if this function was part of the standard library. But it's not -- the stdlib's % operator uses completely different code. The most common use case is probably to generate error messages from ex

[issue23066] re.match hang

Guido van Rossum added the comment: Please go to python-list to get help about writing re expressions for parsing. The example regexp does not technically hang, it is just exploring a very large set of alternatives, none of which match (because the trailing '()' doesn't

[issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events

Guido van Rossum added the comment: OK, fine to expose the BaseEventLoop class. On Tue, Dec 16, 2014 at 3:45 PM, STINNER Victor wrote: > > > STINNER Victor added the comment: > > I'm in favor of exposing BaseEventLoop in the asyncio namespace directly > (asyncio.Bas

[issue22926] asyncio: raise an exception when called from the wrong thread

Guido van Rossum added the comment: Well, the PEP clearly states that get_event_loop() should never return None and raise an exception if the context has no environment. (Where context ~~ thread.) On Tue, Dec 16, 2014 at 3:48 PM, STINNER Victor wrote: > > > STINNER Victor added th

[issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events

Guido van Rossum added the comment: Sounds unlikely. If they write "from asyncio.base_events import Server" it will still work. Only if they wrote "from asyncio.base_events import *" will they be broken, and that sounds not worth worrying about. So LGTM on the patch. (But why

[issue22926] asyncio: raise an exception when called from the wrong thread

Guido van Rossum added the comment: Oh sorry. I'm in too much of a hurry. :-( The problem is that the thread may not have a loop, but the loop still has a tread. E.g. the tests intentionally call set_event_loop(None) to make sure that no code depends on the implict event loop. An app shou

[issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events

Guido van Rossum added the comment: Heh. Well I don't remember why I did that any more, and it doesn't seem to matter now. However the doc issue seems different than for BaseEventLoop -- Server is the *concrete* class (it actually gets instantiated, not a subclass). We could instea

[issue23068] Add a way to determine if the current thread has the import lock

New submission from Guido van Rossum: imp.lock_held() returns True if *any* thread is currently importing something. I'd like to have an API that can tell whether the *current* thread has the import lock. The implementation keeps track of this, but doesn't make the info available.

[issue23068] Add a way to determine if the current thread has the import lock

Guido van Rossum added the comment: Oh. I'd forgotten the PY3 situation is completely different from the PY2 situation. We're still stuck here in PY2 land where there's just the one import lock. I guess not even ctypes can help us find out whether the current thread is holding

[issue23068] Add a way to determine if the current thread has the import lock

Guido van Rossum added the comment: Interesting. The Dropbox server team thanks you for the suggestion! -- ___ Python tracker <http://bugs.python.org/issue23

[issue22926] asyncio: raise an exception when called from the wrong thread

Guido van Rossum added the comment: SGTM. Merry Xmas! -- ___ Python tracker <http://bugs.python.org/issue22926> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22560] Add loop-agnostic SSL implementation to asyncio

Guido van Rossum added the comment: Maybe we should just accept this without review? I really don't have time to review 600+ lines of code, sorry. -- ___ Python tracker <http://bugs.python.org/is

[issue22560] Add loop-agnostic SSL implementation to asyncio

Guido van Rossum added the comment: Oh, I think I understand how this could help STARTTLS. Glyph once explained it to me. STARTTLS takes an existing non-TLS Transport and layers a TLS Transport on top of it. This requires the TLS layer to read/write from the underlying Transport using the

[issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events

Guido van Rossum added the comment: Sure. I already said LGTM on the patch (http://bugs.python.org/issue23046#msg232783). -- ___ Python tracker <http://bugs.python.org/issue23

[issue23140] InvalidStateError on asyncio subprocess task cancelled

Guido van Rossum added the comment: The patch looks good, although the test feels overly complex (but maybe I'm missing something). I'm okay with leaving the other unguarded set_result() call unchanged, but I'm also okay with putting "if not self.waiter.can

[issue23187] Segmentation fault, possibly asyncio related

Guido van Rossum added the comment: That's going to be really hard to debug. Is it always the same stack trace? Could it be slowly running out of memory? (The consistent time until it happens points to this.) A segfault in dealloc might point to a refcounting bug. The rarity of the even

[issue23192] Generator return value ignored in lambda function

Guido van Rossum added the comment: Hm, looks like nobody bothered to update the lambda code generation to use the value from yield. I almost feel like there is some unnecessary check "if we are in a lambda" in the code generation for yield. Have you looked through the code gene

[issue23209] asyncio: break some cycles

Guido van Rossum added the comment: All three changes look good to me. The selectors.py fix should be applied to CPython first; the others to Tulip first. -- ___ Python tracker <http://bugs.python.org/issue23

[issue23185] add inf and nan to math module

Guido van Rossum added the comment: Should inf and nan be added to cmath too? It has e and pi and isnan() and isinf()... Also complex(0, math.nan) a value that is printed as "nanj" and complex("nanj") parses and returns such a value, so the point could be made tha

[issue23229] add inf, nan, infj, nanj to cmath module

Guido van Rossum added the comment: > Note: following the precedent of cmath.e and cmath.pi, cmath.nan and cmath.inf should have type *float*. Let's not get into the business of deciding *which* complex infinities and nans to represent.

[issue23229] add inf, nan, infj, nanj to cmath module

Guido van Rossum added the comment: Note, the reason I proposed nanj (and infj) is that these are produced by repr() of complex numbers. Having them in the cmath module provides a place to document them which will then be searchable. On Tue, Jan 13, 2015 at 8:46 AM, Guido van Rossum wrote

[issue23229] add inf, nan, infj, nanj to cmath module

Guido van Rossum added the comment: I don't understand why w ends up having -0 as the real part. For floats, at least, we've done a lot of work to make eval(repr()) roundtrip correctly in all cases. Is the issue with complex superficial (we should fix eval or repr) or deep (if w

[issue23229] add inf, nan, infj, nanj to cmath module

Guido van Rossum added the comment: OK, let's not try to resolve that issue, we can just note it in the docs. BTW I don't want repr() of a complex number to use the complex(..., ...) notation -- it's too verbose. On Tue, Jan 13, 2015 at 11:38 AM, Serhiy Storchaka wrote: >

[issue23229] add inf, nan, infj, nanj to cmath module

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <http://bugs.python.org/issue23229> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Let's tread careful here. In regular dicts, for better or for worse, {'x': 1, 'x': 2} is defined and returns {'x': 2}. But in keyword arg processing, duplicates are always rejected. This may be an area where we need to adjus

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: SGTM On Tue, Jan 20, 2015 at 4:08 PM, Neil Girdhar wrote: > > Neil Girdhar added the comment: > > That makes sense. > > If you wanted to override, you could always write: > > f(**{**a, **b, 'x': 5}) > > rather than &g

[issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module

Guido van Rossum added the comment: Python 3's exception chaining allows us to do the second (easier to catch without resorting to "except Exception:" or even "except:") while still showing the original exception in the traceback. ---

[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture

Guido van Rossum added the comment: Congrats with the fix, and thanks for your perseverance! -- ___ Python tracker <http://bugs.python.org/issue23095> ___ ___

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Both. On Jan 26, 2015 8:42 AM, "Neil Girdhar" wrote: > > Neil Girdhar added the comment: > > Is this correct? > > >>> f(*i for i in ['abc', 'def']) > ['a', 'b', 'c', &#

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Wait, with that f() definition I'd expect a different result from the former -- each letter as a new arg. Right? On Jan 26, 2015 8:42 AM, "Neil Girdhar" wrote: > > Neil Girdhar added the comment: > > >>>

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Let's wait until I have a keyboard. In 20 min. On Jan 26, 2015 8:55 AM, "Guido van Rossum" wrote: > Wait, with that f() definition I'd expect a different result from the > former -- each letter as a new arg. Right? > On Jan 26

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: So I think the test function here should be: def f(*a, **k): print(list(a), list(k)) Then we can try things like: f(x for x in ['ab', 'cd']) which prints a generator object, because this is interpreted as an argument that'

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: @Joshua: Re: f(x: y for x, y in z) I don't think that follows at all. We support f(**d) now, but if d == {'a': 1, 'b': 2}, it is equivalent to f(a=1, b=2), not f(a: 1, b: 2). --

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Hi Neil, I think disallowing them is the best approach. There doesn't seem to be a good use case that would be thwarted. Hopefully the syntactic prohibition isn't too hard to implement. On Thu, Jan 29, 2015 at 4:32 PM, Neil Girdhar wrote: > &

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: For the PEP update, please check out the PEP repo at hg.python.org and send a patch to p...@python.org. On Jan 30, 2015 3:54 AM, "Neil Girdhar" wrote: > > Neil Girdhar added the comment: > > Is it possible to edit the PEP to refl

[issue23467] Improve byte formatting compatibility between Py2 and Py3

Guido van Rossum added the comment: Yeah, we probably got carried away by purity concerns. -- ___ Python tracker <http://bugs.python.org/issue23467> ___ ___ Pytho

[issue20015] Allow 1-character ASCII unicode where 1-character str is required

Guido van Rossum added the comment: Let's not do this. The time to meddle with Python 2.7 details is long gone. -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.

[issue21998] asyncio: support fork

Guido van Rossum added the comment: I think only (3) is reasonable -- raise RuntimeError. There are too many use cases to consider and the behavior of the selectors seems to vary as well. Apps should ideally not fork with an event loop open; the only reasonable thing to do after a fork with

[issue21998] asyncio: support fork

Guido van Rossum added the comment: I was thinking only in the child. The parent should be able to continue to use the loop as if the fork didn't happen, right? -- ___ Python tracker <http://bugs.python.org/is

[issue21998] asyncio: support fork

Guido van Rossum added the comment: I don't understand. If the fork fails nothing changes right? I guess I'm missing some context or use case. -- ___ Python tracker <http://bugs.python.o

[issue21998] asyncio: support fork

Guido van Rossum added the comment: That's really the problem of the code that calls fork(), not directly of the event loop. There are some very solid patterns around that (I've written several in the distant past, and Unix hasn't changed that much :-). On Tue, May 26, 2015 at

[issue21998] asyncio: support fork

Guido van Rossum added the comment: I don't actually know if the 5th option is possible. My strong requirement is that no matter what the child process does, the parent should still be able to continue using the loop. IMO it's better to leak a FD in the child than to close a resourc

[issue24325] Speedup types.coroutine()

Guido van Rossum added the comment: Since it's a speedup it could also go into 3.5.1. On May 30, 2015 1:22 PM, "Yury Selivanov" wrote: > > Yury Selivanov added the comment: > > Larry, can you accept the first version of the patch (only function that > patches

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Guido van Rossum added the comment: Maybe it's possible to give an interpretation to awaiting on a threaded Future? __await__ could return a new asyncio Future, and add a completion callback to the original Future that makes the asyncio Future ready and transfers the result/exception. This

[issue24383] consider implementing __await__ on concurrent.futures.Future

Guido van Rossum added the comment: So in issue24017 I wrote: """ Maybe it's possible to give an interpretation to awaiting on a threaded Future? __await__ could return a new asyncio Future, and add a completion callback to the original Future that makes the asyncio Future

[issue24383] consider implementing __await__ on concurrent.futures.Future

Changes by Guido van Rossum : -- Removed message: http://bugs.python.org/msg244833 ___ Python tracker <http://bugs.python.org/issue24383> ___ ___ Python-bug

[issue24383] consider implementing __await__ on concurrent.futures.Future

Guido van Rossum added the comment: Sorry, I don't like that either. See my review. -- ___ Python tracker <http://bugs.python.org/issue24383> ___ ___ Pytho

[issue24383] consider implementing __await__ on concurrent.futures.Future

Guido van Rossum added the comment: Thinking about this more I think we should pass on this for now. -- ___ Python tracker <http://bugs.python.org/issue24

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Guido van Rossum added the comment: I think it's actually good feedback and we should fix this during the beta. -- ___ Python tracker <http://bugs.python.org/is

[issue24400] Awaitable ABC incompatible with functools.singledispatch

Guido van Rossum added the comment: FYI I am on vacation and don't have the bandwidth to look into this, so I hope you will all work together to find a solution without my help. -- ___ Python tracker <http://bugs.python.org/is

<    44   45   46   47   48   49   50   51   52   53   >