16 Aug: My second article: From Scripts To Prediction API

8月16日：我的第二篇文章： 從腳本到預(yù)測(cè)API

As advanced beginners, we know quite a lot: EDA, ML concepts, model architectures etc…… We can write a big Jupyter Notebook, click “Restart & Run All” and generate state-of-art results. OK, what next? How can others use/reproduce/scale your results?

作為高級(jí)初學(xué)者，我們了解很多：EDA，ML概念，模型體系結(jié)構(gòu)等……我們可以編寫一個(gè)大型的Jupyter Notebook，單擊“重新啟動(dòng)并全部運(yùn)行”并生成最新的結(jié)果。 好，接下來呢？ 其他人如何使用/復(fù)制/縮放結(jié)果？

In this article, I will show you how I convert a Jupyter Notebook from Kaggle on the Wine dataset to scripts, share some engineering practices that we can adapt easily and bring benefits right away.

在本文中，我將向您展示如何將Jupyter Notebook從Wine數(shù)據(jù)集上的Kaggle轉(zhuǎn)換為腳本，分享一些我們可以輕松適應(yīng)并立即帶來收益的工程實(shí)踐。

For each of them, there is much more to dig in but we will only surface with the basics, show the benefits, and explain the thought process! The goal is to minimize the probability that the engineers roll their eyes when they talk to you.

對(duì)于他們每個(gè)人，還有很多需要挖掘的東西，但是我們只會(huì)浮現(xiàn)基礎(chǔ)知識(shí)，展示收益并解釋思想過程！ 目的是最大程度地降低工程師與您交談時(shí)翻白眼的可能性。

Jupyter筆記本 (Jupyter Notebook)

Jupyter Notebook is nice for exploration and prototype but we cannot stay there forever. No engineers [Or no one] wants to read your code and rewrite it. Even you are fortunate enough to have engineering resources, it just slows the whole process down🙁

Jupyter Notebook非常適合用于探索和原型制作，但我們不能永遠(yuǎn)呆在那里。 沒有工程師(或者沒有人)想要閱讀您的代碼并重寫它。 即使您幸運(yùn)地?fù)碛泄こ藤Y源，也只會(huì)減慢整個(gè)過程的速度🙁

Somehow we need to adapt engineering practices, make it reproducible, automatable, and deployable! The first step is to convert the notebook to scripts and it is the main theme of this article!

我們需要以某種方式適應(yīng)工程實(shí)踐，使其可重現(xiàn)，自動(dòng)化和可部署！ 第一步是將筆記本轉(zhuǎn)換為腳本，這是本文的主題！

>>>GitHub repo<<<

>>> GitHub存儲(chǔ)庫<<<

All credits of this great notebook in repo go to the original creator!

回購中這款出色筆記本的全部功勞歸原始創(chuàng)建者所有！

腳本：ipynb-> .py (Scripts: ipynb -> .py)

Why script? Why can’t we just use the interactive notebook when it is working fine? Let me propose some scenarios to justify why it may be a good idea to use scripts beyond exploration!

為什么要腳本？ 為什么不能在交互式筆記本正常工作時(shí)使用它？ 讓我提出一些方案來證明為什么使用腳本而不是探索可能是一個(gè)好主意！

If you want to run 20 big models in parallel, will you open 20 notebooks?

如果要并行運(yùn)行20個(gè)大型型號(hào)，是否可以打開20個(gè)筆記本？

Suppose you are willing to open 20 notebooks, how will you configure the hyperparameters? Go to each notebook and find related cells?

假設(shè)您愿意打開20個(gè)筆記本，那么如何配置超參數(shù)？ 轉(zhuǎn)到每個(gè)筆記本并找到相關(guān)的單元格？

Suppose you manually configure 20 notebooks, how will you analyze the results? Go to each notebook?

假設(shè)您手動(dòng)配置20個(gè)筆記本，將如何分析結(jié)果？ 轉(zhuǎn)到每個(gè)筆記本？

Suppose you can handle 20 notebooks for the first 3 steps, what if you have a great idea but you need to experiment with 200 sets of hyperparameters, are you willing to repeat steps 1–3?

假設(shè)您可以在前三個(gè)步驟中處理20個(gè)筆記本，如果您有個(gè)好主意，但需要試驗(yàn)200套超參數(shù)，您是否愿意重復(fù)步驟1-3？

Suppose you find a bug in the original notebook and need to rerun everything, are you willing to repeat steps 1–3?

假設(shè)您在原始筆記本中發(fā)現(xiàn)了一個(gè)bug，并且需要重新運(yùn)行所有內(nèi)容，是否愿意重復(fù)步驟1-3？

If you answer YES to all, then this article is NOT for you, bye and have a good day 😊

如果您對(duì)所有人的回答都是“是”，那么本文不適合您，再見，祝您愉快

The way I structure the pipeline is to break it down into etl.py, train.py, and predict.py. Each script has its responsibility and tries to be as atomic as possible such that they can be developed by individual teammates as long as the responsibility is clear.

我結(jié)構(gòu)管道的方法是把它分解成etl.py，train.py和predict.py。 每個(gè)腳本都有其責(zé)任，并且要盡可能地原子化，以便只要責(zé)任明確，就可以由單個(gè)隊(duì)友開發(fā)。

etl.py: convert the raw data, do some transformation, create train.csv and test.csv under data folder [train_test_split]

etl.py ：轉(zhuǎn)換原始數(shù)據(jù)，進(jìn)行一些轉(zhuǎn)換，在數(shù)據(jù)文件夾[train_test_split]下創(chuàng)建train.csv和test.csv

train.py: use data in train.csv, export a model to model folder [model.fit(X, y)]

train.py ：使用train.csv中的數(shù)據(jù)，將模型導(dǎo)出到模型文件夾[model.fit(X，y)]

predict.py: use data in test.csv and trained model, export the predictions, and evaluate [model.predict(X, y)]

predict.py：在test.csv使用數(shù)據(jù)和訓(xùn)練模型，導(dǎo)出的預(yù)測(cè)，并評(píng)估[model.predict(X，Y)]

# File structure
.
├── README.md
├── __init__.py
├── autoformat.sh
├── data
│ ├── predict.csv
│ ├── test.csv
│ ├── train.csv
│ └── winequality.csv
├── log
│ ├── etl.log
│ ├── predict.log
│ └── train.log
├── model
│ └── model.pkl
├── notebook
│ └── prediction-of-quality-of-wine.ipynb
├── requirement.txt
└── scripts
├── config.yml
├── etl.py
├── predict.py
├── test_train.py
├── test_utility.py
├── train.py
└── utility.py

If I mess up something, I will not try to figure out why [imagine state mutation in Jupyter because you random run the cells], I will just run the script again and see.

如果我搞砸了，我將不會(huì)嘗試找出原因(在Jupyter中想象狀態(tài)突變，因?yàn)槟S機(jī)運(yùn)行單元格)，我將再次運(yùn)行腳本并查看。

# Run in command line, as simple as this :)$ python3 ./scripts/etl.py
$ python3 ./scripts/train.py
$ python3 ./scripts/predict.py

Great, we can load and run the scripts in the command line! But as we mentioned in the scenarios above [№2], how can we configure the hyperparameters then ?_?

太好了，我們可以在命令行中加載和運(yùn)行腳本！ 但是，正如我們?cè)谏鲜鯷№2]的場(chǎng)景中提到的那樣，那么如何配置超參數(shù)？

配置文件作為輸入：單擊 (Config file as input: click)

The principle is to try not to touch the code, I have created another config.yml to contain all the configurations and load them via click. In this way, every new model is just another configuration, this ensures the reproductivity and avoids manually changing the code [and introduce bugs 🙁 ].

原理是盡量不要碰代碼，我創(chuàng)建了另一個(gè)config.yml來包含所有配置，并通過click加載它們。 這樣，每個(gè)新模型都只是另一種配置，這確保了可重復(fù)性，并且避免了手動(dòng)更改代碼[并引入錯(cuò)誤🙁]。

# config.yml example, I only use this to configure the scripts
etl:
raw_data_file: "data/winequality.csv"
processed_path: "data"
test_size: 0.2
random_state: 42train:
processed_train: "data/train.csv"
ensemble_model: "RandomForestClassifier"
model_config: {n_estimators: 300}
model_path: "model/model.pkl"predict:
model_path: "model/model.pkl"
processed_test: "data/test.csv"
predicted_file: "data/predict.csv"
export_result: True

Inside the script, I created a utility function to parse the configuration file

在腳本內(nèi)部，我創(chuàng)建了一個(gè)實(shí)用程序函數(shù)來解析配置文件

