relecture de la formation
This commit is contained in:
Benjamin Bohard
parent
62b57d9dfb
commit
3569c00af1
|
|
@ -3,7 +3,7 @@ Programmation python courante
|
|||
|
||||
.. _namespaces:
|
||||
|
||||
les espaces de nommage
|
||||
Les espaces de nommage
|
||||
-----------------------
|
||||
|
||||
Packages et modules::
|
||||
|
|
@ -15,9 +15,9 @@ Packages et modules::
|
|||
__init__.py
|
||||
module2.py
|
||||
|
||||
A utilser pour organiser votre projet
|
||||
Permet de minimiser les risques de conflits de nome
|
||||
Permet de diminuer les entrées dans le :envvar:`PYTHONPATH`
|
||||
À utilser pour organiser votre projet.
|
||||
Permet de minimiser les risques de conflits de nom.
|
||||
Permet de diminuer les entrées dans le :envvar:`PYTHONPATH`.
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -35,31 +35,31 @@ Permet de diminuer les entrées dans le :envvar:`PYTHONPATH`
|
|||
|
||||
from os import *
|
||||
|
||||
lance un module en tant que script :
|
||||
Lancer un module en tant que script :
|
||||
|
||||
::
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
|
||||
Organisation modulaire
|
||||
Organisation modulaire :
|
||||
|
||||
- construire des composants élémentaires
|
||||
- combiner ces composants
|
||||
- construire des composants élémentaires ;
|
||||
- combiner ces composants ;
|
||||
- utiliser une structure pyramidale : les composants sont les éléments de
|
||||
composants plus complexes.
|
||||
|
||||
|
||||
- découplage de l'ensemble en composants indépendants (gros programmes réalisables)
|
||||
- donner de la structure (rendre les gros programmes compréhensibles)
|
||||
- spécifier les liens entre les composants (rendre les programmes maintenables)
|
||||
- identifier les sous-composants indépendants (rendre les programmes réutilisables)
|
||||
- forcer l'abstraction (augmenter la sureté du programme)
|
||||
- découplage de l'ensemble en composants indépendants (gros programmes réalisables) ;
|
||||
- donner de la structure (rendre les gros programmes compréhensibles) ;
|
||||
- spécifier les liens entre les composants (rendre les programmes maintenables) ;
|
||||
- identifier les sous-composants indépendants (rendre les programmes réutilisables) ;
|
||||
- forcer l'abstraction (augmenter la sureté du programme).
|
||||
|
||||
Les méthodes spéciales
|
||||
-----------------------
|
||||
|
||||
méthodes spéciales correspondants aux interfaces des types de bases :
|
||||
Méthodes spéciales correspondant aux interfaces des types de bases :
|
||||
|
||||
.. function:: __init__(self, *args, **kwargs)
|
||||
le constructeur de l'instance d'objet
|
||||
|
|
@ -106,9 +106,9 @@ aux attributs est règlable.
|
|||
>>> cobj.__dict__['insattr']
|
||||
'an instance attribute'
|
||||
|
||||
les attributs ne sont pas systématiquement encapsulées en python.
|
||||
Les attributs ne sont pas systématiquement encapsulés en python.
|
||||
|
||||
pour contrôler l'accès aux attributs, on utilise les méthodes spéciales::
|
||||
Pour contrôler l'accès aux attributs, on utilise les méthodes spéciales::
|
||||
|
||||
__getattr__(self, name)
|
||||
|
||||
|
|
@ -139,7 +139,7 @@ pour contrôler l'accès aux attributs, on utilise les méthodes spéciales::
|
|||
Dict with a default value
|
||||
--------------------------
|
||||
|
||||
il est possible d'hériter des types de base
|
||||
Il est possible d'hériter des types de base
|
||||
|
||||
>>> a = dict.defaultdict(default=0)
|
||||
>>> a
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ Password:
|
|||
.. module:: shelve
|
||||
:synopsis: linéarisation de données
|
||||
|
||||
linéarisation de données
|
||||
Linéarisation de données
|
||||
==========================
|
||||
|
||||
>>> import shelve
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ deux
|
|||
1
|
||||
>>>
|
||||
|
||||
fonctions
|
||||
Fonctions
|
||||
-----------
|
||||
|
||||
>>> def blabla(x):
|
||||
|
|
@ -69,7 +69,7 @@ fonctions
|
|||
...
|
||||
>>>
|
||||
|
||||
il n'y a que des fonctions (et pas de procédures):
|
||||
Il n'y a que des fonctions (et pas de procédures):
|
||||
|
||||
|
||||
>>> def ma_func(x):
|
||||
|
|
@ -147,13 +147,13 @@ argumments nommés {'tata': 3, 'tutu': 2}
|
|||
>>> vars(a)
|
||||
{'a': 'titi', 'b': 'toto'}
|
||||
|
||||
puisque tout est objet en python, ``vars(mon_objet)`` est équivalent à
|
||||
Puisque tout est objet en python, ``vars(mon_objet)`` est équivalent à
|
||||
``mon_objet.__dict__``
|
||||
|
||||
|
||||
- générateurs et compréhension de liste
|
||||
|
||||
les compréhensions de listes permettent de générer de nouvelles listes
|
||||
Les compréhensions de listes permettent de générer de nouvelles listes
|
||||
|
||||
exemple :
|
||||
|
||||
|
|
@ -169,7 +169,7 @@ exemple :
|
|||
[(2, 4), (2, 5), (2, 6), (2, 7), (3, 4), (3, 5), (3, 6), (3, 7), (4, 4), (4, 5), (4, 6), (4, 7)]
|
||||
>>>
|
||||
|
||||
les expressions générateurs
|
||||
Les expressions générateurs
|
||||
|
||||
>>> expr = (2*i for i in range(10))
|
||||
>>> expr
|
||||
|
|
@ -190,10 +190,10 @@ les expressions générateurs
|
|||
>>>
|
||||
|
||||
|
||||
le polymorphisme paramétrique
|
||||
Le polymorphisme paramétrique
|
||||
-----------------------------
|
||||
|
||||
polymorphisme exemple de contexte :
|
||||
Polymorphisme exemple de contexte :
|
||||
la fonction print
|
||||
|
||||
>>> print 1
|
||||
|
|
@ -203,7 +203,7 @@ la fonction print
|
|||
|
||||
.. todo:: `print 1` et `print "1"` renvoient le même résultat. Pourquoi ?
|
||||
|
||||
la programmation par exceptions
|
||||
La programmation par exceptions
|
||||
-------------------------------------
|
||||
|
||||
>>> def function_raise(x):
|
||||
|
|
@ -224,7 +224,7 @@ Pas le bon type
|
|||
ou bien lever une exception
|
||||
|
||||
|
||||
programmation objet
|
||||
Programmation objet
|
||||
--------------------
|
||||
|
||||
- la programmation objet définit des classes
|
||||
|
|
@ -249,13 +249,13 @@ hello
|
|||
|
||||
- définition d'une classe :
|
||||
|
||||
méthode classique :
|
||||
Méthode classique :
|
||||
|
||||
>>> class A:
|
||||
... pass
|
||||
...
|
||||
|
||||
méthode dynamique (la fonction :func:`type` est ici un **constructeur** :
|
||||
Méthode dynamique (la fonction :func:`type` est ici un **constructeur** :
|
||||
|
||||
>>> type("A", (), {})
|
||||
<class '__main__.A'>
|
||||
|
|
@ -264,16 +264,16 @@ méthode dynamique (la fonction :func:`type` est ici un **constructeur** :
|
|||
>>> type(a)
|
||||
<class '__main__.A'>
|
||||
|
||||
types et classe
|
||||
Types et classe
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
affichage d'une calculette, il faut créer un type `Touche`
|
||||
Affichage d'une calculette, il faut créer un type `Touche`
|
||||
qui contient deux désignations : `Chiffre` et `operation`::
|
||||
|
||||
type operation = Plus | Moins | Divise
|
||||
type touche = Chiffre of int | Memoire | Op of operation
|
||||
|
||||
soit, on définit un type touche, soit on ne définit pas ce type::
|
||||
Soit on définit un type touche, soit on ne définit pas ce type::
|
||||
|
||||
type operation = Plus | Moins | Divise
|
||||
type memoire = Memoire
|
||||
|
|
|
|||
|
|
@ -3,14 +3,14 @@ Tests unitaires et pile d'appels
|
|||
|
||||
Les tests automatiques sont un complément à la déclaration des types.
|
||||
|
||||
que tester, quoi tester ?
|
||||
Que tester, quoi tester ?
|
||||
|
||||
- que les composants interagissent bien entre eux
|
||||
- que les unités (fonctions, objets...) réagissent bien à une entrée spécifique
|
||||
- que le code se comporte de la manière attendue dans des environnements différents
|
||||
(systèmes d'exploitation, etc...)
|
||||
|
||||
les types de tests :
|
||||
Les types de tests :
|
||||
|
||||
- tests unitaires
|
||||
- tests fonctionnels
|
||||
|
|
@ -52,7 +52,7 @@ http://pytest.org/latest/
|
|||
|
||||
- écrire un fichier commençant par `test_` qui teste les fonctions du fichier
|
||||
|
||||
options utiles dans `py.test`
|
||||
Options utiles dans `py.test`
|
||||
------------------------------
|
||||
|
||||
::
|
||||
|
|
@ -67,10 +67,10 @@ options utiles dans `py.test`
|
|||
py.test -k test_simple
|
||||
|
||||
|
||||
utiliser la pile d'appel pour débugger
|
||||
Utiliser la pile d'appel pour débugger
|
||||
---------------------------------------
|
||||
|
||||
utiliser la pile d'appels, elle se lit de bas en haut. Il est possible de
|
||||
Utiliser la pile d'appels, elle se lit de bas en haut. Il est possible de
|
||||
provoquer cette pile d'appels.
|
||||
|
||||
::
|
||||
|
|
@ -79,7 +79,7 @@ provoquer cette pile d'appels.
|
|||
traceback.print_exc()
|
||||
|
||||
|
||||
traiter une exception avec
|
||||
Traiter une exception avec
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -95,9 +95,9 @@ traiter une exception avec
|
|||
bla bla
|
||||
|
||||
|
||||
créer le plus possible ses propres exceptions spécifiques au programme
|
||||
Créer le plus possible ses propres exceptions spécifiques au programme.
|
||||
|
||||
utiliser le module :mod:`pdb`
|
||||
Utiliser le module :mod:`pdb`
|
||||
|
||||
.. module:: pdb
|
||||
:synopsis: debugger de la lib standard
|
||||
|
|
@ -144,7 +144,7 @@ Remarquons que :mod:`pdb` utilise le module :mod:`cmd`, voir :ref:`cmdlabel` qu'
|
|||
(Pdb)
|
||||
|
||||
|
||||
last but not least :
|
||||
Last but not least :
|
||||
|
||||
utiliser pylint ou pychecker
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue