It depends on the underlying implementation - what the Cursor object actually IS inside the driver.
In many DB-api implementations, the Cursor object isn't "interesting" (i.e. you can keep lots of them and let the GC worry about them), especially if you haven't done a query which returns result sets.
I've not used Python with Oracle, but I suspect (based on experience with JDBC and others) that this is not the case in Oracle. Oracle JDBC drivers have server-side cursors which it is vitally important that you close quickly (there is a fairly low default per-connection cursor limit; exceeding the limit causes a failure trying to open another).
In Oracle, relying on the GC to close your cursors might be hazardous if, for example, you open a new cursor in the loop and the GC keeps them all until the looping function returns.
if this is true, it might be helpful to use a with-statement construction to ensure that the cursor is closed in a timely fashion, even if an exception occurs.
UPDATE: You can use contextlib.closing as a context-manager such as
with contextlib.closing(myconnection.cursor()) as curs:
curs.execute(...
# even if exception happens, cursor is still closed immediately
# after this block