Une implémentation de référence, c'est bien quand ça suit exactement la norme et quand ça n'expose aucun particularité.
ben python n'est pas défini par ses extensions... c'est un peu la définition d'une extension
Python est défini par la grammaire et la bibliothèque standard. N'importe quelle implémentation doit juste implémenter ça, et cela peut-être fait indépendamment du GC ou autre choix. (C'est peut-être juste plus facile
Après, ils s'est avéré que la bibliothèque standard n'était pas suffisant pour certains cas. Une des extensions la plus connus est sans doute numpy pour le calcul scientifique. Cela ne fait pas partie de la bibliothèque standard et les auteurs du projet ont choisi une approche implémentation dépendante, pour être efficace. Du coup les autres implémentations se trouvent défavorisés... Mais ce n'est pas la bibliothèque standard, ni la grammaire du langage donc ça ne fait pas partie du langage vraiment, c'est juste extrêmement dommage de ne pas pouvoir l'utiliser.
La solution serait d'inclure ces extensions dans la bibliothèque standard; mais ça risque de faire un énorme travail pour les implémentations alternatives...
L'autre solution étant d'utiliser les couches intermédiaires, comme expliquer dans les commentaires, mais cela suppose de changer la base de code existante... et vu la rapidité du passage à Python 3 (pourquoi Pyston ne commence pas directement par là ?) ben ça ne risque pas d'arriver bientôt...
En gros c'est bien dommage, mais c'est un peu difficile de changer les choses. Néanmoins, c'est un problème que les devs python ont l'air d'avoir bien en-tête et la situation va peut-être se décanter petit à petit.
Cela se passe déjà par un effort d'homogéneisation des extensions (voir les modules cffi et autres ou par exemple la PEP 465 sur un opérateur dédié pour la multiplication de matrix)
[^] # Re: Modules d'extension
Posté par manawy . En réponse à la dépêche Un projet de VM Python chez Dropbox et état des lieux des autres VM. Évalué à 5.
ben python n'est pas défini par ses extensions... c'est un peu la définition d'une extension
Python est défini par la grammaire et la bibliothèque standard. N'importe quelle implémentation doit juste implémenter ça, et cela peut-être fait indépendamment du GC ou autre choix. (C'est peut-être juste plus facile
Après, ils s'est avéré que la bibliothèque standard n'était pas suffisant pour certains cas. Une des extensions la plus connus est sans doute numpy pour le calcul scientifique. Cela ne fait pas partie de la bibliothèque standard et les auteurs du projet ont choisi une approche implémentation dépendante, pour être efficace. Du coup les autres implémentations se trouvent défavorisés... Mais ce n'est pas la bibliothèque standard, ni la grammaire du langage donc ça ne fait pas partie du langage vraiment, c'est juste extrêmement dommage de ne pas pouvoir l'utiliser.
La solution serait d'inclure ces extensions dans la bibliothèque standard; mais ça risque de faire un énorme travail pour les implémentations alternatives...
L'autre solution étant d'utiliser les couches intermédiaires, comme expliquer dans les commentaires, mais cela suppose de changer la base de code existante... et vu la rapidité du passage à Python 3 (pourquoi Pyston ne commence pas directement par là ?) ben ça ne risque pas d'arriver bientôt...
En gros c'est bien dommage, mais c'est un peu difficile de changer les choses. Néanmoins, c'est un problème que les devs python ont l'air d'avoir bien en-tête et la situation va peut-être se décanter petit à petit.
Cela se passe déjà par un effort d'homogéneisation des extensions (voir les modules cffi et autres ou par exemple la PEP 465 sur un opérateur dédié pour la multiplication de matrix)