Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #85216 > unrolled thread

Re: meaning of: line, =

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: meaning of: line, = Albert-Jan Roskam <fomcl@yahoo.com> - 2015-02-04 14:38 +0000
    Re: meaning of: line, = Rustom Mody <rustompmody@gmail.com> - 2015-02-04 07:09 -0800
      Re: meaning of: line, = Peter Otten <__peter__@web.de> - 2015-02-04 18:36 +0100
      Re: meaning of: line, = Chris Angelico <rosuav@gmail.com> - 2015-02-05 08:18 +1100
      Re: meaning of: line, = Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-02-05 01:10 -0800
        Re: meaning of: line, = Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-05 20:40 +1100
          Re: meaning of: line, = Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-05 09:08 -0700
            Re: meaning of: line, = Rustom Mody <rustompmody@gmail.com> - 2015-02-05 08:45 -0800
              Re: meaning of: line, = Skip Montanaro <skip.montanaro@gmail.com> - 2015-02-05 10:56 -0600
              Re: meaning of: line, = Tim Chase <python.list@tim.thechases.com> - 2015-02-05 11:00 -0600
              Re: meaning of: line, = Rustom Mody <rustompmody@gmail.com> - 2015-02-05 08:59 -0800
                Re: meaning of: line, = Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-02-06 05:09 -0800
                  Re: meaning of: line, = Rustom Mody <rustompmody@gmail.com> - 2015-02-06 05:20 -0800
                  Re: meaning of: line, = Rustom Mody <rustompmody@gmail.com> - 2015-02-06 06:03 -0800
          Re: meaning of: line, = Tim Chase <python.list@tim.thechases.com> - 2015-02-05 10:21 -0600
          Re: meaning of: line, = Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-02-05 17:12 -0800
          Re: meaning of: line, = Chris Angelico <rosuav@gmail.com> - 2015-02-06 12:17 +1100
            Re: meaning of: line, = Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-06 17:52 +1300
        Re: meaning of: line, = Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-06 12:30 +1300

#85216 — Re: meaning of: line, =

----- Original Message -----

> From: Chris Angelico <rosuav@gmail.com>
> To: 
> Cc: "python-list@python.org" <python-list@python.org>
> Sent: Wednesday, February 4, 2015 3:24 PM
> Subject: Re: meaning of: line, =
> 
> On Thu, Feb 5, 2015 at 1:08 AM, ast <nomail@invalid.com> wrote:
>>  I dont understand why there is a comma just after line in the following
>>  command:
>> 
>>  line, = plt.plot(x, np.sin(x), '--', linewidth=2)
>> 
>> 
>>  I never saw that before
>> 
>>  Found here:
>> 
> http://matplotlib.org/examples/lines_bars_and_markers/line_demo_dash_control.html
>> 
> 
> That's a slightly unusual form of unpacking. Compare:
> 
> def get_values():
>     return 5, 7, 2
> 
> x, y, z = get_values()
> 
> This is like "x = 5; y = 7; z = 2", because it unpacks the 
> function's
> return value into those three targets.
> 
> What you have is exactly the same, except that it has only one target.
> So it's expecting plt.plot() to return an iterable with exactly one
> thing in it, and it'll unpack it and put that thing into line:
> 
> def get_packaged_value():
>     return [42]
> 
> x, = get_packaged_value()
> 
> This is equivalent to "x = 42". I don't know matplotlib, so I 
> don't
> know what it's returning or why, but as long as it's iterable and
> yields exactly one thing, this will work.



I have also never seen this before, but perhaps this:

>>> f = lambda: [42]
>>> result, = f()
>>> result
42

... is slightly cleaner than this:
>>> result = f()[0]
>>> result
42

[toc] | [next] | [standalone]

#85218

