Differences in what lint (e.g., mypy, flake8, etc) require from new code and what Cpython uses/returns - e.g., strings with single/double quotes.
Hi all, Last year I was struggling to get some code to pass CI in pypa/packaging. There were other issues, but one that suprised me most was learning to ALWAYS use double quotes (") to get the code to pass the lint check (type checking). Anything using single quotes (') as string delimiters were not accepted as a STRING type. I am not questioning the demands of the lint checker - rather - I am offering my services (aka time) to work through core to make CPython pass it's own (I assume) PEP recommendations or guidelines. Again, this is not a bug-report - but an offer to assist with what I see as an inconsistency. If my assistance in this area is appreciated/desired I would appreciate one or more core developers to assist me with managing the PR process. Not for speed, but I would not want to burden just one core developer. My approach would entail opening a number of related 'issues' for different pieces: e.g., Lib, Modules, Python, Documentation where some Lib|Modules|Python pieces might need to be individual 'issues' due to size and/or complexity. I do not see this as happening 'overnight'. so-called simple things to fix: In Documentation: The return value is the result of the evaluated expression. Syntax errors are reported as exceptions. Example: x = 1 eval('x+1') 2 Change the text above to state eval("x+1") - assuming the lint process would no longer accept eval('x+1') as proper typed syntax. And, then, hoping this is still regarded as 'simple' make sure code such as ctypes.util.find_library() is consistent, returning strings terminated by double quotes rather than the single quotes as of now. >>> import ctypes.util >>> ctypes.util.find_library("c") >>> 'libc.a(shr.o)' >>> ctypes.util.find_library("ssl") >>> 'libssl.a(libssl.so)' Something more "complex" may be the list of names dir() returns: >>> >>> import sysconfig >>> dir(sysconfig)) ['_BASE_EXEC_PREFIX', '_BASE_PREFIX', '_CONFIG_VARS', '_EXEC_PREFIX', '_INSTALL_SCHEMES', '_PREFIX', '_PROJECT_BASE', '_PYTHON_BUILD', '_PY_VERSION', '_PY_VERSION_SHORT', '_PY_VERSION_SHORT_NO_DOT', '_SCHEME_KEYS', '_USER_BASE', '__all__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', '_expand_vars', '_extend_dict', '_generate_posix_vars', '_get_default_scheme', '_get_sysconfigdata_name', '_getuserbase', '_init_non_posix', '_init_posix', '_is_python_source_dir', '_main', '_parse_makefile', '_print_dict', '_safe_realpath', '_subst_vars', '_sys_home', 'get_config_h_filename', 'get_config_var', 'get_config_vars', 'get_makefile_filename', 'get_path', 'get_path_names', 'get_paths', 'get_platform', 'get_python_version', 'get_scheme_names', 'is_python_build', 'os', 'pardir', 'parse_config_h', 'realpath', 'scheme', 'sys'] >>> Regards, Michael
On Thu, 9 Jan 2020 at 10:42, Michael <aixtools@felt.demon.nl> wrote:
Last year I was struggling to get some code to pass CI in pypa/packaging. There were other issues, but one that suprised me most was learning to ALWAYS use double quotes (") to get the code to pass the lint check (type checking). Anything using single quotes (') as string delimiters were not accepted as a STRING type.
pypa/packaging is a different project than CPython, with different standards and contribution guidelines. The insistence on double quoted strings sounds like the project uses black for formatting, and indeed the project documentation at https://packaging.pypa.io/en/latest/development/submitting-patches/#code confirms that. You shouldn't need to manually correct all of the code you write in that case - simply running black on any file you change should fix the style to match the project standards (again, please note this is *only* for the pypa/packaging project - you should check the contribution guidelines for any other project you contribute to, because their standards may be different). Paul
Hi Michael, and welcome! On Thu, Jan 09, 2020 at 11:37:33AM +0100, Michael wrote:
I am not questioning the demands of the lint checker - rather - I am offering my services (aka time) to work through core to make CPython pass it's own (I assume) PEP recommendations or guidelines.
That would create a lot of code churn for no good reason. The CPython project doesn't encourage making style changes just for the sake of changing the style. The most important part of PEP 8 is this: https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgo... Going through the entire stdlib creating bug reports for style issues is not a productive use of anyone's time. There are large numbers of open bug reports and documentation issues that are far more important. Regarding strings, PEP 8 doesn't recommend either single quotes or double quotes for the std lib, except that doc strings should use triple double-quotes. Each project or even each module is free to choose its own rules. https://www.python.org/dev/peps/pep-0008/#string-quotes -- Steven
On 09/01/2020 13:16, Steven D'Aprano wrote:
Hi Michael, and welcome!
On Thu, Jan 09, 2020 at 11:37:33AM +0100, Michael wrote:
I am not questioning the demands of the lint checker - rather - I am offering my services (aka time) to work through core to make CPython pass it's own (I assume) PEP recommendations or guidelines. That would create a lot of code churn for no good reason. The CPython project doesn't encourage making style changes just for the sake of changing the style.
Code churn is not my goal. Passing pypa/packaging CI (as Paul commented) is only required by them - afaik. And a tool, such as `black` can fix these things auto/magic/ally. But it got me thinking as it is not the first time I have been forced to make a style change because there is a new tweak that can be turned - yet ignore everything else. Further, this is something I would expect to be extremely boring to someone wanting to make functional improvements, rather than just "sweeping the floor". So thanks you for your clear responses! Discussion closed. Best wishes for 2020!
The most important part of PEP 8 is this:
https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgo...
Going through the entire stdlib creating bug reports for style issues is not a productive use of anyone's time. There are large numbers of open bug reports and documentation issues that are far more important.
Regarding strings, PEP 8 doesn't recommend either single quotes or double quotes for the std lib, except that doc strings should use triple double-quotes. Each project or even each module is free to choose its own rules.
participants (3)
-
Michael -
Paul Moore -
Steven D'Aprano