カテゴリー: ブログ

こんにちは、石川さんです。

最近ORACLEのPL/SQLでストアドプログラムを作っています。どっちのパフォーマンスが良いのか、ちょっと気になったので調べてみました。

作っていたのは、ファイルを１行ずつ読み込んで、諸々チェックして、問題なければテーブルにINSERTする、というよくある単純な処理です。このとき、呼び出し側からOUTパラメータを指定して、登録件数とチェックしたエラー件数をもどす、という要件があるときの変数の使い方として、以下の二通りを考えました。どっちが早いのでしょうね？

1. OUTパラメータを直接インクリメントする
2. 別途定義したローカル変数をインクリメントして、最後にOUTパラメータへ結果をセットする

実験

わからないことは、すぐに実験しましょう。と、いうことで以下のスクリプトを作ってみました。

set serveroutput on

DECLARE
  counter NUMBER := 0;
  s1 TIMESTAMP;
  s2 TIMESTAMP;
  e1 TIMESTAMP;
  e2 TIMESTAMP;
  PROCEDURE inner_procedure1(an_counter OUT NUMBER) IS
  BEGIN
    an_counter := 0;
    LOOP
      an_counter := an_counter + 1;
      EXIT WHEN an_counter > 10000000;
    END LOOP;
  END;
  PROCEDURE inner_procedure2(an_counter OUT NUMBER) IS
    counter NUMBER := 0;
  BEGIN
    an_counter := 0;
    LOOP
      counter := counter + 1;
      EXIT WHEN counter > 10000000;
    END LOOP;
    an_counter := counter;
  END;
BEGIN
  s1 := SYSTIMESTAMP;
  inner_procedure1(counter);
  e1 := SYSTIMESTAMP;
  s2 := SYSTIMESTAMP;
  inner_procedure2(counter);
  e2 := SYSTIMESTAMP;
  DBMS_OUTPUT.PUT_LINE('START:'||TO_CHAR(s1,'YYYY-MM-DD HH24:MI:SS.FF'));
  DBMS_OUTPUT.PUT_LINE('END  :'||TO_CHAR(e1,'YYYY-MM-DD HH24:MI:SS.FF'));
  DBMS_OUTPUT.PUT_LINE(e1 - s1);
  DBMS_OUTPUT.PUT_LINE('START:'||TO_CHAR(s2,'YYYY-MM-DD HH24:MI:SS.FF'));
  DBMS_OUTPUT.PUT_LINE('END  :'||TO_CHAR(e2,'YYYY-MM-DD HH24:MI:SS.FF'));
  DBMS_OUTPUT.PUT_LINE(e2 - s2);
END;
/

inner_procedure1が、OUTパラメータをインクリメントする「１．」のケースで、inner_procedure2が、ローカル変数をインクリメントする「２．」のケースになります。

では何回か実行します。そして、結果は、、、

（・・・略・・・）
12:41:11  39  /
START:2022-11-30 12:41:11.901000000
END  :2022-11-30 12:41:12.665000000
+000000000 00:00:00.764000000
START:2022-11-30 12:41:12.665000000
END  :2022-11-30 12:41:13.149000000
+000000000 00:00:00.484000000

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:01.26
12:41:13 SQL> /
START:2022-11-30 12:41:18.841000000
END  :2022-11-30 12:41:19.492000000
+000000000 00:00:00.651000000
START:2022-11-30 12:41:19.492000000
END  :2022-11-30 12:41:19.872000000
+000000000 00:00:00.380000000

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:01.03
12:41:19 SQL> /
START:2022-11-30 12:41:23.800000000
END  :2022-11-30 12:41:24.439000000
+000000000 00:00:00.639000000
START:2022-11-30 12:41:24.439000000
END  :2022-11-30 12:41:24.818000000
+000000000 00:00:00.379000000

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:01.02
12:41:24 SQL>

「２．ローカル変数をインクリメントして、最後にOUTパラメータへ結果をセットする」方がおよそ1.5倍ほど、はやい！ということがわかりました。

と、いうことで今後はOUTパラメータへのアクセスは最後の一回のみ、ということにしたいと思います。

結論

ローカル変数をインクリメントして、最後にOUTパラメータへ結果をセットした方がはやい、というのは結果からみるとそのとおりなのですが、実は、10000000回（1千万回）ループしているのですよね。その上で、早くなったのは、0.3秒未満なので、大量データを何度も扱わない限りは気にしなくても良さそうです。億超えのデータをしょっちゅう扱うような人は、ちょっとずつ効いてきますので、気にしましょう！
ぼくはとっても気になります！！！

