To 'with' or not to 'with': how is the question ?

[Jason Cunliffe]

Alex

Thanks for presenting this simply and clearly.. :-)

> so use:
>
> for ns in [somenamespace]:
>     ns.something
>     ns.orother
>
> You get the abbreviation (to something readable such as ns, or to
> the quasi-transparent _ if you prefer) and the indentation.  It's
> not normally considered necessary to follow this with a
>     del ns
> to unbind the name, but you can do it if you want.

YES I think this is a very nice and readable solution.

If I understand correctly, one could then assign the 'ns' object any time
any way wone needed to.
For example a system or program logic detect method could determine whether
'ns' should be versionA, versionB, versionC.
This is just the kind of minmal Python factoring approach which could help a
lot of code be friendlier, especially where there are many modules or
versions to test/apply.
The method which sets the 'ns' could have say a  '.readme' property, which
could then be accessed from anywhere to explain what namespace was being
used and why. Thus:

for ns in [somenamespace]:
    ns.something
    ns.orother
    ns.readme

where the ns.readme might return

"""
last changed by GM & JC 29-Aug-2000
This version tests latest sort methods in new BDB binding from RD download
at http://www.rd.com/dolphins.bdb.sort/latest
"""

and include a nested line  like
    if ns == 'dolphins.bdb.sort.version4':
        print 'you should update dbd sort now'


To give a case in point.. We are using a SleepyCatSoftware's BerkeleyDB tool
and there is a Python interface module by RobinDunn. So far so great. But
BerekeleyDB existst in various versions, not all of which Robin's module
speaks to our has been throghoughly tested. Futhermore, between several
remote development and testsite machines: Win98se, WinNT, LinuxRedHat6.x,
Mandrake7.x it is never terribly obvious which version of what is installed.
And once it is intsalled you really want to forget about it and get on with
using higher level tools. We are currently using Zope and have made a simple
BSDObject product which allows us to use BerkeleyDB via Zope's Python
External methods. It is is lovely solution when everything is in place,
avoiding many of the heachaches of DTML, but to maintain can be fragile
becuase crucial low level components are hidden [as they should be] and dont
display or track usbcomepent revisions so well. Our Zope BSDObject product
includes the single line:

"from TCS.bsddb import db"  [the recommended method]


In such a situation, as as new versions become available we may need to
install test modules in parallel without deleting or having to rename
everything all the time. It is not too bad on one's own system, but across
systems it is a little messy - much manual renaming, making bakups,
deleting, copypaste etc. for non-developers to keep on top of..

To be able to keep all this in one place and have the dependant code adapt
quickly is real advantage. Experienced Python programmers must all have
their own strategies for handling this, but for beginners it is not so
evident how to do this well.

> > I think the heart of my question is how you direct python to say "use
> > this_namespace until further notice"?
> > ..Where this_namespace is started by 'with' and further notice is
demarked
> > by 'endwith'.
>
> Explicit is better than implicit.  Just as in an object's method I
> explicitly
> say self.foo to refer to its foo field (rather than use just foo, as in
many
> other OO languages, _implicitly_ using the object's namespace), so I
> do in other context -- supply and use an explicit name.

Do you consider 'for ns in [namespace]:' explicit enough ?

> > This begs the newbie question: "Hello python expert, what decides your
>
> I'm not a real expert, but...:
>
> > choice of when to use
> >  - from somewhere import something
>
> Rare, basically only when I want to make something look like a builtin
> function (e.g. because it overrides one).
>
> > - from somewhere import *
>
> Rare, only with those very rare modules explicitly designed and
> documented for that usage.
>
> > - import something
>
> The normal way to access a module.

Right. this gets to the other problem of namespace conflicts when importing
Modules the 'normal' way
You might easily have several modules which define an object namespace
called 'DateTime', or mouseX, mouseY.

How can you avoid conflict without ending up with very daft long unique
names for thing?.
It is not just a question of typing [explicit is better than implicit] it is
a matter of code reuse and clean factoring..
You might have a number of calendar modules which need to use differing
DateTime resources, or to compare them easily.
And you  don't want to uninstall exsiitng modules, just be able to switch to
them.

In such a situation one can write a top method called 'selectDateTime()' and
then all the rest of one's own code is free to remain clean.
What is not clear to me is how to get imported 3rd party modules and
packages to comply without making revisions. Perhaps through a general
'importManager.py' file which runs at startup, includes a single editable
dictionary list of modules, has methods one can call
from anywhere to reassign or test...

Any thought about this?
I fell I must be reinventing/invoking a long old Python thread under another
topicname!

cheers
- Jason