MNT: making simple refactors in the Flight class

[Gui-FernandesBR]

Pull request type

• Code maintenance (refactoring, formatting, tests)

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

Current behavior

The Flight class is one of the most complicated to be read. Regardless the sophisticated u_dot, some functions/methos were added a long time ago and needs an update.
The subclass FlightPhases is barely documented, and its error messages looks like each other too much.

New behavior

• Improving readability and fixing some "mistakes"
• The reason I'm adding more lines than removing is basically due the new docstrings that were missing.
• I really hope you like the additions and find them more easy-to-read

Something important:

• I recently found this problem of having mutable default arguments in python functions (https://www.codecademy.com/learn/learn-intermediate-python-3/modules/int-python-function-arguments/cheatsheet). Honestly, I think "fixing" this was a bit too much of precautions as that error would probably never happens to us. But it's Python, we should follow conventions when they exists, future devs/users may appreciate this habit.

Breaking change

• No

Additional information

• Some commits have a longer description if you dropdown it.
• I stopped making changes because the PR was getting too big already, but more improvements are still welcome.
• The module is too large, with more than 3k code lines. Effort on increasing readability are more than necessary

[Gui-FernandesBR]

Copying the commentary here in case we need it in the future:

Ok, this is actually the best PEP to understand about the problem: https://peps.python.org/pep-0597/

Summarizing... It actually does not matter that much in this case since we are just saving a text file with numbers separated by comma. Any encoding should work here.

However, not specifying the encoding when using open() is a bad practice since PEP0597. The 'utf-8' is standard in Python and is usually more flexible than ascii.

To be "platform-dependent", i.e. to write the files using the same encoding as the local machine, it's possible to use encoding="locale", but this only works on python 3.10 and above. See this section for a short description: https://peps.python.org/pep-0597/#for-experienced-users

All in all, this is not a problem for now. I'm expecting that one day in the future we can revisit this issue in the long term future when Python start to enforce the explicit encoding definition everywhere.