On Wed, May 20, 2009 at 6:30 PM, Mike Meyer
<mwm@mired.org> 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.