Proposal: Inline Import

[Mike Meyer]

Shane Hathaway <shane at hathawaymix.org> writes:
> Mike Meyer wrote:
>> Shane Hathaway <shane at hathawaymix.org> writes:
>>>That syntax is verbose and avoided by most coders because of the speed
>>>penalty.
>> What speed penalty? "import re" is a cheap operation, every time but
>> the first one in a program.
> I'm talking about using imports *everywhere*.  The penalty would be
> appreciable.

As Kent shows, it wouldn't. Are you sure you understand what import
really does?

>>>What's really got me down is the level of effort required to move code
>>>between modules.  After I cut 100 lines from a 500 line module and
>>>paste them to a different 500 line module, I have to examine every
>>>import in both modules as well as examine the code I moved for missing
>>>imports.
>> Has it ever occured to you that if you're cutting and pasting 500
>> line
>> blocks, you're doing something fundamentally wrong? One of the points
>> of modules and OO is that you don't *have* to do things like
>> that. Cut-n-paste means you wind up with two copies of the code to
>> maintain, so that bug fixes in one will have to be propogated to the
>> other "by hand". Rather than spend time fixing what you broke by
>> yanking the code out of it's context, you'd be better off refactoring
>> the code so you could use it in context. That'll cut down on the
>> maintenance in the future, and may well mean that the next time
>> someone needs the code, it'll already be properly refactored so they
>> can use it directly, without having to cut-n-paste-n-fix it again.
> I said cut and paste, not copy and paste.  I'm moving code, not
> copying it.  Your advice is correct but doesn't apply to this problem.

In that case, dealing with importst is a minor part of your
problem. You have to check for every name in the global name space in
both the old and new files to make sure they get defined properly.

     <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.