def parse_config(config_file):
with open(config_file, "rb") as f:
config = yaml.safe_load(f)
return config

Then we can load the configurations to the scripts in an extensible way!

然后，我們可以以可擴(kuò)展的方式將配置加載到腳本中！

@click.command()@click.argument("config_file", type=str, default="scripts/config.yml")
def etl(config_file):
config = parse_config(config_file)
raw_data_file = config["etl"]["raw_data_file"]
processed_path = Path(config["etl"]["processed_path"]).......DO SOMETHING.......

If we have 20 models with a similar architecture, we can just prepare 20 configurations, that’s it

如果我們有20個(gè)具有相似架構(gòu)的模型，那么我們只需準(zhǔn)備20個(gè)配置即可

無打印：正在記錄 (No print: logging)

We can now combine the script and configuration in the command line environment! How can I get the outputs? In the Jupyter world, I will print and see but it means I need to scan through a long long notebook, what if I have many models? Is there any concrete way to collect the outputs in a file?

現(xiàn)在，我們可以在命令行環(huán)境中結(jié)合腳本和配置！ 如何獲得輸出？ 在Jupyter的世界中，我將進(jìn)行打印和查看，但這意味著我需要瀏覽一個(gè)很長的筆記本，如果我有很多型號(hào)怎么辦？ 有什么具體方法可以將輸出收集到文件中？

Let print go, learn logging! Logging module in Python does what its name suggests, do logging in Python. We can define and log the things we are interested in, for example, which stage of the script [for debug], a summary of the metrics [for evaluation], I extracted a piece from model prediction and evaluation as an example

放手打印，學(xué)習(xí)日志記錄 ！ Python中的日志記錄模塊按照其名稱的含義執(zhí)行操作，在Python中進(jìn)行日志記錄。 我們可以定義并記錄我們感興趣的事物，例如，腳本的哪個(gè)階段[用于調(diào)試]，度量的摘要[用于評(píng)估]，我從模型預(yù)測(cè)和評(píng)估中提取了一部分作為示例

This piece of code will generate the log similar to the one below

這段代碼將生成類似于以下內(nèi)容的日志

Learn more about logging from this article! https://www.machinelearningplus.com/python/python-logging-guide/

從本文中了解有關(guān)日志記錄的更多信息！ https://www.machinelearningplus.com/python/python-logging-guide/

Aside:

在旁邊：

Logging is great but still if we have 100 experiments, we will get 100 log files 🙁 Even they are concrete, we may not want to read them one by one, is there any better way to evaluate? Below are some potential solutions:

日志記錄很好，但是如果我們有100個(gè)實(shí)驗(yàn)，我們將獲得100個(gè)日志文件🙁即使它們是具體的，我們也可能不想一一閱讀，有沒有更好的評(píng)估方法？ 以下是一些可能的解決方案：

• Yet another script, utilize grep or regex, parse and extract the key information [but what if someone changes the format or spelling!?]
  還有一個(gè)腳本，利用grep或regex，解析并提取關(guān)鍵信息[但是如果有人更改格式或拼寫該怎么辦！？]

• Yet another tool, checkout MLFlow or ModelDB! [Logging is only one of the features of both products]

  另一個(gè)工具，簽出MLFlow或ModelDB ！ [記錄只是這兩種產(chǎn)品的功能之一]

再現(xiàn)性問題：Conda env (Reproducibility matters: Conda env)

Yo, things seem good now! I can push to GitHub and my friends/colleagues can clone and run in their computer 😊

喲，現(xiàn)在看來情況不錯(cuò)！ 我可以推送到GitHub，而我的朋友/同事可以克隆并在他們的計(jì)算機(jī)中運(yùn)行😊

Oh wait……..their computer……..what if we are using different versions? It is common because every package has many versions, eg: sklearn. The APIs / interfaces may change over time [and breaks the code 🙁 ], how can we ensure we are using the same package?

哦等等.....他們的電腦.....如果我們使用的是其他版本？ 這很常見，因?yàn)槊總€(gè)軟件包都有許多版本，例如： sklearn 。 API /接口可能會(huì)隨時(shí)間變化[并破壞代碼🙁]，我們?nèi)绾未_保使用相同的程序包？

Short answer: Conda env, check out Matt’s article

簡短答案：Conda env，請(qǐng)查看Matt的文章

