This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients barry, gvanrossum, lemburg, michael.foord, ncoghlan, terry.reedy
Date 2013-07-27.15:12:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1374937980.42.0.680508996663.issue18472@psf.upfronthosting.co.za>
In-reply-to
Content
This is mostly fine.

FWIW I disagree with MAL's assertion that we need to start adding internal versioning; people who "lawyer" about which version of the PEP should apply are focused on the wrong thing entirely.  IIUC the occasional Python-3-specific rule is already flagged as such.  Also for real nitpickers there's the Hg revision. :-)

My nits on the diff:

- You're missing a comma after Barry's name (i.e. before your own).

- Also a period at the end of point 3 starting near line 55.

- I think we should recommend against tabs outright.  They are getting more and more misunderstood.

- Regarding line length, I think it is reasonable to mention that many organizations are settling on 100 as a compromise.  On newer laptops you can still fit two terminal windows (with a reasonable font size) side by side.  (Also many people checking code into the stdlib ignore the 80 char limit. :-( )

- The section about Latin-1 author names sounds a little confused (why recommend Latin-1 over UTF-8 at all?).  I believe what is left unsaid is that you don't need a coding cookie when using Latin-1 in comments in Python 2?  But in strings the cookie would still be required IIRC.  But this will cause problems when the file is converted Python 3 because the UTF-8 default will complain about non-ASCII Latin-1 bytes.

- "In performance sensitive parts of the library" -- are we suddenly clinging to the fiction that PEP 8 only applies to the stdlib?  I'd change "parts of the library" to "code". Also, it's "performance-sensitive".

- Eliminate this:
"""
+- Use class-based exceptions (recent versions of Python require that all
+  exceptions inherit from BaseException).
"""
Instead, I'd add an admonition to derive exceptions from Exception rather than BaseException unless you really know what you're doing.  

- Which reminds me.  Do we have a recommendation yet to write
  except Exception:
instead of
  except:
If not, we should.

- I wouldn't mind seeing at least a mild recommendation against using exceptions for non-local control flow.  The lessons of StopIteration suggest that such designs are often fraught with subtle problems.

- About third party experiments: can you strike "highly"?  I don't want mypy to feel out of line (http://www.mypy-lang.org/).
History
Date User Action Args
2013-07-27 15:13:00gvanrossumsetrecipients: + gvanrossum, lemburg, barry, terry.reedy, ncoghlan, michael.foord
2013-07-27 15:13:00gvanrossumsetmessageid: <1374937980.42.0.680508996663.issue18472@psf.upfronthosting.co.za>
2013-07-27 15:13:00gvanrossumlinkissue18472 messages
2013-07-27 15:12:59gvanrossumcreate