Re: [Python-ideas] Bytecode JIT

[Chris Angelico]

On Sun, Jul 2, 2017 at 3:41 PM, Steven D'Aprano  wrote:
>> Let's say that you do. Given how short it is, it would just get inlined.
>> Your call of mysum ("a", "b") would indeed not use IADD, nor would it be
>> a call. It would potentially not invoke any operators, but instead get
>> replaced with "ab".
>
> What you are describing sounds more like the output of a keyhole
> optimizer that folds constants, only extended to look inside functions.
> I expect that it would have to be a VERY clever optimizer, since it
> would have to do a complete whole-of-program static analysis to be sure
> that mysum has not been replaced, shadowed or redefined by the time it
> is called.
>
> I won't say that is outright impossible, but it would be *extremely*
> hard to do something like that at compile time.

Isn't that the sort of thing that the "versioned globals dictionary"
was supposed to do? If your globals haven't changed, you know that the
optimizer was correct.

But that's still a hard problem. Or at very least, it's decidedly
non-trivial, and the costs are significant, so the net benefits aren't
proven.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Bytecode JIT

[Steven D'Aprano]

On Sat, Jul 01, 2017 at 07:52:55PM -0300, Soni L. wrote:
> 
> 
> On 2017-07-01 07:34 PM, Victor Stinner wrote:
> >Let's say that you have a function "def mysum (x; y): return x+y", do 
> >you always want to use your new IADD instruction here? What if I call 
> >mysum ("a", "b")?
> >
> >Victor
> 
> Let's say that you do. Given how short it is, it would just get inlined. 
> Your call of mysum ("a", "b") would indeed not use IADD, nor would it be 
> a call. It would potentially not invoke any operators, but instead get 
> replaced with "ab".

What you are describing sounds more like the output of a keyhole 
optimizer that folds constants, only extended to look inside functions. 
I expect that it would have to be a VERY clever optimizer, since it 
would have to do a complete whole-of-program static analysis to be sure 
that mysum has not been replaced, shadowed or redefined by the time it 
is called.

I won't say that is outright impossible, but it would be *extremely* 
hard to do something like that at compile time.

 
> When you have a tracing JIT, you can do away with a lot of overhead. You 
> can inline functions, variables, do away with typechecks, and many other 
> things. This holds true even if that JIT never emits a single byte of 
> machine code.

What you are describing sounds more like an "Ahead Of Time" (AOT) 
compiler to me. Especially the part about doing away with typechecks. As 
far as I know you can really only do away with typechecks or other 
guards if you know ahead of time (at compile time) what the types of 
values are, and that requires static typing.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Bytecode JIT

[Soni L.]

On 2017-07-01 11:57 PM, rym...@gmail.com wrote:
This is literally PyPy. There's little reason for something like this 
to end up in official CPython, at least for now.


It's literally not PyPy. PyPy's internal bytecode, for one, does have 
typechecks. And PyPy emits machine code, which is not something I wanna 
deal with because you shouldn't need to write a C compiler AND a whole 
assembly backend just to port python to a new CPU architecture. A C 
compiler should be enough.





--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
http://refi64.com
On Jul 1, 2017 at 5:53 PM, mailto:fakedme...@gmail.com>> 
wrote:




On 2017-07-01 07:34 PM, Victor Stinner wrote:

> Let's say that you have a function "def mysum (x; y): return x+y", do  

> you always want to use your new IADD instruction here? What if I call  


> mysum ("a", "b")?

>

> Victor



Let's say that you do. Given how short it is, it would just get inlined.

Your call of mysum ("a", "b") would indeed not use IADD, nor would it be

a call. It would potentially not invoke any operators, but instead get

replaced with "ab".



When you have a tracing JIT, you can do away with a lot of overhead. You

can inline functions, variables, do away with typechecks, and many other

things. This holds true even if that JIT never emits a single byte of

machine code.

___

Python-ideas mailing list

Python-ideas@python.org 

https://mail.python.org/mailman/listinfo/python-ideas

Code of Conduct:http://python.org/psf/codeofconduct/



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Bytecode JIT

[rym...@gmail.com]

This is literally PyPy. There's little reason for something like this to
end up in official CPython, at least for now.


--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone
elsehttp://refi64.com

On Jul 1, 2017 at 5:53 PM, > wrote:



On 2017-07-01 07:34 PM, Victor Stinner wrote:
> Let's say that you have a function "def mysum (x; y): return x+y", do
> you always want to use your new IADD instruction here? What if I call
> mysum ("a", "b")?
>
> Victor

Let's say that you do. Given how short it is, it would just get inlined.
Your call of mysum ("a", "b") would indeed not use IADD, nor would it be
a call. It would potentially not invoke any operators, but instead get
replaced with "ab".

When you have a tracing JIT, you can do away with a lot of overhead. You
can inline functions, variables, do away with typechecks, and many other
things. This holds true even if that JIT never emits a single byte of
machine code.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Bytecode JIT

[Chris Angelico]

On Sun, Jul 2, 2017 at 8:52 AM, Soni L.  wrote:
> On 2017-07-01 07:34 PM, Victor Stinner wrote:
>>
>> Let's say that you have a function "def mysum (x; y): return x+y", do you
>> always want to use your new IADD instruction here? What if I call mysum
>> ("a", "b")?
>>
>> Victor
>
>
> Let's say that you do. Given how short it is, it would just get inlined.
> Your call of mysum ("a", "b") would indeed not use IADD, nor would it be a
> call. It would potentially not invoke any operators, but instead get
> replaced with "ab".
>
> When you have a tracing JIT, you can do away with a lot of overhead. You can
> inline functions, variables, do away with typechecks, and many other things.
> This holds true even if that JIT never emits a single byte of machine code.

Let's try a more complicated example.

# demo.py
def mysum(x, y):
return x + y

def do_stuff(a, b):
print(mysum("foo", "bar"))
print(mysum(5, 7))
print(mysum(a, 42))
print(mysum(b, "spam"))


What can you optimize here? Now let's look at a file that might call it:

# cruel.py
import demo

def nasty(x, y):
demo.mysum = random.choice([
lambda x, y: x + y,
lambda x, y: f"{x} + f{y}",
lambda x, y: "muahahaha",
])
return Ellipsis

demo.mysum = nasty
demo.do_stuff("what", "now?")

Unless you can prove that this doesn't happen, you can't really
optimize much of mysum away. That's where a tracing JIT compiler has
the advantage: it can notice *at run time* that you're not doing this
kind of thing, and in effect, forfeit the optimizations when you're
running your tests (since test suites are where this kind of
monkey-patching tends to happen).

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Bytecode JIT

[Soni L.]

On 2017-07-01 07:34 PM, Victor Stinner wrote:
Let's say that you have a function "def mysum (x; y): return x+y", do 
you always want to use your new IADD instruction here? What if I call 
mysum ("a", "b")?


Victor


Let's say that you do. Given how short it is, it would just get inlined. 
Your call of mysum ("a", "b") would indeed not use IADD, nor would it be 
a call. It would potentially not invoke any operators, but instead get 
replaced with "ab".


When you have a tracing JIT, you can do away with a lot of overhead. You 
can inline functions, variables, do away with typechecks, and many other 
things. This holds true even if that JIT never emits a single byte of 
machine code.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Bytecode JIT

[Victor Stinner]

Let's say that you have a function "def mysum (x; y): return x+y", do you
always want to use your new IADD instruction here? What if I call mysum
("a", "b")?

Victor
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] CPython should get...

[Paul Moore]

On 1 July 2017 at 18:35, Nick Timkovich  wrote:
> Devil's advocate: why prepare a patch and submit it if it is going to be
> dismissed out of hand. Trying to gauge support for the idea is a reasonable
> first-step.

That's perfectly OK, but it's important to phrase the email in a way
that makes that clear - "I'm considering putting together a PR for
Python to implement X. Does that sound like a good idea, or does
anyone have suggestions for potential issues I might consider? Also,
is there any prior work in this area that I should look into?"

"Python should have X" implies (a) that you are criticising the python
developers for missing that feature out, (b) that you consider your
position self-evident, and (c) that you expect someone to implement
it.

People have different ways of expressing themselves, so we should all
be prepared to allow some leeway in how people put their ideas across.
But the writer has some responsibility for the tone, too.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] CPython should get...

[Nick Timkovich]

On Sat, Jul 1, 2017 at 1:17 PM, Oleg Broytman  wrote:
>
>I think the sentence "Python should have  implement feature>" should be ;-) forbidden if it is not followed with
> "I'm in the middle of development. Expect the 1st PR in  timeframe>."
>
>Python can only have features that You, the , implemented (or
> paid for) and submitted.
>

Devil's advocate: why prepare a patch and submit it if it is going to be
dismissed out of hand. Trying to gauge support for the idea is a reasonable
first-step.

