Assertion for python scripts

[matthias]

Howdy !

I started using the assert() stmt and found it quite useful I
have only one problem: I don't
know how to turn them off again.

I know that "-O" turns off assertions in general. However, how do I
pass thus parameter to
python to an executable script ?

I have tried the following:

1.
!#/usr/bin/env python -O

-> Fails with this msg: /usr/bin/env: python -O: No such file or
directory

Also, putting it in quotes won't do it.

2.
Passing the "-O" to the runnable script won't work either.


Here is my question: How do I maintain debug / release builds that
allow me to switch
debug stmts, like assert, on / off ?

Thanx,
Matthias

 

[Matt McCredie]

Howdy !

I started using the assert() stmt and found it quite useful I
have only one problem: I don't
know how to turn them off again.

I know that "-O" turns off assertions in general. However, how do I
pass thus parameter to
python to an executable script ?

I have tried the following:

1.
!#/usr/bin/env python -O

-> Fails with this msg: /usr/bin/env: python -O: No such file or
directory

Also, putting it in quotes won't do it.

2.
Passing the "-O" to the runnable script won't work either.


Here is my question: How do I maintain debug / release builds that
allow me to switch
debug stmts, like assert, on / off ?

Thanx,
Matthias

Use:
python -O -mcompileall path

That command will compile all of the files in the given path and
produce .pyo files. If the .pyo file is present and up-to-date it will
be used instead of the .py file.

Alternatively you could do this:

python -O -mpy_compile somefile.py

which can be used to compile one file at a time.

Many Python programs and modules include a compile step as part of
their installation process. There is also a -OO option, which will
strip doc-strings as well.

Matt

 

[matthias]

Use:
python -O -mcompileall path

That command will compile all of the files in the given path and
produce .pyo files. If the .pyo file is present and up-to-date it will
be used instead of the .py file.

Alternatively you could do this:

python -O -mpy_compile somefile.py

which can be used to compile one file at a time.

Many Python programs and modules include a compile step as part of
their installation process. There is also a -OO option, which will
strip doc-strings as well.

Matt

Thanx for your reply , Matt !

However, I think I am missing something.

Here is my example prog, assert.py, with the executable bit set:

#!/usr/bin/env python

assert 1 > 1, "ASSERTTION !"

Running this:

# python ./assert.py
Traceback (most recent call last):
File "assert.py", line 3, in ?
assert 1 > 1, "ASSERTTION !"
AssertionError: ASSERTTION !

leads to the expected result.

Now I do this as you've recommended:

# python -O -mpy_compile assert.py

This indeed creates a file with the name assert.pyo. That must be the
optimized one.

Now I try this:

# ./assert.py
Traceback (most recent call last):
File "./assert.py", line 3, in ?
assert 1 > 1, "ASSERTTION !"
AssertionError: ASSERTTION !

Ok, so it still uses the unoptimized version.

Now I try this:

# chmod 755 assert.pyo
# ./assert.pyo
bash: ./assert.pyo: cannot execute binary file

Here is my problem: I want to have an optimized executable version of
assert.py.

I am assuming that I am thinking in an unconventional way wrt Python.
If so, then
how do you start your optimized python scripts ?


Thanx,
Matthias

 

[Bart.]

Friday 02 of November 2007 20:53:12 matthias napisał(a):

Thanx for your reply , Matt !

However, I think I am missing something.

Here is my example prog, assert.py, with the executable bit set:

#!/usr/bin/env python

assert 1 > 1, "ASSERTTION !"

Running this:

# python ./assert.py
Traceback (most recent call last):
File "assert.py", line 3, in ?
assert 1 > 1, "ASSERTTION !"
AssertionError: ASSERTTION !

leads to the expected result.

Now I do this as you've recommended:

# python -O -mpy_compile assert.py

This indeed creates a file with the name assert.pyo. That must be the
optimized one.

Now I try this:

# ./assert.py
Traceback (most recent call last):
File "./assert.py", line 3, in ?
assert 1 > 1, "ASSERTTION !"
AssertionError: ASSERTTION !

Ok, so it still uses the unoptimized version.

Now I try this:

# chmod 755 assert.pyo
# ./assert.pyo
bash: ./assert.pyo: cannot execute binary file

Here is my problem: I want to have an optimized executable version of
assert.py.

I am assuming that I am thinking in an unconventional way wrt Python.
If so, then
how do you start your optimized python scripts ?


Thanx,
Matthias

check this:

python ./assert.pyo

 

[matthias]

Friday 02 of November 2007 20:53:12 matthias napisa (a):























check this:

python ./assert.pyo

Yes, I know that this works. Thanx. However, that's not what I was
going for.

Essentially, I am targeting a build system that allows me to build
debug / release versions
of my Python code. I know how to build the Python code, but how do I
package it so that I
can simply dump it on the test system with either build type and the
same calling interface ?

Thanx,
Matthias

 

[Bart.]

Friday 02 of November 2007 22:07:42 matthias napisał(a):

Yes, I know that this works. Thanx. However, that's not what I was
going for.

Essentially, I am targeting a build system that allows me to build
debug / release versions
of my Python code. I know how to build the Python code, but how do I
package it so that I
can simply dump it on the test system with either build type and the
same calling interface ?

how about distutils ?
look on the egg paskages

 

[Gabriel Genellina]

En Fri, 02 Nov 2007 16:53:12 -0300, matthias

This indeed creates a file with the name assert.pyo. That must be the
optimized one.

Now I try this:

# ./assert.py
Traceback (most recent call last):
File "./assert.py", line 3, in ?
assert 1 > 1, "ASSERTTION !"
AssertionError: ASSERTTION !

Ok, so it still uses the unoptimized version.

Now I try this:

# chmod 755 assert.pyo
# ./assert.pyo
bash: ./assert.pyo: cannot execute binary file

Here is my problem: I want to have an optimized executable version of
assert.py.

Move all your code into modules; those modules can be pre-compiled with -O
as above.
Your main script should contain just a few lines; import the other modules
from inside your main script.
When you import "foo", if python finds "foo.pyo" and it's up to date, it
will use it instead of foo.py;
foo.py doesn't have to be available either.

 

[Carl Banks]

Here is my question: How do I maintain debug / release builds that
allow me to switch
debug stmts, like assert, on / off ?

If you want to distribute a single-file optimized version, perhaps
embedding the Python code as a here-file in a shell script would work
for you. For example:

#!/bin/sh
exec python -O <<EOF

assert False

EOF


For anything larger, I second the advice elsewhere in this thread:
build pyo files and distribute them.


Carl Banks

 

[Carl Banks]

If you want to distribute a single-file optimized version, perhaps
embedding the Python code as a here-file in a shell script would work
for you. For example:

#!/bin/sh
exec python -O <<EOF

assert False

EOF

Not long after I made this suggestion, I suddenly found myself in a
situation where I wanted to do something like this (temporarily: I
needed to disable a pointer check that a buggy C++ extension was
causing). Here's what I ended up with, after falling in a few pits:

#!/bin/sh
MALLOC_CHECK_=0 /usr/bin/python2.4 - "$@" <<'SCRIPT'

<script goes here>

SCRIPT


Carl Banks

 

[Steven W. Orr]

On Friday, Nov 2nd 2007 at 14:14 -0000, quoth matthias:

=>Howdy !
=>
=>I started using the assert() stmt and found it quite useful I
=>have only one problem: I don't
=>know how to turn them off again.
=>
=>I know that "-O" turns off assertions in general. However, how do I
=>pass thus parameter to
=>python to an executable script ?

I had similar questions and I decided that what I really needed for my
app was a preprocessor. I looked around and found what I thought to be
really cool:

http://nedbatchelder.com/code/cog

It's a preprocessor written in python which allows you to embed python
code (called cogs) in your python such that the cogs execute and are
replaced by what they output.

I have print statements (effectively) which produce either output or
nothing, depending on what I pass from the Makefile. The files that I
write are called .cog.py and when I execute make, it produces .py files as
output. It's a hugely useful thing to have available. The only slight
disadvantage is that you have to (remember to) run make if you change your
..cog.py files before retrying something.

--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net