PySimpleGUI 技術関連ニュース

 (github.com/PySimpleGUI)
4 ポイント 投稿者 GN⁺ 2023-12-11 | 1件のコメント | WhatsAppで共有
  • PySimpleGUIは商用化の試みを終えた後、PySimpleGUI 5のコードからライセンスとセキュリティコンポーネントを削除し、GitHubとPyPIでLGPL3ライセンスのPySimpleGUI 6として再公開された
  • 最新版はpython -m pip install PySimpleGUIでインストールでき、旧バージョン4.60.5.1やGitHubのmaster、特定リリース6.1もpipで直接インストール可能
  • PySimpleGUIはtkinterなどのGUIライブラリのラッパーで、GUI SDKをよりシンプルで圧縮された構造に変えつつ細かなカスタマイズを提供し、事前のGUIプログラミング経験は不要だと紹介されている
  • バージョン6.2には、Window.settings_saveのバグ修正、Multilineでの画像インライン出力、psgupgrade、Treeノードのプログラムによる選択、Window.start_timerの"H:M:S"文字列タイマー、Frameの枠線色設定などが含まれる
  • プロジェクトはプルリクエストを受け付けない方式で維持されており、長期的な将来は不透明だが、作者はコードを書き、エコシステムを整理し続ける意向を示している

PySimpleGUI 6の再オープンソース化

  • PySimpleGUIは商用化を試みたが、期待した水準でプロジェクトを継続するために必要なリソースを生み出せなかった
  • 2025年2月にPySimpleSoftの終了と2025年末までのサポート継続が発表され、その後、コード・ドキュメント・リポジトリをどうするかが残された課題だった
  • PySimpleGUI 5のコードはライセンスとセキュリティコンポーネントを削除したうえでGitHubとPyPIに公開された
  • 新たに公開されたバージョンはLGPL3ライセンスを使用する
  • Udemy講座はしばらく無料で提供され、クーポンコードは033334A16163C571B739

インストール方法

  • PyPIの最新版v6をインストール:
    • python -m pip install PySimpleGUI
  • 旧バージョン4.60.5.1をインストール:
    • python -m pip install PySimpleGUI==4.60.5.1
  • GitHubリポジトリの最新コードは直接インストールできる:
  • GitHubの特定リリースをインストールするには、masterをリリース番号に置き換える:
  • リポジトリをクローンまたはダウンロードした後、ローカルインストールも可能:
    • python -m pip install .

PySimpleGUIの役割

  • PySimpleGUIはtkinterや他のGUIライブラリを包むラッパー
  • GUI SDKをよりシンプルで圧縮された構造に変えつつ、細かなカスタマイズも提供する
  • 事前のGUIプログラミング経験は不要だと紹介されている
  • READMEの例では、Text、Input、Button、Window、イベントループ、window.read()、window.close()だけで対話型ウィンドウアプリを構成する
  • ドキュメントはDocs.PySimpleGUI.comで提供されている

開発方式と長期的展望

  • PySimpleGUIは従来のオープンソースプロジェクトよりも、プロプライエタリ製品に近い方式で開発されてきたと説明されている
  • プルリクエストは受け付けていない
  • 長期的な将来は明確ではないが、現在作者はコードを書き、手助けすることを楽しんでいる
  • PySimpleGUIでの経験は、人々が作った成果物を見ることができた「once-in-a-lifetime」の経験だったと表現されている

バージョン6.2の機能と修正

  • 6.2にはWindow.settings_saveのバグ修正が含まれる
  • Multiline要素で画像をインラインに“print”する機能が追加された
  • 最新のメンテナンスリリースへアップグレードする機能が、再びPySimpleGUIに組み込まれた
    • Home Windowまたはコマンドラインのpsgupgradeを使用できる
    • リリースノートを確認し、新しいバージョンをインストールできる
  • Graphイベントがwrite_event_valueイベントを受け取ると無限ループに入っていた#5750のバグが修正された
    • リアルタイムボタンフラグをクリアする方式で修正された
    • 変更範囲はGraph要素の条件文に限定されており、リグレッションの可能性は小さいと記されている
  • Tree.updateにselect_node_keysパラメータが追加され、ツリーノードをユーザーが選択したかのようにプログラムから選択できるようになった
  • Multilineのecho_stdout_stderr機能とパラメータが修正された
    • stdoutまたはstderrを該当要素へリルートした場合にのみechoする
    • この機能自体が直接リルートを実行するわけではない
  • #6686の修正により、Calendar chooserボタンがwindow.readの戻り時点でのみクリアすべきフィールドをクリアしていた問題が解決された
  • Home Windowにメンテナンスリリースのバージョン番号が表示され、インストールボタンの位置が移動された
  • Window.start_timer呼び出し時に"H:M:S"文字列でタイマーを指定できる
  • スクロール可能なColumn要素に、水平スクロールのみをサポートする機能が追加された
  • Frame要素にはborder_color、border_width_no_reliefパラメータが追加され、枠線の色を設定できる
    • Frameの枠線色は別途設定がなければ、テキスト要素の色をデフォルトとして使用する
  • ドキュメントのcall referenceセクションは6.2リリースに合わせて更新された

