[Michael] > This was a proposal for a mechanism for mingling types safely. It > was not intended as a definition of how decimal numbers should be > implemented. My implementation tests the interaction of the current > number types with the decimal type and I only completed enought of > the decimal type implementation to support this testing. I was not > expecting to discuss how decimal types should work. That has been > discussed already. I was primarily interested in testing the effects > of adding a new number type as I described in the PEP. Can you summarize the rules you used for mixed arithmetic? I forget what your PEP said would happen when you add a decimal 1 to a binary 1. Is the result decimal 2 or binary 2? Why? > What did you think of the idea of adding a new command and file format? I don't think that would be necessary. I'd prefer the 'd' and 'f' (or maybe 'b'?) suffixes to be explicit, perhaps combined with an optional per-module directive to set the default. This would be more robust than keying on the filename extension. If you have to change the default globally, I'd prefer a command line option. After all it's only the scanner that needs to know about the different defaults, right? I wonder about the effectiveness of the default though. If you write a module for decimal arithmetic, how do you prevent a caller to pass in a binary number? > > Are you aware that Aahz is implementing "the real" spec for > > Python, a level up at > > > > http://www2.hursley.ibm.com/decimal/ > > > > under "Base specification"? There are so few people working on > > the decimal idea that I hate to see it fragmented already. > > Yes I have played with the Decimal.py module. I developed > decimalobject.c so I could test the inpact of introducing an > additional command and file format to Python. I expect this code to > be replaced. As I said in the PEP I also think the decimal number > implementation will evolve into a type that supports inheritance. Please, please, please, unify all these efforts. A decimal PEP would be a good one, but there should be only one. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4