[Samuele Pedroni] > btw in 2.1 there was no 0x (at least on Windows): > > Python 2.1.3 (#35, Apr 8 2002, 17:47:50) [MSC 32 bit (Intel)] on > win32 Type "copyright", "credits" or "license" for more information. > >>> class C: pass > ... > >>> C > <class __main__.C at 007DE55C> > >>> Yup. Everywhere Python uses printf's %p format code to display pointers, C doesn't define anything about what the output "looks like". In really old versions of MS C, %p used to embed a colon in the address too (segment:offset). For stuff going thru PyString_FromFormat(), I added crap to that function to special-case %p formats, near this comment: /* %p is ill-defined: ensure leading 0x. */ But older versions of Python don't have that hack -- and not all uses of %p in Python go thru PyString_FromFormat (but most do now). > ... > If I were to put an 'at 0x' in there, I would be tempted to revert > to that value (System.identityHashCode) but given that is not unique > and != id(.), it is rather less useful. CPython certainly intends to force a leading 0x (not 0X either -- it's forcing lowercase 'x' too) in such displays now. It's not doing anything to force hex display of the rest, although I don't know of a platform C %p that doesn't produce hex. Still, displaying id() in hex is also an intent. IOW, CPython is enduring some pain to try to make this consistent too; it's not only Jython that can't get a free ride here.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4