Skip to content

MS_PythonForVSCode

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

Python for Visual Studio Code

概要

  • Visual Studio Code の Python 拡張機能
  • コード補完などの他、デバッグに関する機能などがある。
  • 正式には「Python Extension for Visual Studio Code」かも。

補足（現在の拡張機能の構成）: Python 拡張も
C# 拡張と同様に分割されたため、現況を補っておく。

拡張機能 ID 役割
Python ms-python.python 基盤（環境の選択、デバッグ、テスト）
Pylance ms-python.vscode-pylance 言語サービス（補完・型チェック）★
Python Debugger ms-python.debugpy デバッガ（旧: Python 拡張に同梱）
Jupyter ms-toolsai.jupyter ノートブック（本ページの詳細節） 
【Pylance が中核】
   ・Microsoft 製の言語サーバ（Pyright ベース）
   ・【型ヒントを解釈して補完・エラー検出を行う】★
   ・"python.analysis.typeCheckingMode": "basic" / "strict"
      → strict にすると、TypeScript の strict に近い厳しさになる
        （[TypeScript](MS_TypeScript) の strictNullChecks と同じ発想）

C# 拡張と同じく LSP の枠組みである
（OmniSharp）。

詳細

  • 基本的には、WSL プラグインを使って WSL2 へ接続して使用。

  • 更に Jupyter プラグインを使って ipykernel カーネルに接続して使用。

  • Python - .NET 開発基盤部会 Wiki（DNET_Python.md）

補足（この構成の意味）: **「Windows の VS Code から
WSL2 上の Python を使う」**という構成は、
現在の Windows における Python 開発の標準形である。理由を補う。

【なぜ WSL2 上で動かすのか】

 ① 【ライブラリが Linux 前提】であることが多い
      科学計算・機械学習系（PyTorch、TensorFlow、各種 C 拡張）
      → Windows ネイティブではビルドが通らない/遅いことがある

 ② 【本番環境が Linux】である
      → 開発と本番の差を減らせる
      → [.NETのクロスプラットフォーム対応](MS_DotNetCrossPlatform) と同じ動機

 ③ ファイル I/O が速い（WSL2 のファイルシステム内なら）★
      → ただし /mnt/c/... の Windows 側は【遅い】
      → プロジェクトは【WSL2 側（~/ 配下）に置く】のが要点

 ④ pip / apt が素直に動く

【リモート開発の仕組み】

   Windows 側                        WSL2 側
   ┌──────────┐         ┌────────────────┐
   │ VS Code（UI）│ ◀─────▶ │ VS Code Server   │
   │              │         │  ├ Python 拡張   │
   │  画面だけ    │         │  ├ Pylance       │
   └──────────┘         │  └ python / pip  │
                             └────────────────┘
     → 【拡張機能とコードは WSL2 側で動く】★
     → 「Windows に Python を入れる」必要がない

同じ仕組みで、SSH 先・コンテナ内でも開発できる
（Remote - SSH、Dev Containers）。
Visual Studio CodeによるSPA開発 で述べた
「主戦場が VS Code へ移った」理由の 1 つが、このリモート開発機能である。

補足（Python 環境の選択が最初の関門）: Python 拡張を使う際、
「どのインタープリターを使うか」で最も詰まる。

【Python の環境が複数存在しうる】
   ・システムの python3（/usr/bin/python3）
   ・pyenv で入れた版
   ・仮想環境（venv / .venv）★ 通常はこれを使う
   ・conda 環境
   ・Windows 側の Python（WSL からは別物）

 → VS Code 左下 or コマンド パレットで
   【Python: Select Interpreter】を実行して明示的に選ぶ

# 現在の定石：プロジェクト直下に .venv を作る
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
#   → VS Code は .venv を自動検出して候補に出す ★
【症状と原因】
  「import できない」「補完が効かない」
     → インタープリターの選択が違う（別環境を見ている）★
  「pip install したのに使えない」
     → activate せずに入れた／別環境に入った
  「デバッグだけ失敗する」
     → launch.json の python パスが古い

**uv（Rust 製の高速なパッケージ・環境管理）**が近年急速に
普及しており、pip / venv の代替として選択肢に入る。

参考

Microsoft Docs

補足（Jupyter を VS Code で使う利点）: 参考リンクが
Jupyter への接続方法に集中しているのは、
この構成が実務で有用だからである。

【ブラウザの Jupyter Notebook との比較】

  ブラウザ版           VS Code 版
  ─────────────────────────────────────
  補完が弱い        →  【Pylance の補完・型チェックが効く】★
  Git 差分が汚い    →  同じ（.ipynb は JSON なので差分が読みにくい）
  デバッガが弱い    →  【ブレークポイントを張れる】★
  拡張が別体系      →  VS Code の拡張がそのまま使える
  環境の切替が面倒  →  カーネル選択が UI から

【.ipynb をソース管理する際の注意】★
   ・実行結果（出力）が JSON に埋め込まれる
      → 差分が巨大になる、機密データが混入する
   【対策】
      ・コミット前に【出力をクリアする】（nbstripout）
      ・または .py として持ち、jupytext で同期する
      ・実験は notebook、確定したロジックは .py に切り出す

.NET 開発者にとっての接点:

・.NET Interactive（Polyglot Notebooks）拡張を入れると、
  【VS Code のノートブックで C# / F# / PowerShell が書ける】★
   → データ調査や API の動作確認に便利
   → Python のセルと C# のセルを同一ノートに混在させられる

Microsoft Learn

Tags: 移行, プログラミング, ツール類

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally