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.


De : gvanros...@gmail.com [mailto:gvanros...@gmail.com] De la part de Guido van 
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 
_.py:10: error: Argument 2 to "f" has incompatible type "int"; expected 

On Tue, Feb 13, 2018 at 1:21 AM, Sylvain MARIE 
The main use case I had in mind was PEP484-based type hinting/checking actually:

def my_function(foo: Boolean):

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.


De : Python-ideas 
 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__" ("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__).


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
Code of Conduct: http://python.org/psf/codeofconduct/

--Guido van Rossum (python.org/~guido<http://python.org/~guido>)

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

Reply via email to