Re: [Python-Dev] PEP 492: async/await in Python; version 4

[Arnaud Delobelle]

On 3 May 2015 at 16:24, Steven D'Aprano  wrote:
> On Fri, May 01, 2015 at 09:24:47PM +0100, Arnaud Delobelle wrote:
>
>> I'm not convinced that allowing an object to be both a normal and an
>> async iterator is a good thing.  It could be a recipe for confusion.
>
> In what way?
>
> I'm thinking that the only confusion would be if you wrote "async for"
> instead of "for", or vice versa, and instead of getting an exception you
> got the (a)syncronous behaviour you didn't want.

Yes.  This is the same kind of confusion that this PEP is trying hard
to get rid of in other parts (i.e. the confusion between 'yield' and
'yield from' in current coroutines).

> But I have no intuition for how likely it is that you could write an
> asyncronous for loop, leave out the async, and still have the code do
> something meaningful.

Well if you've made you object both iterable and 'async iterable' then
it's very likely that you're going to get something meaningful out of
either kind of iteration.  Just not the way you want it if you
mistakenly left out (or added) the 'async' keyword in your loop.

> Other than that, I think it would be fine to have an object be both a
> syncronous and asyncronous iterator. You specify the behaviour you want
> by how you use it. We can already do that, e.g. unittest's assertRaises
> is both a test assertion and a context manager.

The latter is fine, because there is no danger of mistaking one for
the other, unlike iterators and 'async iterators'.

But my argument is simply that there is no good reason to aim for the
ability to have object conform to both protocols.  So it shouldn't be
a criterion when looking at the merits of a proposal.  I may very well
be wrong but I haven't yet seen a compelling case for an object
implementing both protocols.

Cheers,

-- 
Arnaud
___
Python-Dev mailing list
Python-Dev@python.org
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 492: async/await in Python; version 5

[Rajiv Kumar]

I wrote a little example[1] that has a bare-bones implementation of Go
style channels via a custom event loop. I used it to translate the prime
sieve example from Go[2] almost directly to Python. The code uses "message
= await channel.receive()" to mimic Go's "message <- channel". Instead of
using "go func()" to fire off a goroutine, I add the PEP492 coroutine to my
simple event loop.

It's not an efficient implementation - really just a proof of concept that
you can use async/await in your own code without any reference to asyncio.
I ended up writing it as I was thinking about how PEP 342 style coroutines
might look like in an async/await world.

In the course of writing this, I did find that it would be useful to have
the PEP document how event loops should advance the coroutines (via
.send(None) for example). It would also be helpful to have the semantics of
how await interacts with different kinds of awaitables documented. I had to
play with Yury's implementation to see what it does if the __await__ just
returns iter([1,2,3]) for example.

- Rajiv

[1] https://gist.github.com/vrajivk/c505310fb79d412afcd5#file-sieve-py
 https://gist.github.com/vrajivk/c505310fb79d412afcd5#file-channel-py

[2] https://golang.org/doc/play/sieve.go


On Tue, May 5, 2015 at 2:54 PM, Paul Moore  wrote:

