カテゴリー: Python

Home / カテゴリー: Python

Pythonでバッチ書いてcronで実行させると死ぬ

2017-06-21 | Python | コメントはまだありません

今回の解決方法はこちら。
export PYTHONIOENCODING=UTF-8
bash_profileかなんかに書いとく
おわり。
以下おまけ。

UnicodeEncodeError: ‘ascii’ codec can’t encode characters in position 38-41: ordinal not in range(128)

こんなこといわれる。Python書いてるとどっかで必ずぶつかって唸るやつ。
内部エンコードが云々とかはやっとこ理解してきて、中ではunicode、外に出すとき初めてencodeして、とかいうあたりは馴染んできた。
今日悩んでいたのは、自分で叩くと問題なく実行できる、文字列の出力を伴うプログラム。
実行状況をコンソールで見たかったので、あちこちにprintがどかどか入っているもの。
なんとなくうまくいくようなので、じゃあcrontab(これがまあ前時代的とかはあるんだけどrundeckだろうと根っこは同じだ)にセットすると、これがうまくいかない。
文字列を出力するところでいつものやつがでていて死んでる。
どういうこっちゃ。あたしゃ毎日0:30にリモートログインして手で叩かないといけないのか。

結局どうも、シェルに諸々やらせるときには、エンコーディングについていい具合によろしくしてくれないので、わからんのでasciiでいいやと判断され、死ぬということがわかりました。
症状見ればそこまでは分かるんだけど、export LANG=ja_JP.UTF-8云々を書いてもうまくいかないし、なんなのと泣いていたところ、そういえばPYTHONIOENCODINGってあったよね何なのかよく知らんけどという着地をした次第。
新しくこさえたEC2に移行作業してるんですが、そういうまっさらのとこだと、設定の漏れがポコポコ出てくるんですね。
ansibleに追記して保存、一件落着。

参考りんく

Python 3の各種エンコーディングについて – Qiita http://qiita.com/methane/items/6e294ef5a1fad4afa843

Python2で文字列を処理する際の心掛け – Qiita http://qiita.com/FGtatsuro/items/cf178bc44ce7b068d233

FFXIVなんとかかんとか調査メモ

2015-02-15 | Final Fantasy XIV, Python | コメントはまだありません

とある何かの中身を調べております。
Itemテーブル
legacy=1は「✝」マークついてたり、英語名にDated(時代遅れの,旧式の)とついたりしている。旧FF14のアイテムなのかな。見るべきものではなさそう。

なんかもーすごいきちんとデータが整理されてて、データ眺めていて気持ちがいい。

ほんとは馬とったとかいろいろ書くことあるんだけど、作業楽しいので後回し。

Rarityが1~7くらいまであるぽ。7はエーテリアル装備かなあ。

仮想環境構築:Vagrant + Docker

2014-12-12 | Nginx, Python, 仮想環境, 要件とか | コメントはまだありません

Kindle版の本を買って、日々vagrantとdockerについての理解を深めようと努力する日々です。
実のところインフラなんて興味なかった。結線だルーティングだミドルウェアがどうしたこうした。
「ぼかぁもっとクリエイティブな(略」
と思ってたんだけど、クリエイティブな何かをつくろうとするときの用意がめんどくさすぎる。手前の準備が煩雑すぎて、プログラム書くとこまで到達できない。
Vagrantはそもそも職場での開発環境の用意がめんどくさいことに加え、手順が口伝というのを打破するにあたり提案されていたツールで、名前しか知らなかった。
VMでマシン作るときの自動化がこいつで出きると。たしかにVirtualBoxで一個マシン作るのも面倒だった。
で、Dockerをその上に云々
vms
こういうのをやりたい。ずいぶん余計なのも色々あるんですが、Webサーバ幾つかのログをfluentdがかき集め、それをkibanaとかでビビっと束ねた表示とかをしちゃいたい。
この記事、下書きのままずいぶん放置してたんですが、そろそろやんないと。

参考書籍:Vagrant

参考書籍:Docker

SQLAlchemyとSQLiteで日付を取り扱う

2014-06-28 | Python, SQLAlchemy | コメントはまだありません

あたくしの脳にぼんやりと刻まれている情報によれば、SQLiteは文字列と数値しか扱えないはず。
日付どうする。いやセンセ、日付ぐらいは扱ってくれてもいいのでは。
さておき、SQLAlchemyを通した場合に、なにか賢い仕組みがあるはず。

SQLAlchemyのマニュアルの当該ページには、

Date and Time Types

SQLite does not have built-in DATE, TIME, or DATETIME types, and pysqlite does not provide out of the box functionality for translating values between Python datetime objects and a SQLite-supported format. SQLAlchemy’s own DateTime and related types provide date formatting and parsing functionality when SQlite is used. The implementation classes are DATETIME, DATE and TIME. These types represent dates and times as ISO formatted strings, which also nicely support ordering. There’s no reliance on typical “libc” internals for these functions so historical dates are fully supported.

超訳:
SQLiteは日付型持ってない。SQLAlchemyが独自にこさえてる日付とかの型は、日付フォーマット+SQLiteで使った場合に動作するようになってる。その対象になってるのはDATETIME、DATEおよびTIMEだ。
これらを使う場合に限っては順番とかもちゃんと正しく動くし、ISOフォーマットされた文字列として日付と時刻を表現する。
で、こいつらはlibc内の関数に依存していないので、歴史的な日付が完全にサポートされている。

うわー自信ない。特に最後の一行。逆に読んでたらどうしよう。だって「libc非依存なのでヒストリカルデートが完全にサポートされてる」って、前後つながってる感がない。
だいたい、libcってなんだ。cのライブラリか。

ちょろっと見るとORACLE様の変なページが見つかり、「表 2–10 libc の日付と時間の処理関数」というところで以下の3つの関数の記述がある。

  • getdate() ユーザー形式の日付と時間を変換する
  • strftime() 日付と時間を文字列表現に変換する。
  • strptime() 日付と時間の変換

ははあ。こいつら完全にあたし見たことあるわ、phpで。phpのあの関数ってこいつらをラップしてたんだろか。
見てみる。
こんなページがあった。
PLEAC-PHP(http://pleac.sourceforge.net/pleac_php/datesandtimes.html)

これによると、phpはいろんな方法で日付のサポートをしていて、

  • UNIX/Cライブラリベース
    (localtime, gmtime, strftime, strptime, mktime, time, getdate, gettimeofday)
  • PHPのネイティブ関数(date,strtotime)
  • DateTimeクラスベース

日付の扱い方にこういう種類があるんだよ、とある。
phpのstrftimeとかははラッパーだったんだー、いやそういう感じのことなんだろうなとは思っていたがちゃんと理解した。
Library [libc]-based routinesってことは、Cのライブラリってのがlibcってことでいいんだな。なので、SQLAlchemy+SQLiteにおきましては、こいつらには関係ない作りになってます。ってことですね。
いやー勉強になりました。

Pyramidのわだい。
SQLAlchemyがいじわるな子になっている件。
掲題のエラーが出るんですよ。

全体感としては、
models.mymodel.pyの中で

Base = declarative_base()
MyModel(Base)

こう。MyModelクラスを切っておき、他のファイルの各モデルクラスがMyModelを継承するというかんじ。
models.employee.pyには

class Employee(MyModel):

こういうのがいますという形。
なんてことないというか、以前これで普通に使えていたはずなんだけどナーというところですが
sqlalchemy.exc.NoForeignKeysError: Can’t find any foreign key relationships between ‘models’ and ‘employee’.

むむむ。なんだよ。リレーションなんて張らないよ。継承元でしかないんだけどどういうことなの。

手当たり次第にぐぐります。

そして発見

if you want your NewBase to be a descendant of Base, then you’d need to put __abstract__=True on it. But if these cols are global to everyone you could make it the superclass of your declarative Base also by passing it as “class_” to declarative_base().
the naming conventions recipe is another way to go too.

新しいBase(たぶんdeclarative_baseのことなんだろう)を使うときは、__abstract__を使ってみてとある。
なんすかそれは。
入れてみますと、これが当たりでした。

こうするとよいということですね。

class MyModel(Base):
    __tablename__ = 'models'
    __abstract__=True
    id       = Column(Integer, primary_key=True)
    status   = Column(Integer, default=1)
    created  = Column(DateTime, default=datetime.datetime.now)
    updated  = Column(DateTime, default=datetime.datetime.now)

    def __init__(self, name, value):
        self.name = name

あ、えーとPEP8違反(=の両脇にスペースたくさん入れるのNG)の記述になってます。すいません。
PyCharmもあまりにこれガミガミ言うんで警告出さないようにしちゃった。すいません。
=の位置が揃ってないと気持ち悪いんだよ。