{"id":5940,"date":"2025-02-19T04:47:01","date_gmt":"2025-02-19T12:47:01","guid":{"rendered":"https:\/\/wonghoi.humgar.com\/blog\/?p=5940"},"modified":"2025-12-01T02:16:56","modified_gmt":"2025-12-01T10:16:56","slug":"pandas-dataframe-in-python-1-disadvantage-of-using-attributes-to-access-columns","status":"publish","type":"post","link":"https:\/\/wonghoi.humgar.com\/blog\/2025\/02\/19\/pandas-dataframe-in-python-1-disadvantage-of-using-attributes-to-access-columns\/","title":{"rendered":"Pandas DataFrame in Python (1): Disadvantage of using attributes (dot notation) to access columns. Use `[]` (getitem) operator instead"},"content":{"rendered":"\n
There are two ways to access columns in DataFrame. The preferred way is by square brackets (indexing into it like a dictionary), while it’s tempting to use the neater dot notation (treating columns like an attribute), my recommendation is don’t! <\/p>\n\n\n\n
Python has dictionaries that handles arbitary labels well while it doesn’t have dynamic field names like MATLAB do. This puts DataFrame at a disadvantage developing dot notation syntax while the dictionary syntax opens up a lot of possibilities that are worth giving up dot notation for. The nature of the language design makes the dot notation very half-baked in Python and it’s better to avoid it altogether<\/p>\n\n\n\n
Reason 1: Cannot create new columns with dot notation<\/h2>\n\n\n\n
UserWarning: Pandas doesn't allow columns to be created via a new attribute name - see https:\/\/pandas.pydata.org\/pandas-docs\/stable\/indexing.html#attribute-access<\/code><\/pre>\n\n\n\n
Reason 2: Only column names that doesn’t happen to be valid Python attribute names (say, no spaces) AND a DataFrame that does not have any method with the same name as the column can be accessed through dot notation.<\/h2>\n\n\n\n
Take an example of dataframe constructed from device info dictionaries created by the package pyft4222<\/code>. I added a column called 'test me'<\/code> to a table converted from the dictionary of device info. The tabe T<\/code> looks like this:<\/p>\n\n\n\n<\/figure>\n\n\n\n
I tried dir()<\/code> on the table and noticed:<\/p>\n\n\n\n
\n
The column name \"test me\"<\/code> did not appear anywhere, not even mangled. It has a space in between so it’s not a valid attribute or variable name, so this column is effectively hidden from the dot notation <\/li>\n\n\n\n
flags<\/code> is an internal attribute of DataFrame and it was not overriden by the data column flags<\/code> when called by the dot notation. This means the flags<\/code> column was also shadowed in (aka hidden to) the dot notation as there were no mangled name for it either<\/li>\n<\/ul>\n\n\n\n
Even more weird is that getattr()<\/code> works for columns with non-qualified attribute name like test me<\/code> (despite the dot notation cannot access it because of the lack of dynamic field names syntax yet test me<\/code> doesn’t show up in dir()<\/code>). getattr(T, 'flags')<\/code> still gets the DataFrame’s internal attribute flags<\/code> instead of the column called flags<\/code> as expected.<\/p>\n
![\"\"](\"https:\/\/wonghoi.humgar.com\/blog\/wp-content\/uploads\/2025\/02\/image-3.png\")
<\/figure>\n\n\n\n