On Wed, 13 Jun 2012 20:46:50 +0200, Antoine Pitrou <solipsis@pitrou.net> wrote:
> On Wed, 13 Jun 2012 11:20:24 -0700
> Toshio Kuratomi <a.badger@gmail.com> wrote:
> > On Wed, Jun 13, 2012 at 01:58:10PM -0400, R. David Murray wrote:
> > >
> > > OK, but you didn't answer the question :).  If I understand correctly,
> > > everything you said applies to *writing* the bytecode, not reading it.
> > >
> > > So, is there any reason to not use the .pyo file (if that's all that is
> > > around) when -O is not specified?
> > >
> > > The only technical reason I can see why -O should be required for a .pyo
> > > file to be used (*if* it is the only thing around) is if it won't *run*
> > > without the -O switch.  Is there any expectation that that will ever be
> > > the case?
> > >
> > Yes.  For instance, if I create a .pyo with -OO it wouldn't have docstrings.
> > Another piece of code can legally import that and try to use the docstring
> > for something.  This would fail if only the .pyo was present.
>
> Not only docstrings, but also asserts. I think running a pyo without -O
> would be a bug.

Again, a program that depends on asserts is buggy.

As Ethan pointed out we are asking about the case where someone is
*deliberately* setting the .pyo file up to be run as the "normal"
case.

I'm not sure we want to support that, I just want us to be clear
about why we don't :)

PyPy toolchain is an example of such buggy program. And oh any tests. I would not be impressed if my python read .pyo files out of nowhere when not running with -O flag (I'm trying very hard to never run python with -O, because it's different python after all)
">

(original) (raw)

On Wed, Jun 13, 2012 at 9:13 PM, R. David Murray <rdmurray@bitdance.com> wrote:

On Wed, 13 Jun 2012 20:46:50 +0200, Antoine Pitrou <solipsis@pitrou.net> wrote:
> On Wed, 13 Jun 2012 11:20:24 -0700
> Toshio Kuratomi <a.badger@gmail.com> wrote:
> > On Wed, Jun 13, 2012 at 01:58:10PM -0400, R. David Murray wrote:
> > >
> > > OK, but you didn't answer the question :). If I understand correctly,
> > > everything you said applies to \*writing\* the bytecode, not reading it.
> > >
> > > So, is there any reason to not use the .pyo file (if that's all that is
> > > around) when -O is not specified?
> > >
> > > The only technical reason I can see why -O should be required for a .pyo
> > > file to be used (\*if\* it is the only thing around) is if it won't \*run\*
> > > without the -O switch. Is there any expectation that that will ever be
> > > the case?
> > >
> > Yes. For instance, if I create a .pyo with -OO it wouldn't have docstrings.
> > Another piece of code can legally import that and try to use the docstring
> > for something. This would fail if only the .pyo was present.
>
> Not only docstrings, but also asserts. I think running a pyo without -O
> would be a bug.

Again, a program that depends on asserts is buggy.

As Ethan pointed out we are asking about the case where someone is
\*deliberately\* setting the .pyo file up to be run as the "normal"
case.

I'm not sure we want to support that, I just want us to be clear
about why we don't :)

PyPy toolchain is an example of such buggy program. And oh any tests. I would not be impressed if my python read .pyo files out of nowhere when not running with -O flag (I'm trying very hard to never run python with -O, because it's different python after all)