> On 5 May 2015 at 22:38, Yury Selivanov  wrote:
> > n 2015-05-05 5:01 PM, Paul Moore wrote:
> >>
> >> On 5 May 2015 at 21:00, Yury Selivanov  wrote:
> >>>
> >>> On 2015-05-05 3:40 PM, Jim J. Jewett wrote:
> 
>  On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated
>  PEP492.
> 
>  Where are the following over-simplifications wrong?
> 
>  (1)  The PEP is intended for use (almost exclusively) with
>  asychronous IO and a scheduler such as the asynchio event loop.
> >>>
> >>> Yes. You can also use it for UI loops.  Basically, anything
> >>> that can call your code asynchronously.
> >>
> >> Given that the stdlib doesn't provide an example of such a UI loop,
> >> what would a 3rd party module need to implement to provide such a
> >> thing? Can any of the non-IO related parts of asyncio be reused for
> >> the purpose, or must the 3rd party module implement everything from
> >> scratch?
> >
> > The idea is that you integrate processing of UI events to
> > your event loop of choice.  For instance, Twisted has
> > integration for QT and other libraries [1].  This way you
> > can easily combine async network (or OS) calls with your
> > UI logic to avoid "callback hell".
>
> We seem to be talking at cross purposes. You say the PEP is *not*
> exclusively intended for use with asyncio. You mention UI loops, but
> when asked how to implement such a loop, you say that I integrate UI
> events into my event loop of choice. But what options do I have for
> "my event loop of choice"? Please provide a concrete example that
> isn't asyncio. Can I use PEP 492 with Twisted (I doubt it, as Twisted
> doesn't use yield from, which is Python 3.x only)? I contend that
> there *is* no concrete example that currently exists, so I'm asking
> what I'd need to do to write one. You pointed at qamash, but that
> seems to be subclassing asyncio, so isn't "something that isn't
> asyncio".
>
> Note that I don't have a problem with there being no existing
> implementation other than asyncio. I'd just like it if we could be
> clear over exactly what we mean when we say "the PEP is not tied to
> asyncio". It feels like the truth currently is "you can write your own
> async framework that uses the new features introduced by the PEP". I
> fully expect that *if* there's a need for async frameworks that aren't
> fundamentally IO multiplexors, then it'll get easier to write them
> over time (the main problem right now is a lack of good tutorial
> examples of how to do so). But at the moment, asyncio seems to be the
> only game in town (and I can imagine that it'll always be the main IO
> multiplexor, unless existing frameworks like Twisted choose to compete
> rather than integrate).
>
> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rajiv.kumar%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Minimal async event loop and async utilities (Was: PEP 492: async/await in Python; version 4)

[Paul Sokolovsky]

Hello,

On Wed, 6 May 2015 09:27:16 +0100
Paul Moore  wrote:

> On 6 May 2015 at 07:46, Greg Ewing 
> wrote:
> > Another problem with the "core" idea is that
> > you can't start with an event loop that "just does
> > scheduling" and then add on other features such
> > as I/O *from the outside*. There has to be some
> > point at which everything comes together, which
> > means choosing something like select() or
> > poll() or I/O completion queues, and build that
> > into the heart of your event loop. At that point
> > it's no longer something with a simple core.

[]

> So, to some extent (how far is something I'd need to code up a loop to
> confirm) you can build the Futures and synchronisation mechanisms with
> an event loop that supports only this "minimal interface".
> 
> Essentially, that's my goal - to allow people who want to write (say)
> a Windows GUI event loop, or a Windows event loop based of
> WaitForXXXObject, or a Tkinter loop, or whatever, to *not* have to
> write their own implementation of synchronisation or future objects.
> 
> That may mean lifting the asyncio code and putting it into a separate
> library, to make the separation between "asyncio-dependent" and
> "general async" clearer. Or if asyncio's provisional status doesn't
> last long enough to do that, we may end up with an asyncio
> implementation and a separate (possibly 3rd party) "general"
> implementation.

MicroPython has alternative implementation of asyncio subset. It's
structured as a generic scheduler component "uasyncio.core"
https://github.com/micropython/micropython-lib/blob/master/uasyncio.core/uasyncio/core.py
(170 total lines) and "uasyncio" which adds I/O scheduling on top of
it:
https://github.com/micropython/micropython-lib/blob/master/uasyncio/uasyncio/__init__.py

"uasyncio.core" can be used separately, and is intended for usage as
such on e.g. microcontrollers. It's built around native Python concept
of coroutines (plus callbacks). It doesn't include concept of futures.
They can be added as an extension built on top, but so far I didn't see
need for that, while having developed a web picoframework 
for uasyncio (https://github.com/pfalcon/picoweb)


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
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 492 quibble and request

[Arnaud Delobelle]

On 3 May 2015 at 02:22, Greg Ewing  wrote:
> Guido van Rossum wrote:
>>
>> On Sat, May 2, 2015 at 1:18 PM, Arnaud Delobelle > > wrote:
>>
>> Does this mean that
>> somehow "await x" guarantees that the coroutine will suspend at least
>> once?
>
>
> No. First, it's possible for x to finish without yielding.
> But even if x yields, there is no guarantee that the
> scheduler will run something else -- it might just
> resume the same task, even if there is another one that
> could run. It's up to the scheduler whether it
> implements any kind of "fair" scheduling policy.

That's what I understood but the example ('yielding()') provided by
Ron Adam seemed to imply otherwise, so I wanted to clarify.

-- 
Arnaud
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Ancient use of generators

[David Mertz]

I'm glad to see that everything old is new again.  All the stuff being
discussed nowadays, even up through PEP 492, was largely what I was trying
to show in 2002  the syntax just got nicer in the intervening 13 years
:-).

On Wed, May 6, 2015 at 10:57 AM, Guido van Rossum  wrote:

> For those interested in tracking the history of generators and coroutines
> in Python, I just found out that PEP 342
>  (which introduced
> send/throw/close and made "generators as coroutines" a mainstream Python
> concept) harks back to PEP 288 ,
> which was rejected. PEP 288 also proposed some changes to generators. The
> interesting bit though is in the references: there are two links to old
> articles by David Mertz that describe using generators in state machines
> and other interesting and unconventional applications of generators. All
> these well predated PEP 342, so yield was a statement and could not receive
> a value from the function calling next() -- communication was through a
> shared class instance.
>
> http://gnosis.cx/publish/programming/charming_python_b5.txt
> http://gnosis.cx/publish/programming/charming_python_b7.txt
>
> Enjoy!
>
> --
> --Guido van Rossum (python.org/~guido)
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list
Python-Dev@python.org
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 492: async/await in Python; version 5

[Ryan Hiebert]

This draft proposal for async generators in ECMAScript 7 may be interesting 
reading to those who haven’t already: https://github.com/jhusain/asyncgenerator 


This talk also has some good ideas about them, though the interesting stuff 
about using async generator syntax is all on the last slide, and not really 
explained: https://www.youtube.com/watch?v=gawmdhCNy-A 

> On May 5, 2015, at 3:55 PM, Guido van Rossum  wrote:
> 
> One small clarification:
> 
> On Tue, May 5, 2015 at 12:40 PM, Jim J. Jewett  > wrote:
> [...] but I don't understand how this limitation works with things like a
> per-line file iterator that might need to wait for the file to
> be initially opened.
> 
>  Note that PEP 492 makes it syntactically impossible to use a coroutine 
> function to implement an iterator using yield; this is because the generator 
> machinery is needed to implement the coroutine machinery. However, the PEP 
> allows the creation of asynchronous iterators using classes that implement 
> __aiter__ and __anext__. Any blocking you need to do can happen in either of 
> those. You just use `async for` to iterate over such an "asynchronous stream".
> 
> (There's an issue with actually implementing an asynchronous stream mapped to 
> a disk file, because I/O multiplexing primitives like select() don't actually 
> support waiting for disk files -- but this is an unrelated problem, and 
> asynchronous streams are useful to handle I/O to/from network connections, 
> subprocesses (pipes) or local RPC connections. Checkout the streams 
>  and subprocess 
>  submodules of the 
> asyncio package. These streams would be great candidates for adding 
> __aiter__/__anext__ to support async for-loops, so the idiom for iterating 
> over them can once again closely resemble the idiom for iterating over 
> regular (synchronous) streams using for-loops.)
> 
> -- 
> --Guido van Rossum (python.org/~guido )
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/ryan%40ryanhiebert.com

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 492 (async/await)

[Ludovic Gasc]

Thank you Yuri for the all process (PEP+code+handle debate).

It's the first time I follow the genesis of a PEP, from the idea to the
acceptation, it was very instructive to me.

--
Ludovic Gasc (GMLudo)
http://www.gmludo.eu/

2015-05-06 1:58 GMT+02:00 Guido van Rossum :

