On Feb 9, 2015, at 8:34 PM, Neil Girdhar mistersh...@gmail.com wrote:
On Mon, Feb 9, 2015 at 7:53 PM, Donald Stufft don...@stufft.io
mailto:don...@stufft.io wrote:
On Feb 9, 2015, at 7:29 PM, Neil Girdhar mistersh...@gmail.com
mailto:mistersh...@gmail.com wrote:
For some reason
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]
On Tue, Feb 10, 2015 at 1:31 AM, Donald Stufft don...@stufft.io wrote:
On Feb 10, 2015, at 12:55 AM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Donald Stufft wrote:
However [*item for item in ranges] is mapped more to something like
this:
result = []
for item in iterable:
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
Le 10 févr. 2015 03:07, Ethan Furman et...@stoneleaf.us 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
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
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
On Feb 10, 2015, at 12:55 AM, Greg Ewing greg.ew...@canterbury.ac.nz 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
On Tue, Feb 10, 2015 at 2:20 AM, Victor Stinner victor.stin...@gmail.com
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],
On Tue, Feb 10, 2015 at 2:08 AM, Victor Stinner victor.stin...@gmail.com
wrote:
Le 10 févr. 2015 03:07, Ethan Furman et...@stoneleaf.us a écrit :
That line should read
return func(*(args + fargs), **{**keywords, **fkeywords})
to avoid the duplicate key error and keep the original
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
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 mistersh...@gmail.com wrote:
On Tue, Feb 10, 2015 at 2:20 AM, Victor Stinner victor.stin...@gmail.com
wrote:
To be logic, I expect [(*item) for
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
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,
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
On Feb 9, 2015, at 7:29 PM, Neil Girdhar mistersh...@gmail.com 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
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
The admonition is against syntax that currently exists.
On Mon, Feb 9, 2015 at 7:53 PM, Barry Warsaw ba...@python.org 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
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 mistersh...@gmail.com wrote:
The admonition is against syntax that currently exists.
2015-02-10 1:29 GMT+01:00 Neil Girdhar mistersh...@gmail.com:
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
On 09.02.15 14:48, raymond.hettinger wrote:
https://hg.python.org/cpython/rev/dc820b44ce21
changeset: 94572:dc820b44ce21
user:Raymond Hettinger pyt...@rcn.com
date:Mon Feb 09 06:48:29 2015 -0600
summary:
Mirco-optimizations to reduce register spills and reloads observed on
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.
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)
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
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
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
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
On Mon, 9 Feb 2015 16:06:20 -0500
Neil Girdhar mistersh...@gmail.com 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
2015-02-10 0:51 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
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
On Feb 9, 2015, at 4:06 PM, Neil Girdhar mistersh...@gmail.com wrote:
Hello all,
The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/
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
On 10 Feb 2015 08:13, Benjamin Peterson benja...@python.org 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/)
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 benja...@python.org
wrote:
On Mon, Feb 9, 2015, at 16:32, Guido van Rossum
On Tue, 10 Feb 2015 08:43:53 +1000
Nick Coghlan ncogh...@gmail.com 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
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
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 benja...@python.org
wrote:
On Mon, Feb 9, 2015, at 17:12, Neil Girdhar wrote:
Right,
Hi,
2015-02-09 22:06 GMT+01:00 Neil Girdhar mistersh...@gmail.com:
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
On Mon, Feb 9, 2015 at 7:53 PM, Donald Stufft don...@stufft.io wrote:
On Feb 9, 2015, at 7:29 PM, Neil Girdhar mistersh...@gmail.com 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
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
38 matches
Mail list logo
