(追記)下記の件、Pylance以外の文法チェッカーでも同じような項目がありましたら、ご意見ください。
Visual Studio CodeでPythonコーディングしている皆さんにお尋ねします。
下記のPylanceの設定ですが、何を選択していますか？
- Pylanceは、MicrosoftのPython拡張機能と同時にインストールされるもの
- 設定の検索で
python.analysis.typeCheckingModeと入力すると表示
私は最近この設定を知って
- offで注意される内容は当然直す(直さないと動かない)
- basicやstandardで注意される内容は、がんばれば消せる
- strictで注意される内容は...結構厳しい
という感じです。
PythonはC/C++/Javaに比べると、適当に書いても適当に動くところが人気だと思っていました(インデントを除く)。
でも、strictレベルが当たり前だとすると、まだまだ勉強することが多いです。
コーディング規約にも関係する話だと思いますが、皆さんの選択とその理由を聞いてみたいです。
回答15件
#1
総合スコア120
投稿2025/06/11 09:12
そもそも型の厳密性を求めてPythonを選択するべきではないです
strictモードの制約は他言語において前提の仕様です
それらを放棄して手軽さを売りとするのがPythonの思想です
なのでカプセル化の概念もなく、定数も存在しません
むしろ標準の仕様を知らずにstrictのみを導入しても、Pythonの独自仕様に振り回されてコーディングどころではないでしょう
どうしても厳密性を担保したい場面で、段階的に制約を追加していく形が理想です
#3
総合スコア4925
投稿2025/06/11 23:30
編集2025/06/11 23:53以前、別のアノテーション関係の意見交換でも、回答ついてなかった気がします。
それだけ、アノテーション使ってる人が(ここには)いないんだろうなと思っています。
そういう私も、アノテーションをつけることはほとんどないです。理由は単にめんどくさいというだけです。アノテーション書くのは、dataclass とか pydantic 使うときや、ライブラリっぽいものを作るときぐらいかも。
ちなみに、自分の設定確認したら Standard になってました。アノテーションつけなくても文句言われないし、つけたときは適度にチェックしてくれるので、ちょうど良いです。
以前、がっつりアノテーションつけたコードを書いたとき、Strict にしてみたことがありますが、どうしても消せない警告(循環インポートがらみ)があったので、これを完全にクリアすることを基準にしなくていいと思います。
#4
総合スコア86365
投稿2025/06/12 11:14
初めて意見交換を立ててみましたが、ここはPython使いが多いはずなのに、1名だけとは残念でした。
質問が悪かったのか、嫌われているだけなのか...
ここだけ回答します。
「Pythonに対しての認識はこれこで、開発はこれこれこういう前提の元で行っているが、その場合にはどういう設定にするのがいいか？」という状況を詳しく書いた上での「質問」であれば、回答がもう少し付いたかも知れません。最初から良い回答が付けばそれ以上は回答が出ないかも知れませんが（グッドは付くかな）。
ケースバイケースで考えるべき物について、「これこれについて、いろんな考えがあると思いますが、みなさんはどうしてますか？」というアンケート的な物は回答が付きにくいと思います。公式の書いてるようなユルい話題なら付いたりしてますが。
ひとそれぞれ、プログラミングに関する考え方が違い、開発対象も、大企業のミッションクリティカルなシステムから、Teratailのようなゆるいシステム、個人の趣味での開発など、いろいろ前提が違う人から、結果だけAかBかCかを聞いても意味があるとは思えません。回答が数千あれば集計してもいかも知れませんが。
「Aです」と1行だけ書くのは簡単ですが、「何故Aなんですか？」と聞かれて説明するのは長くなるし、バックグラウンドが違う相手にどうやって説明したら良いのかも分からない。
「ここだけ回答」と書きましたが、これだけだと何なので私の意見も書いておくと、
・組織での開発なら、組織でルールを議論して決めて、それに従う（という当たり前の回答なので書かなかった）
・組織の仕事と別の、全くの個人での開発（趣味の開発とか、個人運営サイトとか）ならこの手のツールは気にしない（学習途上の人で、こういうツールのメッセージが役に立つと思えば使えばいいが）（というこの質問を否定するような回答なので書かなかった）
#1 Manabuさんの回答にも賛成です。
組織での開発の場合は、組織(規模、個人スキル)や、開発の考え方（ゆるい、厳しい）や、対象システムが異なると、他組織のルールはあまり参考にならないと思います。
「何故この開発でPythonを選んだのか」もかな。こういうケースがあるかどうか分かりませんが「他のシステムはほぼJava等ばかりだが、ライブラリーやプラットフォームの関係で止むなくPythonを選んだ」であれば厳しく設定するのでしょうね。プルダウンの四択から選ぶのでなくJavaに合うように個別に細かく設定するのかも。「迷うことなくPython（or Rubyと迷った）」なら、おそらくゆるめで。
#7
総合スコア86365
投稿2025/06/13 11:40
編集2025/06/13 11:44私の質問で不快な思いをさせてしまい、
質問自体は、全く不快さはなく、回答を見送った私の意見も、見送った理由と共に書きました。
念のため#4を見返しましたが、不快に感じていると表しているような表現は見当たりませんでしたが、どの部分でしょうか？
回答・意見が付きにくいだけで、不快に感じるような悪い質問ではないと思います。「警告/指摘に対する向き合い方」という観点では、「gcc -Wall -pedantic ~~で出る警告が、プログラムを修正してもなかなか消えないがどうしたら良いか？」的な質問もあった気がします。
strictまで対応しなくてもよいという意見
ケースバイケースで考えるべき事(※)を、ケースバイケースを斟酌しない単純なツールでの指摘にとらわれるのは意味ないでしょうね。将来AIを使った高度なチェックツールが登場しても、企業ごとプロジェクトごとのカスタマイズは必要でしょう。
組織での開発の場合は組織で方針を決めるとして、個人の私的な開発の場合は、strictに設定した上で、すべての指摘を「この指摘は無視」「この指摘は "なるほど" なので修正」と自分で1つずつ判断するのも1つの考え方です。たぶん面倒なのでこれを勧めるわけではないですが、指摘に対応しなくとも指摘してもらいそれに対応すべきかどうか考えること自体は無意味ではない。そういう意味では「strictでしか出ない指摘は対応不要」と一律に決めてしまうのではなく「strictでしか出ない指摘の中には対応不要なものもある」ということかと思います(standardについても同様)。
※の部分は私見なので、「型についてはどんな場合でもこうあるべき。ケースバイケースなどとんでもない」という意見の方もいらっしゃるかもしれません。
#8
総合スコア14
投稿2025/06/17 00:38
おそらく、Pylanceの設定について回答が集まりにくいのは、そもそもPylanceを使っていない方や、strictな型チェックを必要とする状況に遭遇していない方が多いからではないかと感じています。
Pythonの型サポートは比較的最近強化されたもので、型アノテーションを前提としないプロジェクトもまだ多く存在します。アップデートされていないコードベースでは、Pylanceのstrict設定も十分に活かしきれないことがあります。
ManabuさんもおっしゃっているようにPythonは他の動的型付け言語の中でも特に仕様が緩いと感じています。
また、最近のPythonの型チェックではPylanceよりもPydanticとmypyの組み合わせが主流です。
例えばPythonを使ったオープンソースのコントリビュータに求める環境も、今はPydanticとmypyが一般的です。
個人的にも、PylanceはTypescriptベースということもあり、Pythonの最新仕様に追いついていないと感じます。これに起因して正しく型チェックができず、回避するための作業が発生して本質的な問題解決に集中できなくなるリスクを感じました。そのため、型安全性を求めるプロジェクトではPydanticとmypyを使う方が型安全性の担保ができると感じています。
最後に、個人的にはPylanceを使うことが強制されているプロジェクトではbasicで使っています。
しかし型の厳密な検査が求められる場面では、Pydanticとmypyの利用を強くおすすめしたいです。
#10
総合スコア88
投稿2025/06/19 02:32
初めて意見交換を立ててみましたが、ここはPython使いが多いはずなのに、1名だけとは残念でした。
質問が悪かったのか、嫌われているだけなのか...
嫌われてると意見交換に人が来ないの?
恐ろしい場所だな、teratail・・・・・・(来たばっかなんで・笑)。
いや、単純に、
Visual Studio CodeでPythonコーディングしている皆さんにお尋ねします。
とか書いてたから。単純にVisual Studio Codeを使ってないから。それだけ、です。
そもそも個人的には、昨今のVisual Studio Codeを使って、って書いてる初心者向けのPython入門書の類を見て、Visual Studio CodeをPythonで使うのは間違ってる、って思い込んでるんで(笑)。
そんなんで、参加しなかっただけ、です。
PythonはC/C++/Javaに比べると、適当に書いても適当に動くところが人気だと思っていました
100%同意。
そもそも、動的型付け言語に厳密な型チェックとか・・・・・・。
これもおかしいんだよな。そんな事するくらいなら初めから強い静的型付け言語を使うべきだと思う。
なんかビミョーに昨今のPython周りが「おかしいな」ってカンジになってきてて・・・・・・。
多分ユーザーで、「静的型付け言語が好き!」って人が多くなりだして、じゃあ、そういう言語を使えよ、って話になるんだけど、「Pythonのスタイルは好きじゃないんだけど、ライブラリの多さから屈服(笑)せざるを得ない」ってカンジになってきてるんだろうか・・・・・・。
何か「気楽に使える」言語から遠いトコに来ちゃったなぁ、ってカンジです。
とまぁ、雑談でした。別に「嫌ってる」わけじゃないんで。そもそも初見ですし。
#11
#10
文法チェックも入力補助もしてくれるし、初心者こそVisual Studio CodeでPythonだと思います。
逆に皆さん、何を使っているのでしょうか？
Vimとかサクラエディタとかでしょうか。意見交換を立ててもいいかも。
(私は遠慮します)
Pythonのスタイルは好きじゃないんだけど、ライブラリの多さから屈服(笑)せざるを得ない
これですね。C/C++だけでは食っていけないので。
食うための言語は、10年くらい前まではJava、その後はPythonです。(個人の感想)
雑談、大歓迎です。
ご意見ありがとうございます。
#12
総合スコア88
投稿2025/06/19 15:15
編集2025/06/19 15:15逆に皆さん、何を使っているのでしょうか？
Vimとかサクラエディタとかでしょうか。
いや、プログラミング初心者はPython付属のIDLEで充分ですよ。オールインワンなのに「余計なIDEを導入させようとする」のはおかしい。
もちろん、プロが開発環境にVisual Studio Codeを使う事を否定する事はないんだけど、少なくともこのテの「入門書」を見る限り、Visual Studio Codeの「旨味」なんざ全く無い。consoleにPython ファイル名と打つ、とか「インタプリタでの開発手法を知らんのか?」と言うような本ばっかだ。
要はリスナー無しでPython開発なんざありえるのか?とか言うのが感想になっている。それで提示コードは結果print塗れ・・・・。なんじゃこりゃ、と(笑)。
要は、Visual Studio CodeってのはC/C++やJavaなんかのコンパイラ処理系向けであって、単純にはリスナー(REPL)へのファイルを読み込む機能がない。GNU Emacsで言うinferior-pythonがないのね。そんな不便な開発環境をプログラミング初心者に強要するくらいだったらIDLEの方が単純にマシ、なんですよ。つまり、
文法チェックも入力補助もしてくれる
より、リスナーがない、と言う一点だけで教育観点だとデメリットの方がデカイ、んです。
もちろん、Visual Studio CodeでREPLを使えるエクステンションなんかも探せばある。ただし、「IDEをマトモに使えるように持っていく」には面倒の方がデカイ、ってのが一つ。もう一つはちと使いづらかったりして・・・・・・。実行したい部分的なコードをマウスで選択して・・・とかワンアクション多いのね。
と言うわけで、開発現場でVisual Studio Codeを使う事を否定してるわけじゃなくって、単純に初心者向けじゃない。インタプリタのリスナーを使ったインタラクティヴなプログラミングを指南するにはVisual Studio Codeの導入は邪魔なだけってのが感想です。
と言う雑談でした。
#14
総合スコア86365
投稿2025/06/20 15:27
編集2025/06/20 15:29cametanさんの言ってるのは、「初心者」というか、「入門途上の人」のことかと思います。
具体的には、プログラミング未経験から「プログラミング未経験者向けのプログラミング入門書」を読み終えてちゃんと分かったという実感を持てるまでの間の人。
構文規則、制御構文、演算子などを一通り覚えたとしても、下記くらいのことが分かってないと、「入門途上」だと思います。
・変数にオブジェクトを代入した場合の変数とオブジェクトの関係
・（前項と同じだが）変数に代入されているオブジェクトの書き換えと、変数に別のオブジェクトを再度代入することとの違い
・関数・メソッドの返り値と、端末に出力することとの違い
・仮引数と、実引数。引数機構
・文法エラーに対してどうすればいいか
もうちょっとあるかも。
cametanさんと理由は違うかも知れませんが、似たようなことは思っていて、
「これからプログラミングを始めてみたい」と思って着手した人に、環境構築で色々苦労したり、「IDEとは何か」「JupytterNotebookとは何か」など理解したりというプロセスが必要なのかという疑問はありますね。まあ、どうしても使わせたいなら、「VScodeの役割とか設定などの理解はさておき、テキスト通り操作すれば良い」で教えるのですかね。疑問を持ったときに教えてくれる人が身近にいれば良いのですが。
授業や研修で「プログラミング」を教える場合は、環境まるごと用意してその上で「テキスト通り操作すれば良い」で教えるのでしょうね。勤務先の新人研修でのプログラミングの部分はそんな感じのはずです。これは教師が側にいるのでそれでいい。
ただ、
・関数・メソッドの返り値と、端末に出力することとの違い
の理解がおかしい人が出てきたのは、REPLで入門した結果かと思います。まあ、この点だけなら理解し直すのは難しくないだろうし（とは言うのものの、過去にここであった質問で、一度の説明では通じてなかった）、REPLで入門した人すべてが勘違いするわけじゃないでしょうから、「REPLで入門」自体は悪いとは思いません。
「エディターとpython ファイル名」というオーソドックスな方法とどちらが良いのかは一概に言えない。
（私自身はIDEやREPLという概念そのものが無い時代にプログラミングを始めたので、「エディター＋言語コマンド名 ファイル名」でした）
このあたりを抜け出して、簡単なプログラムを自分でゼロから書けるようになれば「初心者」ですかね。
その段階だと、
文法チェックも入力補助もしてくれるし、
がありがたいと思いますし、頼るべきです。
#15
総合スコア88
投稿2025/07/06 18:55
編集2025/07/06 19:11cametanさんの言ってるのは、「初心者」というか、「入門途上の人」のことかと思います。
具体的には、プログラミング未経験から「プログラミング未経験者向けのプログラミング入門書」を読み終えてちゃんと分かったという実感を持てるまでの間の人。
ああ、そうですね。
「初学者」って表現の方が適切だったかもしれません。
cametanさんと理由は違うかも知れませんが、似たようなことは思っていて、
「これからプログラミングを始めてみたい」と思って着手した人に、環境構築で色々苦労したり、「IDEとは何か」「JupytterNotebookとは何か」など理解したりというプロセスが必要なのかという疑問はありますね。
全くその通り、です。
「初学者にとっては」IDEの導入ってのは思ったより敷居が高い。
だから、単純に、Pythonのように「オールインワンになってる」処理系に対しては、追加でIDEを導入させよう、ってのは悪手なんですよ。
思い返してみれば僕自身、最初にプログラミングを学び始めた段階で「GNU Emacsを導入しろ」的な事を言われて戸惑った方なんです。
今はかなりマシになってるんだけど、僕が使い始めた当時だと.emacsにEmacs Lispで色々書くのが「標準の手順」みたいになっていて・・・・・・。
「なんでプログラミング始める前にこんな手間かけなアカンの?」とかかなり苛立っていた(笑)。
オールインワンだったらこんなクソ面倒くさい手間かけなくて済むのに、と(笑)。
授業や研修で「プログラミング」を教える場合は、環境まるごと用意してその上で「テキスト通り操作すれば良い」で教えるのでしょうね。勤務先の新人研修でのプログラミングの部分はそんな感じのはずです。これは教師が側にいるのでそれでいい。
そう、教えてくれる人が傍にいれば、何の問題もないんだけど、自習派はそうじゃない。
上にも書いたけど、例えばGNU Emacsなんかも、授業で使ってたり、とか先輩が使ってたり、だと「苦もなく」覚えられる。
でも自習でやるとそもそもGNU Emacsの環境構築「さえも」自習にならざるを得なくて洒落になんないのです。
VS Codeは往年のGNU Emacsに比べると圧倒的に「マシ」ではあるんだけど、Python備え付けのIDLEを「使う」って判断より上回ってるわけじゃない。
依然として初学者に対してはデメリットの方が多いです。
・関数・メソッドの返り値と、端末に出力することとの違い
の理解がおかしい人が出てきたのは、REPLで入門した結果かと思います。まあ、この点だけなら理解し直すのは難しくないだろうし（とは言うのものの、過去にここであった質問で、一度の説明では通じてなかった）、REPLで入門した人すべてが勘違いするわけじゃないでしょうから、「REPLで入門」自体は悪いとは思いません。
これは面白い意見だと思います。
ただ、返り値と「出力」の何が違うのか、ってのはREPLで学ぶか端末に出力させるのを学ぶかに関わらず起きる問題じゃないかなぁ・・・。
実際、僕も最初は混乱したクチだし。
端末で出力させる事を徹底させる、ってのは悪くなく見えるんだけど、一方そうすると、「何でもかんでもprintする」って悪癖を付ける原因になるんですよ。
実際、VS Codeを無自覚に導入させる本だとそういう結果に導きやすい。
例えば、これ、本当にある「初学者向け」のPython本(Visual Studio Code使用)に書かれてたコードなんだけど、マジで酷い(笑)。
Python
1list = [70, 15, 66, 21, 19, 97, 33, 44, 30, 2] 2disp = "" 3for k in range(len(list) - 1, 0, -1): 4 print(str(len(list) - k) + "度目") 5 for j in range(0, k): 6 if list[j] > list[j+1]: 7 temp = list[j] 8 list[j] = list[j+1] 9 list[j+1] = temp 10 for i in list: 11 disp = disp + str(i) + " " 12 print(disp) 13 disp = ""
まぁ、バブルソートを図示化しよう、って意図は分かるんだけど、ホント、色々とヒドいコードだ(笑)。
Pythonの「使い方」が間違ってる(笑)。
で、実際、こういう質のコードの方が意外と多くて、「返り値を説明しようとする」よりprintを駆使する方が多いし、VSCodeでpython ファイル名の利用だと、問答無用にこのテのコードを書かせる方が多いんです。
何故ならリスナーだったら簡単に分かる事が、コンソール利用だと分からないから。
その辺、実際問題、VSCode利用でのターミナル利用の方が弊害が大きいんじゃないの?ってのが僕が思ってる事です。
だから個人的には、teratailみたいなトコで投稿する際には、なるたけ関数中にprintを挿し込まずに、printを使う際にはif __name__ == '__main__:'以下でしか使わないようにしてコードを提示するようにはしています。ただ、初学者に「エントリポイント」を説明する方が厄介だったりして・・・(んで、実際のトコ、if __name__ == '__main__:'はエントリポイントじゃねぇし・苦笑)。
あるいは、無作為なprintの導入を避けさせる為にVS Codeの使用と共にunittest使って最初からテスト駆動開発を徹底する習慣を付けさせてプログラミングを教授する、って方法も無いこたぁ無いんだけど・・・・・・。
どうかなぁ。これはこれでかなりメンドイんじゃない?って気もします。
余談だけど、ANSI Common Lispって言語だと、出力命令を使ってもリスナ上では返り値も表示されるようになってます。
Lisp
1CL-USER> (princ "Hello, World!") 2Hello, World! 3"Hello, World!"
「なんで2つも表示されるん?」とか最初は思ったもんですが(笑)、「返り値と表示は別だ」と理解するならこれは結構結果良かったかも。
まぁ、その辺はREPLの設計次第かな。
文法チェックも入力補助もしてくれるし、
がありがたいと思います
実は現行のIDLEだと、既に入力補完くらいはしてくれるようになってんです。
他にも既にエクステンションの類も導入可能となっている。
結局ね、あまりにも昔のIDLEがヒドかったから(笑)、そのイメージがついて回ってるんですよ。そもそもtcl/tkが汚いし(笑)。そして出来る事は大した事がなかった。
でもIDLEもなんだかんだ言われながら地道に進歩してきて・・・入力補完くらいだと、別にVS Code持ち出す程でもなくなっちゃってる。エラーは結果、実行してみるなり、IDLE付属のデバッガで見れば済む話だし。
もちろん、フルでエクステンション完備のVS Codeには敵わないでしょう。餅は餅屋だし、IDEとしては「専門の」VS Codeには最終的には勝てない。
ただし、フル拡張するとなると・・・初学者含み初心者でも「環境構築が面倒くさすぎる」と言う最初の問題へと戻るわけです。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。