Pythonが嫌い・苦手と感じるエンジニア必見！独特なインデント構文や動的型付けのイライラ解消法

Pythonは「読みやすい言語」として評価される一方で、実務レベルの開発に入ると独特の仕様にストレスを感じるエンジニアも少なくありません。
特に顕著なのがインデントによる構文制御と動的型付けによる不確実性です。
これらは設計思想としては合理的であるものの、チーム開発や大規模システムでは思わぬ摩擦を生みます。

例えばインデントは一見シンプルですが、以下のような問題を引き起こします。

見た目上は揃っているのにタブとスペース混在でエラー
コピー＆ペーストでブロック構造が崩壊
レビュー時にロジックではなくインデント差分に時間を取られる

また動的型付けについても、柔軟性の裏側で以下のような問題が発生します。

実行時まで型不一致に気づけない
IDEの補完精度が落ちるケースがある
リファクタリング時に影響範囲が読みにくい

こうした特性は「速く書ける」というメリットと表裏一体ですが、長期運用では負債化しやすい側面があります。

一方で、これらのイライラは適切な対策を取ることで大きく軽減できます。
例えば型チェックツールの導入やコーディング規約の厳格化、さらには静的解析の活用によって、Pythonの弱点はある程度コントロール可能です。
重要なのは言語そのものを否定するのではなく、特性を理解した上で設計レベルで吸収する姿勢です。

本記事では、Pythonに苦手意識を持つエンジニアが「なぜストレスを感じるのか」を構造的に整理し、そのうえで実務で使える具体的な解消法まで論理的に解説していきます。

Pythonが苦手・嫌いと感じるエンジニアの共通点と背景
インデント構文が引き起こすバグとストレスの正体
タブとスペース問題とPEP8による実務対策
動的型付けがもたらす実務リスクと予期しないバグ
型ヒントとmypyでPythonの弱点を補う方法
大規模開発でPythonが扱いにくくなる理由
IDEと静的解析ツールでストレスを軽減する実践手法
チーム開発におけるPythonコーディング規約の重要性
まとめ：Pythonの特性を理解してストレスを制御する

Pythonが苦手・嫌いと感じるエンジニアの共通点と背景

Pythonは学習コストが低く、読みやすさを重視した設計思想を持つ言語として広く普及しています。
しかし実務の現場では、「思ったより扱いづらい」「仕様が直感に合わない」と感じるエンジニアも一定数存在します。
この感覚は単なる好みの問題ではなく、プログラミング経験や開発対象のドメインによって生まれる構造的なギャップに起因する場合が多いです。

まず共通点として挙げられるのは、静的型付け言語に慣れているエンジニアです。
例えばJavaやC#のような言語では、コンパイル時に型の整合性が保証されるため、実行前に多くの不整合を検出できます。
一方Pythonは動的型付けを採用しているため、以下のような違いが発生します。

実行時まで型エラーが検出されない
IDEの補完精度が環境依存になりやすい
変数の意図がコードから読み取りづらい場合がある

この違いが、「安全性が低い」という心理的ストレスにつながることがあります。

また、バックエンドや大規模システム開発を主戦場とするエンジニアほど、Pythonに対する評価が厳しくなる傾向があります。
理由はシンプルで、スケーラビリティや保守性を重視する環境では、静的解析や明示的な型定義が重要になるからです。
Pythonは柔軟性を優先する設計であるため、設計思想そのものが異なるのです。

さらに、インデント構文への違和感も無視できません。
多くの言語では波括弧でブロックを明示しますが、Pythonではインデントが構造そのものを決定します。
このため以下のような問題が発生します。

見た目上のズレが即エラーにつながる
チーム開発時にフォーマット差異が混入しやすい
コピー＆ペーストで構造が壊れるリスクがある

特に長年C系言語に慣れているエンジニアほど、「構造が視覚に依存する設計」に違和感を覚えやすい傾向があります。

