<div dir="ltr"><span style="font-family: courier new,monospace;">On Wednesday, March 16, 2016 at 7:43:05 PM UTC-5, Steven D'Aprano wrote:<br>> On Wed, Mar 16, 2016 at 03:50:53PM -0700, Rick Johnson wrote:<br>><br>> > from module _import Foo, bar<br>> <br>> That's anything but self-explanatory, since it gives no<br>> hint that Foo and bar will be imported under some name<br>> other than Foo and bar.  <br><br>Yes, I'll agree it would be far too esoteric for a language<br>that promotes readability. If i end up writing my own hack<br>though, i'll probably go this way, simply because it's the<br>most compact solution i think of at the moment.<br><br>> Besides, why is "import x as _x" so special to require special syntax? <br><br>Well, for a single symbol, it's not bad. But consider something like:<br><br> from module import Foo as _Foo, bar as _bar, BAZ as _BAZ, spam as _spam, eggs as _eggs<br><br>Now, that may seem like a contrived example, but i've<br>witnessed much longer "run-on import lines" than that. 79<br>chars will be eaten-up really quickly. But what eats up most<br>of the space, is the redundant " as _...". <br><br>When importing "piecemeal", it's impossible to avoid writing<br>the actual symbol names , but, if we can avoid the redundant<br>repetition of " as _...", it would be an improvement.<br><br>> Out of the infinite number of names that x could be<br>> imported as (import x as y etc) what's so special about _x<br>> that it deserves a short-cut?<br><br>Not exactly sure what your saying here, but, i'll fancy a<br>guess... <br><br>If you're suggesting that my syntax would be limited to<br>merely "adding a single leading underscore to the public<br>symbol (or symbols) as they are imported", then yes, you are<br>correct!<br><br>The intended purpose is to: "automate the privatization of<br>public symbols during the import process". Of course, if<br>they already have a leading underscore, they will remain<br>unchanged. But i wonder what should be done when they have<br>more than one underscore? Hmm...<br> <br>From my POV, I don't see anything wrong with "single purpose<br>utilities". In fact, i find them to be more intuitive. The<br>whole: "Do one thing, and do it well" philosophy...<br><br><br></span></div>