On Wed, May 20, 2009 at 6:30 PM, Mike Meyer email@example.com wrote:
On Wed, 20 May 2009 17:44:54 -0700 Aaron Rubin firstname.lastname@example.org wrote:
On Wed, May 20, 2009 at 4:02 PM, Steven D'Aprano <email@example.com wrote: As time marches forward and email editors don't wrap (mine doesn't),
That makes your mail editor a throwback. Used to be, none of them wrapped. Then an 800 lb gorilla of a company decided to ignore what the RFCs said, and made their mailer act like there WP products and wrap text. It's hard to find a modern mailer that doesn't wrap.
I use gmail.
printers are used less (which is already happening), etc. then standards for core libraries will probably change as well.
But PDAs and Netbooks are being used more and more.
You can't possibly make a case that programming on either of these devices should be what we should cater to. I want to program on my Palm phone as well, but I have to accept that the world won't try to accommodate me, but the other way around.
Either way, the style for coding within a non-standard library might want to be revisited much sooner. In other words, programming to a standard which is common to all people who use it means you probably must accommodate the lowest common denominator. This would not be true for anything but the standard library.
Um, I'd say it holds for pretty much every other open source project done in Python, excepting those that are targeted for some specific platform. I.e. - if you're writing scripts for a high-end CAD program, then you get one set of assumptions about the working environment. But if you're developing on and for N60, you get a completely different set.
I am trying to discern between a code base which must cater to all, and a code base which mustn't. An open source project is akin to a widely used closed source project. What they share is they don't need to cater to the least common denominator, but instead a least common denominator, which gives them more flexibility.
The problem is that on it's good days, this is a bikeshed issue. On it's bad day out and out religious. Choosing to follow PEP-8 so as to not waste time discussing it is a rational choice for any group working in Python. It's certainly better than no standards at all!
But choosing to pinpoint particular aspects which do not appear to make much sense and attempt to further understand the rationale behind it, so as to assess whether it is worth it to follow those aspects is very worthwhile. Whether the entire community accepts it is another thing. The entire community appears to be quite divided on this issue and rightfully so...we appear to be in the middle of change :) Otherwise, there wouldn't be so much debate on the topic.