namespaces

[Steven D'Aprano]

On Sun, 31 Jul 2005 15:09:48 +0200, Paolino wrote:

> Steven D'Aprano wrote:
> 
>> def translate(text):
>>     import string
>>     all=string.maketrans('','')
>>     badcars=all.translate(all,string.letters+string.digits)
>>     table=string.maketrans(badcars,'_'*len(badcars))
>>     return text.translate(table)
>> 
>> No pollution.
> 
> And no efficience.Recalculating all,badcars and table was not an 
> acceptable solution ,sorry if I didn't state this point :(

Why not? Is it too slow? Too many lines of code? Uses too much memory?
What exactly is the problem? I would like to see your profile tests that
show why this is not acceptable.

Are you sure that this solution is less efficient than creating a class? A
class has all that extra machinery and methods and attributes that needs
to be created, only to be thrown away. How do you know that my solution is
less efficient than your solution?


>> Then after you are finished with the bindings, delete them:
>> 
>> import string
>> all=string.maketrans('','')
>> badcars=all.translate(all,string.letters+string.digits)
>> table=string.maketrans(badcars,'_'*len(badcars))
>> def translate(text):
>>     return text.translate(table)
>> # clean up the temporary variables so as to prevent namespace pollution
>> del string; del all; del badcars; del table
> 
> Well,a solution but not a programming pattern for an elegant language ?
> More this is also loosing informations.

Deleting things you don't need or want is not losing information. You
asked for a solution to make the bindings go away. Deleting them makes
them go away.

> Probably I've not been clear with the word pollution and the example is 
> poor.
> I didn't mean 'binding to unuseful informations' but 'bindings  in a non 
> -structured organization'
> 
> I restate the problem.Python is in some ways unable to project the 
> module structure inside the module.Or ... namespace pattern instances 
> seems  not deriving from a common pattern.

I'm sorry, but I do not understand this.


> Finally, (before I get polemic which is not my aim) I start thinking 
> classes (namespaces defined via 'class' keyword) are a specialization of 
> generic namespaces in which there-defined methods get a special way of 
> being called and __call__ method is a way of cloning access to them.
> (Thin ice....)

Yes, classes are a namespace.

I don't know what you mean by "cloning access", but __call__ is the method
called for arbitrary objects when you call them as if they were a
function: someobject().


> Don't really know if modules can be defined as specialization  of 
> generic namespaces and be placed somewhere next to classes.
> 
> Even worse I get with methods and function namespaces.

What is "even worse" about them?


Quoting Rob Williscroft:

>  > def translate( text )
>  >     import string
>  >     all=string.maketrans('','')
>  >     badcars=all.translate(all,string.letters+string.digits)
>  >     TABLE = string.maketrans(badcars,'_'*len(badcars))
>  >
>  >     global translate
>  >     def translate( text ):
>  >         return text.translate(TABLE)
>  >
>  >     return translate( text )

This is a difficult piece of code to understand and maintain. You have a
function called translate, which in turn calls the string translate()
method. That's okay. But then you have a global variable *also* called
translate -- does that refer to the same function? Is this self-modifying
code? That is a dangerous, hard to debug, hard to understand technique
that is too-clever-by-half.

Then you create a local variable, also called translate, also a function,
which simply calls the translate method of its argument. A waste of a
function, when all you need to do is call the pre-existing translate
method. If I have understood this code correctly, the *local* translate
is bound to the *global* translate, which is the function being
defined.

And lastly, just to complete the confusion, the original function itself
appears to call itself -- presumably the rebound copy that points to what
was the local copy -- recursively, with the same argument.

That's a nifty piece of code for showing how clever you are at writing
mildly obfuscated code. But for commercial use, where the code has to be
maintained and debugged, it is a terrible idea.

> There is a way to access 'all' and 'badcars'  here?

I can't see any way to access them. Isn't that the point? You don't want
them available?

> In my trial translate.all and translate.badcars can be accessed easily
> and maybe coherently.

Yes, and you asked for that not to happen. That's what namespace pollution
means -- you get temporary objects persisting after you no longer
need them, and showing up in the namespace when you don't want them there.

-- 
Steven.