On Fri, Apr 27, 2012 at 4:03 PM, bruno desthuilliers <[email protected]> wrote: > On Apr 27, 2:30 pm, Tom Evans <[email protected]> wrote: >> >> The datetime class lives inside the datetime module. > > So far so good.... but! > >> You must have >> "import datetime" in that code, perhaps as well as "from datetime >> import datetime". > > The first statement will import the datetime module and bind it to the > name "datetime" in the current namespace. The second will import the > datetime class from the datetime module and bind it to the name > "datetime" in thye current namespace, _in this cas overwriting the > first binding. IOW : you either use the first form and access the > datetime class as "datetime.datetime", or use the second form and > access the datetime class as "datetime", but using both forms is at > once useless and confusing. > > As far as I'm concerned, I strongly favor the first form (importing > the module and using the fully qualified name), since there are other > useful stuff in the datetime module and chances are you'll need them > if you need the (badly named) datetime.datetime class. >
What I was trying to say is that he probably has code like this in (eg) app.views: from datetime import datetime from app.models import * and therefore thinks that he is using the datetime class, not the module. However, if app.models doesn't specify the symbols it exports, and has this in it: import datetime then the variable 'datetime' in app.views will be bound to the module, not the class. A similar bug is importing twice in the same file: from datetime import datetime .... import datetime Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
