saimn a écrit 99 commentaires

from __future__ import (absolute_import, division, print_function)

future is now, Python 2 is dead !

import numpy as N

Rien que ça c'est alambiqué, respectons les conventions pour commencer ;)
Sinon avec Numpy il y a plus simple:

import numpy as np
arr = np.array(some_list)
arr[np.chararray.startswith(arr, 'a')]

En l'occurrence la version la plus rapide est la simple boucle for. Et il y a pas de mal a en utiliser une quand le besoin se justifie (liste avec pas mal d'éléments). Je vois régulièrement des gens faire des compréhension de liste ([s for s in some_list if s.startswith('a')]) alambiquées juste pour ne pas faire une vraie boucle for, en oubliant que le plus important est encore de privilégier la lisibilité.

Sinon une autre solution pour faire une seule itération en peu moins verbeux:

from collections import defaultdict
lists = defaultdict(list)
for s in some_list: 
   lists[s[0]].append(s)

C'est pas forcément très clair mais il semble effectivement que l'UE soit plus ou moins épargnée, merci le RGPD:
https://www.lemonde.fr/pixels/article/2021/01/07/whatsapp-revoit-ses-conditions-d-utilisation-sur-le-partage-des-donnees-utilisateurs-avec-facebook_6065529_4408996.html

Par contre en dehors de l'UE point de salut, ici Whatsapp est juste incontournable, tu peux contacter tout le monde avec, du gars qui livre le bois de chauffage au centre de santé pour faire une radio (ce qui en soit est bien pratique quand tu ne parles pas bien la langue).

