Re: [Python-Dev] cpython: Mirco-optimizations to reduce register spills and reloads observed on CLANG and

[Serhiy Storchaka]

On 09.02.15 14:48, raymond.hettinger wrote:

https://hg.python.org/cpython/rev/dc820b44ce21
changeset:   94572:dc820b44ce21
user:Raymond Hettinger 
date:Mon Feb 09 06:48:29 2015 -0600
summary:
   Mirco-optimizations to reduce register spills and reloads observed on CLANG 
and GCC.

files:
   Objects/setobject.c |  6 --
   1 files changed, 4 insertions(+), 2 deletions(-)


diff --git a/Objects/setobject.c b/Objects/setobject.c
--- a/Objects/setobject.c
+++ b/Objects/setobject.c
@@ -84,8 +84,9 @@
  return set_lookkey(so, key, hash);
  if (cmp > 0)  /* likely */
  return entry;
+mask = so->mask; /* help avoid a register spill */


Could you please explain in more details what this line do? The mask 
variable is actually constant and so->mask isn't changed in this loop.



___
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] (no subject)

[Neil Girdhar]

Hello all,

The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
implemented now based on some early work by Thomas Wouters (in 2008) and
Florian Hahn (2013) and recently completed by Joshua Landau and me.

The issue tracker http://bugs.python.org/issue2292  has  a working patch.
Would someone be able to review it?

Thank you very much,

Neil
___
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] (no subject)

[Benjamin Peterson]

On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote:
> Hello all,
> 
> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
> implemented now based on some early work by Thomas Wouters (in 2008) and
> Florian Hahn (2013) and recently completed by Joshua Landau and me.
> 
> The issue tracker http://bugs.python.org/issue2292  has  a working patch.
> Would someone be able to review it?

The PEP is not even accepted.
___
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] (no subject)

[Guido van Rossum]

FWIW, I've encouraged Neil and others to complete this code as a
prerequisite for a code review (but I can't review it myself). I am mildly
in favor of the PEP -- if the code works and looks maintainable I would
accept it. (A few things got changed in the PEP as a result of the work.)

On Mon, Feb 9, 2015 at 1:28 PM, Benjamin Peterson 
wrote:

>
>
> On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote:
> > Hello all,
> >
> > The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
> > implemented now based on some early work by Thomas Wouters (in 2008) and
> > Florian Hahn (2013) and recently completed by Joshua Landau and me.
> >
> > The issue tracker http://bugs.python.org/issue2292  has  a working
> patch.
> > Would someone be able to review it?
>
> The PEP is not even accepted.
> ___
> 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] (no subject)

[Ethan Furman]

On 02/09/2015 01:28 PM, Benjamin Peterson wrote:
> On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote:
>>
>> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
>> implemented now based on some early work by Thomas Wouters (in 2008) and
>> Florian Hahn (2013) and recently completed by Joshua Landau and me.
>>
>> The issue tracker http://bugs.python.org/issue2292  has  a working patch.
>> Would someone be able to review it?
> 
> The PEP is not even accepted.

I believe somebody (Guido?) commented "Why worry about accepting the PEP when 
there's no working patch?"  -- or
something to that effect.

--
~Ethan~



signature.asc
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] (no subject)

[Benjamin Peterson]

On Mon, Feb 9, 2015, at 16:32, Guido van Rossum wrote:
> FWIW, I've encouraged Neil and others to complete this code as a
> prerequisite for a code review (but I can't review it myself). I am
> mildly
> in favor of the PEP -- if the code works and looks maintainable I would
> accept it. (A few things got changed in the PEP as a result of the work.)

In a way, it's a simplification, since functions are now simply called
with a sequence of "generalized arguments"; there's no privileged kwarg
or vararg. Of course, I wonder how much of f(**w, x, y, *k, *b, **d, c)
we would see...
___
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] (no subject)

[Benjamin Peterson]

On Mon, Feb 9, 2015, at 16:34, Ethan Furman wrote:
> On 02/09/2015 01:28 PM, Benjamin Peterson wrote:
> > On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote:
> >>
> >> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
> >> implemented now based on some early work by Thomas Wouters (in 2008) and
> >> Florian Hahn (2013) and recently completed by Joshua Landau and me.
> >>
> >> The issue tracker http://bugs.python.org/issue2292  has  a working patch.
> >> Would someone be able to review it?
> > 
> > The PEP is not even accepted.
> 
> I believe somebody (Guido?) commented "Why worry about accepting the PEP
> when there's no working patch?"  -- or
> something to that effect.

On the other hand, I'd rather not do detailed reviews of patches that
won't be accepted. :)
___
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] (no subject)

[Nick Coghlan]

On 10 Feb 2015 08:13, "Benjamin Peterson"  wrote:
>
>
>
> On Mon, Feb 9, 2015, at 16:34, Ethan Furman wrote:
> > On 02/09/2015 01:28 PM, Benjamin Peterson wrote:
> > > On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote:
> > >>
> > >> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
> > >> implemented now based on some early work by Thomas Wouters (in 2008)
and
> > >> Florian Hahn (2013) and recently completed by Joshua Landau and me.
> > >>
> > >> The issue tracker http://bugs.python.org/issue2292  has  a working
patch.
> > >> Would someone be able to review it?
> > >
> > > The PEP is not even accepted.
> >
> > I believe somebody (Guido?) commented "Why worry about accepting the PEP
> > when there's no working patch?"  -- or
> > something to that effect.
>
> On the other hand, I'd rather not do detailed reviews of patches that
> won't be accepted. :)

It's more a matter of the PEP being acceptable in principle, but a
reference implementation being needed to confirm feasibility and to iron
out corner cases.

For example, the potential for arcane call arguments suggests the need for
a PEP 8 addition saying "first standalone args, then iterable expansions,
then mapping expansions", even though syntactically any order would now be
permitted at call time.

Cheers,
Nick.

> ___
> 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/ncoghlan%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] (no subject)

[Neil Girdhar]

Right,

Just to be clear though:  **-args must follow any *-args and position
arguments.  So at worst, your example is:

f(x, y, *k, *b, c,  **w, **d)

Best,

Neil

On Mon, Feb 9, 2015 at 5:10 PM, Benjamin Peterson 
wrote:

