Division oddity

[Michael Hudson]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

> Peter Hansen <peter at engcorp.com> writes:
> > > Python has no support for macros or aliases, and it would be silly
> > > to add some special kludge for input().  The user needs to be able
> > > to redefine the function and so forth too.
> > 
> > Sure it does:
> > 
> > def input(*args):
> >     return eval(raw_input(*args))
> 
> For it to be an alias, that definition would have to be injected into
> the module that input is actually called from, not run in a separate
> module.

The problem with doing things this way is that it's not easy to get
Python-defined functions into an extension module.  Nothing deep.

> How the heck does input get at the environment of its caller, anyway?
> Through the frame object chain?  

Yes.  The function you are seeking is called
PyEval_MergeCompilerFlags.

> I guess the obvious fix is for the future division flag to be part of
> the environment, so evaling in the caller environment is done according
> to the flag.  

I'm not sure what you mean here.  eval() already respects future
division, as does execfile() and compile().  input() just got
overlooked when this stuff got added (back in the 2.1 era for nested
scopes, though the details have changed intermittently over the
intervening vwersions).

> Someone has already checked a fix into sourceforge, but I haven't
> looked at it and don't know if it works that way or some other way.

Wouldn't checking have taken about as much time as writing the above
post?  It's a very simple patch...

Cheers,
mwh

-- 
  All obscurity will buy you is time enough to contract venereal
  diseases.                                  -- Tim Peters, python-dev