Add DataFrame.iterrowdicts
- [x] tests added / passed
- [ ] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [ ] whatsnew entry

I have not checked the linting / whatsnew stuff, will make a followup commit with those necessary changes.

----

### What is this?

Adds a method `DataFrame.iterrowdicts()` that is a very close relation to `DataFrame.itertuples()` that offers fast row-based iteration without the column name mangling of `DataFrame.itertuples()`.

I added it to the basics documentation but didn't change any of the documentation that currently recommends `DataFrame.itertuples()` as the "default" row-based iteration method. 
is there an issue for this? highly unlikey to expand the api like this. > is there an issue for this? highly unlikey to expand the api like this.

Is this push back because "this API expansion is not valuable (enough)" or because "the Pandas project doesn't want to expand the API anymore"? I'd be -1 on this API as well since you can convert the namedtuples to dicts directly.

> column name mangling

Might be worthwhile to instead to have `namedtuples` maybe customize the column name output instead  Any kind of name mangling is going to be more complicated and error prone than just using the columns directly. As long as you need to preserve the `result.<column_name>` behaviour, it's going to have problems.

This can also be thought of the row-wise parallel to `DataFrame.to_dict` (or `DataFrame.to_dict('records')`, except fast and plausibly includes the index).

The real point is that `DataFrame.itertuples()` is the only fast row-wise iteration in town and it has serious API constraints in practice. If we were going to do name mangling, it should have been done a long time ago as a restriction on DataFrame columns. That is, we already allow `df.<column_name>` to opportunistically work - if there was ever a time to introduce name mangling, it'd be to make that behaviour consistent by limiting the possible column names on DataFrames.

Basically, I think this would see use in practice because I often wish I had this and have to write my own.

Forgive the use of the "royal we", changing it to "you" all over the place sounded accusatory. :P @github-actions pre-commit Hello @logannc! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:

* In the file [`pandas/core/frame.py`](https://github.com/pandas-dev/pandas/blob/81a8617e84b3999653b79377ac76a4b4a69307f5/pandas/core/frame.py):

> [Line 1462:89](https://github.com/pandas-dev/pandas/blob/81a8617e84b3999653b79377ac76a4b4a69307f5/pandas/core/frame.py#L1462): [E501](https://duckduckgo.com/?q=pep8%20E501) line too long (107 > 88 characters)

* In the file [`pandas/tests/frame/test_iteration.py`](https://github.com/pandas-dev/pandas/blob/81a8617e84b3999653b79377ac76a4b4a69307f5/pandas/tests/frame/test_iteration.py):

> [Line 161:89](https://github.com/pandas-dev/pandas/blob/81a8617e84b3999653b79377ac76a4b4a69307f5/pandas/tests/frame/test_iteration.py#L161): [E501](https://duckduckgo.com/?q=pep8%20E501) line too long (111 > 88 characters)



##### Comment last updated at 2022-01-28 05:00:04 UTC Thanks for the pull request and effort, but for new features we usually request a discussion and buy-in from the core team in an issue before proceeding. Especially since there has been expression of doubt initially in this PR, going to close and encourage a discussion in an issue before proceeding here. 