Cross platform difference: Object hex address case

[Follower]

Thanks for the responses.

[[Summary]]
I guess I was trying to have my unit tests know "too much", by having
at least some of the string representation hard-coded in the unit
test. My tests now just determine the complete string representation
at run-time.

[[Additional Comments]]
The actual unit test itself is testing a 'SessionInfo' object which
contains  key/value pairs where the values can (originally) be
anything but are forced into a string value for consistent and "safe"
retrieval. (Much hand-waving here...)

The unit test is checking that the string representation of the
'SessionInfo' object is a formatted string consisting of the keys
along with their stringified value. So the string representation of
each item/object is embedded in another string which represents the
'SessionInfo' object.

[Tim Peters]
> Whether hex() produces lower or upper case actually depends on its argument:
Is that intentional? Or useful?

> You can write a cleverer test than that <wink>.
I'm tempted to show how the *actual* test works, but in the end it's
fairly inconsequential, so I won't waste anyone's time. But if
"cleverer" means "better", how would *you* test it? (Admittedly, my
original example didn't show the "embedded" nature of my actual usage
of the string representation of the object.)

> > it would seem the Windows version's behaviour is non-standard.
> Thw Windows %p behavior is surprising to Linux users, and vice versa.
> Python doesn't have a preference.
I should probably have used the phrase "seems inconsistent with
hexadecimal case usage elsewhere in Python", but as it happens it's
not inconsistent anyway, since you've shown that Python doesn't use
case consistently for hexadecimals elsewhere.

I guess it all goes to show how cross-platform Python helps you find
out what's really "Python" & what's not... :-)

Thanks again for the responses.

--Phil.