[issue25466] offer "from __future__ import" option for "raise... from"
New submission from alanf: There is no "from __future__ import" option that would allow Python 2x users the "raise... from" syntax that is provided with Python 3. This is especially unfortunate because even if the "raise... from" is included in a branch that is never executed, loading the code in 2.7 can cause a seemingly unrelated exception (in my case, an import error for StringIO). Since my code must work in 2.7, 3.3, and 3.4, this is a problem. I have found a workaround. If I want to achieve the equivalent of "raise XXX from None", for instance, I can do it as follows: if hasattr(newExc, '__cause__'): newExc.__cause__ = None raise newExc This works because the Exception class exists in all three Python versions, but only has a __cause__ attribute in Python 3. However, it's clumsier than I would like. Also, it's not obvious. I discovered that exception handling had changed when I saw that raising an exception when another one was active caused a "During handling of the above exception, another exception occurred" message on Python 3 (behavior that I didn't want) but was silently dropped in Python 2.7 (behavior that I did want). After I found a description of the "raise... from None" syntax in Python 3, I expected to find a "from __future__ import" statement that would handle this, but was disappointed. It took me a while longer to figure out the workaround above. I'd rather that other people didn't have to go through the process of figuring out the workaround. -- messages: 253384 nosy: alanf priority: normal severity: normal status: open title: offer "from __future__ import" option for "raise... from" type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue25466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24591] offer option to suppress "clean --all" output relating to nonexistent dirs
New submission from alanf: The command "setup.py clean --all" writes out information about nonexistent directories that the script tried to clean but couldn't find. Example: 'build/bdist.linux-x86_64' does not exist -- can't clean it 'build/scripts-2.7' does not exist -- can't clean it It would be better to suppress this output, or at least offer an option for suppressing it. This information serves no purpose to the user, except possibly to make him or her unnecessarily worried. (I know at least three developers on my team who wondered whether these lines indicated a problem when they tested our setup.py, which performs the equivalent of "clean --all" whenever "build" is run.) It's perfectly normal for these directories not to exist. The chance that you would have every possible such directory is close to zero. There is a "quiet" option, but that's not what I want to use, since the other output issued by the command (that is, the removal of real directories) is informative. -- components: Distutils messages: 246458 nosy: alanf, dstufft, eric.araujo priority: normal severity: normal status: open title: offer option to suppress "clean --all" output relating to nonexistent dirs type: enhancement ___ Python tracker <http://bugs.python.org/issue24591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24466] extend_path explanation in documentation is ambiguous
New submission from alanf: The description of pkgutil.extend_path in the doc (e.g., https://docs.python.org/2/library/pkgutil.html , https://docs.python.org/3/library/pkgutil.html ) is so ambiguous that I had to run a test to understand its behavior. The doc says: This will add to the package’s __path__ all subdirectories of directories on sys.path named after the package. It wasn't clear to me how this should be parsed. Using parentheses to group the clauses, there's this possibility : (1) This will add to the package’s __path__ all (subdirectories of directories on sys.path) named after the package. That is, given all subdirectories of directories on sys.path, find the ones that are named after the package, and add them to the package's __path__. or: (2) This will add to the package’s __path__ all subdirectories of (directories on sys.path named after the package). That is, given all directories on sys.path that are named after the package, add all their subdirectories to the package's __path__. or: (3) This will add to the package’s __path__ all subdirectories of ((directories on sys.path) named after the package). That is, given all directories on sys.path that are named after the package, add all their subdirectories to the package's __path__. or: (4) This will add to the package’s __path__ all (subdirectories of (directories on sys.path)) named after the package. That is, given all directories on sys.path, add any of their subdirectories that are named after the package to the package's __path__. It was also unclear to me whether the subdirectories were meant to be traversed recursively. My testing indicates that (4) is the correct parse, and that the subdirectories are not meant to be traversed recursively. I suggest this wording: For each directory on sys.path that has a subdirectory that matches the package name, add the subdirectory to the package's __path__. -- assignee: docs@python components: Documentation messages: 245468 nosy: alanf, docs@python priority: normal severity: normal status: open title: extend_path explanation in documentation is ambiguous type: enhancement versions: Python 2.7, Python 3.4 ___ Python tracker <http://bugs.python.org/issue24466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
