How to achieve Set+Part like behaviour in custom Set function?

The suggested solution

There is a simple option - add these definitions:

SetAttributes[DFSet, HoldFirst]; DFSet[Part[df_, name_String], data_List] := DFSet[df, name, data]; DFSet[df_, name_String, data_List] := With[{dfl = df}, DFSet[dfl, name, data] /; dfl =!= Unevaluated[df] ]; 

and all will be fine. Basically, what happens here is that we only maintain the HoldFirst attribute for the 2-argument definition to recognize Part before it evaluates, and destructure it. The second definition replaces the first argument by its evauated form, in case when it is different (a check is needed to avoid infinite recursion).

Note, that these definitions must be executed before the existing ones for DFSet, since the order of them is important here. Note also, that we could not get away with just having a single DFSet[Part[df_, name_String], data_List] := DFSet[Evaluate@df, name, data], because DFSet is now HoldFirst, and a stand-alone application of the 3-argument DFSet would not pattern-match correctly when we pass variables like frame, rather than explicit DataFrame objects.

Using references to cover more cases

Mr.Wizard rightly noted that my current solution does not cover cases such as

x := frame[["a"]] 

where indeed DFSet[x, {1, 2, 3}] returns unevaluated. There are several ways to cover this case. One is to suppy some custom one-step evaluator like Mr.Wizard's step function. One potential problem with fixed-number-of-steps evaluators is that there is generally no way to tell how many evaluation steps would it take to evaluate some part of expression which is of interest to us. In this particular case though, this is not of a concern for Mr.Wizard's solution, because the definitions in his solution using step are constructed such that the one-step evaluation will repeat until one obtains Part[...], so this is certainly a perfectly valid and clever solution.

In any case, here I will show another method, which is - introduce and use generic references. Such references would work also for functions which hold their arguments, and effectively will allow local one-step evaluation. Here is a possible definition for a reference generator:

ClearAll[ref]; SetAttributes[ref, HoldAll]; ref /: (op : (Set | SetDelayed))[ref[sym_Symbol], rhs_] := sym /: (f : Except[ Clear | ClearAll | Unset | Remove | Set | SetDelayed ])[left___, sym, right___] := f[left, rhs, right]; 

Here is then the syntax to defined a reference:

ref @ y := frame[["b"]] 

I defined ref in this way intentionally, so that the definition looks natural: all we need to do is to add ref @ to the left of our usual variable assignment. Now, for example, we get:

Hold[y] (* Hold[frame[["b"]]] *) 

One can also test that part assignments will now work:

DFSet[y, {1, 2, 3}] frame[["b"]] (* {1,2,3} *) 

Note that such references can be useful in a more general context, since in combination with functions having Hold-attributes they implement local one-step evaluation. Since UpValues for these references will be applied by evaluator before DownValues for the functions where we pass them, we get the desired effect. Their values are substituted into those functions but we don't lose control over further evaluation of these values. Such evaluation is governed by the definitions of those functions we pass these values to.