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

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

Most probably a stupid question, but I still want to ask

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

Contents

  Most probably a stupid question, but I still want to ask Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 18:51 -0400
    Re: Most probably a stupid question, but I still want to ask Chris Angelico <rosuav@gmail.com> - 2016-04-11 08:58 +1000
    Re: Most probably a stupid question, but I still want to ask Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 09:04 +1000
    Re: Most probably a stupid question, but I still want to ask Stephen Hansen <me+python@ixokai.io> - 2016-04-10 16:30 -0700
      Re: Most probably a stupid question, but I still want to ask Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 20:17 -0400
        Re: Most probably a stupid question, but I still want to ask Stephen Hansen <me+python@ixokai.io> - 2016-04-10 17:32 -0700
        Re: Most probably a stupid question, but I still want to ask Terry Reedy <tjreedy@udel.edu> - 2016-04-10 21:45 -0400
          Re: Most probably a stupid question, but I still want to ask Marko Rauhamaa <marko@pacujo.net> - 2016-04-11 08:41 +0300
    one-element tuples [Was: Most probably a stupid question, but I still want to ask] Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 20:13 -0400
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Stephen Hansen <me+python@ixokai.io> - 2016-04-10 17:19 -0700
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Stephen Hansen <me+python@ixokai.io> - 2016-04-10 17:18 -0700
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Chris Angelico <rosuav@gmail.com> - 2016-04-11 10:20 +1000
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 20:22 -0400
        Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Stephen Hansen <me+python@ixokai.io> - 2016-04-10 17:28 -0700
        Re: one-element tuples Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 10:31 +1000
          Re: one-element tuples Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 20:48 -0400
            Re: one-element tuples Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 10:56 +1000
              Re: one-element tuples Grant Edwards <invalid@invalid.invalid> - 2016-04-11 14:10 +0000
                Re: one-element tuples Fillmore <fillmore_remove@hotmail.com> - 2016-04-11 10:11 -0400
                  Re: one-element tuples Grant Edwards <invalid@invalid.invalid> - 2016-04-11 14:26 +0000
            Re: one-element tuples Ned Batchelder <ned@nedbatchelder.com> - 2016-04-10 18:00 -0700
            Re: one-element tuples Stephen Hansen <me+python@ixokai.io> - 2016-04-10 18:07 -0700
            Re: one-element tuples "Martin A. Brown" <martin@linux-ip.net> - 2016-04-10 18:08 -0700
              Re: one-element tuples Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 23:19 -0400
                Re: one-element tuples Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-04-11 09:57 +0300
                Re: one-element tuples Larry Hudson <orgnut@yahoo.com> - 2016-04-11 23:01 -0700
            Re: one-element tuples Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 11:36 +1000
              Re: one-element tuples Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 22:57 -0400
                Re: one-element tuples Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 14:10 +1000
                  Re: one-element tuples Fillmore <fillmore_remove@hotmail.com> - 2016-04-11 00:43 -0400
                    Re: one-element tuples Stephen Hansen <me+python@ixokai.io> - 2016-04-10 21:54 -0700
                    Re: one-element tuples Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 15:40 +1000
                  Re: one-element tuples Rustom Mody <rustompmody@gmail.com> - 2016-04-10 22:07 -0700
            Re: one-element tuples BartC <bc@freeuk.com> - 2016-04-11 12:15 +0100
              Re: one-element tuples Marko Rauhamaa <marko@pacujo.net> - 2016-04-11 15:12 +0300
                Re: one-element tuples Grant Edwards <invalid@invalid.invalid> - 2016-04-11 14:12 +0000
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 10:30 +1000
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] MRAB <python@mrabarnett.plus.com> - 2016-04-11 01:33 +0100
        Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Dan Sommers <dan@tombstonezero.net> - 2016-04-11 02:22 +0000
          Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Chris Angelico <rosuav@gmail.com> - 2016-04-11 12:34 +1000
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Chris Angelico <rosuav@gmail.com> - 2016-04-11 10:38 +1000
      Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask]) Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 10:45 +1000
      Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask]) Chris Angelico <rosuav@gmail.com> - 2016-04-11 10:50 +1000
      Re: Parens do create a tuple Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 10:57 +1000
      Re: Parens do create a tuple Chris Angelico <rosuav@gmail.com> - 2016-04-11 11:04 +1000
      Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask]) Stephen Hansen <me@ixokai.io> - 2016-04-10 18:03 -0700
      Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask]) Tim Chase <python.list@tim.thechases.com> - 2016-04-10 19:52 -0500
      Re: Parens do create a tuple Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 11:41 +1000
        Re: Parens do create a tuple Steven D'Aprano <steve@pearwood.info> - 2016-04-11 12:32 +1000
          Re: Parens do create a tuple Random832 <random832@fastmail.com> - 2016-04-10 22:51 -0400
            Re: Parens do create a tuple Steven D'Aprano <steve@pearwood.info> - 2016-04-11 14:08 +1000
              Re: Parens do create a tuple Random832 <random832@fastmail.com> - 2016-04-11 01:27 -0400
                Re: Parens do create a tuple Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-04-11 18:01 +1000
                  Re: Parens do create a tuple Random832 <random832@fastmail.com> - 2016-04-11 09:42 -0400
          Re: Parens do create a tuple Chris Angelico <rosuav@gmail.com> - 2016-04-11 13:02 +1000
          Re: Parens do create a tuple Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 14:08 +1000
      Re: Parens do create a tuple Chris Angelico <rosuav@gmail.com> - 2016-04-11 11:51 +1000
        Re: Parens do create a tuple Steven D'Aprano <steve@pearwood.info> - 2016-04-11 12:57 +1000
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Tim Chase <python.list@tim.thechases.com> - 2016-04-10 19:46 -0500
    Re: Most probably a stupid question, but I still want to ask Steven D'Aprano <steve@pearwood.info> - 2016-04-11 11:50 +1000
      Re: Most probably a stupid question, but I still want to ask Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 22:48 -0400
        Re: Most probably a stupid question, but I still want to ask Steven D'Aprano <steve@pearwood.info> - 2016-04-11 13:54 +1000
          Re: Most probably a stupid question, but I still want to ask Fillmore <fillmore_remove@hotmail.com> - 2016-04-11 00:03 -0400
            Re: Most probably a stupid question, but I still want to ask Stephen Hansen <me+python@ixokai.io> - 2016-04-10 21:46 -0700
              Re: Most probably a stupid question, but I still want to ask Rustom Mody <rustompmody@gmail.com> - 2016-04-10 22:18 -0700
                Re: Most probably a stupid question, but I still want to ask Stephen Hansen <me+python@ixokai.io> - 2016-04-10 22:42 -0700
                  Re: Most probably a stupid question, but I still want to ask Rustom Mody <rustompmody@gmail.com> - 2016-04-10 23:57 -0700
            Re: Most probably a stupid question, but I still want to ask Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-04-11 17:50 +1000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#106814 — Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

