On Wed, 20 May 2009 18:55:11 -0700 Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
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.
Nope, you don't make things more difficult for everybody else just to make things easier for them. On the other hand, you can't possibly disenfranchise them, either - which means that a change that makes things harder on people using them needs to benefit everyone else enough to make up for it.
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.
But the PSL is just another open source project. It has no requirement to cater to all, or to *the* lcd, any more than any other such project. In fact, it clearly doesn't, as it certainly never catered to people working in the Python implementation for the old Palm series III devices, or the N60 implementation, etc.
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.
Oh? Doesn't seem to be much different than last time (I saw it, anyway - it may have happened again during a hiatus). Lots of people with strong personal preferences, but the best real reason around is "we've always done it that way". Of course, everyone also seems to be forgetting one of the most important points in the PEP: But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask! But why not help things along even further, by cutting the length of what's probably the most common variable name in python by 50%, and replace "self" with "my". We can't shorten cls, but we can bring it into the same part of speach by making it "our". <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org