Especially when a tab isn't 8 spaces worth and you don't have a near useless level of indentation from the start (e.g. Java's "class" scope), I rarely found a problem with 80 (or 78) character limits. Quite the opposite, usually there's something "wrong" with code that exceeds that limit (a "code smell", as the hip kids like to say).
Granted, quite often it's a "language smell", like Java or earlier C++'s verbose initialization forms and class terminology (AbstractFactoryImpl etc.). Other than that, it's often longer formulas or string building exercises, which usually could benefit from some temporary variables or printf-style format languages. If a statemenet has more than one operator and polysyllabic variable names, I generally prefer some variation of "let x be the overlong constant/class/descriptive name", e.g. "int x = DomainBasedStaticConfigurationSingleton.MAXIMUM_FROBNICATION_VALUE", instead of just adding up those monsters themselves. And being German, I'm actually quite used to silly compound nouns.
I don't know; I think it's fairly easy to hit that limit with some constructs like list comprehensions, particularly if they're inside a method (which cuts 12 characters with indention), yet remain readable. Something like:
[person.name for person in people if person.country_of_origin == 'Netherlands' and person.age > 30]
That's well above the limit, yet I still find it more readable than either a for loop that appends to a list or a map/filter (which would also have go through the list twice).
A longer/complicated list comprehension looks pretty similar to a (simple) SQL statement. And in both cases, there's really no reason why you couldn't put it on multiple lines, and they usually offer pretty good places to insert line breaks (e.g. "if" and "and" in your example).
But does it really improve readability? Personally, I don't think it does - in neither case; unless it's really pathological, but then it shouldn't all be forced into a single list comprehension.
Well, it certainly doesn't help readability if parts of a line are cut off or the editor has to do an ugly linewrap, spoiling indentation. So as long as it doesn't significantly decrease readability for those corner cases and the benefits outweigh the drawbacks, I'm all for certain code conventions.
Granted, quite often it's a "language smell", like Java or earlier C++'s verbose initialization forms and class terminology (AbstractFactoryImpl etc.). Other than that, it's often longer formulas or string building exercises, which usually could benefit from some temporary variables or printf-style format languages. If a statemenet has more than one operator and polysyllabic variable names, I generally prefer some variation of "let x be the overlong constant/class/descriptive name", e.g. "int x = DomainBasedStaticConfigurationSingleton.MAXIMUM_FROBNICATION_VALUE", instead of just adding up those monsters themselves. And being German, I'm actually quite used to silly compound nouns.