how to overload sqrt in a module?

[Michael McNeil Forbes]

I would like to write a module that provides some mathematical functions
on top of those defined in math, cmath etc. but I would like to make it
work with "any" type that overloads the math functions.

Thus, I would like to write:

module_f.py
----
def f(x):
""" Compute sqrt of x """
return sqrt(x)

from math import *
import module_f
module_f.f(3) Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "module_f.p y", line 2, in f
return sqrt(x)
NameError: global name 'sqrt' is not defined

I understand why sqrt is not in scope, but my question is: what is the
best way to do this?

Here is one fairly ugly solution:

module_g.py
-----------
def g(x,math):
return math.sqrt(x)
import math, cmath, module_g
module_g.g(2,ma th) 1.4142135623730 951 module_g.g(-2,cmath)

1.4142135623730 951j

I am sure there is a better way of doing this that makes use of the
type of the argument (Dynamical scoping would solve the
problem but we don't want to go there...). Note that the following
function would work fine

def f(x):
return abs(x)

because of the special member __abs__ attached to the type. There is no
corresponding member for sqrt, sin etc.

What is the "proper" pythonic way to do this?

Michael.

[Michael McNeil Forbes]

On Fri, 3 Mar 2006, david mugnai wrote:

[snip]

If I don't misunderstood the problem, you can define an "init" method for
your module_g

(code not tested)

module_g.py
-----------

_functions = {}
def init(mathmodule ):
_function['sqrt'] = getattr(mathmod ule, 'sqrt', None)

def _get(name):
try:
return _functions[name]
except KeyError:
raise TypeError("you have to initialize module_g")

def sqrt(x):
return _get('sqrt')(x)

main.py
-------

import math
import module_g

module_g.init(m ath)
print module_g.sqrt(2 )

Thanks, this gets me close. Is there anything really bad about the
following? It works exactly as I would like, but I don't want to get in
trouble down the road:

module_f
--------
import math as my_math

def set_math(custom _math):
globals()['my_math'] = custom_math

def f(x):
return my_math.sqrt(x)

import module_f
module_f.f(2) 1.4142135623730 951 import cmath
module_f.set_ma th(cmath)
module_f.f(2j)

(1+1j)

Or, if one wants to use the "from __ import *" form:

from math import *

def set_math(custom _math):
globals().updat e(custom_math._ _dict__)

def f(x):
return sqrt(x)

Michael

[Michael McNeil Forbes]

On Fri, 3 Mar 2006, Steven D'Aprano wrote:

... you can do this:

import my_module
my_module.set_e nvironment("mat h") # or cmath, or numeric, or whatever

Your my_module will be like this:

# Warning: untested code.
ENVIRON = None # global variables sometimes have their uses

def f(x):
if ENVIRON is None:
raise ValueError("Uni nitialised module!")
# or use a custom exception
return ENVIRON.sqrt(x)

def set_environment (name):
global ENVIRON
ENVIRON = __import__(name )
Does this help?

Yes. However, this raises a question: Is this any different than
directly modifying the globals, or is it just syntactic sugar.

import math as my_math

def set_environment (name):
globals()['ENVIRON'] = __import__(name )

Thanks,
Michael.

[Kent Johnson]

Michael McNeil Forbes wrote:

Is there anything really bad about the
following? It works exactly as I would like, but I don't want to get in
trouble down the road:

module_f
--------
import math as my_math

def set_math(custom _math):
globals()['my_math'] = custom_math
This seems clearer to me:
def set_math(custom _math):
global my_math
my_math = custom_math
Or, if one wants to use the "from __ import *" form:

from math import *

def set_math(custom _math):
globals().updat e(custom_math._ _dict__)

This will cause interesting trouble if custom_math doesn't implement all
the functions you use from math.

Kent

[Steven D'Aprano]

On Sat, 04 Mar 2006 23:07:12 -0800, Michael McNeil Forbes wrote:

On Fri, 3 Mar 2006, Steven D'Aprano wrote:

... you can do this:

import my_module
my_module.set_e nvironment("mat h") # or cmath, or numeric, or whatever

Your my_module will be like this:

# Warning: untested code.
ENVIRON = None # global variables sometimes have their uses

def f(x):
if ENVIRON is None:
raise ValueError("Uni nitialised module!")
# or use a custom exception
return ENVIRON.sqrt(x)

def set_environment (name):
global ENVIRON
ENVIRON = __import__(name )
Does this help?
Yes. However, this raises a question: Is this any different than
directly modifying the globals, or is it just syntactic sugar.

The keyword "global" instructs Python to make all references to the
following name come from the global namespace. It is the correct way to
do it (but not necessarily the *only* correct way, or *always* the
correct way). In something as tiny as your example:
def set_environment (name):
globals()['ENVIRON'] = __import__(name )

it may not make any practical difference which method you use. But in
larger, more complex code, you are creating a rod for your own back. Try
running these three functions, and explain the difference in their
behaviour.

def f1():
global parrot
parrot = 3
parrot += 1
print "parrot is %d" % parrot

def f2():
globals()["parrot"] = 3
globals()["parrot"] += 1
print "parrot is %d" % parrot

def f3():
globals()["parrot"] = 3
parrot += 1
print "parrot is %d" % parrot
Directly modifying the globals is playing around with Python's internals.
You are allowed to do that, and sometimes it is the right thing to do,
otherwise Guido wouldn't have made globals() writable.

E.g. you have code where you want -- heaven knows why -- a name to refer
to both a local and a global variable. This will work:

def func():
x = 5 # x is local
globals()['x'] = 3 # but this x is global
I don't know whether writing to globals() is guaranteed to work for all
variants of Python (CPython, Jython, PyPy, IronPython ... ) or if it is
likely to change in Python 3. But even if modifying globals() is
officially allowed, it still has a whiff of the sort of code-smell that
Joel Spolsky talks about:

http://www.joelonsoftware.com/articles/Wrong.html

In my opinion, manipulating globals() is one of those things that ring
warning bells in my head. It might not be *wrong*, exactly, but I'll want
to pay extra attention to any function that does that.
--
Steven.