[Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Sylvain MARIE]

The numbers module provides very useful ABC for the ‘numeric tower’, able to abstract away the differences between python primitives and for example numpy primitives.

I could not find any equivalent for Booleans.

However numpy defines np.bool too, so being able to have an abstract Boolean class for both python bool and numpy bool would be great.

 

Here is a version that I included in valid8 in the meantime

 

-----------------------

class Boolean(metaclass=ABCMeta):

    """

    An abstract base class for booleans, similar to what is available in numbers

    see https://docs.python.org/3.5/library/numbers.html

    """

    __slots__ = ()

 

    @abstractmethod

    def __bool__(self):

        """Return a builtin bool instance. Called for bool(self)."""

 

    @abstractmethod

    def __and__(self, other):

        """self & other"""

 

    @abstractmethod

    def __rand__(self, other):

        """other & self"""

 

    @abstractmethod

    def __xor__(self, other):

        """self ^ other"""

 

    @abstractmethod

    def __rxor__(self, other):

        """other ^ self"""

 

    @abstractmethod

    def __or__(self, other):

        """self | other"""

 

    @abstractmethod

    def __ror__(self, other):

        """other | self"""

 

    @abstractmethod

    def __invert__(self):

        """~self"""

 

 

# register bool and numpy bool_ as virtual subclasses

# so that issubclass(bool, Boolean) = issubclass(np.bool_, Boolean) = True

Boolean.register(bool)

 

try:

    import numpy as np

    Boolean.register(np.bool_)

except ImportError:

    # silently escape

    pass

 

---------------------------

 

If that topic was already discussed and settled in the past, please ignore this thread – apologies for not being able to find it.

Best regards

 

Sylvain

 

[Steven D'Aprano]

On Mon, Feb 12, 2018 at 09:41:04AM +0000, Sylvain MARIE wrote:

> The numbers module provides very useful ABC for the 'numeric tower',
> able to abstract away the differences between python primitives and
> for example numpy primitives.
> I could not find any equivalent for Booleans.
> However numpy defines np.bool too, so being able to have an abstract
> Boolean class for both python bool and numpy bool would be great.

I don't know anything about numpy bools, but Python built-in bools are
numbers, and as such already have an ABC: they are a subclass of int.



--
Steve
_______________________________________________
Python-ideas mailing list
Python...@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Guido van Rossum]

TBH I've found the numeric tower a questionable addition to Python's stdlib. For PEP 484 we decided not to use it (using the concrete types, int, float etc. instead). So I'm not excited about adding more like this, especially since essentially *everything* can be used in a Boolean context.

If your specific project has a specific style requirement for Booleans that would be helped by a Boolean ABC, maybe you should add it to your project and see how it works out, and after a few months report back here.

Finally. How were you planning to use this new ABC?

_______________________________________________
Python-ideas mailing list
Python...@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

--

--Guido van Rossum (python.org/~guido)

[David Mertz]

NumPy np.bool_ is specifically not a subclass of any np.int_.  If it we're, there would be an ambiguity between indexing with a Boolean array and an array of ints. Both are meaningful, but they mean different things (mask vs collection of indices).

Do we have other examples a Python ABC that exists to accommodate something outside the standard library or builtins? Even if not, NumPy is special... the actual syntax for '@' exists primarily for that library!

[Nick Coghlan]

On 13 February 2018 at 02:14, David Mertz <me...@gnosis.cx> wrote:
> NumPy np.bool_ is specifically not a subclass of any np.int_. If it we're,
> there would be an ambiguity between indexing with a Boolean array and an
> array of ints. Both are meaningful, but they mean different things (mask vs
> collection of indices).
>
> Do we have other examples a Python ABC that exists to accommodate something
> outside the standard library or builtins? Even if not, NumPy is special...
> the actual syntax for '@' exists primarily for that library!

collections.abc.Sequence and collections.abc.Mapping come to mind -
the standard library doesn't tend to distinguish between different
kinds of subscriptable objects, but it's a distinction some third
party libraries and tools want to be able to make reliably.

The other comparison that comes to mind would be the distinction
between "__int__" ("can be coerced to an integer, but may lose
information in the process") and "__index__" ("can be losslessly
converted to and from a builtin integer").

Right now, we only define boolean coercion via "__bool__" - there's no
mechanism to say "this *is* a boolean value that can be losslessly
converted to and from the builtin boolean constants". That isn't a
distinction the standard library makes, but it sounds like it's one
that NumPy cares about (and NumPy was also the main driver for
introducing __index__).

Cheers,
Nick.

--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia

[David Mertz]

I'm not sure I'm convinced by Sylvain that Boolean needs to be an ABC in the standard library; Guido expresses skepticism.  Of course it is possible to define it in some other library that actually needs to use `isinstance(x, Boolean)` as Sylvain demonstraits in his post.  I'm not sure I'm unconvinced either, I can see a certain value to saying a given value is "fully round-trippable to bool" (as is np.bool_).

But just for anyone who doesn't know NumPy, here's a quick illustration of what I alluded to:

In [1]: import numpy as np

In [2]: arr = np.array([7,8,12,33])

In [3]: ndx1 = np.array([0,1,1,0], dtype=int)

In [4]: ndx2 = np.array([0,1,1,0], dtype=bool)

In [5]: arr[ndx1]

Out[5]: array([7, 8, 8, 7])

In [6]: arr[ndx2]

Out[6]: array([ 8, 12])

ndx1 and ndx2 are both nice things (and are both often programmatically constructed by operations in NumPy).  But indexing using ndx1 gives us an array of the things in the listed positions in arr.  In this case, we happen to choose two each of the things an index 0 and index 1 in the result.

Indexing by ndx2 gives us a filter of only those positions in arr corresponding to 'True's.  These are both nice things to be able to do, but if NumPy's True was a special kind of 1, it wouldn't work out unambiguously.  However, recent versions of NumPy have gotten a bit smarter about recognizing the special type of Python bools, so it's less of a trap than it used to be.  Still, contrast these (using actual Python lists for the indexes:

In [10]: arr[[False, True, True, False]]

Out[10]: array([ 8, 12])

In [11]: arr[[False, True, 1, 0]]

Out[11]: array([7, 8, 8, 7])

--

Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.

[Chris Barker]

On Mon, Feb 12, 2018 at 10:07 PM, David Mertz <me...@gnosis.cx> wrote:

I'm not sure I'm convinced by Sylvain that Boolean needs to be an ABC in the standard library; Guido expresses skepticism.  Of course it is possible to define it in some other library that actually needs to use `isinstance(x, Boolean)` as Sylvain demonstraits in his post.  I'm not sure I'm unconvinced either, I can see a certain value to saying a given value is "fully round-trippable to bool" (as is np.bool_).

But is an ABC the way to do it? Personally, I'm skeptical that ABCs are a solution to, well, anything (as apposed to duck typing and EAFTP). Take Nick's example:

"""

The other comparison that comes to mind would be the distinction
between "__int__" ("can be coerced to an integer, but may lose
information in the process") and "__index__" ("can be losslessly
converted to and from a builtin integer").

""" 

I suppose we could have had an Index ABC -- but that seems painful to me.

so maybe we could use a __true_bool__ special method? 

(and an operator.true_bool() function ???)

(this all makes me wish that python bools were more pure -- but way to late for that!)

I guess it comes down to whether you want to:

 - Ask the question: "is this object a boolean?"

or

 - Make this object a boolean

__index__ (and operator.index())  is essentially the later -- you want to make an index out of whatever object you have, if you can do so.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris....@noaa.gov

[Sylvain MARIE]

My point is just that today, I use the ‘numbers’ package classes (Integral, Real, …) for PEP484 type-hinting, and I find it quite useful in term of input type validation (in combination with PEP484-compliant type checkers, whether static or dynamic). Adding a Boolean ABC with a similar behavior would certainly add consistency to that ‘numbers’ package – only for users who already find it useful, of course.

 

Note that my use case is not about converting an object to a Boolean, I’m just speaking about type validation of a ‘true’ boolean object, for example to be received as a function argument for a flag option. This is for example for users who want to define strongly-typed APIs for interaction with the ‘outside world’, and keep using duck-typing for internals.

 

Sylvain

 

De : Python-ideas [mailto:python-ideas-bounces+sylvain.marie=schneider-e...@python.org] De la part de Chris Barker
Envoyé : mardi 13 février 2018 21:12
À : David Mertz <me...@gnosis.cx>
Cc : python-ideas <python...@python.org>
Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

[Guido van Rossum]

Can you show some sample code that you have written that shows where this would be useful?

Note that using the numbers package actually makes static type checking through e.g. mypy difficult. So I presume you are talking about dynamic checking?

--Guido

On Feb 14, 2018 12:42 AM, "Sylvain MARIE" <sylvai...@schneider-electric.com> wrote:

My point is just that today, I use the ‘numbers’ package classes (Integral, Real, …) for PEP484 type-hinting, and I find it quite useful in term of input type validation (in combination with PEP484-compliant type checkers, whether static or dynamic). Adding a Boolean ABC with a similar behavior would certainly add consistency to that ‘numbers’ package – only for users who already find it useful, of course.

 

Note that my use case is not about converting an object to a Boolean, I’m just speaking about type validation of a ‘true’ boolean object, for example to be received as a function argument for a flag option. This is for example for users who want to define strongly-typed APIs for interaction with the ‘outside world’, and keep using duck-typing for internals.

 

Sylvain

 

De : Python-ideas [mailto:python-ideas-bounces+sylvain.marie=schneider-electr...@python.org] De la part de Chris Barker

[Sylvain MARIE]

The main use case I had in mind was PEP484-based type hinting/checking actually:

 

def my_function(foo: Boolean):

    pass

 

explicitly states that my_function accepts any Boolean value, whether it is a python bool or a np.bool that would come from a numpy array or pandas dataframe.

Note that type hinting is also the use case for which I make extensive use of the types from the ‘numbers’ package, for the same reasons.

 

Sylvain

 

De : Python-ideas [mailto:python-ideas-bounces+sylvain.marie=schneider-e...@python.org] De la part de David Mertz
Envoyé : mardi 13 février 2018 07:08
À : Nick Coghlan <ncog...@gmail.com>

Cc : python-ideas <python...@python.org>
Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

 

I'm not sure I'm convinced by Sylvain that Boolean needs to be an ABC in the standard library; Guido expresses skepticism.  Of course it is possible to define it in some other library that actually needs to use `isinstance(x, Boolean)` as Sylvain demonstraits in his post.  I'm not sure I'm unconvinced either, I can see a certain value to saying a given value is "fully round-trippable to bool" (as is np.bool_).

[Guido van Rossum]

I am mystified how you can be using the numbers package with mypy. Example:

import numbers
def f(a: numbers.Integral, b: numbers.Integral) -> numbers.Integral:
  return a + b
f(12, 12)

This gives an two errors on the last line when checked by mypy:

_.py:10: error: Argument 1 to "f" has incompatible type "int"; expected "Integral"
_.py:10: error: Argument 2 to "f" has incompatible type "int"; expected "Integral"

On Tue, Feb 13, 2018 at 1:21 AM, Sylvain MARIE <sylvai...@schneider-electric.com> wrote:

The main use case I had in mind was PEP484-based type hinting/checking actually:

 

def my_function(foo: Boolean):

    pass

 

explicitly states that my_function accepts any Boolean value, whether it is a python bool or a np.bool that would come from a numpy array or pandas dataframe.

Note that type hinting is also the use case for which I make extensive use of the types from the ‘numbers’ package, for the same reasons.

 

Sylvain

 

De : Python-ideas [mailto:python-ideas-bounces+sylvain.marie=schneider-electr...@python.org] De la part de David Mertz

_______________________________________________
Python-ideas mailing list
Python...@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Sylvain MARIE]

