Re: [Python-Dev] async/await in Python; v2

[Greg Ewing]

Yury Selivanov wrote:

- If it's an object with __await__, return iter(object.__await__())


Is the iter() really needed? Couldn't the contract of
__await__ be that it always returns an iterator?

--
Greg
___
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

[Python-Dev] Questionable TCP server example

[Andrea Griffini]

It's not the first time someone is confused by the server example of

https://docs.python.org/3/library/socketserver.html

where the receiving side is not making a loop over recv.

Moreover the documentation contains a misleading description of what really
happens:

"The difference is that the readline() call in the second handler will call
recv() multiple times until it encounters a newline character, while the
single recv() call in the first handler will just return what has been sent
from the client in one sendall() call."

Unless I'm missing something there's no way to know client side when all
data sent by "sendall" has been received (TCP stream protocol doesn't have
message boundaries) and the `recv` based code doesn't handle neither
fragmentation nor clients that send more than 1024 bytes.

Am I missing something or that is indeed an example of how NOT to write a
socket-based server?

Andrea
___
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] Type hints -- a mediocre programmer's reaction

[Terry Reedy]

On 4/22/2015 8:45 PM, Guido van Rossum wrote:

On Wed, Apr 22, 2015 at 2:38 PM, Chris Barker mailto:chris.bar...@noaa.gov>> wrote:



On Tue, Apr 21, 2015 at 11:32 PM, Terry Reedy mailto:tjre...@udel.edu>> wrote:

I was just thinking today that for this, typing needs a
subtraction (difference) operation in addition to an addition
(union) operation: Difference(Iterable(str), str)



Anyway, the point is that being able to say "all these types, except
this one" would solve this particular problem -- but would it solve
any others? Do we want this to work around a quirk in Pythons string
type?



More seriously, I doubt there are other important use cases for Difference.


I thought about Difference(numbers.Number, complex) to get ordered 
numbers, but numbers.Real should probably work.  I agree more real uses 
are needed before adding Difference.


--
Terry Jan Reedy

___
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] async/await in Python; v2

[Wolfgang Langner]

Hi,

most of the time I am a silent reader but in this discussion I must step in.
I use twisted and async stuff a lot over years followed development of
asyncio closely.

First it is good to do differentiate async coroutines from generators. So
everyone can see it and have this in mind
and don't mix up booth. It is also easier to explain for new users.
Sometimes generators blows their mind and it takes
a while to get used to them. Async stuff is even harder.

1. I am fine with using something special instead of "yield" or "yield
from" for this. C# "await" is ok.

Everything else suggested complicates the language and makes it harder to
read.

2.
async def f(): is harder to read and something special also it breaks the
symmetry in front (def indent).
Also every existing tooling must be changed to support it. Same for def
async, def f() async:
I thing a decorator is enough here
@coroutine
def f():
is the best solution to mark something as a coroutine.


3.
async with and async for
Bead idea, we clutter the language even more and it is one more thing every
newbie could do wrong.
for x in y:
  result = await f()
is enough, every 'async' framework lived without it over years.
Same for with statement.

The main use case suggested was for database stuff and this is also where
most are best with
defer something to a thread and keep it none async.


All together it is very late in the development cycle for 3.5 to
incorporate such a big change.
Best is to give all this some more time and defer it to 3.6 and some alpha
releases to experiment with.

Regards,

Wolfgang



On Tue, Apr 21, 2015 at 7:26 PM, Yury Selivanov 
wrote:

> Hi python-dev,
>
> I'm moving the discussion from python-ideas to here.
>
> The updated version of the PEP should be available shortly
> at https://www.python.org/dev/peps/pep-0492
> and is also pasted in this email.
>
> Updates:
>
> 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();
>
> 5. New section highlighting differences from
>PEP 3152.
>
> 6. New AST node - AsyncFunctionDef; the proposal
>now is 100% backwards compatible;
>
> 7. A new section clarifying that coroutine-generators
>are not part of the current proposal;
>
> 8. Various small edits/typos fixes.
>
>
> There's is a bug tracker issue to track code review
> of the reference implementation (Victor Stinner is
> doing the review): http://bugs.python.org/issue24017
> While the PEP isn't accepted, we want to make sure
> that the reference implementation is ready when such
> a decision will be made.
>
>
> Let's discuss some open questions:
>
> 1. Victor raised a question if we should locate
>coroutine() function from 'types' module to
>'functools'.
>
>My opinion is that 'types' module is a better
>place for 'corotine()', since it adjusts the
>type of the passed generator.  'functools' is
>about 'partials', 'lru_cache' and 'wraps' kind
>of things.
>
> 2. I propose to disallow using of 'for..in' loops,
>and builtins like 'list()', 'iter()', 'next()',
>'tuple()' etc on coroutines.
>
>It's possible by modifying PyObject_GetIter to
>raise an exception if it receives a coroutine-object.
>
>'yield from' can also be modified to only accept
>coroutine objects if it is called from a generator
>with CO_COROUTINE flag.
>
>This will further separate coroutines from
>generators, making it harder to screw something
>up by an accident.
>
>I have a branch of reference implementation
>https://github.com/1st1/cpython/tree/await_noiter
>where this is implemented.  I did not observe
>any performance drop.
>
>There is just one possible backwards compatibility
>issue here: there will be an exception if  some user
>of asyncio actually used to iterate over generators
>decorated with @coroutine.  But I can't imagine
>why would someone do that, and even if they did --
>it's probably a bug or wrong usage of asyncio.
>
>
> That's it!  I'd be happy to hear some feedback!
>
> Thanks,
> Yury
>
>
>
> PEP: 492
> Title: Coroutines with async and await syntax
> Version: $Revision$
> Last-Modified: $Date$
> Author: Yury Selivanov 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 09-Apr-2015
> Python-Version: 3.5
> Post-History: 17-Apr-2015, 21-Apr-2015
>
>
> Abstract
> 
>
> This PEP introduces new syntax for coroutines, asynchronous ``with``
> statements and ``for`` loops.  The main motivation behind this proposal
> is to streamline writing and maintaining asynchronous code, as well as
> to simplify previously hard to implement code patterns.
>
>
> Rationale and Goals
> ===
>
> Current Python supports implementing coroutines via generators (PEP
> 342), further enhanced by the ``yield from`` syntax introduced in PEP
> 380. Th

Re: [Python-Dev] async/await in Python; v2

[Greg Ewing]

Victor Stinner wrote:

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 3152? Do you need to call an artifical
method like "cocall fut.return_self()" where the return_self() method simply
returns fut?


In a PEP 3152 world, Future objects and the like would be
expected to implement __cocall__, just as in a PEP 492 world
they would be expected to implement __await__.


@asyncio.coroutine currently calls a function and *then* check if it should
yields from it or not:

res = func(*args, **kw)
if isinstance(res, futures.Future) or inspect.isgenerator(res):
res = yield from res


To accommodate the possibility of func being a cofunction,
you would need to add something like

   if is_cofunction(func):
  res = yield from costart(func, *args, **kw)
   else:
  # as above

--
Greg
___
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] async/await in Python; v2

[Greg Ewing]

Victor Stinner wrote:


Using a custom name like "cofunction" may confuse users coming from other
programming languages. I prefer to keep "coroutine", but I agree that we
should make some effort to define the different categories of "Python
coroutines".


I should perhaps point out that "cofunction" is not
just an arbitrary word I made up to replace "coroutine".
It is literally a kind of function, and is meant to
be thought of that way.

As for confusing new users, I would think that, as
an unfamiliar word, it would point out that there is
something they need to look up and learn about.
Whereas they may think they already know what a
"coroutine" is and not bother to look further.

--
Greg
___
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] async/await in Python; v2

[Greg Ewing]

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.


This is certainly possible with PEP 3152. The decorator
just needs to be an ordinary function whose return
value is a cofunction.

--
Greg
___
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] async/await in Python; v2

[Greg Ewing]

Paul Sokolovsky wrote:

And having both asymmetric and symmetric
would quite confusing, especially that symmetric are more powerful and
asymmetric can be easily implemented in terms of symmetric using
continuation-passing style.


You can also use a trampoline of some kind to
relay values back and forth between generators,
to get something symmetric.

--
Greg
___
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] Type hints -- a mediocre programmer's reaction

[Wolfgang Langner]

Hi,

having a lot experience with Python beginners and people programming
Java/Python I have also an opinion about this. ;-)

First reaction was, oh good. Then I read every thread and comment about it,
looked at a lot internal code give all some time
and the result is:

I found a lot of code written like Java with assert and isinstance for type
checks. Not very Pythonic but someone from Java thinks this is good.
Because Python has no type checks. A lot of people think types help in the
IDE and for tools to do automatic checks, find some errors earlier.

My conclusion:

1. typing.py is good to make a standard how to specify type hints. Can also
be used by tools and IDE's

2. Using it in the language as part of the function signature, my first
thought was oh good, then I changed my mind
   to: oh it can be very ugly and unreadable, it is the wrong place.
   Now I am against it, best is, if I have to specify type signatures, do
it in one place, keep them up to date.
   Most of the time this is the documentation. Why not use the docstring
with a standard type specifier for this.
   Suggested here:
http://pydev.blogspot.de/2015/04/type-hinting-on-python.html

3. Stub files are good if someone needs this feature, it is complete
separate and if someone don't want to write them
it is no problem. But it is good to have a way to name them and a place
to find them and know this.

IDE's parse the docstring already, it is optional to have one and every
Editor has folding support to disable it if it is to much
of information. Checkers like mypy can use the type info from there to do
checks. If there is a standard way to specify types in docstrings.
It is also possible to specify a type hint for a variable, this is good for
documentations and can also be used for type checks.

For stub files the same can be used. So no different syntax. Also If
someone wants it and a module has no documentation it can be added from
there.

For nearly every function I have written, there is a docstring and most of
the time also a type specified.
But if I must provide all this in a second place it is not the right way to
go. Over time normally one place misses some changes and is wrong.

I am convinced something like:

def myfunction(a, b):
  """
  My special function.

  :param a: ...
  :type a: int
  :param b: second value
  :type b: int
  :rtype: None
  """

or shorter form also possible in Sphinx if only one type for parameter is
specified:

def myfunction(a, b):
  """
  My special function.

  :param int a: ...
  :param int b: second value
  :rtype: None
  """

Is easier to maintain good to read, changes not the world how to write
Python functions and is useful for IDE's and checkers.
And the best, most editors and IDE's support folding of docstrings and if
someone don't want to see them it can be done now.
The docstring is a good place for type specification, because as stated
Python never will do type checks on execution. So no need
to make it part of the language syntax.

