[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