Update documentation's "Prints" comments after #47502

[Mickeon]

See:

• Always add decimal when converting float to string #47502

To make it brief, print(a) # Prints {value} is a very common way in the class reference to represent a result. What follows it needs to be precisely what is printed in the console. This is not always the case, but it's a pretty consistent rule.

For transparency, my own notes on these kinds of comments is as follows:

• # Prints {value}: After a print call. (or similar).
  Suitable for beginner topics, where you want the user to see the result upon copying and pasting the code sample. {value} should be formatted exactly how it would be printed to the console. No periods, no quotes.

However, since #47502, whole floating-point numbers are always converted and printed with the trailing .0, making many of these comments inaccurate.

Although this is technically an error, this PR is worth debating about, as it actually makes readability worse in a vast majority of cases.
Either these comments are mostly fine as they are, we make a special exception just for Vectors, or we go ahead and always favour pure accuracy to not confuse the user.

[tetrapod00]

I think your original notes are still correct. If you're bothering to add a comment with the expected output, it should match the actual output.

I'm also not sure this decreases readability. In some other contexts (like shaders), adding the explicit .0 to whole number floats is favored, because it makes it clear you're working with a float-based type rather than an int-based type. In this case, I could take it or leave it, but it's not clearly a decrease in readability.

[Mickeon]

I have to say it somewhat impacts readability when multiple Vector types are involved (see the PR itself). This readability issue is somewhat similar to what this user brought up.
Keep in mind there can be a lot of numbers, dots, and commas packed within these codeblocks, oftentimes in the same line. Also, these numbers within comments have no syntax highlighting.

Problematic examples include:

• print(polygon) # Prints [(50.0, 50.0), (150.0, 50.0), (150.0, 150.0), (50.0, 150.0)]

• print(my_basis.x) # Prints (2.0, 0.0, 0.0).
  print(my_basis.y) # Prints (0.0, 4.0, 0.0).
  print(my_basis.z) # Prints (0.0, 0.0, 8.0).

• var a = AABB(Vector3(4, 4, 4), Vector3(8, 8, 8)).grow(4)
  print(a.position) # Prints (0.0, 0.0, 0.0)
  print(a.size)     # Prints (16.0, 16.0, 16.0)
  
  var b = AABB(Vector3(0, 0, 0), Vector3(8, 4, 2)).grow(2)
  print(b.position) # Prints (-2.0, -2.0, -2.0)
  print(b.size)     # Prints (12.0, 8.0, 6.0)
  

Note that one solution could also be to rework the examples to mitigate this issue, outright.

[tetrapod00]

Of the examples in your last comment, only the polygon example seems unreadable to me, since it's a long line. In the other examples, a single vector print on each line seems fine. But then again I've been mostly working with shader examples where floats always use .0 for clarity.

In general, I think accuracy should be prioritized, since these comments are presumably used to check your work when you copy-paste an example. Some readability loss is acceptable for that, IMO.

I don't feel all that strongly about this, though. Making an exception for vectors, or just overall not caring about matching the exact output, is also a reasonable choice.

[Mickeon]

Addressed the above review across the board.

[Mickeon]

This is not related to the PR but it looks like an obvious oversight.

[Repiteo]

Seems like we're sticking with the trailing zero format for floats, so this style checks out

[Repiteo]

Thanks!