There are two issues. 1) what is the requested changed and is it technically correct; 2) if correct, should it be made from a policy viewpoint.

1) Alex, do I understand correctly that you see the behavior of disallowing nulls in paths as correct, and that you want an AssertRaises(..., TypeError) test added?

This rule seems like an OS rule, not a Python language rule. Is it uniform across all OSes?

The following is near the top of the 3.3 os module doc:

"Note: All functions in this module raise OSError in the case of invalid or inaccessible file names and paths, or other arguments that have the correct type, but are not accepted by the operating system."

On that basis, I would expect OSError. But perhaps the doc needs revision to accord with the reworking of OSErrors. On 3.3, Win7, I actually get

>>> os.stat("/tmp\x00abcds")
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    os.stat("/tmp\x00abcds")
FileNotFoundError: [Error 2] The system cannot find the file specified: '/tmp\x00abcds'

It appears that os.stat did not check for embedded nulls but just passed the string to Windows.


2. I am not sure if I understand the opposition to adding tests. As I remember, the 2011 PyCon sprint partly focused on adding tests. Were they not added to 3.2?

If the test is correct, it cannot break anything, and can catch future reversions (which do happen occasionally), besides helping other implementations. 3.2 will soon be a moot point, but I hope other implementations seriously work on 3.3 versions, and that we are willing to improve its test suite after the initial release.

If we are split here, discussion could move to pydev. It is not unusual that a specific issue raises a generic issue that needs broader discussion, but with the specific issue as a focal point.

Anyway, until there is a patch that we agree is technically correct, no decision need be made about commitment and the underlying generic policy.