MicroPython ne prend pas en charge toutes les bibliothèques standard Python. Les modules exclus ne conviennent pas pour une utilisation avec le contrôleur intégré. Certains modules ne peuvent pas être mis en œuvre par le microcontrôleur en raison d'une consommation de mémoire élevée (comme sqlite3) ou d'un manque de fonctionnalités matérielles requises (comme le multitraitement). Une liste complète des bibliothèques standard Python peut être trouvée ici: Python 3.4 Standard lib
Il existe quelques différences entre CPython3 (une implémentation de référence du langage Python3) et MicroPython. Les différences se divisent en trois catégories. Chaque catégorie a un statut différent concernant la possibilité que les éléments classés dans chaque catégorie changent.
MicroPython est destiné aux environnements plus contraints, en particulier les microcontrôleurs avec plus de performances et de contraintes de mémoire que les systèmes «de bureau» exécutant CPython3. En bref, MicroPython doit être conçu avec cet environnement contraint à l'esprit, en excluant les fonctionnalités qui ne s'adaptent pas ou ne s'adaptent pas au système cible. Il est peu probable que vous changiez la différence de «conception».
MicroPython n'est pas fourni avec une bibliothèque standard étendue de modules. Il est impossible et déraisonnable de fournir une bibliothèque CPython3 complète. De nombreux modules ne sont ni disponibles ni utiles dans le contexte des systèmes embarqués. Il n'y a pas assez de mémoire pour déployer la bibliothèque entière sur un petit appareil. Par conséquent, MicroPython adopte une approche minimale. Seul le type de données de base (+ modules spécifiques à un matériel particulier) est inclus dans l'interpréteur, et le reste dépend du tiers de l'application utilisateur particulière. Le projet micropython-lib fournit une bibliothèque standard non monolithique pour MicroPython (Forum. viewtopic.php? f = 5 & t = 70))
Contrairement à CPython3, qui utilise des comptages de références, MicroPython utilise le garbage collection comme principal moyen de gestion de la mémoire.
MicroPython n'implémente pas le modèle de données objet CPython complet, mais seulement un sous-ensemble de celui-ci. La méthode __new__, qui est une utilisation avancée de l'héritage multiple, peut ne pas fonctionner. L'ordre de résolution de la méthode est différent (# 525). Les métaclasses ne sont pas (du moins pas encore) prises en charge.
La conception de MicroPython n'est pas basée sur des objets descripteurs. Jusqu'à présent, il a implémenté toutes les fonctionnalités natives de Python (y compris les propriétés), à l'exception des descripteurs explicites. Les descripteurs sont considérés comme des fonctionnalités «trop dynamiques», ce qui contredit l'objectif d'être rapide et efficace. Cependant, en tant que fonctionnalité opt-in, nous avons implémenté une prise en charge simplifiée des descripteurs.
Étant donné que MicroPython est "micro", il implémente uniquement un sous-ensemble de fonctionnalités et de paramètres d'une fonction ou d'une classe particulière. Chaque problème particulier peut être traité comme une «différence d'implémentation» et résolu, mais il est peu probable qu'il couvre 100% des fonctionnalités de CPython.
Étant donné que MicroPython est "micro", il ne prend en charge qu'un sous-ensemble minimal de fonctionnalités d'introspection et de réflexion (noms d'objets, chaînes de documents, etc.). Chaque fonctionnalité particulière est traitée comme une différence d'implémentation et peut être résolue, mais il est peu probable qu'elle couvre 100% des fonctionnalités de CPython.
La fonction print () ne vérifie pas les structures de données récursives que CPython gère. Cependant, comme il vérifie l'utilisation de la pile, l'affichage des structures de données récursives ne plante pas en raison d'un débordement de pile. Il est possible d'implémenter un traitement de type CPython pour les structures de données récursives au niveau de l'application Python. Créez une fonction qui conserve un historique de chaque objet référencé et remplacez le print () intégré par une fonction personnalisée. Une telle implémentation, bien sûr, peut utiliser beaucoup de mémoire. Par conséquent, il n'est pas implémenté au niveau MicroPython.
MicroPython optimise la gestion des variables locales et n'enregistre ni ne fournit d'informations d'introspection. Par exemple, locals () n'a pas d'entrées pour les variables locales.
Certaines fonctionnalités peuvent ne pas être compatibles avec les systèmes contraints ou ne pas être faciles à mettre en œuvre efficacement. Ces caractéristiques sont appelées «différences de mise en œuvre» et certaines peuvent être sujettes à des développements futurs (après discussion et considération correspondantes). De nombreuses «différences d'implémentation» affectent la taille et les performances des implémentations MicroPython, de sorte que certaines cibles MicroPython peuvent ne pas implémenter certaines fonctionnalités.
Le support Unicode est en cours. Il est basé sur une représentation interne utilisant UTF-8. Prise en charge complète des chaînes contenant des échappements Unicode aux formats \ xNN, \ uNNNN et \ U000NNNNN. \ N {...} n'est pas pris en charge. # 695.
La finalisation d'objets (méthode __del__ ()) n'est pas prise en charge par le type intégré, mais est prise en charge par la classe d'utilisateurs. Ceci est pris en charge par # 245.
Le sous-classement intégré est partiellement implémenté, mais présente diverses différences et problèmes de compatibilité avec CPython. # 401
Il ne prend pas en charge les flux d'E / S tamponnés (io.TextIOWrapper et ses superclasses).
Le mot-clé ʻasync def est simplifié et implémenté comme suit: Il n'y a pas de type d'objet "coroutine" séparé, et ʻasync def apparaît dans le corps de la fonction comme "yield" ou "yield from". Définissez simplement une fonction de générateur qui ne nécessite rien. ʻAsync def` Ne détecte ni n'autorise l'utilisation de "yield" ou "yield from" dans la fonction.
«asynchroniser avec» doit être équivalent à la description dans PEP492.
«async for» doit être équivalent à la description dans PEP492.
Il n'y a pas de support pour les "objets de type futur" dans la méthode __await__. wait n'est disponible que sur les collouts et les générateurs (pas sur les "objets de type futur"). C'est aussi juste un sucre de syntaxe «rendement de», acceptant les itérables et les itérateurs que CPython n'autorise pas.
La prise en charge par exemple de __dict __ est facultative (désactivée dans de nombreux ports) et en lecture seule, donc foo .__ dict __ ['bar'] = 23 oufoo .__ dict __. Update ({'bar': 23})ne fonctionne pas. # 1757, # 2139
Les problèmes connus sont essentiellement considérés comme des bogues ou des fonctionnalités incorrectes et seront corrigés. Par conséquent, idéalement, vous devriez également vous référer au ticket de bogue pour ce qui est écrit ici. Cependant, notez que ces problèmes connus ont des priorités différentes, en particulier dans un large éventail de processus de développement. Par conséquent, si vous êtes réellement concerné par le problème, veuillez ajouter les détails du cas à votre ticket (inscrivez-vous si le ticket n'existe pas déjà) pour aider à le refléter dans votre plan. L'envoi de correctifs est encore plus productif. (Notez que la liste des modules / classes non implémentés ne contient que ceux qui sont considérés comme très importants à implémenter; comme mentionné précédemment, MicroPython fournit une bibliothèque standard complète. Absent.
Certaines fonctions ne vérifient pas suffisamment leurs arguments et peuvent planter si le mauvais type d'argument est passé. ~~
Certaines fonctionnalités utilisent ʻassert () `pour vérifier les arguments. Mauvais type d'argument passé → Face à de mauvaises conditions conduit à un crash. Remplacez-le par une exception Python.
~~ Les fonctions intégrées ne peuvent pas être remplacées de la manière habituelle. Jusqu'à présent, le module "builtins" n'a pas été implémenté, donc tous les remplacements ne fonctionneront que dans le module actuel. # 959 ~~
La prise en charge persistante du bytecode (.pyc analogique) est en version bêta.
La fonction ~~ print () n'utilise pas l'infrastructure de flux Python, mais utilise directement la fonction C printf () sous-jacente. Autrement dit, la substitution de sys.stdout n'affecte pas print (). # 209 ~~
Actuellement, sys.stdin, sys.stdout et sys.stderr ne peuvent pas être remplacés (pour plus d'efficacité, ils sont stockés dans une mémoire en lecture seule).
~~ L'utilisation plus avancée des importations de packages / modules n'a pas encore été totalement implémentée. # 298 ~~
~~ La gestion des exceptions par le générateur n'est pas totalement implémentée. ~~ (Certains petits détails doivent encore être traités.) # 243
str.format () peut manquer des fonctionnalités avancées / ambiguës (Mais presque entièrement mis en œuvre). \ # 407, # 574
L'opérateur de format de chaîne ~~% a peut-être manqué des fonctionnalités plus avancées ~~ # 403, [# 574] ](Https://github.com/micropython/micropython/issues/574)
L'implémentation du module struct (nommée ʻustruct) devrait avoir toutes les fonctionnalités de base ~~, mais quelques sucres de syntaxe (comme la répétition de chaînes de types) Non ~~. Renommé en fonction struct` complète qui fonctionne au niveau Python
Au lieu du module «re», le module «ure» minimisé est un sous-ensemble de la fonctionnalité fournie par re. micropython-lib fournit une implémentation complète basée sur le moteur "PCRE" pour le portage "unix" # 13
Jusqu'à présent, il n'y a que le début du module ʻio` et de la hiérarchie des classes.
La classe collections.deque n'est pas implémentée.
L'objet ~~ memoryview n'est pas implémenté. ~~
L'allocation / suppression de tranches de conteneur n'est que partiellement mise en œuvre. # 509
17.3 Le découpage des arguments n'est que partiellement implémenté.
~~ Les mots clés et les arguments contenant uniquement des mots clés nécessitent plus de travail. ~~ # 466, # 524
Seul le support de base est disponible pour la méthode __new__ \ # 606, [# 622](https: // github. com / micropython / micropython / issues / 622)
~~ opération de bit long int n'est que partiellement implémentée (X & 0xffffffff idiome pour la tâche de transtypage de valeurs 32 bits signées non signées). ~~ # 1810
Recommended Posts