Guido's Python

May 12, 2010 1:14 PM

Guido's Python: Introduction is part of a series by Yaniv Aknin which seeks to look at the programming language through the eyes of Guido van Rossum, author of the language (and mentioned previously).

This introductory article looks at the internals of CPython, specifically what happens when it is compiled to bytecode.

posted by Deathalicious (67 comments total)

import this
posted by Mach5 at 1:23 PM on May 12, 2010

But how do you keep the fake tanning goop off the keyboard?
posted by anti social order at 1:27 PM on May 12, 2010 [3 favorites]

Guido is about as far from a guido as is possible.
posted by GuyZero at 1:39 PM on May 12, 2010

I still experience "scripted vs. compiled" language discrimination. I have no charitable explanation as to why. For the vast majority of the work I touch, execution speed is far less critical than, you know, making working code where I do not have to chase down bugs based on freakin' pointers and worry about buffers. And that bytecode is simple and readable. BINARY_SUBTRACT, huh, guess what that does.

As someone who fled classic ASP and VBScript for Perl, and then ran away from Perl when I realized that There's More Than One Way To Do It means A) that gal whose code you're reading -- she will have done things a wholly different way, B) wait six months and you won't know how you did anything, Python had just made things happen for me. I can create elaborate data structures, perfectly suited to my problem, with little mental overhead. I surprise myself when I write three hundred lines of code and it does the job the first time I run it. For the most part, I do not even notice the whitespace.

It's not a perfect language by any means. I had to unlearn functions versus subroutines. I would like a way to force myself to declare variables, ahem, names first. Some of the conventions (eighty characters, really, still?) irritate me. The official online documentation seems more aimed at describing a language specification rather than teaching one how to use it. Common problem domains (images, databases, CGI sessions, for example) are left outside of the standard library and remain ruled by strange downloads and competing frameworks. I am still working out some namespace issues and, looking at some of the coding examples I see, everyone else is, too. I want constants, not workarounds that behave mostly like constants ... mostly.

Before classic ASP I had a dozen flavors of BASIC, a little Rexx, and some assembler. A little C, a little C++ — totally unused. One day I suspect I will move on from Python, as well. Programmers are tramps, trudging from one bad situation to a new town, before that inevitably sours. I hope to stick around a while.
posted by adipocere at 1:52 PM on May 12, 2010 [2 favorites]

Oh yeah. Loves me some Python, thanks for the links!
posted by JHarris at 1:55 PM on May 12, 2010

    i still fear
        whitespace
posted by jenkinsEar at 2:06 PM on May 12, 2010 [2 favorites]

hey, it's better than make. tabs OR spaces!
posted by GuyZero at 2:10 PM on May 12, 2010 [2 favorites]

Guido on tabs or spaces:
"Definitely spaces. Four to be precise (even though the Google style guide uses two)."
posted by needled at 2:35 PM on May 12, 2010

Four spaces with an 80 character line limit in python... madness. Obviously those are both just guidelines, though -- no reason to limit to 80 chars within a particular group/project/company. I could see 4/80 with something like C or C++, but for something with as many indents as Python it seems crazy.
posted by wildcrdj at 3:16 PM on May 12, 2010

Yeah, we settled on 120 column with for my work project. Although honestly, a lot of the time when you get that deeply nested that it won't fit on 80, it's time to think about refactoring IMO.

I still experience "scripted vs. compiled" language discrimination.

This is going away thanks to fast, cheap hardware, but you are still going to run into "strong vs. dynamic" type arguments, which are closely linked. Declaring and typing variables allows a compiler to catch common mistakes that you only see at runtime with a dynamic language like Python. These can be very hard to track down since they might manifest as unexpected behavior rather than an outright error. Still, I think the trade-off is worth it, but the pro-strong-type camp do have a point there I must concede.

    i still fear
        whitespace

