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

## Advertising

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