py_compile vs. built-in compile, with __future__
dhyams
dhyams at gmail.com
Mon Jun 10 19:31:47 EDT 2013
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.
More information about the Python-list
mailing list