Is the timeout and TimeoutError intended to be different?

[Stwerp]

Some students are having issues with their systems running for lengths longer than an hour or so. We've been able to catch some errors, and it seems that a solution like: #170 (comment) is the best idea so far and wrapping everything related to the actual sending of the GET/POST call in a try block

try:
    [...]
except (ValueError, RuntimeError, ConnectionError, OSError, TimeoutError) as e:
   [... handle reset and retry]

However, we've also seen students have a timeout error coming from

Adafruit_CircuitPython_ESP32SPI/adafruit_esp32spi/adafruit_esp32spi_socket.py

Line 154 in 956d6a0

raise timeout("timed out")

This error is different than a TimeoutError that, for example, might come from

Adafruit_CircuitPython_ESP32SPI/adafruit_esp32spi/adafruit_esp32spi.py

Line 831 in 956d6a0

raise TimeoutError("Failed to establish connection")

Is this an intentional difference? It seems to be, given the class definition on these lines

Adafruit_CircuitPython_ESP32SPI/adafruit_esp32spi/adafruit_esp32spi_socket.py

Lines 196 to 201 in 956d6a0

	class timeout(TimeoutError):
	"""TimeoutError class. An instance of this error will be raised by recv_into() if
	the timeout has elapsed and we haven't received any data yet."""
	def __init__(self, msg):
	super().__init__(msg)

I'm just not understanding why. If this is the case, then we should be catching a TimeoutError as well as a timeout error, so our except block would have this:

try:
    [...]
except (ValueError, RuntimeError, ConnectionError, OSError, TimeoutError, timeout) as e:
   [... handle reset and retry]

That seems a little strange to me, but I just wanted to check (and also be able to tell students why they need to catch both those errors).

[justmobilize]

@FoamyGuy was there a reason in this commit you didn't just raise a TimeoutError?

[justmobilize]

@Stwerp timeout has been removed. It was originally in there to match older versions of Python