resolve KeyError#33
Conversation
|
That solution would be quite wrong. This is probably a duplicate of #32, which isn't really solvable. Which NetworkManager version are you using? |
|
Hey, thanks for getting back to me. Yeah it's definitely the same issue. Those entries seem pretty non-critical. The approach of "do something decently reasonable and print a warning" is how a lot of Python packages (e.g. numpy) warn you that you're using deprecated behavior. Should I change my PR to do that? |
|
Those entries are entirely critical, without them you can't handle signals... |
|
The current behavior of crashing the Python interpreter also removes my ability to handle signals. The other option I can think of is to throw a catchable exception at the end of the import, to warn of the missing functionality. That's just a thought though. What do you think is the correct workaround on distros with older network manager versions? |
|
Try 522658b |
|
Thanks for working on it. I just tested. That fixed one KeyError, but there's also a python-networkmanager/NetworkManager.py Line 237 in 522658b I think a similar code change to line 237 should fix the problem. |
|
Yeah. See cad4dc7
|
|
Thanks, I just tested and that fixed it. I'm happy closing this PR when you are. |
When I called 'import NetworkManager', I observed a KeyError on these lines, caused by an arg that had a 'type' attribute but not a 'name' attribute.
I don't fully understand this section of code, but I tried debugging a bit. When the KeyError occurred, I printed the other attributes on that line:
The problems occurred on Raspbian when wlan0 was not connected to an access point, and wlan1 was connected. The edits in this PR fixed it, and NetworkManager was still able to control connections, at least to the extent I could test.
(Also, please let me know if there's a better way to handle this problem than setting name to 'unknown'. I'm new to dbus and NetworkManager.)