On Mon, Apr 11, 2016 at 10:33 AM, MRAB <python@mrabarnett.plus.com> wrote:
> For example, object are passed into a function thus:
>
>     f(x, y)
>
> (In reality, it's making a tuple and then passing that in.)

Actually that's not the case; certain syntactic constructs allow you
to specify multiple of something, without packaging them up into a
tuple. Function arguments and parameters are like this; otherwise
keyword arguments would have to be some kind of magic syntax in
tuples, instead of being a feature of function calls.

But there are plenty of situations where what you're describing _is_
the case, such as assigning multiple values to multiple targets:

# Package up y and x into a tuple
# Then unpack the tuple into two names
x, y = y, x

ChrisA

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

#106815 — Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])

Stephen Hansen <me+python@ixokai.io> writes:

> […] parens don't make tuples, commas do.


Chris Angelico <rosuav@gmail.com> writes:

> The thing you're confused at is that it's not the parentheses that
> create a tuple. Parentheses merely group.


MRAB <python@mrabarnett.plus.com> writes:

> As has been said already, it's the comma that makes the tuple. The
> parentheses are often needed to avoid ambiguity.

This is too simplistic, and IMO it's just sowing the seed for future
confusion.

As MRAB states in the same message:

> There _is_ one exception though: (). It's the empty tuple (a 0-element
> tuple). It doesn't have a comma and the parentheses are mandatory.
> There's no other way to write it.

