Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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 ht

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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 t

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

> 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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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 itera

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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.

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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.

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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 allow

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject) PEP 448

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

Re: [Python-Dev] (no subject) PEP 448

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,

Re: [Python-Dev] (no subject)

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 t

Re: [Python-Dev] (no subject)

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 c

Re: [Python-Dev] (no subject)

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 call

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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 th

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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

Re: [Python-Dev] (no subject)

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 t

[Python-Dev] (no subject)

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

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

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.