Hi, Jean-Claude; thanks for your mail.

GV> Show them [1, "two"] and they (a) understand it, and (b) think GV> it's cool; show them (1, "two") as well and they become confused. Because they mean the same thing, I suppose?

Redundancy seems to confuse people (did someone say "Perl" or "PL/1"?)

GV> If tuples didn't already exist, would anyone ask for them to GV> to be added to the language today?

Why indeed? They are more space-efficient, and they are immutable, but those are both purely technical reasons.

Agreed --- I could understand having tuples as an internal data structure, but do not understand why they are exposed to users. If Python had been a type-checked, type-inferenced langauge from the beginning, I guess I could see it... As for the immutability:

...

...

...

x = [1, 2] y = (10, x, 11) y[1][0] = 999 y (10, [999, 2], 11)

GV> I've never had any trouble explaining int vs. float to students at Because ints and floats differ in meaning?

People are taught "whole numbers" vs. "fractions" at an early age.

GV> I've also never had any trouble explaining int vs. long GV> (memory vs. accuracy).

That's interesting. Tuples vs. lists are a similar tradeoff, though both memory-savings and immutability are CS-type issues, whereas non- programmers are more likely to consider accuracy a meaningful tradeoff?

I just show them the range of values that can be represented in 8, 16, 32, or 64 bits (for ints); 'float' vs. 'double' follows naturally from that. Again, I've never had any trouble with this one... Interestingly, I've also never had trouble with strings being immutable. I point out to people that the number 123 isn't mutable, and that supposedly-mutable strings in other languages are really allocating/deallocating memory behind your back; everybody nods, and we carry on. Greg

[Greg Wilson]

(Hope no-one minds me keeping this thread alive --- as I said in my first reply to Tim Peters, there's either something very fundamental here, or a "just-so" story...)

Fundamental but not obvious, and possibly a matter of taste. I can only repeat myself at this point, but I'll try minor rewording <wink>: I write my code deliberately to follow the guidelines I mentioned (tuples for fixed heterogenous products, lists for indefinite homogenous sequences). Perhaps I see it that way because I love Haskell too, where those "guidelines" are absolute requirements (btw, is Haskell being silly here too in your view?). In Python, I find that following them voluntarily is a truly effective aid to both reasoning and clarity. Give it a try! The distinction between ints and floats is much more a "just so" story to me: your students never questioned it because their previous languages (Fortran and C++ and ...) told them the same story. Now they suck on it for comfort <wink>. But, e.g., Perl got along fine for years without a distinct "int" type, and added one (well, added a funky "use int" pragma) purely for optimization. At the language level there's really little sense to this distinction -- it's "play nice with the guts of the machine" cruft. Now given Python's use to script various C interfaces more or less directly, I'd actually be loathe to see Python give up the distinction entirely. But, if you think about it *hard* (accept my "start from ground zero" invitation), I expect you'll find there's far less justification for it than you may currently believe. Heck, floating point is even faster than ints on some platforms <wink>.

... If tuples didn't already exist, would anyone ask for them to to be added to the language today?

I probably would, because I grew to like the distinction so much in Haskell, and would *expect* the Haskell benefits to carry over to Python as well. Note that I've never made the "dict key" argument here, because I don't think it's fundamental. However, if you hate tuples you're going to have to come up with a reasonable alternative (if that's the deepest use you can see for them now, fine, then at least address it for real *at* that level ...).

Show them [1, "two"] and they (a) understand it, and (b) think it's cool; show them (1, "two") as well and they become confused.

So don't show people [1, "two"] at first <0.5 wink>.

... I've never had any trouble explaining int vs. float to students at any level; I've also never had any trouble explaining int vs. long (memory vs. accuracy).

That last tradeoff is an artifact of the current implementation; there's no fundamental reason for this tension. Python already has different concrete implementations of a single "integer" interface, and essentially the only things needed to integrate int and long fully are changing the literal parsers to ignore "L", and changing the guts of the "if (overflow) {}" bits of intobject.c to return a long instead of raising an exception (a nice refinement would be also to change the guts of longobject.c to return an int for "small" longs). Note that, e.g., high end HP calculators use about a dozen(!) different internal representations for its one visible "number" type (to save precious space), and users aren't even aware of this. It's an old implementation trick. and-a-good-one-ly y'rs - tim

Greg Wilson wrote:

1) As long as it's just a convention, that only a handful of people strictly conform to, it's a pedagogic wart --- every Python book or tutorial I've read spends at least a paragraph or two justifying tuples' existence.

2) I tried in my first class at LANL to say "tuples are like records". One guy put his hand up and said, "Records that you access using integer indices instead of names? *laugh* Well, it's good to see that Fortran-66 is alive and well!" *general laughter*