All this can also be applied over time to the standard library. If it makes
sense so specify a type it is good to have it in the documentation.
And sphinx is the standard documentation tool for Python now.

Also ask why no one used type specifier, they are possible since Python 3.0
?
Because it is the wrong way for Python.


Regards,

Wolfgang
___
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] async/await in Python; v2

[Antoine Pitrou]

Hi,

I agree with most of Wolfgang's points below. As a data point, I
haven't used asyncio for anything real (despite having approved the
PEP!), but I have some extensive prior experience with Twisted and
Tornado :-)

Regards

Antoine.


On Thu, 23 Apr 2015 09:30:30 +0200
Wolfgang Langner  wrote:
> Hi,
> 
> most of the time I am a silent reader but in this discussion I must step in.
> I use twisted and async stuff a lot over years followed development of
> asyncio closely.
> 
> First it is good to do differentiate async coroutines from generators. So
> everyone can see it and have this in mind
> and don't mix up booth. It is also easier to explain for new users.
> Sometimes generators blows their mind and it takes
> a while to get used to them. Async stuff is even harder.
> 
> 1. I am fine with using something special instead of "yield" or "yield
> from" for this. C# "await" is ok.
> 
> Everything else suggested complicates the language and makes it harder to
> read.
> 
> 2.
> async def f(): is harder to read and something special also it breaks the
> symmetry in front (def indent).
> Also every existing tooling must be changed to support it. Same for def
> async, def f() async:
> I thing a decorator is enough here
> @coroutine
> def f():
> is the best solution to mark something as a coroutine.
> 
> 
> 3.
> async with and async for
> Bead idea, we clutter the language even more and it is one more thing every
> newbie could do wrong.
> for x in y:
>   result = await f()
> is enough, every 'async' framework lived without it over years.
> Same for with statement.
> 
> The main use case suggested was for database stuff and this is also where
> most are best with
> defer something to a thread and keep it none async.
> 
> 
> All together it is very late in the development cycle for 3.5 to
> incorporate such a big change.
> Best is to give all this some more time and defer it to 3.6 and some alpha
> releases to experiment with.
> 
> Regards,
> 
> Wolfgang


___
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] Questionable TCP server example

[Antoine Pitrou]

On Thu, 23 Apr 2015 09:21:11 +0200
Andrea Griffini  wrote:
> It's not the first time someone is confused by the server example of
> 
> https://docs.python.org/3/library/socketserver.html
> 
> where the receiving side is not making a loop over recv.

This is a trivial example indeed. If you think something more realistic
yet simple is desirable, we welcome contributions :-) You can take a
look at https://docs.python.org/devguide/ to get started.

> Moreover the documentation contains a misleading description of what really
> happens:
> 
> "The difference is that the readline() call in the second handler will call
> recv() multiple times until it encounters a newline character, while the
> single recv() call in the first handler will just return what has been sent
> from the client in one sendall() call."
> 
> Unless I'm missing something there's no way to know client side when all
> data sent by "sendall" has been received (TCP stream protocol doesn't have
> message boundaries) and the `recv` based code doesn't handle neither
> fragmentation nor clients that send more than 1024 bytes.

Indeed, the quoted paragraph is wrong.

> Am I missing something or that is indeed an example of how NOT to write a
> socket-based server?

The problem is coming up with an example that reflects better practices
while being simple enough :-)

Regards

Antoine.


___
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] async/await in Python; v2

[Greg Ewing]

Yury Selivanov wrote:


So how would we do "await fut" if await requires parentheses?


I've answered this with respect to PEP 3152 -- futures would
implement __cocall__, so you would write 'cocall fut()'.

I'm not sure what to say about PEP 492 here, because it
depends on exactly what a version of await that "requires
parentheses" would mean. It's not clear to me what you
have in mind for that from what you've said so far.

I'm not really in favour of just tweaking the existing PEP
492 notion of await so that it superficially resembles a
PEP 3152 cocall. That misses the point, which is that a
cocall is a special kind of function call, not a special
kind of yield-from.

--
Greg
___
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] async/await in Python; v2

[Andrew Svetlov]

On Thu, Apr 23, 2015 at 10:30 AM, Wolfgang Langner
 wrote:
> Hi,
>
> most of the time I am a silent reader but in this discussion I must step in.
> I use twisted and async stuff a lot over years followed development of
> asyncio closely.
>
> First it is good to do differentiate async coroutines from generators. So
> everyone can see it and have this in mind
> and don't mix up booth. It is also easier to explain for new users.
> Sometimes generators blows their mind and it takes
> a while to get used to them. Async stuff is even harder.
>
> 1. I am fine with using something special instead of "yield" or "yield from"
> for this. C# "await" is ok.
>
> Everything else suggested complicates the language and makes it harder to
> read.
>
> 2.
> async def f(): is harder to read and something special also it breaks the
> symmetry in front (def indent).
> Also every existing tooling must be changed to support it. Same for def
> async, def f() async:
> I thing a decorator is enough here
> @coroutine
> def f():
> is the best solution to mark something as a coroutine.
>
Sorry, `@coroutine` decorator is part of Python semantics, not Python
syntax. That means Python compiler cannot relay on @coroutine in
parsing.
`away`, `async for` and `async with` are available only inside `async
def`, not inside regular `def`.
>
> 3.
> async with and async for
> Bead idea, we clutter the language even more and it is one more thing every
> newbie could do wrong.
> for x in y:
>   result = await f()
> is enough, every 'async' framework lived without it over years.

async for i in iterable:
pass

is not equal for

for fut in iterable:
i = yield from fut

async for is also suitable when size of iterable sequence is unknown
on iteration start.

Let's look, for example, on Redis SCAN command
(http://redis.io/commands/scan) for iterating over redis keys.
It returns bulk of keys and opaque value for next SCAN call.

In current Python it must be written as

cur = 0
while True:
bulk, cur = yield from redis.scan(cur)
for key in bulk:
process_key(key)
if cur == 0:
break

With new syntax iteration looks much more native:

async for key in redis.scan(cur):
process_key(key)

> Same for with statement.
>
> The main use case suggested was for database stuff and this is also where
> most are best with
> defer something to a thread and keep it none async.
>
`async with` is not only for transactions in relation databases.
As well as plain `with` is used not only for databases but for many
other things -- from files to decimal contexts.

As realistic example not related to databases please recall RabbitMQ.
Every message processing may be acknowledged. The native API for that
may be

while True:
async with channel.consume("my queue") as msg:
process_msg(msg)

with acknowledgement on successful message processing only.
Acknowledgement requires network communication and must be
asynchronous operation.

>
> All together it is very late in the development cycle for 3.5 to incorporate
> such a big change.
> Best is to give all this some more time and defer it to 3.6 and some alpha
> releases to experiment with.
>
> Regards,
>
> Wolfgang
>
>
>
> On Tue, Apr 21, 2015 at 7:26 PM, Yury Selivanov 
> wrote:
>>
>> Hi python-dev,
>>
>> I'm moving the discussion from python-ideas to here.
>>
>> The updated version of the PEP should be available shortly
>> at https://www.python.org/dev/peps/pep-0492
>> and is also pasted in this email.
>>
>> Updates:
>>
>> 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();
>>
>> 5. New section highlighting differences from
>>PEP 3152.
>>
>> 6. New AST node - AsyncFunctionDef; the proposal
>>now is 100% backwards compatible;
>>
>> 7. A new section clarifying that coroutine-generators
>>are not part of the current proposal;
>>
>> 8. Various small edits/typos fixes.
>>
>>
>> There's is a bug tracker issue to track code review
>> of the reference implementation (Victor Stinner is
>> doing the review): http://bugs.python.org/issue24017
>> While the PEP isn't accepted, we want to make sure
>> that the reference implementation is ready when such
>> a decision will be made.
>>
>>
>> Let's discuss some open questions:
>>
>> 1. Victor raised a question if we should locate
>>coroutine() function from 'types' module to
>>'functools'.
>>
>>My opinion is that 'types' module is a better
>>place for 'corotine()', since it adjusts the
>>type of the passed generator.  'functools' is
>>about 'partials', 'lru_cache' and 'wraps' kind
>>of things.
>>
>> 2. I propose to disallow using of 'for..in' loops,
>>and builtins like 'list()', 'iter()', 'next()',
>>'tuple()' etc on coroutines.
>>
>>It's possible by modifying PyObject_GetIter to
>>raise an exception if it receives 

Re: [Python-Dev] async/await in Python; v2

[Greg Ewing]

Yury Selivanov wrote:
I think that the problem of forgetting 'yield from' is a bit 
exaggerated. Yes, I myself forgot 'yield from' once or twice. But that's 
it, it has never happened since.


I think it's more likely to happen when you start with
an ordinary function, then discover that it needs to
be suspendable, so you need to track down all the
places that call it, and all the places that call
those, etc. PEP 3152 ensures that you get clear
diagnostics if you miss any.

--
Greg
___
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] async/await in Python; v2

[Andrew Svetlov]

Greg, how waiting for multiple cocalls should look and work?

In asyncio when I need to wait for two and more coroutines/futures I
use `asyncio.gather()`:

yield from gather(coro1(a1, a2), coro2(), fut3)

>From my understanding to use cofunctions I must wrap it with costart call:

yield from gather(costart(coro1, a1, a2), costart(coro2), fut3)

That looks weird.

There are other places in asyncio API those accept coroutines or
futures as parameters, not only Task() and async().

On Thu, Apr 23, 2015 at 12:25 PM, Greg Ewing
 wrote:
> Yury Selivanov wrote:
>>
>> I think that the problem of forgetting 'yield from' is a bit exaggerated.
>> Yes, I myself forgot 'yield from' once or twice. But that's it, it has never
>> happened since.
>
>
> I think it's more likely to happen when you start with
> an ordinary function, then discover that it needs to
> be suspendable, so you need to track down all the
> places that call it, and all the places that call
> those, etc. PEP 3152 ensures that you get clear
> diagnostics if you miss any.
>
> --
> Greg
>
> ___
> 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/andrew.svetlov%40gmail.com



-- 
Thanks,
Andrew Svetlov
___
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] async/await in Python; v2

[Greg Ewing]

Yury Selivanov wrote:


So you would have to write 'await fut()'?  This is non-intuitive.


That's because PEP 492 and its terminology encourage you
to think of 'await f()' as a two-step process: evaluate f(),
and then wait for the thing it returns to produce a
result.

PEP 3152 has a different philosophy. There, 'cocall f()'
is a one-step process: call f and get back a result (while
being prepared to get suspended in the meantime).

The two-step approach has the advantage that you can
get hold of the intermediate object and manipulate it.
But I don't see much utility in being able to do that.

Keep in mind that you can treat cofunctions themselves
as objects to be manipulated, just like you can with
ordinary functions, and all the usual techniques such
as closures, * and ** parameters, etc. are available
if you want to encapsulate one with some arguments.

About the only thing you gain from being able to pass
generator-iterators around instead of the functions that
produce them is that you get to write

   t = Task(func(args))

instead of

   t = Task(func, args)

which seems like a very minor thing to me. I would even
argue that the latter is clearer, because it makes it
very obvious that the body of func is *not* executed
before the Task is constructed. The former makes it
look as though the *result* of executing func with
args is being passed to Task, rather than func itself.

--
Greg
___
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] async/await in Python; v2

[Greg Ewing]

Andrew Svetlov wrote:

From my understanding to use cofunctions I must wrap it with costart call:

yield from gather(costart(coro1, a1, a2), costart(coro2), fut3)

There are other places in asyncio API those accept coroutines or
futures as parameters, not only Task() and async().


In a PEP 3152 aware version of asyncio, they would all
know about cofunctions and what to do with them.

--
Greg
___
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] async/await in Python; v2

[Greg Ewing]

Paul Sokolovsky wrote:

Greg Ewing  wrote:


You can also use a trampoline of some kind to
relay values back and forth between generators,
to get something symmetric.


Yes, that's of course how coroutine frameworks were done long before
"yield from" appeared and how Trollius works now.


No, what I mean is that if you want to send stuff
back and forth between two particular coroutines in
a symmetric way, you can write a specialised
scheduler that just handles those coroutines.

If you want to do that at the same time that other
things are going on, I think you're better off
not trying to do it using yield. Use a general
scheduler such as asyncio, and some traditional
IPC mechanism such as a queue for communication.

--
Greg
___
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] async/await in Python; v2

[Andrew Svetlov]

On Thu, Apr 23, 2015 at 3:10 PM, Greg Ewing  wrote:
> Andrew Svetlov wrote:
>>
>> From my understanding to use cofunctions I must wrap it with costart call:
>>
>> yield from gather(costart(coro1, a1, a2), costart(coro2), fut3)
>>
>> There are other places in asyncio API those accept coroutines or
>> futures as parameters, not only Task() and async().
>
>
> In a PEP 3152 aware version of asyncio, they would all
> know about cofunctions and what to do with them.
>
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.

Maybe your proposal is better than current asyncio practice.
But now asyncio is built on top of two-step process, as you have
mentioned: building coroutine and waiting for it's result.

That's why I prefer `await` as replace for well-known `yield from`.


>
> --
> Greg
> ___
> 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/andrew.svetlov%40gmail.com



-- 
Thanks,
Andrew Svetlov
___
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] async/await in Python; v2

[Wolfgang Langner]

On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky  wrote:

> Hello,
>
> On Thu, 23 Apr 2015 12:18:51 +0300
> Andrew Svetlov  wrote:
>
> []
>
> > > 3.
> > > async with and async for
> > > Bead idea, we clutter the language even more and it is one more
> > > thing every newbie could do wrong.
> > > for x in y:
> > >   result = await f()
> > > is enough, every 'async' framework lived without it over years.
> >
> > async for i in iterable:
> > pass
> >
> > is not equal for
> >
> > for fut in iterable:
> > i = yield from fut
>
> But people who used Twisted all their life don't know that! They just
> know that "async for" is not needed and bad.
>
>
I don't think it is bad nor not needed, but the syntax is not beautiful and
for the 90% not doing async stuff irritating and one more thing to learn
and do right/wrong.

I had also a need for async loop. But there are other solutions like
channels,
not needing a new syntax.

Also possible a function returning futures and yield in the loop with a
sentinel.

All this goes the road down to a producer consumer pattern. Nothing more.



> I know I'm a bad guy to make such comments, too bad there's a bit of
> truth in them, or everyone would just call me an a%$&ole right away.
>
>
> Generally, I already provided feedback (on asyncio list) that asyncio
> is based not on native Python concepts like a coroutine, but on
> foreign concurrency concepts like callback or Future, and a coroutine
> is fitted as a second-class citizen on top of that. I understand why
> that was done - to not leave out all those twisteds from a shiny new
> world of asyncio, but sometimes one may wonder if having a clear cut
> would've helped (compat could then have been added as a clearly separate
> subpackage, implemented in terms of coroutines). Now people coming from
> non-coroutine frameworks who were promised compatibility see "bad"
> things in asyncio (and related areas), and people lured by a promise of
> native Python framework see bad things too.
>
>
This has nothing to do with people using twisted or other async frameworks
like tornado.
I think a coroutine should be first class. But all this should be done in a
way a beginner
can handle and not design this stuff for experts only. If we do this we
scare away new people.

This can be done step by step. No need to hurry.


And finally we have stackless Python but explicit. ;-)


-- 
bye by Wolfgang
___
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] Type hints -- a mediocre programmer's reaction

[Wolfgang Langner]

Hello,

On Thu, Apr 23, 2015 at 11:59 AM, Paul Sokolovsky  wrote:

> Hello,
>
> On Thu, 23 Apr 2015 10:43:52 +0200
> Wolfgang Langner  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 - MyPy, MicroPython, etc. Even more should use them (any JIT
> module, which are many), but sit in the bushes, waiting for a kick, like
> PEP484 provides.
>
>
> (*) Everyone of those who needs them. Otherwise, let's throw out
> metaclasses - noone uses them.
>
>
They are there to be used and won't go away.
But for most Libraries out there no one used it.

JIT (Numba), Cython and other compilers/tools doing optimization have their
own syntax and needs.
They need even more information like i32, i64, different floats and so on.
MyPy is really new and in development. And the docstring type spec way is
still possible.
MicroPython uses one annotation for their inline assembler stuff not type
hints.
For the library there are no type hints for function definitions.


Remark: I use Metaclasses, seldom but if needed very useful. :-)


-- 
bye by Wolfgang
___
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] async/await in Python; v2

[Yury Selivanov]

On 2015-04-23 8:10 AM, Greg Ewing wrote:

Andrew Svetlov wrote:
From my understanding to use cofunctions I must wrap it with costart 
call:


yield from gather(costart(coro1, a1, a2), costart(coro2), fut3)

There are other places in asyncio API those accept coroutines or
futures as parameters, not only Task() and async().


In a PEP 3152 aware version of asyncio, they would all
know about cofunctions and what to do with them.


What do you mean by that?

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)).

That's all. That's PEP 3152-aware world.

Somehow you think that it's OK to write

cocall fut()  # instead of just cocall fut()

*But it's not*.

A huge amount of existing code won't work.  You won't be
able to migrate it to new syntax easily.

If you have a future object 'fut', it's not intuitive
or pythonic to write 'cocall fut()'.

PEP 3152 was created in pre-asyncio era, and it shows.
It's just not gonna work.  I know because I designed
PEP 492 with a reference implementation at hand, tuning
the proposal to make it backwards compatible and on the
other hand to actually improve things.

Your idea of syntaticaly forcing to use 'cocall' with
parens is cute, but it breaks so many things and habits
that it just doesn't worth it.

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] async/await in Python; v2

[Yury Selivanov]

On 2015-04-23 9:01 AM, Yury Selivanov wrote:
cocall fut()  # instead of just cocall fut() 

Should be:

cocall fut()  # instead of just cocall fut

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] Type hints -- a mediocre programmer's reaction

[Paul Sokolovsky]

Hello,

On Thu, 23 Apr 2015 10:43:52 +0200
Wolfgang Langner  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 - MyPy, MicroPython, etc. Even more should use them (any JIT
module, which are many), but sit in the bushes, waiting for a kick, like
PEP484 provides.


(*) Everyone of those who needs them. Otherwise, let's throw out
metaclasses - noone uses them.


> Regards,
> 
> Wolfgang



-- 
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] Type hints -- a mediocre programmer's reaction

[Florian Bruhin]

* Wolfgang Langner  [2015-04-23 10:43:52 +0200]:
> 2. Using it in the language as part of the function signature, my first
> thought was oh good, then I changed my mind
>to: oh it can be very ugly and unreadable, it is the wrong place.
>Now I am against it, best is, if I have to specify type signatures, do
> it in one place, keep them up to date.
>Most of the time this is the documentation. Why not use the docstring
> with a standard type specifier for this.
>Suggested here:
> http://pydev.blogspot.de/2015/04/type-hinting-on-python.html

While I happen to agree with you (but I'm happy with both variants
really), I think that's a thing which has definitely been decided
already.

The idea is also listed in the PEP:

https://www.python.org/dev/peps/pep-0484/#other-backwards-compatible-conventions

Docstrings. There is an existing convention for docstrings, based
on the Sphinx notation ( :type arg1: description ). This is pretty
verbose (an extra line per parameter), and not very elegant. We
could also make up something new, but the annotation syntax is
hard to beat (because it was designed for this very purpose).

> For nearly every function I have written, there is a docstring and most of
> the time also a type specified.
> But if I must provide all this in a second place it is not the right way to
> go. Over time normally one place misses some changes and is wrong.

It seems there's an extension for Sphinx already to use type
annotations:

https://pypi.python.org/pypi/sphinx-autodoc-annotation

It seems to be older than PEP 484 (December 2013), so I hope it'll be
updated or already work well with the ideas in the PEP.

> Also ask why no one used type specifier, they are possible since Python 3.0
> ?
> Because it is the wrong way for Python.

Well, except that Sphinx extension, and MyPy, and MicroPython, and a
thing which already exists for run-time type checking[1] and probably
a whole lot more.

The whole *reason* for PEP 484 (at least from my perspective) is to
have a common base for the existing usages of type annotations.

Florian

[1] https://github.com/ceronman/typeannotations

-- 
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


pgp0dRiwqbI7j.pgp
Description: PGP signature
___
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] async/await in Python; v2

[Paul Sokolovsky]

Hello,

On Thu, 23 Apr 2015 20:39:51 +1200
Greg Ewing  wrote:

> Paul Sokolovsky wrote:
> > And having both asymmetric and symmetric
> > would quite confusing, especially that symmetric are more powerful
> > and asymmetric can be easily implemented in terms of symmetric using
> > continuation-passing style.
> 
> You can also use a trampoline of some kind to
> relay values back and forth between generators,
> to get something symmetric.