>
>
> On Mon, Feb 9, 2015, at 16:32, Guido van Rossum wrote:
> > FWIW, I've encouraged Neil and others to complete this code as a
> > prerequisite for a code review (but I can't review it myself). I am
> > mildly
> > in favor of the PEP -- if the code works and looks maintainable I would
> > accept it. (A few things got changed in the PEP as a result of the work.)
>
> In a way, it's a simplification, since functions are now simply called
> with a sequence of "generalized arguments"; there's no privileged kwarg
> or vararg. Of course, I wonder how much of f(**w, x, y, *k, *b, **d, c)
> we would see...
>
___
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] (no subject)

[Antoine Pitrou]

On Tue, 10 Feb 2015 08:43:53 +1000
Nick Coghlan  wrote:
> 
> For example, the potential for arcane call arguments suggests the need for
> a PEP 8 addition saying "first standalone args, then iterable expansions,
> then mapping expansions", even though syntactically any order would now be
> permitted at call time.

There are other concerns:

- inspect.signature() must be updated to cover the new call
  possibilities

- function call performance must not be crippled by the new
  possibilities

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] (no subject)

[Benjamin Peterson]

On Mon, Feb 9, 2015, at 17:12, Neil Girdhar wrote:
> Right,
> 
> Just to be clear though:  **-args must follow any *-args and position
> arguments.  So at worst, your example is:
> 
> f(x, y, *k, *b, c,  **w, **d)
> 
> Best,

Ah, I guess I was confused by this sentence in the PEP: " Function calls
currently have the restriction that keyword arguments must follow
positional arguments and ** unpackings must additionally follow *
unpackings."

That suggests that that rule is going to change.
___
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] (no subject)

[Neil Girdhar]

That wording is my fault.  I'll update the PEP to remove the word
"currently" after waiting a bit to see if there are any other problems.

Best,

Neil

On Mon, Feb 9, 2015 at 6:16 PM, Benjamin Peterson 
wrote:

>
>
> On Mon, Feb 9, 2015, at 17:12, Neil Girdhar wrote:
> > Right,
> >
> > Just to be clear though:  **-args must follow any *-args and position
> > arguments.  So at worst, your example is:
> >
> > f(x, y, *k, *b, c,  **w, **d)
> >
> > Best,
>
> Ah, I guess I was confused by this sentence in the PEP: " Function calls
> currently have the restriction that keyword arguments must follow
> positional arguments and ** unpackings must additionally follow *
> unpackings."
>
> That suggests that that rule is going to change.
>
___
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] (no subject)

[Victor Stinner]

Hi,

2015-02-09 22:06 GMT+01:00 Neil Girdhar :
> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
> implemented now based on some early work by Thomas Wouters (in 2008) and
> Florian Hahn (2013) and recently completed by Joshua Landau and me.

I don't like this PEP. IMO it makes the Python syntax more complex and
more difficult to read.

Extract of the PEP:
> Current usage of the * iterable unpacking operator features unnecessary 
> restrictions that can harm readability.

Yes, the current syntax is more verbose, but it's simpler to
understand and simpler to debug.

--

Example:

>>> ranges = [range(i) for i in range(5)]
>>> [*item for item in ranges]
[0, 0, 1, 0, 1, 2, 0, 1, 2, 3]

I don't understand this code.

It looks like you forgot something before *item, I would expect 2*item
for example.

If it's really to unpack something, I still don't understand the
syntax. Does "*" apply to item or to the whole "item for item in
ranges"? It's not clear to me. If it applies to the whole generator,
the syntax is really strange and I would expect parenthesis: [*(item
for item in ranges)].

--

> function(**kw_arguments, **more_arguments)

If the key "key1" is in both dictionaries, more_arguments wins, right?


I never suffered of the lack of the PEP 448. But I remember that a
friend learning Python asked me that * and ** are limited to
functions. I had no answer. The answer is maybe to keep the language
simple? :-)

I should maybe read the PEP one more time and think about it.

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] (no subject) PEP 448

[Antoine Pitrou]

On Mon, 9 Feb 2015 16:06:20 -0500
Neil Girdhar  wrote:
> Hello all,
> 
> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
> implemented now based on some early work by Thomas Wouters (in 2008) and
> Florian Hahn (2013) and recently completed by Joshua Landau and me.

To be clear, the PEP will probably be useful for one single line of
Python code every 1. This is a very weak case for such an intrusive
syntax addition. I would support the PEP if it only added the simple
cases of tuple unpacking, left alone function call conventions, and
didn't introduce **-unpacking.

Barring that, I really don't want to review the patch and I'm a rather
decided -1 on the current PEP.

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] (no subject) PEP 448

[Victor Stinner]

2015-02-10 0:51 GMT+01:00 Antoine Pitrou :
>> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
>> implemented now based on some early work by Thomas Wouters (in 2008) and
>> Florian Hahn (2013) and recently completed by Joshua Landau and me.
>
> To be clear, the PEP will probably be useful for one single line of
> Python code every 1.

@Neil: Can you maybe show us some examples of usage of the PEP 448 in
the Python stdlib? I mean find some functions where using the PEP
would be useful and show the code before/after (maybe in a code
review). It would help to get a better opinion on the PEP. I'm not
sure that examples in the PEP are the most revelant.

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] (no subject)

[Donald Stufft]

> On Feb 9, 2015, at 4:06 PM, Neil Girdhar  wrote:
> 
> Hello all,
> 
> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/ 
> ) is implemented now based on some 
> early work by Thomas Wouters (in 2008) and Florian Hahn (2013) and recently 
> completed by Joshua Landau and me.
> 
> The issue tracker http://bugs.python.org/issue2292 
>   has  a working patch.  Would someone be 
> able to review it?
> 

I just skimmed over the PEP and it seems like it’s trying to solve a few 
different things:

* Making it easy to combine multiple lists and additional positional args into 
a function call
* Making it easy to combine multiple dicts and additional keyword args into a 
functional call
* Making it easy to do a single level of nested iterable "flatten".

Looking at the syntax in the PEP I had a hard time detangling what exactly it 
was doing even with reading the PEP itself. I wonder if there isn’t a way to 
combine simpler more generic things to get the same outcome.

Looking at the "Making it easy to combine multiple lists and additional 
positional args into a  function call" aspect of this, why is:

print(*[1], *[2], 3) better than print(*[1] + [2] + [3])?

That's already doable in Python right now and doesn't require anything new to 
handle it.

Looking at the "making it easy to do a single level of nsted iterable 
'flatten'"" aspect of this, the example of:

>>> ranges = [range(i) for i in range(5)]
>>> [*item for item in ranges]
[0, 0, 1, 0, 1, 2, 0, 1, 2, 3]

Conceptually a list comprehension like [thing for item in iterable] can be 
mapped to a for loop like this:

