[RFC] Adding Py3k support while maintaining compatibility with python <= 2.6

[Matt Mackall]

On Thu, 2010-06-03 at 11:03 +0200, Dirkjan Ochtman wrote:
> On Wed, Jun 2, 2010 at 22:17, Renato Cunha <renatoc at gmail.com> wrote:
> > The major drawback here is that the call to sys.exc_info()[1] is a bit cryptic,
> > and a call to a function eventually defined in util.py would be better, like:
> >
> > foobar.py:
> >    def exceptionvalue():
> >        return sys.exc_info()[1]
> >    try:
> >        os.unlink('/non/existing/path/foo')
> >    except OSError:
> >        err = exceptionvalue()
> >        print ('There was an error:')
> >        print (err)
> >
> > So, is this new approach good? What about the function name (exceptionvalue)?
> 
> I'd prefer just using sys.exc_info()[1], mostly because I think it's a
> pattern that I think people will be able to recognize from other code
> bases that are getting ported. Using a util.exceptionvalue() really
> doesn't gain us anything, it only obscures the problem.

Not sure I agree with that. In particular I know I won't be able to
remember it and will find myself looking it up somewhere else every time
I want to use it.

I'm beginning to think we might want to extend 2to3 for our purposes
instead.

> As for the octal constants, using constants could be fine. In terms of
> how much code is required for the workaround, it seems to me like just
> using int('666', 8) might be just as clear and require less other crap
> (importing os or referring to util.MODE_something).

Unfortunately several of these use-cases are fairly
performance-sensitive, particularly dirstate. Here we often cache scope
lookups in local variables for performance, just going from an octal
constant to a variable may actually be a measurable performance hit.

-- 
Mathematics is the supreme nostalgia of our time.