Yes, that's of course how coroutine frameworks were done long before
"yield from" appeared and how Trollius works now. But this just proves
point given to the original subtopic starter - that Python already has
powerful enough machinery to achieve functionality needed for "yield to
asyncio main loop", and adding something specifically for that will
only make situation more complicated (because what is asyncio main
loop? Just a random user-level function/coroutine, if you need to
support yielding "directly" to it, you need to supporting yielding
directly to an arbitrary coroutine).

> 
> -- 
> Greg

-- 
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

[Python-Dev] Task Request

[Leonid Kokorev]

Hello.
My name is Leonid. I'm very interested in Python programming language.
I'm sending this letter to the python-dev mailing list in order to get 
any task, that I could perform.

I want to help my community and improve my skills.
If anybody has not very complicated task, please email me at 
ldvc...@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

[Python-Dev] PEP 3152 and yield from Future()

[Victor Stinner]

(I prefer to start a new thread, the previous one is too long for me :-))

Hi,

I'm still trying to understand how the PEP 3152 would impact asyncio.
Guido suggests to replace "yield from fut" with "cocall fut()" (add
parenthesis) and so add a __cocall__() method to asyncio.Future.
Problem: PEP 3152 says "A cofunction (...) does not contain any yield
or yield from expressions". Currently, Future.__iter__() is
implemented using yield:

def __iter__(self):
if not self.done():
self._blocking = True
yield self  # This tells Task to wait for completion.
assert self.done(), "yield from wasn't used with future"
return self.result()  # May raise too.

>From my understanding, the PEP 3151 simply does not support
asyncio.Future. Am I right?

How is it possible to suspend a cofunction if it's not possible to use yield?

If waiting for a future in a cofunction is not supported, the PEP 3151
is useless for asyncio, since asyncio completly relies on futures.

Victor
___
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] async/await in Python; v2

[Paul Sokolovsky]

Hello,

On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov  wrote:

[]

> > 3.
> > async with and async for
> > Bead idea, we clutter the language even more and it is one more
> > thing every newbie could do wrong.
> > for x in y:
> >   result = await f()
> > is enough, every 'async' framework lived without it over years.
> 
> async for i in iterable:
> pass
> 
> is not equal for
> 
> for fut in iterable:
> i = yield from fut

But people who used Twisted all their life don't know that! They just
know that "async for" is not needed and bad.

I know I'm a bad guy to make such comments, too bad there's a bit of
truth in them, or everyone would just call me an a%$&ole right away.


Generally, I already provided feedback (on asyncio list) that asyncio
is based not on native Python concepts like a coroutine, but on
foreign concurrency concepts like callback or Future, and a coroutine
is fitted as a second-class citizen on top of that. I understand why
that was done - to not leave out all those twisteds from a shiny new
world of asyncio, but sometimes one may wonder if having a clear cut
would've helped (compat could then have been added as a clearly separate
subpackage, implemented in terms of coroutines). Now people coming from
non-coroutine frameworks who were promised compatibility see "bad"
things in asyncio (and related areas), and people lured by a promise of
native Python framework see bad things too.  


-- 
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] Type hints -- a mediocre programmer's reaction

[Daniel Holth]

On Thu, Apr 23, 2015 at 5:59 AM, Paul Sokolovsky  wrote:
> Hello,
>
> On Thu, 23 Apr 2015 10:43:52 +0200
> Wolfgang Langner  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 - MyPy, MicroPython, etc. Even more should use them (any JIT
> module, which are many), but sit in the bushes, waiting for a kick, like
> PEP484 provides.

It's OK that type hints are only to assist the programmer. 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
___
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] async/await in Python; v2

[Andrew Svetlov]

On Thu, Apr 23, 2015 at 3:27 PM, Wolfgang Langner
 wrote:
>
>
> On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky  wrote:
>>
>> Hello,
>>
>> On Thu, 23 Apr 2015 12:18:51 +0300
>> Andrew Svetlov  wrote:
>>
>> []
>>
>> > > 3.
>> > > async with and async for
>> > > Bead idea, we clutter the language even more and it is one more
>> > > thing every newbie could do wrong.
>> > > for x in y:
>> > >   result = await f()
>> > > is enough, every 'async' framework lived without it over years.
>> >
>> > async for i in iterable:
>> > pass
>> >
>> > is not equal for
>> >
>> > for fut in iterable:
>> > i = yield from fut
>>
>> But people who used Twisted all their life don't know that! They just
>> know that "async for" is not needed and bad.
>>
>
> I don't think it is bad nor not needed, but the syntax is not beautiful and
> for the 90% not doing async stuff irritating and one more thing to learn
> and do right/wrong.
>
> I had also a need for async loop. But there are other solutions like
> channels,
> not needing a new syntax.
>
By `channels` do you mean something like `asyncio.Queue`? It requires
that producer and consumer should be separate tasks. Often it works
(with some performance penalty cost) but creating 2 tasks is not
always obvious way to solve problem.

> Also possible a function returning futures and yield in the loop with a
> sentinel.
A proposal looks like guess to avoid `for` loop and use `while` everywhere.

Just compare `while` loop:

it = iter(it)
while True:
try:
i = next(it)
process(i)
except StopIteration:
break

with `for` alternative:

for i in it:
process(i)


>
> All this goes the road down to a producer consumer pattern. Nothing more.
>
I think one of the most convenient consumer-producer pattern
implementation in Python is `for` loop and iterators concept. It's
sometimes too limited but works pretty well in 95% of use cases.

>



-- 
Thanks,
Andrew Svetlov
___
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] Type hints -- a mediocre programmer's reaction

[Paul Sokolovsky]

Hello,

On Thu, 23 Apr 2015 14:48:58 +0200
Wolfgang Langner  wrote:

> Hello,
> 
> On Thu, Apr 23, 2015 at 11:59 AM, Paul Sokolovsky 
> wrote:
> 
> > Hello,
> >
> > On Thu, 23 Apr 2015 10:43:52 +0200
> > Wolfgang Langner  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 - MyPy, MicroPython, etc. Even more should use them (any
> > JIT module, which are many), but sit in the bushes, waiting for a
> > kick, like PEP484 provides.
> >
> >
> > (*) Everyone of those who needs them. Otherwise, let's throw out
> > metaclasses - noone uses them.
> >
> >
> They are there to be used and won't go away.
> But for most Libraries out there no one used it.
> 
> JIT (Numba), Cython and other compilers/tools doing optimization have
> their own syntax and needs.

That's exactly what needs to change, and where this PEP helps, as was
already pointed out:
http://code.activestate.com/lists/python-dev/135659/

> They need even more information like i32, i64, different floats and
> so on. 

That's poor excuse for not trying to be a good member of Python
community (and work on standard type annotation syntax, instead of
digging own hole).

> MyPy is really new and in development. And the docstring type
> spec way is still possible.

Anything is possible. The talk is about what makes most of sense.
Docstrings were always arbitrary string designated at human's
consumption, how (ab)using them for type annotations is better than
having clean language-grammar syntax?

> MicroPython uses one annotation for their inline assembler stuff not
> type hints.

Here's how MicroPython uses type annotations:
https://github.com/micropython/micropython/blob/master/tests/micropython/viper_ptr8_load.py

> For the library there are no type hints for function definitions.
> 
> 
> Remark: I use Metaclasses, seldom but if needed very useful. :-)
> 
> 
> -- 
> bye by Wolfgang



-- 
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] Type hints -- a mediocre programmer's reaction

[Paul Sokolovsky]

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, everyone(*)
> > uses them - MyPy, MicroPython, etc. Even more should use them (any
> > JIT module, which are many), but sit in the bushes, waiting for a
> > kick, like PEP484 provides.
> 
> It's OK that type hints are only to assist the programmer.

Yes, it's OK to have a situation where type hints assist only a
programmer. It's not OK to think that type hints may be useful only for
programmer, instead of bunch more purposes, several of which
were already shown in the long previous discussion.

> 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 intended to write "why type hints are not for *PyPy's*
performance". There're many other language implementations and modules
for which it may be useful, please don't limit your imagination by a
single case.

And speaking of PyPy, it really should think how to improve its
performance - not of generated programs, but of generation itself. If
compilation of a trivial program on a pumpy hardware takes 5 minutes
and gigabytes of RAM and diskspace, few people will use it for other
purposes beyond curiosity. There's something very un-Pythonic in
waiting 5 mins just to run 10-line script. Type hints can help here
too ;-) (by not wasting resources propagating types thru the same old
standard library for example).


-- 
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] Task Request

[Brett Cannon]

A better place to ask this question is the core-mentorship mailing list
which was set up specifically to help people contribute to Python.

On Thu, Apr 23, 2015 at 9:07 AM Leonid Kokorev  wrote:

> Hello.
> My name is Leonid. I'm very interested in Python programming language.
> I'm sending this letter to the python-dev mailing list in order to get
> any task, that I could perform.
> I want to help my community and improve my skills.
> If anybody has not very complicated task, please email me at
> ldvc...@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/brett%40python.org
>
___
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] Type hints -- a mediocre programmer's reaction

[Daniel Holth]

On Thu, Apr 23, 2015 at 9:55 AM, Paul Sokolovsky  wrote:
> 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, everyone(*)
>> > uses them - MyPy, MicroPython, etc. Even more should use them (any
>> > JIT module, which are many), but sit in the bushes, waiting for a
>> > kick, like PEP484 provides.
>>
>> It's OK that type hints are only to assist the programmer.
>
> Yes, it's OK to have a situation where type hints assist only a
> programmer. It's not OK to think that type hints may be useful only for
> programmer, instead of bunch more purposes, several of which
> were already shown in the long previous discussion.
>
>> 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 intended to write "why type hints are not for *PyPy's*
> performance". There're many other language implementations and modules
> for which it may be useful, please don't limit your imagination by a
> single case.
>
> And speaking of PyPy, it really should think how to improve its
> performance - not of generated programs, but of generation itself. If
> compilation of a trivial program on a pumpy hardware takes 5 minutes
> and gigabytes of RAM and diskspace, few people will use it for other
> purposes beyond curiosity. There's something very un-Pythonic in
> waiting 5 mins just to run 10-line script. Type hints can help here
> too ;-) (by not wasting resources propagating types thru the same old
> standard library for example).

Naturally, PyPy is very controversial.

Type annotations can help to compile Python into a subset of Python.
___
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] Type hints -- a mediocre programmer's reaction

[Harry Percival]

lol @ the fact that the type hints are breaking github's syntax highlighter
:)

On 23 April 2015 at 14:44, Paul Sokolovsky  wrote:

