Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python-future and six's with_meta and the stack frame #75

Open
faassen opened this issue Jul 8, 2014 · 2 comments
Open

python-future and six's with_meta and the stack frame #75

faassen opened this issue Jul 8, 2014 · 2 comments

Comments

@faassen
Copy link

faassen commented Jul 8, 2014

In Morepath, I use a library Venusian within a metaclass to attach some information. Venusian goes up the frames to find out in which context the attachment takes place (module, class).

Introducing the metaclass in Morepath broke its Python 3 compatibility. So I tried to use future.utils.with_meta. I couldn't make it work -- the depth of the stack frame had changed. I adjusted the Venusian call to use an increased depth, but from my limited debugging, the depth of the stack frame seems to vary depending on whether a class (with a metaclass) is defined in a function or in a module-level context.

I discovered future contains a copy of six. So I tried using future.utils.six's with_meta and all my tests passed without a problem in Python 2, Python 3 and PyPy. I didn't need to adjust the depth either.

To make matters more exciting, I switched to six proper, 1.7.3, which is presumably a more recent version than the copy in python-future, and all my tests broke again in a similar way to python-future's...

I thought I'd better report this problem.

Meanwhile I think it's best to take old-six's version and copy it into Morepath. I guess it isn't perfect, but it seems to work for my purposes.

@faassen
Copy link
Author

faassen commented Jul 8, 2014

It would be nice if at the very least with_meta's stack frame behavior could be made consistent all the way through. Preferably level 1 of depth like plain Python, but if it's to be 2, I can adjust for that, as long as it's the same in all circumstances and versions of Python.

I'd also like to know why the old version in six needed to be adjusted -- presumably it fixes some issues with metaclasses, and since the old version does the job for my metaclass, I wonder what's wrong with it and if it's going to bite me.

@faassen
Copy link
Author

faassen commented Jul 8, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants