On 10 Oct 2014 00:05, "Nathaniel Smith" <njs@pobox.com> wrote:
>
> > Valid reasons would be to make it easier for alternative interpreters,
> > or to catch edge cases (e.g. make it work nicely with custom
> > importers, zip files, etc). But at that point, we can just do it the
> > "right way"*, have the backcompat story to a third-party shim.
> >
> > * i.e. "not paying attention to older Pythons" – I'm not saying
> > __new__.py is necessarily the right way, I'm criticizing this reason
> > against it
>
> My point is just that it matters whether a backcompat shim is doable. Probably there is some way to implement a backcompat shim for __new__.py, but I don't immediately know how to do it.

Eric Snow already backported the Python 3.4 importlib to Python 2.7 as importlib2, and I know of at least one large company that is planning to deploy that in order to benefit from the directory caching feature. It's a reasonably safe assumption that any future Python 3 import system changes will be made available for Python 2.7 the same way.

That said...

> And again, this is to be compared to the __class__ assignment approach, where we know very well that a backcompat shim is doable because it is done :-).

I actually agree making modules a proxy type that allows setting __class__ on instances is likely the simpler solution here.

You won't get full magic method support, but it *will* enable use of the descriptor protocol for module level attributes.

Cheers,
Nick.

>
> -n
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/