> Hello,
>
> On Thu, 23 Apr 2015 14:48:58 +0200
> Wolfgang Langner  wrote:
>
> > Hello,
> >
> > On Thu, Apr 23, 2015 at 11:59 AM, Paul Sokolovsky 
> > wrote:
> >
> > > Hello,
> > >
> > > On Thu, 23 Apr 2015 10:43:52 +0200
> > > Wolfgang Langner  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 - MyPy, MicroPython, etc. Even more should use them (any
> > > JIT module, which are many), but sit in the bushes, waiting for a
> > > kick, like PEP484 provides.
> > >
> > >
> > > (*) Everyone of those who needs them. Otherwise, let's throw out
> > > metaclasses - noone uses them.
> > >
> > >
> > They are there to be used and won't go away.
> > But for most Libraries out there no one used it.
> >
> > JIT (Numba), Cython and other compilers/tools doing optimization have
> > their own syntax and needs.
>
> That's exactly what needs to change, and where this PEP helps, as was
> already pointed out:
> http://code.activestate.com/lists/python-dev/135659/
>
> > They need even more information like i32, i64, different floats and
> > so on.
>
> That's poor excuse for not trying to be a good member of Python
> community (and work on standard type annotation syntax, instead of
> digging own hole).
>
> > MyPy is really new and in development. And the docstring type
> > spec way is still possible.
>
> Anything is possible. The talk is about what makes most of sense.
> Docstrings were always arbitrary string designated at human's
> consumption, how (ab)using them for type annotations is better than
> having clean language-grammar syntax?
>
> > MicroPython uses one annotation for their inline assembler stuff not
> > type hints.
>
> Here's how MicroPython uses type annotations:
>
> https://github.com/micropython/micropython/blob/master/tests/micropython/viper_ptr8_load.py
>
> > For the library there are no type hints for function definitions.
> >
> >
> > Remark: I use Metaclasses, seldom but if needed very useful. :-)
> >
> >
> > --
> > bye by Wolfgang
>
>
>
> --
> 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/hjwp2%40cantab.net
>



-- 
--
Harry J.W. Percival
--
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype: harry.percival
___
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] Task Request

[Leonid Kokorev]

Thanks for advice.

On 04/23/2015 05:07 PM, Brett Cannon wrote:
A better place to ask this question is the core-mentorship mailing 
list which was set up specifically to help people contribute to Python.


On Thu, Apr 23, 2015 at 9:07 AM Leonid Kokorev > wrote:


Hello.
My name is Leonid. I'm very interested in Python programming language.
I'm sending this letter to the python-dev mailing list in order to get
any task, that I could perform.
I want to help my community and improve my skills.
If anybody has not very complicated task, please email me at
ldvc...@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/brett%40python.org



___
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] Type hints -- a mediocre programmer's reaction

[Paul Sokolovsky]

Hello,

On Thu, 23 Apr 2015 15:25:30 +0100
Harry Percival  wrote:

> lol @ the fact that the type hints are breaking github's syntax
> highlighter :)

What one can expect from software written in Ruby? ;-)


-- 
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 3152 and yield from Future()

[andrew . svetlov]

I can live with `cocall fut()` but the difference between `data = yield from 
loop.sock_recv(sock, 1024)` and `data = cocall (loop.sock_recv(sock, 1024))()` 
frustrates me very much.



—
Sent from Mailbox

On Thu, Apr 23, 2015 at 4:09 PM, Victor Stinner 
wrote:

> (I prefer to start a new thread, the previous one is too long for me :-))
> Hi,
> I'm still trying to understand how the PEP 3152 would impact asyncio.
> Guido suggests to replace "yield from fut" with "cocall fut()" (add
> parenthesis) and so add a __cocall__() method to asyncio.Future.
> Problem: PEP 3152 says "A cofunction (...) does not contain any yield
> or yield from expressions". Currently, Future.__iter__() is
> implemented using yield:
> def __iter__(self):
> if not self.done():
> self._blocking = True
> yield self  # This tells Task to wait for completion.
> assert self.done(), "yield from wasn't used with future"
> return self.result()  # May raise too.
> From my understanding, the PEP 3151 simply does not support
> asyncio.Future. Am I right?
> How is it possible to suspend a cofunction if it's not possible to use yield?
> If waiting for a future in a cofunction is not supported, the PEP 3151
> is useless for asyncio, since asyncio completly relies on futures.
> Victor
> ___
> 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/andrew.svetlov%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 3152 and yield from Future()

[Łukasz Langa]

> On Apr 23, 2015, at 8:22 AM, andrew.svet...@gmail.com wrote:
> 
> I can live with `cocall fut()` but the difference between `data = yield from 
> loop.sock_recv(sock, 1024)` and `data = cocall (loop.sock_recv(sock, 
> 1024))()` frustrates me very much.

This is unacceptable. None of the existing async/await implementations in other 
languages force you to write stuff like this.

-- 
Best regards,
Łukasz Langa

WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev___
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] async/await in Python; v2

[Yury Selivanov]

Hi Wolfgang,

On 2015-04-23 8:27 AM, Wolfgang Langner wrote:

On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky  wrote:


Hello,

On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov  wrote:

[]


3.
async with and async for
Bead idea, we clutter the language even more and it is one more
thing every newbie could do wrong.
for x in y:
   result = await f()
is enough, every 'async' framework lived without it over years.

async for i in iterable:
 pass

is not equal for

for fut in iterable:
 i = yield from fut

But people who used Twisted all their life don't know that! They just
know that "async for" is not needed and bad.



I don't think it is bad nor not needed, but the syntax is not beautiful and
for the 90% not doing async stuff irritating and one more thing to learn
and do right/wrong.

There is no way to do things wrong in PEP 492.  An object
either has __aiter__ or it will be rejected by async for.
An object either has __aenter__ or it will be rejected by
async with.

  transaction = yield from connection.transaction()
  try:
...
  except:
yield from transaction.rollback()
  else:
yield from transaction.commit()

is certainly more irritating than

  async with connection.transcation():
...



I had also a need for async loop. But there are other solutions like
channels,
not needing a new syntax.

Also possible a function returning futures and yield in the loop with a
sentinel.

All this goes the road down to a producer consumer pattern. Nothing more.




I know I'm a bad guy to make such comments, too bad there's a bit of
truth in them, or everyone would just call me an a%$&ole right away.


Generally, I already provided feedback (on asyncio list) that asyncio
is based not on native Python concepts like a coroutine, but on
foreign concurrency concepts like callback or Future, and a coroutine
is fitted as a second-class citizen on top of that. I understand why
that was done - to not leave out all those twisteds from a shiny new
world of asyncio, but sometimes one may wonder if having a clear cut
would've helped (compat could then have been added as a clearly separate
subpackage, implemented in terms of coroutines). Now people coming from
non-coroutine frameworks who were promised compatibility see "bad"
things in asyncio (and related areas), and people lured by a promise of
native Python framework see bad things too.



This has nothing to do with people using twisted or other async frameworks
like tornado.
I think a coroutine should be first class. But all this should be done in a
way a beginner
can handle and not design this stuff for experts only.


I think that most of async frameworks out there are for
experts only.  Precisely because of 'yield from', 'yield',
inlineCallbacks, '@coroutine', channels and other stuff.

PEP 492 will make it all easier. And Twisted can use
its features too.



If we do this we
scare away new people.


It doesn't scare away anyone.  async/await were the most
awaited features in dart and javascript.  One of the most
popular features in c#.


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] PEP 3152 and yield from Future()

[Victor Stinner]

2015-04-23 17:22 GMT+02:00  :
> I can live with `cocall fut()` but the difference between `data = yield from
> loop.sock_recv(sock, 1024)` and `data = cocall (loop.sock_recv(sock,
> 1024))()` frustrates me very much.

You didn't answer to my question. My question is: is it possible to
implement Future.__cocall__() since yield is defined in cofunctions.
If it's possible, can you please show how? (Show me the code!)

Victor
___
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] async/await in Python; v2

[Yury Selivanov]

Hi,

On 2015-04-23 3:30 AM, Wolfgang Langner wrote:

Hi,

most of the time I am a silent reader but in this discussion I must step in.
I use twisted and async stuff a lot over years followed development of
asyncio closely.

First it is good to do differentiate async coroutines from generators. So
everyone can see it and have this in mind
and don't mix up booth. It is also easier to explain for new users.
Sometimes generators blows their mind and it takes
a while to get used to them. Async stuff is even harder.

1. I am fine with using something special instead of "yield" or "yield
from" for this. C# "await" is ok.

Everything else suggested complicates the language and makes it harder to
read.

2.
async def f(): is harder to read and something special also it breaks the
symmetry in front (def indent).
Also every existing tooling must be changed to support it. Same for def
async, def f() async:
I thing a decorator is enough here
@coroutine
def f():
is the best solution to mark something as a coroutine.


You can't combine a keyword (await) with runtime decorator. Also
it's harder for tools to support @coroutine / @inlineCallbacks
than "async".



3.
async with and async for
Bead idea, we clutter the language even more and it is one more thing every
newbie could do wrong.
for x in y:
   result = await f()
is enough, every 'async' framework lived without it over years.


I only lived without it because I used greenlets for async
for's & with's.  There must be a native language concept to
do these things.


Same for with statement.

The main use case suggested was for database stuff and this is also where
most are best with
defer something to a thread and keep it none async.


All together it is very late in the development cycle for 3.5 to
incorporate such a big change.


The PEP isn't a result of some quick brainstorming.  It's a
result of long experience using asyncio and working around
many painpoints of async programming.


Best is to give all this some more time and defer it to 3.6 and some alpha
releases to experiment with.


There is reference implementation.  asyncio is fully ported,
every package for asyncio should work.  You can experiment right now
and find a real issue why the PEP doesn't work.


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] PEP 3152 and yield from Future()

[Yury Selivanov]

Hi Victor,

On 2015-04-23 4:43 AM, Victor Stinner wrote:
[...]

 From my understanding, the PEP 3151 simply does not support
asyncio.Future. Am I right?



Greg wants to implement __cocall__ on futures.  This way
you'll be able to write

   cocall fut()  # instead of "await fut"

So you *will have to* use "()"


Another problem is functions that return future:

def do_something():
...
return fut

With Greg's idea to call it you would do:

   cocall (do_something())()

That means that you can't refactor your "do_something"
function and make it a coroutine.

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] async/await in Python; v2

[Wolfgang Langner]

On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov 
wrote:

> Hi Wolfgang,
>
> On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
>
>> On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky 
>> wrote:
>>
>>  Hello,
>>>
>>> On Thu, 23 Apr 2015 12:18:51 +0300
>>> Andrew Svetlov  wrote:
>>>
>>> []
>>>
>>>  3.
> async with and async for
> Bead idea, we clutter the language even more and it is one more
> thing every newbie could do wrong.
> for x in y:
>result = await f()
> is enough, every 'async' framework lived without it over years.
>
 async for i in iterable:
  pass

 is not equal for

 for fut in iterable:
  i = yield from fut

>>> But people who used Twisted all their life don't know that! They just
>>> know that "async for" is not needed and bad.
>>>
>>>
>>>  I don't think it is bad nor not needed, but the syntax is not beautiful
>> and
>> for the 90% not doing async stuff irritating and one more thing to learn
>> and do right/wrong.
>>
> There is no way to do things wrong in PEP 492.  An object
> either has __aiter__ or it will be rejected by async for.
> An object either has __aenter__ or it will be rejected by
> async with.
>
>   transaction = yield from connection.transaction()
>   try:
> ...
>   except:
> yield from transaction.rollback()
>   else:
> yield from transaction.commit()
>
> is certainly more irritating than
>
>   async with connection.transcation():
> ...
>
>
>> I had also a need for async loop. But there are other solutions like
>> channels,
>> not needing a new syntax.
>>
>> Also possible a function returning futures and yield in the loop with a
>> sentinel.
>>
>> All this goes the road down to a producer consumer pattern. Nothing more.
>>
>>
>>
>>  I know I'm a bad guy to make such comments, too bad there's a bit of
>>> truth in them, or everyone would just call me an a%$&ole right away.
>>>
>>>
>>> Generally, I already provided feedback (on asyncio list) that asyncio
>>> is based not on native Python concepts like a coroutine, but on
>>> foreign concurrency concepts like callback or Future, and a coroutine
>>> is fitted as a second-class citizen on top of that. I understand why
>>> that was done - to not leave out all those twisteds from a shiny new
>>> world of asyncio, but sometimes one may wonder if having a clear cut
>>> would've helped (compat could then have been added as a clearly separate
>>> subpackage, implemented in terms of coroutines). Now people coming from
>>> non-coroutine frameworks who were promised compatibility see "bad"
>>> things in asyncio (and related areas), and people lured by a promise of
>>> native Python framework see bad things too.
>>>
>>>
>>>  This has nothing to do with people using twisted or other async
>> frameworks
>> like tornado.
>> I think a coroutine should be first class. But all this should be done in
>> a
>> way a beginner
>> can handle and not design this stuff for experts only.
>>
>
> I think that most of async frameworks out there are for
> experts only.  Precisely because of 'yield from', 'yield',
> inlineCallbacks, '@coroutine', channels and other stuff.
>
> PEP 492 will make it all easier. And Twisted can use
> its features too.
>

Yes and it is good to make it easier. But not complicate it for others.
Beginners will be confronted with all this new syntax an my feel lost.
Oh I have to different for loops, one with async. Same for with statement.


>
>  If we do this we
>> scare away new people.
>>
>
> It doesn't scare away anyone.  async/await were the most
> awaited features in dart and javascript.  One of the most
> popular features in c#.
>

I like it in C#.
I like await for Python but I don't like async there and how to specify it.
I still think a decorator is enough and no special for and with syntax.

async in JavaScript is for execution a whole script asynchronously used in
the script tag.
dart is for the google universe with less usage outside.


-- 
bye by Wolfgang
___
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] async/await in Python; v2

[Yury Selivanov]

Hi Wolfgang,

On 2015-04-23 11:57 AM, Wolfgang Langner wrote:

On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov 
wrote:


Hi Wolfgang,

On 2015-04-23 8:27 AM, Wolfgang Langner wrote:


On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky 
wrote:

  Hello,

On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov  wrote:

[]

  3.

async with and async for
Bead idea, we clutter the language even more and it is one more
thing every newbie could do wrong.
for x in y:
result = await f()
is enough, every 'async' framework lived without it over years.


async for i in iterable:
  pass

is not equal for

for fut in iterable:
  i = yield from fut


But people who used Twisted all their life don't know that! They just
know that "async for" is not needed and bad.


  I don't think it is bad nor not needed, but the syntax is not beautiful

and
for the 90% not doing async stuff irritating and one more thing to learn
and do right/wrong.


There is no way to do things wrong in PEP 492.  An object
either has __aiter__ or it will be rejected by async for.
An object either has __aenter__ or it will be rejected by
async with.

   transaction = yield from connection.transaction()
   try:
 ...
   except:
 yield from transaction.rollback()
   else:
 yield from transaction.commit()

is certainly more irritating than

   async with connection.transcation():
 ...



I had also a need for async loop. But there are other solutions like
channels,
not needing a new syntax.

Also possible a function returning futures and yield in the loop with a
sentinel.

All this goes the road down to a producer consumer pattern. Nothing more.



  I know I'm a bad guy to make such comments, too bad there's a bit of

truth in them, or everyone would just call me an a%$&ole right away.


Generally, I already provided feedback (on asyncio list) that asyncio
is based not on native Python concepts like a coroutine, but on
foreign concurrency concepts like callback or Future, and a coroutine
is fitted as a second-class citizen on top of that. I understand why
that was done - to not leave out all those twisteds from a shiny new
world of asyncio, but sometimes one may wonder if having a clear cut
would've helped (compat could then have been added as a clearly separate
subpackage, implemented in terms of coroutines). Now people coming from
non-coroutine frameworks who were promised compatibility see "bad"
things in asyncio (and related areas), and people lured by a promise of
native Python framework see bad things too.


  This has nothing to do with people using twisted or other async

frameworks
like tornado.
I think a coroutine should be first class. But all this should be done in
a
way a beginner
can handle and not design this stuff for experts only.


I think that most of async frameworks out there are for
experts only.  Precisely because of 'yield from', 'yield',
inlineCallbacks, '@coroutine', channels and other stuff.

PEP 492 will make it all easier. And Twisted can use
its features too.


Yes and it is good to make it easier. But not complicate it for others.
Beginners will be confronted with all this new syntax an my feel lost.
Oh I have to different for loops, one with async. Same for with statement.


Absolute beginners don't write async code and http servers.

And when they start doing things like that, they're not someone
who can't understand 'async' and 'await'.  It's not harder
than '@coroutine' and 'yield from'.

What is hard for even experienced users, is to understand
what's the difference between 'yield from' and 'yield', and
how asyncio works in the core. Why you should always use the
former etc.

Unfortunately I just can't agree with you here.  Too much time
was spent trying to explain people how to write asyncio code,
and it's hard.  PEP 492 will make it easier.





  If we do this we

scare away new people.


It doesn't scare away anyone.  async/await were the most
awaited features in dart and javascript.  One of the most
popular features in c#.


I like it in C#.
I like await for Python but I don't like async there and how to specify it.
I still think a decorator is enough and no special for and with syntax.

Please read the "Debugging Features" section in the PEP. It explains
why decorator is not enough.  Also the "Rationale" section also
stresses some points.

Decorator solution is "enough", but it's far from being ideal.

For IDEs and linters it's harder to support.  What if you
write "from asyncio import coroutine as coro"?  You have to analyze
the code statically to reason about what "@coroutine" is.  Moreover,
you need to enable good IDE support for other frameworks too.



async in JavaScript is for execution a whole script asynchronously used in
the script tag.
dart is for the google universe with less usage outside.




Please read a proposal to add async/await in JS (refd in the PEP).
It's very likely to be accepted, because JS is asynchronous to its
very core, and it's a pain to program in it with callb

Re: [Python-Dev] PEP 3152 and yield from Future()

[Yury Selivanov]

On 2015-04-23 11:26 AM, Victor Stinner wrote:

2015-04-23 17:22 GMT+02:00  :

I can live with `cocall fut()` but the difference between `data = yield from
loop.sock_recv(sock, 1024)` and `data = cocall (loop.sock_recv(sock,
1024))()` frustrates me very much.

You didn't answer to my question. My question is: is it possible to
implement Future.__cocall__() since yield is defined in cofunctions.
If it's possible, can you please show how? (Show me the code!)


I can do that.

class Future:

def __iter__(self):
   
__cocall__ = __iter__


I've outlined the problem with this approach in parallel
email: https://mail.python.org/pipermail/python-dev/2015-April/139456.html

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] async/await in Python; v2

[Wolfgang Langner]

On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov 
wrote:

> Hi Wolfgang,
>
> On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
>
>> On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky 
>> wrote:
>>
>>  Hello,
>>>
>>> On Thu, 23 Apr 2015 12:18:51 +0300
>>> Andrew Svetlov  wrote:
>>>
>>> []
>>>
>>>  3.
> async with and async for
> Bead idea, we clutter the language even more and it is one more
> thing every newbie could do wrong.
> for x in y:
>result = await f()
> is enough, every 'async' framework lived without it over years.
>
 async for i in iterable:
  pass

 is not equal for

 for fut in iterable:
  i = yield from fut

>>> But people who used Twisted all their life don't know that! They just
>>> know that "async for" is not needed and bad.
>>>
>>>
>>>  I don't think it is bad nor not needed, but the syntax is not beautiful
>> and
>> for the 90% not doing async stuff irritating and one more thing to learn
>> and do right/wrong.
>>
> There is no way to do things wrong in PEP 492.  An object
> either has __aiter__ or it will be rejected by async for.
> An object either has __aenter__ or it will be rejected by
> async with.
>

Don't mean it can be done wrong on execution or syntax level.
I mean for a beginner it is not as easy an more and some will try
async in some places, yes they will get an error. But there is a
new possibility to get such errors if async is there for with and for
statements.
And the next beginner will then implement __aiter__ instead of __iter__
because
he/she don't get it.

On the other side I like "await" and __await__ implementation.
Symmetric good easy to explain, same with "int" and "__int__" and all
others.


>
>   transaction = yield from connection.transaction()
>   try:
> ...
>   except:
> yield from transaction.rollback()
>   else:
> yield from transaction.commit()
>
> is certainly more irritating than
>
>   async with connection.transcation():
> ...
>
>
Sorry till now I use async stuff and database access and do it in an extra
thread in sync mode.
No performance problems and can use all good maintained database libraries.
Also twisteds RDBMS (adbapi) is enough here. First I thought it is not
enough or to slow but this was not the case.
https://twistedmatrix.com/documents/current/core/howto/rdbms.html

Here I am on line with Mike Bayer:
http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/
___
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] async/await in Python; v2

[Yury Selivanov]

Wolfgang,

On 2015-04-23 12:12 PM, Wolfgang Langner wrote:

