Room 303 » code

See no eval, hear no eval, speak no eval

Patrys — Fri, 03 Sep 2010 15:51:31 +0000

Choć sam konta w Książeczce Maryja nie posiadam, przyszło mi ostatnio ścierać się z ichnim API, coby dla klienta wdrożenia poczynić. Po przejrzeniu dostępnych bibliotek (w tym dość żałosnego python-sdk), stanęło na dość popularnym projekcie pyfacebook.

Oryginalne repozytorium było wybrakowane pod względem funkcjonalności, wybraliśmy więc fork, który z pewnością stworzył fan Władcy Pierścieni. Jak się miało później okazać, „jeden, by wszystkie zgromadzić i w ciemności związać” dość wiernie oddaje uzyskany efekt.

Człowiek głupi, to przy pierwszym problemie zajrzał w bebechy ofiary. Po tym stanął jak wryty i całe Satchmo przeleciało mu przed oczami. Na początek tradycyjny problem — przejście się w glanach po separacji warstw:

from threading import local

_thread_locals = local()

def get_facebook_client():
    """
    Get the current Facebook object for the calling thread.

    """
    try:
        return _thread_locals.facebook
    except AttributeError:
        raise ImproperlyConfigured('Make sure you have the Facebook middleware installed.')

class FacebookMiddleware(object):
    """
    Middleware that attaches a Facebook object to every incoming request.
    The Facebook object created can also be accessed from models for the
    current thread by using get_facebook_client().

    callback_path can be a string or a callable.  Using a callable lets us
    pass in something like lambda reverse('our_canvas_view') so we can follow
    the DRY principle.
    """
    # ...

    def process_request(self, request):
        # ...
        _thread_locals.facebook = request.facebook = Facebook(self.api_key,
                self.secret_key, app_name=self.app_name,
                callback_path=callback_path, internal=self.internal,
                proxy=self.proxy, app_id=self.app_id, oauth2=self.oauth2)

Przerażające konstrukcje zaczęły się jednak później:

# generate the Facebook proxies
def __generate_proxies():
    for namespace in METHODS:
        methods = {}

        for method, param_data in METHODS[namespace].iteritems():
            methods[method] = __generate_facebook_method(namespace, method, param_data)

        proxy = type('%sProxy' % namespace.title(), (Proxy,), methods)

        globals()[proxy.__name__] = proxy

__generate_proxies()

class Facebook(object):
    """
    Provides access to the Facebook API.

    ...
    """

    def __init__(self, api_key, secret_key, auth_token=None, app_name=None,
                 callback_path=None, internal=None, proxy=None,
                 facebook_url=None, facebook_secure_url=None,
                 generate_session_secret=0, app_id=None, oauth2=False):
        # ...
        for namespace in METHODS:
            self.__dict__[namespace] = eval('%sProxy(self, '%s')' % (namespace.title(), 'facebook.%s' % namespace))

Skończyło się na własnym forku i refaktoryzacji tych i wielu innych fragmentów kodu. Poprawioną wersję można znaleźć na GitHubie.

Na koniec stare powiedzenie ludowe:

Gdy bowiem zoczysz, iż jest coś narzeczy, a za cwanego masz się i uważasz __globals__ i eval() za sprawy rozwiązanie, mylisz się wielce, przeto idź przypudrować nos¹.

¹ Ciało, 2003

See no eval, hear no eval, speak no eval © Patryk Zawadzki, Creative Commons Attribution-NonCommercial-ShareAlike 2.5 Poland.

Python: Nie będziesz używał **kwargs nadaremnie

Patrys — Wed, 04 Aug 2010 14:16:52 +0000

Prawidłowe użycie:

def foo(bar, *args, **kwargs):
    frobnicate(bar)
    baz(*args, **kwargs)

Nigdy tak¹:

def foo(bar, *args, **kwargs):
    frobnicate(bar)
    baz()

¹ Z wyjątkiem kilku API, które wyraźnie rezerwują sobie możliwość wprowadzenia dodatkowych parametrów. Działają tak np. wbudowane sygnały w Django.

Ciche połykanie śmieci w parametrach w malowniczy sposób zemści się przy pierwszej literówce w kodzie. I będzie ci się należało.

Jeśli wydaje ci się, że w ten sposób skracasz sobie kod, to przypomnij sobie starą zasadę: utrzymywanie kodu wymaga dwa razy więcej inteligencji i sprytu, niż jego napisanie. Jeśli cały swój spryt włożysz w stworzenie kodu, to z definicji jesteś za głupi, by go potem debugować.

