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