On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov 
wrote:


Hi Wolfgang,

On 2015-04-23 8:27 AM, Wolfgang Langner wrote:


On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky 
wrote:

  Hello,

On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov  wrote:

[]

  3.

async with and async for
Bead idea, we clutter the language even more and it is one more
thing every newbie could do wrong.
for x in y:
result = await f()
is enough, every 'async' framework lived without it over years.


async for i in iterable:
  pass

is not equal for

for fut in iterable:
  i = yield from fut


But people who used Twisted all their life don't know that! They just
know that "async for" is not needed and bad.


  I don't think it is bad nor not needed, but the syntax is not beautiful

and
for the 90% not doing async stuff irritating and one more thing to learn
and do right/wrong.


There is no way to do things wrong in PEP 492.  An object
either has __aiter__ or it will be rejected by async for.
An object either has __aenter__ or it will be rejected by
async with.


Don't mean it can be done wrong on execution or syntax level.
I mean for a beginner it is not as easy an more and some will try
async in some places, yes they will get an error. But there is a
new possibility to get such errors if async is there for with and for
statements.
And the next beginner will then implement __aiter__ instead of __iter__
because
he/she don't get it.


Sorry, Wolfgang, but I don't get your argument.  Beginners
shouldn't just randomly try to use statements.  There is a
documentation for that.  Plus we can make exception messages
better.



On the other side I like "await" and __await__ implementation.
Symmetric good easy to explain, same with "int" and "__int__" and all
others.


Glad to hear that! ;)





   transaction = yield from connection.transaction()
   try:
 ...
   except:
 yield from transaction.rollback()
   else:
 yield from transaction.commit()

is certainly more irritating than

   async with connection.transcation():
 ...



Sorry till now I use async stuff and database access and do it in an extra
thread in sync mode.
No performance problems and can use all good maintained database libraries.
Also twisteds RDBMS (adbapi) is enough here. First I thought it is not
enough or to slow but this was not the case.
https://twistedmatrix.com/documents/current/core/howto/rdbms.html

Here I am on line with Mike Bayer:
http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/



It's good article, I read it. The PEP will help those who
don't want to use threads and want to use coroutines.

There are no fundamental reasons why coroutines are
slower than threads.  It will only be improved. There is
a fundamental reason to avoid doing threads in python
though, because it can harm performance drastically.

There are some fundamental reasons why Mike will always
love threads though -- we won't ever have asynchronous
__getattr__, so SQLAlchemy won't be as elegant as it is
in sync mode.

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] PEP 3152 and yield from Future()

[Yury Selivanov]

I've updated the PEP 492: https://hg.python.org/peps/rev/352d4f907266

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] async/await in Python; v2

[Wolfgang Langner]

On Thu, Apr 23, 2015 at 6:22 PM, Yury Selivanov 
wrote:

> Wolfgang,
>
>
> On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
>
>> On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov 
>> wrote:
>>
>>  Hi Wolfgang,
>>>
>>> On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
>>>
>>>  On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky 
 wrote:

   Hello,

> On Thu, 23 Apr 2015 12:18:51 +0300
> Andrew Svetlov  wrote:
>
> []
>
>   3.
>
>> async with and async for
>>> Bead idea, we clutter the language even more and it is one more
>>> thing every newbie could do wrong.
>>> for x in y:
>>> result = await f()
>>> is enough, every 'async' framework lived without it over years.
>>>
>>>  async for i in iterable:
>>   pass
>>
>> is not equal for
>>
>> for fut in iterable:
>>   i = yield from fut
>>
>>  But people who used Twisted all their life don't know that! They just
> know that "async for" is not needed and bad.
>
>
>   I don't think it is bad nor not needed, but the syntax is not
> beautiful
>
 and
 for the 90% not doing async stuff irritating and one more thing to learn
 and do right/wrong.

  There is no way to do things wrong in PEP 492.  An object
>>> either has __aiter__ or it will be rejected by async for.
>>> An object either has __aenter__ or it will be rejected by
>>> async with.
>>>
>>>  Don't mean it can be done wrong on execution or syntax level.
>> I mean for a beginner it is not as easy an more and some will try
>> async in some places, yes they will get an error. But there is a
>> new possibility to get such errors if async is there for with and for
>> statements.
>> And the next beginner will then implement __aiter__ instead of __iter__
>> because
>> he/she don't get it.
>>
>
> Sorry, Wolfgang, but I don't get your argument.  Beginners
> shouldn't just randomly try to use statements.  There is a
> documentation for that.  Plus we can make exception messages
> better.
>

Had to coach a lot of new users to Python and some to async stuff in
twisted.
And what beginners not should do don't care them. ;-)
They will do strange stuff and go other way's than you expected. I only
like to make
it as easy as possible for them. Nothing more.
Less keywords, less ways to do something, best only one way to do it.



Don't get me wrong, I like the PEP it is well written and covers a lot of
areas about async programming.
I know Python must improve in this area and has a lot of potential.
But don't hesitate, give the people time to try it and mature it. If all
this should be in 3.5 it is to early.

Also we can avoid the async keyword completely and do the same as for
generators.
If there is an await, it is a coroutine.
IDE's can detect generators and must only be expanded to detect coroutines.

Function
with yield -> return a generator
with await -> return a coroutine

Move async for and async with to another PEP and handle it later or with a
different syntax using the new await keyword.

Only one new keyword, good improvement for async programming.

Sorry still don't like the word async in a language and sprinkle it every
where.
And still have the feeling if we provide async for loop we next must
provide async like generator expresions or list comprehensions or ...
never ends ;-)

The only downside with await converting a function to a coroutine is, it is
not explicit marked.
But if we care about this, whats about generators and yield ?


-- 
bye by Wolfgang
___
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 3152 and yield from Future()

[Guido van Rossum]

I think this is the nail in PEP 3152's coffin.

On Thu, Apr 23, 2015 at 9:54 AM, Yury Selivanov 
wrote:

> I've updated the PEP 492: https://hg.python.org/peps/rev/352d4f907266
>
> 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/guido%40python.org
>



-- 
--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 3152 and yield from Future()

[Antoine Pitrou]

On Thu, 23 Apr 2015 09:58:33 -0700
Guido van Rossum  wrote:
> I think this is the nail in PEP 3152's coffin.

If you only put one nail, it might manage to get out.

Regards

Antoine.


___
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 3152 and yield from Future()

[Ryan Gonzalez]

Then blow it up like Duck Dynasty does.

On April 23, 2015 12:07:46 PM CDT, Antoine Pitrou  wrote:
>On Thu, 23 Apr 2015 09:58:33 -0700
>Guido van Rossum  wrote:
>> I think this is the nail in PEP 3152's coffin.
>
>If you only put one nail, it might manage to get out.
>
>Regards
>
>Antoine.
>
>
>___
>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/rymg19%40gmail.com

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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] async/await in Python; v2

[Yury Selivanov]

Wolfgang,

On 2015-04-23 12:58 PM, Wolfgang Langner wrote:

On Thu, Apr 23, 2015 at 6:22 PM, Yury Selivanov 
wrote:


Wolfgang,


On 2015-04-23 12:12 PM, Wolfgang Langner wrote:


On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov 
wrote:

  Hi Wolfgang,

On 2015-04-23 8:27 AM, Wolfgang Langner wrote:

  On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky 

wrote:

   Hello,


On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov  wrote:

[]

   3.


async with and async for

Bead idea, we clutter the language even more and it is one more
thing every newbie could do wrong.
for x in y:
 result = await f()
is enough, every 'async' framework lived without it over years.

  async for i in iterable:

   pass

is not equal for

for fut in iterable:
   i = yield from fut

  But people who used Twisted all their life don't know that! They just

know that "async for" is not needed and bad.


   I don't think it is bad nor not needed, but the syntax is not
beautiful


and
for the 90% not doing async stuff irritating and one more thing to learn
and do right/wrong.

  There is no way to do things wrong in PEP 492.  An object

either has __aiter__ or it will be rejected by async for.
An object either has __aenter__ or it will be rejected by
async with.

  Don't mean it can be done wrong on execution or syntax level.

I mean for a beginner it is not as easy an more and some will try
async in some places, yes they will get an error. But there is a
new possibility to get such errors if async is there for with and for
statements.
And the next beginner will then implement __aiter__ instead of __iter__
because
he/she don't get it.


Sorry, Wolfgang, but I don't get your argument.  Beginners
shouldn't just randomly try to use statements.  There is a
documentation for that.  Plus we can make exception messages
better.


Had to coach a lot of new users to Python and some to async stuff in
twisted.
And what beginners not should do don't care them. ;-)
They will do strange stuff and go other way's than you expected. I only
like to make
it as easy as possible for them. Nothing more.
Less keywords, less ways to do something, best only one way to do it.



Don't get me wrong, I like the PEP it is well written and covers a lot of
areas about async programming.
I know Python must improve in this area and has a lot of potential.
But don't hesitate, give the people time to try it and mature it. If all
this should be in 3.5 it is to early.


The thing about this PEP is that it's build on existing
concepts that were validated with asyncio.

As for is it enough time to review it or not -- it's up to
BDFL to decide.  I'm doing my best trying to get the reference
implementation reviewed and to address all questions in the
PEP, hoping that it will help.

I can only say that if it doesn't land in 3.5, we'll have
to wait another *1.5 years*.  And it's not that people will
download CPython 3.6.alpha0 and start rewriting their code
and playing with it.  In the meanwhile, people want more
good reasons to migrate to Python 3, and I strongly believe
that this PEP is a great reason.

Moreover, it's several months before 3.5 is released. We still
will be able to slightly alter the behaviour and gather
feedback during beta periods.



Also we can avoid the async keyword completely and do the same as for
generators.
If there is an await, it is a coroutine.

Unfortunately there is a problem with this approach:
refactoring of code becomes much harder.  That's one of the
corner cases that @coroutine decorator solves; see
https://www.python.org/dev/peps/pep-0492/#importance-of-async-keyword

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] async/await in Python; v2

[Barry Warsaw]

On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote:

>The updated version of the PEP should be available shortly at
>https://www.python.org/dev/peps/pep-0492 and is also pasted in this email.

There's a lot to like about PEP 492.  I only want to mildly bikeshed a bit on
the proposed new syntax.

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 the current line to find the
function its defined on.  Sure, tools can be updated but it is it *necessary*
to choose a syntax that breaks tools?

def async useful():

seems okay to me.

Probably the biggest impact on the PEP would be symmetry with asynchronous
with and for.  What about:

