On 1 September 2010 15:20, David Gowers <[email protected]> wrote:
> 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.
Well, I did manually copy the lines into a python shell to try them
out, if that's what you mean.
>>
>>> (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)
Very nice.
> ----
>
>>
>>>> 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.
What, used XML? Of course not!
Actually, to be honest I don't use python for more than 20-liners,
although I really wish I did. The problem is that all the projects I'm
involved in are written in nasty languages like FB!
>>
>> 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)
I meant that you compared {'a':0, 'a':1} and {'a':1, 'a':0} as inequal.
But, Mike was quite right that order does matter, I had confused
myself. However in practice, order doesn't matter for most of of our
RELOAD-based file formats. For example, the zone file format right now
contains the list of zones ordered as they appear in a hash table -
essentially randomly. And all these zones are stored in nodes named
"zone" (with null values) indistinguishable to a first degree.
So, could you please add the previous elements_equal function back?
Even better, this function, which further allows identically named
children to be out of order:
def fuzzy_equal (x, y):
if x.name != y.name:
return False
if x.data != y.data:
return False
if len(x.children) != len (y.children):
return False
xh = [hash(v) for v in x.children]
yd = dict((hash(v),v) for v in y.children)
if set(xh) != set(yd.keys()):
return False
return all(fuzzy_equal(c1, yd[c1]))
An alternative that is probably slower:
def fuzzy_equal (x, y):
if x.name != y.name:
return False
if x.data != y.data:
return False
if len(x.children) != len (y.children):
return False
xh = [hash(v) for v in x.children]
yh = [hash(v) for v in y.children]
if set(xh) != set(yh):
return False
for n, c1 in enumerate (x.children):
if fuzzy_equal(c1, y.children[yh.index(xh[n])]) == False:
return False
return True
I don't know whether those are correct, because python isn't installed
on this laptop :(. I also wonder whether there is a more efficient
method that doesn't require temporary sets, and whether it can be made
to not assume equally hashing nodes are equal.
> 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
>
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
