On Tue, Aug 31, 2010 at 11:43 PM, Ralph Versteegen <[email protected]> wrote: > On 31 August 2010 02:34, David Gowers <[email protected]> wrote: >> On Mon, Aug 30, 2010 at 9:52 PM, Ralph Versteegen <[email protected]> wrote: >>> I tried it out, discovered it was broken, and eventually discovered >>> that this was due (only) to errors in the RELOAD documentation. Nice >>> work! Patch attached. >> >> Thanks! Pushed to git master + fixed the doctests that had broken due >> to the stringtable changes. > > Ah, since I don't have nose I forgot about the doctests.
Hehe, you don't need nose to do doctesting. but okay. > >> (also I had added a reload_from_dict function since then. That's >> available now too FWIW) > > Looks useful. But I'm not sure just what is or is not useful until I > actually sit down and build a real program using nohrio.reload. No > ideas for one yet. Well I was mainly thinking if you wanted to write documents in YAML and convert them to RELOAD, this would make it only slightly harder than falling off a log. (providing you didn't care about node order -- unless you are using Py3, the YAML module doesn't provide ordered mappings.) ---- import yaml f = open (myfile,'rb') y = yaml.safe_load(f) f.close() from nohrio.reload import reload_from_dict r = reload_from_dict (y, 'root') f = open (myoutfile,'wb') r.write_root(f) ---- > >>> It now correctly reads and writes all RELOAD >>> documents that I threw at it, including the unittest.rld that >>> reloadtest produces. Also, I reimplemented reload2xml in a couple >>> lines (MUCH nicer than the 'real' thing :) ), >> lxml2 is pretty nice :) I had it's model in mind vaguely when >> implementing my system. > > I might take a look at lxml2. The official reload interface still > feels unfinished to me. Oh, k.. just had assumed you used that, since it's available in many python installations. > > However, I notice you're still assuming children with the same name > are in the same order. hm? I compared the sets of their names. If those don't differ, then I can safely assume that I can sort only one of the lists of names and use it to reorder both lists of children. (I'm assuming you have the latest changes; everything has been pushed) Their order may or may not matter depending on > the document. It's not very pleasant to fix, but I assume that Python > uses hashes when comparing objects, so it could be done fairly Using hashes sounds like a MUCH better idea. (It has been done. And pushed. The hashing solution is QUITE elegant.) > efficiently? Or does defining a __eq__ method override any use of > hashes? I should discard the __eq__ method and just define a __hash__ method. Thanks, TMC :) (it turned out I do need a __eq__ method but it can be trivial. I also defined a 'perfect' __eq__ just in case.) >>> I suggest comparing the textual >>> representation of data, so that None == "", and maybe an option for >>> exact comparison like reloadutil's --pedantic option. Not quite how I >>> would have designed things, but that's how things worked out: the >>> official implementation's interface doesn't distinguish between null >>> and zero-length string nodes. >> That seems slightly evil. I'll have to consider it. > > I'm not sure it's needed, since AFAIK the only way that a node would > actually change type to something textually equivalent is through > being converted to XML and back. > > I just looked at the archlinux script for that package, and can see > that someone really screwed it up. If you don't want to move installed > files around, you could download a standalone build instead, and throw > it in a folder in ~. > Okay, I'll try that. thanks TMC. _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
