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

Wed Feb 14 18:34:51 EST 2018

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.marie at 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 :* gvanrossum at gmail.com [mailto:gvanrossum at gmail.com] *De la part de*
> Guido van Rossum
> *Envoyé :* mercredi 14 février 2018 19:47
> *À :* Sylvain MARIE <sylvain.marie at schneider-electric.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 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)
>
>
> ______________________________________________________________________
> 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/9df6a38b/attachment-0001.html>