Basically, what it comes down to is Python's explicit over implicit policy. First, unlike PHP, not everything in the Python language is automatically included in every file. You explicitly import things. datetime is a module in the standard Python library. It includes several things: datetime, time, date, timedelta. . . So, often what you want is a datetime object from the datetime module, but you could do datetime.date.today().

One of the nice things about Python is that you should be able to see where something comes from anytime you're using it. If you're referencing something, it will either be defined in that file or be defined by something imported at the top. So, if you see "Site.objects.get_current()" you can easily search the file for where Site comes from. Maybe it's a Site class defined in the file itself. Maybe it's imported from django.contrib.sites.models. Maybe it's from somewhere else. The nice thing is that you can easily see where it comes from so that you can look up that code.

This is very unlike many languages. PHP's include()/require() could execute anything when you call them and define any number of things and you might not know where they come from so easily. I get push back on this from some of my friends who argue that good IDEs should track that for you, but I like that there isn't the ambiguity in Python.

To be fair, an import in Python could execute anything, too.

True. It would be much nicer to have a now method in the datetime module so that we could just do import datetime; now = datetime.now()

The first is the datetime module. The second is a class.

It comes down to how you import it. These two bits of code are equivalent:

# Example 1

import datetime; print datetime.datetime.now()

# Example 2

from datetime import datetime; print datetime.now()

I generally prefer "import FOO" over "from FOO import BAR", which is why you see example 1 used in the Django Book.

The datetime module was also written before the Python style conventions were created.

If the datetime module was written today, it would make a bit more sense looking like this:

import datetime

datetime.DateTime.now()

Or it might have just been merged into the time module. The datetime module is mostly a single class which wraps the functions in the time module and adds a few convenience methods. I wouldn't be surprised if the reason for the separation is just historical -- say, time was written to match the C library, and later someone donated datetime as a set of utilities with an OO interface.

Anyway, since the common utilities in that are all attached to the datetime class in that module, there's no harm in importing the class directly. You could even fix the naming yourself, if you were so inclined:

    from datetime import datetime as DateTime
    DateTime.now()

So a `DateTime = datetime' in the module would let newer code look more conventional?

It would make the datetime class look more like other class names, but I'd strongly recommend against doing this. The Python community values consistency in the way that code is written (TOOWTDI) and this would be a sharp departure from that.

Fair, but maybe some class renames wouldn't be a bad idea for the v2 to v3 switch over. I don't know what the priorities are or what the bar is for changes that make the cut, so don't quote me on this :-)

As others have mentioned, datetime is basically a module that deals with everything related to dates and times. datetime.datetime is a class that deals specifically with date and time combinations. So basically datetime.datetime.now() would return something that contained both the present date and time, while datetime.time deals with time objects.

thanks guys