Of course, we already can use mxDateTime in our own products. But
there is a problem, both modules have the same name, if you write
"import DateTime" you get the Zope's DateTime module.
A solution is to rename the mxDateTime module directory from
DateTime to, for example, mxDateTime, then use "import mxDateTime"
and everything is fine. Unfortunetaly this could break other
I've played for several hours with imp, __import__, sys, etc..
but haven't been able to import mxDateTime as it's installed.
If somebody knows how to do it please let me know.
We also could build a python product (a Zope component as Brian
suggests), it would be just a copy of mxDateTime. This is not very
elegant because you could need two copies of mxDateTime, one for
the Zope and one for other python programs. And it wouldn't be so
easy to install because mxDateTime has C code that needs to be
Another posibility is to use a symbolic link:
$ cd <INSTANCE_HOME>/Products
$ ln -s <wherever the mxDateTime module is> mxDateTime
And then use "from Products import mxDateTime". Windows users
still would need to copy the directory.
The (small) problem with this solution is that requires some
work of the user/admin that would be nice to avoid.
The following code automates the creation of the sym. link:
import imp, os, string, sys
filename = os.path.join(INSTANCE_HOME, 'Products', 'mxDateTime')
if not os.path.isdir(filename):
## Find the path to the mxDateTime module
path = filter(lambda x, find=string.find: find(x, 'zope') == -1, sys.path)
file, pathname, description = imp.find_module('DateTime', path)
## Create the symlink
from Products import mxDateTime
But I still don't like this solution. If somebody comes to something better
please let me know. Improvements to that code are also very welcomed, I want
to use mxDateTime for the upcomoing new version of the CalendarTag.
Also, perhaps DC could do something to avoid the name conflict for a future
Zope release, :)
> Note the "DC needs to decide..." only applies to what we
> decide to integrate (and thus sign up to maintain, at some
> level) into the core. One of the key goals of our long-term
> strategy of becoming much more component-oriented is that
> the "marketplace" (aka the community) decides what the best
> component is for a given task.
> And we do not have to wait for the full component story to
> land for this to happen; as noted, I'm sure someone could
> come up with a product that "componentizes" mxDateTime in
> some way so that people who prefer it can use it easily.
> Time and de facto usage would then tell whether we (DC) should
> consider some sort of transition - and we can learn whether
> that would be a good idea without inconveniencing those who
> prefer to continue using the built-in DateTime in the meantime.
> Brian Lloyd [EMAIL PROTECTED]
> Software Engineer 540.371.6909
> Digital Creations http://www.digicool.com
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -