If the character limit didn't remain relevant, we'd remove it,
My suggestion is to just bump it up a bit (perhaps to 100 chars). Docstrings and code for method definitions in Python typically start at two tabs deep. That means that most of the body of a program is in a somewhat narrow band. This most troublesome with string literals embedded in the code and with trailing comments. IMO, if a string literal is less than 80 chars, then cutting it midstring is an anti-pattern. Breaking the literals is awkward and uncomfortable. This seems to come-up often with error messages which seem to usually be defined several levels deep so that there isn't much space left for the message. class X: def Y(self): 'Comment' for something in Z: if somecondition: raise Exception(some_message % somevalue) Another problematic area is with unittests: class TestX(unittest.testcase): def test_z(self): self.assertRaises(TypeError, real_code_starts_here) Both of those situations seem to lead to awkward line wrapping right in the middle of a literal or expression. It both cases, the literal or expression of interest starts without a whole lot of room left. Sometimes we're able to fit it in gracefully, sometimes not.
people do print out code onto paper
My experience with printing code is that vertical space is the main challenge. The unittest module for example takes at least 25 pages depending on how much you're willing to give-up margins and large type.
Some people find their productivity is enhanced with an 80 character limit.
Perhaps this is true, though I've not heard one jot of evidence to support it and certainly no evidence focusing on Python coding practices which are affected by the use of whitespace for control flow. Nor have I seen evidence of comparative productivity of 80 char limits versus 100 char limits. All we have is anecdotal evidence and personal tastes. What I have seen is a company where all of the Python programmers routinely moved into the 100 character range when necessary and it worked out fine. Also, I've seen plenty of code be made "pep-8 compliant" and not look any better for the effort. Raymond