J’en avais marre de taper Python en entier. Et surtout, je voulais lancer Python3.5 si il est dispo, et si possible ptpython, ou ipython. Sauf si je passe des arguments. Et que ça pete pas tout dans un virtualenv.

Bref:

function p {
    local SUFFIX="$@"
    if [[ "$VIRTUAL_ENV" != "" ]]
    then
      local PREFIX="$VIRTUAL_ENV"/bin
      COMMANDS=("python")
    else
      local PREFIX=/usr/bin
      COMMANDS=("python3.5" "python")
    fi
 
    if [[ "$#" -eq 0 ]]; then
        SUFFIX=""
        local COMMANDS=("python3.5 -m ptpython"
                        "python3.5 -m ipython"
                        "python -m ptpython"
                        "python -m ipython"
                        "python")
    fi
 
    for i in "${COMMANDS[@]}"
    do
       $PREFIX'/'$i $SUFFIX;
       [ "$?" -eq 0 ] && return 0
    done
 
}

Quand le Divx est sorti, il y a eu tout un débat sur la valeur du DVD. Le truc qui prend de la place, qui s’abime, qui est une plaie à sauvegarder, qui est zoné… En prime, quand tu payais un DVD, tu avais ça:

Attendez : il fallait aussi se déplacer pour acheter physiquement ce putain de DVD

Et est venu l’ère du streaming.

Et on a eu le droit à une redite.

Limite par pays, peu de sous-titre, catalogue limité et gros délais entre certaines sortis selon les médias et/ou les zones. Or the pirate bay et pop corn time n’ont pas tous ces problèmes.

Mais alors qu’en est-il du livre numérique ?

Le livre, c’est fait par des gens qui utilisent leur cerveau, non ?

Je veux dire, ils lisent, en théorie…

Et bien, après avoir galéré pour trouvé certains titres légalement et perdu ma collection suite au bricage de ma première tablette, je n’étais déjà pas très convaincu. J’aime l’outil pour le voyage, mais le service laisse à désirer. Nénamoins, je suis un geek, peut etre que les gens moins attachés à la cause étaient moins sensibles à ces problématiques.

Il faut croire que non, puisque mon frère m’a écrit dernièrement ce mail bien rageux:

ALORS j´ai acheté mon livre sur un site.

DRM ADOBE donc j´installe tout etc..1h30 à faire les inscriptions les mots de passe,
les confirmations. Et je peux même pas lire mon livre…
Les mecs sont les plus nazes de la terre ils se tirent un balle dans le pieds.

Du coup je vais devoir pirater mon propre livre que j´ai acheté légalement

Youpi.

Et du coup bah qu´ils aillent bien se faire mettre pour la suite ce sera le premier et le dernier livre avec DRM que achète et si je trouve pas mon livre en Epub sans DRM bah je le piraterai.

Dés que j´ai mon livre sans DRM je te l´envois.

Bisoux

Notez que lui sait ce qu’est un DRM. Je n’ose pas imaginer Mme Michu.

Je travaille sur un projet magique. Chaque jour est une nouvelle découverte, une aventure !

Par exemple, c’est un projet utilisant l’exellent Django Rest Framework, une app Django très puissante qui permet de créer des API succulentes.

DRF est très flexible, et permet de régler tout un tas de paramètres à l’aide de classes de configuration. Par exemple, il extrait automatiquement tout champ lookup_field sur ses classes Serializer afin de choisir sur quel champ filtrer les données.

L’auteur du code que j’ai sous les yeux, je crois, a voulu être vraiment, mais alors vraiment sur d’avoir un look up:

class FooViewSet(ModelViewSet):
 
    class Meta:
        model = Foo
        lookup_field = 'pk'
        lookup_fields = ('pk', 'data_id')
        extra_lookup_fields = None

En soit, c’est très drôle.

Et je pourrais arrêter l’article ici.

Mais non.

En effet, y a pas un truc qui vous choque ?

Je veux dire, autre que la sainte trinité des lookup fields…

Allez, relisez l’article depuis le début, je vous laisse une chance.

…
…

