On 5 January 2011 15:57, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Wed, Jan 5, 2011 at 11:42 PM, Michael Foord
<fuzzyman@voidspace.org.uk> wrote:
> So should I do this in unittest for Python 2.7 / 3.2?
> The problem this *would* solve is that pickled unittest objects from 2.7 /
> 3.2 can't be unpickled on earlier versions of Python.
> I don't know how *real* a problem it is or whether it is worth losing /
> faking the __module__ information on these classes to solve it. Sure it's a
> problem that is likely to bite *someone* at some point, but not very many
> people. If someone is using __module__ information to find source code (or
> anything else) for a class then changing __module__ will break that, so I'm
> not convinced it's a worthwhile tradeoff.

The two examples I looked at (functools and datetime) favoured hiding
the implementation details at the cost of causing introspection
problems. Despite my comments in the opening post of the thread, I
think that is the better trade-off to make.

Both of those are because of underlying C implementations where introspection problems would be the default anyway, which isn't quite the same for situation for unittest.



Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
Python-ideas mailing list


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html