bug/poor tracebacks while importing code

[Robin Becker]

In article <anfcgq$eae$1 at peabody.colorado.edu>, Fernando Pérez
<fperez528 at yahoo.com> writes
>Robin Becker wrote:
>
>> Is there some reason why we have poor code inspection during imports.
>> b.py isn't mentioned in the traceback obtained in c.py in the following
>> noddy example and this is limiting my ability to do nasty import tricks.
>> This is with stock win32 2.2.1.
>> 
>
>The problem is --I think-- rather that by explicitly doing the printing of the 
>traceback yourself, you are limiting the scope of the information returned. 
>
>Consider the following changes (I left your b.py unaltered):
.....actual traceback ommitted
>In this case you do get information about b, the importer.
>
>hth,
>
>f
The underlying problem is that I want to determine the python machine
instruction that caused a bootstrap __init__.py to be imported as I wish
to transparently cause a different package to be substituted. I can do
this if the import is of the form 'import a', but not obviously if it is 
'import a.sub_a' or 'from a import sub_a' etc as I require to repeat the
required import with my __import__ magic in place.

When I try and locate the instruction using sys._getframe() and
frame.f_back etc I find that the frame.f_lasti doesn't seem to be set
properly.

I was groping towards using something from traceback to help me and
indeed when not using -O it seems that we can get a more precise
location using the approach used by Mike. If line numbers are present
and I know the line number I can locate the right setlineno code and
proceed from there. Wit -O on it seems as though even this isn't
possible. 

The best solution to this problem would be for ceval to update f_lasti
when doing an import instruction, but I guess that's unlikely to happen.
-- 
Robin Becker