[Zope] DateTime and mxDateTime confusion
Andreas Jung" <firstname.lastname@example.org
Fri, 18 May 2001 07:01:28 -0400
>From: "Alex" <email@example.com>
Subject: [Zope] DateTime and mxDateTime confusion
> I've got some big confusion about DateTime objects on zope:
> in short:
> - zope has a built-in object called DateTime available in 'script
> - python has a 3rd party module mxDateTime which is called the same:
> question is: why did zope developers choose an existing name for that ?!
Who was first - the chicken or the egg ? I can't say mxDateTime introduced
DateTime first or Zope did it first.And I think this is not the point. You
this problems with others modules too when using "from module import xxx"
and xxx is available in another module too. The best way to get around is
to "import module" and use "module.xxx". This should avoid all conflicts.
> a more detailed description:
> I was trying PsycopgDA (postgresql database adaptor) which converts sql
> timestamp fields to DateTime objects and I wanted the floating point
> in UTC of it, so I called it's method timeTime() , but that method didn't
> exist. I wanted to be sure the object I was using was really a DateTime
> object so I've tried type(myObject) and it did return "DateTime" (note:
> is an external method which returns the python's function type()). I
> a DateTime object doing x = DateTime() and when I call x.timeTime() it
> worked, so I've tried type(x) and it also return "DateTime". Both objects
> were "DateTime" objects, but one was a zope built-in object called
> and the other was the python's 3rd party module mxDateTime also called
Maybe you could rewrite the check using isinstance() instead of using
> Using the same object type name on different object types is not what I
> a very intuitive idea. Why did zope go that way?
This happens often is not limited to Zope. It is also not an intuitive idea
"from world import *". This is unclean too :-))