I did implement TryFromObject for CString recently, but you could also just have a nulcheck function that makes sure a string doesn't have a nul char in it, and returns a ValueError if it does, then just call nulcheck(s, vm)?;. (Or maybe a vm method?)

I did implement TryFromObject for CString recently, but you could also just have a nulcheck function that makes sure a string doesn't have a nul char in it, and returns a ValueError if it does, then just call nulcheck(s, vm)?;. (Or maybe a vm method?)

The problem is that CPython support nul char while rust throws exception.

os.stat("/dev/null\x00")

Should not throw an error.

Ah, I see; that is tricky.

It seems only trailing \x00 exists in tests. Trimming them before making PyPathLike would work?

This will actually give the opposite result. As /dev/null should be different then /dev/null\x00

This is not specifically related to this PR, but while reading, i found i have no idea why PyPathLike is not PyPath but Like

Thats how they are called in CPython.

I try to test this problem a bit, but I can't make null-included path working. Could you describe your working environment?

macOS, python 3.8.1, APFS

>>> open('abc\x00', 'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: embedded null byte
>>> import os
>>> os.stat('/dev/null\x00')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: embedded null byte
>>>

Linux, Python 3.5.2, ext4

>>> open('abc\x00', 'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: embedded null byte
>>> import os
>>> os.stat('/dev/null\x00')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: embedded null byte

If you will look at the tests. For example https://github.com/RustPython/RustPython/pull/1840/files#diff-6bc3eb7fdef7557c945c66fb0b60a134R1921

@coolreader18 @youknowone can this be pushed and we will solve the nul later?

It seems Vec<u8> is the reasonble internal data of path types. And they may be used to create ffistring in future when they are actually used. Is it possible to fix now? or do you want to merge this for right now as it is?

It seems Vec<u8> is the reasonble internal data of path types. And they may be used to create ffistring in future when they are actually used. Is it possible to fix now? or do you want to merge this for right now as it is?

I am not sure I understand... Would you like to change the OsString to Vec<u8>?

I guess so. I didn't check cpython implementation well yet, but it seems it is more close to Vec<u8> than OsString. Or enum { Bytes(Vec<u8>), Str(String) } if there are difference by str/bytes.

@palaviv I think fixing it later would be fine, it's not too critical to pathlib, and I think it would rarely happen in practice.

I have merged this and we can do the proposed changes in the future

I checked about PyPathLike impl but it revealed enum is not fit for the use case.