　今日も見に来てくださってありがとうございます。石川さんです。

　今日は、Oracleにおいてのテーブルのカラムの順番を入れ替える方法について書いておきます。昔だと、テーブル再作成してデータを入れ直す、という方法しかなかったのですが、別のやり方もあります、というお話です。Google先生に聞いたら、新しいやり方については簡単に出てこなかったので、周知しなければ、というモチベーションです。（笑）

Invisibleにして、Visibleにする

　結論を先に知りたい人のために、項目をInvisibleにして、visibleに設定し直すと、項目がテーブルの最後に移動します。この特性を使って順番を入れ替える、ということになります。

-- テーブルを作成します。POIに意味はありませんが、キーボード上に並んでいて、「ポイ」という感じが気に入っていてテストのときによく使っています。
SQL> create table poi (
  2    a number,
  3    b number,
  4    e number,
  5    d number
  6  );

表が作成されました。

-- 「C」列を追加し忘れました。よく見ると「E」「D」の列の順番も間違っていました。
SQL> desc poi
 名前                                      NULL?    型
 ----------------------------------------- -------- ----------------------------
 A                                                  NUMBER
 B                                                  NUMBER
 E                                                  NUMBER
 D                                                  NUMBER

-- 「C」列を追加します。
SQL> alter table poi add (c number);

表が変更されました。

-- 確認すると、最後に追加されています。
SQL> desc poi
 名前                                      NULL?    型
 ----------------------------------------- -------- ----------------------------
 A                                                  NUMBER
 B                                                  NUMBER
 E                                                  NUMBER
 D                                                  NUMBER
 C                                                  NUMBER

-- 「E」「D」列を「invisible」に設定します。
SQL> alter table poi modify ( e invisible, d invisible );

表が変更されました。

-- 確認すると、確かに「E」「D」列が見えなくなっています。ちなみにこの状態でINSERT INTO POI VALUES ( 1, 2, 3 );を実行すると、見えない列はNULLになりました。
SQL> desc poi
 名前                                      NULL?    型
 ----------------------------------------- -------- ----------------------------
 A                                                  NUMBER
 B                                                  NUMBER
 C                                                  NUMBER

-- 順番が大事ですので、まずは「D」列を見えるようにします。
SQL> alter table poi modify ( d visible );

表が変更されました。

-- そして、次に「E」列を見えるようにします。
SQL> alter table poi modify ( e visible );

表が変更されました。

-- 確認すると、順番が正しく入れ替わりました。
SQL> desc poi
 名前                                      NULL?    型
 ----------------------------------------- -------- ----------------------------
 A                                                  NUMBER
 B                                                  NUMBER
 C                                                  NUMBER
 D                                                  NUMBER
 E                                                  NUMBER

SQL> insert into poi values ( 1, 2, 3, 4, 5 );

1行が作成されました。

-- INSERT文を実行するときに項目を省略してみましたが、入れ替わった順番どおり値がセットされていました！
SQL> select * from poi;

         A          B          C          D          E
---------- ---------- ---------- ---------- ----------
         1          2          3          4          5

経過: 00:00:00.01
SQL>

　テーブルの項目をInvisibleに設定するオプションですが、Oracle 12cから登場したようです。これを実行すると文字通り見えなくなります。

追記：開発中のテーブルで実際に項目追加が必要になってやってみましたが、VISIBLEに設定するのは手抜きして以下のように一気にやっても順番通りに戻りました。

alter table poi modify ( e visible, d visible );

まとめ

　Oracleのテーブルのカラム定義の順番を入れ替えるのに、かつては再作成とデータ投入が必要でしたが、ALTER TABLE文だけで項目が入れ替えられるようになっていました！権限やインデックス、データ投入など、必要な手間を考えると圧倒的にこちらのほうが良い気がします。

　今日も見に来てくださって、ありがとうございます。石川さんです。
Excelの実行時エラー、1年ほど前に書いた記事のアクセスが一番多いので、みなさんのお役に立っているようです。と、いうことで先日職場にて発生した実行時エラー、今度は「5」です。こちらが発生しました。今回は全くつまづくこともなく、すぐに解決できたのですが、ひとによっては悩みに悩んで解決できない、ということもあるかも知れないと思って記事にすることにしました。（Excelはニーズが多いですからね。アクセスが増えるかもしれない、と調子に乗っております。）

