Quelles sont les différences entre le niveau de langage 3 de Cython et 3str ?

Question

Dans la prochaine version de Cython 3.0, 3str language_level (qui a été introduit avec Cython 0.29 ) devient le nouveau défaut à la place du défaut actuel 2 c'est-à-dire si le niveau de langue n'est pas défini ( comment régler ), nous obtenons l'avertissement suivant :

FutureWarning : La directive Cython 'language_level' n'est pas définie, nous utilisons '3str'. pour le moment (Py3). Ceci a changé par rapport aux versions précédentes ! Fichier : /home/ed/mygithub/cython/foo.pyx tree = Parsing.p_module(s, pxd, nom_du_module_complet)

Mais quelles sont les différences entre 3str y 3 niveaux de langage et pour quel code y aura-t-il des différences dans le comportement des modules compilés avec 3str y 3 les niveaux de langue ?

Answer 1

TLDR : 3str ne suppose pas que les chaînes de caractères sont unicode sous Python2.x, ce qui facilite la migration de Python2.x à Python3.

Ce n'est pas une réponse complète car je ne connais pas le code pour mettre en évidence les différences et cela laisse encore de la place pour des questions, mais cela peut être utile, Nouveautés de cython 0.29 :

Un nouveau niveau de langue '

Cython 0.29 prend en charge un nouveau paramètre pour l'attribut language_level directive, language_level=3str qui deviendra le nouveau niveau de langue par défaut dans Cython 3.0. Nous l'avons ajouté dès maintenant, afin que les utilisateurs puissent en bénéficier dès maintenant, et préparer déjà leur code au changement à venir. Il s'agit d'un paramètre " intermédiaire ", qui permet de bénéficier de tous les avantages de Python 3 qui ne sont pas compatibles avec la syntaxe de Python 2.x, mais sans exiger que tous les littéraux de chaîne non fixés deviennent des chaînes Unicode lorsque le code compilé s'exécute en Python 2.x. . C'était l'un des plus gros problèmes de la migration générale vers Py3. Et dans le contexte de l'intégration de Cython avec du code C, cela a gêné nos utilisateurs encore un peu plus que dans du code Python. Nos objectifs sont de permettre aux nouveaux utilisateurs qui viennent de Python 3 de compiler facilement leur code avec Cython et de permettre aux bases de code existantes (Cython/Python 2) d'utiliser les avantages avant qu'ils puissent faire un changement complet.

Également noté par Page de manuel de Debian pour cython :

--embed[=<method_name>] Générez une fonction main() qui intègre l'interpréteur Python.
-2 Compilation basée sur la syntaxe et la sémantique du code Python-2.
-3 Compilation basée sur la syntaxe et la sémantique du code Python-3.
--3str Compilation basée sur la syntaxe et la sémantique du code Python-3 sans supposer l'unicode par défaut pour les littéraux de chaîne sous Python 2.

Enfin noté par documentation sur le cython :

El 3str permet d'activer la sémantique Python 3 mais ne modifie pas l'option str et des chaînes de caractères littéraux sans préfixe pour le type unicode lorsque le code compilé s'exécute dans Python 2.x.

Answer 2

language_level est utilisé pour indiquer dans quelle version de Python le fichier pyx est écrit. Ainsi, pour language_level=3 le comportement du code pyx qui en résulte est comme s'il était exécuté en Python3, même lorsque l'extension résultante est exécutée avec Python2 (voir une explication plus détaillée aquí ).

Niveau de langue 3str signifie "sémantique Python3, mais avec des littéraux str (également dans Python2.7)". - donc str dans le nom. Quelles sont exactement les conséquences ?

Python3 : Lorsqu'il est construit dans/pour Python3, il n'y a pas de différences entre les niveaux. 3 et le niveau 3str .

Dans Python3, str es unicode donc le type de

# foo.pyx
def test():
   return type("aaa")

restera la même ( str ) pour language_level=3 y language_level=3str .

Python2 : La situation est différente lorsqu'il s'agit de construire avec/pour Python2. avec language_level=3 le résultat de ce qui précède test -La fonction sera unicode et avec language_level=3str le résultat sera str (qui est un octet dans Python2). Mais aussi pour Python2, dans tous les autres cas, 3 y 3str ont le même comportement.

---

Ce serait une erreur de penser, que

cdef char *c_string = "some string"

n'a pas pu être construit avec language_level=3 (et construit avec succès avec 3str pour Python2, comme "une certaine chaîne" ont été bytes ), car "some string" est unicode et les littéraux unicodes ne peuvent être coercitifs qu'à l'égard de Py_UNICODE* .

Le littéral du côté droit n'est pas un objet Python au départ, mais juste une chaîne C dans le code C généré.