A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-February/002115.html below:

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

[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






RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4