Malgré les critiques, j’aime beaucoup AngularJS. Mais à l’annonce de la version 2 d’Angular complètement incompatible avec la version 1, seulement quelques années après sa sortie, des questions se sont posées sur l’avenir du framework.

J’utilise AngularJS pour certains de mes projets, je suis payé pour former sur AngularJS et j’ai commencé à écrire un guide sur le sujet.

Mais je me demande franchement si ça vaut le coup de s’investir plus.

Je vais continuer à l’utiliser pour mes projets actuels, tout en regardant du côté de la concurrence ici et là.

Si j’écris l’article, ce n’est pas pour vous alarmer. Ni même pour vous dire “arrêtez d’utiliser Angular”. Je pense que la V1 va être maintenue par la communauté pendant des années.

Non, je me demande simplement si ça vaut le coup que je me casse le cul à finir le guide.

J’ai du travail à la pelle, le guide sur les tests en Python, Django une app à la fois, 0bin à porter en Python 3…

Bref, est-ce que vous êtes toujours aussi intéressés par ce guide ?

L’implémentation de référence de Python est écrite en C, et son API est exposée et bien documentée. Il est donc possible de créer des objets Python, charger un module Python ou exécuter une fonction Python depuis un code C/C++ et compiler tout ça.

Mettons que j’ai dans un fichier biblio.py :

def yolo(arg):
    return arg.upper() + ' !!'

Je peux écrire un fichier prog.c qui l’utilise :

#include <Python.h>
 
int main () {
    // PyObject est un wrapper Python autour des objets qu'on
    // va échanger enter le C et Python.
    PyObject *retour, *module, *fonction, *arguments;
    char *resultat;
 
    // Initialisation de l'interpréteur. A cause du GIL, on ne peut
    // avoir qu'une instance de celui-ci à la fois.
    Py_Initialize();   
 
    // Import du script. 
    PySys_SetPath("."); // Le dossier en cours n'est pas dans le PYTHON PATH
    module = PyImport_ImportModule("biblio");
 
    // Récupération de la fonction
    fonction = PyObject_GetAttrString(module, "yolo");
 
    // Création d'un PyObject de type string. Py_BuildValue peut créer
    // tous les types de base Python. Voir :
    // https://docs.python.org/2/c-api/arg.html#c.Py_BuildValue
    arguments = Py_BuildValue("(s)", "Leroy Jenkins"); 
 
    // Appel de la fonction.
    retour = PyEval_CallObject(fonction, arguments);
 
    // Conversion du PyObject obtenu en string C
    PyArg_Parse(retour, "s", &resultat);
 
    printf("Resultat: %s\n", resultat);
 
    // On ferme cet interpréteur.
    Py_Finalize(); 
    return 0;
}

Là je mets du C, mais la seule vraie différence avec du C++, c’est qu’on aurait cout au lieu de printf.

Pour compiler tout ça, il faut les headers Python et un compilateur. Sous Ubuntu, c’est un simple :

sudo apt-get install python-dev gcc

Et on a tout nos .h dans /usr/include/python2.7. On gccise :

gcc -I/usr/include/python2.7 prog.c -lpython2.7 -o prog -Wall  && ./prog

Même pas un warning, c’est beau.

./prog
Resultat: LEROY JENKINS !!

C’est un exemple simple, mais comme vous le savez je suis une grosse burne en C, donc je ne pourrai pas porter l’expérience plus loin.

Je ne le recommande pas pour rendre votre programme scriptable en Python. Il vaut mieux permettre à Python d’appeler votre code C dans ce cas. Des outils comme cffi rendent cela beaucoup plus facile et rentable que tout faire tout le taff à la main. D’ailleurs si quelqu’un est chaud pour faire un tuto sur cffi…

Non, c’est plus dans le cas où vous avez un programme C, un programme Python, et votre programme C veut utiliser le programme Python sans avoir à tout réécrire. Ou pour le cas où vous avez décidé d’écrire une grosse partie de votre programme en Python pour profiter de sa productivité, mais que vous ne pouvez pas installer Python sur la machine sur laquelle vous aller installer le programme. Bon, y a PyInstaller et Nuitka pour ça également hein, donc tentez avant de tout embeder comme un bourrin.

