prePEP: Decimal data type
Batista, Facundo
FBatista at uniFON.com.ar
Tue Nov 4 15:57:26 EST 2003
John Roth wrote:
#- I can see how what I said could be interpreted that way, but
#- I certainly
#- didn't mean it for strings.
If you understand one thing and I understand another, one of both of us is
wrong, :p. Who? In my last example, what do you think that happens?
#- It is. I was thinking in terms of a type, not a class. All
#- the builtin
#- types start with lower class names.
OK, so it stays uppercase (as long it's a class).
#- What you propose?
#-
#- - the configuration (precision, flags, etc) is on by-instance basis
#- - you have different contexts, and a group of instances with each
#- context.
#-
#- [John Roth]
#- More likely the second. My concern here is the usual one with
#- singletons and globals. Processing gets very messy when you
#- have to operate in several different modes or areas. See the
#- difficulties people get into with internationalization when they
#- have an application that has to operate in several different
#- jurisdictions at once, etc.
In another mail, Aahz explains (even to me) that the idea is to have a
"context per thread". So, all the instances of a thread belongs to a
context, and you can change a context in thread A (and the behaviour of the
instances of that thread) without changing nothing on the thread B.
So, I think your proposal has future, as long I could finish the Aahz work,
;)
#- So we're planning
#- on doing a software implementation of a *draft* standard,
#- including very complicated facilities that I most
#- respectfully think are going to be of marginal
#- utility.
But is that or is making a Money data type and reinventing the wheel for all
its arithmetic behaviour.
I can't assure you if somebody ever will use the "not a number" capabilities
of Decimal (I think a lot of people will). But that's the specification, :p
. Facundo
More information about the Python-list
mailing list