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 - rpm-python inconsistency with documentation
Summary: rpm-python inconsistency with documentation
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-13 14:15 UTC by Miroslav Suchý
Modified: 2014-02-14 07:44 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-14 07:44:52 UTC


Attachments (Terms of Use)

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).


Note You need to log in before you can comment on or make changes to this bug.