On Mon, Apr 25, 2022 at 03:38:21PM -, aanonyme.perso...@hotmail.fr wrote:
> Typically, when subclassing a NamedTuple type, you often don't want
> the <, >, <=, >=, + or * operators to work, so in that case you would
> want for the related methods to return NotImplemented.
When I have
On Tue, 26 Apr 2022 at 09:00, wrote:
>
> This is useful in the context of reducing the available methods and operator
> overloading, when subclassing a type.
> Typically, when subclassing a NamedTuple type, you often don't want the <, >,
> <=, >=, + or * operators to work, so in that case you
This is useful in the context of reducing the available methods and operator
overloading, when subclassing a type.
Typically, when subclassing a NamedTuple type, you often don't want the <, >,
<=, >=, + or * operators to work, so in that case you would want for the
related methods to return
On Sun, Apr 17, 2022 at 07:39:29PM +1200, Greg Ewing wrote:
> On 16/04/22 10:26 pm, Steven D'Aprano wrote:
> >C++ and Eiffel are even stricter (more restrictive) than Python. They
> >don't just exclude class hierarchies which are inconsistent, they
> >exclude class hierarchies with perfectly good
Stephen J. Turnbull writes:
> It's usually helpful to assume that if you parse someone's statement
> as nonsense, then probably you parsed it wrong.
Sorry, s/wrong/inconsistent with the statement's intended meaning/.
Obviously the statement was parsed correctly as English. It's "wrong"
only
