Hi internals,
Currently, print_r() will print ints and floats in exactly the same way, despite the fact that they are different types
and floats may cause a TypeError (or be treated differently from integers, e.g. avro encoding) when used where an integer is expected.
This is not documented in https://www.php.net/print_r
I've created https://github.com/php/php-src/pull/6611 , which proposes to have print_r() dump floats such as 1.0 as 1.0, like var_export currently does.
php > print_r(1.0); // old behavior, proposed behavior is 1.0
1
php > print_r(1);
1
php > var_export(1.0);
1.0
php > var_export(1);
1
Benefits:
-
print_r()previously make it look as if a value was an int when it really was a
float. When usingprint_r()to inspect the value of an array, TypeErrors or differences in behavior can be unintuitive
if you think the value is really an integer when it's actually a float.This change should save time debugging in the long run for users unfamiliar with this behavior.
(https://www.php.net/print_r has no mention of the behavior seen for floats in the summary or user-submitted comments) -
print_r()output now shows a difference between 0.0 and 0,
which is useful for generating diffs between expected and actual values in test failures, etc.
Cons:
- Existing tests of php, pecl extensions, and composer libraries need to be changed if they involve the raw output of
print_r and dumping float values.
If this is merged, tests would need to normalize print_r output or use format string expectations
to pass in both 8.0 and 8.1 (or switch tovar_dump(),var_export(), etc.)
Thanks,
- Tyson
Le 17 janv. 2021 à 16:58, tyson andre tysonandre775@hotmail.com a écrit :
Hi internals,
Currently,
print_r()will print ints and floats in exactly the same way, despite the fact that they are different types
and floats may cause a TypeError (or be treated differently from integers, e.g. avro encoding) when used where an integer is expected.
This is not documented in https://www.php.net/print_r
This is the same behaviour as print (and asecho). Note also that there is also no distinction for print/print_r in rendering the string "1", the integer 1, and the booleantrue. I think that the original intention of print_r was to have a “recursive” version of print.
If some action is to be taken, I suggest to deprecate print_r.
—Claude
Hi Tyson,
I was taught in school that trailing zeros and the decimal point can be
omitted when writing a number. It reads much better when you don't have to
see all the zeroes following the decimal point. When humans write a number
that has no digits after the decimal point they don't write the decimal
point. print_r is designed to print the data in a human-readable format.
There should be no information about the variable type. If you would like
to see the data together with the type then you can use var_dump. If you
want to see the data exactly as it is stored internally then use
var_export.
print_r is meant to display the data recursively in a friendly way.
Adding the unnecessary decimal point is against that.
On a technical note. print_r and print display data after casting it to
a string. The way PHP is currently designed is that when you cast 1.0 to a
string it becomes "1". Same with boolean TRUE. If you want to change the
way that floats and booleans are represented as strings then you would have
to change the way that the cast to string works. This would be a major
change.
Kind Regards,
Kamil