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

Wed Feb 14 13:47:21 EST 2018

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 at 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.com at python.org] *De la part de* David Mertz
> *Envoyé :* mardi 13 février 2018 07:08
> *À :* Nick Coghlan <ncoghlan at gmail.com>
> *Cc :* python-ideas <python-ideas at 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 <ncoghlan at gmail.com> wrote:
>
> On 13 February 2018 at 02:14, David Mertz <mertz at 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   |   ncoghlan at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180214/f57191bd/attachment.html>