J’ai dis que DRF extraiyais un champ lookup_field sur les classes Serializer, et comme vous pouvez le constater, l’auteur ici hérite joyeusement de ModelViewSet, mais pas du tout de Serializer.

Oui, parce qu’on est en pleine exploration de Fistland (Au fond du fun !™), ces 3 champs ne sont en aucun cas exploités automatiquement par DRF… car sur les Viewset, lookup_field est utilisé pour générer des URLs, et mes prédécesseurs ont créé un router custo qui override ceci. Mais si on retire les champs, ça pête tout car ils y a des bouts de leur code qui supposent l’existence de ce champ.

Néanmoins, ne soyons pas complètement négatif, certaines classes héritent bien de Serialiser, et définissent aussi lookup_field. D’ailleurs une part de mon job est de migrer tout ça. Car la petite touche humoristique finale, c’est que lookup_field est deprecated depuis 3 releases dans DRF \o/ Mais deprecated sur les Serializer uniquement hein, pas les Viewset. Enfin je dis ça…

Dernièrement j’ai mis les fonctions suivantes dans mon script PYTHONSTARTUP…

Toujours choper une event loop toute fraiche, et ouverte:

import asyncio
 
def aloop(*args, **kargs):
    """ Ensure they is an opened event loop available and return it"""
    loop = asyncio.get_event_loop()
    if loop.is_closed():
        policy = asyncio.get_event_loop_policy()
        loop = policy.new_event_loop(*args, **kargs)
        policy.set_event_loop(loop)
    return loop

Lancer une coroutine dans une event loop jusqu’à ce qu’elle se termine:

import inspect
 
def arun(coro):
    """ Run this in a event loop """
    loop = aloop()
    if not inspect.isawaitable(coro):
        if not inspect.iscoroutinefunction(coro):
            coro = asyncio.coroutine(coro)
        coro = coro()
    future = asyncio.ensure_future(coro)
    return loop.run_until_complete(future)

Et ça s’utilise comme ça:

async def foo():
    await asyncio.sleep(1)
    print('bar')
 
arun(coro)

Ca me fait gagner pas mal de temps.

J’utilise aussi cette commande magique dans iPython qui permet de balancer des await en plein milieu du shell. Je suis en train de voir pour ajouter un truc similaire à ptpyhon.

Je me suis fait aussi un petit script pour lancer vite fait n’importe quel script dans une boucle asyncio de manière transparente, mais j’ai pas le temps de poster ça aujourd’hui donc ça sera pour la prochaine fois.

Je travaillais pour un client dont l’infrastructure m’avait pris quelques jours à prendre en main. Avec l’aide de toute l’équipe et de la patience, victoire, j’avais l’env de prod sur ma machine, et je pouvais faire tourner le produit…

Previouly, on Sam and Max

Je me rend sur la page d’accueil, qui me redirige instantanément sur l’admin du site Django.

Ceci n’avait aucun sens. Je regarde les requêtes HTTP, j’ai une 302 qui sort de nulle part. Je suis authentifié, ma conf nginx est pas déconnante, et dans le routing défini du urls.py, le pattern pour l’admin est le classique http://domain.tld/admin.

Rien de fou.

Alors après m’être arraché les cheveux, je vais voir un techos et lui demande si à tout hasard il a une idée.

- Il me dit “tu as appelé ton user comment ?”

– Oh, j’ai fait un ./manage.py createsuperuser vite fait pour tester en local avec username:admin, password:admin.

– Ben c’est ça, on peut pas créer un user qui s’appelle “admin”.

– Ah ?

– Oui on a un url pattern pour la page du profile utilisateur qui fait:

http://domain.tld/<username>

Quand tu arrives sur /, on redirige dessus automatiquement.

Du coup si tu l’appelles admin, tu as plus accès à ton profile…

And now…

Aujourd’hui, en explorant la base de code, je tombe sur ça:

class RegistrationForm(forms.Form):
 
    _reserved_usernames = [
        'accounts',
        'about',
        'admin',
        'clients',
        'data',
        'forms',
        'maps',
        ... + 50
    ]

J’ai de quoi écrire un bouquin avec le contenu des fichiers que je vois, je sens que ça va me faire quelques articles :)