datetime.datetime. or datetime. ?

[NiklasRTZ]

Hello, my basic question is which recommendation is after slight
restructuring datetime.datetime to datetime
Both works but only one should be chosen probably adjust my package to
comply to dependencies.
Spec integrated code where datetime.datetime.now() refactored to
datetime.now()
set rather
from datetime import datetime, timedelta
than
import datetime
or no matter and completely flexible (then why gae error that
datetime.datetime wasn't datetime?)
Naturally better not to customize external dependencies but seemingly
impossible to use both for a little xmpp project.
Thanks with best regards

 

[Diez B. Roggisch]

Hello, my basic question is which recommendation is after slight
restructuring datetime.datetime to datetime
Both works but only one should be chosen probably adjust my package to
comply to dependencies.
Spec integrated code where datetime.datetime.now() refactored to
datetime.now()
set rather
from datetime import datetime, timedelta
than
import datetime
or no matter and completely flexible (then why gae error that
datetime.datetime wasn't datetime?)
Naturally better not to customize external dependencies but seemingly
impossible to use both for a little xmpp project.
Thanks with best regards

Some remarks:

- whitespace is significant. In python. And in posting here.

- please show us the exact traceback you get, and a minimal example
that produces it.

- how to import is mostly a matter of taste, as long as you refrain
from using "from datetime import *"e

Diez

 

[niklasr]

Some remarks:

  - whitespace is significant. In python. And in posting here.

  - please show us the exact traceback you get, and a minimal example
that produces it.

  - how to import is mostly a matter of taste, as long as you refrain
from using "from datetime import *"e

Diez

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.
Then changed import and cut the first datetime occurance which looks
good but breaks next sync with other. The project is the crowdguru
xmpp chat test reachable via gae app "classifiedsmarket@
{gmail,appspot}" currently importing
from datetime import datetime, timedelta
instead of
import datetime
Many thanks for the help and all further recommendation
code disponible montao.googlecode.com

 

[Diez B. Roggisch]

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.
Then changed import and cut the first datetime occurance which looks
good but breaks next sync with other. The project is the crowdguru
xmpp chat test reachable via gae app "classifiedsmarket@
{gmail,appspot}" currently importing
from datetime import datetime, timedelta
instead of
import datetime
Many thanks for the help and all further recommendation
code disponible montao.googlecode.com

I'm sorry, but this gibberish is beyond what I'm willing to decipher.
Good luck with somebody else doing so & helping you.

Diez

 

[Gabriel Genellina]

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".

 

[Carl Banks]

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.
Then changed import and cut the first datetime occurance which looks
good but breaks next sync with other. The project is the crowdguru
xmpp chat test reachable via gae app "classifiedsmarket@
{gmail,appspot}" currently importing
from datetime import datetime, timedelta
instead of
import datetime
Many thanks for the help and all further recommendation
code disponible montao.googlecode.com- Hide quoted text -

When you do this:

import datetime

you have to do this

d = datetime.datetime()

And when you do this:

from datetime import datetime

you have to do this:

d = datetime()

You evidently did this:

from datetime import datetime

then this:

d = datetime.datetime()

which is not allowed.

If you want to self-comply, I recommend always doing it the first way.


Carl Banks

 

[niklasr]

niklasr schrieb:





I'm sorry, but this gibberish is beyond what I'm willing to decipher.
Good luck with somebody else doing so & helping you.

Diez

Ok: Naming a class or function the same name the module is,
datetime.datetime is confusing or what?, you won't know module from
class from method. Thank you, at least one can inform what's
deciphered instead of only baptizing it, system spec
"datetime.datetime" or hasty handling description. Deciphering system
text "datetime.datetime...." we won't know module from class or
method.
It's more a question of internal forward compatibility than liking or
disliking output.

 

[niklasr]

When you do this:

  import datetime

you have to do this

  d = datetime.datetime()

And when you do this:

  from datetime import datetime

you have to do this:

  d = datetime()

You evidently did this:

  from datetime import datetime

then this:

  d = datetime.datetime()

which is not allowed.

If you want to self-comply, I recommend always doing it the first way.

Carl Banks

Understood it's a choice and to stay consistent with chosen. If the
first is recommended, why is second way possible? However it's now
possible that mixing two dependendies with different choices
conflicts. Both ways seems ok, this is my first xmpp test and long
time how to stay consistent using datetime import, strict conventions
welcomed so that dependencies shan't conflict and shall harmonize.
Thanks

 

[niklasr]

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.


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".

"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.

 

[Carl Banks]

Understood it's a choice and to stay consistent with chosen. If the
first is recommended, why is second way possible?

Because not everything in Python is a "professional project" that
needs "self-complying".

Also there are occasions where the second way is better. In a piece
of code that does a lot of math, would you rather write "math.sin(x
+2)" all over the place, or "sin(x+2)"?


Carl Banks

 

[niklasr]

Because not everything in Python is a "professional project" that
needs "self-complying".

Also there are occasions where the second way is better.  In a piece
of code that does a lot of math, would you rather write "math.sin(x
+2)" all over the place, or "sin(x+2)"?

Carl Banks

just sin(x+2) looks most natural. exactly why I asked, first module
and class or class and function have same name so we don't know which
is which, then conflict when dev1 uses one convention and dev2
another. I anyway complied towards the devendency so that next commit
from dev 2 is compatible with dev 1 and viceversa. My choice would
have been ...=datetime.now which was incompatible
with ...=datetime.datime.now() therefore just rather refactoring my
thing to comply with the dependecies than the other way, changing the
patch, appears the smoothest way here.
Thanks for all help
Niklas r