Commit 82847eb2 authored by Torsten Landschoff's avatar Torsten Landschoff

Import upstream release 3.0.10 from swig-3.0.10.tar.gz

parent 59bf624c
......@@ -91,6 +91,9 @@ matrix:
- compiler: gcc
os: linux
env: SWIGLANG=python PY3=3 VER=3.5
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin VER=2.6
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin
......@@ -100,6 +103,9 @@ matrix:
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.5
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-builtin PY3=3 VER=3.5 SWIGOPTPY3=
- compiler: gcc
os: linux
env: SWIGLANG=python SWIG_FEATURES=-O
......
*** ANNOUNCE: SWIG 3.0.9 (29 May 2016) ***
*** ANNOUNCE: SWIG 3.0.10 (12 Jun 2016) ***
http://www.swig.org
We're pleased to announce SWIG-3.0.9, the latest SWIG release.
We're pleased to announce SWIG-3.0.10, 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.9.tar.gz
http://prdownloads.sourceforge.net/swig/swig-3.0.10.tar.gz
A Windows version is also available at
http://prdownloads.sourceforge.net/swig/swigwin-3.0.9.zip
http://prdownloads.sourceforge.net/swig/swigwin-3.0.10.zip
Please report problems with this release to the swig-devel mailing list,
details at http://www.swig.org/mail.html.
......
......@@ -3,6 +3,202 @@ 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.9 (29 May 2016)
===========================
2016-05-24: mromberg
[Python] Patch #612 - Add support for Python's implicit namespace packages.
2016-05-23: wsfulton
[Ruby] Fix #602 - Error handling regression of opaque pointers introduced
in swig-3.0.8 when C functions explicitly reset a pointer using 'DATA_PTR(self) = 0'.
An ObjectPreviouslyDeleted error was incorrectly thrown when the pointer was used
as a parameter.
2016-05-17: tamuratak
[Ruby] Patch #651 - Correct overloaded function error message when function is
using %newobject.
2016-05-17: aurelj
[Ruby] Patch #582 - add support for docstring option in %module()
2016-05-14: wsfulton
Fix #434 - Passing classes by value as parameters in director methods did not create
a copy of the argument leading to invalid memory accesses if the object was used
after the upcall into the target language. Passing arguments by value shouldn't give
rise to these sorts of memory problems and so the objects are now copied and ownership
of their lifetime is controlled by the target language.
2016-05-07: wsfulton
Fix #611. Fix assertion handling defaultargs when using %extend for a template
class and the extended methods contain default arguments.
2016-05-05: ejulian
[Python] Patch #617. Fix operator/ wrappers.
2016-05-02: wsfulton
Fix #669. Don't issue warning about ignoring base classes when the derived class is
itself ignored.
2016-04-18: ianlancetaylor
[Go] Fix use of goout typemap when calling base method by
forcing the "type" attribute to the value we need.
2016-04-17: ianlancetaylor
[Go] Fixes for Go 1.6: avoid returning Go pointers from
directors that return string values; add a trailing 0 byte
when treating Go string as C char*.
2016-04-06: smarchetto
[Scilab] #552 Make Scilab runtime keep track of pointer types
Instead of a Scilab pointer which has no type, SWIG Scilab maps a
pointer to a structure tlist containing the pointer adress and its type.
2016-04-02: ahnolds
[Python] Apply #598. Fix misleading error message when attempting to read a non-existent
attribute. The previous cryptic error message:
AttributeError: type object 'object' has no attribute '__getattr__'
is now replaced with one mentioning the attribute name, eg:
AttributeError: 'Foo' object has no attribute 'bar'
2016-04-02: derkuci
[Python] Patch #610 to fix #607.
Fix single arguments when using python -builtin -O with %feature("compactdefaultargs")
2016-03-31: wsfulton
Fixes #594. Fix assertion for some languages when wrapping a C++11 enum class that
is private in a class.
Also don't wrap private enums for a few languages that attempted to do so.
2016-03-31: wsfulton
[Java] unsigned long long marshalling improvements when a negative number
is passed from Java to C. A cast to signed long long in the C layer will now
result in the expected value. No change for positive numbers passed to C.
Fixes #623.
2016-03-22: alexwarg
[Lua] #398 Fix lua __getitem + inheritance
The new handling of classes in Lua (not merging methods into the derived classes)
breaks for classes that provide a __getitem function. The __getitem function
prevents method calls to any method defined in a base class. This fix calls
__getitem only if the member is not found using recursive lookup.
2016-03-18: ptomulik
[Python] #563 Stop generating unnecessary _swigconstant helpers.
2016-03-16: richardbeare
[R] #636 Add extra std::vector numeric types
2016-03-14: wsfulton
[Java] Add std_array.i for C++11 std::array support.
2016-03-12: wsfulton
[Java, C#, D] Fix static const char member variables wrappers with %javaconst(1)
%csconst(1) or %dmanifestconst.
This fixes the case when an integer is used as the initializer, such as:
struct W { static const char w = 100; };
Fix generated code parsing enum values using char escape sequences
when these values appear in the Java code (usually when using %javaconst(1))
such as:
enum X { x1 = '\n', x2 = '\1' };
Similarly for static const member char variables such as:
struct Y { static const char y = '\n'; }
Likewise for D and %dmanifestconstant. For C# and %csconst(1), char
values in C# are now hex escaped as C# doesn't support C octal escaping.
2016-03-11: wsfulton
[Java C#] Add support for treating C++ base classes as Java interfaces
instead of Java proxy classes. This enable some sort of support for
multiple inheritance. The implementation is in swiginterface.i and
provides additional macros (see Java.html for full documentation):
%interface(CTYPE)
%interface_impl(CTYPE)
%interface_custom("PROXY", "INTERFACE", CTYPE)
2016-03-01: wsfulton
Add rstrip encoder for use in %rename. This is like the strip encoder but
strips the symbol's suffix instead of the prefix. The example below
will rename SomeThingCls to SomeThing and AnotherThingCls to AnotherThing:
%rename("%(rstrip:[Cls])s") "";
class SomeThingCls {};
struct AnotherThingCls {};
2016-03-01: olly
Fix isfinite() check to work with GCC6. Fixes
https://github.com/swig/swig/issues/615 reported by jplesnik.
2016-02-17: olly
[Python] Add missing keywords 'as' and 'with' to pythonkw.swg.
2016-02-07: kwwette
[Octave] recognise various unary functions
* Use __float__() for numeric conversions, e.g. when calling double()
* Map various unary functions, e.g. abs() to __abs__(), see full list
in section 32.3.10 of manual; only available in Octave 3.8.0 or later
2016-02-07: kwwette
[Octave] export function swig_octave_prereq() for testing Octave version
2016-02-06: pjohangustavsson
[C#] Fix duplicate symbol problems when linking the source generated
from multiple SWIG modules into one shared library for the -namespace
option. The namespace is now mangled into the global PInvoke function
names.
*** POTENTIAL INCOMPATIBILITY ***
2016-01-27: ahnolds
[Python] Added support for differentiating between Python Bytes
and Unicode objects using by defining SWIG_PYTHON_STRICT_BYTE_CHAR
and SWIG_PYTHON_STRICT_UNICODE_WCHAR.
2016-01-27: steeve
[Go] Ensure structs are properly packed between gc and GCC/clang.
2016-01-25: ahnolds
[Python] Support the full Python test suite in -classic mode
* Convert long/unsigned long/long long/unsigned long long to PyInt
rather than PyLong when possible. Certain python functions like
len() require a PyInt when operating on old-style classes.
* Add support for static methods in classic mode, including support
for pythonappend, pythonprepend, and docstrings.
* Removing the use of __swig_getmethods__ for static member methods
since they will always be found by the standard argument lookup
* Fix a bug where the wrong type of exception was caught when
checking for new-style class support
2016-01-23: ahnolds
[Go] Enable support for the Go test-suite on OSX:
* The linker on OSX requires that all symbols (even weak symbols)
are defined at link time. Because the function _cgo_topofstack is
only defined starting in Go version 1.4, we explicitly mark it as
undefined for older versions of Go on OSX.
* Avoid writing empty swigargs structs, since empty structs are not
allowed in extern "C" blocks.
2016-01-12: olly
[Javascript] Look for "nodejs" as well as "node", as it's packaged
as the former on Debian.
2016-01-12: olly
[Javascript] For v8 >= 4.3.0, use V8_MAJOR_VERSION.
Fixes https://github.com/swig/swig/issues/561.
2016-01-10: ahnolds
Improved size_t and ptrdiff_t typemaps to support large values
on platforms where sizeof(size_t) > sizeof(unsigned long) and
sizeof(ptrdiff_t) > sizeof(long).
Version 3.0.8 (31 Dec 2015)
===========================
......@@ -587,7 +783,7 @@ Version 3.0.3 (30 Dec 2014)
2014-10-21: wsfulton
Fix issue #242 - Use of the "kwargs" feature no longer automatically turns on the
"compactdefaultargs" feature if the target language does not support kwargs.
Only Java and Ruby support kwargs, so this affects all the other languages.
This change affects all languages except Python and Ruby.
*** POTENTIAL INCOMPATIBILITY ***
......
This diff is collapsed.
......@@ -1595,6 +1595,13 @@
<li><a href="Python.html#Python_absimport">Enforcing absolute import semantics</a>
<li><a href="Python.html#Python_importfrominit">Importing from __init__.py</a>
<li><a href="Python.html#Python_implicit_namespace_packages">Implicit Namespace Packages</a>
<li><a href="Python.html#Python_package_search">Searching for the wrapper module</a>
<ul>
<li><a href="Python.html#Python_package_search_both_package_modules">Both modules in the same package</a>
<li><a href="Python.html#Python_package_search_wrapper_split">Split modules</a>
<li><a href="Python.html#Python_package_search_both_global_modules">Both modules are global</a>
<li><a href="Python.html#Python_package_search_static">Statically linked C modules</a>
</ul>
</ul>
<li><a href="Python.html#Python_python3support">Python 3 Support</a>
<ul>
......
......@@ -117,6 +117,13 @@
<li><a href="#Python_absimport">Enforcing absolute import semantics</a>
<li><a href="#Python_importfrominit">Importing from __init__.py</a>
<li><a href="#Python_implicit_namespace_packages">Implicit Namespace Packages</a>
<li><a href="#Python_package_search">Searching for the wrapper module</a>
<ul>
<li><a href="#Python_package_search_both_package_modules">Both modules in the same package</a>
<li><a href="#Python_package_search_wrapper_split">Split modules</a>
<li><a href="#Python_package_search_both_global_modules">Both modules are global</a>
<li><a href="#Python_package_search_static">Statically linked C modules</a>
</ul>
</ul>
<li><a href="#Python_python3support">Python 3 Support</a>
<ul>
......@@ -5521,6 +5528,23 @@ They should be created by other means. Both files (module <tt>*.py</tt> and
directories in order to obtain a desirable package/module hierarchy.
</p>
<p>
Python3 adds another option for packages with
<a href="https://www.python.org/dev/peps/pep-0420/">PEP 0420</a> (implicit
namespace packages). Implicit namespace packages no longer use
__init__.py files. SWIG generated Python modules support implicit
namespace packages. See
<a href="#Python_implicit_namespace_packages">36.11.5 Implicit Namespace
Packages</a> for more information.
</p>
<p>
If you place a SWIG generated module into a Python package then there
are details concerning the way SWIG
<a href="#Python_package_search">searches for the wrapper module</a>
that you may want to familiarize yourself with.
</p>
<p>The way Python defines its modules and packages impacts SWIG users. Some
users may need to use special features such as the <tt>package</tt> option in the
<tt>%module</tt> directive or import related command line options. These are
......@@ -5680,8 +5704,9 @@ class M2(pkg2.mod3.M3): pass
<p>By default, SWIG would generate <tt>mod2.py</tt> proxy file with
<tt>import</tt> directive as in point 1. This can be changed with the
<tt>-relativeimport</tt> command line option. The <tt>-relativeimport</tt> instructs
SWIG to organize imports as in point 2 (for Python 2.x) or as in point 4 (for
Python 3, that is when the -py3 command line option is enabled). In short, if you have
SWIG to organize imports as in point 2 (for Python < 2.7.0) or as in point 4
for Python 2.7.0 and newer. This is a check done at the time the module is
imported. In short, if you have
<tt>mod2.i</tt> and <tt>mod3.i</tt> as above, then without
<tt>-relativeimport</tt> SWIG will write</p>
......@@ -5695,22 +5720,17 @@ import pkg1.pkg2.mod3
write</p>
<div class="targetlang">
<pre>
import pkg2.mod3
</pre>
</div>
<p>if <tt>-py3</tt> is not used, or</p>
<div class="targetlang">
<pre>
from . import pkg2
import pkg1.pkg2.mod3
<pre>
from sys import version_info
if version_info &gt;= (2, 7, 0):
from . import pkg2
import pkg1.pkg2.mod3
else:
import pkg2.mod3
del version_info
</pre>
</div>
<p>when <tt>-py3</tt> is used.</p>
<p>You should avoid using relative imports and use absolute ones whenever
possible. There are some cases, however, when relative imports may be
necessary. The first example is, when some (legacy) Python code refers entities
......@@ -5943,6 +5963,181 @@ zipimporter requires python-3.5.1 or newer to work with subpackages.
<b>Compatibility Note:</b> Support for implicit namespace packages was added in SWIG-3.0.9.
</p>
<H3><a name="Python_package_search">36.11.6 Searching for the wrapper module</a></H3>
<p>
When SWIG creates wrappers from an interface file, say foo.i, two Python modules are
created. There is a pure Python module module (foo.py) and C/C++ code which is
built and linked into a dynamically (or statically) loaded module _foo
(see the <a href="Python.html#Python_nn3">Preliminaries section</a> for details). So, the interface
file really defines two Python modules. How these two modules are loaded is
covered next.
</p>
<p>
The pure Python module needs to load the C/C++ module in order to link
to the wrapped C/C++ methods. To do this it must make some assumptions
about what package the C/C++ module may be located in. The approach the
pure Python module uses to find the C/C++ module is as follows:
</p>
<ol>
<li><p>The pure Python module, foo.py, tries to load the C/C++ module, _foo, from the same package foo.py is
located in. The package name is determined from the <tt>__name__</tt>
attribute given to foo.py by the Python loader that imported
foo.py. If foo.py is not in a package then _foo is loaded
as a global module.</p>
</li>
<li><p>If the above import of _foo results in an ImportError
being thrown, then foo.py makes a final attempt to load _foo
as a global module.</p>
</li>
</ol>
<p>
As an example suppose foo.i is compiled into foo.py and _foo.so. Assuming
/dir is on PYTHONPATH, then the two modules can be installed and used in the
following ways:
</p>
<H4><a name="Python_package_search_both_package_modules">36.11.6.1 Both modules in the same package</a></H4>
<p>Both modules are in one package:</p>
<div class="diagram">
<pre>
/dir/package/foo.py
/dir/package/__init__.py
/dir/package/_foo.so
</pre>
</div>
<p>And imported with</p>
<div class="diagram">
<pre>
from package import foo
</pre>
</div>
<H4><a name="Python_package_search_wrapper_split">36.11.6.2 Split modules</a></H4>
<p>The pure python module is in a package and the C/C++ module is global:</p>
<div class="diagram">
<pre>
/dir/package/foo.py
/dir/package/__init__.py
/dir/_foo.so
</pre>
</div>
<p>And imported with</p>
<div class="diagram">
<pre>
from package import foo
</pre>
</div>
<H4><a name="Python_package_search_both_global_modules">36.11.6.3 Both modules are global</a></H4>
<p>Both modules are global:</p>
<div class="diagram">
<pre>
/dir/foo.py
/dir/_foo.so
</pre>
</div>
<p>And imported with</p>
<div class="diagram">
<pre>
import foo
</pre>
</div>
<p>
If _foo is statically linked into an embedded Python interpreter, then it may or
may not be in a Python package. This depends in the exact way the module was
loaded statically. The above search order will still be used for statically
loaded modules. So, one may place the module either globally or in a package
as desired.
</p>
<H4><a name="Python_package_search_static">36.11.6.4 Statically linked C modules</a></H4>
<p>It is strongly recommended to use dynamically linked modules for the C
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.
Please also see the <a href="Python.html#Python_nn8">Static Linking</a> section.
</p>
<p>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.
</p>
<p>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
(<a href="Python.html#Python_nn8">Static Linking</a>). However one can find this
init function in the C file generated by SWIG.
</p>
<p>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.
</p>
<p>The details concerning this are covered completly in the documentation
for Python itself. Links to the relavent sections follow:
</p>
<ul>
<li><a href="https://docs.python.org/2/extending/extending.html#methodtable">Extending in python2</a></li>
<li><a href="https://docs.python.org/3.6/extending/extending.html#the-module-s-method-table-and-initialization-function">Extending in python3</a></li>
</ul>
<p>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.
</p>
<p>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.
</p>
<p>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 <b>global</b>
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.
</p>
<H2><a name="Python_python3support">36.12 Python 3 Support</a></H2>
......
This diff is collapsed.
......@@ -8,7 +8,7 @@
<H1><a name="Sections">SWIG-3.0 Documentation</a></H1>
<p>
Last update : SWIG-3.0.9 (29 May 2016)
Last update : SWIG-3.0.10 (12 Jun 2016)
</p>
<H2><a name="Sections_Sections">Sections</a></H2>
......
......@@ -327,11 +327,11 @@ else
endif
PYTHON_SO = @PYTHON_SO@
# SWIG option for Python
# SWIG option for Python3
ifeq (,$(PY3))
SWIGPYTHON = $(SWIG) -python
SWIGOPTPY3 =
else
SWIGPYTHON = $(SWIG) -python -py3
SWIGOPTPY3 = -py3
endif
PEP8 = @PEP8@
......@@ -342,7 +342,7 @@ PEP8_FLAGS = --ignore=E402,E501,E30,W291,W391
# ----------------------------------------------------------------
python: $(SRCDIR_SRCS)
$(SWIGPYTHON) $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(SWIG) -python $(SWIGOPTPY3) $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(CC) -c $(CCSHARED) $(CPPFLAGS) $(CFLAGS) $(ISRCS) $(SRCDIR_SRCS) $(INCLUDES) $(PYTHON_INCLUDE)
$(LDSHARED) $(CFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(PYTHON_DLNK) $(LIBS) -o $(LIBPREFIX)_$(TARGET)$(PYTHON_SO)
......@@ -351,7 +351,7 @@ python: $(SRCDIR_SRCS)
# -----------------------------------------------------------------
python_cpp: $(SRCDIR_SRCS)
$(SWIGPYTHON) -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(SWIG) -python $(SWIGOPTPY3) -c++ $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(CXX) -c $(CCSHARED) $(CPPFLAGS) $(CXXFLAGS) $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) $(INCLUDES) $(PYTHON_INCLUDE)
$(CXXSHARED) $(CXXFLAGS) $(LDFLAGS) $(OBJS) $(IOBJS) $(PYTHON_DLNK) $(LIBS) $(CPP_DLLIBS) -o $(LIBPREFIX)_$(TARGET)$(PYTHON_SO)
......@@ -367,12 +367,12 @@ TKINTER =
PYTHON_LIBOPTS = $(PYTHON_LINK) @LIBS@ $(TKINTER) $(SYSLIBS)
python_static: $(SRCDIR_SRCS)
$(SWIGPYTHON) -lembed.i $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(SWIG) -python $(SWIGOPTPY3) -lembed.i $(SWIGOPT) -o $(ISRCS) $(INTERFACEPATH)
$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) @LINKFORSHARED@ $(ISRCS) $(SRCDIR_SRCS) $(INCLUDES) \
$(PYTHON_INCLUDE) $(LIBS) -L$(PYTHON_LIB) $(PYTHON_LIBOPTS) -o $(TARGET)
python_static_cpp: $(SRCDIR_SRCS)
$(SWIGPYTHON) -c++ -lembed.i $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(SWIG) -python $(SWIGOPTPY3) -c++ -lembed.i $(SWIGOPT) -o $(ICXXSRCS) $(INTERFACEPATH)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) $(ICXXSRCS) $(SRCDIR_SRCS) $(SRCDIR_CXXSRCS) $(INCLUDES) \
$(PYTHON_INCLUDE) $(LIBS) -L$(PYTHON_LIB) $(PYTHON_LIBOPTS) -o $(TARGET)
......
......@@ -10,11 +10,15 @@ import_packages_subdirs = \
from_init3 \
relativeimport1 \
relativeimport2 \
relativeimport3
relativeimport3 \
split_modules \
namespace_pkg
check: build
if test "x$(SRCDIR)" != x; then \
for file in `cd $(SRCDIR) && find . -type f -name __init__.py`; do \
for file in `cd $(SRCDIR) && find . -type f -name "*.py"`; do \
mkdir -p `dirname $$file`; \
cp "${SRCDIR}$$file" "$$file" || exit 1; \
done; \
fi; \
......@@ -35,7 +39,7 @@ static:
clean:
$(MAKE) -f $(TOP)/Makefile SRCDIR='$(SRCDIR)' python_clean
if test "x$(SRCDIR)" != x; then \
for file in `cd $(SRCDIR) && find . -type f -name __init__.py`; do \
for file in `cd $(SRCDIR) && find . -type f -name "*.py"`; do \
rm -f "$$file" || exit 1; \
done; \
fi; \
......
import sys
import os
import shutil
import zipfile
def copyMods():
dirs = ['path1', 'path2', 'path3']
# Clean out any old package paths
for d in dirs:
if os.path.isdir(d):
shutil.rmtree(d)
for d in dirs:
os.mkdir(d)
os.mkdir(os.path.join(d, 'brave'))
shutil.copy('robin.py', os.path.join('path1', 'brave'))
os.system('cp _robin.* ' + os.path.join('path1', 'brave'))
shutil.copy('robin.py', os.path.join('path2', 'brave'))
os.system('cp _robin.* ' + os.path.join('path3', 'brave'))
mkzip()
def mkzip():
zf = zipfile.ZipFile("path4.zip", "w")
zf.writestr("brave/", b'')
zf.write('robin.py', 'brave/robin.py')
zf.close()
def main():
copyMods()
# Run each test with a separate interpreter
os.system(sys.executable + " nonpkg.py")
os.system(sys.executable + " normal.py")
os.system(sys.executable + " split.py")
os.system(sys.executable + " zipsplit.py")
if __name__ == "__main__":
main()
# These examples rely on namespace packages. Don't
# run them for old python interpreters.
import sys
if sys.version_info < (3, 3, 0):
sys.exit(0)
import os
import shutil
import zipfile
def copyMods():
dirs = ['path1', 'path2', 'path3']
# Clean out any old package paths
for d in dirs:
if os.path.isdir(d):
shutil.rmtree(d)
import os.path
for d in dirs:
os.mkdir(d)
os.mkdir(os.path.join(d, 'brave'))
testname = os.path.basename(os.path.dirname(os.path.abspath(__file__)))
print "Testing " + testname + " - namespace packages"
shutil.copy('robin.py', os.path.join('path1', 'brave'))
os.system('cp _robin.* ' + os.path.join('path1', 'brave'))
shutil.copy('robin.py', os.path.join('path2', 'brave'))
os.system('cp _robin.* ' + os.path.join('path3', 'brave'))
mkzip()
def mkzip():
zf = zipfile.ZipFile("path4.zip", "w")
zf.writestr("brave/", b'')
zf.write('robin.py', 'brave/robin.py')
zf.close()
def main():
copyMods()
if sys.version_info < (3, 3, 0):
print " Not importing nstest as Python version is < 3.3"
sys.exit(0)
# Run each test with a separate interpreter
os.system(sys.executable + " nonpkg.py")
os.system(sys.executable + " normal.py")
os.system(sys.executable + " split.py")
os.system(sys.executable + " zipsplit.py")
import nstest