From 7b1b2e177f7f7cfe9498133cf920f0fc7177e3d7 Mon Sep 17 00:00:00 2001 From: Mike Romberg Date: Tue, 7 Jun 2016 15:28:40 -0600 Subject: [PATCH 1/7] Add documentation about how foo.py finds/loads _foo for python. --- Doc/Manual/Python.html | 112 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) diff --git a/Doc/Manual/Python.html b/Doc/Manual/Python.html index 83baa1a47..e19aae9a9 100644 --- a/Doc/Manual/Python.html +++ b/Doc/Manual/Python.html @@ -117,6 +117,7 @@
  • Enforcing absolute import semantics
  • Importing from __init__.py
  • Implicit Namespace Packages +
  • Searching for the wrapper module
  • Python 3 Support
  • Python 3 Support
  • Python 3 Support
  • Python 3 Support @@ -6065,6 +6066,77 @@ loaded modules. So, one may place the module either globally or in a package as desired.

    +

    36.11.6.4 Statically linked C modules

    + +

    It is strongly recommended to use dynamically linked modules for the C +portion of your pair of python modules. See the section on +Static Linking. If for some reason you still need +to link the C module of the pair of python modules generated by swig into +your interpreter, then this section provides some details on how this impacts +the pure python modules ability to locate the other part of the pair. +

    + +

    When python is extended with C code the python interpreter needs to be +informed about details of the new C functions that have been linked into +the executable. The code to do this is created by swig and is automatically +called in the correct way when the module is dynamically loaded. However +when the code is not dynamically loaded (because it is statically linked) +Then the initialization method for the module created by swig is not +called automatically. And the python interpreter has no idea that the +new swig C module exists. +

    + +

    Before python3, one could simply call the init method created by swig +which would have normally been called when the shared object was dynamically +loaded. The specific name of this method is not given here because statically +linked modules are not encouraged with swig +(Static Linking). However one can find this +init function in the _wrap.c file generated by swig. +

    + +

    Assuming you have found the init function in the _wrap.c file and you +are still undeterred by what has been said so far, then there are two ways +to initialize the swig generated C module with the init method. Which way +you use depends on what version of python your module is being linked with. +Python2 and Python3 treat this init function differently. And they way +they treat it differently affects how the pure python module will be able to +locate the C module. +

    + +

    The details concerning this are covered completly in the documentation +for python itself. Links to the relavent sections follow: +

    + + + +

    There are two keys things to understand. The first of which is that in +python2 the init() function returns void. But in python3, the init() funcion +returns a PyObject * which points to the new module. Secondly when +you call the init() method manually, you are the python importer. So, you +determine which package the C module will be located in. +

    + +

    So, if you are using python3 it is important that you follow what is +described in the python documentation linked above. In particular, you can't +simply call the init() function generated by swig and cast the PyObject +pointer it returns over the side. If you do then python3 still will have no +idea that your C module exists and the pure python half of your wrapper will +not be able to find it. You need to register your module with the python +interpreter as descibed in the python docs. +

    + +

    With python2 things are somewhat more simple. In this case the init function +returns void. And calling it will register your new C module as a global +module. The pure python part of the swig wrapper will be able to find it +because it tries both the package the pure python module is part of and +globally. If you wish to not have the statically linked module be a global +module then you will either need to refer to the python documentation on how +to do this (remember you are now the python importer) or use dynamic linking. +

    +

    36.12 Python 3 Support

    From 64f5d23b1362e0f1444f793cc3f42c5f01b8ed58 Mon Sep 17 00:00:00 2001 From: William S Fulton Date: Sun, 12 Jun 2016 00:13:07 +0100 Subject: [PATCH 4/7] Python docs on static linking section edits --- Doc/Manual/Contents.html | 1 + Doc/Manual/Python.html | 87 ++++++++++++++++++++-------------------- 2 files changed, 45 insertions(+), 43 deletions(-) diff --git a/Doc/Manual/Contents.html b/Doc/Manual/Contents.html index b75da40e3..7107384c8 100644 --- a/Doc/Manual/Contents.html +++ b/Doc/Manual/Contents.html @@ -1600,6 +1600,7 @@
  • Both modules in the same package
  • Split modules
  • Both modules are global +
  • Statically linked C modules
  • Python 3 Support diff --git a/Doc/Manual/Python.html b/Doc/Manual/Python.html index a6325342e..ce7f9fe5a 100644 --- a/Doc/Manual/Python.html +++ b/Doc/Manual/Python.html @@ -122,7 +122,7 @@
  • Both modules in the same package
  • Split modules
  • Both modules are global -
  • Statically linked C modules
    • +
  • Statically linked C modules
  • Python 3 Support @@ -6068,73 +6068,74 @@ as desired.

    36.11.6.4 Statically linked C modules

    +

    It is strongly recommended to use dynamically linked modules for the C -portion of your pair of python modules. See the section on -Static Linking. If for some reason you still need -to link the C module of the pair of python modules generated by swig into +portion of your pair of Python modules. +If for some reason you still need +to link the C module of the pair of Python modules generated by SWIG into your interpreter, then this section provides some details on how this impacts -the pure python modules ability to locate the other part of the pair. +the pure Python modules ability to locate the other part of the pair. +Please also see the Static Linking section.

    -

    When python is extended with C code the python interpreter needs to be +

    When Python is extended with C code the Python interpreter needs to be informed about details of the new C functions that have been linked into -the executable. The code to do this is created by swig and is automatically +the executable. The code to do this is created by SWIG and is automatically called in the correct way when the module is dynamically loaded. However when the code is not dynamically loaded (because it is statically linked) -Then the initialization method for the module created by swig is not -called automatically. And the python interpreter has no idea that the -new swig C module exists. +Then the initialization method for the module created by SWIG is not +called automatically and the Python interpreter has no idea that the +new SWIG C module exists.

    -

    Before python3, one could simply call the init method created by swig +

    Before Python 3, one could simply call the init method created by SWIG which would have normally been called when the shared object was dynamically loaded. The specific name of this method is not given here because statically -linked modules are not encouraged with swig -(Static Linking). However one can find this -init function in the _wrap.c file generated by swig. +linked modules are not encouraged with SWIG +(Static Linking). However one can find this +init function in the C file generated by SWIG.

    -

    Assuming you have found the init function in the _wrap.c file and you -are still undeterred by what has been said so far, then there are two ways -to initialize the swig generated C module with the init method. Which way -you use depends on what version of python your module is being linked with. -Python2 and Python3 treat this init function differently. And they way -they treat it differently affects how the pure python module will be able to -locate the C module. +

    If you are really keen on static linking there are two ways +to initialize the SWIG generated C module with the init method. Which way +you use depends on what version of Python your module is being linked with. +Python 2 and Python 3 treat this init function differently. And the way +they treat it affects how the pure Python module will be able to +locate the C module.

    The details concerning this are covered completly in the documentation -for python itself. Links to the relavent sections follow: +for Python itself. Links to the relavent sections follow:

    -

    There are two keys things to understand. The first of which is that in -python2 the init() function returns void. But in python3, the init() funcion -returns a PyObject * which points to the new module. Secondly when -you call the init() method manually, you are the python importer. So, you -determine which package the C module will be located in. +

    There are two keys things to understand. The first is that in +Python 2 the init() function returns void. In Python 3 the init() function +returns a PyObject * which points to the new module. Secondly, when +you call the init() method manually, you are the Python importer. So, you +determine which package the C module will be located in.

    -

    So, if you are using python3 it is important that you follow what is -described in the python documentation linked above. In particular, you can't -simply call the init() function generated by swig and cast the PyObject -pointer it returns over the side. If you do then python3 still will have no -idea that your C module exists and the pure python half of your wrapper will -not be able to find it. You need to register your module with the python -interpreter as descibed in the python docs. +

    So, if you are using Python 3 it is important that you follow what is +described in the Python documentation linked above. In particular, you can't +simply call the init() function generated by SWIG and cast the PyObject +pointer it returns over the side. If you do then Python 3 will have no +idea that your C module exists and the pure Python half of your wrapper will +not be able to find it. You need to register your module with the Python +interpreter as described in the Python docs.

    -

    With python2 things are somewhat more simple. In this case the init function -returns void. And calling it will register your new C module as a global -module. The pure python part of the swig wrapper will be able to find it -because it tries both the package the pure python module is part of and -globally. If you wish to not have the statically linked module be a global -module then you will either need to refer to the python documentation on how -to do this (remember you are now the python importer) or use dynamic linking. +

    With Python 2 things are somewhat more simple. In this case the init function +returns void. Calling it will register your new C module as a global +module. The pure Python part of the SWIG wrapper will be able to find it +because it tries both the pure Python module it is part of and the global +module. If you wish not to have the statically linked module be a global +module then you will either need to refer to the Python documentation on how +to do this (remember you are now the Python importer) or use dynamic linking.

    36.12 Python 3 Support

    From 9c9a503a506e504c407537c38c24c8dfe517bb4d Mon Sep 17 00:00:00 2001 From: William S Fulton Date: Sun, 12 Jun 2016 00:20:51 +0100 Subject: [PATCH 5/7] Add more about Python module loading changes from Mike Romberg --- CHANGES.current | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/CHANGES.current b/CHANGES.current index 17574c807..d0ab95a5e 100644 --- a/CHANGES.current +++ b/CHANGES.current @@ -16,10 +16,29 @@ Version 3.0.10 (in progress) (assuming bar.foo was the main module). Every place _foo is imported now first tries it from the package where foo was found and if that fails tries _foo as a global module. - 2) The separate block of python code that injected code to pull in the attributes + 2) The separate block of Python code that injected code to pull in the attributes from _foo when -builtin is used made use of the -py3 switch to either do 'from ._foo import *' or "from _foo import *". This block of code no longer does this - and instead checks the python version at runtime to switch between the two syntaxes. + and instead checks the Python version at runtime to switch between the two syntaxes. + + In summary, swig-3.0.10 has been modified to ease the creation of wrapper modules + that can be fully made part of a Python package. SWIG no longer + assumes the dynamically linked C module is a global module. + The dynamic module can now be placed into either the same package as the pure Python + module or as a global module. Both locations are used by the Python wrapper to + locate the C module. + + However, this could cause a backwards incompatibility with some code + that was relying on the ability of "from package import _module" to + pull attributes out of the package directly. If your code populates a + module (which is also a package) with attributes that are SWIG + generated modules which were not loaded in a conventional way, + swig-3.0.8 and earlier may have worked due to 'from package import + _module' bypassing a real import and pulling your module in as an + attribute. This will no longer work. Since this is not a common (or + even recommended) practice, most folk should not be affected. + + *** POTENTIAL INCOMPATIBILITY *** 2016-05-31: wsfulton Fix #690 - Smart pointer to %ignored class doesn't expose inherited methods. From d9875c6579efc8a56132313704c69e627c990dac Mon Sep 17 00:00:00 2001 From: William S Fulton Date: Sun, 12 Jun 2016 00:23:15 +0100 Subject: [PATCH 6/7] swig-3.0.10 release --- ANNOUNCE | 2 +- CHANGES.current | 2 +- Doc/Manual/Sections.html | 2 +- README | 2 +- RELEASENOTES | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/ANNOUNCE b/ANNOUNCE index 71c4f2ec2..5fec2f40e 100644 --- a/ANNOUNCE +++ b/ANNOUNCE @@ -1,4 +1,4 @@ -*** ANNOUNCE: SWIG 3.0.10 (in progress) *** +*** ANNOUNCE: SWIG 3.0.10 (12 Jun 2016) *** http://www.swig.org diff --git a/CHANGES.current b/CHANGES.current index d0ab95a5e..b5b4567e2 100644 --- a/CHANGES.current +++ b/CHANGES.current @@ -2,7 +2,7 @@ Below are the changes for the current release. See the CHANGES file for changes in older releases. See the RELEASENOTES file for a summary of changes in each release. -Version 3.0.10 (in progress) +Version 3.0.10 (12 Jun 2016) ============================ 2016-06-06: mromberg diff --git a/Doc/Manual/Sections.html b/Doc/Manual/Sections.html index 8df5f33db..0adc60642 100644 --- a/Doc/Manual/Sections.html +++ b/Doc/Manual/Sections.html @@ -8,7 +8,7 @@

    SWIG-3.0 Documentation

    -Last update : SWIG-3.0.10 (in progress) +Last update : SWIG-3.0.10 (12 Jun 2016)

    Sections

    diff --git a/README b/README index 46f767338..8d1a5a231 100644 --- a/README +++ b/README @@ -1,6 +1,6 @@ SWIG (Simplified Wrapper and Interface Generator) -Version: 3.0.10 (in progress) +Version: 3.0.10 (12 Jun 2016) Tagline: SWIG is a compiler that integrates C and C++ with languages including Perl, Python, Tcl, Ruby, PHP, Java, C#, D, Go, Lua, diff --git a/RELEASENOTES b/RELEASENOTES index 9a04b93f3..080bb6066 100644 --- a/RELEASENOTES +++ b/RELEASENOTES @@ -8,7 +8,7 @@ Detailed release notes are available with the release and are also published on the SWIG web site at http://swig.org/release.html. SWIG-3.0.10 summary: -- Regression fixes for smart pointers and importing python modules. +- Regression fixes for smart pointers and importing Python modules. SWIG-3.0.9 summary: - Add support for Python's implicit namespace packages. From 84b06fa21b61c96eb7da49d73edb66e17de10821 Mon Sep 17 00:00:00 2001 From: William S Fulton Date: Sun, 12 Jun 2016 10:14:11 +0100 Subject: [PATCH 7/7] Bump version to 3.0.11 --- ANNOUNCE | 8 ++++---- CHANGES | 42 ++++++++++++++++++++++++++++++++++++++++ CHANGES.current | 41 +-------------------------------------- Doc/Manual/Sections.html | 2 +- README | 2 +- configure.ac | 2 +- 6 files changed, 50 insertions(+), 47 deletions(-) diff --git a/ANNOUNCE b/ANNOUNCE index 5fec2f40e..53c5bbc59 100644 --- a/ANNOUNCE +++ b/ANNOUNCE @@ -1,8 +1,8 @@ -*** ANNOUNCE: SWIG 3.0.10 (12 Jun 2016) *** +*** ANNOUNCE: SWIG 3.0.11 (in progress) *** http://www.swig.org -We're pleased to announce SWIG-3.0.10, the latest SWIG release. +We're pleased to announce SWIG-3.0.11, the latest SWIG release. What is SWIG? ============= @@ -27,11 +27,11 @@ Availability ============ The release is available for download on Sourceforge at - http://prdownloads.sourceforge.net/swig/swig-3.0.10.tar.gz + http://prdownloads.sourceforge.net/swig/swig-3.0.11.tar.gz A Windows version is also available at - http://prdownloads.sourceforge.net/swig/swigwin-3.0.10.zip + http://prdownloads.sourceforge.net/swig/swigwin-3.0.11.zip Please report problems with this release to the swig-devel mailing list, details at http://www.swig.org/mail.html. diff --git a/CHANGES b/CHANGES index d6e1d291c..0146ac7ac 100644 --- a/CHANGES +++ b/CHANGES @@ -3,6 +3,48 @@ SWIG (Simplified Wrapper and Interface Generator) See the CHANGES.current file for changes in the current version. See the RELEASENOTES file for a summary of changes in each release. +Version 3.0.10 (12 Jun 2016) +============================ + +2016-06-06: mromberg + [Python] Patch #698. Add support for -relativeimport for python 2.7, so -py3 is no + longer also required for relative import support. + +2016-06-05: mromberg + [Python] Patch #694 - Fix package import regressions introduced in swig-3.0.9. + + 1) The code in 3.0.9 did not fall back to 'import _foo' if 'import bar._foo' failed + (assuming bar.foo was the main module). Every place _foo is imported now first tries + it from the package where foo was found and if that fails tries _foo as a global module. + + 2) The separate block of Python code that injected code to pull in the attributes + from _foo when -builtin is used made use of the -py3 switch to either do + 'from ._foo import *' or "from _foo import *". This block of code no longer does this + and instead checks the Python version at runtime to switch between the two syntaxes. + + In summary, swig-3.0.10 has been modified to ease the creation of wrapper modules + that can be fully made part of a Python package. SWIG no longer + assumes the dynamically linked C module is a global module. + The dynamic module can now be placed into either the same package as the pure Python + module or as a global module. Both locations are used by the Python wrapper to + locate the C module. + + However, this could cause a backwards incompatibility with some code + that was relying on the ability of "from package import _module" to + pull attributes out of the package directly. If your code populates a + module (which is also a package) with attributes that are SWIG + generated modules which were not loaded in a conventional way, + swig-3.0.8 and earlier may have worked due to 'from package import + _module' bypassing a real import and pulling your module in as an + attribute. This will no longer work. Since this is not a common (or + even recommended) practice, most folk should not be affected. + + *** POTENTIAL INCOMPATIBILITY *** + +2016-05-31: wsfulton + Fix #690 - Smart pointer to %ignored class doesn't expose inherited methods. + Regression introduced in swig-3.0.9. + Version 3.0.9 (29 May 2016) =========================== diff --git a/CHANGES.current b/CHANGES.current index b5b4567e2..312343f56 100644 --- a/CHANGES.current +++ b/CHANGES.current @@ -2,44 +2,5 @@ Below are the changes for the current release. See the CHANGES file for changes in older releases. See the RELEASENOTES file for a summary of changes in each release. -Version 3.0.10 (12 Jun 2016) +Version 3.0.11 (in progress) ============================ - -2016-06-06: mromberg - [Python] Patch #698. Add support for -relativeimport for python 2.7, so -py3 is no - longer also required for relative import support. - -2016-06-05: mromberg - [Python] Patch #694 - Fix package import regressions introduced in swig-3.0.9. - - 1) The code in 3.0.9 did not fall back to 'import _foo' if 'import bar._foo' failed - (assuming bar.foo was the main module). Every place _foo is imported now first tries - it from the package where foo was found and if that fails tries _foo as a global module. - - 2) The separate block of Python code that injected code to pull in the attributes - from _foo when -builtin is used made use of the -py3 switch to either do - 'from ._foo import *' or "from _foo import *". This block of code no longer does this - and instead checks the Python version at runtime to switch between the two syntaxes. - - In summary, swig-3.0.10 has been modified to ease the creation of wrapper modules - that can be fully made part of a Python package. SWIG no longer - assumes the dynamically linked C module is a global module. - The dynamic module can now be placed into either the same package as the pure Python - module or as a global module. Both locations are used by the Python wrapper to - locate the C module. - - However, this could cause a backwards incompatibility with some code - that was relying on the ability of "from package import _module" to - pull attributes out of the package directly. If your code populates a - module (which is also a package) with attributes that are SWIG - generated modules which were not loaded in a conventional way, - swig-3.0.8 and earlier may have worked due to 'from package import - _module' bypassing a real import and pulling your module in as an - attribute. This will no longer work. Since this is not a common (or - even recommended) practice, most folk should not be affected. - - *** POTENTIAL INCOMPATIBILITY *** - -2016-05-31: wsfulton - Fix #690 - Smart pointer to %ignored class doesn't expose inherited methods. - Regression introduced in swig-3.0.9. diff --git a/Doc/Manual/Sections.html b/Doc/Manual/Sections.html index 0adc60642..8417bec15 100644 --- a/Doc/Manual/Sections.html +++ b/Doc/Manual/Sections.html @@ -8,7 +8,7 @@

    SWIG-3.0 Documentation

    -Last update : SWIG-3.0.10 (12 Jun 2016) +Last update : SWIG-3.0.11 (in progress)

    Sections

    diff --git a/README b/README index 8d1a5a231..3421b72bf 100644 --- a/README +++ b/README @@ -1,6 +1,6 @@ SWIG (Simplified Wrapper and Interface Generator) -Version: 3.0.10 (12 Jun 2016) +Version: 3.0.11 (in progress) Tagline: SWIG is a compiler that integrates C and C++ with languages including Perl, Python, Tcl, Ruby, PHP, Java, C#, D, Go, Lua, diff --git a/configure.ac b/configure.ac index a29443005..492d9cc1c 100644 --- a/configure.ac +++ b/configure.ac @@ -2,7 +2,7 @@ dnl Process this file with autoconf to produce a configure script. dnl The macros which aren't shipped with the autotools are stored in the dnl Tools/config directory in .m4 files. -AC_INIT([swig],[3.0.10],[http://www.swig.org]) +AC_INIT([swig],[3.0.11],[http://www.swig.org]) dnl NB: When this requirement is increased to 2.60 or later, AC_PROG_SED dnl definition below can be removed