> I totally forgot to publicly congratulate Yury on this PEP. He's put a
> huge effort into writing the PEP and the implementation and managing the
> discussion, first on python-ideas, later on python-dev. Congrats, Yury! And
> thanks for your efforts. Godspeed.
>
> On Tue, May 5, 2015 at 4:53 PM, Guido van Rossum  wrote:
>
>> Everybody,
>>
>> In order to save myself a major headache I'm hereby accepting PEP 492.
>>
>> I've been following Yury's efforts carefully and I am fully confident
>> that we're doing the right thing here. There is only so much effort we can
>> put into clarifying terminology and explaining coroutines. Somebody should
>> write a tutorial. (I started to write one, but I ran out of time after just
>> describing basic yield.)
>>
>> I've given Yury clear instructions to focus on how to proceed -- he's to
>> work with another core dev on getting the implementation ready in time for
>> beta 1 (scheduled for May 24, but I think the target date should be May 19).
>>
>> The acceptance is provisional in the PEP 411 sense (stretching its
>> meaning to apply to language changes). That is, we reserve the right to
>> change the specification (or even withdraw it, in a worst-case scenario)
>> until 3.6, although I expect we won't need to do this except for some
>> peripheral issues (e.g. the backward compatibility flags).
>>
>> I now plan to go back to PEP 484 (type hints). Fortunately in that case
>> there's not much *implementation* that will land (just the typing.py
>> module), but there's still a lot of language in the PEP that needs updating
>> (check the PEP 484 tracker ).
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/gmludo%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
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 492 quibble and request

[Ron Adam]

On 05/03/2015 03:03 PM, Arnaud Delobelle wrote:

On 3 May 2015 at 02:22, Greg Ewing  wrote:

>Guido van Rossum wrote:

>>
>>On Sat, May 2, 2015 at 1:18 PM, Arnaud Delobelle >> wrote:
>>
>> Does this mean that
>> somehow "await x" guarantees that the coroutine will suspend at least
>> once?

>
>
>No. First, it's possible for x to finish without yielding.
>But even if x yields, there is no guarantee that the
>scheduler will run something else -- it might just
>resume the same task, even if there is another one that
>could run. It's up to the scheduler whether it
>implements any kind of "fair" scheduling policy.

That's what I understood but the example ('yielding()') provided by
Ron Adam seemed to imply otherwise, so I wanted to clarify.



Guido is correct of course.  In examples I've used before with trampolines, 
a co-routine would be yielded back to the event loop, and if there was any 
other co-routines in the event loop they would execute first.  I'm not sure 
if async and await can be used with a trampoline type scheduler.


A scheduler might use a timer or priority based system system to schedule 
events.  So yes, it's up to the scheduler and the pep492 is intended to be 
flexible as to what scheduler is used.


Cheers,
   Ron








___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's missing in PEP-484 (Type hints)

[Dima Tisnek]

On 30 April 2015 at 14:33, Steven D'Aprano  wrote:
> On Thu, Apr 30, 2015 at 01:41:53PM +0200, Dima Tisnek wrote:
>
>> # Syntactic sugar
>> "Beautiful is better than ugly, " thus nice syntax is needed.
>> Current syntax is very mechanical.
>> Syntactic sugar is needed on top of current PEP.
>
> I think the annotation syntax is beautiful. It reminds me of Pascal.

Haha, good one!

>
>
>> # internal vs external
>> @intify
>> def foo() -> int:
>> b = "42"
>> return b  # check 1
>> x = foo() // 2  # check 2
>>
>> Does the return type apply to implementation (str) or decorated callable 
>> (int)?
>
> I would expect that a static type checker would look at foo, and flag
> this as an error. The annotation says that foo returns an int, but it
> clearly returns a string. That's an obvious error.

Is this per PEP, or just a guess?

I think PEP needs to be explicit about this.

[snipped]
>
> lambda arg: arg + 1
>
> Obviously arg must be a Number, since it has to support addition with
> ints.

Well, no, it can be any custom type that implements __add__
Anyhow, the question was about non-trivial lambdas.

>> # local variables
>> Not mentioned in the PEP
>> Non-trivial code could really use these.
>
> Normally local variables will have their type inferred from the
> operations done to them:
>
> s = arg[1:]  # s has the same type as arg

Good point, should be mentioned in PEP.

Technically, type can be empty list, mixed list or custom return type
for overloaded __getitem__ that accepts slices.

