tuple.index()
Nick Maclaren
Why doesn't the tuple type have an index method? It seems such a
bizarre restriction that there must be some reason for it. Yes,
I know it's a fairly rare requirement.
Regards,
Nick Maclaren.
Fredrik Lundh
> Why doesn't the tuple type have an index method? It seems such a
> bizarre restriction that there must be some reason for it.
hah! not being able to remove or add things to tuples is an even
bizarrer restriction!
</F>
Nick Maclaren
In article <mailman.1588.1166096...@python.org>,
Eh? Why?
My understanding of the difference between a tuple and a list is
PRECISELY that the former is immutable and the latter mutable.
But an index method makes precisely as much sense on an immutable
sequence as it does on a mutable one.
Regards,
Nick Maclaren.
Glenn Hutchings
> Why doesn't the tuple type have an index method? It seems such a
> bizarre restriction that there must be some reason for it.
In fact, tuples have no non-__underscored__ methods at all. The list
count() method would also be useful for tuples, since it doesn't modify
anything. I have no idea why they aren't implemented either.
Glenn
Simon Brunning
> Well, if that were so, it would explain things. But lists AREN'T
> necessarily homogeneous!
>
> >>> a=[52,"abc",[1,2],5.6]
> >>> print repr(a)
> [52, 'abc', [1, 2], 5.5999999999999996]
It's not a technical restriction, as I said, but it's what lists are *for*.
Indeed, it *can't* be a technical restriction, because, as I said, by
'type' I wasn't referring to anything technical. A list might contain,
for example, "things to process". That's a conceptual kind of thing,
so the list is conceptually homogeneous, but technically speaking, the
list might contain instances of any class (or built-in type).
A good example of a tuple, OTOH, might be a database tuple, i.e. a row
returned from an RDBMS. Even if all the tables columns are of the same
type - say, strings - it doesn't mean that they are interchangeable.
Their position has semantic significance - it means something.
Make sense?
--
Cheers,
Simon B
si...@brunningonline.net
http://www.brunningonline.net/simon/blog/
Fredrik Lundh
> My understanding of the difference between a tuple and a list is
> PRECISELY that the former is immutable and the latter mutable.
while tuples can be used as "frozen lists", that's definitely not what
they are, from a design perspective.
just like in math [1], a Python tuple is a heterogeneous sequence where
the position implies type and usage. in contrast, a list is a homo-
geneous collection where all the items are "the same" in some sense,
no matter where they are. if you sort or otherwise reorder a list
of things, it's still a list of the same things. if you sort a tuple,
you'll break it.
in other words, you're supposed to know what the individual items are in
a tuple; if you feel the need to search for things by value in a tuple,
you're using the wrong container type.
</F>
Simon Brunning
>
> Why doesn't the tuple type have an index method? It seems such a
> bizarre restriction that there must be some reason for it. Yes,
> I know it's a fairly rare requirement.
It's because, philosophically, a Python tuple isn't just a read-only list.
Lists are for homogeneous data, all entries being of the same 'type'.
('Type' here doesn't refer to class or anything like that - just
conceptual type - what kind of thin g it is.) So, you can infer no
semantic meaning from an items position in the list. Sorting makes
sence,m and does looking though a list to find something - hence
index().
A tuple, on the other hand, is heterogeneous. The fact that an item is
the nth item is a tuple *means* something. Sorting a tuple would make
no sense, even if it were possible, and you are supposed to know where
in the tuple things are, so it makes no sense to search for it.
Glenn Hutchings
> It's because, philosophically, a Python tuple isn't just a read-only list.
But there are situations where you might want to treat it as a
read-only list. E.g., an argument to a function, so that you can
guarantee the function won't modify it. In that case, it makes sense
for the non-modifying methods (index() and count()) to be available.
Roberto Bonvallet
> But there are situations where you might want to treat it as a
> read-only list. E.g., an argument to a function, so that you can
> guarantee the function won't modify it. In that case, it makes sense
> for the non-modifying methods (index() and count()) to be available.
list(my_arg).index(...)
--
Roberto Bonvallet
Fredrik Lundh
> But there are situations where you might want to treat it as a
> read-only list. E.g., an argument to a function, so that you can
> guarantee the function won't modify it.
if you cannot trust your own code not to modify objects you pass to it,
I'm not sure Python's the right language for you.
</F>
Glenn Hutchings
> list(my_arg).index(...)
Absolutely -- you can work around the limitation without any problems.
But the question is, why doesn't the list type share all its
non-modifying methods with the tuple type? All the previous arguments
about "homogenous" and "heterogenous" in this thread sound bogus to me.
Python is first and foremost a practical language; what lists and
tuples are supposedly "for" strikes me as being irrelevant.
Glenn
Glenn Hutchings
> if you cannot trust your own code not to modify objects you pass to it,
> I'm not sure Python's the right language for you.
It's not my own code I'm worried about. :-)
Simon Brunning
> All the previous arguments
> about "homogenous" and "heterogenous" in this thread sound bogus to me.
> Python is first and foremost a practical language; what lists and
> tuples are supposedly "for" strikes me as being irrelevant.
Tell that to Guido. They are his arguments.
Simon Brunning
> Tell that to Guido. They are his arguments.
On 2nd thoughts, don't. He has enough on his plate at the moment. ;-)
Fredrik Lundh
> Python is first and foremost a practical language; what lists and
> tuples are supposedly "for" strikes me as being irrelevant.
if you don't want to understand the design, nobody can force you. but arguing
that the people behind the design "don't get it" isn't very practical.
and if you want random hacks and no design philosophy, use PHP.
</F>
Simon Brunning
> It's not my own code I'm worried about. :-)
If you want a language that protects you not only from your own
mistakes, but also the mistakes of others, well, err, sorry, I'm not
sure I can help you. Eiffel, perhaps?
<http://en.wikipedia.org/wiki/Design_by_contract>
Glenn Hutchings
> if you don't want to understand the design, nobody can force you. but arguing
> that the people behind the design "don't get it" isn't very practical.
I'm not arguing that at all. What I'm saying is that from the
perspective of someone not interested in design issues, it seems like
an omission for tuples to be missing the non-modifying methods that
lists have.
Glenn
Nick Maclaren
In article <1166106278.1...@n67g2000cwd.googlegroups.com>,
And, from the perspective of someone VERY interested in design issues,
from the viewpoint of program validation (a.k.a mathematical models,
a.k.a. 'program proving' a.k.a. 'software engineering') it also seems
like one!
If lists are intended to be homogeneous, then they should be checked
for that, and an exception raised when an attempt is to make them
non-homogeneous. At least as a Python checking option.
If tuples are intended to be bags, then it makes no sense to allow
them to be subscripted OR indexed. Mathematically, 'x = a[i]' and
'i = a.index(x)' have dual properties - and are true duals if you
include the constraint of no duplicate elements.
I remain baffled. I accept the explanations, but what I am now
confused by is the reason for the explanations ....
Regards,
Nick Maclaren.
Georg Brandl
> In article <1166106278.1...@n67g2000cwd.googlegroups.com>,
> "Glenn Hutchings" <zon...@googlemail.com> writes:
> |> Fredrik Lundh wrote:
> |>
> |> > if you don't want to understand the design, nobody can force you. but arguing
> |> > that the people behind the design "don't get it" isn't very practical.
> |>
> |> I'm not arguing that at all. What I'm saying is that from the
> |> perspective of someone not interested in design issues, it seems like
> |> an omission for tuples to be missing the non-modifying methods that
> |> lists have.
>
> And, from the perspective of someone VERY interested in design issues,
> from the viewpoint of program validation (a.k.a mathematical models,
> a.k.a. 'program proving' a.k.a. 'software engineering') it also seems
> like one!
>
> If lists are intended to be homogeneous, then they should be checked
> for that, and an exception raised when an attempt is to make them
> non-homogeneous. At least as a Python checking option.
There you have the "consenting adults" philosophy again: You know what lists
are for, so you can use them for it. You can also use them for something else,
but in that case it's moot to complain about missing features.
> If tuples are intended to be bags, then it makes no sense to allow
> them to be subscripted OR indexed. Mathematically, 'x = a[i]' and
> 'i = a.index(x)' have dual properties - and are true duals if you
> include the constraint of no duplicate elements.
You're describing sets. Tuples are not sets. Sets are not indexable and have
unique elements.
Indexing is the *vital* point of tuples. They are an ordered collection of
values, and you are supposed to know which data is found at which index.
Don't tell me that tuples in maths are sets.
For a mathematical example, take
A = { (x,y) : 0 < x < 1, 0 < y < 1 }
Here, (x,y) is a 2-tuple, and you know that at index 0 there's the x-coordinate
of a point contained in the square A, and at index 1 there's the y-coordinate.
Georg
Fredrik Lundh
> If lists are intended to be homogeneous, then they should be checked
> for that, and an exception raised when an attempt is to make them
> non-homogeneous.
so how would that check work, given that Python's type model is based on
duck typing
http://en.wikipedia.org/wiki/Duck_typing
?
</F>
Nick Maclaren
In article <elrqjl$j4s$1...@news.albasani.net>,
Georg Brandl <g.brand...@gmx.net> writes:
|> >
|> > If lists are intended to be homogeneous, then they should be checked
|> > for that, and an exception raised when an attempt is to make them
|> > non-homogeneous. At least as a Python checking option.
|>
|> There you have the "consenting adults" philosophy again: You know what lists
|> are for, so you can use them for it. You can also use them for something else,
|> but in that case it's moot to complain about missing features.
One of the places where Cobol, Ada and Python are superior to C and Perl
is that they regard checking as a part of the language.
|> > If tuples are intended to be bags, then it makes no sense to allow
|> > them to be subscripted OR indexed. Mathematically, 'x = a[i]' and
|> > 'i = a.index(x)' have dual properties - and are true duals if you
|> > include the constraint of no duplicate elements.
|>
|> You're describing sets. Tuples are not sets. Sets are not indexable and have
|> unique elements.
Actually, I was describing bags - like sets, but with element multiplicity.
See http://en.wikipedia.org/wiki/Multiset
|> Indexing is the *vital* point of tuples. They are an ordered collection of
|> values, and you are supposed to know which data is found at which index.
Memo to self: you really MUST remember NEVER to use reductio ad absurdum
on Usenet.
The point is that an index method makes sense on ANY data structure that
can be subscripted by an integer value but, for reasons that aren't at
all clear, is not defined for Python tuples. There is no technical or
mathematical reason why it shouldn't be.
Regards,
Nick Maclaren.
Glenn Hutchings
> I remain baffled. I accept the explanations, but what I am now
> confused by is the reason for the explanations ....
Maybe this archive posting, straight from the horse's mouth, will clear
things up once and for all...
http://www.python.org/search/hypermail/python-1992/0285.html
Glenn
Fredrik Lundh
> The point is that an index method makes sense on ANY data structure that
> can be subscripted by an integer value but, for reasons that aren't at
> all clear, is not defined for Python tuples. There is no technical or
> mathematical reason why it shouldn't be.
so where would you put such an "index" implementation so it would work on
ANY data structure that can be subscripted by an integer value ?
</F>
Nick Maclaren
In article <mailman.1604.1166110...@python.org>,
See my response to Georg Brandl (specifically the memo. to myself).
Regards,
Nick Maclaren.
Nick Maclaren
In article <1166111379.4...@t46g2000cwa.googlegroups.com>,
Wonderful! Thanks. Yes, that does. It makes perfect sense. I did
say that I thought it would be a rarely used feature :-)
Regards,
Nick Maclaren.
Nick Maclaren
In article <mailman.1605.1166111...@python.org>,
In the same place you put the subscription method, clearly. I really
don't see the problem. I can see that it has not been done because
Guido and others felt that it wasn't worth doing, but not that it is
hard to do.
Regards,
Nick Maclaren.
Neil Cerutti
Though the full rationale no longer applies to strings, which now
have plenty of methods.
--
Neil Cerutti
Weight Watchers will meet at 7 p.m. Please use large double door at the side
entrance. --Church Bulletin Blooper
Carsten Haese
> In article <mailman.1605.1166111...@python.org>,
> "Fredrik Lundh" <fre...@pythonware.com> writes:
> |>
> |> > The point is that an index method makes sense on ANY data structure that
> |> > can be subscripted by an integer value but, for reasons that aren't at
> |> > all clear, is not defined for Python tuples. There is no technical or
> |> > mathematical reason why it shouldn't be.
> |>
> |> so where would you put such an "index" implementation so it would work on
> |> ANY data structure that can be subscripted by an integer value ?
>
> In the same place you put the subscription method, clearly.
Clearly not, because that would force *every* object that implements
__getitem__ to also implement index.
And to verify the truth of your assertion that index makes sense for
"ANY data structure that can be subscripted by an integer value",
consider the following theoretical but conceivable examples:
1) A mailbox object that returns the i-th message on subscripting.
2) A scroll cursor in a database that returns the i-th row of the result
set.
3) A prime number generator that calculates the i-th prime number.
Does .index() make sense for them? How would it be implemented?
-Carsten
Fredrik Lundh
> In the same place you put the subscription method, clearly.
which is?
</F>
Fredrik Lundh
> See my response to Georg Brandl (specifically the memo. to myself).
"reductio ad absurdum" and "arbitrary handwaving" are two different
things, though.
</F>
Nick Maclaren
In article <mailman.1607.1166112...@python.org>,
Carsten Haese <car...@uniqsys.com> writes:
|> > |>
|> > |> so where would you put such an "index" implementation so it would work on
|> > |> ANY data structure that can be subscripted by an integer value ?
|> >
|> > In the same place you put the subscription method, clearly.
|>
|> Clearly not, because that would force *every* object that implements
|> __getitem__ to also implement index.
Well, yes, but why is that impossible? You may feel that it is
undesirable, but that is not the same at all. And there is no problem
with providing a generic default version of index that just does a
linear search, so only objects that wanted to optimise index would
need to provide anything.
|> And to verify the truth of your assertion that index makes sense for
|> "ANY data structure that can be subscripted by an integer value",
|> consider the following theoretical but conceivable examples:
|>
|> 1) A mailbox object that returns the i-th message on subscripting.
|> 2) A scroll cursor in a database that returns the i-th row of the result
|> set.
|> 3) A prime number generator that calculates the i-th prime number.
|>
|> Does .index() make sense for them? How would it be implemented?
You are correct that it does also need some sort of a concept of
equivalence, but a language like Python always has one - the 'is'
operator, if nothing else.
index makes sense for all of the above examples, and the implementation
couls be based on 'is' for (1) and (2), and on value for (3). And, as
mentioned above, it could be implemented as a linear search, if nothing
else works.
Mathematically, the counterexamples are only lists of entities where
there is no definable concept of equivalence between entities, and
Python has no such entities as far as I know.
Guido's response is fine - we didn't because we didn't think that it
was worth doing. One can dissent, but it makes perfect sense.
Regards,
Nick Maclaren.
Fredrik Lundh
> Guido's response is fine - we didn't because we didn't think that it
> was worth doing. One can dissent, but it makes perfect sense.
so which Guido should you trust more? the "tuples should not be used
for arrays of homogeneous data" and "searching tuples doesn't make
sense" guy seen e.g here:
http://mail.python.org/pipermail/python-dev/2002-January/019664.html
http://mail.python.org/pipermail/python-dev/2003-March/033964.html
http://mail.python.org/pipermail/python-dev/2003-March/033972.html
or that "we didn't add list methods to tuples because we're lazy" guy?
</F>
Fredrik Lundh
> so which Guido should you trust more?
not to mention the "If you have a need for using count() or index() on
tuples, you're using them the wrong way" guy:
http://mail.python.org/pipermail/patches/2001-February/004071.html
</F>
Carl Banks
> Simon Brunning wrote:
> > It's because, philosophically, a Python tuple isn't just a read-only list.
>
> But there are situations where you might want to treat it as a
> read-only list. E.g., an argument to a function, so that you can
> guarantee the function won't modify it.
Seems to me a misplaced fear. Do you take steps to also protect other
mutable arguments (dicts, class instances, etc.)? If not, there should
be no reason why you should protect lists that way either. If so, you
could do a similar thing for lists as well.
For the record, I don't agree with tuple's absent count and index
methods either, but for other reasons. It's a minor thing. I deal
with it.
> In that case, it makes sense
> for the non-modifying methods (index() and count()) to be available.
As I said in another thread, making sense is about step one out of a
hundred for getting your change into the language.
Carl Banks
Nick Maclaren
In article <1166118142....@l12g2000cwl.googlegroups.com>,
"Carl Banks" <pavlove...@gmail.com> writes:
|> Glenn Hutchings wrote:
|> > Simon Brunning wrote:
|> > > It's because, philosophically, a Python tuple isn't just a read-only list.
|> >
|> > But there are situations where you might want to treat it as a
|> > read-only list. E.g., an argument to a function, so that you can
|> > guarantee the function won't modify it.
|>
|> Seems to me a misplaced fear. Do you take steps to also protect other
|> mutable arguments (dicts, class instances, etc.)? If not, there should
|> be no reason why you should protect lists that way either. If so, you
|> could do a similar thing for lists as well.
Well, in an ideal language, yes. And, yes, that is the correct solution.
If I were a designing a language, mutability would be an orthogonal
property to type. It isn't a misplaced fear, but the extra protection
provided by doing that only for tuples is like locking one door out of
ten to deter burglars - good practice, if there is no downside, but not
worth putting much effort into.
And the 'misplaced fear' assertion is equally applicable to the misuse
of tuples - but that viewpoint is clearly heretical :-)
|> For the record, I don't agree with tuple's absent count and index
|> methods either, but for other reasons. It's a minor thing. I deal
|> with it.
Indeed. The code to sort out the problem was trivial. I was curious
as to the reason, since there was no technical or mathematical one, and
seem to have accidentally committed one of Python's Seven Unforgiveable
Heresies, to have lost my soul irredeemably, and to be in danger of
being burnt at the stake.
Ah, well.
[ Incidentally, my use was in argument decoding, where the Python layer
holds the arguments as strings, and I need to pass them as an index to C
(so they DO form a respectable tuple even in Guido's sense, being fixed
in number and value and just happening to be homogeneous). ]
Regards,
Nick Maclaren.
Fredrik Lundh
> Indeed. The code to sort out the problem was trivial. I was curious
> as to the reason, since there was no technical or mathematical one
you still haven't explained what your solution to the technical
issues is, though. if simply repeating that something is trivial
would make the real issues go away, the Py3K developers would
have made a lot more progress over the last year.
> seem to have accidentally committed one of Python's Seven
> Unforgiveable Heresies
duck-typing applies to usenet posters too, you know. if you look like a ...
</F>
Carl Banks
Nick Maclaren wrote:
> It isn't a misplaced fear, but the extra protection
> provided by doing that only for tuples is like locking one door out of
> ten to deter burglars - good practice, if there is no downside, but not
> worth putting much effort into.
Maybe "inconsistent" fear is a better word. It's like when people are
deathly afraid to get on an airplane, but think nothing of riding in a
car without a seatbelt.
Carl Banks
Nick Maclaren
In article <1166122540....@16g2000cwy.googlegroups.com>,
I agree with that. I consider the difficulty of adding a reliable
immutable attribute in most languages to be a serious piece of
misdesign, but there isn't a huge amount of point unless it is done
properly. Unreliable safety devices are as likely to increase
errors as reduce them, at least in the hands of the naive.
Regards,
Nick Maclaren.
Christoph Zwerschke
are for heterogeneous data, list are for homogeneous data" would be
written down somewhere in the tutorial, reference or in PEP8, so people
would be aware of it.
And can somebody explain what is exactly meant with "homogenous data"?
That the type of the elements is the same in some technical or
philosophical meaning? Concretely speaking, which data type should I use
for coordinate tuples? Usually, tuples are used. Does this mean that I
should better use lists from now on because all the components have the
same type?
-- Christoph
Tim Golden
> And can somebody explain what is exactly meant with
> "homogenous data"?
This seems to have been explained a few times
recently :) Basically, if you have a "list of xs"
and remove one item from it, it is still a "list of xs",
where "xs" might be people, coordinate-pairs, numbers
or whatever made sense to you. If you have a tuple
containing, say, a 2d coordinate pair, and remove something
from it, it's no longer a coordinate pair. If you add one to it,
it's something else as well (perhaps a 3d coord?)
A typical example of their combined use is a set of
rows returned from a database: each row is a tuple
of fields, the same as all other such rows, and removing
or adding a field would make no sense. However, add
a new row to the list and it remains a list of rows.
Now you can take this or leave it within Python. You
can but mixed values into a list so it isn't really a list
of "xs" unless "x" is just "thing". Likewise you can use
a tuple to hold a list of identical things although you
can't add to it or take away.
> Concretely speaking, which data type should I use
> for coordinate tuples? Usually, tuples are used. Does this mean that I
> should better use lists from now on because all the components have the
> same type?
This would seem to be slightly false logic (and very
possibly used tongue-in-cheek). Heterogeneous data
doesn't mean that each item *has* to be different, merely
that they *may* be.
TJG
Simon Brunning
> What I'm saying is that from the
> perspective of someone not interested in design issues, it seems like
> an omission for tuples to be missing the non-modifying methods that
> lists have.
>From the perpective of somone not interested in Football, the offside
rule looks very strange - but I'm not making any suggestions as to how
it should be changed.
Christoph Zwerschke
> Christoph Zwerschke wrote:
>> And can somebody explain what is exactly meant with
>> "homogenous data"?
>
> This seems to have been explained a few times
> recently :) Basically, if you have a "list of xs"
> and remove one item from it, it is still a "list of xs",
According to that definition, everything would be homogenous. I guess
what you wanted to say is if you have an "x" and remove one item from it
it is still an "x", then it's homogenous. The problem is that depending
on how exactly you define "x", you will come to different results.
> If you have a tuple containing, say, a 2d coordinate pair,
> and remove something from it, it's no longer a coordinate pair.
Now here comes the ambiguity. If you interpret "x" as "coordinate tuple"
it would be still one (a 1-tuple), but if you interpret "x" as
"coordinate pair" then it would indeed not be an "x" any more. So that
definition is not really helpful.
> A typical example of their combined use is a set of
> rows returned from a database: each row is a tuple
> of fields, the same as all other such rows, and removing
> or adding a field would make no sense. However, add
> a new row to the list and it remains a list of rows.
Sounds plausible. But when I read a row with the name and forename of a
person, I might want to collapse the name and forename into one element
before I hand it over to a function that will display it as a table. Or
I may want to delete certain elements which are not important. In such
cases, having each row as list may also make sense.
>> Concretely speaking, which data type should I use
>> for coordinate tuples? Usually, tuples are used. Does this mean that I
>> should better use lists from now on because all the components have the
>> same type?
>
> This would seem to be slightly false logic (and very
> possibly used tongue-in-cheek). Heterogeneous data
> doesn't mean that each item *has* to be different, merely
> that they *may* be.
I don't think it's a problem of false logic but the problem that
"homogenous data" is not defined.
We probably agree that it usually makes perfect sense to use tuples for
coordinates. But in certain mathematical algorithms it also makes sense
to ask for the number of zero components of a coordinate tuple - the
count() method would be helpful here.
The statement "if you are looking for index() or count() for your
tuples, you're using the wrong container type" is too extreme I think. I
would agree with "it *may indicate* that you should better use lists".
-- Christoph
Simon Brunning
> Maybe there would be less dispute if this dogma/convention(?) "Tuples
> are for heterogeneous data, list are for homogeneous data" would be
> written down somewhere in the tutorial, reference or in PEP8, so people
> would be aware of it.
It's not a dogma. It's just that it explains the intention behind the
designs of the tuple and list APIs. If you use them for thier intended
purposes, naturally you'll find the APIs more helpful.
But you won't find the data-structure police breaking down your doors
in the small hours if you choose to go your own way[1]. I can use a
spreadsheet to write a letter if I want to - but it would be foolish
to complain that the word wrapping was a bit dodgy.
--
Cheers,
Simon B
si...@brunningonline.net
[1] The PSU, on the other hand, Mi%_$@-£+%(
Simon Brunning
> > and remove something from it, it's no longer a coordinate pair.
>
> Now here comes the ambiguity. If you interpret "x" as "coordinate tuple"
> it would be still one (a 1-tuple), but if you interpret "x" as
> "coordinate pair" then it would indeed not be an "x" any more. So that
> definition is not really helpful.
But the new 1-tuple is no longer usable in the same contexts as the
coordinate pair. In the coordinate pair, you can infer the item's
meaning from its position.
> > A typical example of their combined use is a set of
> > rows returned from a database: each row is a tuple
> > of fields, the same as all other such rows, and removing
> > or adding a field would make no sense. However, add
> > a new row to the list and it remains a list of rows.
>
> Sounds plausible. But when I read a row with the name and forename of a
> person, I might want to collapse the name and forename into one element
> before I hand it over to a function that will display it as a table. Or
> I may want to delete certain elements which are not important. In such
> cases, having each row as list may also make sense.
Sure, you can translate the tuple into a different tuple for a
different purpose, but in terms of the database, only the original
tuple (or other with the same structure) is meaningful.
> The statement "if you are looking for index() or count() for your
> tuples, you're using the wrong container type" is too extreme I think. I
> would agree with "it *may indicate* that you should better use lists".
Oh, absolutely, it's not a hard and fast rule. But I find that if I
try to decide whether to use a tuple or a list based on lists for
homogeneous collections and tuples for heterogeneous collections where
position carries semantic meaning, then I end up using the type that
does what I need. Homogeneous collections often need to be sorted or
searched, wheras heterogeneous collections are often used as
dictionary keys.
George Sakkis
> The statement "if you are looking for index() or count() for your
> tuples, you're using the wrong container type" is too extreme I think. I
> would agree with "it *may indicate* that you should better use lists".
And also if that statement was correct, I would argue that Python uses
the wrong container type for storing positional arguments. More often
that not, when ones uses *varargs, he expects a homogeneous container
of extra arguments. There are exceptions of course (e.g. range()) where
each of the expected *varargs has distinct semantics, but from my
experience these are far less common than the unlimited-extra-arguments
case.
George
Nick Maclaren
In article <1166187479.1...@n67g2000cwd.googlegroups.com>,
"Tim Golden" <tjgo...@gmail.com> writes:
|> [Christoph Zwerschke]
|>
|> > And can somebody explain what is exactly meant with
|> > "homogenous data"?
|>
|> This seems to have been explained a few times
|> recently :) Basically, if you have a "list of xs"
|> and remove one item from it, it is still a "list of xs",
|> containing, say, a 2d coordinate pair, and remove something
|> it's something else as well (perhaps a 3d coord?)
Hmm. If I remove an object from a list of objects, does it not
remain a list of objects?
The converse is worse, as in my example. If a heterogeneous list
just happens to have objects that are all similar, does it remain
heterogeneous?
Loose guidelines are very useful, but should almost always come with
the rider "Follow these unless you have good reasons to ignore them,
but do make sure that you understand the rules first before deciding
your rules are good". Some of the responses here went a little, er,
a lot beyond that.
Regards,
Nick Maclaren.
James Stroud
> So, you can infer no semantic meaning from an items position in the list.
[...]
> The fact that an item is the nth item is a tuple *means* something.
Wouldn't it be nice, then, to find out where something is in a tuple so
that one could infer semantic meaning from its position and make
inferences about the tuple object searched, /philosophically/ speaking?
Or is the logic conveniently one-way?
James
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095
James Stroud
> Maybe there would be less dispute if this dogma/convention(?) "Tuples
> are for heterogeneous data, list are for homogeneous data" would be
> written down somewhere in the tutorial, reference or in PEP8, so people
> would be aware of it.
This is a good idea. It has taken me a while to begin using them in this
manner. I have been more or less forced to by the design of the language
and I confess that the intended usage of each is pretty natural.
But until this thread, I only had a latent understading of their
intended use. Now it is much clearer to me, though it seems kind of
late. I don't think an explicit explanation is in Learning Python (which
is the book I used to learn python).
It seems like such an fundamental principle should be in *all* of the
introductory texts, much like the process for defining a function is in
all introductory texts. I don't think PEPs, the language reference, or
inclusion in a single introductory text somewhere would be enough for
one to point at and say "you should have read this".
(Well, I'm in the process of reading the internet right now, but I just
haven't gotten to PEP 646 or python-dev from 1993. I estimate I'll get
to these in a few dozen years.)
If I recall correctly, Learning Python emphasized the practical
differences between tuples and lists and did not elaborate on the
philosophy of their usage. I seem to remember an emphasis on efficiency
and how tuples hold an advantage.
> And can somebody explain what is exactly meant with "homogenous data"?
> That the type of the elements is the same in some technical or
> philosophical meaning?
Hopefully homogenous means that all of the objects in the list share a
common interface. To enforce this interface would require the interface
definition in the initialization of a list, etc., which would not be
consistent with python duck typing and would require that interfaces be
added to the language.
> Concretely speaking, which data type should I use
> for coordinate tuples? Usually, tuples are used. Does this mean that I
> should better use lists from now on because all the components have the
> same type?
I don't think that all homogenous structures should be lists. This is
not the same as saying that all lists should be homogenous.
Hendrik van Rooyen
> I don't think it's a problem of false logic but the problem that
> "homogenous data" is not defined.
>
> We probably agree that it usually makes perfect sense to use tuples for
> coordinates. But in certain mathematical algorithms it also makes sense
> to ask for the number of zero components of a coordinate tuple - the
> count() method would be helpful here.
>
> The statement "if you are looking for index() or count() for your
> tuples, you're using the wrong container type" is too extreme I think. I
> would agree with "it *may indicate* that you should better use lists".
>From a practical point of view, the only reason to use a tuple instead
of a list for anything seems to be that you want to use it as a key in a dict...
Otherwise, why bother with these recalcitrant things that you can't
change or index, or append to or anything that lists allow?
- Hendrik
Christoph Zwerschke
> From a practical point of view, the only reason to use a tuple instead
> of a list for anything seems to be that you want to use it as a key in a dict...
>
> Otherwise, why bother with these recalcitrant things that you can't
> change or index, or append to or anything that lists allow?
I can imagine (but don't know whether this is actually the case in
CPython) that tuples have some memory and/or performance advantages over
lists, and there could be special optimizations for small (2 or 3
element) tuples because they are used very frequently.
So that would be another practical aspect why a long list of tuples
could be better than a long list of lists - but does anybody know
whether this is even true for CPython?
-- Christoph
Christoph Zwerschke
> Christoph Zwerschke wrote:
>> Maybe there would be less dispute if this dogma/convention(?) "Tuples
>> are for heterogeneous data, list are for homogeneous data" would be
>> written down somewhere in the tutorial, reference or in PEP8, so
>> people would be aware of it.
>
> This is a good idea. It has taken me a while to begin using them in this
> manner. I have been more or less forced to by the design of the language
> and I confess that the intended usage of each is pretty natural.
I just found that there is indeed some mentioning in the FAQ here:
http://www.python.org/doc/faq/general/#why-are-there-separate-tuple-and-list-data-types
But it is a bit vague, too, and does not mention whether there is any
difference in efficiency which would be interesting to know as well.
It would be nice if somebody with more knowledge about the internals
could overhaul and supplement that answer in the FAQ. A link to this in
the tutorial or other parts of the standard doc where tuples and lists
are discussed would be also helpful.
>> Concretely speaking, which data type should I use for coordinate
>> tuples? Usually, tuples are used. Does this mean that I should better
>> use lists from now on because all the components have the same type?
>
> I don't think that all homogenous structures should be lists. This is
> not the same as saying that all lists should be homogenous.
So in which cases exactly should one make exceptions? Python experts
probably decide this from their "gut feelings" but it would be nice to
have a more complete "rule of thumb" or decision guidance for
non-experts that is mentioned somewhere in the docs, too:
Must be hashable for use as dict key or set element --> tuple
"Inhomogenous" in some meaning of the word --> tuple
... (fill in the details) --> tuple
everything else --> list
Maybe we can agree on something concrete here.
Nick Maclaren
In article <em0i1g$mpe$1...@online.de>, Christoph Zwerschke <ci...@online.de> writes:
|>
|> I just found that there is indeed some mentioning in the FAQ here:
|> http://www.python.org/doc/faq/general/#why-are-there-separate-tuple-and-list-data-types
|> But it is a bit vague, too, and does not mention whether there is any
|> difference in efficiency which would be interesting to know as well.
It is a trifle bizarre, much like most of the reasons that have been
given in this thread. I know only some of how Python is implemented,
but have a lot of relevant experience, and here is some commentry on
the FAQ.
The mutability one is the key. See 1.4.19 for a reason. In a less
functional language, a tuple would be a value and a list a variable.
You CAN implement dictionaries using mutable objects as keys, but
the result is to add a large amount of inefficiency, complication,
and confusion, for next to no useful function.
The homogeneity argument baffles me. While it is relevant to some
languages, I know of nothing within either Python's design or its
implementation that makes it relevant to Python. There may be some
abstruse aspect that I have missed, and I should be very interested
if anyone can explain it.
Both of these are orthogonal to whether tuples should support count
and index methods. Guido has given a clear answer "We didn't think
it was worth doing."
In terms of efficiency, it is clearly possible to implement tuples
more efficiently, as there is a lot of mechanism that lists need that
they don't. This accounts for the measurements people have made but,
as Guido says, it is EXTREMELY unlikely that any real application
will notice the difference. The extra cost is almost entirely in the
setup, as the current implementation of list indexing is near-optimal.
It would also be possible to improve lists to make insertion an
O(log N) operation, not an O(N) one as at present, at the expense of
increasing the cost of indexing. Not necessarily as much as from the
present O(1) to O(log N), but still significantly. Python has chosen
not to do that.
Regards,
Nick Maclaren.
James Stroud
> "Inhomogenous" in some meaning of the word --> tuple
I think that you have nailed it here. I don't think anyone on this list
is capable of giving a "concrete" (as you have put it) operational
definition of "inhomogenous". They will resort to use cases and thus
cloud the definition with programming philosophy.
So, programming philosophy, whether it will be admitted or not, is fully
responsible for the exclusion of index() from the tuple interface.
But perhaps we could take "not necessarily homogenous" to be the
operational definition of "inhomogenous". Of course then we would have
to define necessary...
James
Nick Maclaren
In article <4583ED06...@mbi.ucla.edu>,
James Stroud <jst...@mbi.ucla.edu> writes:
|> Christoph Zwerschke wrote:
|>
|> > "Inhomogenous" in some meaning of the word --> tuple
|>
|> I think that you have nailed it here. I don't think anyone on this list
|> is capable of giving a "concrete" (as you have put it) operational
|> definition of "inhomogenous". They will resort to use cases and thus
|> cloud the definition with programming philosophy.
Yes, I can. Here is one:
A collection is inhomogeneous if, for some attribute that is needed
for at least one action on at least one element of the collection,
the attribute is not shared by all elements of the collection.
Yes, this means that the concept of inhomogeneity depends on the use to
which a collection is put, and not just on the collection.
|> So, programming philosophy, whether it will be admitted or not, is fully
|> responsible for the exclusion of index() from the tuple interface.
Agreed.
|> But perhaps we could take "not necessarily homogenous" to be the
|> operational definition of "inhomogenous". Of course then we would have
|> to define necessary...
It's not necessary :-) Lists, in Python, are no more homogeneous than
tuples in any sense that I have located. As I posted earlier, if
anyone knows of one, please tell me.
Regards,
Nick Maclaren.
greg
> A collection is inhomogeneous if, for some attribute that is needed
> for at least one action on at least one element of the collection,
> the attribute is not shared by all elements of the collection.
If you mean "attribute" in the Python sense, then this
is wrong, because you're just defining it in terms of
concrete types again.
There is no rigorous definition in Python terms, because
Python doesn't formally embody the concept. But that
doesn't mean the concept isn't real.
There are other languages that do embody it, for example,
C. A Python tuple is like a C struct, and a Python list
is like a C array.
--
Greg
Roy Smith
> A Python tuple is like a C struct, and a Python list is like a C array.
A Python list is more like C++/STL vector than an array, but that's
probably picking nits.
The real problem is that while the *intent* of the Python tuple is to act
like a C/C++ struct (again, the C++ flavor is a better analogy, since
tuples have methods), that's a poor comparison.
The struct does lookup by name, the tuple is inherently index based. Yes,
I know that the struct element names are converted to offsets by the
compiler, but from the programming interface point of view, they're named
elements. In that respect, a Python dict is a better analogy for a C++
struct than a tuple is.
Also, consider that tuples and lists are completely fungible. For any list
l, list(tuple(l)) is an identity operation. The same is true of
tuple(list(t)) for any tuple t. That implies that neither one contains any
information that the other one doesn't.
Nick Maclaren
In article <4584E98...@cosc.canterbury.ac.nz>,
greg <gr...@cosc.canterbury.ac.nz> writes:
|>
|> > A collection is inhomogeneous if, for some attribute that is needed
|> > for at least one action on at least one element of the collection,
|> > the attribute is not shared by all elements of the collection.
|>
|> If you mean "attribute" in the Python sense, then this
|> is wrong, because you're just defining it in terms of
|> concrete types again.
No, I am not. I am using it in the normal English sense.
|> There is no rigorous definition in Python terms, because
|> Python doesn't formally embody the concept. But that
|> doesn't mean the concept isn't real.
Of course the concept is real, but the point is that Python doesn't
embody the concept of homogeneity in lists, formally or informally,
as far as I know or anyone has pointed out.
Regards,
Nick Maclaren.
greg
> The struct does lookup by name, the tuple is inherently index based.
I was trying to help people understand the distinction
we're talking about by showing an example of the same
distinction in another language where it's much clearer.
There are a great many ways in which C structs are
different from Python tuples, and C arrays are different
from Python lists. But they're not the aspects I'm
drawing an analogy between.
--
Greg
Roy Smith
greg <gr...@cosc.canterbury.ac.nz> wrote:
Well, yeah, but it's kind of like saying "a tangerine and an orange are
very different things because one of them is like an apple and the other
one is like a pear" :-)
Nick Maclaren
In article <4um6tgF...@mid.individual.net>,
greg <gr...@cosc.canterbury.ac.nz> writes:
|> Roy Smith wrote:
|>
|> > The struct does lookup by name, the tuple is inherently index based.
|>
|> I was trying to help people understand the distinction
|> we're talking about by showing an example of the same
|> distinction in another language where it's much clearer.
|>
|> There are a great many ways in which C structs are
|> different from Python tuples, and C arrays are different
|> from Python lists. But they're not the aspects I'm
|> drawing an analogy between.
Unfortunately, you are confusing the issue, because there are far
more extraneous aspects than relevant ones, and your view of the
similarities requires looking at the issue in a very strange way.
I think that I can see what you mean, but only just.
Regards,
Nick Maclaren.
greg
> Unfortunately, you are confusing the issue, because there are far
> more extraneous aspects than relevant ones, and your view of the
> similarities requires looking at the issue in a very strange way.
> I think that I can see what you mean, but only just.
Each member of a struct has a distinct, predefined
role. Even if they all have the same type, you
can't swap their values around without destroying
the meaning of the data. That's what's meant by
"heterogeneous" in this context -- it's not about
the values themselves, but the way they're used.
This is the kind of thing for which Python tuples
are mainly designed -- use as a struct whose
members happen to be named by integers rather
than strings.
If you still don't understand, then I'm afraid
I've run out of ideas on how to explain it.
--
Greg
Nick Maclaren
In article <4587506...@cosc.canterbury.ac.nz>,
greg <gr...@cosc.canterbury.ac.nz> writes:
|> Nick Maclaren wrote:
|>
|> > Unfortunately, you are confusing the issue, because there are far
|> > more extraneous aspects than relevant ones, and your view of the
|> > similarities requires looking at the issue in a very strange way.
|> > I think that I can see what you mean, but only just.
|>
|> Each member of a struct has a distinct, predefined
|> role. Even if they all have the same type, you
|> can't swap their values around without destroying
|> the meaning of the data. That's what's meant by
|> "heterogeneous" in this context -- it's not about
|> the values themselves, but the way they're used.
|>
|> This is the kind of thing for which Python tuples
|> are mainly designed -- use as a struct whose
|> members happen to be named by integers rather
|> than strings.
Well, that was obvious to me on a cursory reading, because I have
enough relevant experience with other languages. It wasn't what I
was referring to, which was two things:
C arrays are not extensible and, before C99, were fixed in size
at compile time. That makes them rather more similar to tuples in
those ways! I know that's not the aspect you were thinking of, but
is why I made the remark that I did.
It does explain why you think of lists as homogeneous, but the
analogy doesn't hold water on closer inspection. There doesn't seem
to be ANYTHING in the specification or implementation that assumes
lists are homogeneous.
Regards,
Nick Maclaren.
Simon Brunning
>
> It does explain why you think of lists as homogeneous, but the
> analogy doesn't hold water on closer inspection. There doesn't seem
> to be ANYTHING in the specification or implementation that assumes
> lists are homogeneous.
As has been said a number of times in this thread, "lists are for
homogeneous data" isn't a technical restriction, it's purely
conceptual. It's what lists were designed for, and their API reflects
this. Any by "objects of the same type", we are not talking about
"type" in any technical sense.
But you go ahead and put whatever you like in them if you have trouble
with the idea.
Similarly, the tuple API was designed for heterogeneous items where
the items' position in the list has semantic meaning. Use them as you
will, but don't complain if the API doesn't support what you want to
do.
I've had enough of this thread. You can lead a horse to water...
J. Clifford Dyer
Actually, I found the distinction a bit more helpful than that--more
like saying, "a tangerine and a pear are very different things because
one of them is like an orange and the other is like an apple." Still
not a precise definition, but a useful analogy in many ways.
Cheers,
Cliff
J. Clifford Dyer
> Christoph Zwerschke wrote:
>> "Inhomogenous" in some meaning of the word --> tuple
>
> I think that you have nailed it here. I don't think anyone on this list
> is capable of giving a "concrete" (as you have put it) operational
> definition of "inhomogenous". They will resort to use cases and thus
> cloud the definition with programming philosophy.
>
How about: "A heterogenous sequence is one in which each element plays a
unique role, specific to its position in the sequence. A homogenous
sequence is one in which position is determinative of nothing
significant other than (perhaps) order."
I'm not exactly sure what you mean by "programming philosophy." I
suspect it does enter into the choice of which to use, (as programming
philosophy determines whether a database will have a "name" field, or
"lastname", "firstname", and "middlename" fields) but I don't see that
this clouds the definitions, necessarily.
> So, programming philosophy, whether it will be admitted or not, is fully
> responsible for the exclusion of index() from the tuple interface.
>
No. Because as pointed out in another subthread, the exclusion of
index() from the tuple interface is in many ways orthogonal to the issue
of homogeneity/heterogeneity. It's partly that, and partly that The
Maintainers have decreed that the workarounds (list(mytuple).index())
are trivial enough to obviate the need for making all the changes to the
source code, and hacking something ugly (a linear search has been
suggested) into all unsuspecting hand-rolled subscriptable objects.
> But perhaps we could take "not necessarily homogenous" to be the
> operational definition of "inhomogenous". Of course then we would have
> to define necessary...
>
> James
I doubt the python interpreter will ever try to enforce
homogeneity/heterogeneity on lists/tuples, in part because there no good
ways of definining it syntactically, and in part because there are
certainly good reasons for breaking the rules. As someone said: passing
lists to untrustworthy functions. And as someone else said, *args
passes a tuple, even though it is frequently just a homogenous list of
more arguments.
Forgive me for referencing throughout the threads without proper
citation. I've been ill all weekend, and I just don't feel like doing
it right.
Cheers,
Cliff
Nick Maclaren
In article <em90d9$aua$2...@aioe.org>,
"J. Clifford Dyer" <webm...@cacradicalgrace.org> writes:
|>
|> How about: "A heterogenous sequence is one in which each element plays a
|> unique role, specific to its position in the sequence. A homogenous
|> sequence is one in which position is determinative of nothing
|> significant other than (perhaps) order."
Nope. Sorry. Consider the old model where an I/O list is an ordered
sequence of strings and agents (effectively procedure calls), with no
constraints on how those are ordered. With your specification, that
is neither heterogenous nor homogenous :-)
|> I doubt the python interpreter will ever try to enforce
|> homogeneity/heterogeneity on lists/tuples, in part because there no good
|> ways of definining it syntactically, and in part because there are
|> certainly good reasons for breaking the rules. As someone said: passing
|> lists to untrustworthy functions. And as someone else said, *args
|> passes a tuple, even though it is frequently just a homogenous list of
|> more arguments.
It's a complete delusion, because even the claimed assumption of list
homogeneity is tantmount to saying that Python doesn't encourage (or,
arguably, support) ANY way of using mutable heterogenous sequences
(such as the example above). To claim that they are inherently an
undesirable programming practice is a clear descent into religion!
I would be amused to know what Python type the "lists are intended to
be homogenous" people use to implement mutable heterogenous sequences,
or whether they claim that wanting such a feature is heresy :-)
Regards,
Nick Maclaren.
J. Clifford Dyer
> In article <em90d9$aua$2...@aioe.org>,
> "J. Clifford Dyer" <webm...@cacradicalgrace.org> writes:
> |>
> |> How about: "A heterogenous sequence is one in which each element plays a
> |> unique role, specific to its position in the sequence. A homogenous
> |> sequence is one in which position is determinative of nothing
> |> significant other than (perhaps) order."
>
> Nope. Sorry. Consider the old model where an I/O list is an ordered
> sequence of strings and agents (effectively procedure calls), with no
> constraints on how those are ordered. With your specification, that
> is neither heterogenous nor homogenous :-)
On the contrary, I think that example fits perfectly with my definition
of homogenous. If there is no constraint on position, then what is the
position determinative of? Order in the queue. Nothing more. By my
definition, homogeneous. QED.
I'll grant, it's not exactly the most intuitive definition of
homogenous, but I think it is the most accurate for this situation.
Perhaps homogenous and heterogenous aren't the best possible words here,
but I think they work.
>
> |> I doubt the python interpreter will ever try to enforce
> |> homogeneity/heterogeneity on lists/tuples, in part because there no good
> |> ways of definining it syntactically, and in part because there are
> |> certainly good reasons for breaking the rules. As someone said: passing
> |> lists to untrustworthy functions. And as someone else said, *args
> |> passes a tuple, even though it is frequently just a homogenous list of
> |> more arguments.
>
> It's a complete delusion, because even the claimed assumption of list
> homogeneity is tantmount to saying that Python doesn't encourage (or,
> arguably, support) ANY way of using mutable heterogenous sequences
> (such as the example above). To claim that they are inherently an
> undesirable programming practice is a clear descent into religion!
>
> I would be amused to know what Python type the "lists are intended to
> be homogenous" people use to implement mutable heterogenous sequences,
> or whether they claim that wanting such a feature is heresy :-)
>
By my definition, how can it be mutable AND heterogenous? If the first
element is a name, the second element is a phone number, and the third
element is an email address, and you insert an element in between the
first two elements, do you mean to tell me that the phone number, which
has moved to the third slot, is now an email address? It doesn't make
sense.
Maybe the words are wrong. I'm not sure. But I think the distinction
is valid. Furthermore, I think we "lists are intended to be homogenous"
people would say that you are perfectly welcome to use lists for other
purposes, if it suits you. Just as you can use a string as a list. We
don't have to be rigid to appreciate the difference. :)
>
> Regards,
> Nick Maclaren.
>
>
Blessings,
Cliff
Nick Maclaren
In article <em9aq9$2tn$1...@aioe.org>,
"J. Clifford Dyer" <webm...@cacradicalgrace.org> writes:
|>
|> On the contrary, I think that example fits perfectly with my definition
|> of homogenous. If there is no constraint on position, then what is the
|> position determinative of? Order in the queue. Nothing more. By my
|> definition, homogeneous. QED.
|>
|> I'll grant, it's not exactly the most intuitive definition of
|> homogenous, but I think it is the most accurate for this situation.
|> Perhaps homogenous and heterogenous aren't the best possible words here,
|> but I think they work.
Grrk. I see what you mean. The homogeneity is referring to the order
and not to the types :-)
|> By my definition, how can it be mutable AND heterogenous? If the first
|> element is a name, the second element is a phone number, and the third
|> element is an email address, and you insert an element in between the
|> first two elements, do you mean to tell me that the phone number, which
|> has moved to the third slot, is now an email address? It doesn't make
|> sense.
Well, I could provide an example, but they are a bit weird. More
seriously, consider changing a structure consisting of a name and
telephone number, and then changing the value of the latter (not
exactly an unreasonable requirement!) With tuples that can't be done,
but it makes perfect sense, and it is a mutable heterogeneous sequence
with your definition.
|> Maybe the words are wrong. I'm not sure. But I think the distinction
|> is valid. Furthermore, I think we "lists are intended to be homogenous"
|> people would say that you are perfectly welcome to use lists for other
|> purposes, if it suits you. Just as you can use a string as a list. We
|> don't have to be rigid to appreciate the difference. :)
Nope. That is DEFINITELY wrong. If you write code that abuses a
language construct in a way that is discouraged but just happens to
work, a couple of decades down the line it will stop working, because
someone will change the feature. Been there - been caught by that :-(
Regards,
Nick Maclaren.
J. Clifford Dyer
> In article <em9aq9$2tn$1...@aioe.org>,
> "J. Clifford Dyer" <webm...@cacradicalgrace.org> writes:
> |>
> |> On the contrary, I think that example fits perfectly with my definition
> |> of homogenous. If there is no constraint on position, then what is the
> |> position determinative of? Order in the queue. Nothing more. By my
> |> definition, homogeneous. QED.
> |>
> |> I'll grant, it's not exactly the most intuitive definition of
> |> homogenous, but I think it is the most accurate for this situation.
> |> Perhaps homogenous and heterogenous aren't the best possible words here,
> |> but I think they work.
>
> Grrk. I see what you mean. The homogeneity is referring to the order
> and not to the types :-)
Thank you. The more I tried to explain it, the more I was losing the
sense of the actual words "homogeneous" and "heterogenous" in this
context, but that helps me recapture it. It made so much sense until I
tried to articulate it...
>
> |> By my definition, how can it be mutable AND heterogenous? If the first
> |> element is a name, the second element is a phone number, and the third
> |> element is an email address, and you insert an element in between the
> |> first two elements, do you mean to tell me that the phone number, which
> |> has moved to the third slot, is now an email address? It doesn't make
> |> sense.
>
> Well, I could provide an example, but they are a bit weird. More
> seriously, consider changing a structure consisting of a name and
> telephone number, and then changing the value of the latter (not
> exactly an unreasonable requirement!) With tuples that can't be done,
> but it makes perfect sense, and it is a mutable heterogeneous sequence
> with your definition.
>
Good example. Of course, an immutable sequence can be made up of
mutable elements, but a string (which you'd probably use for a telephone
number or an email address) isn't one of those types.
> |> Maybe the words are wrong. I'm not sure. But I think the distinction
> |> is valid. Furthermore, I think we "lists are intended to be homogenous"
> |> people would say that you are perfectly welcome to use lists for other
> |> purposes, if it suits you. Just as you can use a string as a list. We
> |> don't have to be rigid to appreciate the difference. :)
>
> Nope. That is DEFINITELY wrong. If you write code that abuses a
> language construct in a way that is discouraged but just happens to
> work, a couple of decades down the line it will stop working, because
> someone will change the feature. Been there - been caught by that :-(
>
Yeah, that could suck. Personally, I can't picture such a basic
construct as a list or a tuple ever being given such a restrictive
meaning. If you ask me what a list is (in python), I would never say "a
list is a homogeneous sequence." I would say "a list is a mutable
sequence," as I believe the language reference defines it. (No
citation). If you then asked me why we have separate mutable and
immutable sequences, THAT's when I'd bring up homogeneity and
heterogeneity. So I wouldn't say you were misusing the structure for
making a homogeneous tuple, as long as you didn't try to mutate it. Or
that you were misusing a list if you really needed a mutable
heterogeneous sequence (like for changing phone numbers). The mapping
from heterogeneous to immutable is helpful, but not perfect, nor
normative. However, if more powerful minds disagree with me, that's
when you'd get in trouble.
Cheers,
Cliff
>
> Regards,
> Nick Maclaren.
greg
> It does explain why you think of lists as homogeneous, but the
> analogy doesn't hold water on closer inspection. There doesn't seem
> to be ANYTHING in the specification or implementation that assumes
> lists are homogeneous.
Then what do you think is suggested by the fact
that lists have an index() method but tuples don't?
That's how this whole discussion got started --
someone wanted an explanation of why that is so.
The explanation is that tuples and lists were
designed for different use cases.
You don't *have* to use them that way, but if
you use them differently, you're on your own
and can't complain if they don't have all the
features you want.
--
Greg
Nick Maclaren
In article <458919D...@cosc.canterbury.ac.nz>,
greg <gr...@cosc.canterbury.ac.nz> writes:
|>
|> > It does explain why you think of lists as homogeneous, but the
|> > analogy doesn't hold water on closer inspection. There doesn't seem
|> > to be ANYTHING in the specification or implementation that assumes
|> > lists are homogeneous.
|>
|> Then what do you think is suggested by the fact
|> that lists have an index() method but tuples don't?
Eh? Nothing relevant to homogeneity, to be sure. See the Library
reference, 2.3.3. It starts by saying "Comparison operations are
supported by all objects." and the first paragraph after the table
says that == is defined to return False for different types (except
numeric and string). 2.3.6 (Mutable Sequence Types) says that index
returns the smallest value such that == returns True.
So index finds a match among compatible types. That is an old
specification of searching heterogeneous lists that I have been
using for over 30 years - I can't now remember which languages
include it.
What's the problem?
|> That's how this whole discussion got started --
|> someone wanted an explanation of why that is so.
|> The explanation is that tuples and lists were
|> designed for different use cases.
The problem is that the homogeneity argument is irrational (which
does NOT necessarily mean either wrong or undesirable), IS NOT
DOCUMENTED IN THE REFERENCES, and Python is not generally irrational.
My mental model of Guido is that he thinks fairly rationally. Python
isn't Perl or C, after all.
|> You don't *have* to use them that way, but if
|> you use them differently, you're on your own
|> and can't complain if they don't have all the
|> features you want.
Which is tantamount to saying that Python doesn't support mutable
heterogeneous sequences, even though they are not locked out. That
is more than just odd - it is almost unbelievable. They are a very
basic data structure, after all!
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
greg
> Nope. Sorry. Consider the old model where an I/O list is an ordered
> sequence of strings and agents (effectively procedure calls), with no
> constraints on how those are ordered. With your specification, that
> is neither heterogenous nor homogenous :-)
I don't see any difficulty. This is a list (homogeneous) of
two-element tuples (heterogeneous).
If you're thinking of representing this as just a flat
list, [str1, agent1, str2, agent2, ...], that's a borked
way of doing it and you deserve whatever philosophical
knots you get into as a result.
> It's a complete delusion, because even the claimed assumption of list
> homogeneity is tantmount to saying that Python doesn't encourage (or,
> arguably, support) ANY way of using mutable heterogenous sequences
> (such as the example above).
It's unfortunate that Python doesn't make the homogeneous/
heterogeneous distinction orthogonal to the mutable/immutable
one. Ideally, yes, there would be mutable and immutable
tuples, and mutable and immutable lists. Perhaps also even
fixed and variable sized versions of these as well.
But that would be eight different data types, which is a
lot of trouble to go to just to give you something that's
precisely tailored to exactly what you want. Some might
say it was overkill.
Python takes a more pragmatic approach, and provides
just two: the tuple, optimised for the case of heterogeneous
*and* fixed size *and* immutable -- and the list, for
everything else.
So it's not really that lists are intended *only* for
homogeneous collections, but for anything that can't be
represented as a tuple for whichever reason.
--
Greg
Nick Maclaren
In article <4uslgfF...@mid.individual.net>,
greg <gr...@cosc.canterbury.ac.nz> writes:
|>
|> > Nope. Sorry. Consider the old model where an I/O list is an ordered
|> > sequence of strings and agents (effectively procedure calls), with no
|> > constraints on how those are ordered. With your specification, that
|> > is neither heterogenous nor homogenous :-)
|>
|> I don't see any difficulty. This is a list (homogeneous) of
|> two-element tuples (heterogeneous).
Not at all. I didn't say that they came in pairs. Consider:
[str1, str2, agent1, str3, agent2, agent3, agent4, str4, ...]
See Algol 68 for an example of this.
Regards,
Nick Maclaren.
Paul Boddie
>
> Which is tantamount to saying that Python doesn't support mutable
> heterogeneous sequences, even though they are not locked out. That
> is more than just odd - it is almost unbelievable. They are a very
> basic data structure, after all!
What a fuss about something so intangible! :-) If I were you, I'd not
worry about taking what people say with regard to the philosophy as a
starting point. Instead, it may be more illustrative to consider things
from the ground up...
* You can put any combination of things into both tuples and lists.
* Tuples are immutable, lists are mutable.
* You can test both tuples and lists for element membership
(x in seq).
* You can iterate over both tuples and lists.
The contentious issue is why you can't ask where something is in a
tuple (the position of an element) whereas you can in a list or even in
a string (albeit only with substrings in that particular case). This is
where you have to consider how you'd use an immutable sequence like a
tuple rather than a mutable sequence like a list.
With a tuple, since you can't append to it, you already need to have
decided its size and its contents (mutable elements notwithstanding)
when you create it. Although it's possible to have thousands of
elements in a tuple, you would in most situations need to build such
long tuples up either by concatenating existing ones - this is not
likely to be particularly efficient due to the need to construct a new
tuple for each concatenation of existing ones - or by converting a list
into a tuple (questioning the need for a tuple, anyway). So it's
unlikely that you'd lightly consider using tuples as an ad-hoc sequence
for recording long collections of objects, or that the structure of any
tuple you've created is consequently going to be unknown to your
program. Even if you were dealing with totally unknown tuples from
other sources, the need to query the location of specific elements
would probably be much less than just iterating over the tuple or
asking whether something is present in it.
Of course, one can still argue that querying for the presence of an
element is no real substitute for knowing its position. In a program
where you define the structure of a tuple in such a way that it makes
little sense for a particular element to appear in more than one place
- which is where the heterogeneous assertion comes in - knowing the
presence of an element is as good as knowing its position (since the
program has knowledge of the position implicitly). In a program where
you don't define the structure in such a way, the problem situation
seems to be as narrow as needing short tuples (as opposed to lists,
possibly for use as dictionary keys, for example) whose elements'
locations are efficiently discoverable, and where such location
information is significantly useful for other purposes. Since tuples
are immutable, you can't replace those elements using such location
information, leaving fewer and fewer compelling reasons for needing
that information in the first place, I would have thought.
Perhaps the notion of heterogeneous is best defined in the most general
case as a selection of objects unlikely to be considered equal or
equivalent, in such a way that the standard test for presence (x in
seq) employs such a measure of equality and can suggest (with
contextual information) the location of an object by just knowing
whether it is present.
Paul
greg
> Not at all. I didn't say that they came in pairs. Consider:
>
> [str1, str2, agent1, str3, agent2, agent3, agent4, str4, ...]
That's homogeneous. Any item of the list can be
either a string or an agent, and the only thing
the position in the list affects is what order
the strings and agents are processed in.
--
Greg
Hendrik van Rooyen
> Not at all. I didn't say that they came in pairs. Consider:
>
> [str1, str2, agent1, str3, agent2, agent3, agent4, str4, ...]
>
> See Algol 68 for an example of this.
When I looked at the above, I went "tilt" -
If you had no a priori knowledge about how many strings
are associated with an agent - (or agents with a string),
then you could only identify an agent because it was not
a string, or if it had some other magic property...
I cannot imagine a use case for this that would not be better
done with a dict using the agents as keys - or are the strings the
keys?
If the strings are "inputs" and the agents "routines" - is the idea
to call the agents one after the other all with the same input, or
is agent3 called with the return value of agent2 like a systolic
array arrangement?
What would be the reason for doing it like this?
I am confused
- Hendrik
Nick Maclaren
In article <4589D599...@cosc.canterbury.ac.nz>,
Grrk. I think that I see Python's problem - and it is Python's problem,
not mine or that of any of the other people who ask related questions.
The terms "heterogeneous" and "homogeneous" are being used in an extremely
specialised, unconventional and restricted way, without any kind of hint
in the documentation that this is so. It isn't an UNREASONABLE use, but
assuredly will NOT spring to the mind of anyone who sees the terms, most
especially if they are familiar with their use in other areas of computing
and mathematics.
But, given that meaning, I now understand your point.
Regards,
Nick Maclaren.
Nick Maclaren
In article <mailman.1895.1166684...@python.org>,
"Hendrik van Rooyen" <ma...@microcorp.co.za> writes:
|> "Nick Maclaren" <nm...@cus.cam.ac.uk> wrote:
|>
|> > Not at all. I didn't say that they came in pairs. Consider:
|> >
|> > [str1, str2, agent1, str3, agent2, agent3, agent4, str4, ...]
|> >
|>
|> When I looked at the above, I went "tilt" -
Yes, you are confused :-) Neither the agents nor strings take the
other as 'arguments', but are effectively methods of the I/O object.
Let's consider a modern example: a text editor with hyperlink
facilities. Note that I am referring to the hyperlinks of the kind
that can occur anywhere, and not those associated with a particular,
usually highlighted, word.
Text is a sequence of letters/words/sentences/paragraphs/markup/etc.;
let's assume words, as strings, for the purpose of argument. Words
can be inserted, deleted, changed etc.
Hyperlinks are agents and can be added at any point. Their only
relationship with the text is the position at which they occur (i.e.
none or more may occur between any two consecutive words).
Regards,
Nick Maclaren.
Hendrik van Rooyen
Thanks that helps - I really had the queen cat by the balls...
- Hendrik