Super Tuples [or why python is so good]

[Manuel Gutierrez Algaba]

On Wed, 29 Dec 1999 08:44:23 -0500, Paul Prescod <paul at prescod.net> wrote:
>
> * why does Python need an immutable list type but not an immutable
>dictionary?

Because a tuple is the simplest way of saying:
there are three things a,b,c and they're ordered thus: (a,b,c)
There is no simpler way  to say it. 

An inmutable dictionary... perhaps subclassing and removing 
__set__ ?? :)


>has a special "meaning." The time library is a perfect example of this:
>
>"The time tuple as returned by gmtime(), localtime(), and strptime(),
>and accepted by asctime(), mktime() and strftime(), is a tuple of 9
>integers: year (e.g. 1993), month (1-12), day (1-31), hour (0-23),
>minute (0-59), second (0-59), weekday (0-6, monday is 0), Julian day
>(1-366) and daylight savings flag (-1, 0 or 1)."
>
>The primary weakness with the time library is that you have to index
>daylight savings flag by (for example) [9] instead of .daylight .

This is a perfect example of what to do in those cases:
index_year = 0
index_month = 1
index_day = 2
... 
index_daylight = 9

time.asctime()[time.index_daylight]

And this example is probably the only one that would justify such
a thing. 

Being OO means that everything should be considered and object,
so the more objects we use and in a clearer way ( defining them
as objects ) the better for the purity of the language and 
uniformity of the code. Imagine that python would have a big 
set of iterators (loop's, while, selectors...) and a whole bunch
of tuple,list or dicts functions ( think in Ruby list for 
examples ), then python would have lost most of its personality:
a simple syntax. And instead of inter-object relationships we'd
have simple algebraic relationships very nice for Haskell
or any mathematic rubish but a disaster for those (like me) that
like utter simplicity in the relationships:
- *Many* objects linked by very simple constructs ( inheritance
and has-to)
- Each object simple enough to handle not too many relationships
- Each object is linked to "a real world " idea or it's 
a clearly "defined" part of a "big" idea.

I don't like those python codes that hold dozens of lines of code
inside a function ( or hundreds of lines inside a class).

Any change of syntax towards "algebraization"(haskellation/
mathematicalization) : many operators, many "abstractions",
*long* formulae and so on, would be **really** nasty.

Java is a cast oriented language, perl is a criptic oriented language,
python is a simplicity oriented language, a complex python
would not be python anymore.


 Having little but powerful enough constructs 
helps to the orthogonality of the code. 

A tuple behaving almost an object doesn't sound orthogonal. And
it could turn into a nightmare. Imagine this:

Step 1 ) We have tuples this way : o = (time= 23, name= "alfa", g = 1)
Step 2) We allow keywords for those tuples
           t =  (time = 23, name="alfa", g= 1).keys()  would
 return time, alfa, g
 and constructs like t['time' ] = 28 
          
Step 3) We allow procedures for those tuples
      
def print_time(t):
   print t.time

t = (t, print_time) # this means that print_time is associated
with the tuple itself

Well you see, after some steps we have tuples that behave like
dicts, tuples or objects. Very different programming styles
would arise and a poorer readibility of python code.  



-- 
Manolo