[Python-ideas] 80 character line width vs. something wider

[Mike Meyer]

On Wed, 20 May 2009 18:55:11 -0700
Aaron Rubin <aaron.rubin at 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 at 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