PJ Eby wrote:
I find this a little weird. Why not just have `with` and `for` inside
a coroutine dynamically check the iterator or context manager, and
either behave sync or async accordingly? Why must there be a
*syntactic* difference?
It depends on whether you think it's important to
have a
Yury Selivanov wrote:
I think there is another way... instead of pushing
GET_ITER
...
YIELD_FROM
opcodes, we'll need to replace GET_ITER with another one:
GET_ITER_SPECIAL
...
YIELD_FROM
I'm lost. What Python code are you suggesting this
would be generated from?
--
Greg
On 23/04/2015 6:32 a.m., Andrew Svetlov wrote:
If we forbid to call `async def` from regualr code how asyncio should
work? I'd like to push `async def` everywhere in asyncio API where
asyncio.coroutine required.
As I suggested earlier, a way could be provided to mark a
function as callable usin
On 04/23/2015 04:18 AM, Yury Selivanov wrote:
2. We'll hack Gen(/ceval.c?) objects to raise an error if they
are called directly and have a 'CO_COROUTINE' flag.
By "Gen", do you mean the generator-function or the
generator-iterator?
That flag has to be on the generator-function, not the
gener
I guess to raise exception on unwinded async generator in destructor
even in non-debug mode.
Debug mode may have more complex info with source_traceback included,
as Victor Stinner does for CoroWrapper.
On Thu, Apr 23, 2015 at 4:27 AM, Yury Selivanov wrote:
> Greg,
>
> On 2015-04-22 7:47 PM, Gre
Greg,
On 2015-04-22 7:47 PM, Greg Ewing wrote:
Yury Selivanov wrote:
On the other hand, I hate the idea
of grammatically requiring parentheses for 'await'
expressions. That feels non-pytonic to me.
How is it any different from grammatically requiring
parens in an ordinary function call? Nob
On Thu, Apr 23, 2015 at 3:35 AM, Guido van Rossum wrote:
> On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
> wrote:
>>
>> Guido van Rossum wrote:
>>>
>>> On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to
>>> wrap a coroutine in a Task, the way its done in asyncio by the Task()
>
On 2015-04-22 9:04 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:55 PM, Yury Selivanov
wrote:
On 2015-04-22 8:35 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
wrote:
Guido van Rossum wrote:
On Wed, Apr 22, > OTOH I'm still struggling with what you h
On Wed, Apr 22, 2015 at 5:55 PM, Yury Selivanov
wrote:
> On 2015-04-22 8:35 PM, Guido van Rossum wrote:
>
>> On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
>> wrote:
>>
>> Guido van Rossum wrote:
>>>
>>> On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to
wrap a coroutine
On 2015-04-22 8:35 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
wrote:
Guido van Rossum wrote:
On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to
wrap a coroutine in a Task, the way its done in asyncio by the Task()
constructor, the loop.create
On Wed, Apr 22, 2015 at 2:38 PM, Chris Barker wrote:
>
>
> Oh wait, maybe it won't -- a string IS a sequence of strings. That's why
>> this is an insidious bug in the first place.
>
> On Tue, Apr 21, 2015 at 11:32 PM, Terry Reedy wrote:
>
>
>> I was just thinking today that for this, typing need
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
wrote:
> Guido van Rossum wrote:
>
>> On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to
>> wrap a coroutine in a Task, the way its done in asyncio by the Task()
>> constructor, the loop.create_task() method, and the async() functio
> Oh wait, maybe it won't -- a string IS a sequence of strings. That's why
> this is an insidious bug in the first place.
On Tue, Apr 21, 2015 at 11:32 PM, Terry Reedy wrote:
> I was just thinking today that for this, typing needs a subtraction
> (difference) operation in addition to an additio
Guido van Rossum wrote:
On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to wrap a coroutine
in a Task, the way its done in asyncio by the Task() constructor, the
loop.create_task() method, and the async() function
That's easy. You can always use costart() to adapt a cofunc
Yury Selivanov wrote:
On the other hand, I hate the idea
of grammatically requiring parentheses for 'await'
expressions. That feels non-pytonic to me.
How is it any different from grammatically requiring
parens in an ordinary function call? Nobody ever
complained about that.
In the PEP 3152
Hello,
On Wed, 22 Apr 2015 09:53:39 -0700
Rajiv Kumar wrote:
> I'd like to suggest another way around some of the issues here, with
> apologies if this has already been discussed sometime in the past.
>
> From the viewpoint of a Python programmer, there are two distinct
> reasons for wanting to
Hello,
On Wed, 22 Apr 2015 13:31:18 -0700
Guido van Rossum wrote:
> On Wed, Apr 22, 2015 at 1:10 PM, Andrew Svetlov
> wrote:
>
> > On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby
> > wrote:
> > > On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov
> > >
> > wrote:
> > >> It is an error to pass a regula
> On Apr 22, 2015, at 2:45 PM, Facundo Batista wrote:
>
> Hola!
>
> I just commited a simple improvement to HTTPError repr, and checking
> in the source code page [0], I see that my commit has a small
> "default" besides it; and other commits don't have that, but have 2.7,
> or 3.4, etc...
>
>
The default branch is going to become 3.5, so you're fine.
On Wed, Apr 22, 2015 at 5:45 PM Facundo Batista
wrote:
> Hola!
>
> I just commited a simple improvement to HTTPError repr, and checking
> in the source code page [0], I see that my commit has a small
> "default" besides it; and other com
On Wed, Apr 22, 2015 at 6:46 PM, Brett Cannon wrote:
> The default branch is going to become 3.5, so you're fine.
Thanks!!
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Twitter: @facundobatista
___
Python-D
Hola!
I just commited a simple improvement to HTTPError repr, and checking
in the source code page [0], I see that my commit has a small
"default" besides it; and other commits don't have that, but have 2.7,
or 3.4, etc...
So, question: Did I commit in the correct branch? Should I have done
anyth
Ludovic,
On 2015-04-22 5:00 PM, Ludovic Gasc wrote:
Not related, but one of my coworkers asked me if with the new syntax it
will be possible to write an async decorator for coroutines.
If I understand correctly new grammar in PEP, it seems to be yes, but could
you confirm ?
There shouldn't be
2015-04-22 22:46 GMT+02:00 Victor Stinner :
>
> Kind (A):
>
> - "yield-from coroutines" or "coroutines based on yield-from"
> - maybe "asyncio coroutines"
> - "legacy coroutines"?
>
"legacy coroutines" name has the advantage to be directly clear it isn't a
good idea to write new source code with t
Greg Ewing canterbury.ac.nz> writes:
> I still don't like the idea of hijacking the generic
> term "coroutine" and using it to mean this particular
> type of object.
There are only two hard things in Computer Science: cache invalidation
and naming things.
-- Phil Karlton
:-)
When revie
On Wed, Apr 22, 2015 at 1:10 PM, Andrew Svetlov
wrote:
> On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby wrote:
> > On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov
> wrote:
> >> It is an error to pass a regular context manager without ``__aenter__``
> >> and ``__aexit__`` methods to ``async with``. I
Hi,
Guido van Rossum python.org> writes:
> I'm slowly warming up to Greg's notion that you can't call a coroutine (or
whatever it's called) without a special keyword.
A huge part of the asyncio module is based on "yield from fut" where fut is
a Future object.
How do you write this using the PEP
Hi PJ,
On 2015-04-22 3:44 PM, PJ Eby wrote:
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov wrote:
It is an error to pass a regular context manager without ``__aenter__``
and ``__aexit__`` methods to ``async with``. It is a ``SyntaxError``
to use ``async with`` outside of a coroutine.
I find
+1 about Andrew Svetlov proposition: please help to migrate as smoothly as
possible to async/await.
--
Ludovic Gasc (GMLudo)
http://www.gmludo.eu/
2015-04-22 20:32 GMT+02:00 Andrew Svetlov :
> For now I can use mix asyncio.coroutines and `async def` functions, I
> mean I can write `await f()` in
On 04/22, PJ Eby wrote:
> tl;dr: I like the overall ideas but hate the syntax and type
> segregation involved: declaring a function async at the top is OK to
> enable async with/for semantics and await expressions, but the rest
> seems unnecessary and bad for writing robust code. (e.g. note that
On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby wrote:
> On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov
> wrote:
>> It is an error to pass a regular context manager without ``__aenter__``
>> and ``__aexit__`` methods to ``async with``. It is a ``SyntaxError``
>> to use ``async with`` outside of a cor
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov wrote:
> It is an error to pass a regular context manager without ``__aenter__``
> and ``__aexit__`` methods to ``async with``. It is a ``SyntaxError``
> to use ``async with`` outside of a coroutine.
I find this a little weird. Why not just have `
On Wed, Apr 22, 2015 at 10:24 PM, Yury Selivanov
wrote:
>
>
> On 2015-04-22 2:53 PM, Andrew Svetlov wrote:
>>
>> On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov
>> wrote:
>
> [...]
>>>
>>>
If we forbid to call `async def` from regualr code how asyncio should
work? I'd like to push `asyn
On 2015-04-22 2:53 PM, Andrew Svetlov wrote:
On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov wrote:
[...]
If we forbid to call `async def` from regualr code how asyncio should
work? I'd like to push `async def` everywhere in asyncio API where
asyncio.coroutine required.
You'll have to us
On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov wrote:
> Andrew,
>
> On 2015-04-22 2:32 PM, Andrew Svetlov wrote:
>>
>> For now I can use mix asyncio.coroutines and `async def` functions, I
>> mean I can write `await f()` inside async def to call
>> asyncio.coroutine `f` and vise versa: I can use
Andrew,
On 2015-04-22 2:32 PM, Andrew Svetlov wrote:
For now I can use mix asyncio.coroutines and `async def` functions, I
mean I can write `await f()` inside async def to call
asyncio.coroutine `f` and vise versa: I can use `yield from g()`
inside asyncio.coroutine to call `async def g(): ...`.
For now I can use mix asyncio.coroutines and `async def` functions, I
mean I can write `await f()` inside async def to call
asyncio.coroutine `f` and vise versa: I can use `yield from g()`
inside asyncio.coroutine to call `async def g(): ...`.
If we forbid to call `async def` from regualr code how
On Wed, Apr 22, 2015 at 9:26 AM, Ian Cordasco
wrote:
> As the other maintainer of requests, I think having hints *might* help
> some developers, but looking at what Cory generated (which looks to be
> valid), I'm wondering about something else with Type Hints.
>
> I've heard several people say "J
On Wed, Apr 22, 2015 at 9:12 AM, Skip Montanaro
wrote:
>
> On Wed, Apr 22, 2015 at 10:43 AM, Guido van Rossum
> wrote:
>
>> For Requests, it looks like it may be better not to have stubs at all.
>
>
> Can you expand on this? Why would Requests be any different than any other
> module/package?
>
Hi Rajiv,
On 2015-04-22 12:53 PM, Rajiv Kumar wrote:
I'd like to suggest another way around some of the issues here, with
apologies if this has already been discussed sometime in the past.
From the viewpoint of a Python programmer, there are two distinct reasons
for wanting to suspend executio
Whoops, sorry. Yeah, I knew about that behavior, but in hindsight it's
obviously going to be a surprise for others :)
One plain zip file coming up for the next release. All the binaries will be
signed and paranoid people can check the GPG sig and embed their own hashes if
not the files themselv
I'd like to suggest another way around some of the issues here, with
apologies if this has already been discussed sometime in the past.
>From the viewpoint of a Python programmer, there are two distinct reasons
for wanting to suspend execution in a block of code:
1. To yield a value from an itera
On Wed, Apr 22, 2015 at 11:30 AM, Skip Montanaro
wrote:
>
>
> On Wed, Apr 22, 2015 at 11:26 AM, 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.
>>
>
> Thanks. That enco
On Wed, Apr 22, 2015 at 11:12 AM, Skip Montanaro
wrote:
>
> On Wed, Apr 22, 2015 at 10:43 AM, Guido van Rossum
> wrote:
>
>> For Requests, it looks like it may be better not to have stubs at all.
>
>
> Can you expand on this? Why would Requests be any different than any other
> module/package?
>
Hi Guido,
On 2015-04-22 11:50 AM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 8:40 AM, Yury Selivanov
wrote:
On the one hand I like your idea to disallow calling
coroutines without a special keyword (await in case of
PEP 492). It has downsides, but there is some
elegance in it. On the ot
On Wed, Apr 22, 2015 at 10:43 AM, Guido van Rossum wrote:
> For Requests, it looks like it may be better not to have stubs at all.
Can you expand on this? Why would Requests be any different than any other
module/package?
As for versioning, I think stub files would absolutely have to declare t
On Wed, Apr 22, 2015 at 8:40 AM, Yury Selivanov
wrote:
>
> On the one hand I like your idea to disallow calling
> coroutines without a special keyword (await in case of
> PEP 492). It has downsides, but there is some
> elegance in it. On the other hand, I hate the idea
> of grammatically requiri
I definitely think that we shouldn't jump the gun here and tread carefully.
Both Marc-André and Cory brought up good things to watch out for.
For closed-source software the only way to obtain stubs is presumably from
the author, if they care. As Gregory Smith said in another thread, the
tooling wi
Hi Greg,
On 2015-04-22 2:05 AM, Greg Ewing wrote:
Yury Selivanov wrote:
1. CO_ASYNC flag was renamed to CO_COROUTINE;
2. sys.set_async_wrapper() was renamed to
sys.set_coroutine_wrapper();
3. New function: sys.get_coroutine_wrapper();
4. types.async_def() renamed to types.coroutine();
I
On 22 April 2015 at 13:45, Paul Moore wrote:
> On 21 April 2015 at 23:05, Steve Dower wrote:
>> I made it a self-extracting RAR file so it could be signed, but I've already
>> had multiple people query it so the next release will probably just be a
>> plain ZIP file. I just need to figure out s
On 21 April 2015 at 23:05, Steve Dower wrote:
> I made it a self-extracting RAR file so it could be signed, but I've already
> had multiple people query it so the next release will probably just be a
> plain ZIP file. I just need to figure out some reliable way of validating the
> download othe
On 22 April 2015 at 11:46, M.-A. Lemburg wrote:
> Unlike with translations, where missing or poor ones don't have
> much effect on the usefulness of the software, a type checker
> would complain loudly and probably show lots of false positives
> (if you read a type bug as "positive"), causing the
On 21 April 2015 at 17:59, Guido van Rossum wrote:
> For me, PEP 484 is a stepping stone. Among the authors of PEP 484 there was
> much discussion about duck typing, and mypy even has some limited support
> for duck typing (I think you can still find it by searching the mypy code
> for "protocol")
On 21 April 2015 at 18:12, Steven D'Aprano wrote:
> I expect that dealing with duck typing will be very high on the list
> of priorities for the future. In the meantime, for this specific use-case,
> you're probably not going to be able to statically check this type hint.
> Your choices would be:
On 21.04.2015 18:08, Guido van Rossum wrote:
> On Tue, Apr 21, 2015 at 12:33 AM, M.-A. Lemburg wrote:
>
>> On 21.04.2015 05:37, Guido van Rossum wrote:
>>> On Mon, Apr 20, 2015 at 4:41 PM, Jack Diederich
>> wrote:
* Uploading stubs for other people's code is a terrible idea. Who do I
c
54 matches
Mail list logo
