2016-12-16 14:00:46 +00:00
|
|
|
import pytest
|
Implement py::init_alias<>() constructors
This commit adds support for forcing alias type initialization by
defining constructors with `py::init_alias<arg1, arg2>()` instead of
`py::init<arg1, arg2>()`. Currently py::init<> only results in Alias
initialization if the type is extended in python, or the given
arguments can't be used to construct the base type, but can be used to
construct the alias. py::init_alias<>, in contrast, always invokes the
constructor of the alias type.
It looks like this was already the intention of
`py::detail::init_alias`, which was forward-declared in
86d825f3302701d81414ddd3d38bcd09433076bc, but was apparently never
finished: despite the existance of a .def method accepting it, the
`detail::init_alias` class isn't actually defined anywhere.
This commit completes the feature (or possibly repurposes it), allowing
declaration of classes that will always initialize the trampoline which
is (as I argued in #397) sometimes useful.
2016-09-09 06:42:51 +00:00
|
|
|
|
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
def test_alias_delay_initialization1(capture):
|
2016-12-16 14:00:46 +00:00
|
|
|
"""
|
|
|
|
A only initializes its trampoline class when we inherit from it; if we just
|
|
|
|
create and use an A instance directly, the trampoline initialization is
|
|
|
|
bypassed and we only initialize an A() instead (for performance reasons).
|
2016-11-20 20:21:54 +00:00
|
|
|
"""
|
Implement py::init_alias<>() constructors
This commit adds support for forcing alias type initialization by
defining constructors with `py::init_alias<arg1, arg2>()` instead of
`py::init<arg1, arg2>()`. Currently py::init<> only results in Alias
initialization if the type is extended in python, or the given
arguments can't be used to construct the base type, but can be used to
construct the alias. py::init_alias<>, in contrast, always invokes the
constructor of the alias type.
It looks like this was already the intention of
`py::detail::init_alias`, which was forward-declared in
86d825f3302701d81414ddd3d38bcd09433076bc, but was apparently never
finished: despite the existance of a .def method accepting it, the
`detail::init_alias` class isn't actually defined anywhere.
This commit completes the feature (or possibly repurposes it), allowing
declaration of classes that will always initialize the trampoline which
is (as I argued in #397) sometimes useful.
2016-09-09 06:42:51 +00:00
|
|
|
from pybind11_tests import A, call_f
|
|
|
|
|
|
|
|
class B(A):
|
|
|
|
def __init__(self):
|
|
|
|
super(B, self).__init__()
|
|
|
|
|
|
|
|
def f(self):
|
|
|
|
print("In python f()")
|
|
|
|
|
|
|
|
# C++ version
|
|
|
|
with capture:
|
|
|
|
a = A()
|
|
|
|
call_f(a)
|
|
|
|
del a
|
2016-12-16 14:00:46 +00:00
|
|
|
pytest.gc_collect()
|
Implement py::init_alias<>() constructors
This commit adds support for forcing alias type initialization by
defining constructors with `py::init_alias<arg1, arg2>()` instead of
`py::init<arg1, arg2>()`. Currently py::init<> only results in Alias
initialization if the type is extended in python, or the given
arguments can't be used to construct the base type, but can be used to
construct the alias. py::init_alias<>, in contrast, always invokes the
constructor of the alias type.
It looks like this was already the intention of
`py::detail::init_alias`, which was forward-declared in
86d825f3302701d81414ddd3d38bcd09433076bc, but was apparently never
finished: despite the existance of a .def method accepting it, the
`detail::init_alias` class isn't actually defined anywhere.
This commit completes the feature (or possibly repurposes it), allowing
declaration of classes that will always initialize the trampoline which
is (as I argued in #397) sometimes useful.
2016-09-09 06:42:51 +00:00
|
|
|
assert capture == "A.f()"
|
|
|
|
|
|
|
|
# Python version
|
|
|
|
with capture:
|
|
|
|
b = B()
|
|
|
|
call_f(b)
|
|
|
|
del b
|
2016-12-16 14:00:46 +00:00
|
|
|
pytest.gc_collect()
|
Implement py::init_alias<>() constructors
This commit adds support for forcing alias type initialization by
defining constructors with `py::init_alias<arg1, arg2>()` instead of
`py::init<arg1, arg2>()`. Currently py::init<> only results in Alias
initialization if the type is extended in python, or the given
arguments can't be used to construct the base type, but can be used to
construct the alias. py::init_alias<>, in contrast, always invokes the
constructor of the alias type.
It looks like this was already the intention of
`py::detail::init_alias`, which was forward-declared in
86d825f3302701d81414ddd3d38bcd09433076bc, but was apparently never
finished: despite the existance of a .def method accepting it, the
`detail::init_alias` class isn't actually defined anywhere.
This commit completes the feature (or possibly repurposes it), allowing
declaration of classes that will always initialize the trampoline which
is (as I argued in #397) sometimes useful.
2016-09-09 06:42:51 +00:00
|
|
|
assert capture == """
|
|
|
|
PyA.PyA()
|
|
|
|
PyA.f()
|
|
|
|
In python f()
|
|
|
|
PyA.~PyA()
|
|
|
|
"""
|
|
|
|
|
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
def test_alias_delay_initialization2(capture):
|
|
|
|
"""A2, unlike the above, is configured to always initialize the alias; while
|
|
|
|
the extra initialization and extra class layer has small virtual dispatch
|
|
|
|
performance penalty, it also allows us to do more things with the trampoline
|
|
|
|
class such as defining local variables and performing construction/destruction.
|
|
|
|
"""
|
|
|
|
from pybind11_tests import A2, call_f
|
Implement py::init_alias<>() constructors
This commit adds support for forcing alias type initialization by
defining constructors with `py::init_alias<arg1, arg2>()` instead of
`py::init<arg1, arg2>()`. Currently py::init<> only results in Alias
initialization if the type is extended in python, or the given
arguments can't be used to construct the base type, but can be used to
construct the alias. py::init_alias<>, in contrast, always invokes the
constructor of the alias type.
It looks like this was already the intention of
`py::detail::init_alias`, which was forward-declared in
86d825f3302701d81414ddd3d38bcd09433076bc, but was apparently never
finished: despite the existance of a .def method accepting it, the
`detail::init_alias` class isn't actually defined anywhere.
This commit completes the feature (or possibly repurposes it), allowing
declaration of classes that will always initialize the trampoline which
is (as I argued in #397) sometimes useful.
2016-09-09 06:42:51 +00:00
|
|
|
|
|
|
|
class B2(A2):
|
|
|
|
def __init__(self):
|
|
|
|
super(B2, self).__init__()
|
|
|
|
|
|
|
|
def f(self):
|
|
|
|
print("In python B2.f()")
|
|
|
|
|
|
|
|
# No python subclass version
|
|
|
|
with capture:
|
|
|
|
a2 = A2()
|
|
|
|
call_f(a2)
|
|
|
|
del a2
|
2016-12-16 14:00:46 +00:00
|
|
|
pytest.gc_collect()
|
Implement py::init_alias<>() constructors
This commit adds support for forcing alias type initialization by
defining constructors with `py::init_alias<arg1, arg2>()` instead of
`py::init<arg1, arg2>()`. Currently py::init<> only results in Alias
initialization if the type is extended in python, or the given
arguments can't be used to construct the base type, but can be used to
construct the alias. py::init_alias<>, in contrast, always invokes the
constructor of the alias type.
It looks like this was already the intention of
`py::detail::init_alias`, which was forward-declared in
86d825f3302701d81414ddd3d38bcd09433076bc, but was apparently never
finished: despite the existance of a .def method accepting it, the
`detail::init_alias` class isn't actually defined anywhere.
This commit completes the feature (or possibly repurposes it), allowing
declaration of classes that will always initialize the trampoline which
is (as I argued in #397) sometimes useful.
2016-09-09 06:42:51 +00:00
|
|
|
assert capture == """
|
|
|
|
PyA2.PyA2()
|
|
|
|
PyA2.f()
|
|
|
|
A2.f()
|
|
|
|
PyA2.~PyA2()
|
|
|
|
"""
|
|
|
|
|
|
|
|
# Python subclass version
|
|
|
|
with capture:
|
|
|
|
b2 = B2()
|
|
|
|
call_f(b2)
|
|
|
|
del b2
|
2016-12-16 14:00:46 +00:00
|
|
|
pytest.gc_collect()
|
Implement py::init_alias<>() constructors
This commit adds support for forcing alias type initialization by
defining constructors with `py::init_alias<arg1, arg2>()` instead of
`py::init<arg1, arg2>()`. Currently py::init<> only results in Alias
initialization if the type is extended in python, or the given
arguments can't be used to construct the base type, but can be used to
construct the alias. py::init_alias<>, in contrast, always invokes the
constructor of the alias type.
It looks like this was already the intention of
`py::detail::init_alias`, which was forward-declared in
86d825f3302701d81414ddd3d38bcd09433076bc, but was apparently never
finished: despite the existance of a .def method accepting it, the
`detail::init_alias` class isn't actually defined anywhere.
This commit completes the feature (or possibly repurposes it), allowing
declaration of classes that will always initialize the trampoline which
is (as I argued in #397) sometimes useful.
2016-09-09 06:42:51 +00:00
|
|
|
assert capture == """
|
|
|
|
PyA2.PyA2()
|
|
|
|
PyA2.f()
|
|
|
|
In python B2.f()
|
|
|
|
PyA2.~PyA2()
|
|
|
|
"""
|