in statement and namespace type ideas

Roman Suzi rnd at
Sat Jun 16 17:34:32 EDT 2001

On Sat, 16 Jun 2001, Bjorn Pettersen wrote:

>> From: Roman Suzi [mailto:rnd at]
>> Hello,
>> right now namespace handling in Python uses dicts,
>> however, docs say it could change.
>> I can't be sure that my code which uses globals() to merge,
>> for example,
>> cgi-form variables with globals namespace will work with future Python
>I think this is a Perl'ism which we shouldn't repeat here (it only works
>if the cgi vars are valid Python vars, otherwise it will blow up rather

I do not want it to be automatic. I just want to avoid things like this:

add_here(globals(), ["action", "name",...])

because it repeats too often in cgi scripts.

(I simplified my example. In reality I have defaults parameters
and sanitize function hooks).

The other aplication is storing or communicating names
(by pickling or other means). Again,

name = p['name']
action = p['action']


name =
action = p.action

look ugly, add noise.

Just imaging if one needed these to import names from
the module instead of just

from module import a, b, c

or even with "as".

>> versions. There are other examples where I need to transfer some
>> variables from one namespace to another. Dict is good type
>> for namespace,
>> but maybe it's time to propose new mapping type - namespace -
>> to do things I described?
>> I also thought about absent "with" operator and how it could be used
>> in Python. Maybe it is beneficial to have "with" syntax like in the
>> followin example:
>[snip example]
>> Are these ideas worth serious consideration?
>Perhaps, although I didn't find anything particularly compelling in your
>argument. Moving values from one namespace to another is easily handled
>by return values and assignment -- or if you're returning a large number
>of variables, by wrapping them in an object or a dictionary.
>The "with" keyword leads to a lot of implied context (especially when
>nested). While it may make code easier to write for a "lazy" programmer,
>readability and maintainability suffers. I think "explicit is better
>than implicit" is the better alternative here.

The main application for the things proposed is for small scripts, like
CGI-scripts, embedded things, database works, and such, where there are
some flows of names which need merging, reorginizing, etc by some
more automated means than just lots of assignments.

some kind of:

from DICT import "name" as "username", "action" ...

or just:

from DICT import *

Maybe module-like object could help here?

>-- bjorn

Sincerely yours, Roman Suzi
_/ Russia _/ Karelia _/ Petrozavodsk _/ rnd at _/
_/ Saturday, June 16, 2001 _/ Powered by Linux RedHat 6.2 _/

More information about the Python-list mailing list