On Wednesday, February 4, 2015 at 8:14:29 PM UTC+5:30, Albert-Jan Roskam wrote:
> ----- Original Message -----
> 
> > From: Chris Angelico 
> > Sent: Wednesday, February 4, 2015 3:24 PM
> > Subject: Re: meaning of: line, =
> > 
> > On Thu, Feb 5, 2015 at 1:08 AM, ast wrote:
> >>  I dont understand why there is a comma just after line in the following
> >>  command:
> >> 
> >>  line, = plt.plot(x, np.sin(x), '--', linewidth=2)
> >> 
> >> 
> >>  I never saw that before
> >> 
> >>  Found here:
> >> 
> > http://matplotlib.org/examples/lines_bars_and_markers/line_demo_dash_control.html
> >> 
> > 
> > That's a slightly unusual form of unpacking. Compare:
> > 
> > def get_values():
> >     return 5, 7, 2
> > 
> > x, y, z = get_values()
> > 
> > This is like "x = 5; y = 7; z = 2", because it unpacks the 
> > function's
> > return value into those three targets.
> > 
> > What you have is exactly the same, except that it has only one target.
> > So it's expecting plt.plot() to return an iterable with exactly one
> > thing in it, and it'll unpack it and put that thing into line:
> > 
> > def get_packaged_value():
> >     return [42]
> > 
> > x, = get_packaged_value()
> > 
> > This is equivalent to "x = 42". I don't know matplotlib, so I 
> > don't
> > know what it's returning or why, but as long as it's iterable and
> > yields exactly one thing, this will work.
> 
> 
> 
> I have also never seen this before, but perhaps this:
> 
> >>> f = lambda: [42]
> >>> result, = f()
> >>> result
> 42
> 
> ... is slightly cleaner than this:
> >>> result = f()[0]
> >>> result
> 42

Well its cryptic and confusing (to me at least)
And is helped by adding 2 characters:

(result,) = f()

instead of 

result, = f()

[toc] | [prev] | [next] | [standalone]

#85227

Rustom Mody wrote:

> Well its cryptic and confusing (to me at least)
> And is helped by adding 2 characters:
> 
> (result,) = f()
> 
> instead of
> 
> result, = f()

Another alternative is to put a list literal on the lefthand side:

>>> def f(): yield 42

... 
>>> [result] = f()
>>> result
42

(If you're worried: neither the list nor the tuple will be created; the 
bytecode is identical in both cases)

[toc] | [prev] | [next] | [standalone]

#85233

On Thu, Feb 5, 2015 at 4:36 AM, Peter Otten <__peter__@web.de> wrote:
> Another alternative is to put a list literal on the lefthand side:
>
>>>> def f(): yield 42
>
> ...
>>>> [result] = f()
>>>> result
> 42

Huh, was not aware of that alternate syntax.

> (If you're worried: neither the list nor the tuple will be created; the
> bytecode is identical in both cases)

It can't possibly be created anyway. Python doesn't have a notion of
"assignable thing that, when assigned to, will assign to something
else" like C's pointers or C++'s references. There's nothing that you
could put into the list that would have this behaviour.

ChrisA

[toc] | [prev] | [next] | [standalone]

#85252

On Wed, Feb 4, 2015 at 1:18 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Feb 5, 2015 at 4:36 AM, Peter Otten <__peter__@web.de> wrote:
>> Another alternative is to put a list literal on the lefthand side:
>>
>>>>> def f(): yield 42
>>
>> ...
>>>>> [result] = f()
>>>>> result
>> 42
>
> Huh, was not aware of that alternate syntax.

Nor are most people. Nor is Python, in some places -- it seems like
people forgot about it when writing some bits of the grammar.

I'd suggest not using it.

>> (If you're worried: neither the list nor the tuple will be created; the
>> bytecode is identical in both cases)
>
> It can't possibly be created anyway. Python doesn't have a notion of
> "assignable thing that, when assigned to, will assign to something
> else" like C's pointers or C++'s references. There's nothing that you
> could put into the list that would have this behaviour.

