Thanks for the bug report! Prioritizing P3 - this will be taken care during the
next sprint, at the latest (most likely sooner than that, though).

Could this be changed to implement a better __str__/__repr__ for enums? From
python docs:

"It is possible that the tp_print field will be deprecated. In any case, it is
recommended not to define tp_print, but instead to rely on tp_repr and tp_str
for printing."

Also: "The print function is only called when the instance is printed to a real
file; when it is printed to a pseudo-file (like a StringIO instance), the
instance’s tp_repr or tp_str function is called to convert it to a string."

Forgot the link :)

http://docs.python.org/c-api/typeobj.html?highlight=tp_print#tp_print

Ah, so the documentation seems to be inconsistent, because whatever your quote
says, the fact is that when you derive from the int type (as PySide enums do),
it's necessary to re-implement tp_print if you want print's documentation to
hold true:
http://docs.python.org/library/functions.html#print
http://docs.python.org/reference/simple_stmts.html#the-print-statement

At any rate, there are three hypotheses:
- the current PySide behavior is OK and the print() documentation is wrong.
- the tp_print documentation forgot to say that in the (rare) case when you
inherit from int you still have to redefine tp_print.
- int's tp_print implementation is buggy because it doesn't take derived
classes into account.

The first hypothesis seems very unlikely, so PySide's behavior will have to
change either through a fix in Python or a fix in PySide.

Did you check that the bug happens even with Python 2.7(.1)?


PS: the issue of a better __str__/__repr__ is completely independent of this
bug: a tp_print implementation would consider __str__ as a black box.

Fixed in commit Shiboken/32938470.

release beta4