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".