Re: [Python-ideas] PEP 8 and long string literals

[Stephen J. Turnbull]

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: turnb...@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/

Re: [Python-ideas] PEP 8 update on line length

[Abdur-Rahmaan Janhangeer]

i thought it interesting as it presented a non py's view of things (web
dev) for the 80 chars length.

Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 8 update on line length

[Christopher Barker]

> saw that today
>
> 80 Characters per Line Is a Standard Worth Sticking to Even Today
> https://dev.to/nickjj/80-characters-per-line-is-a-standard-worth-sticking-to-even-today-26kk
>

Same arguments made in this thread. I noticed that most of the comments
were from folks disagreeing:-)

Anyway, the only point to have UNH this discussion on this list is to
suggest changes to PEP8.

And clearly there is no consensus to increase the line length in the Style
guide.

So I would like to propose the softening of the language a bit as I
proposed earlier in this thread, and other than that call it done.

Here’s what I wrote:

We could reword:

"""
Some teams strongly prefer a longer line length. For code maintained
exclusively or primarily by a team that can reach agreement on this issue,
it is okay to increase the nominal line length from 80 to 100 characters
(effectively increasing the maximum length to 99 characters), provided that
comments and docstrings are still wrapped at 72 characters.
"""

To be a bit less harsh -- that is, change the clause:

"For code maintained exclusively or primarily by a team that can reach
agreement on this issue, it is okay ..."

To maybe just

"For code maintained  by a team that can reach agreement on this issue, it
is okay ..."


-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 8 and long string literals

[David Mertz]

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  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.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 8 and long string literals

[Gregory P. Smith]

On Mon, Feb 25, 2019 at 2:05 AM INADA Naoki  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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 8 and long string literals

[Jonathan Fine]

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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 8 and long string literals

[David Mertz]

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  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.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 8 and long string literals

[David B]

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  wrote:
> On Mon, Feb 25, 2019 at 10:05 AM INADA Naoki 
> 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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions

[Kyle Lahnakoski]

On 2019-02-22 17:20, Chris Angelico wrote:
> On Sat, Feb 23, 2019 at 9:14 AM Kyle Lahnakoski  
> wrote:
>> Can Python provide better support for the CNCR pattern? If it is
>> lightweight enough, maybe people will use it, and then we can say
>> something useful about the (restricted) range of exceptions coming from
>> a method:
> The CNCR pattern, if used repeatedly, will quickly create a long chain
> of exceptions, where each exception represents one function call.
> Python already has very good support for seeing the function call
> history that led to the exception - it's called a traceback. You even
> get the full function locals as part of the exception object... and it
> requires no code whatsoever! Simply allowing exceptions to bubble up
> will have practically the same benefit.

I like your point that the exception chain is long, and similar to the
stack: I do find that in practice. This may indicate there is an
optimization in how CNCR can be handled:  Maybe instantiation of CNCR
exceptions can be deferred to the point where an exception handler
actually does something beyond CNCR, if ever.

I also agree, with a debugger at hand, we can inspect the stack trace.
We can also write code that reflects on the method names in the stack
trace to figure out how to handle an exception. But, I am concerned that
stack trace inspection is brittle because methods can be renamed and
refactored.  Also, the CNCR pattern is not 1-1 with methods, there can
be more than one type of CNCR exception emitted from a method.  Methods
could be split, so each only throws one type of exception; and then the
stack trace would suffice; but that brings us back to brittle: A split
method may be accidentally merged for clarity at a later time.

We should also consider what happens in the case that an exception chain
is not handled: It may be printed to the log: We can not reasonably
print all the locals; there are many, some do not serialize, and some
are sensitive.  CNCR is being explicit about what locals(), if any, are
important.



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 8 update on line length

[Abdur-Rahmaan Janhangeer]

saw that today

80 Characters per Line Is a Standard Worth Sticking to Even Today
https://dev.to/nickjj/80-characters-per-line-is-a-standard-worth-sticking-to-even-today-26kk

Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius

On Tue, 19 Feb 2019, 08:38 Simon,  wrote:

> Hello,
>
> I'd like to propose an update to PEP8. Indeed, the 80 characters per line
> guideline is, I feel, outdated.
>
> I understand the need for it, back when monitors were small, and everyone
> coded on terminals, but nowadays, I feel like that guideline is more of a
> hinderance, and that it promotes poor code.
>
> Indeed, people abiding by this rule tend to choose shorter variable names,
> reduce the amount of indentation, and other tricks to just keep the
> character count under 80. I think a 100 or even 120 suggested characters
> per line count is much more realistic by today's standards. It still allow
> for the code to be completely displayed, even on just half of a screen.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Support localization of unicode descriptions

[Thomas Jollans]

On 10/07/2018 23.20, David Mertz wrote:
> The problem with non-canonical translations of the Unicode character
> names is that there is not one unique possible rendering into language
> X. Equally, I could find synonyms in general English for the names, but
> one would be official, the others at best informally clarifying.

Let's not forget that some official names of unicode symbols are either
misleading or entirely wrong, but cannot be changed.

See e.g. https://www.unicode.org/notes/tn27/tn27-4.html


> For informational purposes I think it's great to have a third party
> project to find out "Unicode character named 'Something In English' is
> roughly translated as  in your native language." But it's hard
> to see how an unofficial loose cross-language dictionary should be party
> of the standard library.
> 
> On Tue, Jul 10, 2018, 5:11 PM Terry Reedy  > wrote:
> 
> On 7/10/2018 4:45 AM, Pander wrote:
> 
> > This is a third party initiative. The translations are contributed by
> > volunteers. I have talked with Python core developers and they
> suggested
> > to post this here, as it is for them out of scope for Python std lib.
> 
> Python-ideas list is for discussion of python and the stdlib library.
> This is not a place for prolonged discussion of pypi projects.
> It *is* a place to discuss adding a hook that can be used to access
> translations.
> 
> There are both official doc translations, accessible from the official
> doc pages, and others that are independent.  The official ones, at
> least, are discussed on the doc-sig list
> https://mail.python.org/mailman/listinfo/doc-sig
> There are currently 7 languages and coordinators listed at
> https://devguide.python.org/experts/#documentation-translations
> 4 have progressed far enough to be listed in the drop-down box on
> https://docs.python.org/3/
> 
> I should think that these people should be asked if they want to be
> involved with unicode description translations.  They should certainly
> have some helpful advice.
> 
> The description vocabulary is rather restricted, so a word translation
> dictionary should be pretty easy.  For at least for some languages, it
> should be possible to generate the 20 description translations from
> this. The main issues are word order and language-dependent 'word'
> units.  Hence, the three English words "LATIN SMALL LETTER" become two
> words in German, 'LATEINISCHER KLEINBUCHSTABE', versus three words in
> Spanish, but in reverse order, 'LETRA PEQUEÑA LATINA'.  It is possible
> that the doc translators already uses translation software that deal
> with these issues.
> 
> -- 
> Terry Jan Reedy
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 8 and long string literals

[Jonathan Fine]

On Mon, Feb 25, 2019 at 10:05 AM INADA Naoki  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/

Re: [Python-ideas] PEP 8 and long string literals

[INADA Naoki]

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  
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] PEP 8 and long string literals

[Jonathan Fine]

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/

Re: [Python-ideas] PEP 8 update on line length

[Stephen J. Turnbull]

Alex Walters writes:

 > There is no way to win in changing the guideline.

IMO this is true, despite the comment below:

 > PEP-8 is not a universal truth, or even a standard, we really
 > shouldn't be treating it like it is.

Unfortunately, it's not us (at least, I don't think it is), and it's
not our choice.  Despite repeated warnings on the lists and even in
the PEP that this is specific to the Python standard library, there
are a lot of projects that choose to use the pep8 and flake8 utilities
to more or less enforce PEP 8 as a standard.

I believe the OP was in that situation, and it usually comes up when
we have these discussions.  They want us to take leadership in
enforcing their standard on the rest of the world.  But I don't see
what's in it for us, given how divided we are on the issue.

-- 
Associate Professor  Division of Policy and Planning Science
http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: turnb...@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/