The datetime.datetime.strptime documentation states that it is equivalent to datetime(*(time.strptime(date_string, format)[0:6])), but the time.struct_time returned by time.strptime does not include microseconds, implying that datetime's strptime would also not include microseconds, but testing of the functions shows that it does include them.

Removing the false statement of equivalence would be enough to remove this bug from the documentation.

The same part repeated at https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior can also be corrected. It seems both of them use _strptime which returns microseconds but only datetime.datetime.strptime uses it with time.strptime ignoring it.

Thanks

Hey I would like to remove this bug I was going through the discussion so does that mean remove the about mentioned lines from 

https://docs.python.org/3/library/datetime.html#datetime.datetime.strptime

will fix this issue? Or should we add some more information there?

It is true that time.srtptime() does not return microseconds, but as the documentation suggests, it will return the microseconds after you wrap it up with datetime().
I have attached a walkthrough of how I see that section of the docs. Please let me know if you have anything else in mind. Thanks!

At least with Python 3.7.0, the equivalence is not complete: datetime.strptime() is better, since it retains both microseconds and timezone data. See examples below.

>>> from datetime import datetime, timezone
>>> import time
>>> s = datetime.strftime(datetime.now(), '%a %b %d %H:%M:%S %f')
>>> s
'Fri Oct 12 11:33:32 999810'
>>> datetime.strptime(s, '%a %b %d %H:%M:%S %f')
datetime.datetime(1900, 10, 12, 11, 33, 32, 999810)
>>> datetime(*time.strptime(s, '%a %b %d %H:%M:%S %f')[:6])
datetime.datetime(1900, 10, 12, 11, 33, 32)
>>> s2 = datetime.strftime(datetime.now(timezone(timedelta(hours=1))), '%a %b %d %H:%M:%S %f%z')
>>> s2
'Fri Oct 12 09:48:40 347076+0100'
>>> datetime.strptime(s2, '%a %b %d %H:%M:%S %f%z')
datetime.datetime(1900, 10, 12, 9, 48, 40, 347076, tzinfo=datetime.timezone(datetime.timedelta(seconds=3600)))
>>> datetime(*time.strptime(s2, '%a %b %d %H:%M:%S %f%z')[:6])
datetime.datetime(1900, 10, 12, 9, 48, 40)

As far as I can see, every time something changes on datetime.strptime(), it will invalidate that section of the documentation. On the other hand, I believe the comparison with datetime(*(time.strptime(date_string, format)[0:6])" is interesting and valuable to keep.
Given that, instead of "This is equivalent to [...]", I would suggest something like:
"This is similar to [...], but datetime.strptime() is better since it retains both microseconds and timezone data."

I agree with Gus, such new wording would be great. Gus, would you like to make a PR?

I'd split the comparison into a second paragraph, and avoid the word "better", instead using something like "but datetime.strptime() also retains both microseconds and timezone data."

Note that such a change of the wording to "similar" rather than "equivalent" will also future-proof this wording from minor future changes to either function.

Thanks, Tal. I will open up a PR for it.

New changeset c0799ec973530ad2492bb1d6c7287ffc428f0348 by Victor Stinner (Gus Goulart) in branch 'master':
bpo-27741: Better wording for datetime.strptime() (GH-9994)
https://github.com/python/cpython/commit/c0799ec973530ad2492bb1d6c7287ffc428f0348

New changeset 0a53a067dc4eb86ecf94c50582b3e22359c601a9 by Miss Islington (bot) in branch '3.6':
bpo-27741: Better wording for datetime.strptime() (GH-9994)
https://github.com/python/cpython/commit/0a53a067dc4eb86ecf94c50582b3e22359c601a9

New changeset a02bc719ebc496bc527e9e46de2f2e83f68bfd77 by Miss Islington (bot) in branch '3.7':
bpo-27741: Better wording for datetime.strptime() (GH-9994)
https://github.com/python/cpython/commit/a02bc719ebc496bc527e9e46de2f2e83f68bfd77

New changeset 4ec427b005036dab0a380de20f31774394ca4dd6 by Miss Islington (bot) in branch '2.7':
bpo-27741: Better wording for datetime.strptime() (GH-9994)
https://github.com/python/cpython/commit/4ec427b005036dab0a380de20f31774394ca4dd6

Thanks Nicholas Colclasure for the bug report and Gus Goulart for the fix.