Pythonカーネルの再起動メカニズムを提供するこのウィッシュリストのリクエストのきっかけは何ですか?
JMP で実行する Python コードを開発するには、通常、Github リポジトリをクローンし、次のように JMP をコードのローカル コピーにポイントする必要があります。
jmputils.jpip('install','myrepo c:\\pathto\\myrepo')
どのような改善を望みますか?
JMP を閉じて再度開くことなく、ユーザーが Python カーネルを再起動できるメカニズム (ボタン、API など) を提供します。
このアイデアはなぜ重要なのでしょうか?
コード開発中は、ローカル コードに多数の変更が加えられ、そのたびに新しいコードを Python カーネルにロードする必要があります。現在、新しいローカル コードを Python カーネルにロードする唯一の方法は、JMP を閉じて再起動することです。これにより開発が大幅に遅くなり、一部の開発者にとって障害となる可能性があります。
自動化とスクリプトRe: Python カーネルの再起動メカニズムを提供する最初にエディターでコードを変更して再実行すると、変更内容が反映されます。
インポートしたコードの場合
コードをインポートする
# 'mycode' パッケージを強制的にリロードする必要がある場合
インポートimportlib
importlib.reload(mycode)
これは既存の Python の動作です。ほとんどの場合、Python はコマンド ラインから実行され、スクリプトとPython は実行の合間に終了するため、この動作は見られません。JMP は Python 共有ライブラリをロードするため、このような場合は JMP を Python として考える必要があります。変更の合間に終了せずに Python 対話型コンソール (IDLE など) 内で同じ作業を行うと、同じ動作が見られます。Python 環境は共有されているため、最初に使用してから JMP が終了するまで有効です。これがJSL / Python 統合を実装できる方法です。
したがって、importlib.reload( package ) がこのニーズを満たすため、現時点では「再起動」は提供されません。
独立した Python サブインタープリターを起動する機能について調査中です。これにより、必要に応じてスクリプトをクリーンな環境で実行するなど、多くの追加機能が可能になります。サブインタープリターの調査は、JMP 19 が Python 3.13.x にアップグレードする理由の 1 つです。更新とセキュリティ ライフサイクルが、3.13.x への更新の主な推進力です。
Re: Python カーネル再起動メカニズムの提供 - ステータスが「現時点では計画されていません」に変更されましたRe: Python カーネルの再起動メカニズムを提供するうーん。さまざまな Python スクリプト ウィンドウとバックグラウンドのタスク間ですべての変数を共有できるのは便利ですね。
アプリケーション ビルダーにこのオプションがあればよかったのに!
しかし、少し「実験的」な感じがするのは認めざるを得ません。
再起動によってカーネルをリセットすることは、1995 年以来私たちが慣れ親しんできたことであり、とても快適に感じられます。
他の多くの (!!!) Python IDE もこの機能を提供しています。他の IDE では、コードを実行してからカーネルを閉じます。
「よりクリーンな環境でスクリプトを実行する」
...有望そうです。
このようなサブインタープリターの起動 (および再起動)は自動的に利用可能になると思います。
なぜ「いいえ」なのか不思議です。これにより、JMP に欠けている機能が実現されるのでしょうか?
Re: Python カーネルの再起動メカニズムを提供する最大の問題は、メモリにロードされた共有ライブラリを実行中のプロセスでアンロードできないことです。これは Python 自体だけでなく、NumPy のような共有ライブラリを持つインポートされた Python パッケージにも当てはまります。Python は別のプロセス空間で実行されているのではなく、JMP 自体の内部で JMP の一部として実行されています。はい、Py_Finalize() を呼び出し、その後 Py_Initialize() を実行してインタープリタを 2 度目に初期化できます。私が過去に遭遇した問題は、2 度目のインタープリタ初期化後のインポートに対して NumPy が特にうまく反応しなかったことです。JMP は不安定になり、特に再起動後の NumPy のインポート時にクラッシュしがちになりました。他のIDE が Python をどのように処理するかは調べていませんが、Python を埋め込むのではなく Python のインスタンスを実行している可能性があります。
JMP 18 では、以前のバージョンからメモリ処理を大幅に改善しました。そのため、このような再起動が可能かどうかを確認するために、これを再検討する価値があるかもしれません。これはメモリ処理の問題であった可能性がありますが、共有ライブラリをロードする NumPy やその他のパッケージにまだ問題がある可能性もあります。