So, let's please stop saying “parens don't create a tuple”. They do, and
because of that I've stopped saying that false over-simplification.

A pair of tuples as an expression is literal syntax to create a tuple
with zero items.

Also, there is another obvious way to create an empty tuple: call the
‘tuple’ type directly:

    >>> foo = tuple()
    >>> print(type(foo), len(foo))
    <class 'tuple'> 0

So the expanation that remains true when you examine it is: People
wanted a literal syntax to create a zero-length tuple. A pair of parens
is that literal syntax, and it's the parens that create the (empty)
tuple.

-- 
 \     “It is hard to believe that a man is telling the truth when you |
  `\      know that you would lie if you were in his place.” —Henry L. |
_o__)                                                          Mencken |
Ben Finney

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

#106817 — Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])

On Mon, Apr 11, 2016 at 10:45 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> So the expanation that remains true when you examine it is: People
> wanted a literal syntax to create a zero-length tuple. A pair of parens
> is that literal syntax, and it's the parens that create the (empty)
> tuple.

But parens do NOT create a one-element tuple, and that's usually where
people trip up. If you show someone this line of code:

x = ()

and ask what x will be, you might get some wrong responses, but you'll
get a lot of people correctly deducing that it's a tuple. The problem
is that people see this progression:

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

and assume they're all tuples. A better progression is this:

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

where every element is followed by a comma and every tuple is
surrounded by parentheses. In that situation, everything works. There
are slightly different rules about which parts are optional (the
parens everywhere except the first case, and the last comma everywhere
except the second), but this should be the basic form of tuple
progression.

ChrisA

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

#106820 — Re: Parens do create a tuple

Chris Angelico <rosuav@gmail.com> writes:

> On Mon, Apr 11, 2016 at 10:45 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> > So the expanation that remains true when you examine it is: People
> > wanted a literal syntax to create a zero-length tuple. A pair of parens
> > is that literal syntax, and it's the parens that create the (empty)
> > tuple.
>
> But parens do NOT create a one-element tuple, and that's usually where
> people trip up.

So let's stop saying “parens do not create a tuple”, because that's just
wantonly creating *another* stubling block.

-- 
 \         “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\    Brain, but don't you need a swimming pool to play Marco Polo?” |
_o__)                                           —_Pinky and The Brain_ |
Ben Finney

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

#106821 — Re: Parens do create a tuple

On Mon, Apr 11, 2016 at 10:57 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> On Mon, Apr 11, 2016 at 10:45 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
>> > So the expanation that remains true when you examine it is: People
>> > wanted a literal syntax to create a zero-length tuple. A pair of parens
>> > is that literal syntax, and it's the parens that create the (empty)
>> > tuple.
>>
>> But parens do NOT create a one-element tuple, and that's usually where
>> people trip up.
>
> So let's stop saying “parens do not create a tuple”, because that's just
> wantonly creating *another* stubling block.

Fair enough. Let's instead say "commas create tuples", which is true
in all cases except the singleton empty tuple. Is that near enough
that we can avoid the detail?

I'd rather be correct on the one-element case and wrong on the empty
than the other way around.

ChrisA

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

#106822 — Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])

On Sun, Apr 10, 2016, at 05:45 PM, Ben Finney wrote:
> So, let's please stop saying “parens don't create a tuple”. They do, and
> because of that I've stopped saying that false over-simplification.

I stand by "parens don't make a tuple", with the caveat that I should
have mentioned the empty tuple exception that proves the rule. The only
time you need parens is to resolve ambiguity.

To suggest that parens do make tuples confuses the issue, given things
like this:
>>> a = 1,2,3
>>> b = (1, 2, 3)

--
Stephen Hansen
  m e @ i x o k a i  . i o

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

#106826 — Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])

On 2016-04-11 10:45, Ben Finney wrote:
> Also, there is another obvious way to create an empty tuple: call
> the ‘tuple’ type directly:
> 
>     >>> foo = tuple()
>     >>> print(type(foo), len(foo))  
>     <class 'tuple'> 0

But here the parens make the tuple too:

  >>> foo = tuple
  >>> print(type(foo))
  <class 'type'>
  >>> len(foo)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: object of type 'type' has no len()

(totally just yanking chains, throwing pebbles in the pond to watch
the ripples, and otherwise sewing confusion ;-)

-tkc

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

#106830 — Re: Parens do create a tuple

Chris Angelico <rosuav@gmail.com> writes:

> Fair enough. Let's instead say "commas create tuples", which is true
> in all cases except the singleton empty tuple. Is that near enough
> that we can avoid the detail?

It's a fine thing to say, because it's simply true. Commas create
tuples.

There are some tuples that cannot be created as a literal by comma. That
does not make the statement untrue.

They are not the *only* thing that creates tuples; parens can also
create tuples. So we should avoid false statements on that score.

> I'd rather be correct on the one-element case and wrong on the empty
> than the other way around.

To say “commas create tuples” is to say an unobjectionably true
statement about Python syntax. It remains true as one continues to learn
Python.

To say “parens do not create tuples” is to lay a trap which needs to be
de-fused at some point. Better IMO never to lay that trap.

-- 
 \         “It’s a great idea to come in unencumbered by dogma but you |
  `\        can’t also be unencumbered by evidence.” —Darren Saunders, |
