タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

Pythonとmemoryとprogrammingに関するraimon49のブックマーク (4)

  • プログラミング言語の未来はどうなるか | κeenのHappy Hacκing Blog

    κeenです。最近JEITAのソフトウェアエンジニアリング技術ワークショップ2020に参加したんですが、そこで五十嵐先生、柴田さん、Matzとパネルティスカッションをしました。その議論が面白かったので個人的に話を広げようと思います。 年末年始休暇に書き始めたんですが体調を崩したりと色々あって執筆に時間がかかってしまいました。 時間を置いて文章を書き足していったので継ぎ接ぎ感のある文体になってるかもしれませんがご容赦下さい。 というのを踏まえて以下をお読み下さい。 いくつか議題があったのですが、ここで拾うのは一番最後の「プログラミング言語の未来はどうなるか」という話題です。 アーカイブが1月末まで残るようです。もうあと数日しかありませんが間に合うかたはご覧下さい。 そのとき各人の回答を要約すると以下でした。 五十嵐先生:DSLを簡単に作れる言語というのが重要。それとプログラム検証、プログラム

    プログラミング言語の未来はどうなるか | κeenのHappy Hacκing Blog
    raimon49
    raimon49 2021/01/27
    obj.method()形式のオブジェクト指向っぽいメソッド呼び出しはIDEなどが補完するタイミングを読み取るのに優しいから生き残るっていう考察がとても面白くて腹落ちした。
  • PHPとPythonとRubyの連想配列のデータ構造が同時期に同じ方針で性能改善されてた話 - hnwの日記

    PHPPythonRubyの連想配列のデータ構造がそれぞれ4〜5年ほど前に見直され、ベンチマークテストによっては倍以上速くなったということがありました。具体的には以下のバージョンで実装の大変更がありました。 PHP 7.0.0 HashTable高速化 (2015/11) Python 3.6.0 dictobject高速化 (2016/12) Ruby 2.4.0 st_table高速化 (2016/12) これらのデータ構造はユーザーの利用する連想配列だけでなく言語のコアでも利用されているので、言語全体の性能改善に貢献しています1。 スクリプト言語3つが同時期に同じデータ構造の改善に取り組んだだけでも面白い現象ですが、さらに面白いことに各実装の方針は非常に似ています。独立に改善に取り組んだのに同じ結論に至ったとすれば興味深い偶然と言えるでしょう2。 稿では3言語の連想配列の従来実

    PHPとPythonとRubyの連想配列のデータ構造が同時期に同じ方針で性能改善されてた話 - hnwの日記
  • python自習テキスト [kirinwiki]

    このコンテンツを更新しなくなって久しく、さらにレンタルサーバーのPHPもずっと古いバージョンを使うわけにいかず、従来のdocuwikiを使うのをやめました。全ての内容を静的なHTMLにするのが割と手間なため、手抜きとして、ここの表紙以外をPDFに直してしまいました。これで保存します。python2用なので利用価値もすでに少ないですけどね。 っていうか、実際は動物さんイラスト集サイト。pythonの話はオマケ。 スクリプトが書けると、多分どっかで何かの役に立ちます。決まりきった仕事をチマチマと手作業でやるような場面で、スクリプトを上手に書けると劇的に楽になったりすることもあります。筆者自身がそういう経験を持っているので、他にも同じようなことができる人が現れてほしい。こういった動機で、習得用のテキストをポチポチと書き続けています。 興味はある(or 必要に迫られている)んだけど、当に何も知ら

    raimon49
    raimon49 2018/11/17
    yield文について、ティッシュを1枚ずつ取り出すのと束で取り出すメタファーでリソース効率を、バケツリレーのメタファーでコルーチンを解説。
  • __del__, gc, 循環参照, weakref

    2010年11月22日公開 Python の __del__ メソッド、ガベージコレクタ、循環参照、そして弱参照についての解説と考察。 参照カウンタ __del__ __del__ の落とし穴 循環参照 __del__ の落とし穴 考察 __del__ を使わない 循環参照を確実に避けることはできる? 弱参照 weakref モジュールを利用したハック いったいいつ __del__ を使うのか 参考文献 事項 参照カウンタ C/C++ では、malloc を使って確保したメモリや new で作成したオブジェクトについては、必ず対応する free / delete を呼ばなければならない。これを忘れるといつまでも解放されないメモリがプログラムの生存期間中居残ることになる。これをメモリリークと呼ぶ。メモリリークがあると、確保されたままになったメモリが OS や他のプロセスを圧迫して、システム全

    raimon49
    raimon49 2012/10/13
    __init__で例外が発生するようなシチュエーションでは__del__の呼び出しは保証されない。del(obj)した時も参照カウントが1減るだけで、即時の呼び出しは保証されない。
  • 1