On Tue, 28 Mar 2000, Jeremy Hylton wrote: > >>>>> "KLM" == Ken Manheimer <klm@digicool.com> writes: > > >> The only problematic use of from ... import ... is > >> from text.re import * > >> which adds an unspecified set of names to the current > >> namespace. > > KLM> The other gotcha i mean applies when the thing you're importing > KLM> is a terminal, ie a non-module. Then, changes to the > KLM> assignments of the names in the original module aren't > KLM> reflected in the names you've imported - they're decoupled from > KLM> the namespace of the original module. > > This isn't an import issue. Some people simply don't understand > that assignment (and import as form of assignment) is name binding. > Import binds an imported object to a name in the current namespace. > It does not affect bindings in other namespaces, nor should it. I know that - i was addressing the asserted evilness of from ... import ... and how it applied - and didn't - w.r.t. packages. > KLM> I thought the other problem peter was objecting to, having to > KLM> change the import sections in the first place, was going to be > KLM> avoided in the 1.x series (if we do this kind of thing) by > KLM> inherently extending the import path to include all the > KLM> packages, so people need not change their code? Seems like > KLM> most of this would be fairly transparent w.r.t. the operation > KLM> of existing applications. > > I'm not sure if there is consensus on backwards compatibility. I'm > not in favor of creating a huge sys.path that includes every package's > contents. It would be a big performance hit. Yes, someone reminded me that the other (better, i think) option is stub modules in the current places that do the "from ... import *" for the right values of "...". py3k finishes the migration by eliminating the stubs. Ken klm@digicool.com
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