So with other languages, you don't bother to indent your code? That must be horrendous to work with.
posted by cj_ at 3:27 PM on May 12, 2010

wildcrdj: "I could see 4/80 with something like C or C++, but for something with as many indents as Python it seems crazy."

The idea is that if you are indenting that much you need to refactor into smaller more modular code.
posted by idiopath at 3:27 PM on May 12, 2010

cj_: "Declaring and typing variables allows a compiler to catch common mistakes that you only see at runtime with a dynamic language like Python."

Mind you, languages like Haskell, Ocaml, and even some implementations of common lisp can figure out what types your variables are and give warnings or errors or even optimize based on this without needing type declarations. Ocaml's type inference is powerful enough that it can even catch some classes of code logic error (reporting an infinite loop as a type error because it prevents the function from ever returning its declared type iirc).
posted by idiopath at 3:30 PM on May 12, 2010

(of course this can not be a universal detector for all classes of infinite loop as is taught in cs 101)
posted by idiopath at 3:31 PM on May 12, 2010

The idea is that if you are indenting that much you need to refactor into smaller more modular code.

Yes, but in my experience that's not always true. I would agree that most of the time it's not an issue, but as a hard rule it would be too much for me. Line limits seem silly to me period, if they're supposed to be a proxy for bad code it's better just to not write bad code than to force line breaks (in other words, it's treating a symptom that's not a particularly good sign of any specific problem).
posted by wildcrdj at 3:40 PM on May 12, 2010

wildcrdj: "it's treating a symptom that's not a particularly good sign of any specific problem"

That could easily describe almost every significant difference between python and most other languages: what makes python interesting is that it treats style concerns as explicitly enforced conventions (in a way that many people like).
posted by idiopath at 3:47 PM on May 12, 2010

The idea is that if you are indenting that much you need to refactor into
smaller more modular code.

The 80 character line limit made a lot of sense when most people had displays
that couldn't fit in more than 80 columns and 25 rows. Continuing to advocate
for that standard is obscene in an age when most terminals can support 132 or
more characters per line. Most terminals and editors can also auto-wrap a
long line. Although excessive nesting is a problem, sometimes you just need a
long line and forcing artificial breaks only serves to make code more
cumbersome to read.
posted by o0o0o at 4:09 PM on May 12, 2010 [3 favorites]

It is not a "hard rule". It's not like it won't execute code if it goes over 80 characters. It's just a highly recommended convention. There is plenty of code in the stdlib that breaks the PEP style guide in all sorts of ways, owing to it being mostly contributed by the community.

The reason I used 120 instead of 80 for my own work-related project is that it is a django project, and just one ORM call can break 80 easily. Which has nothing to do with nesting, just general verbosity.
posted by cj_ at 4:15 PM on May 12, 2010

If you need more than 80 columns for anything but a string constant in a sane language you are making a mistake in either naming, encapsulation, or code clarity - if not all 3.
posted by idiopath at 4:17 PM on May 12, 2010 [3 favorites]

Usually for me it's either a string or a string + the array of substitutions (although you can get around that with a map or separate array declaration, it usually looks cleaner to me on one line).

It's more of an issue when you're using tabs and have line continuations, since they'll line up differently for different tabstops. On the other hand, being able to use my own tabstop is nice.
posted by wildcrdj at 4:37 PM on May 12, 2010

If you need more than 80 columns for anything but a string constant in a sane language you are making a mistake in either naming, encapsulation, or code clarity - if not all 3.

This is bollocks, especially so with django framework. The most simple of idioms take up that much space just in parameters, and ORM calls much more, depending on the complexity of the query. Renaming stuff as short as possible, assigning temp variables, etc. just to make it fit in 80 characters does not improve readability and certainly impacts performance. It also might produce unoptimized SQL since you'd be forcing evaluation prematurely.

"A foolish consistency is the hobgoblin of little minds."
posted by cj_ at 4:37 PM on May 12, 2010