I see :)

 

This does not seem to happen with PyCharm IDE + Anaconda distribution. Is PyCharm relying on MyPy under the hood ?

I actually have no knowledge at all about MyPy and how it relates to PyCharm static code analysis warnings. I’m pretty sure though that the runtime checkers (enforce, pytypes) are not dependent on MyPy.

 

Sylvain

 

De : gvanr...@gmail.com [mailto:gvanr...@gmail.com] De la part de Guido van Rossum
Envoyé : mercredi 14 février 2018 19:47
À : Sylvain MARIE <sylvai...@schneider-electric.com>

Cc : python-ideas <python...@python.org>
Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

 

I am mystified how you can be using the numbers package with mypy. Example:

import numbers
def f(a: numbers.Integral, b: numbers.Integral) -> numbers.Integral:
  return a + b
f(12, 12)

This gives an two errors on the last line when checked by mypy:

_.py:10: error: Argument 1 to "f" has incompatible type "int"; expected "Integral"
_.py:10: error: Argument 2 to "f" has incompatible type "int"; expected "Integral"

On Tue, Feb 13, 2018 at 1:21 AM, Sylvain MARIE <sylvai...@schneider-electric.com> wrote:

The main use case I had in mind was PEP484-based type hinting/checking actually:

 

def my_function(foo: Boolean):

    pass

 

