On Wed, Apr 22, 2015 at 10:43 AM, Guido van Rossum gu...@python.org 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
Hi Guido,
On 2015-04-22 11:50 AM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 8:40 AM, Yury Selivanov yselivanov...@gmail.com
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
On Wed, Apr 22, 2015 at 11:12 AM, Skip Montanaro skip.montan...@gmail.com
wrote:
On Wed, Apr 22, 2015 at 10:43 AM, Guido van Rossum gu...@python.org
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
On 21 April 2015 at 23:05, Steve Dower steve.do...@microsoft.com 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
On Wed, Apr 22, 2015 at 11:30 AM, Skip Montanaro skip.montan...@gmail.com
wrote:
On Wed, Apr 22, 2015 at 11:26 AM, Ian Cordasco graffatcolmin...@gmail.com
wrote:
On a separate thread Cory provided an example of what the hints would
look like for *part* of one function in the requests
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
On 22 April 2015 at 13:45, Paul Moore p.f.mo...@gmail.com wrote:
On 21 April 2015 at 23:05, Steve Dower steve.do...@microsoft.com 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
On Wed, Apr 22, 2015 at 8:40 AM, Yury Selivanov yselivanov...@gmail.com
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
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 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
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 still don't like the idea of hijacking the generic
On 4/21/2015 6:41 PM, Chris Barker wrote:
Well, it'll catch passing in a string instead of a sequence of strings
-- one of teh common and semi-insidious type errors I see a lot (at
least with newbies).
Oh wait, maybe it won't -- a string IS a sequence of strings. That's why
this is an
On 4/21/2015 6:50 PM, Chris Barker wrote:
On Tue, Apr 21, 2015 at 11:58 AM, Paul Sokolovsky pmis...@gmail.com
mailto:pmis...@gmail.com wrote:
It does, and hope people won't be caught in static typechecking
loop and consider other usages too.
I an interested is using type hints for
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
On Wed, Apr 22, 2015 at 9:12 AM, Skip Montanaro skip.montan...@gmail.com
wrote:
On Wed, Apr 22, 2015 at 10:43 AM, Guido van Rossum gu...@python.org
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
On Wed, Apr 22, 2015 at 9:26 AM, Ian Cordasco graffatcolmin...@gmail.com
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
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
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
On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov yselivanov...@gmail.com 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
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():
On 2015-04-22 2:53 PM, Andrew Svetlov wrote:
On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov yselivanov...@gmail.com 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
On Wed, Apr 22, 2015 at 10:24 PM, Yury Selivanov
yselivanov...@gmail.com wrote:
On 2015-04-22 2:53 PM, Andrew Svetlov wrote:
On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
[...]
If we forbid to call `async def` from regualr code how asyncio should
work?
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov yselivanov...@gmail.com 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.
Greg Ewing greg.ewing at 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
:-)
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
On 2015-04-22 9:04 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:55 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
On 2015-04-22 8:35 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Guido van Rossum wrote:
On Wed,
On Wed, Apr 22, 2015 at 2:38 PM, Chris Barker chris.bar...@noaa.gov 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 tjre...@udel.edu wrote:
I was just thinking today
On 2015-04-22 8:35 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing greg.ew...@canterbury.ac.nz
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 Thu, Apr 23, 2015 at 3:35 AM, Guido van Rossum gu...@python.org wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing greg.ew...@canterbury.ac.nz
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
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 tjre...@udel.edu wrote:
I was just thinking today that for this, typing needs a subtraction
(difference) operation in addition
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?
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 yselivanov...@gmail.com wrote:
Greg,
On
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
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing greg.ew...@canterbury.ac.nz
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
On Wed, Apr 22, 2015 at 5:55 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
On 2015-04-22 8:35 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Guido van Rossum wrote:
On Wed, Apr 22, OTOH I'm still struggling with what you
2015-04-22 22:46 GMT+02:00 Victor Stinner victor.stin...@gmail.com:
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
On Apr 22, 2015, at 2:45 PM, Facundo Batista facundobati...@gmail.com 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
Hello,
On Wed, 22 Apr 2015 13:31:18 -0700
Guido van Rossum gu...@python.org wrote:
On Wed, Apr 22, 2015 at 1:10 PM, Andrew Svetlov
andrew.svet...@gmail.com wrote:
On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby p...@telecommunity.com
wrote:
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov
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
The default branch is going to become 3.5, so you're fine.
On Wed, Apr 22, 2015 at 5:45 PM Facundo Batista facundobati...@gmail.com
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
On Wed, Apr 22, 2015 at 6:46 PM, Brett Cannon br...@python.org 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
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
Hello,
On Wed, 22 Apr 2015 09:53:39 -0700
Rajiv Kumar rajiv.ku...@gmail.com 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
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
On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby p...@telecommunity.com wrote:
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
It is an error to pass a regular context manager without ``__aenter__``
and ``__aexit__`` methods to ``async with``. It is a ``SyntaxError``
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
+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 andrew.svet...@gmail.com:
For now I can use mix asyncio.coroutines and `async def` functions, I
mean I
Hi PJ,
On 2015-04-22 3:44 PM, PJ Eby wrote:
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov yselivanov...@gmail.com 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
Hi,
Guido van Rossum guido at 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
On Wed, Apr 22, 2015 at 1:10 PM, Andrew Svetlov andrew.svet...@gmail.com
wrote:
On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby p...@telecommunity.com wrote:
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
It is an error to pass a regular context manager without
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
On 21.04.2015 18:08, Guido van Rossum wrote:
On Tue, Apr 21, 2015 at 12:33 AM, M.-A. Lemburg m...@egenix.com wrote:
On 21.04.2015 05:37, Guido van Rossum wrote:
On Mon, Apr 20, 2015 at 4:41 PM, Jack Diederich jackd...@gmail.com
wrote:
* Uploading stubs for other people's code is a terrible
On 21 April 2015 at 18:12, Steven D'Aprano st...@pearwood.info 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
On 21 April 2015 at 17:59, Guido van Rossum gu...@python.org 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
On 22 April 2015 at 11:46, M.-A. Lemburg m...@egenix.com 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),
55 matches
Mail list logo