ドラッグ＆ドロップと周辺プロジェクト

  • ドラッグ＆ドロップは長らく望まれていた機能で、PySimpleGUIのコードを変更せずユーザーコード空間で実装する方法が見つかったと説明されている
  • psgdndはPySimpleGUIにドラッグ＆ドロップを追加する新しいパッケージ
    • pipでインストールして使用できる
    • 詳細情報と例は該当リポジトリにある
  • psgdnd 6.0.1はPyPIでリリースされ、Windowsで動作する
  • GitHubの6.0.2にはLinuxで必要だった修正が含まれる
  • Mac対応状況はまだ不明
  • PSGMicroPythonリポジトリには、MicroPythonベースのマイクロコントローラとインターフェースするコードが追加された
    • Raspberry Pi PicoとESP32で動作する
    • 他のボードでも動作する可能性がある
    • 堅牢なものや大規模プロジェクトとして意図されたものではなく、有用かもしれないコードとして紹介されている

PSGWebプロトタイプ

  • PSGWebはPySimpleGUIをブラウザウィンドウで実行するプロトタイプ
  • ほとんどのデモプログラムで動作する
  • GitHub上のPySimpleGUIアプリケーションURLの前にpsgweb.usを付けると、実行を試すことができる
  • PSGWebはより大きなPSG 5作業の一部として作られたが、公開されなかった
  • このプロトタイプをリリースまたは拡張する計画はない

AI利用に対する立場

  • 作者はLLMをドキュメント検索と要約、エラー検索、調査、知識獲得に使用している
  • LLMでコードは書いていない
  • 理由は単純に、コードを書くこと自体が好きだからだと明かしている
  • プロジェクトをプルリクエストに開放しなかったのも、他人にコードを書いてもらうより自分でコードを書きたかったためだと説明している
  • PySimpleGUIがAI時代にも関連性を持つかについては、毎日人々がPySimpleGUIを見つけてインストールし、少なくとも1人が使っているだけで十分だと考えている
  • 作者はWindowsアプリを作るとき、PySimpleGUIなしでは想像しにくいと述べている
    • 最近の6502ブレッドボードコンピュータ作業で、2台のRaspberry Pi PicoとPySimpleGUIアプリを使ってバスアナライザを作ったと説明している
    • Windowsでツールを制御するフロントエンドアプリをPySimpleGUIで簡単に作れたという

プロジェクトの歴史と資金問題

  • PySimpleGUIは2018年、メディアプレーヤーのプロトタイプ用GUIが必要だったために作られた一回限りのコードから始まった
  • 目標は、オブジェクト指向GUIフレームワークの経験がなくても、Tkinterをより線形で直感的な方法で包み、すばやく動くようにすることだった
  • 作者はPythonやオープンソースの経験がないままGitHubに公開し、従来のオープンソースプロジェクトよりもスタートアップのように取り組んだ
  • タイムライン:
    • 2018年7月: Version 1
    • 2019年6月: Version 4
    • 2020年1月: 資金問題が主な懸念となり、商用化が言及された
    • 2020年11月: Udemy講座の発表と公開での支援依頼を追加
    • 2021年12月: 講座リリース
    • 2024年2月: Version 5商用リリース
    • 2026年4月: Version 6
  • GitHubのAnnouncements Issueは、プロジェクト記録を残すブログのように使われ、1,700件を超える項目に増えた
  • 読みやすくするため、ドキュメントのAnnouncements 2018-2024タブにスナップショットが掲載された
  • フルタイムのオープンソース作業は、即時かつ継続的な金銭的プレッシャーを生んだ
  • スポンサーと寄付はGitHub Sponsors、Buy Me a Coffeeを通じ、ピーク時でも月約150ドル程度だった
  • 61レッスン、11.5時間分のUdemy講座は初期に一時、月約2,000ドルまで達したが、その後100ドル未満に落ちた
  • どちらの方式もプロジェクトを長期的に維持するには十分ではなかった

商用化の結果とライセンス経験

  • Version 5の有料製品リリースは突然の決定ではなく、READMEと告知で何年にもわたり公開で議論されてきた
  • 2024年初めに他の選択肢を使い果たした後、商用版がリリースされた
  • 目標は障壁を作ることではなく、アクセスしやすさを維持することだった
  • 財務的な持続可能性という基準ではうまくいかなかったが、経験・学習・関係という基準では価値があったとまとめられている
  • 商用化後もほとんどのユーザーを失ったわけではなく、多くの企業が引き続きPySimpleGUIを使用している
  • 問題は、企業にライセンスを購入してもらうことだった
  • 趣味ユーザーと学生は無料で使用し、企業は費用を支払うHobbyist Licenseが選ばれた
  • 実際には大多数のユーザーが自分を趣味ユーザーだと識別した
  • 数万人の企業ユーザーが無料ティアに登録し、大企業でも数百人のユーザーがいながら有料ライセンスは少数というケースは珍しくなかった
  • 無料オプションを提供した決定自体は後悔していないと明かしている
  • 個人的な結論は、Pythonツールとライブラリは無料であるべきだという文化的期待が強いということ
  • 価格や不満が核心的な問題だったようには見えず、人々はPySimpleGUIを使い続けたが、費用を支払う義務は感じなかったと解釈している
  • 明確なライセンス条件も、常に行動を変えられるわけではなかった

現在のライセンス

  • 著作権表記はCopyright 2018-2026 PySimpleGUI. All rights reserved.
  • 現在のライセンスはLGPL3

関連記事

