Edits to DPF-Core RST and TXT files

[PipKat]

@PProfizi I've done a quick edit to the RST and TEXT files. Initially, one asterisk was used to tag terms in italic and two asterisks were used to tag UI elements in bold. Given that so many tags for terms were in bold, I changed all tags to bold. I will consult later with the PyAnsys team to evaluate this approach. If there is time before the release, I can go through the PY files for the API reference and the examples, but I am not sure that there is enough time to do this. (I believe that you told me that any edits had to be in by the end of the year.) One PyAnsys team has replacing "optional" in the parameter description with "default: x" where x is the default value. This makes the default more visible and eliminates words in the subsequent description. We could perhaps do this in your library documentation the next time the PY files for the API reference section are edited.

[codecov]

Codecov Report

Merging #729 (c1ef1b0) into master (d503907) will increase coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #729      +/-   ##
==========================================
+ Coverage   88.64%   88.70%   +0.05%     
==========================================
  Files          71       71              
  Lines        8088     8091       +3     
==========================================
+ Hits         7170     7177       +7     
+ Misses        918      914       -4     

[PProfizi]

Hi @PipKat, thank you for this! I agree that making this more coherent is good.
As for the release deadlines, I do not think we now have specific ones. PyDPF-Core will be released whenever necessary, and now that DPF Server is released every 4-6 weeks, this means we will continue with a release frequency of around one per month.
This means you can work on this whenever you have time, and it will be deployed live within a month.

Concerning the "default" for other pyansys libraries, I think this comes from their use of sphinx-autodoc-typehints, which automatically builds the type definitions in docstrings based on the type hinting done in the code. This is integrated in PyDPF-Post but apparently not yet in PyDPF-Core. Once this is integrated, the docstring for an optional argument with a default value will by default look like what you described without the need to write it explicitely. You can find the related discussion here

[PipKat]

@PProfizi Thanks for catching so many small errors! I appreciate your careful review and have incorporated all of your proposed changes. Please review/accept and merge if you are OK with doing so!

[PProfizi]

Hey @cbellot000 @anslpa, could you please take a look at the proposed changes for user_guide/server_types.rst?
I am not so sure the new wording fits conveniently with what we meant initially.

[PipKat]

@cbellot000 Hi, there! Any chance that you can review user_guide/server_types.rst per Paul's request soon so that I can get this PR closed and merged?

[PProfizi]

@cbellot000 Hi, there! Any chance that you can review user_guide/server_types.rst per Paul's request soon so that I can get this PR closed and merged?

Hi @PipKat, I think she was okay with it, so I'll approve myself and you can merge.

[PipKat]

@PProfizi Thanks for the update!