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


Groups > comp.lang.python > #47620

Re: py_compile vs. built-in compile, with __future__

Newsgroups comp.lang.python
Date 2013-06-10 16:31 -0700
References <0bfe7bee-3df2-4fb8-8aad-c2124792b8b6@googlegroups.com> <mailman.2987.1370897988.3114.python-list@python.org> <a0902635-60ca-4c93-a296-88f1740ac8fe@googlegroups.com> <mailman.2990.1370903766.3114.python-list@python.org>
Message-ID <e0a8943b-d851-491d-ad88-5fe1c7241e09@googlegroups.com> (permalink)
Subject Re: py_compile vs. built-in compile, with __future__
From dhyams <dhyams@gmail.com>

Show all headers | View raw


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.

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web