Setting the "copyright" for a Sphinx project requires overriding a builtin

[adamtheturtle]

Describe the bug

copyright is a constant added by the site module in Python.

$ python3 -c "print(copyright)"
Copyright (c) 2001-2020 Python Software Foundation.
All Rights Reserved.

Copyright (c) 2000 BeOpen.com.
All Rights Reserved.

Copyright (c) 1995-2001 Corporation for National Research Initiatives.
All Rights Reserved.

Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam.
All Rights Reserved.

copyright is also a Sphinx configuration variable overriding this.

This means that pylint (correctly, I think) errors with redefined-builtin when a copyright is set in conf.py.

Expected behavior

I think that it would be best to provide an alternative name for this variable name.

Environment info

• Python version: 3.8.5
• Sphinx version: 3.2.1

[fametrano]

+1

project_copyright might be the Sphinx alternative

[shimizukawa]

Ah, it's true that it's battling with a built-in global variable.
However, I think only a few people care about this conflict.
+0 for an alias.

[tk0miya]

-0: I consider conf.py is a configuration file (using python syntax). So it is not necessary to lint it. But I don't object to adding a new alias.

[adamtheturtle]

@tk0miya - Thank you! I appreciate that you fixed this, especially despite being -0 on it.

I consider conf.py is a configuration file (using python syntax). So it is not necessary to lint it.

I happen to lint configuration files where I can, e.g. with YAML linters, with travis-lint, with nginx linters and more. Linting can help find issues faster, which is why I use linters where possible to achieve that.

[tk0miya]

To follow the warnings from lint tools, we can't use the name of python builtin functions and variables for the configurations of Sphinx because of we're using .py script as a file format. It means nobody warns to use copyright keyword if we use JSON, TOML and so on for our file format. I don't have a plan to add a new configuration variables as same as python builtins. I feel that is strange...

Anyway, I can agree with the new alias name; project_copyright. So we don't have any big problem at present. let's think about linting tools again if we'll get another problem.

[asears]

Linting and test coverage are important for some projects and this would be multiplied by each team using flake8 scans to scan code. Would team consider adding # noqa A001 to the scaffolding tools to silence the flake8-builtins lint check, if copyright isn't to be renamed, and for backwards compatibility?