Laura Creighton writes:
> [W]hat I expect the type annotations to be used for, especially in
> the SciPy world, is to make things easier for Numba to generate
> fast code.
I don't understand why that's a problem. *You* run mypy, and *you*
decide whether to do anything about its warnings. The
> Yes, but what I expect the type annotations to be used for, especially
> in the SciPy world, is to make things easier for Numba to generate fast
> code.
Well, probably not.
There are two reasons to have type declarations: performance and type safety.
But the current type annotations are design
In a message of Wed, 14 Oct 2015 23:49:33 +0100, Oscar Benjamin writes:
>I'm sure the bokeh developers will be aware of the different ways that
>their library is used (at this level). If the input spec is "sequence of
>coercible to float" then I agree that they should use type annotations to
>match
On 14 Oct 2015 23:06, "Laura Creighton" wrote:
>
> In a message of Wed, 14 Oct 2015 21:21:30 -, Oscar Benjamin writes:
> >Generally if it's possible to interchange floats and decimals in your
code
> >then there's probably no need for decimals in the first place.
>
> Yes, but, at least around h
I forgot something.
In a message of Wed, 14 Oct 2015 21:21:30 -, Oscar Benjamin writes:
>The point of static type checking is to detect precisely these kinds of
>errors.
Yes, but what I expect the type annotations to be used for, especially
in the SciPy world, is to make things easier for N
On Wed, Oct 14, 2015 at 3:04 PM, Laura Creighton wrote:
> That code writers in the scientific python world mostly
> never think of Decimal users, doesn't mean they don't end up writing
> perfectly wonderful tools and libraries we use. :) thankfully :)
>
sure -- but those are almost guaranteed
In a message of Wed, 14 Oct 2015 21:21:30 -, Oscar Benjamin writes:
>Generally if it's possible to interchange floats and decimals in your code
>then there's probably no need for decimals in the first place.
Yes, but, at least around here the common case is that you already
_have_ a pile of
On Wed, 14 Oct 2015 21:57 Laura Creighton wrote:
In a message of Wed, 14 Oct 2015 08:38:43 -0700, Guido van Rossum writes:
>Perhaps you could solve this with type variables. Here's a little
>demonstration program:
>```
>from decimal import Decimal
>from typing import TypeVar
>F = TypeVar('F', flo
In a message of Wed, 14 Oct 2015 08:38:43 -0700, Guido van Rossum writes:
>Perhaps you could solve this with type variables. Here's a little
>demonstration program:
>```
>from decimal import Decimal
>from typing import TypeVar
>F = TypeVar('F', float, Decimal)
>def add(a: F, b: F) -> F:
>return
>> Well, that's what you get in exchange for "type safety".
>
> AIUI, the point of type annotations is that some use cases benefit *a
> lot* from machine-parsable type information, not that type annotation
> is a universally good idea in itself. It's not type *safety* that's
> the aim here. It's
Perhaps you could solve this with type variables. Here's a little
demonstration program:
```
from decimal import Decimal
from typing import TypeVar
F = TypeVar('F', float, Decimal)
def add(a: F, b: F) -> F:
return a+b
print(add(4.2, 3.14))
print(add(Decimal('4.2'), Decimal('3.14')))
print(add(D
And these days
> anybody who is using Decimal for Money (which ought to be everybody,
I'm not so sure about that -- using base-10 is nice, but it doesn't
automatically buy you the appropriate rounding rules, etc that you
need to "proper" accounting.
And, as MA pointed out, in much "finance" work,
In a message of Wed, 14 Oct 2015 11:44:40 +0200, "M.-A. Lemburg" writes:
>I can only underline this. Conversion to decimals or fractions should
>not be implicit. People needing these types will know when they need
>them and apply the required explicit conversions to fit their use case.
>
>E.g. in
On 14.10.2015 01:37, Raymond Hettinger wrote:
>
>> On Oct 13, 2015, at 9:16 AM, Random832 wrote:
>>
>>> ##
>>> ## Decimal has all of the methods specified by the Real abc, but it should
>>> ## not be registered as a Real because decimals do not interoperate with
>>> ## binary flo
Chris Barker - NOAA Federal writes:
> Laura Creighton writes:
> > I merely worry about what happens if people
> > start relying upon the fact that a float annotation 'will handle all
> > the numbers I care about' to the forgotten Decimal users such as
> > myself.
>
> Well, that's what you
I merely worry about what happens if people
> start relying upon the fact that a float annotation 'will handle all
> the numbers I care about' to the forgotten Decimal users such as
> myself.
Well, that's what you get in exchange for "type safety".
Which is exactly why I'm concerned about widesp
Steven D'Aprano writes:
> On Tue, Oct 13, 2015 at 04:37:43PM -0700, Raymond Hettinger wrote:
>
>> We could have (and still could) make the choice to always coerce to
>> decimal (every float is exactly representable in decimal). Further,
>> any decimal float or binary float could be losslessly
On Tue, Oct 13, 2015 at 04:37:43PM -0700, Raymond Hettinger wrote:
> We could have (and still could) make the choice to always coerce to
> decimal (every float is exactly representable in decimal). Further,
> any decimal float or binary float could be losslessly coerced to a
> Fraction, but th
> On Oct 13, 2015, at 9:16 AM, Random832 wrote:
>
>> ##
>> ## Decimal has all of the methods specified by the Real abc, but it should
>> ## not be registered as a Real because decimals do not interoperate with
>> ## binary floats (i.e. Decimal('3.14') + 2.71828 is undefined).
On 13.10.2015 17:38, Raymond Hettinger wrote:
Traceback (most recent call last):
File "", line 1, in
Decimal('3.14') + 2.71828
TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'
Reminds me of 'int' and 'long'. Different but almost the same.
Best,
Sven
In a message of Tue, 13 Oct 2015 08:38:07 -0700, Raymond Hettinger writes:
>
>
>> On Oct 13, 2015, at 4:21 AM, Laura Creighton wrote:
>>
>> Any chance of adding Decimal to the list of things that are also
>> acceptable for things annotated float?
>
>>From Lib/numbers.py:
>
>## Notes on Decimal
>#
> From Lib/numbers.py:
>
> ## Notes on Decimal
> ##
> ## Decimal has all of the methods specified by the Real abc, but it should
> ## not be registered as a Real because decimals do not interoperate with
> ## binary floats (i.e. Decimal('3.14') + 2.71828 is undefined). But,
> ##
> On Oct 13, 2015, at 4:21 AM, Laura Creighton wrote:
>
> Any chance of adding Decimal to the list of things that are also
> acceptable for things annotated float?
>From Lib/numbers.py:
## Notes on Decimal
##
## Decimal has all of the methods specified by the Real abc, but it
23 matches
Mail list logo
