簡體 English 中英

使用C / C ++擴展Python

[英]Extending Python with C/C++

原文 2009-07-02 19:42:30 6 9 c++/ python/ c

任何人都可以給我一些關於用C / C ++擴展Python的工具或軟件的技巧嗎？ 謝謝。

9 個解決方案

Python網站本身有很多示例，以及API文檔。 這就是我在需要編寫C擴展時使用的所有內容。

我將為Boost.Python添加對C ++內容的強制性引用。

我們使用SWIG來包裝我們的C / C ++庫以便在Python中使用。 它運作得很好。

http://www.swig.org/

我看到沒有人指出我最喜歡的包裝C ++代碼的解決方案之一， SIP （我相信它也適用於包裝C，如SWIG和Boost不同，但我從未使用過這種方式）。 這是Riverbank軟件開發的工具PyQt，它是美妙的Qt C ++跨平台框架的Python接口 - 所以如果您的C ++代碼使用任何Qt功能，它就是一個自然的選擇，就像Boost Python是C ++代碼的自然選擇一樣使用Boost。

SWIG是我們在工作中使用的（10年前制定的合理決策;-)並且具有理論上的優勢，它還可以包裝C或C ++代碼以供Java，Perl，Tcl等使用 - 但是如果你只關心Python，很難看到任何讓它脫穎而出的東西。

如果你只是包裝一個現有的DLL /，除了Cython，其他答案已經指出了（我贊同，但是 - 它現在變化非常快，所以如果你需要更穩定的東西，請注意），考慮標准函數模塊ctypes - 我不會將它用於非常廣泛的工作（C或C ++編譯器指出的“oops”錯誤會導致運行時崩潰與ctypes），但是對於小型工作來說它很棒（並且非常方便，因為它帶有標准的Python發行版！ - ）。

好的舊C API還沒有死 - 今天剛剛遇到了Case，這位偉大的家伙最近為我的老式開源項目gmpy做了大部分的操作，我們一起決定堅持使用C API至少gmpy的下一個版本 - 我們會考慮在穩定時切換到Cython，但我們同意現在的轉換仍然有點為時過早。 （我們甚至沒有想到任何其他選擇，因為gmpy的主要觀點是盡可能快地制造它！ - ）。

有很多解決方案。 一般來說，如果可能的話，你應該避免使用它，因為編寫C擴展是很乏味的。 通常，有必要使用第三方庫。 在這種情況下，我認為今天的成功解決方案是cython 。

Cython是一種“看起來像python”的語言，但通過使用可選的輸入可以更快地制作。 你可以在里面直接調用C函數，並且大多數引用計數（C擴展中的難題）都是自動完成的。 根據我的經驗，它比boost.python，swig或ctypes要好得多：

boost.python只適用於包裝C ++擴展IMHO。 我發現它太復雜了，當出現問題時很難調試。
swig有一些開銷，並沒有導致良好的代碼。 它適用於幾個函數，但非平凡的擴展通常使用類型映射，語法很快就會變得難看

使用cython，您可以使用python對象（list，dict等...）來包裝您的C庫。 當然，如果您出於速度原因需要編寫自己的擴展，它也非常有用。 在科學python社區，我認為cython已成為需要速度時的首選工具。

我過去使用過pycxx ，我非常喜歡使用這個庫。

在我看來，它比SWIG更容易使用。 我無法與boost.python進行比較，因為我從未真正使用過boost。 我認為pycxx比boost.python輕，但我可能錯了。

pycxx的關鍵點在於它是python c api的c ++包裝器。 它是面向對象的，它隱藏了所有困難的機制。 這對python程序員來說非常直觀。 它非常易於使用，並且有一些很好的入門示例。

我建議pycxx作為在c ++中進行python擴展的一等公民。

是的，你需要這個： http ： //www.python.org/doc/ext/

當然還有一個C / C ++編譯器。

如果你描述你想要做什么，以及你正在做什么樣的擴展，我相信人們可以給你更多的信息。

有一些像SWIG這樣的東西來包裝庫，如果你想做的話。 如果你只想要加速，C往往是答案，但並非總是如此等。

我很驚訝沒有人提到過pybind11 。 Pybind11 太神奇了！

從他們的文檔：

pybind11是一個輕量級的僅限頭的庫，它在Python中公開C ++類型，反之亦然，主要是為了創建現有C ++代碼的Python綁定。 它的目標和語法類似於David Abrahams的優秀Boost.Python庫：通過使用編譯時自省推斷類型信息來最小化傳統擴展模塊中的樣板代碼。

...