2025年は巳年です！🐍 そして、Python開発用のQtが前進し続けていることをお知らせいたします。モジュールPySide6とshiboken6の改善だけでなく、QtとPythonの統合の未来も見据えています。
今回のリリースでは、Qt 6.8で追加した新機能の改善に重点的に取り組み、新しいプラットフォームへのサポートを追加し、新しい取り組みを開始しました。詳細についてぜひ読み続けてください。
以下では、今回の新リリースのハイライトをいくつかご紹介します。さらに詳細な情報が必要な場合は、変更ログをこちらでご確認ください。
Qt Design Studio 統合の正式化
前回のブログ記事を見逃した方のために説明すると、Qt Design Studio では、バージョン 4.5 から Python 開発者向けのプロジェクトのエクスポート機能が提供されています。6.8 リリースで、デプロイメントツール pyside6-deploy を使用してQt DS プロジェクトのデプロイを容易にできるようになりました。 当初は、モンキーパッチングによって Qt Design Studio が生成した main.py ファイルを修正するといった回避策が必要でした。
6.9 以降の新しいアプローチは、Qt Design Studio Python プロジェクトのすべてのファイル依存関係を QRC ファイルから特定し、コンパイル済みの Python リソースファイルを Python 実行ファイルに含めるため、はるかに効率的です。pyside6-rcc を最初に実行してコンパイル済みの Python リソースファイルを作成し、その後で pyside6-deploy を実行します。または、pyside6-project を実行するだけで、pyside6-rcc を実行してコンパイル済みのリソースファイルを作成し、プロジェクトを自動的にビルドします。pyside6-project の deploy コマンドを使用してプロジェクトをデプロイできます。
この合理化されたプロセスにより、PySide6とQt Design Studioを使用する開発者は、よりスムーズで効率的なワークフローを実現でき、プロジェクトの管理とデプロイが容易になります。
間もなく、詳細とユーザー事例をすべて盛り込んだ新しいチュートリアルを公開する予定です。
Qt CreatorとPySideツールのpyproject.tomlサポート
Qt Creatorは、pyproject拡張子を持つPySideプロジェクト用のカスタムプロジェクト構成ファイルを使用します。これらのファイルは、プロジェクトファイルの配列を含むシンプルなJSONオブジェクトです。コミュニティで広く採用されているPython標準ガイドラインに合わせるため、pyproject.tomlをpyprojectファイルの代替として使用するサポートが導入されました。これにより、将来的な機能やPySideおよびQtツールとの統合も拡張されます。
pyproject.tomlファイルは、必要なPythonのバージョン、パッケージの依存関係、コードのフォーマット設定など、幅広いプロジェクトのメタデータを提供します。 詳細は、Python パッケージングユーザーガイドをご覧ください。
pyside6-projectコマンドに追加された新しいオプションpyside6-project migrate-pyprojectのおかげで、既存のプロジェクトの移行は簡単です。 次の例は、当社リポジトリ内のサンプルです。
| (env) ➜ tetrix git:(dev) tree . ├── doc │ ├── tetrix.rst │ └── tetrix-screenshot.png ├── tetrix.py └── tetrix.pyproject 2 directories, 4 files (env) ➜ tetrix git:(dev) cat tetrix.pyproject { "files": ["tetrix.py"] } (env) ➜ tetrix git:(dev) pyside6-project migrate-pyproject Created "/home/crmaurei/dev/pyside-setup/examples/widgets/widgets/tetrix/pyproject.toml" (env) ➜ tetrix git:(dev) cat pyproject.toml [project] name = "tetrix" [tool.pyside6-project] files = ["tetrix.py"] |
このツールは既存の*.pyprojectファイルを読み込み、まだ存在していない場合は新しいpyproject.tomlファイルを作成します。pyproject.tomlファイルがすでに存在している場合は、その内容を更新する前にユーザーに確認を促し、安全な動作を確保します。
pyproject.tomlをプロジェクト構成ファイルとしてサポートすることで、Qt CreatorやVisual Studio codeなどのIDEとの統合を強化できると期待しています。今後の展開にご期待ください！
タイプヒントの改善
多数のユーザーから、タイプヒントのpyiファイル（Python インターフェーススタブ）に関する問題が報告されています。これはさらなる改善を行う上で非常に有用でした。ただし、このファイルはリポジトリには存在しないため、改善を反映させることはファイルを編集するほど単純な作業ではありませんでした。
.pyiファイルの生成は、Qtソースコードから直接、関数シグネチャ、クラス構造、および型情報を抽出することで、手動ではなく自動化されています。Pythonが進化し、新しいPEPが型ヒントのルールに変更を加えると、この自動化プロセスにより、.pyiファイルが最新の標準に一致し続けることが保証されます。
.pyiファイルでは、Callable、Iterable、Sequenceのインポートが、collections.abcに更新されました。これは、それらの使用がPython 3.10以降非推奨となったためです。さらに、Python 3ではすべてのクラスが暗黙的にobjectを継承するため、冗長となるオブジェクト継承がクラスから削除されました。これは、Qt for PythonでPython 2をサポートしていた時代の遺物です。
今後6.9リリースで引き続き修正する予定の問題が数多くありますので、価値があると考える限界事例、バグ、提案について、より多くのレポートを提出してください。
Shibokenの更新とバイナリサイズの縮小
バインディングの生成には、通常、エラーの可能性を発見するために多くの情報が必要となり、出力が冗長的になりがちです。出力を減らすために、mjb_rejected_classes.log などの他のログファイルに加えて、追加のログファイルmjb_shiboken.log を導入しました。コマンドライン引数、インスタンス化されたコンテナなどに関する情報メッセージは、このログファイルにリダイレクトされます。これにより、ごちゃごちゃした感じが軽減され、見落としがちな標準エラーの警告メッセージがより目立つようになります。
6.8で開始された取り組みを継続し、仮想関数用に生成されたコードにいくつかの最適化を適用することで、生成されたモジュールのサイズを縮小することに成功しました。全体では、約35%の縮小が見られましたが、他のモジュールでは2%程度の縮小にとどまりました。
値型に対するデフォルトコンストラクタおよびコピーコンストラクタの検出を改善し、型システムでこれをオーバーライドする方法を追加しました。
さらに、等価な型に対するオーバーロードを自動的に破棄するためのルールを指定する方法を追加し、注入されたドキュメントのスニペットからクラスのドキュメント文字列を生成する方法を改善しました。
Windows ARM64のサポートは現在テクニカルプレビュー
当社はプラットフォームのサポートを拡大し、幅広いプラットフォームで PySide6 がスムーズに動作することを確実にしていきたいと考えています。新しい 6.9.0 のリリースに伴い、テクニカルプレビューとして Windows ARM64 ホイールをリリースすることを発表できることを嬉しく思います。このリリースは、開発者が試用しフィードバックを提供できるように、Windows ARM64 ホイールへの早期アクセスを提供することを目的としています。
今後のリリースにおける Windows ARM64 ホイールの完全サポートに関する最新情報にご注目ください。
Qt Remote Objects の貢献
Qt Remote Objects のメンテナから貢献をいただきました。これにより、Qt Remote Objects の Python サポートが大幅に改善されました。repファイルをPython から読み込んで、通信用の動的型を作成できるようになりました。この貢献に大変感謝しています。
技術プレビュー版であることを考慮し、ぜひお試しいただき、ご意見をいただければ幸いです。これにより、将来的にサポートされる可能性のあるユースケースを発見できるでしょう。
他にどのような開発が進行中ですか？
PEP 730 が承認されて以来、Qt ユーザーから PySide アプリケーションを iOS に移植したいという多くの要望が寄せられています。Android サポートの成功を考慮すると、次のリリース期間中も iOS に関する研究を継続する予定です。
3.13リリース前に、フリースレッドPythonとの互換性を確保するためにいくつかのテストを行いましたが、これは非常に有望なものでした。この機能はまだ実験段階にあるため、さらなる開発は中断しましたが、この機能が実験段階を終了した時点で、将来のバージョンに適切な実装を検討する予定です。
最後に、Qt フレームワーク用のバインディングを生成することは簡単な作業ではないことをご理解いただいていると思います。多くの言語がこの作業に挑戦してきましたが、Qt を完全にサポートできた言語は多くありません。これは理解できることであり、また、「Python ユーザーは本当にすべての Qt モジュールを必要としているのか？」、「さまざまな使用事例を解決するために、これを少しスリム化することは可能か？」、そしてより重要なこととして、「他の言語を公式にサポートすることはどの程度難しいのか？」 といった新たな疑問も生じます。
当チームは、現在、PythonコードをQt Quickアプリケーションに簡単に接続する方法を提供することを目的とした、新たなエキサイティングなプロジェクトに取り組んでいる多くのエンジニアと力を合わせています。このプロジェクトの主な目的は、Python開発者がPySideが提供する必要な手順やQtの知識をすべて習得することなく、Qt Quickを使用できるようにすることです。PythonとQtの橋渡しをするコード量を減らすことで、開発者はPythonとQtアプリケーションのバックエンド部分だけに集中できるようになります。複雑なデータ構造をQt Quick UIとシームレスに統合することで、
PythonとC++以外にも、他のプログラミング言語も大好きです！Pythonプロジェクトでさえ、既知の問題を解決する他の言語のおかげでレベルアップしてきたことを見てきました。そのため、これはQtにも当てはまるでしょう。
Qtエコシステムにバインディングを介して他の言語を追加することは新しいことではありませんが、今回は、(1) 完全なバインディングセットを提供しない、(2) 他のプログラミング言語の強みをより早くQtエコシステムにもたらす、(3) 新しい開発者とともにQtコミュニティを拡大する、(4) Qtをより優れたフレームワークにする、という目的のために、異なるアプローチを考えています。
これらの強力な統合が実現するまで、どうぞご期待ください！
これからも連絡を取り合いましょう！
当社は新しい実験的なサポート、機能、Pythonモジュール統合を試していきたいと考えています。次に何をすべきでしょうか？メッセージをお送りいただくか、JIRAに提案を投稿してください。
リリースをお楽しみいただければ幸いです。また、いつも通り、コミュニティプラットフォームにアクセスし、何かうまく動作しない点があれば、バグレポートを提出してお知らせください。
