[Python-Dev] 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.

[Michael]

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

[Paul Moore]

On Thu, 9 Jan 2020 at 10:42, Michael <aixt...@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
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/7C6YD4X3YEEMOAOVPAFF7R2UUZ2G6GOV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Steven D'Aprano]

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-hobgoblin-of-little-minds

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

_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/RILHWKTNWSV552LPHO4VHB35ZY5ZXCKH/

[Michael]

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 automagically. 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!