[datatable-help] setnames on a non-data.table object

[Ricardo Saporta]

yes, it was mostly in general.  eg

  X <- 1:5
  setnames(X, LETTERS[X])
  # Error in setnames(X, LETTERS[X]) : x is not a data.table or data.frame


Ricardo Saporta
Graduate Student, Data Analytics
Rutgers University, New Jersey
e: saporta at rutgers.edu



On Wed, Oct 2, 2013 at 12:28 PM, Matt Dowle <mdowle at mdowle.plus.com> wrote:

>
> Rick,
>
> Oh - setnames already does work on data.frame.   That was a change in
> v1.8.4.
>
> Was the question more for lists and vectors then (anything that can have
> names),  rather than just data.frame/data.table?
>
> Matt
>
>
> On 02/10/13 15:13, Matt Dowle wrote:
>
> On 02/10/13 12:50, Ricky Saporta wrote:
>
>
>  This might be a topic to raise in a separate email:
> What do you think of adapting a naming convention where the name of the
> function indicates when a function will modify an object by reference?  In
> my personal work, I have been trying to end such functions with an
> underscore.  Putting aside for the moment all obvious and not so obvious
> issues with changing the names of existing functions & backwards
> compatibility, is the idea itself worth considering?
>
>
> Maybe.  But the convention was already that any function started "set"
> indicates it will change the object by reference. The documentation uses
> "set*" in several places with this in mind.
>
> > objects("package:data.table", pattern="^set")
> [1] "set"         "setattr"     "setcolorder" "setkey"      "setkeyv"
> [6] "setnames"
> >
>
> If the functions insert() and delete() are added, they'll add and remove
> rows by reference.  Those verbs don't start with set, but it's clear (in my
> mind) that they'd change the data.table by reference; e.g. insert(DT, row
> number | "end", some data).
>
> Looking at base etc for functions starting "set*" there's some side-effect
> meaning intended there too (setwd, setTimeLimit, set.seed).  setdiff and
> setequal are about sets in the collection sense.  So it's just setNames as
> a one off really.   And we don't use camelCase in data.table, so that's how
> to remember that.
>
> > objects("package:base", pattern="^set")
> [1] "setdiff"             "setequal"            "setHook"
> [4] "setNamespaceInfo"    "set.seed"            "setSessionTimeLimit"
> [7] "setTimeLimit"        "setwd"
> > objects("package:stats", pattern="^set")
> [1] "setNames"
> > objects("package:utils", pattern="^set")
> [1] "setBreakpoint"     "setRepositories"   "setTxtProgressBar"
>
> Since other set* functions work on data.frame  (set() for example!),
> setnames should too.  I was forgetting that. Let's change it then.
>
> Matt
>
>
>  Rick
>
>
>
> Matt
>
>
> On 01/10/13 20:51, Ricardo Saporta wrote:
>
>  Hi All,
>
>  I'm wondering if there are any potential problems or unforseen pitfalls
> with having
>
>    setnames(x, nms)
>
>  call
>     setattr(x, "names", nms)
>
>  when x is not a data.table.
>
>  Thoughts?
>
>  Rick
>
>  Ricardo Saporta
> Graduate Student, Data Analytics
> Rutgers University, New Jersey
> e: saporta at rutgers.edu
>
>
>
> _______________________________________________
> datatable-help mailing listdatatable-help at lists.r-forge.r-project.orghttps://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
>
>
>
>
>
> _______________________________________________
> datatable-help mailing listdatatable-help at lists.r-forge.r-project.orghttps://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/datatable-help/attachments/20131002/d14d0816/attachment-0001.html>