Well now that we have established the size of my mind you can feel free to disregard my input.
posted by idiopath at 4:55 PM on May 12, 2010 [3 favorites]

"Definitely spaces. Four to be precise (even though the Google style guide uses two)."

Two spaces here. I nest a lot and dammit I see no reason to change.
posted by JHarris at 5:07 PM on May 12, 2010 [1 favorite]

Descriptive names can be long, it happens. Big whoop. As noted, it's not as if it's part of hte language that 80-column lines are an error (like with INTERCAL not working if you don't say PLEASE often enough, or something).

The official online documentation seems more aimed at describing a language specification rather than teaching one how to use it.

I'm surprised to see this, actually, since I find Python's documentation, both of the language itself and (especially) of the libraries, extremely helpful; practically everything about it I know I learned from the official docs.

ESPECIALLY the libraries. For some reason, it seems to have caught on more in the python world than in (say) the ruby world that documentation for the user of a library is more than just an api reference.
posted by kenko at 6:01 PM on May 12, 2010

I was always told the 80 character limit wasn't about what fits in a window. It's about efficiency. The average length of a line in most languages is something like 35 to 45 characters. A limit of 80 characters per line is supposed to strike a balance between have large amounts of wasted space at the end of each line and having to wrap lines frequently. I see my coworkers with full screened editors and lines scrolling off to the right and I can't help but stare at the huge white spaces between those infrequent long lines.

I like 80 characters because it lets me put 3 terminals with 3 editors side by side in 1600px, if I use the right font. I don't understand how people manage with a single tabbed editor window. Visual Studio and Eclipse are painful.
posted by joegester at 6:16 PM on May 12, 2010 [3 favorites]

You can have multiple edit windows in Visual Studio (and dock them side by side, top/bottom, etc). I'm pretty sure you can in Eclipse too. I work in emacs again these days and of course can do the same there. No reason you need separate terminals to do multiple side by side edit windows (though of course that way works too).
posted by wildcrdj at 6:49 PM on May 12, 2010

If you need more than 80 columns for anything but a string constant in a sane language you are making a mistake in either naming, encapsulation, or code clarity - if not all 3.

This is bollocks, especially so with django framework.

Just because extremely long lines of code are inevitable when working with Django doesn't mean that the extreme length isn't negatively impacting your code's readability. If your library requires you to regularly write ponderously wide lines of code, I'm inclined to agree that someone is making a mistake -- maybe not you in this case, but whoever designed the library.

Of course, I'm not sure that I agree with the convention that 80 characters counts as "extremely long." It doesn't start bothering me until at least 120. Also, I've never used Django, so I'm not really eligible to criticize it on its usability. Suffice it to say that there is certainly a point at which I'll start looking for a new library if the one I'm using is making my code unwieldy.
posted by magnificent frigatebird at 7:03 PM on May 12, 2010 [1 favorite]

Two spaces FTW. It's sufficient to allow you to instantly comprehend the blocks without robbing yourself of columns, and to my eye it's more readable than larger indents, not less. And add me to the list of people who say that a coding framework that forces lines to be consistently more than 80 characters long is not your friend, at least in that respect.

Nobody's saying "never let a line exceed 80 chars" but if it happens constantly and you can't do anything about it, something's not right.

...I find Python's documentation, both of the language itself and (especially) of the libraries, extremely helpful; practically everything about it I know I learned from the official docs.

Agreed. Some languages and libraries (notably almost anything from Microsoft) don't become clear without recipes and code samples, and the best-selling books on them show ways to do things rather than explain the concepts behind them. Python by contrast makes it remarkably clear what you can do with it and how, simply from basic standard references. "How would I actually use that?" is not a question you really need to ask very often.
posted by George_Spiggott at 7:20 PM on May 12, 2010

Wow. That was a lot lower level than I as expecting.


What this reminded me of (perhaps just the gentle poster's initial post) was the Camel book, written by Larry Wall - which is Larry's take on the language. To this day, I can't stop calling... thingies, "thingies", because that's what he calls them in the book. His own code examples look like acrobatics compared to more extremely boring (yet moronically easy to follow) style.
posted by alex_skazat at 8:32 PM on May 12, 2010

Four spaces is just right.
posted by Crabby Appleton at 9:20 PM on May 12, 2010

Tabs. *runs and hides*
posted by !Jim at 9:33 PM on May 12, 2010 [3 favorites]

Tabs! You can make tabs any length you want. Tabs!
posted by wobh at 10:36 PM on May 12, 2010

Tabs for indentation, spaces for alignment. It's the only sane way to do it.
posted by The Pusher Robot at 11:42 PM on May 12, 2010 [1 favorite]

Tabs! You can make tabs any length you want. Tabs!

I don't normally do this, but QFT.
posted by !Jim at 12:15 AM on May 13, 2010

When I found out

if (blah) {
  stuff
}

and

if (blah)
{
  stuff
}

are different in Go (namely, only the former works), I about shit myself.
posted by fleacircus at 1:16 AM on May 13, 2010

On the one hand, bondage and discipline language.

On the other hand, Perl going nowhere fast. And Ruby, while much more likeable than Perl for me, has a bunch of shortcomings of its own. An for a bunch of stuff I touch on a day to day basis (RHEL, Satellite server) Python is thefirst-class language.

That said, having forced myself to start doing Stuff and Things in Python on a more-than-play basis, I'm finding it reasonably pleasant to work with; the cx_Oracle and psychopg DB drivers are good (although, really, nothing touches DBI; it's a pity so many people are so invested in looking down their noses at Perl that we end up with third rate crap like JDBC instead); since a huge amount of what I care about is grabbing stuff from DBs, that's important to me (and the terrible mess that is Scala DB interfaces pretty much put a hold on my efforts to work in Scala and Lift).
posted by rodgerd at 3:00 AM on May 13, 2010

Why not tabs? Because code will look consistent regardless of the editor, and because there are no surprises when deleting some indentation. Also because I started programming on a Commodore 64, where there were no tabs.

The "sane language" comment above doesn't help matters much. I've seen plenty of insane languages. Perl looks like Great Cthulhu's own scripting torture.
posted by JHarris at 3:54 AM on May 13, 2010

(define (best-lang-in-list? seq)
  (cond ((null? seq) #f)
        ((string=? (car seq) "scheme") #t)
        (else (best-lang-in-list? (cdr seq)))))

posted by DU at 4:41 AM on May 13, 2010 [4 favorites]

JHarris, were you using c4python?
posted by wobh at 5:42 AM on May 13, 2010

(where did the 6 go?)
posted by wobh at 5:58 AM on May 13, 2010

Spaces.
posted by Crabby Appleton at 7:42 AM on May 13, 2010 [1 favorite]

On the other hand, Perl going nowhere fast.

(An implementation of) Perl 6 is available and usable. The first major release is expected in June. There's still a lot left to be done, but they're making progress.
posted by The Pusher Robot at 8:45 AM on May 13, 2010

JHarris: "Perl looks like Great Cthulhu's own scripting torture."

Only when used properly and idiomatically in the spirit intended. A madman can write readable code in Perl if he sets his mind to it.
posted by idiopath at 1:08 PM on May 13, 2010 [3 favorites]

(An implementation of) Perl 6 is available and usable. The first major release is expected in June.

For values of "usable" and "major release" which do not, in fact, include implementing the language as specced.
posted by rodgerd at 1:28 PM on May 13, 2010

>>> from __future__ import braces
File "", line 1
SyntaxError: not a chance
>>>
posted by 3.2.3 at 1:47 PM on May 13, 2010

Spaces.

Imagine this scenario. We're both using spaces for indentation as you desire.

Now, I happen to loove indentation so I have it set at 8 spaces. You're all about the narrowness and so you have your indentation set to 4 spaces.

I have written the following awesome code. For visibility I've replaced leading spaces with ‧

if (name == "Deathalicious"):
‧‧‧‧‧‧‧‧print "You are awesome."
‧‧‧‧‧‧‧‧if time_of_day == "Noon":
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧print "Lunch is on me!"
‧‧‧‧‧‧‧‧if time_of_day == "Evening":
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧offer_copious_booze()
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧throw_party()
‧‧‧‧‧‧‧‧give_candybar()
‧‧‧‧‧‧‧‧play_triumphant_music()
‧‧‧‧‧‧‧‧parade()
else:
‧‧‧‧‧‧‧‧print "Whatever"

Pretty neat, huh? Every time, I get candy, music, and a parade.

It just so happens you have written a similar little program for yourself:

if (name == "Crabby Appleton"):
‧‧‧‧print "You are really nifty!"
‧‧‧‧if time_of_day == "Morning":
‧‧‧‧‧‧‧‧if day_of_week == "Monday":
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧print "Take the week off!"
          [snip]
‧‧‧‧‧‧‧‧if day_of_week == "Sunday"
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧print "No chores for you!"
else:
‧‧‧‧print "Whatever"

You read my code and say, Wow. Candy, music, and a parade sounds awesome. I'm totally going to add that as something that happens each time. Here's what the code looks like if you do a straight cut-and-paste from my code to your code:

if (name == "Crabby Appleton"):
‧‧‧‧print "You are really nifty!"
‧‧‧‧if time_of_day == "Morning":
‧‧‧‧‧‧‧‧if day_of_week == "Monday":
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧print "Take the week off!"
          [snip]
‧‧‧‧‧‧‧‧if day_of_week == "Sunday"
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧print "No chores for you!"
‧‧‧‧‧‧‧‧give_candybar()
‧‧‧‧‧‧‧‧play_triumphant_music()
‧‧‧‧‧‧‧‧parade()
else:
‧‧‧‧print "Whatever"

Oh noes! Unless you remove all that extra indentation, you only get the candy, parade, and music in the mornings! That isn't what you wanted at all. Now let's look at what the code looks like if we used tabs (indicated by －⇥):

My code:

if (name == "Deathalicious"):
－⇥print "You are awesome."
－⇥if time_of_day == "Noon":
－⇥－⇥print "Lunch is on me!"
－⇥if time_of_day == "Evening":
－⇥－⇥offer_copious_booze()
－⇥－⇥throw_party()
－⇥give_candybar()
－⇥play_triumphant_music()
－⇥parade()
else:
－⇥print "Whatever"

Your code:

if (name == "Crabby Appleton"):
－⇥print "You are really nifty!"
－⇥if time_of_day == "Morning":
－⇥－⇥if day_of_week == "Monday":
－⇥－⇥－⇥－⇥print "Take the week off!"
－⇥－⇥－⇥[snip]
－⇥－⇥if day_of_week == "Sunday"
－⇥－⇥－⇥－⇥print "No chores for you!"
else:
－⇥print "Whatever"

And here's your code with my code added:

if (name == "Crabby Appleton"):
－⇥print "You are really nifty!"
－⇥if time_of_day == "Morning":
－⇥－⇥if day_of_week == "Monday":
－⇥－⇥－⇥－⇥print "Take the week off!"
－⇥－⇥－⇥[snip]
－⇥－⇥if day_of_week == "Sunday"
－⇥－⇥－⇥－⇥print "No chores for you!"
－⇥give_candybar()
－⇥play_triumphant_music()
－⇥parade()
else:
－⇥print "Whatever"

Yay! That's exactly what you wanted!

Here's the thing. Every "Spaces are better than tabs" argument basically hinges on What happens if my indention amount is different from your indention amount? and the answer is: Nothing. Nothing happens if your indentation amount is different than mine. The only time -- really, the only time that indentation becomes a problem is when you use spaces. The only other exception, which as far as I know won't cause problems with how the code runs, but may make it look weird depending on indentation, is if you use extra tabs to make a line of text line up with a arbitrary position in the line above, as in:

pretty_little_array = [
                       "isn't",
                       "this",
                       "precious"
                      ]

which should always be replaced with

normal_array = [
    "no",
    "it",
    "isn't"
]

posted by Deathalicious at 3:19 PM on May 13, 2010 [3 favorites]

That said, I use spaces in Python because everyone uses spaces in Python. But the argument for spaces basically is, "Spaces are better because your tabs will mess up things because I already use spaces and there are a lot of other jerks like me who are going to use spaces, so you have to accommodate us."

Now that I think of it, it goes one step further. If I use tabs, I can say "I like my tabs to look like 6 spaces" or "I like my tabs to look like 3 spaces" or even "I like my tabs to look like 18 spaces" but the thing is, in order to avoid the problem above you must indent with 4 spaces.

Oh, and let's not forget that tabs were designed for indentation. That's what they are there for.
posted by Deathalicious at 3:27 PM on May 13, 2010

For values of "usable" and "major release" which do not, in fact, include implementing the language as specced.

Granted. I didn't mean to imply that Perl 6 was almost done. It is usable for a lot of day-to-day stuff, though, and you can see some of the features that have been implented so far here. (The sudden drop in passing tests a few months ago was due to a major change in order to support lazy evaulation.)
posted by The Pusher Robot at 4:25 PM on May 13, 2010

The only time -- really, the only time that indentation becomes a problem is when you use spaces.

The problem in your example is not indentation. The problem is the mindless cutting and pasting of code from random other programs (written by random other programmers, even) without even checking to see if it fits or works. Who does that?
posted by DU at 5:21 PM on May 13, 2010

Well, yeah, obviously. Still, I cut and paste in snippets all the time when I find something that does what I want. So I have to go through and manually fix the indentation. Which I wouldn't have to do, if everyone used tabs.
posted by Deathalicious at 5:44 PM on May 13, 2010

In almost anything besides Python, C-x/M-x indent-region will fix that problem. And I generally have to fix the indentation anyway, since I've usually cut from/pasted to the inside of a loop or something.
posted by DU at 6:04 PM on May 13, 2010 [1 favorite]

Every "Spaces are better than tabs" argument basically hinges on "What happens if my indention amount is different from your indention amount?"

I respectfully disagree. I think the best argument for not having tabs in a source file is that tabs are non-printing characters. The semantics of spaces are well-known and supported in every program that handles text. Tabs are treated differently in just about every program that handles text. (And before somebody brings up CRs and LFs, their semantics are also well-known, and supported even at the file system level, in most OSs.)
posted by Crabby Appleton at 7:45 PM on May 13, 2010

Crabby Appleton: "Tabs are treated differently in just about every program that handles text."

For display: whitespace that continues until a defined column.

For interpretation: identical to a space (except for make and cut, because make and cut are stupid).

I cannot think of any other use of tabs in the programs I use. Maybe the programs I don't use have a myriad of incompatible uses for tabs. Line feeds, Carriage returns, vertical tabs, and page break (^L) are also whitespace, and handled even less consistently than tab is.
posted by idiopath at 8:33 PM on May 13, 2010

For display: whitespace that continues until a defined column.

Which column?
posted by Crabby Appleton at 8:55 PM on May 13, 2010

Which column?

Whichever column you want. The point is, it doesn't matter which column. Set your tabstop to two, I'll set mine to seven, things just work.

I don't really set my tabstop to seven, that's just weird.
posted by The Pusher Robot at 9:00 PM on May 13, 2010

Whichever column you want.

No, not whichever column I want. Whichever column J. Random Program that displays text decides, in its infinite wisdom, is the correct one. I'm not just talking about text editors. Everything from cat to grep to od to Internet Explorer. They're all different, and most of them are wrong. There's very little disagreement about what a space means. (The only one I can think of is fixed-width vs. variable-width, and that's really a font issue.)
posted by Crabby Appleton at 10:10 PM on May 13, 2010

cat and grep and od all rely on their output device (probably a terminal), which is either arbitrarily configurable, or broken and you should pick a new one

In a sane terminal 'tput hts' sets a tab stop in the current column, 'tput ctb' clears all tab stops.
posted by idiopath at 10:14 PM on May 13, 2010

or easier, 'man tabs'
posted by idiopath at 10:22 PM on May 13, 2010

Oh, OK then.
posted by Crabby Appleton at 10:29 PM on May 13, 2010

No, not whichever column I want. Whichever column J. Random Program that displays text decides, in its infinite wisdom, is the correct one.

Why are you using J.Random Program to edit text? If you're not using an editor that lets you define a tab stop, that's your problem, not mine.
posted by !Jim at 10:50 PM on May 13, 2010

Well now that we have established the size of my mind you can feel free to disregard my input.

Haha, sorry, I didn't mean it that way. It is part of the "python zen" and is meant to say that "these rules are to be broken when it makes sense to break them." Taking a hard-line on any style rule (such as "anything over 80 characters means you're doing something wrong") is just limiting. Where did you get that number, 80? Oh, it's the display width of terminals about 35 years ago. It has nothing to do with the ideal line length of programs whatsoever.

I agree that overly long lines are bad, as well as nesting too deeply. Until you need to do so, then it's fine. Unclench, man.
posted by cj_ at 1:40 AM on May 14, 2010

Where did you get that number, 80? Oh, it's the display width of terminals about 35 years ago.

Or: "Yeah, that's the widely accepted value for a document of monospaced text at a readable font size. It's proven to be plenty for what, 35 years?"
posted by fleacircus at 4:44 AM on May 14, 2010

Or: "Yeah, that's the widely accepted value for a document of monospaced text at a readable font size. It's proven to be plenty for what, 35 years?"

It is widely accepted because of tradition (spawned from terminal sizes), not because of any inherent value in readability. Yes, there is a point where lines are Too Damn Long and it impacts code readability. Asserting that this point is 80 characters no matter what is ridiculous though. "Too long" is a subjective, context-dependent, and a malleable concept. If you are using a framework that trades the abstraction of complexity for slightly more verbose methods (such as, but not limited to, django) then longer lines are what you are going to get. The alternatives are not any more readable.

People that think >80 characters is instantly wrong no matter what remind me of those that are OK with charging 18 year old men with statutory rape for having sex with their 17 year old girlfriends. As if this specific number (80 in this case, 18 to the state) were magical somehow and not up for any form of debate.
posted by cj_ at 2:19 AM on May 15, 2010

Asserting that this point is 80 characters no matter what is ridiculous though.

Agreed, but I don't think anyone said that. I'm not entirely sure who you were telling to unclench. I was just saying: hey, don't throw the 80 column rule of thumb into the "arbitrary old BS" bin where we keep CRLF.
posted by fleacircus at 3:37 AM on May 15, 2010

Or: "Yeah, that's the widely accepted value for a document of monospaced text at a readable font size. It's proven to be plenty for what, 35 years?"

Knuth says 66. You know better than The Knuth?
posted by rodgerd at 6:26 PM on May 15, 2010

Python - it just works. Mostly.
posted by mdoar at 10:27 PM on May 15, 2010

Agreed, but I don't think anyone said that.

I was responding to this:

"If you need more than 80 columns for anything but a string constant in a sane language you are making a mistake in either naming, encapsulation, or code clarity - if not all 3."
posted by cj_ at 11:08 PM on May 15, 2010

Python - it just works. Mostly.

This is true of all programming languages, except for the ones that barely work.
posted by rodgerd at 11:43 PM on May 15, 2010