py_compile vs. built-in compile, with __future__

[dhyams]

The built-in compile() function has a "flags" parameter that one can use to influence the "__future__" mechanism. However, py_compile.compile, which I'm using to byte-compile code, doesn't have an equivalent means to do this.

Is this by design, or would this be considered a bug? I'm just wanting to do something like:

import __future__
py_compile.compile("foobar.py",flags=__future__.CO_FUTURE_DIVISION)

but there is no "flags" parameter to py_compile.compile().

It seems like this would be fixed just as easily as adding a "flags" parameter to py_compile.compile(), and then passing that through to the built-in compile(), which is called inside of py_compile.compile().

 

[Terry Jan Reedy]

The built-in compile() function has a "flags" parameter that one can
use to influence the "__future__" mechanism. However,
py_compile.compile, which I'm using to byte-compile code, doesn't
have an equivalent means to do this.

That flag was added to compile bacause it is needed to compile
expressions and single statements, whether in string or ast form, that
use future syntax. It is impossible to include a future statement with
either. It is not needed for compiling multiple statements.

Is this by design, or would this be considered a bug?

Design, not needed.

import __future__
py_compile.compile("foobar.py",flags=__future__.CO_FUTURE_DIVISION)

Put the future statement inside foobar.py just as you would do if
running it from the command line. Notice that there is no command-line
future flag either.

Terry

 

[dhyams]

That flag was added to compile bacause it is needed to compile

expressions and single statements, whether in string or ast form, that

use future syntax. It is impossible to include a future statement with

either. It is not needed for compiling multiple statements.



Design, not needed.







Put the future statement inside foobar.py just as you would do if

running it from the command line. Notice that there is no command-line

future flag either.



Terry

I guess I'll have to agree to disagree here...the situation I'm in is that I want a user to be able to write a mathematical plugin with as little effort as possible. So I want the "from __future__ import division" to be baked into the plugin, without have to require the user to put that bit of confusingness at the top of every plugin they write. It's a matter of eleganceto the end-user, especially because I want to make the plugins as idiot-proof as I can. It will be common for a user not familiar with python to make the common 1/2 mistake (vs. 1.0/2.0).

Is that not a reasonable use-case?

I added the capability in my local Python tree with two very small modifications to py_compile.py:


Change (I'm leaving out the line numbers because they will be different fordifferent versions of Python).

< def compile(file, cfile=None, dfile=None, doraise=False):

def compile(file, cfile=None, dfile=None, doraise=False, flags=0):

and

< codeobject = __builtin__.compile(codestring, dfile or file,'exec')

codeobject = __builtin__.compile(codestring, dfile or file,'exec',flags=flags)

Seems like a reasonable use-case and a correspondingly tiny change to the Python source code base to me...but if no one else sees the value, then I'lljust leave it alone.

 

[Chris Angelico]

I guess I'll have to agree to disagree here...the situation I'm in is that I want a user to be able to write a mathematical plugin with as little effort as possible. So I want the "from __future__ import division" to be baked into the plugin, without have to require the user to put that bit of confusingness at the top of every plugin they write. It's a matter of elegance to the end-user, especially because I want to make the plugins as idiot-proof as I can. It will be common for a user not familiar with python to make the common 1/2 mistake (vs. 1.0/2.0).

Is that not a reasonable use-case?

Can you read the file into a string, prepend a future directive, and
then compile the string?

Alternatively, can you switch to Python 3, where the future directive
isn't necessary?

If all else fails, you should be able to just copy and mod the
function into your own source file.

ChrisA

 

[dhyams]

Can you read the file into a string, prepend a future directive, and

then compile the string?

Technically yes, except that now there is complication of writing the modified module back to a file so that I can still use py_compile.compile() to byte compile that code. If I don't do that, then I would be duplicating thework of py_compile.compile(), which wouldn't be good design. And I some file caching already going on that is reasonably complicated already, that Ididn't want to add another level of failure modes to.

Alternatively, can you switch to Python 3, where the future directive

isn't necessary?

If only all of my dependencies were Python 3 ready But that really doesn't solve the underlying problem...surely there will be other "futures" that people will want to use when moving from Python 3.x to Python y.z, for example.

If all else fails, you should be able to just copy and mod the

function into your own source file.

That's kind of where I am now, but IMO the small addition of the flags argument to py_compile.compile() takes care of things.

 

[Neil Cerutti]

Technically yes, except that now there is complication of
writing the modified module back to a file so that I can still
use py_compile.compile() to byte compile that code.

You would use StringIO instead of writing a temp file.

 

[dhyams]

You would use StringIO instead of writing a temp file.

I don't think that would work...py_compile takes a filename as input, not a file object.

 

[Neil Cerutti]

I don't think that would work...py_compile takes a filename as
input, not a file object.

Dang. Sorry for the misinfo.