リスト、タプル、辞書の中身を可変長引数に渡す

python3 可変長引数 - Qiita

list, tuple, dictの中身を可変長引数に渡すには変数の前に*, **を付ける。

def a(*args):
    print(args)
    
def b(**kwargs)
    print(kwargs)

list  = [1,2,3]
tuple = (1,2,3)
dict  = {'a':1, 'b':2, 'c':3 }

a(*list)    # (1, 2, 3)
a(*tuple)   # (1, 2, 3)
b(**dict)   # {'a': 1, 'c': 3, 'b': 2}

a(list)     # ([1, 2, 3],)
a(tuple)    # ((1, 2, 3),)
b(dict)     # TypeError: b() takes 0 positional arguments but 1 was given
b(kwargs=dict) # {'kwargs': {'a': 1, 'c': 3, 'b': 2}}

xmlを整形を出力する

テキストとして出力はできる、が整形されてない。

import xml.etree.ElementTree as ET

xml = ET.fromstring(xml_string)
xml_string = ET.tostring(xml, encoding='utf-8').decode('utf-8')

これを整形出力する。

import xml.dom.minidom

xml = xml.dom.minidom.parseString(xml_string) # or xml.dom.minidom.parse(xml_fname)
pretty_xml_as_string = xml.toprettyxml()

Pretty printing XML in Python - Stack Overflow

セグメントエラーのデバッグ

コンパイルオプション -g を追加してコンパイル

$ gcc test.c -g -o test

生成するコアダンプのリミットを無制限にする

$ ulimit -c unlimited

確認
$ cat /proc/%%プロセスID%%/limits

再現させる。

$ ./test
セグメンテーション違反です (core dumped)

コアダンプファイル(core.%%プロセスID%%)が生成される。 ※emacs上のshellだと作成されない(か他の場所に出来る?)

$ ls core*
core.26253

gdbで発生場所を確認する。

$ gdb test core.26253
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
....
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/i686/cmov/librt.so.1...done.
Loaded symbols for /lib/i686/cmov/librt.so.1
....
Loaded symbols for /usr/lib/gtk-2.0/2.10.0/engines/libcrux-engine.so
Core was generated by `./test'.
Program terminated with signal 11, Segmentation fault.
[New process 26253]
[New process 26274]
[New process 26272]
#0  0x080594da in Common::AppWindow::CheckIdleTimer (this=0x8091cc0)
    at ../raspi_tools2/fwgtk2/AppWindow.h:331
331       if (e->enable) {

後は直すだけ。

稼働中のプロセスにcoreを吐かせるのは

$ gcore %%プロセスID%%

参考

markdownでの改行

段落は空行によって分けられる。

改行は行末に2つのスペースを挿入すれば改行扱いになる。

引用内でも同じで、通常の改行が無視されるので代わりに2つのスペースを使う。

参考:

python3のzipfileで日本語ファイルの文字化け

python3/Windows7の環境で、zipfile標準ライブラリを使って日本語ファイルを圧縮したらファイル名が文字化けした。

調べたら理由が2つ。

  1. zipfileの仕様で強制的にファイル名がUTF-8エンコードされる
  2. Windows7の初期状態ではファイル名がShift-JIS(CP932)以外でエンコードされていると文字化けする

なのでUTF-8エンコードされたファイル名があると文字化けしちゃう。

簡単なのは、2.の問題を解決し、UTF-8のファイル名を扱える様にするのが早い。

Microsoftのパッチ。

参照:

1.を解決するには標準ライブラリを書き換えエンコードを変える、という荒業でも対処できるが...。

逆にShift-JISでエンコードされたZIPを解凍するとき

結論的には扱わない方が良さそう。

zipfile標準ライブラリを書き換える方法で対処している。が、予めファイル名のエンコードを知っている必要があるわけで...。

その辺も考慮して作り込む覚悟がないので扱わないこととする。

またはtar.gzへ切り替えるか。

余談

python2系なら解決できる

つまり原因は...。

誤った正規化

ZipFile.__init__でファイル名のバイト列中にある文字、os.sepをスラッシュに正規化している。この処理でsjisの2バイト文字のバックスラッシュがWindowsのパス区切りと誤認されて全てスラッシュに置き換えられてしまう。結果、解凍されるフォルダ名が文字化けする。

os.makedirsの誤った分割

zipfile.ZipFile.extractは内部でos.makedirs(unixでいうmake-pのような関数)を呼び出す。この関数は、パス文字列をos.sepで分割して、未だ存在しないフォルダを作成していく。このとき、1.で正規化されたパス文字列が/で分割され、誤ったパスでディレクトリが作成されていく。

ということらしい。

実はWindowsカーネルではUnicode

わざわざSJISへ変換してる(恐らく下位互換のため)

インターネット上で「Windows のファイル名の文字コードSJIS が使用される」という情報が散見されますが、正確には、Windows2000, WindowsXP などの NT 系 Windows カーネルでは、Windows カーネル内部では、ファイル名は全て Unicode で扱われており、状況によって SJIS への変換が行われます。

中略。

ファイル圧縮ツールを使用する場合  
(1) NTFS ファイルシステム上のファイルを Windows のファイル圧縮ツール(zip, lha など)で圧縮ファイルにまとめると、Windows カーネルは、ファイル名を Unicode -> SJIS 変換してファイル圧縮ツールに渡し、ファイル圧縮ツールは、SJIS のファイル名で圧縮ファイル内に保存します。  
 
(2) (1) の圧縮ファイルを NTFS ファイルシステム上に解凍すると、ファイル圧縮ツールSJIS のファイル名でファイルを展開し、Windows カーネルは、ファイル名を SJIS -> Unicode 変換して、NTFS ファイルシステムに保存します。  
 
⇒ この時、ファイル名に SJIS に存在しない文字があると、圧縮・解凍時の文字コード変換がうまくできないため、エラーが発生したり、解凍するとファイル名に文字化けが発生したりすることがあります。  
 
(3) (1) の圧縮ファイルを Linux に持っていき、Linux 上のツールで解凍すると、(Linux 上のツール文字コード変換機能を持たない場合)Linux 上のツールは、SJIS のファイル名のままでファイルを解凍して、ファイルシステムに保存します。  
 
⇒ この時、Linux の端末の文字コード設定が SJIS 以外の場合、端末上でファイル名に文字化けが発生します。