[Tutor] 0 > "0" --> is there a "from __future__ import to make this raise a TypeError?

[Albert-Jan Roskam]

Hi,


In Python 2 one can do silly apple-pear comparisons such as 0> "0".*) "CPython implementation detail: Objects of different types except numbers are ordered by their type names; objects of the same types that don’t support proper comparison are ordered by their address.". In Python3 this has been fixed (it raises a TypeError). Is there a way to emulate this behavior in Python 2?



*)http://stackoverflow.com/questions/3270680/how-does-python-compare-string-and-int


Thank you!


Albert-Jan
_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mai

[Emile van Sebille]

On 10/12/2015 9:12 AM, Albert-Jan Roskam wrote:
> Hi,
>
>
> In Python 2 one can do silly apple-pear comparisons such as 0> "0".*) "CPython implementation detail: Objects of different types except numbers are ordered by their type names; objects of the same types that don’t support proper comparison are ordered by their address.". In Python3 this has been fixed (it raises a TypeError). Is there a way to emulate this behavior in Python 2?
>
>
>
> *)http://stackoverflow.com/questions/3270680/how-does-python-compare-string-and-int
>

See if implementing __cmp__ gets you what you're looking for.

See http://www.rafekettler.com/magicmethods.html#comparisons for more info.

Emile


_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinf

[Albert-Jan Roskam]

----------------------------------------
> To: ***@python.org
> From: ***@fenx.com
> Date: Mon, 12 Oct 2015 09:25:00 -0700
> Subject: Re: [Tutor] 0> "0" --> is there a "from __future__ import to make this raise a TypeError?
>
> On 10/12/2015 9:12 AM, Albert-Jan Roskam wrote:
>> Hi,
>>
>>
>> In Python 2 one can do silly apple-pear comparisons such as 0> "0".*) "CPython implementation detail: Objects of different types except numbers are ordered by their type names; objects of the same types that don’t support proper comparison are ordered by their address.". In Python3 this has been fixed (it raises a TypeError). Is there a way to emulate this behavior in Python 2?
>>
>>
>>
>> *)http://stackoverflow.com/questions/3270680/how-does-python-compare-string-and-int
>>
>
> See if implementing __cmp__ gets you what you're looking for.
>
> See http://www.rafekettler.com/magicmethods.html#comparisons for more info.
>
> Emile

Hi Emille,

Maybe like so? Is it possible to call __cmp__ wiithout the need to make an instance? I would find it nicer if I could do Cmp(42) == "42".
Also, the two if/elifs don't feel quite right/generic.

# -*- coding: utf-8 -*-.

class Cmp(object):
    """Compare objects the Python 3 way: no apple-pear comparisons allowed!
   
   >>> x = Cmp()  # doctest: +IGNORE_EXCEPTION_DETAIL
   >>> x(42) == "42"
    Traceback (most recent call last):
    ...
    TypeError
   >>> x(42) == 42
    True
   >>> x(42) == 42.1
    False
   >>> x("42")> 0
    Traceback (most recent call last):
    ...
    TypeError
    """
    def __call__(self, x):
        self.x = x
        return self
    def __cmp__(self, y):
        #print "__cmp__"
        self.y = y
        if isinstance(self.x, (str, unicode)) and hasattr(self.y, "__int__"):
            raise TypeError
        elif isinstance(self.y, (str, unicode)) and hasattr(self.x, "__int__"):
            raise TypeError
        return -1 if self.x < self.y else 0 if self.x == self.y else 1


if __name__ == "__main__":
    import doctest
    doctest.testmod()




_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/list

[Oscar Benjamin]

On Mon, 12 Oct 2015 17:15 Albert-Jan Roskam <***@hotmail.com> wrote:

Hi,

In Python 2 one can do silly apple-pear comparisons such as 0> "0".*)
"CPython implementation detail: Objects of different types except numbers
are ordered by their type names; objects of the same types that don’t
support proper comparison are ordered by their address.". In Python3 this
has been fixed (it raises a TypeError). Is there a way to emulate this
behavior in Python 2?



Why do you want to? This kind of thing is nice to have when it's there by
default since it can help pick up errors. When it's not there that's
unfortunate which is why this was changed in Python 3 but it's not really
essential.

Most of the time you won't mix strings and ints unless it's a mistake. Are
you worried about making mistakes? Why not just test your code under Python
3 if so?

--
Oscar
_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/ma

[Albert-Jan Roskam]

From: ***@gmail.com
Date: Mon, 12 Oct 2015 20:37:43 +0000
Subject: Re: [Tutor] 0> "0" --> is there a "from __future__ import to make this raise a TypeError?
To: ***@hotmail.com; ***@python.org





On Mon, 12 Oct 2015 17:15 Albert-Jan Roskam wrote:
Hi,

