You still have to start a loop, but you can break out of it and kill the cursor at any time:

import arcpy
fc = 'c:/data/base.gdb/features'
# Open a cursor on some fields in a table
with arcpy.da.SearchCursor(fc, ['OID@', 'SHAPE@AREA']) as cursor:
for row in cursor:
# Do something with the first row of data here
break
del cursor

Since the arcpy.da.SearchCursor is an iterable that returns one list per row of the table/cursor, the Python built-in next() function can be used to retrieve the next row, which would be the first row if the cursor was just created or reset.

import arcpy
fc = 'c:/data/base.gdb/features'
# Open a cursor on some fields in a table
with arcpy.da.SearchCursor(fc, ['OID@', 'SHAPE@AREA']) as cursor:
row = next(cursor)
# Do something with the first row of data here
del cursor

If the cursor isn't going to be used once and disposed of, using a Python with statement ensures the cursor is reset for its next use. But then again, maybe having the cursor automatically reset isn't what someone wants. Just depends on the situation and need.

True, for now and in the ArcPy realm, calling the search cursor's next method will get the same result. I suggested using the built-in next method because of broader changes happening with Python outside of ArcPy. For Python 3 after PEP 3114 was approved, it meant the next() iterator method was going away. The Transition Plan for PEP 3114 covers two additional changes needed for moving to Python 3:

Method definitions named next will be renamed to __next__ .

Explicit calls to the next method will be replaced with calls to the built-in next function. For example, x.next() will become next(x) .

The built-in next function was introduced in Python 2.6 to smooth the transition. Since we know that Esri has made the leap to Python 3 with ArcGIS Pro, I suggested an approach using the built-in function. For now, Esri's implementation of the ArcPy Data Access (arcpy.da) module in ArcGIS Pro still includes cursors having explicit next() methods, but I argue the current ArcGIS Pro implementation isn't very pythonic since the explicit next() methods don't add any special functionality beyond simply iterating.

Several functionally equivalent code snippets were provided. I doubt the performance differences between the different code snippets will be noticeable, let alone significant. I think it is mostly a matter of style and what you prefer.

Lately, if I don't need to re-use the cursor, I have been using a variation of the one liner offered by Xander Bakker: