Driver selection

[Stuart D. Gathman]

The pyspf package [http://cheeseshop.python.org/pypi/pyspf/] can use
either pydns, or dnspython. The pyspf module has a simple driver
function, DNSLookup(), that defaults to the pydns version. It can be
assigned to a dnspython version, or to a test driver for in memory DNS.
Or you can modify the source to "from drivermodule import DNSLookup".

What is the friendliest way to make this configurable? Currently, users
are modifying the source to supply the desired driver. Yuck. I would
like to supply several drivers, and have a simple way to select one at
installation or run time.

--
Stuart D. Gathman <st****@bmsi.co m>
Business Management Systems Inc. Phone: [phone] Fax: [phone]
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

[Gabriel Genellina]

On 9 dic, 00:53, "Stuart D. Gathman" <[e-mail] mwrote:

The pyspf package [http://cheeseshop.python.org/pypi/pyspf/] can use
either pydns, or dnspython. The pyspf module has a simple driver
function, DNSLookup(), that defaults to the pydns version. It can be
assigned to a dnspython version, or to a test driver for in memory DNS.
Or you can modify the source to "from drivermodule import DNSLookup".

What is the friendliest way to make this configurable? Currently, users
are modifying the source to supply the desired driver. Yuck. I would
like to supply several drivers, and have a simple way to select one at
installation or run time.

You can store the user's choice in a configuration file (like the ones
supported by ConfigParser).
Then you can put all the logic to select and import the right function
in a separate module, and export the DNSLookup name; make all the other
parts of the application say "from mymodule import DNSLookup"

--
Gabriel Genellina

[Stuart D. Gathman]

On Fri, 08 Dec 2006 21:35:41 -0800, Gabriel Genellina wrote:

On 9 dic, 00:53, "Stuart D. Gathman" <[e-mail] mwrote:

>Or you can modify the source to "from drivermodule import DNSLookup".

What is the friendliest way to make this configurable? Currently, users
are modifying the source to supply the desired driver. Yuck. I would
like to supply several drivers, and have a simple way to select one at
installation or run time.

You can store the user's choice in a configuration file (like the ones
supported by ConfigParser).
Then you can put all the logic to select and import the right function
in a separate module, and export the DNSLookup name; make all the other
parts of the application say "from mymodule import DNSLookup"

pyspf is a library, not an application. It would be nasty to make it have
a config file. We already have "from pydns_driver import DNSLookup" in
the pyspf module. If only users could import *for* a module from
*outside* the module. I suppose you can do something like this:

app.py:

import spf
# select dnspython driver for spf module
from spf.dnspython_d river import DNSLookup
spf.DNSLookup = DNSLookup
del DNSLookup

....

That is ugly. I'm looking for better ideas. Is there a clean way to make
a setdriver function? Used like this, say:

app.py:

import spf
spf.set_driver( 'dnspython')
....

Can a function replace itself? For instance, in spf.py, could DNSLookup
do this to provide a default:

def set_driver(d):
if d == 'pydns':
from pydns_driver import DNSLookup
elif d == 'dnspython':
from dnspython_drive r import DNSLookup
else: raise Exception('Unkn own DNS driver')

def DNSLookup(name, t):
from pydns_driver import DNSLookup
return DNSLookup(name, t)

--
Stuart D. Gathman <st****@bmsi.co m>
Business Management Systems Inc. Phone: [phone] Fax: [phone]
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

[Gabriel Genellina]

At Saturday 9/12/2006 13:15, Stuart D. Gathman wrote:

>app.py:

import spf
spf.set_driver ('dnspython')
...

Can a function replace itself? For instance, in spf.py, could DNSLookup
do this to provide a default:

def set_driver(d):
if d == 'pydns':
from pydns_driver import DNSLookup
elif d == 'dnspython':
from dnspython_drive r import DNSLookup
else: raise Exception('Unkn own DNS driver')

def DNSLookup(name, t):
from pydns_driver import DNSLookup
return DNSLookup(name, t)

The above code *almost* works, but DNSLookup is a local name inside
the function. Use the global statement.
As an example, see how getpass.py (in the standard library) manages
the various getpass implementations .
--
Gabriel Genellina
Softlab SRL

_______________ _______________ _______________ _____
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

[Stuart D. Gathman]

On Mon, 11 Dec 2006 20:59:27 -0300, Gabriel Genellina wrote:

The above code *almost* works, but DNSLookup is a local name inside
the function. Use the global statement.
As an example, see how getpass.py (in the standard library) manages
the various getpass implementations .

Ok, I have a working package:

spf/
__init__.py
pyspf.py
pydns.py
dnspython.py

__init__.py:
from pyspf import *
from pyspf import __author__,__em ail__,__version __

def set_dns_driver( f):
global DNSLookup
DNSLookup = f
pyspf.DNSLookup = f

def DNSLookup(name, qtype,strict=Tr ue):
import pydns
return DNSLookup(name, qtype,strict)

set_dns_driver( DNSLookup)

Importing a driver module activates that driver.
For instance, in pydns.py:

import DNS # http://pydns.sourceforge.net
import spf

....
def DNSLookup(...):
...

spf.set_dns_dri ver(DNSLookup)

NOW, this is all very nice and modular. BUT, the original module was a
single file, which could be run as a script as well as imported as a
module. The script features provided useful command line functionality.
(Using if __name__ == '__main__':). Now that 'spf' is a package, the
command line feature is gone! Even using -m, I get:

python2.4 -m spf
python2.4: module spf has no associated file

Looking at getpass.py as advised, I see they put all the drivers in the
module. I could do that with spf.py, I suppose. But I like how with the
package, the driver code is not loaded unless needed.

One other idea I had was an arrangement like this:

SPF/
pydns.py
dnspython.py

spf.py

This would keep the module as a single file usable from the command line,
but still make driver available as separately loaded modules.

So which of the three options,

1) single file module with all drivers, ala getpass
2) package that cannot be run directly from command line
3) single file module with associated driver package

is the most pythonic?
--
Stuart D. Gathman <st****@bmsi.co m>
Business Management Systems Inc. Phone: [phone] Fax: [phone]
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

[Gabriel Genellina]

On 16 dic, 12:28, "Stuart D. Gathman" <[e-mail] mwrote:

NOW, this is all very nice and modular. BUT, the original module was a
single file, which could be run as a script as well as imported as a
module. The script features provided useful command line functionality.
(Using if __name__ == '__main__':). Now that 'spf' is a package, the
command line feature is gone! Even using -m, I get:

Yes, a little sacrifice...

Looking at getpass.py as advised, I see they put all the drivers in the
module. I could do that with spf.py, I suppose. But I like how with the
package, the driver code is not loaded unless needed.

That's good.

One other idea I had was an arrangement like this:

SPF/
pydns.py
dnspython.py

spf.py

This would keep the module as a single file usable from the command line,
but still make driver available as separately loaded modules.

So which of the three options,

1) single file module with all drivers, ala getpass

You've already seen that it's not a good option. getpass is different
in the sense that only one version should be available in a given
system, so it keeps trying alternatives until a candidate is found.

2) package that cannot be run directly from command line
3) single file module with associated driver package

I think that keeping demo/application code separate from the library
would be a good thing.
So, keep your library inside a package, and provide some external
scripts as example, demo, whatever.
You can instruct distutils to install each thing in the right place.

--
Gabriel Genellina