[Python-ideas] `numbers.Natural`

Ian Cordasco graffatcolmingov at gmail.com
Fri Sep 26 22:27:03 CEST 2014


On Fri, Sep 26, 2014 at 3:06 PM, Ram Rachum <ram at rachum.com> wrote:
> Hmm, I don't know, but I like it better. I probably had a reason and forgot
> it. Sorry :(
>
>
> On Fri, Sep 26, 2014 at 11:03 PM, David Mertz <mertz at gnosis.cx> wrote:
>>
>> Isn't the right answer to create an isNatural() function? Why do we need a
>> type or class rather than just a function? It's not any easier to write
>> 'isinstance(x, Natural)' than it is to write 'isNatural(x)'.
>>
>> On Fri, Sep 26, 2014 at 11:47 AM, Andrew Barnert
>> <abarnert at yahoo.com.dmarc.invalid> wrote:
>>>
>>> On Sep 26, 2014, at 11:37, Ram Rachum <ram at rachum.com> wrote:
>>>
>>> I checked it and you're right. So I guess `Hashable` is a bit confusing:
>>>
>>>     >>> isinstance(([3],), collections.Hashable)
>>>     True
>>>
>>>
>>> It makes sense if you think of isinstance as a type check, which is what
>>> it's supposed to be, rather than a value check. ([3],) is a tuple, and
>>> tuples are hashable as a type, even though some specific tuple values might
>>> not be.
>>>
>>> That's exactly why I think you want a type that you can check for
>>> Natural, rather than something about the value. That's what isinstance is
>>> for, and if you start subverting it to mean other things, that's when it
>>> leads to confusion.
>>>
>>>
>>> On Fri, Sep 26, 2014 at 9:35 PM, Andrew Barnert <abarnert at yahoo.com>
>>> wrote:
>>>>
>>>> On Sep 26, 2014, at 11:13, Ram Rachum <ram at rachum.com> wrote:
>>>>
>>>> I agree with both the points you raised, they're both disadvantages. The
>>>> question is whether the uses would be worth these two disadvantages.
>>>> (`collections.Hashable` also has the second disadvantage you mentioned, and
>>>> it's still in the stdlib, so there's hope.)
>>>>
>>>>
>>>> Hashable doesn't have that disadvantage. It checks whether the object's
>>>> class or any superclass has a __hash__ method. So it's still based on the
>>>> type, not on the value, and it works as expected with issubclass.
>>>>
>>>>
>>>> On Fri, Sep 26, 2014 at 9:10 PM, Thomas Gläßle <t_glaessle at gmx.de>
>>>> wrote:
>>>>>
>>>>> At first glance it sounds nice and straight forward.
>>>>> But - is a natural positive, or just non-negative? I guess, I'd have to
>>>>> look it up in the docs each time, since either definition is used in lots of
>>>>> places.
>>>>> Also, Natural does not correspond to the python type, but its value.
>>>>> So, you couldn't use it with issubclass.
>>>>>
>>>>>
>>>>> Ram Rachum wrote on 09/26/2014 07:54 PM:
>>>>>
>>>>> I wish the `numbers` module would include a `Natural` class that would
>>>>> simply check whether the number is integral and positive.


The only motivations I can think of for making this a type (not that
they're good ones) is you could do something like:

if isinstance(x, (Natural, Complex, Real)):
   #
elif isinstance(x, Rational):
   #
else:
   raise ValueError

Which is naturally (no pun intended) slightly nicer than

if isinstance(x, (Complex, Real)) or isNatural(x):
    #

But really, I agree with David that *if* this were added to the
stdlib, it should be as a function. I'm however, unconvinced about the
usefulness of having this as a stdlib function (since it should be
easy for anyone to define):

def isNatural(x):
    if not isinstance(x, int):
        return False
    return x > 0

But here we could argue over whether 0 is Natural or not. Further,
this could be rewritten as a one-liner:

def isNatural(x):
    return isinstance(x, int) and x > 0

Which falls under the adage I've oft heard repeated here "Not every
one-liner belongs in the standard library"


More information about the Python-ideas mailing list