result = []
for item in iterable:
result.append(thing)

However [*item for item in ranges] is mapped more to something like this:

result = []
for item in iterable:
result.extend(*item)

I feel like switching list comprehensions from append to extend just because of 
a * is really confusing and it acts differently than if you just did *item 
outside of a list comprehension. I feel like the itertools.chain() way of doing 
this is *much* clearer.

Finally there's the "make it easy to combine multiple dicts into a function 
call" aspect of this. This I think is the biggest thing that this PEP actually 
adds, however I think it goes around it the wrong way. Sadly there is nothing 
like [1] + [2] for dictionaries. The closest thing is:

kwargs = dict1.copy()
kwargs.update(dict2)
func(**kwargs)

So what I wonder is if this PEP wouldn't be better off just using the existing 
methods for doing the kinds of things that I pointed out above, and instead 
defining + or | or some other symbol for something similar to [1] + [2] but for 
dictionaries. This would mean that you could simply do:

func(**dict1 | dict(y=1) | dict2)

instead of

dict(**{'x': 1}, y=2, **{'z': 3})

I feel like not only does this genericize way better but it limits the impact 
and new syntax being added to Python and is a ton more readable.


---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
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] (no subject)

[Neil Girdhar]

For some reason I can't seem to reply using Google groups, which is is
telling "this is a read-only mirror" (anyone know why?)  Anyway, I'm going
to answer as best I can the concerns.

Antoine said:

To be clear, the PEP will probably be useful for one single line of
> Python code every 1. This is a very weak case for such an intrusive
> syntax addition. I would support the PEP if it only added the simple
> cases of tuple unpacking, left alone function call conventions, and
> didn't introduce **-unpacking.


To me this is more of a syntax simplification than a syntax addition.  For
me the **-unpacking is the most useful part. Regarding utility, it seems
that a many of the people on r/python were pretty excited about this PEP:
http://www.reddit.com/r/Python/comments/2synry/so_8_peps_are_currently_being_proposed_for_python/

—

Victor noticed that there's a mistake with the code:

>>> ranges = [range(i) for i in range(5)]
> >>> [*item for item in ranges]
> [0, 0, 1, 0, 1, 2, 0, 1, 2, 3]


It should be a range(4) in the code.  The "*" applies to only item.  It is
the same as writing:

[*range(0), *range(1), *range(2), *range(3), *range(4)]

which is the same as unpacking all of those ranges into a list.

> function(**kw_arguments, **more_arguments)
> If the key "key1" is in both dictionaries, more_arguments wins, right?


There was some debate and it was decided that duplicate keyword arguments
would remain an error (for now at least).  If you want to merge the
dictionaries with overriding, then you can still do:

function(**{**kw_arguments, **more_arguments})

because **-unpacking in dicts overrides as you guessed.

—



On Mon, Feb 9, 2015 at 7:12 PM, Donald Stufft  wrote:

>
> On Feb 9, 2015, at 4:06 PM, Neil Girdhar  wrote:
>
> Hello all,
>
> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
> implemented now based on some early work by Thomas Wouters (in 2008) and
> Florian Hahn (2013) and recently completed by Joshua Landau and me.
>
> The issue tracker http://bugs.python.org/issue2292  has  a working
> patch.  Would someone be able to review it?
>
>
> I just skimmed over the PEP and it seems like it’s trying to solve a few
> different things:
>
> * Making it easy to combine multiple lists and additional positional args
> into a function call
> * Making it easy to combine multiple dicts and additional keyword args
> into a functional call
> * Making it easy to do a single level of nested iterable "flatten".
>

I would say it's:
* making it easy to unpack iterables and mappings in function calls
* making it easy to unpack iterables  into list and set displays and
comprehensions, and
* making it easy to unpack mappings into dict displays and comprehensions.



>
> Looking at the syntax in the PEP I had a hard time detangling what exactly
> it was doing even with reading the PEP itself. I wonder if there isn’t a
> way to combine simpler more generic things to get the same outcome.
>
> Looking at the "Making it easy to combine multiple lists and additional
> positional args into a  function call" aspect of this, why is:
>
> print(*[1], *[2], 3) better than print(*[1] + [2] + [3])?
>
> That's already doable in Python right now and doesn't require anything new
> to handle it.
>

Admittedly, this wasn't a great example.  But, if [1] and [2] had been
iterables, you would have to cast each to list, e.g.,

accumulator = []
accumulator.extend(a)
accumulator.append(b)
accumulator.extend(c)
print(*accumulator)

replaces

print(*a, b, *c)

where a and c are iterable.  The latter version is also more efficient
because it unpacks only a onto the stack allocating no auxilliary list.


> Looking at the "making it easy to do a single level of nsted iterable
> 'flatten'"" aspect of this, the example of:
>
> >>> ranges = [range(i) for i in range(5)]
> >>> [*item for item in ranges]
> [0, 0, 1, 0, 1, 2, 0, 1, 2, 3]
>
> Conceptually a list comprehension like [thing for item in iterable] can be
> mapped to a for loop like this:
>
> result = []
> for item in iterable:
> result.append(thing)
>
> However [*item for item in ranges] is mapped more to something like this:
>
> result = []
> for item in iterable:
> result.extend(*item)
>
> I feel like switching list comprehensions from append to extend just
> because of a * is really confusing and it acts differently than if you just
> did *item outside of a list comprehension. I feel like the
> itertools.chain() way of doing this is *much* clearer.
>
> Finally there's the "make it easy to combine multiple dicts into a
> function call" aspect of this. This I think is the biggest thing that this
> PEP actually adds, however I think it goes around it the wrong way. Sadly
> there is nothing like [1] + [2] for dictionaries. The closest thing is:
>
> kwargs = dict1.copy()
> kwargs.update(dict2)
> func(**kwargs)
>
> So what I wonder is if this PEP wouldn't be better off just using the
> existing methods for doing the kinds of things that I pointed out above,
> a

Re: [Python-Dev] (no subject)

[Larry Hastings]

What's an example of a way inspect.signature must change?  I thought PEP 
448 added new unpacking shortcuts which (for example) change the 
*caller* side of a function call.  I didn't realize it impacted the 
*callee* side too.



//arry/

On 02/09/2015 03:14 PM, Antoine Pitrou wrote:

On Tue, 10 Feb 2015 08:43:53 +1000
Nick Coghlan  wrote:

For example, the potential for arcane call arguments suggests the need for
a PEP 8 addition saying "first standalone args, then iterable expansions,
then mapping expansions", even though syntactically any order would now be
permitted at call time.

