Pour le raw_int, à la limite, tu as toujours ctypes.c_int :)
> pour l'indentation, je me demande si autoriser a la fois les espaces et les tabulations est une bonne idée et s'il n'aurait pas fallu rejeter les tabulations.
Pas d'accord. Le mélange des deux est une mauvaise idées, mais beaucoup indentent avec des tabulations, ce qui est moult pratique ! Il n'y a guère que quelques éditeurs dinosaures (je ne citerai pas de nom) qui font ch*er à mal gérer les tabulations.
Les tabulations ont l'ÉNORME avantage de faire plaisir à tout monde: certain préfèrent avoir une indentation à deux espaces (moi), d'autres à 4 espaces (beaucoup, parmis les pythnoeux), d'autres à 6 (j'en ai pas vu beaucoup, mais j'en ai vus), d'autres à 8 (beaucoup parmis les codeurs PHP). La solution pour mettre tout le monde d'accord est d'utiliser les tabulations et de laisser l'éditeur choisir par combien d'espaces représenter une tabulation. Avec les espaces, tu imposes ton style aux autres, c'est chiant au possible.
Sans compter que dans le cas de l'indentation par espaces, à moins d'ajouter des * vim: je sais pas quoi: * ou des *emacs: xxx* qui polluent le code, tu es obligé de changer la configuration de ton éditeur dès que tu contribues à un proet différent. C'est vraiment lourd. (encore que moi, je suis pas trp dérangé, scite detecte automatiquement le style utilisé)
Selon moi, c'est plutot l'indentation par espaces qui devrait gicler...
> Tu es en train de dire que le souligné _ est l'opérateur de concaténation des tuples?? Beurk!
Non.
Avant, tu écrivais def spam(a, (b, c)) et tu pouvais faire my_tuple = (4,2); spam(a, my_tuple). C'est à dire que le décompactage du tuple se faisait implicitement. Maintenant, tu dois le faire explicitement, mais tu aurais aussi pu faire
def spam(a, my_bc_tuple): b, c = my_bc_tuple
En fait, je connaissais mêmepas la syntaxe def spam(a, (b,c))
> l'abus de self n'est pas corrigé, quand tu lis du python, cest "def f(self, ...) def g(self, ...)": pénibles ces self partout.
C'est a un énorme point positif: ça évite les variables "magiques" et c'est après tout un argument comme un autre (self peut être passé à travers *args ou **kwargs par exemple). Ça évite les comportements plus que surprenants provenant du fait que ce soit un "machin spécial" (je n'ai jamais réussi à utiliser correctement "this" en JavaScript...)
[^] # Re: Grillay...
Posté par Moonz . En réponse à la dépêche Sortie de la version 3.0a1 du langage Python. Évalué à 4.
> pour l'indentation, je me demande si autoriser a la fois les espaces et les tabulations est une bonne idée et s'il n'aurait pas fallu rejeter les tabulations.
Pas d'accord. Le mélange des deux est une mauvaise idées, mais beaucoup indentent avec des tabulations, ce qui est moult pratique ! Il n'y a guère que quelques éditeurs dinosaures (je ne citerai pas de nom) qui font ch*er à mal gérer les tabulations.
Les tabulations ont l'ÉNORME avantage de faire plaisir à tout monde: certain préfèrent avoir une indentation à deux espaces (moi), d'autres à 4 espaces (beaucoup, parmis les pythnoeux), d'autres à 6 (j'en ai pas vu beaucoup, mais j'en ai vus), d'autres à 8 (beaucoup parmis les codeurs PHP). La solution pour mettre tout le monde d'accord est d'utiliser les tabulations et de laisser l'éditeur choisir par combien d'espaces représenter une tabulation. Avec les espaces, tu imposes ton style aux autres, c'est chiant au possible.
Sans compter que dans le cas de l'indentation par espaces, à moins d'ajouter des * vim: je sais pas quoi: * ou des *emacs: xxx* qui polluent le code, tu es obligé de changer la configuration de ton éditeur dès que tu contribues à un proet différent. C'est vraiment lourd. (encore que moi, je suis pas trp dérangé, scite detecte automatiquement le style utilisé)
Selon moi, c'est plutot l'indentation par espaces qui devrait gicler...
> Tu es en train de dire que le souligné _ est l'opérateur de concaténation des tuples?? Beurk!
Non.
Avant, tu écrivais def spam(a, (b, c)) et tu pouvais faire my_tuple = (4,2); spam(a, my_tuple). C'est à dire que le décompactage du tuple se faisait implicitement. Maintenant, tu dois le faire explicitement, mais tu aurais aussi pu faire
def spam(a, my_bc_tuple): b, c = my_bc_tuple
En fait, je connaissais mêmepas la syntaxe def spam(a, (b,c))
> l'abus de self n'est pas corrigé, quand tu lis du python, cest "def f(self, ...) def g(self, ...)": pénibles ces self partout.
C'est a un énorme point positif: ça évite les variables "magiques" et c'est après tout un argument comme un autre (self peut être passé à travers *args ou **kwargs par exemple). Ça évite les comportements plus que surprenants provenant du fait que ce soit un "machin spécial" (je n'ai jamais réussi à utiliser correctement "this" en JavaScript...)