Skip to content

Commit 99f98de

Browse files
WEB: fix list formatting in PDEP-4 (#50895)
1 parent 86ae81c commit 99f98de

File tree

1 file changed

+4
-0
lines changed

1 file changed

+4
-0
lines changed

web/pandas/pdeps/0004-consistent-to-datetime-parsing.md

+4
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,7 @@
99
## Abstract
1010

1111
The suggestion is that:
12+
1213
- ``to_datetime`` becomes strict and uses the same datetime format to parse all elements in its input.
1314
The format will either be inferred from the first non-NaN element (if `format` is not provided by the user), or from
1415
`format`;
@@ -42,6 +43,7 @@ Out[2]: DatetimeIndex(['2000-12-01', '2000-01-13'], dtype='datetime64[ns]', freq
4243
## Detailed Description
4344

4445
Concretely, the suggestion is:
46+
4547
- if no ``format`` is specified, ``pandas`` will guess the format from the first non-NaN row
4648
and parse the rest of the input according to that format. Errors will be handled
4749
according to the ``errors`` argument - there will be no silent switching of format;
@@ -66,6 +68,7 @@ dtype: datetime64[ns]
6668
## Usage and Impact
6769

6870
My expectation is that the impact would be a net-positive:
71+
6972
- potentially severe bugs in people's code will be caught early;
7073
- users who actually want mixed formats can still parse them, but now they'd be forced to be
7174
very explicit about it;
@@ -80,6 +83,7 @@ The whatsnew notes read
8083
> In the next major version release, 2.0, several larger API changes are being considered without a formal deprecation.
8184
8285
I'd suggest making this change as part of the above, because:
86+
8387
- it would only help prevent bugs, not introduce any;
8488
- given the severity of bugs that can result from the current behaviour, waiting another 2 years until pandas 3.0.0
8589
would potentially cause a lot of damage.

0 commit comments

Comments
 (0)