Même chose au Chili, quand tu atteint ton compta de Go ou la fin du mois pour du prepayé, la seule chose qui fonctionne encore c'est Whatsapp. Et c'est simple ici tout se fait par Whatsapp :(

Il y a bien conda, qui au fil du temps est devenu un gestionnaire de paquets plus généraliste.

pip s'est enrichit au fil du temps de quelques options supplémentaires bien pratiques, notamment pour voir les paquets qui peuvent être mis à jour:

pip list --outdated

A combiner si besoin avec --user ou --local (pour les virtualenv ayant accès au site-packages global). Et aussi --editable pour les paquets installés en mode develop (avec pip install -e).

Il manque essentiellement une commande pour tout mettre à jour, du coup j'utitlise ça:

pip list --outdated --format=freeze --exclude-editable | \
    cut -d = -f 1 | xargs -n1 pip install -U

mais comme il n'y a pas de vérification des versions requises par les dépendances, il faut parfois ajuster manuellement et forcer les versions de certains paquets.

Le principe ressemble pas mal à Dask (https://dask.org/), donc je le mentionne au cas où tu ne connaisses pas (un petit example: https://github.com/dask/dask-tutorial/blob/master/01_dask.delayed.ipynb).

A noter que pip install créé automatiquement des wheels pour les paquets qui ne sont pas (encore) distribués comme tel, et les met en cache localement. Donc la méthode présentée ici n'est utile que si on veut partager ce répertoire sur plusieurs machines (et encore, pas sur que les wheel linux - avec extension C - compilées ici soient compatibles sur n'importe quelle machine, dans ce cas il faut faire des wheels "manylinux1").

Non non il n'écrase pas.

Par contre c'est dur de se faire une idée sur le code s'il manque l'indentation …

Ca me fait penser à http://0.30000000000000004.com/

Ce serait cool si on pouvait éviter la dépendance à Inkscape. Hier je l'ai installé dans le train donc j'ai viré la dépendance. J'imagine que c'est utilisé pour l'icône ?

Oui ok, pour d'autres langages peut-être ;), mais pour des projets Python autant éviter de recourir à un outil externe.
__doc__ est une simple string:

>>> def foo():
...     """Super fonction
... 
...     {paragraph}
...     """
...     pass
... 
>>> foo.__doc__
'Super fonction\n\n\t{paragraph}\n\t'
>>> help(foo)
Help on function foo in module __main__:

foo()
    Super fonction

    {paragraph}

>>> foo.__doc__ = foo.__doc__.format(paragraph="Un paragraphe")
>>> help(foo)
Help on function foo in module __main__:

foo()
    Super fonction

    Un paragraphe

Ca me parait bien compliqué par rapport à un besoin qui a l'air simple: si c'est juste pour remplacer des chaînes dans des docstring, pour du python. Pour ce cas là, il est facile de manipuler les docstring, de les formater avec un __doc__.format(...), voir de faire un décorateur pour ça. Il y a aussi tout ce qu'on peut faire quand on génère du HTML avec Sphinx.

Après ton projet est plus général, c'est peut-être un point important pour toi, ça dépend du besoin.

Il n'y a pas d'accesseur par défaut, rien ne permet de dire que self.commercant (la property) doit renvoyer self._commercant (une variable classique), donc c'est à toi de le faire (better explicit …). C'est pour ca aussi que tu ne risque pas de boucle infinie, quand tu set self._commercant ça n'appelle pas la property.
Et au passage autant utiliser la syntaxe avec les décorateurs, c'est fait pour :

class ingredient():
    def __init__(self):
        self._commercant = ""

    @property
    def commercant(self):
        return self._commercant

    @commercant.setter
    def commercant(self, nom):
        print("Vous avez modifié l'entrée du commercant §")
        self._commercant = nom

Peut on configurer l'interpréteur dans cette configuration afin d'être sur que python n'accède pas via propriety ailleur dans le code ?

self._commercant est une variable privée mais comme beaucoup de choses en Python c'est une convention. Rien n'empêche d'y accéder (i = ingredient() ; i._commercant = 'foo'), c'est juste mal de le faire.

J'ai joué un peu avec pandas et matplotlib et voilà ce que ça pourrait donner:

Le reste est ici : https://gist.github.com/saimn/70edc8916c205dd3fbd8
avec un notebook pour générer tout ça (s'il y a des amateurs pour améliorer le rendu).
Pour les couleurs j'ai utilisé une barre de couleur centrée sur la moyenne limité à 5 sigma, mais on voit sur l'histogramme que c'est pas vraiment gaussien.

Voici quelques exemples pour la structure:
https://github.com/kennethreitz/samplemod
https://github.com/mapbox/pyskel
http://blog.ionelmc.ro/2014/07/08/a-python-package-template/

Il y a plusieurs possibilités:
- soit mon_logiciel/mon_logiciel/{init,mon_logiciel,…}.py
- soit mon_logiciel/{lib ou src}/mon_logiciel/{init,mon_logiciel,…}.py

mon_logiciel.py doit être dans le répertoire des sources, et pour lancer ton soft en mode install ou développement tu te bases sur le setup.py avec les 'entry_points' (pour le dev, un virtualenv + python setup.py develop).

Plutôt que d'avoir plusieurs instances de vim, je l'utilise aujourd'hui principalement en mode IDE:
- une seule instance pour tout ouvrir,
- ctrlp pour ouvrir facilement les fichiers, switcher entre les buffers, naviguer dans les tags (avec ctags), …
- des onglets quand le besoin s'en fait sentir,
- plein d'autres trucs, largement basé sur la config de Steve Losh:
http://stevelosh.com/blog/2010/09/coming-home-to-vim/
https://bitbucket.org/sjl/dotfiles/src

Une capture pour donner une idée: http://lut.im/cJas0lz0

Même pas besoin de google, il suffit de lire la sortie de git status (en français en plus):

~/l/dotfiles git:master $ git status
Sur la branche master
Votre branche est à jour avec 'origin/master'.

Modifications qui ne seront pas validées :
  (utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
  (utilisez "git checkout -- <fichier>..." pour annuler les modifications dans la copie de travail)

  modifié :   vimrc

Le langage Python poursuit son bonhomme de chemin avec la disponibilité de python-setuptools à la version 0.7. Ce travail effectué par Toshio Kuratomi, Bohuslav Kabrdae et Nick Coghlan permet de mettre à disposition l'outil incontournable pour gérer les dépendances de nombreux projets développés en Python. Ce projet longtemps en maintenance uniquement reprend son évolution en rompant la compatibilité avec ses versions antérieures à cause d'une API refaite. Depuis lors, un projet concurrent est disponible : python-distribute. Cette concurrence devrait permettre de tirer le meilleur de chacun et de favoriser leurs progressions.

Ce paragraphe porte un peu à confusion: setuptools et distribute ont été mergés, justement pour la version 0.7, donc distribute est obsolète. Les choses se sont d'ailleurs accélérées et la version 2.0 de setuptools est sortie récemment en virant le support de python 2.4 et 2.5.

d'une partie des utilisateurs:
http://linuxfr.org/suivi/pouvoir-desactiver-le-n-br

Il y a effectivement le serveur de dev de django. Une autre possibilité c'est gunicorn, installable facilement dans un virtualenv (il y a une commande spécifique pour django: http://docs.gunicorn.org/en/latest/run.html#gunicorn-django).

En fait c'est expliqué sur le site de mezzanine, le seul truc qui te manque c'est de faire un virtualenv pour tester ça facilement sans pourrir ton système: https://pypi.python.org/pypi/virtualenv

$ virtualenv mezzanine-env
$ cd mezzanine-env

# Install from PyPI    
$ pip install mezzanine

# Create a project
$ mezzanine-project myproject
$ cd myproject

# Create a database
$ python manage.py createdb

# Run the web server (le serveur de dev de django)
$ python manage.py runserver

Travis est bien pratique pour ça, et bien intégré à github (pratique pour tester les pull requests). Sinon il y a tox, mais ça nécessite d'avoir les différentes versions installlées sur ta machine.
Pour 3.0 et 3.1 tu peux les oublier, ça doit être vraiment très peu utilisé, et même 3.2, à part debian stable …

Dans le même genre, un projet sorti récemment (enfin j'ai pas testé mais il me semble que c'est assez proche) : https://github.com/audreyr/cookiecutter

ou rmlint: http://www.f.0x2501.org/p/009/