Ça reste intéressant de voir les entrailles de CPython et à quel point il joue bien avec les langages bas niveaux.

Tout le monde connait le fichier __init__.py, mais __main__.py est moins connu.

Il permet de lancer du code si on tente d’exécuter un package (c’est à dire un dossier qui contient un fichier __init__.py):

$ tree monpackage/
monpackakge/
├── __init__.py
└── __main__.py
 
0 directories, 2 files
$ cat monpackage/__main__.py
print('Hello :)')
$ python monpackage/ # ceci est un dossier 
Hello :)

Le __main__.py est aussi exécuté quand on fait python -m monpackage.

Notez que son exécution suppose l’import préalable du package, et que donc __init__.py sera toujours exécuté avant __main__.py. En revanche, faire juste import monpackage ne déclenche pas l’exécution de __main__.py.

Si vous zippez votre package et appelez la commande python, c’est aussi ce fichier qui sera exécuté. Pratique donc, pour faire un exécutable portable à peu de frais, tout en gardant la lib importable.

Le duck typing, qu’on pourrait traduire par “typage canard” mais on ne le fera pas parce que c’est très moche, est une manière de créer des APIs basée sur la philosophie que l’aspect pratique est plus important que la pureté du code.

L’idée est de créer des signatures de callable qui acceptent des paramètres en fonction de leur comportement, pas leur type :

Si ça marche comme un canard et que ça fait le bruit d’un canard, alors ça ressemble assez à un canard pour le traiter comme un canard

Imaginez que vous ayez un objet avec un interface ICanard:

class ICanar:
    def coin():
        pass

Une fonction qui est programmée selon le duck typing acceptera comme argument un objet qui possède la méthode coin, peut importe si il implémente cette interface ou non.

En gros, si un paramètre possède une interface suffisante pour nous, ou peut être casté en un objet avec une interface suffisante pour nous, on l’accepte. Cela rend un callable plus générique.

Ok, trève de bavardage, qu’est-ce que ça implique, dans la vraie vie vivante ?

Si je fais une fonction qui retourne le premier élément d’une liste ou un élément par défaut :

def getfirst(lst, default=None):
    try:
        return lst[0]
    except IndexError:
        return default

Pratique, et ça marche sur d’autres itérables :

>>> getfirst([1, 2, 3])
1
>>> getfirst('abcde')
'a'

On a une forme de duck typing : si on peut récupérer le premier élément, alors ça suffit pour nous. Peut importe qu’il s’agit d’une liste ou d’un tuple.

On peut néanmoins améliorer la généricité de cette fonction:

def getfirst(iterable, default=None):
    for x in iterable:
        return x
    return default

Ici, le comportement recherché est qu’on puisse faire une une boucle for dessus, pas qu’on puisse récupérer un élément par son index.

Cela rend la fonction encore plus flexible, ainsi elle marche sur les générateurs, les flux, les fichiers:

>>> getfirst(open('/etc/fstab'))
'# /etc/fstab: static file system information.\n'

Un autre exemple ? La fonction Python sum par exemple, accepte tout types de nombres :

>>> sum((1, 2, 3)) # integers
6
>>> sum((1.3, 2.4, 3.5)) # floats
7.2
>>> sum((1j, 2j, 3j)) # complexes
6j

Sympas, mais l’addition en Python supporte bien plus que les nombres :

>>> [1] + [2]
[1, 2]
>>> (1, 2) + (2, 4)
(1, 2, 2, 4)
>>> "a" + "b"
'ab'

Mais sum ne les accepte pas :

>>> sum("a", "b")
Traceback (most recent call last):
  File "<ipython-input-24-1e5baeda1183>", line 1, in <module>
    sum("a", "b")
TypeError: sum() can't sum strings [use ''.join(seq) instead]

Il est possible de faire un sum plus générique :

