タグ

ブックマーク / qiita.com/methane (12)

  • Python 3.8 では空dictが小さくなる - Qiita

    Python 3.7 では {} で作った空 dict よりも、 dict.clear() で作った空 dict の方が省メモリでした。 >>> import sys >>> d = {} >>> sys.getsizeof(d) 240 >>> d.clear() >>> sys.getsizeof(d) 72 これは dict オブジェクトを新規作成するときに最小サイズのハッシュテーブルを確保し初期化するのに対して、 dict.clear() は shared key dict の仕組みを使って空 dict 専用の共有テーブル（書き込み禁止）を利用しているからです。 空の dict の数は無視できないくらいにはあるので、Python 3.8 で新規に dict オブジェクトを作るときも dict.clear() の結果と同じ共有領域を使うようにしました。 なお Python 3.7 の

    Python 3.8 では空dictが小さくなる - Qiita

  • Python 3 で日本語ファイル名が入った zip ファイルを扱う - Qiita

    zip ファイルは最近の仕様では UTF-8 でファイル名を格納できるのですが、多くの場合レガシーな環境依存文字コードでファイル名が格納された形式が使われています。日本語の場合は Windows に合わせて Shift-JIS (cp932) が使われることが多いです。 Python 2 では zipfile モジュールが返すファイル名はバイト文字列だったのでそのまま cp932 のファイル名が返ってきたのですが、 Python 3 では文字列が Unicode に統一されたため、 zip ファイルを読み込むとファイル名がデコードされて文字列になって返ってきます。 が、もちろん日本語の慣習がデフォルトの挙動になってるわけではないので、このままでは文字化けしてしまいます。 Python 3.4 の zipfile モジュールを読むと次のようになっていました。 if flags & 0x800

    Python 3 で日本語ファイル名が入った zip ファイルを扱う - Qiita

  • Rubyist が pyenv を使うときに知っておいてほしいこと - Qiita

    はじめに 機械学習ブームなどにより、 Python を触り始める Rubyist が増えてきたと思います。その際に問題になりやすいのが環境構築です。Rubyだと rbenv がデファクトスタンダードになっているのに、なぜか Python には pyenv に否定的な意見が多いんですよね。 私は pyenv を使っていますし、便利だと思っています。また、 Ruby は殆ど使わないのですが、RubyとPythonのツールスタックの違いについても調べました。 (参考: gem, bundler と pip, venv の比較) その視点から、 Rubyユーザーが自分でpyenvの使い方を自分で決める上で知っておいた方が良いだろうなと思う Ruby と Python の環境の違いをまとめてみます。 tl;dr 丁寧に解説しても、「Python使うにはこんな長い記事を読まないといけないの」とすぐに否

    Rubyist が pyenv を使うときに知っておいてほしいこと - Qiita

  • Go が他の多くの言語での非同期プログラミングよりも優れている理由 - Qiita

    はじめに 非同期プログラミングと呼んでいるのは、ノンブロッキングIOと select, poll, epoll, kqueue のようなIO多重化を利用したネットワークアプリケーションを書くことです。 node.js で websocket 使ったチャットを書くとかそういうのです。 「他の多くの言語」とは、 Python (asyncio), node.js, C# などを想定しています。 Erlang や GHC なんかは Go に近いかも知れません。 async / await がない言語では、「コールバック地獄」や「deferred地獄」のような問題もありますがこの記事では扱っていません。 async / await のメリットを解説した他の記事を参照してください。 あとこの記事は主にランタイムに関する部分を扱っているので、「それは言語じゃなくて処理系の問題だ！」等の頓珍漢な揚げ足取

    Go が他の多くの言語での非同期プログラミングよりも優れている理由 - Qiita

  • [翻訳] Why Go? - Qiita

    (この記事は Dave Cheney さんの Why Go? の翻訳です。) 数週間前、友人に「Goに注目に値するのはなんで？」と聞かれました。 彼は私がGoに情熱を注いでいることを知っていましたが、なぜ私が他の人もGoを気にするべきだと思っているのかを知りたいようでした。 この記事は、私がGoを重要なプログラミング言語だと考える、3つの大きな理由を紹介します。 メモリ安全 個人としては、私もあなたもC言語でメモリリークも危険なメモリの再利用もしないプログラムを書く事ができるでしょう。しかし、40年以上の経験から、集団としてのプログラマーはC言語で信頼できるプログラムを書けない事がはっきりしています。 コードの静的解析、 valgrind, tsan (訳注: たぶん ThreadSanitizer), -Werror といったツールは10年以上前から使えますが、それらのツールが広く認知さ

    [翻訳] Why Go? - Qiita

  • Python 3の各種エンコーディングについて - Qiita

    Python 2 に比べるとずっと楽になったものの、環境によっては Python 3 で予期せぬ UnicodeError に遭遇することがあります。 Python 3.6 時点での、 Python の各種エンコーディングの扱いを整理してみます。 Python のエンコーディング filesystem encoding (sys.getfilesystemencoding()) 主にファイルパスに使うエンコーディングですが、コマンドライン引数にも使われます。 (そうでないとファイルパスをコマンドライン引数に渡したときに困る) また locale が関連するので、実際にはそれ以外にも glibc とかと連携するときに使われます。 Python 2 時代の名残りでしょうが、今では filesystem encoding というより system encoding と呼んだほうが実態を表している

    Python 3の各種エンコーディングについて - Qiita

  • FAQ: 数値の比較を is ですると一貫性がないのはなぜ？ - Qiita

    x と y は別々に作られた、別々のリストオブジェクトです。なので、 x is y は False になりますし、 x を変更しても y には影響しません。 一方、 z は x と同一のオブジェクトを参照しています。なので x is z は True になりますし、 x (が参照しているリストオブジェクト)を変更すると当然 z も同じように変化します。 整数型は immutable オブジェクトが示す値が、オブジェクトを生成したときに決まり、その後変化しないようなオブジェクトを immutable といいます。 整数は immutable です。次のサンプルコードを見てください。 y = x した直後は、 x と y は同じ 42 を表すオブジェクトを示しているので x is y は True でした。 x += 1 すると、 x には 43 を表す別のオブジェクトが代入されます。なので

    FAQ: 数値の比較を is ですると一貫性がないのはなぜ？ - Qiita

  • Python のリファクタリングでイケてないコードを別に美しいオブジェクト指向設計ではない普通のコードにする方法 - Qiita

    Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法 - その１ その2 その3 これを Python でやってみます 元のコード 元の Ruby 版をできるだけ真似してみます。テストは py.test を使います。 #ordersreport.py from collections import namedtuple Order = namedtuple("Order", "amount placed_at") class OrdersReport: def __init__(self, orders, start_date, end_date): self.orders = orders self.start_date = start_date self.end_date = end_date def total_sales_within

    Python のリファクタリングでイケてないコードを別に美しいオブジェクト指向設計ではない普通のコードにする方法 - Qiita

  • loggingについて話そう - Qiita

    この記事は Let’s talk about logging の翻訳です。 Nate Finch による Go Forum への投稿で始まったスレッド を見てこの記事を書くことにしました。 この記事は Go を対象にしていますが、あなたのいままでのやり方を振り返ってみたら、同じ考え方がより広く適用できると思います。 なんでこんなに足りないの？ 訳注: "Why no Love?" を、「（愛されてないから）機能が足りない」というニュアンスで解釈しましたが、自信が無いです。 Go の log パッケージ はレベル付きのロギングを提供していません。なので手動で debug, info, warn, error のようなプレフィックスを書く必要があります。 また、 Go はパッケージごとにログの出力レベルを制御する方法も提供していません。 比較対象としてサードパーティーのロギングライブラリを見て

    loggingについて話そう - Qiita

  • エラーを検査する - Qiita

    NOTE: この記事は Inspecting Errors を翻訳したものです。 原文に従い、 Creative Commons ライセンスで公開します。 error インターフェイス型の値を返す関数の一般的な契約は、呼び出し側はその error をチェックする前にそれ以外のいかなる戻り値も利用してはいけないというものです。 多くのケースにおいて、関数が返した error 値は呼び出し元にとって不透明であるべきです。 error が nil かどうかチェックすることで呼び出しが成功したかどうかを知ることができ、そしてそれ以上のことはしません。 少ないケースにおいて、主にネットワークなどプロセス外の世界とやりとりする場合に、呼び出し側がエラーの種別を調べて、操作をリトライするべきかどうかを決める必要があります。 パッケージ作者に対して、呼び出し側がエラーの型を判別して利用できるように返すエラ

    エラーを検査する - Qiita

  • Go 1.4 の環境構築 Homebrew + Vim 編 (2014.12) - Qiita

    Windows や Linux 向けのバイナリを作りたい場合は --cross-compile-common オプションを付けましょう。

    Go 1.4 の環境構築 Homebrew + Vim 編 (2014.12) - Qiita

  • Windows での Python 2.7, 3.4, 3.5 の拡張モジュールビルド環境 - Qiita

    Windows 用に Python のバイナリパッケージを作成するときに知っておいたほうがいい基礎知識や便利情報をまとめて書いていきます。 Windows でのバイナリパッケージの重要性について Windows 上で Python を使っているユーザーは、 Python の拡張モジュールをビルドする環境を持っている可能性はとても低いです。 もともと Mac に比べてコンパイラをインストールしているユーザーが少ない上に、 Mac 版では OS のバージョンごとにコンパイラが固定されるのに対して、 Windows では OS ではなく Python のバージョンによってコンパイラのバージョンが決まるという事情もあり、自分で調べて Python の開発環境を揃えている人以外が適切なコンパイラをセットアップしている可能性はゼロに近いです。 一方で Windows では python.org が提供

    Windows での Python 2.7, 3.4, 3.5 の拡張モジュールビルド環境 - Qiita
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.