PEP 8 and long string literals
I've started this thread, because I think long string literals are somewhat special, and may have an easy resolution. According to PEP 8 a good reason to ignore the line-length (or any other) guideline is that "applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP." PEP 8 also says "Limit all lines to a maximum of 79 characters." So perhaps it is enough, for long string literals, to add a note to PEP 8: When sensible to do so, lines containing a long string literal can exceed this length. It might also help to add to PEP 8 some Programming Recommendations for Long String Literals. (PEP 8 already has recommendations for Function and Variable Annotations.) Finally, tools such as pep8 and pylint would need some changes, to treat differently lines that contain a long string constant. -- Jonathan
I think long URL in comment or docstring is good reason to ignore line length limit. But I'm not sure about general long string literals. -- INADA Naoki <songofacandy@gmail.com>
On Mon, Feb 25, 2019 at 10:05 AM INADA Naoki <songofacandy@gmail.com> wrote:
I think long URL in comment or docstring is good reason to ignore line length limit.
A very good point. We can't banish long URLs from the Internet, because they violate PEP 8.
But I'm not sure about general long string literals.
I hope programmers would be sensible in their use of long string literals (as with their choice of variable names). However, I don't think this can be reliable machine checked, with the tools we presently have. Machines find it hard to determine programmer intent, except via a formal language. -- Jonathan
I generally break them up and then use "".join() as that is "most readable" IMHO. The same is true for SQL queries. On 2/25/19, Jonathan Fine <jfine2358@gmail.com> wrote:
On Mon, Feb 25, 2019 at 10:05 AM INADA Naoki <songofacandy@gmail.com> wrote:
I think long URL in comment or docstring is good reason to ignore line length limit.
A very good point. We can't banish long URLs from the Internet, because they violate PEP 8.
But I'm not sure about general long string literals.
I hope programmers would be sensible in their use of long string literals (as with their choice of variable names). However, I don't think this can be reliable machine checked, with the tools we presently have. Machines find it hard to determine programmer intent, except via a formal language.
-- Jonathan _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- With the simplicity of true nature, there shall be no desire. Without desire, one's original nature will be at peace. And the world will naturally be in accord with the right Way. Tao Te Ching
On Mon, Feb 25, 2019 at 2:05 AM INADA Naoki <songofacandy@gmail.com> wrote:
I think long URL in comment or docstring is good reason to ignore line length limit.
Yep, that's what we do in the yapf autoformatter. There's good reason too, source viewers and editors linkify URLs, if you break them across strings to fit within a line length limit, you get a broken partial url. It also makes searching a codebase for references to specific identifiers much more difficult if you've broken up their value at arbitrary points. There are other examples for this such as allowing trailing line comments for pylint, type checkers, etc. to go beyond 80 columns. See the Exceptions in https://google.github.io/styleguide/pyguide.html#32-line-length for what make good practical examples. I'm not convinced that codifying this in PEP-8 makes sense though unless we see this happening within the Python standard library code itself (the purpose of pep-8). PEP-8 is not trying to be a style guide for all Python users, just a stdlib style guide that happens to serve a base from which to build upon. -gps
I find the main pain point of line width limits to be string literals that call out to some *other* code-like thing. Long URLs, user messages, and long SQL are three common examples. It's actually less an issue with SQL since that is itself more readable across multiple lines, plus SQL itself doesn't care about newlines embedded. So just using triple-quoted strings works best there. However, sometimes it's just a quick one-liner SQL I want to include, but that can easily grow longer than 80 characters (or really even 50 chars if the SQL is being assigned to something inside some nested logic, or being an argument to a function call). URLs can get long, and are whitespace sensitive. I wrote something like this just today: url = (f'{URL_BASE}' f'&arg1={row["column_name_1"]}' f'&something_else={1+row["that value"]}' f'&more_args={USER_ID}' f'&some_other_stuff={translate[row["foo"]]}' f'&yep_this={row["foo"]}' f'&arg17=123456') I don't think that's terrible, and it's a lot nicer to be able to visually separate what are really arguments to a REST call. But it's definitely super-easy to mess up this sort of thing, including by letting a little whitespace sneak in where I don't want it. But if the URL wasn't quite so convoluted (this example is pretty directly taken from a real thing today, just a few names munged to protect the client :-)), I might want it on one line. And I'd probably want my linters to stop nagging me about the fact I do that. However, what I care about more than that is my editor. It would be really nice if my editor provided something like "vertical folding" for things like this. I do not know of any editors that do that, but it would be easy to imagine. E.g. I might have an editor display: url = f'{URL_BASE}&arg1={row["column_*(..93 chars..)*rg17=123456' Does anyone know of editors that do that sort of thing? Obviously, you'd need some way to fold/unfold the hidden text. But for many purposes, the first and last few characters probably convey the purpose of the line. On Mon, Feb 25, 2019 at 4:53 AM Jonathan Fine <jfine2358@gmail.com> wrote:
I've started this thread, because I think long string literals are somewhat special, and may have an easy resolution.
According to PEP 8 a good reason to ignore the line-length (or any other) guideline is that "applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP."
PEP 8 also says "Limit all lines to a maximum of 79 characters."
So perhaps it is enough, for long string literals, to add a note to PEP 8: When sensible to do so, lines containing a long string literal can exceed this length.
It might also help to add to PEP 8 some Programming Recommendations for Long String Literals. (PEP 8 already has recommendations for Function and Variable Annotations.)
Finally, tools such as pep8 and pylint would need some changes, to treat differently lines that contain a long string constant.
-- Jonathan _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
Hi David Thank you for sharing your experience. I'd be most grateful if you could tell us, are you happy with the interpretation and additions I've suggested for PEP 8? And the revisions to pep8 and other linting tools? Jonathan
I've sort of lost the threads about who recommends what. I do not think that PEP8 needs to include a sentence like "Better tooling would be really cool" ... notwithstanding that I think that is a true sentence. On Mon, Feb 25, 2019 at 2:50 PM Jonathan Fine <jfine2358@gmail.com> wrote:
Hi David
Thank you for sharing your experience.
I'd be most grateful if you could tell us, are you happy with the interpretation and additions I've suggested for PEP 8?
And the revisions to pep8 and other linting tools?
Jonathan
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
David Mertz writes:
However, what I care about more than that is my editor. It would be really nice if my editor provided something like "vertical folding" for things like this. I do not know of any editors that do that, but it would be easy to imagine. E.g. I might have an editor display:
url = f'{URL_BASE}&arg1={row["column_*(..93 chars..)*rg17=123456'
Does anyone know of editors that do that sort of thing? Obviously, you'd need some way to fold/unfold the hidden text. But for many purposes, the first and last few characters probably convey the purpose of the line.
You may not like my answer: Emacs does several kinds of hiding text. They're not exactly what you ask for, of course, but the tools are definitely there. The only automatic hiding features I use are truncate-lines mode, which as you might guess hides the tail of the line by default, but also scrolls only that line if point moves into the hidden tail (as many browsers do in their address bars), and outline mode, which has a couple of ways to tweak display (hide non-heading text, hide subheadings, do either locally or globally). I don't know who maintains python-mode, but they might be interested in your suggestion if you're interested in an Emacs feature. Whoever maintains python-mode is exceptionally open to wacky (ie, contra GNUish orthodoxy) ideas, I must say. It's the only mode I use where RET is bound to newline-and-indent instead of newline, for example. -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
If you use Atom (http://atom.io), you can use the default functionality called Wrap Guide. The wrap guide is fully configurable to your needs on different line lengths (https://github.com/atom/wrap-guide). The example on the doc shows 4 wrap guides: 'wrap-guide': 'columns': [72, 80, 100, 120] On Tue, Feb 26, 2019 at 4:32 AM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
David Mertz writes:
However, what I care about more than that is my editor. It would be really nice if my editor provided something like "vertical folding" for things like this. I do not know of any editors that do that, but it would be easy to imagine. E.g. I might have an editor display:
url = f'{URL_BASE}&arg1={row["column_*(..93 chars..)*rg17=123456'
Does anyone know of editors that do that sort of thing? Obviously, you'd need some way to fold/unfold the hidden text. But for many purposes, the first and last few characters probably convey the purpose of the line.
You may not like my answer: Emacs does several kinds of hiding text. They're not exactly what you ask for, of course, but the tools are definitely there.
The only automatic hiding features I use are truncate-lines mode, which as you might guess hides the tail of the line by default, but also scrolls only that line if point moves into the hidden tail (as many browsers do in their address bars), and outline mode, which has a couple of ways to tweak display (hide non-heading text, hide subheadings, do either locally or globally). I don't know who maintains python-mode, but they might be interested in your suggestion if you're interested in an Emacs feature.
Whoever maintains python-mode is exceptionally open to wacky (ie, contra GNUish orthodoxy) ideas, I must say. It's the only mode I use where RET is bound to newline-and-indent instead of newline, for example.
-- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Vinicius Mesel CEO e Fundador do PyJobs http://www.pyjobs.com.br
participants (7)
-
David B -
David Mertz -
Gregory P. Smith -
INADA Naoki -
Jonathan Fine -
Stephen J. Turnbull -
Vinicius Mesel