Import concerns revisited

[Dave]

kris wrote:
> Dave wrote:
>> Actually, how about:
>>
>> import from some.long.modid func as f1, abcd, efgh as zzz;
>> private import from this.other.cool.db.lib as dblib;
>>
>> Is more consistent w/ current syntax, maintains the visual continuity, 
>> allows more than one symbol import per module (w/o retyping the 
>> module), and combines the import w/ the alias if desired.
>>
>> - Dave
> 
> 
> Don't wish to belabour the point, but why the private attribute when 
> it's not really required?
> 

I missed that... You're right, no need for 'private'.

> Traditional import:
> 
> a - import lib.text.locale;
> 
> Safe import:
> 
> b - import lib.text.locale as locale;
> 
> 
> Selective safe import variations:
> 
> 1 - import from lib.text.locale Date, Time as myTime;
> 
> 2 - import lib.text.locale.Date;
>     import lib.text.locale.Time as myTime;
> 
> 3 - with lib.text.locale import Date, Time as myTime;
> 
> 
> If import consistency is deemed desirable, then #1 & #2 perhaps looks 
> like the most appropriate in that context? Although the latter seems 
> notably more verbose. Personally, I like your #1 due to the consistency 
> of the leading "import"
> 

I tend to forget things if I don't use a syntax (or a language) for a 
while; the more consistent things are the less I have to RTFM for 
something I've forgotten - just my preference. I think it'll probably be 
important for brand-newbies too, along with the aforementioned scanning 
code for imports.

The other part of it is that the C-lineage languages all start their 
'includes' with a verb, not a preposition, so #1 just feels more natural 
than #3.

> Whatever the outcome, daily usage should be simple to use and maintain, 
> obvious, and not tiresomely redundant -- we want to encourage the use of 
> the safe import.
> 
> ------------
> 
> Contrived illustration:
> 
> module lib.net.server.ftp;
> 
> import lib.io.file,
>        lib.text.convert.utf as utf;
> 
> import from lib.text.locale Date, Time;
> 
>