From mal at egenix.com Tue Jan 3 20:08:25 2012 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 3 20:08:31 2012 Subject: [egenix-users] Re: mx.DateTime 3.2.x and numpy In-Reply-To: References: <19832693.354.1323724898647.JavaMail.root@athene> <4EF0A97C.40905@egenix.com> <4EF251F6.1070001@egenix.com> Message-ID: <4F035229.9080101@egenix.com> V wrote: > M.-A. Lemburg writes: >> Not really, but it's possible that the new per operation >> coercion code does things in a different order. > > That's possible. I'm in the process of upgrading from an older version of > python/numpy/mx, and all those data types used to live together nicely. So must > be some new behavior, somewhere... > >> Do you get the same exception when swapping the two arguments ? ... > > No, when I swap the order, then it actually works. I did some debugging, and it > looks like when the order is switched, then the code never really hits the mx > DateTime code with the array, but only with individual elements of the array. My > guess is that this is so because it goes to the numpy code first, which does an > element-by-element comparison for the scalar on the right. Right, that's how it works and I expected the switch in order to resolve the problem. >> I guess we will either have to add a special case for numpy arrays >> or fallback to try other methods in case conversion to a float >> fails. > > Yes, I was thinking about that. I think probably that both of those options are > "not ideal" from a software engineering point of view. We've settled on simply giving up in case of an error. In such a case, we clear the error and let the right argument deal with the operation. This solves the problem with numpy and should also resolve similar problems with other types that expose __float__/nb_float slots, but only implement the operation for a few special cases. This may in some cases hide errors, but at least we don't have to add workarounds for numpy arrays or other similar types. We'll have the fix in version 3.2.2 of egenix-mx-base. BTW: If you know that a data types behaves like this, it's better to place the type on the left side of an operation (if you can), since then it'll get a chance to deal with the special casing before the other other argument has to deal with it (that's how mixed type operations work in Python since PEP 208 was implemented). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 03 2012) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From vovansim at gmail.com Tue Jan 3 19:37:04 2012 From: vovansim at gmail.com (V) Date: Tue Jan 3 20:37:23 2012 Subject: [egenix-users] Re: mx.DateTime 3.2.x and numpy References: <19832693.354.1323724898647.JavaMail.root@athene> <4EF0A97C.40905@egenix.com> <4EF251F6.1070001@egenix.com> <4F035229.9080101@egenix.com> Message-ID: M.-A. Lemburg writes: > We'll have the fix in version 3.2.2 of egenix-mx-base. Sounds good, thanks! From christian at marquardt.sc Tue Jan 3 22:03:56 2012 From: christian at marquardt.sc (Christian Marquardt) Date: Tue Jan 3 22:04:11 2012 Subject: [egenix-users] Re: mx.DateTime 3.2.x and numpy In-Reply-To: <4F035229.9080101@egenix.com> References: <19832693.354.1323724898647.JavaMail.root@athene> <4EF0A97C.40905@egenix.com> <4EF251F6.1070001@egenix.com> <4F035229.9080101@egenix.com> Message-ID: Would you have a patch available for the current release? We have a medium size application that uses mx.DateTime quite extensively with numpy, and it would add a real world test... Thanks, Christian. On 3 Jan 2012, at 20:08, "M.-A. Lemburg" wrote: > V wrote: >> M.-A. Lemburg writes: >>> Not really, but it's possible that the new per operation >>> coercion code does things in a different order. >> >> That's possible. I'm in the process of upgrading from an older version of >> python/numpy/mx, and all those data types used to live together nicely. So must >> be some new behavior, somewhere... >> >>> Do you get the same exception when swapping the two arguments ? ... >> >> No, when I swap the order, then it actually works. I did some debugging, and it >> looks like when the order is switched, then the code never really hits the mx >> DateTime code with the array, but only with individual elements of the array. My >> guess is that this is so because it goes to the numpy code first, which does an >> element-by-element comparison for the scalar on the right. > > Right, that's how it works and I expected the switch in order > to resolve the problem. > >>> I guess we will either have to add a special case for numpy arrays >>> or fallback to try other methods in case conversion to a float >>> fails. >> >> Yes, I was thinking about that. I think probably that both of those options are >> "not ideal" from a software engineering point of view. > > We've settled on simply giving up in case of an error. In such > a case, we clear the error and let the right argument deal with the > operation. This solves the problem with numpy and should also resolve > similar problems with other types that expose __float__/nb_float > slots, but only implement the operation for a few special cases. > > This may in some cases hide errors, but at least we don't have > to add workarounds for numpy arrays or other similar types. > > We'll have the fix in version 3.2.2 of egenix-mx-base. > > BTW: If you know that a data types behaves like this, it's better > to place the type on the left side of an operation (if you can), > since then it'll get a chance to deal with the special casing > before the other other argument has to deal with it (that's how > mixed type operations work in Python since PEP 208 was implemented). > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 03 2012) >>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > > ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: > > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Tue Jan 3 22:27:34 2012 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 3 22:25:50 2012 Subject: [egenix-users] Re: mx.DateTime 3.2.x and numpy In-Reply-To: References: <19832693.354.1323724898647.JavaMail.root@athene> <4EF0A97C.40905@egenix.com> <4EF251F6.1070001@egenix.com> <4F035229.9080101@egenix.com> Message-ID: <4F0372C6.8070109@egenix.com> Christian Marquardt wrote: > Would you have a patch available for the current release? We have a medium size application that uses mx.DateTime quite extensively with numpy, and it would add a real world test... That would be great ! We've uploaded a snapshot with the patch to our download server: http://downloads.egenix.com/python/egenix-mx-base-3.2.2_dev_20120103.tar.gz http://downloads.egenix.com/python/egenix-mx-base-3.2.2_dev_20120103.zip Please give it a try. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ > Thanks, > > Christian. > > > > On 3 Jan 2012, at 20:08, "M.-A. Lemburg" wrote: > >> V wrote: >>> M.-A. Lemburg writes: >>>> Not really, but it's possible that the new per operation >>>> coercion code does things in a different order. >>> >>> That's possible. I'm in the process of upgrading from an older version of >>> python/numpy/mx, and all those data types used to live together nicely. So must >>> be some new behavior, somewhere... >>> >>>> Do you get the same exception when swapping the two arguments ? ... >>> >>> No, when I swap the order, then it actually works. I did some debugging, and it >>> looks like when the order is switched, then the code never really hits the mx >>> DateTime code with the array, but only with individual elements of the array. My >>> guess is that this is so because it goes to the numpy code first, which does an >>> element-by-element comparison for the scalar on the right. >> >> Right, that's how it works and I expected the switch in order >> to resolve the problem. >> >>>> I guess we will either have to add a special case for numpy arrays >>>> or fallback to try other methods in case conversion to a float >>>> fails. >>> >>> Yes, I was thinking about that. I think probably that both of those options are >>> "not ideal" from a software engineering point of view. >> >> We've settled on simply giving up in case of an error. In such >> a case, we clear the error and let the right argument deal with the >> operation. This solves the problem with numpy and should also resolve >> similar problems with other types that expose __float__/nb_float >> slots, but only implement the operation for a few special cases. >> >> This may in some cases hide errors, but at least we don't have >> to add workarounds for numpy arrays or other similar types. >> >> We'll have the fix in version 3.2.2 of egenix-mx-base. >> >> BTW: If you know that a data types behaves like this, it's better >> to place the type on the left side of an operation (if you can), >> since then it'll get a chance to deal with the special casing >> before the other other argument has to deal with it (that's how >> mixed type operations work in Python since PEP 208 was implemented). >> >> -- >> Marc-Andre Lemburg >> eGenix.com From christian at marquardt.sc Thu Jan 5 01:16:46 2012 From: christian at marquardt.sc (Christian Marquardt) Date: Thu Jan 5 01:16:54 2012 Subject: [egenix-users] Re: mx.DateTime 3.2.x and numpy In-Reply-To: <4F0372C6.8070109@egenix.com> Message-ID: <26405877.95.1325722606202.JavaMail.root@athene> Thanks! That worked well - our application works absolutely fine again. Christian. ----- "M.-A. Lemburg" wrote: > Christian Marquardt wrote: > > Would you have a patch available for the current release? We have a > medium size application that uses mx.DateTime quite extensively with > numpy, and it would add a real world test... > > That would be great ! > > We've uploaded a snapshot with the patch to our download > server: > > http://downloads.egenix.com/python/egenix-mx-base-3.2.2_dev_20120103.tar.gz > http://downloads.egenix.com/python/egenix-mx-base-3.2.2_dev_20120103.zip > > Please give it a try. > > Thanks, > -- > Marc-Andre Lemburg > eGenix.com Professional Python Services directly from the Source > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ________________________________________________________________________ > > ::: Try our new mxODBC.Connect Python Database Interface for free ! > :::: > > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > > > Thanks, > > > > Christian. > > > > > > > > On 3 Jan 2012, at 20:08, "M.-A. Lemburg" wrote: > > > >> V wrote: > >>> M.-A. Lemburg writes: > >>>> Not really, but it's possible that the new per operation > >>>> coercion code does things in a different order. > >>> > >>> That's possible. I'm in the process of upgrading from an older > version of > >>> python/numpy/mx, and all those data types used to live together > nicely. So must > >>> be some new behavior, somewhere... > >>> > >>>> Do you get the same exception when swapping the two arguments ? > ... > >>> > >>> No, when I swap the order, then it actually works. I did some > debugging, and it > >>> looks like when the order is switched, then the code never really > hits the mx > >>> DateTime code with the array, but only with individual elements of > the array. My > >>> guess is that this is so because it goes to the numpy code first, > which does an > >>> element-by-element comparison for the scalar on the right. > >> > >> Right, that's how it works and I expected the switch in order > >> to resolve the problem. > >> > >>>> I guess we will either have to add a special case for numpy > arrays > >>>> or fallback to try other methods in case conversion to a float > >>>> fails. > >>> > >>> Yes, I was thinking about that. I think probably that both of > those options are > >>> "not ideal" from a software engineering point of view. > >> > >> We've settled on simply giving up in case of an error. In such > >> a case, we clear the error and let the right argument deal with > the > >> operation. This solves the problem with numpy and should also > resolve > >> similar problems with other types that expose __float__/nb_float > >> slots, but only implement the operation for a few special cases. > >> > >> This may in some cases hide errors, but at least we don't have > >> to add workarounds for numpy arrays or other similar types. > >> > >> We'll have the fix in version 3.2.2 of egenix-mx-base. > >> > >> BTW: If you know that a data types behaves like this, it's better > >> to place the type on the left side of an operation (if you can), > >> since then it'll get a chance to deal with the special casing > >> before the other other argument has to deal with it (that's how > >> mixed type operations work in Python since PEP 208 was > implemented). > >> > >> -- > >> Marc-Andre Lemburg > >> eGenix.com -- Dr. Christian Marquardt Email: christian@marquardt.sc Im Hausst?ck 16 Tel.: +49 (0) 6257 503 85 78 64665 Alsbach-H?hnlein Mobile: +49 (0) 179 290 84 74 Germany From christian at marquardt.sc Thu Jan 5 01:25:46 2012 From: christian at marquardt.sc (Christian Marquardt) Date: Thu Jan 5 01:25:57 2012 Subject: [egenix-users] Leap seconds and mx.DateTime In-Reply-To: <1842539.101.1325723059043.JavaMail.root@athene> Message-ID: <3694925.104.1325723146738.JavaMail.root@athene> Hello, on another topic - a while ago, we discovered a small inconsistency in the handling of leap seconds in mx.DateTime; some checks assume that a day is not longer than 86400 seconds, although of course on a day with a leap second this would be 86401 seconds. I've attached a patch (against the 3.2.2 dev version from another discussion thread) that has fixed the issue for us; maybe it or an improved version could make it's way into one of the next releases... Thanks a lot, Christian. -------------- next part -------------- A non-text attachment was scrubbed... Name: egenix-mx-base-3.2.2-leapsecondrange.patch Type: text/x-patch Size: 2441 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20120105/69c500bc/egenix-mx-base-3.2.2-leapsecondrange.bin From vovansim at gmail.com Fri Jan 6 15:26:44 2012 From: vovansim at gmail.com (V) Date: Fri Jan 6 16:27:01 2012 Subject: [egenix-users] Re: mx.DateTime 3.2.x and numpy References: <19832693.354.1323724898647.JavaMail.root@athene> <4EF0A97C.40905@egenix.com> <4EF251F6.1070001@egenix.com> <4F035229.9080101@egenix.com> <4F0372C6.8070109@egenix.com> Message-ID: M.-A. Lemburg writes: > We've uploaded a snapshot with the patch to our download > server: > > http://downloads.egenix.com/python/egenix-mx-base-3.2.2_dev_20120103.tar.gz > http://downloads.egenix.com/python/egenix-mx-base-3.2.2_dev_20120103.zip > > Please give it a try. Hey thanks for a quick turnaround on the new build! We tried this in our system, and it solved the problem as well. From mal at egenix.com Fri Jan 6 18:36:44 2012 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 6 18:36:55 2012 Subject: [egenix-users] Re: mx.DateTime 3.2.x and numpy In-Reply-To: References: <19832693.354.1323724898647.JavaMail.root@athene> <4EF0A97C.40905@egenix.com> <4EF251F6.1070001@egenix.com> <4F035229.9080101@egenix.com> <4F0372C6.8070109@egenix.com> Message-ID: <4F07312C.30202@egenix.com> V wrote: > M.-A. Lemburg writes: >> We've uploaded a snapshot with the patch to our download >> server: >> >> http://downloads.egenix.com/python/egenix-mx-base-3.2.2_dev_20120103.tar.gz >> http://downloads.egenix.com/python/egenix-mx-base-3.2.2_dev_20120103.zip >> >> Please give it a try. > > Hey thanks for a quick turnaround on the new build! We tried this in our system, > and it solved the problem as well. Great, thanks for the feedback. We'll probably release 3.2.2 next week. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2012) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From vovansim at gmail.com Mon Jan 9 11:01:27 2012 From: vovansim at gmail.com (Vovan Sim) Date: Mon Jan 9 18:01:31 2012 Subject: [egenix-users] DateTime formatting issue Message-ID: Hello, There seems to be an issue with DateTime formatting in mxBase 3.2. Imagine the following scenario: I have a datetime object that I turn into a float using absdays, and then create a new date time object from the float using DateTimeFromAbsDays. In the previous version I was using (mxBase 3.0) this behaved correctly: >>> from mx import DateTime >>> DateTime.__version__ '3.0.0' >>> print DateTime.DateTimeFromAbsDays(DateTime.DateTimeFrom('2009-01-03 01:31:00.00').absdays) 2009-01-03 01:30:59.99 You can see that the new object is off by one hundredth of a second. This is OK, it's obviously an inevitable consequence of this transformation caused by float rounding errors. However, in the new version, the output is a little different: >>> from mx import DateTime >>> DateTime.__version__ '3.2.1' >>> print DateTime.DateTimeFromAbsDays(DateTime.DateTimeFrom('2009-01-03 01:31:00.00').absdays) 2009-01-03 01:30:60.00 You can see that the output is rounded to 60 seconds, instead of 59.99. This is a bit of an issue, because now it's an illegally formatted date, and in fact if I try to parse this string, I get an error: >>> print DateTime.DateTimeFrom('2009-01-03 01:30:60.00') Traceback (most recent call last) [... snip ...] RangeError: Failed to parse "2009-01-03 01:30:60.00": second out of range (0.0 - <60.0; <61.0 for 23:59): 60 Since it breaks the parsing, it seems to me that the output of 59.99 seconds would be preferable to 60.00 seconds. Is that something that you guys think you could look into? Thanks, V From mal at egenix.com Mon Jan 9 18:21:14 2012 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 9 18:21:18 2012 Subject: [egenix-users] Leap seconds and mx.DateTime In-Reply-To: <3694925.104.1325723146738.JavaMail.root@athene> References: <3694925.104.1325723146738.JavaMail.root@athene> Message-ID: <4F0B220A.4090701@egenix.com> Christian Marquardt wrote: > Hello, > > on another topic - a while ago, we discovered a small inconsistency in the handling of leap seconds in mx.DateTime; some checks assume that a day is not longer than 86400 seconds, although of course on a day with a leap second this would be 86401 seconds. > > I've attached a patch (against the 3.2.2 dev version from another discussion thread) that has fixed the issue for us; maybe it or an improved version could make it's way into one of the next releases... Thanks. We've added support for those values to the upcoming 3.2.2 version as well. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 09 2012) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From info at egenix.com Wed Jan 11 10:41:27 2012 From: info at egenix.com (eGenix Team: M.-A. Lemburg) Date: Wed Jan 11 10:58:47 2012 Subject: [egenix-users] ANN: eGenix mx Base Distribution 3.2.2 (mxDateTime, mxTextTools, etc.) Message-ID: <4F0D5947.9060706@egenix.com> ________________________________________________________________________ ANNOUNCING eGenix.com mx Base Distribution Version 3.2.2 for Python 2.4 - 2.7 Open Source Python extensions providing important and useful services for Python programmers. This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-mx-Base-Distribution-3.2.2-GA.html ________________________________________________________________________ ABOUT The eGenix.com mx Base Distribution for Python is a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed data types. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. Contents of the distribution: * mxDateTime - Easy to use Date/Time Library for Python * mxTextTools - Fast Text Parsing and Processing Tools for Python * mxProxy - Object Access Control for Python * mxBeeBase - On-disk B+Tree Based Database Kit for Python * mxURL - Flexible URL Data-Type for Python * mxUID - Fast Universal Identifiers for Python * mxStack - Fast and Memory-Efficient Stack Type for Python * mxQueue - Fast and Memory-Efficient Queue Type for Python * mxTools - Fast Everyday Helpers for Python The package also include a number of helpful smaller modules in the mx.Misc subpackage, such as mx.Misc.ConfigFile for config file parsing or mx.Misc.CommandLine to quickly write command line applications in Python. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. For more information, please see the distribution page: http://www.egenix.com/products/python/mxBase/ ________________________________________________________________________ NEWS The 3.2.2 release of the eGenix mx Base Distribution is the latest release of our open-source Python extensions. The new patch-level version includes a few important fixes: * mxDateTime seconds rounding is now more careful to not show 60.00 or 61.00 as second value. * mxDateTime will now correctly work with numeric arrays (numpy) again. Thanks to Christian Marquardt for reporting the problem. * mxDateTime's DateTimeFromAbsDateTime() now accepts leap second values (86400.0 - <86401.0) as well. Thanks to Christian Marquardt for reporting the problem. * Enhanced mx.Misc.ConfigFile. Please see the changelog for details (URL listed below). If you are upgrading from eGenix mx Base 3.1.x, please also see the eGenix mx Base Distribution 3.2.0 release notes for details on what has changed and which new features are available: http://www.egenix.com/company/news/eGenix-mx-Base-Distribution-3.2.0-GA.html As always, we are providing pre-built binaries for all common platforms: Windows 32/64-bit, Linux 32/64-bit, FreeBSD 32/64-bit, Mac OS X 32/64-bit. Source code archives are available for installation on all other Python platforms, such as Solaris, AIX, HP-UX, etc. To simplify installation in Zope/Plone and other egg-based systems, we have also precompiled egg distributions for all platforms. These are available on our own PyPI-style index server for easy and automatic download. Whether you are using a pre-built package or the source distribution, installation is a simple "python setup.py install" command in all cases. The only difference is that the pre-built packages do not require a compiler or the Python development packages to be installed. For a full list of changes, please refer to the eGenix mx Base Distribution change log at http://www.egenix.com/products/python/mxBase/changelog.html and the change logs of the various included Python packages. ________________________________________________________________________ DOWNLOADS The download archives and instructions for installing the packages can be found on the eGenix mx Base Distribution page: http://www.egenix.com/products/python/mxBase/ ________________________________________________________________________ LICENSE The eGenix mx Base package is distributed under the eGenix.com Public License 1.1.0 which is an Open Source license similar to the Python license. You can use the packages in both commercial and non-commercial settings without fee or charge. The package comes with full source code ________________________________________________________________________ SUPPORT Commercial support for this product is available from eGenix.com. Please see http://www.egenix.com/services/support/ for details about our support offerings. Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 11 2012) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From d.szoska at steinreichwald.de Fri Jan 27 11:40:17 2012 From: d.szoska at steinreichwald.de (Szoska, Daniel) Date: Fri Jan 27 11:40:21 2012 Subject: [egenix-users] segfault in method .pydate() of DateTime Message-ID: Hello, Python dies with a segmentation fault, can someone reproduce this: >>> import mx.DateTime >>> mx.DateTime.Date(2012, 1, 1).pydate() segmentation fault This happens with .pydatetime() and .pytime() too. I tried it with Python 2.7.2, egenix-mx-base 3.2.2 under Linux, Max OS 10.7 and Windows XP. Best regards, Daniel -- Daniel Szoska Rechenzentrum f?r Berliner Apotheken Stein & Reichwald GmbH Schulstr. 20 15366 Neuenhagen bei Berlin Tel. 03342/211999-1 Fax 03342/211999-2 Mail D.Szoska@steinreichwald.de IK Apotheken: 300802830 IK sonst. LE: 661200128 ___________________________________________________________________________ Gesch?ftsf?hrer: Amtsgericht Steuernummer: USt-IdNr.: Daniel Szoska Frankfurt (Oder) 064/117/01849 DE136744915 HRB 11605 FF -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20120127/0a22f298/attachment.htm From mal at egenix.com Fri Jan 27 12:44:15 2012 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:44:26 2012 Subject: [egenix-users] segfault in method .pydate() of DateTime In-Reply-To: References: Message-ID: <4F228E0F.4040703@egenix.com> Szoska, Daniel wrote: > Hello, > > Python dies with a segmentation fault, can someone reproduce this: > >>>> import mx.DateTime >>>> mx.DateTime.Date(2012, 1, 1).pydate() > segmentation fault > > This happens with .pydatetime() and .pytime() too. > > I tried it with Python 2.7.2, egenix-mx-base 3.2.2 under Linux, Max OS 10.7 > and Windows XP. Thank you for reporting this. We have done some preliminary tests and it appears to be caused by the fact that mxDateTime uses a lazy import of the datetime module to implement interfacing with Python's datetime module types. The problem doesn't show up in the tests because the datetime module's C API is already initialized by the time the .pydate() (et al.) tests are run. We will issue a new patch level release to address the problem. Until then, please use the following trick to force initialization of the datetime C API in mxDateTime: # Trick to force initialization of the datetime C API in mxDateTime: import mx.DateTime import datetime mx.DateTime.today() == datetime.date.today() Background: The comparison causes a forced initialization. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2012) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mal at egenix.com Fri Jan 27 13:13:00 2012 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 13:13:12 2012 Subject: [egenix-users] segfault in method .pydate() of DateTime In-Reply-To: <4F228E0F.4040703@egenix.com> References: <4F228E0F.4040703@egenix.com> Message-ID: <4F2294CC.9060906@egenix.com> M.-A. Lemburg wrote: > Szoska, Daniel wrote: >> Hello, >> >> Python dies with a segmentation fault, can someone reproduce this: >> >>>>> import mx.DateTime >>>>> mx.DateTime.Date(2012, 1, 1).pydate() >> segmentation fault >> >> This happens with .pydatetime() and .pytime() too. >> >> I tried it with Python 2.7.2, egenix-mx-base 3.2.2 under Linux, Max OS 10.7 >> and Windows XP. > > Thank you for reporting this. > > We have done some preliminary tests and it appears to be caused > by the fact that mxDateTime uses a lazy import of the datetime > module to implement interfacing with Python's datetime module > types. > > The problem doesn't show up in the tests because the datetime > module's C API is already initialized by the time the .pydate() > (et al.) tests are run. > > We will issue a new patch level release to address the problem. > > Until then, please use the following trick to force initialization > of the datetime C API in mxDateTime: > > # Trick to force initialization of the datetime C API in mxDateTime: > import mx.DateTime > import datetime > mx.DateTime.today() == datetime.date.today() > > Background: The comparison causes a forced initialization. Here's a patch which fixes the problem. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2012) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset_25267.diff Type: text/x-patch Size: 4997 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20120127/0f28a8e1/changeset_25267.bin