C pointers don't do that either. It's really just references. (C
pointers aren't any more action-at-a-distance than Python attributes.)

Anyway, it could create a new list in Python, because Python can do
whatever it wants. But it doesn't, because as you say, that wouldn't
do anything.

-- Devin

[toc] | [prev] | [next] | [standalone]

#85253

Devin Jeanpierre wrote:

> On Wed, Feb 4, 2015 at 1:18 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> On Thu, Feb 5, 2015 at 4:36 AM, Peter Otten <__peter__@web.de> wrote:
>>> Another alternative is to put a list literal on the lefthand side:
>>>
>>>>>> def f(): yield 42
>>>
>>> ...
>>>>>> [result] = f()
>>>>>> result
>>> 42
>>
>> Huh, was not aware of that alternate syntax.
> 
> Nor are most people. Nor is Python, in some places -- it seems like
> people forgot about it when writing some bits of the grammar.

Got an example where you can use a,b but not [a,b] or (a,b)?




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#85256

On Thu, Feb 5, 2015 at 2:40 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Devin Jeanpierre wrote:
>
>> On Wed, Feb 4, 2015 at 1:18 PM, Chris Angelico <rosuav@gmail.com> wrote:
>>> On Thu, Feb 5, 2015 at 4:36 AM, Peter Otten <__peter__@web.de> wrote:
>>>> Another alternative is to put a list literal on the lefthand side:
>>>>
>>>>>>> def f(): yield 42
>>>>
>>>> ...
>>>>>>> [result] = f()
>>>>>>> result
>>>> 42
>>>
>>> Huh, was not aware of that alternate syntax.
>>
>> Nor are most people. Nor is Python, in some places -- it seems like
>> people forgot about it when writing some bits of the grammar.
>
> Got an example where you can use a,b but not [a,b] or (a,b)?

>>> def f(a, (b, c)):
...     print a, b, c
...
>>> f(3, [4, 5])
3 4 5
>>> def g(a, [b, c]):
  File "<stdin>", line 1
    def g(a, [b, c]):
             ^
SyntaxError: invalid syntax

Although to be fair, the first syntax there is no longer valid either
in Python 3.

[toc] | [prev] | [next] | [standalone]

#85260

On Thursday, February 5, 2015 at 9:39:27 PM UTC+5:30, Ian wrote:
> On Thu, Feb 5, 2015 at 2:40 AM, Steven D'Aprano wrote:
> > Devin Jeanpierre wrote:
> >
> >> On Wed, Feb 4, 2015 at 1:18 PM, Chris Angelico wrote:
> >>> On Thu, Feb 5, 2015 at 4:36 AM, Peter Otten  wrote:
> >>>> Another alternative is to put a list literal on the lefthand side:
> >>>>
> >>>>>>> def f(): yield 42
> >>>>
> >>>> ...
> >>>>>>> [result] = f()
> >>>>>>> result
> >>>> 42
> >>>
> >>> Huh, was not aware of that alternate syntax.
> >>
> >> Nor are most people. Nor is Python, in some places -- it seems like
> >> people forgot about it when writing some bits of the grammar.
> >
> > Got an example where you can use a,b but not [a,b] or (a,b)?
> 
> >>> def f(a, (b, c)):
> ...     print a, b, c

What the hell is that?!
First I am hearing/seeing it.
Whats it called?

[toc] | [prev] | [next] | [standalone]

#85262

Tuple packing. No longer supported in Python 3, but in available in Python <= 2.

Skip


On Thu, Feb 5, 2015 at 10:45 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Thursday, February 5, 2015 at 9:39:27 PM UTC+5:30, Ian wrote:
>> On Thu, Feb 5, 2015 at 2:40 AM, Steven D'Aprano wrote:
>> > Devin Jeanpierre wrote:
>> >
>> >> On Wed, Feb 4, 2015 at 1:18 PM, Chris Angelico wrote:
>> >>> On Thu, Feb 5, 2015 at 4:36 AM, Peter Otten  wrote:
>> >>>> Another alternative is to put a list literal on the lefthand side:
>> >>>>
>> >>>>>>> def f(): yield 42
>> >>>>
>> >>>> ...
>> >>>>>>> [result] = f()
>> >>>>>>> result
>> >>>> 42
>> >>>
>> >>> Huh, was not aware of that alternate syntax.
>> >>
>> >> Nor are most people. Nor is Python, in some places -- it seems like
>> >> people forgot about it when writing some bits of the grammar.
>> >
>> > Got an example where you can use a,b but not [a,b] or (a,b)?
>>
>> >>> def f(a, (b, c)):
>> ...     print a, b, c
>
> What the hell is that?!
> First I am hearing/seeing it.
> Whats it called?
> --
> https://mail.python.org/mailman/listinfo/python-list

[toc] | [prev] | [next] | [standalone]

#85263

On 2015-02-05 08:45, Rustom Mody wrote:
> > >>> def f(a, (b, c)):
> > ...     print a, b, c
> 
> What the hell is that?!
> First I am hearing/seeing it.
> Whats it called?

"tuple parameter unpacking", removed in Py3

https://www.python.org/dev/peps/pep-3113/

-tkc

[toc] | [prev] | [next] | [standalone]

#85264

On Thursday, February 5, 2015 at 10:15:29 PM UTC+5:30, Rustom Mody wrote:
> On Thursday, February 5, 2015 at 9:39:27 PM UTC+5:30, Ian wrote:
> > On Thu, Feb 5, 2015 at 2:40 AM, Steven D'Aprano wrote:
> > > Devin Jeanpierre wrote:
> > >
> > >> On Wed, Feb 4, 2015 at 1:18 PM, Chris Angelico wrote:
> > >>> On Thu, Feb 5, 2015 at 4:36 AM, Peter Otten  wrote:
> > >>>> Another alternative is to put a list literal on the lefthand side:
> > >>>>
> > >>>>>>> def f(): yield 42
> > >>>>
> > >>>> ...
> > >>>>>>> [result] = f()
> > >>>>>>> result
> > >>>> 42
> > >>>
> > >>> Huh, was not aware of that alternate syntax.
> > >>
> > >> Nor are most people. Nor is Python, in some places -- it seems like
> > >> people forgot about it when writing some bits of the grammar.
> > >
> > > Got an example where you can use a,b but not [a,b] or (a,b)?
> > 
> > >>> def f(a, (b, c)):
> > ...     print a, b, c
> 
> What the hell is that?!
> First I am hearing/seeing it.
> Whats it called?

The reason I ask: I sorely miss haskell's pattern matching in python.

It goes some way:

>>> ((x,y),z) = ((1,2),3)
>>> x,y,z
(1, 2, 3)

But not as far as I would like:

>>> ((x,y),3) = ((1,2),3)
  File "<stdin>", line 1
SyntaxError: can't assign to literal
>>> 

[Haskell]

Prelude> let (x, (y, (42, z, "Hello"))) = (1, (2, (42, 3, "Hello")))
Prelude> (x,y,z)
(1,2,3)

[toc] | [prev] | [next] | [standalone]

#85286

Sorry for late reply, I somehow missed this email.

On Thu, Feb 5, 2015 at 8:59 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> The reason I ask: I sorely miss haskell's pattern matching in python.
>
> It goes some way:
>
>>>> ((x,y),z) = ((1,2),3)
>>>> x,y,z
> (1, 2, 3)
>
> But not as far as I would like:
>
>>>> ((x,y),3) = ((1,2),3)
>   File "<stdin>", line 1
> SyntaxError: can't assign to literal
>>>>
>
> [Haskell]
>
> Prelude> let (x, (y, (42, z, "Hello"))) = (1, (2, (42, 3, "Hello")))
> Prelude> (x,y,z)
> (1,2,3)

Yeah, but Haskell is ludicrous.

Prelude> let (x, 2) = (1, 3)
Prelude>

Only non-falsifiable patterns really make sense as the left hand side
of an assignment in a language without exceptions, IMO. Otherwise you
should use a match/case statement. (Of course, Python does have
exceptions...)

-- Devin

[toc] | [prev] | [next] | [standalone]

#85287

On Friday, February 6, 2015 at 6:40:23 PM UTC+5:30, Devin Jeanpierre wrote:
> Sorry for late reply, I somehow missed this email.
> 
> On Thu, Feb 5, 2015 at 8:59 AM, Rustom Mody wrote:
> > The reason I ask: I sorely miss haskell's pattern matching in python.
> >
> > It goes some way:
> >
> >>>> ((x,y),z) = ((1,2),3)
> >>>> x,y,z
> > (1, 2, 3)
> >
> > But not as far as I would like:
> >
> >>>> ((x,y),3) = ((1,2),3)
> >   File "<stdin>", line 1
> > SyntaxError: can't assign to literal
> >>>>
> >
> > [Haskell]
> >
> > Prelude> let (x, (y, (42, z, "Hello"))) = (1, (2, (42, 3, "Hello")))
> > Prelude> (x,y,z)
> > (1,2,3)
> 
> Yeah, but Haskell is ludicrous.
> 
> Prelude> let (x, 2) = (1, 3)
> Prelude>
> 
> Only non-falsifiable patterns really make sense as the left hand side
> of an assignment in a language without exceptions, IMO. Otherwise you
> should use a match/case statement.

Which is what people do 99% of the times - write pattern matching function defs

I was just writing a 1 liner showing matching of constants and variables simultaneously

[toc] | [prev] | [next] | [standalone]

#85289

On Friday, February 6, 2015 at 6:40:23 PM UTC+5:30, Devin Jeanpierre wrote:
> Sorry for late reply, I somehow missed this email.
> 
> On Thu, Feb 5, 2015 at 8:59 AM, Rustom Mody wrote:
> > The reason I ask: I sorely miss haskell's pattern matching in python.
> >
> > It goes some way:
> >
> >>>> ((x,y),z) = ((1,2),3)
> >>>> x,y,z
> > (1, 2, 3)
> >
> > But not as far as I would like:
> >
> >>>> ((x,y),3) = ((1,2),3)
> >   File "<stdin>", line 1
> > SyntaxError: can't assign to literal
> >>>>
> >
> > [Haskell]
> >
> > Prelude> let (x, (y, (42, z, "Hello"))) = (1, (2, (42, 3, "Hello")))
> > Prelude> (x,y,z)
> > (1,2,3)
> 
> Yeah, but Haskell is ludicrous.
> 
> Prelude> let (x, 2) = (1, 3)
> Prelude>
> 
> Only non-falsifiable patterns really make sense as the left hand side
> of an assignment in a language without exceptions, IMO. Otherwise you
> should use a match/case statement. (Of course, Python does have
> exceptions...)

Also its good to see the full context of your example:

Prelude> let (x, 2) = (1, 3)
Prelude> x
*** Exception: <interactive>:2:5-19: Irrefutable pattern failed for pattern (x, 2)

Prelude> 


So I am not sure what you find ludicrous.
Haskell is a lazy language. 
This is lazy behavior. What else can it be?

[Does not make me a great fan of laziness -- which is another matter]

[toc] | [prev] | [next] | [standalone]

#85267

On 2015-02-05 09:08, Ian Kelly wrote:
> > Got an example where you can use a,b but not [a,b] or (a,b)?  
> 
> >>> def f(a, (b, c)):  
> ...     print a, b, c
> ...

Interesting.  I knew that at one point you could do this with lambdas
but never thought to do it with regular functions.  There are times
this would have been useful, but since it appears to have gone away
in Py3, I guess I won't adopt it.

-tkc

[toc] | [prev] | [next] | [standalone]

#85276

On Thu, Feb 5, 2015 at 8:08 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Thu, Feb 5, 2015 at 2:40 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Devin Jeanpierre wrote:
>>> On Wed, Feb 4, 2015 at 1:18 PM, Chris Angelico <rosuav@gmail.com> wrote:
>>>>>>>> [result] = f()
>>>>>>>> result
>>>>> 42
>>>>
>>>> Huh, was not aware of that alternate syntax.
>>>
>>> Nor are most people. Nor is Python, in some places -- it seems like
>>> people forgot about it when writing some bits of the grammar.
>>
>> Got an example where you can use a,b but not [a,b] or (a,b)?
>
>>>> def f(a, (b, c)):
> ...     print a, b, c
> ...
>>>> f(3, [4, 5])
> 3 4 5
>>>> def g(a, [b, c]):
>   File "<stdin>", line 1
>     def g(a, [b, c]):
>              ^
> SyntaxError: invalid syntax
>
> Although to be fair, the first syntax there is no longer valid either
> in Python 3.

As Ian rightly understood, I was referring to differences between "[a,
b, ...]" and "(a, b, ...)".

