Présentation de Bython : Python avec des accolades

Présentation de Bython : Python avec des accolades sans les espaces blancs, Bython est un préprocesseur Python qui traduit les accolades en indentation.

Voici la présentation de Bython, le langage Python avec des accolades. Bython est un préprocesseur Python qui traduit les crochets en indentation. La raison ? Parce que Python est génial, mais les espaces blancs sont horribles.

Caractéristiques principales

• "Oubliez" l'indentation. Vous devriez toujours écrire un beau code, mais si vous vous trompez avec les tabulations/espaces, ou si vous copiez un morceau de code dans un autre qui utilise un style d'indentation différent, il ne sera pas cassé.
  
  
• Utilise Python pour l'interprétation, ce qui signifie que tous vos modules existants, comme NumPy et Matplotlib, fonctionnent toujours.

Exemple de code

Code:

---

1 2 3 4 5 6 7 8 9

def print_message(num_of_times) { for i in range(num_of_times) { print("Bython is awesome!"); } }   if __name__ == "__main__" { print_message(10); }

---

Installation de Bython

Vous pouvez installer Bython directement depuis PyPI en utilisant pip (avec ou sans sudo -H, selon votre installation de Python) :

Code:

---

$ sudo -H pip3 install bython

---

Si, pour une raison ou une autre, vous souhaitez l'installer à partir du dépôt git, vous pouvez utiliser git clone et faire une installation locale à la place :

Code:

---

1 2 3

$ git clone https://github.com/mathialo/bython.git $ cd bython $ sudo -H pip3 install .

---

La version git est parfois un peu en avance sur la version PyPI, mais pas de manière significative.

Pour désinstaller, lancez simplement

Code:

---

$ sudo pip3 uninstall bython

---

ce qui annulera tous les changements.


Introduction rapide

Bython fonctionne en traduisant d'abord les fichiers Bython (terminaison de fichier suggérée : .by) en fichiers Python, puis en utilisant Python pour les exécuter. Vous avez donc besoin d'une installation fonctionnelle de Python pour que Bython fonctionne.

Pour exécuter un programme Bython, il suffit de taper

Code:

---

$ bython source.by arg1 arg2 ...

---

pour exécuter source.by avec arg1, arg2, ... comme arguments de ligne de commande. Si vous voulez plus de détails sur la façon d'exécuter les fichiers Bython (drapeaux, etc.), tapez

Code:

---

$ bython -h

---

pour afficher la page d'aide intégrée. Vous pouvez également consulter la page de manuel en tapant

Code:

---

$ man bython

---

Bython comprend également un traducteur de Python vers Bython. Il est accessible via la commande py2by :

Code:

---

$ py2by test.py

---

Cela créera un fichier Bython appelé test.by. Une explication complète de py2by est disponible en tapant

Code:

---

$ py2by -h

---

ou en consultant la page de manuel :

Code:

---

$ man py2by

---

Structure du dépôt

Pour l'instant, Bython est écrit en Python. Le dépôt git est structuré en 4 répertoires :

• bython contient un paquetage Python contenant l'analyseur et d'autres utilitaires utilisés par le script principal
  
  
• etc contient les pages de manuel et d'autres fichiers auxiliaires
  
  
• scripts contient les scripts Python exécutables, c'est-à-dire ceux qui sont exécutés à partir de l'interpréteur de commandes
  
  
• testcases contient quelques exemples de fichiers *.by et *.py destinés à tester l'implémentation.

Source : Bython

Et vous ?

:fleche: Quel est votre avis sur ce projet ?
:fleche: Pensez-vous que Bython soit crédible ou pertinent ?

Voir aussi :

:fleche: Python 3.13 ajoute un compilateur JIT qui pourrait améliorer les performances du langage d'environ 9 %, mais l'annonce suscite des réactions mitigées

:fleche: Popularité des langages sur GitHub : Python, Go et JavaScript en progression, tandis que Java et C++ sont en légère baisse mais restent dans le Top 5, d'après GitHut 2.0

Et non ça n'est pas un trolldi :mrgreen:

Mais ça aurait pu :ptdr:


:dehors:

Citation:

---

Quel est votre avis sur ce projet ?

---

Pour moi c'est :pan: .
Si besoin, un Ide peut éventuellement re indenter un code...

Ca veut dire qu'avec bython on pourra revenir aux codes immondes qu'on avait déjà en C dans le style...

Code:

---

1 2 3 4 5 6 7 8 9

def print_message(num_of_times) { for i in range(num_of_times) { print("Bython is awesome!"); } }   if __name__ == "__main__" { print_message(10); }

---

... et qu'on y reviendra fatalement.

