Scoped change of a global variable

[Luigi Ballabio]

Greetings,

At 12:27 PM 1/2/02 +0100, Alex Martelli wrote:
>In Python, like in every other language, you'll generally get better
>mileage if you use the language as it was designed to be used, rather
>than throwing your energies at mimicking the way some OTHER language
>was designed to be used.

Absolutely. Hence my question, namely, "How does one do this in Python", 
"this" being the abstraction of storing, changing and restoring a global 
variable, not the particular way it is done in other language. The snippets 
in other languages were not meant as models but rather as clarification of 
what I meant by "abstracting": the global variable change in one point, the 
wrapped code in another. Then again, I probably expressed myself poorly. I 
should know better than sending mails before my second coffee :)

> > P.S. the name of the game here is encapsulating the
> > store-set-calculate-restore logic; it is not to show me that there are
> > better ways to implement the above than to access a global variable. I
> > know. The above is just a contrived 10 lines example to show my point.
>
>...and that point IS...?

Ouch, my fault again. I keep hoping that a problem can be shown in a few 
lines of code out of context, not to bore people with details. Seems like I 
managed to mislead you instead.

The context is: I'm trying to implement the OMG specification for 
Currencies. The particular issue is: a class Money is defined which 
contains an amount of money and the currency in which the amount is 
expressed. If two Money instances are added which have the same currency, 
the result is a Money instance whose currency is the same and whose amount 
is the sum of the amounts of the addends. If the two instances have 
different currencies, a global variable determines whether 1) an error is 
raised, 2) the result is converted in the currency of the first operand, or 
3) the result is converted in a base currency which is stored in another 
global variable.

>The 'set' part is best seen as a function
>return in Python, rather than binding some arbitrary name (forcing
>it to be global [to what module?!])

To the current scope. The idea was:

#!/usr/bin/python

# Some code here which initializes the script,
# defines variables, whatever.

# Let's say that I have read a list of Money instances
# which represent payments. Now I want to add them all.

# here is the store-and-set thing
oldBaseCurrency = Currency.BaseCurrency
Currency.BaseCurrency = EUR

# Here are the calculations, during which Money.__add__ uses
# Currency.BaseCurrency to determine what to do.
# They could be a single function call such as:

sum = reduce(lambda x,y: x+y, paymentList)

# or a few lines of code with control structures inside such as:

sum = Money()
for payment in paymentList:
     sum += payment           # Money.__iadd__ uses Currency.BaseCurrency

# here is the restore thing
Currency.BaseCurrency = oldBaseCurrency

# more code here

However, I see that encapsulating in _one_ point the store-change-restore 
logic might be impossible here...

>the natural unit for passing code as arguments in Python is
>the function.  You just put the assignment _outside_ changingGlobals,
>as shown above.  Have all functions communicate through the arguments
>they receive and the results they return: this is by far the most
>Pythonic arrangement of things.

Point taken.

Thanks for the help,
                         Luigi