datetime.datetime. or datetime. ?

Discussion in 'Python' started by NiklasRTZ, Oct 8, 2009.

  1. NiklasRTZ

    NiklasRTZ Guest

    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
     
    NiklasRTZ, Oct 8, 2009
    #1
    1. Advertising

  2. NiklasRTZ schrieb:
    > 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
     
    Diez B. Roggisch, Oct 8, 2009
    #2
    1. Advertising

  3. NiklasRTZ

    niklasr Guest

    On Oct 8, 5:25 pm, "Diez B. Roggisch" <> wrote:
    > NiklasRTZ schrieb:
    >
    > > 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


    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
     
    niklasr, Oct 8, 2009
    #3
  4. niklasr schrieb:
    > On Oct 8, 5:25 pm, "Diez B. Roggisch" <> wrote:
    >> NiklasRTZ schrieb:
    >>
    >>> 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

    >
    > 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
     
    Diez B. Roggisch, Oct 9, 2009
    #4
  5. En Thu, 08 Oct 2009 19:11:04 -0300, niklasr <> escribió:
    > On Oct 8, 5:25 pm, "Diez B. Roggisch" <> 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
     
    Gabriel Genellina, Oct 9, 2009
    #5
  6. NiklasRTZ

    Carl Banks Guest

    On Oct 8, 3:11 pm, niklasr <> wrote:
    > On Oct 8, 5:25 pm, "Diez B. Roggisch" <> wrote:
    >
    >
    >
    >
    >
    > > NiklasRTZ schrieb:

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

    >
    > 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
     
    Carl Banks, Oct 9, 2009
    #6
  7. NiklasRTZ

    niklasr Guest

    On Oct 8, 7:34 pm, "Diez B. Roggisch" <> wrote:
    > niklasr schrieb:
    >
    >
    >
    > > On Oct 8, 5:25 pm, "Diez B. Roggisch" <> wrote:
    > >> NiklasRTZ schrieb:

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

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

    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, Oct 10, 2009
    #7
  8. NiklasRTZ

    niklasr Guest

    On Oct 8, 10:17 pm, Carl Banks <> wrote:
    > On Oct 8, 3:11 pm, niklasr <> wrote:
    >
    >
    >
    > > On Oct 8, 5:25 pm, "Diez B. Roggisch" <> wrote:

    >
    > > > NiklasRTZ schrieb:

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

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


    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, Oct 10, 2009
    #8
  9. NiklasRTZ

    niklasr Guest

    On Oct 8, 8:33 pm, "Gabriel Genellina" <> wrote:
    > En Thu, 08 Oct 2009 19:11:04 -0300, niklasr <> escribió:
    >
    > > On Oct 8, 5:25 pm, "Diez B. Roggisch" <> 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.
     
    niklasr, Oct 10, 2009
    #9
  10. NiklasRTZ

    Carl Banks Guest

    On Oct 10, 2:26 am, niklasr <> wrote:
    > On Oct 8, 10:17 pm, Carl Banks <> wrote:
    >
    >
    >
    > > On Oct 8, 3:11 pm, niklasr <> wrote:

    >
    > > > On Oct 8, 5:25 pm, "Diez B. Roggisch" <> wrote:

    >
    > > > > NiklasRTZ schrieb:

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

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

    >
    > 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
     
    Carl Banks, Oct 11, 2009
    #10
  11. NiklasRTZ

    niklasr Guest

    On Oct 10, 8:43 pm, Carl Banks <> wrote:
    > On Oct 10, 2:26 am, niklasr <> wrote:
    >
    >
    >
    > > On Oct 8, 10:17 pm, Carl Banks <> wrote:

    >
    > > > On Oct 8, 3:11 pm, niklasr <> wrote:

    >
    > > > > On Oct 8, 5:25 pm, "Diez B. Roggisch" <> wrote:

    >
    > > > > > NiklasRTZ schrieb:

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

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

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


    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
     
    niklasr, Oct 11, 2009
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Christos TZOTZIOY Georgiou
    Replies:
    3
    Views:
    711
    Christos TZOTZIOY Georgiou
    Sep 13, 2003
  2. Tim Peters
    Replies:
    0
    Views:
    537
    Tim Peters
    Sep 9, 2003
  3. mp
    Replies:
    1
    Views:
    392
    John Machin
    Jul 28, 2006
  4. Martin
    Replies:
    0
    Views:
    338
    Martin
    Dec 27, 2008
  5. Replies:
    2
    Views:
    762
    M.-A. Lemburg
    Jan 6, 2009
Loading...

Share This Page