[issue29042] os.path.exists should not throw "Embedded NUL character" exception
New submission from Dolda2000:
Currently, calling os.path.exists on a path which contains NUL characters
behaves consistently with most file-system calls by throwing an exception:
>>> os.path.exists('\0')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/genericpath.py", line 19, in exists
os.stat(path)
ValueError: embedded null byte
However, os.path.exists is supposed to be a predicate returning whether there
exists a file named by the path; it does not specify any particular method or
system call for doing the test, and so reflecting the behavior of the
underlying syscall used is not obviously desirable. A path containing an
embedded NUL character simply cannot name an existing file, and therefore
os.path.exists should return False for such a path.
--
components: Library (Lib)
messages: 283807
nosy: Dolda2000
priority: normal
severity: normal
status: open
title: os.path.exists should not throw "Embedded NUL character" exception
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue29042>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22674] strsignal() missing from signal module
New submission from Dolda2000: Like it says on the tin, it would be nice if strsignal(3) were added to the signal module. -- components: Library (Lib) messages: 229691 nosy: Dolda2000 priority: normal severity: normal status: open title: strsignal() missing from signal module type: enhancement versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue22674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21317] Home page certificate troubles
New submission from Dolda2000: This is misfiled under "Documentation" since it affects the documentation peripherally and I couldn't find any better component to file it under. To get to the point, the website seems to have certificate troubles for some URLs affecting the older versions of documentation. For instance, at this URL: <https://docs.python.org/3.0/c-api/arg.html> For me at least, it says "400 Bad Request // The SSL certificate error [sic] // nginx". I am also not allowed to access it over HTTP, since that just redirects me to the HTTPS version. (As an aside, you may also want to fix the typo in the error message while your at it. ;) -- assignee: docs@python components: Documentation messages: 216928 nosy: Dolda2000, docs@python priority: normal severity: normal status: open title: Home page certificate troubles type: crash ___ Python tracker <http://bugs.python.org/issue21317> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20074] open() of read-write non-seekable streams broken
Dolda2000 added the comment: >So the question is, is the *design* of the IO module that '+' requires a >seekable stream the best behavior, or can that constraint be relaxed? What purpose does that constraint serve? Is there any reason it shouldn't be relaxed? It seems to work quite well without it in Python 2. -- ___ Python tracker <http://bugs.python.org/issue20074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20074] open() of read-write non-seekable streams broken
Dolda2000 added the comment: Oh sorry, my bad. I messed up. :) Given that that works, though, why can't open() handle opening /dev/tty directly in text mode? Clearly, TextIOWrapper can handle the necessary buffering without the stream having to be seekable. -- ___ Python tracker <http://bugs.python.org/issue20074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20074] open() of read-write non-seekable streams broken
Dolda2000 added the comment:
Python 3.3.3 (default, Dec 8 2013, 14:51:59)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import io
>>> io.TextIOWrapper(open("/dev/tty", "rb+"))
Traceback (most recent call last):
File "", line 1, in
io.UnsupportedOperation: File or stream is not seekable.
Was this also fixed in 3.4?
--
___
Python tracker
<http://bugs.python.org/issue20074>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20074] open() of read-write non-seekable streams broken
Dolda2000 added the comment: Just to demonstrate failure of getpass, by the way: $ cat >/tmp/pwtest.py import getpass print(getpass.getpass()) $ python3 /tmp/pwtest.py print(getpass.getpass()) File "/usr/lib/python3.3/getpass.py", line 83, in unix_getpass passwd = fallback_getpass(prompt, stream) File "/usr/lib/python3.3/getpass.py", line 118, in fallback_getpass return _raw_input(prompt, stream) File "/usr/lib/python3.3/getpass.py", line 134, in _raw_input raise EOFError EOFError -- ___ Python tracker <http://bugs.python.org/issue20074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20074] open() of read-write non-seekable streams broken
Dolda2000 added the comment: >I don't think getpass will fail, since it uses os.open, not open. It also uses fdopen() on the resulting file descriptor, however, which has the same problem. >Use unbuffered binary file. It's nice that that's at least possible, but I, for one, would still consider it a bug that it isn't possible to open it in text mode. -- ___ Python tracker <http://bugs.python.org/issue20074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20074] open() of read-write non-seekable streams broken
New submission from Dolda2000:
It seems open() is slightly broken in Python 3, in that one cannot open
non-seekable files in read-write mode. One such common use is open("/dev/tty",
"r+") for interacting directly with the controlling TTY regardless of standard
stream redirections. Note that this is a regression for Python 2, where this
worked as expected.
What happens is the following:
>>> open("/dev/tty", "r+")
Traceback (most recent call last):
File "", line 1, in
io.UnsupportedOperation: File or stream is not seekable.
Just for the record, the same thing happens with "w+" and "rb+".
This also means that the getpass module is slightly broken, since it will
always fail whenever stdin is redirected.
--
components: IO
messages: 206957
nosy: Dolda2000
priority: normal
severity: normal
status: open
title: open() of read-write non-seekable streams broken
type: behavior
versions: Python 3.1, Python 3.3
___
Python tracker
<http://bugs.python.org/issue20074>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
