Python3 のクラス属性はcopy-on-writeでインスタンス属性になるのか？(そうではなくshadow-on-assignというそうです)

2023年6月11日、色々と調べてくださった方の情報を追記しました。それをみてもらえれば「copy-on-write」というのはやはり的外れでした。ので、タイトルも若干修正。
(2023年6月17日。「shadow-on-assign」はChatGPT命名だそうです→ https://twitter.com/sumim/status/1667680973960654849 )

 オライリーの 入門Python3 (分厚い奴ね:-)と以下の記事を見て？？？と思ったので実験。

記事: Python クラス変数 と インスタンス変数 の違い https://aiacademy.jp/media/?p=922

テストしたコードはこれ。

class Z:
    y = 'a'

a = Z()
b = Z()
print(f"Z.y = {Z.y}")
print(f"a.y = {a.y}")
print(f"b.y = {b.y}")

a.y = 'x'
print(f"Z.y = {Z.y}")
print(f"a.y = {a.y}")
print(f"b.y = {b.y}")

Z.y = 'q'
print(f"Z.y = {Z.y}")
print(f"a.y = {a.y}")
print(f"b.y = {b.y}")

a.__class__.y = 'r'
print(f"Z.y = {Z.y}")
print(f"a.y = {a.y}")
print(f"b.y = {b.y}")

実行した結果。

Z.y = a
a.y = a
b.y = a
Z.y = a
a.y = x
b.y = a
Z.y = q
a.y = x
b.y = q
Z.y = r
a.y = x
b.y = r

つまり、クラス属性はインスタンス生成時には、そのインスタンスはクラス属性を共有しているが、その値を変更(write)する際には、インスタンス属性としてcopy-on-writeするということでしょうかねぇ。。。

ちょっとcopy-on-writeのところって、分かりにくくないか？。むしろ上記の例なら「a.y = 」で書き換えるのをエラーか何かにしてしまった方がいいんじゃないだろうか？。

勿論、言語の設計はその言語の設計者の自由なんだけど。なんか、これでうっかりして挙動に頭を抱えている人がいないか心配してしまった:-)

Twitterにおける新たな削除機能の提案 (既投稿ツイートの編集機能よりもマシな手法として) / Proposal of a new deletion function on Twitter (as a better method than the editing function of posted tweets)

(Click to English translated version.)

本稿はTwitterの一利用者としての思いつきを書いたものであり、実際に採用するには、実装やユーザインタフェース等の一層の検討が必要と思われる。しかしながら、Twitterがより良くなる一助になればとの思いで書いた。
 

提案する削除機能

本稿で提案したいのは、現在のTwitterのツイート削除機能の変更、あるいは第2の削除機能の追加である。

Twitterでは、個々のツイートにはURLが付与されており、その一つ一つがあたかもWebページのように閲覧できる。次のURLは私が投稿したツイート例である。

https://twitter.com/tsaka1/status/1511731179846012928

WebブラウザでこのURLをアクセスすると、内容が
「This is a test tweet.」
であることがわかる。

このツイートを削除すると、そのURLをアクセスすると
「このページは存在しません。他のページを検索してみましょう。」
のように削除されている旨のメッセージが表示される。そして、このツイートに対するリプライも表示されなくなり、リプライのリンクも解除されていることがわかる。

リプライツイートを見ると、リプライとしてツイートされたことはわかるが、リプライ先ツイートが削除されている旨表示されるのみである。

ここで提案する新たな削除機能では、削除された際に、単に削除されたことだけでなく、例えば
「このツイートは2022年4月11日 0時50分に削除されました」
と削除された日時を表示する。そして、リプライやコメント付RTからの参照は削除前と同様につながったままとするものである。

リプライやコメント付きRTなどの参照関係を維持することで、ツイート内容の訂正に相当する機能を実現すると同時に、削除したときにスレッドが分割されてしまうような事態を回避する。

例えば、内容を訂正したいツイートがあれば、訂正済内容のツイートをそのリプライとして投稿し、元のツイートについては本提案における「削除」を行う。そうすれば、元のツイートに対するリプライやコメント付きRTのツイートから元のツイートを閲覧しようとすると、削除されていることがわかり、そこにぶら下がっているリプライで訂正後の内容を知ることができる。
 

既投稿ツイートの編集機能との比較

