Re: Only Bytecode, No .py Files

2011-07-29 Thread John Roth
On Jul 27, 8:56 am, Thomas Rachel nutznetz-0c1b6768-bfa9-48d5- a470-7603bd3aa...@spamschutz.glglgl.de wrote: Am 27.07.2011 14:18 schrieb John Roth: Two comments. First, your trace isn't showing attempts to open .py files, it's showing attempts to open the Curses library in the bash

Re: Only Bytecode, No .py Files

2011-07-29 Thread Ethan Furman
John Roth wrote: ACK. That is exactly what I wanted to show. (With the difference that this is probably nt the bash, but the linux loader trying to link a .so, but for the problem, it doesn't make any difference.) Sorry. I thought what you posted was from the OP. I guess I don't really expect

Re: Only Bytecode, No .py Files

2011-07-29 Thread Jerry Hill
On Fri, Jul 29, 2011 at 8:51 AM, John Roth johnro...@gmail.com wrote: Sorry. I thought what you posted was from the OP. I guess I don't really expect someone to post a completely irrelevant trace in a thread started by someone who has a problem. I'm not sure why you would think that that post

Re: Only Bytecode, No .py Files

2011-07-29 Thread Thomas Rachel
Am 29.07.2011 14:51 schrieb John Roth: Sorry. I thought what you posted was from the OP. I guess I don't really expect someone to post a completely irrelevant trace in a thread started by someone who has a problem. In what way do you find the trace irrelevant? It clearly shows that it is not

Re: Only Bytecode, No .py Files

2011-07-29 Thread Alan Meyer
On 07/26/2011 11:19 AM, Eldon Ziegler wrote: Is there a way to have the Python processor look only for bytecode files, not .py files? We are seeing huge numbers of Linux audit messages on production system on which only bytecode files are stored. The audit subsystem is recording each open

Re: Only Bytecode, No .py Files

2011-07-27 Thread Thomas Rachel
Am 26.07.2011 17:19 schrieb Eldon Ziegler: Is there a way to have the Python processor look only for bytecode files, not .py files? We are seeing huge numbers of Linux audit messages on production system on which only bytecode files are stored. The audit subsystem is recording each open failure

Re: Only Bytecode, No .py Files

2011-07-27 Thread Christian Heimes
Am 27.07.2011 03:32, schrieb harrismh777: Christian Heimes wrote: The first four bytes of a pyc file contain the magic header. It must match the magic of the current Python version. The next four bytes contain the pyc_mtime. It must match the mtime of the corresponding .py files as returned

Re: Only Bytecode, No .py Files

2011-07-27 Thread John Roth
On Jul 27, 1:10 am, Thomas Rachel nutznetz-0c1b6768-bfa9-48d5- a470-7603bd3aa...@spamschutz.glglgl.de wrote: Am 26.07.2011 17:19 schrieb Eldon Ziegler: Is there a way to have the Python processor look only for bytecode files, not .py files? We are seeing huge numbers of Linux audit messages

Re: Only Bytecode, No .py Files

2011-07-27 Thread Thomas Rachel
Am 27.07.2011 14:18 schrieb John Roth: Two comments. First, your trace isn't showing attempts to open .py files, it's showing attempts to open the Curses library in the bash directory. Of course. My goal was to show that the OP's problem is not a python one, but occurs all over several

Re: Only Bytecode, No .py Files

2011-07-27 Thread harrismh777
Christian Heimes wrote: Now the test.py has the same mtime as test.pyc and Python won't recompile the .pyc file from the .py file as long as the magic header (168686339) is correct. ~very cool. -- http://mail.python.org/mailman/listinfo/python-list

Only Bytecode, No .py Files

2011-07-26 Thread Eldon Ziegler
Is there a way to have the Python processor look only for bytecode files, not .py files? We are seeing huge numbers of Linux audit messages on production system on which only bytecode files are stored. The audit subsystem is recording each open failure. Thanks, Eldon Ziegler -- http

Re: Only Bytecode, No .py Files

2011-07-26 Thread Billy Mays
On 07/26/2011 11:19 AM, Eldon Ziegler wrote: Is there a way to have the Python processor look only for bytecode files, not .py files? We are seeing huge numbers of Linux audit messages on production system on which only bytecode files are stored. The audit subsystem is recording each open

Re: Only Bytecode, No .py Files

2011-07-26 Thread Miki Tebeka
*Maybe* you can cook something with import hooks (see PEP 302). However I think the easier option will be to distribute the .py files as well. -- http://mail.python.org/mailman/listinfo/python-list

Re: Only Bytecode, No .py Files

2011-07-26 Thread Dan Stromberg
Another possibility: You could probably create a bunch of zero-length .py's that are older than the corresponding .pyc's. On Tue, Jul 26, 2011 at 8:19 AM, Eldon Ziegler eld...@atlanticdb.comwrote: Is there a way to have the Python processor look only for bytecode files, not .py files? We

Re: Only Bytecode, No .py Files

2011-07-26 Thread Eldon Ziegler
that are older than the corresponding .pyc's. On Tue, Jul 26, 2011 at 8:19 AM, Eldon Ziegler eld...@atlanticdb.com wrote: Is there a way to have the Python processor look only for bytecode files, not .py files? We are seeing huge numbers of Linux audit messages

Re: Only Bytecode, No .py Files

2011-07-26 Thread Terry Reedy
to have the Python processor look only for bytecode files, not .py files? We are seeing huge numbers of Linux audit messages on production system on which only bytecode files are stored. The audit subsystem is recording each open failure. Try packaging the app into a zip file so

Re: Only Bytecode, No .py Files

2011-07-26 Thread Christian Heimes
Am 26.07.2011 23:20, schrieb Eldon Ziegler: That seemed like a good idea but the .py file was complied even though it was dated 2001-01-01 00:00:00. Python must be checking something beside the date. The first four bytes of a pyc file contain the magic header. It must match the magic of the

Re: Only Bytecode, No .py Files

2011-07-26 Thread harrismh777
Christian Heimes wrote: The first four bytes of a pyc file contain the magic header. It must match the magic of the current Python version. The next four bytes contain the pyc_mtime. It must match the mtime of the corresponding .py files as returned by fstat().st_mtime. If the magic doesn't