Devil's devil's advocate: if it has value, it could stand on it's own and
gain it's own group of supporters as a CPython fork.

Nick
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] CPython should get...

[Oleg Broytman]

Hi, All!

On Sat, Jul 01, 2017 at 04:22:31PM +, Brett Cannon  wrote:
> On Fri, Jun 30, 2017, 10:38 Koos Zevenhoven,  wrote:
> > On Jun 30, 2017 5:16 PM, "Oleg Broytman"  wrote:
> >
> > On Fri, Jun 30, 2017 at 12:09:52PM -0300, "Soni L." 
> > wrote:
> > > CPython should get a
> >
> >You're welcome to create one. Go on, send your pull requests!
> >
> > But if you are planning to do that, it is still a good idea to ask for
> > feedback here first. That will increase the chances of acceptance by a lot.
> > Also, it doesn't necessarily need to be your own idea :)
> 
> I think Oleg was more responding to the fact that Soni said "CPython
> should" do something. Phrasing it that way comes off as demanding instead

   Exactly!

> of just sharing an idea. Oleg tried to turn it around and point out that if
> Soni thinks this should happen then he should be ready to contribute the
> work to see it happen.

   I think the sentence "Python should have " should be ;-) forbidden if it is not followed with
"I'm in the middle of development. Expect the 1st PR in ."

   Python can only have features that You, the , implemented (or
paid for) and submitted.

> -brett
> 
> > -- Koos

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] CPython should get...

[Brett Cannon]

On Fri, Jun 30, 2017, 10:38 Koos Zevenhoven,  wrote:

> On Jun 30, 2017 5:16 PM, "Oleg Broytman"  wrote:
>
> On Fri, Jun 30, 2017 at 12:09:52PM -0300, "Soni L." 
> wrote:
> > CPython should get a
>
>You're welcome to create one. Go on, send your pull requests!
>
>
> But if you are planning to do that, it is still a good idea to ask for
> feedback here first. That will increase the chances of acceptance by a lot.
> Also, it doesn't necessarily need to be your own idea :)
>

I think Oleg was more responding to the fact that Soni said "CPython
should" do something. Phrasing it that way comes off as demanding instead
of just sharing an idea. Oleg tried to turn it around and point out that if
Soni thinks this should happen then he should be ready to contribute the
work to see it happen.

-brett


> -- Koos
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] + operator on generators

[Wes Turner]

On Saturday, July 1, 2017, Steven D'Aprano  wrote:

> On Sat, Jul 01, 2017 at 01:35:29AM -0500, Wes Turner wrote:
> > On Saturday, July 1, 2017, Steven D'Aprano  > wrote:
> >
> > > On Fri, Jun 30, 2017 at 01:09:51AM +0200, Jan Kaliszewski wrote:
> > >
> > > [...]
> > >
> > > But the more I think about it the more I agree with Nick. Let's start
> > > by moving itertools.chain into built-ins, with zip and map, and only
> > > consider giving it an operator after we've had a few years of
> experience
> > > with chain as a built-in. We might even find that an operator doesn't
> > > add any real value.
> >
> >
> > - Would that include chain.from_iterable?
>
> Yes.
>
> > - So there's then a new conditional import (e.g. in a compat package)?
> What
> > does this add?
>
> try:  chain
> except NameError:  from itertools import chain
>
> Two lines, if and only if you both need chain and want to support
> versions of Python older than 3.7.
>
> There's no need to import it if you aren't going to use it.


Or, can I just continue to import the same function from the same place:

  from itertools import chain

Nice, simple, easy. There's even (for all you functional lovers):

  from itertools import *

And, again, this works today:

  from fn import Stream
  itr = Stream() << my_generator() << (8,9,0)

-
https://github.com/kachayev/fn.py/blob/master/README.rst#streams-and-infinite-sequences-declaration
  - https://github.com/kachayev/fn.py/blob/master/fn/stream.py

- AFAIU, + doesn't work because e.g. numpy already defines + and & for
Iterable arrays.


>
>
> > > > ¹ Preferably using the existing `yield from` mechanism -- because, in
> > > > case of generators, it would provide a way to combine ("concatenate")
> > > > *generators*, preserving semantics of all that their __next__(),
> send(),
> > > > throw() nice stuff...
> > >
> > > I don't think that would be generally useful.
> >
> > Flatten one level?
>
> Flattening typically applies to lists and sequences.
>
> I'm not saying that chain shouldn't support generators. That would be
> silly: a generator is an iterable and chaining supports iterables. I'm
> saying that it wouldn't be helpful to require chain objects to support
> send(), throw() etc.


So the argspec is/shouldbe Iterables with __iter__ (but not necessarily
__len__)?


>
> > > If you're sending values
> > > into an arbitrary generator, who knows what you're getting? chain()
> will
> > > operate on arbitrary iterables, you can't expect to send values into
> > > chain([1, 2, 3], my_generator(), "xyz") and have anything sensible
> > > occur.
> >
> >
> > - is my_generator() mutable (e.g. before or during iteration)?
>
> It doesn't matter. Sending into a chain of arbitrary iterators isn't a
> useful thing to do.


So, with a generator function, I get a traceback at the current yield
statement. With chain() I get whatever line the chain call is on.


>
>
> > - https://docs.python.org/2/reference/expressions.html#generator.send
>
> Why are you linking to the 2 version of the docs? We're discusing a
> hypotheticial new feature which must go into 3, not 2.


In your opinion, has the send() functionality changed at all?


>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org 
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] + operator on generators

[Paul Moore]

On 1 July 2017 at 07:13, Steven D'Aprano  wrote:
> But the more I think about it the more I agree with Nick. Let's start
> by moving itertools.chain into built-ins, with zip and map, and only
> consider giving it an operator after we've had a few years of experience
> with chain as a built-in. We might even find that an operator doesn't
> add any real value.

I'm struck here by the contrast between this and the "let's slim down
the stdlib" debates we've had in the past.

How difficult is it really to add "from itertools import chain" at the
start of a file? It's not even as if itertools is a 3rd party
dependency.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] + operator on generators

[Chris Angelico]

On Sat, Jul 1, 2017 at 6:11 PM, Steven D'Aprano  wrote:
>> - So there's then a new conditional import (e.g. in a compat package)? What
>> does this add?
>
> try:  chain
> except NameError:  from itertools import chain
>
> Two lines, if and only if you both need chain and want to support
> versions of Python older than 3.7.
>
> There's no need to import it if you aren't going to use it.
>

It'd be even simpler. If you want to support <3.7 and 3.7+, you write:

from itertools import chain

At least, I presume it isn't going to be *removed* from itertools.
Promotion to builtin shouldn't break pre-existing code, so the way to
be compatible with pre-promotion Pythons is simply to code for those
and not take advantage of the new builtin.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] + operator on generators

[Steven D'Aprano]

On Sat, Jul 01, 2017 at 01:35:29AM -0500, Wes Turner wrote:
> On Saturday, July 1, 2017, Steven D'Aprano  wrote:
> 
> > On Fri, Jun 30, 2017 at 01:09:51AM +0200, Jan Kaliszewski wrote:
> >
> > [...]
> >
> > But the more I think about it the more I agree with Nick. Let's start
> > by moving itertools.chain into built-ins, with zip and map, and only
> > consider giving it an operator after we've had a few years of experience
> > with chain as a built-in. We might even find that an operator doesn't
> > add any real value.
> 
> 
> - Would that include chain.from_iterable?

Yes.

> - So there's then a new conditional import (e.g. in a compat package)? What
> does this add?

try:  chain
except NameError:  from itertools import chain

Two lines, if and only if you both need chain and want to support 
versions of Python older than 3.7.

There's no need to import it if you aren't going to use it.


> > > ¹ Preferably using the existing `yield from` mechanism -- because, in
> > > case of generators, it would provide a way to combine ("concatenate")
> > > *generators*, preserving semantics of all that their __next__(), send(),
> > > throw() nice stuff...
> >
> > I don't think that would be generally useful.
> 
> Flatten one level?

Flattening typically applies to lists and sequences.

I'm not saying that chain shouldn't support generators. That would be 
silly: a generator is an iterable and chaining supports iterables. I'm 
saying that it wouldn't be helpful to require chain objects to support 
send(), throw() etc.

> > If you're sending values
> > into an arbitrary generator, who knows what you're getting? chain() will
> > operate on arbitrary iterables, you can't expect to send values into
> > chain([1, 2, 3], my_generator(), "xyz") and have anything sensible
> > occur.
> 
> 
> - is my_generator() mutable (e.g. before or during iteration)?

It doesn't matter. Sending into a chain of arbitrary iterators isn't a 
useful thing to do.


> - https://docs.python.org/2/reference/expressions.html#generator.send

Why are you linking to the 2 version of the docs? We're discusing a 
hypotheticial new feature which must go into 3, not 2.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] + operator on generators

[Wes Turner]

On Saturday, July 1, 2017, Steven D'Aprano  wrote:

> On Fri, Jun 30, 2017 at 01:09:51AM +0200, Jan Kaliszewski wrote:
>
> [...]
>
> But the more I think about it the more I agree with Nick. Let's start
> by moving itertools.chain into built-ins, with zip and map, and only
> consider giving it an operator after we've had a few years of experience
> with chain as a built-in. We might even find that an operator doesn't
> add any real value.


- Would that include chain.from_iterable?
- So there's then a new conditional import (e.g. in a compat package)? What
does this add?


>
> > ¹ Preferably using the existing `yield from` mechanism -- because, in
> > case of generators, it would provide a way to combine ("concatenate")
> > *generators*, preserving semantics of all that their __next__(), send(),
> > throw() nice stuff...
>
> I don't think that would be generally useful.


Flatten one level?


>
> If you're sending values
> into an arbitrary generator, who knows what you're getting? chain() will
> operate on arbitrary iterables, you can't expect to send values into
> chain([1, 2, 3], my_generator(), "xyz") and have anything sensible
> occur.


- is my_generator() mutable (e.g. before or during iteration)?

- https://docs.python.org/2/reference/expressions.html#generator.send
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] + operator on generators

[Steven D'Aprano]

On Fri, Jun 30, 2017 at 01:09:51AM +0200, Jan Kaliszewski wrote:

> But implementation of the OP's proposal does not need to be based on
> __add__ at all.  It could be based on extending the current behaviour of
> the `+` operator itself.
> 
> Now this behavior is (roughly): try left side's __add__, if failed try
> right side's __radd__, if failed raise TypeError.
> 
> New behavior could be (again: roughly): try left side's __add__, if
> failed try right side's __radd__, if failed try __iter__ of both sides
> and chain them (creating a new iterator¹), if failed raise TypeError.

That's what I suggested earlier, except using & instead of + as the 
operator.

The reason I suggested & instead of + is that there will be fewer 
clashes between iterables that already support the operator and hence 
fewer surprises.

Using + will be a bug magnet. Consider:


it = x + y  # chain two iterables
first = next(it, "default")


That code looks pretty safe, but it's actually a minefield waiting to 
blow you up. It works fine if you pass (let's say) a generator object 
and a string, or a list and an iterator, but if x and y happen to both 
be strings, or both lists, or both tuples, the + operator will 
concatenate them instead of chaining them, and the call to next will 
blow up.

So you would have to write:

it = iter(x + y)  # chain two iterables, and ensure the result is an iterator

to be sure. Which is not a huge burden, but it does take away the 
benefit of having an operator. In that case, you might as well do:

it = chain(x, y)

and be done with it.

It's true that exactly the same potential problem occurs with & but its 
less likely. Strings, tuples, lists and other sequences don't typically 
support __(r)and__ and the & operator, so you're less likely to be 
burned. Still, the possibility is there. Maybe we should use a different 
operator. ++ is out because that already has meaning, so that leaves 
either && or inventing some arbitrary symbol.

But the more I think about it the more I agree with Nick. Let's start 
by moving itertools.chain into built-ins, with zip and map, and only 
consider giving it an operator after we've had a few years of experience 
with chain as a built-in. We might even find that an operator doesn't 
add any real value.



> ¹ Preferably using the existing `yield from` mechanism -- because, in
> case of generators, it would provide a way to combine ("concatenate")
> *generators*, preserving semantics of all that their __next__(), send(),
> throw() nice stuff...

I don't think that would be generally useful. If you're sending values 
into an arbitrary generator, who knows what you're getting? chain() will 
operate on arbitrary iterables, you can't expect to send values into 
chain([1, 2, 3], my_generator(), "xyz") and have anything sensible 
occur.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/