Re: [Python-Dev] cpython: Issue 14814: Correctly return NotImplemented from ipaddress._BaseNetwork.__eq__

2012-07-07 Thread Antoine Pitrou
On Sat,  7 Jul 2012 15:08:42 +0200 (CEST)
nick.coghlan  wrote:
>  
>  def __eq__(self, other):
> -if not isinstance(other, _BaseNetwork):
> -raise TypeError('%s and %s are not of the same type' % (
> - self, other))
> -return (self._version == other._version and
> -self.network_address == other.network_address and
> -int(self.netmask) == int(other.netmask))
> +try:
> +return (self._version == other._version and
> +self.network_address == other.network_address and
> +int(self.netmask) == int(other.netmask))
> +except AttributeError:
> +return NotImplemented

I think the isinstance() test was correct. If you have an object which
duck-types IPNetwork, you probably want its __eq__ to be called, not
yours.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] cpython: Issue 14814: Correctly return NotImplemented from ipaddress._BaseNetwork.__eq__

2012-07-07 Thread Nick Coghlan
On Sat, Jul 7, 2012 at 11:55 PM, Antoine Pitrou  wrote:
> I think the isinstance() test was correct. If you have an object which
> duck-types IPNetwork, you probably want its __eq__ to be called, not
> yours.

This change was just to bring IPNetwork in line with the other types
in the module and to stop it throwing TypeError itself, which meant
the RHS was never even getting a chance to affect the result.

Ducktyping and operator overloading has always been a tricky area
though. If you use isinstance() checks, then the other side has to
know how to reimplement your equality check, or temporarily create a
real instance to do the comparison. If you use ducktyping internally,
then the other side *has* to use inheritance if they want to
completely control the result, but also have the option to just expose
the appropriate attributes in order to interoperate with your class.

The standard library tends to be a mixture of both based on how
integral the author feels the ordering and comparison behaviour is to
the classes involved. In this case, I currently think internal
ducktyping is the right answer, but I'm open to being persuaded
otherwise.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] cpython: Issue 14814: Correctly return NotImplemented from ipaddress._BaseNetwork.__eq__

2012-07-07 Thread Nick Coghlan
On Sun, Jul 8, 2012 at 12:59 AM, Nick Coghlan  wrote:
> On Sat, Jul 7, 2012 at 11:55 PM, Antoine Pitrou  wrote:
>> I think the isinstance() test was correct. If you have an object which
>> duck-types IPNetwork, you probably want its __eq__ to be called, not
>> yours.
>
> This change was just to bring IPNetwork in line with the other types
> in the module and to stop it throwing TypeError itself, which meant
> the RHS was never even getting a chance to affect the result.

Hmm, I just noticed the __lt__ implementations still throw TypeError
directly (at least in the IPNetwork case). Looks like some more
cleanups are still needed in this area :P

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] cpython (3.2): Fix issue14826 - make urllib.request.Request quoted url consistent with

2012-07-07 Thread Antoine Pitrou
>  
> +def test_quote_url(self):
> +Request = urllib.request.Request
> +request = Request("http://www.python.org/foo bar")
> +self.assertEqual(request.full_url, "http://www.python.org/foo%20bar";)
> +

This means someone who already quotes URL will get a double escaping,
right?

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com