Comments in-line (I wish Outlook would behave sensibly) -----Original Message----- From: Paul Moore <[email protected]> Sent: 05 March 2020 09:52 To: Steve Barnes <[email protected]> Cc: [email protected] Subject: Re: [Python-ideas] IDEA: Allow override of all assignments of a built in type to be a different type
On Thu, 5 Mar 2020 at 09:28, Steve Barnes <[email protected]> wrote: > Wouldn’t it be possible to have something along the lines of: > > ``` > from decimal import TreatFloatsAsDecimal @TreatFloatsAsDecimal a = 0.1 > # These are all now decimals b = 0.2 c = 0.3 > > a + b == c # This now works > ``` I'm not at all clear how you imagine this would work. How would the scope of that TreatFloatsAsDecimal "decorator" be determined? How would the Decimal constructor get access to the original string representation of 0.1, rather than the float value? [Steve Barnes] To my mind a decorator would have function scope and there might be a file scope "magic". The interpreter would have to handle passing the raw value, (always a string at that stage), to the constructor rather than to the float constructor. > I do know that this goes against the explicit is better than implicit so an > alternative might be to have a flexible base modifier, something like: > > ``` > from decimal import DecimalBase as D > > a = 0D0.1 # These are all now decimals b = 0D0.2 c = 0D0.3 > > a + b == c # This now works > ``` You can already do ``` from decimal import Decimal as D a = D("0.1") # These are all now decimals b = D("0.2") c = D("0.3") a + b == c # This now works ``` so the main differences are (1) a few keystrokes, and (2) a conceptual model closer to what you intend ("these are decimal numbers" rather than "these are strings that we parse to get decimals"). I mention (2) because it's often ignored, and yet it's probably the most important reason people keep coming back to this. [Steve Barnes] (2) is an important point and as you say the all too often forgotten - I don't mind a few keystrokes but the fact that Decimal(0.2) != Decimal("0.2") is the source of more than a few bugs I am sure. But user-defined literals have been discussed many times in the past, and never really got anywhere as an idea. I don't have links right now, but a search for the mailing list archives should turn up some. You should probably research those and explain how your proposal here addresses the objections that have been raised previously. Personally, I have a vague attachment to the idea in theory, but in practice I don't think I'd ever use it (at least not for the use cases you mention, and I can't think of any others that I would use it for) so it would be a non-trivial increase in the complexity of the language for little obvious benefit. The other thing that often acts as a good argument for a proposal is to point out some reasonably substantial bodies of existing, real-world, code that would be improved by the proposal. This is again where this idea often falls down - I don't actually know of any substantial code base that even uses Decimal or Fraction types, much less uses literals sufficiently frequently that a dedicated syntax would help. (I'm not saying that Decimal and/or Fraction are useless - I use them myself, but mostly in the REPL, or in adhoc code experiments, not in actual applications). [Steve Barnes] To an extent the lack of substantial code bases that make use of decimal could well be at least partly because of these issues. There is probably a lot of code out there with either bugs or awkward work arounds that could be addressed by such a feature, just about any financial calculations for example - I have seen quite a lot of such code that works in pennies or cents and then scales the results for example. Paul _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/EWAFOZOC6S3Z5D5N467ATKXTG55LRPUR/ Code of Conduct: http://python.org/psf/codeofconduct/
