diff --git a/build/bpl_static.dsp b/build/bpl_static.dsp new file mode 100644 index 00000000..60f56070 --- /dev/null +++ b/build/bpl_static.dsp @@ -0,0 +1,216 @@ +# Microsoft Developer Studio Project File - Name="bpl_static" - Package Owner=<4> +# Microsoft Developer Studio Generated Build File, Format Version 6.00 +# ** DO NOT EDIT ** + +# TARGTYPE "Win32 (x86) Static Library" 0x0104 + +CFG=bpl_static - Win32 Debug +!MESSAGE This is not a valid makefile. To build this project using NMAKE, +!MESSAGE use the Export Makefile command and run +!MESSAGE +!MESSAGE NMAKE /f "bpl_static.mak". +!MESSAGE +!MESSAGE You can specify a configuration when running NMAKE +!MESSAGE by defining the macro CFG on the command line. For example: +!MESSAGE +!MESSAGE NMAKE /f "bpl_static.mak" CFG="bpl_static - Win32 Debug" +!MESSAGE +!MESSAGE Possible choices for configuration are: +!MESSAGE +!MESSAGE "bpl_static - Win32 Release" (based on "Win32 (x86) Static Library") +!MESSAGE "bpl_static - Win32 Debug" (based on "Win32 (x86) Static Library") +!MESSAGE + +# Begin Project +# PROP AllowPerConfigDependencies 0 +# PROP Scc_ProjName "" +# PROP Scc_LocalPath "" +CPP=cl.exe +RSC=rc.exe + +!IF "$(CFG)" == "bpl_static - Win32 Release" + +# PROP BASE Use_MFC 0 +# PROP BASE Use_Debug_Libraries 0 +# PROP BASE Output_Dir "Release" +# PROP BASE Intermediate_Dir "Release" +# PROP BASE Target_Dir "" +# PROP Use_MFC 0 +# PROP Use_Debug_Libraries 0 +# PROP Output_Dir "Release" +# PROP Intermediate_Dir "Release" +# PROP Target_Dir "" +# ADD BASE CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_MBCS" /D "_LIB" /YX /FD /c +# ADD CPP /nologo /MD /W4 /WX /GR /GX /O2 /I "..\..\.." /I "c:\tools\python\include" /D "WIN32" /D "NDEBUG" /D "_MBCS" /D "_LIB" /FR /YX /FD /c +# ADD BASE RSC /l 0x409 /d "NDEBUG" +# ADD RSC /l 0x409 /d "NDEBUG" +BSC32=bscmake.exe +# ADD BASE BSC32 /nologo +# ADD BSC32 /nologo +LIB32=link.exe -lib +# ADD BASE LIB32 /nologo +# ADD LIB32 /nologo + +!ELSEIF "$(CFG)" == "bpl_static - Win32 Debug" + +# PROP BASE Use_MFC 0 +# PROP BASE Use_Debug_Libraries 1 +# PROP BASE Output_Dir "Debug" +# PROP BASE Intermediate_Dir "Debug" +# PROP BASE Target_Dir "" +# PROP Use_MFC 0 +# PROP Use_Debug_Libraries 1 +# PROP Output_Dir "Debug" +# PROP Intermediate_Dir "Debug" +# PROP Target_Dir "" +# ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_MBCS" /D "_LIB" /YX /FD /GZ /c +# ADD CPP /nologo /MDd /W4 /WX /Gm /GR /GX /ZI /Od /I "..\..\.." /I "c:\tools\python\include" /D "WIN32" /D "_DEBUG" /D "_MBCS" /D "_LIB" /FR /YX /FD /GZ /c +# ADD BASE RSC /l 0x409 /d "_DEBUG" +# ADD RSC /l 0x409 /d "_DEBUG" +BSC32=bscmake.exe +# ADD BASE BSC32 /nologo +# ADD BSC32 /nologo +LIB32=link.exe -lib +# ADD BASE LIB32 /nologo +# ADD LIB32 /nologo + +!ENDIF + +# Begin Target + +# Name "bpl_static - Win32 Release" +# Name "bpl_static - Win32 Debug" +# Begin Group "Source Files" + +# PROP Default_Filter "cpp;c;cxx;rc;def;r;odl;idl;hpj;bat" +# Begin Source File + +SOURCE=..\src\classes.cpp +# ADD CPP /W3 +# End Source File +# Begin Source File + +SOURCE=..\src\conversions.cpp +# ADD CPP /W3 +# End Source File +# Begin Source File + +SOURCE=..\src\extension_class.cpp +# ADD CPP /W3 +# End Source File +# Begin Source File + +SOURCE=..\src\functions.cpp +# ADD CPP /W3 +# End Source File +# Begin Source File + +SOURCE=..\src\init_function.cpp +# ADD CPP /W3 +# End Source File +# Begin Source File + +SOURCE=..\src\module_builder.cpp +# ADD CPP /W3 +# End Source File +# Begin Source File + +SOURCE=..\src\objects.cpp +# ADD CPP /W3 +# End Source File +# Begin Source File + +SOURCE=..\src\types.cpp +# ADD CPP /W3 +# End Source File +# End Group +# Begin Group "Header Files" + +# PROP Default_Filter "h;hpp;hxx;hm;inl" +# Begin Source File + +SOURCE=..\..\..\boost\python\detail\base_object.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\callback.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\caller.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\detail\cast.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\class_builder.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\classes.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\detail\config.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\conversions.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\errors.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\detail\extension_class.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\detail\functions.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\detail\init_function.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\module_builder.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\detail\none.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\objects.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\operators.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\reference.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\detail\signatures.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\detail\singleton.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\detail\types.hpp +# End Source File +# Begin Source File + +SOURCE=..\..\..\boost\python\detail\wrap_python.hpp +# End Source File +# End Group +# End Target +# End Project diff --git a/build/build.dsw b/build/build.dsw new file mode 100644 index 00000000..f4ee1a11 --- /dev/null +++ b/build/build.dsw @@ -0,0 +1,74 @@ +Microsoft Developer Studio Workspace File, Format Version 6.00 +# WARNING: DO NOT EDIT OR DELETE THIS WORKSPACE FILE! + +############################################################################### + +Project: "bpl_static"=.\bpl_static.dsp - Package Owner=<4> + +Package=<5> +{{{ +}}} + +Package=<4> +{{{ +}}} + +############################################################################### + +Project: "example1"=.\example1\example1.dsp - Package Owner=<4> + +Package=<5> +{{{ +}}} + +Package=<4> +{{{ + Begin Project Dependency + Project_Dep_Name bpl_static + End Project Dependency +}}} + +############################################################################### + +Project: "rwgk1"=.\rwgk1\rwgk1.dsp - Package Owner=<4> + +Package=<5> +{{{ +}}} + +Package=<4> +{{{ + Begin Project Dependency + Project_Dep_Name bpl_static + End Project Dependency +}}} + +############################################################################### + +Project: "test"=.\test\test.dsp - Package Owner=<4> + +Package=<5> +{{{ +}}} + +Package=<4> +{{{ + Begin Project Dependency + Project_Dep_Name bpl_static + End Project Dependency +}}} + +############################################################################### + +Global: + +Package=<5> +{{{ +}}} + +Package=<3> +{{{ +}}} + +############################################################################### + diff --git a/build/build.opt b/build/build.opt new file mode 100644 index 00000000..a650cf1f Binary files /dev/null and b/build/build.opt differ diff --git a/build/como.mak b/build/como.mak new file mode 100644 index 00000000..5a9920d8 --- /dev/null +++ b/build/como.mak @@ -0,0 +1,51 @@ +LIBSRC = \ + classes.cpp \ + conversions.cpp \ + extension_class.cpp \ + functions.cpp \ + init_function.cpp \ + module_builder.cpp \ + objects.cpp \ + types.cpp + +LIBOBJ = $(LIBSRC:.cpp=.o) +OBJ = $(LIBOBJ) + + +ifeq "$(OS)" "Windows_NT" +PYTHON_LIB=c:/tools/python/libs/python15.lib +INC = -Ic:/cygnus/usr/include/g++-3 -Ic:/cygnus/usr/include -Ic:/boost -Ic:/tools/python/include +MODULE_EXTENSION=dll +else +INC = -I/usr/local/include/python1.5 +MODULE_EXTENSION=so +endif + +%.o: ../src/%.cpp + como --pic $(INC) -o $*.o -c $< + +%.d: ../src/%.cpp + @echo creating $@ + @set -e; como -M $(INC) -c $< \ + | sed 's/\($*\)\.o[ :]*/\1.o $@ : /g' > $@; \ + [ -s $@ ] || rm -f $@ + +example1: example1.o libpycpp.a + como-dyn-link -o ../example/hellomodule.$(MODULE_EXTENSION) $(PYHTON_LIB) example1.o -L. -lpycpp + python ../example/test_example1.py + +example1.o: ../example/example1.cpp + como --pic $(INC) -o $*.o -c $< + +clean: + rm -rf *.o *.$(MODULE_EXTENSION) *.a *.d *.pyc *.bak a.out + +libpycpp.a: $(LIBOBJ) + rm -f libpycpp.a + ar cq libpycpp.a $(LIBOBJ) + +DEP = $(OBJ:.o=.d) + +ifneq "$(MAKECMDGOALS)" "clean" +include $(DEP) +endif diff --git a/build/example1/example1.dsp b/build/example1/example1.dsp new file mode 100644 index 00000000..78d1f0d8 --- /dev/null +++ b/build/example1/example1.dsp @@ -0,0 +1,107 @@ +# Microsoft Developer Studio Project File - Name="example1" - Package Owner=<4> +# Microsoft Developer Studio Generated Build File, Format Version 6.00 +# ** DO NOT EDIT ** + +# TARGTYPE "Win32 (x86) Dynamic-Link Library" 0x0102 + +CFG=example1 - Win32 Debug +!MESSAGE This is not a valid makefile. To build this project using NMAKE, +!MESSAGE use the Export Makefile command and run +!MESSAGE +!MESSAGE NMAKE /f "example1.mak". +!MESSAGE +!MESSAGE You can specify a configuration when running NMAKE +!MESSAGE by defining the macro CFG on the command line. For example: +!MESSAGE +!MESSAGE NMAKE /f "example1.mak" CFG="example1 - Win32 Debug" +!MESSAGE +!MESSAGE Possible choices for configuration are: +!MESSAGE +!MESSAGE "example1 - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library") +!MESSAGE "example1 - Win32 Debug" (based on "Win32 (x86) Dynamic-Link Library") +!MESSAGE + +# Begin Project +# PROP AllowPerConfigDependencies 0 +# PROP Scc_ProjName "" +# PROP Scc_LocalPath "" +CPP=cl.exe +MTL=midl.exe +RSC=rc.exe + +!IF "$(CFG)" == "example1 - Win32 Release" + +# PROP BASE Use_MFC 0 +# PROP BASE Use_Debug_Libraries 0 +# PROP BASE Output_Dir "Release" +# PROP BASE Intermediate_Dir "Release" +# PROP BASE Target_Dir "" +# PROP Use_MFC 0 +# PROP Use_Debug_Libraries 0 +# PROP Output_Dir "Release" +# PROP Intermediate_Dir "Release" +# PROP Ignore_Export_Lib 0 +# PROP Target_Dir "" +# ADD BASE CPP /nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "EXAMPLE1_EXPORTS" /YX /FD /c +# ADD CPP /nologo /MD /W3 /GX /O2 /I "..\..\..\.." /I "c:\tools\python\include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "EXAMPLE1_EXPORTS" /YX /FD /c +# ADD BASE MTL /nologo /D "NDEBUG" /mktyplib203 /win32 +# ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32 +# ADD BASE RSC /l 0x409 /d "NDEBUG" +# ADD RSC /l 0x409 /d "NDEBUG" +BSC32=bscmake.exe +# ADD BASE BSC32 /nologo +# ADD BSC32 /nologo +LINK32=link.exe +# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 +# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 /out:"Release/hello.dll" /libpath:"c:\tools\python\libs" + +!ELSEIF "$(CFG)" == "example1 - Win32 Debug" + +# PROP BASE Use_MFC 0 +# PROP BASE Use_Debug_Libraries 1 +# PROP BASE Output_Dir "Debug" +# PROP BASE Intermediate_Dir "Debug" +# PROP BASE Target_Dir "" +# PROP Use_MFC 0 +# PROP Use_Debug_Libraries 1 +# PROP Output_Dir "Debug" +# PROP Intermediate_Dir "Debug" +# PROP Ignore_Export_Lib 0 +# PROP Target_Dir "" +# ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "EXAMPLE1_EXPORTS" /YX /FD /GZ /c +# ADD CPP /nologo /MDd /W3 /Gm /GR /GX /ZI /Od /I "..\..\..\.." /I "c:\tools\python\include" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "EXAMPLE1_EXPORTS" /YX /FD /GZ /c +# ADD BASE MTL /nologo /D "_DEBUG" /mktyplib203 /win32 +# ADD MTL /nologo /D "_DEBUG" /mktyplib203 /win32 +# ADD BASE RSC /l 0x409 /d "_DEBUG" +# ADD RSC /l 0x409 /d "_DEBUG" +BSC32=bscmake.exe +# ADD BASE BSC32 /nologo +# ADD BSC32 /nologo +LINK32=link.exe +# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept +# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /out:"Debug/hello.dll" /pdbtype:sept /libpath:"c:\tools\python\libs" + +!ENDIF + +# Begin Target + +# Name "example1 - Win32 Release" +# Name "example1 - Win32 Debug" +# Begin Group "Source Files" + +# PROP Default_Filter "cpp;c;cxx;rc;def;r;odl;idl;hpj;bat" +# Begin Source File + +SOURCE=..\..\example\example1.cpp +# End Source File +# End Group +# Begin Group "Header Files" + +# PROP Default_Filter "h;hpp;hxx;hm;inl" +# End Group +# Begin Group "Resource Files" + +# PROP Default_Filter "ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe" +# End Group +# End Target +# End Project diff --git a/build/gcc.mak b/build/gcc.mak new file mode 100644 index 00000000..d0b42548 --- /dev/null +++ b/build/gcc.mak @@ -0,0 +1,53 @@ +LIBSRC = \ + classes.cpp \ + conversions.cpp \ + extension_class.cpp \ + functions.cpp \ + init_function.cpp \ + module_builder.cpp \ + objects.cpp \ + types.cpp + +LIBOBJ = $(LIBSRC:.cpp=.o) +OBJ = $(LIBOBJ) + + +ifeq "$(OS)" "Windows_NT" +PYTHON_LIB=c:/tools/python/libs/python15.lib +INC = -Ic:/cygnus/usr/include/g++-3 -Ic:/cygnus/usr/include -Ic:/boost -Ic:/tools/python/include +MODULE_EXTENSION=dll +else +INC = -I/usr/local/include/python1.5 +MODULE_EXTENSION=so +endif + +%.o: ../src/%.cpp + g++ -fPIC -Wall -W $(INC) -o $*.o -c $< + +%.d: ../src/%.cpp + @echo creating $@ + @set -e; g++ -M $(INC) -c $< \ + | sed 's/\($*\)\.o[ :]*/\1.o $@ : /g' > $@; \ + [ -s $@ ] || rm -f $@ + + +example1: example1.o libpycpp.a + g++ -shared -o ../example/hellomodule.$(MODULE_EXTENSION) $(PYHTON_LIB) example1.o -L. -lpycpp + python ../example/test_example1.py + +example1.o: ../example/example1.cpp + g++ -fPIC -Wall -W $(INC) -o $*.o -c $< + + +clean: + rm -rf *.o *.$(MODULE_EXTENSION) *.a *.d *.pyc *.bak a.out + +libpycpp.a: $(LIBOBJ) + rm -f libpycpp.a + ar cq libpycpp.a $(LIBOBJ) + +DEP = $(OBJ:.o=.d) + +ifneq "$(MAKECMDGOALS)" "clean" +include $(DEP) +endif diff --git a/build/rwgk1/rwgk1.dsp b/build/rwgk1/rwgk1.dsp new file mode 100644 index 00000000..18526979 --- /dev/null +++ b/build/rwgk1/rwgk1.dsp @@ -0,0 +1,105 @@ +# Microsoft Developer Studio Project File - Name="rwgk1" - Package Owner=<4> +# Microsoft Developer Studio Generated Build File, Format Version 6.00 +# ** DO NOT EDIT ** + +# TARGTYPE "Win32 (x86) Dynamic-Link Library" 0x0102 + +CFG=rwgk1 - Win32 Debug +!MESSAGE This is not a valid makefile. To build this project using NMAKE, +!MESSAGE use the Export Makefile command and run +!MESSAGE +!MESSAGE NMAKE /f "rwgk1.mak". +!MESSAGE +!MESSAGE You can specify a configuration when running NMAKE +!MESSAGE by defining the macro CFG on the command line. For example: +!MESSAGE +!MESSAGE NMAKE /f "rwgk1.mak" CFG="rwgk1 - Win32 Debug" +!MESSAGE +!MESSAGE Possible choices for configuration are: +!MESSAGE +!MESSAGE "rwgk1 - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library") +!MESSAGE "rwgk1 - Win32 Debug" (based on "Win32 (x86) Dynamic-Link Library") +!MESSAGE + +# Begin Project +# PROP AllowPerConfigDependencies 0 +# PROP Scc_ProjName "" +# PROP Scc_LocalPath "" +CPP=cl.exe +MTL=midl.exe +RSC=rc.exe + +!IF "$(CFG)" == "rwgk1 - Win32 Release" + +# PROP BASE Use_MFC 0 +# PROP BASE Use_Debug_Libraries 0 +# PROP BASE Output_Dir "Release" +# PROP BASE Intermediate_Dir "Release" +# PROP BASE Target_Dir "" +# PROP Use_MFC 0 +# PROP Use_Debug_Libraries 0 +# PROP Output_Dir "Release" +# PROP Intermediate_Dir "Release" +# PROP Target_Dir "" +# ADD BASE CPP /nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "RWGK1_EXPORTS" /YX /FD /c +# ADD CPP /nologo /MD /W3 /GX /O2 /I "..\..\..\.." /I "c:\tools\python\include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "RWGK1_EXPORTS" /YX /FD /c +# ADD BASE MTL /nologo /D "NDEBUG" /mktyplib203 /win32 +# ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32 +# ADD BASE RSC /l 0x409 /d "NDEBUG" +# ADD RSC /l 0x409 /d "NDEBUG" +BSC32=bscmake.exe +# ADD BASE BSC32 /nologo +# ADD BSC32 /nologo +LINK32=link.exe +# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 +# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 /libpath:"c:\tools\python\libs" + +!ELSEIF "$(CFG)" == "rwgk1 - Win32 Debug" + +# PROP BASE Use_MFC 0 +# PROP BASE Use_Debug_Libraries 1 +# PROP BASE Output_Dir "Debug" +# PROP BASE Intermediate_Dir "Debug" +# PROP BASE Target_Dir "" +# PROP Use_MFC 0 +# PROP Use_Debug_Libraries 1 +# PROP Output_Dir "Debug" +# PROP Intermediate_Dir "Debug" +# PROP Target_Dir "" +# ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "RWGK1_EXPORTS" /YX /FD /GZ /c +# ADD CPP /nologo /MDd /W3 /Gm /GX /ZI /Od /I "..\..\..\.." /I "c:\tools\python\include" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "RWGK1_EXPORTS" /YX /FD /GZ /c +# ADD BASE MTL /nologo /D "_DEBUG" /mktyplib203 /win32 +# ADD MTL /nologo /D "_DEBUG" /mktyplib203 /win32 +# ADD BASE RSC /l 0x409 /d "_DEBUG" +# ADD RSC /l 0x409 /d "_DEBUG" +BSC32=bscmake.exe +# ADD BASE BSC32 /nologo +# ADD BSC32 /nologo +LINK32=link.exe +# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept +# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept /libpath:"c:\tools\python\libs" + +!ENDIF + +# Begin Target + +# Name "rwgk1 - Win32 Release" +# Name "rwgk1 - Win32 Debug" +# Begin Group "Source Files" + +# PROP Default_Filter "cpp;c;cxx;rc;def;r;odl;idl;hpj;bat" +# Begin Source File + +SOURCE=..\..\example\rwgk1.cpp +# End Source File +# End Group +# Begin Group "Header Files" + +# PROP Default_Filter "h;hpp;hxx;hm;inl" +# End Group +# Begin Group "Resource Files" + +# PROP Default_Filter "ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe" +# End Group +# End Target +# End Project diff --git a/build/test/test.dsp b/build/test/test.dsp new file mode 100644 index 00000000..a29d011a --- /dev/null +++ b/build/test/test.dsp @@ -0,0 +1,112 @@ +# Microsoft Developer Studio Project File - Name="test" - Package Owner=<4> +# Microsoft Developer Studio Generated Build File, Format Version 6.00 +# ** DO NOT EDIT ** + +# TARGTYPE "Win32 (x86) Dynamic-Link Library" 0x0102 + +CFG=test - Win32 Debug +!MESSAGE This is not a valid makefile. To build this project using NMAKE, +!MESSAGE use the Export Makefile command and run +!MESSAGE +!MESSAGE NMAKE /f "test.mak". +!MESSAGE +!MESSAGE You can specify a configuration when running NMAKE +!MESSAGE by defining the macro CFG on the command line. For example: +!MESSAGE +!MESSAGE NMAKE /f "test.mak" CFG="test - Win32 Debug" +!MESSAGE +!MESSAGE Possible choices for configuration are: +!MESSAGE +!MESSAGE "test - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library") +!MESSAGE "test - Win32 Debug" (based on "Win32 (x86) Dynamic-Link Library") +!MESSAGE + +# Begin Project +# PROP AllowPerConfigDependencies 0 +# PROP Scc_ProjName "" +# PROP Scc_LocalPath "" +CPP=cl.exe +MTL=midl.exe +RSC=rc.exe + +!IF "$(CFG)" == "test - Win32 Release" + +# PROP BASE Use_MFC 0 +# PROP BASE Use_Debug_Libraries 0 +# PROP BASE Output_Dir "Release" +# PROP BASE Intermediate_Dir "Release" +# PROP BASE Target_Dir "" +# PROP Use_MFC 0 +# PROP Use_Debug_Libraries 0 +# PROP Output_Dir "Release" +# PROP Intermediate_Dir "Release" +# PROP Ignore_Export_Lib 0 +# PROP Target_Dir "" +# ADD BASE CPP /nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "TEST_EXPORTS" /YX /FD /c +# ADD CPP /nologo /MD /W3 /GR /GX /O2 /I "..\..\..\.." /I "c:\tools\python\include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "TEST_EXPORTS" /YX /FD /Zm200 /c +# ADD BASE MTL /nologo /D "NDEBUG" /mktyplib203 /win32 +# ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32 +# ADD BASE RSC /l 0x409 /d "NDEBUG" +# ADD RSC /l 0x409 /d "NDEBUG" +BSC32=bscmake.exe +# ADD BASE BSC32 /nologo +# ADD BSC32 /nologo +LINK32=link.exe +# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 +# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 /libpath:"c:\tools\python\libs" + +!ELSEIF "$(CFG)" == "test - Win32 Debug" + +# PROP BASE Use_MFC 0 +# PROP BASE Use_Debug_Libraries 1 +# PROP BASE Output_Dir "Debug" +# PROP BASE Intermediate_Dir "Debug" +# PROP BASE Target_Dir "" +# PROP Use_MFC 0 +# PROP Use_Debug_Libraries 1 +# PROP Output_Dir "Debug" +# PROP Intermediate_Dir "Debug" +# PROP Ignore_Export_Lib 0 +# PROP Target_Dir "" +# ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "TEST_EXPORTS" /YX /FD /GZ /c +# ADD CPP /nologo /MDd /W3 /Gm /GR /GX /ZI /Od /I "..\..\..\.." /I "c:\tools\python\include" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "TEST_EXPORTS" /YX /FD /GZ /Zm200 /c +# ADD BASE MTL /nologo /D "_DEBUG" /mktyplib203 /win32 +# ADD MTL /nologo /D "_DEBUG" /mktyplib203 /win32 +# ADD BASE RSC /l 0x409 /d "_DEBUG" +# ADD RSC /l 0x409 /d "_DEBUG" +BSC32=bscmake.exe +# ADD BASE BSC32 /nologo +# ADD BSC32 /nologo +LINK32=link.exe +# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept +# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept /libpath:"c:\tools\python\libs" +# SUBTRACT LINK32 /pdb:none + +!ENDIF + +# Begin Target + +# Name "test - Win32 Release" +# Name "test - Win32 Debug" +# Begin Group "Source Files" + +# PROP Default_Filter "cpp;c;cxx;rc;def;r;odl;idl;hpj;bat" +# Begin Source File + +SOURCE=..\..\test\comprehensive.cpp +# End Source File +# End Group +# Begin Group "Header Files" + +# PROP Default_Filter "h;hpp;hxx;hm;inl" +# Begin Source File + +SOURCE=..\..\test\comprehensive.hpp +# End Source File +# End Group +# Begin Group "Resource Files" + +# PROP Default_Filter "ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe" +# End Group +# End Target +# End Project diff --git a/build/tru64.mak b/build/tru64.mak new file mode 100644 index 00000000..6631615c --- /dev/null +++ b/build/tru64.mak @@ -0,0 +1,51 @@ +# +# Tested with: +# Compaq C++ V6.2-024 for Digital UNIX V5.0 (Rev. 910) +# +# Python 1.5.2 was installed without any customizations. +# boost_all.zip vers. 1.18.1 was unpacked using unzip -aa and not modified. +# STLport-4.1b3 was unpacked using unzip -aa and not modified. +# +# Initial version 2000-10-20: Ralf W. Grosse-Kunstleve, rwgk@cci.lbl.gov +# + +PYINC= /usr/local/include/python1.5 +BOOSTINC= /usr/local/boost_1_18_1 +STLPORTINC= /usr/local/STLport-4.1b3/stlport +STLPORTOPTS= \ + -D__USE_STD_IOSTREAM \ + -D__STL_NO_SGI_IOSTREAMS \ + -D__STL_NO_NEW_C_HEADERS \ + -D_RWSTD_COMPILE_INSTANTIATE=1 + +STDOPTS= -std strict_ansi +WARNOPTS= -msg_disable 186,450,1115 +# use -msg_display_number to obtain integer tags for -msg_disable + +CPP= cxx +CPPOPTS= -I$(STLPORTINC) $(STLPORTOPTS) -I$(BOOSTINC) -I$(PYINC) \ + $(STDOPTS) $(WARNOPTS) + +LD= cxx +LDOPTS= -shared -expect_unresolved '*' + +OBJ = extclass.o functions.o init_function.o module.o newtypes.o \ + objects.o py.o subclass.o + +.SUFFIXES: .o .cpp + +all: demo.so hello.so + +demo.so: $(OBJ) extclass_demo.o + $(LD) $(LDOPTS) $(OBJ) extclass_demo.o -o demo.so + +hello.so: $(OBJ) example1.o + $(LD) $(LDOPTS) $(OBJ) example1.o -o hello.so + +.cpp.o: + -$(CPP) $(CPPOPTS) $(INC) -c $*.cpp + +clean: + rm -f $(OBJ) extclass_demo.o example1.o demo.so hello.so so_locations + rm -rf cxx_repository + rm -f *.pyc diff --git a/doc/#index.html# b/doc/#index.html# deleted file mode 100644 index ff5946a8..00000000 --- a/doc/#index.html# +++ /dev/null @@ -1,212 +0,0 @@ - - - - py_cpp Python/C++ binding documentation - -