I list out some useful commands below, just enough for our needs

我在下面列出了一些有用的命令，足以滿足我們的需求

# In terminal# Create the environment
$ conda create — name YOU_CHANGE_THIS python=3.7 -y# Activate it
$ conda activate YOU_CHANGE_THIS# Install the needed package
$ pip install –r requirements.txt# # ## # ## # ## # ## # ## # ##
# # # Do your development # # #
# # ## # ## # ## # ## # ## # ### Deactivate and back to normal environment
$ conda deactivate# This will remove the environment, do it when you finish the project?
$ conda remove –name YOU_CHANGE_THIS –all

*in requirements.txt, you should always specify the version! If you don’t specify it, it will try to download the latest one, but your latest maybe not my latest and lose the whole point of using Conda env

*在requirements.txt中，您應(yīng)始終指定版本！ 如果您不指定它，它將嘗試下載最新版本，但是您的最新版本可能不是我的最新版本，從而失去了使用Conda env的全部意義。

# this is what I have inside requirements.txt
pytest==5.3.5
pandas==1.0.1
Click==7.0
scikit-learn==0.22.1
black==19.10b0
isort==4.3.21
PyYAML==5.2

不要破壞您以前的代碼：pytest (Don’t break your previous code: pytest)

In the software / ML world, change is the constant, we change something whenever we work. But how can we ensure the new change doesn’t break the existing one [especially those you wrote a few months before]?

在軟件/ ML世界中，變化是不變的，只要我們工作，我們都會(huì)進(jìn)行更改。 但是我們?nèi)绾未_保新的變更不會(huì)破壞現(xiàn)有的變更(尤其是您幾個(gè)月前寫的變更)？

Unit tests are here to help 😊 We can write the test cases for each function to ensure they have the expected behavior. Unit tests cannot prove program correctness but they can safeguard the scenarios you listed!

單元測(cè)試可為您提供幫助😊我們可以為每個(gè)功能編寫測(cè)試用例，以確保它們具有預(yù)期的行為。 單元測(cè)試不能證明程序的正確性，但是可以保護(hù)您列出的方案！

For example, the code below asserts the type and output dimension are as expected. It seems silly and simple but if your load_data function becomes more complex, you will appreciate something safeguard you all the way [especially if you want to change something, don’t ask me how I know]!

例如，下面的代碼斷言類型和輸出維符合預(yù)期。 看起來很愚蠢和簡單，但是如果您的load_data函數(shù)變得更加復(fù)雜，您將一路欣賞一些可以保護(hù)您的方法[特別是如果您想更改某些內(nèi)容，請(qǐng)不要問我怎么知道]！

To run the unit test, simply run pytest in the terminal and you should see the output like this

要運(yùn)行單元測(cè)試，只需在終端中運(yùn)行pytest ，您應(yīng)該會(huì)看到這樣的輸出

Cool, we can run pytest before we push to GitHub and try to maintain a workable program! But human isn’t reliable, what if we forget to run pytest before push and break the code!? How can we protect ourselves from this situation?

太酷了，我們可以在推送到GitHub并嘗試維護(hù)可行的程序之前運(yùn)行pytest！ 但是人類是不可靠的，如果我們忘記在推送和破壞代碼之前運(yùn)行pytest呢？ 在這種情況下，我們?nèi)绾伪Ｗo(hù)自己？

如果可能，不要依靠人：持續(xù)集成 (If possible, don’t rely on human: Continuous Integration)

What if the program itself can run the unit tests automatically when we push/create pull request? Then it can stop the merge if it cannot pass the tests! If you heard of continuous integration, this is part of the feature! Popular products in the market are CircleCI / TravisCI / jenkins, but I am lazy, I don’t want to do any extra configuration work if not needed so we will use relatively new GitHub Action for that 😊

如果在推送/創(chuàng)建請(qǐng)求請(qǐng)求時(shí)程序本身可以自動(dòng)運(yùn)行單元測(cè)試該怎么辦？ 如果無法通過測(cè)試，則可以停止合并！ 如果您聽說過持續(xù)集成，那么這就是該功能的一部分！ 市場(chǎng)上流行的產(chǎn)品是CircleCI / TravisCI / jenkins，但是我很懶，如果不需要，我不想做任何額外的配置工作，因此我們將為此使用相對(duì)較新的GitHub Action。