_o__)                                                       2015-12-02 |
Ben Finney

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

#106836 — Re: Parens do create a tuple

On Mon, 11 Apr 2016 11:41 am, Ben Finney wrote:

> Chris Angelico <rosuav@gmail.com> writes:
> 
>> Fair enough. Let's instead say "commas create tuples", which is true
>> in all cases except the singleton empty tuple. Is that near enough
>> that we can avoid the detail?
> 
> It's a fine thing to say, because it's simply true. Commas create
> tuples.

def func(arg1, arg2, arg3):
    pass

func(1, 2, 3) 

does not create a tuple (1, 2, 3) anywhere in its execution. So there are
commas that don't create a tuple. Including these:

import math, sys, time

# Python 2
print "This", "is", "not", "a", "tuple."

# Also Python 2
try:
    ...
except Exception, err:
    ...

# Any Python
del fe, fi, fo, fum



Live by pedantry, die by pedantry.

:-)


> To say “commas create tuples” is to say an unobjectionably true
> statement about Python syntax. It remains true as one continues to learn
> Python.

Really not.


> To say “parens do not create tuples” is to lay a trap which needs to be
> de-fused at some point. Better IMO never to lay that trap.

If one wishes to be both pedantic and correct, as well as long-winded and
verbose, one needs to say something like this:


In the statement

    mytuple = (1, 2, 3, 4, 5)

it is not the parentheses or round brackets which creates the tuple, it is
the commas, so this will work equally well:

    mytuple = 1, 2, 3, 4, 5


In general, you create tuples in an expression by separating the values with
commas, not by surrounding them in parentheses. Parens act to group
expressions, so they're useful for ambiguous cases such as nested tuples:

    mytuple = 1, 2, 3, (10, 20, 30), 5

or to overrule the default precedence rules:

    lambda x, y: x+1, y+2  # a tuple of (lambda, y+2)

    lambda x, y: (x+1, y+2)  # a function that returns a tuple (x+1, y+2)


or just to make the expression look nicer. As a consequence, a single item
tuple can be created with a trailing comma, with or without parens:

    mytuple = 1,
    mytuple = (1,)


The zero-element tuple is a special case. You can't have a comma on its own,
so the zero-element tuple has its own special syntax:

    mytuple = ()



-- 
Steven

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

#106839 — Re: Parens do create a tuple

On Sun, Apr 10, 2016, at 22:32, Steven D'Aprano wrote:
> def func(arg1, arg2, arg3):
>     pass
> 
> func(1, 2, 3) 
> 
> does not create a tuple (1, 2, 3) anywhere in its execution.

Well, the second argument to PyObject_Call and function_call is a tuple,
which had to come from somewhere. That may be a CPython implementation
detail, but what else could __call__'s prototype be but (self, *args,
**kwargs)?

> Live by pedantry, die by pedantry.

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

#106850 — Re: Parens do create a tuple

On Mon, 11 Apr 2016 12:51 pm, Random832 wrote:

> On Sun, Apr 10, 2016, at 22:32, Steven D'Aprano wrote:
>> def func(arg1, arg2, arg3):
>>     pass
>> 
>> func(1, 2, 3)
>> 
>> does not create a tuple (1, 2, 3) anywhere in its execution.
> 
> Well, the second argument to PyObject_Call and function_call is a tuple,
> which had to come from somewhere.

It didn't come from any Python language feature. It is a purely internal
implementation detail.

Let me put it this way: a Python expression like 3/x-1 may be parsed into a
abstract syntax tree which might look something like this:

(OPERATOR, -, 
  (OPERATOR, /, 
    (CONSTANT, 3, None, None), 
    (NAME, 'x', None, None)), 
  (CONSTANT, 1, None, None)
  )


Should we say that the / and - operators therefore create tuples? I don't
think so.



-- 
Steven

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

#106858 — Re: Parens do create a tuple

On Mon, Apr 11, 2016, at 00:08, Steven D'Aprano wrote:
> Should we say that the / and - operators therefore create tuples? I don't
> think so.

But I am talking about the tuple that is passed to FunctionType.__call__
at runtime, not a tuple created within some parser stage.

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

#106866 — Re: Parens do create a tuple

On Monday 11 April 2016 15:27, Random832 wrote:

> On Mon, Apr 11, 2016, at 00:08, Steven D'Aprano wrote:
>> Should we say that the / and - operators therefore create tuples? I don't
>> think so.
> 
> But I am talking about the tuple that is passed to FunctionType.__call__
> at runtime, not a tuple created within some parser stage.


What tuple that is passed to FunctionType.__call__?

Where is the tuple in these examples?


py> from types import FunctionType
py> FunctionType.__call__(lambda x: x+1, 23)
24
py> FunctionType.__call__(lambda x, y: str(x)+str(y), 23, 42)
'2342'

I don't see any evidence of a tuple being involved anywhere visible from 
Python code. How do you know that there's a tuple involved? (That's not a 
rhetorical question, I am genuinely curious.)

In you want to tell me that, deep inside the CPython implementation, 
function calls involve an invisible and inaccessible tuple of arguments, 
then I'll say "That's interesting, but not really relevant." There could be, 
and probably are, all sorts of places in Python's implementation where 
tuples are used internally. But that's not a language feature, its an 
implementation detail.



-- 
Steve

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

#106877 — Re: Parens do create a tuple

On Mon, Apr 11, 2016, at 04:01, Steven D'Aprano wrote:
> What tuple that is passed to FunctionType.__call__?
> 
> Where is the tuple in these examples?
> 
> 
> py> from types import FunctionType
> py> FunctionType.__call__(lambda x: x+1, 23)
> 24
> py> FunctionType.__call__(lambda x, y: str(x)+str(y), 23, 42)
> '2342'
> 
> I don't see any evidence of a tuple being involved anywhere visible from 
> Python code.

The fact that it can be called with two positional arguments in your
first example, and three in your second, is itself weak evidence for
this (more evidence is needed to show that these aren't
keyword/positional arguments with defaults) - a pure python function
that behaved as FunctionType.__call__ would have to be defined with
*args and **kwargs. And, indeed...

>>> inspect.signature(FunctionType.__call__)
<Signature (self, /, *args, **kwargs)>

I am assuming that *args' use of a tuple is defined as part of the
language. If I'm mistaken and it can be any sequence, I suppose I stand
corrected.

> How do you know that there's a tuple involved? (That's not a 
> rhetorical question, I am genuinely curious.)

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

#106842 — Re: Parens do create a tuple

On Mon, Apr 11, 2016 at 12:51 PM, Random832 <random832@fastmail.com> wrote:
> On Sun, Apr 10, 2016, at 22:32, Steven D'Aprano wrote:
>> def func(arg1, arg2, arg3):
>>     pass
>>
>> func(1, 2, 3)
>>
>> does not create a tuple (1, 2, 3) anywhere in its execution.
>
> Well, the second argument to PyObject_Call and function_call is a tuple,
> which had to come from somewhere. That may be a CPython implementation
> detail, but what else could __call__'s prototype be but (self, *args,
> **kwargs)?

On the arrivals side, sure, *args. But on the departures side, you can
use any sequence, and there's the whole thing of positional and
keyword arguments to look at. So ultimately, all you can possibly be
seeing is an implementation detail - there's no requirement that a
tuple ever be built.

ChrisA

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

#106849 — Re: Parens do create a tuple

Steven D'Aprano <steve@pearwood.info> writes:

> On Mon, 11 Apr 2016 11:41 am, Ben Finney wrote:
>
> > Chris Angelico <rosuav@gmail.com> writes:
> > 
> >> Fair enough. Let's instead say "commas create tuples", which is true
> >> in all cases except the singleton empty tuple. Is that near enough
> >> that we can avoid the detail?
> > 
> > It's a fine thing to say, because it's simply true. Commas create
> > tuples.
>
> […] there are commas that don't create a tuple.

Of course. That doesn't make the above statement false.

Commas create tuples. Also, commas do other things.