一方で、Pythonに対する苦手意識は単なる技術的問題だけではなく、開発スタイルの違いにも影響されます。
例えば以下のような対比が挙げられます。

観点	静的型言語志向	Python志向
型安全性	コンパイル時保証	実行時チェック
設計思想	厳密性重視	柔軟性重視
開発速度	中程度	高速

この違いは優劣ではなく、適用領域の違いにすぎません。
しかし認知のズレがあると、「なぜこんな仕様なのか」というストレスに直結します。

さらにもう一つ重要な背景として、学習初期の体験も影響します。
Pythonは入門教材として広く使われるため、簡単なスクリプトから学び始めるケースが多いです。
しかし業務レベルに移行した際に、非同期処理や設計パターン、依存管理などの複雑性に直面し、「思っていたPythonと違う」と感じることがあります。

このように、Pythonへの苦手意識は単一の原因ではなく、

型システムの違い
構文設計思想の違い
開発規模とのミスマッチ
学習体験と実務のギャップ

といった複数要素が重なって形成されるものです。
したがって重要なのは、Pythonそのものを否定するのではなく、その特性をどの領域で活かすべきかを冷静に整理する視点です。

インデント構文が引き起こすバグとストレスの正体

Pythonのインデント構文は、コードの可読性を高めるという明確な意図のもと設計されています。
波括弧を排除し、視覚的な構造と論理構造を一致させることで、コードの「見た目」と「意味」を揃えるという思想です。
しかし実務レベルにおいては、この設計が思わぬ形でストレスやバグの温床になるケースがあります。

特に問題となるのは、インデントが単なるスタイルではなく構文そのものを支配している点です。
これにより、以下のような問題が発生します。

スペースとタブの混在による実行時エラー
エディタごとの自動インデント差異による構造崩壊
コピー＆ペースト時に発生する意図しないブロック変化
差分レビューでロジックではなく空白の修正が発生

これらは一見すると単純なフォーマット問題に見えますが、実際には開発速度と精神的負荷に直結する重要な要因です。

例えば以下のようなケースを考えます。

def process(data):
    if data is None:
        return None
      return data.strip()

このコードは一見問題なさそうに見えますが、returnのインデントが崩れているため、Pythonでは構文エラー、もしくは意図しない制御フローを引き起こします。
C系言語であれば波括弧の位置に依存せず、コンパイラが構造を明確に解釈しますが、Pythonでは「見た目のズレ＝意味のズレ」となるため、ミスの検出が視覚依存になります。

さらにチーム開発では、この問題がより複雑化します。
複数人が異なるエディタや設定で開発する場合、以下のような不整合が起きやすくなります。

VSCodeではスペース4つ、Vimではタブなど設定差異
フォーマッタ未導入時のスタイル不統一
CIで初めてインデントエラーが発覚する遅延検出

このような状況では、コードレビューの本質がロジック確認ではなく「空白チェック」に変質してしまい、生産性が低下します。

また心理的な側面も無視できません。
インデントエラーは実行時まで気づかれない場合もあり、「なぜ動かないのか分からない」という状態を生みやすいです。
この不確実性が、特に静的解析に慣れているエンジニアにとって強いストレス要因となります。

一方で、この構文設計には明確な利点も存在します。

コードブロックの視認性が高い
無駄な記号が少なく、読みやすい
教育用途では理解が直感的

しかし重要なのは、これらの利点と引き換えに「構文と空白が不可分である」という制約が導入されている点です。

したがってインデント構文の本質的な問題は、単なる書き方の違いではなく、構造表現の手段が視覚情報に依存していることにあります。
この設計思想を理解せずに扱うと、些細なミスが重大なバグとして顕在化し、結果として「Pythonは扱いにくい」という印象につながるのです。

タブとスペース問題とPEP8による実務対策

Pythonにおけるインデント問題の中でも、特に実務で頻繁に発生するのが「タブとスペースの混在」です。
これは単純な見た目の問題ではなく、Pythonインタプリタがインデントを構文として厳密に解釈するため、即座に実行エラーへ直結する構造的な問題です。

まず前提として、Pythonではインデントは論理ブロックそのものを定義します。
そのためタブとスペースが混在すると、同じ見た目でも内部的には異なる字下げとして扱われる可能性があります。
この差異が原因で発生する典型的な問題は以下の通りです。

TabErrorによる実行停止
チーム間でのコード差分の不一致
エディタ依存の表示崩れ
CI環境でのみ発生する謎エラー

特に厄介なのは「ローカルでは動くがCIで落ちる」ケースです。
これはエディタの設定やOSのデフォルト挙動によってタブがスペースに自動変換されているかどうかが異なるために発生します。
この非決定性は、開発体験として非常にストレスフルです。

この問題に対する基本的な解決策は、PEP8に従ったスタイル統一です。
PEP8では以下のようなルールが推奨されています。

インデントはスペース4つを使用する
タブの使用は禁止（または極力回避）
行の最大長や空白の扱いも統一する

この中でも特に重要なのが「タブを排除し、スペースに統一する」というルールです。
これにより、環境差異によるインデント解釈のズレを根本的に防ぐことができます。

実務では、PEP8を手動で守るのではなく、ツールによる自動化が一般的です。
例えば以下のような構成がよく採用されます。

フォーマッタ：black
リンター：flake8
型チェック補助：mypy

これらを組み合わせることで、インデントに関する問題の多くは事前に排除可能です。
特にblackはコード全体のフォーマットを強制的に統一するため、タブとスペース問題を実質的に無効化できます。

また、エディタ側の設定も重要です。
VSCodeやVimなどでは以下の設定が推奨されます。

項目	推奨設定	目的
tab size	4	スペース幅の統一
insert spaces	true	タブ禁止
format on save	true	自動整形

このように、言語仕様だけでなく開発環境全体で統一することが重要です。

さらに、CIパイプラインにフォーマットチェックを組み込むことで、人的ミスを防ぐことができます。
例えばGitHub Actionsなどでblack --checkを実行すれば、フォーマット不一致のコードはマージ前に検出できます。

重要なのは、PEP8は単なる「スタイルガイド」ではなく、チーム開発における構造的な安全装置として機能するという点です。
これを軽視すると、タブとスペースのような些細な違いが、プロジェクト全体の品質低下につながる可能性があります。

結論として、タブとスペース問題は言語仕様の弱点ではなく、運用設計で解決すべき課題です。
適切なツールとルールを導入すれば、Pythonのインデント構文はむしろ一貫性の高いコードベースを形成する強力な仕組みに変わります。

動的型付けがもたらす実務リスクと予期しないバグ

Pythonの動的型付けは、柔軟性と開発速度を高める設計として広く評価されています。
変数宣言時に型を明示する必要がなく、同じ変数に異なる型の値を代入できるため、プロトタイピングや小規模スクリプトでは非常に強力です。
しかし一方で、実務レベルのシステム開発においては、この柔軟性がそのままリスクへ転化することがあります。

最も典型的な問題は、型の不一致が実行時まで検出されない点です。
静的型付け言語であればコンパイル時にエラーとして検出されるケースでも、Pythonでは実際にコードが実行されるまで問題が顕在化しません。
これにより、以下のような事象が発生しやすくなります。

本番環境で初めて発覚する型エラー
テストケースの網羅不足による見逃し
関数間のインターフェース不整合
リファクタリング時の副作用の増加

例えば、以下のようなコードは一見問題なく動作しますが、入力の型によっては意図しない挙動を引き起こします。

def add_values(a, b):
    return a + b
result = add_values("10", 5)

この場合、文字列と整数の加算が行われることで実行時エラーが発生します。
もし入力がユーザー依存であれば、バグは再現性が低く、原因特定が困難になります。

動的型付けのもう一つの問題は、コードの意図が静的に読み取りづらいことです。
関数の引数や戻り値の型が明示されないため、コードレビュー時や保守時に認知負荷が増加します。
特に大規模プロジェクトでは、この曖昧性が設計理解の妨げになります。

さらに、型情報が欠如していることでIDEの補完精度も低下する場合があります。
これは開発効率に直結する問題であり、特に以下のような場面で顕著です。

大規模リファクタリング時の影響範囲把握
API連携部分のデバッグ
複数モジュール間の依存関係解析

このような課題に対して、実務ではいくつかの対策が取られています。

対策	内容	効果
型ヒント	`typing`モジュールで型を明示	可読性向上
静的解析	mypyなどで事前チェック	バグの早期発見
テスト強化	境界値テストの充実	実行時エラー削減

特に型ヒントの導入は、Pythonの柔軟性を維持しながら静的言語に近い安全性を補う重要な手法です。
例えば以下のように記述することで、意図が明確になります。

def add_values(a: int, b: int) -> int:
    return a + b

このように型を明示することで、コードの自己文書化が進み、チーム開発における認知コストを低減できます。

ただし重要なのは、型ヒントは強制ではなく「補助」であるという点です。
Pythonの設計思想はあくまで動的型付けにあり、型ヒントはその上に乗るオプション機能です。
そのため、導入の有無や厳格さはプロジェクトの規模や要件に応じて調整する必要があります。

結論として、動的型付けは生産性の向上と引き換えに、予測可能性を犠牲にする設計です。
その特性を理解せずに使用すると、表面的にはシンプルでも内部的には複雑なバグを抱えやすい構造になります。
したがって、適切な型管理と静的解析の導入が、実務における安定性確保の鍵となります。

型ヒントとmypyでPythonの弱点を補う方法

Pythonの動的型付けは柔軟性という大きな利点を持つ一方で、実務においては「型の曖昧さ」がバグの温床になることがあります。
この問題に対する現実的な解決策が、型ヒント（type hints）と静的解析ツールであるmypyの組み合わせです。

まず型ヒントは、Pythonの実行モデルを変更するものではなく、あくまで「コードに型情報を付与するメタデータ」です。
これにより、開発者やツールがコードの意図をより正確に理解できるようになります。

例えば以下のようなコードを考えます。

def multiply(a, b):
    return a * b

この状態では、aとbが数値なのか文字列なのか、あるいはリストなのかは実行するまで確定しません。
しかし型ヒントを付けることで、意図が明確になります。

def multiply(a: int, b: int) -> int:
    return a * b

このようにするだけで、コードの可読性と意図の明確性は大きく向上します。

ただし型ヒント単体では実行時のエラーを防ぐことはできません。
そこで重要になるのがmypyのような静的型チェッカーです。
mypyはコードを実行せずに型整合性を検査し、不整合があれば事前に警告を出します。

実務では、以下のような流れで導入されることが一般的です。

コードに型ヒントを追加
CI環境でmypyを実行
型エラーをマージ前に検出
徐々に型カバレッジを拡大

このプロセスにより、Pythonの「実行してみないと分からない」という不確実性を大幅に減らすことができます。

さらに、型ヒントとmypyを組み合わせることで得られる効果は単なるバグ防止にとどまりません。
特に大規模開発では以下のような副次的効果が重要になります。

領域	改善内容	効果
可読性	関数の入出力が明確化	理解コスト低下
保守性	影響範囲の予測が容易	リファクタリング安全性向上
IDE支援	補完精度の向上	開発速度改善

また、型ヒントは「段階的導入が可能」という点でも実務向きです。
Pythonは強制的な型システムを持たないため、既存コードベースに少しずつ導入できるという柔軟性があります。
例えば最初は重要なAPI層のみ型を付与し、その後ユーティリティ関数へ拡張していくといったアプローチが現実的です。

一方で注意すべき点もあります。
型ヒントを過剰に導入すると、コードが冗長化し、逆に可読性を損なうケースがあります。
また、mypyの厳格度を上げすぎると、動的言語としてのPythonの柔軟性が失われる可能性もあります。
そのため、プロジェクトごとに「どの程度型安全性を求めるか」を設計することが重要です。

結論として、型ヒントとmypyはPythonの欠点を完全に消すものではありません。
しかし、動的型付けの利点を維持しながら、静的型付けに近い安全性を段階的に取り入れるための現実的な妥協点です。
実務においては、このバランス設計こそが品質と生産性を両立させる鍵になります。

大規模開発でPythonが扱いにくくなる理由

Pythonはプロトタイピングや小規模開発において非常に優れた生産性を発揮します。
しかしシステム規模が拡大し、複数チーム・多数のモジュール・長期運用が前提となる大規模開発に移行すると、その設計思想が逆に課題として顕在化することがあります。
これは言語の欠陥というよりも、設計トレードオフがスケールと噛み合わなくなる問題と捉えるのが適切です。

まず最も大きな要因は、型と構造の曖昧さです。
動的型付けにより柔軟にコードを書くことができますが、システム全体の整合性を静的に保証する仕組みが弱いため、以下のような問題が発生しやすくなります。

モジュール間インターフェースの不整合
リファクタリング時の影響範囲の不可視化
暗黙的なデータ構造依存の増加
テストに依存した品質保証構造

特に問題となるのは、コードの「意味」が型ではなく実行結果に依存する点です。
これにより、設計段階での誤りがコンパイル時に検出されず、テスト段階や本番環境で初めて顕在化するケースが増えます。

次に挙げられるのは、モジュール分割と依存関係管理の難しさです。
Pythonは自由度が高いため、設計規律が弱いまま開発が進行すると、依存関係が複雑に絡み合った「スパゲッティ構造」になりやすい傾向があります。
この結果として、以下のような問題が顕在化します。

問題領域	具体的症状	影響
依存関係	循環インポートの発生	起動エラーや設計破綻
モジュール構造	責務の曖昧化	保守性低下
変更影響	影響範囲の不透明化	修正コスト増大

さらに、大規模開発ではチーム間の認知のズレも重要な問題になります。
Pythonは記述の自由度が高いため、同じ機能でも実装スタイルが開発者ごとに異なる傾向があります。
これが積み重なると、コードベース全体の一貫性が失われ、理解コストが急激に上昇します。

また、動的型付けと柔軟な構造は、CI/CDパイプラインとの相性にも影響を与えます。
静的言語であればコンパイル時に多くの問題を検出できますが、Pythonではテストと静的解析に依存するため、以下のような構造になります。

コード実装
テスト作成
静的解析実行
実行時検証

この「実行依存型の品質保証」は、規模が大きくなるほどコストが増加します。

加えて、パフォーマンス面も無視できません。
Pythonはインタプリタ型であるため、CPUバウンドな処理や大量データ処理では限界が見えやすく、必要に応じて他言語との連携が発生します。
その結果、システムが複雑化し、アーキテクチャの一貫性が損なわれることがあります。

ただし重要なのは、これらの問題はPython単体の欠点ではなく、「大規模システムに求められる制約」と「動的言語の自由度」が衝突することで発生するという点です。
したがって対策としては、以下のような設計的アプローチが有効です。

型ヒントと静的解析の徹底
ドメイン駆動設計による責務分離
フォーマッタによるコードスタイル統一
明確なレイヤーアーキテクチャの採用

結論として、Pythonが大規模開発で扱いにくくなる理由は、言語仕様そのものよりも「設計統制の難しさ」にあります。
適切な規約とアーキテクチャ設計を導入しなければ、柔軟性はそのまま複雑性へと転化し、結果として運用コストが増大することになります。

IDEと静的解析ツールでストレスを軽減する実践手法

Python開発におけるストレスの多くは、言語仕様そのものよりも「検出の遅さ」と「人間依存のチェック」に起因します。
特にインデントや動的型付けの問題は、実行して初めて発覚することが多く、これが開発効率と心理的負荷を同時に悪化させます。
これを解決するための現実的なアプローチが、IDEと静的解析ツールの徹底活用です。

まずIDEの役割は単なるエディタではなく、「静的なミスを事前に潰す第一防衛線」として位置づけるべきです。
例えばVSCodeやPyCharmなどのモダンIDEでは、リアルタイムで以下のような検出が可能です。

未定義変数の参照
型不一致の可能性提示
インデント崩れの即時警告
未使用インポートの検出

これにより、従来は実行時まで気づけなかった問題の多くが、入力段階で可視化されます。

さらに重要なのが静的解析ツールの併用です。
代表的な構成は以下の通りです。

ツール	役割	効果
black	コードフォーマッタ	スタイル統一の強制
flake8	リンター	構文・スタイル違反検出
mypy	型チェック	型不整合の事前検出
pylance	IDE補助	高精度な補完と警告

このように役割を分担させることで、「書く」「整える」「検証する」を分離できます。
これが重要で、すべてを人間の判断に委ねる構造を排除することが目的です。

実務では、これらを単体で使うのではなく、CI/CDパイプラインと統合することが重要です。
例えば以下のようなフローが一般的です。

ローカルIDEでリアルタイムチェック
blackによる自動フォーマット
flake8でスタイルと構文検査
mypyで型整合性チェック
CIで全チェック再実行

この二重チェック構造により、「ローカルでは動くが本番で壊れる」という典型的な事故を大幅に減らすことができます。

またIDE設定の最適化も重要な要素です。
特にPython開発では以下の設定が推奨されます。

インデントをスペース4に統一
保存時自動フォーマット有効化
リアルタイムlintチェック有効化
型ヒント警告の表示強化

これにより、開発者は「正しいコードを書くこと」ではなく「間違えようとしても間違えにくい環境」に移行できます。

重要なポイントは、これらのツールは単なる補助ではなく、設計レベルの安全装置として機能するという点です。
特に大規模開発では、人間のレビューだけに依存することは現実的ではなく、機械的な一貫性チェックが必須になります。

ただし注意点も存在します。
ツールを過剰に厳格化すると、以下のような副作用が発生します。

開発速度の低下
警告疲れによる無視行動
柔軟性の喪失

そのため、プロジェクト初期ではルールを軽めに設定し、徐々に厳格化していく「段階的導入」が現実的です。

結論として、Pythonのストレスの多くは言語ではなく「検出遅延」と「統一不足」に起因します。
IDEと静的解析ツールを適切に組み合わせることで、この問題は構造的に解消可能です。
重要なのは個人の注意力に依存するのではなく、システムとしてミスを防ぐ設計に移行することです。

チーム開発におけるPythonコーディング規約の重要性

Pythonは自由度の高い言語であり、同じ処理でも複数の書き方が成立します。
この柔軟性は個人開発では大きな利点ですが、チーム開発においては一貫性の欠如を招きやすく、結果としてコードベースの複雑性を増大させる要因になります。
そのため、コーディング規約の導入は単なるスタイル統一ではなく、システムの認知負荷を制御するための設計手段として重要になります。

まずコーディング規約がない状態では、以下のような問題が発生しやすくなります。

同じ処理でも開発者ごとに実装スタイルが異なる
変数名や関数設計の粒度が統一されない
インデントや空白ルールが混在する
レビューがロジックではなくスタイル修正に偏る

これらは一見すると軽微な問題に見えますが、プロジェクト規模が拡大するほど影響は指数的に増加します。
特にコードレビューの負荷増大は、開発速度の低下に直結します。

コーディング規約の中心となるのは、PEP8をベースとした標準化です。
PEP8はPythonコミュニティで広く採用されているスタイルガイドであり、以下のようなルールを定義しています。

インデントはスペース4つ
1行の長さ制限（通常79〜88文字）
変数名はsnake_case
クラス名はPascalCase

これらのルールを統一することで、コードの見た目と構造が安定し、開発者間の認知ギャップを減少させることができます。

さらに重要なのは、規約を「ドキュメント」ではなく「強制ルール」として運用することです。
実務では以下のような仕組みが用いられます。

手段	役割	効果
black	自動フォーマット	スタイルの完全統一
flake8	静的チェック	規約違反検出
pre-commit	コミット制御	未整形コードの防止

特にblackのような自動フォーマッタは重要で、人間の判断を排除し「議論不要な領域」を作ることができます。
これにより、レビュー対象はロジックと設計に集中できるようになります。

またチーム開発では、規約の導入順序も重要です。
一般的には以下のような段階的アプローチが採用されます。

基本スタイル（PEP8）の合意
フォーマッタ導入（black）
リンター導入（flake8）
CI/CDへの統合
型チェック追加（mypy）

このように段階的に導入することで、既存コードとの互換性を保ちながら徐々に品質を向上させることが可能です。

一方で、規約は厳しすぎても問題になります。
過度に細かいルールは開発者の自由度を奪い、結果として生産性低下や規約疲れを引き起こします。
そのため、重要なのは「最小限のルールで最大限の一貫性を得る」という設計思想です。

特に注意すべきは以下の点です。

本質的でないルールを増やさない
ツールで自動化できるものは人間に判断させない
プロジェクトごとに規約レベルを調整する

結論として、チーム開発におけるPythonコーディング規約は、単なるスタイル統一ではなく「認知コストの削減」と「設計の標準化」を目的としたインフラです。
これを適切に設計・運用することで、Pythonの柔軟性を維持しながら、大規模開発に耐えうるコードベースを構築することが可能になります。

まとめ：Pythonの特性を理解してストレスを制御する

Pythonに対する「苦手意識」や「扱いにくさ」は、単なる感情的な好みではなく、言語設計と開発規模、そしてエンジニアの経験背景が相互作用して生じる構造的な現象です。
本記事で整理してきたように、その多くはインデント構文の厳密性、動的型付けによる実行時依存、そして大規模開発における設計統制の難しさに起因しています。

重要なのは、これらの要素を「欠陥」として単純に捉えるのではなく、「特性」として正しく理解することです。
例えばインデント構文はミスの温床になる一方で、コードの視覚的一貫性を強制する仕組みでもあります。
また動的型付けは不確実性を含む反面、試作速度や柔軟な設計変更を可能にします。
つまり、同じ性質が利点にも欠点にもなり得るということです。

このような二面性を持つ言語を扱う際に重要なのは、以下のような設計的な視点です。

言語仕様に依存せず、ツールで制約を補強する
人間の判断を減らし、機械的な一貫性を確保する
小さな自由度よりも、大きな予測可能性を優先する場面を明確にする

特に実務においては、Python単体の評価ではなく、周辺ツールや開発プロセス全体を含めた「運用設計」として考えることが重要です。
型ヒントやmypy、black、flake8といったツール群は、そのための補助装置として機能します。
これらを適切に組み合わせることで、動的言語の弱点はかなりの程度まで制御可能です。

また、エンジニアの経験領域によっても感じ方は大きく異なります。
静的型付け言語に慣れた開発者ほど不確実性に敏感になり、逆にスクリプト言語中心の経験を持つ場合は柔軟性を強く評価する傾向があります。
この差異を理解せずに議論すると、「Pythonは良い・悪い」という不毛な対立に陥りがちです。

したがって最終的な結論として重要なのは、言語そのものの優劣ではなく、「どのように制御しながら使うか」という視点です。
Pythonは適切に設計・運用されれば、非常に生産性の高い言語です。
一方で無秩序に使用すれば、その柔軟性がそのまま複雑性へと転化します。

結局のところ、Pythonのストレスの多くは言語ではなく運用設計の問題です。
特性を理解し、ツールと規約で補強し、チーム全体で一貫性を担保することで、そのストレスは構造的に制御可能になります。
そしてその結果として、Pythonは「扱いにくい言語」ではなく「適切に扱えば非常に強力な言語」として機能するようになります。