それは、基になる実装 (Cursor オブジェクトが実際にドライバー内にあるもの) に依存します。
多くの DB-api 実装では、特に結果セットを返すクエリを実行していない場合、Cursor オブジェクトは「興味深い」ものではありません (つまり、多数のオブジェクトを保持して GC に心配させることができます)。
私は Oracle で Python を使用したことはありませんが、(JDBC などの経験に基づいて) Oracle ではそうではないのではないかと思います。Oracle JDBC ドライバーにはサーバー側のカーソルがあり、これをすばやく閉じることが非常に重要です (接続ごとのデフォルトのカーソル制限はかなり低く、制限を超えると、別のカーソルを開こうとすると失敗します)。
Oracle では、カーソルを閉じるために GC に依存することは危険です。たとえば、ループ内で新しいカーソルを開き、ループ関数が戻るまで GC がすべてのカーソルを保持する場合です。
これが当てはまる場合は、 with ステートメントの構造を使用して、例外が発生した場合でもカーソルがタイムリーに閉じられるようにすることが役立つ場合があります。
更新: contextlib.closing を次のようなコンテキストマネージャとして使用できます
with contextlib.closing(myconnection.cursor()) as curs:
curs.execute(...
# even if exception happens, cursor is still closed immediately
# after this block