[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Fri, Feb 28, 2014 at 6:34 PM, Steven D'Aprano <steve at pearwood.info> wrote: > On Fri, 28 Feb 2014 16:00:10 +1100, Chris Angelico wrote: > >> If we had some other tag, like 'd', we could actually construct a >> Decimal straight from the source code. Since source code is a string, >> it'll be constructed from that string, and it'll never go via float. > > Now that Python has a fast C implementation of Decimal, I would be happy > for Python 4000 to default to decimal floats, and require special syntax > for binary floats. Say, 0.1b if you want a binary float, and 0.1 for a > decimal. Maybe, but I believe the cdecimal module is still slower than typical floating point. There'd also be considerations regarding NumPy and how you'd go about working with an array of non-integer values, and so on. Certainly this will be an extremely reasonable topic of discussion once there's any notion of a Py4K on the cards. There'll be arguments on both sides. > But for now, backwards-compatibility requires that the default floating > point type remains binary float. But we could maybe agitate for a 1.234d > Decimal literal type. Care to write a PEP? > > :-) Heh. Strong consideration here: it would mean importing the decimal module on startup. >>> t=time.time(); import decimal; time.time()-t 4.5000159740448 >>> t=time.time(); import decimal; time.time()-t 0.0 A dummy import (when it's already loaded) is so fast that it's immeasurable, but four and a half seconds to load up decimal? This is 3.4.0b2 on Windows, btw. It was a lot quicker on my Linux box, probably because the OS or disk cache had the file. So maybe it wouldn't be too bad in practice; but it's still a cost to consider. >> The question is how far Python wants to bless the Decimal type with >> syntax - after all, if Decimal can get a literal notation, why can't >> Fraction, and why can't all sorts of other types? And that's a huge can >> of worms. > > I like Fractions, but I don't think they're important enough for the > average users to require literal notation. Yeah, but where do you draw the line? Either decimal.Decimal becomes a built-in type, or there needs to be a system for constructing literals of non-built-in types. And if Decimal becomes built-in, then why that and not <<insert type name here>>? Also, if Decimal becomes a built-in type, does that affect the numeric tower? ChrisA

- Prev by Date:
**Can global variable be passed into Python function?** - Next by Date:
**extend methods of decimal module** - Previous by thread:
**extend methods of decimal module** - Next by thread:
**extend methods of decimal module** - Index(es):