　急いでいる方に結論だけ、お知らせします。こちらは以下のスクリプトで再現できます。

Sub test()
    'B1セルの内容がA1セルより小さいとき、B1セルの背景をグレーにしてフォントを太字にする条件付き書式を設定します
    With Range("B1").FormatConditions.Add(Type:=xlExpression, Formula1:="=AND($B1<$A$1)")
        .Font.Bold = True
        .Interior.Color = RGB(166, 166, 166)
    End With
End Sub

　ちなみにこちらのスクリプト、以前は問題なく実行できていたのですけど、ある日突然「実行時エラー’5’」が発生するようになりました、というお問い合わせでした。ただ、こちらのスクリプト、メールで受信して、ダウンロードして実行しても、ぼくの環境ではエラーにならなかったのです。不思議でしょ。なので、上記のスクリプトを記述してもエラーにならない方もいるかも知れません。その場合は、違う原因かも知れません。

　それで、エラーの出ている人のエクセルとぼくのエクセルをよくよくを見てみますと、セルの列の表記が違うのですよね。

　そう、列が「1､2､3､4､5､､､」となっているか「A､B､C､D､E､､､」となっているかの違いです。こちらは「ファイル(F)」の「オプション」を選択することで表示される「Excel のオプション」画面から「数式」を選択することで表示される「数式の処理」の「R1C1 参照形式を使用する(R)」をチェックすることで切り替えられます。チェック時は「1､2､3､4､5､､､」で、チェックオフ時は「 A､B､C､D､E､､､」と表示されるようになります。

　今回はこの設定が悪さをしていました。スクリプト作成時はR1C1参照形式を使わない設定になっていたのに、途中で切り替えて保存した、ということのようです。こちらの「R1C1 参照形式を使用する(R)」の設定は、Excel全体の設定ではなくて、ファイルごとに設定を保持するようです。ちょっと動作確認してみたところ、新規作成時は前回エクセル終了時の設定を利用して、既存ファイルを開いたときはそのファイルの設定を利用するようです。

まとめ

　マクロ実行時に今まで動作していたのにこのエラーが出るようになったら、「R1C1 参照形式を使用する(R)」の設定を疑ってみるといいかも知れませんね。マクロで条件付き書式の設定をするときには、参照形式をこの設定にそろえておかないといけない、ということですね。

　いつも見にきてくれてありがとうございます。石川さんです。スイカの季節ですね。いや、今ならオリンピックの話題が優先でしょうか。オリンピック、あんまり興味が持てないんだよねぇ。せっかく東京でやるのにね。

概要

　Anacondaに付属してくるSpyder IDEを使っていたのですが、パソコン再起動後、突然起動しなくなりました。原因はプロジェクトを利用するときに、日本語のファイル名を使ったことでした。Bugのようですが、対応方法について記載しておきました。

経緯

　最近、Pythonのスクリプトの編集、実行には、AnacondaをインストールするとついてくるSpyderを使っています。しかし、今日は、パソコンを再起動したあとに、Spyderを起動するとなぜか立ち上がらなくなってしまいました。えっ、どうした、Spyderよ。立ち上がって来いよ～。そんなに貧弱じゃないだろ？と、言いつつ、Anacondaプロンプトですらヒストリが読めなくて起動時にエラーを出力していたことを思い出しました。何か、入力しちゃいけない文字コードを入力してしまったのでしょうか。しかし、起動した後に、スプラッシュ画像が出て、そのままお亡くなりになるなんて、聞いてないよ～。少なくともエラーメッセージを出して欲しいよ。どうしようもないじゃない、Spyderさん。

まずはSpyderを開始できるようにします

　さて。気を取り直して、実行プログラムのありかを探して、まずはそこからでしょうか、と、思って実行プログラムを見ると、おや、今まで気にもならなかったプログラムがあるじゃないですか！そう、「Reset Spyder Settings (anaconda3)」です。こんなの、今まで、気にしたこともなかったなぁ。

　さて、実行したところ、何やら設定がリセットされたような気がしますので、再度実行してみます。心なしかスプラッシュ画像が小さくなったような気がします。何とか立ち上がりました。アイコンも心なしか小さくなったような気がしますねぇ。。。ま、それはいいか。

原因を追究します

　直前に作業していたのは、、、と、記憶をたどると、そうそう、新しくプロジェクトを作成して、そこにドキュメントフォルダをつくって、Sphinxのドキュメントを構築しようとしていたんだった、と、いうことを思い出しました。ということで、その新しいプロジェクトを再度開いてみると、、、おお、エラーか？。。。エラーですね。「Issue reporter」なる画面が起動されました。ふむふむ「Spyder has encountered an internal problem!」ということですね。内部の問題に直面しました、ということなのですが、問題レポートを送ればいいのかな？

　いや、送る前に、包括的なトラブルシューティングガイドで相談してください、と、書いてありますね。ほとんどの問題が解決されるらしいです。あとは、分かっているバグ、を検索してということだけど、検索しようにも何のメッセージも出てないしなぁ。。。そもそもこの「Issue report」は出てきたんだけど、エラーメッセージは何にも出力されていないのですよね。だからレポートを書くとしたら、「プロジェクトを開こうとしたら、内部的な問題に出会いました」くらいしか書きようがないですよね。とりあえず、「Close」でよいのかな？あ、「Close」ボタンの隣に「Show details」ボタンを発見しました！このボタンを押して詳細を見てみよう。と、ポチリとした結果、下部にエラーメッセージが出てまいりました。

テキストは一部分だけが見える状態でしたので、以下に全文を張り付けておきます。これだけ情報があれば、なんとかなりそうですね。

Traceback (most recent call last):
  File "C:\Users\mitsu\anaconda3\lib\site-packages\spyder\plugins\projects\plugin.py", line 129, in <lambda>
    triggered=lambda v: self.open_project())
  File "C:\Users\mitsu\anaconda3\lib\site-packages\spyder\plugins\projects\plugin.py", line 402, in open_project
    project_type_class = self._load_project_type_class(path)
  File "C:\Users\mitsu\anaconda3\lib\site-packages\spyder\plugins\projects\plugin.py", line 813, in _load_project_type_class
    config.read(fpath)
  File "C:\Users\mitsu\anaconda3\lib\configparser.py", line 697, in read
    self._read(fp, filename)
  File "C:\Users\mitsu\anaconda3\lib\configparser.py", line 1017, in _read
    for lineno, line in enumerate(fp, start=1):
UnicodeDecodeError: 'cp932' codec can't decode byte 0x81 in position 269: illegal multibyte sequence

　想定の範囲内ですが、UnicodeDecodeErrorですね！記憶にないけど、プロジェクト作るときに、日本語を使っちゃったのかなぁ。configparser.pyでエラーが発生しているのと、起動時は問題なくてプロジェクトを開くときにエラーが発生したので、プロジェクトのフォルダを見に行ってみます。ありましたね「.spyproject」フォルダが怪しいです。ちょっと覗いてみます。

　なるほど、「config」フォルダがあって、その中に複数の「.ini」ファイルがあります。この中をひとつずつ見ていきましょう。

　見つけました。「workspace.ini」ファイルですね。ここにマルチバイト文字がありました。そうそう、Sphinxで使う「.rst」のファイル名を日本語にしたのを思い出しました。このファイル自体はUTF-８で保存されていたので、うまく開けないのはどうしてでしょうね。

[workspace]
restore_data_on_startup = True
save_data_on_exit = True
save_history = True
save_non_project_files = False
project_type = empty-project-type
recent_files = ['..\\..\\..\\Users\\mitsu\\.spyder-py3\\temp.py', 'doc\\source\\index.rst', 'doc\\source\\このドキュメントについて.rst', 'doc\\source\\conf.py']

[main]
version = 0.2.0
recent_files = []

さらに原因を追究します

　configparser.pyのソースファイルを覗いてみたところ、ファイルをencoding=Noneとしてオープンしていることがわかりました。encoding=Noneとした場合は、ロケールのデフォルトエンコーディングが使用されます。つまり、日本語のWindows10環境では「cp932」が使われる、ということになります。configparser.pyの中にはファイルへの書き込みのためのオープンが見当たらなかったので、どのような設定になっているのかはちょっと不明だったのですが、上述のとおりファイルの内容はUTF-8で書き込まれていたので、書き込み時はUTF-8でオープンされているのだと思います。

では、修正しましょう

　さて、どう修正するのがよいでしょうか。気持ちとしてはconfigparser.pyのencoding=”utf-8″としたいところですが、影響範囲がはかり知れないので、Spyderに限って考えたいと思います。そうすると、エラーメッセージで指摘されている、C:\Users\mitsu\anaconda3\lib\site-packages\spyder\plugins\projects\plugin.pyの813行目に、encoding=”utf-8″を追加するのがよいでしょうか。

        config.read(fpath)  # 修正前

        config.read(fpath,encoding="utf-8")  # 修正後

　さて、修正してみたまではよかったのですが、果たして反映されるのでしょうか。Spyderって、実行形式で配布されている訳じゃないのかな？と、迷っている間に実行できそうなので、ささっとSpyderを再起動してみます。おっ、できました。エラーは発生しませんでした。

まとめ

　結論としては、UTF-8で保存したファイルをローカルロケールでオープンして読み込んだためにエラーが発生した、ということでしたね。なので、パソコン再起動が原因ではなくて、Spyderの再起動が原因、ということでした。Pythonはバージョン3から完全UTF-8対応したはずなのに、どうしてこんなことが起きるのかというと、デフォルトエンコーディング、大混乱しているようですね。「Fluent Python Pythonicな思考とコーディング手法」を参考に、Pythonのデフォルトエンコーディングに影響を与える設定を確認してみました。

Python 3.8.8 (default, Apr 13 2021, 15:08:03) [MSC v.1916 64 bit (AMD64)]
Type "copyright", "credits" or "license" for more information.

IPython 7.22.0 -- An enhanced Interactive Python.

In [1]: import sys, locale

In [2]: locale.getpreferredencoding()
Out[2]: 'cp932'

In [3]: my_file = open("dummy","w")

In [4]: type(my_file)
Out[4]: _io.TextIOWrapper

In [5]: my_file.encoding
Out[5]: 'cp932'

In [6]: sys.stdout.isatty()
Out[6]: False

In [7]: sys.stdout.encoding
Out[7]: 'UTF-8'

In [8]: sys.stdin.isatty()
Out[8]: False

In [9]: sys.stdin.encoding
Out[9]: 'cp932'

In [10]: sys.stderr.isatty()
Out[10]: False

In [11]: sys.stderr.encoding
Out[11]: 'UTF-8'

In [12]: sys.getdefaultencoding()
Out[12]: 'utf-8'

In [13]: sys.getfilesystemencoding()
Out[13]: 'utf-8'

In [14]: my_file.close()

　書籍はブラジル向けにローカライズされたWindows 7の結果が示されており、結果はなんと4種類のエンコーディングが出力されていました。それに比べると日本語のWindows10環境は「cp932」と「utf-8」の二つしかないので、まだマシな方かも知れませんね。（苦笑）

　今日も見にきてくださってありがとうございます。石川さんです。梅雨入りしてジメジメが続きますね。

　さて、先日翔泳社の『テスト駆動Python』という書籍を購入しまして、さ〜て、やりますか、と張り切っていたのですが、1章の1ページ目からうまく動かず。実行はできたのですけど、何故か警告が出力されてしまうのですよね。ぼくの環境は、Windows 10 ＆ Anaconda3です。

(base) C:\work\pytest\ch1>pytest test_one.py
================================================= test session starts =================================================
platform win32 -- Python 3.8.8, pytest-6.2.3, py-1.10.0, pluggy-0.13.1
rootdir: C:\work\pytest\ch1
plugins: anyio-2.2.0
collected 1 item

test_one.py .                                                                                                    [100%]

================================================== warnings summary ===================================================
..\..\..\ProgramData\Anaconda3\lib\site-packages\pyreadline\py3k_compat.py:8
  C:\ProgramData\Anaconda3\lib\site-packages\pyreadline\py3k_compat.py:8: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working
    return isinstance(x, collections.Callable)

-- Docs: https://docs.pytest.org/en/stable/warnings.html
============================================ 1 passed, 1 warning in 0.08s =============================================

(base) C:\work\pytest\ch1>

　なるほど、Anaconda3のpyreadlineモジュールで警告ですね。これは問題だと言われているファイル、py3k_compat.pyの8行目、「return isinstance(x, collections.Callable)」のところの「collections.Callable」を「collections.abc.Callable」に修正することで回避できました。そういえば、ちょっと前にもこちらの記事でpyreadlineのモジュール、修正していましたね。警告が出なくなってスッキリしたのですが、ふと、最近購入した、iPad Proでもできるんじゃないかな、と、やってみました。

実行環境のセットアップ

　iPad Proでのpythonというと、大体は「Pythonista 3」か、jupyter notebook系だと「Juno」「Carnets」がおすすめされることがほとんどだと思います。でも、今回使ったのは、「a-Shell」というアプリで、iOSで簡単なUnixコマンドが使えるシェルです。ここから「python」や「ipython 」を実行することができます。App Storeの検索で「a-Shell」を入力してぐるぐるのアイコンを探してインストールします。