The point is a serious one --- Pascal taught us to give meaningful names to the fields in structures, and then tuples take us back to "oh, I think the day of the month is in the fourth field --- or is it the fifth?"

When this comes up from newbies on the list (which is *much* less often than a number of other so-called warts), I explain the difference, and then say, "If you don't know which to use, use a list. One day it will become obvious." Now, experience (not a priori reasoning) tells me that this is safe: x, y = tpl and this is not: x, y = lst There's not much use in arguing about it, because both require trust in the programmer. It's just the in the first case, you *can* trust the programmer, and in the second you *can't*. Even when the programmer is yourself. The fact that you don't like "zen" arguments doesn't mean you have to make them. Don't defend it at all. Just point out that most Python programmers consider tuples very valuable and move on. In general, it's very hard to "defend" Python on theoretical grounds. The newsgroup is littered with posts from OO cultists berating Python for it's primitive object model. They either move on, or shut up once they realize that Python's object model is a lot cleaner *in practice* than the theoretically correct crap they cut their teeth on. (What astounds me is the number of functional programmers who are sure that Python is modeled after a functional language.) - Gordon

From: Gordon McMillan <gmcm@hypernet.com>

The fact that you don't like "zen" arguments doesn't mean you have to make them. Don't defend it at all. Just point out that most Python programmers consider tuples very valuable and move on.

Doesn't really work with argumentative, opinionated and poorly informed students, which are majority in the computer field =).

In general, it's very hard to "defend" Python on theoretical grounds.

The point is not theoretical grounds, but, at least in my case, backing up the claim that Python has an elegant, spare design. Tuples show up as challenging that claim, as do some of the other warts on AMK's pages. I expect some of those to go away naturally (e.g. apply(Base.__init__, (self,)+args, kw) will mutate naturally to: Base.__init__(self, *args, **kw) but the tuples will stay. I'm just looking for a better pedagogical trick, not arguing against them on theoretical grounds. --david

On Sat, 5 Feb 2000, Andrew Kuchling wrote:

... Not quite *that* simple; you'd also have to change various bits of the core that currently do PyInt_Check(whatever) to also accept longs. I just sent off a patch to make long*sequence legal, but there's still slicing and indexing to take care of: list[0L:5L] isn't currently legal.

The Solaris large-file patch that makes .tell() return a long is probably going to turn up more errors like this. Making ints and long ints integerchangeable would be an *excellent* idea. Possible for 1.6? Maybe, if GvR indicates it should be a priority. 'grep -l PyInt_Check' over the Python source code lists lots of Modules, most of the files in Objects/, and 5 files in Python/ (ceval, marshal, pythonrun, structmember, and traceback).

Priority or not, it won't happen if the patch is not available :-) As we say in Apache-land, "+1 on concept" Cheers, -g ps. Python-land translation: I agree with the concept ... go for it -- Greg Stein, http://www.lyra.org/

...

The Solaris large-file patch that makes .tell() return a long is probably going to turn up more errors like this. Making ints and long ints integerchangeable would be an *excellent* idea. Possible for 1.6? Maybe, if GvR indicates it should be a priority. 'grep -l PyInt_Check' over the Python source code lists lots of Modules, most of the files in Objects/, and 5 files in Python/ (ceval, marshal, pythonrun, structmember, and traceback).

The idea is very old, and has come up several times, but I don't recall Guido ever saying anything about it. So it's safe to conclude it *hasn't* been a priority for him. I can't channel him on this issue. I'm personally in favor of merging them, but along with Konrad (Hinsen) am also in favor of doing a lot more "numeric merging" in Python 3000. It's really unclear to me whether the distinction in Python1 can be erased without breaking programs -- but can't make time to think about it now, either. Sorry!

I'm not sure I want to make this a priority given the accellerated 1.6 schedule, but I certainly think this is the way of the future, and I don't expect many backwards compatibility problems... --Guido van Rossum (home page: http://www.python.org/~guido/)

Hi, Jean-Claude; thanks for your mail.

GV> Show them [1, "two"] and they (a) understand it, and (b) think GV> it's cool; show them (1, "two") as well and they become confused. Because they mean the same thing, I suppose?

Redundancy seems to confuse people (did someone say "Perl" or "PL/1"?)

GV> If tuples didn't already exist, would anyone ask for them to GV> to be added to the language today?

Why indeed? They are more space-efficient, and they are immutable, but those are both purely technical reasons.

Agreed --- I could understand having tuples as an internal data structure, but do not understand why they are exposed to users. If Python had been a type-checked, type-inferenced langauge from the beginning, I guess I could see it... As for the immutability:

...

...

...

x = [1, 2] y = (10, x, 11) y[1][0] = 999 y (10, [999, 2], 11)

GV> I've never had any trouble explaining int vs. float to students at Because ints and floats differ in meaning?

People are taught "whole numbers" vs. "fractions" at an early age.

GV> I've also never had any trouble explaining int vs. long GV> (memory vs. accuracy).

That's interesting. Tuples vs. lists are a similar tradeoff, though both memory-savings and immutability are CS-type issues, whereas non- programmers are more likely to consider accuracy a meaningful tradeoff?

I just show them the range of values that can be represented in 8, 16, 32, or 64 bits (for ints); 'float' vs. 'double' follows naturally from that. Again, I've never had any trouble with this one... Interestingly, I've also never had trouble with strings being immutable. I point out to people that the number 123 isn't mutable, and that supposedly-mutable strings in other languages are really allocating/deallocating memory behind your back; everybody nods, and we carry on. Greg

[Greg Wilson]

(Hope no-one minds me keeping this thread alive --- as I said in my first reply to Tim Peters, there's either something very fundamental here, or a "just-so" story...)

Fundamental but not obvious, and possibly a matter of taste. I can only repeat myself at this point, but I'll try minor rewording <wink>: I write my code deliberately to follow the guidelines I mentioned (tuples for fixed heterogenous products, lists for indefinite homogenous sequences). Perhaps I see it that way because I love Haskell too, where those "guidelines" are absolute requirements (btw, is Haskell being silly here too in your view?). In Python, I find that following them voluntarily is a truly effective aid to both reasoning and clarity. Give it a try! The distinction between ints and floats is much more a "just so" story to me: your students never questioned it because their previous languages (Fortran and C++ and ...) told them the same story. Now they suck on it for comfort <wink>. But, e.g., Perl got along fine for years without a distinct "int" type, and added one (well, added a funky "use int" pragma) purely for optimization. At the language level there's really little sense to this distinction -- it's "play nice with the guts of the machine" cruft. Now given Python's use to script various C interfaces more or less directly, I'd actually be loathe to see Python give up the distinction entirely. But, if you think about it *hard* (accept my "start from ground zero" invitation), I expect you'll find there's far less justification for it than you may currently believe. Heck, floating point is even faster than ints on some platforms <wink>.

... If tuples didn't already exist, would anyone ask for them to to be added to the language today?

I probably would, because I grew to like the distinction so much in Haskell, and would *expect* the Haskell benefits to carry over to Python as well. Note that I've never made the "dict key" argument here, because I don't think it's fundamental. However, if you hate tuples you're going to have to come up with a reasonable alternative (if that's the deepest use you can see for them now, fine, then at least address it for real *at* that level ...).

Show them [1, "two"] and they (a) understand it, and (b) think it's cool; show them (1, "two") as well and they become confused.

So don't show people [1, "two"] at first <0.5 wink>.

... I've never had any trouble explaining int vs. float to students at any level; I've also never had any trouble explaining int vs. long (memory vs. accuracy).

That last tradeoff is an artifact of the current implementation; there's no fundamental reason for this tension. Python already has different concrete implementations of a single "integer" interface, and essentially the only things needed to integrate int and long fully are changing the literal parsers to ignore "L", and changing the guts of the "if (overflow) {}" bits of intobject.c to return a long instead of raising an exception (a nice refinement would be also to change the guts of longobject.c to return an int for "small" longs). Note that, e.g., high end HP calculators use about a dozen(!) different internal representations for its one visible "number" type (to save precious space), and users aren't even aware of this. It's an old implementation trick. and-a-good-one-ly y'rs - tim

Greg Wilson wrote:

1) As long as it's just a convention, that only a handful of people strictly conform to, it's a pedagogic wart --- every Python book or tutorial I've read spends at least a paragraph or two justifying tuples' existence.

2) I tried in my first class at LANL to say "tuples are like records". One guy put his hand up and said, "Records that you access using integer indices instead of names? *laugh* Well, it's good to see that Fortran-66 is alive and well!" *general laughter*

The point is a serious one --- Pascal taught us to give meaningful names to the fields in structures, and then tuples take us back to "oh, I think the day of the month is in the fourth field --- or is it the fifth?"

When this comes up from newbies on the list (which is *much* less often than a number of other so-called warts), I explain the difference, and then say, "If you don't know which to use, use a list. One day it will become obvious." Now, experience (not a priori reasoning) tells me that this is safe: x, y = tpl and this is not: x, y = lst There's not much use in arguing about it, because both require trust in the programmer. It's just the in the first case, you *can* trust the programmer, and in the second you *can't*. Even when the programmer is yourself. The fact that you don't like "zen" arguments doesn't mean you have to make them. Don't defend it at all. Just point out that most Python programmers consider tuples very valuable and move on. In general, it's very hard to "defend" Python on theoretical grounds. The newsgroup is littered with posts from OO cultists berating Python for it's primitive object model. They either move on, or shut up once they realize that Python's object model is a lot cleaner *in practice* than the theoretically correct crap they cut their teeth on. (What astounds me is the number of functional programmers who are sure that Python is modeled after a functional language.) - Gordon

From: Gordon McMillan <gmcm@hypernet.com>

The fact that you don't like "zen" arguments doesn't mean you have to make them. Don't defend it at all. Just point out that most Python programmers consider tuples very valuable and move on.

Doesn't really work with argumentative, opinionated and poorly informed students, which are majority in the computer field =).

In general, it's very hard to "defend" Python on theoretical grounds.

The point is not theoretical grounds, but, at least in my case, backing up the claim that Python has an elegant, spare design. Tuples show up as challenging that claim, as do some of the other warts on AMK's pages. I expect some of those to go away naturally (e.g. apply(Base.__init__, (self,)+args, kw) will mutate naturally to: Base.__init__(self, *args, **kw) but the tuples will stay. I'm just looking for a better pedagogical trick, not arguing against them on theoretical grounds. --david

On Sat, 5 Feb 2000, Andrew Kuchling wrote:

... Not quite *that* simple; you'd also have to change various bits of the core that currently do PyInt_Check(whatever) to also accept longs. I just sent off a patch to make long*sequence legal, but there's still slicing and indexing to take care of: list[0L:5L] isn't currently legal.

The Solaris large-file patch that makes .tell() return a long is probably going to turn up more errors like this. Making ints and long ints integerchangeable would be an *excellent* idea. Possible for 1.6? Maybe, if GvR indicates it should be a priority. 'grep -l PyInt_Check' over the Python source code lists lots of Modules, most of the files in Objects/, and 5 files in Python/ (ceval, marshal, pythonrun, structmember, and traceback).

Priority or not, it won't happen if the patch is not available :-) As we say in Apache-land, "+1 on concept" Cheers, -g ps. Python-land translation: I agree with the concept ... go for it -- Greg Stein, http://www.lyra.org/

...

The Solaris large-file patch that makes .tell() return a long is probably going to turn up more errors like this. Making ints and long ints integerchangeable would be an *excellent* idea. Possible for 1.6? Maybe, if GvR indicates it should be a priority. 'grep -l PyInt_Check' over the Python source code lists lots of Modules, most of the files in Objects/, and 5 files in Python/ (ceval, marshal, pythonrun, structmember, and traceback).

The idea is very old, and has come up several times, but I don't recall Guido ever saying anything about it. So it's safe to conclude it *hasn't* been a priority for him. I can't channel him on this issue. I'm personally in favor of merging them, but along with Konrad (Hinsen) am also in favor of doing a lot more "numeric merging" in Python 3000. It's really unclear to me whether the distinction in Python1 can be erased without breaking programs -- but can't make time to think about it now, either. Sorry!

I'm not sure I want to make this a priority given the accellerated 1.6 schedule, but I certainly think this is the way of the future, and I don't expect many backwards compatibility problems... --Guido van Rossum (home page: http://www.python.org/~guido/)