Re: [Python-Dev] Proper way to specify that a method is not defined for a type

2016-06-07 Thread R. David Murray
For those interested in this topic, if you are not already aware of it,
see also http://bugs.python.org/issue25958, which among other things
has a relevant proposed patch for datamode.rst.

On Tue, 07 Jun 2016 10:56:37 -0700, Guido van Rossum  wrote:
> Setting it to None in the subclass is the intended pattern. But CPython
> must explicitly handle that somewhere so I don't know how general it is
> supported. Try defining a list subclass with __len__ set to None and see
> what happens. Then try the same with MutableSequence.
> 
> On Tue, Jun 7, 2016 at 10:37 AM, Ethan Furman  wrote:
> 
> > For binary methods, such as __add__, either do not implement or return
> > NotImplemented if the other operand/class is not supported.
> >
> > For non-binary methods, simply do not define.
> >
> > Except for subclasses when the super-class defines __hash__ and the
> > subclass is not hashable -- then set __hash__ to None.
> >
> > Question:
> >
> > Are there any other methods that should be set to None to tell the
> > run-time that the method is not supported?  Or is this a general mechanism
> > for subclasses to declare any method is unsupported?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Proper way to specify that a method is not defined for a type

2016-06-07 Thread Guido van Rossum
Setting it to None in the subclass is the intended pattern. But CPython
must explicitly handle that somewhere so I don't know how general it is
supported. Try defining a list subclass with __len__ set to None and see
what happens. Then try the same with MutableSequence.

On Tue, Jun 7, 2016 at 10:37 AM, Ethan Furman  wrote:

> For binary methods, such as __add__, either do not implement or return
> NotImplemented if the other operand/class is not supported.
>
> For non-binary methods, simply do not define.
>
> Except for subclasses when the super-class defines __hash__ and the
> subclass is not hashable -- then set __hash__ to None.
>
> Question:
>
> Are there any other methods that should be set to None to tell the
> run-time that the method is not supported?  Or is this a general mechanism
> for subclasses to declare any method is unsupported?
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Proper way to specify that a method is not defined for a type

2016-06-07 Thread Émanuel Barry
> From: Ethan Furman
> Sent: Tuesday, June 07, 2016 1:38 PM
> To: Python Dev
> Subject: [Python-Dev] Proper way to specify that a method is not defined
for
> a type

(Just so everyone follows, this is a followup of
http://bugs.python.org/issue27242 )

> For binary methods, such as __add__, either do not implement or return
> NotImplemented if the other operand/class is not supported.
> 
> For non-binary methods, simply do not define.
> 
> Except for subclasses when the super-class defines __hash__ and the
> subclass is not hashable -- then set __hash__ to None.

Should I mention the __hash__ special case in the
NotImplemented/NotImplementedError docs? If people are looking for a way to
declare this specific operation undefined, they'd find it there as well as
the hash() documentation.

> Question:
> 
> Are there any other methods that should be set to None to tell the
> run-time that the method is not supported?  Or is this a general
> mechanism for subclasses to declare any method is unsupported?

There was a discussion on one of Python-ideas or Python-dev some time ago
about exactly that, but I don't think any consensus was reached. However, I
think it would make sense for e.g. __iter__ and __reversed__ to tell the
interpreter to *not* fall back to the default sequence protocol (well, in
practice that already works, but it gives an unhelpful error message). I'm
not sure how useful it would be for arbitrary methods, though. __bytes__
(which originally sparked the issue) may or may not be a good candidate, I'm
not sure.

While I like the `__magic_method__ = None` approach, I think the main reason
__hash__ supports that is because there are legitimate use cases of
disallowing hashing (i.e. mutable objects which may or may not change hash
during their lifetime), but I don't think the same rationale applies to
everything ("accidentally" iterating over a not-meant-to-be-iterable object
will result in nonsensical data, but it won't bite the user later, unlike
changing hashes which definitely will).

> --
> ~Ethan~

Special-cases-aren't-special-enough-but-they're-still-there'ly yrs,
-Emanuel
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Proper way to specify that a method is not defined for a type

2016-06-07 Thread Ethan Furman
For binary methods, such as __add__, either do not implement or return 
NotImplemented if the other operand/class is not supported.


For non-binary methods, simply do not define.

Except for subclasses when the super-class defines __hash__ and the 
subclass is not hashable -- then set __hash__ to None.


Question:

Are there any other methods that should be set to None to tell the 
run-time that the method is not supported?  Or is this a general 
mechanism for subclasses to declare any method is unsupported?


--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com