2016-09-02 2 views
2

In dem O'Reilly-Video-Lernprogramm "Learning Cython" in Kapitel 5 gibt es ein Notebook namens strings.ipynb.Probleme beim Verstehen der Ausgabe in einem Jupyter-Notizbuch ("Learning Cython")

Erste Zelle lädt die Cython Erweiterung:

%load_ext cython 

Gefolgt von dieser Cython Zelle:

%%cython 
# cython: language_level=3 

def f(char* text): 
    print(text) 

Dann wird die folgende Zelle verwendet wird, zu zeigen, dass ein (Unicode) Zeichenfolge nicht als char* verwendet werden Argument:

Das Ergebnis ist ein TypeError Ausnahme.

All dies ist, was ich von den Bemerkungen des Autors in der Voice-Over erwarten würde. Doch das Ergebnis der nächsten Zelle:

f(b'It is I, Arthur, son of Uther Pendragon') 

war:

b'It is I, Arthur, son of Uther Pendragon' 

und stapfte mich.

ein einfaches print in der Funktion f verwendet hat, warum erscheint die Ausgabe, als ob es durch repr zuerst ausgeführt wurde, wenn sie innerhalb des Cython Code oben war es klar nicht Lauf durch repr?

Der Autor erwähnt nicht einmal dieses (zumindest für mich) unerwartete Ergebnis im Voice-Over.

Was gibt? Warum sieht die Ausgabe so aus, als ob sie zuerst durch repr geleitet wurde? Sind Bytefolgen in Python 3 nicht "druckbar" (d. H. Ohne str Methode) und fallen daher zurück auf repr?

PS: Ich muss zugeben, dass ich von Python 2.x komme und nicht zu viel mit Python 3.x zu tun hatte, also ist vielleicht der Unterschied darin.

Antwort

1

Weil es war. In Python 3 bytes_str verwendet bytes_repr internally:

static PyObject * 
bytes_str(PyObject *op) 
{ 
    if (Py_BytesWarningFlag) { 
     if (PyErr_WarnEx(PyExc_BytesWarning, 
         "str() on a bytes instance", 1)) 
      return NULL; 
    } 
    return bytes_repr(op); // call repr on it 
} 

Als solche print wird im Wesentlichen wissen, rufen repr(bytes_instance).

+0

Danke. Das erklärt es. Der Hinweis auf den jeweiligen C-Code ist eine wirklich nette Geste! – 0xC0000022L

Verwandte Themen