My point is just that today, I use the ‘numbers’ package classes (Integral,
Real, …) for PEP484 type-hinting, and I find it quite useful in term of input
type validation (in combination with PEP484-compliant type checkers, whether
static or dynamic). Adding a Boolean ABC with a similar behavior
Can you show some sample code that you have written that shows where this
would be useful?
Note that using the numbers package actually makes static type checking
through e.g. mypy difficult. So I presume you are talking about dynamic
checking?
--Guido
On Feb 14, 2018 12:42 AM, "Sylvain MARIE"
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 h
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 incompati
Folks-
The ipaddress library returns an IP address object which can represent
itself in a number of ways:
In [1]: import ipaddress
In [2]: v4 = ipaddress.IPv4Address('1.2.3.4')
In [3]: print(v4)
1.2.3.4
In [4]: v4
Out[4]: IPv4Address('1.2.3.4')
In [6]: v4.packed
Out[6]: b'\x01\x02\x03\x04'
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, pyty
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 eve
This idea is inspired by Eric Osborne's post "Extending __format__
method in ipaddress", but I wanted to avoid derailing that thread.
I notice what seems to be an inconsistency in the ipaddress objects:
py> v4 = ipaddress.IPv4Address('1.2.3.4')
py> bin(v4)
Traceback (most recent call last):
Fi
On Thu, Feb 15, 2018 at 11:18 AM, Steven D'Aprano wrote:
> This idea is inspired by Eric Osborne's post "Extending __format__
> method in ipaddress", but I wanted to avoid derailing that thread.
>
> I notice what seems to be an inconsistency in the ipaddress objects:
>
> py> v4 = ipaddress.IPv4Add
>
> 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.
mypy isn’t an “official” tool, but PEP484 is — and mypy is more or
less a reference implimentation, yes?
mypy s
On 02/14/2018 02:29 PM, Eric Osborne wrote:
Nick Coghlan suggested I instead extend __format__, which is what the diffs in
the current pull request do. This
allows a great deal more flexibility: the current code takes 'b', 'n', or 'x'
types, as well as the '#' option and
support for the '_' s
On 15 February 2018 at 10:18, Steven D'Aprano wrote:
> This idea is inspired by Eric Osborne's post "Extending __format__
> method in ipaddress", but I wanted to avoid derailing that thread.
>
> I notice what seems to be an inconsistency in the ipaddress objects:
>
> py> v4 = ipaddress.IPv4Address
On 15 February 2018 at 08:29, Eric Osborne wrote:
> Nick Coghlan suggested I instead extend __format__, which is what the
> diffs in the current pull request do. This allows a great deal more
> flexibility: the current code takes 'b', 'n', or 'x' types, as well as the
> '#' option and support f
On Thu, Feb 15, 2018 at 11:45:46AM +1100, Chris Angelico wrote:
> Except that this computer's IPv4 is not 3232235539, and I never want
> to enter it that way. I enter it as 192.168.0.19 - as four separate
> integers.
That's partly convention (and a useful convention: it is less error-
prone than
On Thu, Feb 15, 2018 at 3:14 PM, Steven D'Aprano wrote:
> On Thu, Feb 15, 2018 at 11:45:46AM +1100, Chris Angelico wrote:
>
>> Except that this computer's IPv4 is not 3232235539, and I never want
>> to enter it that way. I enter it as 192.168.0.19 - as four separate
>> integers.
>
> That's partly
On Thu, 15 Feb 2018 15:14:03 +1100, Steven D'Aprano wrote:
> On Thu, Feb 15, 2018 at 11:45:46AM +1100, Chris Angelico wrote:
>
>> Except that this computer's IPv4 is not 3232235539, and I never want
>> to enter it that way. I enter it as 192.168.0.19 - as four separate
>> integers.
>
> That's pa
On Wed, Feb 14, 2018 at 5:49 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> >
> > 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.
>
> mypy isn’t an
On Thu, Feb 15, 2018 at 01:39:13PM +1000, Nick Coghlan wrote:
> There are tests that ensure IP addresses don't implement __index__,
> and the pragmatic reason for that is the downside you mentioned: to
> ensure they can't be used as indices, slice endpoints, or range
> endpoints.
If it is an inte
As far as I can see, a comprehension like
alist = [f(x) for x in range(10)]
is better than a for-loop
for x in range(10):
alist.append(f(x))
because the previous one shows every element of the list explicitly so that we
don't need to handle `append` mentally.
But when it comes to something like
19 matches
Mail list logo