J’ai trouvé un script sur le net qui utilise le module bytearray pour la recherche de nombres premiers . Mais quand je lance le script python3 me dit que bytearray n’a pas l’attribut setall .

Merci à l’avance

Comme les bytes sont beaucoup plus bas niveau, les bytes n’ont pas ce traitement magique, et récupérer un bout du type bytes() donne bien un seul des éléments qui compose ce flux d’octets. Un octest, c’est un nombre, donc c’est logique que ce soit un int.

Attention, il N’Y A AUCUNE LETTRE dans les bytes.

Je sais les gens ont une forte tendance à confondre ce qui s’affiche dans le shell avec les données elles-mêmes.

Par exemple:

>>> bytes([115, 97, 109])
    b'sam'

Là on a une instruction qui dit : “créer un flux de données qui contient 3 octests. Je fournis ces valeurs sous la forme d’entiers, créés à partir d’une notation en base 10.

Le shell me répond: “voilà, j’ai créé ton flux de donnée. je t’affiche une réprésentation de ce flux sous forme de caractères ascii”.

La donnée n’est pas différent en entrée et en sortie. J’ai juste une réprésentation différente à la saisie et à l’affichage.

Exemple, je fais:

>>> bytes((0x73, 0x61, 0x6d))
    b'sam'

Là on a AUSSI une instruction qui dit : “créer un flux de données qui contient 3 octests . Je fournis ces valeurs sous la forme d’entiers”. Mais j’ai créés ces entiers à partir d’une notation en base 10.

Ensuite:

>>> b'sam'
    b'sam'

Là on a AUSSI une instruction qui dit : “créer un flux de données qui contient 3 octests . Je fournis ces valeurs sous la forme d’entiers”. Mais j’ai créés ces entiers à partir d’une notation en base ASCII.

Et c’est la la truc : dans le monde du bas niveau, on manipule des octets (des bytes), donc des nombres, avec des représentations différentes. Par exemple avec des lettres ASCII. Mais c’est le même nombre.

Par ailleurs, un autre difficulté et que la notation pour créer une lettre est très similaire à celle utilisée pour créer un octet:

>>> 'a'
    'a'

>>> b'a'
    b'a'

Mais cest instruction ne font pas DU TOUT la même chose. L’un créé un type destiné à être manipulé comme des lettres. L’autre créé un type destiné à être manipulé comme une sequence de chiffres.

Donc, au contraire, le type bytes est TRES explicite, et force les programmeurs à clairement délimiter les cas où ils manipules des données qui sont conceptuellement des octets bas niveau, celles qui sont conceptuellement du texte.

Je dis conceptuellement, car évidement, au niveau de l’implémentation, le texte est représenté par des octets. Mais quand on manipule du texte, on est pas intéressé par sa valeur en tant qu’octet. On veut l’afficher. Le splitter. Le mettre en majuscule.

Quand on manipule des bytes, on est intéressé par la valeur des octets.

Alors vient une difficulté supplémentaire: comment afficher les bytes qu’on a manipulé. Et bien il faut le concertir explictement en type str. Car cela oblige à penser à l’encoding et à l’échappement, une grosse source de bug qui pose problèmes à tout ceux qui manipulent bytes et textes sont faire attention.

j’ai un machin pour lequel quand je fais, type var[0] (var en toute lettre) me renvoie un ‘int’ … le tout est encapsullé dans une b’list (remplie) de byte ecrite en toute lettre… (je crois que je vais mourir, c’est pire encore que l’encodage de python 2.7 unicode versus cp1258…)

c’est par hasard que je me suis rendu compte que le type list, etait un type b’list (impossible d’afficher correctement les données, et pour les traduires, même avec .decode(utf-8) il me reste b” résiduel à l’affichage… bon je decouvre le type byte du a ce module (dont je tais le nom, parcequ’il existe (et déjà, c’est bô) donc

mais comment je fait pour avoir ma petite liste remplie de gentil str bien sage, au lieu de ces int-byte-text(qui cache bien leur jeu …

en mode explicite, le type byte ça serait pas plus simple ?? avec de vrai morceau de ‘int’ dedans, ou du x09 partout au lieu de faire croire au blaireau (dont je suis l’humble représentant) qu’ils sont de brave str gentiment exploitable…

bref, après l’encodage unicode résolu, y’a un gars chez python qu’a pas pu s’empêcher de rendre tout b’ super klèr’ len=1, type =int.. grrrrrrrr

Effectivement, on peut imaginer une liste chaînée, sauf que les structures de données Python sont toutes de haut niveau. Même les arrays du module array sont pas de simples arrays.

Typiquement, une liste permet une collection d’objet hétérogènes. De plus, récupérer sa taille est une opération O(1) (https://wiki.python.org/moin/TimeComplexity). Donc les listes ne sont pas juste des arrays, il y a une couche par dessus.

Bref, l’auteur veut juste à tout prix faire son kéké devant ses élèves. J’ai horreur de ces profs.

dans tout ça ?

Sinon pour les listes et les array si pour listes on pense à une implémentation par des listes chaînées

Pour un tableau, l’accès au énième élément est directe pour une liste, il faut parcourir tout les éléments. Ca change des choses pour l’ajout et la suppression si l’élément est en plein milieu ou aux extrémités.

En python pour avoir une liste (doublement) chainée il faut un collections.deque

Merci pour ce site, c’est vraiment sympa.

Un array est une structure de données de bas niveau. La distance entre deux adresses de deux éléments voisins est constante dans tout l’array (généralement tous les éléments on le même type pour qu’ils prennent la même place).

Une liste est une séquence d’élément finie.

On voit bien que l’array est une question d’implémentation, la liste est une question de sémantique.

Maintenant, le point de l’auteur de l’article cité est biaisé, car il ne dit pas si il définit la liste du point de vue de l’implémentation (ni de laquelle), de l’API ou du concept sémantique.

A la fin il conclut de manière prétentieuse :

At this point, the student attains enlightment and starts applying for jobs in industry.

Personnellement, un mec comme ça, je le vire.

Il a visiblement plus de connaissance du monde papier que du code réel.

En php par exemple, le type Array ne représente pas du tout l’implémentation d’un array. Terme mal choisi ? Sans aucun doute. Raison d’écrire un article de 100 lignes et de faire chier ses élèves avec. Err…

Au final, on s’en branle. En Python, on appelle “liste” le type de base qui regrouper et parcourir un ensemble ordonné d’éléments dont la taille n’est pas connue par avance mais qui est finie.

bytearray et bytes sont bien des arrays par contre en Python, dans leurs implémentations et leurs api, bien que l’API soit plus riche que celle d’un array basique. Mais encore une fois, tu ne manipuleras presque jamais un array en Python. Seuls les programmeurs scientifiques ou de libs le feront. Dans la programmation de tous les jours, on utilise des listes, et c’est tout.

J’avoue que je n’y ai pas compris grand chose. Quelle est la différence entre une liste et un array?

Je crois qu’en Java une liste est un type particulier d’array, mais j’ai dû mal à saisir ce que les listes ont en plus.