Steven Rotondo
Steven Rotondo
> The behaviour of `infer_datetime_format` is also unexpected to many, see [here](https://github.com/pandas-dev/pandas/issues/46210), [here](https://github.com/pandas-dev/pandas/pull/47745#discussion_r940141720) and [here](https://github.com/pandas-dev/pandas/pull/35428#pullrequestreview-456225397), and many more @MarcoGorelli What if we were to change the current function of `infer_datetime_format`...
> And if someone wants to retain the current functionality of guessing the format for each element individually, they could still do that with `.apply(pd.to_datetime)` @MarcoGorelli I suppose if the...
> Does this overlap with #48362? If so I would recommend allowing @johannes-mueller to continue with that PR first In that PR, @johannes-mueller stated that if the behavior was made...
> From #48542, I think this needs deprecating. It is documented in the User Guide, so it would be a breaking change. @rhshadrach How does the deprecation process work in...
> Just wanted to ask whether this is really what would be best - why not make `infer_datetime_format` strict: > > * if the format is inferred, and some row...
@MarcoGorelli Even though it's not very well documented, looking at the code and following the pathway makes it very clear that the fallback is intentional. If you would like to...
@rhshadrach `DataFrame.loc` also seems to exhibit the same behavior here, allowing the addition of a row. Unless I am very much mistaken, that's probably another related bug as well, right?...
> @srotondo - I do think the same should apply to `.loc` (i.e. setting a value that doesn't exist should raise). However, `.loc` is designed to be much more flexible,...