flake8 sees 'c' as an undefined name

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](http://flake8.pycqa.org) 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.

Start by reproducing the F821 report in utils/bar.py with the flake8 command shown, then read the Python configuration-file behavior described in the linked Traitlets documentation. Identify the configuration entry point that creates c; done means an optional explicit declaration is supported without requiring a linter-specific noqa directive.

由索引模型根据 Issue 内容生成。