why () is () and [] is [] work in other way?
Adam Skutt
askutt at gmail.com
Fri Apr 27 05:32:27 EDT 2012
On Apr 26, 10:56 pm, "OKB (not okblacke)"
<brenNOSPAMb... at NObrenSPAMbarn.net> wrote:
> Adam Skutt wrote:
> > If I write a function that does a value comparison, then it should
> > do value comparison on _every type that can be passed to it_,
> > regardless of whether the type is a primitive or an object, whether
> > it has value or reference semantics, and regardless of how value
> > comparison is actually implemented. If I write some function:
> > f(x : T, y : U) => x == y
> > where T and U are some unknown types, then I want the function to
> > do a value comparison for every type pairing that allows the
> > function to compile. Likewise, if I write a function that does
> > identity comparison, then it logically wants to do identity
> > comparison on _every type that can be passed to it_.
>
> What you say here makes perfect sense, but also shows that you
> really shouldn't be using Python if you want stuff to work this way. In
> Python any value of any type can be passed to any function. The claims
> you are making about object identity and object equality are reasonable,
> but as you show here, to really handle them requires dragging in a huge
> amount of type-system baggage.
So the check gets deferred to runtime, and the programmer may need to
explictly throw 'NotImplemented' or something like that. Which is
what happens in Python. Not type-checking arguments simply moves the
burden from the language to the programmer, which is a standard
consequence of moving from static to dynamic typing.
Adam
More information about the Python-list
mailing list