-- 
 \       “Faith, n. Belief without evidence in what is told by one who |
  `\   speaks without knowledge, of things without parallel.” —Ambrose |
_o__)                           Bierce, _The Devil's Dictionary_, 1906 |
Ben Finney

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

#106833 — Re: Parens do create a tuple

On Mon, Apr 11, 2016 at 11:41 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
>> I'd rather be correct on the one-element case and wrong on the empty
>> than the other way around.
>
> To say “commas create tuples” is to say an unobjectionably true
> statement about Python syntax. It remains true as one continues to learn
> Python.
>
> To say “parens do not create tuples” is to lay a trap which needs to be
> de-fused at some point. Better IMO never to lay that trap.

Fair. "Commas create tuples" is correct but incomplete; "parens do not
create tuples" is incorrect in a narrow way. Fortunately, technical
correctness lines up with the more useful case of helping people
understand the one-element case.

ChrisA

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

#106841 — Re: Parens do create a tuple

On Mon, 11 Apr 2016 11:51 am, Chris Angelico wrote:

> On Mon, Apr 11, 2016 at 11:41 AM, Ben Finney <ben+python@benfinney.id.au>
> wrote:
>>> I'd rather be correct on the one-element case and wrong on the empty
>>> than the other way around.
>>
>> To say “commas create tuples” is to say an unobjectionably true
>> statement about Python syntax. It remains true as one continues to learn
>> Python.
>>
>> To say “parens do not create tuples” is to lay a trap which needs to be
>> de-fused at some point. Better IMO never to lay that trap.
> 
> Fair. "Commas create tuples" is correct but incomplete; 

It's incorrect as well as incomplete. Not every comma is part of a tuple.

It's not even correct if you limit yourself to expressions, rather than all
Python statements. There are two commas in both the following expressions:

    (lambda a, b: a+2*b)(1, 2)

    "abc,def".split(",")


and yet no tuples are involved.

Yes, I'm being pedantic. I'm being more pedantic than Ben, and that's a
scary thing :-)


> "parens do not create tuples" is incorrect in a narrow way. 

It's only incorrect if you neglect to follow up by saying "with the
exception of the empty tuple". Which makes it incomplete rather than
incorrect. It is *certainly true* that in the expression:

    (1, 2, 3, 4)

the parens do not create the tuple, they are only used for grouping. So it
is misleading to say that '"parens do not create tuples" is incorrect'.


> Fortunately, technical 
> correctness lines up with the more useful case of helping people
> understand the one-element case.

You know, I've never come across anyone who has failed to understand the
one-element case from an explanation similar to this:

"Parentheses or round brackets don't create tuples, they are used for
grouping. It is the commas, not the brackets, that creates the tuple. The
only exception is the empty tuple, which is written as ()."

*especially* if you give an example of a one-element tuple to reinforce the
lesson.

Short, snappy, memorable statements like "parens don't create tuples" don't
have to be pedantically correct in all the technical details to be useful.
It is allowed to follow them with a more detailed explanation, including
any exceptions to the rule.



-- 
Steven

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

#106864 — Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

On 2016-04-11 01:33, MRAB wrote:
> A one-element tuple can be written as:
> 
>  >>> ('hello',)  
> ('hello',)
> 
> As has been said already, it's the comma that makes the tuple. The 
> parentheses are often needed to avoid ambiguity.

Except when the comma *doesn't* make the tuple:

   >>> t = ()
   >>> type(t)
   <class 'tuple'>

;-)

-tkc

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

#106832

On Mon, 11 Apr 2016 08:51 am, Fillmore wrote:

> at which point did the language designers decide to betray the
> "path of least surprise" principle and create a 'discontinuity' in the
> language?

It was March 1996, and I was there. I don't remember the date, I'm afraid.
Some of the core Python developers and users had got together in a trendy
bar in Los Angeles to discuss the future of the language before the 1.0
release. I don't remember the name of the bar, but you had to go down some
steps to get to it from the street (like the one in Cheers), and the
barkeeper was this amazingly entertaining black man in his 40s who kept us
in stitches with his anecdotes and stories about the various places he had
worked before.

Anyway, to get back to the question on hand, we were sitting around
discussing questions about the language. Remember, this was back in the
pre-1.0 days, and there was a *lot* still open for debate:

- case sensitive or insensitive?

- tabs or spaces or both?

- should floats be C singles or doubles?

- use '' for strings or ""?

among others.

I remember Tim Peters, the Timbot, arguing strongly that using doubles was a
waste of time, nobody would ever need that much precision for floating
point calculations, but the rest of us convinced Guido to ignore him.

I don't know who exactly it was that came up with the idea, because I was at
the bar ordering a round of drinks, but when I came back I remember Guido's
words like it was yesterday:

"It's not just enough to betray the principle of least surprise," he said,
and banged his fist on the table in emphasis, "any idiot can design a
surprising language like C. We have to do it in much more subtle way."

Congratulations to Fillmore. It's taken 20 years, but somebody has finally
rumbled to the fact that Python is a joke language! Guido made it all up to
prank people.

I don't think we used the word "troll" back then, but we spent the rest of
the afternoon deciding how we could best troll people with a language which
*seemed* consistent, with a single, coherent programming model, but was
actually a hodge-podge of competing paradigms, inconsistencies and
surprises for the unwary.

I mean, come on guys, in hindsight it should be obvious. Python is a
language that supports three inconsistent language paradigms:

- object oriented
- functional
- procedural

I thought that was too obvious and would give the game away, but Guido was
right. Programmers aren't that bright.

My own contribution to the gag was mutable default function arguments. I'm
really proud of that, because I came up with what seems like a perfectly
sensible and logical explanation for the behaviour, and a name for
it, "early binding", that makes it seem kinda technical and "computer
sciency", but we really added it just to be dicks and annoy folks.

Fillmore, you should feel very pleased with yourself. All the tens of
thousands of Python programmers, and millions of lines of code written in
the language, but nobody until now was able to see what you alone had the
intelligence and clarity of thought to spot. Well done!



-- 
Steven

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web