Rethink "connected" attribute

[WasabiFan]

When we originally designed the ev3dev-lang libraries, we based them all on a concept where devices would expose a connected property to indicate whether they had successfully found a device matching the parameters from the constructor. This has led to a lot of code that looks like this:

m = ev3.Motor(ev3.OUTPUT_A)
assert m.connected

...and lots of confused users as a result (especially when they don't know to include that assertion).

Do we want to change this behavior? I think it would make sense at this point to throw an exception from the constructor. This would be just for this library and wouldn't necessarily require a change to others.

[ddemidov]

I guess there is no point in creating a Motor class instance that is not actually linked to a physical motor, so 👍

[dwalton76]

Seems worth raising an Exception in this scenario

[ensonic]

+1, right now you get exception when you try to use it anyway (e.g. when you set m.polarity right after constructing it).

[dwalton76]

See PR #402

[bidaian]

Throwing the exception is ok. But, should we get rid of the connected attribute too? Isn't there a valid use case for it?

[WasabiFan]

Yep, one of the changes in #402 is to remove the attribute entirely. In fact, that's the title of the PR.

[bidaian]

Yep, one of the changes in #402 is to remove the attribute entirely. In fact, that's the title of the PR.

I noticed the title :). My question is, if it would make sense to just throw the exception but not get rid of the attribute, because it might come in handy at some point (for things that could actually go on/offline after instantiation) and because it was exposed, so it's removal would break things (for example this or this from the projects gallery).

[WasabiFan]

Yes, it will be a breaking change. I can't imagine a case where a device would come on/offline in a way that we'd notice proactively (i.e., every read of connected would need to perform I/O to check if things are still connected). If there are devices that have such a need, those classes can implement this attribute as needed.

Existing scripts will work as-is. I'm working on an "upgrading guide" (#399) which walks you through the details, but the short version is that we plan to rename the module to be ev3dev2. So, if you continue to import ev3dev, you'll get the existing version of the library, but you can choose to update your import statements and only then will you be forced to adapt to breaking changes. So, those examples will work, however we'll need to make sure we have clear documentation that explains this behavior.

[bidaian]

Existing scripts will work as-is. I'm working on an "upgrading guide" (#399) which walks you through the details, but the short version is that we plan to rename the module to be ev3dev2. So, if you continue to import ev3dev, you'll get the existing version of the library

Well done. No concerns then. Thanks for clearing that up.