Hi @CrazyIvan359,
having more support while conding in Pyhton is really great - thanks a ton for that!
I have a problem though (maybe it’s more of an annoyance than a real problem):
I get coding tips from Pylance and pylint. These are redundant, as they are duplications, but I am ok with that:
When using a builtin though (ON, CLOSED, etc.), pylint is fine with that (which it should be, as in .pylint.rc, these additional builtins are defined), but I get a complaint fom Pylance:
Is there a way to configure the plugins, so that Pylance either knows about the builtins or that I can disable this kind of tips from Pylance? Or maybe even configure things in a way, that only one linter is used?
I tried to find out how Pylance and pylint work in conjunction (to me they seem to have overlapping functionality here), but did not really succeed in getting information that let me understand this.
Thank you for the positive feedback! It is nice to hear from a user on these, I’ve been waiting for some feedback to know if they are helpful or broken.
Side note to anyone reading: I know that the only stubs currently available are quite outdated, I assure you I will be adding more as soon as I can, but my time is limited and I have another project that must come first right now.
You are correct that Pylance and pylint overlap, though not 100%. If you want you can disable pylint, I do not suggest that in the instructions because a lot of OH users have limited to no knowledge of Python, so the more help the better to point out mistakes.
You should read through the Usage and Reference pages in the stubs repo, they contain some examples of ways to get the most out of the stubs. In particular for your problem with the “built-ins” (actually the contents of the defaultScope in the Script Engine) you should look here.
Hi @CrazyIvan359 . thanks for the explanation. With that input I got most of my rules now set up with the typing. At the moment I am trying to reduce messages from pylint/Pylance which are not needed, so they don’t distract from the real problems.
I can control messages like “‘items’ is not defined” with this import for the typechecking:
import typing as t
if t.TYPE_CHECKING: # imports used only for type hints
from core.jsr223.scope import items
However: Pylance tells me “Import ‘core.jsr223.scope’ could not be resolved” and I do not get suggestions for members of ìtems.
(With “no suggestions” I mean, there is no popup, showing me the possible attributes and methods when I type items..)
Is that expected behaviour?
If not, I will doublecheck my setup vs. the available documentation to hopefully find what’s going wrong.
No, it is not expected behaviour. The items object is included in core.jsr223.scope.
First off, it sounds like you did not add the stubs from the Helper Libraries repo (they are packaged there so that you get a version matching the HLs you just downloaded).
This error tells me Pylance can’t find {OH_CONF}/typings/core/jsr223/scope/__init__.py where items is defined. Make sure you completed step 5 of the stubs installation. Also note the path above where Pylance is looking, if you copied the Core/typings folder into {OH_CONF}/typings you may have ended up with {OH_CONF}/typings/typings/core/jsr223/scope/__init__.py.
Second thing is more just an FYI in case you hadn’t already heard/discovered this: you can no longer reference Items as attributes of the items object in Python/Jython. This behaviour was added to mimic the DSL and JavaScript behaviour of being able to reference map/dictionary keys as if they are attributes of the map/dict. It was removed a few commits before I started maintaining the HLs because it was problematic.
If you are interested, items is actually an instance of org.openhab.core.automation.module.script.internal.defaultscope.ItemRegistryDelegate, which itself is just a Map<String, State> of Item states, so don’t expect too many methods there.
Well, I made a rather stupid error, but failed to recognize it until you pointed me to the installation part again.
All stub-files were placed correctly, but as I use the parent directory of {OH_CONF} as my workspace root, the paths in pyrightconfig.json and settings.json need to be adapted accordingly. Whilst doing that during my initial install, I missed two out of the three paths in settings.json so there we have the culprit.
Everything is working fine now - thanks again for the help.