Python」タグアーカイブ

Python subprocess

何を今更だけど os.system や os.popen はもう「使うな!」なんだね。
17.1. subprocess ? サブプロセス管理 ? Python 2.7ja1 documentation

それどころか Python3 には commands が無い。
subprocess の使いかたを覚えておかなければ。

# command

import os
import subprocess

#os.system("gvfs-open hoge.txt")
subprocess.call(["gvfs-open", "hoge.txt"])

# With spaces in the file names
#os.system('gvfs-open "on space.txt"')
subprocess.call(["gvfs-open", "on space.txt"])

引数の最初が args だから list に全部入れなきゃだめってことみたい。
ファイル名にスペースがある場合に楽になった、ような…

それからえっと
os.system(“gedit &”)
みたいなバックグラウンド実行はどうするのかな。

# Background

#subprocess.call(["gedit", "&"]) # Error
subprocess.Popen(["gedit"])

Popen を選ぶだけみたい、ふむふむ。

でコマンドのアウトプットを得るには

# Get Output

#output = os.popen("pwd").read()
#output = commands.getoutput("pwd")
output = subprocess.check_output(["pwd"])

なるほど。

ということでこんなページを作ってみた。
Python Tips – L’Isola di Niente

でも結局 GLib を使ったほうが楽だったりして。
全部 Python でやることにこだわるなんて正直アホみたい。

from gi.repository import GLib

# Execute
GLib.spawn_command_line_async("gvfs-open hoge.txt")
# Get Output
result, output, error, status = GLib.spawn_command_line_sync("ls -l")
print output

Gtk+ DataBinding

明日から仕事始めなのでと覚書ページ書き換えラストスパート。
GtkSwitch を試していて困った。

GtkSwitch

activate シグナルがあるけど connect しても発行されない。
but use the notify::active signal.
なんて書いてあるから当然なんだけど、どう使うの?
さて今日も英語と格闘が始まるな。

Short Example of GSettings Bindings with Python using a Gtk Switch ? Mariano Chavero

なるほど、こうやって使うのか。
GNOME3 環境の人しか実験できないサンプルだけど on off でデスクトップアイコンの表示切り替えができるのを確認した。
しかも dconf-editor で切り替えたら GtkSwitch も切り替わる双方向。

つまり Widget のプロパティと GSettings はバインディングできるんだね。
それなら Widget 同士でもやれそうだと思ったので調べてみる。
というか GSettings のサンプルだと GNOME3 以外を使っている人には解らないし。

GBinding

g_object_bind_property という関数で Widget 同士のバインドもできそう。
PyGI で GObject.Binding 内を探すが見当たらない。

GObject-2.0 Python API Documentation

うーんココには有ると書いているんだけど。
って URL をよく見たら ubuntu-12.10 だ、つまり Fedora17 より新しい。
仮想 Ubuntu 12.10 を立ち上げ dir してみる。

bind_property

あぁやっぱり。
しかたがない、今は仮想 Ubuntu 上で試してみるか。

#!/usr/bin/env python
#-*- coding:utf-8 -*-

"""
    Widget Property Binding Sample
"""

from gi.repository import GObject, Gtk

switch = Gtk.Switch()
check = Gtk.CheckButton("Check")
GObject.Binding.bind_property(
        switch, "active",
        check, "active",
        GObject.BindingFlags.BIDIRECTIONAL )

hbox = Gtk.Box.new(Gtk.Orientation.HORIZONTAL, 0)
hbox.pack_start(switch, False, False, 0)
hbox.pack_start(check, False, False, 0)

w = Gtk.Window()
w.add(hbox)
w.connect("delete-event", Gtk.main_quit)
w.show_all()
Gtk.main()

widget_property_binding

GBindingFlags は
GObject.BindingFlags.DEFAULT では source 側からの一方向バインド。
GObject.BindingFlags.BIDIRECTIONAL で双方向になる。
他2つはよく解らない、上記2つあれば充分だし。

こんな感じでデータと GUI を結びつければ面白くなるね。
WPF の ObservableCollection みたくできるかも、アレは混乱の元だが。

しかし早く fedora 18 出ないか、今日サイトを見たら又伸びているんだが…

Vala GTK+ (GError)

前回の GTK+ コードでコンパイル時に WARNING が出ていた件が解決した。
valac はオプションに -C を入れるとコンパイル前に C 言語に変換されたソースコードを吐き出す。
コレを利用してどのように変換されたかを調べる。

