Python

2.1 Why the move?

2.2 No big deal!

2.3 Surprises!

3.1 Learning takes time

3.2 Legibility and other virtues

3.3 Auto-checking of errors

3.4 General appreciation

3.5 Version fatigue

3.6 Module names

3.7 Execution speed

3.8 Writing efficiency

4.1 Single or double quotes?

4.2 Multi-line strings

4.3 Internationalization

4.4 Style

1. Explicit closing of files?
   
   1. Summary
      

      There is a recurring debate among Python users about if we should explicitly close files, in Python, or not. Many people have shown strong and diverging opinions, and I am not neutral in all this.

      As most of us came to Python while already having other languages as background, and as many languages mandate explicit closes, we are prone to blindly applying the forcefully acquired aesthetics to Python. Moreover, there are genuine cases where explicitly closing files in Python is adequate. Also, depending on how you define what Python is, there are viewpoints from which explicit closes are always adequate.

      On the other hand, the reference implementation of Python does timely automatic finalisation of files as for any other kind of objects. Most practical usages of files in Python programs could take advantage of this finalisation, yielding a significant increase in elegance and legibility, with no real loss in maintainability. This explains my position on the matter, as legibility and maintainability are Python virtues which much appeal on me.

   2. Python finalisation
      

      Python, as created and maintained by Guido van Rossum and team is sometimes nicknamed CPython, to distinguish it from JPython in particular, the former being written in C, the later in Java. Now that JPython has been renamed Jython, I'll merely use Python to name the mainstream, reference implementation.

      Python uses reference-counting for reclaiming dead objects, so when the last reference to a file is cut, that file gets automatically and immediately closed by the Python system. Consider:

      buffer = file(NAME).read()
      

      In the above statement, as the user does not keep a reference to the file, it gets automatically closed as soon as its contents have been read.

      The Python Reference Manual says: Objects are never explicitly destroyed; however, when they become unreachable they may be garbage-collected. An implementation is allowed to postpone garbage collection or omit it altogether – it is a matter of implementation quality how garbage collection is implemented, as long as no objects are collected that are still reachable.

      Indeed, there are other implementations of Python which delay object finalisation. The classic example is Jython, which relies on the garbage-collector in the Java runtime system, so a file which is not explicitly closed by the Jython programmer, before the last reference is cut, will be closed in some indeterminate future by the garbage-collector. So, in Jython, the above example might better be written as:

      handle = file(NAME)
      buffer = handle.read()
      handle.close()
      del handle
      

      yet in practice, I guess Jython programmers would not worry about the del statement and merely let the closed file object lie around.

   3. Choosing Python
      

      In the following code fragment:

      file(FILE, 'w').write(DATA)
      

      a Python programmer knows that FILE has received DATA, all secured to disk, by the end of the statement.

      Some say that this works purely as an accident, or artifact of the current implementation of Python, which may unexpectedly change behaviour one day, also insisting that Python is not defined that way, and that programmers should not depend on any particular features of garbage collection — not even on its existence.

      This seems quite overcautious to me. Python fundamentally relies on reference counting since its inception, this is not going to change. While the Python garbage collector may be tuned or deactivated, reference counting may not be shut down, and will likely never be: the amount of breakage that would result all over is unthinkable.

      The Python Reference Manual allows for alternative Python implementations to delay finalisation, and so, use other memory management techniques than reference counting. I guess this is so Jython (at the time the Reference Manual was amended for this), and then others, could use the name Python despite such differences. Moreover, the writer of Jython is also a member of the Python development team.

   4. Elegance considerations
      

      There might be cases when one moves between Python and Jython, indeed. When one knows s/he works with Python only, it is good style to rely on the refcount behaviour, as it yields code which is not only more legible, but also more elegant and concise. It means that you understand and accept in advance having to revise your code if you ever want to use other implementations of Python, like Jython. As someone was pointing to me very recently, the Python reference tries to describe a common language, but there is no C-Python specific guide. If there was one, the refcount behaviour would most probably be described as dependable and reliable, even through future versions, as far as Python programming is concerned.

      And besides, it seems the few implementations of Python do not support exactly the same language: extensions here may not be available there. Defining good style as the common subset of all Python implementations, and everything else as bad style, seems questionable. The only thing is that you have to be aware of the implications of your choices.

      There is no common opinion what poor writing style is. Yet, that does not mean that the concept is vacuous. My mother often said to me:

      Des goûts et des couleurs, on ne discute pas. Mais il y en a de meilleurs que d'autres…

      (roughly translated: People should never discuss about what is good taste. Yet, some people have better taste than others.).

      In practice, there is some common sense that could emerge, and on which we could rely, more or less. More than less, actually! ☺

      For this Jython-forces-you-to-explicit-closes matter, my feeling is that Jython encourages bad style here, much more than it defines good style. Surely, there has never been a bad intent from Jython author. We understand the limitation comes from the fact Jython relies on the Java system for collecting garbage. One has to close explicitly in Jython for practical implementation considerations, this has nothing to do with good style, and does not define what good style may be.

      This is surely good to explicitly close() when one is done with a file, but for other reasons, needs to keep a reference on this file. Yet, the nicest is not keeping a reference to the file, whenever it can be avoided easily. Some consider this as laziness. This is no laziness at all, this is rather an active seek for legibility, with the code going straight to the essentials, and showing those essentials as clearly as possible.

      Someone writes: The opened file (when not needed) may cause problems to other applications that try to do something with the same file. One should not consider any open file object as the exclusive property of the running application. Because of that, the file should be closed as soon as possible.

      But this is exactly what happens. There is no problem, only fears. Once you get use to the paradigm, you discover that it is safe and dependable.

      It is only natural that people, coming from other programming languages culture, want to use Python in a way that best reflect the idioms they already know. However, Python has its own paradigms, that can be put to good use for what they are, and independently of our past experiences, provided they fit our own values. My own values are mainly about maintainability, and this one alone implies legibility, compactness, simplicity, humility.

      Depending on how s/he studied computers, the programmer may think that arguments are passed on a stack (conceptual or not), or he may just think with higher concepts and even ignore that a stack is involved. After a while, the first category comes to take for granted the stack cleanup, the same as Lisp people, for example, take the garbage collector for granted, and would never think at explicitly freeing cons cells. We may decide to "take for granted" a lot of other idioms, if we only choose to. It's not that difficult. After we make such choices, we discover the elegance we might have been reluctant to see. Still using Lisp as an example, I surely knew people which were extremely reluctant to see that Lisp was quite elegant, as they were sticking themselves at assembler-level thinking.

      Elegance roots itself in that conceptual simplicity of automatic finalisation of various Python objects.

   5. Blind principles
      

      A few programmers will close all files explicitly for blindly sticking to some principles, while not fully understanding the meaning of the principles they quote.

      Explicit is better than implicit

      This statement, part of the Python credo, is sometimes used as a justification for explicit closes, instead of letting the system take care of them.

      But the system takes care of really many things implicitly, which do not honestly bother programmers otherwise. For example, Python local variables allocated within a function are automatically deleted on exit from that function, but no one in his proper soul would think about del-eting all local variables. There is something implicit in recursion that could have been made explicit through a programmer-managed stack. And so on. So, the blind argument above just does not float; it looks more like a justification than a reason.

      There is an equilibrium between explicit and implicit, and a sense of good taste goes in that equilibrium. Good taste in Python is not the same as for Perl or for C, we need to un-dust ourselves a bit when we switch between languages.

      Never depend on the implementation

      As various implementations of Python vary significantly, both for the language features they offer, and the libraries they rely upon, using an implementation is effectively selecting a dialect and a set of paradigms which prevent real portability between implementations.

      It is a false feeling to think that, by not depending on this particular aspect of Python, Python programs will truly become portable. Taking Jython as an example, this particular implementation itself happily pretends to correct many deficiencies of Python, lags significantly behind Python development, and invites programmers to depend on many Java libraries and classes which are unavailable to Python. There is nothing inherently wrong in all this, except in the false feeling that Python and Jython are the same language. When one is choosing one of them, s/he is definitely not choosing the other.

      Porting from Python to Jython or another variant, or vice-versa, involves many issues and there is an unavoidable cost to porting, while open file concerns is only a fraction of that cost. To guard against all such issues in Python for any program that might never be ported is likely to cost much, much more.

      Python itself, the mainstream dialect, has been ported to many platforms, and there lies real Python portability. The language is defined by its implementation, programmers do not refrain from using Python specificities, and depending on permanent characteristics of one given implementation. The behaviour on timely finalisation is there to stay. We may depend on it. So, in the case at stake here, the statement of the principle above is more rhetorical than practical.

      It is bad programming practice

      The Jython documentation states that depending on timely finalisation is bad programming practice, and some people blindly translates this statement to Python itself. Wrongly, of course.

      Others assert that programmers are going to be bitten, sooner or later, because functions might unexpectedly keep references in a cache, or create reference cycles preventing finalisation, or such other mysteries. They assert their gut feelings and experience, saying that relying on Python automatic finalisation is not serious, sloppy, etc., and then go great length at trying, but not that successfully in my opinion, at substantiating their emotion.

      Often, experience might come from languages other than Python. We might be careful when we extend our experience from one language to another, in recognising the specificities of the new languages. Our experience is often helpful, but in some cases, if we are not careful, it may blinds us. Best practice might well be to avoid noisy code.

      The truth is that Python does not play such trickeries on programmers. Programmers themselves, on the wide average, are competent and careful enough that they have a rather good idea of what their programs are doing, and they can feel themselves in peaceful and confident control.

   6. Debugging
      

      What happens when it is not possible to write into the 'stuffile'. […] Because of the brevity of the code it is also not so explicitly visible what the write() will do when the file cannot be opened.

      Python will traceback, magically, wonderfully, with adequate information.

   7. Other notes
      

      [2001-04-02 lun] In the Language Reference, section 3.1 talks about finalization and garbage collection as implementation specific, and even strongly recommends using methods such as close() on objects that involved external resources, but indirectly circumstantiated by but since garbage collection is not guaranteed to happen…. In C-Python, currently, such a guarantee exists. I was confirmed that Python will never give up refcounting.

      Some rightly argue that if the finalization was postponed, that exception might crop up in the strangest place. Yet, in many cases, we know that the finalization is not going to be postponed, and in such cases, I think we might avoid making it explicit.

      [2002-05-29 mer] It is generatlly considered bad programming practice depending on features which the manual claims may not exist, and I heartedly agree that it is bad practice not keeping oneself between the tracks set by specifications. Without really knowing, I imagine that the Python documentation on this topic might be a politeness from Guido towards other implementations, encouraging them, so they could claim being called Python nevertheless. I wonder if the quote has been there since the beginnings of Python. ☺ The current (C-)Python implementation of reference counting, where objects are collected as soon as they stop being reachable, is of high quality on that respect, and after checking with knowledgeable people, I got that the dependability of refcounts could be considered as cast in stone, exactly like if it has been documented as such. If I did not get this confirmation first, I would never have started to use things like open(FILE, 'w').write(CONTENTS). Now, I really see it as part of (unwritten) specifications of (C-)Python, and perfectly legitimate.

      Because Jython exists, which uses delayed garbage collection, some consider that I am trading off safety for saving a line or two. But I'm not currently using Jython, and doing lines = open(file).readlines() looks perfectly safe to me, I'm not trading any safety. The goal of using such writing is not saving a line or two, but writing more legibly, by eliminating unnecessary noise. Saving lines is not very important. Saving spurious lines is, however. All those things are quite debatable, there is some aesthetic considerations associated with legibility; moreover, aesthetics do not alway yield to legibility. I think Python is nice because it has one artist in charge, able to impose a common view. If it was democratic, it would loose much.

      If immediate finalization was documented to say that it can be relied on, now and forever, this would be ideal, indeed. Despite my current choices and what I was told, there is always a tiny, unlikely risk that Python changes his behaviour on this, despite what I was told, and I would surely prefer not have to revise the code I wrote. But if I ever have to revise it, for Jython or otherwise, I will be happy having enjoyed the current legibility and simplicity for a long while! Once again, I would not have started depending on immediate finalisation before getting a confirmation of some sort that it is dependable. On one hand, I've always have been strict, anal, at using only documented features, in all systems and languages I've used in my life. On the other hand, in this precise case, the advantages were so appealing that I felt compelled to ask for clarification about the dependability of immediate finalisation.