Python: Nie będziesz używał **kwargs nadaremnie © Patryk Zawadzki, Creative Commons Attribution-NonCommercial-ShareAlike 2.5 Poland.

To jest mój wątek i nie oddam go nikomu

Patrys — Mon, 26 Jul 2010 14:53:26 +0000

Bezstanowość protokołu HTTP jest faktem. Niezależnie od tego, czego chciałby autor danej aplikacji. Na przykład nie jest prawdą, że jeden proces lub wątek serwera jest przypisany jednemu, konkretnemu odwiedzającemu stronę. Wybaczcie zatem łzy, które zakręciły mi się w oczach na widok tego:

def _get_taxprocessor(request=None):
    taxprocessor = get_thread_variable('taxer', None)
    if not taxprocessor:
        if request:
            user = request.user
            if user.is_authenticated():
                user = user
            else:
                user = None
        else:
            user = get_current_user()

        taxprocessor = get_tax_processor(user=user)
        set_thread_variable('taxer', taxprocessor)

    return taxprocessor

Dalej był już tylko płacz:

def get_current_user():
    user = get_thread_variable('user', None)
    if user != None: return user
    req = get_current_request()
    if req == None: return None
    return req.user

I zgrzytanie zębów:

from threading import local

_threadlocals = local()

def set_current_user(user):
    set_thread_variable('user', user)

def set_thread_variable(key, var):
    setattr(_threadlocals, key, var)

def get_thread_variable(key, default=None):
    return getattr(_threadlocals, key, default)

def get_current_request():
    return get_thread_variable('request', None)

class ThreadLocalMiddleware(object):
    """Middleware that gets various objects from the
    request object and saves them in thread local storage."""

    def process_request(self, request):
        set_thread_variable('request', request)
        set_current_user(request.user)

Pytanie-zagadka: co się stanie z podatkiem, gdy ten sam wątek serwera obsłuży innego użytkownika? Pytanie pomocnicze: skąd może pochodzić ów kod?

Otrzymujesz k3 Punkty Obłędu. Jeśli całkowita liczba zebranych punktów wynosi 6 lub więcej, rozpatrz test nabycia trwałej choroby psychicznej zgodnie z procedurą opisaną w rozdziale Obłęd podręcznika.

To jest mój wątek i nie oddam go nikomu © Patryk Zawadzki, Creative Commons Attribution-NonCommercial-ShareAlike 2.5 Poland.

Być jak Satchmo

Patrys — Tue, 20 Jul 2010 15:20:30 +0000

Z pewnością naczytałeś się już, jakie to Satchmo nie jest doskonałe, zazdrościsz i chciałbyś stworzyć coś równie wspaniałego. Dość jednak nieprzespanych nocy, albowiem przygotowałem krótki poradnik, który w kilku krokach pozwoli ci dorównać mistrzom.

Sięgaj tam, gdzie import nie sięga

Tak jest, zacznij od stworzenia modułu z myślnikiem w nazwie. Niestety, oczywista nazwa email-auth.py została już zajęta — musisz się bardziej wysilić. Znajomym oczy wypadną z zazdrości, gdy tylko pierwszy raz zobaczą:

hahaha = __import__('pokonalem-was', globals(), locals(), [], -1)

Uatrakcyjniaj pętle

Od dawna wiadomo już, że przedwczesna optymalizacja jest złem, naszą odpowiedzią będzie zatem przedwczesna dezoptymalizacja! Oto przykład atrakcyjnego wyświetlenia listy:

{% for product in products %}
    {% if forloop.first %}   {% endif %}
        {% thumbnail product.main_image.picture 85x85 as image %}
         href="{{ product.get_absolute_url }}"> src="{{ image }}" width="{{ image.width }}" height="{{ image.height }}" />
         href="{{ product.get_absolute_url }}">{{ product.translated_name }}
    {% if forloop.last %}  {% endif %}
{% endfor %}

Tylko wyobraź sobie ich miny! Jeśli chcesz przeskoczyć mistrza, spróbuj przenieść kod do Pythona:

for counter, product in enumerate(products):
    if counter == 0:
        print ''
    # ...i tak dalej

Nie daj się zaszufladkować

Nie łudźmy się — przestrzenie nazw są dla frajerów. Bez ceregieli pakuj wszystko w ścieżkę Pythona i upewnij się, że tak właśnie importujesz swoje moduły. Pokaż, że jesteś ważniakiem i twórz moduły o jak najogólniejszych nazwach. Naucz fajansów pokory, tych kilka dodatkowych wpisów w PYTHONPATH ich nie zabije. Mogą to zrobić konflikty, ale jeśli chcą używać czegoś ponad twój framework, to sami są sobie winni i zasłużyli na karę.

export PYTHONPATH=~/web/satchmo/satchmo/apps

Unikaj biurokracji

Po co męczyć się z formularzami, gdy do wszystkiego sięgnąć można już w widoku? Niezwykle istotne jest tu unikanie request.REQUEST.

if request.method=="POST":
    reqdata = request.POST
else:
    reqdata = request.GET

if reqdata.has_key('quantity'):
    try:
        quantity = round_decimal(reqdata['quantity'], places=2, roundfactor=.25)
    except RoundedDecimalError:
        quantity = Decimal('1.0')
        log.warn("Could not parse a decimal from '%s', returning '1.0'", reqdata['quantity'])
else:
    quantity = Decimal('1.0')

Jeśli już musisz użyć formularza, upewnij się, że upakujesz wszystkie, niezwiązane ze sobą grupy pól w jednej dużej klasie. Dzięki temu zaoszczędzisz sobie kilka wywołań is_valid() i jednocześnie udaremnisz wszelkie próby innego wykorzystania poszczególnych części przez te niedorozwoje, które mają czelność importować twoje klasy.

Wyznaczaj nowe trendy

Przez takich jak oni, programowanie obiektowe stoi praktycznie w miejscu. Pokaż im nowe sztuczki, takie jak zastąpienie rozszerzania klas nadpisywaniem funkcji w locie¹:

def confirm_info(request, template='shop/checkout/protx/confirm.html', extra_context={}):
    payment_module = config_get_group('PAYMENT_PROTX')
    controller = confirm.ConfirmController(request, payment_module)
    controller.templates['CONFIRM'] = template
    controller.extra_context = extra_context
    controller.onForm = secure3d_form_handler
    controller.confirm()
    return controller.response

¹ W rzeczywistości ConfirmController.onForm jest w konstruktorze klasy ustawiany na ConfirmController._onForm, co można uznać za architekturę po dwakroć lepszą.

Parametry dobieraj z rozmachem

Piękno tkwi w różnorodności. Upewnij się zatem, że wyczerpiesz wszelkie metody osiągnięcia tego samego celu.

class ProductImage(models.Model):
    # ...
    picture = ImageWithThumbnailField(verbose_name=_('Picture'),
        upload_to="__DYNAMIC__",
        name_field="_filename",
        max_length=200)
    # ...

class ImageWithThumbnailField(ImageField):
    # ...
    def __init__(self, verbose_name=None, name=None,
                 width_field=None, height_field=None,
                 auto_rename=NOTSET, name_field=None,
                 upload_to=upload_dir, **kwargs):
        # ...
        if upload_to == "__DYNAMIC__":
            upload_to = upload_dir
        # ...

Bądź elastyczny

Teraz twój sklep znajduje się w Polsce, ale kto wie, co będzie po obiedzie? Upewnij się, że cała konfiguracja może być edytowana w locie. Zwłaszcza te jej fragmenty, które wymagają restartu aplikacji. To jedna z wielu sztuczek, które zapewnią ci popularność w branży. Co prawda dawni przyjaciele zazdroszczą ci już do tego stopnia, że przestali się do ciebie odzywać, ale i tak nie tęsknisz po tych prostakach. Od teraz twoim jedynym przyjacielem jest aplikacja django-livesettings. Na innych nie masz szans, bo przyjaciół poznaje się w biedzie, a ty przecież właśnie zyskałeś umiejętności, dzięki którym praktycznie już jesteś bogaty.

Być jak Satchmo © Patryk Zawadzki, Creative Commons Attribution-NonCommercial-ShareAlike 2.5 Poland.

Python: finanse

Patrys — Thu, 20 May 2010 20:36:56 +0000

Nie dalej jak wczoraj kolega podesłał mi łatkę do mojej biblioteki do słownego zapisu liczb i kwot. Nie zdradzę od kogo, by chronić niewinnego. Grunt, że łatka wyglądała tak:

--- to_words_pl.py	(upstream)
+++ to_words_pl.py	(working copy)
@@ -82,7 +82,7 @@
         iteration += 1
     if unit:
         result.append(unit)
-    result.append(u'%d/100' % int(remainder * 100))
+    result.append(u'%d/100' % int(round(remainder * 100)))
     result = ' '.join(result)
     return result

Zdziwiłem się bardzo, bo zwykłem kwoty odpowiednio zaokrąglać do dwóch miejsc po przecinku. Co się jednak okazało? 0.48 zamieniało się w 0.47. A dokładniej? W 0.47999999999999998. Tuś mi, ptaszku.

Patrząc na 0.48 tak naprawdę w głowie widziałem decimal.Decimal('0.48'). Jak się jednak okazuje, niektórzy próbują operacje finansowe przeprowadzać na liczbach zmiennopozycyjnych. Nie używamy typu float do operacji finansowych. Dlaczego?

>>> 0.48
0.47999999999999998
>>> 0.82
0.81999999999999995

Do operacji na liczbach o znanej precyzji używamy typu decimal.Decimal i jego kontrolowanego (i konfigurowalnego!) mechanizmu zaokrąglania:

>>> from decimal import Decimal
>>> Decimal('0.48') + Decimal('0.12')
Decimal('0.60')
>>> vat = Decimal('0.48') * Decimal('0.22')
>>> vat.quantize(Decimal('0.01'))
Decimal('0.11')

Python: finanse © Patryk Zawadzki, Creative Commons Attribution-NonCommercial-ShareAlike 2.5 Poland.

Python: wyjątkowo głupi pomysł

Patrys — Thu, 13 May 2010 16:12:38 +0000

Nigdy nie róbcie tak:

try:
    # ...
except FooException, e:
    # ...
    raise e

Wyjątki przepuszcza się tak:

try:
    # ...
except FooException:
    # ...
    raise

Istotna różnica polega na niezniszczeniu całego stosu wywołań. Z góry dziękuję.

Python: wyjątkowo głupi pomysł © Patryk Zawadzki, Creative Commons Attribution-NonCommercial-ShareAlike 2.5 Poland.

Django: abstrakcji ciąg dalszy

Patrys — Tue, 27 Apr 2010 09:33:38 +0000

Tym razem inne podejście, naturalne dziedziczenie abstrakcyjnych modeli z dwoma dodatkowymi metodami.

W przeciwieństwie do poprzedniego przykładu, pozwala używać super() w abstrakcyjnych klasach pośrednich.

from django.db import models

class AbstractMixin(object):
    _classcache = {}

    @classmethod
    def contribute(cls):
        return {}

    @classmethod
    def construct(cls, *args, **kwargs):
        attrs = cls.contribute(*args, **kwargs)
        attrs.update({
            '__module__': cls.__module__,
            'Meta': type('Meta', (), {'abstract': True}),
        })
        key = (args, tuple(kwargs.items()))
        if not key in cls._classcache:
            clsname = ('%s%x' % (cls.__name__, hash(key))) \
                    .replace('-', '_')
            cls._classcache[key] = type(clsname, (cls, ), attrs)
        return cls._classcache[key]

Przykład użycia:

class CategoryFactory(models.Model, AbstractMixin):
    name = models.CharField(max_length=100)

    class Meta:
        abstract = True

    def __unicode__(self):
        return self.name

class ProductFactory(models.Model, AbstractMixin):
    name = models.CharField(max_length=100)

    class Meta:
        abstract = True

    @classmethod
    def contribute(cls, category):
        return {'category': models.ForeignKey(category)}

    def __unicode__(self):
        return u'%s / %s' % (self.category, self.name)

Konkretyzacja klas:

class MyCategory(CategoryFactory.construct()):
    pass

class MyProduct(ProductFactory.construct(category=MyCategory)):
    pass

Działa również nasz test:

from . import models

c = models.MyCategory(name='cat')
p = models.MyProduct(name='prod', category=c)
print p
# cat / prod

Django: zabawa z abstrakcją

Patrys — Thu, 22 Apr 2010 20:22:45 +0000

Zastanawialiśmy się ostatnimi czasy, w jaki sposób zbudować aplikację tak, by z jednej strony była uniwersalna (abstrakcyjne modele bazowe), a z drugiej zawierała całą niezbędną logikę. Problem polega na tym, że — z oczywistych względów — klucza obcego do modelu abstrakcyjnego stworzyć się nie da. Pozostaje więc zwalić pracę na programistę, który konkretyzuje abstrakcyjne prototypy, prawda?

Dzisiaj do głowy przyszło mi rozwiązanie może nie do końca ładne, ale na pewno działające. Fabryka abstrakcyjnych modeli:

from django.db import models

class AbstractModelMetaclass(type):
    def __new__(cls, name, bases, attrs):
        super_new = super(AbstractModelMetaclass, cls).__new__
        if bases == (object, ):
            return super_new(cls, name, bases, attrs)
        new_attrs = attrs.copy()
        module = attrs['__module__']
        new_cls = super_new(cls, name, bases, {'__module__': module})
        fields = getattr(new_cls, '_fields', {}).copy()
        for key, val in attrs.items():
            if key not in ['construct', '__new__']:
                fields[key] = val
        new_attrs['_fields'] = fields
        return super_new(cls, name, bases, new_attrs)

class AbstractModelFactory(object):
    __metaclass__ = AbstractModelMetaclass

    @staticmethod
    def construct():
        return {}

    def __new__(cls, *args, **kwargs):
        attrs = cls._fields.copy()
        attrs.update(cls.construct(*args, **kwargs))
        attrs['__module__'] = cls.__module__
        attrs['Meta'] = type('Meta', (), {'abstract': True})
        return type(cls.__name__, (models.Model, ), attrs)

Idea jest taka, że implementując swoją podklasę fabryki modeli mamy możliwość zadecydować o polach, jakie trafią do ostatecznego modelu. Dla lepszego zrozumienia, rozważmy abstrakcyjne klasy produktu i kategorii:

class CategoryFactory(AbstractModelFactory):
    name = models.CharField(max_length=100)

    def __unicode__(self):
        return self.name

class ProductFactory(AbstractModelFactory):
    name = models.CharField(max_length=100)

    @staticmethod
    def construct(category):
        return {'category': models.ForeignKey(category)}

    def __unicode__(self):
        return u'%s / %s' % (self.category, self.name)

Skonkretyzujmy klasy własną implementacją:

class MyCategory(CategoryFactory()):
    pass

class MyProduct(ProductFactory(category=MyCategory)):
    pass

Upewnijmy się, że zależności działają prawidłowo:

from . import models

c = models.MyCategory(name='cat')
p = models.MyProduct(name='prod', category=c)
print p
# cat / prod

Oczywiście — ktoś zaraz powie — to samo można uzyskać tworząc funkcję zwracającą klasę zdefiniowaną w jej ciele. Można, ale nie da się po niej wygodnie dziedziczyć (rozszerzenie istniejącej fabryki).

twojastara.py

Patrys — Wed, 14 Apr 2010 13:28:27 +0000

fat = unicode
print type(ur'mom') is fat

Tak, tak, poniżej krytyki. Za to już niedługo: seria niewyjaśnionych znalezisk w kodzie Satchmo (czyli jak Pythona używać nie należy).

Django: TestCase i testowanie szablonów

Patrys — Mon, 15 Mar 2010 17:03:55 +0000

Bardzo brzydki hack, oparty o załącznik do ticketu 7611. Czyści wewnętrzny cache Django, ale pozwala testować działanie kodu opierającego się o renderowanie szablonów bez ryzyka, że aplikacja owe szablony nadpisze:

import os
import sys
from django.conf import settings
from django.template import loader
from django.test import TestCase

class TemplateTestCase(TestCase):
    def _pre_setup(self):
        self._template_setup()
        super(TemplateTestCase, self)._pre_setup()

    def _post_teardown(self):
        self._template_teardown()
        super(TemplateTestCase, self)._post_teardown()

    def _template_setup(self):
        if hasattr(self, 'template_loaders'):
            self._old_template_loaders = settings.TEMPLATE_LOADERS
            settings.TEMPLATE_LOADERS = self.template_loaders
            loader.template_source_loaders = None
        if hasattr(self, 'template_dirs'):
            self._old_template_dirs = settings.TEMPLATE_DIRS
            test_dir = os.path.dirname(sys.modules[self.__module__].__file__)
            settings.TEMPLATE_DIRS = [ os.path.join(test_dir, dirname) for dirname in self.template_dirs ]

    def _template_teardown(self):
        if hasattr(self, '_old_template_loaders'):
            settings.TEMPLATE_LOADERS = self._old_template_loaders
            loader.template_source_loaders = None
        if hasattr(self, '_old_template_dirs'):
            settings.TEMPLATE_DIRS = self._old_template_dirs

Użycie:

class TestSomething(TemplateTestCase):
    template_loaders = ('django.template.loaders.app_directories.load_template_source',)

    def test_foo(self):
        pass

Django: TestCase i testowanie szablonów © Patryk Zawadzki, Creative Commons Attribution-NonCommercial-ShareAlike 2.5 Poland.