Hello I am playing around with the DateTime module in order to adapt it to other formats than the American one. However, I would like not to start a work that someone is already doing or that is already done. I have found a little patch that solves temporarily the problem, but I would like to do something more definitive. However, I need to be careful due to the large use that is done internally by Zope. To whom can I get in touch regarding this issue? Best regards Stefano Vedovelli
Hello, IMHO the long term solution would be to use the mxDateTime [1] module instead of the DateTime module that currently uses Zope. best regards, jdavid [1] http://www.lemburg.com/files/python/mxDateTime.html
Hello
I am playing around with the DateTime module in order to adapt it to other formats than the American one. However, I would like not to start a work that someone is already doing or that is already done. I have found a little patch that solves temporarily the problem, but I would like to do something more definitive.
However, I need to be careful due to the large use that is done internally by Zope. To whom can I get in touch regarding this issue?
Best regards Stefano Vedovelli
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
"spinwing@inwind.it" wrote:
Hello
I am playing around with the DateTime module in order to adapt it to other formats than the American one. However, I would like not to start a work that someone is already doing or that is already done. I have found a little patch that solves temporarily the problem, but I would like to do something more definitive.
However, I need to be careful due to the large use that is done internally by Zope. To whom can I get in touch regarding this issue?
Best regards Stefano Vedovelli
IMHO, the best approach would be to make mxDateTime available separately from DateTime in the _ variable. That would avoid breaking any code, but allow anyone who wanted to use mxDateTime that option from within Zope. I think a product that adds mxDateTime to the _ variable would be your best bet. My $.02 -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
Hi!
IMHO, the best approach would be to make mxDateTime available separately from DateTime in the _ variable. That would avoid breaking any code, but allow anyone who wanted to use mxDateTime that option from within Zope.
I think a product that adds mxDateTime to the _ variable would be your best bet.
Well, my opinion, too. On the long run this might get the preferred way of dealing with time stuff so that the use of DateTime gets depreceated. But I guess DC needs to decide this.. I also dunno if there are any problems with mxDateTime being used (e.g. security concerns, whatever) as I havent't looked to closely at this. -- christian -- COM.lounge http://comlounge.net/ communication & design info@comlounge.net
IMHO, the best approach would be to make mxDateTime available separately from DateTime in the _ variable. That would avoid breaking any code, but allow anyone who wanted to use mxDateTime that option from within Zope.
I think a product that adds mxDateTime to the _ variable would be your best bet.
Well, my opinion, too. On the long run this might get the preferred way of dealing with time stuff so that the use of DateTime gets depreceated. But I guess DC needs to decide this.. I also dunno if there are any problems with mxDateTime being used (e.g. security concerns, whatever) as I havent't looked to closely at this.
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 brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Hello, 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 python programs. 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 compiled. 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 os.symlink(pathname, filename) 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, :) best regards, jdavid
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 brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Hello well, my idea was, as I said, to create a pubblic interface called DateTime, and then wrap mxDateTime or other forms behind it. This will make it fully compatible with the existing DC implementation. Then if soembody like me needs a more flexible implementation, as in my case a class that accepts and returns things in the central european format, then he/she can decide whatever or not use this implementation. Best regards Stefano -----Messaggio originale----- Da: Brian Lloyd [mailto:brian@digicool.com] Inviato: venerdì 16 marzo 2001 20.09 A: Christian Scholz; Casey Duncan Cc: spinwing@inwind.it; zope-dev@zope.org Oggetto: RE: [Zope-dev] Playing with DateTime
IMHO, the best approach would be to make mxDateTime available separately from DateTime in the _ variable. That would avoid breaking any code, but allow anyone who wanted to use mxDateTime that option from within Zope.
I think a product that adds mxDateTime to the _ variable would be your best bet.
Well, my opinion, too. On the long run this might get the preferred way of dealing with time stuff so that the use of DateTime gets depreceated. But I guess DC needs to decide this.. I also dunno if there are any problems with mxDateTime being used (e.g. security concerns, whatever) as I havent't looked to closely at this.
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 brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
participants (6)
-
Brian Lloyd -
Casey Duncan -
cs＠comlounge.net -
palomar＠sg.uji.es -
spinwing＠inwind.it -
Stefano