無需安裝Python，就可以在.NET里調用Python庫

Pythonnet這個屌爆的項目的出現，使得我們可以用一種新的方式，讓C#可以和Python之間進行互操作。但是它的設置和部署可能有點問題，真的是這樣嗎？

本文我會介紹Python.Included這個項目，它不但優雅的解決了這個問題，并且讓.NET開發者可以輕松愉快的讓.NET與Python進行互操作。作為概念的證明，我將使用Numpy.Net進行展示，它是一個.NET標準庫，它為Python的Numpy提供了一個強類型API，并且使用它并不需要在Windows上安裝Python。

開發人員從Numpy.NET的強類型API中獲益，與動態API不同，后者支持Visual Studio的IntelliSense功能，可以顯示原始的Numpy文檔。

問題是什么？

每個人可能都安裝了不同版本的Python，有一些人用Python 2.7，其他一些人用Python 3.5，3.6甚至3.7。當你使用pythonnet的時候，針對Python的每個小版本，它必須使用不同的配置進行編譯，而且該版本的Python必須安裝，這樣代碼才可以運行。所以如果你在團隊里工作，每個人就必須配置完全相同的Python環境。但拿我們的SciSharp團隊來說，情況就已經不是這樣的了。如果你想部署你的.NET應用，你首先必須部署Python，從開發人員角度來講，這很鬧心。

然而，如果你正在搞機器學習和人工智能，盡管微軟和SciSharp都付出了很大努力，但目前你還是無法完全避免Python的使用。如果你看一下正在使用pythonnet的項目的列表，你會發現很多AI領域的公司當前都在使用.NET與Python進行連接。

Python.Included 前來救援

如果你可以很簡單的引用一個Nuget包，并在無需手動修改的情況下，一切都會自動的配置好，假如可以達到這種程度，你會感覺怎么樣？這就是我創建Python.Included的愿景，Python.Included可以把packages python-3.7.3-embed-amd64.zip包含在它的程序集里，這這樣就允許你可以通過Nuget來有效的引用Python了。為了證明它能正常工作，并可以快速提供所有的NumSharp中仍然缺少的Numpy功能，我創建了基于Python.Included的Numpy.NET這個項目。

概念驗證：Numpy.NET

Numpy.NET為Numpy提供了強類型的包裝函數，這意味著您完全不需要使用dynamic關鍵字，但這部分我會在另一篇文章中深入討論。今天的重點是介紹 Numpy.NET 如何使用 Python.Included 來按需自動部署Python和Numpy以便對它們進行調用。

這是Numpy將在幕后實際執行的設置代碼。這些都不需要你來操作。一旦你使用了它的一個函數：

var a = np.array(new [,] {{1, 2}, {3, 4}});,

Numpy.dll 就會設置好嵌入的Python發行版，而它是從你本機home目錄里的程序集里解壓縮出來的（如果還沒安裝過的話）。

var installer = new Python.Included.Installer();
installer.SetupPython(force:false).Wait();

下一步（如果在之前的運行中還沒完成）它將解壓縮 numpy pip wheel，而numpy pip wheel 是作為嵌入的資源打包到了Numpy.dll里的并其安裝到了Python安裝文件里。

installer.InstallWheel(typeof(NumPy).Assembly, "numpy-1.16.3-cp37-cp37m-win_amd64.whl").Wait();

最后，pythonnet運行時被初始化了，Numpy也被導入進來了，可供后續使用。

PythonEngine.Initialize();
Py.Import("numpy");

這些都是在幕后發生的，使用Numpy.dll的用戶根本不用擔心本地的Python安裝。事實上，即使您已安裝了任何版本的Python也無所謂。

性能注意事項

大家都知道pythonnet比較慢，因此您可能會問自己，使用pythonnet將Python庫與.NET接在一起是否真的是一個好主意。一如既往，這要看情況而定。

我的測試結果表明，與直接從Python調用Numpy相比，使用.net調用numpy的開銷大約是它的4倍。需要澄清一下，這并不意味著Numpy.NET比python中的numpy慢四倍，這僅僅意味著通過pythonnet調用Numpy會有額外的開銷。當然了，由于Numpy.NET調用的是Numpy，Numpy函數本身的執行時間是完全相同的。

開銷是否是一個問題完全取決于實際用例。如果您在一個嵌套循環中不斷的在CLR和Python之間來回切換，那就可能會遇到問題。但大多數Python庫的設計都都是為了提高效率，避免數據循環。Numpy允許您只使用一個調用就可以對數百萬的數組元素進行操作。Pytorch和Tensorflow允許您完全在GPU上執行操作。因此，如果正確使用，與處理大量數據時操作的執行時間相比，互操作開銷可以忽略不計。

路線圖

我知道現在有很多把Numpy移植到.NET上的方案和項目，例如使用IronPython。但是IronPython項目仍然只支持Python 2.7，而且項目進展非常緩慢。這就導致了依賴于python 3的庫不能通過IronPython來獲得和使用，而且這種情況在近期也不會有什么改變。

我的重點是通過pythonnet為.NET提供更多的機器學習和人工智能庫。SciSharp團隊也在討論如何研發出一個更快版本的pythonnet，從而避免使用天性緩慢的DynamicObject。

請嘗試一下Numpy.NET，并讓我知道它為你做了什么并且做的如何。如果有任何意見或建議，我將不勝感激，我希望我的工作能夠幫助.NET機器學習社區成長和繁榮。