explicitly states that my_function accepts any Boolean value, whether it is a python bool or a np.bool that would come from a numpy array or pandas dataframe.

Note that type hinting is also the use case for which I make extensive use of the types from the ‘numbers’ package, for the same reasons.

 

Sylvain

 

De : Python-ideas [mailto:python-ideas-bounces+sylvain.marie=schneider-e...@python.org] De la part de David Mertz

[Guido van Rossum]

No, PyCharm has its own annotation checker, which is much more lenient than mypy (and less compliant with PEP 484). And indeed the runtime checkers are also unrelated (though a runtime checker will have to work with the type objects created by typing.py).

So as long as you are not expecting to ever need mypy you should be fine -- however if you're sharing code at some point someone is probably going to want to point mypy at it.

On Wed, Feb 14, 2018 at 2:36 PM, Sylvain MARIE <sylvai...@schneider-electric.com> wrote:

I see :)

 

This does not seem to happen with PyCharm IDE + Anaconda distribution. Is PyCharm relying on MyPy under the hood ?

I actually have no knowledge at all about MyPy and how it relates to PyCharm static code analysis warnings. I’m pretty sure though that the runtime checkers (enforce, pytypes) are not dependent on MyPy.

 

Sylvain

 

De : gvanr...@gmail.com [mailto:gvanr...@gmail.com] De la part de Guido van Rossum

Envoyé : mercredi 14 février 2018 19:47

À : Sylvain MARIE <sylvain.marie@schneider-electric.com>

Cc : python-ideas <python...@python.org>
Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

 

I am mystified how you can be using the numbers package with mypy. Example:

import numbers
def f(a: numbers.Integral, b: numbers.Integral) -> numbers.Integral:
  return a + b
f(12, 12)

This gives an two errors on the last line when checked by mypy:

_.py:10: error: Argument 1 to "f" has incompatible type "int"; expected "Integral"
_.py:10: error: Argument 2 to "f" has incompatible type "int"; expected "Integral"

On Tue, Feb 13, 2018 at 1:21 AM, Sylvain MARIE <sylvain.marie@schneider-electric.com> wrote:

The main use case I had in mind was PEP484-based type hinting/checking actually:

 

def my_function(foo: Boolean):

    pass

 

explicitly states that my_function accepts any Boolean value, whether it is a python bool or a np.bool that would come from a numpy array or pandas dataframe.

Note that type hinting is also the use case for which I make extensive use of the types from the ‘numbers’ package, for the same reasons.

 

Sylvain

 

De : Python-ideas [mailto:python-ideas-bounces+sylvain.marie=schneider-electr...@python.org] De la part de David Mertz

[Chris Barker - NOAA Federal]

>
> So as long as you are not expecting to ever need mypy you should be fine -- however if you're sharing code at some point someone is probably going to want to point mypy at it.

mypy isn’t an “official” tool, but PEP484 is — and mypy is more or
less a reference implimentation, yes?

mypy support bool, as far as I can tell, will that not work for your case?

Even though the python bools are integer subclasses, that doesn’t mean
a type checker shouldn’t flag passing an integer in to a function that
expects a bool.

-CHB

[Guido van Rossum]

On Wed, Feb 14, 2018 at 5:49 PM, Chris Barker - NOAA Federal <chris....@noaa.gov> wrote:

>
> So as long as you are not expecting to ever need mypy you should be fine -- however if you're sharing code at some point someone is probably going to want to point mypy at it.

mypy isn’t an “official” tool, but PEP484 is — and mypy is more or
less a reference implimentation, yes?

Except PEP 484 is silent on many, many details. So far from all of mypy's behavior is normative.

