pleroma.debian.social

pleroma.debian.social

Yesterday was quite unusual for me, I spent a whole day on one thing, writing python. It was also mostly quite pleasant.
replies
1
announces
0
likes
3

The stupidest thing was discovering that `os.path.exists` can accept integers, and treats them as file descriptors, meaning `os.path.exists(0)` is true, and anything that coerces to 0 is also true for example the Boolean value false

@jmtd 🦆🦆🪿

@jmtd ((Billie Eilish's 'What Was I Made For' playing softly in the background))

@jmtd @jmtd if stdin == false:
…
if stdout == true:
…

@jmtd
The combination of duck typing and coercion is an amazing way to create very subtle bugs.

@brunogirin yes. When I hit this I took it for granted that accepting file descriptors actually made sense for someone, then it was pointed out to me, the file descriptor is not a path. Why did they even add this? I wondered if it was inherited Legacy, but they explicitly added this in 3.3.

@jmtd it makes sense at the kernel level: a file path is a nice string that resolves to a file descriptor, which itself is an integer that the file system uses to get to the actual data. So that capability makes sense for low level processes.

So you hit one of Python's annoyances where despite being a high level language, some of the quirks of the underlying C API sometimes surface to wreck havoc on your code.

@jmtd

$ touch /tmp/nah
$ exec 3</tmp/nah
$ unlink /tmp/nah
$ python
>>> import os.path
>>> os.path.exists(3)
True
>>> os.readlink('/proc/self/fd/3')
'/tmp/nah (deleted)'

that’s messed up 🤯 I thought it would at least check if the file descriptor is still linked in the FS (st_nlink > 0)