En Fri, 20 Apr 2007 23:48:02 -0300, Alex Martelli <[EMAIL PROTECTED]> escribió:
> Gabriel Genellina <[EMAIL PROTECTED]> wrote:
>
>> Reference Manual, 5.9 Comparisons
>>
>> "The objects need not have the same type. If both are numbers, they are
>> converted to a common type. Otherwise, objects of d
Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> En Fri, 20 Apr 2007 11:40:00 -0300, Alex Martelli <[EMAIL PROTECTED]>
> escribió:
>
> > I'm still interested to know where that erroneous quote from Alan Isaac
> > comes from, because if it's in Python's docs, it can be fixed.
>
> It was a partial
En Fri, 20 Apr 2007 11:40:00 -0300, Alex Martelli <[EMAIL PROTECTED]> escribió:
> I'm still interested to know where that erroneous quote from Alan Isaac
> comes from, because if it's in Python's docs, it can be fixed.
It was a partial quote, that's why it appeared to be wrong:
Library reference
Tommy Grav <[EMAIL PROTECTED]> wrote:
> On Apr 19, 2007, at 11:00 PM, Alex Martelli wrote:
>
> > Alan Isaac <[EMAIL PROTECTED]> wrote:
> >
> >> currently documented behavior:
> >> "objects of different types always compare unequal".
> >
> > Where is that documented? URL please?
> >
> 1.0 ==
On Apr 19, 2007, at 11:00 PM, Alex Martelli wrote:
> Alan Isaac <[EMAIL PROTECTED]> wrote:
>
>> currently documented behavior:
>> "objects of different types always compare unequal".
>
> Where is that documented? URL please?
>
1.0 == 1
> True
type(1.0), type(1)
> (, )
>
Isn't this an
"Steve Holden" <[EMAIL PROTECTED]> wrote:
> PS: Revision question: How many objects of type NoneType are there?
You ask the damnesd Questions.
There must be millions of the little buggers out there, with the population
shifting incessantly as instances of the interpreter are started, and die..
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> But if you wanted to do extra work unnecessarily, a less unnecessary
> amount of extra work would be:
>
> if type(x) == type(None): ...
Of course, like the original poster's proposal, this CAN be faked out
(while the 'is' test cannot, one more weird r
Alan Isaac <[EMAIL PROTECTED]> wrote:
> currently documented behavior:
> "objects of different types always compare unequal".
Where is that documented? URL please?
>>> 1.0 == 1
True
>>> type(1.0), type(1)
(, )
here, just as an example, are two objects of different types that
compare equal; the
On Thu, 19 Apr 2007 17:00:29 +, Alan Isaac wrote:
>
> "Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> You shouldn't expect comparisons between types to
>> sort the same from one version of Python to another, although they may,
>> and in the future (Python 3)
On Thursday 19 April 2007, Steven Howe wrote:
> > ((int(3) > int(4)) == True) == True
> >
> > Explicit is better than sensible, yes?
> >
> > *wink*
>
> Your example, even with the *wink*, is stupid. The language requires 3
> to be an integer, 4 to be an integer.
Incidentally, the language also req
| Alan Isaac wrote:
| > "Terry Reedy" <[EMAIL PROTECTED]> wrote in message
| > news:[EMAIL PROTECTED]
| >
| >> Should be in the reference manual section on comparisons.
| > Only to this extent:
| > http://www.python.org/doc/2.4/ref/comparisons.html
| >
| > objects of different types always
Steven Howe a écrit :
(snip)
> I've read and found that 'None' comparisons is not always a good idea.
> Better to:
> from types import NoneType
>
> x = None
> if type( x ) == NoneType:
># true
>< code >
> else:
># false; do something else.
>< more code >
Actually, None is garantee
out the redundancy in the
expression (3 > 4) == True.
> As much as I love Python, it's ability to morph an object type can be a
> pain. Testing before using can prevent a program from Error-ing out.
>
You still don't convince me that there is there is *any* value in
chec
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> You shouldn't expect comparisons between types to
> sort the same from one version of Python to another, although they may,
> and in the future (Python 3) it is likely to become an error to compare
> incomparable objec
"Steve Holden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Steven Howe wrote:
> > Alan Isaac wrote: [type comparison stuff]
> > I love scripting languages ... but sometimes an explicit evaluation that
> > one would find in
> > a compiled language is better.
Actually all that lang
On 4/19/07, Steven Howe <[EMAIL PROTECTED]> wrote:
>
> Steven D'Aprano wrote:
> On Thu, 19 Apr 2007 08:18:30 -0400, Steve Holden wrote:
>
>
>
>
> Which is why I suggested using the explicit type(x) == types.NoneType as
> opposed to
> x is None
>
>
>
> This seems to go entirely against the spiri
Steven D'Aprano wrote:
On Thu, 19 Apr 2007 08:18:30 -0400, Steve Holden wrote:
Which is why I suggested using the explicit type(x) == types.NoneType as
opposed to
x is None
This seems to go entirely against the spirit of the language. It's about
as sensible as writing
(3 > 4)
On Wed, 18 Apr 2007 15:19:26 -0700, Steven Howe wrote:
> I've read and found that 'None' comparisons is not always a good idea.
You're probably thinking of testing against None with equality:
if x == None: do_something()
That can go wrong if x is a class that has an overly-broad concept of
equa
On Thu, 19 Apr 2007 08:18:30 -0400, Steve Holden wrote:
>> Which is why I suggested using the explicit type(x) == types.NoneType as
>> opposed to
>> x is None
>>
>>
> This seems to go entirely against the spirit of the language. It's about
> as sensible as writing
>
>(3 > 4) == True
Ple
Steven Howe wrote:
> Alan Isaac wrote: [type comparison stuff]
> I love scripting languages ... but sometimes an explicit evaluation that
> one would find in
> a compiled language is better.
"better" in what sense?
> Which is why I suggested using the explicit type(x) == types.NoneType as
> opp
On Thu, 19 Apr 2007 02:46:18 +, Alan Isaac wrote:
> However, Gary Herron's explanation makes sense: this provides a stable
> sort when None is involved, and meets the criterion that objects of
> different types must always compare unequal.
That's only correct for "sensible" objects that don't
Alan Isaac wrote:
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Should be in the reference manual section on comparisons.
Only to this extent:
http://www.python.org/doc/2.4/ref/comparisons.html
objects of different types always compare unequal, and
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Should be in the reference manual section on comparisons.
Only to this extent:
http://www.python.org/doc/2.4/ref/comparisons.html
objects of different types always compare unequal, and are ordered
consiste
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Should be in the reference manual section on comparisons.
Only to this extent:
http://www.python.org/doc/2.4/ref/comparisons.html
objects of different types always compare unequal, and are ordered
consiste
Steven Howe wrote:
> Alan G Isaac wrote:
>> >>> None >= 0
>> False
>> >>> None <= 0
>> True
>>
>> Explanation appreciated.
>>
>> Thanks,
>> Alan Isaac
>>
> I've read and found that 'None' comparisons is not always a good idea.
> Better to:
> from types import NoneType
>
> x = None
> if type(
[EMAIL PROTECTED] wrote:
> On Apr 18, 3:19 pm, Steven Howe <[EMAIL PROTECTED]> wrote:
>
>> I've read and found that 'None' comparisons is not always a good idea.
>> Better to:
>> from types import NoneType
>>
>> x = None
>> if type( x ) == NoneType:
>> # true
>> < code >
>> else:
>>
Alan G Isaac wrote:
> >>> None >= 0
> False
> >>> None <= 0
> True
>
> Explanation appreciated.
>
> Thanks,
> Alan Isaac
>
So that we can sort lists of objects, even when the objects of are
different types, Python guarantees to supply a unique and consistent
ordering of any two objects. The
[EMAIL PROTECTED] wrote:
> On Apr 18, 3:19 pm, Steven Howe <[EMAIL PROTECTED]> wrote:
>> I've read and found that 'None' comparisons is not always a good idea.
>> Better to:
>> from types import NoneType
>>
>> x = None
>> if type( x ) == NoneType:
>> # true
>> < code >
>> else:
>> # fal
On Apr 18, 3:19 pm, Steven Howe <[EMAIL PROTECTED]> wrote:
> I've read and found that 'None' comparisons is not always a good idea.
> Better to:
> from types import NoneType
>
> x = None
> if type( x ) == NoneType:
> # true
> < code >
> else:
> # false; do something else.
> < more c
On Apr 18, 5:19 pm, Steven Howe <[EMAIL PROTECTED]> wrote:
> Alan G Isaac wrote:
> > >>> None >= 0
> > False
> > >>> None <= 0
> > True
>
> > Explanation appreciated.
>
> > Thanks,
> > Alan Isaac
>
> I've read and found that 'None' comparisons is not always a good idea.
> Better to:
> from types
Alan G Isaac wrote:
> >>> None >= 0
> False
> >>> None <= 0
> True
>
> Explanation appreciated.
>
> Thanks,
> Alan Isaac
>
I've read and found that 'None' comparisons is not always a good idea.
Better to:
from types import NoneType
x = None
if type( x ) == NoneType:
# true
< code >
el
"Alan G Isaac" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| >>> None >= 0
| False
| >>> None <= 0
| True
|
| Explanation appreciated.
Should be in the reference manual section on comparisons.
--
http://mail.python.org/mailman/listinfo/python-list
>>> None >= 0
False
>>> None <= 0
True
Explanation appreciated.
Thanks,
Alan Isaac
--
http://mail.python.org/mailman/listinfo/python-list
33 matches
Mail list logo
