>>> 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 .
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
>>> 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
>
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,
>>> 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, h
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
>> 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 explici
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
> 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 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
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, a
Sean DiZazzo 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.
--
http://mail.python.org/mailman/listinfo/python-
> 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 cond
Steven D'Aprano 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 (say) all having the same byt
Leave magic to the witches of Perl. :)
--
http://mail.python.org/mailman/listinfo/python-list
> 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 a
> 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 m
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
* Steven D'Aprano:
On Sat, 30 Jan 2010 18:40:42 -0800, Paul Rubin wrote:
Ben Finney 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 fo
On Sat, 30 Jan 2010 18:40:42 -0800, Paul Rubin wrote:
> Ben Finney 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
Ben Finney 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 magic numbers instead of
Steven D'Aprano 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 # Python 2.6 -O
> f2d20a0d
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, whi
John Bokma wrote:
MRAB writes:
Alf P. Steinbach wrote:
* John Bokma:
MRAB 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
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
MRAB writes:
> Alf P. Steinbach wrote:
>> * John Bokma:
>>> MRAB 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
Alf P. Steinbach wrote:
* John Bokma:
MRAB 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 # Pyth
On Jan 30, 2:14 pm, 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 possibl
* John Bokma:
MRAB 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
wow: so much for
MRAB 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
wow: so much for
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 th
On Jan 30, 4:14 pm, 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 possibl
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 good
33 matches
Mail list logo
