On 01/06/2015 05:35 AM, Chris Angelico wrote:
On Wed, Jan 7, 2015 at 12:30 AM, Andrew Robinson
<andr...@r3dsolutions.com> wrote:
Why this is so important to Guido, I don't know ... but it's making it VERY
difficult to add named aliases of False which will still be detected as
False and type-checkable as a bool. If my objects don't type check right --
they will likely break some people's legacy code... and I really don't even
care to create a new instance of the bool object in memory which is what
Guido seems worried about, rather I'm really only after the ability to
detect the subclass wrapper name as distinct from bool False or bool True
with the 'is' operator. If there were a way to get the typecheck to match,
I wouldn't mind making a totally separate class which returned the False
instance; eg: something like an example I modified from searching on the
web:
Okay, so why not just go with your own class, and deal with the
question of the type check? Simple solution: Instead of fiddling with
__gt__/__lt__, create your own method, and use your own comparison
function to sort these things.
ChrisA
Because defining a bunch of special methods defeats the very purpose of
making my class compatible with float variables.
eg: No legacy code would work...
I know (belatedly) that am going to have to define my own class.
That's pretty much a given, but I want to do it in a way which requires
my users to make very few changes to their traditional floating point
algorithms and code.
The type check issue is mostly about compatability in the first place ;
eg: users typecheck either unintentionally -- (novices syndrome) -- or
because they need all the capabilities of a given type, and the only
simple way to find out if they are all there are there is to typecheck.
eg: That's the whole point of subclassing bool ... to let the user know
they have at their disposal (in a portable, simple way) all the features
of the base type.
Well, if I make a new object -- type checking is pointless. No user
thinking they were coding for floating point in the past would know that
my new return type is totally compatible with bool. They would have to
have written individual tests for the existence of every method in bool,
and why would they be crazy enough to do that? It's a lot of work for
nothing...
--
https://mail.python.org/mailman/listinfo/python-list
