I like seeing them in the same place as the source file, because when I
start developing a module, I often end up renaming it multiple times
before it settles on a final name. When I rename or move it, I delete
the .pyc file, and that ensures that if I miss changing an import, and
try to
On Wed, 03 Feb 2010 11:55:57 +0100, Daniel Fetchinson wrote:
[...]
Python does most of that for you: it automatically recompiles the
source whenever the source code's last modified date stamp is newer
than that of the byte code. So to a first approximation you can forget
all about the .pyc
Python does most of that for you: it automatically recompiles the
source whenever the source code's last modified date stamp is newer
than that of the byte code. So to a first approximation you can forget
all about the .pyc files and just care about the source.
True, but the .pyc file is
Personally, I think it is a terribly idea to keep the source file and
byte code file in such radically different places. They should be kept
together. What you call clutter I call having the files that belong
together kept together.
I see why you think so, it's reasonable, however there is
On Tue, 02 Feb 2010 09:38:07 +0100, Daniel Fetchinson wrote:
I like seeing them in the same place as the source file, because when I
start developing a module, I often end up renaming it multiple times
before it settles on a final name. When I rename or move it, I delete
the .pyc file, and
PEP 3147 has just been posted, proposing that, beginning in release
3.2 (and possibly 2.7) compiled .pyc and .pyo files be placed in a
directory with a .pyr extension. The reason is so that compiled
versions of a program can coexist, which isn't possible now.
Frankly, I think this is a
On Mon, 01 Feb 2010 11:14:42 +0100, Daniel Fetchinson wrote:
I also think the PEP is a great idea and proposes a solution to a real
problem. But I also hear the 'directory clutter' argument and I'm really
concerned too, having all these extra directories around (and quite a
large number of
I also think the PEP is a great idea and proposes a solution to a real
problem. But I also hear the 'directory clutter' argument and I'm really
concerned too, having all these extra directories around (and quite a
large number of them indeed!).
Keep in mind that if you don't explicitly ask
On Mon, 01 Feb 2010 21:19:52 +0100, Daniel Fetchinson wrote:
Personally, I think it is a terribly idea to keep the source file and
byte code file in such radically different places. They should be kept
together. What you call clutter I call having the files that belong
together kept together.
Naming files using magic numbers is really beyond me. The fact that the
above needs comments to explain what's what already shows to me that
there's a problem with this naming scheme. What if for one reason or
another I want to delete all pyc files for Python 2.5? Where do I look
up the magic
True. You might also want to note that Python 2.6 -U appears to have a
different magic number from Python 2.6 and Python 2.6 -O.
I don't know whether they always change for each new version.
Here is a recent list of magic numbers:
Python 2.6a0: 62151 (peephole optimizations and
Leave magic to the witches of Perl. :)
--
http://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Sun, 31 Jan 2010 04:44:18 +0100, Alf P. Steinbach wrote:
The relationship between byte code magic number and release version
number is not one-to-one. We could have, for the sake of the argument,
releases 3.2.3 through 3.5.0
Here is a recent list of magic numbers:
Python 2.6a0: 62151 (peephole optimizations and STORE_MAP opcode)
Python 2.6a1: 62161 (WITH_CLEANUP optimization)
Python 2.7a0: 62171 (optimize list comprehensions/change LIST_APPEND)
Python 2.7a0: 62181 (optimize
Sean DiZazzo half.italian at gmail.com writes:
Does magic really need to be used? Why not just use the revision
number?
Because magic is easier and otherwise CPython developers would have to rebuild
their pycs everytime their working copy was updated.
--
On Sun, 31 Jan 2010 09:06:18 -0600, John Bokma wrote:
Based on the magic numbers I've seen so far it looks like that not an
option. They increment with every minor change.
They increment with every *incompatible* change to the marshal format,
not every change to the compiler.
So to me, at
On Sun, 31 Jan 2010 14:10:34 -0800, Dennis Lee Bieber wrote:
Ugh... That would mean that for an application using, say 20
files,
one now has 20 subdirectories for what, in a lot of cases, will contain
just one file each (and since I doubt older Python's will be modified to
support
PEP 3147 has just been posted, proposing that, beginning in release
3.2 (and possibly 2.7) compiled .pyc and .pyo files be placed in a
directory with a .pyr extension. The reason is so that compiled
versions of a program can coexist, which isn't possible now.
Frankly, I think this is a really
On Jan 30, 4:14 pm, John Roth johnro...@gmail.com wrote:
PEP 3147 has just been posted, proposing that, beginning in release
3.2 (and possibly 2.7) compiled .pyc and .pyo files be placed in a
directory with a .pyr extension. The reason is so that compiled
versions of a program can coexist,
John Roth wrote:
PEP 3147 has just been posted, proposing that, beginning in release
3.2 (and possibly 2.7) compiled .pyc and .pyo files be placed in a
directory with a .pyr extension. The reason is so that compiled
versions of a program can coexist, which isn't possible now.
Frankly, I think
MRAB pyt...@mrabarnett.plus.com writes:
The PEP has a .pyr directory for each .py file:
foo.py
foo.pyr/
f2b30a0d.pyc # Python 2.5
f2d10a0d.pyc # Python 2.6
f2d10a0d.pyo # Python 2.6 -O
f2d20a0d.pyc # Python 2.6 -U
0c4f0a0d.pyc # Python 3.1
* John Bokma:
MRAB pyt...@mrabarnett.plus.com writes:
The PEP has a .pyr directory for each .py file:
foo.py
foo.pyr/
f2b30a0d.pyc # Python 2.5
f2d10a0d.pyc # Python 2.6
f2d10a0d.pyo # Python 2.6 -O
f2d20a0d.pyc # Python 2.6 -U
0c4f0a0d.pyc #
On Jan 30, 2:14 pm, John Roth johnro...@gmail.com wrote:
PEP 3147 has just been posted, proposing that, beginning in release
3.2 (and possibly 2.7) compiled .pyc and .pyo files be placed in a
directory with a .pyr extension. The reason is so that compiled
versions of a program can coexist,
Alf P. Steinbach wrote:
* John Bokma:
MRAB pyt...@mrabarnett.plus.com writes:
The PEP has a .pyr directory for each .py file:
foo.py
foo.pyr/
f2b30a0d.pyc # Python 2.5
f2d10a0d.pyc # Python 2.6
f2d10a0d.pyo # Python 2.6 -O
f2d20a0d.pyc # Python 2.6 -U
MRAB pyt...@mrabarnett.plus.com writes:
Alf P. Steinbach wrote:
* John Bokma:
MRAB pyt...@mrabarnett.plus.com writes:
The PEP has a .pyr directory for each .py file:
foo.py
foo.pyr/
f2b30a0d.pyc # Python 2.5
f2d10a0d.pyc # Python 2.6
f2d10a0d.pyo #
John Roth:
4. I'm in favor of putting the source in the .pyr directory as well,
but that's got a couple more issues. One is tool support, which is
likely to be worse for source, and the other is some kind of algorithm
for identifying which source goes with which object.
Many tools work
John Bokma wrote:
MRAB pyt...@mrabarnett.plus.com writes:
Alf P. Steinbach wrote:
* John Bokma:
MRAB pyt...@mrabarnett.plus.com writes:
The PEP has a .pyr directory for each .py file:
foo.py
foo.pyr/
f2b30a0d.pyc # Python 2.5
f2d10a0d.pyc # Python 2.6
On Sat, 30 Jan 2010 14:14:54 -0800, John Roth wrote:
PEP 3147 has just been posted, proposing that, beginning in release 3.2
(and possibly 2.7) compiled .pyc and .pyo files be placed in a directory
with a .pyr extension. The reason is so that compiled versions of a
program can coexist, which
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
Unfortunately the magic number doesn't seem to be documented anywhere
I can find other than in the source code (import.c). The PEP gives
some examples:
f2b30a0d.pyc # Python 2.5
f2d10a0d.pyc # Python 2.6
f2d10a0d.pyo
Ben Finney ben+pyt...@benfinney.id.au writes:
0c4f0a0d.pyc # Python 3.1
Mapping magic numbers to versions is infeasible and will be incomplete:
Any mapping that exists in (say) Python 3.1 can't know in advance what
the magic number will be for Python 4.5.
But why do the filenames have
On Sat, 30 Jan 2010 18:40:42 -0800, Paul Rubin wrote:
Ben Finney ben+pyt...@benfinney.id.au writes:
0c4f0a0d.pyc # Python 3.1
Mapping magic numbers to versions is infeasible and will be incomplete:
Any mapping that exists in (say) Python 3.1 can't know in advance what
the magic number
* Steven D'Aprano:
On Sat, 30 Jan 2010 18:40:42 -0800, Paul Rubin wrote:
Ben Finney ben+pyt...@benfinney.id.au writes:
0c4f0a0d.pyc # Python 3.1
Mapping magic numbers to versions is infeasible and will be incomplete:
Any mapping that exists in (say) Python 3.1 can't know in advance what
On Sun, 31 Jan 2010 04:44:18 +0100, Alf P. Steinbach wrote:
The relationship between byte code magic number and release version
number is not one-to-one. We could have, for the sake of the argument,
releases 3.2.3 through 3.5.0 (say) all having the same byte codes. What
version number should
33 matches
Mail list logo
