Vrftsjtryk

If it is best to open cursors using a with statement to ensure it is deleted, like so:

with arcpy.da.UpdateCursor(fc,fields) as cursor:

Then, if a cursor is used as the iterable in a comprehension like so:

d = {k:v for (k,v) in arcpy.da.SearchCursor(fc,fields)}

Is it necessary to delete the cursor after using it in the comprehension?

No, it is not necessary to delete a cursor after using it in a comprehension. A cursor is an instance of a class, which is an object (everything in python is an object). Every python session has a namespace which contains references to all the objects in the session - think of it like a dictionary where the keys are references to each object, and the values are the objects themselves. When the 'reference count' - the number of keys that refer to that object - drops to zero, the object is removed and the memory re-allocated. When you use a cursor in a comprehension, there is no reference to that object in the namespace. After the comprehension is done, the object will be deleted.

There is no entry in the namespace, and therefore no need to delete anything. ESRI also illustrates this syntax in example 2, here.

To further clarify, if you run:

>>> import arcpy

>>> f = r'C:Workspacestudy_area.shp'

>>> a = arcpy.da.SearchCursor(f, ['*'])

You will see a .lock file appear in the directory (check your file explorer). The reference to the cursor is a, which will make the cursor (and therefore the lock) persist until a is deleted. So when you then run:

>>> del(a)

The entry in the namespace will be removed, and the lock will release (.lock file will disappear). If you run:

>>> t = [i for i in arcpy.da.SearchCursor(f, ['*'])]

You either won't see a lock file, or it will disappear when the command completes. Without an entry in the namespace, the cursor is not persistent. t refers to the list you just created, not the cursor used to create it.

To summarize, you need only worry about deleting cursors when they have a reference in the namespace (i.e. when you have assigned them to a variable, like a in the above example).

Update and insert cursors cannot be created for a table or feature class if an exclusive lock exists for that dataset. The UpdateCursor
or InsertCursor functions fail because of an exclusive lock on the
dataset. If these functions successfully create a cursor, they apply
an exclusive lock on the dataset so that two scripts cannot create an
update or insert cursor on the same dataset.

In Python, the lock persists until the cursor is released. Otherwise,
all other applications or scripts could be unnecessarily prevented
from accessing a dataset. A cursor can released by one of the
following:

Including the cursor inside a with statement, which will guarantee the
release of locks regardless of whether or not the cursor is
successfully completed Calling reset() on the cursor The completion of
the cursor Explicitly deleting the cursor using Python's del statement
- ESRI

Locking with arcpy.da cursors is pretty much the same as locking with the original arcpy cursors.

After testing your code, and as gberard pointed out, there is no reference to the cursor after the comprehension ends.

Also, there are no locks on the feature class after the comprehension ends. Search cursor does not lock the feature class anyway, so there is no need to worry about the cursor after the comprehension.

Whether it's necessary is the wrong question to ask. The question is whether you should. As a rule in programming, when it comes to releasing resources, you don't rely on weird implementation details. If something has an explicit way of releasing resources, use it. Don't expose yourself to the risk of bugs because they decided to change the implementation or because they have a bug. Just make the release explicit and be done with it:

with arcpy.da.UpdateCursor(fc,fields) as cursor:

    d = {k: v for (k,v) in cursor}

Saving one line of code is not worth the risks or the confusion others will experience when they read the code. Context managers are the standard mechanism for acquiring and releasing resources in Python, and they do it very well.

This, of course, assumes you're putting this code in a script to be run and potentially maintained by someone else. If you're the only one who will be impacted by a problem, then by all means, fly in the face of good practices all you want.