On Mar 16, 2010, at 07:44 PM, Nick Coghlan wrote:
>In Python 3.1, *invoking* py_compile.compile() will create 2.x style
>bytecode. Similarly, when force==False, compileall.compile_dir() and
>compileall.compile_path() will check for 2.x style bytecode in order to
>decide whether or not to compile t
Barry Warsaw wrote:
> On Mar 14, 2010, at 12:17 AM, Nick Coghlan wrote:
>> While it's probably OK if the import side-effects only create files
>> using the new scheme, the standard library modules will likely need to
>> support both schemes (although I'm not sure if "same as import system"
>> or "s
On Mar 15, 2010, at 07:43 AM, Nick Coghlan wrote:
>He did (in favour of keeping the directory visible).
http://www.mail-archive.com/python-dev@python.org/msg45203.html
(added to pep)
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mail
On Mar 14, 2010, at 04:37 PM, Paul Moore wrote:
>The bdist_wininst installer also compiles modules explicitly on
>install (as does the python.org Windows MSI installer). I've always
>assumed that this worked via compileall, but haven't checked.
>Regardless, these should probably also be covered in
On Mar 14, 2010, at 12:17 AM, Nick Coghlan wrote:
>Hmm - methinks the PEP actually needs to talk explicitly about the
>py_compile and compileall modules. These compile the files directly
>rather than using the import system's side-effect, so they'll need to
>understand the intricacies of the new s
Jon Ribbens wrote:
Sorry if I missed it, but why on earth is the bytecode directory
__pycache__ and not .pycache? (Or indeed anything else that starts
with a '.') Surely this is a classic ideal use case for a "hidden"
directory?
Please don't try to hide it. On MacOSX, it makes it impossible
to
R. David Murray wrote:
> On Sun, 14 Mar 2010 12:59:50 -, Jon Ribbens
> wrote:
>> Sorry if I missed it, but why on earth is the bytecode directory
>> __pycache__ and not .pycache? (Or indeed anything else that starts
>> with a '.') Surely this is a classic ideal use case for a "hidden"
>> dire
On Sun, 14 Mar 2010 12:59:50 -, Jon Ribbens
wrote:
> On Fri, Mar 12, 2010 at 05:56:57PM -0500, Barry Warsaw wrote:
> > Nope, sorry I should have been clearer.
> >
> > *creation* is the key here. As per BDFL pronouncement, we'll support
> > reading
> > pyc-only modules just like we do today
On 13 March 2010 14:17, Nick Coghlan wrote:
> The creation side could be made a little more explicit in the PEP. We
> could also do something via the compileall module.
>
> (Pause while Nick goes and reads the source code for compileall for the
> first time ever...)
>
> Hmm - methinks the PEP actu
Le Sun, 14 Mar 2010 12:59:50 +,
Jon Ribbens a écrit :
>
> Sorry if I missed it, but why on earth is the bytecode directory
> __pycache__ and not .pycache? (Or indeed anything else that starts
> with a '.') Surely this is a classic ideal use case for a "hidden"
> directory?
I suppose the same
On Sun, 14 Mar 2010 11:59:50 pm Jon Ribbens wrote:
> Sorry if I missed it, but why on earth is the bytecode directory
> __pycache__ and not .pycache? (Or indeed anything else that starts
> with a '.') Surely this is a classic ideal use case for a "hidden"
> directory?
I disagree with your assumpt
On Fri, Mar 12, 2010 at 05:56:57PM -0500, Barry Warsaw wrote:
> Nope, sorry I should have been clearer.
>
> *creation* is the key here. As per BDFL pronouncement, we'll support reading
> pyc-only modules just like we do today. This is in PEP 3147. We won't
> support creating them though.
>
> B
Barry Warsaw wrote:
> *creation* is the key here. As per BDFL pronouncement, we'll support reading
> pyc-only modules just like we do today. This is in PEP 3147. We won't
> support creating them though.
The creation side could be made a little more explicit in the PEP. We
could also do somethin
On Mar 12, 2010, at 10:48 PM, Michael Foord wrote:
>On 12/03/2010 19:53, Barry Warsaw wrote:
>> I believe we've decided /not/ to support creation of bytecode-only
>> distributions out of the box.
>>
>
>I thought Guido said on this topic [1]:
>
>" FWIW, I started at -1 and am still -1. I think
On 12/03/2010 22:48, Michael Foord wrote:
On 12/03/2010 19:53, Barry Warsaw wrote:
On Mar 04, 2010, at 11:34 PM, Nick Coghlan wrote:
The remaining open question to my mind is whether or not there should be
a -X option to control the bytecode generation. E.g.:
-Xcache_bytecode=no (don't wr
On 12/03/2010 19:53, Barry Warsaw wrote:
On Mar 04, 2010, at 11:34 PM, Nick Coghlan wrote:
The remaining open question to my mind is whether or not there should be
a -X option to control the bytecode generation. E.g.:
-Xcache_bytecode=no (don't write bytecode files at all)
-B and $P
On Mar 04, 2010, at 11:34 PM, Nick Coghlan wrote:
>The remaining open question to my mind is whether or not there should be
>a -X option to control the bytecode generation. E.g.:
>
>-Xcache_bytecode=no (don't write bytecode files at all)
-B and $PYTHONDONTWRITEBYTECODE will still be supported and
Barry Warsaw wrote:
> On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:
>
>> I understand the need to ship without source -- but why does that
>> require supporting .pyc (or .pyo) -only?
>>
>> Couldn't vendors just replace the real .py files with empty files?
>
> Yes, I think that's a possibility.
Le Thu, 04 Mar 2010 16:39:03 +1300,
Greg Ewing a écrit :
> Antoine Pitrou wrote:
>
> > Unless the .py files arrange to raise a syntax error on compiling.
>
> I guess that prevents a total disaster, but the
> program is still broken and you have to hunt down
> the offending files and fix the time
Antoine Pitrou wrote:
Actually, I find it neater to have a single cache directory. It makes
for much less clutter, and simpler ignore rules.
Another possibility would be to have a single top-level
cache directory with a subdirectory for each version:
__bytecode__.pycache//.pyc
I don't thin
Antoine Pitrou wrote:
Unless the .py files arrange to raise a syntax error on compiling.
I guess that prevents a total disaster, but the
program is still broken and you have to hunt down
the offending files and fix the timestamps -- if
it's even evident what the problem is and how to
fix it.
Glyph Lefkowitz wrote:
if we're going to have it be something.something-else, can we please
make sure that .something-else is a common extension that means
"python bytecode cache"?
Maybe something like
__bytecode-__.pycache
?
--
Greg
___
Python-
Le Thu, 04 Mar 2010 16:22:13 +1300,
Greg Ewing a écrit :
> Glenn Linderman wrote:
>
> > In this scenario, the .pyc files would still live in __pycache__ ?
> > Complete with the foo..pyc naming ?
>
> It might be neater to have a separate cache directory
> for each bytecode version, named __cac
Le Wed, 3 Mar 2010 17:51:04 -0800,
Brett Cannon a écrit :
> On Wed, Mar 3, 2010 at 16:37, Jim Jewett wrote:
>
> > I understand the need to ship without source -- but why does that
> > require supporting .pyc (or .pyo) -only?
> >
> > Couldn't vendors just replace the real .py files with empty fil
On Mar 3, 2010, at 10:22 PM, Greg Ewing wrote:
> Glenn Linderman wrote:
>
>> In this scenario, the .pyc files would still live in __pycache__ ? Complete
>> with the foo..pyc naming ?
>
> It might be neater to have a separate cache directory
> for each bytecode version, named __cache.__ or
> s
Glenn Linderman wrote:
In this scenario, the .pyc files would still live in __pycache__ ?
Complete with the foo..pyc naming ?
It might be neater to have a separate cache directory
for each bytecode version, named __cache.__ or
some such.
--
Greg
__
Barry Warsaw wrote:
On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:
Couldn't vendors just replace the real .py files with empty files?
Yes, I think that's a possibility. What would people think about that?
Seems like a perverse thing to have to do to me.
Also a bit fragile, since you woul
On approximately 3/3/2010 5:49 PM, came the following characters from
the keyboard of Barry Warsaw:
On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:
>I understand the need to ship without source -- but why does that
>require supporting .pyc (or .pyo) -only?
>
>Couldn't vendors just replace th
On Wed, Mar 3, 2010 at 16:37, Jim Jewett wrote:
> I understand the need to ship without source -- but why does that
> require supporting .pyc (or .pyo) -only?
>
> Couldn't vendors just replace the real .py files with empty files?
>
Because if someone screws up the mod time on the source files th
On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:
>I understand the need to ship without source -- but why does that
>require supporting .pyc (or .pyo) -only?
>
>Couldn't vendors just replace the real .py files with empty files?
Yes, I think that's a possibility. What would people think about that
I understand the need to ship without source -- but why does that
require supporting .pyc (or .pyo) -only?
Couldn't vendors just replace the real .py files with empty files?
Then no one would need the extra stat call, and no one would be bitten
by orphaned .pyc files after a rename.
[Yes, zips c
31 matches
Mail list logo