def sumum(*iterable, start=None, default=None):
    # On donne à l'utilisateur la possibilité
    # de passer un premier élément
    if start is None:
        # on récupère le premier élément
        try:
            start, *iterable = iterable
        except ValueError:
            # Il n'y a aucun élément dans l'itérable
            # donc on retourne la valeur par default
            return default
    # on additionne
    for x in iterable:
        start += x
    return start

Le duck typing, à son maximum :

>>> sumum('a', 'b', 'c')
'abc'
>>> sumum([1, 2], [3, 4])
[1, 2, 3, 4]

Le duck typing implique aussi une prise de décision. Qu’est-ce qui serait le plus pratique ? De pouvoir additionner tous les types additionnables ? Ou de pouvoir additionner n’importe quoi qui ressemble à un nombre ?

Imaginons que la plupart de nos libs, plutôt que de fournir la possibilité d’additionner, propose la possibilité de caster vers un float :

class Temperature:
    def __init__(self, value, unit='C'):
        self.value = float(value)
        self.unit = unit
    def __float__(self):
        if self.unit == 'C':
            return self.value
        if self.unit == 'K':
            return self.value - 273.15
        if self.unit == 'F':
            return (self.value - 32) * 5/9
    def __repr__(self):
        return '%s %s' % (self.value, (self.unit != 'K')*'°'+self.unit)
 
t1 = Temperature(5)
t2 = Temperature(3, 'K')
t3 = Temperature(30, 'F')
t1, t2, t3
## (5.0 °C, 3.0 K, 30.0 °F)

Dans ce cas notre fonction pourrait convertir tous les éléments d’un itérable avant addition :

def sumcast(*iterable, start=None, default=None):
    # On donne à l'utilisateur la possibilité
    # de passer un premier élément
    if start is None:
        # on récupère le premier élément
        try:
            start, *iterable = iterable
        except ValueError:
            # Il n'y a aucun élément dans l'itérable
            # donc on retourne la valeur par default
            return default
    # on additionne en convertissant tout en float
    start = float(start)
    for x in iterable:
        start += float(x)
    return start
 
>>> sumcast(1, "3", t1, t2, t3)
-262.26111111111106

Dans tous les cas, on se fiche complètement que nos objets soient d’un type précis ou qu’ils implémentent une interface précise à partir du moment où leur API est suffisamment proche du ce type ou de l’interface dont on a besoin.

Le duck typing a beau être une pratique vouée à simplifier la vie au prix du formalisme, il ne dispense pas de documenter votre code à propos de cette subtilité afin que l’utilisateur final n’ait pas de mauvaise surprise.

Il convient de ne pas abuser du duck typing, qui est là pour rendre service uniquement. Si vous ajoutez des cas farfelus dans votre code pour supporter des situations rares, vous le rendez plus compliqué et moins robuste. Visez la généricité pour les situations les plus courantes, pas toutes les situations possibles.

Et souvenez-vous que plus on est dynamique sur les types, plus on perd en performance. Il faut savoir quelle part de compromis on est prêt à faire.

Ceci est un post invité de Bussiere posté sous licence creative common 3.0 unported.

Ce petit article a pour but d’expliquer selon moi ce qu’est l’hypnose et comment cela agit pour moi comme un exhausteur de gout pour la domination / sexe.

L’hypnose de mon point de vue est un hack du cerveau, il revient a faire tilter le cerveau de quelqu’un pour en prendre le contrôle.

Selon moi 95% des gens sont sensibles a l’hypnose et 15% de ses 95 % sont ultras sensibles.
Les spectacles que vous verrez ne sont que sur les gens ultra sensibles, après la prise de drogue, le manque de sommeil et l’alcool peuvent rendre les gens ultra sensibles. De plus une personne qui perd ses repères devient plus sensible a l’hypnose j’ai déjà eu l’occasion de tester hypnose et urbex par exemple dans le cadre de la domination.

La domination et le sub space pour moi se rapprochent énormément de l’hypnose, pour moi les deux étaient fait pour se Rencontrer.

De base la domination rend quelqu’un de sensible ultra sensible, et quelqu’un ayant jouis et du coup abaissant toute ses défense devient ultra sensible a l’hypnose de même que quelqu’un en subspace.

