On Thu, Oct 27, 2016 at 03:27:07AM +1100, Steven D'Aprano wrote:
> I think that there is zero hope of consistency for * the star operator.
> That horse has bolted. It is already used for:
>
> - ...
> - "zero or more of the previous element" in regular expressions
> - "zero or more of any characte
On Wed, Oct 26, 2016 at 01:25:48AM +0100, Rob Cliffe wrote:
> (2) This is admittedly a somewhat tangential argument, but: I didn't
> really know what "yield from" meant. But when I read in an earlier post
> that someone had proposed "yield *" for it, I had a Eureka moment.
Are you aware that
On 14/10/2016 07:00, Greg Ewing wrote:
Neil Girdhar wrote:
At the end of this discussion it might be good to get a tally of how
many people think the proposal is reasonable and logical.
I think it's reasonable and logical.
I concur. Two points I personally find in favour, YMMV:
(1) [*subs
On Sat, Oct 15, 2016 at 05:38:15PM +, Neil Girdhar wrote:
> In ast.c, you can find:
>
> if (is_dict) {
> ast_error(c, n, "dict unpacking cannot be used in "
> "dict comprehension");
> return NULL;
>
On Sat, Oct 15, 2016 at 5:01 AM Steven D'Aprano wrote:
> On Thu, Oct 13, 2016 at 01:30:45PM -0700, Neil Girdhar wrote:
>
> > From a CPython implementation standpoint, we specifically blocked this
> code
> > path, and it is only a matter of unblocking it if we want to support
> this.
>
> I find th
On Thu, Oct 13, 2016 at 01:30:45PM -0700, Neil Girdhar wrote:
> From a CPython implementation standpoint, we specifically blocked this code
> path, and it is only a matter of unblocking it if we want to support this.
I find that difficult to believe. The suggested change seems like it
should be
On 13 October 2016 at 02:32, Sven R. Kunze wrote:
> Here I disagree with you. We use *args all the time, so we know what * does.
> I don't understand why this should not work in between brackets [...].
It does work between brackets:
>>> [*range(3)]
[0, 1, 2]
It doesn't work as part of t
Neil Girdhar wrote:
At the end of this discussion it might be good to get a tally of how
many people think the proposal is reasonable and logical.
I think it's reasonable and logical.
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
http
I've never used nor taught a * in a list display. I don't think they seem
so bad, but it's a step down a slippery slope towards forms that might as
well be Perl.
On Oct 13, 2016 10:33 PM, "Greg Ewing" wrote:
> David Mertz wrote:
>
>> it would always be "Here's a Python wart to look out for if yo
David Mertz wrote:
it would always be "Here's a Python wart to look out
for if you see it in other code... you should not ever use it yourself."
Do you currently tell them the same thing about the use
of * in a list display?
--
Greg
___
Python-ideas
On Fri, Oct 14, 2016 at 12:06 AM Neil Girdhar wrote:
> Regarding Steven's example, like Sven, I also see it this way:
>
> [*t for t in [(1, 'a'), (2, 'b'), (3, 'c')]]
>
> should mean:
>
>[*(1, 'a'), *(2, 'b'), *(3, 'c')]]
>
> Which coincides with what the OP is asking for.
>
>
>From a C
First of all:
+1 to Sven's very well-expressed support of the proposal, and
+1 to Nick's very well-explained reasons for rejecting it.
As one of the main implementers of PEP 448, I have always liked this, but I
suggested that we leave this out when there was opposition since there's no
rush for
Exactly with Paul!
As I mentioned, I teach software developers and scientists Python for a
living. I get paid a lot of money to do that, and have a good sense of
what learners can easily understand and not (I've also written hundred of
articles and a few books about Python). The people I write f
On Thu, Oct 13, 2016 at 03:28:27PM +, אלעזר wrote:
> It may also suggest that there are currently two ways to understand the
> *[...] construct,
This thread is about allowing sequence unpacking as the internal
expression of list comprehensions:
[ *(expr) for x in iterable ]
It isn't a
On Thu, Oct 13, 2016 at 6:19 PM Paul Moore wrote:
> On 13 October 2016 at 15:32, Sven R. Kunze wrote:
> > Steven, please. You seemed to struggle to understand the notion of the
> > [*] construct and many people (not just me) here tried their best to
> > explain their intuition to you.
>
> An
On 13 October 2016 at 15:32, Sven R. Kunze wrote:
> Steven, please. You seemed to struggle to understand the notion of the
> [*] construct and many people (not just me) here tried their best to
> explain their intuition to you.
And yet, the fact that it's hard to explain your intuition to oth
On 13.10.2016 16:10, Steven D'Aprano wrote:
On Thu, Oct 13, 2016 at 10:37:35AM +0200, Sven R. Kunze wrote:
Multiplication with only a single argument? Come on.
You didn't say anything about a single argument. Your exact words are
shown above: "where have I seen * so far?". I'm pretty sure you'v
On Thu, Oct 13, 2016 at 5:10 PM Steven D'Aprano wrote:
> On Thu, Oct 13, 2016 at 10:37:35AM +0200, Sven R. Kunze wrote:
> > About the list constructor: we construct a list by writing [a,b,c] or by
> > writing [b for b in bs]. The end result is a list
>
> I construct lists using all sorts of ways:
On Thu, Oct 13, 2016 at 10:37:35AM +0200, Sven R. Kunze wrote:
> On 13.10.2016 01:29, Steven D'Aprano wrote:
> >On Wed, Oct 12, 2016 at 06:32:12PM +0200, Sven R. Kunze wrote:
> >>
> >>So, my reasoning would tell me: where have I seen * so far? *args and
> >>**kwargs!
> >And multiplication.
>
> Mul
On 13.10.2016 01:29, Steven D'Aprano wrote:
On Wed, Oct 12, 2016 at 06:32:12PM +0200, Sven R. Kunze wrote:
So, my reasoning would tell me: where have I seen * so far? *args and
**kwargs!
And multiplication.
Multiplication with only a single argument? Come on.
And sequence unpacking.
We
On Thu, Oct 13, 2016 at 2:35 AM Steven D'Aprano wrote:
> On Wed, Oct 12, 2016 at 04:11:55PM +, אלעזר wrote:
>
> > Steve, you only need to allow multiple arguments to append(), then it
> makes
> > perfect sense.
>
> I think you're missing a step. What will multiple arguments given to
> append
On Wed, Oct 12, 2016 at 04:11:55PM +, אלעזר wrote:
> Steve, you only need to allow multiple arguments to append(), then it makes
> perfect sense.
I think you're missing a step. What will multiple arguments given to
append do? There are two obvious possibilities:
- collect all the arguments
On Wed, Oct 12, 2016 at 06:32:12PM +0200, Sven R. Kunze wrote:
> On 12.10.2016 17:41, Nick Coghlan wrote:
> >This particular proposal fails on the first question (as too many
> >people would expect it to mean the same thing as either "[*expr, for
> >expr in iterable]" or "[*(expr for expr in iterab
The semantics seem fairly obvious if you treat it as changing the method calls.
For lists, * uses .extend() instead of .append(). Sets use * for .update()
instead of .add(). Dicts use ** for .update() instead of __setitem__. In that
case x should be a mapping (or iterable of pairs maybe), and al
To be honest, I don't have a clear picture of what {**x for x in d.items()}
should be. But I do have such picture for
dict(**x for x in many_dictionaries)
Elazar
On Wed, Oct 12, 2016 at 11:37 PM אלעזר wrote:
> On Wed, Oct 12, 2016 at 11:26 PM David Mertz wrote:
>
> On Wed, Oct 12, 20
On 12.10.2016 21:38, אלעזר wrote:
What is the intuition behind [1, *x, 5]? The starred expression is
replaced with a comma-separated sequence of its elements.
The trailing comma Nick referred to is there, with the rule that [1,,
5] is the same as [1, 5].
I have to admit that I have my pr
On Wed, Oct 12, 2016 at 11:26 PM David Mertz wrote:
> On Wed, Oct 12, 2016 at 12:38 PM, אלעזר wrote:
>
> What is the intuition behind [1, *x, 5]? The starred expression is
> replaced with a comma-separated sequence of its elements.
>
> I've never actually used the `[1, *x, 5]` form. And therefo
On 12 October 2016 at 20:22, David Mertz wrote:
> I've followed this discussion some, and every example given so far
> completely mystifies me and I have no intuition about what they should mean.
Same here.
On 12 October 2016 at 20:38, אלעזר wrote:
> What is the intuition behind [1, *x, 5]? The
On Wed, Oct 12, 2016 at 12:38 PM, אלעזר wrote:
> What is the intuition behind [1, *x, 5]? The starred expression is
> replaced with a comma-separated sequence of its elements.
>
I've never actually used the `[1, *x, 5]` form. And therefore, of course,
I've never taught it either (I teach Python
What is the intuition behind [1, *x, 5]? The starred expression is replaced
with a comma-separated sequence of its elements.
The trailing comma Nick referred to is there, with the rule that [1,, 5] is
the same as [1, 5].
All the examples follow this intuition, IIUC.
Elazar
בתאריך יום ד׳, 12 באו
I've followed this discussion some, and every example given so far
completely mystifies me and I have no intuition about what they should mean.
On Oct 12, 2016 8:43 AM, "Steven D'Aprano" wrote:
> On Tue, Oct 11, 2016 at 02:42:54PM +0200, Martti Kühne wrote:
> > Hello list
> >
> > I love the "new
אלעזר writes:
> Steve, you only need to allow multiple arguments to append(), then it makes
> perfect sense.
No, because that would be explicit. Here it's implicit and ambiguous.
Specifically, it requires guessing "operator associativity". That is
something people have different intuitions ab
On 12.10.2016 17:41, Nick Coghlan wrote:
This particular proposal fails on the first question (as too many
people would expect it to mean the same thing as either "[*expr, for
expr in iterable]" or "[*(expr for expr in iterable)]")
So, my reasoning would tell me: where have I seen * so far? *ar
Steve, you only need to allow multiple arguments to append(), then it makes
perfect sense.
בתאריך יום ד׳, 12 באוק' 2016, 18:43, מאת Steven D'Aprano <
st...@pearwood.info>:
> On Tue, Oct 11, 2016 at 02:42:54PM +0200, Martti Kühne wrote:
> > Hello list
> >
> > I love the "new" unpacking generalisa
On Tue, Oct 11, 2016 at 02:42:54PM +0200, Martti Kühne wrote:
> Hello list
>
> I love the "new" unpacking generalisations as of pep448. And I found
> myself using them rather regularly, both with lists and dict.
> Today I somehow expected that [*foo for foo in bar] was equivalent to
> itertools.ch
On 12 October 2016 at 23:58, Sven R. Kunze wrote:
> Reading PEP448 it seems to me that it's already been considered:
> https://www.python.org/dev/peps/pep-0448/#variations
>
> The reason for not-inclusion were about concerns about acceptance because of
> "strong concerns about readability" but als
Hi Martti,
On 11.10.2016 14:42, Martti Kühne wrote:
Hello list
I love the "new" unpacking generalisations as of pep448. And I found
myself using them rather regularly, both with lists and dict.
Today I somehow expected that [*foo for foo in bar] was equivalent to
itertools.chain(*[foo for foo i
On 11 October 2016 at 23:50, אלעזר wrote:
> I thought about it a lot recently. Specifically on your proposal, and in
> general. Unpacking expression can have a much more uniform treatment in the
> language, as an expression with special "bare tuple" type - like tuple, but
> "without the braces".
I thought about it a lot recently. Specifically on your proposal, and in
general. Unpacking expression can have a much more uniform treatment in the
language, as an expression with special "bare tuple" type - like tuple, but
"without the braces".
It also gives mental explanation for the conditiona
39 matches
Mail list logo
