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