I've never seen anything that states arcpy should/must be imported first in order to not override other system modules. I only skimmed this document but didn't see anything specific, although their examples tend to imply it. However if you do a import-from on datetime BEFORE importing arcpy, then you're datetime import will be destroyed:
>>> from datetime import datetime >>> datetime.now() datetime.datetime(2016, 7, 14, 12, 10, 12, 433000) >>> import arcpy >>> datetime.now() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute 'now' >>>
Either import datetime after arcpy or use the import-from-as syntax and give datetime an alias.
Great, thanks. At the very least, note it in the document about importing Arcpy. There's always the chance of namespace/module collision but I've never seen one like this.
As a workaround you can use:
import datetime datetime.datetime.now() import arcpy datetime.datetime.now()
from datetime import datetime as dt dt.now() import arcpy dt.now()
We'll still look into the actual bug as well
Currently its logged on our internal version control system as a bug, but lower priority due to the workaround. I'll bring it up again at the next Python meeting. I figure it could be fairly problematic if arcpy is used mid-stream in a script that imports other complex packages.
While you are talking about datetime, maybe just mention that math, sys, and time also get clobbered when importing arcpy. I can understand arcpy importing arcgis, but I can't think of any other packages I work with that re-import base packages into the global namespace.