There are other concerns:

- inspect.signature() must be updated to cover the new call
   possibilities

- function call performance must not be crippled by the new
   possibilities

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/larry%40hastings.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] (no subject)

[Neil Girdhar]

Yes, that's exactly right.  It does not affect the callee.

Regarding function call performance, nothing has changed for the originally
accepted argument lists: the opcodes generated are the same and they are
processed in the same way.

Also, regarding calling argument order, not any order is allowed.  Regular
arguments must precede other kinds of arguments.  Keyword arguments must
precede **-args.  *-args must precede **-args.   However, I agree with
Antoine that PEP 8 should be updated to suggest that *-args should precede
any keyword arguments.  It is currently allowed to write f(x=2, *args),
which is equivalent to f(*args, x=2).

Best,

Neil

On Mon, Feb 9, 2015 at 7:30 PM, Larry Hastings  wrote:

>
>
> What's an example of a way inspect.signature must change?  I thought PEP
> 448 added new unpacking shortcuts which (for example) change the *caller*
> side of a function call.  I didn't realize it impacted the *callee* side
> too.
>
>
> */arry*
>
> On 02/09/2015 03:14 PM, Antoine Pitrou wrote:
>
> On Tue, 10 Feb 2015 08:43:53 +1000
> Nick Coghlan   wrote:
>
>  For example, the potential for arcane call arguments suggests the need for
> a PEP 8 addition saying "first standalone args, then iterable expansions,
> then mapping expansions", even though syntactically any order would now be
> permitted at call time.
>
>  There are other concerns:
>
> - inspect.signature() must be updated to cover the new call
>   possibilities
>
> - function call performance must not be crippled by the new
>   possibilities
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing 
> listPython-Dev@python.orghttps://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/larry%40hastings.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/mistersheik%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] (no subject)

[Donald Stufft]

> On Feb 9, 2015, at 7:29 PM, Neil Girdhar  wrote:
> 
> For some reason I can't seem to reply using Google groups, which is is 
> telling "this is a read-only mirror" (anyone know why?)  Anyway, I'm going to 
> answer as best I can the concerns.
> 
> Antoine said:
> 
> To be clear, the PEP will probably be useful for one single line of 
> Python code every 1. This is a very weak case for such an intrusive 
> syntax addition. I would support the PEP if it only added the simple 
> cases of tuple unpacking, left alone function call conventions, and 
> didn't introduce **-unpacking. 
> 
> To me this is more of a syntax simplification than a syntax addition.  For me 
> the **-unpacking is the most useful part. Regarding utility, it seems that a 
> many of the people on r/python were pretty excited about this PEP: 
> http://www.reddit.com/r/Python/comments/2synry/so_8_peps_are_currently_being_proposed_for_python/
>  
> 
> 
> —
> 
> Victor noticed that there's a mistake with the code:
> 
> >>> ranges = [range(i) for i in range(5)] 
> >>> [*item for item in ranges] 
> [0, 0, 1, 0, 1, 2, 0, 1, 2, 3] 
> 
> It should be a range(4) in the code.  The "*" applies to only item.  It is 
> the same as writing:
> 
> [*range(0), *range(1), *range(2), *range(3), *range(4)]
> 
> which is the same as unpacking all of those ranges into a list.
> 
> > function(**kw_arguments, **more_arguments) 
> If the key "key1" is in both dictionaries, more_arguments wins, right? 
> 
> There was some debate and it was decided that duplicate keyword arguments 
> would remain an error (for now at least).  If you want to merge the 
> dictionaries with overriding, then you can still do:
> 
> function(**{**kw_arguments, **more_arguments})
> 
> because **-unpacking in dicts overrides as you guessed.
> 
> —
> 
> 
> 
> On Mon, Feb 9, 2015 at 7:12 PM, Donald Stufft  > wrote:
> 
>> On Feb 9, 2015, at 4:06 PM, Neil Girdhar > > wrote:
>> 
>> Hello all,
>> 
>> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/ 
>> ) is implemented now based on 
>> some early work by Thomas Wouters (in 2008) and Florian Hahn (2013) and 
>> recently completed by Joshua Landau and me.
>> 
>> The issue tracker http://bugs.python.org/issue2292 
>>   has  a working patch.  Would someone be 
>> able to review it?
>> 
> 
> I just skimmed over the PEP and it seems like it’s trying to solve a few 
> different things:
> 
> * Making it easy to combine multiple lists and additional positional args 
> into a function call
> * Making it easy to combine multiple dicts and additional keyword args into a 
> functional call
> * Making it easy to do a single level of nested iterable "flatten".
> 
> I would say it's:
> * making it easy to unpack iterables and mappings in function calls
> * making it easy to unpack iterables  into list and set displays and 
> comprehensions, and
> * making it easy to unpack mappings into dict displays and comprehensions.
> 
>  
> 
> Looking at the syntax in the PEP I had a hard time detangling what exactly it 
> was doing even with reading the PEP itself. I wonder if there isn’t a way to 
> combine simpler more generic things to get the same outcome.
> 
> Looking at the "Making it easy to combine multiple lists and additional 
> positional args into a  function call" aspect of this, why is:
> 
> print(*[1], *[2], 3) better than print(*[1] + [2] + [3])?
> 
> That's already doable in Python right now and doesn't require anything new to 
> handle it.
> 
> Admittedly, this wasn't a great example.  But, if [1] and [2] had been 
> iterables, you would have to cast each to list, e.g.,
> 
> accumulator = []
> accumulator.extend(a) 
> accumulator.append(b)
> accumulator.extend(c)
> print(*accumulator)
> 
> replaces
> 
> print(*a, b, *c)
> 
> where a and c are iterable.  The latter version is also more efficient 
> because it unpacks only a onto the stack allocating no auxilliary list.

Honestly that doesn’t seem like the way I’d write it at all, if they might not 
be lists I’d just cast them to lists:

print(*list(a) + [b] + list(c))

But if casting to list really is that big a deal, then perhaps a better 
solution is to simply make it so that something like ``a_list + an_iterable`` 
is valid and the iterable would just be consumed and +’d onto the list. That 
still feels like a more general solution and a far less surprising and easier 
to read one.


> 
> 
> Looking at the "making it easy to do a single level of nsted iterable 
> 'flatten'"" aspect of this, the example of:
> 
> >>> ranges = [range(i) for i in range(5)]
> >>> [*item for item in ranges]
> [0, 0, 1, 0, 1, 2, 0, 1, 2, 3]
> 
> Conceptually a list comprehension like [thing for item in iterable] can be 
> mapped to a for loop like this:
> 
> result = []
> for item 

