On 24 April 2015 at 09:34, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
and after the refactoring it becomes
cocall await(cocall f(x))
That doesn't look so bad to me.
I've not been following this discussion (and coroutines make my head
hurt) but this idiom looks like it's bound to result
Victor Stinner wrote:
Oh, I missed something in the PEP 3152: a obj__cocall__() method can
be an iterator/generator, it can be something different than a
cofunction.
In fact, it *can't* be cofunction. It's part of the
machinery for implementing cofunctions.
It's not easy to understand the
Yury Selivanov wrote:
It's a common pattern in asyncio when functions
return futures. It's OK later to refactor those
functions to coroutines *and* vice-versa. This
is a fundamental problem for PEP 3152 approach.
Hmmm. So you have an ordinary function that returns
a future, and you want to
Stephen J. Turnbull wrote:
Yury Selivanov writes:
I also read for async item in iter: as I'm iterating iter
with async item.
I thought that was precisely the intended semantics: item is available
asynchronously.
The async-at-the-end idea could be used here as well.
for item in iter
Barry Warsaw wrote:
Sure, tools can be updated but it is it *necessary*
to choose a syntax that breaks tools?
def async useful():
seems okay to me.
That will break any tool that assumes the word following
'def' is the name of the function being defined.
Putting it at the end would seem
Yury Selivanov wrote:
In a PEP 3152 aware version of asyncio, it's just *not
possible to write*
cocall gather(coro1(1,2), coro(2,3))
you just have to use your 'costart' built-in:
cocall gather(costart(coro1, 1, 2), costart(coro, 2,3)).
Another way to write that would be
cocall
Guido van Rossum wrote:
I think this is the nail in PEP 3152's coffin.
Seems more like a small tack to me. :-)
I've addressed all the issues raised there in
earlier posts.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
On Fri, Apr 24, 2015 at 3:14 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Andrew Svetlov wrote:
But we already have asyncio and code based on asyncio coroutines.
To make it work I should always use costart() in places where asyncio
requires coroutine.
As I understand it, asyncio would
Yury Selivanov wrote:
If you have a future object 'fut', it's not intuitive
or pythonic to write 'cocall fut()'.
Another way to approach that would be to provide
a cofunction await() used like this:
cocall await(fut)
That would read more naturally and wouldn't require
modifying fut at
Paul Moore wrote:
On 24 April 2015 at 09:34, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
cocall await(cocall f(x))
That doesn't look so bad to me.
I've not been following this discussion (and coroutines make my head
hurt) but this idiom looks like it's bound to result in people getting
On Wed, Apr 22, 2015 at 11:26:14AM -0500, Ian Cordasco wrote:
On a separate thread Cory provided an example of what the hints would look
like for *part* of one function in the requests public functional API.
While our API is outwardly simple, the values we accept in certain cases
are actually
On Apr 24, 2015, at 08:03 PM, Greg Ewing wrote:
Putting it at the end would seem least likely to
cause breakage:
def useful() async:
That's not bad IMHO. I wonder how crazy it is in the face of, ahem, function
annotations.
Cheers,
-Barry
___
On Thu, Apr 23, 2015 at 01:51:52PM -0400, Barry Warsaw wrote:
Why async def and not def async?
My concern is about existing tools that already know that def as the first
non-whitespace on the line starts a function/method definition. Think of a
regexp in an IDE that searches backwards from
On Apr 24, 2015, at 11:17 PM, Steven D'Aprano wrote:
It seems to me that tools that search for r^\s*def\s+spam\s*\( are
They would likely search for something like r^\s*def\s+[a-zA-Z0-9_]+ which
will hit def async spam but not async def.
Cheers,
-Barry
Greg,
On 2015-04-24 4:13 AM, Greg Ewing wrote:
Guido van Rossum wrote:
I think this is the nail in PEP 3152's coffin.
Seems more like a small tack to me. :-)
I've addressed all the issues raised there in
earlier posts.
I'm sorry, but this is ridiculous.
You haven't addressed the issues.
On Fri, Apr 24, 2015 at 11:34 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Yury Selivanov wrote:
It's a common pattern in asyncio when functions
return futures. It's OK later to refactor those
functions to coroutines *and* vice-versa. This
is a fundamental problem for PEP 3152
On Fri, Apr 24, 2015 at 09:32:51AM -0400, Barry Warsaw wrote:
On Apr 24, 2015, at 11:17 PM, Steven D'Aprano wrote:
It seems to me that tools that search for r^\s*def\s+spam\s*\( are
They would likely search for something like r^\s*def\s+[a-zA-Z0-9_]+ which
will hit def async spam but not
On Fri, Apr 24, 2015 at 11:03 AM, Ethan Furman et...@stoneleaf.us wrote:
On 04/24, Yury Selivanov wrote:
On 2015-04-24 1:03 PM, Guido van Rossum wrote:
Ditto for `__aiter__` and `__anext__`. I guess this means that the async
equivalent to obtaining an iterator through `it = iter(xs)`
On Apr 24, 2015, at 10:03 AM, Guido van Rossum gu...@python.org wrote:
6. StopAsyncException
What if we required `ait.__anext__()` to return a future?
On top of my previous response, one more thing to consider is that this idea
brings a builtin Future back to the proposal, which has
Sorry, when I wrote future (lower-case 'f') I really meant what Yury
calls *awaitable*. That's either a coroutine or something with an __await__
emthod.
On Fri, Apr 24, 2015 at 3:17 PM, Łukasz Langa luk...@langa.pl wrote:
On Apr 24, 2015, at 10:03 AM, Guido van Rossum gu...@python.org wrote:
Le 24/04/15 19:45, Paul Sokolovsky a écrit :
Hello,
On Fri, 24 Apr 2015 18:27:29 +0100
Ronan Lamy ronan.l...@gmail.com wrote:
PyPy's FAQ
has an explanation of why type hints are not for performance.
http://pypy.readthedocs.org/en/latest/faq.html#would-type-annotations-help-pypy-s-performance
ACTIVITY SUMMARY (2015-04-17 - 2015-04-24)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4814 (+22)
closed 31000 (+43)
total 35814 (+65)
Open issues
On Fri, Apr 24, 2015 at 6:05 PM, Ronan Lamy ronan.l...@gmail.com wrote:
Le 24/04/15 19:45, Paul Sokolovsky a écrit :
Hello,
On Fri, 24 Apr 2015 18:27:29 +0100
Ronan Lamy ronan.l...@gmail.com wrote:
PyPy's FAQ
has an explanation of why type hints are not for performance.
On Sat, Apr 25, 2015 at 02:05:15AM +0100, Ronan Lamy wrote:
* Hints have no run-time effect. The interpreter cannot assume that they
are obeyed.
I know what you mean, but just for the record, annotations are runtime
inspectable, so people can (and probably have already started) to write
Guido van Rossum wrote:
Yury, could you tweak the syntax for `await` so that we can write the
most common usages without parentheses? In particular I'd like to be
able to write
```
return await foo()
with await foo() as bar: ...
foo(await bar(), await bletch())
```
Making 'await' a prefix
On 22 April 2015 at 03:03, Carol Willing willi...@willingconsulting.com wrote:
2. Clearly, great thought has been put into this PEP. If anyone has a good
analysis of the potential impact on Python 3 adoption, please do pass along.
I would be interested in reading the information.
I don't have
On 17 April 2015 at 11:41, Berker Peksağ berker.pek...@gmail.com wrote:
On Fri, Apr 17, 2015 at 4:32 AM, Facundo Batista
facundobati...@gmail.com wrote:
Hola!
I'm asking this because quite some time passed since I was active in
the development of our beloved language.
I'm trying to not
On 22 April 2015 at 03:31, Larry Hastings la...@hastings.org wrote:
On 04/21/2015 04:50 AM, Tal Einat wrote:
As for the default set of accepted types for various convertors, if we
could choose any syntax we liked, something like accept=+{NoneType}
would be much better IMO.
In theory
Wild idea:
Let @ mean async when it's directly in front
of a keyword.
Then we would have:
@def f():
...
@for x in iter:
...
@with context as thing:
...
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
On 25 April 2015 at 14:44, Nick Coghlan ncogh...@gmail.com wrote:
On 22 April 2015 at 03:31, Larry Hastings la...@hastings.org wrote:
On 04/21/2015 04:50 AM, Tal Einat wrote:
As for the default set of accepted types for various convertors, if we
could choose any syntax we liked, something
Victor Stinner wrote:
That's why I suggest to reconsider the idea of supporting an
*optional* from __future__ import async to get async and await as
keywords in the current file. This import would allow all crazy
syntax. The parser might suggest to use the import when it fails to
parse an async
On 18 April 2015 at 15:58, Stefan Behnel stefan...@behnel.de wrote:
Petr Viktorin schrieb am 17.04.2015 um 15:52:
As a background, the PyModuleDef structure [1] is currently:
struct PyModuleDef{
PyModuleDef_Base m_base;
const char* m_name;
const char* m_doc;
On Fri, Apr 24, 2015 at 03:44:45PM +0100, Cory Benfield wrote:
On 24 April 2015 at 15:21, Steven D'Aprano st...@pearwood.info wrote:
If the type hints are wrong, there are two errors: false positives, when
code which should be allowed is flagged as a type error; and false
negatives, when
Le 23/04/15 14:55, Paul Sokolovsky a écrit :
Hello,
On Thu, 23 Apr 2015 09:15:44 -0400
Daniel Holth dho...@gmail.com wrote:
[]
Also ask why no one used type specifier, they are possible since
Python 3.0 ?
Because it is the wrong way for Python.
That's an example of how perceptions differ.
I've tried to catch up with the previous threads. A summary of issues
brought up:
1. precise syntax of `async def` (or do we need it at all)
2. do we need `async for` and `async with` (and how to spell them)
3. syntactic priority of `await`
4. `cocall` vs. `await`
5. do we really need `__aiter__`
Guido,
On 2015-04-24 1:03 PM, Guido van Rossum wrote:
*3. syntactic priority of `await`*
Yury, could you tweak the syntax for `await` so that we can write the most
common usages without parentheses? In particular I'd like to be able to
write
```
return await foo()
with await foo() as bar: ...
On 04/24, Yury Selivanov wrote:
On 2015-04-24 1:03 PM, Guido van Rossum wrote:
Ditto for `__aiter__` and `__anext__`. I guess this means that the async
equivalent to obtaining an iterator through `it = iter(xs)` followed by
`for x over it` will have to look like `ait = await aiter(xs)`
On 24 April 2015 at 15:21, Steven D'Aprano st...@pearwood.info wrote:
If the type hints are wrong, there are two errors: false positives, when
code which should be allowed is flagged as a type error; and false
negatives, when code which should be flagged as an error is not.
Ideally, there
Hello,
On Fri, 24 Apr 2015 18:27:29 +0100
Ronan Lamy ronan.l...@gmail.com wrote:
Also ask why no one used type specifier, they are possible since
Python 3.0 ?
Because it is the wrong way for Python.
That's an example of how perceptions differ. In my list,
everyone(*) uses them -
On Apr 24, 2015, at 6:32 AM, Barry Warsaw ba...@python.org wrote:
On Apr 24, 2015, at 11:17 PM, Steven D'Aprano wrote:
It seems to me that tools that search for r^\s*def\s+spam\s*\( are
They would likely search for something like r^\s*def\s+[a-zA-Z0-9_]+ which
will hit def async spam
Hello,
On Fri, 24 Apr 2015 12:04:27 -0700
Łukasz Langa luk...@langa.pl wrote:
[]
They would likely search for something like
r^\s*def\s+[a-zA-Z0-9_]+ which will hit def async spam but not
async def”.
Realistically that can’t be what they’re doing because of multiple
string literals,
On Apr 24, 2015, at 10:03 AM, Guido van Rossum gu...@python.org wrote:
1. precise syntax of `async def`
So I still prefer `async def`.
Me too. Also, we would use a similar vocabulary to existing users of the
feature. This is exactly how Hack does it:
Victor,
On 2015-04-24 5:32 PM, Victor Stinner wrote:
7. compatibility with asyncio and existing users of it
The current state of the PEP makes types.coroutine() mandatory. If a
generator-based coroutine is not modified with types.coroutine, await
cannot be used on it. To be more concrete:
Hi,
2015-04-24 19:03 GMT+02:00 Guido van Rossum gu...@python.org:
1. precise syntax of `async def`
Of all the places to put `async` I still like *before* the `def` the best.
So do I.
2. do we need `async for` and `async with`
Yes we do.
I agree.
3. syntactic priority of `await`
Lukasz,
On 2015-04-24 5:37 PM, Łukasz Langa wrote:
(Though maybe we should consider `await for` and `await with`? That would have
the advantage of making it easy to scan for all suspension points by searching
for /await/. But being a verb it doesn't read very well.)
I’m on the fence here.
45 matches
Mail list logo
