[RFC] Adding Py3k support while maintaining compatibility with python <= 2.6
mpm at selenic.com
Thu Jun 3 10:23:13 CDT 2010
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() 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()
> > 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(), 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
> 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.
More information about the Mercurial-devel