最近、Twitterで既投稿ツイートを編集する機能を設けるべきか否かという話題が盛り上がっている。しかしながら、単純に自由に編集できるようにすると、例えば次のような困ったことが生じる可能性がある。

本来AとBは異なるのに、ある人が「A = Bである」とツイートしたとする。それに対して大勢の人が「このツイートは間違っている」とリプライした後で、その問題のツイートを「A ≠ Bである」と編集してしまうと、リプライの方が間違っているかのように見えてしまうだろう。

以上のことから、ツイート編集機能を設けるのなら、編集履歴を閲覧できるようにするべきだという意見もある。それによって上記のような事態でも編集履歴を確認できれば、後でツイートの内容を覆したこともわかるだろうという考えであろう。確かに、誰もが自由に編集できるWikipediaも編集履歴も自由に閲覧できることからも、妥当な発想に思われる。

しかしながら、例えば[1]などのように、ツイート中のリンク先を見ない人が多いという問題がしばしば話題になっていることを考えると、その編集履歴がどの程度閲覧されるかについては疑問がでてくる。

本稿で提案する削除機能であれば、この例のような場合も、削除して訂正ツイートをしていることがわかり、その削除済ツイートに大勢のリプライがぶら下がっていることがわかるわけである。

以上のアイデアは筆者が昔使用していたUSENET NewsシステムのSupersedes機能の利用経験からの発想したものである。

References

[1] 現代人は読まない…。リンク先を見ずにリツイートしまくる人が大半であると判明 https://www.gizmodo.jp/2016/06/22_5.html

WindowsのファイルにZoneID属性を付与して、外部から持ち込んだOffice系ファイル等の安全性を高める

 タイトルに書いたとおりです:-)

Windows10等では普通にWebブラウザでダウンロードしたファイルには「外部から持ち込んだよ」的フラグがついて、例えばExcel等はそのまま開いてもマクロなど実行されない「保護ビュー」モードになります。

この解除はExcel等の中で保護ビューモードをやめさせるか、エクスプローラーなどでファイルのプロパティを開いて、最下部にチェックを入れる等すればよいのですが、その逆ができるようにはなっていません。

一方、フリーソフトウェアの中にはダウンロードしたファイルにこのフラグを付与しなかったりするものが有ります。また、外部からファイルの持って来る方法として、例えばネットワークドライブとしてマウントするような方法だとフラグは付与されません。

これはちょっと不安なので、フラグを立てる方法を探しました。ぐぐるとなんぼでも見つかりますが、私が注目したのは次のページです。

ZoneID を付与する方法など - setodaNote

なんと notepad.exe で付与できるとあるじゃないですか。。。あと属性の内容を閲覧する際に、more にリダイレクトで与えています。 

ということは、リダイレクトで属性の付与もできるのではないか？と思い、やってみたら無事できました。

その結果を受けて、安直なバッチファイル(CMD.EXE用)を書いてみたのが以下の7行です。

@rem ZoneIDを付与して、Office系ファイルなどのマクロ実行を禁止する
@echo off
for %%f in (%1) do (
  echo %%f
  echo [ZoneTransfer] > %%f:Zone.Identifier
  echo ZoneId=3 >> %%f:Zone.Identifier
)

これで、一応Windowsのワイルドカードにも対応できます。ただ、複数のファイル名を空白などで区切って列挙するのには対応していませんね。その辺がほしければ、コマンドライン引数の受け取り方等をちょいちょいといじればよいでしょう。

例えば、この内容を「addflag.cmd」というファイルに保存して、Windowsのセキュリティで実行許可があるとすれば、次のように実行すると、

addflag *.xlsx

カレントディレクトリにある、Excelのファイルすべてにフラグが付与され、以降解除の操作をしない限りExcelで開くと保護モードになるというわけです。

これで、外から持ち込んだファイルでも多少は安全に開くことができるでしょう:-)

 

(O'Reillyの)PDF電子書籍の目録ページを安直に作ってみた

 まぁ、誰でもやっていると思いますが。

道具はPython3.xにPyPDF2というライブラリを組み合わせて。。。

https://note.nkmk.me/python-pypdf2-pdf-metadata/

とPython公式ドキュメントを見ながらうりゃぁっという感じで書いたので、かなりええ加減ですね。標準出力を 適当にリダイレクトして foo.htmlにでもしてブラウザで開くと。。     

改良の余地はHTMLのリファインの他はソート順とかかなぁ。

import glob
import PyPDF2
import html
import urllib.parse

files = glob.glob('*.pdf')

print("<html>")
print("<body>")
print("<dl>")

for f in files:
    pdf = PyPDF2.PdfFileReader(f)
    # print(pdf.documentInfo)
    print('<a href="{}">'.format(urllib.parse.quote(f)))
    print('<dt>')
    print(html.escape(pdf.documentInfo['/Title'], quote=True))
    print('</dt><dd>')
    print(html.escape(pdf.documentInfo['/Author'], quote=True))
    print('(')
    print(html.escape(pdf.documentInfo['/CreationDate'], quote=True))
    print(')</dd></a>')

print("</dl>")
print("</body>")
print("</html>")
 

Androidからの投稿テスト

Android用にBloggerのアプリがあったので、とりあえずBlackBerry PRIVにインストールしてみました。
これはテスト投稿です。

まぁ問題が生じるとは思ってませんが:-)

Honya Club.comの「店舗受取」に関する懸念？

今日もHonya Club.comで予約した書籍を店頭受取で買ってきました。

便利なサービスで、最寄りの書店の活用にもなるのがいいんですが、気になる点が。。

というわけで、以下は書店等で聞き取り調査等はせずに推測していることなので、事実誤認があれば御指摘歓迎。というわけで、twitterではなくblogにした次第。ただ、ダラダラとした書き方にはなりますが。

その問題は「取りこぼしが多い」ということです。
本稿での「取りこぼし」とは、予約した書籍が店舗に届いた際に、店頭受取のために別に取り置くはずのものを、通常の新刊だと見なして、店頭に並べてしまっている状態のことです。

この「取りこぼし」率が私の経験では1割を超えていて、ヒューマンエラーにしてもちょっと高率過ぎるのが気になる点です。店舗側(の責任ある立場の人)は、その度に謝罪の言葉と「以後気をつけます」とは言ってくれるんですが、実際には改善している様子がない。

ちなみに、予約ではなく、単なる注文の場合には経験したことはありません。

で、これは恐らくHonya Club.comの「店頭受取」のためのシステム設計にエラーを起こしやすくしている点があるんじゃないかと思ってしまうわけですね。
もうちょっとツッコむと、Honya Club.comのサイトで予約注文して、店頭受取を指定した場合に、指定された店舗にその情報がどう伝えられているかに問題があるような気がするわけです。

予約なので、発売予定日まで日がありますから、予約時点で伝えるというのは多分やってないでしょう。実効性を伴わせるとすれば、問屋から出荷したタイミングで通知するか、問屋から届いた荷物でわかるようにしているか、でしょう。
ちなみに、顧客には「予約完了」、「出荷」、「(店舗に)入荷」という3回のタイミングでメールが届きます。

私が考えると、店舗側の手間を省き、間違いが起きないようにするには、店舗に届いた荷物で解るようにするのがベストになります。
一番いいのは、予約分は別の荷物にして、個々の書籍に誰の予約かラベリングしておくことですが、別の荷物にするのはコストがかかるので多分選ばれない。

他の新刊その他の書籍とまとめて送るとして、箱詰めの効率を考えると予約本とそれ以外を物理的に分けておくのもコスト的には多分選びそうに思えません。

とすると、書籍そのものは新刊本としてまとめられているので、書籍だけを見て、どれが予約・店頭受取かを識別出来ないだろうから、別途伝える必要があると思います。

で、素人的には荷物には常識的に送付品リストを添付しているはずだから、そのリストで予約本をわかりやすく明記しておけばいいじゃないかと思うわけですよね。それなら、届いた荷物をリストと照合しながら荷ときしていけば、当然「あ、これは予約だから、取り置こう」となると。
でも、それなら1割を超えるエラーが説明できません。

で、思ったのが「店舗には出荷時に通知するが、その通知は店員が積極的に端末を操作して予約のリストを見ないと分からない」システムになっているのではないかと思った次第です。
で、通常の端末操作では「予約品が出荷されていることはわからず、積極的に予約進出荷リストを表示しないと分からない」とか。。。。いや、まさかとは思うんですが、、、。

つまり、店員が常に「今日は予約品が届いているかもしれないからリストをチェックしよう」と考えて、その操作をしない限り予約品が出荷されたかどうかが分からない、とすれば、「予約品が届く頻度が低い」と空振りな日がほとんどになって、つい、忘れてしまうのではないかと予想した次第です。

