Differences between network.LAN and network.WLAN? No network.LAN disconnect method?

[Jibun-no-Kage]

Differences between network.LAN and network.WLAN? No network.LAN disconnect method? Happen to be using the ESP32 port...

So, if I create a network.WLAN object, I can connect, status 1010 (Got IP), then disconnect status 1000. But if I create a network.LAN object, I can connect, status 5 (Got IP), but since no disconnect method, even if I call network.LAN.active(False), status is returned as 5. Would figure at a minimum network.LAN status would return 1 (Lost Connect) when active set to False no?

Output of some test code...

Wirless? ...  <Active True, WLAN.connect, isconnected>
Wireless, Media Access Control DC:DA:10:18:C6:10, Ip Address 192.168.1.212, Mask 255.255.255.0, Gateway 192.168.1.3, Name Server 192.168.1.251
Wireless! 1010
Ethernet? ..... <Active True, LAN.connect, isconnected>
Ethernet, Media Access Control DC:DA:11:18:C6:11, Ip Address 192.168.1.215, Mask 255.255.255.0, Gateway 192.168.1.3, Name Server 192.168.1.251
Ethernet! 5
Time?  <Call Set Time via ntptime module>
Time! 08/14/2025 13:22:23
Wait? ..........
Ethernet? <No Disconnect so set Active(False)>
Ethernet! 5
Wireless?  <Disconnect and set Active(False) just cuz I can... but status 1000 results from disconnect method of WLAN object>
Wireless! 1000

I guess my real question is why network.LAN has no disconnect method? Like network.WLAN does?

[bikeNomad]

What would disconnection mean for network.LAN? For network.WLAN it means to disassociate from the AP, but that doesn't make sense for an Ethernet connection.

[Jibun-no-Kage]

I guess it is my nature to want consistent code logic... so if I created class for 'Network' objects, I would want to write is consistently across interface types... the lack of disconnect for Ethernet means I had to keep a flag or check the object type before I call disconnect(). Is it a lot of work, no... but just had me thinking, like the status codes being different... it is a delta that requires additional code logic. That said, I realize there are code design trade offs... in keeping MP tight and small... so disconnect() for Ethernet is one thing, but using different status codes for WiFi versus Ethernet would seem to be an obvious optimization using a shared enum, or what have you.