Ever wondered how to create your own domain-specific language tailored to your needs?

This session explores how to build a programming language that lets users write code using natural language. Designed to be fun, intuitive and easy to use, the language is crafted for young learners especially those for whom English is not a first language. Built with Python, the system parses and interprets natural language into executable code. The design challenges, key insights, and lessons learned of the creation of this language will be shared.

This session is for anyone curious about building your own little domain-specific languages, exploring new ways to teach programming or just crafting code that speaks your own language.

Inspired by my working with an organization that taught coding to children and talks at PyCon APAC, I asked: What if programming could be made more accessible with a language tailored to children? 

The talk will cover:

**Language Design**
- Making decisions around syntax depending on the purpose.

**Architecture Choices**
- Interpreter vs compiler: which architecture best fits for your need?
- Parsing libraries: tools available such as PLY, Lark.

**Technical Implementation**
- Building the lexer, parser, and interpreter and handling errors using Python.

**Demo**
- The language in action.

**Future Directions**
- Adding support for more languages, introducing to wider community.

Chaw Chit Su Thwe

What does it take to create a language of your own in Python?

### 対象者
- DjangoやFlaskでWebアプリケーションを開発している中級Pythonエンジニア
- フロントエンド開発にJavaScriptを使っているが、Pythonでも同様の開発体験を求めている開発者
- 既存のDjangoプロジェクトにモダンなUI要素を追加したいと考えている方

### 発表内容

#### 1. ReactPyとは何か？
- 「フロントエンド苦手だけど、こんなのあったら便利だよね」な話
- ReactPyの特徴を簡単に紹介

#### 2. ReactPyの強みとフロントエンド構築ツールとしての位置づけ
- ReactPyの独自の強み
- ReactPyの技術的特徴

#### 3. ReactPyの導入方法と実践活用
- ReactPy単体での使用方法
- 既存プロジェクトへの導入パターン
- 実装デモとコード例

## 発表概要詳細

### 発表内容

#### 1. ReactPyとは何か？
- 「フロントエンド苦手だけど、こんなのあったら便利だよね」な話
  - JavaScript書かずにReactっぽいことがPythonでできる
  - HTMLテンプレートよりもっと柔軟にUIが作れる
- ReactPyの特徴を簡単に紹介
  - Reactのコンポーネント思想をPythonで実現
  - Python慣れしている人には親しみやすい書き方

#### 2. ReactPyの強みとフロントエンド構築ツールとしての位置づけ
- ReactPyの独自の強み
  - 既存のWebアプリケーションに自然に組み込める
  - Pythonの豊富なライブラリエコシステムとの親和性
- ReactPyの技術的特徴
  - Virtual DOM的な仕組み
  - 状態管理の仕組み

#### 3. ReactPyの導入方法と実践活用
- ReactPy単体での使用方法
  - FastAPI、Flaskなど様々なバックエンドとの組み合わせ
  - 新規プロジェクトでの始め方
- 既存プロジェクトへの導入パターン
  - 段階的導入戦略（一部のページから始める）
  - reactpy-djangoを使った既存Djangoプロジェクトでの活用例
- 実装デモとコード例
  - 従来のHTMLテンプレートとの比較
  - ReactPyで実装した動的コンポーネントの例

### 発表への想い

私自身、長年DjangoでWebアプリケーションを開発してきましたが、モダンなUIを実装するためにJavaScriptとPythonを行き来する開発体験に課題を感じていました。特に、小〜中規模のプロジェクトでReact + Django REST Frameworkの組み合わせを採用するには複雑すぎる場合が多く、かといってDjango Templateだけでは表現力に限界がありました。

ReactPyに出会ったとき、「これまでPythonエンジニアが感じていたフロントエンド開発の壁を取り払える可能性がある」と感じました。同じような課題を抱える多くのPythonエンジニアに、新しい選択肢としてReactPyを紹介し、より効率的で楽しい開発体験を共有したいと考えています。

### 難易度（想定）
中級

kumappp

ReactPyを使ってreact likeにUIをPythonで実装する

Pythonによるグラフ構造データ（以下、グラフと呼称）の表現と分析手法について紹介いたします。

グラフは、現実世界における複雑な関係性を表現する強力なツールです。
SNSにおける人々の繋がり、ウェブサイトのリンク構造、交通網、分子構造など、あらゆるものがグラフとしてモデル化でき、データサイエンス分野との親和性も高いのが特徴です。

本発表では、Pythonのグラフ分析パッケージであるNetworkXを用いたグラフの生成や分析、そしてGNN（Graph Neural Networks）による深層学習の例を紹介します。
複雑な理論や数式は避け、初心者にも分かりやすい実践的な内容を発表する予定です。
また、一般的な表形式データの分析に長けたデータサイエンティストやアナリストに対しても、グラフデータの分析手法という新たな学びを提供できればと考えております。

### 1. オープニング (2分)
- 自己紹介
- 発表内容とゴール、オーディエンスが持ち帰りできる知見

### 2. グラフの基礎 (5分)
- 身の回りにあるグラフの例
- グラフで表現するメリット (関係性や構造の可視化や分析、表形式データとの違い)
- グラフの基本構成（ノードやエッジの概念）
- グラフの種類（無向と有向、重みの有無など）

### 3. Pythonによるグラフ表現 (5分)
- NetworkXの紹介
- グラフの作成（空グラフ、ノードやエッジの追加）
- グラフ情報の取得（ノード数やエッジ数、隣接ノード、次数など）
- グラフの可視化

### 4. グラフの分析(5分)
- 中心性分析（例. SNSで影響力のある人を見つける）
- 最短経路探索（例. 最適な配送ルートを探す）
- コミュニティ検出（例. 顧客グループを特定する）

### 5. GNNによる深層学習入門 (5分)
- 表形式データを対象とした機械学習との違い
- GNNが推論可能なタスク（ノード分類、リンク予測、グラフ分類など）
- GNNの基本コンセプト
- GNNの実装例

### 6. まとめ (3分)
- 振り返り（NetworkXによる基本操作、GNNが有効なシーンなど）
- 今後の学習ステップ

（残り時間で質疑応答）

fujine

NetworkXとGNNで学ぶグラフデータ分析入門：複雑な関係性を解き明かすPythonの力

「Pythonのスレッドは遅い」・「GILのせいで真の並列処理ができていない」こうした話は誰もが一度聞いたことがあるでしょう。しかし、Pythonスレッドの実体が何なのか、なぜそういう話がでているのかを実装レベルで理解している人は多くありません。

Python 3.13でついに実現したGIL無効化機能により、この状況は大きく変わろうとしています。しかし、NoGILモードを効果的に活用するためには、まず「Pythonスレッドとは何か」を深く理解する必要があります。

本発表では、CPythonのソースコードを読み解きながら、この根本的な問いに答えます。そもそも、threading.ThreadとThreadPoolExecutorの違いは？WebKitから着想を得た"Parking Lot"とは？NoGILで変わるスピンロックやeval_breakerの挙動は？

実装コードとともに、Pythonスレッドの正体とNoGIL時代の変化を理解する30分間です。

Pythonのスレッドは遅いと言われることがありますが、確かにCPUバウンドタスクでは遅く、
GILのせいで実質1スレッドでしか動作しておりませんでした。しかしながら、I/O待機中ではどうでしょう？
こうした動きの違いをまずは説明します。

まずは、Pythonスレッドの基本となる、threading.TheradやThreadPoolExecutorの中身を説明します。これを実装レベルで理解すると、GILというものが遅さの主要因であることが見えてきます。

そもそも、なぜGILという考えがあったのかを説明します。それにより、スレッドというのはどのような動きになるのかを説明していきます。
その実装の紹介の中で、Parking Lotやスピンロック、eval_breakerといった用語についてもお話できると思います。

2020年代のマルチコア時代にPythonを加速するNoGILモードについて深く理解し、スレッドについて深く理解できるようにする、そんな30分になります。

curekoshimizu

Pythonスレッドとは結局何なのか？ ~CPython実装から見るNoGIL時代の変化~

Python can run on a regular computer or on a general purpose microcontroller. But as a hobbyist, I was curious about how to design a completely custom device, which led me into the FPGA world. Traditionally, FPGA programming requires learning VHDL or Verilog, but there’s a Pythonic alternative: Amaranth. This powerful open-source library lets you describe digital circuits in Python and load them into affordable FPGA boards.
In this presentation, I’ll share a high-level look at the development process using Amaranth, as well as provide demos, including one of a simple CPU built from scratch. If you’re curious about hardware or eager to explore beyond software, this talk will show how Python can open that door.

This talk is an invitation to explore hardware through the lens of Python. I'll share my journey as a software engineer stepping into the world of FPGAs — not through Verilog, but via Amaranth, a Python-based hardware description library. I’m approaching this as a hobbyist curious about expanding my knowledge and building fun toys, rather than polished products — though Amaranth is certainly powerful enough for “real” projects. 

I’ll walk through the tools and process I used to build a small homebrew CPU, inspired by the SAP-1 from Malvino & Brown’s “Digital Computer Electronics.” We’ll look at how to write and integrate design components, interface with a Tang Nano FPGA board, and connect to external hardware. I’ll share photos, videos, and — live-demo gods willing — a real working device.

This session isn’t a step-by-step tutorial, but a guided tour meant to spark your curiosity. If you enjoy Python and like building things, you might just discover a new playground.

Daniel Moisset

How I Built a CPU for Fun (and Didn’t Learn Verilog)

セキュリティは「難しそう」「どこから始めればいいのかわからない」とよく言われており、重要ながらも体系的に学ぶ機会が少ない分野です。このセッションでは、初心者向けにPythonコードをよりセキュアにするための知識と武器を紹介していきます。具体的な事例を交えながら、サプライチェーン攻撃やマルウェアが仕込まれているデータを防ぐ方法・ツールをわかりやすく解説します。

## スコープ

このセッションでは、Pythonに特有のセキュリティ上の考慮事項を取り上げます。SQLインジェクションやシークレットのハードコーディングのような一般的な概念にはあえて触れずに、Pythonのエコシステムにおける既知のセキュリティ上の懸念事項に焦点を当てます。

## 構成

### Pythonコードに潜む4種類の闇 (20分)

このパートでは、可能な限り実例やサンプルコードを使って、各種類の「闇」のリスクをわかりやすく紹介します。また、より安全な代替案も提供します（例：pickleの代わりにJSONを使用するなど）。

1. 闇のサードパーティパッケージ（pipに対するサプライチェーン攻撃）

2. 闇データ（XML、zip、pickle）

3. 闇アルゴリズム（random、hashlib）

4. 闇バージョン（非推奨のPythonバージョンとライブラリ）


### 対策 (10分)

最後に、簡単にできるセキュリティ対策として以下のツールを紹介します。

1. リンターを使って脆弱性を自動検出
2. プライベートリポジトリを構築して信頼できるパッケージをホスト

## リファレンス

セキュリティ上の考慮事項があるモジュールの公式リスト: https://docs.python.org/3/library/security_warnings.html  
危険なpickleの使用を検出するruffリンターの例: https://docs.astral.sh/ruff/rules/suspicious-pickle-usage/

ビビってどうする：セキュアなPythonコードを目指して

Python標準ライブラリである非同期プログラミング用の「asyncio」には、プロファイルの難しさという課題があります。何がどこに依存しているのか、どこにどれだけ負荷がかかっているのか、といった情報をゼロコストで把握することが、言語仕様上困難でした。ただでさえ難しい印象のある並行処理をさらに難しくしてしまう一因として、プロファイリングのしづらさがあると感じています。

この課題を解決する新機能が、Python 3.14で追加される「asyncio」の「 ps」「pstree」です。

2025年10月にリリース予定のPython 3.14では、新しいAPI「capture_call_graph」「print_task_call_graph」およびタスクの新属性「task_awaited_by」が追加され、asyncioの実行中タスクの状態を可視化できるようになります。これにより、余計な負荷をかけずに、より容易に内部状態を把握することが可能になります。

本トークでは、実際のコードを交えながら、asyncioを用いた柔軟な内部状態の可視化手法をご紹介します。

非同期プログラミングを可能にする標準ライブラリ asyncio は、近年のアップデートにより高レベルAPIが充実し、タスクの管理やキャンセルも柔軟に扱えるようになりました。これにより、実装の難易度は大きく下がっています。

しかし実際の開発現場では、「思ったようにパフォーマンスが出ない」といった問題にしばしば直面します。このようなケースではプロファイリングが有効ですが、asyncioにおいて有効な標準手法はまだ確立されていません。また、状態確認のために余計なコストがかかることも、導入の障壁となっています。

こうした課題を解決する手段として期待されているのが、asyncio ps や pstree です。これによってasyncioを強化する強力なピースが追加されました。本トークでは、これらの基本的な使い方から、実際に業務で活用できるのかどうかまでを、コード例を交えながらご紹介します。


## 予定稿
* Python asyncio と既存のプロファイラの紹介 10分
  * pyspy
  * aiomonitor
  * IDE でのプロファイリング

* ps, pstreeの概要 10分
  * なぜこの機能が生まれたのか
  * taskの新しい属性「task_awaited_by」
  * 新しいAPI「capture_call_graph」「print_task_call_graph」

* ps, pstreeで何ができるのか 10分
  * Python Web Frameworkとの連携
  * グローバルバックエンドである anyio / trio における応用可能性

Junya Fukuda

タスクって今どうなってるの？3.14の新機能 asyncio ps と pstree でasyncioのデバッグを