>> # comprehensions
>> [3 * x.data for x in foo if "bar" in x.type]
>> Arguable, perhaps annotation is only needed on `foo` here, but then
>> how complex comprehensions, e.g. below, the intermediate comprehension
>> could use an annotation
>> [xx for y in [...] if ...]
>
> A list comprehension is obviously of type List. If you need to give a
> more specific hint:
>
> result = [expr for x in things if cond(x)]  #type: List[Whatever]
>
> See also the discussion of "cast" in the PEP.
>
> https://www.python.org/dev/peps/pep-0484/#id25

Good point for overall comprehension type.
re: cast, personally I have some reservations against placing `cast()`
into runtime path.

I'm sorry if I was not clear. My question was how should type of
ephemeral `x` be specified.
In other words, can types be specified on anything inside a comprehension?

>> # class attributes
>> s = socket.socket(...)
>> s.type, s.family, s.proto  # int
>> s.fileno  # callable
>> If annotations are only available for methods, it will lead to
>> Java-style explicit getters and setters.
>> Python language and data model prefers properties instead, thus
>> annotations are needed on attributes.
>
> class Thing:
> a = 42  # can be inferred
> b = []  # inferred as List[Any]
> c = []  #type: List[float]

Good point, I suppose comments + stub file may be sufficient.

Stub is better (required?) because it allows to specify types of
attributes that are not assigned in class scope, but that are expected
to be there as result of __init__ or because it's a C extension.

An example in PEP would be good.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's missing in PEP-484 (Type hints)

[Dima Tisnek]

>> # plain data
>> user1 = dict(id=123,  # always int
>> name="uuu",  # always str
>> ...)  # other fields possible
>> smth = [42, "xx", ...]
>> (why not namedtuple? b/c extensible, mutable)
>> At least one PHP IDE allows to annotate PDO.
>> Perhaps it's just bad taste in Python? Or is there a valid use-case?
>
> Most (all?) of this is actually mentioned in the PEP:
> https://www.python.org/dev/peps/pep-0484/#type-comments

The question was about mixed containers, e.g.:
x = [12, "Jane"]
y = [13, "John", 99.9]

There first element is always int, second always str, and rest is variable.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's missing in PEP-484 (Type hints)

[Guido van Rossum]

On Thu, May 7, 2015 at 7:25 AM, Dima Tisnek  wrote:

> On 30 April 2015 at 14:33, Steven D'Aprano  wrote:
> > On Thu, Apr 30, 2015 at 01:41:53PM +0200, Dima Tisnek wrote:
> >> # internal vs external
> >> @intify
> >> def foo() -> int:
> >> b = "42"
> >> return b  # check 1
> >> x = foo() // 2  # check 2
> >>
> >> Does the return type apply to implementation (str) or decorated
> callable (int)?
> >
> > I would expect that a static type checker would look at foo, and flag
> > this as an error. The annotation says that foo returns an int, but it
> > clearly returns a string. That's an obvious error.
>
> Is this per PEP, or just a guess?
>
> I think PEP needs to be explicit about this.
>

The PEP shouldn't have to explain all the rules for type inferencing.
There's a section "What is checked?" that says (amongst other things):

  The body of a checked function is checked for consistency with the
  given annotations.  The annotations are also used to check correctness
  of calls appearing in other checked functions.

> Normally local variables will have their type inferred from the
> > operations done to them:
> >
> > s = arg[1:]  # s has the same type as arg
>
> Good point, should be mentioned in PEP.
>

Again, what do you want the PEP to say? I am trying to keep the PEP shorter
than the actual code that implements the type checker. :-)


> Technically, type can be empty list, mixed list or custom return type
> for overloaded __getitem__ that accepts slices.
>
> I'm sorry if I was not clear. My question was how should type of
> ephemeral `x` be specified.
> In other words, can types be specified on anything inside a comprehension?
>

That's actually a good question; the PEP shows some examples of #type:
comments in peculiar places, but there's no example using list
comprehensions. Your best bet is to leave it to the type inferencer; if
your comprehension is so complex that need to put type annotations on parts
of it, you may be better off rewriting it as a regular for-loop, which
offers more options for annotations.


