知らなかったけど Python 2.6 から format メソッドが使えるんだね。
3.0 系だけだと今まで思っていたよ、IronPython 2.6 も同様。
"{0}: {1}+{2}={3}".format("calc", 1, 2, 1+2)
"%s: %d+%d=%d" % ("calc", 1, 2, 1+2)
のように値に対する書式指定がいらない、くらいしかメリットは無いけど。
引数の順番が変更できたり同一の値を参照…なんてやる人少ないだろうし。
少なくとも C# からプログラミングに入った人なら判りやすいのではないかと。
今は「どっちでもいい」なので好きなほうで書けばいいわけだ。
ただ書き方ごときにあーだこーだなら Ru…（以下略
しかし春の陽気のせいかヤル気が出ない…
Y901w はもう現行 Cinema のまんまでいいじゃないかとか…
とはいえ今になってコードを見ると自身で寒いので全部書き直したいし…
なんんてやっていたら全然進まねぇや、そろそろ Windows 用を何か作らないと干されそう。
Python という言語は関数のオーバーロードができない。
何って、つまり引数が違うだけで同じ関数名を利用する多重定義のことである。
慣れると関数やメソッド量を少しでも減らそうとよく利用するようになる。
だからといっていくつも別名の関数を用意するのは効率が悪い。
結果似たようなことができるデフォルト引数を利用するようになるわけだ。
ん、そういえば C++ や C# もデフォルト引数って使えたよな。
色々な言語を行ったり来たりしている私は同じように書いたほうがいいのでは？
それにデフォルト引数のほうがコードの記述量が減らせるメリットがある。
コンパイル後の機械語では似たような結果になるのだろうけど…
コードが短くできるのは魅力なので C++ や C# でもデフォルト引数をなるべくやろう。
オーバーロードはよく使うから覚えているけどデフォルト引数は C++ でどう書くの。
一つの cpp 内での書き方なら簡単に見つかる、Python とまったく同じか。
けど別ファイルにするには？
やってみた。
Tool.h
#pragma once extern int messagebox(HWND hWnd, LPCWSTR msg, LONG button=MB_OK, LONG icon=MB_ICONEXCLAMATION);
Tool.cpp
#include "StdAfx.h"
#include "Tool.h"
#define MSG_TITLE L"確認 - Y901w"
int messagebox(HWND hWnd, LPCWSTR msg, LONG button, LONG icon)
{
return MessageBox(hWnd, msg, MSG_TITLE, button | icon | MB_SYSTEMMODAL);
}
を用意してメインウインドウで使ってみる。
#include "Tool.h" //略 messagebox(hWnd, L"ウニコード", MB_OKCANCEL);
extern 宣言で使う場合は extern 宣言のほうにだけデフォルトを書けばいいようだ。
本当は名前空間か class で static にするほうがイイと思うけどコレが一番簡単。
Python のように自作関数は小文字と掟を作っておけば間違えることも無いだろう。
しかし今になって昔のコードを見るとメンバ変数に m_ を付けていないとかで迷う。
自分が書いたコードなのに似たような変数名をローカル変数にしていたら迷ってしかたがない。
だから m_ プリフィクスみたいな書き方を推奨しているのね、そうなることが解っているから。
Python の self 強制って実はありがたいと思った、C++ も this 強制でいいくらいだ。
Linux でホームに作成されるデフォルトディレクトリ名は
~/.config/user-dirs.dirs
で指定及び確認ができることは大半の人が知っているだろう。
自分の都合で名前変更しても自動で追従する嬉しいのか迷惑なのかよく解らな（以下略
Windows も準拠してくれれば嬉しいのに…
というのは置いておいて英語表記のデフォルト名は
/etc/xdg/user-dirs.defaults
で私が知るかぎりでは確認できます、全部の Linux がそうなのかは知りません。
ということで。
アプリを自分で作るとデフォルトディレクトリ名を探したくなる場合がある。
自身が使う範囲のみであれば決め打ちでいいけど公開する場合は考える必要がある。
user-dirs.dirs を自己解析すればとも思うけどこの位置さえ決め打ちでいいのだろうか？
画像関連アプリで画像ファイルを保存しているだろう場所を指定みたいなくらいしか（以下略
glib に get_user_special_dir なんてメソッドがある。
コレを使えば PyGtk の GUI アプリでユーザー指定のディレクトリが見つけられそうだ。
get_user_cache_dir メソッドも後々で使いそうだし覚えておいたほうがいいかなと。
#!/usr/bin/env python
#-*- coding:utf-8 -*-
import glib
xdg_default = (
"Desktop",
"Documents",
"Download",
"Music",
"Pictures",
"Public",
"Templates",
"Videos"
)
user_conf = (
glib.USER_DIRECTORY_DESKTOP,
glib.USER_DIRECTORY_DOCUMENTS,
glib.USER_DIRECTORY_DOWNLOAD,
glib.USER_DIRECTORY_MUSIC,
glib.USER_DIRECTORY_PICTURES,
glib.USER_DIRECTORY_PUBLIC_SHARE,
glib.USER_DIRECTORY_TEMPLATES,
glib.USER_DIRECTORY_VIDEOS
)
for i in range(len(xdg_default)):
print "%s: %s" % (xdg_default[i], glib.get_user_special_dir(user_conf[i]))
うん、これでいいんじゃない。
とにかくコレでフルパスが得られるので処理が簡単。
自身で何も指定していないなら None が戻るので処理が簡単。
よし、これで Y901x の初期選択ディレクトリを（理由はソレかい…
私が付けている名前を晒しているけど気にしない
動画の保存先名デフォルトは Videos より Movies のほうがイイと思うんだけどなぁ…
Glade の覚書がちっとも進まない。
やっぱり普段使わないものの覚書って無理があるかも。
ということで Blog でやった IronPython ネタを地味にまとめている。
つまりほとんどコピペ、でコードが IronPython 2.6 でキチンと動くか確認してみたんだが
IronPython の \n が CR/LF になるんだが…
以前は LF のみだったような気がするんだけど違ったかな。
追記
まてよ、もしかして System.IO と組み込み open では扱いが違うのかな？
というより IronPython では内部で \n はどう保持されているんだろう？
気になったのでテストコードを作って試してみた。
# -*- coding: UTF-8 -*-
import System
crlf_test = "a\nb"
# Inside is \n==LF
bytes = System.Text.Encoding.UTF8.GetBytes(crlf_test)
for i in range(len(bytes)):
print bytes[i]
# The following code is \n==LF write
sr = System.IO.StreamWriter("test1.txt")
sr.Write(crlf_test)
sr.Close()
# The following code is \n==CR/LF write
f = open("test2.txt", "w")
f.write(crlf_test)
f.close()
やはり open() で書き込む時にのみ LF を CR/LF に変換しているようで。
標準 Python モジュールの関係あたりで CPython に無理やり合わせたのだろうと憶測。
以前は LF のみだったような気がしたのはコレに気が付かなかっただけかな。
ついでだから C# での内部も一応探ってみる。
using System;
class Program
{
static void Main(string[] args)
{
System.Byte[] bytes = System.Text.Encoding.UTF8.GetBytes("a\nb");
foreach(System.Byte b in bytes)
{
Console.WriteLine(b);
}
}
}
当然のように LF に、つまり .NET Framework なら内部では cli 仕様の \n==LF である。
注意しておかないとハマるかも。
覚書ページの整理が全然進まない。
PyGtk はどの順番で widget 解説を進めるか考えると頭がおかしくなりそう。
TreeView や TextView の前に Scrollbar や Scale の前に Adjustments の知識が必要で…
それより、もう使わなくなった Glade 関連の解説なんかはどうしようかと。
なんたって今では普通 libglade ではなく GtkBuilder を選ぶだろうし。
最初の GUI アプリ作りのとっかかりは Glade ほど解りやすいものは無いだろうし。
いやまてよ。
C 言語から Glade を使う方法てか GTK+ コンパイル方法も併記すればいいんでない。
なんたってソレは私自身もやったことがないので勉強にもなる。
よし Mandriva One に Glade や GTK+ ヘッダをインストールしてみよう。
C でやるには別途でコンパイラの他に GTK+ ヘッダを入れる必要があるんだよね。
Ubuntu での需要ばかりだろうから Ubuntu には後で入れる。
libgtk+2.0_0-devel を導入。
依存関係で他のパッケージも沢山インストールされるが気にしない。
devhelp も導入。
/usr/share/gtk-doc 以下の doc はコレで見られるようになる。
libgtk+ を入れた後はこんな感じになる。
glade も一応入れてと。
んで海外からチュートリアルを探してみたら強烈なとこを見つけた。
GTK+ and Glade3 GUI Programming Tutorial – Part 3
とにかく tutorial.xml を落とし C コードをコピペしてコンパイルしてみる。
普通にコンパイルが通って動かせた。
ふむふむ、C から Glade ファイルを使うにはこうすればいいのか。
しかしこんなトコを見た後では何を書くのも気後れするわ。
でもコンパイルオプションが長くてメンドクセ！
メモリの解放処理をいちいち書かなければいけないのがメンドクセ！
つーかメソッドではなく関数を使うのがメンドクセ！
PyGtk がどれほど楽チンなのか改めて思い知る。