Hoe kan het afdrukken van een object resulteren in een andere uitvoer dan zowel str () als repr ()?

Ik testte een code op de tolk en merkte een onverwacht gedrag op voor de sqlite3.Row klasse.

Ik heb begrepen dat print obj altijd hetzelfde resultaat krijgt als print str (obj) , en typ obj in de interpreter krijgt hetzelfde resultaat als print repr (obj) , maar dit is niet het geval voor sqlite3.Row :

>>> print row       # the row object prints like a tuple
(u'string',)
>>> print str(row)  # why wouldn't this match the output from above?


>>> row             # usually this would be the repr for an object
(u'string',)
>>> print repr(row) # but repr(row) is something different as well!

Ik denk dat sqlite3.Row een subklasse van tuple moet zijn, maar ik begrijp nog steeds niet precies wat er achter de schermen gebeurt dat dit gedrag zou kunnen veroorzaken. Kan iemand dit uitleggen?

Dit werd getest op Python 2.5.1, niet zeker of het gedrag hetzelfde is voor andere Python-versies.

Weet niet zeker of dit al dan niet van belang is, maar de row_factory kenmerk voor mijn Verbinding is ingesteld op sqlite3.Row .

 17
toegevoegd bewerkt
Bekeken: 8
de bron
ro ru fr es pt de hi bn ar be
@kaloyan - Ik kan daar niets vinden dat mijn vraag beantwoordt, als je me er alsjeblieft naar kunt verwijzen.
toegevoegd de auteur Andrew Clark, de bron
Interessant gedrag. sqlite3.Row lijkt tuple niet te subclasseren, dus mijn gok is de speciale lijst met afgedrukte lijsten en/of tuples op basis van andere criteria dan overerving, maar ik kan niets vinden in de lijst documentatie die zou toegeven, laat staan ​​dit uit te leggen.
toegevoegd de auteur millimoose, de bron
Heb je gekeken naar stackoverflow.com/questions/1436703/& hellip; voor het plaatsen?
toegevoegd de auteur ktdrv, de bron

2 antwoord

PySqlite biedt de speciale native hook voor print , maar het implementeert __ repr __ of __ str __ niet. Ik zou zeggen dat dat een beetje een gemiste kans is, maar het verklaart tenminste het gedrag dat je waarneemt.

See pysqlite source: https://github.com/ghaering/pysqlite/blob/master/src/row.c#L241 And python docs: http://docs.python.org/c-api/typeobj.html#tp_print

11
toegevoegd
de bron
Ik heb dit onderwerp gelinkt in de bugtracker van pysqlite: code.google.com/ p/pysqlite/issues/detail? id = 4
toegevoegd de auteur Ondergetekende, de bron
@CiroSantilli Ik heb mijn antwoord bijgewerkt om rekening te houden met de migratie naar github. De slechte functionaliteit is echter nog steeds niet opgelost
toegevoegd de auteur Ondergetekende, de bron
Leuke vondst! Het lijkt erop dat de ontwikkelaars van sqlite tegen de aanbevelingen ingingen. Dit is waarschijnlijk de reden waarom dit niet op meer plaatsen wordt gezien. Uit de documenten: "Een type zou tp_print nooit moeten implementeren op een manier die andere uitvoer oplevert dan tp_repr of tp_str zou" en "het wordt aanbevolen om tp_print niet te definiëren, maar in plaats daarvan te vertrouwen op tp_repr en tp_str voor afdrukken".
toegevoegd de auteur Andrew Clark, de bron
@Ondergetekende de buglink is verbroken, is deze ergens anders terechtgekomen of zullen we een nieuwe openen (op bugs.python. org ?)
toegevoegd de auteur Ciro Santilli 包子露宪 六四事件 法轮功, de bron 
s = str(tuple(row))

is een tijdelijke oplossing als u de originele tuple-tekenreeksrepresentatie wilt.

Het is bijvoorbeeld handig als u de rij eenvoudig wilt loggen als in:

logging.debug(tuple(user_row))

Werkt omdat rijen iterabel zijn.

0
toegevoegd
de bron