Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-16 Thread Guido van Rossum
Thanks for all the changes! On Fri, Apr 16, 2010 at 4:00 PM, Barry Warsaw wrote: > On Apr 15, 2010, at 08:01 PM, Guido van Rossum wrote: >>Hm. I wish there was a way to find out whether the bytecode (or >>whatever) actually *was* read from this file. __file__ in Python 2 >>supports this (though n

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-16 Thread Barry Warsaw
On Apr 16, 2010, at 11:52 AM, Guido van Rossum wrote: >To the contrary, it was invented by Barry and ought to be added to the >English language as a neologism. Actually, it's an Emacs invention! -Barry signature.asc Description: PGP signature ___ Pyt

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-16 Thread Barry Warsaw
On Apr 15, 2010, at 08:01 PM, Guido van Rossum wrote: >> Byte code files contain two 32-bit numbers followed by the marshaled > >big-endian Done. >> [2]_ code object.  The 32-bit numbers represent a magic number and a >> timestamp.  The magic number changes whenever Python changes the byte >> co

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-16 Thread Benjamin Peterson
2010/4/16 Barry Warsaw : > On Apr 15, 2010, at 08:01 PM, Guido van Rossum wrote: >>> This feature is targeted for Python 3.2, solving the problem for those >>> and all future versions.  It may be back-ported to Python 2.7. >> >>Is there time given that 2.7b1 was released? > > I think this would be

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-16 Thread Guido van Rossum
On Fri, Apr 16, 2010 at 11:09 AM, Terry Reedy wrote: > On 4/15/2010 11:01 PM, Guido van Rossum wrote: >>> >>> pyc files inside of the `__pycache__` directories contain a magic >>> identifier in their file names.  These are mnemonic tags for the >>> actual magic numbers used by the importer.  For e

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-16 Thread Terry Reedy
On 4/15/2010 11:01 PM, Guido van Rossum wrote: pyc files inside of the `__pycache__` directories contain a magic identifier in their file names. These are mnemonic tags for the actual magic numbers used by the importer. For example, in Python 3.2, we could use the hexlified [10]_ magic number a

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-16 Thread Barry Warsaw
On Apr 15, 2010, at 08:01 PM, Guido van Rossum wrote: >Comments inline. Nothing showstopping, mostly just spewing obscure >background information... > >Overall, congratulations! I'm fine with the implementation going in >and the PEP being marked as accepted as long as you get to the >clarification

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-15 Thread Steve Holden
Guido van Rossum wrote: [...] >> Implementation strategy >> === >> >> This feature is targeted for Python 3.2, solving the problem for those >> and all future versions. It may be back-ported to Python > > Is there time given that 2.7b1 was released? > I would hope we have le

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-15 Thread Guido van Rossum
Comments inline. Nothing showstopping, mostly just spewing obscure background information... Overall, congratulations! I'm fine with the implementation going in and the PEP being marked as accepted as long as you get to the clarifications I suggest below soon after. --Guido On Tue, Apr 13, 2010

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-14 Thread Barry Warsaw
On Apr 15, 2010, at 08:33 AM, Nick Coghlan wrote: >Brett Cannon wrote: >> And just a quick suggestion: can we standardize what >> imp.source_to_path() and friend are supposed to return if the >> interpreter doesn't support bytecode? I will probably have to rely on >> that for something so it would

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-14 Thread Nick Coghlan
Brett Cannon wrote: > And just a quick suggestion: can we standardize what > imp.source_to_path() and friend are supposed to return if the > interpreter doesn't support bytecode? I will probably have to rely on > that for something so it would be best to say now whether it should be > None or raise

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-14 Thread Barry Warsaw
On Apr 14, 2010, at 09:52 AM, Isaac Morland wrote: >I have one wording suggestion which I hope isn't bikeshedding: up above, I >think the sentence containing "pyc files will contain a magic string" >would be clearer if it made it clear that the file *names*, not (just?) >the file contents, will

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-14 Thread Nick Coghlan
Isaac Morland wrote: > I have one wording suggestion which I hope isn't bikeshedding: up above, > I think the sentence containing "pyc files will contain a magic string" > would be clearer if it made it clear that the file *names*, not (just?) > the file contents, will contain the magic tag. That'

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-14 Thread Isaac Morland
On Tue, 13 Apr 2010, Barry Warsaw wrote: I am attaching the latest revision of PEP 3147 to this message, which is also available here: http://www.python.org/dev/peps/pep-3147/ [] PEP: 3147 Title: PYC Repository Directories [] Further, pyc files will contain a magic string that diff

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-14 Thread Barry Warsaw
On Apr 13, 2010, at 04:44 PM, Guido van Rossum wrote: >Give me a couple of days; but I don't expect any problems given how >the earlier discussion went. If you didn't hear from me by Friday go >ahead and merge. Thanks Guido. -Barry signature.asc Description: PGP signature __

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

2010-04-13 Thread Guido van Rossum
On Tue, Apr 13, 2010 at 1:21 PM, Barry Warsaw wrote: > I am attaching the latest revision of PEP 3147 to this message, which is also > available here: > > http://www.python.org/dev/peps/pep-3147/ > > I think the PEP is ready for pronouncement, and the patch is pretty much ready > for merging into