Help understanding the decisions *behind* python?

[Raymond Hettinger]

While nothing in the list/tuple code requires you to make that

I might be wrong, but I get the impression that many people don't indeed "get
it" and use tuples as static arrays and lists when the array needs to be
dynamically resized. This is certainly how I use them as well.

This would tend to show that Guido's notion here was not particularly
intuitive.

No, it just shows that they are not Dutch ;-)

IIRC, Aahz once made an eloquent statement about how languages aren't
intuitive because different people have different intuitions. The
fact
is that every language has its own set of ways. People usually pick-
up
on what is Pythonic in a short order. The problem comes when people
decide-in-advance how the language ought to be -- it takes them longer
to pick-up the culture and idioms. More than one person here has
observed that the time to learn to program Pythonically is inversely
proportional to their experience in Java.

It is perfectly okay for you to use tuples for statically sized
arrays.
That isn't wrong. It is against then grain though. Guido articulated
his concept early and many of his minions (me included) have designed
the APIs and optimizations to flow nicely with his preferred way of
doing things.


Raymond

 

[Raymond Hettinger]

A tuple is really a frozen list.  Arguably, frozen objects
should have been a general concept.  Conceptually, they're
simple - once "__init__" has run, there can be no more changes
to fields of the object.

I would argue that freezing and thawing (making the container
statefull)
is the proverbial road to hell paved with good intentions. It is
roughly in the same category as dynamic scoping -- programs become
harder to analyze for correctness -- code that used to work can
break because something froze it along the way (perhaps to use it
as a key for dict or set in a caching function) or because something
unfroze it (so it could mutate a value).


Raymond

 

[Gabriel Genellina]

En Fri, 31 Jul 2009 17:26:58 -0300, Emmanuel Surleau

My understanding is that, in this context, it's not so much data types
which
are heterogeneous, but the semantic meaning of the data. For instance, a
tuple
containing (first_name, last_name, address) would be a "legitimate"
tuple, but
not a tuple containing (address, address, address), which, if we follow
Guido's philosophy, ought to be represented as a list.

Note that years ago the distinction was much stronger: tuples had NO
methods at all. All you could do with a tuple was: len(t), t, t1+t2,
t*n, e in t, for e in t
Being so "crippled", thinking of tuples just as immutable lists probably
wasn't so natural.

 

[Dennis Lee Bieber]

I might be wrong, but I get the impression that many people don't indeed "get
it" and use tuples as static arrays and lists when the array needs to be
dynamically resized. This is certainly how I use them as well.

This would tend to show that Guido's notion here was not particularly
intuitive.

Might have been influenced by database theory (and, in my
experience, most DB-API2 implementations follow that)...

A "tuple" in database theory is what most would call a row or
record. Since rows/records contain fields of different types of data...

Notice how .fetchall() returns a list of tuples (and not a tuple of
lists <G>)

(And, what may surprise neophytes, the "relation" in "relational
database" is what most applications call a "table" -- it is NOT a
reference to the linkage of foreign keys in one "table" to the primary
key of another "table" via relational (<, =, >) operations)
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[sturlamolden]

We're not looking to start any arguments or religious wars and we're
not asking that python be changed into something its not. We'd simply
like to understand the decision behind the lists and tuple structures.
We feel that in not "getting" the difference between the two types we
may be missing out on using these data structures to their full
potential.

A crude simplification would be:

- A Python programmer will use a tuple where a C programmer will use a
struct.

- Python and C programmers use lists and arrays similarly.

Tuples are used for passing arguments to and from a function. Common
use of tuples include multiple return values and optional arguments
(*args).

It has already been mentioned that tuples are immutable and can be
used as dictionary keys.

 

[sturlamolden]

 More than one person here has
observed that the time to learn to program Pythonically is inversely
proportional to their experience in Java.

I believe it is opposite. The longer the Java experience, the longer
it takes to program pythonically. The correlation is not inverse. In
particular, programmers accustomed to Java or C++ seem to use for-
loops awfully lot. And when they do, they always loop over a sequence
of integers, and use these as array indices. They consequently use a
class where a tuple would be more appropriate, never return multiple
values from functions, etc. Due to their coding style, they produce
programs that are notoriously inefficient, and blame this on 'Python
being slow'. Unlearning the idioms from Java takes a while. Python is
not Java and should not be programmed as such.

