On Wednesday, March 16, 2016 at 7:43:05 PM UTC-5, Steven D'Aprano wrote:
> On Wed, Mar 16, 2016 at 03:50:53PM -0700, Rick Johnson wrote:
>
> > from module _import Foo, bar
>
> That's anything but self-explanatory, since it gives no
> hint that Foo and bar will be imported under some name
> other than Foo and bar. 

Yes, I'll agree it would be far too esoteric for a language
that promotes readability. If i end up writing my own hack
though, i'll probably go this way, simply because it's the
most compact solution i think of at the moment.

> Besides, why is "import x as _x" so special to require special syntax?

Well, for a single symbol, it's not bad. But consider something like:

 from module import Foo as _Foo, bar as _bar, BAZ as _BAZ, spam as _spam, eggs as _eggs

Now, that may seem like a contrived example, but i've
witnessed much longer "run-on import lines" than that. 79
chars will be eaten-up really quickly. But what eats up most
of the space, is the redundant " as _...".

When importing "piecemeal", it's impossible to avoid writing
the actual symbol names , but, if we can avoid the redundant
repetition of " as _...", it would be an improvement.

> Out of the infinite number of names that x could be
> imported as (import x as y etc) what's so special about _x
> that it deserves a short-cut?

Not exactly sure what your saying here, but, i'll fancy a
guess...

If you're suggesting that my syntax would be limited to
merely "adding a single leading underscore to the public
symbol (or symbols) as they are imported", then yes, you are
correct!

The intended purpose is to: "automate the privatization of
public symbols during the import process". Of course, if
they already have a leading underscore, they will remain
unchanged. But i wonder what should be done when they have
more than one underscore? Hmm...
 
From my POV, I don't see anything wrong with "single purpose
utilities". In fact, i find them to be more intuitive. The
whole: "Do one thing, and do it well" philosophy...