from itertools import product
def f1(it, n):
return list(map(''.join, product(it, repeat=n)))
def f2(it, n):
ls = ['']
for _ in range(n):
ls = [a + b for a in ls for b in it]
return ls
from string import ascii_lowercase
from time import perf_counter
args = (ascii_lowercase, 8)
for funct in (f1, f2):
time = perf_counter()
_ = funct(*args)
time = perf_counter() - time
print(funct.__name__, time)
Voici ma version de base, je pense qu'on peut faire mieux (fais un copier-coller pour retrouver l'indentation) - def pascal(n): if n<=0: return [1] L=pascal(n-1) LL=[1] for i in range(1,n): LL.append(L[i-1]+L[i]) LL.append(1) return LL for i in range(6): print(pascal(i))
Le Tout est souvent plus grand que la somme de ses parties.
t@josmiley: tu triches ... Légère amélioration: Faudrait voir ce qu'on peut faire avec reduce() - def pascal(n): if n<=0: return [1] L=pascal(n-1) return [1] + [L[i-1]+L[i] for i in range(1, n)] + [1] for i in range(6): print(pascal(i))
Le Tout est souvent plus grand que la somme de ses parties.
import sys
def pascal(limit):
num = 1
for i in range(limit):
s = ""
for j in range(i+1):
if j == 0 or i == j:
num = 1
else:
num = (num * (i-j+1)) // j
s += " " + str(num)
print(s.center(limit*4))
pascal(15)
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard) La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Si je suppose qu'un des objectifs de l'exercice est de "dessiner" le triangle de Pascal de façon esthétique, j'aurai besoin du nombre de chiffres du plus grand nombre. Ce nombre se trouve au milieu de la liste correspondant à la plus grande puissance. De plus, si je dois construire toutes les lignes, la méthode récursive m'impose de recalculer les sous-résultats. J'ai décidé de procéder autrement. - power = 10 # Puissance maximum ligne = [1] # Première ligne. triangle = [ligne] # Triangle de Pascal (j'ai failli écrire Des Bermudes ...) for _ in range(power): ligne = [i+j for i, j in zip([0]+ligne, ligne+[0])] # Pas forcément la plus efficace. triangle.append(ligne) width = len(str(triangle[-1][len(triangle[-1])//2])) # Nombre de caractères par nombre. spaces = ' '*width fmt = lambda n, w: (' '*w+str(n))[-w:] for p in range(power+1): print(spaces*(power-p), end='') print(*(fmt(number, width) for number in triangle[p]), sep=spaces)
Le Tout est souvent plus grand que la somme de ses parties.
Si je suppose qu'un des objectifs de l'exercice est de "dessiner" le triangle de Pascal de façon esthétique, j'aurai besoin du nombre de chiffres du plus grand nombre. Ce nombre se trouve au milieu de la liste correspondant à la plus grande puissance. De plus, si je dois construire toutes les lignes, la méthode récursive m'impose de recalculer les sous-résultats. J'ai décidé de procéder autrement. - power = 10 # Puissance maximum ligne = [1] # Première ligne. triangle = [ligne] # Triangle de Pascal (j'ai failli écrire Des Bermudes ...) for _ in range(power): ligne = [i+j for i, j in zip([0]+ligne, ligne+[0])] # Pas forcément la plus efficace. triangle.append(ligne) width = len(str(triangle[-1][len(triangle[-1])//2])) # Nombre de caractères par nombre. spaces = ' '*width fmt = lambda n, w: (' '*w+str(n))[-w:] for p in range(power+1): print(spaces*(power-p), end='') print(*(fmt(number, width) for number in triangle[p]), sep=spaces)
Le formatage est la seule partie de l'exercice qui ne soit pas évidente. Tu obtiens un très joli résultat, j'affiche ce que ça donne pour p=14 :
Je ne sais pas s'il est faisable de faire en sorte que chaque nombre soit exactement au milieu des deux nombres dont il est la somme et que l'écartement soit minimal. Dans ton code ci-dessus 19448 est plus proche (de 1 caractère) de 11440 que de 8008 et cela se produit à plusieurs endroits.
Il y a deux problèmes de centrage. D'abord, si le nombre le plus grand a un nombre impair de chiffres, je ne peux pas centrer les nombres ayant un nombre pair de chiffres. On a le même problème si le plus grand nombre a un nombre pair de chiffres avec les nombres ayant un nombre impair de chiffres. Je peux essayer de centrer un peu tout de même, Ce ne sera pas parfait. J'ai revérifié sur ma console et les nombres sont bien à leur place mais pas centrés dans leur zone.
Le Tout est souvent plus grand que la somme de ses parties.
tJ'ai réécrit ma fonction fmt() qi essaie de centrer autant que possible: fmt=lambda n, w: (s:=str(n), l:=len(s), ' '*((w-l+1)//2)+s+' '*((w-l)//2))[-1]
Le Tout est souvent plus grand que la somme de ses parties.
tJ'ai réécrit ma fonction fmt() qi essaie de centrer autant que possible: fmt=lambda n, w: (s:=str(n), l:=len(s), ' '*((w-l+1)//2)+s+' '*((w-l)//2))[-1]
À mon sens, c'est typiquement dans ce type d'exercice que PyPy et Cython peuvent sortir leur épingle du jeu.
Je pense pas qu'en pure python on puisse faire beaucoup mieux que le code que tu proposes.
Pour PyPy, j'ai essayé, sur cet exemple l'exécution et l'occupation mémoire sont TRÈS mauvaises.
Pour Cython, c'est une punition ! Typiquement, il va falloir travailler avec un gros tableau de caractères, et donc créer un tableau de pointeurs vers les lignes "virtuelles" car si on veut un code efficace, il faut faire des copies massives (l'algo s'y prête) via memcpy, autant dire que Cython ne va que compliquer les choses, autant le faire direct en C.
Je précise l'algo pour trouver par exemple tous les 81 mots de 4 lettres sur l'alphabet a, b, c :
On construit un tableau 4 x 81 de caractères
On remplit la ligne 0 avec a, b et c.
On duplique sur la même ligne pour obtenir la suite de caractères abcabcabc
ligne 1 : on écrit à partir du début la suite de caractères aaabbbccc
On recommence : on duplique 3 fois le bloc 2x9 et on lui colle en dessous une séquence a...ab...c...c
etc
on transpose le tableau pour récupérer les lignes
Donc on se dit qu'on peut largement vectoriser cela avec Numpy. Le problème est que Numpy n'est pas meilleur que python pour travailler sur des chaînes, donc on préfère travailler avec le code ascii des caractères (des uint8) puis reconvertir d'où le code :
from string import ascii_lowercase
import numpy as np
from time import perf_counter
def copy_block(L, alpha, nline, w, n):
# le bloc à répéter
M=L[:nline, :w]
# la copie
C=np.repeat(M,n, axis=0)
# affectation
L[:nline,:w*n]=C.reshape(nline,w*n)
# rajout de ligne
A=np.array([ord(c) for c in alpha])
B=np.zeros(w, dtype=np.uint8).reshape(w,1)
L[nline,:w*n]=(A+B).transpose().flatten()
def product(alpha, p):
n=len(alpha)
L=np.zeros(shape=(p, n**p), dtype=np.uint8)
L[0][:n]=[ord(c) for c in alpha]
nline=1
w=n
for nline in range(1,p):
copy_block(L, alpha, nline, w, n)
w*=n
L=np.array([chr(x) for x in range(128)])[L.transpose()]
join="".join
M=list(map(join, L))
return M
begin_perf = perf_counter()
n=3
p=4
alpha=ascii_lowercase[:n]
# ---- Début de code à exécuter ----
M=product(alpha, p)
# ---- Fin de code à exécuter ----
delta = perf_counter() - begin_perf
print(f"Temps d'exécution : {delta:.2f}s")
M
Hélas, il y a un problème d'efficacité, qui vient de Python. Dans le code ci-dessus (ligne 28), L est un tableau Numpy de caractères dont les lignes sont exactement les caractères des chaînes que nous cherchons. L'obtention de L est assez efficace, pour p=8 et n= 9, ça s'obtient en 1,8s dont les 2/3 (quand même) à reconvertir les code ascii en caractères, à comparer aux 6,35s du code proposé plus haut. La partie TRÈS couteuse du code vient de la ligne 30 qui définit M et qui fusionne avec join les caractères de chaque ligne pour obtenir chaque mot : rien que pour n=8 et p=8, ça prend 35s et une conso mémoire qui croit doucement mais surement, inimaginable à faire pour n=9.
Pour Cython, c'est une punition ! Typiquement, il va falloir travailler avec un gros tableau de caractères, et donc créer un tableau de pointeurs vers les lignes "virtuelles" car si on veut un code efficace, il faut faire des copies massives (l'algo s'y prête) via memcpy, autant dire que Cython ne va que compliquer les choses, autant le faire direct en C.
Oui c'est bien pour ça que je ne l'ai pas écrit
Je suis même pas sûr que ça soit si rapide, car si on souhaite y retrouver la forme de la réponse, soit une liste de chaînes de caractères, il faudra utiliser la méthode decode pour transformer de bytes en str sur l'ensemble des tableaux de caractères calculés et cette méthode est très lente, sans compter la création d'un nouvelle liste où on y ajoute les éléments résultants de decode (boucle supplémentaire).
Bref effectivement, la seule solution est de faire du full cython, et du coup tu as raison, en fait du C pour l'ensemble de l'exercice.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard) La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
L'optimisation réside dans le choix de la structure retournée. Il n'est pas utile de générer et stocker toutes les combinaisons possibles. Une liste qui génère l’élément à la demande serai plus intéressante.
from collections import abc
class Combinations(abc.Sequence):
def __init__(self, digits, width):
self.digits = tuple(digits)
self.base = len(self.digits)
if self.base < 2:
raise ValueError
if not isinstance(width, int):
raise TypeError
if width < 1:
raise ValueError
self.length = self.base ** width
self.width = width
def __len__(self):
return self.length
def __getitem__(self, index):
if not isinstance(index, int):
raise TypeError
if index >= self.length:
raise IndexError
results, index = [], index % self.length
for _ in range(self.width):
results.append(self.digits[index % self.base])
index //= self.base
return results
if __name__ == "__main__":
from string import ascii_lowercase
class Posi(Combinations):
def __init__(self, width):
super().__init__(ascii_lowercase, width)
def __getitem__(self, index):
return ''.join(super().__getitem__(index))
seq = Posi(52)
print(seq[1_000_000_000], seq[-1_000_000_000], sep='\n')
L'optimisation réside dans le choix de la structure retournée. Il n'est pas utile de générer et stocker toutes les combinaisons possibles. Une liste qui génère l’élément à la demande serai plus intéressante.
Merci de cette contribution et du code intéressant. Ici, la question était de retourner une liste. Le code que tu nous proposes est basé (c'est le cas de le dire) sur le fait qu'un élément de rang r donné du produit cartésien est parfaitement connu par l'écriture de r dans la base de numération définie par les chiffres donnés.
Au passage, je suis étonné de deux choses :
habituellement, la génération se fait dans l'ordre lexicographique croissant
il n'est pas possible de choisir ses chiffres.
Je modifie légèrement :
ctions import abc
class Combinations(abc.Sequence):
def __init__(self, digits, width):
self.digits = tuple(digits)
self.base = len(self.digits)
if self.base < 2:
raise ValueError
if not isinstance(width, int):
raise TypeError
if width < 1:
raise ValueError
self.length = self.base ** width
self.width = width
def __len__(self):
return self.length
def __getitem__(self, index):
if not isinstance(index, int):
raise TypeError
if index >= self.length:
raise IndexError
results, index = [], index % self.length
for _ in range(self.width):
results.append(self.digits[index % self.base])
index //= self.base
return results
from string import ascii_lowercase, digits
class Posi(Combinations):
def __init__(self, width, alpha):
super().__init__(alpha, width)
def __getitem__(self, index):
return ''.join(super().__getitem__(index))
seq = Posi(2, digits)
for i in range(42):
print(seq[i])
[Curieusement, les slices ne semblent pas fonctionner, seq[:42] lève une exception].
L'intérêt de ton code est de fournir à la volée n'importe quel élément d'«indice» donné (sans itérer donc). La contrepartie est que l'itération est extrêmement coûteuse même pour des valeurs raisonnables (une liste de quelques millions), c'est normal, on fait une conversion dans la base à chaque étape. Exemple :
from collections import abc
class Combinations(abc.Sequence):
def __init__(self, digits, width):
self.digits = tuple(digits)
self.base = len(self.digits)
if self.base < 2:
raise ValueError
if not isinstance(width, int):
raise TypeError
if width < 1:
raise ValueError
self.length = self.base ** width
self.width = width
def __len__(self):
return self.length
def __getitem__(self, index):
if not isinstance(index, int):
raise TypeError
if index >= self.length:
raise IndexError
results, index = [], index % self.length
for _ in range(self.width):
results.append(self.digits[index % self.base])
index //= self.base
return results
from string import ascii_lowercase
from time import perf_counter
class Posi(Combinations):
def __init__(self, width):
super().__init__(ALPHA, width)
def __getitem__(self, index):
return ''.join(super().__getitem__(index))
n=8
p=8
ALPHA=ascii_lowercase[:n]
seq=Posi(p)
begin_perf = perf_counter()
L=list(seq)
delta = perf_counter() - begin_perf
print(len(seq), n**p)
print(f"Temps d'exécution : {delta:.2f}s")
16777216 16777216
Temps d'exécution : 34.79s
Bien sûr, j'ai bien compris que tu ne souhaitais pas itérer mais parfois c'est utile si le nombre d'items reste raisonnable. En revanche, pas de problème de mémoire (même si elle croit doucement pendant toute l'exécution).
Pour itérer les combinaisons il faudrait utiliser itertools.product (sans passer par une liste ou autre conteneur).
Pour conserver les combinaisons générées il faudrait éviter de créer des millions d'objets distincts. Chaque objet référencé dans une liste pèse plusieurs octets en plus du poids déjà très élevé des objets eux-mêmes (à partir de 25 octets par objets vide ou numérique). Par exemple dans une chaîne de caractères, les perfs en temps et en espace sont déjà très bonnes :
s = ''.join(map(''.join, product(digits, repeat=width)))
Sinon je propose une refonte de la classe Combinations pour le support du slicing :
#!/usr/bin/env python3
from collections import abc
from string import digits
class Combinations(abc.Sequence):
def __init__(self, width, digits=digits):
self.digits = tuple(digits)
self.base = len(self.digits)
if self.base < 2:
raise ValueError
if not isinstance(width, int):
raise TypeError
if width < 1:
raise ValueError
self._data = range(self.base ** width)
self.width = width
def __len__(self):
return len(self._data)
def __getitem__(self, index):
if isinstance(index, slice):
subseq = self.__class__(self.width, self.digits)
subseq._data = self._data.__getitem__(index)
return subseq
item, index = [], self._data[index]
for _ in range(self.width):
item.append(self.digits[index % self.base])
index //= self.base
return item[::-1]
if __name__ == "__main__":
from string import hexdigits
class Posi(Combinations):
def __getitem__(self, index):
if isinstance(index, slice):
return super().__getitem__(index)
return ''.join(super().__getitem__(index))
seq = Posi(16, hexdigits)
sub = seq[::-1]
print(seq[25464985213], seq[-465482215655], sub[465482215654], sep='\n')
Pour itérer les combinaisons il faudrait utiliser itertools.product (sans passer par une liste ou autre conteneur).
Oui mais nous avons vu dans un message précédent que les performances mémoire d'itertools étaient, en l'espèce, très mauvaises par exemple pour n=9 et p=8 et je n'en vois pas la raison puisque product est un itérateur, il ne stocke rien.
.H.D.1. a écrit:
Sinon je propose une refonte de la classe Combinations pour le support du slicing :
Merci pour le code. Je crois que j'ai une erreur pour le slice :
#!/usr/bin/env python3
from collections import abc
from string import digits
class Combinations(abc.Sequence):
def __init__(self, width, digits=digits):
self.digits = tuple(digits)
self.base = len(self.digits)
if self.base < 2:
raise ValueError
if not isinstance(width, int):
raise TypeError
if width < 1:
raise ValueError
self._data = range(self.base ** width)
self.width = width
def __len__(self):
return len(self._data)
def __getitem__(self, index):
if isinstance(index, slice):
subseq = self.__class__(self.width, self.digits)
subseq._data = self._data.__getitem__(index)
return subseq
item, index = [], self._data[index]
for _ in range(self.width):
item.append(self.digits[index % self.base])
index //= self.base
return item[::-1]
if __name__ == "__main__":
from string import hexdigits, digits
class Posi(Combinations):
def __getitem__(self, index):
if isinstance(index, slice):
return super().__getitem__(index)
return ''.join(super().__getitem__(index))
seq = Posi(5, digits)
print(seq[:42])
<__main__.Posi object at 0x7f73a688d668>
J'ai essayé de faire un itérateur sans utiliser itertools en simulant l'ordre lexicographique :
from string import digits
from time import perf_counter
class Product:
def __init__(self, digits, width):
self.width=width
self.digits=digits
self.L=[0]*width
self.L[-1]=-1
self.base=len(digits)
def __iter__(self):
return self
def __next__(self):
L=self.L
base=self.base
d=self.digits
k=-1
try:
while L[k]+1==base:
L[k]=0
k-=1
L[k]+=1
return "".join(d[k] for k in L)
except IndexError:
raise StopIteration
n=8
p=8
begin_perf = perf_counter()
L=list(Product(digits[:n], p))
delta = perf_counter() - begin_perf
print(f"Temps d'exécution : {delta:.2f}s")
print(len(L), n**p)
Temps d'exécution : 18.10s
16777216 16777216
Bien sûr, c'est beaucoup plus lent qu'itertools, la boucle while ralentit tout mais c'est quand même plus rapide que de convertir dans la base. La conso mémoire est très importante (1 Go), à peu près comme ton code et pourtant rien n'est stocké (de visible).
Pour itérer les combinaisons il faudrait utiliser itertools.product (sans passer par une liste ou autre conteneur).
Oui mais nous avons vu dans un message précédent que les performances mémoire d'itertools étaient, en l'espèce, très mauvaises par exemple pour n=9 et p=8 et je n'en vois pas la raison puisque product est un itérateur, il ne stocke rien.
Ce n'est pas le fait de product mais de la liste. Chaque chaîne de la liste résultante pèse plusieurs dizaines d'octets, raison pour laquelle, si besoin de stocker les combinaisons, il est préférable de les concaténer dans une seule chaîne.
.H.D.1. a écrit:
Sinon je propose une refonte de la classe Combinations pour le support du slicing :
Merci pour le code. Je crois que j'ai une erreur pour le slice :
# ...
seq = Posi(5, digits)
print(seq[:42])
<__main__.Posi object at 0x7f73a688d668>
Le résultat d'un slice est un nouvel objet du type dont il est le slice. C'est le comportement normal d'un slicing.
Bien sûr, c'est beaucoup plus lent qu'itertools, la boucle while ralentit tout mais c'est quand même plus rapide que de convertir dans la base. La conso mémoire est très importante (1 Go), à peu près comme ton code et pourtant rien n'est stocké (de visible).
Quel est le code qui occupe 1Go et dans quelle condition ?
#!/usr/bin/env python3
from itertools import product
from memory_profiler import profile
@profile
def funct(s, n):
return ''.join(map(''.join, product(s, repeat=n)))
s = funct("0123456789", 7)
print(s[:7], s[7:14], '...', s[-14:-7], s[-7:])
(profiler) ~$ time mprof run untitled.py
mprof: Sampling memory every 0.1s
running new process
running as a Python program...
Filename: untitled.py
Line # Mem usage Increment Occurences Line Contents
============================================================
7 17.3 MiB 17.3 MiB 1 @profile
8 def funct(s, n):
9 84.5 MiB 67.2 MiB 1 return ''.join(map(''.join, product(s, repeat=n)))
0000000 0000001 ... 9999998 9999999
real 0m1,341s
user 0m1,095s
sys 0m0,157s
(profiler) ~$ cat mprofile_xxx.dat
CMDLINE /home/hd1/.venvs/profiler/bin/python3 untitled.py
MEM 1.398438 1624842158.8203
MEM 47.968750 1624842158.9206
MEM 120.906250 1624842159.0209
MEM 194.046875 1624842159.1211
MEM 268.796875 1624842159.2214
MEM 341.894531 1624842159.3217
MEM 416.261719 1624842159.4220
MEM 489.347656 1624842159.5223
MEM 565.070312 1624842159.6226
MEM 637.058594 1624842159.7229
MEM 631.699219 1624842159.8233
MEM 84.476562 1624842159.9235
Soit une chaîne de 67 Mo contenant 70 000 000 caractères, soit 10 000 000 combinaisons de 7 chiffres, et un pique à 637 Mo qui s'explique par l'accumulation des chaînes intermédiaires que le GC n'a pas eu besoin de nettoyer avant la fin de la concaténation.
Pour itérer les combinaisons il faudrait utiliser itertools.product (sans passer par une liste ou autre conteneur).
Oui mais nous avons vu dans un message précédent que les performances mémoire d'itertools étaient, en l'espèce, très mauvaises par exemple pour n=9 et p=8 et je n'en vois pas la raison puisque product est un itérateur, il ne stocke rien.
Ce n'est pas le fait de product mais de la liste. Chaque chaîne de la liste résultante pèse plusieurs dizaines d'octets, raison pour laquelle, si besoin de stocker les combinaisons, il est préférable de les concaténer dans une seule chaîne.
Ah oui ! c'est vrai que j'ai mesuré la construction de la liste. Si on teste seulement l'itération sur les 43 millions de chaînes :
from time import perf_counter
from itertools import product
from string import ascii_lowercase
p=8
n=9
alpha=ascii_lowercase[:n]
begin_perf = perf_counter()
cpt=0
for x in product(alpha, repeat=p):
"".join(x)
cpt+=1
delta = perf_counter() - begin_perf
print(cpt, n**p)
print(f"Temps d'exécution : {delta:.2f}s")
43046721 43046721
Temps d'exécution : 9.65s
l'empreinte mémoire est effectivement très faible, je lis un maximum de 3,9 Mio.
.H.D.1. a écrit:
Merci pour le code. Je crois que j'ai une erreur pour le slice :
# ...
seq = Posi(5, digits)
print(seq[:42])
<__main__.Posi object at 0x7f73a688d668>
Le résultat d'un slice est un nouvel objet du type dont il est le slice. C'est le comportement normal d'un slicing.
Oui, d'accord, il aurait fallu que j'écrive
for s in seq[:42]:
print(s)
.H.D.1. a écrit:
Quel est le code qui occupe 1Go et dans quelle condition ?
Même erreur que plus haut, j'ai mesuré list(it) au lieu de seulement itérer sur it, désolé.
Donc effectivement, l'itération avec itertools est efficace en mémoire, je vais le mentionner dans le message initial !
@entwanne: As-tu quelque chose à suggérer? Le début m'a semblé banal. I.E. Le nombre de secondes dans une année. Le gros du problème est la durée de l'année ... 365? 365.25? 365j 5h 48m 21s ... Avec ça je vais passer à la postérité ... secondes = lambda s: s minutes = lambda m: m*secondes(60) heures = lambda h: h*minutes(60) jours = lambda j: j*heures(24) annee = lambda a: jours(365) + heures(5) + minutes(48) + secondes(21) print(secondes(13)) print(minutes(20)) print(jours(1)) print(annee(1))
Le Tout est souvent plus grand que la somme de ses parties.
Les exercices sont classés en différentes catégories, le comptage des secondes figure dans la catégorie « Les bases de Python ».
Mais sinon les plus difficiles sont généralement ceux qui ont été résolus le moins de fois.
ma solution pour le triangle de pascal qui est d'ailleurs horrible comparé a vos solutions:
pascal = lambda n, l=[1]: [[1]] + [(l:=([1] + [l[n-1] + l[n] for n in range(len(l)) if (len(l) != 1 or len(l) != 2) and not n == 0] + [1])) for i in range(n-1)]
print(pascal(10))
A
|
B-----C---D-E
| | | |
F-G H-I J L-M
| | | |
K W-X P Z
|
Y
le but est d'afficher l'arborescence d'un seul noeud avec ses enfants dans une fonction de la classe Noeud qui s'appellera print_tree comme dans l'example
- Edité par Le programmeur solitaire 26 novembre 2021 à 8:23:14
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Le Tout est souvent plus grand que la somme de ses parties.
le code FAIT le bonheur (pour moi en tous cas)
Le Tout est souvent plus grand que la somme de ses parties.
Python c'est bon, mangez-en.
Le Tout est souvent plus grand que la somme de ses parties.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Le Tout est souvent plus grand que la somme de ses parties.
Découverte Python Doc Tkinter Les chaînes de caractères
Le Tout est souvent plus grand que la somme de ses parties.
Découverte Python Doc Tkinter Les chaînes de caractères
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Découverte Python Doc Tkinter Les chaînes de caractères
Découverte Python Doc Tkinter Les chaînes de caractères
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Découverte Python Doc Tkinter Les chaînes de caractères
Découverte Python Doc Tkinter Les chaînes de caractères
Découverte Python Doc Tkinter Les chaînes de caractères
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique
Le Tout est souvent plus grand que la somme de ses parties.
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique
le code FAIT le bonheur (pour moi en tous cas)
le code FAIT le bonheur (pour moi en tous cas)
Le Tout est souvent plus grand que la somme de ses parties.
le code FAIT le bonheur (pour moi en tous cas)