On the other hand, I found that my experience with MATLAB helped me a
lot on picking up a pythonical style quickly.

 

[Nobody]

I believe it is opposite. The longer the Java experience, the longer
it takes to program pythonically. The correlation is not inverse. In
particular, programmers accustomed to Java or C++ seem to use for-
loops awfully lot. And when they do, they always loop over a sequence
of integers, and use these as array indices.

It would be more accurate to say that of programmers who are *only*
accustomed to Java or C++. I've been using C for 80-90% of my code for 25
years, and I wouldn't normally loop over the indices. But then the other
10-20% is Lisp, Tcl, Haskell, PostScript and, more recently, Python.

OTOH, using a "for" loop when you could use a generator means less work
when you need to make a minor change and a generator is no longer
sufficient.

 

[sturlamolden]

OTOH, using a "for" loop when you could use a generator means less work
when you need to make a minor change and a generator is no longer
sufficient.

It's not just that. It is e.g. using a for loop and indexes instead of
a slice. E.g.

for i in range(10): # Java idiom
a = b[i+1]

instead of

a[:10] = b[1:11] # Pythonic

 

[sturlamolden]

It's intuitive if you come to Python knowing other languages with  
tuples (which are mostly functional, and in which tuples are *never*  
sequences/iterables). At the end of the day, and if Guido's intention  
truly was what Raymond says, implementing tuples as immutable sequence  
was a mistake. And the documentation is to blame as well: in it,  
tuples are clearly described as a *sequence* type, not a *structure*  
type.

That depends on the readers' preconceptions: Only when the reader have
knowledge of C structs, Pascal records, or Java classes should this
matter. The naïve reader will not have preconceptions about a
difference between "structure types" and "sequence types". A more
advanced C programmer will also know that a struct is a form of a
sequence in C: you can e.g. memcpy any struct to a char array.

 

[Dave Angel]

A crude simplification would be:

- A Python programmer will use a tuple where a C programmer will use a
struct.

- Python and C programmers use lists and arrays similarly.

Tuples are used for passing arguments to and from a function. Common
use of tuples include multiple return values and optional arguments
(*args).

It has already been mentioned that tuples are immutable and can be
used as dictionary keys.

I think collections.namedtuple, introduced in Python 2.6, might help
bridge the gap between a traditional tuple and a C struct.

 

[John Nagle]

That's from Mesa, the Xerox PARC language of the 1970s.

Mesa used tuples for subroutine arguments in a very straightforward
way. Every function took one tuple as an argument, written as parameters
in parentheses separated by commas. Every function returned a tuple
as an argument. This had a nice symmetry; function outputs and
function inputs had the same form. Mesa was the first language
to break through the "single return value" syntax problem.

Python doesn't go that far.

John Nagle

 

[alex23]

Every function returned a tuple as an argument. This had a nice
symmetry; function outputs and function inputs had the same form.  
Mesa was the first language to break through the "single return
value" syntax problem.

    Python doesn't go that far.

I assume here you're referring to the former point and not the latter?

 

[greg]

Mesa used tuples for subroutine arguments in a very straightforward
way. Every function took one tuple as an argument

Python doesn't go that far.

I believe that a very early version of Python did do
something like that, but it was found to be a bad idea,
because there was an ambiguity between multiple args and
a single arg that happened to be a tuple.

This was before keyword arguments existed -- they would
have been hard to incorporate into the old scheme.

 

[Masklinn]

That's from Mesa, the Xerox PARC language of the 1970s.

Mesa used tuples for subroutine arguments in a very straightforward
way. Every function took one tuple as an argument, written as
parameters
in parentheses separated by commas.

Most statically typed functional languages seem to do pretty much the
same: uncurried functions really take a tuple as single argument
rather than multiple arguments, using pattern matching to make it look
like multiple arguments. Then again, most of them seem to default to
curried functions these days, which is nice.