Re: [Python-Dev] (no subject)

[Barry Warsaw]

On Feb 09, 2015, at 07:46 PM, Neil Girdhar wrote:

>Also, regarding calling argument order, not any order is allowed.  Regular
>arguments must precede other kinds of arguments.  Keyword arguments must
>precede **-args.  *-args must precede **-args.   However, I agree with
>Antoine that PEP 8 should be updated to suggest that *-args should precede
>any keyword arguments.  It is currently allowed to write f(x=2, *args),
>which is equivalent to f(*args, x=2).

But if we have to add a PEP 8 admonition against some syntax that's being
newly added, why is this an improvement?

I had some more snarky/funny comments to make, but I'll just say -1.  The
Rationale in the PEP doesn't sell me on it being an improvement to Python.

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] (no subject)

[Neil Girdhar]

The admonition is against syntax that currently exists.

On Mon, Feb 9, 2015 at 7:53 PM, Barry Warsaw  wrote:

> On Feb 09, 2015, at 07:46 PM, Neil Girdhar wrote:
>
> >Also, regarding calling argument order, not any order is allowed.  Regular
> >arguments must precede other kinds of arguments.  Keyword arguments must
> >precede **-args.  *-args must precede **-args.   However, I agree with
> >Antoine that PEP 8 should be updated to suggest that *-args should precede
> >any keyword arguments.  It is currently allowed to write f(x=2, *args),
> >which is equivalent to f(*args, x=2).
>
> But if we have to add a PEP 8 admonition against some syntax that's being
> newly added, why is this an improvement?
>
> I had some more snarky/funny comments to make, but I'll just say -1.  The
> Rationale in the PEP doesn't sell me on it being an improvement to Python.
>
> 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/mistersheik%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] (no subject)

[Neil Girdhar]

Just an FYI:
http://www.reddit.com/r/Python/comments/2v8g26/python_350_alpha_1_has_been_released/

448 was mentioned here (by Python lay people — not developers).

On Mon, Feb 9, 2015 at 7:56 PM, Neil Girdhar  wrote:

> The admonition is against syntax that currently exists.
>
> On Mon, Feb 9, 2015 at 7:53 PM, Barry Warsaw  wrote:
>
>> On Feb 09, 2015, at 07:46 PM, Neil Girdhar wrote:
>>
>> >Also, regarding calling argument order, not any order is allowed.
>> Regular
>> >arguments must precede other kinds of arguments.  Keyword arguments must
>> >precede **-args.  *-args must precede **-args.   However, I agree with
>> >Antoine that PEP 8 should be updated to suggest that *-args should
>> precede
>> >any keyword arguments.  It is currently allowed to write f(x=2, *args),
>> >which is equivalent to f(*args, x=2).
>>
>> But if we have to add a PEP 8 admonition against some syntax that's being
>> newly added, why is this an improvement?
>>
>> I had some more snarky/funny comments to make, but I'll just say -1.  The
>> Rationale in the PEP doesn't sell me on it being an improvement to Python.
>>
>> 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/mistersheik%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] (no subject)

[Victor Stinner]

2015-02-10 1:29 GMT+01:00 Neil Girdhar :
> For some reason I can't seem to reply using Google groups, which is is
> telling "this is a read-only mirror" (anyone know why?)  Anyway, I'm going
> to answer as best I can the concerns.
>
> Antoine said:
>
>> To be clear, the PEP will probably be useful for one single line of
>> Python code every 1. This is a very weak case for such an intrusive
>> syntax addition. I would support the PEP if it only added the simple
>> cases of tuple unpacking, left alone function call conventions, and
>> didn't introduce **-unpacking.
>
>
> To me this is more of a syntax simplification than a syntax addition.  For
> me the **-unpacking is the most useful part. Regarding utility, it seems
> that a many of the people on r/python were pretty excited about this PEP:
> http://www.reddit.com/r/Python/comments/2synry/so_8_peps_are_currently_being_proposed_for_python/

I used grep to find how many times dict.update() is used.

haypo@selma$ wc -l Lib/*.py
()
 112055 total
haypo@selma$ grep '\.update(.\+)' Lib/*.py|wc -l
63

So there are 63 or less (it's a regex, I didn't check each line) calls
to dict.update() on a total of 112,055 lines.

I found a few numbers of codes using the pattern:
"dict1.update(dict2); func(**dict1)". Examples:


functools.py:

def partial(func, *args, **keywords):
def newfunc(*fargs, **fkeywords):
newkeywords = keywords.copy()
newkeywords.update(fkeywords)
return func(*(args + fargs), **newkeywords)
...
return newfunc

=>

def partial(func, *args, **keywords):
def newfunc(*fargs, **fkeywords):
return func(*(args + fargs), **keywords, **fkeywords)
...
return newfunc

The new code behaves differently since Neil said that an error is
raised if fkeywords and keywords have keys in common. By the way, this
must be written in the PEP.


pdb.py:

ns = self.curframe.f_globals.copy()
ns.update(self.curframe_locals)
code.interact("*interactive*", local=ns)

Hum no sorry, ns is not used with ** here.

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] (no subject)

[Neil Girdhar]

On Mon, Feb 9, 2015 at 7:53 PM, Donald Stufft  wrote:

>
> On Feb 9, 2015, at 7:29 PM, Neil Girdhar  wrote:
>
> For some reason I can't seem to reply using Google groups, which is is
> telling "this is a read-only mirror" (anyone know why?)  Anyway, I'm going
> to answer as best I can the concerns.
>
> Antoine said:
>
> To be clear, the PEP will probably be useful for one single line of
>> Python code every 1. This is a very weak case for such an intrusive
>> syntax addition. I would support the PEP if it only added the simple
>> cases of tuple unpacking, left alone function call conventions, and
>> didn't introduce **-unpacking.
>
>
> To me this is more of a syntax simplification than a syntax addition.  For
> me the **-unpacking is the most useful part. Regarding utility, it seems
> that a many of the people on r/python were pretty excited about this PEP:
> http://www.reddit.com/r/Python/comments/2synry/so_8_peps_are_currently_being_proposed_for_python/
>
> —
>
> Victor noticed that there's a mistake with the code:
>
> >>> ranges = [range(i) for i in range(5)]
>> >>> [*item for item in ranges]
>> [0, 0, 1, 0, 1, 2, 0, 1, 2, 3]
>
>
> It should be a range(4) in the code.  The "*" applies to only item.  It is
> the same as writing:
>
> [*range(0), *range(1), *range(2), *range(3), *range(4)]
>
> which is the same as unpacking all of those ranges into a list.
>
> > function(**kw_arguments, **more_arguments)
>> If the key "key1" is in both dictionaries, more_arguments wins, right?
>
>
> There was some debate and it was decided that duplicate keyword arguments
> would remain an error (for now at least).  If you want to merge the
> dictionaries with overriding, then you can still do:
>
> function(**{**kw_arguments, **more_arguments})
>
> because **-unpacking in dicts overrides as you guessed.
>
> —
>
>
>
> On Mon, Feb 9, 2015 at 7:12 PM, Donald Stufft  wrote:
>
>>
>> On Feb 9, 2015, at 4:06 PM, Neil Girdhar  wrote:
>>
>> Hello all,
>>
>> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is
>> implemented now based on some early work by Thomas Wouters (in 2008) and
>> Florian Hahn (2013) and recently completed by Joshua Landau and me.
>>
>> The issue tracker http://bugs.python.org/issue2292  has  a working
>> patch.  Would someone be able to review it?
>>
>>
>> I just skimmed over the PEP and it seems like it’s trying to solve a few
>> different things:
>>
>> * Making it easy to combine multiple lists and additional positional args
>> into a function call
>> * Making it easy to combine multiple dicts and additional keyword args
>> into a functional call
>> * Making it easy to do a single level of nested iterable "flatten".
>>
>
> I would say it's:
> * making it easy to unpack iterables and mappings in function calls
> * making it easy to unpack iterables  into list and set displays and
> comprehensions, and
> * making it easy to unpack mappings into dict displays and comprehensions.
>
>
>
>>
>> Looking at the syntax in the PEP I had a hard time detangling what
>> exactly it was doing even with reading the PEP itself. I wonder if there
>> isn’t a way to combine simpler more generic things to get the same outcome.
>>
>> Looking at the "Making it easy to combine multiple lists and additional
>> positional args into a  function call" aspect of this, why is:
>>
>> print(*[1], *[2], 3) better than print(*[1] + [2] + [3])?
>>
>> That's already doable in Python right now and doesn't require anything
>> new to handle it.
>>
>
> Admittedly, this wasn't a great example.  But, if [1] and [2] had been
> iterables, you would have to cast each to list, e.g.,
>
> accumulator = []
> accumulator.extend(a)
> accumulator.append(b)
> accumulator.extend(c)
> print(*accumulator)
>
> replaces
>
> print(*a, b, *c)
>
> where a and c are iterable.  The latter version is also more efficient
> because it unpacks only a onto the stack allocating no auxilliary list.
>
>
> Honestly that doesn’t seem like the way I’d write it at all, if they might
> not be lists I’d just cast them to lists:
>
> print(*list(a) + [b] + list(c))
>

Sure, that works too as long as you put in the missing parentheses.


>
> But if casting to list really is that big a deal, then perhaps a better
> solution is to simply make it so that something like ``a_list +
> an_iterable`` is valid and the iterable would just be consumed and +’d onto
> the list. That still feels like a more general solution and a far less
> surprising and easier to read one.
>

I understand.  However I just want to point out that 448 is more general.
There is no binary operator for generators.  How do you write (*a, *b,
*c)?  You need to use itertools.chain(a, b, c).


>
>
>
>
>> Looking at the "making it easy to do a single level of nsted iterable
>> 'flatten'"" aspect of this, the example of:
>>
>> >>> ranges = [range(i) for i in range(5)]
>> >>> [*item for item in ranges]
>> [0, 0, 1, 0, 1, 2, 0, 1, 2, 3]
>>
>> Conceptually a list comprehension like [thing for item in iterable] 

Re: [Python-Dev] (no subject)

[Donald Stufft]

> On Feb 9, 2015, at 8:34 PM, Neil Girdhar  wrote:
> 
> 
> 
> On Mon, Feb 9, 2015 at 7:53 PM, Donald Stufft  > wrote:
> 
>> On Feb 9, 2015, at 7:29 PM, Neil Girdhar > > wrote:
>> 
>> For some reason I can't seem to reply using Google groups, which is is 
>> telling "this is a read-only mirror" (anyone know why?)  Anyway, I'm going 
>> to answer as best I can the concerns.
>> 
>> Antoine said:
>> 
>> To be clear, the PEP will probably be useful for one single line of 
>> Python code every 1. This is a very weak case for such an intrusive 
>> syntax addition. I would support the PEP if it only added the simple 
>> cases of tuple unpacking, left alone function call conventions, and 
>> didn't introduce **-unpacking. 
>> 
>> To me this is more of a syntax simplification than a syntax addition.  For 
>> me the **-unpacking is the most useful part. Regarding utility, it seems 
>> that a many of the people on r/python were pretty excited about this PEP: 
>> http://www.reddit.com/r/Python/comments/2synry/so_8_peps_are_currently_being_proposed_for_python/
>>  
>> 
>> 
>> —
>> 
>> Victor noticed that there's a mistake with the code:
>> 
>> >>> ranges = [range(i) for i in range(5)] 
>> >>> [*item for item in ranges] 
>> [0, 0, 1, 0, 1, 2, 0, 1, 2, 3] 
>> 
>> It should be a range(4) in the code.  The "*" applies to only item.  It is 
>> the same as writing:
>> 
>> [*range(0), *range(1), *range(2), *range(3), *range(4)]
>> 
>> which is the same as unpacking all of those ranges into a list.
>> 
>> > function(**kw_arguments, **more_arguments) 
>> If the key "key1" is in both dictionaries, more_arguments wins, right? 
>> 
>> There was some debate and it was decided that duplicate keyword arguments 
>> would remain an error (for now at least).  If you want to merge the 
>> dictionaries with overriding, then you can still do:
>> 
>> function(**{**kw_arguments, **more_arguments})
>> 
>> because **-unpacking in dicts overrides as you guessed.
>> 
>> —
>> 
>> 
>> 
>> On Mon, Feb 9, 2015 at 7:12 PM, Donald Stufft > > wrote:
>> 
>>> On Feb 9, 2015, at 4:06 PM, Neil Girdhar >> > wrote:
>>> 
>>> Hello all,
>>> 
>>> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/ 
>>> ) is implemented now based on 
>>> some early work by Thomas Wouters (in 2008) and Florian Hahn (2013) and 
>>> recently completed by Joshua Landau and me.
>>> 
>>> The issue tracker http://bugs.python.org/issue2292 
>>>   has  a working patch.  Would someone be 
>>> able to review it?
>>> 
>> 
>> I just skimmed over the PEP and it seems like it’s trying to solve a few 
>> different things:
>> 
>> * Making it easy to combine multiple lists and additional positional args 
>> into a function call
>> * Making it easy to combine multiple dicts and additional keyword args into 
>> a functional call
>> * Making it easy to do a single level of nested iterable "flatten".
>> 
>> I would say it's:
>> * making it easy to unpack iterables and mappings in function calls
>> * making it easy to unpack iterables  into list and set displays and 
>> comprehensions, and
>> * making it easy to unpack mappings into dict displays and comprehensions.
>> 
>>  
>> 
>> Looking at the syntax in the PEP I had a hard time detangling what exactly 
>> it was doing even with reading the PEP itself. I wonder if there isn’t a way 
>> to combine simpler more generic things to get the same outcome.
>> 
>> Looking at the "Making it easy to combine multiple lists and additional 
>> positional args into a  function call" aspect of this, why is:
>> 
>> print(*[1], *[2], 3) better than print(*[1] + [2] + [3])?
>> 
>> That's already doable in Python right now and doesn't require anything new 
>> to handle it.
>> 
>> Admittedly, this wasn't a great example.  But, if [1] and [2] had been 
>> iterables, you would have to cast each to list, e.g.,
>> 
>> accumulator = []
>> accumulator.extend(a) 
>> accumulator.append(b)
>> accumulator.extend(c)
>> print(*accumulator)
>> 
>> replaces
>> 
>> print(*a, b, *c)
>> 
>> where a and c are iterable.  The latter version is also more efficient 
>> because it unpacks only a onto the stack allocating no auxilliary list.
> 
> Honestly that doesn’t seem like the way I’d write it at all, if they might 
> not be lists I’d just cast them to lists:
> 
> print(*list(a) + [b] + list(c))
> 
> Sure, that works too as long as you put in the missing parentheses.

There are no missing parentheses, the * and ** is last in the order of 
operations (though the parens would likely make that more clear).

>  
> 
> But if casting to list really is that big a deal, then perhaps a better 
> solution is to simply make it so that something like ``a_list + an_iterable`` 
> is valid and the iterable 

Re: [Python-Dev] (no subject)

[Ethan Furman]

On 02/09/2015 05:14 PM, Victor Stinner wrote:
> 
> def partial(func, *args, **keywords):
> def newfunc(*fargs, **fkeywords):
> return func(*(args + fargs), **keywords, **fkeywords)
> ...
> return newfunc
> 
> The new code behaves differently since Neil said that an error is
> raised if fkeywords and keywords have keys in common. By the way, this
> must be written in the PEP.


That line should read

return func(*(args + fargs), **{**keywords, **fkeywords})

to avoid the duplicate key error and keep the original functionality.

--
~Ethan~



signature.asc
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] (no subject)

[Ethan Furman]

On 02/09/2015 05:48 PM, Donald Stufft wrote:
> 
> I don’t think * means “loop” anywhere else in Python and I would never 
> “guess” that
> 
>  [*item for item in iterable]
> 
> meant that. It’s completely non intuitive. Anywhere else you see *foo it’s 
> unpacking a tuple not making an inner loop. That
> means that anywhere else in Python *item is the same thing as item[0], 
> item[1], item[2], …, but this PEP makes it so
> just inside of a comprehension it actually means “make a second, inner loop” 
> instead of what I think anyone who has
> learned that syntax would expect, which is it should be equivalent to 
> [(item[0], item[1], item[2], …) for item in iterable].

I agree with Donald.  I would expect a list of lists from that syntax... or 
maybe a list of tuples?

--
~Ethan~



signature.asc
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] (no subject)

[Greg Ewing]

Donald Stufft wrote:


why is:

print(*[1], *[2], 3) better than print(*[1] + [2] + [3])?


It could potentially be a little more efficient by
eliminating the construction of an intermediate list.

defining + or | or some other symbol for something similar 
to [1] + [2] but for dictionaries. This would mean that you could simply do:


func(**dict1 | dict(y=1) | dict2)


Same again, multiple ** avoids construction of an
itermediate dict.

--
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] (no subject)

[Greg Ewing]

Donald Stufft wrote:

However [*item for item in ranges] is mapped more to something like this:

result = []
for item in iterable:
result.extend(*item)


Actually it would be

   result.extend(item)

But if that bothers you, you could consider the expansion
to be

result = []
for item in iterable:
   for item1 in item:
  result.append(item)

In other words, the * is shorthand for an extra level
of looping.

and it acts differently than if you 
just did *item outside of a list comprehension.


Not sure what you mean by that. It seems closely
analogous to the use of * in a function call to
me.

--
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] (no subject)

[Greg Ewing]

Donald Stufft wrote:


perhaps a better 
solution is to simply make it so that something like ``a_list + 
an_iterable`` is valid and the iterable would just be consumed and +’d 
onto the list.


I don't think I like the asymmetry that this would
introduce into + on lists. Currently

   [1, 2, 3] + (4, 5, 6)

is an error because it's not clear whether the
programmer intended the result to be a list or
a tuple. I think that's a good thing.

Also, it would mean that

   [1, 2, 3] + foo == [1, 2, 3, "f", "o", "o"]

which would be surprising and probably not what
was intended.

--
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] (no subject)

[Donald Stufft]

> On Feb 10, 2015, at 12:55 AM, Greg Ewing  wrote:
> 
> Donald Stufft wrote:
>> However [*item for item in ranges] is mapped more to something like this:
>> result = []
>> for item in iterable:
>>result.extend(*item)
> 
> Actually it would be
> 
>   result.extend(item)
> 
> But if that bothers you, you could consider the expansion
> to be
> 
> result = []
> for item in iterable:
>   for item1 in item:
>  result.append(item)
> 
> In other words, the * is shorthand for an extra level
> of looping.
> 
>> and it acts differently than if you just did *item outside of a list 
>> comprehension.
> 
> Not sure what you mean by that. It seems closely
> analogous to the use of * in a function call to
> me.
> 

Putting aside the proposed syntax the current two statements are currently
true:

1. The statement *item is roughly the same thing as (item[0], item[1], item[n])
2. The statement [something for thing in iterable] is roughly the same as:
   result = []
   for thing in iterable:
   result.append(something)
   This is a single loop where an expression is ran for each iteration of the
   loop, and the return result of that expression is appended to the result.

If you combine these two things, the "something" in #2 becuase *item, and since
*item is roughly the same thing as (item[0], item[1], item[n]) what you end
up with is something that *should* behave like:

result = []
for thing in iterable:
result.append((thing[0], thing[1], thing[n]))


Or to put it another way:

>>> [*item for item in [[1, 2, 3], [4, 5, 6]]
[(1, 2, 3), (4, 5, 6)]


Is a lot more consistent with what *thing and list comprehensions already mean
in Python than for the answer to be [1, 2, 3, 4, 5, 6].
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
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] (no subject)

[Neil Girdhar]

On Tue, Feb 10, 2015 at 1:31 AM, Donald Stufft  wrote:

>
> > On Feb 10, 2015, at 12:55 AM, Greg Ewing 
> wrote:
> >
> > Donald Stufft wrote:
> >> However [*item for item in ranges] is mapped more to something like
> this:
> >> result = []
> >> for item in iterable:
> >>result.extend(*item)
> >
> > Actually it would be
> >
> >   result.extend(item)
> >
> > But if that bothers you, you could consider the expansion
> > to be
> >
> > result = []
> > for item in iterable:
> >   for item1 in item:
> >  result.append(item)
> >
> > In other words, the * is shorthand for an extra level
> > of looping.
> >
> >> and it acts differently than if you just did *item outside of a list
> comprehension.
> >
> > Not sure what you mean by that. It seems closely
> > analogous to the use of * in a function call to
> > me.
> >
>
> Putting aside the proposed syntax the current two statements are currently
> true:
>
> 1. The statement *item is roughly the same thing as (item[0], item[1],
> item[n])
> 2. The statement [something for thing in iterable] is roughly the same as:
>result = []
>for thing in iterable:
>result.append(something)
>This is a single loop where an expression is ran for each iteration of
> the
>loop, and the return result of that expression is appended to the
> result.
>
> If you combine these two things, the "something" in #2 becuase *item, and
> since
> *item is roughly the same thing as (item[0], item[1], item[n]) what you end
> up with is something that *should* behave like:
>
> result = []
> for thing in iterable:
> result.append((thing[0], thing[1], thing[n]))
>

That is what [list(something) for thing in iterable] does.

The iterable unpacking rule might have been better explained as follows:


On the left of assignment * is packing, e.g.
a, b, *cs = iterable

On the right of an assignment, * is an unpacking, e.g.

xs = a, b, *cs


In either case, the  elements of "cs" are treated the same as a and b.

Do you agree that [*x for x in [as, bs, cs]] === [*as, *bs, *cs] ?

Then the elements of *as are unpacked into the list, the same way that
those elements are currently unpacked in a regular function call

f(*as) === f(as[0], as[1], ...)

Similarly,

[*as, *bs, *cs] === [as[0], as[1], …, bs[0], bs[1], …, cs[0], cs[1], …]

The rule for function calls is analogous:


In a function definition, * is a packing, collecting extra positional
argument in a list.  E.g.,

def f(*args):

In a function call, * is an unpacking, expanding an iterable to populate
positional arguments.  E.g.,

f(*args)

—

PEP 448 proposes having arbitrary numbers of unpackings in arbitrary
positions.

I will be updating the PEP this week if I can find the time.


>
> Or to put it another way:
>
> >>> [*item for item in [[1, 2, 3], [4, 5, 6]]
> [(1, 2, 3), (4, 5, 6)]
>
>
> Is a lot more consistent with what *thing and list comprehensions already
> mean
> in Python than for the answer to be [1, 2, 3, 4, 5, 6].
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
> ___
> 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/mistersheik%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] (no subject)

[Victor Stinner]

Le 10 févr. 2015 03:07, "Ethan Furman"  a écrit :
> That line should read
>
> return func(*(args + fargs), **{**keywords, **fkeywords})
>
> to avoid the duplicate key error and keep the original functionality.

To me, this is just ugly. It prefers the original code which use .update().

Maybe the PEP should be changed to behave as .update()?

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] (no subject)

[Neil Girdhar]

On Tue, Feb 10, 2015 at 2:08 AM, Victor Stinner 
wrote:

>
> Le 10 févr. 2015 03:07, "Ethan Furman"  a écrit :
> > That line should read
> >
> > return func(*(args + fargs), **{**keywords, **fkeywords})
> >
> > to avoid the duplicate key error and keep the original functionality.
>
> To me, this is just ugly. It prefers the original code which use .update().
>
> Maybe the PEP should be changed to behave as .update()?
>
> Victor
>
>
Just for clarity, Ethan is right, but it could also be written:

return func(*args, *fargs, **{**keywords, **fkeywords})

Best,

Neil


> ___
> 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/mistersheik%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] (no subject)

[Victor Stinner]

To be logic, I expect [(*item) for item in mylist] to simply return mylist.

[*(item for item in mylist] with mylist=[(1, 2), (3,)] could return [1, 2,
3], as just [*mylist], so "unpack" mylist.

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] (no subject)

[Neil Girdhar]

On Tue, Feb 10, 2015 at 2:20 AM, Victor Stinner 
wrote:

> To be logic, I expect [(*item) for item in mylist] to simply return mylist.
>

If you want simply mylist as a list, that is [*mylist]

> [*(item) for item in mylist] with mylist=[(1, 2), (3,)] could return [1,
> 2, 3],
>
right

> as just [*mylist], so "unpack" mylist.
>

[*mylist] remains equivalent list(mylist), just as it is now.   In one
case, you're unpacking the elements of the list, in the other you're
unpacking the list itself.

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/mistersheik%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] (no subject)

[Neil Girdhar]

ah, sorry… forget that I said "just as it is now" — I am losing track of
what's allowed in Python now!

On Tue, Feb 10, 2015 at 2:29 AM, Neil Girdhar  wrote:

>
>
> On Tue, Feb 10, 2015 at 2:20 AM, Victor Stinner 
> wrote:
>
>> To be logic, I expect [(*item) for item in mylist] to simply return
>> mylist.
>>
>
> If you want simply mylist as a list, that is [*mylist]
>
>> [*(item) for item in mylist] with mylist=[(1, 2), (3,)] could return [1,
>> 2, 3],
>>
> right
>
>> as just [*mylist], so "unpack" mylist.
>>
>
> [*mylist] remains equivalent list(mylist), just as it is now.   In one
> case, you're unpacking the elements of the list, in the other you're
> unpacking the list itself.
>
> 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/mistersheik%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