flake8 sees 'c' as an undefined name

[cclauss]

From: https://traitlets.readthedocs.io/en/latest/config.html#python-configuration-files

A Config instance [...] is available inside the config file as c, and you simply set attributes on this.

This preestablishment of an external global variable is a bit of magic that causes linters (and sometimes humans) to scratch their heads. Would there be an OPTIONAL way to be explicit instead of implicit about the origins of c? Something OPTIONAL like like from ipython import c or from traitlets import c that would provide a quick hint as to where c came from.

flake8 testing of https://github.com/foo/bar on Python 3.7.0

$ flake8 . --count --select=E901,E999,F821,F822,F823 --show-source --statistics

./utils/bar.py:97:1: F821 undefined name 'c'
c.foo = 'bar'
^
1     F821 undefined name 'c'
1

Usually I would use global c to explain to humans and flake8 that 'c' is created in the global namespace by code that lies outside this file. However, global does not work in an un-indented code bloc which is where 'c' is usually used.

One solution would be to mark the code with a linter directive: c.foo = 'bar' # noqa: F821 but looks clunky and maintainers often resist adding linter-specific directives to their code. It is a shame when maintainers avoid linting a whole codebase because they do not know how to cleanly resolve one issue.

[cclauss]

Perhaps we could placate flake8 with:

from IPython import get_config()
c = get_config()

[minrk]

Yeah, I think a top-level traitlets.get_config would be useful for linting. For now, you can do:

c = get_config()  # noqa 

Since the get_config name is injected into the module namespace.

[cclauss]

It is the “injecting” that throws the linters — they tend to follow the Zen of Python: explicit is is better than implicit