Hi Alan
> Hi Cedric,
>
> Reading through this I can't help but think you are going to
> a lot of trouble to make things very complicated for yourself
> - and for anyone else who has to work on your code. The
> Python module system is very simple and helpful in tracking
> down where the various things live. You can see by the
> prefix name which package/file provides which service.
> It appears that you are trying to hide that information?
>
> Is there a special reason why you are trying to introduce
> this kind of obfuscation?
>
> > > > {a,b,c}.py contains respecetively classA,classB,classC more some
> unittest
> > > > and bunch.py will contains some usefull function using the
> class{A,B,C}
> > > >
> > > > I'd like that when I import MyModule (`import MyModule')OB
> > > > I'll see from it:
> > > > MyModule.classA
> > > > .classB
> > > > .classC
> > > > .<function1 in numch.py>
> > > > .<function2 in numch.py>
> > > > ...
> > > > without seeing MyModule.{a,b,c}
>
> Why do you want to conceal the information about what lives inside
> the package? How will users be able to debug the package? If you
> hide a,b and c you will make it harder to do things like
I thought that it will be more convenient. But as I can read from your email: it seems a really __not_so_good__ idea .
>
> >>> dir(MyModule)
> >>> dir (MyModule.a)
>
> etc to explore the structure and find the code.
never done such kind of things.
>
> > I've done it. But is it normal that I'see also the filename
>
> Actually you don;t see the filename you see the sub moduile names.
> a.py becomes a module called a within your package.
>
> > the idea was to automate the :
> > from MyModule.a import classA
> > from MyModule.b import classB
> > from MyModule.c import classC
>
> What is the advantage - apart from a minimal amount of typing?
> You still need to maintain a list of the class/module mappings.
no the idea was to give a prefix to all my files depending on the way I'd like to import them. In fact, my files are named class_foo.py and the class inside this file is named CFoo.
> > with a loop
> > <snip>
> > lclassname=['classA', 'classB', 'classC']
> > #in the future I can even automate the creation of classname list
> > for classname in lclassname:
> > #filename='a', classname='classA'
> > filename=classname.replace('class','').lower()
>
> Maybe you should use a dictionary as Kent suggested:
>
> classes = {'classA': 'a',
> 'classB': 'b',
> 'classC : 'c'
> }
>
> filename = classes[classname]
>
> > #from filename import classname
> > module=__import__(filename, gloabls(), locals(), [classname])
> > classDefinition=getattr(module,classname)
> > assign(classname,classDefinition)
> > <snip>
>
> But this is a lot of work to sabve a very small amount of typing and
> could slow down your program initialisation significantly.
>
> > In this way, when I'll do an
> > import FWobs
> > I'll get:
> > MyModule.classA
> > .classB
> > .classC
> > .<function1 in numch.py>
> > .<function2 in numch.py>
>
> It looks as if all you really want to do is avoid having the
> sub-module names visible when you import the package. As I
> explained above I think thats a fundamentally bad idea.
Good, I'll follow your recommendation
> If you do just want to export a single set of services from a
> single import it would be much simpler to just put them all
> in a single module! And then you can hide the exposed names
> using the Python naming convention of prefixing with '_'
> or ' __'.
>
> Of course if its a very large set of services a package
> is better, but then you probably should expose the sub modules
> too. NAmespaces are one of Pythons best features - they are
> simple to use and very effective both in controlling program
> structure and in aiding debugging, its probabnly best to use
> them as intended rather than trying to force them to work
> differently.
>
> All IMHO of course! :-)
>
> Alan G
thanks for your time.
Ced.
--
Cedric BRINER