Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1064904

Summary: rpm-python inconsistency with documentation
Product: [Fedora] Fedora Reporter: Miroslav Suchý <msuchy>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: ffesti, jzeleny, novyjindrich, packaging-team-maint, pknirsch, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-14 07:44:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Miroslav Suchý 2014-02-13 14:15:41 UTC
Description of problem:
When I run this script:
http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch16s03s05.html
I will get:
...
Files:
<rpm.fi object at 0x145cbe8>
Provides:
<rpm.ds object at 0x145cc38>
Requires:
<rpm.ds object at 0x145cc38

Instead of human readable list. This seems to be regression, because it obviously worked in past. But I test it even on RHEL6 and I get 
  <rpm.fi object at 0x145cbe8>
there as well. :(


Version-Release number of selected component (if applicable):
rpm-python-4.11.1-7.fc20.x86_64

How reproducible:
always

Comment 1 Panu Matilainen 2014-02-14 07:44:52 UTC
The RPM Guide documents rpm 4.4.x (API, behavior etc), there are lots of things that are not documented by it or are just no longer valid, as is the case here.

The short version is that the 4.4.x behavior of these objects is plain broken, and wont be coming back. So NOTABUG, its the former behavior that was buggy.

The longer version is that the objects themselves are bizarre and broken in various ways... As for the 4.4.x print behavior, it was implemented as tp_print methods, but http://docs.python.org/2/c-api/typeobj.html#PyTypeObject.tp_print says:
"A type should never implement tp_print in a way that produces different output than tp_repr or tp_str would."

http://docs.python.org/2/c-api/typeobj.html#PyTypeObject.tp_repr says:
"Ideally, this function should return a string that, when passed to eval(), given a suitable environment, returns an object with the same value. If this is not feasible, it should return a string starting with '<' and ending with '>' from which both the type and the value of the object can be deduced."

Both rpm.fi and rpm.ds are cases of "this is not feasible", so they return the default '<type object at address>' string.

And as for tp_str, http://docs.python.org/2/c-api/typeobj.html#PyTypeObject.tp_str says:
" This function should return a “friendly” string representation of the object, as this is the representation that will be used by the print statement.

When this field is not set, PyObject_Repr() is called to return a string representation."

Returning partial contents of a complex container object as an arbitrarily formatted string is not any saner, so they fall back to tp_repr. tp_str would only make sense for individual entries from these containers, but the bizarre way especially rpm.fi iteration is implemented prevents doing that either.

rpm >= 4.12 will have new, saner objects for representing files (maybe dependencies too, but not implemented atm).