Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #47572 > unrolled thread

py_compile vs. built-in compile, with __future__

Back to article view | Back to comp.lang.python

Contents

  py_compile vs. built-in compile, with __future__ dhyams <dhyams@gmail.com> - 2013-06-10 08:33 -0700
    Re: py_compile vs. built-in compile, with __future__ Terry Jan Reedy <tjreedy@udel.edu> - 2013-06-10 16:59 -0400
      Re: py_compile vs. built-in compile, with __future__ dhyams <dhyams@gmail.com> - 2013-06-10 15:27 -0700
        Re: py_compile vs. built-in compile, with __future__ Chris Angelico <rosuav@gmail.com> - 2013-06-11 08:36 +1000
          Re: py_compile vs. built-in compile, with __future__ dhyams <dhyams@gmail.com> - 2013-06-10 16:31 -0700
            Re: py_compile vs. built-in compile, with __future__ Neil Cerutti <neilc@norwich.edu> - 2013-06-11 15:37 +0000
              Re: py_compile vs. built-in compile, with __future__ dhyams <dhyams@gmail.com> - 2013-06-11 14:25 -0700
                Re: py_compile vs. built-in compile, with __future__ Neil Cerutti <neilc@norwich.edu> - 2013-06-12 13:30 +0000

#47572 — py_compile vs. built-in compile, with __future__

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().

[toc] | [next] | [standalone]

#47605

On 6/10/2013 11:33 AM, dhyams wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#47608

On Monday, June 10, 2013 4:59:35 PM UTC-4, Terry Jan Reedy wrote:
> On 6/10/2013 11:33 AM, dhyams wrote:
> 
> > 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


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?

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 for different 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'll just leave it alone.

[toc] | [prev] | [next] | [standalone]

#47609

On Tue, Jun 11, 2013 at 8:27 AM, dhyams <dhyams@gmail.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#47620

On Monday, June 10, 2013 6:36:04 PM UTC-4, Chris Angelico wrote:
> On Tue, Jun 11, 2013 at 8:27 AM, dhyams <dhyams> wrote:
> 
> > 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?

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 the work of py_compile.compile(), which wouldn't be good design.  And I some file caching already going on that is reasonably complicated already, that I didn'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.

[toc] | [prev] | [next] | [standalone]

#47667

On 2013-06-10, dhyams <dhyams@gmail.com> wrote:
> On Monday, June 10, 2013 6:36:04 PM UTC-4, Chris Angelico wrote:
>> 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.

You would use StringIO instead of writing a temp file.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#47704

On Tuesday, June 11, 2013 11:37:17 AM UTC-4, Neil Cerutti wrote:
> On 2013-06-10, dhyams <dhyams@gmail.com> wrote:
> 
> > On Monday, June 10, 2013 6:36:04 PM UTC-4, Chris Angelico wrote:
> 
> >> 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.
> 
> 
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#47802

On 2013-06-11, dhyams <dhyams@gmail.com> wrote:
>> 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.

Dang. Sorry for the misinfo.

-- 
Neil Cerutti

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web