JeromeJ's links
614 shaares
5 results
tagged
python-3
Flask ne semble pas supporter la possibilité de retourner des générateurs comme WSGI peut le faire et je ne suis pas sûr qu'ils prévoient que ça soit le cas un jour … ( voir https://github.com/mitsuhiko/flask/pull/684 )
Mais bon perso je trouve ça super sympa de pouvoir yield du contenu lorsqu'on veut dans son code. Un peu comme je pouvais le faire avec cgi ou en PHPouet.
De plus je suis entrain de migrer d'un code pur WSGI à Flask (sous les conseils de Link Mauve si je ne me méprend pas) - pour l'instant j'en suis toujours à l'étape "c'est relou". Pourvu que ça ne dure pas -, du coup c'est plus sympa pour moi de pouvoir conserver cette façon là.
(Note: J'avais également pas envie de devoir spécifier un décorateur @generator pour toutes mes fonctions contenant un yield, j'ai donc décidé de décorer app.route directement (mais ce fut un peu plus compliqué à mettre en place))
from functools import wraps
from flask import Flask, Response, stream_with_context
app = Flask(__name__)
# Decorator to make Flask accept generators
@wraps(app.route)
def route_accept_generators(*args, **kwargs):
route = route_accept_generators.app_route(*args, **kwargs) # Getting our route decorator.
# Decorating it.
@wraps(route)
def decorated(f):
# Make so that the function that will be called return a valid Flask answer in case of returning a generator.
@wraps(f)
def function_accept_generators(*args, **kwargs):
r = f(*args, **kwargs)
if isinstance(r, types.GeneratorType):
# return Response(r, direct_passthrough=True) # Solution proposed here: http://flask.pocoo.org/mailinglist/archive/2010/11/3/using-yield/#478b0c1829b5263700da1db7d2d22c79
return Response(stream_with_context(r)) # Solution found here: http://stackoverflow.com/q/13386681/1524913
return r
return route(function_accept_generators)
return decorated
# Store the function so that it doesn't make an infinite recursion call
# Because accessing from app.route rather than directly)
# And storing it in itself instead of creating another standalone variable
route_accept_generators.app_route = app.route
app.route = route_accept_generators
Mais bon perso je trouve ça super sympa de pouvoir yield du contenu lorsqu'on veut dans son code. Un peu comme je pouvais le faire avec cgi ou en PHPouet.
De plus je suis entrain de migrer d'un code pur WSGI à Flask (sous les conseils de Link Mauve si je ne me méprend pas) - pour l'instant j'en suis toujours à l'étape "c'est relou". Pourvu que ça ne dure pas -, du coup c'est plus sympa pour moi de pouvoir conserver cette façon là.
(Note: J'avais également pas envie de devoir spécifier un décorateur @generator pour toutes mes fonctions contenant un yield, j'ai donc décidé de décorer app.route directement (mais ce fut un peu plus compliqué à mettre en place))
from functools import wraps
from flask import Flask, Response, stream_with_context
app = Flask(__name__)
# Decorator to make Flask accept generators
@wraps(app.route)
def route_accept_generators(*args, **kwargs):
route = route_accept_generators.app_route(*args, **kwargs) # Getting our route decorator.
# Decorating it.
@wraps(route)
def decorated(f):
# Make so that the function that will be called return a valid Flask answer in case of returning a generator.
@wraps(f)
def function_accept_generators(*args, **kwargs):
r = f(*args, **kwargs)
if isinstance(r, types.GeneratorType):
# return Response(r, direct_passthrough=True) # Solution proposed here: http://flask.pocoo.org/mailinglist/archive/2010/11/3/using-yield/#478b0c1829b5263700da1db7d2d22c79
return Response(stream_with_context(r)) # Solution found here: http://stackoverflow.com/q/13386681/1524913
return r
return route(function_accept_generators)
return decorated
# Store the function so that it doesn't make an infinite recursion call
# Because accessing from app.route rather than directly)
# And storing it in itself instead of creating another standalone variable
route_accept_generators.app_route = app.route
app.route = route_accept_generators
Quelques trucs avancés Python.
Savoir ça pourrait bien vous sauvez quelques heures de votre vie.
"For custom classes, implicit invocations of special methods are only guaranteed to work correctly if defined on an object’s type, not in the object’s instance dictionary." → You cannot modify magic method directly from an instance, for instance, doing that wont work:
>>> class C:
... pass
...
>>> c = C()
>>> c.__len__ = lambda: 5
>>> len(c)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: object of type 'C' has no len()
"In addition to bypassing any instance attributes in the interest of correctness, implicit special method lookup generally also bypasses the __getattribute__() method even of the object’s metaclass:" → When a magic method is used and not called explicitely, then all special methods like __getattribute__ are also bypassed.
For instance:
>>> class Meta(type):
... def __getattribute__(*args):
... print("Metaclass getattribute invoked")
... return type.__getattribute__(*args)
...
>>> class C(object, metaclass=Meta):
... def __len__(self):
... return 10
... def __getattribute__(*args):
... print("Class getattribute invoked")
... return object.__getattribute__(*args)
...
>>> c = C()
>>> c.__len__() # Explicit lookup via instance
Class getattribute invoked
10
>>> type(c).__len__(c) # Explicit lookup via type
Metaclass getattribute invoked
10
>>> len(c) # Implicit lookup
10
Savoir ça pourrait bien vous sauvez quelques heures de votre vie.
"For custom classes, implicit invocations of special methods are only guaranteed to work correctly if defined on an object’s type, not in the object’s instance dictionary." → You cannot modify magic method directly from an instance, for instance, doing that wont work:
>>> class C:
... pass
...
>>> c = C()
>>> c.__len__ = lambda: 5
>>> len(c)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: object of type 'C' has no len()
"In addition to bypassing any instance attributes in the interest of correctness, implicit special method lookup generally also bypasses the __getattribute__() method even of the object’s metaclass:" → When a magic method is used and not called explicitely, then all special methods like __getattribute__ are also bypassed.
For instance:
>>> class Meta(type):
... def __getattribute__(*args):
... print("Metaclass getattribute invoked")
... return type.__getattribute__(*args)
...
>>> class C(object, metaclass=Meta):
... def __len__(self):
... return 10
... def __getattribute__(*args):
... print("Class getattribute invoked")
... return object.__getattribute__(*args)
...
>>> c = C()
>>> c.__len__() # Explicit lookup via instance
Class getattribute invoked
10
>>> type(c).__len__(c) # Explicit lookup via type
Metaclass getattribute invoked
10
>>> len(c) # Implicit lookup
10
Interesdasting
Ça y est, je me sers de mon shaarli pour envoyer des messages aux personnes offlines maintenant …
Désolé buddy j'avais pas vu ton message j'étais en mode veille.
Du coup, si tu (ou d'autres) sont intéressés par un projet Python, n'hésite pas à check :
https://github.com/JeromeJ/Devutopia
http://devutopia.net/
Je préviens que le design est pas encore fait :p
(Et pour la licence on va sûrement passer en CopyLeft)
(Wink, wink, les tags ;) à ta demande expresse :D)
Désolé buddy j'avais pas vu ton message j'étais en mode veille.
Du coup, si tu (ou d'autres) sont intéressés par un projet Python, n'hésite pas à check :
https://github.com/JeromeJ/Devutopia
http://devutopia.net/
Je préviens que le design est pas encore fait :p
(Et pour la licence on va sûrement passer en CopyLeft)
(Wink, wink, les tags ;) à ta demande expresse :D)
Commen j'ai pas moyen de te mailer ou autres, je poste ça ici et ptet qu'ainsi tu verras mon message.
J'ai plus simple que ce que la solution que je t'avais proposé.
À savoir, ça : [k for k in myDict if k in myOtherDict] mais avec des .keys() en plus inutile.
En fait c'était tout con, on peut faire ça :
>>> {"a":22, "b":33, "c":24}.keys() & {"a":33, "b":57, "d":78}
{'a', 'b'}
.keys() renvoit une view qui se comporte comme un set, d'où la possibilité d'utiliser l'opérateur "&" normalement propre aux sets. ( http://www.python.org/dev/peps/pep-3106/ )
Et pas vraiment besoin d'utiliser .keys sur le dico de droite (je pense pas que ça impacte les performances), le "set-like" returner par .keys() sait effectuer l'opération "&" sur un dict (car par défaut quand tu itères un dict, ça itère sur les clés, faut utiliser .items() ou .values() sinon).
(Wink, wink, les tags ;) )
J'ai plus simple que ce que la solution que je t'avais proposé.
À savoir, ça : [k for k in myDict if k in myOtherDict] mais avec des .keys() en plus inutile.
En fait c'était tout con, on peut faire ça :
>>> {"a":22, "b":33, "c":24}.keys() & {"a":33, "b":57, "d":78}
{'a', 'b'}
.keys() renvoit une view qui se comporte comme un set, d'où la possibilité d'utiliser l'opérateur "&" normalement propre aux sets. ( http://www.python.org/dev/peps/pep-3106/ )
Et pas vraiment besoin d'utiliser .keys sur le dico de droite (je pense pas que ça impacte les performances), le "set-like" returner par .keys() sait effectuer l'opération "&" sur un dict (car par défaut quand tu itères un dict, ça itère sur les clés, faut utiliser .items() ou .values() sinon).
(Wink, wink, les tags ;) )