Re: [Python-ideas] PEP 8 update on line length
I think the solution is for everyone to rotate their widescreen monitors 90° into a really tall portrait mode. :) On Thu, Feb 21, 2019, 11:44 AM Mike Miller wrote: > > On 2/18/19 8:37 PM, Simon wrote: > > I'd like to propose an update to PEP8. Indeed, the 80 characters per > line > > guideline is, I feel, outdated. > > Hi, I don't agree it is outdated. As someone who has a second 4k monitor > in > portrait mode to minimize scrolling (recommended), the ~80 char line limit > avoids the need for horizontal scrolling as well. This isn't your > father's > Oldsmobile, haha. > > When in landscape on the go I can have two windows open side by side, say > an > editor and documentation/mail at the same time, aka multitasking. Not as > good > as a second monitor, but better than nothing. > > Other folks have chimed in on how newspapers and magazines limit line > length for > readability purposes. > > I suppose if you code fullscreen (or near it) on a 16:9 monitor, longer > lines > might be desirable. Worked at a place where a co-worker frequently > produced > code with ~200 character lines despite calls to cease and desist. Looked > over > once, and sure enough a full+widescreen editor. Nostalgic for DOS, or > focused > like a laser? Not sure. > > The issue is unfortunately exacerbated by the monitor industry forcing us > all to > 16:9 aspect ratios, outside of the MacBook and tablets. That was a > regression > in my opinion. > > -Mike > ___ > 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] PEP 8 update on line length
Opinion first - I don't see a need to change PEP 8. I recommend 100 char width for Python, which is acceptable under PEP 8 anyway. I think the real limit should be around 70 characters per line, not including leading white-space, but I realize that's impractical. I work mostly at 100 character line width, and the question of line width came up for me recently. Otherwise, I follow PEP 8. I want to see where, and why I exceed 79 chars, so I dove into a decently sized module file of mine and tallied the results. This is what I found. 563 total lines 448 non-blank lines For the non-blank lines: 49.6 characters per line on average 36.7 non-leading-whitespace characters per line 13.1 leading spaces per line on average 15.5% of lines exceeded 79 chars. The 69 lines that exceeded 79 characters fell into the following categories, listed according to how annoying they would be to fix. 1 - with statements I have a with statement that contains two context managers "with open(blah) as b, open(foo) as f:". There isn't a really good way to wrap this without adding another with statement or a backslash. 3 - function calls Function calls, even with the arguments put one per line, often exceed 80 (and sometimes 100) character limit. The issue tends to be a combination of tabbing, kwarg names, and the context in which all of this is used. It's often unavoidable. variable = some_class.method(argument=value, argument2=value) 5 - Overly deep logic There were a couple of blocks of code that should have been pushed into separate methods/functions. I do occasionally run into issues where there simply isn't room (in 79 chars) for the logic required, and that logic can't reasonably be separated out. 8 - Format calls While I love the new format syntax, I almost always end up moving the format call to a new line with 4 spaces of extra indentation. These were instances of when I didn't. 21 - Comments There's plenty of space for readable comments in most cases. Under several nested scopes, however, the space gets pretty tight. Those extra 20 chars go a long way. 12 - Strings Like comments, having a few extra chars for strings (mostly exception messages in this case) goes a long way when even moderately nested. 2 - Chained conditionals if A and B and C Should have been: if (A and B and C): 16 - Doc strings These are easily fixable with no change in readability, and rarely have issues with padding. On Wed, Feb 20, 2019 at 12:57 PM Chris Angelico wrote: > On Thu, Feb 21, 2019 at 6:48 AM Jonathan Fine wrote: > > Here's a suggestion, at least for people projects that use black.py > > (such as Samuel's). It is to use black.py with a line-length of say 80 > > characters for code that is saved in version control. And when editing > > code, use whatever line-length that happens to suit the tools you are > > using. > > > > Indeed, like a word-processor, one could use black.py to 'line-wrap' > > the Python code to what is the current width of the editor window. > > From my experience (granted, I work heavily with students, so maybe > it's different if everyone involved in the project has 5+ or 10+ years > coding), autoformatters are a blight. They take a simple, easy-to-find > missed parenthesis, and completely obscure it by reindenting the code > until it finds something unrelated that seems to close it. The > indentation in the code of even a novice programmer is valuable > information about *programmer intent*, and throwing that away > automatically as part of checking in code (or, worse, every time you > save the file) is a bad idea. Easy bugs become hard. > > Of course, if you assume that everything in your code is perfect, then > by all means, reformat it however you like. If you're 100% confident > that nobody writes any buggy code, then the formatting doesn't matter, > and you can display it in whichever way looks prettiest. But if you > appreciate ways of discovering bugs more easily, preserve everything > that represents the programmer's intention. > > ChrisA > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Paul Ferrell pfl...@gmail.com ___ 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] Multi-line string indentation
I particularly like the str.dedent() idea. Adding yet another string
prefix adds more complexity to the language, which I'm generally not
in favor of.
On 2/7/19, Mike Miller wrote:
> Was: "Dart (Swift) like multi line strings indentation"
>
> This discussion petered-out but I liked the idea, as it alleviates something
>
> occasionally annoying.
>
> Am supportive of the d'' prefix, perhaps the capital prefixes can be
> deprecated
> to avoid issues? If not, a sometimes-optimized (or C-accelerated)
> str.dedent()
> is acceptable too.
>
> Anyone still interested in this?
>
> -Mike
>
>
>
> On 3/31/18 5:43 PM, Steven D'Aprano wrote:
>> The ideal solution would:
>>
>> - require only a single pair of starting/ending string delimiters;
>>
>> - allow string literals to be indented to the current block, for
>>the visual look and to make it more convenient with editors
>>which automatically indent;
>>
>> - evaluate without the indents;
>>
>> - with no runtime cost.
>>
>>
>> One solution is to add yet another string prefix, let's say d for
>> dedent, but as Terry and others point out, that leads to a combinational
>> explosion with f-strings and r-strings already existing.
>>
>> Another possibility is to make dedent a string method:
>>
>> def spam():
>> text = """\
>> some text
>> another line
>> and a third
>> """.dedent()
>> print(text)
>>
>> and avoid the import of textwrap. However, that also imposes a runtime
>> cost, which could be expensive if you are careless:
>>
>> for x in seq:
>> for y in another_seq:
>>process("""/
>>some large indented string
>>""".dedent()
>>)
>>
>> (Note: the same applies to using textwrap.dedent.)
>>
>> But we could avoid that runtime cost if the keyhole optimizer performed
>> the dedent at compile time:
>>
>> triple-quoted string literal
>> .dedent()
>>
>> could be optimized at compile-time, like other constant-folding.
>>
>> Out of all the options, including the status quo, the one I dislike the
>> least is the last one:
>>
>> - make dedent a string method;
>>
>> - recommend (but don't require) that implementations perform the
>>dedent of string literals at compile time;
>>
>>(failure to do so is a quality of implementation issue, not a bug)
>>
>> - textwrap.dedent then becomes a thin wrapper around the string method.
>
>
>
> On 4/1/18 4:41 AM, Michel Desmoulin wrote:>
> > A "d" prefix to do textwrap.dedent is something I wished for a long
> time.
> >
> > It's like the "f" one: we already can do it, be hell is it convenient to
> > have a shortcut.
> >
> > This is especially if, like me, you take a lot of care in the error
> > messages you give to the user. I write a LOT of them, very long, very
> > descriptive, and I have to either import textwrap or play the
> > concatenation game.
> >
> > Having a str.dedent() method would be nice, but the d prefix has the
> > huge advantage to be able to dedent on parsing, and hence be more
> > performant.
> >
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Paul Ferrell
pfl...@gmail.com
___
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] Potential PEP: with/except
I completely understand your perspective, and agree with most of it. It doesn't add new expressiveness, it adds a bit of polish (and I think completeness) to the relatively new concept of 'with' statements. Is this so intuitive that we don't actually have to teach it? Is it such a natural extension to 'with', that it would immediately be weird to find it missing in the future? If the answer to either of those questions is 'no', then I absolutely retract my idea. On Tue, Jan 22, 2019 at 3:22 PM Steven D'Aprano wrote: > On Tue, Jan 22, 2019 at 01:11:10PM -0700, Paul Ferrell wrote: > > [...] > > I would like to propose that the syntax for 'with' blocks > > be changed such that they can be accompanied by 'except', 'finally', > > and/or 'else' blocks as per a standard 'try' block. > > What benefit does this give apart from saving one line and one indent? > If either is in short supply, the code probably needs refactoring, not > new syntax. > > The beauty of the current syntax is that try...except and with blocks > are fully independent, composable blocks which can be learned and > reasoned about seperately. You're proposing to add a new special-case > syntax: > > while ... > except ... > > that adds a new block structure that has to be implemented, documented, > tested, maintained, taught and learned. It will inevitably lead to > questions on mailing lists, IRC and Stackoverflow asking what is the > difference between a separate try...with...except and a with...except, > and when to choose one or the other. > > And of course then there will be the inevitable requests that we > generalise it to other blocks: > > for ... > except ... > > while ... > except ... > > If this will allow us to write more expressive code, or do things we > couldn't easily do before, then it might be worthwhile to add this > additional complexity. > > But if all it does is save one line and one indent, then I believe it is > redundant and I would be against it. > > > -- > Steve > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Paul Ferrell pfl...@gmail.com ___ 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] Potential PEP: with/except
That is definitely an ambiguity worth considering (whether __enter__ is
within the implied 'try').
Anecdotally, I showed the with/except example to my student (who's
relatively new to python), to see how he interpreted it. He (correctly?)
assumed the CM operations were within the 'try', and was pretty surprised
when I told him that the except part of the with wasn't actually valid
Python.
On Tue, Jan 22, 2019 at 2:30 PM Chris Angelico wrote:
> On Wed, Jan 23, 2019 at 7:11 AM Paul Ferrell wrote:
> > As a result, I would like to propose that the syntax for 'with' blocks
> > be changed such that they can be accompanied by 'except', 'finally',
> > and/or 'else' blocks as per a standard 'try' block. These would handle
> > exceptions that occur in the 'with' block, including the execution of
> > the applicable __enter__ and __exit__ methods.
> >
> > Example:
> >
> > try:
> > with open(path) as myfile:
> > ... # Do stuff with file
> > except (OSError, IOError) as err:
> > logger.error("Failed to read/open file {}: {}".format(path, err)
> >
> > The above would turn into simply:
> >
> > with open(path) as myfile:
> > ... # Do stuff with file
> > except (OSError, IOError) as err:
> > logger.error(...)
>
> Edge case: The "try/with/except" structure includes the entire 'with'
> header inside the try block, including the call to open(). But if the
> with block itself is handling the exceptions, the expression
> "open(path)" is actually evaluated before the exception handling gets
> going. So adding an except clause is NOT the same as just adding
> another context manager to the stack.
>
> I'm -0.25 on it, as I don't think overlaying in this way improves
> clarity. The current syntax makes it very obvious that the
> "open(path)" call is inside the try/except, but the proposed syntax
> isn't so clear (and as many people will expect it to be inside as
> outside).
>
> ChrisA
> _______
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Paul Ferrell
pfl...@gmail.com
___
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] Fwd: Potential PEP: with/except
>
> The thing that concerns me is that any such problem and solution seems
> to apply equally to any other kind of block. Why not allow excepts on fo
> loops, for example?
>
Very good point.
I think 'with' is special in that it typically contains the entirety of the
use of an object, and the type of objects one tends to use in a 'with' are
prone to throwing exceptions. Other statements like it don't intrinsically
encapsulate the usage of an object.
On Tue, Jan 22, 2019 at 1:23 PM Calvin Spealman wrote:
>
>
> On Tue, Jan 22, 2019 at 3:11 PM Paul Ferrell wrote:
>
>> I've found that almost any time I'm writing a 'with' block, it's doing
>> something that could throw an exception. As a result, each of those
>> 'with' blocks needs to be nested within a 'try' block. Due to the
>> nature of 'with', it is rarely (if ever) the case that the try block
>> contains anything other than the with block itself.
>>
>> As a result, I would like to propose that the syntax for 'with' blocks
>> be changed such that they can be accompanied by 'except', 'finally',
>> and/or 'else' blocks as per a standard 'try' block. These would handle
>> exceptions that occur in the 'with' block, including the execution of
>> the applicable __enter__ and __exit__ methods.
>>
>> Example:
>>
>> try:
>> with open(path) as myfile:
>> ... # Do stuff with file
>> except (OSError, IOError) as err:
>> logger.error("Failed to read/open file {}: {}".format(path, err)
>>
>> The above would turn into simply:
>>
>> with open(path) as myfile:
>> ... # Do stuff with file
>> except (OSError, IOError) as err:
>> logger.error(...)
>>
>>
> It definitely makes sense, both the problem and the proposed solution.
>
> The thing that concerns me is that any such problem and solution seems
> to apply equally to any other kind of block. Why not allow excepts on fo
> loops, for example?
>
>
>>
>> I think this is rather straightforward in meaning and easy to read,
>> and simplifies some unnecessary nesting. I see this as the natural
>> evolution of what 'with'
>> is all about - replacing necessary try-finally blocks with something
>> more elegant. We just didn't include the 'except' portion.
>>
>> I'm a bit hesitant to put this out there. I'm not worried about it
>> getting shot down - that's kind of the point here. I'm just pretty
>> strongly against to unnecessary syntactical additions to the language.
>> This though, I think I can except. It introduces no new concepts and
>> requires no special knowledge to use. There's no question about what
>> is going on when you read it.
>>
>> --
>> Paul Ferrell
>> pfl...@gmail.com
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
>
> CALVIN SPEALMAN
>
> SENIOR QUALITY ENGINEER
>
> cspea...@redhat.com M: +1.336.210.5107
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>
--
Paul Ferrell
pfl...@gmail.com
--
Paul Ferrell
pfl...@gmail.com
___
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] Potential PEP: with/except
I've found that almost any time I'm writing a 'with' block, it's doing
something that could throw an exception. As a result, each of those
'with' blocks needs to be nested within a 'try' block. Due to the
nature of 'with', it is rarely (if ever) the case that the try block
contains anything other than the with block itself.
As a result, I would like to propose that the syntax for 'with' blocks
be changed such that they can be accompanied by 'except', 'finally',
and/or 'else' blocks as per a standard 'try' block. These would handle
exceptions that occur in the 'with' block, including the execution of
the applicable __enter__ and __exit__ methods.
Example:
try:
with open(path) as myfile:
... # Do stuff with file
except (OSError, IOError) as err:
logger.error("Failed to read/open file {}: {}".format(path, err)
The above would turn into simply:
with open(path) as myfile:
... # Do stuff with file
except (OSError, IOError) as err:
logger.error(...)
I think this is rather straightforward in meaning and easy to read,
and simplifies some unnecessary nesting. I see this as the natural
evolution of what 'with'
is all about - replacing necessary try-finally blocks with something
more elegant. We just didn't include the 'except' portion.
I'm a bit hesitant to put this out there. I'm not worried about it
getting shot down - that's kind of the point here. I'm just pretty
strongly against to unnecessary syntactical additions to the language.
This though, I think I can except. It introduces no new concepts and
requires no special knowledge to use. There's no question about what
is going on when you read it.
--
Paul Ferrell
pfl...@gmail.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