Here's another example, one that still exists in Python 3:

>>> [] = ''
>>> () = ''
  File "<stdin>", line 1
SyntaxError: can't assign to ()

The syntax explicitly blacklists (), but forgets to blacklist [].

-- Devin

[toc] | [prev] | [next] | [standalone]

#85277

On Fri, Feb 6, 2015 at 12:12 PM, Devin Jeanpierre
<jeanpierreda@gmail.com> wrote:
> Here's another example, one that still exists in Python 3:
>
>>>> [] = ''
>>>> () = ''
>   File "<stdin>", line 1
> SyntaxError: can't assign to ()
>
> The syntax explicitly blacklists (), but forgets to blacklist [].

So... this is actually a really really obscure little feature.

[] = x
# is equivalent to
try: next(iter(x))
except StopIteration: pass
else: raise ValueError("too many values to unpack (expected 0)")

It's a way of asserting that an iterator is exhausted! Perfect code
snippet for your next International Obfuscated Python Code Contest
entry.

ChrisA

[toc] | [prev] | [next] | [standalone]

#85278

Chris Angelico wrote:
> [] = x
> # is equivalent to
> try: next(iter(x))
> except StopIteration: pass
> else: raise ValueError("too many values to unpack (expected 0)")
> 
> It's a way of asserting that an iterator is exhausted!

But why disallow using () for the same thing? This
is a blatant case of outright list-ism! Tuples are
being unfairly discriminated against!

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#85275

Devin Jeanpierre wrote:
> On Wed, Feb 4, 2015 at 1:18 PM, Chris Angelico <rosuav@gmail.com> wrote:
> 
>>On Thu, Feb 5, 2015 at 4:36 AM, Peter Otten <__peter__@web.de> wrote:
>>
>>>>>>>[result] = f()
>>>>>>result
>>
>>Huh, was not aware of that alternate syntax.
> 
> Nor are most people. Nor is Python, in some places -- it seems like
> people forgot about it when writing some bits of the grammar.

If I remember correctly, it's left over from long ago
when you had to use tuple syntax to unpack tuples and
list syntax to unpack lists (and you couldn't unpack
anything else).

When the iterator protocol was introduced, the two
became equivalent.

-- 
Greg

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web