Dima Tisnek <dim...@gmail.com> added the comment: The code in question is interesting... I don't claim to understand it.
A pair of file descriptors is passed wrapped in sockets, and the objects are used here: https://github.com/sshuttle/sshuttle/blob/966fd0c5231d56c4f464752865d96f97bd3c0aac/sshuttle/ssnet.py#L238-L240 * s.setblocking(False) * os.read(s.fileno()) * select.select([s], [s], ...) elsewhere in the file * s.shutdown() elsewhere in the file server.py uses Mux() with a pair of os.stdin/stdout, realistically pty/pipe/file client.py uses Mux() with [an anonymous domain] socket from socketpair() So, on one hand, it is used like a socket, on the other, it's used as a holder for a file-like file descriptor 🤷♂️ Back in the day, I too wrote (C) code that treated file/tty and socket file descriptors alike. I've since come to realise that's not exactly correct. IIRC doing so was elegant, UNIX-y, but implied platform specifics, i.e. was not cross-platform. I've also done similar tricks with serial.Serial before: instantiate but don't open, set pty fd, use to test code that expects a serial port in memory. Luckily that code was not open-source ☺️. It was a hack, but I don't know if it's cpython's job to support hacks of this kind. My 2c: Personally, I'd rather see the this "fixed" in sshuttle than in cpython. Perhaps someone with authority over the socket module can weight the balance between "a regression because using socket.socket as a container for generic file descriptors used to work before" vs. "least surprise for well-behaved and future code". ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39685> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
