Products.cmfplone: 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:

https://github.com/zopefoundation/zope.site/issues/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 https://github.com/zopefoundation/persistent/pull/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]

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

[jamadden]

persistent 4.4.3 was released with those changes.

[gforcada]

https://github.com/plone/buildout.coredev/pull/541

[pbauer]

So far we use PathReprProvider to fix most __repr__ issues as explained in https://github.com/plone/Products.CMFPlone/issues/2590#issuecomment-433746872.
The issue with _p_repr is continued in https://github.com/zopefoundation/persistent/issues/101