[ZODB-Dev] RE: RE: RE: PersistentMapping

[Tim Peters]

[Tim]
...
>> This worked (which is what I normally do): [build_ext -i]

[Thomas]
> It did for me too. I guess the crucial difference was doing build_ext
> instead of just build.

Yes.

> Maybe someone with more distutils clue could say something about it; if
> my guess is right, README.txt should be changed.

It's more likely due to people fiddling with zpkg.  "setup.py build" _had_
worked fine for running the tests for years, and I know it still worked fine
a few months ago.  But I don't normally do that, so didn't notice when it
broke.  It's not due to changes in ZODB code (no relevant changes have been
made there -- or at least none that I made ;-)).  For whatever reason, looks
like "setup.py build" in ZODB simply ignores the existence of ZODB's
zope/testing directory now (but doesn't ignore ZODB's other zope/*
directories ...).

...

>> I don't know what +1 means on other lists, but on this list it means
>> "that's such a good idea I'm going to devote my life to implementing it,
>> and I promise to finish it before this time next week" -- thanks ;-)

> Normalization of votes should definitely be standardized across lists.

I was pulling your leg -- +1 means the same thing here as elsewhere ("strong
yes, to the extent that I'll least argue in favor of it").

> But then, what does "implementing a deprecation" mean? If it's just
> adding a deprecation warning, I should be able to make it in time ;o)

It means adding the warning, documenting the deprecation in NEWS.txt, adding
a test to ensure that the deprecation warning is raised when appropriate,
and possibly a bunch of tedious hair to suppress the new warning(s) while
the tests that exercise the now-deprecated feature are running (while
deprecated, it's still supported until it goes away, so the tests for it
still need to run).