1件のコメント

 
GN⁺ 2023-12-11
Hacker News の意見

  • 仕事で Jira に作業時間を記録しなければならなかったのですが、Webサイトを開きっぱなしにするのが嫌で、作業中の課題を探し、時間記録リンクを探し、コメントを追加する手順も遅かったです。
    自分に割り当てられた課題一覧と、コメント／作業時間を追加するボタンがあるデスクトップアプリが欲しかったのです。Tkinter では見栄えよく作るのにかなり苦戦しましたが、PySimpleGUI を見つけてから Jira API のフックをつなぎ、欲しいものを作れましたし、UI 開発を学ぶにはよいプロジェクトでした。

    • Jira はあまりにも全般的に遅いので、多くの人が カスタムツールで迂回しようとしているように思います。
      友人もある職場で Jira の基本作業用の社内 Qt クライアントを作ったと言っていましたし、私も Jira で作業を追跡しなければならなかったとき、https://github.com/go-jira/jira を使い、複数のコンソールスクリプトで変更作業を処理していました。
    • 職場で Jira の時間記録を始めると言われたので、新しい職場を探し始めました。
    • このアプリのソースがどこかで公開されているのか気になります。今週似たものを作ろうかと考えているので、既存のアプリに Jira インスタンスだけ指定できるなら本当にありがたいです。
    • これが本当に UI 開発の学習なのかは疑問です。もっと難しいプロジェクトにつながったり、拡張できたりするのかよく分かりません。

  • こういう GUI フレームワークには本当に期待しています。ネイティブデスクトップ体験は WebView の組み合わせよりはるかに良いですし、PySimpleGUI の単純化されたイベントループと 複数バックエンドのアプローチは、実際に新しいものだと思います。
    ただ、データ構造と関数だけ渡せば、それを操作するための適切なインターフェースを自動で作ってくれる「自動 GUI」が、なぜもっと多くないのか不思議です。パネルを縦／横に置くか、タブインターフェースやポップアップにするかをヒューリスティックで選べば、CLI ではネストが深すぎ、Webアプリにするにはネイティブな機能を多く開放しすぎるような用途にも対応できるはずです。

    • 興味があるかもしれないプロジェクトとして、Gooey は「ほぼすべての Python 3 コンソールプログラムを 1 行で GUI アプリに変える」とされています。
      https://github.com/chriskiehl/Gooey
    • 2011年に関数の引数を基にした Web 用の 自動フォーム生成器を作り、最近は D 言語ベースの GUI ツールキットでも少し似たことを試しました。
      構造体を定義して dialog 関数に渡すと、構造体のフィールドに合わせてダイアログを自動生成し、ユーザーが OK を押すとコールバックを呼ぶようにできます。ユーザー定義属性でどのウィジェットを使うかも指定でき、たとえば int に @ControlledBy!VerticalSlider(0, 100) を付けると、数値入力欄の代わりに 0〜100 のスライダーになります。メニュー関数にも @menu("Search") Find(string text) { ... } のように付けてメニューとダイアログを自動生成できますし、変更イベントごとにコールバックを呼ぶ DataControllerWidget もあります。数年前に関連記事も書きましたが、進捗は非常に遅いです: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_02.ht...
      もっと時間を使いたいほど面白いのですが、本業で使う機会がなく、週末にコードを書きたいときに少しずつ進めるだけになっています。
    • その説明に合うものとして、何十年も前に Naked Objects というものがありました。Java 方面には興味がなかったので使ってはいませんが、有用そうに見えました。
    • Python には TraitsUI という、なかなか良い「自動 UI」があり、今でもその役割を果たしています。

  • サンプルの見た目が [0] のように、90年代からそのまま持ってきたかのように見えます。プロトタイプや、CLI を使えない人向けの社内ツールには完璧ですが、見栄えのよい UI が必要なときはどうすればよいのか気になります。
    性能面ではネイティブ UI が常に優れていますが、Webページよりスタイリングが難しいと感じてきました。Python GUI で、Flutter や SwiftUI のように大きな労力なしで洗練されて見えるスタイル付きコンポーネント群に相当するものは何なのか気になります。
    [0] https://raw.githubusercontent.com/PySimpleGUI/PySimpleGUI/ma...

    • 上手い下手の問題ではあるのでしょうが、私の経験では「スタイル付き」UI は、多くのソフトウェアとユーザーにとって、ソフトウェアを悪くする理由の一つでした。
      少なくとも OS が提供する標準 UI スタイルなら、人々はあるアプリで学んだことを別のアプリに持ち越せます。私は優れた UI デザイナーではないので、OS のデフォルトのほうが自分の思いつくものより優れている可能性が高いです。そこに、マーケティング側が聞くのを恐れる「うちのソフトウェアは古く見える」という言葉まで加わると、開発コストはすでに手に負えない水準まで膨らみます。
    • 90年代風そのものは悪くありませんが、これは 90年代の OS ルックにも合っていません。チェックボックスの背景は間違っており、上部のタイトルラベルはずれていて、Exit ボタンの位置も変なので、全体として 設計の悪い UI に見えます。
      90年代にもこういうソフトウェアはありましたが、人々がよく言う90年代の美学ではありません。Windows 95 の UI デザインには多くの労力が注がれていました。
    • 90年代風の見た目の何が問題なのか分かりません。好きな人も多いです。
      最近の UI の広い余白、ボタンに見えないボタン、消えるスクロールバー、ハンバーガーメニューのほうが嫌いです。
    • 見た目が最優先なら、Webページに勝つのはかなり難しそうです。
      フロントエンドとバックエンドの分離も標準でできますし、後で必要になればリモートアクセスも可能です。ネイティブアプリのように使いたければ、小さな Tkinter 系 GUI に「Open browser UI」ボタンを1つ置くだけでも十分です。実行ボタンが URL にトークンを入れるようにすれば、同じマシンの別ユーザーとして実行中のデーモンからも保護できますが、実際にそうしているところは見たことがありません。
    • 問題は、Tkinter が少なくとも Windows では本当に 90年代のウィジェットをベースにしていることです。PySimpleGUI のテーマを SystemDefaultForReal に変えても、ネイティブの Windows ウィジェットは現代的な外観なのに、Tkinter はまったく更新されていないため不自然に見えます。

  • よさそうに見える。ただ、このライブラリはすでに成熟していて大きな変更は難しいかもしれないが、リストの代わりに辞書を使うとよいと思う。最近の Python の辞書は挿入順序を記憶する
    以前の職場で PyQt の上に、これよりずっと薄いラッパーで似たものを作ったことがあり、コード量も驚くほど少なかった。主な違いは、属性／シグナル設定とウィジェットのネストを一緒に扱っていた点。コンストラクタで属性を設定する方式より、あとでテキストを変更するためにウィジェット名が必要な場合でも、ビュー定義の本体で属性を設定できる利点があった。setup_view 関数ひとつが API 全体で、簡単な GUI を素早く作るときにはかなり便利だった。このライブラリも良い代替案に見えるので、共有に感謝

    • その変更は Python 3.7 で入り、もう5年以上前の機能になっている
      https://docs.python.org/3/whatsnew/3.7.html#summary-release-...
    • 最近の GUI フレームワークの流れを見ると、レイアウトとデータの分離のほうが、はるかにきれいなコードになる
      データバインディングはフレームワークに任せるほうがよい。Web もデスクトップも、どちらもこの方向に進みつつある。ウィジェットを直接変更するのではなく、ウィジェットの属性をデータストアにバインドし、変更時に自動で再レンダリングされるようにすべき。ページの入力／出力例は似たものを示している。今では誰も getElementById() を使わない
    • GitHub ページによると、「初心者が理解している Python の中核データ型であるリストと辞書を使って、ウィンドウ定義を単純化した」とある

  • VB6 や Delphi/Lazarus の使いやすさに近づいているように思う。確かに進歩はあり、あとは対話型 GUI ビルダーさえあれば、作ったフォームを #import してすぐ使う、という形で済むかもしれない
    数年前に WxPython と WxFormBuilder を一緒に使おうとして、プロジェクトで膨大な時間を失った。フォームに小さな変更を加えるだけでバックエンドが全部壊れ、間をつなぐ薄いコードを自分で書いたが、フィールド型を変えたらまた全部壊れた。ここではそういうことが起きなさそうでよかった

  • Python GUI アプリケーション [1] を開発している立場からすると、デスクトップアプリに Python を使う際の最大の問題はパッケージングだと思う
    配布可能なバイナリを作る既存のツールは、依存関係がいくつかを超えるだけで動かなくなったり、かなりのハックが必要になったりする。人気のあるパッケージでさえ、隠れた import の欠落や、知らなかったデータファイルの欠落といった難解な問題が起きる。動的モジュール読み込みも、PyInstaller や cx_freeze のように通常の Python 環境の外へ持ち出すと壊れることがある。何ができるかは分からないが、Python にも Java の JAR のように、インタプリタだけに依存する独立実行プログラムのパッケージング標準が必要なのかもしれない

    1. https://github.com/FreeLanguageTools/vocabsieve
    • Python には標準化されていて JAR に似た zipapp がある: https://peps.python.org/pep-0441/
      shiv や PEX のようなツールでアプリケーションの依存関係を含む zipapp を作れるが、バイナリ拡張がある場合、成果物は依然としてプラットフォーム別になる: https://github.com/linkedin/shiv#gotchas
      私の Python プログラムでは、ユーザーに pipx でインストールするよう勧めている: https://github.com/pypa/pipx
      対象ユーザーが少しでも技術寄りなら、これが最善の選択だと思う。pip install --user のバージョン衝突や、アプリごとの仮想環境を手動で作る苦痛を避けられ、全体として悪くないユーザー体験を提供する。pipx を標準のインストール方法として勧めても、人々がインストールに成功すると期待できる。私のプログラムにはバイナリ依存関係はあるが、GUI はない

  • 個人的には CustomTKinter のほうが好み。ずっと洗練されていて Material テーマのような外観で、Windows/Linux/macOS でシステム設定に応じたライト／ダークテーマをサポートしている

  • 高速アプリケーション開発の領域で、VB6 が残した空白をいまだに何もきちんと埋められていないのは驚きだ。言語自体は優れていたわけではないが、VB6 の強みはドラッグ＆ドロップの GUI ビルダーだった

    • 他の人が言っているように Lazarus は検討に値するし、もっと VB らしい体験を望むなら Gambas も面白いかもしれない
      https://www.lazarus-ide.org/
      https://gambas.sourceforge.net/en/main.html
    • 手動編集可能なファイルに UI を保存する、同じパラダイム
      https://qb64.com/inform.html
    • https://www.lazarus-ide.org/
    • ドラッグ＆ドロップによる UI 設計のために、qtcreator を本来よりずっと長く使っていた
      便利なことに、レイアウトファイルを Python スクリプトの横に置いておくだけで pyqt から使える。IDE の Python サポートは良くないが、自分のインストール環境が壊れているせいかもしれない
    • Xojo は事実上、VB6 の精神的後継だ
      https://xojo.com/

  • かなりよくできたCLIインターフェースを持つツールにGUIをかぶせて、デスクトップLinuxを使っていない人でも使えるようにしようか考えている。PySimpleGUIは自分の用途にぴったり合うかもしれないと思っている
    https://github.com/hiAndrewQuinn/finstem
    自分のツールには、CSV、TSV、JSONのフラグがきちんと定義されている。既存の完全なCLIツールを変更せず、その上にGUIを作った経験があるか、どんな難しさを想定すべきか知りたい

    • チェスエンジンは良い参考例。意思決定部分はCLIで、WinBoard[0]やArena[1]のようなGUIにつながる
      エンジンとGUIはWinBoardやUCI[2]のようなプロトコルに従い、STDIN/STDOUTでテキストコマンドをやり取りする。主な難点はマルチスレッドで遭遇するものと同じで、GUIとCLIが互いに待ち合って止まるデッドロックが起こり得ること。そのため、双方とも入出力を「ビジネスロジック」とは別スレッドで処理して応答性を保つ必要がある。もう一つよくある問題は、パイプ処理にOSごとの特性がある点で、バッファのflushやLinux/Mac/Windows間のAPI差に気を配る必要がある
      [0] http://hgm.nubati.net/
      [1] http://www.playwitharena.de/
      [2] https://gist.github.com/DOBRO/2592c6dad754ba67e6dcaec8c90165...
    • 例えばHandBrakeを見ればよい。ffmpeg向けの豪華なUIに近い

  • 失礼に聞こえなければいいのだが、テキストが多すぎる。テキストを入れられる場所のあちこちに長い文章が続いていて、ほとんど一貫性はあるものの、最初の1000語の間に関連するスクリーンショットが一つもない
    何かがずれて見える。おそらく若くて熱心な開発者なのか、使ってみるよう説得しようとしてテキストをたくさん入れたように感じる。READMEには作者が自分を紹介する「about me」セクションまである。READMEのどこでもいいので下に移動して数段落を読み、今読んだ内容を言い直してみれば例になるはず

    • 各セクションには明確な見出しがある。興味のないセクションなら少しスクロールすればよい。誰も「about me」セクションを読むよう強制していない
      「最小限の単語だけ読んで、できるだけ早く実行するにはどうすればいいか」という姿勢より、ツールについて読むこと自体を楽しむ人もいる。他人が作ったツールを無料で使っているのだから、不満を言うのをやめて、本人の望む形で表現させておくのがよい
    • 「若くて熱心な開発者」という推測は間違っている。「About Me」[1]には、70年代からソフトウェアを書いており、キャリアの大半をSilicon Valleyで製品作りに費やしたと書かれている
      [1] https://github.com/PySimpleGUI/PySimpleGUI#about-me-
    • ざっと見ただけ。投資家を引きつけるための製品向けMVPではなく、作った人が自分でドキュメントを書いたツールだ
      失礼でなければいいが、もしかして段階的な要約で口元まで運んでもらえないと、文章を読まなければならないという事実そのものを恐れているのでは、と聞き返したい
    • かなり失礼な表現だと思う。特に、テキストが多い理由を二つのどちらかにだけ還元していて、どちらもあまり良くは聞こえない。しかも、その理由が当たっているようにも見えない
      同じ考えは「視覚的なプロジェクトなら、メインの説明にもっとスクリーンショットがあったほうがよいと感じる」程度でも伝えられたし、侮辱的な推測は省けたはず
    • プロジェクト名をSimpleにしたのが問題かもしれない。読者の頭の中に、期待する先入観を植え付けてしまうからだ
      Smart、Open、Trusted、Secureのような単語をプロジェクト名に入れると、人々はその名前の理想に届いていないと指摘しやすい。逆にCやBSDのような名前には反対語や含意がないので、「C言語は名前負けしている」とは言いにくい