On Feb 1, 2008 6:04 PM, Talin <[EMAIL PROTECTED]> wrote:
> I would like to present an argument both for and against the proposal.
>
> Against: I've never personally needed this capability.
>
> For: In many languages, the 'null' value has a special polymorphic
> behavior in that it is considered a subtype of all reference types. Thus
> in C, you can assign NULL to a Foo * or a Bar * even though Foo and Bar
> aren't related.
>
> So making NULL special seems in line with the general trend.
Hardly. In all languages I know of besides Python, doing *anything*
with such a NULL operand apart from passing it around or doing a
pointer equality comparison on it immediately causes a segfault or a
NullPointerException. In Python, you can already assign None to any
variable and do a pointer comparison ('is'); you can even do a value
equality ('==') without being punished, which is already better than
most languages.
Raymond is asking for *ordering* ('<', '<=' etc.) to be well-defined
when one of the arguments is None. Python 2 indeed did that, because
in Python 2 *all* values are orderable (well, *almost* all --
comparing str to unicode can sometimes raise an exception, complex
numbers can't be ordered, and there are a few other odd exceptions).
Python 3 does away with comparisons between heterogeneous types,
unless at least one of the types take special measures to be
comparable to the other -- this makes much more sense than the
arbitrary decisions in Python 2 about the relative ordering of e.g. ()
and [], or 0 and "". (Ironically, Raymond's pet type, set(), cannot be
compared to None even in Python 2.)
As long as you're comparing real numbers, negative infinity can
fulfill the role that Raymond is asking for. I suspect that for all
collection types, the "empty" value of that type is always naturally
the smallest value. If you really want to sort lists of completely
heterogeneous types, you can always use (tag, value) pairs where the
tags are small ints or strings representing type classifications (I
guess the type name would do in most cases).
I expect that, given the general trend that different types are not
comparable, making an exception for None is more likely a source of
errors than a source of joy.
--Guido
> Raymond Hettinger wrote:
> >> You should have been there when this was decided about two years ago.
> >
> > IIRC, the decision was a general one about cross-type
> > comparisons not being turned-on the default. I do not
> > recall a specific discussion about None.
> >
> > Also, the list at the time was flooded with propositions
> > ranging from the reasonable to the insane. It was not always
> > possible to know what to respond to or the implications of each
> > choice. I sure wasn't aware that those conversations were to be
> > immediately frozen in stone. I had thought one of the purposes
> > of the Py3.0 was so that we could download it and explore the
> > implications of all of these choices. I've done so and bumped
> > into the None comparability issue several times. If you no
> > longer want feedback, that's fine. I can bring my
> > experimentation with the 3.0 alpha to a close.
> >
> > Raymond
> > _______________________________________________
> > Python-3000 mailing list
> > Python-3000@python.org
> > http://mail.python.org/mailman/listinfo/python-3000
> > Unsubscribe:
> > http://mail.python.org/mailman/options/python-3000/talin%40acm.org
> >
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