- c++boost.gif (8819 bytes) py_cpp* -

- -

- The source code for py_cpp, including a MSVC demo project is available here. - -

Synopsis

-

- py_cpp is a system for quickly and easily interfacing C++ code with Python such that the Python interface is - very similar to the C++ interface. It is designed to be minimally - intrusive on your C++ design. In most cases, you should not have to alter - your C++ classes in any way in order to use them with py_cpp. The system - should simply “reflect” your C++ classes and functions into - Python. The major features of py_cpp include support for: -

-among others. - - -

Supported Platforms

-

py_cpp has been tested in the following configurations: - -

- -

Py_cpp requires the boost libraries, and is - has been accepted for inclusion into the boost libraries pending “boostification“ - (completion of the documentation, change in some naming conventions and - resolution of some namespace issues). - -

Credits

- - -

Table of Contents

- -
    -
  1. A Brief Introduction to writing Python - extension modules - -
  2. Comparisons between py_cpp and other - systems for extending Python - -
  3. A Simple Example Using py_cpp - -
  4. Overridable Virtual Functions - -
  5. Function Overloading - -
  6. Inheritance - -
  7. Special Method and Operator Support - -
  8. A Peek Under the Hood - -
  9. Building a Module with Py_cpp - -
  10. Advanced Topics - -
      -
    1. class_builder<> - -
    2. enums - -
    3. References - -
    4. Pointers and Smart Pointers - -
    5. Built-in Python Types - -
    6. Other Extension Types - -
    7. Templates -
    - -
- -

- More sophisticated examples are given in - extclass_demo.cpp, extclass_demo.h, and - test_extclass.py in the source code - archive. There's much more here, and much more documentation to - come... -

- Questions should be directed to the boost mailing list. - -

Naming Contest

- -

- Yes, I know py_cpp is a lousy name. Problem is, the best names my puny - imagination can muster (IDLE and GRAIL) are taken, so I'm holding a - naming contest. First prize? You get to pick the name<0.2wink> and - you will be credited in the documentation. Names that have been suggested - so far include: -

- Please post or send me your suggestions!
-
- -

- © Copyright David Abrahams 2000. Permission to copy, use, modify, - sell and distribute this document is granted provided this copyright - notice appears in all copies. This document is provided “as is” without - express or implied warranty, and with no claim as to its suitability for - any purpose. -

- Updated: Nov 26, 2000 - - diff --git a/doc/building.html b/doc/building.html index 9c0452e7..4ac2343c 100644 --- a/doc/building.html +++ b/doc/building.html @@ -1,21 +1,21 @@ - Building a Module with Py_cpp + Building an Extension Module

c++boost.gif (8819 bytes)Building a Module with Py_cpp + src="../../../c++boost.gif" alt= "c++boost.gif (8819 bytes)">Building an Extension Module

- Right now, the only supported configuration is one in which the py_cpp + Right now, the only supported configuration is one in which the BPL source files are statically linked with the source for your extension module. You may first build them into a library and link it with your extension module source, but the effect is the same as compiling all the source files together. Some users have successfully built the - py_cpp sources into a shared library, and support for a shared library - build is planned, but not yet implemented. The py_cpp source files are: + sources into a shared library, and support for a shared library + build is planned, but not yet implemented. The BPL source files are:

 extclass.cpp
@@ -29,13 +29,14 @@
          

+ Next: Enums Previous: A Peek Under the Hood Up: Top

© Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright - notice appears in all copies. This document is provided “as - is” without express or implied warranty, and with no claim as to + notice appears in all copies. This document is provided ``as + is'' without express or implied warranty, and with no claim as to its suitability for any purpose.

Updated: Nov 26, 2000 diff --git a/doc/comparisons.html b/doc/comparisons.html index d0c31d9f..336220fb 100644 --- a/doc/comparisons.html +++ b/doc/comparisons.html @@ -12,14 +12,16 @@

CXX

- Like py_cpp, CXX attempts to - provide a C++-oriented interface to Python. In most cases, like py_cpp, - it relieves the user from worrying about reference-counts. As far as I - can tell, there is no support for subclassing C++ extension types in - Python. An even more-significant difference is that a user's C++ code is - still basically “dealing with Python objects”, though they are wrapped - in C++ classes. This means such jobs as argument parsing and conversion - are still left to be done explicitly by the user. + Like BPL, CXX attempts to + provide a C++-oriented interface to Python. In most cases, as with the + boost library, it relieves the user from worrying about + reference-counts. Both libraries automatically convert thrown C++ + exceptions into Python exceptions. As far as I can tell, CXX has no + support for subclassing C++ extension types in Python. An even + more significant difference is that a user's C++ code is still basically + ``dealing with Python objects'', though they are wrapped in + C++ classes. This means such jobs as argument parsing and conversion are + still left to be done explicitly by the user.

CXX claims to interoperate well with the C++ Standard Library @@ -38,11 +40,9 @@

As far as I can tell, CXX enables one to write what is essentially idiomatic Python code in C++, manipulating Python objects through the - same fully-generic interfaces we use in Python. I think it would be fair - to say that while you're not programming directly to the “bare - metal” with CXX, in comparison to py_cpp, it presents a low-level - interface to Python. That use is also supported by the py_cpp object - wrappers. + same fully-generic interfaces we use in Python. While you're hardly programming directly to the ``bare + metal'' with CXX, it basically presents a ``C++-ized'' + version of the Python 'C' API.

Paul F. Dubois, the original @@ -51,11 +51,11 @@ fill in the other half. Here is his response to the commentary above:

-“My intention with CXX was not to do what you are doing. It was to enable a +``My intention with CXX was not to do what you are doing. It was to enable a person to write an extension directly in C++ rather than C. I figured others had the wrapping business covered. I thought maybe CXX would provide an easier target language for those making wrappers, but I never explored -that.”
-Paul Dubois +that.''
-Paul Dubois

SWIG

@@ -65,28 +65,28 @@ that.”
-Paul Dubois languages. Swig relies on a parser to read your source code and produce additional source code files which can be compiled into a Python (or Perl or Tcl) extension module. It has been successfully used to create - many Python extension modules. Like py_cpp, SWIG is trying to allow an + many Python extension modules. Like BPL, SWIG is trying to allow an existing interface to be wrapped with little or no change to the - existing code. The documentation says “SWIG parses a form of ANSI C + existing code. The documentation says ``SWIG parses a form of ANSI C syntax that has been extended with a number of special directives. As a result, interfaces are usually built by grabbing a header file and - tweaking it a little bit.” For C++ interfaces, the tweaking has often + tweaking it a little bit.'' For C++ interfaces, the tweaking has often proven to amount to more than just a little bit. One user writes: -
“The problem with swig (when I used it) is that it +
``The problem with swig (when I used it) is that it couldnt handle templates, didnt do func overloading properly etc. For ANSI C libraries this was fine. But for usual C++ code this was a problem. Simple things work. But for anything very complicated (or - realistic), one had to write code by hand. I believe py_cpp doesn't have + realistic), one had to write code by hand. I believe BPL doesn't have this problem[sic]... IMHO overloaded functions are very important to - wrap correctly.”
-Prabhu Ramachandran + wrap correctly.''
-Prabhu Ramachandran

- By contrast, py_cpp doesn't attempt to parse C++ - the problem is simply + By contrast, BPL doesn't attempt to parse C++ - the problem is simply too complex to do correctly. Technically, one does - write code by hand to use py_cpp. The goal, however, has been to make + write code by hand to use BPL. The goal, however, has been to make that code nearly as simple as listing the names of the classes and member functions you want to expose in Python. @@ -95,7 +95,7 @@ that.”
-Paul Dubois SIP is a system similar to SWIG, though seemingly more - C++-oriented. The author says that like py_cpp, SIP supports overriding + C++-oriented. The author says that like BPL, SIP supports overriding extension class member functions in Python subclasses. It appears to have been designed specifically to directly support some features of PyQt/PyKDE, which is its primary client. Documentation is almost @@ -113,7 +113,7 @@ that.”
-Paul Dubois to a wide range of computer languages, including Common Lisp, C++, C, Modula-3, and Python. ILU can parse the ISL to generate a C++ language header file describing the interface, of which the user is expected to - provide an implementation. Unlike py_cpp, this means that the system + provide an implementation. Unlike BPL, this means that the system imposes implementation details on your C++ code at the deepest level. It is worth noting that some of the C++ names generated by ILU are supposed to be reserved to the C++ implementation. It is unclear from the @@ -124,7 +124,7 @@ that.”
-Paul Dubois GRAD is another very ambitious project aimed at generating Python wrappers for - interfaces written in “legacy languages”, among which C++ is the first one + interfaces written in ``legacy languages'', among which C++ is the first one implemented. Like SWIG, it aims to parse source code and automatically generate wrappers, though it appears to take a more sophisticated approach to parsing in general and C++ in particular, so it should do a much better @@ -148,70 +148,70 @@ an inheritance relationship?

