PEP 0484 - the Numeric Tower
Any chance of adding Decimal to the list of things that are also acceptable for things annotated float? Laura
On Oct 13, 2015, at 4:21 AM, Laura Creighton <lac@openend.se> 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 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, ## abstract reals are expected to interoperate (i.e. R1 + R2 should be ## expected to work if R1 and R2 are both Reals). That is still true: Python 3.5.0 (v3.5.0:374f501f4567, Sep 12 2015, 11:00:19) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "copyright", "credits" or "license()" for more information.
from decimal import Decimal Decimal('3.14') + 2.71828 Traceback (most recent call last): File "<pyshell#1>", line 1, in <module> Decimal('3.14') + 2.71828 TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'
Raymond Hettinger
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, ## abstract reals are expected to interoperate (i.e. R1 + R2 should be ## expected to work if R1 and R2 are both Reals).
Why?
On Oct 13, 2015, at 9:16 AM, Random832 <random832@fastmail.com> 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). But, ## abstract reals are expected to interoperate (i.e. R1 + R2 should be ## expected to work if R1 and R2 are both Reals).
Why?
Q. Why is Python the way it is? A. Because Guido said so ;-) IIRC, the answer is that we were being conservative with possibly unintended operations between types with differing precision and with differing notions of what numbers could be exactly representable. 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 that probably isn't what you really want most of the time. I think people who work in decimal usually want to stay there and people who work with binary floating point want to stay there as well (invisible coercions being more likely to cause pain than relieve pain). Raymond
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 that probably isn't what you really want most of the time. I think people who work in decimal usually want to stay there and people who work with binary floating point want to stay there as well (invisible coercions being more likely to cause pain than relieve pain).
Further to what Raymond says, if anyone wants to persue this further, and wants to argue for such automatic promotion of float to Decimal (or vice versa), I think a good place to start would be a survey of other languages with a numeric tower. How do they handle similar situations? -- Steve
Steven D'Aprano <steve@pearwood.info> 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 coerced to a Fraction, but that probably isn't what you really want most of the time. I think people who work in decimal usually want to stay there and people who work with binary floating point want to stay there as well (invisible coercions being more likely to cause pain than relieve pain).
Further to what Raymond says, if anyone wants to persue this further, and wants to argue for such automatic promotion of float to Decimal (or vice versa), I think a good place to start would be a survey of other languages with a numeric tower. How do they handle similar situations?
I believe that in Scheme (which AIUI is where the term "numeric tower" comes from) has a notion of "exact" and "inexact" numbers. A "flonum" (float) would be an inexact number. And any operation between exact and inexact numbers (including e.g. min and max, even if the exact number wins) gives an inexact result. A Decimal, though, could be regarded as an exact number (a special kind of rational) or an inexact number (another kind of floating point). I suspect some people who use them intend them one way and others intend the other (especially since Fraction lacks a good way to format the value in decimal notation). If they are both inexact, then it doesn't much matter which one they're promoted to, since they're both implementation details of the abstract type "inexact real number". AIUI many implementations don't *actually* have any other implementations of "inexact real number" except flonum, and those that do just have them as a rational fraction with an "inexact" flag set, but the spec does allow it. Implementing a scheme-style exact/inexact numeric tower also suggests more ABCs.
On 14.10.2015 01:37, Raymond Hettinger wrote:
On Oct 13, 2015, at 9:16 AM, Random832 <random832@fastmail.com> 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). But, ## abstract reals are expected to interoperate (i.e. R1 + R2 should be ## expected to work if R1 and R2 are both Reals).
Why?
Q. Why is Python the way it is? A. Because Guido said so ;-)
IIRC, the answer is that we were being conservative with possibly unintended operations between types with differing precision and with differing notions of what numbers could be exactly representable.
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 that probably isn't what you really want most of the time. I think people who work in decimal usually want to stay there and people who work with binary floating point want to stay there as well (invisible coercions being more likely to cause pain than relieve pain).
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 accounting you'll likely use decimal, in finance and science you stick to floats.
From a theoretical point of view, it would make sense to add coercion to these types, but not from a practical point of view.
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
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 accounting you'll likely use decimal, in finance and science you stick to floats.
From a theoretical point of view, it would make sense to add coercion to these types, but not from a practical point of view.
-- Marc-Andre Lemburg eGenix.com
Actually, people in Finance tend to use both. (Often while being completely unaware of what they are doing, too.) And these days anybody who is using Decimal for Money (which ought to be everybody, but again, lots of people don't know what they are doing) still wants to grab the SciPy stack so they can use pandas to analyse the data, and matplotlib to graph it, and bokeh to turn the results into a all-singing and dancing interactive graph. Laura
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, the approximations of FP are just as appropriate as they are for science. (Which of course, floats are not always appropriate for...)
still wants to grab the SciPy stack so they can use pandas to analyse the data, and matplotlib to graph it, and bokeh to turn the results into a all-singing and dancing interactive graph.
There's no technical reason Numpy couldn't have a decimal dtype -- someone "just" has to write the code. The fact that no one has tells me that no one needs it that badly. (Or that numpy' dtype system is inscrutable :-) ) But while we're on Numpy -- there is s lesson there -- Numpy supports many different precision a of various styles - int8, int16, int32....float32, float64.... Back in the day, the coercion rules would tend to push user's arrays to larger dtypes: say you added a python float (float64) to a Numpy array of float32: you'd get a float64 array. But the fact is that people choose to use a smaller dtype for a reason -- so numpy's casting rules where changed to make it less likely that you'd accidentally upcast your arrays. A similar principle applies here. If someone is working with Decimals, they have a reason to do so. Likewise if they are Not working with Decimals... So it's all good... -CHB
Laura _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
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(Decimal('4.2'), 3.14)) ``` Note that the last line is invalid. mypy correctly finds this: ``` flt.py:8: error: Type argument 1 of "add" has incompatible value "object" ``` (We could work on the error message.) Now, I'm not sure that this is the best solution given the audience -- but the type variable 'F' only needs to be defined once, so this might actually work. -- --Guido van Rossum (python.org/~guido)
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 a+b print(add(4.2, 3.14)) print(add(Decimal('4.2'), Decimal('3.14'))) print(add(Decimal('4.2'), 3.14)) ``` Note that the last line is invalid. mypy correctly finds this: ``` flt.py:8: error: Type argument 1 of "add" has incompatible value "object" ``` (We could work on the error message.)
Now, I'm not sure that this is the best solution given the audience -- but the type variable 'F' only needs to be defined once, so this might actually work.
-- --Guido van Rossum (python.org/~guido)
This looks good to me. I wonder if there is anything we can do, documentation and PEP wise to encourage people who write code to use it, rather than just using float? Laura
On Wed, 14 Oct 2015 21:57 Laura Creighton <lac@openend.se> 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', 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(Decimal('4.2'), 3.14)) ``` Note that the last line is invalid. mypy correctly finds this: ``` flt.py:8: error: Type argument 1 of "add" has incompatible value "object" ``` (We could work on the error message.)
Now, I'm not sure that this is the best solution given the audience -- but the type variable 'F' only needs to be defined once, so this might actually work.
-- --Guido van Rossum (python.org/~guido)
This looks good to me. I wonder if there is anything we can do, documentation and PEP wise to encourage people who write code to use it, rather than just using float? It's not always appropriate though. If the author types it as float then they're obviously not thinking about decimal in which case it may not work correctly for decimal. Writing accurate numerical code that ducktypes with float and decimal is non-trivial even in cases where the operation is relatively trivial. Personally I just wouldn't mix them but if you want to see how tricky it can be take a look at statistics.sum. 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. If mypy requires you to do an explicit conversion to float then there may be some seld-documenting merit in showing that conversion up front rather than assuming that it's okay to insert decimals where they're not expected. The point of static type checking is to detect precisely these kinds of errors. -- Oscar
In a message of Wed, 14 Oct 2015 21:21:30 -0000, 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 decimals (extracted from your leger) and now you want to do something with them (like graph them and make reports out of the graphs) with other people's graphing and report generating software.
If mypy requires you to do an explicit conversion to float then there may be some seld-documenting merit in showing that conversion up front rather than assuming that it's okay to insert decimals where they're not expected. The point of static type checking is to detect precisely these kinds of errors.
The thing is that there is a very big split between code written as 'this is a float using function and decimal users very much have to avoid using it' and 'this thing works perfectly well for floats and decimals'. 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 :) I was looking for a way for the Python type hinting to be expressive enough to handle this common (at least in my world) case. So then, even if the bokeh developers (just to pick some friends) forget about me in their type annotations, I can just make a pull request, send it back with some corrected annotations and the note 'remember me!' :)
Oscar
Laura
On Wed, Oct 14, 2015 at 3:04 PM, Laura Creighton <lac@openend.se> 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 to convert to float internally, as there is no decimal dtype for numpy. in fact, much numpy code is actually semi-statically typed. The common idiom is to write your functions to take "something that can be turned into a float array", which, in practice, means that calling: np.asarray(the_input_object, dtype-np.float64) Doesn't raise an exception.[1] And, often ends up returning an array with the right shape, also, so maybe: np.asarray(the_input_object, dtype-np.float64).reshape(-1, 2) I guess it would be nice if there were a way to describe that in type annotations. -CHB [1] for those not in the know, "asarray" is more or less: if the input is already an array as specified, return that array unchanged. elif the input is a buffer or memoryview that fits the specification, wrap an ndarray around that buffer. else call np.array() on it -- which will attempt make an appropriate numpy array, and copy the values from the input object into it. I was looking for a way for the Python type hinting to be expressive
enough to handle this common (at least in my world) case. So then, even if the bokeh developers (just to pick some friends) forget about me in their type annotations,
as you see above, it's generally more complicated than a single scalar dtype... -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 14 Oct 2015 23:06, "Laura Creighton" <lac@openend.se> wrote:
In a message of Wed, 14 Oct 2015 21:21:30 -0000, 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 decimals (extracted from your leger) and now you want to do something with them (like graph them and make reports out of the graphs) with other people's graphing and report generating software.
The graphing library will almost certainly convert your data to float so I'd say this comes under the category of: you don't need decimals here.
If mypy requires you to do an explicit conversion to float then there may be some seld-documenting merit in showing that conversion up front rather than assuming that it's okay to insert decimals where they're not expected. The point of static type checking is to detect precisely these kinds of errors.
The thing is that there is a very big split between code written as 'this is a float using function and decimal users very much have to avoid using it' and 'this thing works perfectly well for floats and decimals'. 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 :)
I was looking for a way for the Python type hinting to be expressive enough to handle this common (at least in my world) case. So then, even if the bokeh developers (just to pick some friends) forget about me in their type annotations, I can just make a pull request, send it back with some corrected annotations and the note 'remember me!' :)
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 that rather than putting float and I imagine they would welcome your PR. Guido's suggestion is not general enough for that though: what about Fraction, mpf, gmpy, numpy, sympy, h5py etc? The ABCs in the numeric tower are unused by 3rd party types making them useless for abstract type inference (IMO). AFAIK the lowest common denominator among number types in Python is the __float__ special method. Does mypy have a way to require (a sequence of) that? -- Oscar
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 that rather than putting float and I imagine they would welcome your PR.
Guido's suggestion is not general enough for that though: what about Fraction, mpf, gmpy, numpy, sympy, h5py etc? The ABCs in the numeric tower are unused by 3rd party types making them useless for abstract type inference (IMO). AFAIK the lowest common denominator among number types in Python is the __float__ special method. Does mypy have a way to require (a sequence of) that?
Thank you Oscar, and Chris Barker, and Guido for improving my thoughts on this matter. I go to bed now, pondering the idea that for me, internally, a new way to do type annotation 'to-x-or-is-coercible-to-x' seems a decent-enough idea. Seems a betrayal of earlier principles. Perhaps when I wake up I will feel differently. Off to dream about 'the meaning of type annotation' then. :) Thank you. Laura
I forgot something. In a message of Wed, 14 Oct 2015 21:21:30 -0000, 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 Numba to generate fast code. I really hope that the SciPy world is not going to go nuts for useless annotations, but I have, alas, all too many years dealing with people whose desire to have faster code vastly outstrips their ability to understand just what is possible in that regard. In James Barrie's novel, Peter Pan, earthly children are given the ability to fly by having Fairy Dust (supplied by the unwilling Tinkerbell) sprinkled over them. I now know that what a large number of people who want faster code, really want is magic Fairy Dust. They wanted psyco to be it, they wanted pypy to be it, and now they want Numba to be it. The notion that sprinkling type annotations all over their code will make it fly _absolutely deeply resonates_ with how these people wish the world worked. They will believe that type annotations are magic fairy dust until they are forced to confront the fact poorly written code can not be made fly until it is rewritten. Laura
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 designed only for the latter. A number of us brought this up in the discussion because we do, in fact, want the magic fairy dust of faster code, whether by numba or Cython(my favorite) and I had hoped that type annotations would be useful for that. But it was explicitly stated that that was not the intent. And indeed, if you want to preserve any of python's nifty dynamic typing ( and we all do ) it can't support truly static typing. I.e. In Python, you want to say that your function works with, say, a sequence of numbers. But for performant compilation, you'd need to know the binary layout of that sequence. Side notes: Numba does JIT compilation, so pre specifying the types isn't needed anyway. Certainly adding these type annotations will buy you nothing. Bokeh, on the other hand, has to pass everything off to the browser anyway, presumably with JSON, so in theory it shouldn't need Numpy arrays anyway. (Of course, JSON doesn't support Decimal anyway -- or, strictly speaking, only supports decimal, but JavaScript conveys it to floats...)
I really hope that the SciPy world is not going to go nuts for useless annotations, but I have, alas, all too many years dealing with people whose desire to have faster code vastly outstrips their ability to understand just what is possible in that regard.
In James Barrie's novel, Peter Pan, earthly children are given the ability to fly by having Fairy Dust (supplied by the unwilling Tinkerbell) sprinkled over them. I now know that what a large number of people who want faster code, really want is magic Fairy Dust. They wanted psyco to be it, they wanted pypy to be it, and now they want Numba to be it. The notion that sprinkling type annotations all over their code will make it fly _absolutely deeply resonates_ with how these people wish the world worked. They will believe that type annotations are magic fairy dust until they are forced to confront the fact poorly written code can not be made fly until it is rewritten.
Laura
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
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 application you want to run is still a Python program, as are the modules it imports, and the Python compiler still simply attaches the annotations to the functions and otherwise ignores them, as does the VM. So, running the type checker is optional, just like running a profiler or pylint. How does the availability of profiling tools and linters hurt you? If they don't hurt, why would an optional analysis tool that happens to check types be a problem? It seems to me it wouldn't, but maybe I'm missing something? Unless you expect the Numba people themselves to require annotations before you can use Numba at all. In any case, that's not a problem created by PEP 484. Annotations have been available since 2006, decorator-based type-checkers since around 2003, and LBYL type- checking at runtime since the beginning of time. If Numba was going to require type annotations, they could have devised an annotation syntax themselves and done it long ago. Why would they, or any other project, change to a LBYL approach now? I would expect that Bokeh would be much less likely than Numba to do that, for example.
I now know that what a large number of people who want faster code, really want is magic Fairy Dust.
And a pony. And they think Santa Claus will deliver on Christmas. But I don't understand why that interferes with what you want to do. OK, if you think annotations are ugly and don't want to see them ever, fine, that I can understand (though I don't sympathize, at least not yet -- we'll see how badly they get abused in libraries I use). But how do they actually cause a problem when you're just running your code? I must be missing something .... Steve
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 <lac@openend.se> 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 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, ## abstract reals are expected to interoperate (i.e. R1 + R2 should be ## expected to work if R1 and R2 are both Reals).
That is still true:
Python 3.5.0 (v3.5.0:374f501f4567, Sep 12 2015, 11:00:19) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "copyright", "credits" or "license()" for more information.
from decimal import Decimal Decimal('3.14') + 2.71828 Traceback (most recent call last): File "<pyshell#1>", line 1, in <module> Decimal('3.14') + 2.71828 TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'
Raymond Hettinger
I take it that is a 'no'. I merely worry about what hapens 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. Laura
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 widespread use of type annotations. Might as well use a static language :-( - CHB
Laura _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
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 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 type *auditability*. If it were about "safety", annotations would be in the interpreter, not in a separate, optional application.
Which is exactly why I'm concerned about widespread use of type annotations. Might as well use a static language :-(
No, no way would this satisfy static typing advocates. Optional, remember? In Python, widespread use of type annotations that messes up Decimal users would be un-Pythonic (infringes the "consenting adults" principle). Yes, Laura is going to run into modules that functions that have a "float" or "Real" annotation that will complain about Decimal when Decimal works perfectly well in that function. Not everybody will use annotations according to BDFL Original Intent. But if perfectly normal usage of Decimal or whatever runs into type annotation abuse, and you can't simply refuse to run the type checker, I will bet that Guido himself will be your champion.[1] Footnotes: [1] I'm not channeling anybody here, that's a statement of my personal assessment of the real risk. And of course it may have no effect on the developers who use type annotations in that way, but this is no different from any other hard to work around programming practice.
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 type *auditability*. If it were about "safety", annotations would be in the interpreter, not in a separate, optional application.
Well, what's the point if you don't use it? I'm probably being paranoid here, but I can envision institutions that enforce running the type checker for any committed code, etc... And then for practical purposes, it's enforced on that project.
Which is exactly why I'm concerned about widespread use of type annotations. Might as well use a static language :-(
No, no way would this satisfy static typing advocates. Optional, remember?
Notice that I said "widespread" -- and again, paranoia: it'll always be optional in Python itself, but it may not be optional in some institutions/code bases.
In Python, widespread use of type annotations that messes up Decimal users would be un-Pythonic
Well yes, that's my point :-)
you can't simply refuse to run the type checker,
If you can simply refuse to run the type checker, then it makes me wonder what the point of the type checker is :-) Anyway, lots of folks think type annotations will be useful without constraining the language -- and now we have a standard way to do it -- so I guess we'll see how it plays out. -CHB
I will bet that Guido himself will be your champion.[1]
Footnotes: [1] I'm not channeling anybody here, that's a statement of my personal assessment of the real risk. And of course it may have no effect on the developers who use type annotations in that way, but this is no different from any other hard to work around programming practice.
On 13.10.2015 17:38, Raymond Hettinger wrote:
Traceback (most recent call last): File "<pyshell#1>", line 1, in <module> 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
participants (11)
-
Chris Barker -
Chris Barker - NOAA Federal
-
Guido van Rossum -
Laura Creighton -
M.-A. Lemburg -
Oscar Benjamin -
Random832 -
Raymond Hettinger -
Stephen J. Turnbull -
Steven D'Aprano -
Sven R. Kunze