Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #32338

Re: Re: Simple Python question for some

Date 2012-10-28 23:30 -0500
From Evan Driscoll <driscoll@cs.wisc.edu>
Subject Re: Re: Simple Python question for some
References <00c501cdb567$28ead530$7ac07f90$@gmail.com> <CAPTjJmq_Svcpzaq-aqouqrQJ67Xc7=YRZwqEBzVRCOrRXTVXeQ@mail.gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.2992.1351485346.27098.python-list@python.org> (permalink)

Show all headers | View raw


On 10/28/2012 7:18 PM, Chris Rebert wrote:
> This is fixed in Python 3, where such nonsensical comparisons will
> instead raise TypeError.

It's worth pointing out that at least one kind of inequality comparison
which some people (e.g. me) would consider nonsensical is still allowed
in Python 3, which is between Boolean values and numbers:

  >>> True < 1
  False
  >>> False < 1
  True

which is probably because

  >>> True == 1
  True
  >>> False == 0
  True

Many people (probably most people, to be honest) disagree with me that
this is wrong, but regardless of whether you like it or not you need to
know what happens in such cases.


On 10/28/2012 7:18 PM, Chris Angelico wrote:
> Which means that strings will ALWAYS be compared as strings, and
> numbers will ALWAYS be compared as numbers, and ne'er the twain shall
> conflict. I can trust Python to compare MD5 hashes reliably:
> 
>>>> "912128034267498495410681495015e0" !=00912128034267498495410681495015"
> True
> 
> Of course, I'm not pointing fingers at any other languages here, but
> this is a known security hole in one rather widely-used one.

If you are PerHaPs talking about the language I think you are, my
favorite fact about that is I'm that I think a while back I saw a bug
entry about something like that and they weren't sure how or even if it
should be fixed.

Evan

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

Re: Re: Simple Python question for some Evan Driscoll <driscoll@cs.wisc.edu> - 2012-10-28 23:30 -0500

csiph-web