In the past, I think the engineers are so smart, how can they remember the syntax and come up with a script like this [it is simple already] on their own? Don’t think in that way, most people just copy & modify the template as I do [there is a template called Publish Python package under CI workflows in GitHub Actions]

過去，我認(rèn)為工程師是如此聰明，他們?nèi)绾尾拍苡涀≌Z法并獨(dú)自提出這樣的腳本(已經(jīng)很簡單)？ 不要以這種方式思考，大多數(shù)人都像我一樣復(fù)制和修改模板[GitHub Actions中CI工作流下有一個(gè)名為Publish Python package的模板]

Now you see it! The scripts, package versions, and pytest work together to ensure the package versions are right and the program is workable! They will safeguard us when we develop incrementally, they will say NO if the code breaks the unit tests. If we find a bug, we can include that as another test case to ensure we don’t commit the same mistake twice!

現(xiàn)在您看到了！ 腳本，軟件包版本和pytest可以一起使用，以確保軟件包版本正確且程序可行！ 當(dāng)我們逐步開發(fā)時(shí)，它們將保護(hù)我們，如果代碼破壞了單元測(cè)試，他們將拒絕。 如果發(fā)現(xiàn)錯(cuò)誤，可以將其作為另一個(gè)測(cè)試用例，以確保我們不會(huì)兩次犯相同的錯(cuò)誤！

Can you do the same in Jupyter Notebook with the same level of confidence?

您可以在Jupyter Notebook中以相同的置信度執(zhí)行相同的操作嗎？

Code Style matters: black, isort

代碼樣式很重要：黑色，isoort

Have you heard of pep8? It is the style convention to write Python, there are many (good) points but honestly, please don’t test me on that, my brain cannot remember them all!

您聽說過pep8嗎？ 這是編寫Python的樣式慣例，有很多(好的)要點(diǎn)，但是老實(shí)說，請(qǐng)不要對(duì)此進(jìn)行測(cè)試，我的大腦無法記住所有這些內(nèi)容！

I remember in one of my classes, my professor requires us to use pycodestyle it is a tool to check the code style, then I got these messages and fix them one by one. For example:

我記得在我的一堂課中，我的教授要求我們使用pycodestyle這是一種檢查代碼樣式的工具，然后我得到了這些消息并逐一修復(fù)。 例如：

$ pycodestyle --first optparse.py
optparse.py:69:11: E401 multiple imports on one line
optparse.py:77:1: E302 expected 2 blank lines, found 1
optparse.py:88:5: E301 expected 1 blank line, found 0

I think it is a good tool but kind of incomplete, if you can find my problems, why don’t you just correct that for me and save my time?

我認(rèn)為這是一個(gè)很好的工具，但還不完善，如果您能找到我的問題，為什么不為我改正一下以節(jié)省時(shí)間呢？

Simply run this and the script will do the rest!# If you get permission error, you can try
# chmod +rx autoformat.sh
$ ./autoformat.sh

結(jié)論 (Conclusions)

Things are good for local now! I can push them to GitHub and my friends can clone and run it in their computer

事情現(xiàn)在對(duì)當(dāng)?shù)厝?/strong>有好處！ 我可以將他們推送到GitHub，而我的朋友可以在他們的計(jì)算機(jī)中克隆并運(yùn)行它

BUT! We know the important (bad) messages usually start with BUT/HOWEVER, eg: job application rejections 🙁

但！ 我們知道重要的(壞的)消息通常以BUT / HOWEVER開頭，例如：作業(yè)申請(qǐng)被拒絕🙁

BUT what if we want to productionalize the model ?_?

但是，如果我們要對(duì)模型進(jìn)行生產(chǎn)化怎么辦？

Q: Firstly, what it means by productionalize?

問：首先，生產(chǎn)化意味著什么？

A: In a narrow sense, it means model consumption, I give you the input, you return me the output [maybe in JSON form], eg: web endpoint / API. We need to have a server [another computer] to host the models and endpoints, I don’t want to use my computer to host it or the whole product will rely on my poor Macbook🙁

答：從狹義上講，這意味著模型消耗，我給您輸入，您將輸出返回給我[也許以JSON形式]，例如：Web端點(diǎn)/ API。 我們需要有一個(gè)服務(wù)器[另一臺(tái)計(jì)算機(jī)]主辦的模型和終點(diǎn)，我不想用我的電腦主機(jī)，或整個(gè)產(chǎn)品將依靠我那可憐的MacBook🙁

I highlighted two words above and they are exactly the challenges

我在上面強(qiáng)調(diào)了兩個(gè)詞，而這恰恰是挑戰(zhàn)

1.How to find another computer to host the models?

1.如何找到另一臺(tái)計(jì)算機(jī)來托管模型？

Short answer: Either buy a computer OR rent one from cloud provider [eg: AWS, Azure, GCP], then we can claim we know CLOUD COMPUTING 😊

簡短的答案：要么購買一臺(tái)計(jì)算機(jī)，要么向云提供商租用一臺(tái)計(jì)算機(jī)(例如：AWS，Azure，GCP)，那么我們可以聲稱我們知道云計(jì)算COMP

2.What if another computer isn’t MacOS, how can I ensure my code is working there?

2.如果另一臺(tái)計(jì)算機(jī)不是MacOS，該怎么辦？

Short answer: Docker

簡短答案：Docker

To wrap up, we:

最后，我們：

a. start from a Jupyter Notebook
b. Code conversion [ipynb to .py]
c. Make the scripts configurable [Click]
d. Include logging [logging]
e. Make sure the local environment is the same [Conda env]
f. Include unit test and basic CI [pytest, GitHub Action]
g. Autoformat the script style [black, isort]

I hope file tree structure with annotations can show you the code evolution, don’t be scared by many folders because they are developed step-by-step, if you understand the thought process, it is pretty straightforward!

我希望帶有注釋的文件樹結(jié)構(gòu)可以向您顯示代碼的演變過程，不要被許多文件夾嚇到，因?yàn)樗鼈兪且徊揭徊介_發(fā)的，如果您了解思想過程，那就非常簡單了！

.
├── README.md
├── __init__.py
├── .github/workflows [f]
├── autoformat.sh [g]
├── data
│ ├── predict.csv [b]
│ ├── test.csv [b]
│ ├── train.csv [b]
│ └── winequality.csv
├── log
│ ├── etl.log [d]
│ ├── predict.log [d]
│ └── train.log [d]
├── model
│ └── model.pkl [b]
├── notebook
│ └── prediction-of-quality-of-wine.ipynb [a]
├── requirement.txt [e]
└── scripts
├── config.yml [c]
├── etl.py [b, c]
├── predict.py [b, c]
├── test_train.py [f]
├── test_utility.py [f]
├── train.py [b, c]
└── utility.py

Something we mentioned but didn’t elaborate:

我們提到但未詳細(xì)說明的內(nèi)容：

-> Databricks’s MLFlow / VertaAI’s ModelDB

-> Databricks的MLFlow / VertaAI的ModelDB

Something we can discuss more:

我們可以討論更多的內(nèi)容：

• Model deployment in cloud [AWS]
  云中的模型部署[AWS]
• Containerization [Docker]
  容器化[Docker]

Now we have built a solid foundation, these scripts are in the form that we can reuse it further! Imagine how can you do this with Jupyter Notebook?

現(xiàn)在我們已經(jīng)建立了堅(jiān)實(shí)的基礎(chǔ)，這些腳本的形式可以進(jìn)一步重用！ 想象一下如何使用Jupyter Notebook做到這一點(diǎn)？

I understand what it feels like when someone said you should try ABC / XYZ but they don’t explain why or how to evolve from scratch, I hope this article can contribute a little bit :)

我了解有人說您應(yīng)該嘗試ABC / XYZ，但他們沒有解釋為什么或如何從頭開始發(fā)展時(shí)的感覺，我希望本文能有所作為:)

If this article is useful, you can leave some comments

如果本文有用，則可以留下一些評(píng)論

OR you can star my repo!

或者你可以給我的倉庫加注星號(hào)！

OR my LinkedIn [Welcome but please leave a few words to indicate you are not zombie]!

或我的LinkedIn (歡迎使用，請(qǐng)留下幾句話以表明您不是僵尸)！

I learned most of these things from my internship @ Manifold AI

我從實(shí)習(xí)中獲得了大部分這些東西，這是在Manifold AI

翻譯自: https://towardsdatascience.com/from-jupyter-notebook-to-sc-582978d3c0c

總結(jié)

以上是生活随笔為你收集整理的从Jupyter Notebook到脚本的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。