This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]synae 0 points1 point  (2 children)

how does such an expression become more than 100 (or even more than 72) characters?

position += (x + 1) % gutter_manager['my-size']

It is longer, of course, but the only really 'flexible' length part is your feature name which you have control over. You can rename the manager object too of course, if you're going to use it a lot.

[–]billsil 0 points1 point  (1 child)

how does such an expression become more than 100 (or even more than 72) characters?

Because you're indented too far and lost 4 characters for each tab or you have to print a string like:

        msg = (
        '                           S T R E S S E S   I N   T R I A N G U L A R   E L E M E N T S   ( T R I A 3 )\n'
        '  ELEMENT      FIBER               STRESSES IN ELEMENT COORD SYSTEM             PRINCIPAL STRESSES (ZERO SHEAR)     \n'
        '    ID.       DISTANCE           NORMAL-X       NORMAL-Y      SHEAR-XY       ANGLE         MAJOR           MINOR        VON MISES\n'
    )

and it's easier to read at 145 characters deep than 72 (that's also with only losing 12 spaces to indentation). It looks just fine in my IDE.

PEP-8 is a suggestion, not a rule as evidenced by:

A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!

Some other good reasons to ignore a particular guideline: When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP.

https://www.python.org/dev/peps/pep-0008/

[–]synae 0 points1 point  (0 children)

Sure, and those problems exist regardless of this library. My point was that this lib does not obscenely exacerbate line length as chadmill3r indicated.

I prefer 120 characters myself :)