Zope ExtensionClasses

- ExtensionClasses in Zope use the same underlying mechanism as py_cpp + ExtensionClasses in Zope use the same underlying mechanism as BPL to support subclassing of extension types in Python, including multiple-inheritance. Both systems support pickling/unpickling of extension class instances in very similar ways. Both systems rely on the - same “Don - Beaudry Hack” that also inspired Don's MESS System. + Beaudry Hack'' that also inspired Don's MESS System.

The major differences are:

+ Next: A Simple Example Using BPL Previous: A Brief Introduction to writing Python Extension Modules - Next: A Simple Example Using py_cpp Up: Top

© Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright - notice appears in all copies. This document is provided “as is” without + notice appears in all copies. This document is provided ``as is'' without express or implied warranty, and with no claim as to its suitability for any purpose.

diff --git a/doc/data_structures.txt b/doc/data_structures.txt new file mode 100644 index 00000000..90e41b91 --- /dev/null +++ b/doc/data_structures.txt @@ -0,0 +1,192 @@ +Given a real Python class 'A', a wrapped C++ class 'B', and this definition: + + class C(A, B): + def __init__(self): + B.__init__(self) + self.x = 1 + ... + + c = C() + +this diagram describes the internal structure of an instance of 'C', including +its inheritance relationships. Note that ExtensionClass is derived from +Class, and is in fact identical for all intents and purposes. + + MetaClass + +---------+ +---------+ +types.ClassType: | | | | + | | | | + | | | | + +---------+ +---------+ + ^ ^ ^ + PyClassObject | ExtensionClass | | + A: +------------+ | B: +------------+ | | + | ob_type -+-+ | ob_type -+-----+ | + | | ()<--+- __bases__ | | + | | | __dict__ -+->{...} | + | | 'B'<-+- __name__ | | + +------------+ +------------+ | + ^ ^ | + | | | + +-----+ +-------------+ | + | | | + | | Class | + | | C: +------------+ | + | | | ob_type -+------------+ + tuple:(*, *)<--+- __bases__ | + | __dict__ -+->{__module__, } + 'C' <-+- __name__ | + +------------+ + ^ (in case of inheritance from more than one + | extension class, this vector would contain + +---------------+ a pointer to an instance holder for the data + | of each corresponding C++ class) + | ExtensionInstance + | c: +---------------------+ std::vector + +----+- __class__ | +---+-- + | m_wrapped_objects -+->| * | ... + {'x': 1}<-+- __dict__ | +-|-+-- + +---------------------+ | InstanceValueHolder + | +--------------------------------+ + +-->| (contains a C++ instance of B) | + +--------------------------------+ + + + + + + +In our inheritance test cases in extclass_demo.cpp/test_extclass.py, we have the +following C++ inheritance hierarchy: + + +-----+ +----+ + | A1 | | A2 | + +-----+ +----+ + ^ ^ ^ ^ ^ + | | | | | + +-----+ | +---------+-----+ + | | | | + | +---+----------+ + .......!...... | | + : A_callback : +-+--+ +-+--+ + :............: | B1 | | B2 | + +----+ +----+ + ^ + | + +-------+---------+ + | | + +-+-+ ......!....... + | C | : B_callback : + +---+ :............: + + +A_callback and B_callback are used as part of the wrapping mechanism but not +represented in Python. C is also not represented in Python but is delivered +there polymorphically through a smart pointer. + +This is the data structure in Python. + + ExtensionClass + A1: +------------+ + ()<--+- __bases__ | + | __dict__ -+->{...} + +------------+ + ^ + | ExtensionInstance + | a1: +---------------------+ vec InstanceValueHolder + +---------+- __class__ | +---+ +---------------------+ + | | m_wrapped_objects -+->| *-+-->| contains A_callback | + | +---------------------+ +---+ +---------------------+ + | + | ExtensionInstance + | pa1_a1: +---------------------+ vec InstancePtrHolder,A1> + +---------+- __class__ | +---+ +---+ + | | m_wrapped_objects -+->| *-+-->| *-+-+ A1 + | +---------------------+ +---+ +---+ | +---+ + | +->| | + | ExtensionInstance +---+ + | pb1_a1: +---------------------+ vec InstancePtrHolder,A1> + +---------+- __class__ | +---+ +---+ + | | m_wrapped_objects -+->| *-+-->| *-+-+ B1 + | +---------------------+ +---+ +---+ | +---+ + | +->| | + | ExtensionInstance +---+ + | pb2_a1: +---------------------+ vec InstancePtrHolder,A1> + +---------+- __class__ | +---+ +---+ + | | m_wrapped_objects -+->| *-+-->| *-+-+ B2 + | +---------------------+ +---+ +---+ | +---+ + | +->| | + | +---+ + | ExtensionClass + | A2: +------------+ + | ()<--+- __bases__ | + | | __dict__ -+->{...} + | +------------+ + | ^ + | | ExtensionInstance + | a2: | +---------------------+ vec InstanceValueHolder + | +-+- __class__ | +---+ +-------------+ + | | | m_wrapped_objects -+->| *-+-->| contains A2 | + | | +---------------------+ +---+ +-------------+ + | | + | | ExtensionInstance + | pa2_a2: | +---------------------+ vec InstancePtrHolder,A2> + | +-+- __class__ | +---+ +---+ + | | | m_wrapped_objects -+->| *-+-->| *-+-+ A2 + | | +---------------------+ +---+ +---+ | +---+ + | | +->| | + | | ExtensionInstance +---+ + | pb1_a2: | +---------------------+ vec InstancePtrHolder,A2> + | +-+- __class__ | +---+ +---+ + | | | m_wrapped_objects -+->| *-+-->| *-+-+ B1 + | | +---------------------+ +---+ +---+ | +---+ + | | +->| | + | | +---+ + | | + | +---------------+------------------------------+ + | | | + +------+-------------------------+-|----------------------------+ | + | | | | | + | Class | | ExtensionClass | | ExtensionClass + | DA1: +------------+ | | B1: +------------+ | | B2: +------------+ +(*,)<---+- __bases__ | (*,*)<---+- __bases__ | (*,*)<---+- __bases__ | + | __dict__ -+->{...} | __dict__ -+->{...} | __dict__ -+->{...} + +------------+ +------------+ +------------+ + ^ ^ ^ + | ExtensionInstance | | + | da1: +---------------------+ | vec InstanceValueHolder + +-------+- __class__ | | +---+ +---------------------+ | + | m_wrapped_objects -+--|-->| *-+-->| contains A_callback | | + +---------------------+ | +---+ +---------------------+ | + +--------------------------------------+ | + | ExtensionInstance | + b1: | +---------------------+ vec InstanceValueHolder | + +-+- __class__ | +---+ +---------------------+ | + | | m_wrapped_objects -+->| *-+-->| contains B_callback | | + | +---------------------+ +---+ +---------------------+ | + | | + | ExtensionInstance | +pb1_b1: | +---------------------+ vec InstancePtrHolder,B1> | + +-+- __class__ | +---+ +---+ | + | | m_wrapped_objects -+->| *-+-->| *-+-+ B1 | + | +---------------------+ +---+ +---+ | +---+ | + | +->| | | + | ExtensionInstance +---+ | + pc_b1: | +---------------------+ vec InstancePtrHolder,B1> | + +-+- __class__ | +---+ +---+ | + | | m_wrapped_objects -+->| *-+-->| *-+-+ C | + | +---------------------+ +---+ +---+ | +---+ | + | +->| | | + | +---+ | + | | + | Class +---------------------------------------+ + | DB1: +------------+ | ExtensionInstance + (*,)<---+- __bases__ | a2: | +---------------------+ vec InstanceValueHolder + | __dict__ -+->{...} +-+- __class__ | +---+ +-------------+ + +------------+ | m_wrapped_objects -+->| *-+-->| contains A2 | + ^ +---------------------+ +---+ +-------------+ + | ExtensionInstance + db1: | +---------------------+ vec InstanceValueHolder + +-+- __class__ | +---+ +----------------------+ + | m_wrapped_objects -+-->| *-+-->| contains B1_callback | + +---------------------+ +---+ +----------------------+ diff --git a/doc/enums.html b/doc/enums.html index 57aef35f..04138ff1 100644 --- a/doc/enums.html +++ b/doc/enums.html @@ -8,31 +8,36 @@ c++boost.gif (8819 bytes)Wrapping enums +

Because there is in general no way to deduce that a value of arbitrary type T -is an enumeration constant, py_cpp cannot automatically convert enum values to -and from Python. To handle this case, you need to decide how you want the enum -to show up in Python (since Python doesn't have enums). Once you have done that, -you can write some simple from_python() and -to_python() functions. +is an enumeration constant, the Boost Python Library cannot automatically +convert enum values to and from Python. To handle this case, you need to decide +how you want the enum to show up in Python (since Python doesn't have +enums). Once you have done that, you can write some simple +from_python() and to_python() functions.

If you are satisfied with a Python int as a way to represent your enum -values, py_cpp provides a shorthand for these functions. You just need to +values, we provide a shorthand for these functions. You just need to instantiate boost::python::enum_as_int_converters<EnumType> where EnumType is your enumerated type. There are two convenient ways to do this:

  1. +   ...
    +} // close my_namespace
     // drop into namespace python and explicitly instantiate
     BOOST_PYTHON_BEGIN_CONVERSION_NAMESPACE // this is a gcc 2.95.2 bug workaround
       template class enum_as_int_converters;
     BOOST_PYTHON_END_CONVERSION_NAMESPACE
    +namespace my_namespace { // re-open my_namespace
    +   ...
     
  2.  // instantiate as base class in any namespace
     struct EnumTypeConverters
    -    : boost::python::py_enum_as_int_converters
    +    : boost::python::enum_as_int_converters<EnumType>
     {
     };
     
    @@ -82,11 +87,15 @@ my_class.add(boost::python::to_python(enum_value_1), "enum_value_1"); my_class.add(boost::python::to_python(enum_value_2), "enum_value_2"); ...
+

+ Next: Pointers + Previous: Building an Extension Module + Up: Top

© Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright - notice appears in all copies. This document is provided “as - is” without express or implied warranty, and with no claim as to + notice appears in all copies. This document is provided ``as + is'' without express or implied warranty, and with no claim as to its suitability for any purpose.

Updated: Nov 26, 2000 diff --git a/doc/example1.html b/doc/example1.html index 9bf9e280..655f3d6a 100644 --- a/doc/example1.html +++ b/doc/example1.html @@ -1,7 +1,7 @@ - A Simple Example Using py_cpp + A Simple Example

@@ -9,7 +9,7 @@ "c++boost.gif (8819 bytes)">

- A Simple Example Using py_cpp + A Simple Example

Suppose we have the following C++ API which we want to expose in @@ -24,20 +24,20 @@ namespace hello {    public:       world(int);       ~world(); -      std::string get() const { return "hi, world"; } +      std::string greet() const { return "hi, world"; }     ...   }; -  std::size_t length(const world& x) { return std::strlen(x.get()); } +  std::size_t length(const world& x) { return std::strlen(x.greet()); } }

Here is the C++ code for a python module called hello - which exposes the API using py_cpp: + which exposes the API using:

-#include 
+#include <boost/python/class_builder.hpp>
 // Python requires an exported function called init<module-name> in every
 // extension module. This is where we build the module contents.
 extern "C"
@@ -49,15 +49,15 @@ void inithello()
     try
     {
        // create an object representing this extension module
-       boost::python::module_builder hello("hello");
+       boost::python::module_builder m("hello");
        // Create the Python type object for our extension class
-       boost::python::class_builder<hello::world> world_class(hello, "world");
+       boost::python::class_builder<hello::world> world_class(m, "world");
        // Add the __init__ function
        world_class.def(boost::python::constructor<int>());
        // Add a regular member function
        world_class.def(&hello::world::get, "get");
        // Add a regular function to the module
-       hello.def(hello::length, "length");
+       m.def(hello::length, "length");
     }
     catch(...)
     {
@@ -82,7 +82,7 @@ extern "C" BOOL WINAPI DllMain(HINSTANCE, DWORD, LPVOID)
 
 >>> import hello
 >>> hi_world = hello.world(3)
->>> hi_world.get()
+>>> hi_world.greet()
 'hi, world'
 >>> hello.length(hi_world)
 9
@@ -93,11 +93,11 @@ extern "C" BOOL WINAPI DllMain(HINSTANCE, DWORD, LPVOID)
       
 >>> class my_subclass(hello.world):
-...     def get(self):
+...     def greet(self):
 ...         return 'hello, world'
 ...
 >>> y = my_subclass(4)
->>> y.get()
+>>> y.greet()
 'hello, world'
 
@@ -115,7 +115,8 @@ extern "C" BOOL WINAPI DllMain(HINSTANCE, DWORD, LPVOID) to have a length() of 12? If so, read on...

- Previous: Comparisons with other systems Next: Overridable virtual functions Up: + Next: Overridable virtual functions + Previous: Comparisons with other systems Up: Top

© Copyright David Abrahams 2000. Permission to copy, use, modify, diff --git a/doc/extending.html b/doc/extending.html index 47341389..c4a3a5e4 100644 --- a/doc/extending.html +++ b/doc/extending.html @@ -38,11 +38,11 @@ This last item typically occupies a great deal of code in an extension module. Remember that Python is a completely dynamic language. A callable - object receives its arguments in a tuple; it is up to that object to - extract those arguments from the tuple, check their types, and raise - appropriate exceptions. There are numerous other tedious details that need - to be managed; too many to mention here. Py_cpp is designed to lift most of - that burden.
+ object receives its arguments in a tuple; it is up to that object to extract + those arguments from the tuple, check their types, and raise appropriate + exceptions. There are numerous other tedious details that need to be + managed; too many to mention here. The Boost Python Library is designed to + lift most of that burden.

@@ -56,10 +56,10 @@ sublcassing the extension type. Aside from being tedious, it's not really the same as having a true class, because there's no way for the user to override a method of the extension type which is called from the - extension module. Py_cpp solves this problem by taking advantage of Python's metaclass feature to provide objects which look, walk, and hiss almost exactly - like regular Python classes. Py_cpp classes are actually cleaner than + like regular Python classes. BPL classes are actually cleaner than Python classes in some subtle ways; a more detailed discussion will follow (someday).

Next: Comparisons with Other Systems Up: - py_cpp Python/C++ binding documentation + The Boost Python Library (BPL)

c++boost.gif (8819 bytes) py_cpp* + align="center" height="86">The Boost Python Library (BPL)

-

- The source code for py_cpp, including a MSVC demo project is available here. -

Synopsis

- py_cpp is a system for quickly and easily interfacing C++ code with Python such that the Python interface is + Use the Boost Python Library to quickly and easily export a C++ library to Python such that the Python interface is very similar to the C++ interface. It is designed to be minimally intrusive on your C++ design. In most cases, you should not have to alter - your C++ classes in any way in order to use them with py_cpp. The system - should simply “reflect” your C++ classes and functions into - Python. The major features of py_cpp include support for: + your C++ classes in any way in order to use them with BPL. The system + should simply ``reflect'' your C++ classes and functions into + Python. The major features of BPL include support for:

  • Subclassing extension types in Python
  • Overriding virtual functions in Python @@ -32,7 +28,7 @@ among others.

    Supported Platforms

    -

    py_cpp has been tested in the following configurations: +

    BPL has been tested in the following configurations:

    • Against Python 1.5.2 using the following compiler/library: @@ -56,7 +52,7 @@ among others. href="mailto:rwgk@cci.lbl.gov">Ralf W. Grosse-Kunstleve]
    • An upcoming release of Metrowerks CodeWarrior - Pro6 for Windows (the first release has a bug that's fatal to py_cpp) + Pro6 for Windows (the first release has a bug that's fatal to BPL)

  • Against Python 2.0 using the following compiler/library combinations: @@ -67,18 +63,13 @@ among others.
-

Py_cpp requires the boost libraries, and is - has been accepted for inclusion into the boost libraries pending “boostification“ - (completion of the documentation, change in some naming conventions and - resolution of some namespace issues). -

Credits

    -
  • David Abrahams originated - and wrote py_cpp. +
  • David Abrahams originated + and wrote the library.
  • Ullrich Koethe - had independently developed a similar system. When he discovered py_cpp, + had independently developed a similar system. When he discovered BPL, he generously contributed countless hours of coding and much insight into improving it. He is responsible for an early version of the support for function overloading and wrote the support for @@ -88,13 +79,13 @@ among others. exposing numeric operators, including a way to avoid explicit coercion by means of overloading. -
  • The members of the boost mailing list and the Python community supplied - invaluable early feedback. In particular, Ron Clarke, Mark Evans, Anton - Gluck, Ralf W. Grosse-Kunstleve, Prabhu Ramachandran, and Barry Scott took - the brave step of trying to use py_cpp while it was still in early stages - of development. +
  • The members of the boost mailing list and the Python community + supplied invaluable early feedback. In particular, Ron Clarke, Mark Evans, + Anton Gluck, Ralf W. Grosse-Kunstleve, Chuck Ingold, Prabhu Ramachandran, + and Barry Scott took the brave step of trying to use BPL while it was + still in early stages of development. -
  • The development of py_cpp wouldn't have been +
  • The development of BPL wouldn't have been possible without the generous support of Dragon Systems/Lernout and Hauspie, Inc who supported its development as an open-source project.