However, in this case PEP 484 has an opinion on the numbers module (don't use it, just use int).

 

mypy support bool, as far as I can tell, will that not work for your case?

Even though the python bools are integer subclasses, that doesn’t mean
a type checker shouldn’t flag passing an integer in to a function that
expects a bool.

That's not the issue.

The issue is that, from mypy's POV, np.bool is not a subtype of builtins.bool, just like the various np.intXX types aren't subtypes of builtins.int. But IMO the solution is to lie about this in the stubs and make the np types subtypes of the builtin types, not to switch to numbers.Integral. And the reason is that few people (outside hardcore np fans) will want to write numbers.Integral instead of int.

[Sylvain MARIE]

Yes, this is used in combination  dynamic type checking, currently using enforce (https://github.com/RussBaz/enforce ) but I know that others exist (pytypes in particular)

 

As per examples…all utility functions that we write that are receiving a number or a boolean in their parameters are now written using the numbers and additional Boolean classes:

 

------------- example where Integral is used instead of int -----------------

 

from numbers import Integral

import pandas as pd

from enforce import runtime_validation, config
config(dict(mode='covariant'))  # type validation will accept subclasses too


@runtime_validation
def only_keep_events_lasting_at_least(boolean_series: pd.Series, min_nb_occurrences: Integral):
    """
    Filters boolean flags to keep 'true' only when it appears at least min_nb_occurrences times in a row

    :param boolean_series:
    :param min_nb_occurrences:
    :return:
    """

          (contents skipped for clarity)

 

-------------------------------------

 

Similarly when a bool type hint is in the signature we try to replace it with a Boolean, so that people can call it with a numpy bool. But maybe that’s too much of type checking for the python philosophy ? I’m wondering if we’re going too far here…

 

Anyway, again, my point is just about consistency: if this is available for numbers, why not for simple Booleans?

 

Sylvain

 

De : Guido van Rossum [mailto:gvanr...@gmail.com]
Envoyé : mercredi 14 février 2018 17:14
À : Sylvain MARIE <sylvai...@schneider-electric.com>
Cc : Python-Ideas <python...@python.org>

Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

 

Can you show some sample code that you have written that shows where this would be useful?

 

Note that using the numbers package actually makes static type checking through e.g. mypy difficult. So I presume you are talking about dynamic checking?

 

--Guido

 

On Feb 14, 2018 12:42 AM, "Sylvain MARIE" <sylvai...@schneider-electric.com> wrote:

My point is just that today, I use the ‘numbers’ package classes (Integral, Real, …) for PEP484 type-hinting, and I find it quite useful in term of input type validation (in combination with PEP484-compliant type checkers, whether static or dynamic). Adding a Boolean ABC with a similar behavior would certainly add consistency to that ‘numbers’ package – only for users who already find it useful, of course.

 

Note that my use case is not about converting an object to a Boolean, I’m just speaking about type validation of a ‘true’ boolean object, for example to be received as a function argument for a flag option. This is for example for users who want to define strongly-typed APIs for interaction with the ‘outside world’, and keep using duck-typing for internals.

 

Sylvain

 

De : Python-ideas [mailto:python-ideas-bounces+sylvain.marie=schneider-e...@python.org] De la part de Chris Barker

[Guido van Rossum]

A thought just occurred to me. Maybe we should just add a Boolean class to numbers? It's a subclass of Integral, presumably. And normally only builtins.bool is registered with it. But np.bool can be added at the same point you register the other np integral types.

On Wed, Feb 14, 2018 at 10:23 AM, Sylvain MARIE <sylvai...@schneider-electric.com> wrote:

Yes, this is used in combination  dynamic type checking, currently using enforce (https://github.com/RussBaz/enforce ) but I know that others exist (pytypes in particular)

 

As per examples…all utility functions that we write that are receiving a number or a boolean in their parameters are now written using the numbers and additional Boolean classes:

 

------------- example where Integral is used instead of int -----------------

 

from numbers import Integral

import pandas as pd

from enforce import runtime_validation, config
config(dict(mode='covariant'))  # type validation will accept subclasses too


@runtime_validation
def only_keep_events_lasting_at_least(boolean_series: pd.Series, min_nb_occurrences: Integral):
    """
    Filters boolean flags to keep 'true' only when it appears at least min_nb_occurrences times in a row

    :param boolean_series:
    :param min_nb_occurrences:
    :return:
    """

          (contents skipped for clarity)

 

-------------------------------------

 

Similarly when a bool type hint is in the signature we try to replace it with a Boolean, so that people can call it with a numpy bool. But maybe that’s too much of type checking for the python philosophy ? I’m wondering if we’re going too far here…

 

Anyway, again, my point is just about consistency: if this is available for numbers, why not for simple Booleans?

 

Sylvain

 

De : Guido van Rossum [mailto:gvanr...@gmail.com]

Envoyé : mercredi 14 février 2018 17:14

À : Sylvain MARIE <sylvain.marie@schneider-electric.com>
Cc : Python-Ideas <python...@python.org>

Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

Can you show some sample code that you have written that shows where this would be useful?

 

Note that using the numbers package actually makes static type checking through e.g. mypy difficult. So I presume you are talking about dynamic checking?

 

--Guido

 

On Feb 14, 2018 12:42 AM, "Sylvain MARIE" <sylvain.marie@schneider-electric.com> wrote:

My point is just that today, I use the ‘numbers’ package classes (Integral, Real, …) for PEP484 type-hinting, and I find it quite useful in term of input type validation (in combination with PEP484-compliant type checkers, whether static or dynamic). Adding a Boolean ABC with a similar behavior would certainly add consistency to that ‘numbers’ package – only for users who already find it useful, of course.

 

Note that my use case is not about converting an object to a Boolean, I’m just speaking about type validation of a ‘true’ boolean object, for example to be received as a function argument for a flag option. This is for example for users who want to define strongly-typed APIs for interaction with the ‘outside world’, and keep using duck-typing for internals.

 

Sylvain

 

De : Python-ideas [mailto:python-ideas-bounces+sylvain.marie=schneider-electr...@python.org] De la part de Chris Barker

[Chris Barker - NOAA Federal]

Sent from my iPhone

> A thought just occurred to me. Maybe we should just add a Boolean class to numbers?

This makes lots of sense to me.

Bool is a subclass of int — might as well embrace that fact.

-CHB

[Sylvain MARIE]

> A thought just occurred to me. Maybe we should just add a Boolean class to numbers?

That would be great indeed

> It's a subclass of Integral, presumably. And normally only builtins.bool is registered with it. But np.bool can be added at the same point you register the other np integral types.

I would rather suggest to keep that Boolean ABC class independent of Integral (see proposal in first post) to let it remain 'pure', i.e. represent logical booleans only. However nothing prevents us to register python bool as a virtual subclass of *both* Integral and Boolean - while np.bool would be registered as a virtual subclass of Boolean only. This would reflect quite well the reality - the fact that python bool is both a Boolean and an Integer, while numpy bool is only a Boolean.

By the way, is there a reason for the name "Integral" (algebraic theory) instead of "Integer" (computer science) ? Would it be practically feasible to add "Integer" as an alias to "Integral" in the numbers package ?

Sylvain

-----Message d'origine-----
De : Chris Barker - NOAA Federal [mailto:chris....@noaa.gov]
Envoyé : vendredi 16 février 2018 22:42
À : gu...@python.org
Cc : Sylvain MARIE <sylvai...@schneider-electric.com>; Python-Ideas <python...@python.org>

Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

Sent from my iPhone
> A thought just occurred to me. Maybe we should just add a Boolean class to numbers?

This makes lots of sense to me.

Bool is a subclass of int — might as well embrace that fact.

-CHB

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

[Serhiy Storchaka]

15.02.18 18:27, Guido van Rossum пише:

> A thought just occurred to me. Maybe we should just add a Boolean class
> to numbers? It's a subclass of Integral, presumably.

Isn't bool a subclass of int only for historical reasons? I think that
if bool was in Python from the beginning, it would not be an int subclass.

Operations inherited from int like division or bits shift doesn't make
sense as boolean operations. The only boolean operations are testing for
truthfulness, `not`, `and` and `or`. But every object in Python supports
them. The bool class is just a type of constants True and False.

[Guido van Rossum]

On Mon, Feb 19, 2018 at 5:58 AM, Sylvain MARIE <sylvai...@schneider-electric.com> wrote:

> A thought just occurred to me. Maybe we should just add a Boolean class to numbers?

That would be great indeed

> It's a subclass of Integral, presumably. And normally only builtins.bool is registered with it. But np.bool can be added at the same point you register the other np integral types.

I would rather suggest to keep that Boolean ABC class independent of Integral (see proposal in first post) to let it remain 'pure', i.e. represent logical booleans only. However nothing prevents us to register python bool as a virtual subclass of *both* Integral and Boolean - while np.bool would be registered as a virtual subclass of Boolean only. This would reflect quite well the reality - the fact that python bool is both a Boolean and an Integer, while numpy bool is only a Boolean.

OK, that could work. At this point I think you should just file an issue on bugs.python.org (but since Python 3.7 is in feature freeze, expect this to be put on the 3.8 track).

 

By the way, is there a reason for the name "Integral" (algebraic theory) instead of "Integer" (computer science) ? Would it be practically feasible to add "Integer" as an alias to "Integral" in the numbers package ?

Hm, perhaps Integral is an adjective, just like Boolean? Though it's also possible that it was simply a mistake. In general I don't like adding aliases for different spellings -- it violates TOOWTDI. If we decide that this really was a mistake we should go ahead and make Integer the recommended way and define Integral as an alias for backwards compatibility.

[Nick Coghlan]

On 20 February 2018 at 08:33, Guido van Rossum <gu...@python.org> wrote:
> Hm, perhaps Integral is an adjective, just like Boolean? Though it's also
> possible that it was simply a mistake. In general I don't like adding
> aliases for different spellings -- it violates TOOWTDI. If we decide that
> this really was a mistake we should go ahead and make Integer the
> recommended way and define Integral as an alias for backwards compatibility.

FWIW, I had to run `dir(numbers)` while tinkering at the REPL based on
this discussion, because I was surprised that "numbers.Integer" was
giving me an attribute error.

Checking PEP 3141 doesn't shed any light on the question either -
while that cites Scheme as the origin of the numeric tower structure,
the given reference at
https://groups.csail.mit.edu/mac/ftpdir/scheme-reports/r5rs-html/r5rs_8.html#SEC50
uses "integer" rather than "integral".

Cheers,
Nick.

--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia

[Stephen J. Turnbull]

Guido van Rossum writes:

> Hm, perhaps Integral is an adjective, just like Boolean?

I would guess so. This is the same idiom we use when we call
[1, 2, 3] a "truth-y".

[Guido van Rossum]

Looking at https://en.wikipedia.org/wiki/Number it seems that Integer is "special" -- every other number type is listed as "<adjective> numbers" (e.g. rational numbers, complex numbers) but integers are listed as "Integers". So let's just switch it to that, and keep Integral as an alias for backwards compatibility. I don't think it's a huge problem to fix this in 3.7b2, if someone wants to do the work.

On Mon, Feb 19, 2018 at 9:53 PM, Stephen J. Turnbull <turnbull....@u.tsukuba.ac.jp> wrote:

Guido van Rossum writes:

 > Hm, perhaps Integral is an adjective, just like Boolean?

I would guess so.  This is the same idiom we use when we call
[1, 2, 3] a "truth-y".

[Sylvain MARIE]

https://bugs.python.org/issue32886 created.
Don't hesitate to correct if anything is wrong in the text or associated tags

Sylvain

-----Message d'origine-----
De : Stephen J. Turnbull [mailto:turnbull....@u.tsukuba.ac.jp]
Envoyé : mardi 20 février 2018 06:53

À : gu...@python.org
Cc : Sylvain MARIE <sylvai...@schneider-electric.com>; Python-Ideas <python...@python.org>
Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

Guido van Rossum writes:

> Hm, perhaps Integral is an adjective, just like Boolean?

I would guess so. This is the same idiom we use when we call [1, 2, 3] a "truth-y".

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

[Greg Ewing]

> On Mon, Feb 19, 2018 at 5:58 AM, Sylvain MARIE
> <sylvai...@schneider-electric.com

> <mailto:sylvai...@schneider-electric.com>> wrote:
>
> By the way, is there a reason for the name "Integral" (algebraic
> theory) instead of "Integer" (computer science) ? Would it be
> practically feasible to add "Integer" as an alias to "Integral" in
> the numbers package ?

Possibly inspired by Haskell, which has Integral (a type class, sort of
like an abstract type) and also Integer and Int (which are concrete types).

--
Greg

[Terry Reedy]

On 2/20/2018 12:06 PM, Guido van Rossum wrote:
> Looking at https://en.wikipedia.org/wiki/Number it seems that Integer is
> "special" -- every other number type is listed as "<adjective> numbers"
> (e.g. rational numbers, complex numbers) but integers are listed as
> "Integers". So let's just switch it to that, and keep Integral as an
> alias for backwards compatibility. I don't think it's a huge problem to
> fix this in 3.7b2, if someone wants to do the work.

https://bugs.python.org/issue32891

--
Terry Jan Reedy