　インストールできたら、実行します。黒いコマンドラインがフルスクリーンで登場します。pytestを実行してみましたが、コマンドが存在しない（command not found）、と、エラーになります。pytestを使えるようにするためには、インストールが必要ですね。pipコマンド「pip install pytest」で簡単に実行できるようになりました。

$ pytest
pytest: command not found
$ pip install pytest
Defaulting to user installation because normal site-packages is not writeable
Collecting pytest
  Downloading pytest-6.2.4-py3-none-any.whl (280 kB)
     |████████████████████████████████| 280 kB 4.0 MB/s 
Requirement already satisfied: packaging in /private/var/containers/Bundle/Application/10B03820-2240-4A08-AA93-CE205988D553/a-Shell.app/Library/lib/python3.9/site-packages (from pytest) (20.9)
Requirement already satisfied: attrs>=19.2.0 in /private/var/containers/Bundle/Application/10B03820-2240-4A08-AA93-CE205988D553/a-Shell.app/Library/lib/
python3.9/site-packages (from pytest) (20.3.0)
Requirement already satisfied: toml in /private/var/containers/Bundle/Application/10B03820-2240-4A08-AA93-CE205988D553/a-Shell.app/Library/lib/python3.9/site-packages (from pytest) (0.10.2)
Collecting py>=1.8.2
  Downloading py-1.10.0-py2.py3-none-any.whl (97 kB)
     |████████████████████████████████| 97 kB 10.5 MB/s 
Collecting iniconfig
  Downloading iniconfig-1.1.1-py2.py3-none-any.whl (5.0 kB)
Collecting pluggy<1.0.0a1,>=0.12
  Downloading pluggy-0.13.1-py2.py3-none-any.whl (18 kB)
Requirement already satisfied: pyparsing>=2.0.2 in /private/var/containers/Bundle/Application/10B03820-2240-4A08-AA93-CE205988D553/a-Shell.app/Library/lib/python3.9/site-packages (from packaging->pytest) (2.4.7)
Installing collected packages: py, pluggy, iniconfig, pytest
Successfully installed iniconfig-1.1.1 pluggy-0.13.1 py-1.10.0 pytest-6.2.4

実行してみます

　　書籍の内容を元に、test_one.pyファイルを作成して、以下の通り実行できました。

$ pytest test_one.py
================================================================= test session starts ==================================================================
platform darwin -- Python 3.9.2+, pytest-6.2.4, py-1.10.0, pluggy-0.13.1
rootdir: /private/var/mobile/Containers/Data/Application/117A9320-8100-4E66-A829-2B31D0457140/Documents/work/pytest/ch1
collected 1 item                                                                                                                                       
test_one.py .                                                                                                                                    [100%]
================================================================== 1 passed in 0.01s ===================================================================
$ 

はい、見事に成功しましたね。pytestでテスト対象として自動的に実行されるためには、

• ファイル名が test_*.py または、*_test.py という名前であること
• 関数名やメソッド名は、test_* という名前であること
• クラス名は Test* という名前であること

ということのようです。最初、テスト関数名を「est_passing」と「t」を欠落して作ってしまっていました。その欠落が原因で実行されなかったのですが、「t」の欠落に気づくまでは、警告があると実行できないのか〜、と勘違いしてしばらくウロウロしちゃいました。無事、解決できてよかったです。

お気に入り

　最近は、iPad Pro がお気に入りで、色々と遊んでいます。手書きの性能がとっても良いのが特にお気に入りで、近頃は手帳の替わりにノートアプリの「Goodnotes5」を使うようになりました。手書きのいいところと、電子のいいところの両方が享受できていて、大満足です。
　で、せっかく持ち歩けるのだから、pythonを使ったプログラミングもできないかなぁ、と、色々と検索してたどり着いたのが、今回紹介した「a-Shell」です。ただ、こちら tkinter が使えないので、しばらくは使い道がないなぁ、と思っていたのですが、GUIを利用しない今回のようなケースであれば活用できるはずだ、と、今回張り切って記事にしてみました。

まとめ

　Anaconda3 で pytest を実行するときにでた警告の修正と、iPad Proで pythonを使って pytest を実行する方法について記載しました。これでしばらくは気軽に pytest で遊ぶことができそうです。
　ちなみに、今回の記事は、iPad Pro を使って書いてみました。って、どこ見てもそんなこと分かりませんね。失礼しました！