This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients Martin.Teichmann, gvanrossum, vstinner, yselivanov
Date 2014-09-15.17:51:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1410803481.24.0.515331166833.issue22412@psf.upfronthosting.co.za>
In-reply-to
Content
OK. Trying to understand the patch, there seem to be three parts to it:

(a) Changes to CPython to add a new flag to the exec/eval flags argument that sets the GENERATOR flag in the resulting code object. This seems the most fundamental, but it also feels the trickiest. It is a change to a built-in function so it must be supported by other Python implementations (esp. PyPy, Jython, IronPython, Cython). It also feels "wrong" -- it may be the case that you or your colleagues *want* to be able to write "yield from XXX" at the >>> prompt, but that doesn't make it a good idea. Especially since it will never be supported by the *regular* REPL -- it will only work in your customized REPL, but it isn't particularly obvious why it works there and not elsewhere. Also, I think supporting "yield from" in the repl() will teach the wrong thing -- people used to this working will attempt to use "yield from" at the top level in a script or module and be confused why it doesn't work there. I really think that it's must better to give them a helper function such as was shown early in the python-ideas thread. (Once imported, it's less typing too!)

(b) Changes to the readline module to support some kind of async behavior, so that you can use the readline module's editing behavior from within an asyncio event loop. I can see the advantage of this, and I am not philosophically opposed (as I am for (a)). Without this, your users would either not have the benefit of convenient input editing, or you would have to reimplement the entire set of features of GNU readline afresh, which does sound excessive. However, once you give up on (a), you don't need (b) either. On the pragmatics of the patch, I don't have time to review it in detail, and I don't know if you can easily find anyone who does -- I just want to note that as it stands, there is a bug in the code, at least on OS X, since I get this:

>>> import time, readline
>>> time.sleep(1); readline._input()
asd
asd
>>> python.exe(67432,0x7fff7d790310) malloc: *** error for object 0x7fc8506046f0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

(Immediately after the second input line, I quickly typed 'asd' and pressed Return. The 'asd' got echoed, I got a new >>> prompt, and then something crashed.)

(c) A new function input() in the asyncio module. If (a) and (b) were accepted in Python, this might as well be part of your third-party module that implements your interactive shell, so there's not strictly a need for this. It also doesn't work on all platforms (e.g. I don't think it will work on Windows).

My recommendation to you is to give up on (a) and instead add the suggested helper function to the globals in your own REPL, and tell your users to use that at the top-level. Python doesn't support yield-from at the top level in scripts and modules, and they may as well get used to that idea. You can still, separately, work on (b), but you will have to find someone in the core dev team who is motivated enough to help you make it work properly or fail safely (on platforms where it can't be made to work). For (c), I don't think that's ready for inclusion in the stdlib either (though perhaps we could add some descendant of it to Python 3.5 if you got (b) accepted).
History
Date User Action Args
2014-09-15 17:51:21gvanrossumsetrecipients: + gvanrossum, vstinner, yselivanov, Martin.Teichmann
2014-09-15 17:51:21gvanrossumsetmessageid: <1410803481.24.0.515331166833.issue22412@psf.upfronthosting.co.za>
2014-09-15 17:51:21gvanrossumlinkissue22412 messages
2014-09-15 17:51:20gvanrossumcreate