pip の constraints の正しい用途 - Qiita
$ pip install -r requirements.txt $ pip install flask Collecting flask Downloading Flask-0.12.2-py2.py3-none-any.whl (83kB) 100% |████████████████████████████████| 92kB 3.7MB/s Collecting Jinja2>=2.4 (from flask) Using cached Jinja2-2.10-py2.py3-none-any.whl Collecting click>=2.0 (from flask) Downloading click-6.7-py2.py3-none-any.whl (71kB) 100% |████████████████████████████████| 71kB 3.8MB/s ...
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
Github issue で質問してはいけない - Qiita
この記事は個人ブログで海外向けに書きかけの記事の日本語版です。そのため、一部日本人向けではない記述が含まれます。 英語版はこちらです Why you must not ask questions on Github issues 現在は GitHub は Discussions を提供しています。 Issue Template から Discussion へと誘導するのがおすすめです。 2023-06-14 追記 TL;DR: Issue Tracker で質問するのは開発者に対する DoS 攻撃になるかもしれない。 Forum がある場合は Issue Tracker で質問してはいけない。 背景 Github の時代になる前は、ある程度の規模のOSSプロジェクトはみんな Issue Tracker と別に フォーラム (BBS, ML など) を持っていました。ユーザーはフォーラムでデ
すごく簡単なアルゴリズムがphpで書けなくてつらい - Qiita
ある条件でソートされているIDのリストを与えられて、なんとなく近い範囲でマッチングさせたいという要件があった。配列からの任意の要素の取り出しは O(n) だけど、末尾や末尾から固定した範囲の要素に限って言えば O(1) なので、後ろの方からマッチングさせながら要素を取り出していけば O(n) でマッチングできるはず。 なんにも難しいことは無い話で、 Python で書けばこうなる。 list.pop() が末尾からのインデックス (-1 が最後の要素を表す) を許すのが地味に便利だ。 # coding: utf-8 def match(seq, r=100): from random import randint # 奇数個の時に先頭周辺の要素がボッチになるのが嫌なら、先に後ろの方の # 要素を取り除いて偶数にしておくこと. while len(seq) >= 2: # 引数を省略すると末
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
