(newbie) Is there a way to prevent "name redundancy" in OOP ?

[Carl Banks]

Martin Miller wrote:
> Carl Banks wrote:
>
> > Martin Miller wrote:
> > > ### non-redundant example ###
> > > import sys
> > >
> > > class Pin:
> > >     def __init__(self, name, namespace=None):
> > >         self.name = name
> > >         if namespace == None:
> > >             # default to caller's globals
> > >             namespace = sys._getframe(1).f_globals
> > >         namespace[name] = self
> > >
> > > Pin('aap')      # create a Pin object named 'aap'
> > > Pin('aap2')     # create a Pin object named 'aap2'
> > > print aap.name
> > > print aap2.name
> >
> > The problem with this is that it only works for global namespaces,
> > while failing silently and subtly if used in a local namespace:
>
> Oh, contrair. It would work fine with local namespaces simply by
> overriding the default value of the optional 'namepace' parameter (see
> below).

Did you try it?

> > def fun():
> >     Pin('aap')
> >     aap1 = aap
> >     fun2()
> >     aap2 = aap
> >     print aap1 is aap2
> >
> > def fun2():
> >     Pin('aap')
> >
> > If it's your deliberate intention to do it with the global namespace,
> > you might as well just use globals() and do it explicitly, rather than
> > mucking around with Python frame internals.  (And it doesn't make the
> > class unusable for more straightforward uses.)
>
> You could be more explicit by just passing 'globals()' as a second
> parameter to the __init__ constructor (which is unnecessary, since
> that's effectively the default).
>
> It's not clear to me how the example provided shows the technique
> "failing silently and subtly if used in a local namespace" because what
> happens is exactly what I would expect if the constructor is called
> twice with the same string and defaulted namespace -- namely create
> another object and make the existing name refer to it. If one didn't
> want the call to Pin in fun2 to do this, just change fun2 to this:

Because the usage deceptively suggests that it defines a name in the
local namespace.  Failing may be too strong a word, but I've come to
expect a consistent behavior w.r.t. namespaces, which this violates, so
I think it qualifies as a failure.

> def fun2():
>     Pin('aap', locals())

Did you actually try this?  Better yet, try this function.  Make sure
aap isn't defined as a global:

def fun3():
    Pin('aap',locals())
    print aap

(I get NameError.)

> This way the "print aap1 is aap2" statement in fun() would output
> "true" since the nested call to Pin would now (explicitly) cause the
> name of the new object to be put into fun2's local namespace leaving
> the global one created by the call in fun() alone.

Did you try it?

> Obviously, this was not an objection I anticipated. An important one I
> would think is the fact that the current documentation says that
> f_globals is a special *read-only* attribute of a frame object implying
> that it shouldn't be changed (even though doing so 'works' as my
> example illustrates).

That means it can't be rebound.  It doesn't mean you can't modify the
object.  Nevertheless, frame objects are an internal feature of Python,
not guaranteed to work for other incarnations of Python (it doesn't
even exist in IronPython, for example), and subject to change.  And
what you want to do is easily done in a platform generic way without
using sys._getframe.

> I think other valid arguments against this practice might include
> whether it's an example of good OOP, or a good programming practice at
> all, since it involves possibly subtle side-effects, the use of global
> variables, and/or is 'unpythonic'.

I think programmatically creating variables is fine; I just recommend
you not use sys._getframe, nor the automagical namespace self-insertion
class, to do it.

> Certainly the approach is not without caveats. Despite them, I believe
> it can be useful in some contexts, as long as what is going on is
> clearly understood. The point of my reply to the OP was mainly just to
> illustrate the power and flexibility of Python to the newbie. I guess
> to that I should have also added that it gives you "enough rope to
> shoot yourself" as Allen Holub said regarding C++.
> Cheers,
> -Martin



Carl Banks