J’utilise l’hypnose en domination de plusieurs manières :

Soit pour laisser des mots de commande exemples :

Miaouss pour que la soumise ne puisse que miauler et ne plus parler.
Persian pour qu’elle puisse reparler de nouveau
Spectre pour qu’elle se mette a genoux et ne puisse plus bouger.
Piroli pour qu’elle se fasse plaisir seule.
Rondoudou pour qu’elle s’endorme et parte.
Dracofeu pour la montée de chaleur.

Le plus amusant étant de pouvoir jouer avec des mots de commande en public…

Soit par association :

J’associe les cordes au plaisir

et quand j’attache quelqu’un, cette personne ressent des montées de chaleur plus les cordes la touche. Chose que je fais souvent en performance.

J’ai remarqué que les cordes augmentaient les effets de l hypnose au point ou j’ai des amies qui me demande de les attacher habillées et de les hypnotiser pour les détendre après.

Une chose amusante est aussi de lier un foulard au plaisir et de passer le foulard sur le corps.

Mais sans aller jusqu’à l’hypnose “dure” le conditionnement fait partie de l”hypnose et tout le monde peut le faire. Prenez du velours, si dans les préliminaire quand votre partenaire éprouve du plaisir vous jouez avec un morceau de velours régulièrement, ce morceau de velours sera associé au plaisir. Donc il y aura un effet d’association qui décuplera le reste, et parfois selon votre partenaire juste sortir ce morceau de tissus suffira a le / la faire rougir.

Soit pour augmenter la sensibilité au reste :
Il suffit par hypnose de conditionner la personne et de lui augmenter tout les sens pour qu’elle ressente encore plus de choses.

Apres l’hypnose fait peur j’ai des personnes qui acceptent de me laisser leur corps, je peux les attacher nues mais pas toucher a leur esprit. C’est leur choix et je le respecte mais j’ai du mal a comprendre dans la mesure ou le corps pour moi est une porte sur l’esprit.

J’aimerai savoir si d’autres personnes pratiquent aussi l’hypnose avec la domination ici.

Et en tant que dominateur j’apprécie particulièrement le contrôle sur l’esprit qui pour moi est largement au dessus du corps surtout chez les femmes. Les femmes étant largement plus mental que les hommes, arriver a jouer avec leur esprit est une satisfaction largement plus gratifiante que juste jouer avec les corps.

Sérieusement si vous arrivez a tenir une femme par le mental vous l’emmenez ou vous voulez …
Tout ce qui est préliminaires , jeux , situations , rôles contribue a conditionner une femme et a lui donner plus de plaisir. Sans aller jusqu’à l’hypnose je recommande d’être joueur.

L’hypnose est un outil très intéressant pour tout ce qui touche a la domination si on le rajoute au reste, il en multiplie les effets et le reste décuple les effets de l’hypnose.

Quand vous forcez quelqu’un a se mettre a genoux devant vous , ou qu’il est vulnérable face a vous l’hypnose marchera mieux. Quand vous faites oublier son nom a quelqu’un en “jouant” avec lui il devient plus sensible a l’hypnose.

Bon par contre il y a des questions d’éthiques , personnellement j’ai l’éthique du bdsm qui consiste en un safe word, d’être sur du consentement de la personne sans aucun biais (hypnose, alcool , drogue , fatigue) et souvent de définir un contrat avec la personne sur les choses permises. Et en cas d’absence de contrat je m’abstiens de toute choses plus poussées et j’y vais par pallier.

Ma plus belle réussite reste d’arriver a faire se mettre a genoux et immobiliser une soumise puis la faire jouir en claquant des doigts sans la toucher, tout avec la voix.

Dans un autre domaine j’ai fait un petit jeu open source basé sur l’hypnose :
http://ragemag.fr/oculus-rift-hypnose-virtuelle-ragemag-mystifier-jeu-video-45716/

Et un type que je recommande derren brown :
https://www.youtube.com/user/OfficialDerren

Et pour finir une petite chanson :