[Python-Dev] iscoroutinefunction vs. coroutines
Hi, Is this pattern def foo(): return bar() async def bar(): await async def async_main(): await foo() considered to be valid? The reason I'm asking is that some code out there likes to accept a might-be-a-coroutine-function argument, using def run_callback(fn): if iscoroutinefunction(fn): res = await fn() else: res = fn() instead of def run_callback(fn): res = fn() if iscoroutine(res): res = await res() The former obviously breaks when somebody combines these idioms and calls run_callback(foo) but I can't help but wonder whether the latter use might be deprecated, or even warned about, in the future and/or with non-CPython implementations. -- -- Matthias Urlichs signature.asc Description: Digital signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iscoroutinefunction vs. coroutines
On Thu, Mar 9, 2017 at 3:04 AM, Matthias Urlichs wrote: > Is this pattern > > def foo(): > return bar() > async def bar(): > await > > async def async_main(): > await foo() > > considered to be valid? > Yes, it is valid. > The reason I'm asking is that some code out there likes to accept a > might-be-a-coroutine-function argument, using > > def run_callback(fn): > if iscoroutinefunction(fn): > res = await fn() > else: > res = fn() > > instead of > > def run_callback(fn): > res = fn() > if iscoroutine(res): > res = await res() > > The former obviously breaks when somebody combines these idioms and calls > > run_callback(foo) > > but I can't help but wonder whether the latter use might be deprecated, or > even warned about, in the future and/or with non-CPython implementations. > In general I would recommend against patterns that support either awaitables or non-awaitables. The recommended solution is for run_callback() to require an awaitable, and if you have a function that just returns the value, you should wrap it in an async def that doesn't use await. The difference between the two versions of run_callback() is merely the difference you pointed out -- iscoroutinefunction(f) is not entirely equivalent to iscoroutine(f()). If you're thinking in terms of static types (e.g. PEP 484 and mypy), in the latter version the type of `res` is problematic (it's Union[Awaitable[T], T]), but there's an easy way to rewrite it to avoid that, while still calling iscoroutine(). If there's something else you worry about with the latter please clarify. But in general I would stay far away from this kind of "do what I mean" API -- they are hard to reason about and difficult to debug. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Translated Python documentation
[catching up on an older thread] On Feb 27, 2017, at 05:31, Victor Stinner wrote: > 2017-02-25 19:19 GMT+01:00 Brett Cannon : >> It's getting a little hard to tease out what exactly is being asked at this >> point. Perhaps it's time to move the discussion over to a translation SIG >> (which probably needs to be created unless the old >> https://mail.python.org/mailman/listinfo/i18n-sig makes sense)? That way >> active translators can figure out exactly what they want to ask of >> python-dev in terms of support and we can have a more focused discussion. > > Things are already happening in the background on other lists and > other Python projects, but the problem is that the translation project > seems "blocked" for some reasons. That's why I started the thread. > > Example of a recent CPython PR, blocked: > https://github.com/python/cpython/pull/195 > "bpo-28331: fix "CPython implementation detail:" label is removed when > content is translated." opened 7 days ago by INADA Naoki (JP > translation) > > Example of a docsbuild PR: > https://github.com/python/docsbuild-scripts/pull/8 > "[WIP] Add french, japanese, and chinese", opened at 12 Dec 2016 by > Julien Palard (FR translation) > > See also Julien Palard's threads on python-ideas: no decision was > taken, so the project is blocked. > > According to this thread, there is an official GO for official > translations, so these PR should be merged, right? I don't know exactly what you mean by an "official GO" but I don't think there has been any agreement yet since there hasn't been a specific proposal yet to review. I think what *was* agreed is that, in principle, translation *sounds* like a good idea to follow up on elsewhere, i.e. on one of the existing sigs, and then come back with a specific proposal for review. Thinking about that a little more, I think the appropriate output of those discussions should be a process PEP. Then we can review the proposal properly and also have the process clearly documented for the future. -- Ned Deily [email protected] -- [] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Impoverished compare ...
Hi. I'm looking at stuff proposed over on Python-Ideas, and I'd appreciate some pointers as to the basics of how C-level objects are generally compared in Python 3. The issue is related to the performance of PyObject_RichCompare. I got to the point where I was trying to work out what was the _alternative_ to RichCompare. If a comparison is not "rich", then what is it? There's a tp_richcompare slot in the type structure, but I haven't noticed anything else obvious for simple comparison (In 2.x days - which I have more experience with - __cmp__ was a thing which now seems to be gone. I understand the Python-level changes with sort(..., key=foo) but I've not looked at the underlying C implementation until now). Anyway, I followed things as far as Objects/typeobject.c and then I got bitten by a macro dialect that I don't immediately grok, so anything that spells it out a bit more plainly would be nice (I can follow the code if I need to - but a shortcut from those who know this off the top of their head would be helpful). Thanks, E. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Translated Python documentation
2017-03-10 0:35 GMT+01:00 Ned Deily : > I don't know exactly what you mean by an "official GO" but I don't think > there has been any agreement yet since there hasn't been a specific proposal > yet to review. I think what *was* agreed is that, in principle, translation > *sounds* like a good idea to follow up on elsewhere, i.e. on one of the > existing sigs, and then come back with a specific proposal for review. > Thinking about that a little more, I think the appropriate output of those > discussions should be a process PEP. Then we can review the proposal > properly and also have the process clearly documented for the future. FYI we are already working on a PEP with Julien Palard (FR) and INADA Naoki (JP). We will post it when it will be ready ;-) Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Impoverished compare ...
On Thu, Mar 9, 2017, at 18:43, Erik wrote: > Hi. > > I'm looking at stuff proposed over on Python-Ideas, and I'd appreciate > some pointers as to the basics of how C-level objects are generally > compared in Python 3. > > The issue is related to the performance of PyObject_RichCompare. I got > to the point where I was trying to work out what was the _alternative_ > to RichCompare. If a comparison is not "rich", then what is it? There's > a tp_richcompare slot in the type structure, but I haven't noticed > anything else obvious for simple comparison (In 2.x days - which I have > more experience with - __cmp__ was a thing which now seems to be gone. I > understand the Python-level changes with sort(..., key=foo) but I've not > looked at the underlying C implementation until now). In 2.x the C version of __cmp__ was tp_compare (and it existed even in python 0.9.1, which had neither dunder methods nor tp_richcompare). I assume that the "rich compare" name was retained in Python 3 for the same reason that other names like PyLongObject, PyUnicodeObject were (not PyStringObject, though, presumably because they don't want people to unintentionally create a bytes-only API as a result of a lazy porting process). Maybe Python 4000 can alias it to tp_compare (PyIntObject, PyStringObject) and Python 5000 can get rid of the current names. It's "rich" because it knows which of the object-level methods (less than, greater than, etc) is being called, whereas tp_compare/__cmp__ did not. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale
On 9 March 2017 at 07:58, Guido van Rossum wrote: > On Wed, Mar 8, 2017 at 4:35 AM, Nick Coghlan wrote: > >> >> On 5 March 2017 at 17:50, Nick Coghlan wrote: >> >>> Late last year I started working on a change to the CPython CLI (*not* >>> the shared library) to get it to coerce the legacy C locale to something >>> based on UTF-8 when a suitable locale is available. >>> >>> After a couple of rounds of iteration on linux-sig and python-ideas, I'm >>> now bringing it to python-dev as a concrete proposal for Python 3.7. >>> >> >> In terms of resolving this PEP, if Guido doesn't feel inclined to wade >> into the intricacies of legacy C locale handling, Barry has indicated he'd >> be happy to act as BDFL-Delegate :) >> > > Hi Nick and Barry, I'd very much appreciate if you two could resolve this > without involving me. > OK, I've added Barry to the PEP as BDFL-Delegate: https://github.com/python/peps/commit/4c46c5710031cac03a8d1ab7639272957998a1cc Thanks for the quick response! Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can I revoke PEP 103 (info about git)?
On 9 March 2017 at 06:53, Steven D'Aprano wrote: > On Wed, Mar 08, 2017 at 04:30:41PM +0100, Oleg Broytman wrote: > > On Wed, Mar 08, 2017 at 09:50:06AM -0500, Barry Warsaw > wrote: > > > > It's also okay to remove much of the content and just leave a > placeholder. > > > The historical record would of course always be available in the vcs. > > > >Thanks! That's what I've planned to do in case we don't remove PEPs. > > Why remove the content? > > In fact, since its just an informational PEP, why withdraw it? The PEP Index organises itself by status, so withdrawing it moves it down into the historical PEPs section, and out of the active section. (We're probably due for a PEP "spring clean" in general, but doing that is about as exciting as actual spring cleaning, so it's easy to keep putting it off) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
