[Python-Dev] Great Renaming? What is the goal?

[Ken Manheimer]

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