@@ -105,10 +96,10 @@ among others.
  • A Brief Introduction to writing Python extension modules -
  • Comparisons between py_cpp and other +
  • Comparisons between BPL and other systems for extending Python -
  • A Simple Example Using py_cpp +
  • A Simple Example
  • Overridable Virtual Functions @@ -120,11 +111,13 @@ among others.
  • A Peek Under the Hood -
  • Building a Module with Py_cpp +
  • Building an Extension Module
  • Advanced Topics
      +
    1. Pickling +
    2. class_builder<>
    3. enums @@ -138,72 +131,28 @@ among others.
    4. Other Extension Types
    5. Templates + +
    6. Internal Data Structures

    - More sophisticated examples are given in - extclass_demo.cpp, extclass_demo.h, and - test_extclass.py in the source code - archive. There's much more here, and much more documentation to - come... + Documentation is a major ongoing project; assistance is greatly + appreciated! In the meantime, useful examples of every BPL feature should + be evident in the regression test files test/comprehensive.[py/hpp/cpp] +

    Questions should be directed to the boost mailing list. -

    Naming Contest

    - -

    - Yes, I know py_cpp is a lousy name. Problem is, the best names my puny - imagination can muster (IDLE and GRAIL) are taken, so I'm holding a - naming contest. First prize? You get to pick the name<0.2wink> and - you will be credited in the documentation. Names that have been suggested - so far include: -

      -
    • - Py++ -
    • - Python++ -
    • - Coil -
    • - SnakeSkin -
    • - CCCP - Convert C++ - Classes to Python -
    • - C3PO - Convert C++ - Classes to Python - Objects -
    • - PALIN - Python - Augmented-Language - INtegration -
    • - CLEESE - C++ Language Extension Environment - Supremely Easy -
    • - JONES - Just Obscenely Neat Extension - System -
    • - C-thru -
    • - SeamlessC -
    • - BorderCrossing -
    • - Perseus (because he solved a hairy problem involving snakes by using - reflection and was invisible most of the time). -
    - Please post or send me your suggestions!
    -
    -

    © Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright - notice appears in all copies. This document is provided “as is” without + notice appears in all copies. This document is provided ``as is'' without express or implied warranty, and with no claim as to its suitability for any purpose.

    diff --git a/doc/inheritance.html b/doc/inheritance.html index 2dd8071b..d11899c8 100644 --- a/doc/inheritance.html +++ b/doc/inheritance.html @@ -12,11 +12,11 @@

    Inheritance in Python

    - Py_cpp extension classes support single and multiple-inheritance in - Python, just like regular Python classes. You can mix built-in Python - classes with py_cpp extension classes in a derived class' tuple of - bases. Whenever a py_cpp extension class is among the bases for a new - class in Python, the result is an extension class: + BPL extension classes support single and multiple-inheritance in + Python, just like regular Python classes. You can arbitrarily mix + built-in Python classes with extension classes in a derived class' + tuple of bases. Whenever a BPL extension class is among the bases for a + new class in Python, the result is an extension class:

     >>> class MyPythonClass:
    @@ -37,7 +37,7 @@
     
     

    Reflecting C++ Inheritance Relationships

    - Py_cpp also allows us to represent C++ inheritance relationships so that + BPL also allows us to represent C++ inheritance relationships so that wrapped derived classes may be passed where values, pointers, or references to a base class are expected as arguments. The declare_base member function of @@ -71,7 +71,11 @@ int get_derived_x(const Derived& d) { return d.x; }


    -#include +#include <boost/python/class_builder.hpp> + +// namespace alias for code brevity +namespace python = boost::python; + extern "C" #ifdef _WIN32 __declspec(dllexport) @@ -80,13 +84,13 @@ void initmy_module() {     try     { -       boost::python::module_builder my_module("my_module"); +       python::module_builder my_module("my_module"); -       boost::python::class_builder<Base> base_class(my_module, "Base"); -       base_class.def(boost::python::constructor<void>()); +       python::class_builder<Base> base_class(my_module, "Base"); +       base_class.def(python::constructor<void>()); -       boost::python::class_builder<Derived> derived_class(my_module, "Derived"); -       derived_class.def(boost::python::constructor<void>()); +       python::class_builder<Derived> derived_class(my_module, "Derived"); +       derived_class.def(python::constructor<void>()); // Establish the inheritance relationship between Base and Derived derived_class.declare_base(base_class); @@ -96,7 +100,7 @@ void initmy_module()     }     catch(...)     { -       boost::python::handle_exception();    // Deal with the exception for Python +       python::handle_exception();    // Deal with the exception for Python     } }
    @@ -135,12 +139,12 @@ struct Base2 {}; struct Derived2 { int f(); };
    ... -   boost::python::class_builder<Base> base2_class(my_module, "Base2"); -   base2_class.def(boost::python::constructor<void>()); +   python::class_builder<Base> base2_class(my_module, "Base2"); +   base2_class.def(python::constructor<void>()); -   boost::python::class_builder<Derived2> derived2_class(my_module, "Derived2"); -   derived2_class.def(boost::python::constructor<void>()); - derived_class.declare_base(base_class, boost::python::without_downcast); +   python::class_builder<Derived2> derived2_class(my_module, "Derived2"); +   derived2_class.def(python::constructor<void>()); + derived_class.declare_base(base_class, python::without_downcast);
  • @@ -150,8 +154,8 @@ struct Derived2 { int f(); }; references, or values.

    + Next: Special Method and Operator Support Previous: Function Overloading - Next: Special Method Names Up: Top

    © Copyright David Abrahams 2000. Permission to copy, use, modify, diff --git a/doc/overloading.html b/doc/overloading.html index 6197b230..995b3a40 100644 --- a/doc/overloading.html +++ b/doc/overloading.html @@ -113,8 +113,7 @@ namespace scope as Python member functions.

    Overload Resolution

    - The function overload resolution mechanism in py_cpp works as - follows: + The function overload resolution mechanism works as follows:

      @@ -124,7 +123,7 @@ namespace scope as Python member functions. class is found which has a matching attribute, only functions overloaded in the context of that class are candidates for overload resolution. In this sense, overload resolution mirrors the C++ mechanism, where a name - in a derived class “hides” all functions with the same name from a base + in a derived class ``hides'' all functions with the same name from a base class.

      @@ -133,22 +132,22 @@ namespace scope as Python member functions. def()ed. The first function whose signature can be made to match each argument passed is the one which is ultimately called. This means in particular that you cannot overload the same function on - both “int” and “float” because Python + both ``int'' and ``float'' because Python automatically converts either of the two types into the other one. - If the “float” overload is found first, it is used - also used for arguments of type “int” as well, and the - “int” version of the function is never invoked. + If the ``float'' overload is found first, it is used + also used for arguments of type ``int'' as well, and the + ``int'' version of the function is never invoked.

    - Prev: Overridable Virtual Functions - Next: Special Method Names + Next: Inheritance + Previous: Overridable Virtual Functions Up: Top

    © Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright - notice appears in all copies. This document is provided “as - is” without express or implied warranty, and with no claim as to + notice appears in all copies. This document is provided ``as + is'' without express or implied warranty, and with no claim as to its suitability for any purpose.

    Updated: Nov 26, 2000 diff --git a/doc/overriding.html b/doc/overriding.html index f8810ca1..ae629580 100644 --- a/doc/overriding.html +++ b/doc/overriding.html @@ -17,7 +17,7 @@

    Example

    -

    In this example, it is assumed that world::get() is a virtual +

    In this example, it is assumed that world::greet() is a virtual member function:

    @@ -26,7 +26,7 @@ class world
      public:
         world(int);
         virtual ~world();
    -    virtual std::string get() const { return "hi, world"; }
    +    virtual std::string greet() const { return "hi, world"; }
     };
     
    @@ -65,11 +65,11 @@ struct world_callback : world : world(x), m_self(self) {} - std::string get() const // 3 + std::string greet() const // 3 { return boost::python::callback<std::string>::call_method(m_self, "get"); } static std::string default_get(const hello::world& self) const // 4 - { return self.world::get(); } + { return self.world::greet(); } private: PyObject* m_self; // 1 }; @@ -94,7 +94,7 @@ world_class.def(&world::get, "get", &world_callback::default_get)
     >>> class my_subclass(hello.world):
    -...     def get(self):
    +...     def greet(self):
     ...         return 'hello, world'
     ...
     >>> hello.length(my_subclass())
    @@ -181,9 +181,9 @@ break the ODR).
     
         

    - Prev: A Simple Example Using py_cpp Next: Function Overloading Up: Top + Next: Function Overloading + Previous: A Simple Example Using py_cpp + Up: Top

    © Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright diff --git a/doc/pointers.html b/doc/pointers.html index fe30af0b..26f96f0d 100644 --- a/doc/pointers.html +++ b/doc/pointers.html @@ -13,7 +13,7 @@

    In general, raw pointers passed to or returned from functions are problematic -for py_cpp because pointers have too many potential meanings. Is it an iterator? +for BPL because pointers have too many potential meanings. Is it an iterator? A pointer to a single element? An array? When used as a return value, is the caller expected to manage (delete) the pointed-to object or is the pointer really just a reference? If the latter, what happens to Python references to the @@ -34,12 +34,10 @@ converted from/to Python strings.

    Can you avoid the problem?

    My first piece of advice to anyone with a case not covered above is -“find a way to avoid the problem.” For example, if you have just one -or two functions returning a pointer to a single (not an array of) const -T* for some wrapped T, you may be able to write a “thin -converting wrapper” over those two functions as follows (Since py_cpp -converts const T& values to_python by copying the T -into a new extension instance, Foo must have a public copy constructor): +``find a way to avoid the problem.'' For example, if you have just one +or two functions that return a pointer to an individual const +T, and T is a wrapped class, you may be able to write a ``thin +converting wrapper'' over those two functions as follows:

     const Foo* f(); // original function
    @@ -47,6 +45,10 @@ const Foo& f_wrapper() { return *f(); }
       ...
     my_module.def(f_wrapper, "f");
     
    +

    +Foo must have a public copy constructor for this technique to work, since BPL +converts const T& values to_python by copying the T +value into a new extension instance.

    Dealing with the problem

    @@ -118,7 +120,7 @@ return value. You can handle this case by returning a Python tuple: typedef unsigned ErrorCode; const char* f(int* in_out_x); // original function ... -#include +#include <boost/python/objects.hpp> const boost::python::tuple f_wrapper(int in_x) { const char* s = f(in_x); return boost::python::tuple(s, in_x); @@ -131,8 +133,9 @@ my_module.def(f_wrapper, "f"); >>> str,out_x = f(3)
    - - +

    + Previous: Enums + Up: Top

    © Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright diff --git a/doc/special.html b/doc/special.html index 4c314fcf..7debc7c1 100644 --- a/doc/special.html +++ b/doc/special.html @@ -1,11 +1,10 @@ - + Special Method and Operator Support

    - c++boost.gif (8819 bytes)Special Method and Operator Support

    @@ -13,7 +12,7 @@ Overview

    - Py_cpp supports all of the standard special method names supported by real Python class instances except __complex__ (more on the reasons __init__(self)

    Initialize the class instance. For extension classes not subclassed in - Python, this is provided by the - boost::python::constructor<...>() construct and should not be explicitly defed. + Python, __init__ is defined by + +
        my_class.def(boost::python::constructor<...>())
    + + (see section
    "A Simple Example Using BPL").

    __del__(self)
    - Called when the extension instance is about to be destroyed. + Called when the extension instance is about to be destroyed. For extension classes + not subclassed in Python, __del__ is always defined automatically by + means of the class' destructor.
    __repr__(self)
    @@ -78,7 +82,7 @@
    __call__ (self[, args...])
    -Called when the instance is “called” as a function; if this method +Called when the instance is ``called'' as a function; if this method is defined, x(arg1, arg2, ...) is a shorthand for x.__call__(arg1, arg2, ...). @@ -100,7 +104,7 @@ std::string to_string(Foo const& f) boost::python::class_builder<Foo> foo_class(my_module, "Foo"); foo_class.def(&to_string, "__str__"); - Note that py_cpp also supports automatic wrapping of + Note that BPL also supports automatic wrapping of __str__ and __cmp__. This is explained in the next section and the Table of Automatically Wrapped Methods. @@ -111,9 +115,9 @@ foo_class.def(&to_string, "__str__"); Numeric operators can be exposed manually, by defing C++ [member] functions that support the standard Python numeric - protocols. This is the basic same technique used to expose + protocols. This is the same basic technique used to expose to_string() as __str__() above, and is covered in detail below. Py_cpp also supports + href="#numeric_manual">covered in detail below. BPL also supports automatic wrapping of numeric operators whenever they have already been defined in C++. @@ -121,7 +125,7 @@ foo_class.def(&to_string, "__str__");

    Supose we wanted to expose a C++ class - BigNum which supports addition, so that we can write (in C++): + BigNum which supports addition. That is, in C++ we can write:

     BigNum a, b, c;
     ...
    @@ -143,7 +147,7 @@ bignum_class.def(boost::python::operators<boost::python::op_add>());
     
           Since BigNum also supports subtraction, multiplication, and division, we
           want to export those also. This can be done in a single command by
    -      “or”ing the operator identifiers together (a complete list of these
    +      ``or''ing the operator identifiers together (a complete list of these
           identifiers and the corresponding operators can be found in the Table of Automatically Wrapped Methods):
     
    @@ -170,7 +174,7 @@ a = i + b;
     bignum_class.def(boost::python::operators<boost::python::op_add>(), boost::python::right_operand<int>());
     bignum_class.def(boost::python::operators<boost::python::op_add>(), boost::python::left_operand<int>());
     
    - Py_cpp uses overloading to register several variants of the same + BPL uses overloading to register several variants of the same operation (more on this in the context of coercion). Again, several operators can be exported at once:
    @@ -181,7 +185,7 @@ bignum_class.def(boost::python::operators<(boost::python::op_sub | boost::pyt
     
    The type of the operand not mentioned is taken from the class being wrapped. In our example, the class object is bignum_class, and thus the - other operand's type is “BigNum const&”. You can override + other operand's type is ``BigNum const&''. You can override this default by explicitly specifying a type in the operators template:
    @@ -189,15 +193,18 @@ bignum_class.def(boost::python::operators<boost::python::op_add, BigNum>()
     

    Note that automatic wrapping uses the expression - “left + right” and can be used uniformly + ``left + right'' and can be used uniformly regardless of whether the C++ operators are supplied as free functions -

    +
    + 
     BigNum operator+(BigNum, BigNum)
     
    - or as member - functions
    +
    +        or as member functions
    +
    +
     BigNum::operator+(BigNum).
    -
    +

    For the Python built-in functions pow() and @@ -218,8 +225,7 @@ namespace boost { namespace python {

    In some cases, automatic wrapping of operators may be impossible or undesirable. Suppose, for example, that the modulo operation for BigNums - is defined by a set of functions mod() (for automatic - wrapping, we would need operator%()): + is defined by a set of functions called mod():

     BigNum mod(BigNum const& left, BigNum const& right);
    @@ -228,8 +234,9 @@ BigNum mod(int left, BigNum const& right);
     

    - In order to create the Python operator "__mod__" from these functions, we - have to wrap them manually: + For automatic wrapping of the modulo function, operator%() would be needed. + Therefore, the mod()-functions must be wrapped manually. That is, we have + to export them explicitly with the Python special name "__mod__":

     bignum_class.def((BigNum (*)(BigNum const&, BigNum const&))&mod, "__mod__");
    @@ -237,8 +244,8 @@ bignum_class.def((BigNum (*)(BigNum const&, int))&mod, "__mod__");
     

    - The third form (with int as left operand) cannot be wrapped - this way. We must first create a function rmod() with the + The third form of mod() (with int as left operand) cannot + be wrapped directly. We must first create a function rmod() with the operands reversed:

    @@ -248,7 +255,7 @@ BigNum rmod(BigNum const& right, int left)
     }
     
    - This function must be wrapped under the name "__rmod__": + This function must be wrapped under the name "__rmod__" (standing for "reverse mod"):
     bignum_class.def(&rmod,  "__rmod__");
    @@ -261,9 +268,9 @@ bignum_class.def(&rmod,  "__rmod__");
           

    Automatic and manual wrapping can be mixed arbitrarily. Note that you cannot overload the same operator for a given extension class on both - “int” and “float”, because Python implicitly + ``int'' and ``float'', because Python implicitly converts these types into each other. Thus, the overloaded variant - found first (be it “int“ or “float”) will be + found first (be it ``int`` or ``float'') will be used for either of the two types.

    Coercion

    @@ -271,18 +278,18 @@ bignum_class.def(&rmod, "__rmod__"); Plain Python can only execute operators with identical types on the left and right hand side. If it encounters an expression where the types of - the left and right operand differ, it tries to coerce these type to a + the left and right operand differ, it tries to coerce these types to a common type before invoking the actual operator. Implementing good coercion functions can be difficult if many type combinations must be supported.

    - Py_cpp solves this problem the same way that C++ does: with overloading. This technique drastically simplifies the code neccessary to support operators: you just register - operators for all desired type combinations, and py_cpp automatically + operators for all desired type combinations, and BPL automatically ensures that the correct function is called in each case; there is no need for user-defined coercion functions. To enable operator - overloading, py_cpp provides a standard coercion which is implicitly + overloading, BPL provides a standard coercion which is implicitly registered whenever automatic operator wrapping is used.

    If you wrap all operator functions manually, but still want to use @@ -295,7 +302,7 @@ bignum_class.def_standard_coerce();

    If you encounter a situation where you absolutely need a customized - coercion, you can overload the "__coerce__" operator itself. The signature + coercion, you can still define the "__coerce__" operator manually. The signature of a coercion function should look like one of the following (the first is the safest): @@ -310,13 +317,22 @@ PyObject* custom_coerce(PyObject* left, PyObject* right); converted to the same type. Such a function is wrapped as usual:
    +// this must be called before any use of automatic operator  
    +// wrapping or a call to some_class.def_standard_coerce()
     some_class.def(&custom_coerce, "__coerce__");
     
    - Note that the later use of automatic operator wrapping on a - class_builder or a call to - “some_class.def_standard_coerce()” will cause any - custom coercion function to be replaced by the standard one. + Note that the standard coercion (defined by use of automatic + operator wrapping on a class_builder or a call to + class_builder::def_standard_coerce()) will never be applied if + a custom coercion function has been registered. Therefore, in + your coercion function you should call + +
    +boost::python::standard_coerce(left, right);
    +
    + + for all cases that you don't want to handle yourself.

    The Ternary pow() Operator

    @@ -330,7 +346,7 @@ some_class.def(&custom_coerce, "__coerce__"); this is done as usual:
    -BigNum power(BigNum const& first, BigNum const& second, BigNum const& module);
    +BigNum power(BigNum const& first, BigNum const& second, BigNum const& modulus);
     typedef BigNum (ternary_function1)(const BigNum&, const BigNum&, const BigNum&);
     ...
     bignum_class.def((ternary_function1)&power,  "__pow__");
    @@ -353,19 +369,19 @@ bignum_class.def((ternary_function2)&power,  "__pow__");
     
    In the second variant, however, BigNum appears only as second - argument, and in the last one it is the third argument. These functions - must be presented to py_cpp such that that the BigNum + argument, and in the last one it's the third argument. These functions + must be presented to BPL such that that the BigNum argument appears in first position:
     BigNum rpower(BigNum const& second, int first, int modulus)
     {
    -    return power(first, second, third);
    +    return power(first, second, modulus);
     }
     
    -BigNum rrpower(BigNum const& third, int first, int second)
    +BigNum rrpower(BigNum const& modulus, int first, int second)
     {
    -    return power(first, second, third);
    +    return power(first, second, modulus);
     }
     
    @@ -381,7 +397,7 @@ Note that "__rrpow__" is an extension not present in plain Python.

    Table of Automatically Wrapped Methods

    - Py_cpp can automatically wrap the following special methods: @@ -630,15 +646,16 @@ Note that "__rrpow__" is an extension not present in plain Python. to Python's iteration and access protocols. These protocols differ considerably from the ones found in C++. For example, Python's typical iteration idiom looks like +

     for i in S:
    -
    +
    -while in C++ one writes + while in C++ one writes
    -for (iterator i = S.begin(), end = S.end(); i != end)
    -
    +for (iterator i = S.begin(), end = S.end(); i != end; ++i) +

    One could try to wrap C++ iterators in order to carry the C++ idiom into Python. However, this does not work very well because @@ -689,7 +706,7 @@ void throw_key_error_if_end( // Define some simple wrapper functions which match the Python protocol // for __getitem__, __setitem__, and __delitem__. Just as in Python, a -// free function with a “self” first parameter makes a fine class method. +// free function with a ``self'' first parameter makes a fine class method. const std::string& get_item(const StringMap& self, std::size_t key) { @@ -755,13 +772,13 @@ KeyError: 2

    Customized Attribute Access

    - Just like built-in Python classes, py_cpp extension classes support special the usual attribute access methods __getattr__, __setattr__, and __delattr__. Because writing these functions can be tedious in the common case where the attributes being accessed are - known statically, py_cpp checks the special names + known statically, BPL checks the special names

    • @@ -774,10 +791,10 @@ KeyError: 2 to provide functional access to the attribute <name>. This facility can be used from C++ or entirely from Python. For example, the - following shows how we can implement a “computed attribute” in Python: + following shows how we can implement a ``computed attribute'' in Python:
      ->>> class Range(AnyPy_cppExtensionClass):
      +>>> class Range(AnyBPLExtensionClass):
       ...    def __init__(self, start, end):
       ...        self.start = start
       ...        self.end = end
      @@ -793,7 +810,7 @@ KeyError: 2
                Direct Access to Data Members
             
             

      - Py_cpp uses the special + BPL uses the special __xxxattr__<name>__ functionality described above to allow direct access to data members through the following special functions on class_builder<> and @@ -873,14 +890,14 @@ if (PyInstance_Check(r)) { ...

      - Previous: Inheritance Next: A Peek Under the Hood Up: Top +Next: A Peek Under the Hood +Previous: Inheritance +Up: Top

      © Copyright David Abrahams and Ullrich Köthe 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright notice appears in all copies. This - document is provided “as is” without express or implied + document is provided ``as is'' without express or implied warranty, and with no claim as to its suitability for any purpose.

      Updated: Nov 26, 2000 diff --git a/doc/under-the-hood.html b/doc/under-the-hood.html index 288021cf..902804d3 100644 --- a/doc/under-the-hood.html +++ b/doc/under-the-hood.html @@ -22,7 +22,7 @@ "example1.html#add_world_class">add it to the module it goes into the module's dictionary to be looked up under the name "world".

      - Py_cpp uses C++'s template argument deduction mechanism to determine the + BPL uses C++'s template argument deduction mechanism to determine the types of arguments to functions (except constructors, for which we must provide an argument list because they can't be named in C++). Then, it calls the appropriate @@ -48,8 +48,8 @@ the top of your module's init function, then def the member functions later to avoid problems with inter-class dependencies.

      - Previous: Function Overloading - Next: Building a Module with Py_cpp + Next: Building a Module with BPL + Previous: Special Method and Operator Support Up: Top

      © Copyright David Abrahams 2000. Permission to copy, use, modify, diff --git a/example/rwgk1.cpp b/example/rwgk1.cpp new file mode 100644 index 00000000..b21ae4d1 --- /dev/null +++ b/example/rwgk1.cpp @@ -0,0 +1,41 @@ +#include + +namespace { // Avoid cluttering the global namespace. + + // A couple of simple C++ functions that we want to expose to Python. + std::string greet() { return "hello, world"; } + int square(int number) { return number * number; } +} + +#include + +namespace python = boost::python; + +// Python requires an exported function called init in every +// extension module. This is where we build the module contents. +extern "C" +#ifdef _WIN32 +__declspec(dllexport) +#endif +void initrwgk1() +{ + try + { + // Create an object representing this extension module. + python::module_builder this_module("rwgk1"); + + // Add regular functions to the module. + this_module.def(greet, "greet"); + this_module.def(square, "square"); + } + catch(...) + { + python::handle_exception(); // Deal with the exception for Python + } +} + +// Win32 DLL boilerplate +#if defined(_WIN32) +#include +extern "C" BOOL WINAPI DllMain(HINSTANCE, DWORD, LPVOID) { return 1; } +#endif // _WIN32 diff --git a/example/example1.py b/example/test_example1.py similarity index 100% rename from example/example1.py rename to example/test_example1.py diff --git a/example/test_rwgk1.py b/example/test_rwgk1.py new file mode 100644 index 00000000..87298875 --- /dev/null +++ b/example/test_rwgk1.py @@ -0,0 +1,17 @@ +r'''>>> import rwgk1 + >>> print rwgk1.greet() + hello, world + >>> number = 11 + >>> print number, '*', number, '=', rwgk1.square(number) + 11 * 11 = 121 +''' + +def run(args = None): + if args is not None: + import sys + sys.argv = args + import doctest, test_rwgk1 + doctest.testmod(test_rwgk1) + +if __name__ == '__main__': + run() diff --git a/include/boost/python/class_builder.hpp b/include/boost/python/class_builder.hpp index 9e88f049..7ef843c4 100644 --- a/include/boost/python/class_builder.hpp +++ b/include/boost/python/class_builder.hpp @@ -27,8 +27,8 @@ class class_builder // define constructors template - void def(const signature& signature) - { m_class->def(signature); } + void def(const signature& s) + { m_class->def(s); } // export heterogeneous reverse-argument operators // (type of lhs: 'left', of rhs: 'right') diff --git a/include/boost/python/detail/config.hpp b/include/boost/python/detail/config.hpp index 2488bd8e..faf52ee4 100644 --- a/include/boost/python/detail/config.hpp +++ b/include/boost/python/detail/config.hpp @@ -21,7 +21,7 @@ # else # define BOOST_PYTHON_BEGIN_CONVERSION_NAMESPACE namespace boost { namespace python { # define BOOST_PYTHON_END_CONVERSION_NAMESPACE }} // namespace boost::python -# define BOOST_PYTHON_CONVERSION python +# define BOOST_PYTHON_CONVERSION boost::python # define BOOST_PYTHON_IMPORT_CONVERSION(x) void never_defined() // so we can follow the macro with a ';' # endif diff --git a/include/boost/python/detail/extension_class.hpp b/include/boost/python/detail/extension_class.hpp index 20d48796..0e2e3427 100644 --- a/include/boost/python/detail/extension_class.hpp +++ b/include/boost/python/detail/extension_class.hpp @@ -721,8 +721,6 @@ class extension_instance : public instance // Template function implementations // -tuple extension_class_coerce(ref l, ref r); - template extension_class::extension_class() : extension_class_base(typeid(T).name()) @@ -743,7 +741,7 @@ void extension_class::def_standard_coerce() ref coerce_fct = dict().get_item(string("__coerce__")); if(coerce_fct.get() == 0) // not yet defined - this->def(&extension_class_coerce, "__coerce__"); + this->def(&standard_coerce, "__coerce__"); } template diff --git a/include/boost/python/detail/wrap_python.hpp b/include/boost/python/detail/wrap_python.hpp index 7c6dd5be..eb831b68 100644 --- a/include/boost/python/detail/wrap_python.hpp +++ b/include/boost/python/detail/wrap_python.hpp @@ -1,5 +1,22 @@ +// (C) Copyright David Abrahams 2000. Permission to copy, use, modify, sell and +// distribute this software is granted provided this copyright notice appears +// in all copies. This software is provided "as is" without express or implied +// warranty, and with no claim as to its suitability for any purpose. +// +// The author gratefully acknowleges the support of Dragon Systems, Inc., in +// producing this work. + +// This file serves as a wrapper around which allows it to be +// compiled with GCC 2.95.2 under Win32 and which disables the default MSVC +// behavior so that a program may be compiled in debug mode without requiring a +// special debugging build of the Python library. + + +// To use the Python debugging library, #define BOOST_DEBUG_PYTHON on the +// compiler command-line. + #ifdef _DEBUG -# ifndef DEBUG_PYTHON +# ifndef BOOST_DEBUG_PYTHON # undef _DEBUG // Don't let Python force the debug library just because we're debugging. # define DEBUG_UNDEFINED_FROM_WRAP_PYTHON_H # endif diff --git a/include/boost/python/module_builder.hpp b/include/boost/python/module_builder.hpp index 57507e59..6a8a9b4b 100644 --- a/include/boost/python/module_builder.hpp +++ b/include/boost/python/module_builder.hpp @@ -18,11 +18,10 @@ namespace boost { namespace python { class module_builder { - typedef PyObject * (*raw_function_ptr)(boost::python::tuple const &, boost::python::dictionary const &); - public: // Create a module. REQUIRES: only one module_builder is created per module. module_builder(const char* name); + ~module_builder(); // Add elements to the module void add(detail::function* x, const char* name); @@ -41,13 +40,29 @@ class module_builder add(detail::new_wrapped_function(fn), name); } - static string name(); + // Return true iff a module is currently being built. + static bool initializing(); + // Return the name of the module currently being built. + // REQUIRES: initializing() == true + static string name(); + + // Return a pointer to the Python module object being built + PyObject* module() const; + private: PyObject* m_module; static PyMethodDef initial_methods[1]; }; +// +// inline implementations +// +inline PyObject* module_builder::module() const +{ + return m_module; +} + }} // namespace boost::python #endif diff --git a/include/boost/python/operators.hpp b/include/boost/python/operators.hpp index d0c06895..40400f47 100644 --- a/include/boost/python/operators.hpp +++ b/include/boost/python/operators.hpp @@ -1,15 +1,22 @@ #ifndef OPERATORS_UK112000_H_ #define OPERATORS_UK112000_H_ -#include -#if !defined(__GNUC__) || defined(__SGI_STL_PORT) -# include -#else -# include -#endif +# include +# include + +// When STLport is used with native streams, _STL::ostringstream().str() is not +// _STL::string, but std::string. This confuses to_python(), so we'll use +// strstream instead. Also, GCC 2.95.2 doesn't have sstream. +# if defined(__SGI_STL_PORT) ? __SGI_STL_OWN_IOSTREAMS : !defined(__GNUC__) || __GNUC__ > 2 +# include +# else +# include +# endif namespace boost { namespace python { +tuple standard_coerce(ref l, ref r); + namespace detail { // helper class for automatic operand type detection @@ -473,17 +480,15 @@ namespace detail { tuple args(ref(arguments, ref::increment_count)); -#if !defined(__GNUC__) || defined(__SGI_STL_PORT) +// When STLport is used with native streams, _STL::ostringstream().str() is not +// _STL::string, but std::string. +#if defined(__SGI_STL_PORT) ? __SGI_STL_OWN_IOSTREAMS : !defined(__GNUC__) std::ostringstream s; s << BOOST_PYTHON_CONVERSION::from_python(args[0].get(), boost::python::type()); + return BOOST_PYTHON_CONVERSION::to_python(s.str()); #else std::ostrstream s; s << BOOST_PYTHON_CONVERSION::from_python(args[0].get(), boost::python::type()) << char(); -#endif - -#if !defined(__GNUC__) || defined(__SGI_STL_PORT) - return BOOST_PYTHON_CONVERSION::to_python(s.str()); -#else return BOOST_PYTHON_CONVERSION::to_python(const_cast(s.str())); #endif } diff --git a/release_notes.txt b/release_notes.txt new file mode 100644 index 00000000..8932a0aa --- /dev/null +++ b/release_notes.txt @@ -0,0 +1,217 @@ +2000-11-22 10:00 + Ullrich fixed bug in operator_dispatcher. + +2000-11-21 10:00 + Changed all class and function names into lower_case. + + Ullrich updated documentation for operator wrapping. + +2000-11-20 10:00 + Ullrich renamed ExtensionClass:register_coerce() into + ExtensionClass:def_standard_coerce() and made it public + + Ullrich improved shared_pod_manager. + +2000-11-17 15:04 + Changed allocation strategy of shared_pod_manager to make it portable. + + Added pickling support + tests thanks to "Ralf W. Grosse-Kunstleve" + + + Added a specialization of Callback to prevent unsafe usage. + + Fixed Ullrich's operator_dispatcher refcount bug + + Removed const char* return values from virtual functions in tests; that + usage was unsafe. + + Ullrich changed Module::add() so that it steals a reference (fix of refcount bug) + + Ullrich added operator_dispatcher::create() optimization + + Ullrich changed design and implementation of TypeObjectBase::enable() (to eliminate low-level + code) and added shared_pod_manager optimization. + + +2000-11-15 12:01 + Fixed refcount bugs in operator calls. + + Added callback_adjust_refcount(PyObject*, Type) to account for different ownership + semantics of Callback's return types and Caller's arguments (which both use from_python()) + This bug caused refcount errors during operator calls. + + Moved operator_dispatcher into extclass.cpp + Gave it shared ownership of the objects it wraps + + Introduced sequence points in extension_class_coerce for exception-safety + + UPPER_CASE_MACRO_NAMES + + MixedCase template type argument names + + Changed internal error reporting to use Python exceptions so we don't force the + user to link in iostreams code + + Changed error return value of call_cmp to -1 + + Moved unwrap_* functions out of operator_dispatcher. This was transitional: when + I realized they didn't need to be declared in extclass.h I moved them out, but + now that operator_dispatcher itself is in extclass.cpp they could go back in. + + Numerous formatting tweaks + + Updated the BoundFunction::create() optimization and enabled it so it could actually be used! + +2000-11-15 00:26 + + Made Ullrich's operators support work with MSVC + + Cleaned up operators.h such that invalid define_operator<0> is no longer needed. + + Ullrich created operators.h to support wrapping of C++ operators (including the "__r*__" forms). + He added several auxiliary classes to extclass.h and extclass.cpp (most importantly, + py::detail::operator_dispatcher and py::operators) + +2000-11-13 22:29 + + removed obsolete ExtensionClassFromPython for good. + + removed unused class ExtensionType forward declaration + +2000-11-12 13:08 + + Added enum_as_int_converters for easier enum wrapping + + Introduced new conversion namespace macros: + PY_BEGIN_CONVERSION_NAMESPACE, + PY_END_CONVERSION_NAMESPACE, + PY_CONVERSION + + callback.h, gen_callback.py: + Added call() function so that a regular python function (as opposed to + method or other function-as-attribute) can be called. + + Added newlines for readability. + + class_wrapper.h: + Fixed a bug in add(), which allows non-method class attributes + + Ullrich has added def_raw for simple varargs and keyword support. + + Fixed version number check for __MWERKS__ + + Added tests for enums and non-method class attributes + + objects.h/objects.cpp: + Added py::String operator*= and operator* for repetition + + Change Dict::items(), keys(), and values() to return a List + + Added template versions of set_item, etc., methods so that users can optionally + use C++ types that have to_python() functions as parameters. + + Changed various Ptr by-value parameters to const Ptr& + + +======= Release ======= +2000-11-06 0:22 + Lots of documentation updates + + added 4-argument template constructor to py::Tuple + + added "add" member function to ClassWrapper<> to allow arbitrary Python + objects to be added to an extension class. + + gen_all.py now generates support for n argument member functions and n+1 + argument member functions at the suggestion of "Ralf W. Grosse-Kunstleve" + + + Added regression tests and re-ordered declare_base calls to verify that the + phantom base class issue is resolved. + +2000-11-04 17:35 + + Integrated Ullrich Koethe's brilliant from_python_experiment for better + error-reporting in many cases. + + extclass.h, gen_extclass.py: + removed special-case MSVC code + added much commentary + removed unused py_copy_to_new_value_holder + + init_function.h, gen_init_function.py: + added missing 'template' keyword on type-dependent template member usage + removed special-case MSVC code + added much commentary + +2000-11-04 0:36 + + Removed the need for the phantom base class that screwed up inheritance + hierarchies, introduced error-prone ordering dependencies, and complexified + logic in many places! + + extclass.h: Added some explanatory comments, removed wasteful m_self member + of HeldInstance + + extclass_demo.cpp: Added #pragmas which allow compilation in ansi strict + mode under Metrowerks + + functions.h: Added virtual_function as part of phantom base class removal; + expanded commentary + + pyptr.h: Added some missing 'typename's and a GCC workaround fix + + subclass.cpp: Added missing string literal const_cast<>s. + +2000-11-03 10:58 + + Fix friend function instantiation bug caught by Metrowerks (thanks + Metrowerks!) + + Add proof-of-concept for one technique of wrapping function that return a + pointer + + Worked around MSVC optimizer bug by writing to_python(double) and + to_python(float) out-of-line + +2000-11-02 23:25 + + Add /Zm200 option to vc6_prj to deal with MSVC resource limitations + + Remove conflicting /Ot option from vc6_prj release build + +======= Release ======= +2000-11-02 17:42 + + Added a fix for interactions between default virtual function + implementations and declare_base(). You still need to write your + declare_base() /after/ all member functions have been def()d for the two + classes concerned. Many, many thanks to Ullrich Koethe + for all his work on this. + + Added missing conversions: + to_python(float) + from_python(const char* const&) + from_python(const double&) + from_python(const float&) + + Added a Regression test for a reference-counting bug thanks to Mark Evans + () + + const-ify ClassBase::getattr() + + Add repr() function to Class + + Add to_python/from_python conversions for PyPtr + + Standardize set_item/get_item interfaces (instead of proxies) for Dict and List + + Add Reprable<> template to newtypes.h + + Fix a bug wherein the __module__ attribute would be lost for classes that have a + default virtual function implementation. + + Remove extra ';' in module.cpp thanks to "Ralf W. Grosse-Kunstleve" + + + Fix a bug in the code of example1.html diff --git a/src/classes.cpp b/src/classes.cpp index 34b42c22..2901aa81 100644 --- a/src/classes.cpp +++ b/src/classes.cpp @@ -840,7 +840,27 @@ namespace { void add_current_module_name(dictionary& name_space) { static string module_key("__module__", string::interned); - name_space.set_item(module_key, module_builder::name()); + + // If the user didn't specify a __module__ attribute already + if (name_space.get_item(module_key).get() == 0) + { + if (module_builder::initializing()) + { + // The global __name__ is not properly set in this case + name_space.set_item(module_key, module_builder::name()); + } + else + { + // Get the module name from the global __name__ + PyObject *globals = PyEval_GetGlobals(); + if (globals != NULL) + { + PyObject *module_name = PyDict_GetItemString(globals, "__name__"); + if (module_name != NULL) + name_space.set_item(module_key, module_name); + } + } + } } } diff --git a/src/extension_class.cpp b/src/extension_class.cpp index cde3d836..c15e538b 100644 --- a/src/extension_class.cpp +++ b/src/extension_class.cpp @@ -46,24 +46,19 @@ BOOST_PYTHON_END_CONVERSION_NAMESPACE namespace boost { namespace python { -namespace detail { +tuple standard_coerce(ref l, ref r) +{ + // Introduced sequence points for exception-safety. + ref first(detail::operator_dispatcher::create(l, l)); + + ref second(r->ob_type == &detail::operator_dispatcher::type_obj + ? r + : ref(detail::operator_dispatcher::create(r, ref()))); - tuple extension_class_coerce(ref l, ref r) - { - // Introduced sequence points for exception-safety. - ref first(operator_dispatcher::create(l, l)); - ref second; - - if(r->ob_type == &operator_dispatcher::type_obj) - { - second = r; - } - else - { - second = ref(operator_dispatcher::create(r, ref())); - } - return boost::python::tuple(first, second); - } + return tuple(first, second); +} + +namespace detail { enum { unwrap_exception_code = -1000 }; diff --git a/src/gen_extclass.py b/src/gen_extclass.py index 5180a3de..f8906970 100644 --- a/src/gen_extclass.py +++ b/src/gen_extclass.py @@ -707,8 +707,6 @@ class extension_instance : public instance // Template function implementations // -tuple extension_class_coerce(ref l, ref r); - template extension_class::extension_class() : extension_class_base(typeid(T).name()) @@ -729,7 +727,7 @@ void extension_class::def_standard_coerce() ref coerce_fct = dict().get_item(string("__coerce__")); if(coerce_fct.get() == 0) // not yet defined - this->def(&extension_class_coerce, "__coerce__"); + this->def(&standard_coerce, "__coerce__"); } template diff --git a/src/module_builder.cpp b/src/module_builder.cpp index ea00b71c..57eec75f 100644 --- a/src/module_builder.cpp +++ b/src/module_builder.cpp @@ -14,10 +14,15 @@ namespace { ref name_holder; } +bool module_builder::initializing() +{ + return name_holder.get() != 0; +} + string module_builder::name() { // If this fails, you haven't created a module_builder object - assert(name_holder.get() != 0); + assert(initializing()); return string(name_holder); } @@ -29,6 +34,11 @@ module_builder::module_builder(const char* name) name_holder = ref(PyObject_GetAttrString(m_module, const_cast("__name__"))); } +module_builder::~module_builder() +{ + name_holder.reset(); +} + void module_builder::add(detail::function* x, const char* name) { diff --git a/test/comprehensive.cpp b/test/comprehensive.cpp index cae924e6..7fad74bb 100644 --- a/test/comprehensive.cpp +++ b/test/comprehensive.cpp @@ -11,7 +11,7 @@ #include // for pow() #include -namespace extclass_demo { +namespace bpl_test { FooCallback::FooCallback(PyObject* self, int x) : Foo(x), m_self(self) @@ -714,12 +714,14 @@ const Record* get_record() return &v; } -template class boost::python::class_builder; // explicitly instantiate +} // namespace bpl_test -} // namespace extclass_demo +namespace boost { namespace python { + template class class_builder; // explicitly instantiate +}} // namespace boost::python BOOST_PYTHON_BEGIN_CONVERSION_NAMESPACE -inline PyObject* to_python(const extclass_demo::Record* p) +inline PyObject* to_python(const bpl_test::Record* p) { return to_python(*p); } @@ -731,7 +733,7 @@ BOOST_PYTHON_END_CONVERSION_NAMESPACE /* */ /************************************************************/ -namespace extclass_demo { +namespace bpl_test { struct EnumOwner { @@ -753,8 +755,8 @@ struct EnumOwner } namespace boost { namespace python { - template class enum_as_int_converters; - using extclass_demo::pow; + template class enum_as_int_converters; + using bpl_test::pow; }} // namespace boost::python // This is just a way of getting the converters instantiated @@ -763,7 +765,7 @@ namespace boost { namespace python { //{ //}; -namespace extclass_demo { +namespace bpl_test { /************************************************************/ /* */ @@ -1036,7 +1038,7 @@ void init_module(boost::python::module_builder& m) world_class.def(world_setstate, "__setstate__"); } -PyObject* raw(boost::python::tuple const& args, boost::python::dictionary const& keywords) +PyObject* raw(const boost::python::tuple& args, const boost::python::dictionary& keywords) { if(args.size() != 2 || keywords.size() != 2) { @@ -1055,21 +1057,21 @@ PyObject* raw(boost::python::tuple const& args, boost::python::dictionary const& void init_module() { - boost::python::module_builder demo("demo"); - init_module(demo); + boost::python::module_builder test("test"); + init_module(test); // Just for giggles, add a raw metaclass. - demo.add(new boost::python::meta_class); + test.add(new boost::python::meta_class); } extern "C" #ifdef _WIN32 __declspec(dllexport) #endif -void initdemo() +void inittest() { try { - extclass_demo::init_module(); + bpl_test::init_module(); } catch(...) { boost::python::handle_exception(); @@ -1083,7 +1085,7 @@ CompareIntPairPythonClass::CompareIntPairPythonClass(boost::python::module_build def(&CompareIntPair::operator(), "__call__"); } -} // namespace extclass_demo +} // namespace bpl_test #if defined(_WIN32) @@ -1124,7 +1126,7 @@ BOOL WINAPI DllMain( switch(fdwReason) { case DLL_PROCESS_DETACH: - assert(extclass_demo::total_Ints == 0); + assert(bpl_test::total_Ints == 0); } #endif diff --git a/test/comprehensive.hpp b/test/comprehensive.hpp index d8a8e8ea..ed90f061 100644 --- a/test/comprehensive.hpp +++ b/test/comprehensive.hpp @@ -6,8 +6,8 @@ // The author gratefully acknowleges the support of Dragon Systems, Inc., in // producing this work. -#ifndef EXTCLASS_DEMO_DWA052200_H_ -# define EXTCLASS_DEMO_DWA052200_H_ +#ifndef BPL_TEST_DWA052200_H_ +# define BPL_TEST_DWA052200_H_ // // Example code demonstrating extension class usage // @@ -21,7 +21,7 @@ # include # include -namespace extclass_demo { +namespace bpl_test { // // example: Foo, Bar, and Baz are C++ classes we want to wrap. @@ -226,6 +226,6 @@ struct CompareIntPairPythonClass CompareIntPairPythonClass(boost::python::module_builder&); }; -} // namespace extclass_demo +} // namespace bpl_test -#endif // EXTCLASS_DEMO_DWA052200_H_ +#endif // BPL_TEST_DWA052200_H_ diff --git a/test/comprehensive.py b/test/comprehensive.py index 578197f1..a8e181d2 100644 --- a/test/comprehensive.py +++ b/test/comprehensive.py @@ -209,7 +209,7 @@ Polymorphism also works: Pickling tests: >>> world.__module__ - 'demo' + 'test' >>> world.__safe_for_unpickling__ 1 >>> world.__reduce__() @@ -1072,7 +1072,7 @@ test methodologies for wrapping functions that return a pointer 1 ''' -from demo import * +from test import * import string import re import sys @@ -1080,8 +1080,8 @@ import sys def run(args = None): if args is not None: sys.argv = args - import doctest, test_extclass - doctest.testmod(test_extclass) + import doctest, comprehensive + doctest.testmod(comprehensive) if __name__ == '__main__': run() diff --git a/test/doctest.py b/test/doctest.py new file mode 100644 index 00000000..248da82a --- /dev/null +++ b/test/doctest.py @@ -0,0 +1,1112 @@ +# Module doctest version 0.9.4 +# Released to the public domain 27-Mar-1999, +# by Tim Peters (tim_one@email.msn.com). + +# Provided as-is; use at your own risk; no warranty; no promises; enjoy! + +"""module_builder doctest -- a framework for running examples in docstrings. + +NORMAL USAGE + +In normal use, end each module M with: + +def _test(): + import doctest, M # replace M with your module's name + return doctest.testmod(M) # ditto + +if __name__ == "__main__": + _test() + +Then running the module as a script will cause the examples in the +docstrings to get executed and verified: + +python M.python + +This won't display anything unless an example fails, in which case +the failing example(s) and the cause(s) of the failure(s) are printed +to stdout (why not stderr? because stderr is a lame hack <0.2 wink>), +and the final line of output is "Test failed.". + +Run it with the -v switch instead: + +python M.python -v + +and a detailed report of all examples tried is printed to stdout, along +with assorted summaries at the end. + +You can force verbose mode by passing "verbose=1" to testmod, or prohibit +it by passing "verbose=0". In either of those cases, sys.argv is not +examined by testmod. + +In any case, testmod returns a 2-tuple of ints (f, t), where f is the +number of docstring examples that failed and t is the total number of +docstring examples attempted. + + +WHICH DOCSTRINGS ARE EXAMINED? + ++ M.__doc__. + ++ f.__doc__ for all functions f in M.__dict__.values(), except those + with private names. + ++ C.__doc__ for all classes C in M.__dict__.values(), except those with + private names. + ++ If M.__test__ exists and "is true", it must be a dict, and + each entry maps a (string) name to a function object, class object, or + string. function and class object docstrings found from M.__test__ + are searched even if the name is private, and strings are searched + directly as if they were docstrings. In output, a key K in M.__test__ + appears with name + .__test__.K + +Any classes found are recursively searched similarly, to test docstrings +in their contained methods and nested classes. Private names reached +from M's globals are skipped, but all names reached from M.__test__ are +searched. + +By default, a name is considered to be private if it begins with an +underscore (like "_my_func") but doesn't both begin and end with (at +least) two underscores (like "__init__"). You can change the default +by passing your own "isprivate" function to testmod. + +If you want to test docstrings in objects with private names too, stuff +them into an M.__test__ dict, or see ADVANCED USAGE below (e.g., pass your +own isprivate function to Tester's constructor, or call the rundoc method +of a Tester obj). + +Warning: imports can cause trouble; e.g., if you do + +from XYZ import XYZclass + +then XYZclass is a name in M.__dict__ too, and doctest has no way to +know that XYZclass wasn't *defined* in M. So it may try to execute the +examples in XYZclass's docstring, and those in turn may require a +different set of globals to work correctly. I prefer to do "import *"- +friendly imports, a la + +import XYY +_XYZclass = XYZ.XYZclass +del XYZ + +and then the leading underscore stops testmod from going nuts. You may +prefer the method in the next section. + + +WHAT'S THE EXECUTION CONTEXT? + +By default, each time testmod finds a docstring to test, it uses a +*copy* of M's globals (so that running tests on a module doesn't change +the module's real globals, and so that one test in M can't leave behind +crumbs that accidentally allow another test to work). This means +examples can freely use any names defined at top-level in M. It also +means that sloppy imports (see above) can cause examples in external +docstrings to use globals inappropriate for them. + +You can force use of your own dict as the execution context by passing +"globs=your_dict" to testmod instead. Presumably this would be a copy +of M.__dict__ merged with the globals from other imported modules. + + +WHAT IF I WANT TO TEST A WHOLE PACKAGE? + +Piece o' cake, provided the modules do their testing from docstrings. +Here's the test.python I use for the world's most elaborate Rational/ +floating-base-conversion pkg (which I'll distribute some day): + +from Rational import Cvt +from Rational import Format +from Rational import machprec +from Rational import Rat +from Rational import Round +from Rational import utils + +modules = (Cvt, + Format, + machprec, + Rat, + Round, + utils) + +def _test(): + import doctest + import sys + verbose = "-v" in sys.argv + for mod in modules: + doctest.testmod(mod, verbose=verbose, report=0) + doctest.master.summarize() + +if __name__ == "__main__": + _test() + +IOW, it just runs testmod on all the pkg modules. testmod remembers the +names and outcomes (# of failures, # of tries) for each item it's seen, +and passing "report=0" prevents it from printing a summary in verbose +mode. Instead, the summary is delayed until all modules have been +tested, and then "doctest.master.summarize()" forces the summary at the +end. + +So this is very nice in practice: each module can be tested individually +with almost no work beyond writing up docstring examples, and collections +of modules can be tested too as a unit with no more work than the above. + + +WHAT ABOUT EXCEPTIONS? + +No problem, as long as the only output generated by the example is the +traceback itself. For example: + + >>> 1/0 + Traceback (innermost last): + File "", line 1, in ? + ZeroDivisionError: integer division or modulo + >>> + +Note that only the exception type and value are compared (specifically, +only the last line in the traceback). + + +ADVANCED USAGE + +doctest.testmod() captures the testing policy I find most useful most +often. You may want other policies. + +testmod() actually creates a local obj of class doctest.Tester, +runs appropriate methods of that class, and merges the results into +global Tester obj doctest.master. + +You can create your own instances of doctest.Tester, and so build your +own policies, or even run methods of doctest.master directly. See +doctest.Tester.__doc__ for details. + + +SO WHAT DOES A DOCSTRING EXAMPLE LOOK LIKE ALREADY!? + +Oh ya. It's easy! In most cases a copy-and-paste of an interactive +console session works fine -- just make sure the leading whitespace +is rigidly consistent (you can mix tabs and spaces if you're too lazy +to do it right, but doctest is not in the business of guessing what +you think a tab means). + + >>> # comments are ignored + >>> x = 12 + >>> x + 12 + >>> if x == 13: + ... print "yes" + ... else: + ... print "no" + ... print "NO" + ... print "NO!!!" + ... + no + NO + NO!!! + >>> + +Any expected output must immediately follow the final ">>>" or "..." +line containing the code, and the expected output (if any) extends +to the next ">>>" or all-whitespace line. That's it. + +Bummers: + ++ Expected output cannot contain an all-whitespace line, since such a + line is taken to signal the end of expected output. + ++ Output to stdout is captured, but not output to stderr (exception + tracebacks are captured via a different means). + ++ If you continue a line via backslashing in an interactive session, + or for any other reason use a backslash, you need to double the + backslash in the docstring version. This is simply because you're + in a string, and so the backslash must be escaped for it to survive + intact. Like: + +>>> if "yes" == \\ +... "y" + \\ +... "es": # in the source code you'll see the doubled backslashes +... print 'yes' +yes + +The starting column doesn't matter: + +>>> assert "Easy!" + >>> import math + >>> math.floor(1.9) + 1.0 + +and as many leading whitespace characters are stripped from the expected +output as appeared in the initial ">>>" line that triggered it. + +If you execute this very file, the examples above will be found and +executed, leading to this output in verbose mode: + +Running doctest.__doc__ +Trying: 1/0 +Expecting: +Traceback (innermost last): + File "", line 1, in ? +ZeroDivisionError: integer division or modulo +ok +Trying: x = 12 +Expecting: nothing +ok +Trying: x +Expecting: 12 +ok +Trying: +if x == 13: + print "yes" +else: + print "no" + print "NO" + print "NO!!!" +Expecting: +no +NO +NO!!! +ok +... and a bunch more like that, with this summary at the end: + +5 items had no tests: + doctest.Tester.__init__ + doctest.Tester.run__test__ + doctest.Tester.summarize + doctest.run_docstring_examples + doctest.testmod +12 items passed all tests: + 8 tests in doctest + 6 tests in doctest.Tester + 10 tests in doctest.Tester.merge + 7 tests in doctest.Tester.rundict + 3 tests in doctest.Tester.rundoc + 3 tests in doctest.Tester.runstring + 2 tests in doctest.__test__._TestClass + 2 tests in doctest.__test__._TestClass.__init__ + 2 tests in doctest.__test__._TestClass.get + 1 tests in doctest.__test__._TestClass.square + 2 tests in doctest.__test__.string + 7 tests in doctest.is_private +53 tests in 17 items. +53 passed and 0 failed. +Test passed. +""" + +# 0,0,1 06-Mar-1999 +# initial version posted +# 0,0,2 06-Mar-1999 +# loosened parsing: +# cater to stinkin' tabs +# don't insist on a blank after PS2 prefix +# so trailing "... " line from a compound stmt no longer +# breaks if the file gets whitespace-trimmed +# better error msgs for inconsistent leading whitespace +# 0,9,1 08-Mar-1999 +# exposed the Tester class and added client methods +# plus docstring examples of their use (eww - head-twisting!) +# fixed logic error in reporting total # of tests & failures +# added __test__ support to testmod (a pale reflection of Christian +# Tismer's vision ...) +# removed the "deep" argument; fiddle __test__ instead +# simplified endcase logic for extracting tests, and running them. +# before, if no output was expected but some was produced +# anyway via an eval'ed result, the discrepancy wasn't caught +# made TestClass private and used __test__ to get at it +# many doc updates +# speed _SpoofOut for long expected outputs +# 0,9,2 09-Mar-1999 +# throw out comments from examples, enabling use of the much simpler +# exec compile(... "single") ... +# for simulating the runtime; that barfs on comment-only lines +# used the traceback module to do a much better job of reporting +# exceptions +# run __doc__ values thru str(), "just in case" +# privateness of names now determined by an overridable "isprivate" +# function +# by default a name now considered to be private iff it begins with +# an underscore but doesn't both begin & end with two of 'em; so +# e.g. class_t.__init__ etc are searched now -- as they always +# should have been +# 0,9,3 18-Mar-1999 +# added .flush stub to _SpoofOut (JPython buglet diagnosed by +# Hugh Emberson) +# repaired ridiculous docs about backslashes in examples +# minor internal changes +# changed source to Unix line-end conventions +# moved __test__ logic into new Tester.run__test__ method +# 0,9,4 27-Mar-1999 +# report item name and line # in failing examples +# 0,9,5 29-Jun-1999 +# allow straightforward exceptions in examples - thanks to Mark Hammond! +# 0,9,5,1 31-Mar-2000 +# break cyclic references to functions which are defined in docstrings, +# avoiding cyclic trash +# 0,9,5,2 11-Apr-2000 +# made module argument to testmod optional; it runs testmod on the __main__ +# module in that case. + +__version__ = 0, 9, 5 + +import types +_FunctionType = types.FunctionType +_ClassType = types.ClassType +_ModuleType = types.ModuleType +_StringType = types.StringType +del types + +import string +_string_find = string.find +_string_join = string.join +_string_split = string.split +_string_rindex = string.rindex +del string + +import re +PS1 = ">>>" +PS2 = "..." +_isPS1 = re.compile(r"(\s*)" + re.escape(PS1)).match +_isPS2 = re.compile(r"(\s*)" + re.escape(PS2)).match +_isEmpty = re.compile(r"\s*$").match +_isComment = re.compile(r"\s*#").match +del re + +# Extract interactive examples from a string. Return a list of triples, +# (source, outcome, lineno). "source" is the source code, and ends +# with a newline iff the source spans more than one line. "outcome" is +# the expected output if any, else an empty string. When not empty, +# outcome always ends with a newline. "lineno" is the line number, +# 0-based wrt the start of the string, of the first source line. + +def _extract_examples(s): + isPS1, isPS2 = _isPS1, _isPS2 + isEmpty, isComment = _isEmpty, _isComment + examples = [] + lines = _string_split(s, "\n") + i, n = 0, len(lines) + while i < n: + line = lines[i] + i = i + 1 + m = isPS1(line) + if m is None: + continue + j = m.end(0) # beyond the prompt + if isEmpty(line, j) or isComment(line, j): + # a bare prompt or comment -- not interesting + continue + lineno = i - 1 + if line[j] != " ": + raise ValueError("line " + `lineno` + " of docstring lacks " + "blank after " + PS1 + ": " + line) + j = j + 1 + blanks = m.group(1) + nblanks = len(blanks) + # suck up this and following PS2 lines + source = [] + while 1: + source.append(line[j:]) + line = lines[i] + m = isPS2(line) + if m: + if m.group(1) != blanks: + raise ValueError("inconsistent leading whitespace " + "in line " + `i` + " of docstring: " + line) + i = i + 1 + else: + break + if len(source) == 1: + source = source[0] + else: + # get rid of useless null line from trailing empty "..." + if source[-1] == "": + del source[-1] + source = _string_join(source, "\n") + "\n" + # suck up response + if isPS1(line) or isEmpty(line): + expect = "" + else: + expect = [] + while 1: + if line[:nblanks] != blanks: + raise ValueError("inconsistent leading whitespace " + "in line " + `i` + " of docstring: " + line) + expect.append(line[nblanks:]) + i = i + 1 + line = lines[i] + if isPS1(line) or isEmpty(line): + break + expect = _string_join(expect, "\n") + "\n" + examples.append( (source, expect, lineno) ) + return examples + +# Capture stdout when running examples. + +class _SpoofOut: + def __init__(self): + self.clear() + def write(self, s): + self.buf.append(s) + def get(self): + return _string_join(self.buf, "") + def clear(self): + self.buf = [] + def flush(self): + # JPython calls flush + pass + +# Display some tag-and-msg pairs nicely, keeping the tag and its msg +# on the same line when that makes sense. + +def _tag_out(printer, *tag_msg_pairs): + for tag, msg in tag_msg_pairs: + printer(tag + ":") + msg_has_nl = msg[-1:] == "\n" + msg_has_two_nl = msg_has_nl and \ + _string_find(msg, "\n") < len(msg) - 1 + if len(tag) + len(msg) < 76 and not msg_has_two_nl: + printer(" ") + else: + printer("\n") + printer(msg) + if not msg_has_nl: + printer("\n") + +# Run list of examples, in context globs. "out" can be used to display +# stuff to "the real" stdout, and fakeout is an obj of _SpoofOut +# that captures the examples' std output. Return (#failures, #tries). + +def _run_examples_inner(out, fakeout, examples, globs, verbose, name): + import sys, traceback + OK, BOOM, FAIL = range(3) + NADA = "nothing" + stderr = _SpoofOut() + failures = 0 + for source, want, lineno in examples: + if verbose: + _tag_out(out, ("Trying", source), + ("Expecting", want or NADA)) + fakeout.clear() + try: + exec compile(source, "", "single") in globs + got = fakeout.get() + state = OK + except: + # See whether the exception was expected. + if _string_find(want, "Traceback (innermost last):\n") == 0: + # Only compare exception type and value - the rest of + # the traceback isn't necessary. + want = _string_split(want, '\n')[-2] + '\n' + exc_type, exc_val, exc_tb = sys.exc_info() + got = traceback.format_exception_only(exc_type, exc_val)[0] + state = OK + else: + # unexpected exception + stderr.clear() + traceback.print_exc(file=stderr) + state = BOOM + + if state == OK: + if got == want: + if verbose: + out("ok\n") + continue + state = FAIL + + assert state in (FAIL, BOOM) + failures = failures + 1 + out("*" * 65 + "\n") + _tag_out(out, ("Failure in example", source)) + out("from line #" + `lineno` + " of " + name + "\n") + if state == FAIL: + _tag_out(out, ("Expected", want or NADA), ("Got", got)) + else: + assert state == BOOM + _tag_out(out, ("Exception raised", stderr.get())) + return failures, len(examples) + +# Run list of examples, in context globs. Return (#failures, #tries). + +def _run_examples(examples, globs, verbose, name): + import sys + saveout = sys.stdout + try: + sys.stdout = fakeout = _SpoofOut() + x = _run_examples_inner(saveout.write, fakeout, examples, + globs, verbose, name) + finally: + sys.stdout = saveout + return x + +def run_docstring_examples(f, globs, verbose=0, name="NoName"): + """f, globs, verbose=0, name="NoName" -> run examples from f.__doc__. + + Use dict globs as the globals for execution. + Return (#failures, #tries). + + If optional arg verbose is true, print stuff even if there are no + failures. + Use string name in failure msgs. + """ + + try: + doc = f.__doc__ + if not doc: + # docstring empty or None + return 0, 0 + # just in case CT invents a doc object that has to be forced + # to look like a string <0.9 wink> + doc = str(doc) + except: + return 0, 0 + + e = _extract_examples(doc) + if not e: + return 0, 0 + return _run_examples(e, globs, verbose, name) + +def is_private(prefix, base): + """prefix, base -> true iff name prefix + "." + base is "private". + + Prefix may be an empty string, and base does not contain a period. + Prefix is ignored (although functions you write conforming to this + protocol may make use of it). + Return true iff base begins with an (at least one) underscore, but + does not both begin and end with (at least) two underscores. + + >>> is_private("a.b", "my_func") + 0 + >>> is_private("____", "_my_func") + 1 + >>> is_private("someclass", "__init__") + 0 + >>> is_private("sometypo", "__init_") + 1 + >>> is_private("x.y.z", "_") + 1 + >>> is_private("_x.y.z", "__") + 0 + >>> is_private("", "") # senseless but consistent + 0 + """ + + return base[:1] == "_" and not base[:2] == "__" == base[-2:] + +class Tester: + """class_t Tester -- runs docstring examples and accumulates stats. + +In normal use, function doctest.testmod() hides all this from you, +so use that if you can. Create your own instances of Tester to do +fancier things. + +Methods: + runstring(s, name) + Search string s for examples to run; use name for logging. + Return (#failures, #tries). + + rundoc(object, name=None) + Search object.__doc__ for examples to run; use name (or + object.__name__) for logging. Return (#failures, #tries). + + rundict(d, name) + Search for examples in docstrings in all of d.values(); use name + for logging. Return (#failures, #tries). + + run__test__(d, name) + Treat dict d like module.__test__. Return (#failures, #tries). + + summarize(verbose=None) + Display summary of testing results, to stdout. Return + (#failures, #tries). + + merge(other) + Merge in the test results from Tester obj "other". + +>>> from doctest import Tester +>>> t = Tester(globs={'x': 42}, verbose=0) +>>> t.runstring(r''' +... >>> x = x * 2 +... >>> print x +... 42 +... ''', 'XYZ') +***************************************************************** +Failure in example: print x +from line #2 of XYZ +Expected: 42 +Got: 84 +(1, 2) +>>> t.runstring(">>> x = x * 2\\n>>> print x\\n84\\n", 'example2') +(0, 2) +>>> t.summarize() +1 items had failures: + 1 of 2 in XYZ +***Test Failed*** 1 failures. +(1, 4) +>>> t.summarize(verbose=1) +1 items passed all tests: + 2 tests in example2 +1 items had failures: + 1 of 2 in XYZ +4 tests in 2 items. +3 passed and 1 failed. +***Test Failed*** 1 failures. +(1, 4) +>>> +""" + + def __init__(self, mod=None, globs=None, verbose=None, + isprivate=None): + """mod=None, globs=None, verbose=None, isprivate=None + +See doctest.__doc__ for an overview. + +Optional keyword arg "mod" is a module, whose globals are used for +executing examples. If not specified, globs must be specified. + +Optional keyword arg "globs" gives a dict to be used as the globals +when executing examples; if not specified, use the globals from +module mod. + +In either case, a copy of the dict is used for each docstring +examined. + +Optional keyword arg "verbose" prints lots of stuff if true, only +failures if false; by default, it's true iff "-v" is in sys.argv. + +Optional keyword arg "isprivate" specifies a function used to determine +whether a name is private. The default function is doctest.is_private; +see its docs for details. +""" + + if mod is None and globs is None: + raise TypeError("Tester.__init__: must specify mod or globs") + if mod is not None and type(mod) is not _ModuleType: + raise TypeError("Tester.__init__: mod must be a module; " + + `mod`) + if globs is None: + globs = mod.__dict__ + self.globs = globs + + if verbose is None: + import sys + verbose = "-v" in sys.argv + self.verbose = verbose + + if isprivate is None: + isprivate = is_private + self.isprivate = isprivate + + self.name2ft = {} # map name to (#failures, #trials) pair + + def runstring(self, s, name): + """ + s, name -> search string s for examples to run, logging as name. + + Use string name as the key for logging the outcome. + Return (#failures, #examples). + + >>> t = Tester(globs={}, verbose=1) + >>> test = r''' + ... # just an example + ... >>> x = 1 + 2 + ... >>> x + ... 3 + ... ''' + >>> t.runstring(test, "Example") + Running string Example + Trying: x = 1 + 2 + Expecting: nothing + ok + Trying: x + Expecting: 3 + ok + 0 of 2 examples failed in string Example + (0, 2) + """ + + if self.verbose: + print "Running string", name + f = t = 0 + e = _extract_examples(s) + if e: + globs = self.globs.copy() + f, t = _run_examples(e, globs, self.verbose, name) + globs.clear() # DWA - break cyclic references to functions defined in docstrings + if self.verbose: + print f, "of", t, "examples failed in string", name + self.__record_outcome(name, f, t) + return f, t + + def rundoc(self, object, name=None): + """ + object, name=None -> search object.__doc__ for examples to run. + + Use optional string name as the key for logging the outcome; + by default use object.__name__. + Return (#failures, #examples). + If object is a class object, search recursively for method + docstrings too. + object.__doc__ is examined regardless of name, but if object is + a class, whether private names reached from object are searched + depends on the constructor's "isprivate" argument. + + >>> t = Tester(globs={}, verbose=0) + >>> def _f(): + ... '''Trivial docstring example. + ... >>> assert 2 == 2 + ... ''' + ... return 32 + ... + >>> t.rundoc(_f) # expect 0 failures in 1 example + (0, 1) + """ + + if name is None: + try: + name = object.__name__ + except AttributeError: + raise ValueError("Tester.rundoc: name must be given " + "when object.__name__ doesn't exist; " + `object`) + if self.verbose: + print "Running", name + ".__doc__" + globs = self.globs.copy() + f, t = run_docstring_examples(object, globs, + self.verbose, name) + globs.clear() # DWA - break cyclic references to functions defined in docstrings + + if self.verbose: + print f, "of", t, "examples failed in", name + ".__doc__" + self.__record_outcome(name, f, t) + if type(object) is _ClassType: + f2, t2 = self.rundict(object.__dict__, name) + f = f + f2 + t = t + t2 + return f, t + + def rundict(self, d, name): + """ + d. name -> search for docstring examples in all of d.values(). + + For k, v in d.items() such that v is a function or class, + do self.rundoc(v, name + "." + k). Whether this includes + objects with private names depends on the constructor's + "isprivate" argument. + Return aggregate (#failures, #examples). + + >>> def _f(): + ... '''>>> assert 1 == 1 + ... ''' + >>> def g(): + ... '''>>> assert 2 != 1 + ... ''' + >>> d = {"_f": _f, "g": g} + >>> t = Tester(globs={}, verbose=0) + >>> t.rundict(d, "rundict_test") # _f is skipped + (0, 1) + >>> t = Tester(globs={}, verbose=0, isprivate=lambda x,y: 0) + >>> t.rundict(d, "rundict_test_pvt") # both are searched + (0, 2) + """ + + if not hasattr(d, "items"): + raise TypeError("Tester.rundict: d must support .items(); " + + `d`) + f = t = 0 + for thisname, value in d.items(): + if type(value) in (_FunctionType, _ClassType): + f2, t2 = self.__runone(value, name + "." + thisname) + f = f + f2 + t = t + t2 + return f, t + + def run__test__(self, d, name): + """d, name -> Treat dict d like module.__test__. + + Return (#failures, #tries). + See testmod.__doc__ for details. + """ + + failures = tries = 0 + prefix = name + "." + savepvt = self.isprivate + try: + self.isprivate = lambda *args: 0 + for k, v in d.items(): + thisname = prefix + k + if type(v) is _StringType: + f, t = self.runstring(v, thisname) + elif type(v) in (_FunctionType, _ClassType): + f, t = self.rundoc(v, thisname) + else: + raise TypeError("Tester.run__test__: values in " + "dict must be strings, functions " + "or classes; " + `v`) + failures = failures + f + tries = tries + t + finally: + self.isprivate = savepvt + return failures, tries + + def summarize(self, verbose=None): + """ + verbose=None -> summarize results, return (#failures, #tests). + + Print summary of test results to stdout. + Optional arg 'verbose' controls how wordy this is. By + default, use the verbose setting established by the + constructor. + """ + + if verbose is None: + verbose = self.verbose + notests = [] + passed = [] + failed = [] + totalt = totalf = 0 + for x in self.name2ft.items(): + name, (f, t) = x + assert f <= t + totalt = totalt + t + totalf = totalf + f + if t == 0: + notests.append(name) + elif f == 0: + passed.append( (name, t) ) + else: + failed.append(x) + if verbose: + if notests: + print len(notests), "items had no tests:" + notests.sort() + for thing in notests: + print " ", thing + if passed: + print len(passed), "items passed all tests:" + passed.sort() + for thing, count in passed: + print " %3d tests in %s" % (count, thing) + if failed: + print len(failed), "items had failures:" + failed.sort() + for thing, (f, t) in failed: + print " %3d of %3d in %s" % (f, t, thing) + if verbose: + print totalt, "tests in", len(self.name2ft), "items." + print totalt - totalf, "passed and", totalf, "failed." + if totalf: + print "***Test Failed***", totalf, "failures." + elif verbose: + print "Test passed." + return totalf, totalt + + def merge(self, other): + """ + other -> merge in test results from the other Tester obj. + + If self and other both have a test result for something + with the same name, the (#failures, #tests) results are + summed, and a warning is printed to stdout. + + >>> from doctest import Tester + >>> t1 = Tester(globs={}, verbose=0) + >>> t1.runstring(''' + ... >>> x = 12 + ... >>> print x + ... 12 + ... ''', "t1example") + (0, 2) + >>> + >>> t2 = Tester(globs={}, verbose=0) + >>> t2.runstring(''' + ... >>> x = 13 + ... >>> print x + ... 13 + ... ''', "t2example") + (0, 2) + >>> common = ">>> assert 1 + 2 == 3\\n" + >>> t1.runstring(common, "common") + (0, 1) + >>> t2.runstring(common, "common") + (0, 1) + >>> t1.merge(t2) + *** Tester.merge: 'common' in both testers; summing outcomes. + >>> t1.summarize(1) + 3 items passed all tests: + 2 tests in common + 2 tests in t1example + 2 tests in t2example + 6 tests in 3 items. + 6 passed and 0 failed. + Test passed. + (0, 6) + >>> + """ + + d = self.name2ft + for name, (f, t) in other.name2ft.items(): + if d.has_key(name): + print "*** Tester.merge: '" + name + "' in both" \ + " testers; summing outcomes." + f2, t2 = d[name] + f = f + f2 + t = t + t2 + d[name] = f, t + + def __record_outcome(self, name, f, t): + if self.name2ft.has_key(name): + print "*** Warning: '" + name + "' was tested before;", \ + "summing outcomes." + f2, t2 = self.name2ft[name] + f = f + f2 + t = t + t2 + self.name2ft[name] = f, t + + def __runone(self, target, name): + if "." in name: + i = _string_rindex(name, ".") + prefix, base = name[:i], name[i+1:] + else: + prefix, base = "", base + if self.isprivate(prefix, base): + return 0, 0 + return self.rundoc(target, name) + +master = None + +def testmod(m=None, name=None, globs=None, verbose=None, isprivate=None, + report=1): + """m=None, name=None, globs=None, verbose=None, isprivate=None, report=1 + + Test examples in docstrings in functions and classes reachable from + module m, starting with m.__doc__. Private names are skipped. + + Also test examples reachable from dict m.__test__ if it exists and is + not None. m.__dict__ maps names to functions, classes and strings; + function and class docstrings are tested even if the name is private; + strings are tested directly, as if they were docstrings. + + Return (#failures, #tests). + + See doctest.__doc__ for an overview. + + Optional keyword arg "name" gives the name of the module; by default + use m.__name__. + + Optional keyword arg "globs" gives a dict to be used as the globals + when executing examples; by default, use m.__dict__. A copy of this + dict is actually used for each docstring, so that each docstring's + examples start with a clean slate. + + Optional keyword arg "verbose" prints lots of stuff if true, prints + only failures if false; by default, it's true iff "-v" is in sys.argv. + + Optional keyword arg "isprivate" specifies a function used to + determine whether a name is private. The default function is + doctest.is_private; see its docs for details. + + Optional keyword arg "report" prints a summary at the end when true, + else prints nothing at the end. In verbose mode, the summary is + detailed, else very brief (in fact, empty if all tests passed). + + Advanced tomfoolery: testmod runs methods of a local obj of + class doctest.Tester, then merges the results into (or creates) + global Tester obj doctest.master. Methods of doctest.master + can be called directly too, if you want to do something unusual. + Passing report=0 to testmod is especially useful then, to delay + displaying a summary. Invoke doctest.master.summarize(verbose) + when you're done fiddling. + """ + + global master + + if m is None: + import sys + # DWA - m will still be None if this wasn't invoked from the command + # line, in which case the following TypeError is about as good an error + # as we should expect + m = sys.modules.get('__main__') + + if type(m) is not _ModuleType: + raise TypeError("testmod: module required; " + `m`) + if name is None: + name = m.__name__ + tester = Tester(m, globs=globs, verbose=verbose, isprivate=isprivate) + failures, tries = tester.rundoc(m, name) + f, t = tester.rundict(m.__dict__, name) + failures = failures + f + tries = tries + t + if hasattr(m, "__test__"): + testdict = m.__test__ + if testdict: + if not hasattr(testdict, "items"): + raise TypeError("testmod: module.__test__ must support " + ".items(); " + `testdict`) + f, t = tester.run__test__(testdict, name + ".__test__") + failures = failures + f + tries = tries + t + if report: + tester.summarize() + if master is None: + master = tester + else: + master.merge(tester) + return failures, tries + +class _TestClass: + """ + A pointless class, for sanity-checking of docstring testing. + + Methods: + square() + get() + + >>> _TestClass(13).get() + _TestClass(-12).get() + 1 + >>> hex(_TestClass(13).square().get()) + '0xa9' + """ + + def __init__(self, val): + """val -> _TestClass object with associated value val. + + >>> t = _TestClass(123) + >>> print t.get() + 123 + """ + + self.val = val + + def square(self): + """square() -> square TestClass's associated value + + >>> _TestClass(13).square().get() + 169 + """ + + self.val = self.val ** 2 + return self + + def get(self): + """get() -> return TestClass's associated value. + + >>> x = _TestClass(-42) + >>> print x.get() + -42 + """ + + return self.val + +__test__ = {"_TestClass": _TestClass, + "string": r""" + Example of a string object, searched as-is. + >>> x = 1; y = 2 + >>> x + y, x * y + (3, 2) + """ + } + +def _test(): + import doctest + return doctest.testmod(doctest) + +if __name__ == "__main__": + _test() diff --git a/todo.txt b/todo.txt new file mode 100644 index 00000000..d97eade5 --- /dev/null +++ b/todo.txt @@ -0,0 +1,426 @@ +Check for const reference parameters in all from_python functions in py.h, including implementations. +Better python and C++ exception handling/error reporting. +long long support +use Python generic numeric coercion in from_python() for C++ numeric types +Rename PyPtr to Reference. +Report Cygwin linker memory issues +__init__ stuff + Make abstract classes non-instantiable (?) + Call default __init__ functions automatically where applicable (?) +Support for Python LONG types in Objects.h +Throw TypeError after asserting when objects from objects.cpp detect a type mismatch. +Figure out how to package everything as a shared library. +Unicode string support +Add read-only wrapper for __dict__ attribute +Objects.h support for generic objects, Sequence objects, etc. +empty() member functions for objects.hpp + +Testing + Python 2.0 + object revival in __del__ + More thorough tests of objects.h/cpp classes + Better reference-count checking + +Optimizations + Remove one level of indirection on type objects (no vtbl?). + Specializations of Caller<> for commmon combinations of argument types (?) + Replace uses of XXXable classes + Don't allocate instance __dict__ unless used. + + +Documentation: + + differences between Python classes and ExtensionClasses + additional capabilities of ExtensionClasses + slice adjustment + + Why special attributes other than __doc__ and __name__ are immutable. + + An example of the problems with the built-in Python classes. + + >>> class A: + ... def __getattr__(self, name): + ... return 'A.__getattr__' + ... + >>> class B(A): pass + ... + >>> class C(B): pass + ... + >>> C().x + 'A.__getattr__' + >>> B.__bases__ = () + >>> C().x + 'A.__getattr__' + + Smart pointers + #ifndef PY_NO_INLINE_FRIENDS_IN_NAMESPACE + namespace py { + #endif + + template + struct VtkConverters + { + typedef py::PyExtensionClassConverters Converters; + + friend vtk_ptr& from_python(PyObject* p, py::Type&>) + { return Converters::ptr_from_python(p, py::Type >()); } + + friend vtk_ptr& from_python(PyObject* p, py::Type >) + { return Converters::ptr_from_python(p, py::Type >()); } + + friend const vtk_ptr& from_python(PyObject* p, py::Type&>) + { return Converters::ptr_from_python(p, py::Type >()); } + + friend PyObject* to_python(vtk_ptr x) + { return Converters::ptr_to_python(x); } + }; + + #ifndef PY_NO_INLINE_FRIENDS_IN_NAMESPACE + } + #endif + + template + struct VtkWrapper : py::ClassWrapper, py::VtkConverters + { + typedef py::ClassWrapper Base; + VtkWrapper(Module& module, const char* name) + : Base(module, name) {} + }; + + exception handling + + Advanced Topics: + Advanced Type Conversion + adding conversions for fundamental types + generic conversions for template types (with partial spec). + + Interacting with built-in Python objects and types from C++ + + dealing with non-const reference/pointer parameters + + extending multiple-argument support using gen_all.py + + + Fancy wrapping tricks + templates + Yes. If you look at the examples in extclass_demo.cpp you'll see that I have + exposed several template instantiations (e.g. std::pair) in Python. + Keep in mind, however, that you can only expose a template instantiation, + not a template. In other words, MyTemplate can be exposed. MyTemplate + itself cannot. + + Well, that's not strictly true. Wow, this is more complicated to explain + than I thought. + You can't make an ExtensionClass, since after all MyTemplate is + not a type. You can only expose a concrete type to Python. + + What you *can* do (if your compiler supports partial ordering of function + templates - MSVC is broken and does not) is to write appropriate + from_python() and to_python() functions for converting a whole class of + template instantiations to/from Python. That won't let you create an + instance of MyTemplate from Python, but it will let you + pass/return arbitrary MyTemplate instances to/from your + wrapped C++ functions. + + template + MyTemplate from_python(PyObject* x, py::Type >) + { + // code to convert x into a MyTemplate... that part is up to you + } + + template + PyObject* from_python(const MyTemplate&) + { + // code to convert MyTemplate into a PyObject*... that part is up to + you + } + + For example, you could use this to convert Python lists to/from + std::vector automatically. + + Pointer return values + + Case 1: + + > I am now also able to wrap the problematic TextRecordIterator for Python. + > However, one of its function compiles with this warning: + > + > d:\py_cpp/caller.h(33) : warning C4800: 'const class Record *const ' + > : forcing value to bool 'true' or 'false' (performance warning) + > d:\py_cpp/functions.h(54) : see reference to function template + > instantiation 'struct _object *__cdecl py::Caller::call(const class Record + > *const (__thiscall TextRecordIterator::*)(void),struct _object *,struct + > _object *)' being compiled + > + > If you look at the offending code, you'll see that we really do need to + > get back that pointer: + > + > const Record* const TextRecordIterator::Next() { + > if (fStatus != RecordIterator::SUCCESS) { + > return 0; + > } else { + > return &fData; + > } + > } + > + > The point of the TextRecordIterator is to hand over one reord after + > another. A bool wouldn't do us much good here :-) + > + > Do you have any suggestions for fixing this? + + In general, py_cpp doesn't automatically convert pointer return values + to_python because pointers have too many potential meanings. Is it an + iterator? A pointer to a single element? An array? Is ownership being passed + to Python or is the pointer really just a reference? If the latter, what + happens when some C++ code deletes the referent. The only exception to this + rule is const char*, since it has a generally accepted interpretation (could + be trouble with some generic code, though!) + + If you have wrapped the Record class, you could add this to namespace py: + + PyObject* to_python(const Record* p) { + return to_python(*p); + } + + Of course, this will cause the Record class to be copied. If you can't live + with that (Record would have to be /really/ heavyweight to make this + worthwhile), you can follow one of these dangerous approaches: + + 1. Use the technique I described with dangerous_array in + http://www.egroups.com/message/boost/6196. You do not have to expose Record + explicitly in this case. Instead the class you expose will be more of a + Record_proxy + + 2. Wrap Record in the usual way, then add the following to namespace py: + + PyObject* to_python(const Record* p) + { + return ExtensionClass::ptr_to_python(const_cast(p)); + } + + This will cause the Record* to be treated as though it were an owning smart + pointer, even though it's not. Be sure you don't use the reference for + anything from Python once the pointer becomes invalid, though. Don't worry + too much about the const-correctness issue: Const-correctness is completely + lost to Python anyway! + + 3. As above, but instead wrap const Record rather than plain Record. Then + you can avoid the const_cast, but you obviously can't def() any non-const + member functions of Record. + + Case 2: + + > I have yet another question. This is more a general wrapper question. + > Let me say that there is a function that returns a float* which most + > probably is an array. Similarly if I have a function that takes a + > float* as an argument, what is the best way of wrapping this? + + I think you have correctly perceived that it doesn't make sense for me to + automatically convert all pointers, since the ownership semantics are so + blurry. + + > 1) If the array is small it makes sense to convert it to either a + > tuple or list. What is the easiest way to do this?? I am looking + > for a way that makes one write the least code. :) + + How can you tell the length of the array from a single pointer? + Once you've answered that question, you can expose a wrapper function which + returns an instance of the py::Tuple or py::List class from objects.h. If + you are using a List, for example, you could write something like this: + + py::List wrap_f() + { + T* start = f(); + py::List x; + for (T* p = start; p != start + length_constant; ++p) + x.push_back(py::to_python(*p)); + return x; + } + + > 2) If the array is large it may not make sense to use a list/tuple + > esp. if the values are used for computationally intense programs. + + In this case you can do one of several somewhat dangerous things. Why + dangerous? Because python can not control the lifetime of the data, so the + data in the array may be destroyed or become invalid before the last + reference to it disappears. The basic approach is to make a small C++ class + which contains the pointer, and expose that: + + // UNTESTED + template + struct dangerous_array + { + dangerous_array(T* start, T* end) + : m_start(start), m_end(end) {} + + // exposed as "__len__" + std::size_t length() { + return m_end - m_start; + } + + // exposed as "__getitem__" + T get_item(std::size_t n) { + check_range(n); + return start[n]; + } + + // exposed as "__setitem__" if the array is mutable + void set_item(std::size_t n, const T& x) { + check_range(n); + start[n] = x; + } + private: + void check_range(std::size_t n) { + if (n >= m_end - m_start) { + PyErr_SetString(PyExc_IndexError, "array index out of range"); + throw py::ErrorAlreadySet; + } + } + T* m_start; + T* m_end; + }; + + A reasonably safe approach would be to make a wrapper function for each + function that returns a T*, and expose that instead. If you're too lazy and + you really like to live on the edge, though, you can write to_python(T*) in + terms of to_python(const dangerous_array&), and you'll automatically + convert all T* return values to a wrapped dangerous_array. + + > 3) For an arbitrary class "class_A", say, can py_cpp handle + > references to class_A &instance, or class_A *instance?? i.e. will it + > wrap function calls to such objects? This question is obviously + > related to the earlier questions. + + Yes, iff class_A has been exposed to python with a ClassWrapper. + See http://people.ne.mediaone.net/abrahams/downloads/under-the-hood.html for + a few details. + + raw C++ arrays + You could expose a function like this one to get the desired effect: + + #include + void set_len(UnitCell& x, py::Tuple tuple) + { + double len[3]; + for (std::size_t i =0; i < 3; ++i) + len[i] = py::from_python(tuple[i].get(), py::Type()); + x.set_len(len); + } + + Types that are already wrapped by other libraries + + It's not documented yet, but you should be able to use a raw PyObject* or a + py::Ptr as one parameter to your C++ function. Then you can manipulate it as + any other generic Python object. + + Alternatively, If the NTL gives you a C/C++ interface, you can also write + your own converter function: + + some_ntl_type& from_python(PyObject* p, py::Type) + { + // an Example implementation. Basically, you need + // to extract the NTL type from the PyObject*. + if (p->ob_type != NTL_long_type) { + PyErr_SetString(PyExc_TypeErr, "NTL long required"); + throw py::ArgumentError(); + } + return *static_cast(p); + } + + then the C++ functions you're wrapping can take a some_NTL_type& parameter + directly. + + "Thin converting wrappers" for constructors + + hijack some of the functionality + described in the section on Overridable Virtual Functions (even though you + don't have any virtual functions). I suggest this workaround: + + struct UnitCellWrapper : UnitCell + { + UnitCellWrapper(PyObject* self, py::Tuple x, py::Tuple y) + : UnitCell(from_python(x[1], py::Type()), + from_python(x[2], py::Type()), + from_python(x[3], py::Type()), + from_python(y[1], py::Type()), + from_python(y[2], py::Type()), + from_python(y[3], py::Type())) + {} + } + + py::ClassWrapper unit_cell_class; + unit_cell_class.def(py::Constructor()); + ... + + returning references to wrapped objects + + the importance of declaration order of ClassWrappers/ExtensionInstances + + out parameters and non-const pointers + + Calling back into Python: + // caveat: UNTESTED! + #include + #include + #include + #include + int main() + { + try { + py::Ptr module(PyImport_ImportModule("weapons")); + const int strength = 10; + const char* manufacturer = "Vordon Empire"; + py::Ptr a_blaster(py::Callback::call_method( + module.get(), "Blaster", strength, manufacturer)); + py::Callback::call_method(a_blaster.get(), "Fire"); + int old_strength = py::Callback::call_method(a_blaster.get(), "get_strength"); + py::Callback::call_method(a_blaster.get(), "set_strength", 5); + } + catch(...) + { + } + } + + Miscellaneous + About the vc6 project and the debug build + About doctest.py + +Boost remarks: + + > > One of us is completely nuts ;->. How can I move the test + > > (is_prefix(enablers[i].name + 2, name + 2)) outside the loop if it + depends + > > on the loop index, i? + > > + > name += 2; + > for() + > { + > if (is_prefix(enablers[i].name + 2, name)) + > } + + I see now. I guess I should stop pussyfooting and either go for optimization + or clarity here, eh? + + ------ + + > Re: Dict + > Why abbreviate this? Code is read 5 or 6 times for every time its + > written. The few extra characters don't affect compile time or program + > speed. It's part of my personal goal of write what you mean, name them + what + > they are. + + I completely agree. Abbrevs rub me the wrong way, 2 ;-> + + ------- + + + + +Later: + keyword and varargs? + Put explicit Type<> arguments at the beginnings of overloads, to make them look more like template instance specifications. + +Known bugs + can't handle 'const void' return values + Who returns 'const void'? I did it once, by mistake ;)