Le but des tabulations de Python était justement de ne pas pouvoir écrire comme ci-dessus, de forcer à avoir un code dans lequel les blocs apparaissent bien distinctement. Oui effectivement parfois quand je récupère un code que j'insère dans le mien j'obtiens une exception qui parle de mélange espaces/tabulations mais franchement c'est pas la mort à reformater.
Et là bython arrive comme si c'était le truc qu'on attendait tous et pète tous les fondements de Python. Bon, pas grave, faire et défaire c'est toujours travailler...

Le problème de l'indentation concerne surtout les fonctions Python qui font plus de 100 lignes. On n'arrive plus à s'y retrouver. Faut dire aussi qu'une fonction trop longue manifeste généralement un mauvais codage.

Citation:

---

Ca veut dire qu'avec bython on pourra revenir aux codes immondes qu'on avait déjà en C dans le style...

---

il y a une fâcheuse tendance chez certains praticiens du C/c++ (vu aussi en c# hein) à pondre du code sale.
Mais tellement sale....

Par contre, la réponse python, sans accolades, n'est qu'une réponse.
L'équipe du projet Go apporte une autre réponse
avec un formatage unique pour tous les projets.

Il me semble que c'est une réponse tout aussi pertinente.

Par ailleurs cela permet de mettre définitivement fin au débat
stérile sur le style du code pour se concentrer sur ses qualités intrinsèque.

Ce que python ne fait pas en introduisant un tas de notations en-ligne (et j'en lis souvent dans les posts python).

J'espère que ça ne transforme pas les accolades d'un dictionnaire :aie:

Blagues à part, pour moi l'indentation est la force principale de python.
Cela me parait une mauvaise idée de vouloir l'enlever (ou la remplacer).

Notez que les coredevs de Python y avaient pensé.

Code:

---

1 2 3 4 5 6 7

vincent@djoliba:~$ python3 Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import braces File "<stdin>", line 1 SyntaxError: not a chance >>>

---

Les IDE Python peuvent très bien faire une indentation propre, on le fait bien en Java...

magnifique

mais ça aurait pu être encore mieux :

1er niveau : 1 accolade def f() { ... }
2e niveau : 2 accolades def f() { if none {{ ... }} ... }

ce srait tellement plus beau 8-)

Citation:

---

Envoyé par TotoParis

Les IDE Python peuvent très bien faire une indentation propre, on le fait bien en Java...

---

Le vrai problème pour moi c'est que justement, l'indentation peut dépendre de l'éditeur. Or, je peux être amené d'un client à l'autre à ne pas utiliser le même éditeur (ne serait-ce que parce que chaque client m'impose d'utiliser sa machine où il installe un éditeur bridé) tout en voulant ré-utiliser du code que j'ai mis en open source. Du coup comment ça se passe si un IDE utilise des tabulations et l'autre des espaces?
Bien sûr tu peux installer un reformatteur en amont du git et c'est bien comme ça que je procède quand je vais partager mon code sur Github. Mais si j'utilise un reformatteur automatique, c'est bien pour ne pas m'astreindre à respecter le format au moment où je suis en train d'écrire mon code. Sauf qu'en Python le format fait partie de la syntaxe.

Du coup j'aime bien l'idée. Mais tant qu'à faire, je ne suis pas super fan des langages accumulant les accolades, je préfère la syntaxe if ... end if qu'on trouve en Ada par exemple. ça permet d'être certain qu'on a bien fermé ce qu'on voulait et pas l'instruction du dessus. Et puis si Python est un langage pédagogique, ça permet de conserver cet aspect.
Peut-être des volontaires pour créer Aython du coup?

Citation:

---

Envoyé par esperanto

Sauf qu'en Python le format fait partie de la syntaxe

---

Justement non ! une "tabulation" pour python peut-être uniquement 2 espaces .. 6 espaces ou bien une tabulation et en plus il est possible de mélanger le tout dans le même fichier :mouarf:

Donc, pour moi, python est juste un truc bâtard (pour débutants) et de plus, pourquoi imposer un caractère (":") de début de block si les tabulations sont si bonnes ?

Et puisque je ne vais jamais coder sans tabulation, en fait le seul changement pour moi avec python est l'absence de fin de block (caractère ou mot clé). Donc mon seul changement est : un code plus compact et donc un peu plus difficile à lire :roll:

Citation:

---

Envoyé par papajoker

Justement non ! une "tabulation" pour python peut-être uniquement 2 espaces .. 6 espaces ou bien une tabulation et en plus il est possible de mélanger le tout dans le même fichier :mouarf:?

---

On doit pouvoir configurer son editeur pour remplacer les tabulations par N <space> (comme cela est possible pour IDLE et VIM).

Citation:

---

Envoyé par esperanto

Du coup comment ça se passe si un IDE utilise des tabulations et l'autre des espaces?

---

On impose demande au client de configurer son editeur si on ne sait pas le faire soi-même.


- W
PS: excepté cette longue discussion où tout le monde dit ce qu'il en pense, je ne vous pas trop l'intérêt de ces "braces"

Hello,

Citation:

---

Envoyé par wiztricks

excepté cette longue discussion où tout le monde dit ce qu'il en pense, je ne vous pas trop l'intérêt de ces "braces"

---

Aucun intérêt, ayant fait du C/C++/Java, je peux te confirmer que ça ne m'apporterait rien.

Pire, comme on ajoute une surcouche à python, on perd en performance... et le parsing est en python, la cata :mouarf:

Citation:

---

Envoyé par wiztricks

On doit pouvoir configurer son editeur pour remplacer les tabulations par N ...
On impose demande au client de configurer son editeur

---

Dans la vraie "vie", on utilise même des formateurs (ruff, black) donc ce soin d'avoir un code un peu* "propre" avec ces tabulations n'est en fait qu'un problème que pour les non professionnels.

un peu* : comme si les tabulations étaient la recette magique pour avoir un code clair :roll:

Citation:

---

on ajoute une surcouche

---

Tout a fait ! donc cette solution ne m'intéresse aucunement (bien que je pense que mon code serait plus lisible pour moi avec des accolades pour délimiter les block)

Citation:

---

Envoyé par papajoker

et de plus, pourquoi imposer un caractère (":") de début de block si les tabulations sont si bonnes ?

---

Point de repère permettant à l'interpréteur de se repérer plus facilement (donc plus rapidement) et éventuellement d'écrire les blocs de façon plus lisible

Code:

---

1 2 3 4 5

def fct(param1, param2, param3): ...blablabla...   for (x, y) in ((1, 2), (3, 4), (5, 6), (7, 8), (9, 10)): # Et tant pis si j'ai besoin d'inhiber (3, 4) pour une raison ou une autre... ...(traitement x et y)...

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

def fct( param1, # Ce paramètre sert à truc param2, # Ce paramètre sert à chose param3, # Ce paramètre sert à machin ): ...blablabla...   for (x, y) in ( (1, 2), # (3, 4), # Je l'enlève pour un test... (5, 6), (7, 8), (9, 10), ): ...(traitement x et y)... # Hé oui, quand le traitement tient sur une ligne on n'est pas obligé de le mettre en dessous (merci les ":")...

---

Sans les ":" tu es coinçé. Et peut-être qu'on peut écrire un interpréteur qui s'en sortira quand-même sans eux mais il sera dix fois plus lourd donc traitera le code 100 fois plus lentement (loi des carrés)...

Citation:

---

Envoyé par papajoker

un peu* : comme si les tabulations étaient la recette magique pour avoir un code clair :roll:

---

Il n'y a rien de magique ni de parfait. Par exemple prisme60 a soulevé un point intéressant concernant les sous-blocs multiples qui, de fait, rend difficile de se repérer

Code:

---

1 2 3 4 5 6 7 8 9 10

def toto(): if ...: while ...: truc truc truc for ...: chose chose autre machin...

---

Effectivement pour peu que le while et for grossissent un peu, "autre machin" devient difficile à positionner (oups, je voulais le mettre dans le if !!!).
Rossum a tenté une idée, mais cette idée ne peut marcher que si les dev y mettent aussi un peu du leur...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

def toto(): if ...: while ...: truc truc truc for ...: chose chose # for # while # if autre machin... # Ne voulais-je pas le mettre dans le if ? Pourquoi est-il alors sous le commentaire fermant ??? # toto()

---

Avec tout le respect du a Bython, je ne vois vraiment pas l’intérêt de vouloir s'entraver avec des accolades. Quand je copie du code je dois m'assurer qu'il respecte au moins le format de mon code, je fais pas un copier-coller a tue-tête sans réfléchir quand même .... du coup ce argument de description ne tient pas forcement la route, selon moi ...

Citation:

---

Envoyé par Sve@r

Effectivement pour peu que le while et for grossissent un peu, "autre machin" devient difficile à positionner (oups, je voulais le mettre dans le if !!!).

---

Effectivement d'où l’intérêt du code folding, des indent guides...

Bonjour,

Quelque soit le format du code il suffit de le passer dans un beautifier.
Outre l'ancêtre "cb" il y a des tas d'outils soit en ligne, soit en local qui vous transforme un code C ou C++ en code 'tout beau'

Il y en a même pour le bash !

Alors l'excuse du code sale pour ne pas utiliser des accolades comme séparateur de blocs est irrecevable et relève plus du fanatisme borné que de la technique.

Cordialement