[Python-Dev] Re: PEP 328 -- relative and multi-line import

[Barry Warsaw]

On Sat, 2004-04-10 at 12:57, Andrew Koenig wrote:

> The trouble is that if you commit yourself to backward compatibility, you
> wind up with a growing list of decisions for which the default is wrong but
> you didn't want to break code by changing it.  Each time you make such a
> decision, you make it more difficult the next time to do anything but go for
> compatibility again.  Ultimately, everyone has to remember to override the
> defaults in lots of everyday circumstances, a mental burden that hurts
> everyone from novices to experts.
>  
> On the other hand, if you don't commit yourself to backward compatibility,
> you wind up with people downloading old code that breaks because things have
> changed.
> 
> The third possibility is to support all alternatives forever, perhaps with a
> mechanism such as "from __past__ import foo".  That's possible in theory,
> but if changes include changes in semantics, it may be impossible for old
> and new to coexist.  Moreover, even if they can coexist, testing becomes a
> nightmare.
> 
> It's a trilemma--a choice between three unpleasant alternatives.  I don't
> know the right answer, but I do wish to caution against assuming the problem
> is trivial.

This is one of the reasons I suggested early on that there be a way to
spell -- at the package level by the package developer -- "I'm using
absolute imports here".  Without that spelling, the package would still
use the old semantics, however broken they are <wink>.

E.g. if I could put in email/__init__.py something like:

from __future__ import i_am_absolutely_resolved_about_my_imports

then I'd expect PEP 328 semantics in package email and all subpackages. 
Older packages wouldn't have this declaration and would operate under
the old rules.  (I still don't have any need for relative imports. ;)

-Barry