Track down all implications of the __repr__ changes of Zope objects

[Rotonen]

There are recent changes in how Zope represents its objects. This breaks, at least, some of our doctests.

Entry vectors for understanding what this is about:

zopefoundation/zope.site#8
https://travis-ci.org/plone/plone.testing/builds/435575510

[icemac]

Maybe we can add a __repr__ to OFS.SimpleItem which still contains the path in the ZODB.
See zopefoundation/persistent#96.

But maybe this is different from the actual problem you described here.

[thet]

@icemac +1 for adding __repr__ to OFS.SimpleItem and actually what I suggested while discussing this issue in Halle :)
In the context of Zope, the path is a worthy info to be included in __repr__

[Rotonen]

@icemac see also zopefoundation/persistent#95

Will need to find time to figure out the cPersistent side. Help welcome.

Doctests are not the only issue there - also bad tooling, which consumes and reunsafes the ’bunches of bytes’ OIDs can be.

[icemac]

@Rotonen I do not know enough C to be helpful to resolve zopefoundation/persistent#95. But I see your point and added the ticket to the Zope final issue list.

[jamadden]

zopefoundation/persistent#97 handles getting the type repr the same (and back to what it was) between C and Python; zopefoundation/persistent#98 handles formatting recognisable OIDs as hex ints.

[jamadden]

persistent 4.4.3 was released with those changes.

[gforcada]

plone/buildout.coredev#541

[pbauer]

So far we use PathReprProvider to fix most __repr__ issues as explained in #2590 (comment).
The issue with _p_repr is continued in zopefoundation/persistent#101