with async lock:

and

for async data in cursor:

That would also preserve at least some behavior of existing tools.

Anyway, since the PEP doesn't explicitly describe this as an alternative, I
want to bring it up.

(I have mild concerns about __a*__ magic methods, since I think they'll be
harder to visually separate, but here the PEP does describe the __async_*__
alternatives.)

Cheers,
-Barry


pgpxCIhVKHrXy.pgp
Description: OpenPGP digital signature
___
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] async/await in Python; v2

[Yury Selivanov]

Hi Barry,

On 2015-04-23 1:51 PM, Barry Warsaw wrote:

On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote:


The updated version of the PEP should be available shortly at
https://www.python.org/dev/peps/pep-0492 and is also pasted in this email.

There's a lot to like about PEP 492.  I only want to mildly bikeshed a bit on
the proposed new syntax.

Thanks!


Why "async def" and not "def async"?


To my eye 'async def name()', 'async with', 'async for' look
better than 'def async name()', 'with async' and 'for async'.
But that's highly subjective.

I also read "for async item in iter:" as "I'm iterating iter
with async item".



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 the current line to find the
function its defined on.  Sure, tools can be updated but it is it *necessary*
to choose a syntax that breaks tools?

 def async useful():

seems okay to me.

Probably the biggest impact on the PEP would be symmetry with asynchronous
with and for.  What about:

 with async lock:

and

 for async data in cursor:

That would also preserve at least some behavior of existing tools.

Anyway, since the PEP doesn't explicitly describe this as an alternative, I
want to bring it up.

(I have mild concerns about __a*__ magic methods, since I think they'll be
harder to visually separate, but here the PEP does describe the __async_*__
alternatives.)




Anyways, I'm open to change the order of keywords if most
people like it that way.  Same for __async_*__ naming.

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] async/await in Python; v2

[Barry Warsaw]

On Apr 23, 2015, at 02:02 PM, Yury Selivanov wrote:

>To my eye 'async def name()', 'async with', 'async for' look
>better than 'def async name()', 'with async' and 'for async'.
>But that's highly subjective.

Would you be willing to add this as an alternative to the PEP, under the "Why
async def" section probably?

As with all such bikesheds, Guido will pick the color and we'll ooh and
ahh. :)

Cheers,
-Barry
___
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] async/await in Python; v2

[MRAB]

On 2015-04-23 18:51, Barry Warsaw wrote:

On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote:


The updated version of the PEP should be available shortly at
https://www.python.org/dev/peps/pep-0492 and is also pasted in this email.


There's a lot to like about PEP 492.  I only want to mildly bikeshed a bit on
the proposed new syntax.

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 the current line to find the
function its defined on.  Sure, tools can be updated but it is it *necessary*
to choose a syntax that breaks tools?

 def async useful():

seems okay to me.

Probably the biggest impact on the PEP would be symmetry with asynchronous
with and for.  What about:

 with async lock:

and

 for async data in cursor:

That would also preserve at least some behavior of existing tools.

Anyway, since the PEP doesn't explicitly describe this as an alternative, I
want to bring it up.

(I have mild concerns about __a*__ magic methods, since I think they'll be
harder to visually separate, but here the PEP does describe the __async_*__
alternatives.)


On the other hand, existing tools might be expecting "def" and "for" to
be followed by a name.
___
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] async/await in Python; v2

[Yury Selivanov]

Barry,

On 2015-04-23 2:12 PM, Barry Warsaw wrote:

On Apr 23, 2015, at 02:02 PM, Yury Selivanov wrote:


To my eye 'async def name()', 'async with', 'async for' look
better than 'def async name()', 'with async' and 'for async'.
But that's highly subjective.

Would you be willing to add this as an alternative to the PEP, under the "Why
async def" section probably?

As with all such bikesheds, Guido will pick the color and we'll ooh and
ahh. :)


Sure! I think it's a great idea:

https://hg.python.org/peps/rev/8cb4c0ab0931
https://hg.python.org/peps/rev/ec319bf4c86e

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] async/await in Python; v2

[Yury Selivanov]

On 2015-04-23 3:03 AM, Greg Ewing wrote:

Yury Selivanov wrote:

- If it's an object with __await__, return iter(object.__await__())


Is the iter() really needed? Couldn't the contract of
__await__ be that it always returns an iterator?



I wrote it the wrong way. iter() isn't needed, you're right.
This is a quote from the ref implementation:

   if (!PyIter_Check(await_obj)) {
PyErr_Format(PyExc_TypeError,
 "__await__ must return an iterator, %.100s",
 Py_TYPE(await_obj)->tp_name);


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] async/await in Python; v2

[Łukasz Langa]

> On Apr 23, 2015, at 10:51 AM, Barry Warsaw  wrote:
> 
> (I have mild concerns about __a*__ magic methods, since I think they'll be
> harder to visually separate, but here the PEP does describe the __async_*__
> alternatives.)

Has it been historically a problem with __iadd__ vs __radd__ vs __add__, 
__ior__ vs __ror__ vs __or__, etc.?

-- 
Best regards,
Łukasz Langa

WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev
___
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 3152 and yield from Future()

[Victor Stinner]

Hi,

2015-04-23 17:54 GMT+02:00 Yury Selivanov :
> Greg wants to implement __cocall__ on futures.  This way
> you'll be able to write
>
>cocall fut()  # instead of "await fut"

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. So a __cocall__() *can* use yield and yield from. But to
use cocall, it must be a cofunction.

It's not easy to understand the whole puzzle. IMO the PEP 492 better
explains how pieces are put together ;-)

Victor
___
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 3152 and yield from Future()

[Greg Ewing]

Victor Stinner wrote:

I'm still trying to understand how the PEP 3152 would impact asyncio.
Guido suggests to replace "yield from fut" with "cocall fut()" (add
parenthesis) and so add a __cocall__() method to asyncio.Future.
Problem: PEP 3152 says "A cofunction (...) does not contain any yield
or yield from expressions".


A __cocall__ method doesn't have to be implemented with
a cofunction. Any method that returns an iterator will
do, including a generator. So a Future.__cocall__ that
just invokes Future.__iter__ should work fine.


How is it possible to suspend a cofunction if it's not possible to use yield?


The currently published version of PEP 3152 is not
really complete. A few things would need to be added
to it, one of them being a suspend() builtin that
has the same effect as yield in a generator-based
coroutine.

--
Greg
___
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] Type hints -- a mediocre programmer's reaction

[Chris Barker]

On Wed, Apr 22, 2015 at 5:45 PM, Guido van Rossum  wrote:

> Given that even if Difference existed, and even if we had a predefined
> type alias for Difference[Iterable[str], str], you' still have to remember
> to mark up all those functions with that annotation. It almost sounds
> simpler to just predefine this function:
>
> def make_string_list(a: Union[str, Iterable[str]]) -> Iterable[str]:
> if isinstance(a, str):
> return [a]
> else:
> return a
>

fair enough -- and I do indeed have that code in various places already.

Somehow, I've always been uncomfortable with checking specifically for the
str type -- guess I want everything to be fully duck-typable.

But then I wouldn't be doing type hints, either, would I?

-Chris
-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] async/await in Python; v2

[Greg Ewing]

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 to
make it work seamlessly with PEP 492 as well, since
an object needs to have either a special flag or
an __await__ method before it can have 'await'
applied to it.

--
Greg
___
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 3152 and yield from Future()

[Greg Ewing]

andrew.svet...@gmail.com wrote:
I can live with `cocall fut()` but the difference between `data = yield 
from loop.sock_recv(sock, 1024)` and `data = cocall 
(loop.sock_recv(sock, 1024))()` frustrates me very much.


That's not the way it would be done. In a PEP-3152-ified
version of asyncio, sock_recv would be a cofunction, so
that would be just

   data = cocall loop.sock_recv(sock, 1024)

--
Greg
___
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 3152 and yield from Future()

[Greg Ewing]

Victor Stinner wrote:


You didn't answer to my question. My question is: is it possible to
implement Future.__cocall__() since yield is defined in cofunctions.
If it's possible, can you please show how? (Show me the code!)


The implementation of a __cocall__ method is *not* a
cofunction, it's an *ordinary* function that returns
an iterator. In the case of Future, what it needs to
do is identical to Future.__iter__. So the code can
be just

def __cocall__(self):
return iter(self)

or equivalent.

--
Greg
___
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 3152 and yield from Future()

[Greg Ewing]

Yury Selivanov wrote:

Another problem is functions that return future:

def do_something():
...
return fut

With Greg's idea to call it you would do:

   cocall (do_something())()

That means that you can't refactor your "do_something"
function and make it a coroutine.


There's no fundamental problem with a cofunction
returning another cofunction:

codef do_something():
   return fut

f = cocall do_something()
result = cocall f()

Combining those last two lines into one would
require some extra parenthesisation, but I don't
think that's something you're going to be doing
much in practice. If you're just going to
immediately call the result, there's no point
in returning a future -- just do it all in
do_something().

--
Greg
___
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 3152 and yield from Future()

[Yury Selivanov]

On 2015-04-23 9:05 PM, Greg Ewing wrote:

Combining those last two lines into one would
require some extra parenthesisation, but I don't
think that's something you're going to be doing
much in practice.


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.

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] async/await in Python; v2

[Stephen J. Turnbull]

Yury Selivanov writes:

 > To my eye 'async def name()', 'async with', 'async for' look
 > better than 'def async name()', 'with async' and 'for async'.
 > But that's highly subjective.

I'm with Barry on this one as far as looks go.  (But count that as a
+0, since I'm just a literary critic, I don't use coroutines in anger
at present.)

 > 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.

Again, count as a +0.  FWIW, etc.

___
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] Type hints -- a mediocre programmer's reaction

[Steven D'Aprano]

On Thu, Apr 23, 2015 at 03:25:30PM +0100, Harry Percival wrote:
> lol @ the fact that the type hints are breaking github's syntax highlighter
> :)

That just tells us that Github's syntax highlighter has been broken for 
over five years. Function annotations go back to Python 3.0, more than 
five years ago. The only thing which is new about type hinting is that 
we're adding a standard *use* for those annotations.

I just tested a version of kwrite from 2005, ten years old, and it 
highlights the following annotated function perfectly:

def func(a:str='hello', b:int=int(x+1)) -> None:
print(a + b)


Of course, I'm hoping that any decent type checker won't need the type 
hints. It should be able to infer from the default values that a is a 
string and b an int, and only require a type hint if you want to accept 
other types as well.

(It should also highlight that a+b cannot succeed.)


-- 
Steve
___
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