PEP 0328 (relative import) implementation

[Yhg1s]

BPO	1438387
Nosy	@Yhg1s
Files	pep-0328.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/Yhg1s'
closed_at = <Date 2006-02-28.22:25:06.000>
created_at = <Date 2006-02-24.22:28:22.000>
labels = ['interpreter-core']
title = 'PEP 0328 (relative import) implementation'
updated_at = <Date 2006-02-28.22:25:06.000>
user = 'https://github.com/Yhg1s'

bugs.python.org fields:

activity = <Date 2006-02-28.22:25:06.000>
actor = 'nnorwitz'
assignee = 'twouters'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2006-02-24.22:28:22.000>
creator = 'twouters'
dependencies = []
files = ['7034']
hgrepos = []
issue_num = 1438387
keywords = ['patch']
message_count = 5.0
messages = ['49600', '49601', '49602', '49603', '49604']
nosy_count = 2.0
nosy_names = ['twouters', 'nnorwitz']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1438387'
versions = ['Python 2.5']

[Yhg1s]

This is a complete implementation of PEP-328, relative imports,
including the future statement to enable absolute imports by default.
It's currently lacking tests and documentation. A couple of caveats:

• It's implemented by extending the stack-arguments of the
  IMPORT_NAME opcode, but it doesn't up the bytecode magic. You need
  to 'make clean' or 'make distclean' to remove existing .pyc/.pyo files,
  or you'll get random crashes.

• It's implemented by adding a 5th (optional) argument to __import__,
  to the end, for 'relative depth'. This new argument, 'lvl', can be -1, 0 or
  a positive number. -1 signals 'non-absolute non-dotted import', or
  exactly the same as 'import module' before. 0 signals 'absolute non-
  dotted import', which means 'import module' with absolute-imports
  enabled (by using 'from __future__ import absolute_import'.) A positive
  number is the number of dots in 'import ...module'; the amount of
  relativeness of the import.

• __import__'s 5th value defaults to -1 for now. It should obviously
  change to 0 when absolute imports are the absolute truth (in 2.7 or
  so.)

• The 5th argument to __import__ is only passed when it's not -1, so
  'old' __import__ replacements still work as long as code doesn't use
  'import ..module' or 'from __future__ import absolute_import'.

• I haven't tested it extensively with frozen or zipped modules or
  custom importhooks and what not. The testsuite shows no failures for
  me (on MacOS and Linux) but none of the test modules use
  'import ..test' or 'from __future__ import absolute_import'.

This patch was brought to you by Lufthansa "babycarrier" Airlines and
10 hours stuffed in a too small chair surrounded by crying, whiney
babies and kids.

[Yhg1s]

Logged In: YES
user_id=34209

I just noticed I didn't quite implement the right thing. 'from ..module import
something' works as expected, but 'from . import module' is not implemented,
and the 'import .module' syntax Guido rejected actually *is* implemented. I
guess I'll have to fix that ;)

On the upside, it seems this patch Just Works(tm) with zipimports, so I have
reasonable faith that it's going to work across the board.

[Yhg1s]

Logged In: YES
user_id=34209

A slightly modified patch that implements all of PEP-328 correctly. It does so by,
at AST-generation time, changing 'from . import module' into 'import .module',
and disallowing 'module .module' directly. I'm not sure if the AST should do that
or not, but that's the easiest way to add it.

[Yhg1s]

Logged In: YES
user_id=34209

And now a full, proper, complete implementation, with tests and everything. It
should be just about done, barring small bugfixes, documentation, and
parsermodule and compilerpackage support.

[nnorwitz]

Logged In: YES
user_id=33168

Thomas checked this in.