Path: csiph.com!usenet.pasdenom.info!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.004 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'operator': 0.03; 'interpreter': 0.05; '"""': 0.07; 'assuming': 0.09; 'correct,': 0.09; 'from:addr:ethan': 0.09; 'from:addr:stoneleaf.us': 0.09; 'from:name:ethan furman': 0.09; 'here?': 0.09; 'message- id:@stoneleaf.us': 0.09; '~ethan~': 0.09; 'python': 0.11; 'behave': 0.16; 'bonus.': 0.16; 'container,': 0.16; 'container.': 0.16; 'filename:fname piece:signature': 0.16; 'finney': 0.16; 'implies': 0.16; 'nan': 0.16; "type's": 0.16; 'wrote:': 0.18; '>>>': 0.22; 'header:User-Agent:1': 0.23; '(or': 0.24; 'specially': 0.26; 'values': 0.27; 'header:In-Reply-To:1': 0.27; 'point': 0.28; 'correct': 0.29; '[1]': 0.29; 'along': 0.30; 'membership': 0.31; 'directly,': 0.31; 'steven': 0.31; 'writes:': 0.31; 'class': 0.32; 'skip:_ 10': 0.34; 'problem': 0.35; 'subject: (': 0.35; 'no,': 0.35; 'objects': 0.35; 'but': 0.35; 'false': 0.36; 'subject:?': 0.36; 'example,': 0.37; 'being': 0.38; 'ben': 0.38; 'needed': 0.38; 'to:addr:python-list': 0.38; 'issue': 0.38; 'pm,': 0.38; 'does': 0.39; 'to:addr:python.org': 0.39; 'how': 0.40; 'is.': 0.60; 'received:173': 0.61; 'skip:n 10': 0.64; 'skip:\xe2 10': 0.65; 'equals': 0.68; 'optimized': 0.68; '8bit%:43': 0.74; 'other.': 0.75; 'behavior': 0.77; 'as:': 0.81; '"spam"': 0.84; 'ethan': 0.84; 'furman': 0.84; 'optimisation': 0.84 Date: Thu, 05 Mar 2015 19:44:56 -0800 From: Ethan Furman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: python-list@python.org Subject: Re: Is nan in (nan,) correct? References: <54f90c53$0$12994$c3e8da3$5496439d@news.astraweb.com> <858ufazvff.fsf@benfinney.id.au> <54F91C70.6020303@stoneleaf.us> <85wq2uyffs.fsf@benfinney.id.au> In-Reply-To: <85wq2uyffs.fsf@benfinney.id.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xEMNxtaUcJUSV79HcQbtLMs4tcatvMbKA" X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.19 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 91 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1425613536 news.xs4all.nl 2958 [2001:888:2000:d::a6]:56219 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:86980 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xEMNxtaUcJUSV79HcQbtLMs4tcatvMbKA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/05/2015 07:26 PM, Ben Finney wrote: > Ethan Furman writes: >=20 >> On 03/05/2015 06:55 PM, Ben Finney wrote: >> >>> class NullType(object): >>> """ A type whose value never equals any other. >>> >>> This type's values will behave correctly when tested for >>> membership in a collection:: >>> >>> >>> foo =3D NullType() >>> >>> bar =3D NullType() >>> >>> foo is foo >>> True >>> >>> foo is bar >>> False >>> >>> foo =3D=3D foo >>> False >>> >>> foo =3D=3D bar >>> False >>> >>> quux =3D [foo, "spam"] >>> >>> "spam" in quux >>> True >>> >>> foo in quux >>> True >> >> Did you mean False here? Because True is current behavior. >=20 > Isn't the point at issue that the Python interpreter *may* optimise by > assuming =E2=80=98is implies equality=E2=80=99, so the =E2=80=98in=E2=80= =99 operator can fail if that > assumption is false? No, it's not a /may/, it's a /does/, and that it can be optimized is a bo= nus. > I thought the problem was that types with custom behaviour, as with the= > =E2=80=98NullType=E2=80=99 example, needed to deal specially with the =E2= =80=98is implies > equality=E2=80=99 optimisation Steven explained. The NaN-type objects cannot deal with it directly, as that behavior is in= the container. > If that's the correct behaviour, and we can *depend* on it being > correct, then I don't see what the problem is. Well, we can depend on it for native Python types -- but if you write you= r own container, along with your own __contains__, then you might unwittingly do `for item in self.container:= if item =3D=3D target: return True` and then NaN (or NullType, or what-have-you) would not work "correctly" [1] for your c= ontainer. -- ~Ethan~ [1] Otherwise known as: how Python does it. --xEMNxtaUcJUSV79HcQbtLMs4tcatvMbKA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJU+SK8AAoJENZ7D1rrH75NziUQAMH2V2U1llYd3ND0jLTqQ+1c XgttXMWAvAdxZQZGH7lz2plX1AsMBy+sj4zPrYhxQn5g4YP1X6RcIibo9oWxotDa 9wRTmPAe9Z3nruT536rWPsN4B2l+BozEQpsTIj2oL2WAwS2qq3foEXqpNlAnzEHi bNGSmv7IVLpGaAj+GMEVLfveCvNEX6RrE/3ASbZM+xiEtv51PjYbfrT7yhd+5OC3 vH/uCZxFPO4ND69wRlgtJxtjB0wocuVH4lLHvSweVexytSpBPqwst4he6SuMNkRH LL8AfY+aAxcrX50EgT583qy6BJmkwU7ApANPH0dfMhjrN6Q6NiRxxPDli5soyThz 6MyxqRJlAhUEcTp9//wakl6sVBXQSn/QeoCNrrhw7L5LADZ49UJ2kXsb48VkV52W IA0Mu8yv7IKgUv5aZK9NkcirC4T9hXzAuam/3yH+yEJaQV8hzdWKgoOTP8BjnGFs xC2MkVw1G21SAcHeHYvWvvgiEpMCPUQoo8kSuAv0OSJetOa3t9ANNcUcOvx3cLHH 7FpUAvCLIws5JnhM6QX0ajNzQwXxo7yyPRxcWg9nASYSD+z+YkyZu2v83+oPNIlX IPPr8JcWWn4Yvh8oXDjDODKJQgGpLffWYPLO3gVkyv+2ebzLJpqslpSa2Mzj7q8A Ctu8QQVkBjcR+a8o70W3 =Vk6f -----END PGP SIGNATURE----- --xEMNxtaUcJUSV79HcQbtLMs4tcatvMbKA--