Static typing in pylm API?

[Stefan311]

Working with the pylm api is very tedious. At least if you don't have the parameters and function names in your head. You have to search for everything in the source text or in the documentation. Parameters / function names are often distributed over several levels of class inheritance. Really caustic.

I am used to working with eclipse and java. There I can scroll through all the names available for this object by typing "." . This is very useful when working with 3rd party stuff.

For python I now use the Py Charm IDE, which also has this ability. However, this only works as far as the IDE sees through the API functions. However, this is not the case for most pylm functions. This is clearly due to the dynamic typing of python. I have seen that it is also possible to use static typing in python.

Would it be possible to use static typing in the pylm API?
And if so, would that help?

If you don't know what i am talking about:
https://medium.com/@ageitgey/learn-how-to-use-static-type-checking-in-python-3-6-in-10-minutes-12c86d72677b

[pmrowla]

Yeah we should probably be using type checking now that we dropped support for python 3.5. (3.5 doesn't have type checking, and was supported up until pylm 1.0)

There's some other remaining 3.5->3.6 migration related things that should also be done, like moving format strings to f-strings everywhere. I think there's also still some old legacy stuff that was originally intended for supporting Python 2 as well that should be removed.

[Stefan311]

Another question:
Is there a reason for using cmd.get("Calc") instead of cmd.Calc() ?
I think it would be less confusing to have direct method calls.

[pmrowla]

It's mostly due to how construct wants objects to expose a python dict equivalent interface to serialize things properly, and to make version-specific serialization to XML/text consistent with actual LiveMaker project LSC files (since a lot of commands have properties/attributes that should not exist at all in certain LM versions).

pylivemaker/livemaker/lsb/command.py

Lines 238 to 245 in eba1bec

	Attributes:
	type (:class:`CommandType`): Command type.
	args: OrderedDict of this command's arguments. If an argument is not applicable in
	a given LSB version, it's value should be set to None. Any arg set to None
	will not be serialized. If an arg is applicable in a given version and needs
	to be set to an empty value, use the empty string ''. This should make serialization
	for the .lsc formats consistent with how construct handles optional (version specific)
	values when reading to/from binary .lsb format.

Command classes could maybe be refactored to make everything attributes/properties and then use getattr/setattr everywhere for serialization, but it's not something I'd consider high priority

should also note that another reason it was done like this was bc it's how it was done in irl (the original library pylm is forked off of) and earlier on in the project I was a bit concerned about breaking compatibility with the irl API

[Stefan311]

Thank you for the explanation. I now understand why it is the way it is.
I think that it is necessary to create get* and set* methods anyway. At least if static typing is to be installed.
def get(key: str) -> any is as meaningless as the original.
A def getCalc() -> List[Command] would be much better.

I think also it is not necessary to remove the current functionality. It is required for many reasons, but it should not be a big deal to just add some wrapper functions.

[pmrowla]

It's a bit confusing since LM has the TComCalc/Calc command type, which is different than the named command.Calc arg/parameter, which several other command types can have. It would be better if LM had named the command type Eval or Exec, since what the Calc command does is just execute whatever expression is in Calc.Calc.

So are you looking for a cleaner way to get all of the commands in an LSB which have a certain parameter (in this case Calc)?

[Stefan311]

"Calc" was just an example. Maybe a bad/confusing one.
I am looking for a cleaner way to find out how to use the pylm API in general.