2. Non-ASCII identifiers?
   

   [2002-05-08 mer] Many thinks that identifiers in Python should be ASCII only. For one, I would really like to use letters from my locale in identifiers. Not everyone is writing with the whole planet as a goal, you know! ☺

   There is a lot of in-house development, not meant to be exported, that would be so much more comfortable if we could use our own language while programming. Many years ago, we experienced that university-wide, by modifying the Pascal compiler so we can use French identifiers whenever we feel like it (as well as a lot of other software and even hardware), and we kept modifying compilers while new Pascal versions were released. Moving on to other sites and languages, my co-workers and I did not try redoing such patches all the time, everywhere. Yet, I would deeply like that Python be on our side, and favourable at restoring our Lost Paradise.

   One argued with me, sayint that /"it would be nice" is not a strong-enough rationale for such a change/. But this argument does not stand the road. A great deal of recent Python changes were to make it nicer in various ways. None were strictly unavoidable, the proof being that Python 1.5.2 has been successfully used for many things, and could still be. We should not merely vary the height of the strong-enough rationale bar depending on our own tastes, as this merely gives a logical sounding to relatively pure emotions.

   Having the capability of writing identifiers with national letters is not going to break other people's code, this assertion looks a bit like gratuitous FUD to me. Existing code is not going to break, as long as English identifiers stay a subset of nationally written identifiers. Which is usually the case for most character sets, Unicode among them, allowing ASCII letters as a subset of all letters. OK, there might probably be transient implementation bugs which are normal part of any release cycle. Python has undergone changes which were much deeper and much more drastic than this one would be, and the fear of transient bugs has not been a stopper.

   If many people had experienced the pleasure of naming variables properly for their national language while programming, I guess most of them would be rather enthusiastic proponents on having this capability with Python, today. As very few people experienced it, they can only imagine, without really knowing, all the comfort that results. Python is dynamic and interesting enough, in my opinion, for opening and leading a worth trend in this area.

   Some see an advantage in forbidding non English speaking people from using Python, as it prevents people to write code that cannot be universally exported. People can understand two different, orthogonal things in this issue: keywords and user identifiers. I'm not really asking that keywords be translated, because Python keywords and syntax are modelled after the English languages. This may be debated of course, but is a lower priority issue.

   However, identifiers created by local programmers, and especially identifiers naming functions or methods, should be writable in national language without forcing us to make orthographical mistakes all over (I usually choose English identifiers over disgustingly written French identifiers).

   There is a background irritation at not being able to program in my own language, this irritation is permanent and never fades out — a bit like the fossile radiation after the big bang! ☺ I surely like Python a lot, but I would like it even more if it was on the side of programmers of all nations, and not forcing everyone to wide portability: there are many cases where planetary portability is just not a concern.

   [2005-10-30 dim] People I work with here are rather saddened they couldn't use accented characters, and some hoped that Python would offer that possibility, one of these days. Also given that here, every production program or system has been progressively rewritten in Python, slowly at first, and more aggressively while the confidence was building up, to the point not much of the non-Python things remain by now. So, all our hopes are concentrated into a single language.

   All development is done in house by French people. All documentation, external or internal, comments, identifier and function names, everything is in French. Some of the developers here have had a long programming life, while they only barely read English. It is surely a constant frustration, for some of us, having to mangle identifiers by ravelling out their necessary diacritics. It does not look good, it does not smell good, and in many cases, mangling identifiers significantly decreases program legibility.

   Now, I keep reading strange arguments from people opposing that we use national letters in identifiers, disturbed by the fact they would have a hard time reading our code or publishing it. Even worse, some want to protect us (and the world) against ourselves, using made up, irrational arguments, producing false logic out of their own emotions and feelings. They would like us to think, write, and publish in English. Is it some anachronical colonialism? Quite possible. It surely has some success, as you may find some French people that will only swear in English! ☺

   For one, in my programming life, I surely chose to write a lot of English code, and I still think English is a good vehicle to planetary communication. However, I like it to my choice. I always felt much opened and collaborative with similarly minded people, and for them, happily rewrote my things from French to English in view of sharing, whenever I saw some mutual advantage to it.

   I resent when people want to force me into English when I have no real reason to do so. Let me choose to use my own language, as nicely as I can, when working in-shop with people sharing this language with me, for programs that will likely never be published outside anyway. Internationalisation is already granted in our overall view of today's programming, as a way for letting people be comfortable with computers, each in his/her own language. This comfort should extend widely to naming main programming objects (functions, classes, variables, modules) as legibly as possible. Here, I mean legible in an ideal way for the team or the local community, and not necessarily legible to the whole planet. It does not always have to be planetary, you know.

   For keywords, the need is less stringent, as syntactical constructs are part of a language. When English is opaque to a programmer, he/she can easily learn that small set of words making the syntax, understanding their effect, even while not necessarily understanding the real English meaning of those keywords. This is not a real obstacle in practice.

   Some suggested that we create our own Frenchified version of Python that lets us use all the characters we want, for our own in-house use.No doubt that we, you and me and everybody, could all have our own little version of Python. To tell all the truth, the very topic of this suggestion has already been discussed in-house already, and the decision has been to stick to Python mainstream. We could not justify to our administration that we start modifying our sources, in such a way that we ought to invest maintainance each time a new Python version appears, forever. On the other hand, we may reasonably guess that many people in this world would love being as comfortable as possible using Python, while naming identifiers naturally. It is not so unreasonable that we keep some hope that Guido will soon choose to help us all, not only me.

   It is true that many Python tools are not prepared to handle internationalised identifiers, and it is very unlikely that these tools will get ready before Python opens itself to internationalised identifiers. Let's open Python first, tools will undoubtedly follow. There will be some adaptation period, but after some while, everything will fall in place, things will become smooth again and just natural to everybody, to the point many of us might remember the current times, and wonder what was all that fuss about. ☺