> Stub is better (required?) because it allows to specify types of
> attributes that are not assigned in class scope, but that are expected
> to be there as result of __init__ or because it's a C extension.
>

Note that the PEP does not explicitly say whether the information of a stub
might be *merged* with the information gleaned from the source code. The
basic model is that if a stub is present the implementation source code is
not read at all by the type checker (and, conversely, information from
stubs is not available at all at runtime). But it is possible for some type
checker to improve upon this model.


> An example in PEP would be good.
>

Can you give an example that I can edit and put in the PEP?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
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 492: async/await in Python; version 5

[Guido van Rossum]

On Tue, May 5, 2015 at 3:36 PM, Rajiv Kumar  wrote:

> I wrote a little example[1] that has a bare-bones implementation of Go
> style channels via a custom event loop. I used it to translate the prime
> sieve example from Go[2] almost directly to Python. The code uses "message
> = await channel.receive()" to mimic Go's "message <- channel". Instead of
> using "go func()" to fire off a goroutine, I add the PEP492 coroutine to my
> simple event loop.
>

Cool example!

It's not an efficient implementation - really just a proof of concept that
> you can use async/await in your own code without any reference to asyncio.
> I ended up writing it as I was thinking about how PEP 342 style coroutines
> might look like in an async/await world.
>
> In the course of writing this, I did find that it would be useful to have
> the PEP document how event loops should advance the coroutines (via
> .send(None) for example). It would also be helpful to have the semantics of
> how await interacts with different kinds of awaitables documented. I had to
> play with Yury's implementation to see what it does if the __await__ just
> returns iter([1,2,3]) for example.
>

I've found this too. :-) Yury, perhaps you could show a brief example in
the PEP of how to "drive" a coroutine from e.g. main()?


> - Rajiv
>
> [1] https://gist.github.com/vrajivk/c505310fb79d412afcd5#file-sieve-py
>  https://gist.github.com/vrajivk/c505310fb79d412afcd5#file-channel-py
>
> [2] https://golang.org/doc/play/sieve.go
>

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
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 492: async/await in Python; version 5

[Yury Selivanov]

On 2015-05-07 1:42 PM, Guido van Rossum wrote:

On Tue, May 5, 2015 at 3:36 PM, Rajiv Kumar  wrote:


I wrote a little example[1] that has a bare-bones implementation of Go
style channels via a custom event loop. I used it to translate the prime
sieve example from Go[2] almost directly to Python. The code uses "message
= await channel.receive()" to mimic Go's "message <- channel". Instead of
using "go func()" to fire off a goroutine, I add the PEP492 coroutine to my
simple event loop.


Cool example!

It's not an efficient implementation - really just a proof of concept that

you can use async/await in your own code without any reference to asyncio.
I ended up writing it as I was thinking about how PEP 342 style coroutines
might look like in an async/await world.

In the course of writing this, I did find that it would be useful to have
the PEP document how event loops should advance the coroutines (via
.send(None) for example). It would also be helpful to have the semantics of
how await interacts with different kinds of awaitables documented. I had to
play with Yury's implementation to see what it does if the __await__ just
returns iter([1,2,3]) for example.


I've found this too. :-) Yury, perhaps you could show a brief example in
the PEP of how to "drive" a coroutine from e.g. main()?


OK, will do!

Thanks,
Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unicode literals in Python 2.7

[Martin v. Löwis]

Am 02.05.15 um 21:57 schrieb Adam Bartoš:
> Even if sys.stdin contained a file-like object with proper encoding
> attribute, it wouldn't work since sys.stdin has to be instance of  'file'>. So the question is, whether it is possible to make a file instance
> in Python that is also customizable so it may call my code. For the first
> thing, how to change the value of encoding attribute of a file object.

If, by "in Python", you mean both "in pure Python", and "in Python 2",
then the answer is no. If you can add arbitrary C code, then you might
be able to hack your C library's stdio implementation to delegate fread
calls to your code.

I recommend to use Python 3 instead.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com