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 rhettinger
Recipients barry, gvanrossum, lemburg, michael.foord, ncoghlan, rhettinger, terry.reedy
Date 2013-07-28.04:59:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1374987581.31.0.434083488803.issue18472@psf.upfronthosting.co.za>
In-reply-to
Content
- I think we should recommend against tabs outright.  They are getting more and more misunderstood.

+1  Perhaps also mention that Python 3 now raises TabError for inconsistent tabs and spaces.


- 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

+1  I've seen too many atrocities committed by people trying to scrunch code into 80 columns (weird line splits, over-abbreviated variable names, etc).

- 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.

+1 for UTF-8 as the default preference for everything in the Python world.


- 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.  

+1

- 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.

I'm afraid even a mild admonition would lead of over zealous rejection of legitimate use cases for exceptions.

For uses cases that actually need non-local control flow, there are worse things you can do than use exceptions (i.e. returning an error token up a chain of function calls requiring if-error logic at every step along the way).

In particular, exceptions for control-flow are a good solution to some challenges that arise in larger programs (i.e. problems encountered in low level logic can only be handled by high level user interface logic, and the intermediate level business logic serves only as a pass through).

It seems to me that the issues with StopIteration were mostly caused by having multiple control conditions all sharing the same exception (i.e. a function inside a for-loop can't use StopIteration to control an outer loop; the latter would need its own distinction exception).

P.S.  For those who are interested, the book "The Little MLer" does a great job showing how exceptions for control-flow can be used simplify recursive functions.
History
Date User Action Args
2013-07-28 04:59:41rhettingersetrecipients: + rhettinger, lemburg, gvanrossum, barry, terry.reedy, ncoghlan, michael.foord
2013-07-28 04:59:41rhettingersetmessageid: <1374987581.31.0.434083488803.issue18472@psf.upfronthosting.co.za>
2013-07-28 04:59:41rhettingerlinkissue18472 messages
2013-07-28 04:59:41rhettingercreate