[issue12762] EnvironmentError_str contributes to unportable code

Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue12762] EnvironmentError_str contributes to unportable code

R. David Murray added the comment: The enum module that is likely to land in 3.4 will allow us to fix this. We can discuss whether we want to just display the name, or both the name and the value. Omitting it would indeed be bad, IMO. -- nosy: +r.david.murray stage: -> needs patch t

[issue12762] EnvironmentError_str contributes to unportable code

Mark Lawrence added the comment: It doesn't bother me that Python programmers can write unportable code, what with consenting adults and all that. Further the implementation of PEP 3151 in 3.3 allows specific exceptions to be caught, e.g. FileNotFoundError. I can't see anybody allowing the ex

[issue12762] EnvironmentError_str contributes to unportable code

Changes by Ezio Melotti : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue12762] EnvironmentError_str contributes to unportable code

Barry A. Warsaw added the comment: I tend to agree that the errno is much less useful than the symbolic name. The former is useful and will be available as an attribute, but the latter should be used in the str. The change will probably break scads of doctests, but is probably worth it. :)

[issue12762] EnvironmentError_str contributes to unportable code

Jakub Wilk added the comment: And the lost footnote is: [0] http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html#tag_02_03 -- ___ Python tracker ___ _

[issue12762] EnvironmentError_str contributes to unportable code

New submission from Jakub Wilk : It is a surprisingly common error in 3rd party code to write something like this: try: eggs() except OSError, e: if e.errno == 17: ham() This is wrong, because according to POSIX[0], “only […] symbolic names should be used in programs,