Making classes from Metaclasses globally available

[Peter Otten]

Jacek Generowicz wrote:

> Peter Otten <__peter__ at web.de> writes:
> 
>> Note, however, that dynamically inserting variables is not the best
>> programming practice. When you don't know the variable name in
>> advance, what would be the benefit of being able to access the
>> object via its identifier?
> 
> When _who_ doesn't know the variable name in advance of _what_ ?

I may be fighting with the english language here - and lose...

>>>> dir()
> [ <stuff> ]
>>>> from foo import *
>>>> dir(foo)
> [ <stuff>, 'hello']
>>>> hello()
> 'Hello, World!'
> 
> Here we dynamically inserted variables not known beforehand to the
> user, even if they were known beforehand to the module writer.

I've taken to avoid the * import, but at least I would hope that you
- had a quick look at the foo documentation before you chose to import it
- follow the convention of placing import statements at the beginning of the
module, and therefore can write your own help() function with some
confidence that it will not be inadvertently replaced by foo.help
 
> Not convinced?

You guessed it.

> OK ...
> 
>>>> from treebuilder import build_structure_from_xml_tree
>>>> dir()
> [ <stuff> ]
>>>> build_structure_from_xml_tree('fubar.xml')
>>>> dir()
> [ <stuff>, 'root' ]
>>>> dir(root)
> ['branch1', 'branch2']
> 
> 
> Here we dynamically inserted variables not known beforehand to the
> author of the module, which may or may not have been known to the
> user. If the user were the author of fubar.xml then, presumably he
> would know the variable names; if he were not, then he may well not
> know them beforehand. Either way he is likely to want to access them by
> name.

OK. Now show me the demo again with an XML document along the lines of 

<dir><file/><file/></dir>

In principle I have no problem with the dynamically chosen attribute names -
just hope my example would *not* result in the creation of fileN attributes
- but why can't your function_with_a_long_name() just return the root
*object* and let the user decide about the appropriate name - or at least
take a namespace as its second argument?

> ... still not convinced ?

This is even worse.

> I have a program which parses C++ header files and creates Python
> proxies for the stuff found therein, allowing you to interact with
> objects in C++ libraries. You load something we call a dictionary
> (which describes the library) and the program uses that information to
> create, dynamically, Python objects with the same names and structures
> as the C++ classes in the library.
> 
> The author of the program certainly does not know the names of the
> objects the program is going to create in the future. The client may
> know them (he might be wanting to rewrite some C++ code in Python), or
> not (he might be wanting to use Python's introspection capabilities to
> poke around the C++ library).

As far as I can judge from the description, this is perfectly OK with me. 
The recommendation to avoid dynamic manipulations of the global namespace
was not meant as a rule carved in stone, but rather a means to write
cleaner code and avoid errors that may be hard to reproduce.

Peter

PS: I'm glad I didn't also warn the OP against using metaclasses with as
little information as his code snippets and lack of knowledge of the
globals() function. I admit I was tempted...