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