DataFrames should have a name attribute.

[wesm]

was: should DataFrames have a name attribute?

@y-p

[lbeltrame]

IMO it would make sense only if one would export to Excel worksheets, in such a case it would be nice to have.

[lodagro]

It can also be used to set default path in DataFrame.save(), e.g path = DataFrame.name

[wesm]

Could also be integrated into DataFrame.to_html and stuff like that also. I don't think it's too hard to add-- just will be a bit of a slog to make sure the name is passed on in the right places (it was quite a bit of hacking to add name to Series). Shoot for January or February sometime

[hughesadam87]

I'd upvote this one. I'm using it to auto-title plots and think it would certainly be a nice feature.

[pmacaodh]

I found uses for it too, however the name (as of v0.90) doesn't survive pickling, which if it did, would be useful to have working (my workaround is a bit of a fudge). To see the problem, try the following:

import pandas as pd
df = pd.DataFrame( data=np.ones([6,6]) )
df.name = 'Ones'
df.save('ones.df')
df2 = pd.load('ones.df')
print df2.name

I'd love to be able to dive in and contribute a fix, but I'm still not so well-versed in the library and many aspects of Python.

[wesm]

It's not a simple addition (you have to worry about preserving metadata through computations), but it would be nice. We'll probably look into it in the somewhat near future

[hughesadam87]

Hi Paul,

I have written a couple functions that will let you transfer all the custom
attributes from one dataframe to antother. Check out the function
transfer_attributes()

https://github.com/hugadams/pyuvvis/tree/master/pyuvvis/pandas_utils

In particular, if you save dataframeserial.py, it will save and load your
dataframes while preserving any custom attributes. In the file
df_attrhandler, you can use the function called "transfer_attr" to do
something like:

df=DataFrame()
df.name='test'
df2=DataFrame

transfer_attr(df, df2)
print df2.name
'test'

I agree that persistent custom attributes would be a key development in the
future, and there is already a github issue open for it. In fact, a
package that I"ll be posting to the list soon, really does depend on these
custom attributes.

On Mon, Dec 3, 2012 at 1:01 PM, Wes McKinney notifications@github.comwrote:

It's not a simple addition (you have to worry about preserving metadata
through computations), but it would be nice. We'll probably look into it in
the somewhat near future

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/447#issuecomment-10963804.

[hughesadam87]

Now that I have some time, I wanted to followup with this.

DataFrame, IMO, should have a .name attribute, and df.columns also should have a .name attribute and so should df.index, or at least I've found this useful in my work.

In any case, I think persistent attributes, and to a lesser extent, instance methods, would be an extremely important addition to pandas. Here's my reasoning:

Everybody that uses pandas for analysis outside of the scope of timeseries will eventually benefit from customizing/subclassing a DataFrame at some point. Usually, the dataframe is the ideal object for storing the numerical data, but there is also pertinent information that could go along with it to really customize the object. For example, a dataframe becomes the ideal choice for a spectroscopy experiment if one can store an extra array, the spectral baseline, outside of the dataframe. Additionally, experimental metadata ought to be stored. This is so easily done by adding attributes to the dataframe, that it almost begs to be the canonical way to handle spectral data.

The functions I wrote in the above link use a crude method to transfer arbitrary attributes between dataframes. In short, it first examines an empty DataFrame's attributes, and compares these with a list of attributes from the user's dataframe. Any differences are then transferred to the new dataframe. As a hack until a better solution presents itself, dataframe returns could call my transfer_attr() function before returning a new DataFrame. I wouldn't know how to integrate this fully into pandas otherwise.

I know this is low on the priority list, but I really do think that persistent custom attributes would be a big step forward, and not just an appeasement for corner case users.

Interesting. I'd like to add a couple of notes:

• You're suggesting there needs to be a mechanism to attach arbitrary metadata to a Dataframe.
  good idea.
  I don't though see why custom attributes must be implemented as "attributes" in the python sense.
  a metadata dict with a simple api which is serialized along with the dataframe would take care
  of most use cases and shouldn't be hard to implement. Is there some requirement you have
  for which this is not adequate?
• The .name issue is seperate. The .name(s) attributes are not "custom", but are "baked in"
  ,relied on by internal code and can affect other parts of the package in hard to predict ways
  (see the ongoing excel save/read issue).

[hughesadam87]

y-p,

I would be fine with a metadatadict, or whatever is the most elegant solution to the problem. The reason that I like adding attributes is for access. Something like df.name is easier for people to keep up with than df.metadata['name']; however, if you gave the metadata dict attribute access, then df.metadict.name is also pretty simple. Am I understanding you correctly? Whatever solution ends up being the most simple to implement, would be useful.

I agree that the name issue is separate. If .name is too baked in as you say, then sure, don't include it. But if the pandas Index object also had a way to persist attributes, or a persistent metadata dict, then one could just slap names or whatever attributes they want, onto these object as well.

I like the idea of providing attribute access under a predefined attribute rather then
directly on the object (i.e. df.tags.measurement_date) as the latter pollutes the namespace
and hurts backwards-compatibility when new methods or instance variables are added in
the future.

[hughesadam87]

Whatever is best for pandas would be fine with me. If the import gets too
tedious, it is easy enough to make some properties or basic getters/setters
for the convienence of the user. Something like "get_baseline()" may be
easier to present to users than df.tags.baselinedics.baseline1. In any
case, as long as the functionality is there, it will be very useful.

On Fri, Dec 7, 2012 at 8:10 PM, y-p notifications@github.com wrote:

directly on the object (i.e. df.tags.measurement_date) as the latter
pollutes the namespace

new custom metadata issue at #2485.
@hugadams - your thoughts (and PR, pending discussion) are welcome.

[sglyon]

Anyone working on adding the name attribute?

And where to look for more information on a possible tags property?