[issue8082] Misleading exception when raising an object
New submission from Daniel Eloff : >>> class Foo(object): ... pass ... >>> raise Foo() Traceback (most recent call last): File "", line 1, in TypeError: exceptions must be classes or instances, not Foo >>> class Foo(Exception): ... pass ... >>> raise Foo() Traceback (most recent call last): File "", line 1, in Foo >>> class Foo(BaseException): ... pass ... >>> raise Foo() Traceback (most recent call last): File "", line 1, in Foo It seems exceptions can only be subclasses of BaseException, the error message is confusing and false. -- messages: 100551 nosy: Daniel.Eloff severity: normal status: open title: Misleading exception when raising an object type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8082> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1815] Distutils add ability to skip build [Feature Request]
New submission from Daniel Eloff: There seems to be no way to skip the build step when running "setup.py install" The behavior in such a case should be to skip build and use the existing binaries as created in a separate build step or else print an error. That way you can do "setup.py build" followed by "setup.py install --skip-build" and you only have one build taking place. The purpose of this would be to allow build to take place on a separate computer to install. Currently I do this on Vista because MSVC 2003 is not recommended or supported, and distutils won't use the installed MSVC 2005. So I do the build on a (virtual) XP machine and then install by hand for lack of this option. I think Vista is a strong enough use case to justify adding this feature. -- components: Distutils messages: 59836 nosy: Eloff severity: normal status: open title: Distutils add ability to skip build [Feature Request] versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1815> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6281] Bug in hashlib
Daniel Eloff added the comment: I have indeed seen __get_builtin_constructor fail in practice, in the python build in the Ubuntu repository if IIRC. I seem to recall the problem was that python was using a version of openssl that didn't include all of hash algorithms, probably because a python library or the process hosting python also had a dependency on libssl and had it loaded already. But there is also the issue that Python is a language with many implementations now, and in fact, it's unlikely that CPython will remain the defacto implementation forever. Having a more robust hashlib.py that can handle missing algorithm implementations makes a lot of sense (.NET for example has no implementation of some of the more esoteric SHA hashes.) I remember that in the early days of IronPython, hashlib.py had to be completely replaced to be used. -- ___ Python tracker <http://bugs.python.org/issue6281> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6156] Error compiling valid regex
New submission from Daniel Eloff : This works: r'([xy])(?:\1)+' This won't compile, "error: nothing to repeat" r'([xy])(?:\s*\1)+' I can execute this under other regex engines, and it seems to me that it really should work. -- components: Library (Lib) messages: 88600 nosy: Eloff severity: normal status: open title: Error compiling valid regex type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6156> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6281] Bug in hashlib
New submission from Daniel Eloff : The try statement at the end of hashlib.py is some of the worst python code I've had the mispleasure of reading for a long time. Secondly, it seems flawed in function as well as form. __get_builtin_constructor can throw an ImportError, which seems erroneously caught in the except (why on earth does the except span more than the "import _hashlib"? That's bad style for precisely this reason.) This will cause an error in the import of hashlib when there are possibly many working hash functions already imported. Changing the: try: exec funcName + ' = __get_builtin_constructor(funcName)' except ValueError: pass to catch ImportError as well solves the problem for me. -- messages: 89338 nosy: Eloff severity: normal status: open title: Bug in hashlib type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6281> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6281] Bug in hashlib
Daniel Eloff added the comment: If you're missing any hash algorithm from openssl (say sha224) and the corresponding _sha224 module, hashlib will fail to import and no hash algorithms will be available. Additionally, if no (or only some) openssl algorithms are available, the error branch expects every hash algorithm to be present in it's own module, if even one is missing, hashlib will fail to import. Producing a test case for these without mock objects is difficult at best. I leave that to the python team, if they desire to do so. Here is a rewritten hashlib.py, without that ugly mess of code and without the above two bugs. It passes all tests. -- Added file: http://bugs.python.org/file14297/hashlib.py ___ Python tracker <http://bugs.python.org/issue6281> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6281] Bug in hashlib
Daniel Eloff added the comment: Yes, I prefer: globals()[funcName] = __get_hash(funcName) The exec was used in the original code, I'm not aware of the style of the python stdlib programmers, so I tried to be as true to what I found as possible. I just wanted to blunt my words in the original post, I don't want Gregory Smith to view it as a personal attack, I was just frustrated in having to debug the hashlib code. I'm sure even Gregory would admit it's not code he's proud of (probably done under a tight deadline.) No doubt Gregory normally does high quality work. -- ___ Python tracker <http://bugs.python.org/issue6281> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
