When to set del cursor?

1406
2
Jump to solution
12-09-2021 06:51 AM
RPGIS
by
Occasional Contributor III

Hi,

I have a very simple question in regards to the del cursor. I use it from time to time but I have not thought about it.

When is the del cursor used? I have a sample script with a del cursor but I am not sure if I used it in the right manner.

edit.startEditing(False, True)
edit.startOperation()

with updateLines as cursor:
    for row in updateLines:
        if row[0] in UpdateIsolatedIDs_Lines:
            IsolationID = UpdateIsolatedIDs_Lines[row[0]]
            print (row)
            #print (IsolationID)
            if IsolationID:
                row[0] = row[0]
                row[1] = IsolationID
                row[2] = row[2]
                updateLines.updateRow(row)
            print (row)
            print ('\n')

    del cursor
    
edit.stopOperation()
edit.stopEditing(True)

I am not sure if the del cursor is used properly but I just wanted to ask.

0 Kudos
1 Solution

Accepted Solutions
JohannesLindner
MVP Frequent Contributor

This way is incorrect.

When you use a with block, this is what happens (on a very, very conceptual level!)

 

with arcpy.da.UpdateCursor(...) as cursor:
    your_code()

# this gets translated into
cursor = arcpy.da.UpdateCursor(...)
cursor.__enter__()
your_code()
cursor.__exit__()

 

The __exit__ method of the cursors resets iteration and removes locks. When you delete the cursor object before the __exit__ method is called, there's a good chance that you'll get persistent locks.

Deleting the cursor object is optional. I use cursors all the time and never delete them, never had a problem. ESRI recommends considering using the del to be absolutely sure there are no locks left:

https://pro.arcgis.com/de/pro-app/latest/arcpy/get-started/data-access-using-cursors.htm 
Cursors support with statements to reset iteration and aid in removal of locks. However, using a del statement to delete the object or wrapping the cursor in a function to have the cursor object go out of scope should be considered to guard against all locking cases.

If you want to use it, delete OUTSIDE of the with block:

 

with arcpy.da.UpdateCursor(...) as cursor:
    for row in cursor:
        stuff()
del cursor

 

 


Have a great day!
Johannes

View solution in original post

2 Replies
JohannesLindner
MVP Frequent Contributor

This way is incorrect.

When you use a with block, this is what happens (on a very, very conceptual level!)

 

with arcpy.da.UpdateCursor(...) as cursor:
    your_code()

# this gets translated into
cursor = arcpy.da.UpdateCursor(...)
cursor.__enter__()
your_code()
cursor.__exit__()

 

The __exit__ method of the cursors resets iteration and removes locks. When you delete the cursor object before the __exit__ method is called, there's a good chance that you'll get persistent locks.

Deleting the cursor object is optional. I use cursors all the time and never delete them, never had a problem. ESRI recommends considering using the del to be absolutely sure there are no locks left:

https://pro.arcgis.com/de/pro-app/latest/arcpy/get-started/data-access-using-cursors.htm 
Cursors support with statements to reset iteration and aid in removal of locks. However, using a del statement to delete the object or wrapping the cursor in a function to have the cursor object go out of scope should be considered to guard against all locking cases.

If you want to use it, delete OUTSIDE of the with block:

 

with arcpy.da.UpdateCursor(...) as cursor:
    for row in cursor:
        stuff()
del cursor

 

 


Have a great day!
Johannes
RPGIS
by
Occasional Contributor III

Thanks @JohannesLindner,

I hadn't used them to the degree that some people do. As a matter of fact, I mostly use them with a search cursor. I had noticed that most of my script was getting locked up for some reason and taking as long as several hours. I tried to see if freeing up and locks and emptying dictionaries and lists that I compiled to see if that would speed up the processing a bit. Thank you very much for informing me.

0 Kudos