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, i
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
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 ol
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 see
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 see
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&quo
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 = fal
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,
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 red
