[ldns-users] adding FILE* support for Python3

Mon Aug 22 12:44:14 UTC 2011

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Karel,

Your effort is commendable, but there looks to be license trouble with
it.  This is where the trouble seems to be from:

+++ trunk/contrib/python/file_py3.i	(revision 0)
@@ -0,0 +1,122 @@
+/*
+ * file_py3.i: Typemaps for FILE* for Python 3. Based on SWIG's file.i (See
+ * the COPYRIGHT file for a list of contributors to SWIG and their
copyright
+ * notices.)
+ *
+ * Copyright (c) 2011, Karel Slany (karel.slany AT nic.cz)
+ *
+ * The redistribution and/or modification terms follow the SWIG licensing
+ * and distribution terms.
+ */

That COPYRIGHT file is from swig, lists their 100s of authors.  So it
looks like that file.i was part of the swig sourcecode.  The swig
sourcecode has the GPLv3 license (they have a legal stuff webpage).
Code generated by swig has very liberal licensing, that is what we have
now, we use the output of swig to generate code for us.  But it seems
that file.i was part of the swig sourcecode ...

So, that means, assuming it is created by editing the GPLv3 work, that
the patch could be hosted in the contrib/ dir, and we explain the
license on that patch in a README.  And it does not get applied to the
main code.  Not exactly sure if we should put GPL code in the contrib of
a BSD tarball, perhaps a web url advertising the patch would be neater.

Not sure if it may be easier to simply have the FILE I/O with python 3
io lib and feed that into the string parser routines of ldns.

The ldns project uses the BSD license.

Best regards,
   Wouter

On 08/22/2011 01:42 PM, Karel Slany wrote:
> Hi Wouter,
> 
> many thanks for applying the previous patches. Here is another one. As
> promised it contains a workaround to enable SWIG to generate FILE*
> wrapper code for Python3. The Python2 wrapper code remains unaffected.
> 
> Here is a brief explanation why this patch does what it does:
>  The I/O in Python2 relies on C standard library -- it uses FILE* and
> the Python2/C API contains a straightforward solution how to access
> these structures from C.
>  Python3 uses the io module containing layers of buffers over the low
> level I/O which the OS provides. The Python3/C file API was reduced --
> no more functions for direct FILE* access. Also the io module C API does
> not contain support for direct FILE* access.
>  The Python3/C file API provides a way how to obtain a file descriptor.
> But since the Python3 has their own buffers the documentation warns
> against mixing access between Python3 and OS-level file descriptors.
> 
> What this patch does:
>  In order to get a valid FILE* pointer from a Python object it wraps a
> ldns C function which takes a FILE* argument with C code that:
> * ensures itself whether the object is a file object
> * flushes the python buffers using a python method call
> * gets the file descriptor and flags and creates a copy of the file
> descriptor
> * opens a FILE* for the descriptor copy
> * passes the opened FILE* to the wrapped function
> * after the execution of the function flushes the FILE* and closes it
> 
> The buffer flushes in Python and C ensure the correct order of written
> data but also may slow-down the code. I have not tested the performance
> impacts very thoroughly. The goal was to make FILE* work in Python3. I
> also do not know what the code will be behaving like when executed in a
> multi-threaded application.
> 
> In order to get rid of the sometimes unnecessary buffer flushes the
> Python3 wrapper can be extended with function opening a file for ldns
> only. Such an approach, however, introduces an inconvenience of
> closing/reopening/closing the file when accessing the files from Python
> (but giving the user control over unnecessary buffer flushing).
> 
> The patch contains new files to the SVN repository so please do not
> forget to make the Python3 example scripts executable and to 'svn add'
> all the new files:
> 
> chmod +x trunk/contrib/python/examples/python3/ldns-*.py
> svn add trunk/contrib/python/file_py3.i
> svn add trunk/contrib/python/examples/python3
> 
> I have tested the new code under the GNU/Linux userland using Python
> 3.1. I intent to test it also under FreeBSD -- don't know whether it
> would compile under Windows.
> 
> Best regards,
> K.
> 
> 
> 
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOUk8ZAAoJEJ9vHC1+BF+NC2IP/R4ykLLHmSCvc8Ch+N5Z3bTK
brQQqJaNR518974flPMBLiBXZ7VWRek3w7695j5rgOrEHKBf94cTSbpbHyvELNmG
7PmoZDgUTURNLcZ45YptK0/T1Cc9uQ7yQlJBeW45xcidZkuvz4Ne/zPeiPgKfxLT
OveG0WURmrsz3XJs+up/IDNcWrVfHx1mZT8BKwXQXuxxwwLJm4KgdXewPNvrUeJw
2HF6IyMhjUnfRUNZvZRTSk8WiDMjskZw7hs6jEfspBvFmbZwAlflgj1wmtOtVrzD
wDj18p5zfW0Zq+eHcl6sOgh0VC2hgWgelVwuPvLOC8dq4laS08O+WesvF2w4z8iB
ZBXlZAoe7OF/eVtve8j0uJm+i1whnD9B4oW+UHa2cHs0PF/MQtsvK8sBo3PcheqP
R8ifs/yXFrzSD/HnoKOWcgE9N8ab872i7kwMlIwLQtfOmaY9w7wHjoGRgcpiji00
YCaIcrss8fvjku4SOoPDnLdg8QzlJEkXp2BAeZSGVVbFjkyoRqRDvxTdk7kJY/Ba
m9wOe0CFFjK16VYKeXXJLf9RHZW5z69+miPj8elFhblinSmr16H/gYEMx02Kr2GV
e8wdk+kL5LnuJZy04uoN8v2CWbOuNNlTTAtVU5xLgT6VISWrkoYlbvpLcN0y1Jc3
1NkLVip3SDVpvaFLMaTE
=FIfP
-----END PGP SIGNATURE-----

