Python実務基礎 問題集・練習問題クイズ

変更可能な要素を順序付きで保持し、追加・削除したい。適切な型は？

答え： list

listは順序を保持する変更可能なコレクションです。

ユーザーIDから名前を高速に引きたい。適切なデータ構造は？

答え： dict

dictはkeyとvalueの対応を保持し、keyによる検索に適します。

重複を除いたタグ集合を扱いたい。適切な型は？

答え： set

setは重複しない要素の集合を表します。

辞書にkeyがない場合、例外を出さず既定値を得たい。適切なのは？

答え： mapping.get(key, default)

dict.getはkeyがなければ指定した既定値を返します。

大量の値を一度に保持せず順次処理したい。適切な方法は？

答え： yieldを使うgenerator

generatorは必要なときに値を生成するためメモリ使用量を抑えられます。

関数の既定引数に空listを直接指定すると起き得る問題は？

答え： 呼び出し間で同じlistが再利用される

既定引数は関数定義時に評価されます。Noneを使い関数内で生成するのが一般的です。

関数が受け取った可変長の位置引数をまとめる記法は？

答え： *args

*argsは追加の位置引数をtupleとして受け取ります。

resourceを処理後に例外の有無にかかわらず解放したい。適切な構文は？

答え： with文でcontext managerを使う

withはcontext managerの終了処理を確実に呼び出します。

想定した例外だけを処理し、他の障害は隠したくない。適切なのは？

答え： except ValueErrorのように具体的な例外を捕捉する

具体的な例外だけを捕捉すると予期しない障害を上位へ伝えられます。

例外へ業務上の文脈を追加しつつ元の原因も保持したい。適切なのは？

答え： raise NewError(...) from exc

raise ... from ...は例外chainを明示し、原因追跡を容易にします。

文字列へ変数を読みやすく埋め込みたい。適切なのは？

答え： f-string

f-stringは式を明示的かつ読みやすく埋め込めます。

異なる型の値を文字列と直接+で連結するとどうなる？

答え： 多くの場合TypeErrorになる

明示的にstrへ変換するかf-stringを使います。

2つの変数が同じ値かを比較したい。通常使う演算子は？

答え： ==

==は値の等価性を比較します。isは同一objectかを調べます。

Noneかどうかを判定する推奨記法は？

答え： value is None

Noneはsingletonなのでidentity比較のisを使います。

sequenceをindexと値の組でloopしたい。適切なのは？

答え： enumerate(sequence)

enumerateはindexと要素を同時に返します。

JSON文字列をPython objectへ変換したい。適切なのは？

答え： json.loads(text)

json.loadsはJSON文字列をdictやlist等へdecodeします。

Python objectをJSON文字列へ変換したい。適切なのは？

答え： json.dumps(value)

json.dumpsは対応objectをJSON文字列へencodeします。

UTF-8 text fileを確実に読みたい。適切なopenは？

答え： open(path, encoding="utf-8")

encodingを明示するとOS既定値の差による文字化けを防げます。

OSに依存しにくいpath操作をしたい。適切なのは？

答え： pathlib.Path

pathlibはpathの結合・確認・読み書きをobject指向で扱えます。

外部commandを引数付きで安全に実行したい。適切な基本方針は？

答え： subprocess.runへ引数listを渡しshell=Falseを保つ

引数listとshell=Falseはshell injectionの危険を下げます。

projectごとに依存packageを分離したい。基本的な方法は？

答え： venv等でvirtual environmentを作る

virtual environmentはprojectごとにinterpreter環境とpackageを分離します。

applicationの依存versionを再現可能にしたい。適切なのは？

答え： lockされた依存情報をversion管理しCIで同じものをinstallする

依存を固定すると環境ごとの予期しないversion差を減らせます。

moduleを直接実行した場合だけCLI処理を動かしたい。使うguardは？

答え： if __name__ == "__main__":

直接実行時は__name__が__main__になり、import時の副作用を避けられます。

設定値をsource codeへ直書きせず環境から受け取りたい。基本的な方法は？

答え： os.environまたは設定libraryで環境変数を読む

環境変数は設定をcodeから分離できますが、secret storeや検証も組み合わせます。

application logをprintだけでなくlevel・時刻・出力先付きで管理したい。使う標準moduleは？

答え： logging

loggingはlevel、formatter、handlerを設定して運用可能なlogを出せます。

大量recordを処理中、1件の失敗で全体を即終了させるべきでない。適切な設計は？

答え： 失敗単位を捕捉して記録し、方針に従い継続・retry・隔離する

失敗境界と再処理方針を明確にすると部分障害へ対応できます。

HTTP API呼び出しでnetwork障害へ備える基本方針は？

答え： timeoutを設定し、再試行可能な失敗だけbackoff付きでretryする

timeoutと限定retryにより停止と過負荷を防ぎます。

関数の入力・戻り値の意図を明示しstatic checkerで確認したい。使うものは？

答え： type hints

type hintsは実行時強制ではありませんが、IDEやtype checkerで不整合を検出できます。

単純なdata containerに自動生成されたinitやreprが欲しい。適切なのは？

答え： @dataclass

dataclassはfield定義からinit、repr、比較等を生成できます。

DB queryへユーザー入力を渡す安全な方法は？

答え： DB driverのparameterized queryを使う

parameter bindingは値をSQL構文から分離しSQL injectionを防ぎます。

小さな関数の期待結果を自動検証したい。適切なのは？

答え： unit testで入力と期待値をassertする

unit testは小さい単位の振る舞いを高速・反復可能に確認します。

外部APIを呼ぶ関数のunit testを安定させたい。適切なのは？

答え： dependencyを注入しmock/fakeで境界を置き換える

外部境界を置換すると速度と決定性を保ち、integration testと役割分担できます。

temporary fileを使うtestで後始末漏れを防ぎたい。適切なのは？

答え： temporary directory fixture/context managerを使う

temporary resourceのlifecycleをtest frameworkやcontext managerへ任せます。

値の検証をassertだけで本番処理に実装する問題は？

答え： 最適化optionでassertが無効化され得る

assertは開発時の不変条件確認向けです。入力errorには明示的な例外を使います。

信頼できないdataを読み込む際pickleを避ける理由は？

答え： deserialization時に任意code実行につながり得る

pickleは信頼済みPython object向けで、外部入力には安全なformatとschema検証を使います。

未検証の文字列をevalへ渡す問題は？

答え： 任意のPython codeを実行され得る

evalは式をcodeとして実行するため、parserや明示的な変換を使います。

CPU負荷の高い純Python処理を複数coreで並列化したい。一般的な選択は？

答え： multiprocessingまたはprocess pool

processは別interpreterでCPU-bound処理を複数coreへ分散できます。

多数のI/O待ちtaskを効率よく扱う選択肢は？

答え： asyncioと非同期対応library

asyncioはI/O待ち中に他taskを進められますが、blocking処理を避ける必要があります。

production障害解析に役立つlogへ含める情報は？

答え： 時刻、level、request/job ID、主要contextを秘密なしで記録する

correlation IDとcontextは追跡性を高め、秘密や個人情報はmask・最小化します。

library関数が失敗時にprocess全体をsys.exitする問題は？

答え： callerがerror処理やcleanupを選べなくなる

libraryは意味のある例外をraiseし、終了判断はCLI等の境界へ任せる方が再利用しやすくなります。