ENH: update master with develop for version 1.2.0

[Gui-FernandesBR]

Pull request type

• ReadMe, Docs and GitHub updates

Checklist

• Tests for the changes have been added (if needed)
• Docs have been reviewed and added / updated
• Lint (black rocketpy/ tests/) has passed locally
• All tests (pytest --runslow) have passed locally
• CHANGELOG.md has been updated (if relevant)

Current behavior

RocketPy version 1.1.X

New behavior

RocketPy get news features so we update it to 1.2.0.
See the CHANGELOG.md for more details.

Breaking change

• No

Additional information

I'm creating this draft PR so we can start reviewing it AND to check how the github actions are performing when the head branch is the master.

[Gui-FernandesBR]

Now I believe I've checked every file.

I'm going to open a PR solving the small comments I've made above.

[phmbressan]

Great to see this release on its final steps.

Something that stood out to me is that most of the developed features also had a set of tests.

[phmbressan]

I agree, mnt is already quite often being used here.

[phmbressan]

I agree, my suggestion would be creating a class variable, e.g. ARITHMETIC_TYPES.

In another opportunity we could also double check if there are no redundancies in these types and if there is no other way to support arithmetic with np types besides enumerating all of them.

[Gui-FernandesBR]

I agree, my suggestion would be creating a class variable, e.g. ARITHMETIC_TYPES.

In another opportunity we could also double check if there are no redundancies in these types and if there is no other way to support arithmetic with np types besides enumerating all of them.

Is it really better to make it a class attribute? We may need this being used out of the Function class eventually, therefore not attaching this constant to a class might be a better idea imo. I would simply define it at the top of the file as a python constant variable in UPPERCASE

[phmbressan]

Is it really better to make it a class attribute? We may need this being used out of the Function class eventually, therefore not attaching this constant to a class might be a better idea imo. I would simply define it at the top of the file as a python constant variable in UPPERCASE

Both solutions work of course.

My argument for it being a class variable (a variable pertaining to the class, such as Function.ARITHMETIC_TYPES) is that I believe that this variable only makes sense in a Function class related context.

In the end, the choice is mostly stylistic and I agree with answer given here . To sum up, I am perfectly happy with both ways, although I have a small semantic preference toward a class variable.

[Gui-FernandesBR]

@phmbressan I recommend you reading this page: https://numpy.org/doc/stable/reference/generated/numpy.isscalar.html

No, using isscalar doesn't save our lives because a string is also a scalar apparently (???).
But they do a good recommendation: """If you need a stricter way to identify a numerical scalar, use isinstance(x, numbers.Number), as that returns False for most non-numerical elements such as strings."""