[issue37945] test_locale failing
Change by Tim Lyons : -- nosy: +guy.linton ___ Python tracker <https://bugs.python.org/issue37945> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10466] locale.py resetlocale throws exception on Windows (getdefaultlocale returns value not usable in setlocale)
Tim Lyons guy.lin...@gmail.com added the comment: Surely the user of getlocale as the right to expect that the same thing (i.e. ISO language codes) would be returned on all platforms. I am looking at some code that provides special purpose date handling routines. The appropriate routine is selected by a language code (for the locale category LC_TIME as it happens) like fr_FR. In order to get this to work on different platforms, you have to test whether it is windows, and if so use getdefaultlocale, while for other platforms, you use getlocale in order to return similar language codes. This code would actually be wrong if the application were to change the locale inside the application, because on other platforms the change would have an effect, while on windows, it would be ignored! [I am running on Mac OS X as it happens, not Linux or Windows]. So, don’t say that getdefaultloale is not useful, it is the one that is needed on Windows! Note this is not a problem with the encoding – some of the discussion and many of the related bugs are concerned with the encoding. Also note Marc-Andre pointing out in http://mail.python.org/pipermail/python-bugs-list/2004-December/026667.html that “getdefaultlocale() mimics the lookup mechanism of setlocale(LC_ALL, )”. I recognise that he is talking about the lookup mechanism rather than the results, but it seems to suggest that the results might be similar (if you do the same lookup you would get the same result). But “getdefaultlocale returns something that setlocale cannot consume on Windows”! I recognise that it would be difficult to decide to code locale on python so that windows returns something that is not the same as the native call, but it does seem to me that python locale should translate the Windows language codes so that they are the same as are returned on all the other platforms (i.e. ISO codes etc). -- nosy: +guy.linton ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8516] Speed difference between Python 2.5 and 2.6 during filling bsddb database.
Tim Lyons guy.lin...@gmail.com added the comment: I see the same slowdown in Mac OS X with python 2.6 and bsddb 4.7.3 (4.7.25). (So, same version as Windows, and same versions as apparently run OK in linux). I rely on MacPorts to use these products, so have no idea how I would use bdsdb3 still less python 2.7. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8504] bsddb databases in python 2.6 are not compatible with python 2.5 and are slow in python 2.6
New submission from Tim Lyons guy.lin...@gmail.com: A database created under python 2.5 cannot be opened under python 2.6. It gives the error message DB_RUNRECOVERY: Fatal error, run database recovery -- process-private: unable to find environment , and a database created under python 2.6 cannot be opened under python 2.5 (see http://trac.macports.org/ticket/24310). (This in in Mac OS X: In Windows XP SP3, Python 2.6 can read a Python 2.5 bsddb data base. but not the other way around. If you try, you will end up with a corrupt data base.) python 2.6 bsddb is very much slower than python 2.5. Specifically, in Gramps, import of a 500 person xml file takes 12 sec with python25 and 9 mins 30 secs with python26. The slowness has been observed in Mac OS X (See http://trac.macports.org/ticket/23768) and in Windows (see http://www.gramps-project.org/bugs/view.php?id=3750). I am not sure, but I think that both systems are using the same underlying database module db46, and that the difference may be in the different interface modules: _bsddb.so (on Mac OS X) -- components: Library (Lib) messages: 103998 nosy: guy.linton severity: normal status: open title: bsddb databases in python 2.6 are not compatible with python 2.5 and are slow in python 2.6 type: crash versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8504] bsddb databases in python 2.6 are not compatible with python 2.5 and are slow in python 2.6
Tim Lyons guy.lin...@gmail.com added the comment: On Mac OS X,I get tim$ python Python 2.5.5 (r255:77872, Mar 21 2010, 22:08:39) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type help, copyright, credits or license for more information. import bsddb print bsddb.__version__, bsddb.db.version() 4.4.5.3 (4, 6, 21) tim$ /opt/local/bin/python2.6 Python 2.6.5 (r265:79063, Apr 8 2010, 22:42:38) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type help, copyright, credits or license for more information. import bsddb print bsddb.__version__, bsddb.db.version() 4.7.3 (4, 7, 25) So the database versions are: python 2.5 bsddb 4.4.5.3 (4, 6, 21) python 2.6 bsddb 4.7.3 (4, 7, 25) On python 2.5: Python 2.5.5 (r255:77872, Mar 21 2010, 22:08:39) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type help, copyright, credits or license for more information. import bsddb dbenv=bsddb.db.DBEnv() dbenv.open(., bsddb.db.DB_INIT_TXN | bsddb.db.DB_INIT_MPOOL | bsddb.db.DB_INIT_LOG | bsddb.db.DB_CREATE) db1=bsddb.db.DB(dbenv) db1.open(note.db,flags=bsddb.db.DB_RDONLY,dbtype=bsddb.db.DB_UNKNOWN) and on python 2.6: Python 2.6.5 (r265:79063, Apr 8 2010, 22:42:38) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type help, copyright, credits or license for more information. import bsddb dbenv=bsddb.db.DBEnv() dbenv.open(., bsddb.db.DB_INIT_TXN | bsddb.db.DB_INIT_MPOOL | bsddb.db.DB_INIT_LOG | bsddb.db.DB_CREATE) Traceback (most recent call last): File stdin, line 1, in module bsddb.db.DBError: (-30971, DB_VERSION_MISMATCH: Database environment version mismatch -- Program version 4.7 doesn't match environment version 4.6) The incompatibility between the two environments is therefore resolved as being due to different versions of bsddb. Thanks for all your help in determining this. The database slowdown still remains to be resolved. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
