Ça n'évolueras jamais ? Python n'ajouteras jamais de fonctionnalités à sa fonction open() ?
Mais bien sûr qu'il y ajoute des fonctionnalités. Et d'ailleurs des arguments séparés ont été ajoutés pour certains d'entre eux. Mais les fonctionnalitéss de base restent accessibles simplement via la chaîne de flags, et cela suffit dans la majorité des cas.
Désolé, mais je n'ai jamais vu un seul utilisateur de Python se plaindre de ce que open() produisait du code trop concis et qu'il faudrait plutôt des constantes à rallonge à la place. Et je ne connais personne qui préfère écrire O_CREAT | O_WRONLY plutôt que "wb".
Tu écris 20 caractères de plus
Dans l'exemple Java dont on parlait, c'était AMHA beaucoup plus de 20 caractères. Et avant de les écrire, il faut les mémoriser. Et après, il faut les relire. Comme c'est la philosophie adoptée par Java pour toutes ses APIs, cela produit du code hyper-verbeux.
Enfin bon, libre à toi d'ignorer l'évidence.
Il est surtout nettement plus précis dans son utilisation. Le open() python a très peu de possibilités face au open() système. Être haut niveau ne signifie pas être limité. Java se situe entre les deux.
On commence à s'éloigner franchement du sujet, mais le open() de Python 3 a des possibilités que n'a pas le open() système, comme d'ouvrir un flux unicode (en choisissant l'encodage et le mode de traitement des erreurs), de faire une traduction automatique des caractères de fin de ligne, de choisir une stratégie de buffering, ou de wrapper un descripteur de fichier existant. C'est ce que j'appelle fournir une API haut niveau.
Et, oui, si tu veux accéder aux flags bas niveau du open() système, tu peux utiliser os.open(), qui est une simple indirection vers l'appel système, et qui te produit un descripteur de fichier que tu peux réutiliser avec... open(). Donc tu n'es pas plus limité qu'en Java, et les cas d'usage courants sont largement plus lisibles et concis.
[^] # Re: Les vrais ajouts
Posté par Antoine . En réponse au journal Java 7 est dispo !. Évalué à 4.
Mais bien sûr qu'il y ajoute des fonctionnalités. Et d'ailleurs des arguments séparés ont été ajoutés pour certains d'entre eux. Mais les fonctionnalitéss de base restent accessibles simplement via la chaîne de flags, et cela suffit dans la majorité des cas.
Désolé, mais je n'ai jamais vu un seul utilisateur de Python se plaindre de ce que
open()produisait du code trop concis et qu'il faudrait plutôt des constantes à rallonge à la place. Et je ne connais personne qui préfère écrireO_CREAT | O_WRONLYplutôt que"wb".Dans l'exemple Java dont on parlait, c'était AMHA beaucoup plus de 20 caractères. Et avant de les écrire, il faut les mémoriser. Et après, il faut les relire. Comme c'est la philosophie adoptée par Java pour toutes ses APIs, cela produit du code hyper-verbeux.
Enfin bon, libre à toi d'ignorer l'évidence.
On commence à s'éloigner franchement du sujet, mais le
open()de Python 3 a des possibilités que n'a pas le open() système, comme d'ouvrir un flux unicode (en choisissant l'encodage et le mode de traitement des erreurs), de faire une traduction automatique des caractères de fin de ligne, de choisir une stratégie de buffering, ou de wrapper un descripteur de fichier existant. C'est ce que j'appelle fournir une API haut niveau.Et, oui, si tu veux accéder aux flags bas niveau du open() système, tu peux utiliser
os.open(), qui est une simple indirection vers l'appel système, et qui te produit un descripteur de fichier que tu peux réutiliser avec... open(). Donc tu n'es pas plus limité qu'en Java, et les cas d'usage courants sont largement plus lisibles et concis.