In Python 2 one can do silly apple-pear comparisons such as 0> "0".*) "CPython implementation detail: Objects of different types except numbers are ordered by their type names; objects of the same types that don’t support proper comparison are ordered by their address.". In Python3 this has been fixed (it raises a TypeError). Is there a way to emulate this behavior in Python 2?





Why do you want to? This kind of thing is nice to have when it's there by default since it can help pick up errors. When it's not there that's unfortunate which is why this was changed in Python 3 but it's not really essential.
Most of the time you won't mix strings and ints unless it's a mistake. Are you worried about making mistakes? Why not just test your code under Python 3 if so?
--


========

Hi Oscar

Yes, a justified fear of making mistakes. That is, a mistake has already occurred and I don't want it to happen again.
I made a comparison with data from two sources: a csv file (reference file) an sqlite database (test data). The csv module will always return str, unless one converts it. The test data were written to sqlite with pandas.to_sql, which (it seems) tries to be helpful by making INTs of everything that looks like ints. I chose sqlite because the real data will be in SQL server, and I hope this would mimic the behavior wrt None, NULL, nan, "", etc.

Yesterday I already posted a class with a modified __cmp__ method. Not sure if it came through (I' ve had major problems with DMARC when I was still using yahoo, not yet sure about hotmail)

Regards,
Albert-Jan

_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription op

[Martin A. Brown]

Greetings Albert-Jan,

I have a suggestion and a comment in this matter.

> Yes, a justified fear of making mistakes. That is, a mistake has
> already occurred and I don't want it to happen again.

Suggestion: Choose a single in-memory representation of your data
and make all of your input and output functions perform conversion
to appropriate data types.

See below for a bit more explanation.

> I made a comparison with data from two sources: a csv file
> (reference file) an sqlite database (test data). The csv module
> will always return str, unless one converts it. The test data were
> written to sqlite with pandas.to_sql, which (it seems) tries to be
> helpful by making INTs of everything that looks like ints. I chose
> sqlite because the real data will be in SQL server, and I hope
> this would mimic the behavior wrt None, NULL, nan, "", etc.

Comment and explanation: I have been following this thread and I
will tell you how I would look at this problem (instead of trying to
compare different data types).

* It sounds as though you will have several different types of
backing stores for your data. You mentioned 1) csv, 2) sqlite,
3) SQL server. Each of these is a different serialization tool.

* You also mention comparisons. It seems as though you are
comparing data acquired (read into memory) from backing store 1)
to data retrieved from 2).

If you are reading data into memory, then you are probably planning
to compute, process, transmit or display the data. In each case,
I'd imagine you are operating on the data (numerically, if they are
numbers).

I would write a function (or class or module) that can read the data
from any of the backing stores you want to use (csv, sqlite, SQL
server, punch cards or even pigeon feathers). Each piece of code
that reads data from a particular serialization (e.g. sqlite) would
be responsible for converting to the in-memory form.

Thus, it would not matter where you store the data...once it's in
memory, the form or representation you have chosen will be
identical.

There is the benefit, then, of your code being agnostic (or
extensible) to the serialization tool.

By the way, did you know that pandas.to_csv() [0] also exists?

-Martin

[0] http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.to_csv.html

--
Martin A. Brown
http://linux-ip.net/
_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Danny Yoo]

> In Python 2 one can do silly apple-pear comparisons such as 0> "0".*) "CPython implementation detail: Objects of different types except numbers are ordered by their type names; objects of the same types that don’t support proper comparison are ordered by their address.". In Python3 this has been fixed (it raises a TypeError). Is there a way to emulate this behavior in Python 2?


I don't think so, at least, not easily.

I think that you probably want to move to Python 3 if possible
specifically because it cleans up issues like this. There are a few
niggling differences between Python 2 and 3, most of them with the
same characteristic as the one you're pointing out with loose
comparison. (e.g. distinguishing bytes vs strings is another one of
the fixes in Python 3). And if you're willing to change the
semantics of "<" in Python 2, you're already well on your way to
Python 3.
_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:

[Steven D'Aprano]

On Mon, Oct 12, 2015 at 04:12:57PM +0000, Albert-Jan Roskam wrote:
> Hi,
>
>
> In Python 2 one can do silly apple-pear comparisons such as 0> "0".*)
> "CPython implementation detail: Objects of different types except
> numbers are ordered by their type names; objects of the same types
> that don’t support proper comparison are ordered by their address.".
> In Python3 this has been fixed (it raises a TypeError). Is there a way
> to emulate this behavior in Python 2?

I don't believe so.

You could write your own comparison functions and use those:


def gt(a, b):
if type(a) is type(b):
return a > b
raise TypeError

if gt(this, that): ...


but there's no way to change the behaviour of the comparison operators >
etc themselves, nor of list.sort.

In hindsight, this should have been a __future__ import, but it's too
late now :-(



--
Steve
_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.pyth