preferring [] or () in list of error codes?

[Gunter Henriksen]

[In this tuple]

dodge_city = (1781, 1870, 1823)
(population, feet_above_sea_level, establishment_year) = dodge_city
each index in the sequence implies something very
different about each value. The semantic meaning
of each index is *more* than just the position in
the sequence; it matters *for interpreting that
component*, and that component would not mean the
same thing in a different index position. A tuple
is the right choice, for that reason.

I think I would have difficulty holding a position
that this should not be a class (or equivalent via
namedtuple()) or a dict. It seems to me like a case
could be made that there are far more situations where
it makes sense to use tuples as immutable sequences than
as objects whose attributes are named implicitly by an
index. This dodge_city definitely does not seem to me
like a good candidate for a plain tuple.

 

[Gunter Henriksen]

Try, then, this tuple:

event_timestamp = (2009, 06, 04, 05, 02, 03)
(year, month, day, hour, minute, second) = event_timestamp

A list would be wrong for this value, because each position in the
sequence has a specific meaning beyond its mere sequential position. Yet
it also matters to the reader that these items are in a specific
sequence, since that's a fairly standard ordering for those items.

In this case, a tuple is superior to a list because it correctly conveys
the semantic meaning of the overall value: the items must retain their
sequential order to have the intended meaning, and to alter any one of
them is conceptually to create a new timestamp value.

I totally agree about anything to do with immutability,
I think the relative ordering of the elements in this
example may be orthogonal to the concept of a tuple
as an object whose elements have a semantic meaning
implicitly defined by location in the sequence... in
other words knowing that element i+1 is in some sense
ordinally smaller than element i does not give me much
information about what element i+1 actually is.

To me a timestamp could be (date, time), or (days,
seconds, microseconds) (as in datetime.timedelta()), so
it is not clear to me that using a tuple as something
where the semantic meaning of the element at position i
should readily apparent would be the best approach
for timestamps, or enough to distinguish list and tuple
(in other words I am not suggesting a dict or class).

In the case of something like (x, y) or (real, imag),
or (longitude, latitude), or any case where there is
common agreement and understanding, such that using
names is arguably superfluous... I think in those
cases the concept makes sense of a tuple as a sequence
of attributes whose elements have a semantic meaning
implicitly defined by position in the sequence. My
feeling is the number of cases where tuples are better
than lists for that is small relative to the number of
cases where tuple adds value as an immutable list.

I do not mean to be suggesting that a tuple should only
ever be used or thought of as a "frozenlist" though.

 

[Gunter Henriksen]

event_timestamp = (2009, 06, 04, 05, 02, 03)

(year, month, day, hour, minute, second) = event_timestamp

[...]

The point of each position having a different semantic meaning is that
tuple unpacking works as above. You need to know the meaning of each
position in order to unpack it to separate names, as above.

So two tuples that differ only in the sequence of their items are
different in meaning. This is unlike a list, where the sequence of items
does *not* affect the semantic meaning of each item.

I do not feel the above is significantly different enough from

event_timestamp = [2009, 06, 04, 05, 02, 03]
(year, month, day, hour, minute, second) = event_timestamp

event_timestamp = (2009, 06, 04, 05, 02, 03)
(year, month, day, hour, minute, second) = event_timestamp

event_timestamp = [2009, 06, 04, 05, 02, 03]
[year, month, day, hour, minute, second] = event_timestamp

to suggest tuples are really adding significant value
in this case, especially when I can do something like

event_timestamp = (2009, 06, 04, 05, 02, 03)
(year, month, day, hour, second, minute) = event_timestamp

and not have any indication I have done the wrong thing.

I guess to me, fundamentally, the interpretation of
tuple as a sequence whose elements have semantic meaning
implicitly defined by position is a relatively abstract
intrepretation whose value is dubious relative to the
value of immutability, since it seems like a shortcut
which sacrifices explicitness for the sake of brevity.

I would feel differently if seemed unusual to find good
Python code which iterates through the elements of a
tuple as a variable length homogenous ordered collection.
But then I would be wishing for immutable lists...

 

[Mel]

Gunter Henriksen wrote:
[ ... ]

I guess to me, fundamentally, the interpretation of
tuple as a sequence whose elements have semantic meaning
implicitly defined by position is a relatively abstract
intrepretation whose value is dubious relative to the
value of immutability, since it seems like a shortcut
which sacrifices explicitness for the sake of brevity.

The immutability makes it easier to talk about the semantic meanings. After
you do

event_timestamp = (2009, 06, 04, 05, 02, 03)

there's nothing that can happen to the tuple to invalidate

(year, month, day, hour, minute, second) = event_timestamp

even though, as you say, there's nothing in the tuple to inform anybody
about the year, month, day, ... interpretation.

And of course there's nothing in a C struct object that isn't in the
equivalent Python tuple. The difference is that the C compiler has arranged
all the outside code that uses the struct object to use it in the correct
way. The only object I've found in Python that truly replaces a struct
object in C is a dict with string keys -- or an object that uses such a dict
as its __dict__.


Mel.

 

[Albert van der Horst]

But practicality beats purity -- there are many scenarios where we make
compromises in our meaning in order to get correct, efficient code. E.g.
we use floats, despite them being a poor substitute for the abstract Real
numbers we mean.

In addition, using a tuple or a list in this context:

if e.message.code in (25401,25402,25408):

is so idiomatic, that using a set in it's place would be distracting.
Rather that efficiently communicating the programmer's intention, it
would raise in my mind the question "that's strange, why are they using a
set there instead of a tuple?".

As a newby I'm really expecting a set here. The only reason my mind
goes in the direction of 3 items is that it makes no sense in
combination with ``in''. That makes this idiom one that should be killed.

"
point1 = (0,1,0)
point2 = (1,0,0)
point3 = (0,0,1)
for i in (point1,point2, point3):
....
" ???

I don't think so.
At least I would do

"
for i in [point1,point2,point3]:
statements
"

But I greatly prefer a set

"
for i in {point1,point2,point3}:
statements
"
Because a set is unorderded, this would convey to the
the compiler that it may evaluate the three statements concurrently.
For a list I expect the guarantee that the statements are
evaluated in order.
For a tuple I don't know what to expect. That alone is sufficient
reason not to use it here.

[Yes I know { } doesn't denote a set. I tried it. I don't
know how to denote a set ... ]

Groetjes Albert.