[Tutor] Star imports, was Re: How to get a Tkinter window to print a color copy of itself as a .pdf file?

[boB Stepp]

On Thu, Apr 16, 2015 at 2:54 AM, Peter Otten <__peter__ at web.de> wrote:
> boB Stepp wrote:
>
>>> import Tkinter as tk
>>
>> Question: I have been using "from Tkinter import *" as suggested in
>> "Programming Python" by Lutz. He remarks that unlike other situations,
>> this is generally safe with Tkinter. Is there a benefit to doing the
>> import as you have?
>
> It's a stylistic preference: I like to keep namespaces separate.

After reading your full post, you have convinced *me* this is more
than stylistic preference.

> When I make an exception, typically for generic functionality like
>
> contextmanager, groupby, namedtuple, defaultdict...
>
> I import these in a controlled way with
>
> from collections import defaultdict
> from itertools import islice, zip_longest

Making it very clear to anyone who comes later.

> etc., use them as "pseudo-builtins", and avoid writing functions with the
> same name myself. By contrast I have no clear idea of what's in the tkinter
> package and might write my own getint() function, say, thus forcing a reader
> to scan the complete module to learn which getint() is used.

This in particular applies to me at my current stage of learning as I
have only scattered knowledge of all that is in the tkinter package.

> This is a general problem of star imports; when you overwrite an imported
> name you typically don't care or even know about that name in the imported
> module. When you read your module later to fix or amend something your
> knowledge may have grown, and you expect the imported function where the
> custom function is used. This confusion becomes even more likely when a
> second developer is involved.

You are so persuasive here that forthwith I will change to a
substantially explicit format of importing!

-- 
boB