Re: Why is None <= 0
New style classes are classes inherited from class object. Therefore: class A: pass is oldstyle, while class B(object): pass is newstyle. On Tue, Apr 29, 2008 at 8:29 AM, blaine <[EMAIL PROTECTED]> wrote: > On Apr 29, 5:32 am, Duncan Booth <[EMAIL PROTECTED]> wrote: > > =?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote: > > > (FWIW, in 2.x, x>=4?, it's None < numbers < anything else; > > > numbers are ordered by value, everything else is ordered > > > by type name, then by address, unless comparison functions > > > are implemented). > > > > Quite apart from Jon pointing out that this isn't true for all cases > when > > copmparing against None, the other half also isn't true: > > > > >>> class C: pass > > >>> C() < 5 > > > > True > > > > That happens at least in Python 2.5.2 on win32. Yet another reason to > avoid > > old-style classes. > > Sorry - but what are new style classes? > -- > http://mail.python.org/mailman/listinfo/python-list > -- | _ | * | _ | | _ | _ | * | | * | * | * | -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
"Aaron Watters" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] |What's up with Tim Peters anyway? I haven't seen much from him for a while. I miss him too ;-) He occasionally responds to tracker or pydev math issues where his unique knowledge and experience is really needed. (As recently as last Jan). That is all I know. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
On Apr 25, 8:17 pm, Jon Ribbens <[EMAIL PROTECTED]> wrote: > On 2008-04-25, Martin v. Löwis <[EMAIL PROTECTED]> wrote: > > > None is smaller than anything. > > According to Tim Peters, this is not true. > > See http://bugs.python.org/issue1673405 This is unfortunate. I would advocate something like ordering "incomparable objects" by the name of their type or something similar. When building indexing structures it can be very nice to be able to construct a list of heterogeneous tuples and sort them without getting an exception. Implementing this using L.sort(cmp) where cmp is implemented in Python can result in a significant speed penalty. What's up with Tim Peters anyway? I haven't seen much from him for a while. -- Aaron Watters === http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=quote+tim+peters -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
blaine <[EMAIL PROTECTED]> wrote: > On Apr 29, 5:32 am, Duncan Booth <[EMAIL PROTECTED]> wrote: >> =?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> >> wrote: >> > (FWIW, in 2.x, x>=4?, it's None < numbers < anything else; >> > numbers are ordered by value, everything else is ordered >> > by type name, then by address, unless comparison functions >> > are implemented). >> >> Quite apart from Jon pointing out that this isn't true for all cases >> when copmparing against None, the other half also isn't true: >> >> >>> class C: pass >> >>> C() < 5 >> >> True >> >> That happens at least in Python 2.5.2 on win32. Yet another reason to >> avoid old-style classes. > > Sorry - but what are new style classes? > New style classes are anything type derived from object. e.g. class D(object): pass or (since list is derived from object): class E(list): pass Old style classes are those which either have old-style base classes or no base class at all (and no __metaclass__ either but don't worry about that for now) e.g. the class C above. The problem with old style classes is that various things either work subtly differently or don't work at all, but you don't get much warning. So basically steer clear of them. An example of something which doesn't work with old style classes would be the @property decorator: you can get the property, but setting it simply overwrites the property with the new value. See http://www.google.co.uk/search?q=python+%22new+style%22 for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
On Apr 29, 5:32 am, Duncan Booth <[EMAIL PROTECTED]> wrote: > =?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote: > > (FWIW, in 2.x, x>=4?, it's None < numbers < anything else; > > numbers are ordered by value, everything else is ordered > > by type name, then by address, unless comparison functions > > are implemented). > > Quite apart from Jon pointing out that this isn't true for all cases when > copmparing against None, the other half also isn't true: > > >>> class C: pass > >>> C() < 5 > > True > > That happens at least in Python 2.5.2 on win32. Yet another reason to avoid > old-style classes. Sorry - but what are new style classes? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote: > (FWIW, in 2.x, x>=4?, it's None < numbers < anything else; > numbers are ordered by value, everything else is ordered > by type name, then by address, unless comparison functions > are implemented). Quite apart from Jon pointing out that this isn't true for all cases when copmparing against None, the other half also isn't true: >>> class C: pass >>> C() < 5 True That happens at least in Python 2.5.2 on win32. Yet another reason to avoid old-style classes. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
Gregor Horvath wrote: D'Arcy J.M. Cain schrieb: On Fri, 25 Apr 2008 20:27:15 +0200 Gregor Horvath <[EMAIL PROTECTED]> wrote: >>> None <= 0 True Why? Why not? Because, from http://www.python.org/dev/peps/pep-0020/ : Errors should never pass silently. In the face of ambiguity, refuse the temptation to guess. Greg Good point. The problem is the typical one; Python did not originally have a Boolean type, and the retrofit resulted in weird semantics. C has the same issue. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
Grant Edwards <[EMAIL PROTECTED]> writes: > On 2008-04-25, D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote: > > On Fri, 25 Apr 2008 20:27:15 +0200 > > Gregor Horvath <[EMAIL PROTECTED]> wrote: > >> >>> None <= 0 > >> True > > Everything in Python can compare to everything else. > > Not true. Even more untrue in Python 3.0: Comparisons other than == and != between disparate types will raise an exception unless explicitly supported by the type http://www.python.org/dev/peps/pep-3100/#core-language> http://mail.python.org/pipermail/python-dev/2004-June/045111.html> -- \ "We demand rigidly defined areas of doubt and uncertainty!" -- | `\ Vroomfondel, _The Hitch-Hiker's Guide To The Galaxy_, Douglas | _o__)Adams | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
On 2008-04-25, D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote: > On Fri, 25 Apr 2008 20:27:15 +0200 > Gregor Horvath <[EMAIL PROTECTED]> wrote: >> >>> None <= 0 >> True >> >> Why? > > Why not? > >> Is there a logical reason? > > Everything in Python can compare to everything else. Not true. Python 2.4.4 (#1, Mar 20 2008, 09:20:52) [GCC 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10)] on linux2 >>> 3j < 7 Traceback (most recent call last): File "", line 1, in ? TypeError: no ordering relation is defined for complex numbers > It is up to the programmer to make sure that they are > comparing reasonable things. True. -- Grant Edwards grante Yow! BEEP-BEEP!! I'm a at '49 STUDEBAKER!! visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
On 2008-04-25, Martin v. Löwis <[EMAIL PROTECTED]> wrote: > None is smaller than anything. According to Tim Peters, this is not true. See http://bugs.python.org/issue1673405 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
> In my humble opinion, I think that comparisons involving None should > return None, but I trust that the designers came up with this for very > good reasons. As far as I know I've never been bitten by it. It's fixed in Python 3.x. Python 3.x refuses to compare objects unless one of both objects has explicit support for both types: >>> 1 < None Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: int() < NoneType() -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
Gregor Horvath wrote: Hi, >>> None <= 0 True Why? Is there a logical reason? Gregor -- http://mail.python.org/mailman/listinfo/python-list In early Python, the decision was made that the comparison of *any* two objects was legal and would return a consistent result. So objects of different types will compare according to an ordering on their types (an implementation dependent, unspecified, but consistent ordering), and objects of the same type will be compared according to rules that make sense for that type. Other implementations have the right to compare an integer and None differently, but on a specific implementation, the result will not change. Python 3 will raise an exception on such comparisons. Gary Herron -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
On 2008-04-25, Gregor Horvath <[EMAIL PROTECTED]> wrote: > Hi, > > >>> None <= 0 > True > > Why? Comparing objects of differing types produces an undefined result. Next time you do it, it might return False. (Well, it's not really going to, but it's allowed to.) > Is there a logical reason? For what? There's no reason it returns true rather than false. The more interesting question is why doesn't it raise an exception. -- Grant Edwards grante Yow! These PRESERVES should at be FORCE-FED to PENTAGON visi.comOFFICIALS!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
On Fri, 25 Apr 2008 11:54:23 -0700 Paul McNett <[EMAIL PROTECTED]> wrote: > In my humble opinion, I think that comparisons involving None should > return None... Like relational databases. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
D'Arcy J.M. Cain schrieb: On Fri, 25 Apr 2008 20:27:15 +0200 Gregor Horvath <[EMAIL PROTECTED]> wrote: >>> None <= 0 True Why? Why not? Because, from http://www.python.org/dev/peps/pep-0020/ : Errors should never pass silently. In the face of ambiguity, refuse the temptation to guess. Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
Gregor Horvath wrote: >>> None <= 0 True More accurately: None < 0 True Why? Is there a logical reason? None is "less than" everything except for itself: >>> None < 'a' True >>> None < False True >>> None == None True In my humble opinion, I think that comparisons involving None should return None, but I trust that the designers came up with this for very good reasons. As far as I know I've never been bitten by it. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
On Fri, 25 Apr 2008 20:27:15 +0200 Gregor Horvath <[EMAIL PROTECTED]> wrote: > >>> None <= 0 > True > > Why? Why not? > Is there a logical reason? Everything in Python can compare to everything else. It is up to the programmer to make sure that they are comparing reasonable things. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is None <= 0
None <= 0 > True > > Why? > Is there a logical reason? None is smaller than anything. The choice of making it so is arbitrary, however, Python 2.x tries to impose a total order on all objects (with varying success), therefore, it is necessary to take arbitrary choices. (FWIW, in 2.x, x>=4?, it's None < numbers < anything else; numbers are ordered by value, everything else is ordered by type name, then by address, unless comparison functions are implemented). Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Why is None <= 0
Hi, >>> None <= 0 True Why? Is there a logical reason? Gregor -- http://mail.python.org/mailman/listinfo/python-list
