[issue22302] Windows os.path.isabs UNC path bug
Akima added the comment: I just realised that monkeyfart!££ is actually a valid relative path name. What I said still holds, just replace monkeyfart!££ with elephant*dung? (which contains the invalid characters: *? ). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22302 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22302] Windows os.path.isabs UNC path bug
Akima added the comment: eryksun: You have marked this bug as effecting Python 2.7. When I tested for the bug on 2.7.5 the problem didn't show up: Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import os.path os.path.isabs(r\\server) True os.path.isabs(r\\server\share) True os.path.isabs(r\\server\share\folder) True os.path.isabs(r\\server\share\folder\folder) True Did you independently test a later release of version 2.7 and find the issue? If not, could you remove Python 2.7 from the Versions list. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22302 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22302] Windows os.path.isabs UNC path bug
Akima added the comment: As eryksun pointed out, I created this bug report to report on one issue; that \\server\share isn't being consider absolute by os.path.isabs when it should be considered absolute. I found this bug when I was writing a basic config file parsing module. One of the options in the config (named log_dir) required an absolute path to a directory where my program could dump log files. It has to be absolute because the working directory of the program changes. A user entered a path \\pollux\logs as the log_dir value in their config file and my program rejected it informing the user that it wasn't absolute (because I checked the path using isabs). I've worked around this bug in my program, but it is clearly a problem that needs fixing. Steve: with regard to what isabs should return when given the string r\\server: does it really matter whether it returns True or False? As you said; \\server isn't a real path. It's invalid. If you ask python if it's absolute (using os.path.isabs) and you expect a boolean response, no matter whether the response is True or False, the response will be meaningless. Consider this: Python 3.2.3 (default, Feb 27 2014, 21:31:18) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. import os.path os.path.isabs(monkeyfart!££) False I just asked isabs if monkeyfart!££ was absolute and it told me it's not an absolute path, it's relative! It's infact, not even a path. There is no os.path.isrelative function. If we want to know if a path is relative we use the isabs function and decide the path is relative if the result is False. If you give the function a junk-string which isn't even a path (eg \\server or monkeyfart!££ ) then you can only expect a junk response. If we decide that all invalid paths provide to isabs should return False then what we are saying is all invalid paths provided to isabs should be considered relative paths. What use is that to anyone? Really, the programmer should ensure that the path is valid before trying to find out if it's relative or absolute. To summarize: I think it's important that isabs works correctly when given a *valid* path (like \\server\share). When it's given a string which is an invalid path (like \\server), its behaviour should be undefined. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22302 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22302] Windows os.path.isabs UNC path bug
Akima added the comment: I checked for the existence of this bug in 2 other python versions today. It's present in CPython 3.4.1, but CPython 2.7.5 doesn't exhibit the issue. Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import os.path os.path.isabs(r\\server) True os.path.isabs(r\\server\share) True os.path.isabs(r\\server\share\folder) True os.path.isabs(r\\server\share\folder\folder) True Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import os.path os.path.isabs(r\\server) True os.path.isabs(r\\server\share) False os.path.isabs(r\\server\share\folder) True os.path.isabs(r\\server\share\folder\folder) True -- versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22302 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22302] Windows os.path.isabs UNC path bug
Akima added the comment: FYI: I've only tested this bug on Python 3.3.5 on Windows 7. I expect the bug exists in other versions of Python. -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22302 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22306] Inconsistent division by 0 behaviour in decimal module
New submission from Akima: 1 / 0 (where both numbers are decimal.Decimal) produces a decimal.DivisionByZero exception as I would expect. This is useful. I can use a simple try except block to catch a potential division by zero error in my code. 0 / 0 (where both numbers are decimal.Decimal) produces a decimal.InvalidOperation exception. This is undesirable. I would expect another decimal.DivisionByZero exception. This means that if I want to catch a division by zero error in my code using a try except block, I now have to catch exceptions for both decimal.DivisionByZero and decimal.InvalidOperation. Presumably decimal.InvalidOperation can be raised in other scenarios, so catching it may result in masking a programming fault (which isn't just a division by zero: 0 / 0). If you perform the same division but using standard Python integers instead of decimal.Decimal objects, the behaviour is exactly as you would expect: 0 / 0 and 1 / 0 both produce a ZeroDivisionError exception. I have tested this in CPython 3.3.5, 3.2.3 and 2.7.3. All versions produce the same behaviour. Demonstration: Python 2.7.3 (default, Feb 27 2014, 19:58:35) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. from decimal import Decimal as d d(1) / d(0) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.7/decimal.py, line 1323, in __truediv__ return context._raise_error(DivisionByZero, 'x / 0', sign) File /usr/lib/python2.7/decimal.py, line 3866, in _raise_error raise error(explanation) decimal.DivisionByZero: x / 0 d(0) / d(0) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.7/decimal.py, line 1322, in __truediv__ return context._raise_error(DivisionUndefined, '0 / 0') File /usr/lib/python2.7/decimal.py, line 3866, in _raise_error raise error(explanation) decimal.InvalidOperation: 0 / 0 1 / 0 Traceback (most recent call last): File stdin, line 1, in module ZeroDivisionError: integer division or modulo by zero 0 / 0 Traceback (most recent call last): File stdin, line 1, in module ZeroDivisionError: integer division or modulo by zero Here is the same demonstration but using a Python 3.2.3 interpreter: Python 3.2.3 (default, Feb 27 2014, 21:31:18) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. from decimal import Decimal as d d(1) / d(0) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python3.2/decimal.py, line 1300, in __truediv__ return context._raise_error(DivisionByZero, 'x / 0', sign) File /usr/lib/python3.2/decimal.py, line 3926, in _raise_error raise error(explanation) decimal.DivisionByZero: x / 0 d(0) / d(0) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python3.2/decimal.py, line 1299, in __truediv__ return context._raise_error(DivisionUndefined, '0 / 0') File /usr/lib/python3.2/decimal.py, line 3926, in _raise_error raise error(explanation) decimal.InvalidOperation: 0 / 0 1 / 0 Traceback (most recent call last): File stdin, line 1, in module ZeroDivisionError: division by zero 0 / 0 Traceback (most recent call last): File stdin, line 1, in module ZeroDivisionError: division by zero -- messages: 226125 nosy: akima priority: normal severity: normal status: open title: Inconsistent division by 0 behaviour in decimal module type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22306] Inconsistent division by 0 behaviour in decimal module
Changes by Akima m...@aki.ma: -- components: +Library (Lib) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22306] Inconsistent division by 0 behaviour in decimal module
Akima added the comment: Hi skrah. Thanks for the feedback. That specification is interesting. As this IBM spec appears to be a /general/ specification for performing decimal arithmatic and not targetted specifically at Python's decimal arithmatic implementation, I would expect all of Python to adhere to its recommendations (for consitency). If the division by 0 behaviour of the decimal module is in fact correct (as per the spec you have linked) and desirable, then perhaps the Python standard integer division by zero behaviour is incorrect. 0 / 0 ... raises a ZeroDivisionError exception. This is in conflict with the IBM spec and with the behaviour of the decimal module. (I realize that arithmatic in the decimal module is not supposed to be equivalent to arithmatic with standard python number types, but this exception behaviour seems like something that should be consistent between the two arithmatic implementations.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22306] Inconsistent division by 0 behaviour in decimal module
Akima added the comment: Sorry. Scratch my last comment. I see from the docs ( https://docs.python.org/3/library/decimal.html ) that the decimal module explicitly references that IBM spec. I imagine that standard python arithmatic doesn't even attempt to conform to this ibm spec. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22302] Windows os.path.isabs UNC path bug
New submission from Akima: A UNC path pointing to the root of a share is not being recognised as an absolute path when it should be. See this interpreter session. PythonWin 3.3.5 (v3.3.5:62cf4e77f785, Mar 9 2014, 10:35:05) [MSC v.1600 64 bit (AMD64)] on win32. Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for further copyright information. import os.path os.path.isabs(r\\server) True os.path.isabs(r\\server\share) False os.path.isabs(r\\server\share\folder) True os.path.isabs(r\\server\share\folder\folder) True -- components: Library (Lib), Windows messages: 226091 nosy: akima priority: normal severity: normal status: open title: Windows os.path.isabs UNC path bug versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22302 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
