Wrong, which should be evident to anyone who reads the entire paragraph
as the complete thought exposition it was meant to be. Beside which,
this negative ad hominem comment is irrelevant to the rest of your post
about the Liskov Substitution Principle.
Terry, I'm sorry that I have stood on your toes here, no offense was
intended. It seemed to me, based on the entire paragraph that you wrote,
that you may have misunderstood the OP's question. The difference in
signatures between the namedtuple class factory and tuple is irrelevant,
as I can now see you understand, but by raising it in the first place
you gave me the impression that you may have misunderstood what the OP
was attempting to do.
The rest of the paragraph, in two more pieces:
In other words, neither the namedtuple object nor any namedtuple class
object can fully substitute for the tuple class object. Nor can
instances of any namedtuple class fully substitute for instances of the
tuple class. Therefore, I claim, the hope that "namedtuples could be
used as replacements for tuples in all instances" is a futile hope,
however one interprets that hope.
I did discuss the fixed length issue directly, and agreed with you that
if your contract is to construct variable-length tuples, then a
fixed-length namedtuple is not substitutable.
But in practice, one common use-case for tuples (whether named or not)
is for fixed-length records, and in that use-case, a namedtuple of
length N should be substitutable for a tuple of length N.
Part of the effect is independent of initialization. Even if namedtuples
were initialized by iterator, there would still be glitches. In
particular, even if John's named tuple class B *could* be initialized as
B((1,2,3)), it still could not be substituted for t in the code below.
t = (1,2,3)
type(t) is type(t[1:])
True
Agreed. There are other differences as well, e.g. repr(t) will differ
between builtin tuples and namedtuples. The only type which is identical
in every conceivable aspect to tuple is tuple itself. Any subclass or
subtype[1] must by definition differ in at least one aspect from tuple:
type(some_tuple) is type(())
and in practice will differ in other aspects as well.
Footnote: [1] Subclass meaning it inherits from tuple; subtype in the
sense that it duck-types as a tuple, but may or may not share any
implementation.
LSP cannot be interpreted in isolation. Any non-trivial modification of
a class will change *something* about the class, after all that's why we
subclassed it in the first place. Either the interface will be
different, or the semantics will be different, or both. LSP must always
be interpreted in the intersection between the promises made by the
class and the promises your application cares about.
Some promises are more important than others, hence some violations are
more serious than others. For instance, I think that tuple indexing is a
critical promise: a "tuple" that cannot be indexed is surely not a tuple.
The exact form of the repr() of a tuple is generally not important at
all: a tuple that prints as MyBunchOStuff(...) is still a tuple. In my
experience, the constructor signature is of moderate importance. But of
course that depends on what promises you rely on, if you are relying on
the tuple constructor, then it is critical *to you*.
The problem I see with the LSP for modeling either abstract or concrete
entities is that we in fact do define subclasses by subtraction or
limitation, as well as by augmentation, while the LSP only allows the
latter.
People do all sorts of things. They write code that is O(N**2) or worse,
they call eval() on untrusted data, they use isinstance() and break
duck-typing, etc. That they break LSP does not necessarily mean that
they should. LSP is one of the five fundamental best-practices for
object-oriented code, "SOLID":
http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
Breaking any of the SOLID principles is a code-smell. That does not mean
that there is never a good reason to do so, but SOLID is a set of
principle which have stood the test of time and practice. Any code that
breaks one of those principles should be should be considered smelly, or
worse, until justified.
(And for the avoidance of doubt, I am more than satisfied with the
justification given for the difference in signature between tuples and
namedtuples.)