This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Various filename-taking posix methods don't like bytes / buffer objects.
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.1
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: sh
Priority: normal Keywords: patch

Created on 2009-12-22 05:07 by sh, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg96792 - (view) Author: Sebastian Hagen (sh) Date: 2009-12-22 05:07
Most of the functions in Python's stdlib that take filename parameters
allow for those parameters to be buffer (such as bytes, bytearray,
memoryview) objects. This is useful for various reasons, among them that
on Posix-likes, file- and pathnames ultimately *are* sequences of bytes.
A number of functions in the posix (and thus, os) module break this
convention:
mkfifo()
mknod()
statvfs()
pathconf()

E.g.:
>>> os.statvfs(b'/')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: statvfs() argument 1 must be string, not bytes

I'm attaching a patch that modifies the abovementioned functions to make
them accept buffer-like objects in addition to string objects; I've
never contributed code to the stdlib, so any general problems with that
patch can be ascribed to my ignorance about established practice (or
inability to program, in the case of downright bugs).

I'm a bit off a loss as what to do about posix.system(). IMO, that one
should also take bytes - at least on posix-like OSes - since it
specifies a commandline, and both the name and the arguments in such
lines are, on posix-likes, sequences of bytes.
I'm not sure how to best reconcile that with the MS Windows version of
that function, however; advice would be welcome.
msg96793 - (view) Author: Sebastian Hagen (sh) Date: 2009-12-22 05:10
I'm taking that patch back. More testing would have been in order before
posting; sorry for that, will repost once I've got the obvious problems
worked out.
msg96794 - (view) Author: Sebastian Hagen (sh) Date: 2009-12-22 05:42
And further testing reveals that all of this has in fact already been
fixed in trunk. I assumed it hadn't been, because the code for at least
some of the relevant functions in Modules/_posixmodule.c is the same as
in 3.1.1; I didn't know that the samentics for the "s" format parameter
to PyArg_ParseTuple() had been modified. Apologies for the noise.
History
Date User Action Args
2022-04-11 14:56:55adminsetgithub: 51809
2009-12-22 05:42:40shsetstatus: open -> closed
versions: - Python 3.2
2009-12-22 05:42:09shsetmessages: + msg96794
2009-12-22 05:10:19shsetmessages: + msg96793
2009-12-22 05:09:44shsetfiles: - posix_fn_bytes_01.patch
2009-12-22 05:08:13shsettype: behavior
2009-12-22 05:07:40shcreate