<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hi Bedrich,<br>
    <br>
    I love the generator function. Looks like the pytonicly correct way
    to access ldns_rr_new_frm_fp_l from python to me! The patch is
    applied in trunk, and the demo scripts added to the example
    directory.<br>
    <br>
    Thanks again! Willem<br>
    <br>
    Op 05-05-11 10:33, Bedrich Kosata schreef:
    <blockquote cite="mid:4DC260ED.3070106@nic.cz" type="cite">Hi
      everybody,
      <br>
      <br>
      after working with the python wrapper around ldns_rr_new_frm_fp_l,
      I would like to propose a few changes.
      <br>
      <br>
      The C version of the ldns_rr_new_frm_fp_l function stores the
      state of zone file parsing in 3 different variables - origin,
      prev(ious owner) and (default) ttl. Due to pointer and pointer to
      pointer usage, these are automatically updated by calls to
      ldns_rr_new_frm_fp_l and the only thing the programmer has to take
      care of it not to touch these.
      <br>
      <br>
      However, in Python this is not possible and the wrapper goes
      around this problem by returning the new values of origin, prev
      and ttl as part of the result of the function. It is then left to
      the programmer to send these updated values back to the subsequent
      calls of ldns.ldns_rr_new_frm_fp_l_. I attach a script that shows
      how to do this and I would suggest putting it into the examples
      directory as reference.
      <br>
      <br>
      I also added a convenience function (a generator) into the python
      interface, so that the context is managed automatically and the
      programmer does not have to take care of it. It is part of the
      patch I attach. There is also a demo script for this function
      attached.
      <br>
      <br>
      Another change that I made in the patch is that I removed the 5th
      argument, which indicated whether the result should contain line
      number. As the value of this argument influenced the number and
      order of items in the returned tuple, which I do not consider a
      good design, I removed it and changed the result, so that it
      always contains the number of lines parsed in this step and the
      format of the result is always the same.
      <br>
      <br>
      Please let me know if these changes are acceptable or if there is
      something else needed.
      <br>
      <br>
      With best regards
      <br>
      <br>
      Beda
      <br>
      <br>
      <br>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
ldns-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ldns-users@open.nlnetlabs.nl">ldns-users@open.nlnetlabs.nl</a>
<a class="moz-txt-link-freetext" href="http://open.nlnetlabs.nl/mailman/listinfo/ldns-users">http://open.nlnetlabs.nl/mailman/listinfo/ldns-users</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>