"Actually Dr. DiNucci is right in a subtle way: zip( ) is not a function,
it's a type, and primitive types are callables in Python. I should
follow-up on that point on edu-sig (too technical for math-teach). Thanks
Dave. zip objects, like ranges, enumerations, other sequential things, are
objects in their own right. I think it's behaving like a function but its
arguments appear non-deterministic and that clouds the picture." -- from
FaceBook
I wonder how long it will be, on math-teach, before
somebody points that out: zip( ) is not a function in
Python. It looks like a function but it's a type.
All the type names serve as callables that make
instances of themselves. That doesn't make them
functions though, not technically, not in Python.
Dr. DiNucci's point was that zip( ) is acting more
like a relation than a function in that the resulting
groupings seem non-deterministic and therefore
f(a) --> c and f(a) --> d are both True. Functions
aren't like that (per Dolciani).
However if we express it this way:
list(zip(set0, set1, set2... setn))
---> gives
[(set0.pop(), set1.pop(), set2.pop().... setn.pop()),
(set0.pop(), set1.pop(), set2.pop().... setn.pop()),
(set0.pop(), set1.pop(), set2.pop().... setn.pop()),
... number of tuples = length of shortest set
]
then that could be seen as a deterministic rule
that's not one-to-many. setx.pop() is somehow
non-deterministic, but zip( ) is not. You could say
(set0.pop(), set1.pop(), set2.pop().... setn.pop())
is an "equivalence class" wherein ('planet', 'aardvark',
'orange') and ('comet', 'aardvark', 'apple') are both
considered "the same" i.e. three delegates from
the three sets, details don't matter.
You get some permutations.
All zips of the same input sets give what we
*might call* the same output -- and so it's a
function in the mathematical sense.
Kirby
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
