classification
Title: extend compileall to compile single files
Type: enhancement Stage: patch review
Components: Library (Lib) Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: doko Nosy List: barry, dmalcolm, doko, eric.araujo
Priority: normal Keywords: patch

Created on 2010-03-14 19:41 by doko, last changed 2010-12-16 06:15 by eric.araujo. This issue is now closed.

Files
File name Uploaded Description Edit
compileall.py.diff doko, 2010-03-14 19:41 proposed patch
compileall.py.diff doko, 2010-03-15 16:24
Messages (7)
msg101064 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2010-03-14 19:41
when byte-compiling files in a deb/rpm package distributed e.g. in a Linux distribution, it is sometimes wanted to only touch the files found in the deb/rpm, which can be a subset of the files in a directory. the attached patch now lets compileall accept files as arguments as well and adds the recognition of @<filelist> and @- to expand the arguments with the contents of the file (@- meaning to read for stdin). Is this ok for 2.7, and a port of that to 3.2?
msg101117 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-03-15 14:32
+1 on this functionality being added for 2.7 and 3.2.  You also mentioned in pvt email that it would be better to patch compileall.py than py_compile.py to take advantage of the quiet and force options (which seems good to me).

I have a few comments on the diff:

* It no longer applies cleanly to trunk.  There was a recent commit that removed an unnecessary catch of KeyboardInterrupt, and I think that's what's causing the hunk reject.

* I don't like @filename and @- as the syntax for reading the compilation list from a file.  Since -f is already taken, what about adding -i<file> which tells it where to take the list from?  Of course '-i -' would mean stdin.

* Please add tests for the new functionality to test_compileall.py

Bonus points for updating this to modern Python <wink>.  E.g. using True/False instead of 1/0, and 'OSError as error' instead of 'os.error, e'.  But don't worry about that too much; I'll probably take that on as part of my PEP 3147 work. ;)
msg101122 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2010-03-15 16:24
changed the @ syntax to an option -i, and added a test for compile_file/compile_dir.
msg101129 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-03-15 17:24
Looks good to me, and should help distros, so +1.
msg101145 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2010-03-16 01:27
fixed for 2.7 and 3.2
msg124104 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-12-16 03:56
I have added versionadded directives that were missing in the doc.
msg124107 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-12-16 06:15
I also added the missing function description.
History
Date User Action Args
2010-12-16 06:15:41eric.araujosetnosy: barry, doko, eric.araujo, dmalcolm
messages: + msg124107
2010-12-16 03:56:54eric.araujosetnosy: + eric.araujo
messages: + msg124104
2010-03-16 01:27:28dokosetstatus: open -> closed
resolution: accepted -> fixed
messages: + msg101145
2010-03-15 17:24:01barrysetassignee: doko
resolution: accepted
messages: + msg101129
2010-03-15 16:24:27dokosetfiles: + compileall.py.diff

messages: + msg101122
2010-03-15 15:47:24dmalcolmsetnosy: + dmalcolm
2010-03-15 14:32:09barrysetnosy: + barry
messages: + msg101117
2010-03-14 19:42:20ezio.melottisetpriority: normal
type: enhancement
stage: patch review
2010-03-14 19:41:31dokocreate