search

JeromeJ / Devutopia

http://devutopia.net/
Other
2 stars 0 forks source link

x for x in open(file) → == .read() ?? #1

Open JeromeJ opened 11 years ago

JeromeJ commented 11 years ago

https://github.com/JeromeJ/Devutopia/blob/master/wsgi-scripts/helloworld.py#L143

    # TODO: Wont this implicitely call ".read()"? (when we iter over it, see tag:devutopia.net,2013-11-03:Probably-implicitely-calling-read-without-parameter )

Une des solutions à laquelle je viens de penser (car le paramètre opener de open ne vas pas aider je crois) serait de faire: 1) Du débogouillage et voir ce qu'appelle for line in hello_world, 2) S'il appelle en effet bien read() 3) Si oui (et peut-être à l'aide de opener du coup), lui passer une classe enfant qui surchage les dites méthodes afin de pouvoir passer un paramètre à read ?

(Bon j'ai tag ça enhancement (du code), mais j'ai aucune idée dans il fallait poster ça (d'ailleurs c'est ptet pas la meilleure chose de reporter une issue pour ça mais je me voyais mal faire un commit rien que pour ça et écrire tout ça dans le code ;D))

EDIT: Au fait, c'est suite à ça que je chipote : http://sebsauvage.net/python/snyppets/#bound_read

Eijebong commented 11 years ago

Non, tu as raison d'ouvrir une issue pour ce genre de truc, ca permet de discuter plus librement que dans le code.

Pour e debugouillage, j'avais vu un truc qui permettait de voir en detail ce que faisait python, mais je me souviens plus…

JeromeJ commented 11 years ago

@Eijebong Il y a plusieurs façons de faire, je sais qu'il y a des déboggueurs mais y a aussi moyen de surcharger la méthode, je crois, __getattribute__ d'un objet pour savoir tous les accès qui lui sont fait (si sa méthode machin est appelée, ou une autre, etc)

Eijebong commented 11 years ago

C'était ptetre avec ipython que j'avais reussi... Je regarde ca ce soir, quand j'aurais le temps

JeromeJ commented 11 years ago

Pour ceux intéressés par l'avancement de notre enquête, on a trouvé les sources : /usr/lib/python3.X/_pyio.py

Les fonctions concernées TextIOWrapper.__next__, TextIOWrapper.readline et TextIOWrapper._read_chunk principalement.

L'idée serait de trouver le meilleur moyen de surcharger ça pour éviter un _read_chunk infini.

JeromeJ commented 10 years ago

J'essayais de changer la méthode __getattribute__ d'un TextIOWrapper et me demandait pourquoi Python me snobait >.>

http://www.olissea.com/mb/links/1/?yx_vmg

→ You cannot modify magic method directly from an instance. → When a magic method is used and not called explicitely, then all special methods like __getattribute__ are also bypassed.

Donc je me suis doublement avoir pour le coup :p J'aurais du me contenter du code source ^^