.pth files
Hi there ! I've some questions regarding pth files (which btw are undocumented in the python reference, is this intentional ?) I thought that I could use a .pth file to be able to import zope products from both INSTANCE_HOME/Products and ZOPE_HOME/lib/python/Products from outside zope: [EMAIL PROTECTED]:~$ cat cvs_work/Products.pth /home/syt/local/Zope-2.8.1-b1/Products /home/syt/local/Zope-2.8.1-b1/lib/python/Products [EMAIL PROTECTED]:~$ [EMAIL PROTECTED]:~$ python Python 2.3.5 (#2, Jun 19 2005, 13:28:00) [GCC 3.3.6 (Debian 1:3.3.6-6)] on linux2 Type help, copyright, credits or license for more information. import sys print sys.path ['', '/home/syt/cvs_work', '/home/syt/cvs_work/prive/soft', '/home/syt/local/lib/python2.3/site-packages', '/home/syt/local/lib/python', '/usr/lib/python23.zip', '/usr/lib/python2.3', '/usr/lib/python2.3/plat-linux2', '/usr/lib/python2.3/lib-tk', '/usr/lib/python2.3/lib-dynload', '/usr/local/lib/python2.3/site-packages', '/usr/lib/python2.3/site-packages', '/usr/lib/python2.3/site-packages/Numeric', '/usr/lib/python2.3/site-packages/PIL', '/usr/lib/python2.3/site-packages/gtk-2.0', '/usr/lib/python2.3/site-packages/vtk_python', '/usr/lib/site-python'] But as you can see, 1. the Products.pth file isn't considered at all, while for example PIL.pht in the site-packages is correctly detected 2. I'm not even sure that I can put several paths in a .pth file Is there a restriction on .pth location ? Is it possible to have multiple path in a pth file ? -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
Re: .pth files
On Tue, 09 Aug 2005 09:37:47 +, Adriano Varoli Piazza wrote: Sylvain Thenault ha scritto: Hi there ! I've some questions regarding pth files (which btw are undocumented in the python reference, is this intentional ?) I thought that I could use a .pth file to be able to import zope products from both INSTANCE_HOME/Products and ZOPE_HOME/lib/python/Products from outside zope: [EMAIL PROTECTED]:~$ cat cvs_work/Products.pth /home/syt/local/Zope-2.8.1-b1/Products /home/syt/local/Zope-2.8.1-b1/lib/python/Products [EMAIL PROTECTED]:~$ [EMAIL PROTECTED]:~$ python Python 2.3.5 (#2, Jun 19 2005, 13:28:00) [GCC 3.3.6 (Debian 1:3.3.6-6)] on linux2 Type help, copyright, credits or license for more information. import sys print sys.path ['', '/home/syt/cvs_work', '/home/syt/cvs_work/prive/soft', '/home/syt/local/lib/python2.3/site-packages', '/home/syt/local/lib/python', '/usr/lib/python23.zip', '/usr/lib/python2.3', '/usr/lib/python2.3/plat-linux2', '/usr/lib/python2.3/lib-tk', '/usr/lib/python2.3/lib-dynload', '/usr/local/lib/python2.3/site-packages', '/usr/lib/python2.3/site-packages', '/usr/lib/python2.3/site-packages/Numeric', '/usr/lib/python2.3/site-packages/PIL', '/usr/lib/python2.3/site-packages/gtk-2.0', '/usr/lib/python2.3/site-packages/vtk_python', '/usr/lib/site-python'] But as you can see, 1. the Products.pth file isn't considered at all, while for example PIL.pht in the site-packages is correctly detected 2. I'm not even sure that I can put several paths in a .pth file Is there a restriction on .pth location ? Is it possible to have multiple path in a pth file ? From Learning Python, 2nd Ed: a relatively new feature of Python allows users to add valid directories to the module search path by simply listing them, one per line, in a text file whose name ends in a .pth suffix. See also the docs for the site module in the Python Library reference. ha, so that's where it's documented ! so answer are: 1. Products.pth are only considered in standard site-packages and site-python directories 2. yes, it's possible Now, the question become: why can't we use pth files in other path specified by the PYTHONPATH environement variable ? -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] pylint 0.7
On Thu, 04 Aug 2005 14:50:18 -0400, François Pinard wrote: [Sylvain Thénault] I'm pleased to announce a new release of PyLint. Bonjour Sylvain. J'ai la compulsion de dire bonjour, et merci! (On peut me tutoyer sans problème.) Bonjour ! C'est une compulsion plutôt sympathique ! ;) Ce logiciel `pylint', que je viens d'installer et d'essayer pour la première fois ce matin (donc, j'écris encore sur l'effet d'une première impression), me semble vraiment excellent. j'espère que l'impression sur le long terme sera la même ! Plaisir supplémentaire, `logilab.common' semble contenir de bien belles choses, intéressantes pour moi, je vais regarder ça de plus près. Il commence à y avoir pas mal de chose dans cette librairie, qui nous sert un peu de fourre-tout pour tout le code qui est partagé entre plusieurs de nos projets. Ça manque un peu de documentation, mais le code devrait être à peu près propre, et n'hésite pas à nous poser des questions au besoin. Étant moi-même plutôt tatillon sur les questions stylistiques, je suis heureux de trouver quelqu'un qui, en plus de parler ma langue, possède probablement le même défaut. Effectivement, je suis un peu (bon d'accord, *très*) maniaque sur ces questions :) Please send any bugs or comments on the mailing list. Dois-je vraiment passer par là? Les discussions sont nécessairement un petit peu plus impersonnelles sur une liste. Si oui, alors je le ferai, bien sûr. J'imagine qu'il faut alors s'y inscrire aussi? Effectivement, c'est un peu plus impersonnel mais ça à l'avantage d'être archivé et la discussion est ainsi partagée avec les autres utilisateurs de pylint. Si tu préfères écrire en français, il y a aussi la liste [EMAIL PROTECTED], qui a un très faible trafic. Ces deux listes (forum-fr et python-projects) demande effectivement un abonnement, mais ce n'est pas requis pour poster, c'est juste que si tu n'est pas membre les mails seront modérés, et donc mettront peut-être un peu plus de temps à arriver. Après, je répond aussi aux mails perso ;) Et si cela me semble intéressant de faire partager la réponse, je met la liste en copie. De petites choses qui m'ont tout de suite sauté aux yeux: * `pylint --version' devrait fournir l'adresse où rapporter les problèmes. * `pylint --generate-rcfile' engendre un fichier qui possède trop d'espace blanc intempestif, en particulier à la fin de plusieurs lignes, et aussi, à la toute fin du fichier. Il serait intéressant aussi que le fichier engendré se tienne dans 79 colonnes: pas toujours possible pour le code, j'en conviens, mais au moins faisable pour les commentaires. tu l'as généré sous windows ? Sous linux ça marche bien, et les commentaires sont wrappés correctement sur 80 colonnes. Je pense que les espaces en trop sont aussi liés à ça. Il me semblait avoir déjà corrigé ce pb, faudra que je trouve une machine windows pour rejeter un oeil à ce problème. * `pylint --parseable=y' pourrait peut-être, sous option, éviter les noms de fichiers absolus et garder une notation relative, cela éliminerait passablement de bruit lorsque le répertoire courant est niché profondément. je met ça dans notre tracker. * Malgré son origine française, `pylint' n'est pas sensible à un locale français. J'imagine que l'internationalisation n'est pas prévue? c'est prévu depuis un moment, mais avec une priorité au plus bas :) ça devrait pas être trop dur à faire, tous les messages étant regroupés dans un dictionnaire pour chaque checker. Merci bien pour PYLINTHOME et PYLINTRC, les variables d'environnement. J'en fait déjà bon usage. :-) D'une certaine manière dans la même mentalité de `pylint', j'ai produit une sorte de redresseur stylistique que j'utilise directement de l'intérieur de Vim. J'ai probablement pensé un peu à Emacs tout aussi bien en l'écrivant, mais je n'ai pas utilisé Emacs depuis un bon moment. toi, l'auteur de pymacs, passé à Vim ! Mais rien ne va plus ;) Je désire bientôt replonger dans ce redresseur et le dépoussiérer sérieusement, pour un autre gros projet. Il vaudrait peut-être la peine de voir s'il m'est possible d'harmoniser mon outil au tien, et vice-versa peut-être, un peu. Du même jet, il m'intrigue de comparer le module `compiler' de Python 2.3, qui ne me satisfait plutôt bien, mais pas tout-à-fait, avec le module `astng' de Logilab. le module astng est en fait une sur-couche du module compiler de la librairie standard. Il ne fait en gros qu'ajouter des propriétés et méthodes aux noeuds de l'arbre produit par ce module, avec en plus quelques classes pour gérer la génération de ces arbres. Et aussi construire des représentations d'objets vivants (si le code source n'est pas accessible ou n'est pas du python par exemple). Donc, en bref, survole: http://fp-etc.progiciels-bpi.ca/showfile.html?name=pynits/pynits.txtmode=vim pour sentir si nos approches ont quelques atomes crochus! :-) Si oui, cela peut ouvrir la
Re: Coding Standards (and Best Practices)
On Tue, 26 Apr 2005 11:02:33 -0700, Trent Mick wrote: [Isaac Rodriguez wrote] Hi, I am fairily new to Python, but I am really liking what I am seeing. My team is going to re-design some automation projects, and we were going to use Python as our programming language. One of the things we would like to do, since we are all new to the language, is to define a set of guidelines and best practices as our coding standards. Does anyone know where I can get some information about what the community is doing? Are there any well defined guidelines established? http://www.python.org/peps/pep-0008.html and you may also be interested by a tool such as pylint[1] which help to enforce coding standards on your code base. Most of the styles suggested in pep 8 are checked by pylint, using its default configuration. [1] http://www.logilab.org/projects/pylint/ -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
connection refused when uploading a package to pypi
Hi ! I got a connection refused when I try to upload a package using python setup.py register. However login using the web interface works well. Does anyone has the same problem or is it a problem on my side ? [EMAIL PROTECTED]:pylint$ python setup.py register running register We need to know who you are, so please choose either: 1. use your existing login, 2. register as a new user, 3. have the server generate a new password for you (and email it to you), or 4. quit Your selection [default 1]: Username: logilab Password: Server response (500): urlopen error (111, 'Connection refused') -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
Re: making symlinks with distutils
On Fri, 04 Feb 2005 02:45:34 -0800, Michele Simionato wrote: I want to distribute a pure Python package with this structure: mypackage __init__.py module1.py module2.py ... myexecutable.py In particular, myexecutable.py is a script which is intended to be used from the command line via the shebang trick. I want to distribute on Unices. and I want a symlink /usr/bin/myexecutable - package-path/mypackage/myexecutable.py to be made at installation time, when the user runs python setup.py install. What is the recommanded way to do that? Do I need a postinstallation script or something like that? I could do that in various way, but I don't see the obvious one, maybe because I am not a Dutch ;) i'm not sure there is a standard way to do so with distutils. My current way to handle executable scripts is to have a run() function in the myexecutable.py module, and then to have a very simple myexecutable script with the following content: #!/usr/bin/python from mypackage import myexecutable myexecutable.run() And then register this script using distutils'scripts keyword argument. This has the advantage that I can also create a very simple .bat file for windows users without code duplication. -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
Re: making symlinks with distutils
On Fri, 04 Feb 2005 04:01:25 -0800, Michele Simionato wrote: From what I see in the docs, registering a script just normalize the shebang line, but does not install it in /usr/bin, nor make any symbolic links, so it is not what I am looking for. Actually it does install it is $PREFIX/bin. -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
Re: making symlinks with distutils
On Fri, 04 Feb 2005 04:59:51 -0800, Michele Simionato wrote: Sylvain Thenault: Actually it does install it is $PREFIX/bin. Aha! And how do I set $PREFIX? Is it a Unix environment variable or is it a keyword argument in setup? Something like setup( prefix=/usr) ? it's a command line argument of the install command: python setup.py install --prefix=~/ or python setup.py install --home=~/ (the difference between --home and --prefix is that the former will install library in $PREFIX/lib/pythonX.Y/site-packages while the latter will install it in $PREFIX/lib/python/ -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Next step after pychecker
On Tue, 01 Feb 2005 16:27:48 -0600, John Roth wrote: Sylvain Thenault [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, 01 Feb 2005 05:18:12 +0100, Philippe Fremy wrote: Did you take a look at the starkiller [1] and pypy projects [2] ? Has anything happened to Starkiller since PyCon 2004? The latest mention I can find on Google is a blog entry (by Ted Leung) on Aug 30 saying he wished someone would give the author some money to finish it and publish it. nothing I'm aware of. Some people talked about it, but no news from starkiller's author. However some posts mention that it already has some usable output now. -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Next step after pychecker
On Tue, 01 Feb 2005 05:18:12 +0100, Philippe Fremy wrote: Hi, Hi I would like to develop a tool that goes one step further than pychecker to ensure python program validity. The idea would be to get close to what people get on ocaml: a static verification of all types of the program, without any kind of variable declaration. This would definitely brings a lot of power to python. The idea is to analyse the whole program, identify constraints on function arguments and check that these constraints are verified by other parts of the program. Did you take a look at the starkiller [1] and pypy projects [2] ? What is in your opinion the best tool to achieve this ? I had an extensive look at pychecker, and it could certainly be extended to do the job. Things that still concern me are that it works on the bytecode, which prevents it from working with jython and the new .NET python. I am currently reading the documentation on AST and visitor, but I am not sure that this will be the best tool either. The AST seems quite deep and I am afraid that it will make the analysis quite slow and complicated. are you talking about the ast returned by the parser module, or the ast from the compiler module ? The former is a higher abstraction, using specific class instances in the tree, and most importantly with all the parsing junk removed. See [3]. You may also be interested in pylint [4] which is a pychecker like program built in top of the compiler ast, and so doesn't require actual import of the analyzed code. However it's not yet as advanced as pychecker regarding bug detection. And finally as another poster said you should probably keep an eye open on the python 2.5 ast branch work... Hope that helps ! [1]http://www.python.org/pycon/dc2004/papers/1/paper.pdf) [2]http://codespeak.net/pypy/index.cgi?home [3]http://www.python.org/doc/current/lib/module-compiler.ast.html [4]http://www.logilab.org/projects/pylint -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Maximum Number of Class Attributes
On Wed, 26 Jan 2005 02:03:12 +, Bob Parnes wrote: In its default configuration, my version of pylint (0.5.0) sets the maximum number of class attributes at 7. This seems low to me, but I can see how an excessive number might make maintenance more difficult. Is this indeed the best value for a maximum under ordinary conditions? If not, can anyone suggest a more reasonable value? well, this value is very subjective, and may change from one context to another... For instance at some point I hope that pylint will detect GUI classes and allow more attributes (and methods?) to those. Anyway that's just an indicator, not a rule of thumb (and pylint itself has some class with more than 7 attributes...). And FYI, this value has been taken from a post to the testdrivendevelopment at yahoogroups (as most others default values in the design analysis checker). Hum, well... After checking it seems that the post said 20 attributes. I don't remember why did i get this number down to 7. If this discussion leads to an agreement for a better number, I can change the default value. -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
MemoryError with parser.suite and wrong encoding declaration
Hi there !
I've noticed the following problem with python = 2.3 (actually 2.3.4 and
2.4):
[EMAIL PROTECTED]:test$ python
Python 2.3.4 (#2, Sep 24 2004, 08:39:09)
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
Type help, copyright, credits or license for more information.
import parser
parser.suite('# -*- coding: IBO-8859-1 -*-')
Traceback (most recent call last):
File stdin, line 1, in ?
MemoryError
parser.suite('# -*- coding: ISO-8859-1 -*-')
parser.st object at 0xb7e5e060
Shouldn't parser.suite just ignore the wrong encoding declaration, or at
least raise a more appropriate exception. IMHO the first solution
would be better, since that's the behaviour of the (C) python interpreter.
--
Sylvain Thénault LOGILAB, Paris (France).
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: MemoryError with parser.suite and wrong encoding declaration
On Tue, 18 Jan 2005 16:16:32 +0100, Thomas Heller wrote:
Sylvain Thenault [EMAIL PROTECTED] writes:
Hi there !
I've noticed the following problem with python = 2.3 (actually 2.3.4
and 2.4):
[EMAIL PROTECTED]:test$ python
Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)]
on linux2 Type help, copyright, credits or license for more
information.
import parser
parser.suite('# -*- coding: IBO-8859-1 -*-')
Traceback (most recent call last):
File stdin, line 1, in ?
MemoryError
parser.suite('# -*- coding: ISO-8859-1 -*-')
parser.st object at 0xb7e5e060
Shouldn't parser.suite just ignore the wrong encoding declaration, or at
least raise a more appropriate exception. IMHO the first solution would
be better, since that's the behaviour of the (C) python interpreter.
Ignore the wrong declaration? All Python's that I have (on windows, at
least) raise a SyntaxError:
File x.py, line 1
SyntaxError: 'unknown encoding: IBO-8859-1'
hum, right (with python = 2.3 which is the first release using those
declaration...). I was sure to have checked this but I've obviously
missed something. Maybe the fact that being able to parse it anyway is
the solution I wish has driven me to write this ;) I would like this
behaviour so that pylint can check a module with a wrong encoding
declaration anyway. But at least, SyntaxError would be better than
MemoryError.
See also:
http://www.python.org/sf/979739
thanks
--
Sylvain Thénault LOGILAB, Paris (France).
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyChecker messages
On Tue, 11 Jan 2005 06:54:54 +, Frans Englich wrote: Hello, Hi I take PyChecker partly as an recommender of good coding practice You may alos be interested by Pylint [1]. Pylint is less advanced in bug detection than pychecker, but imho its good coding practice detection is more advanced and configurable (as the pylint author, i'm a little biased... ;), including naming conventions, code duplication, bad code smells, presence of docstring, etc... Side note : I wish that at some point we stop duplicated effort between pylint and pychecker. In my opinion that would be nice if each one focus on its strenghs (as i said bugs detection for pychecker and convention violation / bad code smell for pylint). That would be even better if both tools could be merged in one, but (at least last time I took a look at pychecker) the internal architecture is so different that it's not an easy task today. Any thoughts ? [1] http://www.logilab.org/projects/pylint -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
import with python -O
Hi there ! I'm usually relying on the fact that pyc file are autogenerated when necessary (ie usually when the py file has been modified since the pyc creation). However, it doesn't seems to work correctly when the -O option is given to the interpreter : [EMAIL PROTECTED]:test$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type help, copyright, credits or license for more information. . from logilab import pylint . pylint.__file__ '/home/syt/cvs_work/logilab/pylint/__init__.pyc' . [EMAIL PROTECTED]:test$ python -O Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type help, copyright, credits or license for more information. . from logilab import pylint . pylint.__file__ '/usr/lib/python2.3/site-packages/logilab/pylint/__init__.pyo' The PYTHONPATH has not changed but the interpreter seems to take the first pyo it finds, even if there is a more recent .py file before in the python path. Should this behaviour be considered as normal ? -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
Re: import with python -O
On Thu, 30 Dec 2004 16:56:17 +0100, Sylvain Thenault wrote: Hi there ! I'm usually relying on the fact that pyc file are autogenerated when necessary (ie usually when the py file has been modified since the pyc creation). However, it doesn't seems to work correctly when the -O option is given to the interpreter : [EMAIL PROTECTED]:test$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type help, copyright, credits or license for more information. . from logilab import pylint . pylint.__file__ '/home/syt/cvs_work/logilab/pylint/__init__.pyc' . [EMAIL PROTECTED]:test$ python -O Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type help, copyright, credits or license for more information. . from logilab import pylint . pylint.__file__ '/usr/lib/python2.3/site-packages/logilab/pylint/__init__.pyo' The PYTHONPATH has not changed but the interpreter seems to take the first pyo it finds, even if there is a more recent .py file before in the python path. Should this behaviour be considered as normal ? ok, my fault... The problem was that the logilab subdirectory didn't have anymore the __init__.py file, but only the __init__.pyc file. Adding it fix the problem. Thank you four your attention. -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
