datetime.datetime. or datetime. ?

niklasr niklasro at gmail.com
Sat Oct 10 05:43:00 EDT 2009


On Oct 8, 8:33 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar> wrote:
> En Thu, 08 Oct 2009 19:11:04 -0300, niklasr <nikla... at gmail.com> escribió:
>
> > On Oct 8, 5:25 pm, "Diez B. Roggisch" <de... at nospam.web.de> wrote:
> >> NiklasRTZ schrieb:
> >> > Hello, my basic question is which recommendation is after slight
> >> > restructuring datetime.datetime to datetime
> >>   - how to import is mostly a matter of taste, as long as you refrain
> >> from using "from datetime import *"e
>
> > type object 'datetime.datetime' has no attribute 'datetime' Traceback
> > (most recent call last):
> > is flexible, both ways worked just that self complying towards more
> > professional projects naturally feels right. Above error log seemingly
> > caused by import datetime instead of from datetime import datetime.
>
> The datetime module doesn't contain anything useful apart from the five  
> classes: date, time, datetime, timedelta and tzinfo. So using "from  
> datetime import ..." is fine.
>
> > Then changed import and cut the first datetime occurance which looks
> > good but breaks next sync with other.
>
> Just make sure to replace *all* occurrences of  "datetime.datetime" to  
> "datetime", etc. Should be easy to do.
> I don't know what you mean "breaks next sync with other".
>
> --
> Gabriel Genellina
"breaks next sync with other" I mean developer 1 using
datetime.datetime syncing with developer 2 using other convention.
I understand. It's OK and works both ways just preparing not to change
it next sync toward that dependency. So easier to comply my thing the
way the dependency is. datetime looks better than datetime.datetime
and my thing uses both timedelta and datetime whereas dependency only
has datetime. Output is no problem, more question about avoiding
future conflicts between conflicting choices.



More information about the Python-list mailing list