[Python-Dev] Re: Python 2 namespace change?

Jeremy Hylton jeremy@cnri.reston.va.us
Mon, 7 Feb 2000 11:49:46 -0500 (EST)


>>>>> "JF" == Jim Fulton <jim@digicool.com> writes:

  JF> I'm suggesting a model where from "M import x" has a different
  JF> meaning than it does now.  I think the notion of sharing a name
  JF> is useful. I'll admit that using "M.x" achieves the same thing,
  JF> although at a higher performance cost (and, OK, typing cost ;).

This seems to contradict the 2nd Pythonic principle:
   Explicit is better than implicit.

I don't literally mean to argue that "The Python Way" should be used
to make design decisions, but it captures exactly what makes me
uncomfortable with the proposed change.

  [someone else, who could have been channeling me, wrote:]
  >> I don't understand why you wanted these semantics in the first
  >> place.

  JF> First, let me say that this isn't super important to me.  It

Glad to hear it <0.3 wink>!

  JF> does solve a problem with reload, which is the context in which
  JF> I brought it up.

I don't think the reload problem is important enough to justify a
change to name binding rules.

  [much omitted]

  JF> In any case, I'd feel comfortable explaining a system in which
  JF>   from M import x # reference semantics wrt name
  JF> had a different meaning from:
  JF>   import M x=M.x # copy semantics
  JF> since I expect an attribute access to give me a value, not a
  JF> name, whereas:
  JF>   from M import x
  JF> seems more to me like it's talking about names.

I think the proposed change muddies the semantics of assignment, and I
would not feel comfortable trying to explain it.  I don't have the
same impression vis a vis import and names; I think this is why I
disagree and have heretofore been puzzled about why you want this.
Assignment binds a name to an object; import is just a variant of
assignment.  There is no need for a special case.

One other worry:  How would it create a copy of an object in general?
How do you copy a class object or a file or a socket?  Since (1) you can't
restrict which types of objects are exported by a module and (2) there
is no clear definition of copy that applies to any type of object, I
don't see how these semantics could be defined.

Jeremy