[ZODB-Dev] RE: RE: RE: PersistentMapping
Tim Peters wrote: Looks it got lost in the branches. PersistentMapping.__iter__ was added in ZODB 3.4.2, just this August: http://mail.zope.org/pipermail/zodb-checkins/2005-August/010225.html Log message for revision 38076: Gave PersistentMapping an __iter__ method. Also gave it some tests (it was woefully untested). ... Tests... there are test suites for PersistentMapping both in src/ZODB/tests/testPersistentMapping.py (which is the one that checkin message talked about) and one in src/persistent/tests/test_mapping.py (which I added when I found test_list.py, but no mapping tests in that place). Now there are two test suites for persistent mapping, just as there are for lists. In the case of lists it's even clearer than for mappings that the duplication is unnecessary as the test code is more or less the same. The tests in src/ZODB/tests were touched more recently than those in src/persistent/tests according to svn, but IMO it's more obvious to test lists and mappings close to where they are defined. What to do about this? Looks like the 3.5 branch got overlooked. Merging rev 38076 from 3.4 branch to 3.5 branch would be fine. This yields a large conflict in 3.5's NEWS.txt. Should I just leave it untouched and not modify old news? -- Thomas ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] RE: RE: RE: PersistentMapping
[Thomas Lotze] Tests... there are test suites for PersistentMapping both in src/ZODB/tests/testPersistentMapping.py (which is the one that checkin message talked about) and one in src/persistent/tests/test_mapping.py (which I added when I found test_list.py, but no mapping tests in that place). Now there are two test suites for persistent mapping, just as there are for lists. In the case of lists it's even clearer than for mappings that the duplication is unnecessary as the test code is more or less the same. The tests in src/ZODB/tests were touched more recently than those in src/persistent/tests according to svn, but IMO it's more obvious to test lists and mappings close to where they are defined. What to do about this? The best idea is to clean it up so that it makes good sense. There's lots of historical cruft in the ZODB code base that doesn't make much sense anymore. Looks like the 3.5 branch got overlooked. Merging rev 38076 from 3.4 branch to 3.5 branch would be fine. This yields a large conflict in 3.5's NEWS.txt. Should I just leave it untouched and not modify old news? Old news will become new news again, when the next micro release in the ZODB 3.5 line is made. 3.5.1 is current. All changes made now on the 3.5 branch will eventually show up in a 3.5.2 release, and NEWS.txt on the 3.5 branch should be changed to record those changes as they're made (the idea that a release manager is going to dig thru ZODB history to do this at the last second before a release is a fantasy -- won't happen). BTW, merges to NEWS-like files generally don't work well across branches. What to do instead: - Do the merge. - Do svn revert NEWS.txt to throw away the botched merged on that single file. - Edit NEWS.txt by hand, inserting branch-appropriate NEWS for what changed in the rest of the merge. Usually this amounts to just copying paragraphs from one NEWS.txt to another, changing version numbers in an obvious way. ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] RE: RE: RE: PersistentMapping
Tim Peters wrote: Things I can't guess include which version of ZODB you're trying this with, and exactly what the errors were. Copy+paste generally works a lot better than English paraphrasing. Sorry. From the build/lib.foo part I guess you're running on Linux. Right. So I tried that just now using ZODB trunk. It failed too, but with different symptoms than you're describing: $ python2.4 setup.py build ... $ python2.4 test.py -v Running tests from build/lib.linux-i686-2.4 Traceback (most recent call last): File test.py, line 40, in ? from zope.testing import testrunner ImportError: No module named zope.testing $ Well, as I wrote, I have the zope package from a current Zope3 trunk in my path. Oh, wait. I wrote this on #zope3-dev where I asked first. Sorry again, I confused myself by spreading over too many (i.e. more than one) media... Anyway, you don't seem to have Zope in your path, but I do. This worked (which is what I normally do): It did for me too. I guess the crucial difference was doing build_ext instead of just build. Maybe someone with more distutils clue could say something about it; if my guess is right, README.txt should be changed. It should also go in the Zope-2_7-branch branch of CVS module ZODB3 (which will eventually become ZODB 3.2.11, for use in the Zope 2.7 line). Yes, you wrote that before, I just didn't quote it. I'd have to find out first whether I have write access to the CVS, though. 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. 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) -- Thomas ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] RE: RE: RE: PersistentMapping
[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). ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