private void on_clicked(Button button) {
    var f = File.new_for_path("gtk.txt");
    var fstream = f.replace(null, false, FileCreateFlags.NONE);
# valac -C --pkg gtk+-3.0 hoge.vala
static void win_on_clicked (Win* self, GtkButton* button) {
	GFile* _tmp0_ = NULL;
	GFile* f;
	GFileOutputStream* _tmp2_ = NULL;
	GFileOutputStream* fstream;

	GError * _inner_error_ = NULL;
	g_return_if_fail (self != NULL);
	g_return_if_fail (button != NULL);
	_tmp0_ = g_file_new_for_path ("gtk.txt");
	f = _tmp0_;
	_tmp1_ = f;
	_tmp2_ = g_file_replace (_tmp1_, NULL, FALSE, G_FILE_CREATE_NONE, NULL, &_inner_error_);
	fstream = _tmp2_;
	if (_inner_error_ != NULL) {
		_g_object_unref0 (f);
		g_critical ("file %s: line %d: uncaught error: %s (%s, %d)", __FILE__, __LINE__, _inner_error_->message, g_quark_to_string (_inner_error_->domain), _inner_error_->code);
		g_clear_error (&_inner_error_);
		return;
    }

どうやら GError にてチェックを行う関数はすべて確認コードを生成するようである。
ところが Vala で書く場合は GError を ref で入れることができない。
このような場合 try,catch 文にすれば GError が渡ってくるようだ。

private void on_clicked(Button button) {

    File f;
    FileOutputStream fstream;
    DataOutputStream dstream;
    
    f = File.new_for_path("gtk.txt");
    try {
        fstream = f.replace(null, false, FileCreateFlags.NONE);
    } catch (Error e) {
        stderr.printf ("Error: %s\n", e.message);
        return;
    }
    dstream = new DataOutputStream(fstream);
    try {
        dstream.put_string(entry.get_text());
    } catch (IOError e) {
         stderr.printf ("Error: %s\n", e.message);
         return;
    }
}

ついでに解ったけど FileOutputStream は関数を抜けると勝手に close される。

エラーなんて絶対に起こらないし厳密すぎだしこんなの面倒くさいよ!
という場合は以下みたいな超手抜きコードでイケる。

private void on_clicked() {
    try {
        var f = File.new_for_path("gtk.txt");
        var fstream = f.replace(null, false, FileCreateFlags.NONE);
        var dstream = new DataOutputStream(fstream);
        dstream.put_string(entry.get_text());
    } catch {
    }
}

前回のコードの on_clicked 関数をこう書き換えれば確認できる。
これで WARNING とはおさらば。

それとせっかく GTK+ を使うのに printf は無いだろう。
やはりココはエラーメッセージをダイアログで出したい。
C# からの乗り換えでは MessageBox.Show() を使いたい。
ということで簡易なものを作ってみた。

using Gtk;

public class MessageBox {
    public static ResponseType Show (string text) {
        var dlg = new MessageDialog(
                null,
                DialogFlags.MODAL,
                MessageType.WARNING,
                ButtonsType.OK,
                text );
        dlg.set_title("TitleBar");  
        var res = dlg.run();
        dlg.destroy();
        return (ResponseType)res;
    }
}

public static int main (string[] args) {
    Gtk.init(ref args);   
    MessageBox.Show("MessageBox.Show Test");
    return 0;
}

やはり PyGI で書くのとほとんど変わらない。
var と new と中括弧とセミコロン、他少々書くことが増えただけ。
ちなみに Python ではこんな感じ。

#!/usr/bin/env python
#-*- coding:utf-8 -*-

from gi.repository import Gtk

class MessageBox:
    @staticmethod
    def Show (text):
        dlg = Gtk.MessageDialog(
                None,
                Gtk.DialogFlags.MODAL,
                Gtk.MessageType.WARNING,
                Gtk.ButtonsType.OK,
                text );
        dlg.set_title("TitleBar")
        res = dlg.run()
        dlg.destroy()
        return res

if __name__ == '__main__':  
    MessageBox.Show("MessageBox.Show Test");

まあコンパイルするわけだから実行速度的には Python を圧倒するわけだ。
こんな PyGI で書いているのとほとんど同じ感覚で C 言語で作られたのと同様な実効速度を持つアプリケーションが生成できるなのならば、それはとっても嬉しいなって。

Linux Python 3

そろそろ Python を 3 に移行しようと思う。
はて、日本語はどうなるのだろう?
Linux ではまったく使っていなかったから解らない。

Gio Tips – L’Isola di Niente

多分組み込みの open() 関数はツジツマを合わせていると思う。
GIO での読み書きはどうなるやら、実験。

# Write and Length Check
s = '日本語'
f = open('test.txt', 'w')
f.write('{0}\n{1}'.format(len(s), s))
f.close()

# g_file_load_contents
from gi.repository import Gio
gfile = Gio.File.new_for_path('test.txt')
res = gfile.load_contents(None)
print(res)

# Streaming I/O
fstream = gfile.read(None)
dstream = Gio.DataInputStream.new(fstream)
print(dstream.read_line_utf8(None))
print(dstream.read_line_utf8(None))
fstream.close(None)

うん、文字列はシッカリ gunichar(UCS-4) だね。
やはり組み込み関数は仕事キッチリか。

g_file_load_contents だと、、、バイナリ扱いになってしまった。
読み込んでも UTF-8 のままで保持するということみたい。
文字列の読み書きに利用するなということなのだろう。

Streaming I/O では文字列自体は UCS-4 化するみたいだけど文字列長は UTF-8 バイナリでカウントしている。
試しに dstream.read_Line(None) に書き換えたら予想通り文字列がバイナリに。
GFileOutputStream は UCS-4 の文字列を普通に UTF-8 として書き込みできた。

うーん、やはり文字列が UCS-4 だと扱い辛いぞ。

GTK+ の GtkEntry の文字列はどうなるんだろう?

#!/usr/bin/env python3
#-*- coding:utf-8 -*-
 
from gi.repository import Gtk
 
class Win(Gtk.Window):
    def __init__(self):
        Gtk.Window.__init__(self)
        self.set_title('たいとるばぁ')
        self.connect('delete-event', Gtk.main_quit)
        self.entry = Gtk.Entry()
        button = Gtk.Button('保存')
        button.connect('clicked', self.on_clicked)
        vbox = Gtk.VBox()
        vbox.pack_start(self.entry, False, False, 0)
        vbox.pack_start(button, False, False, 0)
        self.add(vbox)
        self.show_all()
 
    def on_clicked(self, widget, data=None):
        f = open('gtk.txt', 'w')
        f.write(self.entry.get_text())
        f.close()
 
if __name__ == '__main__':
    w = Win()
    Gtk.main()

タイトルバー等の文字列も GtkEntry とのやりとりも UCS-4 の内部文字列のままでイケてしまうようである。
GIO で文字列を扱う場合以外は Python2 時と同様に使えると思ってよさそう。
なんて思っていたら落とし穴がありそうだが…

もう少し検証したいけど Boxes 上の Ubuntu では辛い。
「クリップボードを共有」を ON にしているのに何故かホストと共有できなくて面倒くさいぞコノヤロウ。
Fedora に入れたいけどデフォルトで使えるコードというポリシーに反するし。
18 にはデフォルトで入るみたいだが β すらまだ出ていない。

ちなみに本サイトのメール送信フォームを利用して文字列のやりとりというバカなことをやっていたりする、サイトを作っておくと便利だよ。

Gst 1.0

Novacut/GStreamer1.0 – Ubuntu Wiki
~jderose/+junk/gst-examples : contents of video-player-1.0 at revision 72

こんなページを見つけた。
これでやっと Y901x の GTK3 化に進歩が…

GStreamer 1.0 用だった。
つーか今まで 1.0 パッケージが公開されたことを知らなかったという…
バージョンは 0.11 のようですけど、0.10 と共存可能らしい。

PPA for GStreamer developers : “GStreamer developers” team

Fedora 17 にデフォルトで入っている GStreamer は 0.10 だ。
0.10 用のサンプルは PyGtk コードのまま。

~jderose/+junk/gst-examples : contents of video-player-0.10 at revision 72

でも 1.0 のコードを 0.10 に書き換えすれば動くかも。
よく見たら Python も Python3 じゃないの、とにかくコピペして書き換え。

#!/usr/bin/env python
#-*- coding:utf-8 -*-

# python2

from os import path

import gi
gi.require_version('Gst', '0.10') #'1.0')
from gi.repository import GObject, Gst, Gtk

# copy...

on_sync_message がやはり発行されない…
ということは on_message を作っても msg は空のまま。
0.10 のバインディングは Fedora 15 時と何も変わっていないということみたい。

このアプリを試すためだけに GStreamer 1.0 を導入してくれ。
なんて言えないよ、てか私も今は入れたくないし。

Fedora や Ubuntu の次期版次第だ、とりあえず覚書ということで。

しかしサンプルコードが Python3 なのも気になる。
実用では見向きもされないままで Linux ではガン無視されている Python3 は失敗作ということで Winamp のごとく Python5 が出るとばかり思っていたのだが。

とにかく文字列が Unicode だと local が utf-8 の Linux では都合が悪すぎ。
とずっと思っていたけど前回 gunichar が ucs-4 だと気がついたっけ。
検索してみる。

DSAS開発者の部屋:Python2.x/3.0のunicode内部表現について

あれ、Fedora の Python って u’str’ は UCS-4 だということなの?
おいおい、私みたいに勘違いしていた人って多くないか?
ならば端末からチト試してみよう。

普通に u” のままで日本語出力ができた、なんじゃこりゃ!
と思ったけど format で成形すると駄目。
ついでにスクリプトファイルにすると直 stdout も駄目になる。

ならばスクリプトを ucs-4 で保存、、、スルーされてしまった。
まあ ucs-4 でスクリプトを保存する人はいないし変換すればいいだけ。
まあとにかくそういう動作をするようだ。

うん、そういうことなら Python3 でも別にいいかなと。
でもデフォルトで入るようになるまで手を出したくない。
「このコードを試すためだけに Python3 を入れてくれ」なんて嫌だよね。