No subject

George Sakkis gsakkis at rutgers.edu
Fri Jul 1 11:25:47 EDT 2005


>> - namespaces
>
> >Aren't namespaces basically the same as packages/modules in python?
>
> Not in the way C++ uses them. In Python if would be something like this:
> ---------------------------
> import os
> using namespace casa
> class os:
>     def open(self, file):
>         pass
> a = os.open('something')
> b = std::os.open('something')
> using namespace std
> c = casa::os.open('something')
> d = os.open('something')
> ---------------------------
> This is a realy stupid example. It's essentially an extra hierarchy
> layer to avoid naming clashes. I don't know of a way to do this in
> Python, how would you do this?

I'm not sure how your pseudo python/c++ example resolves name clashes,
and honestly I would rather not deal with such mind boggling code. You
can certainly avoid name clashes in python less ambiguously; explicit
is better than implicit:

from std import os as std_os
from casa import os as casa_os

class os:
    def open(self, file):
        pass

a = os.open('something')
b = std_os.open('something')
c = casa_os.open('something')

By the way, if os is a class, open() should probably be called in an
instance of os, i.e. os().open('something'), but that's not the point
of your example.

> >> - data hiding
>
> >Surely you can hide data in python?
>
> Again, how? Is there a way to force that an external user of my lib can
> not use my internal data/methods/classes, unless he uses odd compiler
> hacks?

Strictly speaking, no you can't, at least in pure python. The
convention is to prefix internal names with single underscores. There
is limited language support for private class attributes through name
mangling (http://www.python.org/doc/current/tut/node11.html), but
that's in general frowned upon, unless you have very good reasons to do
so. I never understood how mainstream OO languages expect the designer
of a class to know in advance that an attribute should be hidden or
unnecessary to its subclasses by being declared "private" instead of
"protected". The distinction between public and non-public (private +
protected) is more understandable, but again python's philosophy is
"we're all consenting adults here". _single_underscored names just
flash a "use at your own risk" signal, instead of tying your hands in
case the original class designer made a wrong assumption.

George




More information about the Python-list mailing list