py3k.os_fspath enforces inconsist rules with python3 os.fspath
After a recent upgrade of numpy (1.13.1 -> 1.6.0), my code is failing where I provide unicode objects as filenames. Previously they were allowed. Now that are not, and I *must* provide a (py2) str or bytearray only.
# str is OK $ python2.7 -c "from numpy.compat import py3k; print py3k.os_fspath('123')" 123
# unicode is not $ python -c "from numpy.compat import py3k; print py3k.os_fspath(u'123')" Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/local/lib/python2.7/dist-packages/numpy/compat/py3k.py", line 237, in os_fspath "not " + path_type.__name__) TypeError: expected str, bytes or os.PathLike object, not unicode
But this enforcement of "str, bytes or os.PathLike" comes from: https://docs.python.org/3/library/os.html where in Python 3 str is a unicode, and moreover, os.fspath allows
$ python3 -c "import os; print(os.fspath(u'123'))" # unicode str 123 $ python3 -c "import os; print(os.fspath('123'))" # also unicode str 123
.... so... shouldn't py3k.os_fspath allow py2 unicode obejcts.
- Stu
This looks like a bug to me - can you file it on the issue tracker.
Evidently I did not consider python 2 behavior when backporting `os.fspath` from python 3.
Eric
On Mon, 14 Jan 2019 at 16:28 Stuart Reynolds stuart@stuartreynolds.net wrote:
After a recent upgrade of numpy (1.13.1 -> 1.6.0), my code is failing where I provide unicode objects as filenames. Previously they were allowed. Now that are not, and I *must* provide a (py2) str or bytearray only.
# str is OK $ python2.7 -c "from numpy.compat import py3k; print py3k.os_fspath('123')" 123
# unicode is not $ python -c "from numpy.compat import py3k; print py3k.os_fspath(u'123')" Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/local/lib/python2.7/dist-packages/numpy/compat/py3k.py", line 237, in os_fspath "not " + path_type.__name__) TypeError: expected str, bytes or os.PathLike object, not unicode
But this enforcement of "str, bytes or os.PathLike" comes from: https://docs.python.org/3/library/os.html where in Python 3 str is a unicode, and moreover, os.fspath allows
$ python3 -c "import os; print(os.fspath(u'123'))" # unicode str 123 $ python3 -c "import os; print(os.fspath('123'))" # also unicode str 123
.... so... shouldn't py3k.os_fspath allow py2 unicode obejcts.
- Stu
NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Will do.
On Mon, Jan 14, 2019 at 7:10 PM Eric Wieser wieser.eric+numpy@gmail.com wrote:
This looks like a bug to me - can you file it on the issue tracker.
Evidently I did not consider python 2 behavior when backporting `os.fspath` from python 3.
Eric
On Mon, 14 Jan 2019 at 16:28 Stuart Reynolds stuart@stuartreynolds.net wrote:
After a recent upgrade of numpy (1.13.1 -> 1.6.0), my code is failing where I provide unicode objects as filenames. Previously they were allowed. Now that are not, and I *must* provide a (py2) str or bytearray only.
# str is OK $ python2.7 -c "from numpy.compat import py3k; print py3k.os_fspath('123')" 123
# unicode is not $ python -c "from numpy.compat import py3k; print py3k.os_fspath(u'123')" Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/local/lib/python2.7/dist-packages/numpy/compat/py3k.py", line 237, in os_fspath "not " + path_type.__name__) TypeError: expected str, bytes or os.PathLike object, not unicode
But this enforcement of "str, bytes or os.PathLike" comes from: https://docs.python.org/3/library/os.html where in Python 3 str is a unicode, and moreover, os.fspath allows
$ python3 -c "import os; print(os.fspath(u'123'))" # unicode str 123 $ python3 -c "import os; print(os.fspath('123'))" # also unicode str 123
.... so... shouldn't py3k.os_fspath allow py2 unicode obejcts.
- Stu
NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Was recently already submitted: https://github.com/numpy/numpy/issues/12749
On Tue, Jan 15, 2019 at 8:08 AM Stuart Reynolds stuart@stuartreynolds.net wrote:
Will do.
On Mon, Jan 14, 2019 at 7:10 PM Eric Wieser wieser.eric+numpy@gmail.com wrote:
This looks like a bug to me - can you file it on the issue tracker.
Evidently I did not consider python 2 behavior when backporting `os.fspath` from python 3.
Eric
On Mon, 14 Jan 2019 at 16:28 Stuart Reynolds stuart@stuartreynolds.net wrote:
After a recent upgrade of numpy (1.13.1 -> 1.6.0), my code is failing where I provide unicode objects as filenames. Previously they were allowed. Now that are not, and I *must* provide a (py2) str or bytearray only.
# str is OK $ python2.7 -c "from numpy.compat import py3k; print py3k.os_fspath('123')" 123
# unicode is not $ python -c "from numpy.compat import py3k; print py3k.os_fspath(u'123')" Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/local/lib/python2.7/dist-packages/numpy/compat/py3k.py", line 237, in os_fspath "not " + path_type.__name__) TypeError: expected str, bytes or os.PathLike object, not unicode
But this enforcement of "str, bytes or os.PathLike" comes from: https://docs.python.org/3/library/os.html where in Python 3 str is a unicode, and moreover, os.fspath allows
$ python3 -c "import os; print(os.fspath(u'123'))" # unicode str 123 $ python3 -c "import os; print(os.fspath('123'))" # also unicode str 123
.... so... shouldn't py3k.os_fspath allow py2 unicode obejcts.
- Stu
NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
participants (2)
-
Eric Wieser -
Stuart Reynolds