1

The only component I need from pycountry is 'Languages'. I like to avoid importing anything more than needed, so I am tempted to do:

from pycountry import Languages

However, the only documented use I can find is:

import pycountry

Without knowing more, the only prudent option seems to be the documented route. As a module user, what else should I be aware of or consider?

FYI: I looked at In python, what are the pros and cons of importing a class vs. importing the class's module?, which had some good information but was focused on devs creating a module rather than using a module.

Update: I looked at Is import module better coding style than from module import function?. This has a wealth of good information, but I didn't see my fundamental misunderstanding addressed. I had assumed that from X import Y only imported what I asked for, but it imports the whole module.

Update2:
PM 2Ring's comment that "FWIW, all forms of import actually import the entire module" caught me by surprise. Since I got a NameError: name 'pycountry' is not defined on everything else in pycountry, I assumed nothing else was imported. Checking around (for example 'import module' vs. 'from module import function') I can see that 2ring is right and my assumptions were false.

Re: chepner's comment about being able to recognize the source when looking at my code. Since the first thing I would want to do is create my own alias langs = pycountry.languages, I eliminate any advantage either import form had.

Combining the comments from 2Ring and chepner, there is no advantage to the from pycountry import Languages form in my case and I shall use import pycountry.

At this point I feel like my question has been fully answered.

R. Clay
  • 49
  • 6
  • 3
    FWIW, all forms of `import` actually import the entire module - they have to, otherwise the stuff in it wouldn't work properly. The only way they differ is in which _names_ become available in your namespace. – PM 2Ring Jun 13 '17 at 01:04
  • 1
    I'd argue it depends on whether you (or your readers) are going to recognize a particular name as being imported from a particular module. This is somewhat subjective. For example, I'd recognized something like `itemgetter` as coming from `operator`; likewise, I don't really need to know which module `mul` or `add` are from (`operator` again) to have a good idea what they do... – chepner Jun 13 '17 at 01:20
  • ... On the other hand, I might be hard pressed to identify where `tmp_file` comes from. (`os`? no, that's `tmpfile`. `tempfile`? Plausible, but that module doesn't define anything by that name. Must be defined in the current module, or from some other module.) – chepner Jun 13 '17 at 01:20
  • Possible duplicate of [Is \`import module\` better coding style than \`from module import function\`?](https://stackoverflow.com/questions/1744258/is-import-module-better-coding-style-than-from-module-import-function) – Brad Solomon Jun 13 '17 at 02:07

1 Answers1

0

Summary:
I had a fundamental misunderstanding of import. I thought that:

from pycountry import Languages                 #FMIC

only imported the component I asked for, but it actually imports the whole pycountry module. The only difference between the FMIC form and the 'import module' form is that the FMIC form puts the requested component into my namespace (in my case Languages) and import pycountry puts the module (pycountry) into my namespace. In either case, a single object is added to my namespace.

Since the first thing I do is create an alias (either langs = Language('<path>/iso639-3.json') or langs = pycountry.languages), I now have 2 objects in my namespace: 'langs' and the imported object. Regardless of the form used to import, my usage will be no different (ex: current_lang = langs.get(alpha_2='en').

See Is import module better coding style than from module import function? for a discussion of many different cases and the advantages of the 'import module' form.

R. Clay
  • 49
  • 6