3. Parentheses
   

   [2001-08-08 mer] I can write:

   for x in 1, 2, 3:
       pass
   

   because the in is nothing more than a mandated keyword. On the other hand, it always saddened me a little bit that I may not write:

   if x in 1, 2, 3:
       pass
   

   because the in here is an operator, and as such, has its priority relative to a comma. It might not be easy adjusting this in Python without breaking anything.

   Some people prefer to use parentheses for tuples all the time. Whenever language I use, I try to avoid abusing parentheses, as using them often leaves me with the bad feeling I do not know the language enough, and that I write it fuzzily, adding parentheses /just in case/… ☺

   Of course, for many languages, parentheses could be effectively used to increase legibility. But for marking tuples, Python does not need them in most cases, it may be more noisy than useful having them to mark tuples when it is not required to do so. Python sources are cleaner without such spurious parentheses, and it is a good habit learning to avoid them. There is one case, however, where using parentheses with tuples is worth doing, and this is for long lists of tuple elements spanning more than one line. Parentheses combined with proper indenting help the eye at catching the overall structure. For short tuples that fit on a line, parentheses are overkill to me.

5.1 [2002-05-03 ven] The print statement

5.2 main(*sys.argv[1:])

def main(self, *arguments):

main('arg1', 'arg2', 'arg3')

main(['arg1', 'arg2', 'arg3'])

6.1 Linting

1. Comparaison
   

   [2012-01-23 lun] Tout récemment, je me suis fait une opinion sur quelques outils qui font automatiquement une critique du code Python déjà écrit. Ces outils sont (dans l'ordre où je les ai découverts): pylint, PyChecker, pep8 et pyflakes. Ils sont tous directement disponibles sous Ubuntu.

   Le programme pylint est extrêmement critique, et il possède une tonne d'options pour contrôler sa verbosité. Je n'ai pas vraiment l'impression que, sans pas mal d'ajustements dans ces options, je puisse parvenir à des compromis qui me permettraient tout à la fois de hausser la qualité de mon propre code, et de complètement satisfaire cet outil.

   Le programme pychecker est bien plus raisonnable, quoiqu'il importe le code qu'il analyse, ce qui peut avoir pour effet de bord désagréable d'en exécuter un partie de manière inopportune.

   Quant à pyflakes, il remplace assez bien le précédent, sans devoir importer ou exécuter le code. Il m'a aussi semblé beaucoup, beaucoup plus rapide. Mais l'outil ne connaît pas vraiment Python 3 — et c'est à voir pour les autres…

   L'outil pep8 fait une vérification beaucoup plus élémentaire, et souligne les déviations d'avec le standard PEP 8, qui dicte comment disposer raisonnablement des sources Python. Je ne suis pas complètement d'accord avec toutes les conventions du PEP 8, mais pour fins d'uniformité, je veux bien en suivre l'essentiel. Un point me chagrine particulièrement: alors que les standards de GNU suggèrent de placer l'opérateur au début de la ligne de continuation, PEP 8 suggère plutôt de le placer à la fin de la ligne continuée, un mauvais choix au niveau de la clarté et de la lisibilité.

   [2012-06-10 dim] Il me semble assez utopique d'espérer une discipline dans les grandes choses lorsqu'on ne réussit pas à en avoir dans les petites, et c'est vrai dans toute forme d'écriture, y compris l'informatique. Certains gros projets auraient grand avantage à développer au moins de petites uniformités et disciplines, celles du PEP 8 par exemple. Des outils, comme ceux cités plus haut, pourraient être profitables et formateurs. Au niveau de l'habitude de la rigueur, il faut bien commencer quelque part! ☺

   Selon leur documentation, il semble que pylint et pep8 sont extensibles et capables d'intégrer des caprices supplémentaires, et comme j'en ai quelques-uns, ça n'est pas pour me déplaire ☺! Il faudra que je regarde tout ça de plus près un moment donné. Entre-temps, j'intègre pep8 et pyflakes dans mes habitudes, et pylint sous option. Voici les recettes que j'utilise présentement D'abord, un script accessoire, exécutable:

   #!/usr/bin/env python3
   # François Pinard <pinard@iro.umontreal.ca>, 2012.
   
   """\
   Help Emacs to run flymake.
   
   Usage: flymake-helper [OPTION]... FILE...
   
   Options:
     -8        run pep8
     -f        run pyflakes
     -l        run pylint
   
   Run linters on all FILEs and collect diagnostics on standard output.
   If none of -8fl, -f is assumed.
   """
   
   import os
   import subprocess
   import sys
   
   pep8org = os.path.expanduser('~/etc/bin/pep8org')
   pyflakes = 'pyflakes'
   pylint = 'epylint'
   
   
   class Main:
       pep8 = False
       pyflakes = False
       pylint = False
   
       def main(self, *arguments):
           if not arguments:
               sys.stdout.write(__doc__)
               sys.exit(0)
           import getopt
           options, arguments = getopt.getopt(arguments, '8fl')
           for option, value in options:
               if option == '-8':
                   self.pep8 = True
               elif option == '-f':
                   self.pyflakes = True
               elif option == '-l':
                   self.pylint = True
           if not (self.pep8 or self.pyflakes or self.pylint):
               self.pyflakes = True
           for argument in arguments:
               if self.pep8:
                   subprocess.call([pep8org, '--repeat', argument])
               if self.pyflakes:
                   subprocess.call([pyflakes, argument])
               if self.pylint:
                   subprocess.call([pylint, argument])
   
   
   main = Main().main
   
   if __name__ == '__main__':
       main(*sys.argv[1:])
   

   Je place ce script dans ~/etc/bin/flymake-helper, qui est mentionné explicitement dans quelques fragments de code Emacs Lisp situés dans ~/.emacs et qui suivent. Il faut évidemment corriger en fonction de l'endroit que vous-mêmes choisiriez:

   (defvar fp-pep8-flag t)
   
   (defun fp-toggle-pep8 ()
     (interactive)
     (setq fp-pep8-flag (not fp-pep8-flag))
     (let ((buffer (current-buffer)))
       (when (and buffer
                  (eq (buffer-local-value 'major-mode buffer) 'python-mode))
         (flymake-start-syntax-check))
     (message (concat "PEP8 " (if fp-pep8-flag "active" "inactive")))))
   
   (defvar fp-pyflakes-flag t)
   
   (defun fp-toggle-pyflakes ()
     (interactive)
     (setq fp-pyflakes-flag (not fp-pyflakes-flag))
     (let ((buffer (current-buffer)))
       (when (and buffer
                  (eq (buffer-local-value 'major-mode buffer) 'python-mode))
         (flymake-start-syntax-check))
     (message (concat "pyflakes " (if fp-pyflakes-flag "active" "inactive")))))
   
   (defvar fp-pylint-flag nil)
   
   (defun fp-toggle-pylint ()
     (interactive)
     (setq fp-pylint-flag (not fp-pylint-flag))
     (let ((buffer (current-buffer)))
       (when (and buffer
                  (eq (buffer-local-value 'major-mode buffer) 'python-mode))
         (flymake-start-syntax-check))
     (message (concat "pylint " (if fp-pylint-flag "active" "inactive")))))
   
   (defun fp-flymake-py-init ()
     (let* ((temp-file (flymake-init-create-temp-buffer-copy
                        'flymake-create-temp-inplace))
            (local-file (file-relative-name
                         temp-file
                         (file-name-directory buffer-file-name))))
       (let ((arguments (list local-file)))
         (when fp-pep8-flag
           (push "-8" arguments))
         (when fp-pyflakes-flag
           (push "-f" arguments))
         (when fp-pylint-flag
           (push "-l" arguments))
         (list "~/etc/bin/flymake-helper" arguments))))
   
   (add-to-list 'flymake-allowed-file-name-masks
                '("\\.py\\'" fp-flymake-py-init))
   
   ;; Python files do not always end in ".py".
   (defadvice flymake-get-file-name-mode-and-masks
     (around fp-flymake-get-mode activate)
     "Python files do not always end in `.py'."
     (let ((buffer (get-file-buffer file-name)))
       (if (and buffer (eq (buffer-local-value 'major-mode buffer) 'python-mode))
           (setq ad-return-value '(fp-flymake-py-init))
       ad-do-it)))
   
   (global-set-key "\C-cp7" 'fp-toggle-pyflakes)
   (global-set-key "\C-cp8" 'fp-toggle-pep8)
   (global-set-key "\C-cp9" 'fp-toggle-pylint)
   

   Dans mon cas, avec le code juste cité, les commandes Emacs C-c p 7 et C-c p 8 désactivent au vol les diagnostics émis par pyflakes et pep8, ou les basculent ensuite. La commande C-c p 9 active au vol les diagnostics émis par pylint, ou les bascule ensuite.