このトークでは、画像に特殊な効果を施すライブラリ[imgrit](https://pypi.org/project/imgrit/)を紹介します。

このライブラリには2つの機能がありますが、ボロノイモザイク効果に焦点を絞って説明します。ボロノイモザイクとは、ボロノイ図を使って画像にモザイク効果を施すものです。もとの画像の特徴を残しつつボロノイモザイク効果を追加するためには、入力画像に適したボロノイ図を作る必要があります。これまで提案されていた方法は計算時間がかかるため、ボロノイモザイク効果はあまり普及していませんでした。このライブラリでは、計算時間を短縮するために機械学習アルゴリズムの1つであるK-meansクラスタリングを利用しています。これによって計算時間を抑えつつ、比較的綺麗なボロノイモザイク効果を作ることができるようになりました。ライブラリ開発の経緯を含め、ボロノイ図やK-meansクラスタリングに馴染みのない聴衆にもわかるように説明します。

聴衆が持ち帰れる内容
- ボロノイ図についての知識
- K-meansクラスタリングのちょっと変わった利用方法
- このライブラリの使い方

トークの流れは以下の通りです。

- 自己紹介(2分)
- 変換前後の画像を見ながら何をするライブラリなのかを説明（2分）
- ボロノイ図の基本（6分）
- ボロノイモザイクアートの難しさ（5分）
- K-meansクラスタリングを使った解決策（8分）
- 解決すべき課題(5分)
- まとめ(2分)

辻 真吾

ボロノイモザイクアートの作り方

Haiku is a traditional Japanese poetry form known for its brevity, simplicity, and objectivity. Modern haiku is being practiced in other languages as well, including English. The structure of modern English haiku is slightly different from the traditional Japanese form but it still adheres to those three principles. This talk provides a brief introduction to haiku, its poetic ideals, and how it resonates with some of the ideas presented in the Zen of Python. It aims to share with the audience lessons from haiku writing (such as minimalism in writing code and objectivity in collaboration), which are helpful not just in Python programming and software engineering design but also in how we approach problems in general.

Shiva Bhusal

Programming Lessons from Japanese Poetry

Pythonは非常に使いやすい動的言語でありながら、C拡張機能によってパフォーマンスと互換性をサポートしています。しかし、Cにはメモリ安全性、セキュリティ、使いやすさに関して多くの問題があります。近年、Rustは高速でメモリ安全な言語で、多くのプロジェクトでCの代替として注目を集めています。

この講演では、RustがPython開発にどのように影響を与えてきたか、そしてPythonライブラリを構築するためにRustをどのように活用できるかを探ります。RustがCよりも開発をどのように改善するか、そしてPyO3やmaturinのようなツールを使用してRustでPythonライブラリを楽しく開発する方法を学びましょう！

Pythonのアーキテクチャは、時代とともに進化することを可能にしています。Python開発の次のステップを、一緒に歩みましょう！

Outline

* Python+Cの紹介
    * Pythonはこれまで、Cで書かれた拡張機能を多用する言語
    * 純粋なPythonは、コンパイルされた言語に比べて速度が遅く、高速化とCライブラリとの互換性のために、C拡張を利用
* Rustの紹介
    * Rustは、高性能なコードを書くための人気のある言語
    * Rustは、バイトコードにコンパイルされる言語であり、高性能。
    * Goのような言語とは異なり、RustはC呼び出し規約との互換性が良好
    * Rustは、メモリ管理にボローチェッカーを使用することで、メモリセーフなコードを書くのが可能になる。
    * Rustには、多くの優れたツールが含まれている
* Rust + Python
    * 元々はArmin Ronacherのような人々によって探求され、Rustで書かれたPythonツールが増え、優れたパフォーマンスを提供。
        * uv: パッケージマネージャー（ryeに触発されています）
        * ruff: リンターとフォーマッター
    * Rustで書かれたPythonパッケージの作成がはるかに簡単になった
        * PyO3: Rust用のPythonバインディング
        * maturin: Python/Rustプロジェクト用のPythonパッケージビルドバックエンド
* PyO3を使用したRustでのPythonライブラリの開発
    * Rustでコードを書き、Pythonから呼び出す
        * RustでPython関数を作成
        * RustでPythonクラスを作成
        * Rustで書いて、Pythonで処理するエラーハンドリング
        * Rust側のスレッドセーフティ
        * Rustのみのコードでの並列処理
    * RustコードからPythonコードを呼び出す
        * Pythonモジュールのインポート
        * Python関数とメソッドの呼び出し
* maturinを使用したRustで書かれたPythonライブラリのパッケージング
    * Pythonパッケージビルドバックエンド
    * maturin newで新しいパッケージを開始
    * maturinのパッケージ設定
    * maturinでPython wheelを作成・配布
* まとめ
    * Pythonは、進化し続ける柔軟な言語であり、明るい未来があります。
    * Rustは、Python向けのメモリセーフで高速なコードをかける
    * PyO3とmaturinで、Python向けのRustコードを簡単に書け、パッケージ化できる

Ian Lewis

Python & Rust: 次世代のPython開発

私はプロのソフトウェア開発者ではなく、がん治療の現場で働く医学物理士です。日々の業務で扱う医療用デジタルデータ（DICOM）の活用に悩んでいた私が、解決策として出会ったのがPythonでした。「Pythonが医療専門家の共通言語になれば、私たちの働き方はもっと豊かになる」と信じ、2017年に広島で放射線治療に特化したPython講習会を立ち上げました。本講演では、広島で始めた対面式の小規模の講習会が、コロナ禍のオンライン化という転機を経て、実数1000名を超える専門家が集うコミュニティへと発展したか、その経緯をお話しします。また、活動を続ける中で見えてきた、医療現場におけるPythonの現実的な役割と、私自身がコミュニティから受け取た数多くのギフト（共同研究や新たな学びの機会）についても共有します。

中尾　稔

【招待講演】医療職が始めるPython：1000人が集うコミュニティの創造

NumPy is fast, but how can we go faster? In this talk, we will show how to make a faster backend for array processing by writing high-performance code from scratch. We will explore how to construct a NumPy-like array engine in C++, integrating hardware acceleration features such as single-instruction multiple data (SIMD), and exposing it to Python using Pybind11. Comparison of runtime performance to NumPy is made to analyze how well it works and plan for continuous improvement. This talk will provide practical insights for Python users interested in low-level performance optimization and extension development.

NumPy is a popular choice for array operations and numerical computation in Python, offering a simple interface and excellent performance. However, its architecture—built primarily around the Python C-API—can be difficult to integrate into applications where tighter control over system components is required.
In our project, we implemeted a custom array computation backend in C++ to meet integration requirements specific to our numerical application. To utilize the usability benefits of Python, we exposed this backend via Pybind11. 
In this talk, I will share our experience building this system, with a focus on achieving runtime performance comparable to NumPy through low-level optimization and exposing the backend with a clean Python interface.

Kuan-Hsien Lee

How Fast Can We Go? Build a NumPy-Like Backend in C++ with Python Bindings

Pythonの柔軟性は魅力的ですが、その結果として「すぐにリプレイスを余儀なくされるコード」を生み出すことも少なくありません。私たちはテレシー社で6年間、数多くのPython製WebAPIおよびバッチマイクロサービスを運用する中で、「6年間進化し続けるコード」と「短命なコード」の明確な違いを肌で感じてきました。

PyCon JP 2025のテーマ「あつまれPythonのピース」が示すように、Pythonを支える多様な技術、ツール、経験、そして人々が繋がり、新たな可能性を生み出す場を目指しています。このトークでは、私たちの実体験から得られた「転ばぬ先の杖」となる設計原則と具体的なテクニックに焦点を当てます。

特に、型定義の重要性、見通しの良い設計手法、依存性逆転（DIP）によるアーキテクチャの柔軟性、そしてこれらを支えるPydanticなどのツール活用術について、実際の失敗談や成功例を交えながら解説します。特定のWebフレームワークに縛られない設計が、将来的な技術選定の柔軟性をどう高めるか、そしてストレージスタック変更のような大きな変化にどう対応できたかをお伝えします。

これからPythonで堅牢なサービスを構築しようとしている方、または既存システムのメンテナンス性に課題を感じている方にとって、明日から活用できるヒントを提供します。

テレシー社が6年間のPythonマイクロサービス運用で直面した具体的な課題と、それを解決するために導入した設計・開発プラクティスを、実例を交えて解説します。私たちの経験は、まさに「Pythonのピース」が繋がり、より長く「育てられる」システムを構築した証です。

失敗から学ぶマイクロサービス開発の現実
まず、私たちが引き継いだ、あるいは初期に開発したアプリケーションコードが抱えていた具体的な問題点から話を始めます。特に、「メソッドに何が渡されるか分からないような型不明瞭なコード」や、「レイヤー構造が不明確で開発者がどこに何を書くべきか迷うコード」が、いかに開発効率と保守性を損なうかを具体例を挙げて解説します。これらの課題が、いかに「寿命の短いコード」へと繋がったかをお話しします。

持続可能なWebAPI、バッチアプリケーションの構築
これらの課題を乗り越えるため、私たちはWebAPIとバッチアプリケーションの設計と実装において、特定のフレームワークに強く依存せず、必要な機能を自分たちで選定し構築するアプローチを取りました。これにより、将来的な技術選定の柔軟性を確保し、FastAPIなどの別のフレームワークへの移行も容易な疎結合なアーキテクチャを実現しています。

WebAPI（Flaskのルーター＋選定ライブラリ）:

Flaskのルーター機能のみを活用し、ビジネスロジックやドメインモデルを完全に分離する戦略を採用しました。これにより、アプリケーションの核となる部分はフレームワークに縛られず、再利用性や保守性を高めています。

SQLAlchemy を用いた堅牢でフレームワーク非依存なデータベース管理層を構築。

Pydantic による厳密なデータバリデーションと型安全の確保は、特に「メソッドに何が渡されるか分からない」という初期の課題を解決する上で決定的な役割を果たしました。これらのライブラリはフレームワークに依存しないため、他のWebフレームワークへの移行時にもシームレスに利用可能です。

Alembic によるデータベースマイグレーション管理の効率化も、長期運用において重要なピースです。

バッチアプリケーション:

バッチアプリケーションにおいては、特定のフレームワークには依存せず、シンプルな依存性逆転設計を適用した独自の設計を採用しています。これにより、WebAPIで培った知見（特にデータバリデーションやドメインロジックの分離）をバッチにも適用し、堅牢性とテスト容易性を保った開発を進めました。

依存性逆転設計（DIP）によるコード品質の向上
コードの見通しと保守性を劇的に向上させた依存性逆転設計（DIP）について深く掘り下げます。具体的なコード例を通じて、DIPがもたらす設計上の利点（テスト容易性、機能追加の柔軟性、各レイヤーの独立性）と、それが「開発者がどこに何を書けばよいか分からない」という問題をどのように解決したかを解説します。

さらに、この設計思想は、初期のMySQL/AWS S3というストレージスタックから、Snowflakeへのデータ基盤の移行（ダッシュボード表示に必要なメトリクスデータ移設）といった、大きなインフラ変更時にも真価を発揮しました。依存性逆転させていることで、アプリケーションのコアロジックに大きなリアーキテクチャを施すことなく、新たなストレージに対応できた具体的な経験を紹介し、プロジェクト全体の柔軟性と再利用性がどのように向上したかを実例をもとに説明します。

チーム開発を加速させる開発環境とツールチェーン
新メンバーがスムーズに開発を開始し、チーム全体で効率的に開発を進めるためのプラクティスも重要です。

Dockerfileとdocker compose を用いた、再現性の高い開発環境の構築方法。「makeを実行すればすぐに開発環境が手に入る」という具体的なプラクティスを公開し、チーム開発における環境構築の課題解決について詳述します。

Pytest による効果的なテスト自動化。

UV を活用したパッケージ管理の工夫と、依存関係の管理戦略。

CI（GitHub Actionsなど） の構築を通じた開発プロセスの効率化と品質担保。

認証周りの堅牢な実装（Auth0の活用）
最後に、実際のアプリケーションにおける認証機能の重要性と実装について触れます。Auth0 を利用した認証の実装方法を具体的に解説し、セキュリティとユーザー管理のプラクティスについても簡単に紹介します。

fujidomoe

育てるアーキテクチャ：戦い抜くPythonマイクロサービスの設計と進化戦略

最近では、生成AIにコードを書かせることが主流になりつつあります。しかし、だからこそ、「なぜこのコードで動くのか」を理解することが大切だと考えます。
そんな中、データベースは日々使うツールなのに、中で何が起きているかまで理解している方は少ないのではないでしょうか。
そこで、今回は、Pythonを用いて自作したRDBMS：KeiPyDBを使って、データベースの中でも特にRDBMSに焦点を当てて、内部の仕組みを一緒に見てみたいと思います。

発表の構成：
* イントロダクション（3分）：自己紹介、なぜ作ったか、全体アーキテクチャ
* 以下のトピックから、最も興味深い発表ができるものを2〜3選んで構成予定（計27分）：
   * SQLパーサーと実行エンジン：文字列からクエリ実行までをステップ実行で追う
   * ファイルI/O：データの永続化とヘックスビューアーでの可視化
   * トランザクション : ACID特性の実現
   * エンディアン：なぜビッグエンディアンか、バイトオーダーの影響
   * インデックス：ハッシュ、B-Tree、B+Treeの動作、特性の違いがどこから来るのか

現在、それぞれのトピックでの「見せ方」を検討中です。デバッガでのステップ実行とヘックスビューアーでの可視化を組み合わせ、「なるほど、こうなってたのか！」と感じてもらえるような発表を予定しています。

RDBMSを実装してみて、この巨大で複雑なシステムも、一つ一つのピースに分解すれば意外とシンプルなものの組み合わせであるということが理解できました。
参加者が、Pythonで読んで、動くところを見て、RDBMSを理解する一助になれば幸いです

k-kamijo

Python製RDBMSで理解する、データベースのピース 〜コードのステップ実行とヘックスビューアーで内部動作を追ってみよう〜

PythonにはPyAudioやNumPy、Matplotlibをはじめとした信号処理や可視化のためのライブラリが豊富に提供されています。このトークではPythonの入門者やこれから信号処理や音声の分析をしてみたいPythonistaに向けて、音声分析の基礎や音の可視化について説明します。
「音を視る」ことができるスペクトログラムのアルゴリズムを基礎から紹介し、いろいろな音を見てみましょう。トークの中では音の可視化結果をPythonで分析し、物理的にどういう現象が起こってその音になっているかの考察を添えることで「音を視覚的に楽しむ」ことが伝わるようにしたいと思います。

このトークでは次のコンテンツを予定しています。

* 自己紹介
* あえてPythonで信号処理をするモチベーション
  * 豊富なライブラリ群との連携
  * 迅速なプロトタイプコードの作成ができる
* 環境構築
  * venv
  * 外部ライブラリのインストール
* 音声分析の基礎
  * 音の3要素
  * フーリエ変換
    * DFTとFFTを書いてみよう
  * STFTとスペクトログラム
    * 図解スペクトログラム
    * 各解析設定と結果の違い（動画）
* 色々な音の可視化結果（複数音源）
  * この音なんでしょう？
    * 人の声？楽器？動物？
  * この音はどんな要素でできている？
    * スペクトルから考察
    * ScyPyのシミュレーションで再現
* スペクトログラムの応用
  * 機械学習へ応用してみよう
* リアルタイムスペクトログラムのデモ
  * 会場の音を視てみよう（発表の進行具合によります）

Python×信号処理入門！スペクトログラムで視る音の世界

FastAPIは「**Pydanticモデル＋デコレータ＝型安全なREST API**」という魔法のような開発体験を実現し、Python Web開発に革命をもたらしました。この「**型を書けば全てが自動化される**」という開発体験を、gRPC/Connect RPCの世界に転写するとどうなるでしょうか？

本セッションでは、その思考実験に基づき「**Pydanticによる型駆動開発**」を**gRPC/Connect RPC**へ応用した拙作 **pydantic-rpc** (https://github.com/i2y/pydantic-rpc) を通じて、**最新のRPC技術**と**Pythonの型システム**を橋渡しします。難解に思われがちなgRPCやConnect RPCを、FastAPIやPydanticを少し知っている程度の方ならどなたでも理解できる形で解説し、**protoファイルなしで**今すぐ始められる方法を実演します。

### 参加者が持ち帰る3点
1. **最新RPC技術への橋渡し**：gRPC/Connect RPCを、FastAPIの知識から理解する方法
2. **実践的な始め方**：protoファイル不要で、Pydanticモデルから直接RPC開発を始める手順
3. **技術選択の指針**：REST（FastAPI）とRPC、それぞれが輝く場面の見極め方

### 聞き手と得られるもの
- **これからgRPCを学びたいPython開発者**：FastAPIの知識を活かして、最新のRPC技術にスムーズに入門できます
- **FastAPIユーザー**：慣れ親しんだPydanticモデルで、マイクロサービス間通信の新しい選択肢を得られます
- **API設計に悩む開発者**：REST vs RPCの実践的な使い分け基準を理解できます

FastAPIは「**Pydanticモデル＋デコレータ＝型安全なREST API**」という魔法のような開発体験を実現し、Python Web開発に革命をもたらしました。この「**型を書けば全てが自動化される**」という開発体験を、gRPC/Connect RPCの世界に転写するとどうなるでしょうか？

本セッションでは、その思考実験に基づき「**Pydanticによる型駆動開発**」を**gRPC/Connect RPC**へ応用した拙作 **pydantic-rpc** (https://github.com/i2y/pydantic-rpc) を通じて、**最新のRPC技術**と**Pythonの型システム**を橋渡しします。難解に思われがちなgRPCやConnect RPCを、FastAPIやPydanticを少し知っている程度の方ならどなたでも理解できる形で解説し、**protoファイルなしで**今すぐ始められる方法を実演します。

### 参加者が持ち帰る3点
1. **最新RPC技術への橋渡し**：gRPC/Connect RPCを、FastAPIの知識から理解する方法
2. **実践的な始め方**：protoファイル不要で、Pydanticモデルから直接RPC開発を始める手順
3. **技術選択の指針**：REST（FastAPI）とRPC、それぞれが輝く場面の見極め方

### 聞き手と得られるもの
- **これからgRPCを学びたいPython開発者**：Pythonの型ヒントやFastAPI/Pydanticの知識を活かして、最新のRPC技術にスムーズに入門できます
- **FastAPIユーザー**：慣れ親しんだPydanticモデルで、マイクロサービス間通信の新しい選択肢を得られます
- **API設計に悩む開発者**：REST vs RPCの実践的な使い分け基準を理解できます

### タイムテーブル暫定案
| 分 | 内容 |
|---|---|
| 0–5 | **なぜ今、RPCなのか？** • マイクロサービス時代のAPI通信の課題 • FastAPIが示した「型駆動開発」の価値を振り返る |
| 5–12 | **ライブコーディング：FastAPIの感覚でgRPC開発** ① おなじみのPydanticモデル定義（User, Task） ② pydantic-rpcでRPCサービス化（5行のコード） ③ 実行して動作確認（grpcurl & Pythonクライアント） |
| 12–18 | **裏側で何が起きているか** • Pydantic→Protobuf自動変換の仕組み • 型安全性がもたらす開発者体験の向上 • つまずきポイントと解決策の共有 |
| 18–24 | **実践での使い分け** • いつREST？いつRPC？実例で理解する判断基準 • 同じPydanticモデルで両方のAPIを提供する設計パターン • Connect RPCでブラウザから直接呼び出せるRPCの実現 |
| 24–30 | まとめ & Q&A ―「Pythonで最新のAPI技術を使いこなすために」 |

### なぜこの発表をしたいのか
gRPCは高性能で型安全なRPC技術として注目され続けていますが、「protoファイルの記述が面倒」「学習コストが高い」という理由で敬遠されがちです。Connect RPCはgRPCをWebフレンドリーにした技術ですが、やはりprotoファイルは必要です。一方で、FastAPIの登場により、多くのPython開発者が型駆動開発の恩恵を実感しています。

この二つの世界を橋渡しすることで、**より多くのPython開発者が最新のRPC技術（gRPC/Connect RPC）を活用できる**ようになると信じています。pydantic-rpcの開発を通じて得た知見を共有し、皆さまのAPI開発選択肢の拡大に貢献できれば幸いです。

FastAPIの魔法をgRPC/Connect RPCへ -- Pydanticモデル駆動RPC開発

Pythonを用いた開発において、途中からuvを採用したモノレポ構成へ移行した際の道のりを共有します。
私のプロジェクトでは、当初pipenvを用いてシンプルなリポジトリで開発を始めましたが、開発が進むにつれ、リポジトリに性質の異なるモジュールが生まれ、開発の属人化・デプロイ手順の複雑化・それに伴うCI/CDパイプラインのメンテナンスコストの上昇が見られるようになりました。
これに対して、リポジトリの構成を見直し、uvを使用したモノレポ構成に変更することを決めました。
本セッションでは、この経験をもとにモノレポ構成への変更を決めた要因、構成変更の方針の立て方、変更の過程における対処方法、作業における生成AIの活用方法、構成変更によるメリットとデメリット、その対処法についてお話しします。

リポジトリ構成に課題を感じている方、チームでの開発効率やCI/CDの運用改善に関心のある方に、ヒントや具体的な実践例を持ち帰っていただける内容を目指しています。

本セッションでは、Python開発プロジェクトにおいて、当初の pipenv によるシンプルな構成から、uv を活用したモノレポ構成へと移行した道のりと、その工夫についてお話しします。  
以下のような流れで、実際に直面した課題と、それに対する技術的・運用的な解決策を紹介します。

- pipenv を用いた初期構成  
  開発初期に選択した環境構成と、その背景について説明します。

- 開発が進むにつれて顕在化した課題  
  要件の変化、開発者の増減、思想の変化などにより発生した、属人化・手順の複雑化・CI/CD のメンテナンス負荷といった具体的な課題についてお話しします。

- なぜモノレポ構成を目指すのか  
  構成見直しの狙いや、許容したリスクについてお話しします。

- 構成変更のスケジューリング  
  構成変更は完全な切り替えではなく、段階的に進めています。構成変更のプロセスと、その判断基準について触れます。

- uv にタスクランナーがない問題への対応  
  pipenv や poetry にある「スクリプト定義」が uv には存在しません。途中段階で採用した代替手段と、最終的な落とし所についてお話しします。

- 既存のリンターやフォーマッターの統合方法  
  構成変更に伴い、リンターやフォーマッターも見直すかどうかを検討しました。こちらも途中段階での対応と、最終的な落とし所についてお話しします。

- デプロイ手順の見直しと CI/CD の再設計  
  パイプラインが肥大化していた状態から、構成変更によってメンテナンスしやすい形に再構築したアプローチを紹介します。

- 構成変更作業における生成 AI の活用  
  ディレクトリ構成の変更、デプロイスクリプトの作成、デプロイの検証といった場面で生成 AI を活用した例を紹介します。

- 「共通モジュール」の扱い  
  モノレポ構成にしたことで重複コードが目立つようになり、共通モジュールの作成を決めました。しかし、共通モジュールはそれ自体がモノレポ構成内の各モジュールからの読み込みに苦労する要因となったため、その対策を共有します。

Satoshi Kaneyasu

複雑化したリポジトリをなんとかした話、pipenvからuvによるモノレポ構成への移行

Is the multiprocessing serialization bottleneck slowing down your data-intensive applications? A new **piece** of Python has arrived to solve this. The experimental **free-threading mode in Python 3.13+**, which disables the Global Interpreter Lock (GIL), offers a powerful, built-in solution that eliminates serialization overhead.
In this session, I will demonstrate how this new capability can dramatically outperform multiprocessing and even achieve throughput comparable to frameworks like Ray for single-node ML workloads. Through a **live refactoring demo**, we will transform a slow data pipeline into a high-performance, free-threaded application, exposing common pitfalls to avoid. This isn't just theory; it's a new, battle-tested playbook to supercharge your code.

At PyCon JP 2024, we saw a [fantastic introduction](https://pretalx.com/pyconjp2024/talk/A8BQEF/) to the experimental free-threading mode. A year has passed—but how many of us have dared to use it to solve a real-world problem? Whether you're already fighting the multiprocessing serialization bottleneck or simply frustrated that your data-heavy tasks aren't as fast as they should be, this talk is for you.

### The Landscape is Changing

The initial release of free-threading in Python 3.13 came with a known trade-off in [single-threaded performance](https://docs.python.org/3/howto/free-threading-python.html#single-threaded-performance), but the landscape is evolving. We'll dive into the crucial improvements in Python 3.14 that mitigate this issue, making free-threading a more powerful and viable choice than ever for parallel workloads.

### From Theory to a Battle-Tested Playbook

This session delivers a battle-tested playbook, moving from core concepts to a real-world application. Drawing from my experience developing an open-source framework to accelerate a data-intensive research field, I’ll guide you through the following:

- **The "Why" and "How" of Free-Threading**: First, understand the fundamentals of Python's new parallel execution model. We'll cover why multiprocessing struggles with data-intensive tasks and how free-threading provides an elegant, built-in solution.

- **A Real-World Case Study with Hard Data**: Next, we'll dive into a [real-world project](https://github.com/kitsuyaazuma/blazefl) in Federated Learning where free-threading crushed a critical performance bottleneck. You'll see the benchmarks showing its dramatic throughput increase against both multiprocessing and an established framework like [Ray](https://github.com/ray-project/ray).

- **Live Refactoring & Best Practices**: Finally, watch a slow data pipeline get transformed into a high-performance application in a live demo. You will leave with a practical playbook and the confidence to apply these techniques, avoiding common pitfalls like race conditions.

Join me to see how this powerful new **piece** of Python can integrate with demanding ML workloads, unlocking a new level of performance and truly supercharging your code.

Kitsuya Azuma

Beyond Multiprocessing: A Real-World ML Workload Speedup with Python 3.13+ Free-Threading

Python 3.9で標準ライブラリにgraphlibが追加されました。graphlibはグラフ理論におけるグラフのトポロジカルソートを行うライブラリです。グラフ理論におけるグラフとは何か、トポロジカルソートとは何にか、結局graphlibは何に使えるのか、すべて（なるべく）解説します。明日からgraphlib、みんなで使おう。

### 導入
Python 3.9で標準ライブラリにgraphlibが追加されました。
しかし、公式ドキュメントにはgraphlibが導入されたモチベーションや利用例に乏しく、すでにトポロジカルソートの存在を知っている人しか使えないライブラリになっています。
結局、graphlibは何に使えるのか、電池が液漏れする前に（なるべく）すべて解説します。

### グラフ理論速習
graphとは数学のグラフ理論におけるグラフを意味します。
グラフとは（大雑把に説明すれば）物事とその関係性を数学的にモデル化したものであり、鉄道網における駅と線路、人間関係における人間と友人関係など、日常生活においてグラフでモデル化できるものはたくさんあります。
- グラフとは
- 無向グラフと有向グラフ（今回扱うのは有向グラフ）
- 線型順序について（半順序関係、全順序関係）

### トポロジカルソート、有向非巡回グラフ（DAG）について
任意のグラフがトポロジカルソートできるわけではありません。
グラフが有向非巡回グラフであることと、グラフがトポロジカルソート可能であることは同義であることを説明します。

- 有向非巡回グラフの定義
- トポロジカルソートの定義
- グラフが有向非巡回グラフであることと、グラフがトポロジカルソート可能であることは同義

### graphlibの使い方
ここまで理解できれば、明日からgraphlibを使えるようになります。
少なくとも、頭の片隅にgraphlibが入り、必要になった瞬間に思い出せるようになります。

- graphlibの使い方
- 応用例: タスクの処理
- 応用例: クラスの関係

Hayao Suzuki

明日からgraphlib、みんなで使おう

Pythonで開発されたWindows向けソフトウェア(.exe形式)においては、開発環境の構築不要で、動作中のソフトウェアのコードをリアルタイムに書き換え可能な環境を提供することができます。
これは、インタプリタとソースコードをパッケージ化するという配布方式と、スクリプト言語でありながらWindowsの機能の大半を利用できるという言語の強みが合わさって実現されています。

この発表では、オープンソースのスクリーンリーダー（視覚障害者向けの画面読み上げソフト）であるNVDAを題材に、
Pythonだからこそ実現可能なリアルタイム・デバッグの手法をご紹介します。
必要なものは配布されているパッケージとソースコード、Windows附属のメモ帳のみです。

この環境はOSSへの参加やアドオン開発のハードルを格段に下げてくれます。Pythonビギナーの私も、この方式のおかげでアドオンを公開することができています。

さらに、諸学者の教育にも有用かもしれません。
実際に動いているものを数文字直してみるという最初の一歩から大きな機能の追加まで、手軽に経験してもらうことができそうです。
この発表をきっかけに、Pythonの学習環境についても議論できればと思います。

河内勇樹

Pythonだからできる、既存ソフトウェアの高効率なデバッグ方法

Python in ExcelはExcelのセルにPythonのコードを埋め込める機能で、2024年10月に一般提供を開始しました。
Excelをインストールすればすぐ使える機能なので、Pythonの動作環境のセットアップを行わずにデータ解析や機械学習を手軽に試すことができます。
このトークでは、Python in Excelをより便利に使いこなすための、実践プラクティスを紹介します。
トーク中には実際にExcelの画面を表示させたデモも行う予定です。

## Python in Excelの概要

まずは、Python in Excelの概要について説明します。
以下について紹介します。

* Python in Excelはどんな人に役立つ機能か
* Python in Excelの導入方法
* Python in Excelの基本的な使い方

## Python in Excel実践プラクティスの紹介
### 実践プラクティスの情報ソースについて紹介

Python in Excelを便利に使いこなすためのプラクティスを紹介しているサイトを紹介します。
本トークの内容は、これらのサイトをベースに作成しています。

### 元のデータはPython以外を使って加工しない

通常のプログラミングと同様に、Python in Excelにおいても再利用性が高いコードを書くためのテクニックがあります。ここでは、プラクティスを使わなかった場合、使った場合のExcelブックを比較し、プラクティスがどのように役立つのかを説明します。

### コードは複数のセルに分割して書く

Python in Excelでは、ある程度長いコードを書く場合、1つのセルにすべての処理を書いてしまうと可読性が落ちてしまいます。そんなときは、コードを複数のセルに分割して書く方法をお勧めします。
複数のセルに分割して書く場合、留意しなければならないのは「セルの実行順序」です。ここでは、Python in Excelが複数セルに書かれたPythonコードをどの順番で実行するかを説明します。

### 各セルに「文字列リテラルのコメント」を書く

Pythonは「#」より右側の文字列はコメントとして扱われます。Python in Excelでもコメントを書くことができますが、もっとコードを読みやすくするためのテクニックがあります。
ここでは、「文字列リテラルのコメント」の使い方、「文字列リテラルのコメント」が通常のコメントより優れている点について紹介します。

### グラフの描画時に日本語フォントを指定する

Python in Excelではseaborn、matplotlibなどを使ってグラフを描画することができますが、デフォルトではグラフ中の日本語が文字化けします。ここでは、グラフに日本語を表示させる方法について紹介します。

### その他Tips

その他の細かいTipsについて紹介します。

Ryuji Tsutsui

Python in Excelをより便利に使える実践プラクティスの紹介

Python 3.13 was the first Python version released with a free-threaded mode. Although the default interpreter still utilizes the GIL, it provides provisions that enable us to run a free-threaded version of the interpreter with the GIL disabled. 

Through this talk, we’ll set up and run the free-threaded interpreter, benchmarking it against the GIL-enabled version for various tasks. We'll assess the impact on single-threaded vs multithreaded code and test the performance across CPU-bound and I/O-bound tasks, aiming to identify scenarios where free-threaded Python excels.

Adarsh Divakaran

Goodbye GIL: Exploring the Free-threaded mode in Python 3.13 and Beyond

Pythonでデータ処理を行うとき、pandasやpolarsのようなライブラリ群を使う人は多いと思います。また、これらのライブラリにこだわらずPythonスクリプト「効率よくスケールさせたい」、「定期的に動かしたい」と考えたことはありませんか？
データ量が増えてくると様々なケースで「もっと自動化して効率よく処理したい」という壁にぶつかることがよくあります。
そんなときに役立つのが、Dask、Ray、Prefectなどの「分散処理」や「ワークフロー管理」に関わる様々な分散フレームワークたちです。
しかしながら、これらのフレームワークは数がありすぎて「どれがどんなときに向いているのか」が分かりづらいのも事実です。
このトークでは、複数のPythonで利用可能な分散処理フレームワークの特徴を比較します。Pythonのコードをスケーラブルに・効率的に動かすための方法について紹介します。Ray、Prefect、Dask、Restateなどの他、用途別にどのような選択肢があり、何を基準に選べば良いのかを整理し、「とりあえずDask？」「Rayって何？」といった疑問を持つPythonユーザーのために、「選び方」を共有します。

Pythonには多くの分散処理・ワークフロー系のツールがありますが、それぞれに向いているユースケースが異なり、初心者が全体像を把握するのはなかなか難しいのが実情です。

このトークでは、「Pythonコードをもっと速く、安定して、信頼性高く実行したい」と思った人に向けて、代表的な分散処理フレームワークの選び方と使いどころを以下の観点で紹介します。なお、下記の分散処理フレームワークすべてについてトーク時間内で話すのは困難であるため、トークでは3つ程度（Dask、Ray、Prefect）などのツールに絞って紹介します。（下記リストには比較やポイントのみとして登場するツールについても記載しています。）

* Dask：pandas互換の並列処理基盤
* Ray or Mars：汎用的な並列タスク実行。機械学習にも強い
* Prefect or Airflow or Luigi：ETLやバッチ処理のワークフローを構築・スケジュール
* Temporal or ReState：ステートフルな処理を信頼性高く管理。複雑なフローや再試行、管理が必要なときに
* Modal：任意のPython関数をServerlessで実行。

それぞれのツールの特徴、学習コスト、使い始めやすさ、Pythonとの親和性などを比較しながら、「Pythonにおける分散処理フレームワーク選び」を提案します。
このトークを通じて、「Pythonで書いたコードを、もっときちんと動かしたい」という人が、迷わずに一歩踏み出せるようになることを目指しています。

Satoru Kadowaki

Pythonによるデータ処理のための分散フレームワーク選び

衛星データの解析は専門的なソフトウェアが必要と思われがちですが、Pythonとオープンソースライブラリを活用することで、初心者でもすぐに取り組めるようになってきました。本トークでは、オープンに公開されている衛星データを題材に、Pythonでの衛星データ取得、可視化、簡単な解析までを一連の流れで紹介します。都市の変化や植生の分析など具体的なユースケースを交えながら、初心者でも扱いやすいライブラリを中心にJupyter Notebook上でデモを進めます。  
聴講者が日常的なデータ分析の延長として衛星データを扱うイメージを持ち、衛星データ活用の第一歩を踏み出せることを目指します。

**トークの詳細**  
衛星データの活用は専門的で難しそうという印象を持たれがちです。しかし近年、災害対応や農業モニタリング、都市計画など幅広い分野で官民問わず衛星データの利活用が検討され、社会にとってますます重要になっています。こうした中で、Pythonとオープンソースのライブラリを活用することで、初心者でも衛星データを手軽に扱える環境が整ってきました。本トークでは、Pythonを用いた衛星データ解析の基礎から可視化、簡単な解析までを幅広く紹介します。  
具体的には、衛星データの概要とオープンに公開されているデータの入手方法を解説し、leafmap、rasterioなどPython初心者でも扱いやすいライブラリを用いて、衛星データの取得・表示・簡易解析（植生域や都市変化の可視化など）の一連の流れをJupyter Notebook上でデモします。  
衛星データは他の統計データや機械学習と組み合わせて使われることも多くなってきています。Pythonはこれらの分野でも広く使われているため、衛星データをPythonで扱うことは非常に親和性が高く、応用の幅を広げやすいと考えています。農業のモニタリングや都市変化の検知、防災への活用といった具体的なユースケースをイメージしていただき、日常的なデータ分析の延長として衛星データを活用できる感覚を持ってもらうことを目指します。


**発表内容（仮）**  
- 自己紹介
- 衛星データとは？
- 衛星データの取得方法
- 衛星データをPythonで可視化してみよう
- 簡単な解析を行ってみよう
- 応用ユースケースの紹介
- まとめ

ぴっかりん

Hello, satellite data! ～Pythonではじめる衛星データ解析～

40歳を過ぎてから独学でiPhoneアプリを開発したことをきっかけに、15年間にわたり挑戦を続けてきた経験を紹介します。新しいことを始めるのに年齢は関係ないこと、手を動かすことでITの世界がより鮮明に理解できること、仲間と学び合えるコミュニティに出会えること。そして、挑戦を重ねる中で自らの世界が大きく広がっていった過程を、時系列に沿ってお話しします。

tatsuya1970

【招待講演】＃普通の文系サラリーマンチャレンジ　自分でアプリ開発と電子工作を続けたら人生が変わった

Ever had your app crash at the worst moment, during checkout or a key transaction? When that happens, users leave fast. Behind each crash is a bigger story: alerts firing, teams scrambling and no clear root cause. Modern systems are fast, complex and full of hidden failure points. One small issue can ripple out quickly. This talk frames observability not as an ops task but as core engineering. Built on open standards like OpenTelemetry, it avoids vendor lock-in and puts you in control. You’ll learn how to instrument Python app, process telemetry and export it for analysis. It's not just about logs, metrics, or traces—it’s about clarity. If you're a developer or the one on-call when things break, this session will give you practical skills and a new way to think about shared system insight.

# Key topics:

- The evolution of observability and why it has become essential over the past few decades.

- A deep dive into core telemetry signals: Logs, Metrics, and Traces.

- The challenges developers face with modern observability, and how adopting OpenTelemetry can address these issues.

- A comparison between traditional approaches and the OpenTelemetry method, focusing on everything from easy Python code instrumentation to advanced data processing and seamless telemetry export to any observability backend—without vendor lock-in.

- Different sampling techniques like head, tail, probabilistic, allow you to have full control over the data you ingest and its associated costs with different setup strategies.

- Best practices for reducing observability costs with telemetry pipelines.  

- Getting started with OpenTelemetry, including a live code demo.

- Future of AI in the of open-source observability and few ongoing work on OpenTelemetry with eBPF.

Yash Verma

Observability Matters: Empowering Python Developers with OpenTelemetry.

Pythonは科学・工学・教育など多様な分野で活用されています。米国で開催されるSciPy Conferenceは、こうした分野の実践者たちが集い、PythonによるオープンサイエンスとOSS開発を推進する国際カンファレンスです。本セッションでは、2022〜2024年の連続参加を通じて見えてきた、スプリント文化やプロジェクト間連携、誰もが参加できるコミュニティの育て方について紹介します。

SciPy Conferenceは、Pythonを軸に科学とソフトウェア開発が交差する国際的なカンファレンスです。セッション発表に加え、プロジェクト横断のスプリントやハンズオン、教育者・研究者・OSS開発者が垣根なく交流する文化が特徴です。

本セッションでは、以下のようなトピックを扱います：

- SciPy Conferenceの概要と現地の雰囲気
- MyST × PyVistaやGeoVistaなど、実際のプロジェクト連携スプリント事例
- 初心者や非エンジニアでも参加しやすい工夫（ウェルカムイベント、メンタープログラムなど）
- ボランティア運営の仕組みと、持続可能なコミュニティ形成へのヒント
- 日本のコミュニティとつなげる具体的アイデア（SciPyDataJapan など）

科学技術に限らず、教育、文書化、可視化、そしてOSSへの参加など、幅広い実践知を共有します。Pythonが「科学をひらく」ためのプラットフォームになり得ること、そしてその背後にある人のつながり＝コミュニティの力を伝えることが目的です。

Tetsuo Koyama

SciPy Conferenceから学ぶ、科学とPythonをつなぐコミュニティの作り方〜オープンサイエンスを支えるスプリント文化とコラボレーションの実践〜

「関数の戻り値が期待と違ってデバッグに時間を費やした」「引数にNoneが渡ってエラーになった」「リファクタリングが怖くて手を付けられない」など、Pythonの柔軟性が裏目に出て、コードの堅牢性が損なわれるケースは少なくありません。これらの問題は、動的型付け言語であるPythonの特性から来るものですが、実は契約プログラミングの考え方を取り入れることで、これらの課題を大幅に軽減することが可能です。

本セッションでは、バグの原因特定に時間を費やしているPython初心者〜中級者、コードレビューで関数の前提条件に悩むチームメンバー、より堅牢なコードを書きたいがアプローチが分からない方に向けて、「明日から使える実践的手法」から「高度なライブラリ活用」までの段階的な契約プログラミング導入法をお伝えします。

他言語での契約プログラミングと比較しながら、Pythonらしい実装方法を4段階で紹介します。「完璧を求めず、重要な部分から少しずつ」というメッセージを込めつつ、現実的な導入アプローチを提示し、デバッグ効率の向上、コードの意図の明確化、安全なリファクタリングの実現を手助けします。

同じ苦労を味わうPythonistaを一人でも減らし、より良いPythonコードを書く喜びを共有したいという想いを込めて、契約プログラミングの第一歩を踏み出すきっかけを提供します。

聞いてくれた方に「自分のプログラムにも少しずつ契約プログラミングを取り入れてみたい」と思ってもらうことをゴールに、以下の構成で発表を行う予定です。

1. 導入
    - 契約プログラミングとは何か
    - Bertrand Meyerの「契約による設計」
    - 事前条件・事後条件・不変条件の概念
2. 他言語での契約プログラミング
    - Clojureの例
    - Kotlinの例
    - 各言語でのアプローチの違い
3. Pythonにおける契約の段階的実装
    - Level 0: 型ヒント - 静的な契約
    - Level 1: assert文 + docstring - 実行時契約の基礎
    - Level 2: pydantic - データ契約
    - Level 3: dealライブラリ - 高度な契約
4. 実践における考慮点
    - デバッグ環境 vs プロダクション環境
    - テスト戦略との関係
    - チーム導入のステップ
5. まとめ
    - Pythonでの契約プログラミングの現実解
    - 明日から試せること

HASEBA Junya

Pythonによる契約プログラミング入門

本発表では、Pythonにおけるイミュータブル（不変）なデータ構造の重要性と、それを活用した堅牢なシステム設計について解説します。

多くのPython開発者は、リストや辞書などのミュータブル（可変）なデータ構造を日常的に使用していますが、これらが原因で発生する予期しない副作用やバグに悩まされた経験があるのではないでしょうか。特に、複数のモジュール間でデータを共有する際や、並行処理を行う際には、ミュータブルなオブジェクトが思わぬ問題を引き起こすことがあります。

本発表では、実務でのシステム開発で蓄積された知見をもとに、以下の内容を扱います：
- ミュータブルなコードが引き起こす典型的な問題パターン
- frozen dataclassesやプロパティを活用したイミュータブルな設計手法
- Webアプリケーションでの活用事例（データベースなど）

発表では、実際のプロダクションコードから抽出した具体例を交えながら、すぐに現場で活用できる実践的なテクニックを紹介します。Pythonの型ヒントとイミュータブルデザインを組み合わせることで、より安全で保守性の高いコードベースを構築する方法を学ぶことができます。

対象者は、Pythonでシステムを開発している方、チーム開発でコードの品質向上を目指している方々を想定しています

1. **イントロダクション（3分）**
   - ミュータブルなコードが引き起こした実際のインシデント事例
   - なぜ今イミュータブルが重要なのか

2. **ミュータブルの罠（5分）**
   - デフォルト引数の罠（`def func(items=[])`など）
   - 意図しない参照共有による副作用
   - リストの直接変更がもたらす追跡困難なバグ
   - 実際の失敗例

3. **イミュータブルデザインパターン（10分）**
   - frozen dataclassesの活用方法と注意点
   - プライベート属性とプロパティによる読み取り専用設計
   - 実務を例にした値オブジェクトの実装など

4. **実践的な活用方法（5分）**
   - 既存のミュータブルなドメインオブジェクトの改善など
   - Webアプリケーションでの活用事例（データベースなど）

5. **まとめとQ&A（2分）**
   - チームへの導入方法
   - パフォーマンスへの影響と対策

加藤雅也

Pythonで実現する堅牢なシステム設計 - イミュータブルがもたらす恩恵

Data scientists and AI engineers today have more tools than ever at their disposal. But more choices has also led to fragmentation, even when it comes to the basic task of loading data. With Apache Arrow ADBC (Arrow Database Connectivity), anyone working with databases in Python can access systems from BigQuery to PostgreSQL to Snowflake using familiar DB-API interfaces and maximum performance. We’ll show how ADBC makes it easy and fast to work with different data sources and different engines (like pandas and Polars). We’ll also look under the hood, with an introduction to the Apache Arrow ecosystem at the heart of the modern data science and AI ecosystems.

Apache Arrow is an open source project developing a high-performance, language-independent standard for in-memory representation of columnar data. Since its start in 2016, it has expanded to provide other related projects, from efficient file formats for storing data tables to RPC frameworks for developing data services. Many vendors and open source projects depend on or interoperate via Arrow or one of its subprojects, including pandas, Polars, PyIceberg, Snowflake, Apache Spark, and more.

One of the Arrow subprojects is ADBC (Arrow Database Connectivity), providing language-independent APIs for interacting with data systems (including databases and data warehouses) using Arrow data. The project aims to replace JDBC and ODBC for data science, OLAP, and AI/ML applications, as they demand more performance than existing implementations can fundamentally provide.

ADBC embraces polyglot development environments and zero-copy interfaces, which allows Pythonistas to more easily benefit from cutting-edge developments in data science and AI/ML. Thanks to Apache Arrow, ADBC users in Python can leverage drivers written in C++, Go, Rust, and other languages, giving them high-performance access to Snowflake, Databricks, BigQuery, PostgreSQL. Moreover, users can continue using familiar APIs (DB-API 2.0), while developers don’t have to provide Python-specific bindings. Arrow and ADBC also let Python users interoperate easily with libraries like Polars that have become popular for data science.

David Li

Fast, Universal Data Access with Apache Arrow ADBC

広島での高校生向けPython教育の事例を中心に、学びが地域課題解決へと広がる可能性を示し、教育×Pythonから始まる未来を展望します。

kan_yukiko

【招待講演】広島から世界へ ― Pythonで描くデータサイエンスの新しい未来

## 概要
TypeScript で培った型安全性への愛着を持つフロントエンドエンジニアが、Python での開発を始めて体験した「カルチャーショック」と「新たな発見」を共有します。言語の違いは単なる文法の違いではなく、思考パターンの転換でもありました。本セッションでは、JavaScript/TypeScript の世界から Python の世界へ飛び込んだ際の具体的な戸惑いと、それを乗り越えるための実践的なアプローチを紹介します。

### 発表の構成

1. **言語の違いから学ぶ、9 つのカルチャーショック** 

   - **TypeScript の型システムで得ていた安心感**
     - コンパイル時エラーからランタイムエラーへの心理的な不安
     - 型推論の恩恵を失った時の対処法

   - **Python の動的型付けへの最初の戸惑い**
     - 「型がないこと」の自由と責任
     - ダックタイピングという新しい考え方

   - **undefined と null から None へ：「無」の概念の統一**
     - JavaScript の 2 つの「無」から Python の 1 つの「無」へ
     - None の扱い方とベストプラクティス

   - **==と===の使い分けから、Python の==と is の理解へ**
     - 値の比較と参照の比較の新しい切り分け
     - よくある落とし穴と正しい使い分け

   - **オブジェクトの分割代入からタプルアンパックへの適応**
     - `const {a, b} = obj`から`a, b = tuple`への思考転換
     - 複数戻り値の扱い方の違い

   - **文字列の`${}`テンプレートから f-string への感動**
     - より直感的になった文字列フォーマット
     - f-string の隠れた便利機能

   - **CamelCase から snake_case へ：命名規則の文化的違い**
     - コミュニティの規約を尊重することの重要性

   - **array.map()からリスト内包表記へ：Python らしい書き方の発見**
     - 関数型プログラミングから Pythonic way へ
     - リスト内包表記の美しさと落とし穴

   - **React の useState から Python のクラス属性・インスタンス変数への概念転換**
     - 状態管理の考え方の根本的な違い
     - ミュータブルとイミュータブルの新しい理解

2. **実践！JavaScript エンジニアのための Python 型安全性戦略** 
   - Type Hints で取り戻す型の安心感
   - mypy を使った段階的な型チェックの導入
   - TypeScript ライクな開発体験の構築
   - 実際のコード比較：同じロジックを両言語で実装

3. **まとめ：両方の世界のいいとこ取り**
   - 言語の違いを強みに変える方法
   - フルスタックエンジニアとしての視野の広がり

翁 安

フロントエンドエンジニアが Python エンジニアになって見えた世界！

Pythonユーザーが作成したスクリプトやデータ分析、機械学習モデルなどの成果物を「見せる」「使ってもらう」には、アプリ化というハードルがあります。

本セッションでは、Pythonユーザーが自分のコードをすぐWebで共有できるようになるための手法として、PythonだけでGUIを構築できるWebアプリフレームワーク「Flet」の仕組みと使い方を紹介します。
Fletは、裏側でPyodideを使ってWebAssemblyを活用することで、従来のWeb開発の壁を取り払ってくれています。まずはこのフレームワークを通してPiodideとWASMを深掘ります。
次に実際に使えるサンプルを通じて、「見せられるPythonアプリ」を手軽に作る方法をデモを交えて解説します。

**Pythonだけで、誰かとつながれる**そんな開発体験を提案します。

Pythonはデータ分析や自動化、AIなど多様な分野で活用されていますが、その成果を「誰かに見せたい・使ってもらいたい」と思ったとき、Webアプリ化の壁にぶつかった経験はありませんか？HTMLやJavaScriptの知識、デプロイの面倒さに挫折した方もいるかもしれません。

このセッションでは、そうしたハードルを越え、「Pythonだけ」でWebブラウザ上に動作するアプリを構築・共有できる方法を紹介します。今回メインで紹介するのはGUIをPythonコードのみで記述できる**Flet**というフレームワークです。
Fletはマルチプラットフォームに対応しています。静的サイトを構築する場合は、**WebAssembly**（WASM）上でPythonを動かすためのランタイムである**Pyodide**を内部で活用しており、ユーザーは技術的な複雑さを意識することなく、Webアプリを素早く構築・共有できます。
まず、WASMとPyodideがどのようにFletの基盤を支えているのか、その構造をわかりやすく解説し、「なぜPythonがブラウザで動くのか」を理解します。
その後、実際の開発ユースケースに沿ったデモを通して、Fletによる開発の手軽さと拡張性を体験していただきます。

「Pythonで作る → ブラウザで動かす → 誰かに使ってもらえる」この一連の流れがどれほどシンプルかつ強力かを体感し、日々の開発や共有の可能性を広げるヒントを持ち帰っていただける内容です。

## 予定トーク構成

### 1. はじめに（2分）

- 自己紹介
- 自分のアイディアや成果を早くみんなに届けたい

---

### 2. 背景技術を知る：Fletの裏側で「動くピース」たち（12分）

- **GUIアプリケーションフレームワークの紹介**
- **Fletの仕組みと特徴**  
  - Pythonのみで完結するUI構築
  - FlutterとPyodideを使って実現
  - 宣言的で直感的なコードスタイル
  - 開発効率を高めるホットリロード
  - もちろんマルチプラットフォームに対応している
- **WebAssembly（WASM）とは？**  
  ブラウザでネイティブに近い速度で動作するための基盤技術。
- **Pyodideとは？**  
  WASM上でPythonを動かすランタイム。
- **Fletの中でPyodideがどう使われているか？**  
  「Fletを使うだけで、この複雑な技術が裏で動いている」ことを伝える。

---

### 3. 実演：PythonだけでWeb GUIを作りデプロイする（14分）

- **デモ①：CSV可視化アプリ（業務効率化ツール）**
  - CSVアップロード→グラフ表示→簡易フィルタ
  - 日常のちょっとした分析を「誰かと共有する形」に
- **デモ②：AIモデルのデモアプリ（アイデアの具現化）**
  - テキスト入力→AIモデルによる処理→結果表示
  - アイデア検証やプレゼンに即使えるWebアプリの形
- 作ったFletアプリをどう公開するか？
  - GitHub Pages, Vercel, Netlify, Cloudflare Pagesなどの活用方法

---

### 4. おわりに（2分）

- Pythonユーザーがもっと手軽につながれる開発体験の価値

Shintaro Matsudo

Pythonだけでつながるあなたのアイディア、フロントエンドもPythonで

Webアプリケーション開発の開発においては、@app.get("/users/{user_id}")のような一文で処理とパスのマッピングを記述しますよね。しかし、その一行の裏側で、フレームワークがどのようにして正しい処理を呼び出しているか、仕組みを考えたことはありますか？

本トークは、普段当たり前の機能として使いがちなパスルーティングの裏側に目を向けます。Python製WebフレームワークであるDjangoとFastAPIを例にとり、そのルーティング機能がどのようなアルゴリズム（単純な正規表現、効率的なTrie木など）によって実現されているかを、図やコードを交えて解説します。さらに実験を通じて、登録するルートの量や深さに応じて、アルゴリズムごとに実行時間がどのように変わるかを比較します。

このトークを通じて、競技プログラミングで学ぶようなアルゴリズムが、実世界のアプリケーション開発という身近な場所で活きている、その面白さを共有します。Webアプリを構成する重要なパーツであるルーティングへの理解を深め、当たり前に使っている機能がどのように実現しているかを探求する楽しさへと繋がることを目指します。

以下のアウトラインを想定しています。

1. はじめに (3分)
- 自己紹介とこのトークのゴール
- 対象聴衆（Web開発の次の一歩を踏み出したいBeginnerの方へ）

2. 身近なフレームワークにおけるルーティング (7分)
- Django: path() とre_path()
- FastAPI: Starletteにおけるルーティング実装

3. ルーティングアルゴリズムの世界へダイブ (12分)
- アプローチ1：正規表現
    - バックトラッキング
- アプローチ2：Trie木
    - Trie木と基数木
    - パスを効率的に探索する仕組みのStep by Stepでの解説
- 計算量の比較

4. 比較実験：速さと柔軟性のトレードオフ (5分)
- 実験概要：URLの数やネストの深さがマッチング速度に与える影響
- 実験結果見る各アプローチの特性
- 考察：パフォーマンスとパスパラメータ対応などの機能（柔軟性）のバランス

5. まとめ (3分)

hkws

Webアプリケーションにおけるパスルーティングアルゴリズムの解剖

PyCon JP TVのパーソナリティ2人が、Pythonで開発を始めるための環境を整備する過程をライブでお届けします。
Pythonのインストールから、VS Codeの設定、venv、pip、ruff、mypyなどのツールを導入して、Pythonのプログラムを実際に書き進めていきます。

* 自己紹介
  * パーソナリティ2名の紹介
  * PyCon JP Associationの紹介
  * PyCon JP TVの紹介
* Pythonのインストール
  * python.orgから公式インストーラーをダウンロードしてインストール
* VS Codeの設定
  * 日本語化
  * Pythonの拡張機能をインストール
* venvで仮想環境を作成
* pipでサードパーティ製ライブラリをインストール
* Pythonコードに型ヒントを付ける
  * エディタによる間違いの指摘を元に修正
* Ruffでコードを整形
* pyproject.tomlでRuffの設定を追加、コードのチェック内容を増やす

Takanori Suzuki

Manabu TERADA

Python開発環境の整え方ライブデモ

本トークでは、現在最も注目される3つの型チェッカーを比較し、それぞれの特性と適用場面を明らかにします。

  対象となるツールは：
  - mypy：Pythonコミュニティで最も歴史があり、67%の開発者が使用する事実上の標準
  - pyright：Microsoftが開発し、38%が使用するモダンな型チェッカー
  - ty：Astral社（ruff/uvの開発元）がRustで開発中の次世代型チェッカー

  これら3つのツールは、それぞれ異なる設計思想と強みを持っています

  本トークでは、実際のPythonプロジェクトを用いて以下の観点から比較検証を行います
  1. パフォーマンス比較
  2. 型推論能力比較
  3. エラーメッセージの比較

さらに、各ツールが得意とするユースケースを紹介します。
型安全なPython開発は、もはや選択肢ではなく必須要件となりつつあります。
本トークを通じて 、プロジェクトに最適な型チェッカーを選択し、チーム全体の生産性を向上させる知見を得ていただければ幸いです。

## 型チェッカーの現在地
Python開発における型チェッカーは、もはや「あれば便利」なツールではなく、プロダクション開発に不可欠な存在となりました。しかし、その選択肢は多様化し、それぞれが異なる思想と技術的アプローチを持っています。
本トークでは、現在最も注目される3つの型チェッカーを取り上げ、それぞれの特性を多角的に分析します。
歴史と実績のmypy、モダンで高速なpyright、そして革新的なアーキテクチャで注目を集めるty。これらのツールが生まれた背景と、それぞれが目指す方向性を理解することから始めます。

## 各型チェッカーの誕生と背景
mypy（2012年〜）
mypyは歴史の長い型チェッカーです。DropboxのエンジニアJukka Lehtosalo氏が博士研究の一環として開発を開始しました。
当時のPythonには型注釈の仕組みすら存在していなかった中で、mypyが挙げた功績についてまとめます。

pyright（2019年〜）
MicrosoftがTypeScriptの成功体験を基に開発した型チェッカーです。
「開発者体験の向上」を最優先に掲げ、短期間で成熟度を高めたこのチェッカーの思想についてお話ししま　す。

ty（2024年発表、2025年プレビュー版）
Astral社が「Python開発ツールの再発明」というビジョンの下で開発中の次世代型チェッカーです。
このチェッカーの登場から、今注目されている理由についてご紹介します。

## 実践的な比較検証
1. パフォーマンス比較
異なるサイズのプロジェクトでの性能測定結果を提示します。初回実行時間、インクリメンタルチェックの速度、メモリ使用量など、開発効率に直結する指標を比較することで、
各ツールの実装言語（Python/TypeScript/Rust）の違いが、どのようにパフォーマンスに影響するかを解説します。

2. 型推論能力比較
Pythonの様々な型機能に対して、各ツールがどこまで推論できるかを検証します。基本的な型注釈から、ジェネリクス、Protocol、型ガード、デコレータなど、段階的に複雑度を上げながら、それぞれの推論能力の限界を探ります。同じコードに対する3つのツールの解釈の違いを並べて比較してみましょう。

3. エラーメッセージの比較
開発者の生産性に直結するエラーメッセージの質を比較します。よくある型エラーのパターンを用意し、各ツールがどのようなメッセージを出力するかを実演します。エラーの特定しやすさ、修正提案の有用性、メッセージの分かりやすさを、実際にお見せして評価を行います。

## 比較結果から見るツールの本質と、選択指針
実験結果を総合し、各ツールがどのような開発シーンで最も力を発揮するかを整理します。単純な優劣ではなく、それぞれが提供する価値の違いに焦点を当ててお話しします。
また、プロジェクトの規模、チームの状況、使用するフレームワークやエディタなどに応じた型チェッカー選択の決定木を提示します。大規模プロジェクトでの選択、中小規模での最適解、新規プロジェクトでの実験的アプローチなど、具体的なシナリオ別の推奨事項についてご紹介します。

本トークを通じて、参加者の皆様が自信を持って型チェッカーを選択し、より安全で生産的なPython開発を実現できることを願っています。

Misato Maeda

mypyの10年、pyrightの5年、tyの挑戦 - 型チェッカー進化論

画像という非構造化データから構造化データを抽出することは、現代DXの最重要課題です。本トークでは、**4コマ漫画のデータ化**という具体的な挑戦を通じて、最新のLLM技術とPythonエコシステムを組み合わせた**実践的で再現可能なアプローチ**を紹介します。

Gemini 2.0の登場以降、LLMによる日本語のOCR能力と非構造化データの理解は格段に進歩しました。領収書や健康診断の結果、手書き書類などのデータ化において、**「もうAIで全部解決できるのでは？」** という期待は非常に高まったことでしょう。

しかし、現実はそう単純ではありませんでした。 私が取り組んだ4コマ漫画のデータ化プロジェクトでは、画像処理によるコマの切り出し、OCRでのセリフ抽出、深層学習での人物認識、検索可能なデータ配置、そして得られたデータの分析など、あらゆるPythonエコシステムを総動員してきました。LLMの登場で従来技術の一部は置き換えられましたが、すべてが魔法のように解決したわけではありません。

むしろ見えてきたのは、LLMと既存技術の適材適所な組み合わせと、人間が介入して修正を行うUI/UXの設計こそが、実運用には大事だということです。そして興味深いことに、高性能なLLMとAIエージェントは、腰が重くて取り組んでこれなかった実装や機能同士の統合、Pythonバージョンやライブラリのモダン化などを圧倒的なスピードで支援してくれる開発パートナーとしても機能したのです。

このトークでは、そんなLLMの現実と戦い、理想のためにまだPythonが必要な領域を見据えた奮闘記を共有します。4コマ漫画という一見ニッチな題材に込められた、あらゆる非構造化データ処理に通じる普遍的な学びが見えてくるでしょう。

1. イントロダクション：なぜ 4 コマ漫画なのか？

   - 4 コマ漫画は「画像」「テキスト」「連続性」が凝縮された、非構造化データ処理の格好の題材
   - 最終目標：単行本をスキャンするだけで、コマ、登場人物、セリフ、状況を構造化し、検索・分析可能なデータベースを構築する

2. アプローチの変遷：LLM 以前の格闘

   - フェーズ 1: 人力とスプレッドシートの時代
     - 手動でのデータ入力と管理の限界
   - フェーズ 2: Python と深層学習（DL）による挑戦
     - コマの自動切り出し（物体検出: YOLO など）
     - セリフの OCR（Tesseract, Google VisionAPI など）
     - 登場人物の検出（物体検出）
     - 課題：各コンポーネントの連携が難しく、精度も限定的。修正のための UI（アノテーション画面）開発コストが高い。

3. LLM の衝撃と現実：Gemini 登場で何が変わったか？

   - 期待：「LLM に画像を投げるだけで全部解決！」
     - セリフ抽出：驚異的な精度。従来の OCR を凌駕。
     - 状況説明・構図の理解：人間のように自然言語で説明を生成。
   - 現実の壁：LLM だけでは越えられない課題
     - 人物座標の曖昧さ：LLM は「左の人物」とは分かっても、正確なバウンディングボックスを返せない。
     - 人物識別の低精度：「A というキャラ」と「B というキャラ」を安定して見分けるのは困難。
     - 話者同定の難しさ：どのセリフを誰が話しているのか、吹き出しと人物の関連付けができない。

4. ハイブリッド・アプローチ：LLM と Python エコシステムの協調

   - 適材適所な役割分担
     - LLM (Gemini)：
       - 役割：意味理解、文脈判断、自然言語生成（セリフ、状況説明）
     - Python/DL (YOLO, DINOv2 など)：
       - 役割：精密な空間認識（コマ、人物、吹き出しの正確な座標検出）
       - 役割：特徴量ベースの識別（顔認識による人物識別）
   - 具体的なパイプライン
     1. コマ切り出し: YOLO で 4 つのコマを正確に検出・切り出し。
     2. 並列処理: 各コマ画像を LLM と DL モデルに同時に投入。
        - LLM → セリフと状況説明を JSON で出力。
        - DL → 人物と吹き出しの座標リストを出力。
     (WIP)3. データ統合:
        Python スクリプトが、座標情報を元に「どの吹き出しが、どの人物に最も近いか」を計算し、話者を同定。
     (WIP)4. 最終構造化データ: 全ての情報を統合して出力。

5. 開発の加速：AI エージェントは最強のペアプログラマー

   - 品質と開発速度の向上
     - Human-in-the-Loop UI の高速開発: 「検出結果をすぐに確認・修正できる WebUI を作って」と指示するだけで、Flask や FastAPI ベースのツールを自動生成。
       - LLMとの連携によって開発速度が圧倒的に向上すると、確認のためのツールもそれに追いつく便利さが必要
     - Colab 学習ノートブックの自動生成: モデルの学習やファインチューニングに必要なコードを対話的に生成。
     - レガシーコードのモダン化: 煩雑な Python スクリプト群の統合や、ライブラリのアップデートを支援。
     - プロンプト改善: より良い結果を得るためのプロンプトエンジニアリングを支援する UI の作成。

6. まとめと今後の展望
   - LLM は万能ではない。しかし、既存の Python エコシステムと組み合わせることで、これまで不可能だったレベルのデータ構造化が実現可能になる。
   - 「自動化（LLM/DL）」と「人間による確認・修正（UI/UX）」のサイクルをいかに効率的に回すかが、実用的なシステムの鍵。
   - AI エージェントの活用は、この開発サイクルを劇的に加速させる。
   - 今後の挑戦：動画、音声など、他の非構造化データへの応用。

esuji

PythonとLLMで挑む、4コマ漫画の構造化データ化

PyCon JP 2025 座長の nishimotz です。
今年の招待講演として、Mirascope, Inc. の 青野 高大（あおの こうだい） さん（koxudaxi）をお迎えします。

Python 3.14 には新機能 t-strings（Template Strings）が導入されます。青野さんは、この仕様をまとめた PEP 750 の共同著者です。

Python 3.14 の最終リリースは 2025 年 10 月に予定されています。私たちは、9 月開催の PyCon JP 2025 のタイミングで、3.14 の「いま」を会場で共有できるセッションを設けたいと考え、特に注目度の高い t-strings を第一線で牽引してきた青野さんにご登壇をお願いしました。

青野さんは、OpenAPI／JSON Schema から型安全なコードを生成する datamodel-code-generator や、Ruff・Pydantic 向けの PyCharm プラグイン など、現場で役立つ OSS を数多く開発されています。PyCon US や EuroPython など国際カンファレンスでの登壇実績も豊富です。

Python の文字列機能は、% 演算子、str.format()、f-strings と発展してきました。次の一歩となる t-strings が、あるいは将来の Python が、どんな世界を作ろうとしているのか。私自身もお話を伺うのを楽しみにしています。どうぞご期待ください。

Koudai Aono

【招待講演】PEP 750 の共同著者 青野高大 氏による Python3.14の新機能の紹介

私の仕事道具の中で最も重要なピース（piece）、かつ、お客様の大事なピース（peace）を守るための道具であるMakdoをご紹介したいと思います。

Makdoは、MS Word形式のファイルをMarkdown記法を使って作成・編集するアプリで、私が一人で開発しています。
なお、MS Word形式のファイルの作成には"python-docx"を使い（ただし、独自に大幅拡張しています。）、エディタのGUIには"tkinter"を使っています。
また、Makdoは「MAKe DOcx files」及び「MArKDOwn」の略です。

MakdoでMS Word形式のファイルを開くと、自動でMarkdown形式の原稿に変換されて、独自開発のMarkdownエディタが起動し、編集できるようになります。
編集後に原稿を保存すると、自動でMS Word形式のファイルに変換されて保存されます。

私は、普段、弁護士をしています。
学生時代は理科系でしたが、卒業直前に法律に転向しましたので、ただのアマチュアプログラマです。

弁護士の仕事は裁判所に提出する書面の作成がかなりの部分を占めていて、MS Word形式のファイルで作成するのが事実上の標準になっています。
ところが、私はLinuxユーザであるため、MS Wordが使えません。
そこで、どうしても必要なときは古いWindowsパソコンを使うなどして、最近までなんとか仕事をしてきました。

今から約3年前のある日、この問題をPythonを使って解決できないかと思い、開発を始めたのがMakdoです。
Makdoには、日本の役所（裁判所、市役所等）に特化した機能も含め、私が「あったらいいな」と思う機能を全て実装しました。

開発の動機、開発の苦労話、実装した機能などを、初心者からプロまで幅広い層の方に聞いていただきたいと考えています。

1. Pythonとの出会い

私は、学生時代からUNIX（主にLinux）ユーザです。
これまで何度も、WindowsやMacに移行しようと思ったのですが、マウスが苦手であったり値段が高かったりという理由で挫折してきました。
Linuxでは市販のアプリを買って使うということは、あまり期待できません。
そのため、標準のアプリがなければ、自分でアプリを開発しなければなりません。

その開発の言語として、以前はPerlを使っていました。
今から約20年前、Perlからの移行先として選んだのが、Pythonでした。

2. Pythonとのこれまで

Pythonを使い、様々なアプリを開発しました。

例えば、サーバの状態を調査して報告の電子メールを送信するアプリや、画像の画質を調整してファイルサイズを小さくするアプリなどです。

でも、その多くが数百行程度の簡単なもので、コマンドラインから実行するものばかりで、GUIアプリには、全く興味がありませんでした。

3. Makdoの開発

Makdoも、当初は、コマンドライン上で、①MS Word形式のファイルをMarkdown形式の原稿に変換するスクリプト（makdo_docx2md.py）と、②Markdown形式の原稿をMS Word形式のファイルに変換するスクリプト（makdo_md2docx.py）として開発を開始しました。

しかし、約1年前に、実際に原稿を編集するエディタがなければ、誰も使わない（使えない）ということに気が付きました。
そこで、③これらのスクリプトのランチャーとして機能し、Markdown形式の原稿を編集するエディタ（makdo_editor.py）の開発を開始しました。

はじめてのGUIアプリの開発で、戸惑うことも多かったですが、楽しく勉強しながら、開発させていただきました。

このエディタの完成により、私は長年お世話になったEmacsと遂にサヨナラすることになりました。
Makdoの方がEmacsよりも便利になってしまったためです。
Makdoの方が便利なのは当然で、私がEmacs、MS Word、LibreOfficeの便利な機能を全て実装したうえに、Emacsでは実装が難しかった機能も実装したからです。

なお、Emacs、MS Word、LibreOfficeが素晴らしいエディタであること自体は否定しません。
Pythonのコードを書くエディタとしては今もEmacsを愛用していますし、WS WordやLibreOfficeは、文章を書く道具として、たくさんの方に使われています。

4. Makdoの開発の必要性

MS Word形式のファイルをMarkdown形式のファイルに変換したり、Markdown形式のファイルをMS Word形式のファイルに変換するアプリは、すでに存在しています。
有名なものは「pandoc」です。
それらのアプリは、段落番号を自動入力する機能などを前提としていますが、多くの弁護士やお客様はこれらの機能を使いこなせていません。
そのため、本文の内容から段落番号を抽出してMarkdownに変換する必要があり、そのために自作しなければなりませんでした。

また、便利なMarkdownエディタもたくさん存在しています。
しかし、Makdoは書面をきれいに作成するためにMarkdown記法を拡張しており、エディタはその拡張に色付けやインデントで対応する必要があるため、エディタを自作しなければなりませんでした。
しかも、自作エディタは、ほしい機能をいくらでも実装でき、カスタマイズし放題です。

5. Makdoの機能

Makdoには様々な機能を実装しています。

①Markdownエディタとしての基本的機能
②Markdownのタグや法律用語などに色を付けて見やすくする機能
③原稿に書かれている数式を計算する機能
④原稿上の単語を辞書で調べる機能
⑤画面を分割する機能
⑥別の原稿との違いを確認し、編集中の原稿に反映させる機能
⑦原稿内の節を折り畳んで、文章の流れを見やすくする機能
⑧原稿内のカーソル移動を支援する機能

6. まとめ

上記の内容を踏まえ、現時点では次のような流れでお話させていただければと考えております。

①自己紹介
②Makdoの紹介（実際にMakdoを起動して見ていただきます）
③開発の動機
④開発の経過（開発の苦労話）
⑤機能のご紹介（技術的なご説明、実装に苦労話）

主にお伝えしたいことは、次の3点です。

①アマチュアでも、かっこいいアプリを開発できること
②Pythonを使えば、業務で使えるレベルのアプリを簡単に開発できること
③そして何より、自分で開発すれば、カスタマイズし放題！

よろしくお願いいたします。

Makdoで編集した原稿をMS Wordで開いた様子

秦　誠一郎

マイエディタのすすめ

Most MCP servers break under real-world load. This talk reveals the Python patterns that transform basic implementations into production-ready systems handling serious workloads.
We'll explore advanced async techniques, intelligent error handling, and performance optimization that separate prototypes from scalable MCP infrastructure. Through live examples, we'll build servers that handle concurrent requests, implement smart caching, and recover from failures gracefully.
You'll discover practical patterns for connection management, memory optimization, and horizontal scaling that apply to any high-throughput Python system. This isn't about building your first MCP server—it's about engineering reliable, fast infrastructure ready for production.
Perfect for Python developers tackling AI agent

Most MCP server tutorials show you how to build basic examples, but they don't prepare you for what happens when real users start hitting your servers. This talk bridges that gap, showing you the Python patterns and architectural decisions that make MCP servers production-ready.

We'll start by examining common failure points - why MCP servers crash under load, leak memory, or become unresponsive. Then we'll dive into the practical solutions: async patterns that actually work at scale, error handling that prevents cascading failures, and performance optimizations that keep your servers responsive.

### Core Topics Covered

**Production-Ready Async Patterns:** Moving beyond basic asyncio to patterns that handle real-world complexity - connection pooling, request queuing, and resource management that prevents your MCP server from becoming a bottleneck.

**Smart Error Handling:** Implementing retry logic, circuit breakers, and graceful degradation that keeps your MCP servers running even when dependencies fail. We'll explore Python-specific techniques for handling partial failures and maintaining system stability.

**Performance and Memory Optimization:** Practical techniques for profiling MCP servers, identifying bottlenecks, and optimizing for sustained load. Learn how to prevent memory leaks and tune garbage collection for long-running MCP processes.

**Scaling Strategies:** Patterns for horizontal scaling, load balancing, and state management that let you grow your MCP infrastructure as demand increases. We'll examine real-world architectures that handle thousands of daily requests.

**Security and Monitoring:** Implementing request validation, resource sandboxing, and comprehensive logging that gives you visibility into your MCP server's behavior and protects against malicious requests.

### Real-World Case Studies

Through detailed examples, we'll examine MCP servers powering actual applications - from data processing workflows to API integration services. You'll see the specific challenges each faced and the Python solutions that solved them.

### Live Debugging Session

We'll debug a failing MCP server in real-time, showing you how to identify problems, implement fixes, and verify improvements using Python profiling and monitoring tools.

This talk is designed for Python developers who want to move beyond toy examples and build MCP infrastructure that can handle real workloads. You'll leave with battle-tested patterns, practical debugging techniques, and a clear roadmap for scaling your MCP servers from prototype to production.

## Talk Outline (30 Minutes Total)

### Opening: When MCP Servers Break (3 minutes)

- **Live failure demo:**
- **The Reality Gap:** Why tutorial MCP servers don't survive real usage
- **Common Failure Patterns:** Memory leaks, connection exhaustion, unhandled errors
- **Practical patterns that solve these problems** 

### Part 1: Async Patterns That Actually Work (8 minutes)

#### Beyond Basic AsyncIO
- **Connection Management:** Building connection pools that don't leak resources
- **Request Queuing:** Handling concurrent agent requests without blocking
- **Resource Limits:** Using semaphores and guards to prevent resource exhaustion

#### Code Deep-Dive
```python
# Robust async patterns for stable MCP servers
# Connection pooling with proper cleanup
# Request batching and intelligent queuing
```

#### Performance Improvements
- **Before/After Metrics:** Response times and memory usage comparison
- **Profiling Tools:** Using Python tools to identify async bottlenecks

### Part 2: Error Handling and Recovery (7 minutes)

#### Smart Retry Patterns
- **Circuit Breaker Implementation:** Preventing cascading failures in MCP networks
- **Exponential Backoff:** Intelligent retry strategies that don't overwhelm failing services
- **Graceful Degradation:** Keeping MCP servers functional when dependencies fail

#### Memory Management
- **Leak Detection:** Identifying and fixing memory leaks in long-running MCP processes
- **Resource Cleanup:** Proper async context management and resource disposal
- **GC Optimization:** Tuning garbage collection for stable performance

#### Live Debugging Session
- **Real Problem Solving:** Debugging a failing MCP server with Python profiling tools
- **Monitoring Integration:** Adding observability to MCP servers for production visibility

### Part 3: Scaling and Architecture Patterns (8 minutes)

#### Horizontal Scaling Strategies
- **Load Balancing:** Distributing agent requests across multiple MCP server instances
- **State Management:** Handling session data and shared resources across servers
- **Health Monitoring:** Implementing health checks and automatic failover

#### Case Study: Real-World MCP Infrastructure
- **The Challenge:** Scaling from prototype to handling thousands of daily requests
- **Architecture:** Multi-server setup with load balancing and monitoring
- **Lessons Learned:** What worked, what failed, and key architectural decisions

#### Security and Validation
- **Input Sanitization:** Protecting MCP servers from malicious agent requests
- **Resource Sandboxing:** Limiting agent access to system resources safely
- **Audit Logging:** Tracking agent actions for debugging and compliance

### Part 4: Real Applications and Next Steps (3 minutes)

#### Production Examples
- **Data Processing Pipeline:** MCP server handling batch processing requests
- **API Integration Service:** Managing external API calls for AI agents
- **File Management System:** Secure file operations with proper access controls

#### Immediate Action Items
- **Assessment Checklist:** Evaluating your current MCP server for production readiness
- **Implementation Roadmap:** Which patterns to implement first for maximum impact
- **Tools and Resources:** Python libraries and monitoring solutions for MCP development

### Closing: Your MCP Production Journey (1 minute)

- **Key Patterns:** The essential architectural decisions for reliable MCP servers
- **Common Pitfalls:** Mistakes to avoid when scaling MCP infrastructure
- **Community Resources:** Where to get help and contribute to MCP development

Kushal Vijay

Weaponizing MCP Servers: Production-Ready AI Agent Infrastructure with Python

ChatGPTをはじめとする大規模言語モデル（LLM）が普及したことで、AIはより身近な存在となりました。しかし、その仕組みを根本から理解する機会は意外と少なく、ブラックボックスのまま活用している方も多いのではないでしょうか。

本セッションでは、TransformerアーキテクチャをベースにしたLLMをPyTorchとPythonのみでゼロから実装し、それをRAG（Retrieval-Augmented Generation）と組み合わせて、社内Q&Aボットとして実用化する方法を紹介します。

外部APIや既存の商用モデルには頼らず、自作LLMだけで完結することで、AIの「中身」に踏み込みながら、実装力も鍛えられる構成となっています。

発表では、自作LLMの構成、RAGとの連携、実務での活用例までをステップごとに解説し、PythonユーザーがAIを「使う側」から「創る側」へ進むためのヒントを提供します。

AIの仕組みを根本から理解したい方、自作に挑戦したい方におすすめの内容です。

本セッションでは、大規模言語モデル（LLM）の仕組みを根本から理解したい方を対象に、PythonとPyTorchのみを用いてTransformerベースの自作LLMをゼロから構築し、それをRAG（Retrieval-Augmented Generation）と組み合わせて社内Q&Aボットを実現する方法を解説します。ChatGPTなどの商用モデルや外部APIに依存せず、あえて自作で完結させることによって、AIの内部構造を学び、実装力と応用力の両方を身につけられる構成となっています。発表では、LLMの最小構成モデルの実装、Retrieverによる文脈検索、プロンプト統合による回答生成までを段階的に紹介し、初心者でも再現可能な内容としてまとめます。業務への応用も視野に入れ、実践的なヒントも提供します。

イノウエサイシン

ゼロから作る自作LLM：AIを根本から理解し、業務に活かすRAG構成

You might know that Python doesn't have a max integer size. Unlike most other languages that are limited to having a 64 bit integer type, Python has a "theoretically infinite" maximum integer.

But, is that true?

Turns out no, Python*does* have a maximum integer size. We'll look onto Python's source code and figure out how it stores and works with integer values.

We'll be covering the following topics:

- Python integers, and how they're different from all other languages (5 min)
- How they are implemented in C (3 min)
- What's truly the largest number that Python integers can store? (7 min)
- How does Python efficiently do math with these integers? (10 min)
- Q&A (5 min)

Tushar Sadhwani

How big can python integers *really* get

What started as a mission to eat all the kakigori in Japan became a full-blown Python project to track, rate, and visualize my dessert adventures across Japan. In this talk, I’ll walk you through how to efficiently eat every cute dessert in Japan based on reviews from Tabelog. This is a cute, data-driven app built with Python, Flask, and the Notion API that transforms a dessert obsession into a meaningful coding journey. 
Using web scraping techniques on Tabelog, geospatial mapping with Google Maps API, and a diary-style interface powered by Notion, I’ll show how this app turns personal cravings into structured data and joyful visualizations. You’ll also learn how to compare official ratings with your own, build playful tracking tools, and use Python to celebrate small moments of sweetness

Diane Phan

Sweetski: A Python-Powered Dessert Adventure Through Japan

In this talk, Python and quantitative methods are used to access, validate, and analyze fundamental financial data from the US Securities and Exchange Commission (SEC) EDGAR system. The SEC's JSON API provides structured financial data, derived from company filings reported in eXtensible Business Reporting Language (XBRL), an international standard for financial reporting. Pydantic is used for robust data validation. Attendees will learn to:

- Fetch basic metrics
- Calculate financial ratios
- Visualize trends
- Navigate common data challenges

While focused on the US market data, a brief explanation of the international landscape will also be provided. No finance background required. Basic Python is required to understand the data processing part.

### Target

- **Who**: This talk is designed for anyone interested in using Python to understand public company financials, spanning from students, programmers, hobbyists, even experienced working professionals. As mentioned, no finance background is required for this talk. Beginner-level Python (variables, functions, lists, using libraries) might be required to understand how the financial data is processed to output metrics.

- **What:** Attendees will be able to discover briefly about the XBRL language, hands-on techniques for getting data from SEC EDGAR's `companyfacts` API, combining data science and software engineering to validate data with Pydantic, extract key fundamental metrics from the API responses, calculate basic financial ratios, visualize financial trends, and learn the nuances of working with public financial data APIs, even internationally.

- **How:** This talk will be presented in a mixed-style of core financial concepts with live (fallback is prepared in case network errors) Python demonstrations in a Jupyter Notebook / Google Colaboratory. This talk will go through the entire process: selecting a company to visualize its financial health, techniques to ensure that the data is valid, and calculating financial metrics and ratios.

### Scope

- **I am NOT a financial advisor and this talk is for educational purposes only, I will NOT promote or recommend any specific assets, companies, products, and strategies, and this talk is NOT to be construed as any financial, investment, or trading advice**
- Advanced financial modeling, company valuations, and comprehensive ratio analysis are outside of the talk's scope
- This talk does not dive deep with parsing XBRL format
- This talk does not cover how to buy and/or sell securities
- All examples of this talk use historical data, past performance is not indicative of future performance

### Outline

Planned outline of the presentation:

- Introduction and Disclaimer (~3 minutes)
    - Quick self-introduction and an important disclaimer that I am not a financial advisor and this talk is not a financial advice
    - Why analyze company fundamentals with Python?
- The Data: SEC EDGAR, XBRL, and APIs (~4 minutes)
    - Overview of SEC, EDGAR system, and U.S. company filings (10-K)
    - Brief introduction to XBRL as the structured data standard
    - Focus on the `companyfacts` JSON API for XBRL-derived data
- Real-Life Scenario: Ensuring Data Quality with Pydantic (~3 minutes)
    - Why Pydantic and a quick overview of the Pydantic models for the API response
- Fetching and Validating Company Data (~3 minutes)
    - Use `requests` and `pydantic` to get and validate data for a sample U.S. company
    - Handle potential API or validation issues
- Finance Metrics Explanation & Extraction (~7 minutes)
    - Explanation of basic, core finance metrics: `Revenue`, `Net Income`, `Assets`, `Liabilities`, `Equity`
    - Extraction of the annual data, building the `pandas`'s `DataFrame` to showcase the data
    - Adapting to different XBRL tags (different derived JSON property) for the same financial concept, companies might not have the same schema
- Calculation of Finance Ratios (~3 minutes)
    - Explanation of finance ratios: `Net Profit Margin`, `Debt to Equity Ratio`
    - Calculation of the metrics
- Visualizing Trends (~2 minutes)
    - From the metrics and calculations, generating and showcasing plots with `matplotlib` / `seaborn`
- Internationalization and Data Nuances (~2 minutes)
    - How other countries (example: Japan has `EDINET`) has a different system, but with the same XBRL data structure, proving the skills and knowledge are transferrable
- Key Takeaways, Recap, Closing (~2 minutes)
    - Summary of the process, the tools, suggestions for future exploration

Nicholas Dwiarto

Pythonic Finance: Analyze Company Fundamentals with SEC EDGAR APIs

多くのPythonライブラリはオープンソースソフトウェア（＝OSS）として公開されています。
Pythonを使ったソフトウェア開発は、これらのOSSによって支えられていると言ってよいでしょう。

さて、「OSSを開発する」という言葉を見聞きした時に、どれぐらいのハードルを感じるでしょうか？
もちろん、ユーザー数が多い重要なOSSの開発活動は大変かもしれませんが、必ずしもそのようなプロダクトばかりではなく、案外始めようと思えば始められるものだったりします。
また、OSSの面白い点として環境変化で意外なスポットの当たり方をすることもあります。

このトークの中では「OSS開発を」「個人的余暇のつもりで」「無理をしない」という観点で進行するために、どのようなアプローチを取っているかを紹介します。
また、後半ではこのアプローチを5年以上続けていた際に体験した実例を紹介する予定です。

タイトルについての内容を「OSS開発をスモール開発するためのマインドセット」「スモール開発を継続しているOSSにおける環境変化」という2つの観点に分けて話します。
前者では取り組みを始める際に持つと良い観点を一般化した表現で解説し、後者ではその結果として実際に起きたことについての紹介をします。

## 予定アウトライン

- 自己紹介
- 「OSS≒盆栽」とは？
  - Pythonライブラリにおける利用者規模
  - 個人的活動でOSS開発をするということ
- 無理をしないための考え方
  - (下記は予定している一部)
  - 多くの人が使うことを想定しない
  - 機械的に行えることは機械的に
- sphinx-revealjsによる事例
  - プロダクトソースコード上の変化
  - 開発する基盤に起きた変化
  - 周囲にある環境で起こっていた変化

Kazuya Takei (attakei)

OSS≒盆栽 〜個人的趣味として無理なくOSS開発をするときに意識したいこと〜

Python has grown into a key tool for creating art and fashion, moving beyond data work to help make clothing, jewelry, and interactive designs. This talk looks at how Python brings together artists, designers, and coders to build projects that mix tradition with tech. Through live coding, we'll demonstrate how libraries like Shapely, Trimesh can turn math into patterns for textiles, 3D-printed accessories, or reactive garments that light up. We'll draw inspiration from works like costumes in Black Panther or Nervous System's 3D-printed dresses, demonstrating Python's power in creating tangible art.

What if your next outfit was designed by an algorithm you wrote? This talk explores how Python quietly brings together artists, coders, and makers to create wearable art that blends tradition with computation. We'll walk through how simple code - starting with basic turtle graphics - can evolve into sophisticated design tools for fashion and art. Using libraries like Shapely, numpy, matplotlib, and Trimesh, we'll live-code two projects: crafting Japanese origami-inspired fabric patterns that can be laser-cut, and creating an animated dress design that responds to simulated heartbeat data. Watch as mathematical functions transform into intricate patterns, and see how sensor data could drive color-changing garments through visualization. We'll export real files for laser cutters and pen plotters, showing the complete path from code to fabrication. Inspired by innovators like Julia Koerner's Black Panther costumes and Nervous System's kinetic designs, the talk focuses on practical, beginner-friendly techniques. No art degree or fashion background needed - just curiosity about what happens when Python meets creativity.

Neeraj Pandey

Hitesh Khandelwal

Dress Code: How Python Writes the Future of Fashion

皆さんは標準ライブラリのloggingモジュールを使っていますか？
私は使っていますが、loggingモジュールは理解するのが難しかったですね。

どうやらこのモジュール、私にとってだけじゃなく**Pythonコミュニティにとっても難しそう**なんですよね。
というのもChatGPT登場後に話題になったライブラリをいくつか触ったのですが、どれもロギングの実装が伸びしろ豊富でした。
実務で使うならロギングをしてアプリケーションの動きを手に取るように分かりたい、でもライブラリのロギングがオレオレすぎてライブラリユーザ側で*ハック*が必要...
いやーリアルワールドのロギングは大変苦労させられますね

こういった経験からPythonのロギングについては要点を押さえて伝えられるようになったと自負しているので、私のような苦労をする人が少しでも減るように、Pythonのロギングの基本の型を共有します。
ロギングは非機能な分、機能の実装に比べてかけられる時間も少なくなりがちだと思っています。
この発表と資料が、loggingモジュールに込められた組合せたロギングの1つの型を提供できたら嬉しいです（もちろん理解したうえで採用しないのもOKです）

loggingモジュールにはいろいろな要素が含まれます。
ロガー、ハンドラ、フォーマッタ、フィルタ。
これらを**組合せた**ロギングの型を1つ示します。

* ライブラリ（importされるコード）でのロギングの実装：ロガー（+NullHandler）
* アプリケーション（ライブラリをimportするコード）でのロギングの実装
    * ルートロガーにハンドラをつける
    * ハンドラにフォーマッタをつける
    * フィルタやログレベルをハンドラに設定できる

---

# 構成

（はじめにとまとめで3分）

loggingモジュールの構成要素（4分）

* ロガー
* ハンドラ
* フォーマッタ
* フィルタ

ロガーのレベルはどう決まる？ ー NOTSET（5分）

* ロガーのレベル以上の呼び出しでログレコードが作られる
* ライブラリのコードで`getLogger()`したとき、そのレベルは？
* ロガーの階層構造
* **親のロガーのレベルを変えると、子のロガーのレベルも変わる**

ルートロガーでロギングしよう（8分）

* ライブラリの作者は、ロギングのフォーマットや出力先には関心がない
* **propagate**：子のロガーが作ったログレコードは親のロガーに渡る
* ルートロガー（＝一番親のロガー）にハンドラをつける
* そのハンドラにフォーマッタをつける
* 複数のハンドラを付ける例：「INFO以上はファイルにロギング、ERROR以上はコンソールにもログ出力」
* 別のフォーマッタに差し替える例：JSONフォーマットでログ出力したい

伸びしろのあるロガーと、対処術（6分）

※メッセージとしては「こんなハックをする必要がないように、ロギングを実装してください」

* printするものはロギングではありません（これは使わないという対処しかできない）
    * printとロギングの違い
    * やりたかったのだろう色付きロギング：フォーマッタへの差し替えを紹介
* ライブラリでルートロガーを触ってはいけません
    * basicConfigの秘密：ルートロガーを触っています！
    * 巻き起こるpropagateによる2重出力
    * 解除方法（ルートロガーのハンドラをいじる）

落穂拾い（4分）

* ライブラリのロガーにハンドラを付けない場合：「最終手段ハンドラ」でWARNING以上のメッセージを出力できる
* コードを書く代わりにファイルでの設定
* loguruなどeasyなライブラリの存在を紹介

nikkie

標準ライブラリのlogging、レゴブロックのように組合せてロギングできることを理解しよう！

The `ast` module allows you to manipulate the AST (Abstract Syntax Tree) and change the behavior of the code at runtime.

I would like to introduce it with an interesting use case with Pyodide, a Python distribution for the browser. Pyodide has some differences from CPython due to its nature, so some code for CPython does not work on Pyodide. For example, you need to use `await asyncio.sleep()` instead of `time.sleep()` on Pyodide.

However, you may want to run the same code both on CPython and Pyodide for interoperability.
In such a case, you can modify the AST to make it work on Pyodide without modifying the original Python code.

This talk should provide insights about how to use the `ast` module to solve some problems with actual examples.

I will introduce the `ast` module and how powerful the AST manipulation is by sharing my actual experience on [Pyodide](https://pyodide.org/en/stable/).

Pyodide is a Python distribution that runs in the browser, and it has some limitations as follows:
* `time.sleep()` uses a busy-wait and sometimes doesn't work as expected for example with `yield`
* `asyncio.run()` raises an error

So for better interoperability, the following code changes are needed:
* `time.sleep()` -> `await asyncio.sleep()`
* `asyncio.run(fn())` -> `await fn()`

And if a function `fn` contains such method calls, the function definition must be changed to `async def fn()` because they are transformed to be `await`ed as above, so `fn()` must be changed to `await fn()` then.

* `def fn()` -> `async def fn()`
* `fn()` -> `await fn()`
* `mod.fn()` -> `await mod.fn()`

I actually implemented these code changes as AST transformations in my project, [Stlite](https://github.com/whitphx/stlite), which has a kind of a script runner that can run CPython-targeted code on Pyodide.

Its AST transformation code is available at https://github.com/whitphx/stlite/blob/main/packages/kernel/py/stlite-lib/stlite_lib/codemod.py. It's very complicated so I will break it down and pick up some important parts in this talk to make the essential parts clear.

Pyodide project is being improved with new browser features and these problems should be removed when [WebAssembly JavaScript Promise Integration (JSPI)](https://developer.chrome.com/blog/webassembly-jspi-origin-trial) is available, but these contents will still be useful to understand the practical use cases of the AST manipulation.

Yuichiro Tachibana

AST Black Magic: Run synchronous Python code on asynchronous Pyodide

データアナリティクス機能を "Python" で “外のお客様” に届けたい開発者へ。
本発表では、社内ツールで終わりがちな Streamlit アプリを“商用品質”に引き上げ、わずか２週間で EC 事業者向け SaaS としてリリースした実体験を共有します。
EC事業者の売上向上を支援する中で「どの商品が返品を生むか」「メール施策は機能しているか」といったデータ活用ニーズが高まりました。PoCは瞬時に作れるStreamlitですが、本番SaaSにはセキュリティ・性能・品質保証という壁が立ちはだかります。

私たちは「PoCの速さ」と「SaaSの品質」を両立させるため、以下のPythonエコシステムのピースを戦略的に組み合わせました。
*   堅牢性：Streamlitの独自例外をDecoratorで捕捉し、ユーザーフレンドリーな通知と情報漏洩を防止
*   分析基盤：S3/Kinesis Firehose/Athena/awswranglerによるETL不要のサーバーレス構成
*   パフォーマンス：効率的なSession StateキャッシュでAthenaコスト削減、レスポンスを高速化
*   UX：Altairによる宣言的で美しいインタラクティブグラフ 
*   認証：WebSocketのCookie問題をJWT検証Decoratorで解決
*   品質保証：mypy/pyrightによる型安全担保/Streamlit Testing APIを用いたヘッドレステストをCIに統合

リリース初日から顧客10社が利用開始し、インシデントゼロで安定稼働しています。
「あつまれ Python のピース」に沿い、多様なピースを束ねてビジネス価値を最大化する方法を紹介します。
参加者は「迅速さ」と「高品質」を両立させる具体的なレシピを持ち帰れます。

* **イントロダクション**
    *   自己紹介
    *   顧客の強いデータ活用ニーズと「2 週間リリース」の背景  
    *   Streamlit の爆速 PoC を *商用品質* に高めるミッション

* **堅牢性 & セキュリティ**
    *    *例外握りつぶし問題*：Decorator で捕捉し安全なエラー表示  
    *    *WebSocket × Cookie の罠*：JWT 検証 Decorator で毎リクエスト再チェック  

* **分析基盤 & パフォーマンス**
    *   S3 → Firehose → Athena → awswrangler
    *   SessionState キャッシュによる Athena コスト削減
    *   Altair による宣言的・美しいインタラクティブグラフ

* **品質保証 & CI/CD**
    *   型安全ファースト：mypy／pyright と `Result` 型でバグ未然防止  
    *   Streamlit Testing API を用いたヘッドレステストを自動化（pytest-xdist 併用）  
    *   Jsonnet + GitHub Actions → ECS Fargate：環境差分のないワンコマンドデプロイ

* **ビジネスインパクト & 学び**
    *   公開初日で顧客 10 社 が即利用、データドリブン施策が加速  
    *   *PoC の速さ × SaaS の品質* を両立する設計Tips

* **まとめ & Q&A**
    *   発表内容のサマリー（持ち帰ってほしいこと） 
    *   質疑応答

Yuki Furukawa

Streamlit は社内ツールだけじゃない！PoCの速さで実現する"商用品質"の分析SaaSアーキテクチャ

UnitTestを書いていますか？UnitTestの実行にはどのくらい時間がかかっていますか？
テスト対象の規模に比例してテスト数は増えていきますが、気付くとテスト実行に1分、2分かかっていた、ということがよくあります。
また、十分に速いと思っていても、10倍の速さでテストが終われば使い方が変わります。
PyPIの事例ではテストの改善によって 163 秒かかっていたのが 30 秒、80%削減しました。
私の事例では、171秒 が 30秒 に、82%削減しました。

テストが爆速になると、色々なメリットがあります。
分かりやすいところでは、手元で実行するのに「待たなくて良い」ので、気軽に再実行できます。
また、CIの実行待ち行列が解消し、サービス利用料の削減にも繋がります。

このトークでは、現実のWebサービス開発のコードを対象に、UnitTest実行時間を削減した10の方法を紹介します。

10の方法

1. pytest-xdist を使って、並列実行する
2. DBにはsqlite3のメモリDBをできるだけ使う
3. DBトランザクションテストをやめる
4. DBのレコードを作らない
5. テスト用のデータ量を絞る
6. 外部通信しない
7. coverage では sysmon を使う
8. テスト起動時の不要なインポートを止める
9. pytestの探索パスをしぼる
10. pytest-profiling でテスト実行のボトルネックを探る

トークでは、「何をテストするべきか」という観点で、ボトルネックとなっている箇所を置き換えるための判断を行っていくことについても紹介します。「テストでは本番の動作をできるだけ再現させる」と考えてしまうと、本番と同じRDBMS、同じ量のデータ、同じ設定、同じ通信、、などがボトルネックとなり時間が累積していきます。それらを別の方法に置き換えるには、本番とは異なる方法に置き換えるための判断が必要になります。トーク参加者はそういった判断をしてもよいことに気づき、持ち帰ることが出来ます。
また、テスト高速化のために、テストの質を落とさないことも重要です。紹介する10の方法では、元々やっていた品質の担保レベルを落とさずに高速化をおこなってします。そして、テストが爆速になれば、むしろこれまでカバーできていなかった部分までテストできるようになります。

Takayuki Shimizukawa

pytest を爆速にする10の方法

私が現在携わっているWebサービスでは、10年以上にわたり外部向けAPIを複数回リプレースしながら提供してきました。従来はDjango上に構築された独自のAPI実装を用いていましたが、機能追加や仕様変更のたびに複雑化が進み、開発効率や保守性に課題を抱えていました。

そこで今回、Pythonの型ヒントを活かしながら軽量かつ高速に開発できる「Django Ninja」によるAPIアーキテクチャへと段階的にリプレースしました。

この発表では、Django Ninjaを選定した理由や、実際の移行プロセス、運用面での工夫、そして開発・運用の効率化に繋がった具体的な知見を紹介します。DjangoでAPIを開発・運用している方にとって、明日から役立つ実践的なノウハウをお持ち帰りいただける内容です。

## 発表の構成（予定）

1. **はじめに**
   - 自己紹介・会社紹介
   - 発表の背景とゴール
   - 想定する聞き手

2. **Django Ninjaとは何か**
   - Django REST frameworkやFastAPIとの比較
   - Django Ninjaの特徴（型ヒント、OpenAPI連携、FastAPI互換の設計思想など）

3. **なぜDjango Ninjaを選んだのか**
   - 比較検討した選択肢（独自実装・DRF・FastAPIなど）
   - パフォーマンス、学習コスト、開発効率、保守性の観点からの選定理由

4. **Django Ninjaを用いた実践例**
   - 型ヒントで定義するリクエスト・レスポンススキーマ
   - 自動生成されるOpenAPIドキュメントの活用
   - 認証・認可（API Key, JWT など）の実装方法
   - スロットリングやページネーションの設計
   - テスト戦略（ユニット・統合テスト）

5. **段階的なリプレース戦略**
   - 既存の独自実装との共存
   - 互換性維持の工夫
   - 移行計画と影響範囲のコントロール

6. **まとめとQ&A**
   - 得られた効果と課題
   - 今後の展望（型安全な開発・APIクライアント自動生成など）

DjangoCongressJPで発表したスライド