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.
Dec 14 '06
77 4339
In article <em**********@online.de>, Christoph Zwerschke <ci**@online.dewrites:
|>
|I just found that there is indeed some mentioning in the FAQ here:
| http://www.python.org/doc/faq/genera...ist-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.
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.
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
In article <45**************@mbi.ucla.edu>,
James Stroud <js*****@mbi.ucla.eduwrites:
|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.
Nick Maclaren wrote:
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
greg <gr**@cosc.canterbury.ac.nzwrote:
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.
In article <45************@cosc.canterbury.ac.nz>,
greg <gr**@cosc.canterbury.ac.nzwrites:
|>
| 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.
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.
--
Greg
In article <4u*************@mid.individual.net>,
greg <gr**@cosc.canterbury.ac.nzwrote:
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.
--
Greg
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" :-)
In article <4u*************@mid.individual.net>,
greg <gr**@cosc.canterbury.ac.nzwrites:
|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.
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.
If you still don't understand, then I'm afraid
I've run out of ideas on how to explain it.
--
Greg
In article <45************@cosc.canterbury.ac.nz>,
greg <gr**@cosc.canterbury.ac.nzwrites:
|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.
On 19 Dec 2006 10:01:47 GMT, Nick Maclaren <nm**@cus.cam.ac.ukwrote:
>
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...
--
Cheers,
Simon B si***@brunningonline.net
Roy Smith wrote:
In article <4u*************@mid.individual.net>,
greg <gr**@cosc.canterbury.ac.nzwrote:
>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.
-- Greg
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" :-)
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
James Stroud wrote:
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
In article <em**********@aioe.org>,
"J. Clifford Dyer" <we*******@cacradicalgrace.orgwrites:
|>
|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.
Nick Maclaren wrote:
In article <em**********@aioe.org>,
"J. Clifford Dyer" <we*******@cacradicalgrace.orgwrites:
|>
|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
In article <em**********@aioe.org>,
"J. Clifford Dyer" <we*******@cacradicalgrace.orgwrites:
|>
|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.
Nick Maclaren wrote:
In article <em**********@aioe.org>,
"J. Clifford Dyer" <we*******@cacradicalgrace.orgwrites:
|>
|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.
Nick Maclaren wrote:
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
In article <45************@cosc.canterbury.ac.nz>,
greg <gr**@cosc.canterbury.ac.nzwrites:
|>
| 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
Nick Maclaren wrote:
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
In article <4u*************@mid.individual.net>,
greg <gr**@cosc.canterbury.ac.nzwrites:
|>
| 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.
Nick Maclaren wrote:
>
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
Nick Maclaren wrote:
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
"Nick Maclaren" <nm**@cus.cam.ac.ukwrote:
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
In article <45**************@cosc.canterbury.ac.nz>,
greg <gr**@cosc.canterbury.ac.nzwrites:
|>
| 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.
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.
In article <ma***************************************@python. org>,
"Hendrik van Rooyen" <ma**@microcorp.co.zawrites:
|"Nick Maclaren" <nm**@cus.cam.ac.ukwrote:
|>
| 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" -
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.
"Nick Maclaren" <nm**@cus.cam.ac.ukwrote:
"Hendrik van Rooyen" <ma**@microcorp.co.zawrites:
|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).
Thanks that helps - I really had the queen cat by the balls...
- Hendrik This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Ron Griswold |
last post by:
Can anyone tell me why the following will cause the returned tuple elements to remain un collected when the tuple goes out of scope:
PyObject * iobj = PyObject_New( PyIntObject, &PyInt_Type );...
|
by: Jinming Xu |
last post by:
Sorry for the previous message. It's really a simple question and I have
solved it myself.
Thanks,
Jinming
------------------------------------------------------------------------
Hi Folks,
|
by: Will McGugan |
last post by:
Hi,
Why is that a tuple doesnt have the methods 'count' and 'index'? It
seems they could be present on a immutable object.
I realise its easy enough to convert the tuple to a list and do this,...
|
by: Steve M |
last post by:
Hello,
I'm trying to figure out the index position of a tuple member.
I know the member name, but I need to know the members index position. I
know that if I use the statement print tuple that...
|
by: Rakesh |
last post by:
In my Python code fragment, I want to write a code fragment such that
the minimum element of a tuple is subtracted from all the elements of a
given
tuple.
When I execute the following python...
|
by: groups.20.thebriguy |
last post by:
I've noticed that there's a few functions that return what appears to
be a tuple, but that also has attributes for each item in the tuple.
For example, time.localtime() returns a time.time_struct,...
|
by: alainpoint |
last post by:
Hello,
I have got a problem that i can't readily solve.
I want the following:
I want to create a supertuple that behaves both as a tuple and as a
class.
It should do the following:...
|
by: rshepard |
last post by:
I'm a bit embarrassed to have to ask for help on this, but I'm not finding
the solution in the docs I have here.
Data are assembled for writing to a database table. A representative tuple
looks...
|
by: hall.jeff |
last post by:
Before the inevitable response comes, let me assure you I've read
through the posts from Guido about this. 7 years ago Guido clearly
expressed a displeasure with allowing these methods for tuple....
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |