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

[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 " 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

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

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

[Greg Ewing]

On Mon, Feb 19, 2018 at 5:58 AM, Sylvain MARIE 
> 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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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.stephen...@u.tsukuba.ac.jp] 
Envoyé : mardi 20 février 2018 06:53
À : gu...@python.org
Cc : Sylvain MARIE <sylvain.ma...@schneider-electric.com>; Python-Ideas 
<python-ideas@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.
__
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

Looking at https://en.wikipedia.org/wiki/Number it seems that Integer is
"special" -- every other number type is listed as " 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.stephen...@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".
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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".

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

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

[Nick Coghlan]

On 20 February 2018 at 08:33, Guido van Rossum  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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Mon, Feb 19, 2018 at 5:58 AM, Sylvain MARIE <
sylvain.ma...@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.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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.


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

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

[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.bar...@noaa.gov] 
Envoyé : vendredi 16 février 2018 22:42
À : gu...@python.org
Cc : Sylvain MARIE <sylvain.ma...@schneider-electric.com>; Python-Ideas 
<python-ideas@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.
__
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 <
sylvain.ma...@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:gvanros...@gmail.com]
> *Envoyé :* mercredi 14 février 2018 17:14
> *À :* Sylvain MARIE <sylvain.ma...@schneider-electric.com>
> *Cc :* Python-Ideas <python-ideas@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-
> electric@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-ideas@python.org>
> *Objet :* Re: [Python-ideas] Boolean ABC similar to what's provided in
> the 'numbers' module
>
>
>
>
>
>
>
> 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:
>
>
>
> ""&q

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

[Guido van Rossum]

On Wed, Feb 14, 2018 at 5:49 PM, Chris Barker - NOAA Federal <
chris.bar...@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.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 <
sylvain.ma...@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 :* gvanros...@gmail.com [mailto:gvanros...@gmail.com] *De la part de*
> Guido van Rossum
> *Envoyé :* mercredi 14 février 2018 19:47
> *À :* Sylvain MARIE <sylvain.ma...@schneider-electric.com>
>
> *Cc :* python-ideas <python-ideas@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-
> electric@python.org] *De la part de* David Mertz
> *Envoyé :* mardi 13 février 2018 07:08
> *À :* Nick Coghlan <ncogh...@gmail.com>
> *Cc :* python-ideas <python-ideas@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_).
>
>
>
> 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])
>
>
>
>
>
>
>
> On Mon, Feb 12, 2018 at 7:50 PM, Nick Coghlan <ncogh

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

[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 : gvanros...@gmail.com [mailto:gvanros...@gmail.com] De la part de Guido van 
Rossum
Envoyé : mercredi 14 février 2018 19:47
À : Sylvain MARIE <sylvain.ma...@schneider-electric.com>
Cc : python-ideas <python-ideas@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.ma...@schneider-electric.com<mailto:sylvain.ma...@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<mailto:python-ideas-bounces%2Bsylvain.marie>=schneider-electric@python.org<mailto:schneider-electric@python.org>]
 De la part de David Mertz
Envoyé : mardi 13 février 2018 07:08
À : Nick Coghlan <ncogh...@gmail.com<mailto:ncogh...@gmail.com>>
Cc : python-ideas <python-ideas@python.org<mailto:python-ideas@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_).

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])



On Mon, Feb 12, 2018 at 7:50 PM, Nick Coghlan 
<ncogh...@gmail.com<mailto:ncogh...@gmail.com>> wrote:
On 13 February 2018 at 02:14, David Mertz 
<me...@gnosis.cx<mailto: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__" ("ca

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

[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 <
sylvain.ma...@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-
> electric@python.org] *De la part de* David Mertz
> *Envoyé :* mardi 13 février 2018 07:08
> *À :* Nick Coghlan <ncogh...@gmail.com>
> *Cc :* python-ideas <python-ideas@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_).
>
>
>
> 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])
>
>
>
>
>
>
>
> On Mon, Feb 12, 2018 at 7:50 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>
> 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

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

[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-electric@python.org] 
De la part de David Mertz
Envoyé : mardi 13 février 2018 07:08
À : Nick Coghlan <ncogh...@gmail.com>
Cc : python-ideas <python-ideas@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_).

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])



On Mon, Feb 12, 2018 at 7:50 PM, Nick Coghlan 
<ncogh...@gmail.com<mailto:ncogh...@gmail.com>> wrote:
On 13 February 2018 at 02:14, David Mertz 
<me...@gnosis.cx<mailto: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   |   ncogh...@gmail.com<mailto:ncogh...@gmail.com>   |   
Brisbane, Australia



--
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.

__
This email has been scanned by the Symantec Email Security.cloud service.
__
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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" <
sylvain.ma...@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-
electric@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-ideas@python.org>
*Objet :* Re: [Python-ideas] Boolean ABC similar to what's provided in the
'numbers' module







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(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov


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

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

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

[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-electric@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-ideas@python.org>
Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 
'numbers' module



On Mon, Feb 12, 2018 at 10:07 PM, David Mertz 
<me...@gnosis.cx<mailto: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(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov<mailto:chris.bar...@noaa.gov>

__
This email has been scanned by the Symantec Email Security.cloud service.
__
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Barker]

On Mon, Feb 12, 2018 at 10:07 PM, David Mertz  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(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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])




On Mon, Feb 12, 2018 at 7:50 PM, Nick Coghlan  wrote:

> On 13 February 2018 at 02:14, David Mertz  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   |   ncogh...@gmail.com   |   Brisbane, Australia
>



-- 
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.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nick Coghlan]

On 13 February 2018 at 02:14, David Mertz  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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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!

On Feb 12, 2018 5:51 AM, "Steven D'Aprano"  wrote:

On Mon, Feb 12, 2018 at 09:41:04AM +, 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-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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?

On Mon, Feb 12, 2018 at 1:41 AM, Sylvain MARIE <
sylvain.ma...@schneider-electric.com> 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.
>
>
>
> 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
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

On Mon, Feb 12, 2018 at 09:41:04AM +, 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-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[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

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