人にポリングさせる＆頻度が低いとそりゃ無理があるでしょうから、普通は避けると思いたいんですが。。。
で、ミスがあるとしばらくは一所懸命毎日チェック するけど、空振りな日がずっと続くので、やがて他の忙しさでチェックを忘れても実害がなかなか起きないので(以下略)

現に今日も入荷通知が来てないけど、棚に挿してあるのを見つけて店員に聞いたら、一所懸命端末(いやPCですが)を操作して画面をいくつも見て確認してましたし(画面の内容までは私は見てません)。

で、改善して欲しいわけですが、特定の小規模店舗に言っても無理だろうしねぇ。Honya Club.comにユーザとして要望を出すと、私の登録店舗に対して厳重注意、つまり「運用でカバーしろ」になるような気がして、、、。

で、なんで上記のような事になっているように想像したかというと、店頭で予約注文した際の古典的な流れをシステムの設計時にいれたんではないかと。店頭で受ければ、店員側で把握しているし、それなりにわかりやすく伝票を整理しておけば、見落としはそうそう起きないと思うけど、そうじゃないからねぇ。。。

単なる注文の時は、発売予定日前後でもなく、突然既刊本が交じるわけですから、「あれ？注文出したわけでもないのに？」となるから多分気づいて今まではエラーを起こさなかったのかなぁと。

今までは、棚に並べられても私が店に行く閉店間際まで売れずにいてくれたから良かったんですが、売れてたらどうなることやら。（まぁ、そう売れないような本だから予約しないと入らないだろうなぁと予想して予約しているわけですけど:-)

 せっかくのサービスなので、改善して欲しいなぁと思うわけです。

あ、懲りずにこれからも何度も使うつもりですよ。（と言うか今も数冊予約しているし）

Zebra Puzzle

たまたまTLに流れてきた
https://twitter.com/algoRafael0110/status/873469127364534272
に刺激されて、Zebra Puzzleを解くプログラムをPrologで書いてみました。

上記のツイートで言及されているのは、
http://qiita.com/ShunIchikawa/items/6449f492dc38a7201162
「Prolog実践入門 - AIに特化した老舗言語 - Qiita」
の簡易版と、英語版Wikipediaの解説
https://en.wikipedia.org/wiki/Zebra_Puzzle
「Zebra Puzzle - Wikipedia」

元のツイートで「is」述語を使っているのがパット見で気になって、「nth1があるよなぁ」と思いながらQiitaのページをちらっと見た後、自分で書いたら使う必要がなかった。。。

まぁこれで一応最低限は出来たと思います。

?- who(W, Z).

と問えばOK.
先のツイートで上手くいかなかったのを厳密に分析はしていませんが、is 述語はこの手の純粋なパズル系の問題では要注意だというのが私見です。

とりあえず。以下がコード。(SWI-Prologで確認。改行位置がきちゃないのはご勘弁を)

neighbour(X, Y, [X, Y| _]).
neighbour(X, Y, [Y, X| _]).
neighbour(X, Y, [_| R]) :- neighbour(X, Y, R).
right(X, Y, [Y, X| _]).
right(X, Y, [_| R]) :- right(X, Y, R).

who(Water, Zebra) :-
  Street = [H1, H2, H3, H4, H5],
  member(house(englishman, red, _, _, _), Street),
  member(house(spaniard, _, dog, _, _), Street),
  member(house(_, green, _, coffee, _), Street),
  member(house(ukrainian, _, _, tea, _), Street),
  right(house(_, green, _, _, _), house(_, ivory, _, _, _), Street),
  member(house(_, _, snails, _, old_gold), Street),
  member(house(_, yellow, _, _, kools), Street),
  house(_, _, _, milk, _) = H3,
  house(norwegian, _, _, _, _) = H1,
  neighbour(house(_, _, _, _, chesterfields), house(_, _, fox, _, _), Street),
  neighbour(house(_, _, _, _, kools), house(_, _, horse, _, _), Street),
  member(house(_, _, _, orange_juice, lucky_strike), Street),
  member(house(japanese, _, _, _, parliaments), Street),
  neighbour(house(norwegian, _, _, _, _), house(_, blue, _, _, _), Street),
  member(house(Water, _, _, water, _), Street),
  member(house(Zebra, _, zebra, _, _), Street).