On 25 April 2015 at 16:23, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> 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.
>
>
> But how is an awaitable supposed to raise StopIteratio
Guido van Rossum wrote:
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.
But how is an awaitable supposed to raise StopIteration
if it's implemented by a generator or async def[*] function
On 25 April 2015 at 07:37, Łukasz Langa wrote:
> On Apr 24, 2015, at 10:03 AM, 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?
>
> +1
>
> Yury points out there was likely
On 22 April 2015 at 03:03, Carol Willing 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 hard data, but I do get to s
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 asyn
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
https://mail.
On 25 April 2015 at 14:44, Nick Coghlan wrote:
> On 22 April 2015 at 03:31, Larry Hastings 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}"
>>
On 22 April 2015 at 03:31, Larry Hastings 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 Argument Clin
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 ope
On 18 April 2015 at 15:58, Stefan Behnel 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;
>> Py_ssize
On 17 April 2015 at 11:41, Berker Peksağ wrote:
> On Fri, Apr 17, 2015 at 4:32 AM, Facundo Batista
> 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 break any new rule not known by me.
>
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
ru
On Fri, Apr 24, 2015 at 6:05 PM, Ronan Lamy wrote:
> Le 24/04/15 19:45, Paul Sokolovsky a écrit :
>
>> Hello,
>>
>> On Fri, 24 Apr 2015 18:27:29 +0100
>> Ronan Lamy wrote:
>>
>> PyPy's FAQ
> has an explanation of why type hints are not for performance.
>
> http://pypy.readthedocs.or
Le 24/04/15 19:45, Paul Sokolovsky a écrit :
Hello,
On Fri, 24 Apr 2015 18:27:29 +0100
Ronan Lamy 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
You probably intend
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 wrote:
>
> On Apr 24, 2015, at 10:03 AM, Guido van Rossum wrote:
>
> *6. StopAsyncException*
>
> On Apr 24, 2015, at 10:03 AM, Guido van Rossum 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 already been rej
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.
Hi,
2015-04-24 19:03 GMT+02:00 Guido van Rossum :
> 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`
>
> Yury, could
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: async
> On Apr 24, 2015, at 10:03 AM, Guido van Rossum 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:
http://docs.hhvm.com/manual/en/hack.async.php
<
Hello,
On Fri, 24 Apr 2015 12:04:27 -0700
Łukasz Langa 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 6:32 AM, 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
Hello,
On Fri, 24 Apr 2015 18:27:29 +0100
Ronan Lamy 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 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 spa
On Fri, Apr 24, 2015 at 11:03 AM, Ethan Furman 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)` followed by
>
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)`
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: ...
Le 23/04/15 14:55, Paul Sokolovsky a écrit :
Hello,
On Thu, 23 Apr 2015 09:15:44 -0400
Daniel Holth 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, every
On Fri, Apr 24, 2015 at 03:44:45PM +0100, Cory Benfield wrote:
> On 24 April 2015 at 15:21, Steven D'Aprano 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 s
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__`
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 wit
On 24 April 2015 at 15:21, Steven D'Aprano 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 should be no false
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 actua
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. W
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 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
__
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 back
On Fri, Apr 24, 2015 at 11:34 AM, Greg Ewing
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 approach.
>
>
> Hmmm. So
On Fri, Apr 24, 2015 at 3:14 AM, Greg Ewing 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 require changes
Paul Moore wrote:
On 24 April 2015 at 09:34, Greg Ewing 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
the idea that you scatter "c
On 24 April 2015 at 09:34, Greg Ewing 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 in people getting
the
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 i
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 t
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 who
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
https://mail.python.
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 gather(Task
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 all
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 l
48 matches
Mail list logo
