Re: [Python-Dev] 2.6 on Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Which is the best state I've ever managed to get the 64bit build to. Note however that bsddb3 was skipped by my tests. Running that test alone, both platforms report the same error as the buildbot: FAIL: test01_basic_replication (bsddb.test.test_replication.DBReplicationManager) -- Traceback (most recent call last): File "o:\src\python-svn-amd64\lib\bsddb\test\test_replication.py", line 134, in test01_basic_replication self.assertTrue(time.time()However, the error appears after a number of seconds of inactivity - so I suspect it has nothing to do with the timer resolution on Windows and more about the fact that the test really did fail. So while I'm not sure what else the buildbot is seeing, the only real problem seems exactly 1 test in the bsddb3 tests. Thanks Mark. If we can't get bsddb3 running cleanly, we'll have to add an item to the release notes about it. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSK1fgHEjvBPtnXfVAQLu2wP8D5dBf6wAeGgOgK49FPDhN+5hvcrlp4KT pMJTD161e21+XdgzY0pohWWPXiUnpUuJduuUTpVOfbi73kpDJakExDWqL7T3D4T+ CtNPxnoTZlv/AkrYwQfc0qKdWGn82uAiH8j6C6xMqtxNMgWCHjhD1z9w1eOssLRt +r9MfRCLRqs= =XXlj -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 2.6b3 and 3.0b3
And this release, the special award for making it possible goes to Antoine Pitrou for quick and accurate work on the memoryview implementation. [Resounding Applause] On Wed, Aug 20, 2008 at 10:17 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On behalf of the Python development team and the Python community, I am happy > to announce the third and last planned beta releases of Python 2.6 and Python > 3.0. > > Please note that these are beta releases, and as such are not suitable for > production environments. We continue to strive for a high degree of quality, > and these releases are intended to freeze the feature set for Python 2.6 and > 3.0. > > As these are the last planned beta releases, we strongly urge you to download > these releases and test them against your code. Once we reach release > candidates (currently planned for 03-Sep-2008), only highly critical bugs will > be fixed before the final release. > > If you find things broken or incorrect, please submit bug reports at > > http://bugs.python.org > > For more information and downloadable distributions, see the Python > 2.6 website: > > http://www.python.org/download/releases/2.6/ > > and the Python 3.0 web site: > > http://www.python.org/download/releases/3.0/ > > See PEP 361 for release schedule details: > > http://www.python.org/dev/peps/pep-0361/ > > Enjoy, > - -Barry > > Barry Warsaw > [EMAIL PROTECTED] > Python 2.6/3.0 Release Manager > (on behalf of the entire python-dev team) > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIrN472YZpQepbvXERAl4fAJ9QxHhSn/jYdA3lCYvgfXRhBVV2pgCfdNUx > 3NTlSrsSULxXhoMqiNmUMSg= > =Z4+y > -END PGP SIGNATURE- > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.6b3 and 3.0b3
I've downloaded the Python 2.6b3 source, exported with svn all external packages as stated in PCBuild/Readme.txt, edited external.bat removing DEBUG=1, ran external.bat to get tcl/tk compiled, set "Release" on Visual C++ Express Edition 2008, and everything seemed to be worked out fine (on Vista Ultimate x64), but running python (both from VSC++ or by command prompt) and trying to import Tkinter I've got this: >>> import Tkinter Traceback (most recent call last): File "", line 1, in File "c:\tmp\Python-2.6b3\lib\lib-tk\Tkinter.py", line 38, in import FixTk File "c:\tmp\Python-2.6b3\lib\lib-tk\FixTk.py", line 28, in import _tkinter ImportError: DLL load failed: Impossibile trovare il modulo specificato. It seems that its impossible to find the _tkinter module, but in PCbuild I've found these files: 21/08/2008 10.35 636 _tkinter.exp 21/08/2008 10.35 1.732 _tkinter.lib 21/08/2008 10.35 338.944 _tkinter.pdb 21/08/2008 10.3534.304 _tkinter.pyd 19/03/2008 08.45 9.569 _tkinter.vcproj 21/08/2008 10.33 2.577 _tkinter.vcproj.Conan.Cesare.user All other external packages (sqlite3, bsddb and socket.ssl) works well. Any idea? Cesare On Wed, Aug 20, 2008 at 10:17 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On behalf of the Python development team and the Python community, I am happy > to announce the third and last planned beta releases of Python 2.6 and Python > 3.0. > > Please note that these are beta releases, and as such are not suitable for > production environments. We continue to strive for a high degree of quality, > and these releases are intended to freeze the feature set for Python 2.6 and > 3.0. > > As these are the last planned beta releases, we strongly urge you to download > these releases and test them against your code. Once we reach release > candidates (currently planned for 03-Sep-2008), only highly critical bugs will > be fixed before the final release. > > If you find things broken or incorrect, please submit bug reports at > > http://bugs.python.org > > For more information and downloadable distributions, see the Python > 2.6 website: > > http://www.python.org/download/releases/2.6/ > > and the Python 3.0 web site: > > http://www.python.org/download/releases/3.0/ > > See PEP 361 for release schedule details: > > http://www.python.org/dev/peps/pep-0361/ > > Enjoy, > - -Barry > > Barry Warsaw > [EMAIL PROTECTED] > Python 2.6/3.0 Release Manager > (on behalf of the entire python-dev team) > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIrN472YZpQepbvXERAl4fAJ9QxHhSn/jYdA3lCYvgfXRhBVV2pgCfdNUx > 3NTlSrsSULxXhoMqiNmUMSg= > =Z4+y > -END PGP SIGNATURE- > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 2.6b3 and 3.0b3
On Thu, Aug 21, 2008 at 7:09 AM, Cesare Di Mauro <[EMAIL PROTECTED]> wrote: > import Tkinter > Traceback (most recent call last): > File "", line 1, in > File "c:\tmp\Python-2.6b3\lib\lib-tk\Tkinter.py", line 38, in >import FixTk > File "c:\tmp\Python-2.6b3\lib\lib-tk\FixTk.py", line 28, in >import _tkinter > ImportError: DLL load failed: Impossibile trovare il modulo specificato. > > It seems that its impossible to find the _tkinter module, but in PCbuild > I've found these files: > > 21/08/2008 10.3534.304 _tkinter.pyd The most likely explanation for this is that _tkinter.pyd has a static dependency that can't be loaded. If, for instance, the TCL and TK DLLs themselves are neither in PCbuild nor elsewhere in the path, then you wouldn't be able to load _tkinter. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 2.6b3 and 3.0b3
Thank you for the hint: it works. :) Cesare In data 21 agosto 2008 alle ore 17:34:56, Curt Hagenlocher <[EMAIL PROTECTED]> ha scritto: > On Thu, Aug 21, 2008 at 7:09 AM, Cesare Di Mauro > <[EMAIL PROTECTED]> wrote: >> > import Tkinter >> Traceback (most recent call last): >> File "", line 1, in >> File "c:\tmp\Python-2.6b3\lib\lib-tk\Tkinter.py", line 38, in >>import FixTk >> File "c:\tmp\Python-2.6b3\lib\lib-tk\FixTk.py", line 28, in >>import _tkinter >> ImportError: DLL load failed: Impossibile trovare il modulo specificato. >> >> It seems that its impossible to find the _tkinter module, but in PCbuild >> I've found these files: >> >> 21/08/2008 10.3534.304 _tkinter.pyd > > The most likely explanation for this is that _tkinter.pyd has a static > dependency that can't be loaded. If, for instance, the TCL and TK > DLLs themselves are neither in PCbuild nor elsewhere in the path, then > you wouldn't be able to load _tkinter. > > -- > Curt Hagenlocher > [EMAIL PROTECTED] > -- Dott. Cesare Di Mauro A-Tono S.r.l. T.: (+39)095-7365314 Information in this email is confidential and may be privileged. It is intended for the addresses only. If you have received it in error, please notify the sender immediately and delete it from your system. You should not otherwise copy it, retransmit it or use or disclose its content to anyone. Thank you for your co-operation. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 on AMD64 recusion crash
Mark Hammond skippinet.com.au> writes: > > However, test_cpickle takes a different path and doesn't see this doubling of > the count - therefore dieing at the depth of 629 that I can see. 629 is a very low number, far lower than the default recursion limit of 1000. Please open a bug for the problem. > My solution to this was to simply double the stack size for the executables > in 64bit builds, from 2MB to 4MB (2.1 and 4.2 for debug builds.) Is this an > appropriate fix? Unless this can be set in the configure script for all affected architectures, I'm not sure this is ok. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Unicode 5.1.0
I was just paid a visit by my Google colleague Mark Davis, co-founder of the Unicode project and the president of the Unicode Consortium. He would like to see improved Unicode support for Python. (Well duh. :-) On his list of top priorities are: 1. Upgrade the unicodata module to the Unicode 5.1.0 standard 2. Extende the unicodedata module with some additional properties 3. Add support for Unicode properties to the regex syntax, including Boolean combinations I've tried to explain our release schedule and no-new-features-in-point-releases policies to him, and he understands that it's too late to add #2 or #3 to 2.6 and 3.0, and that these will have to wait for 2.7 and 3.1, respectively. However, I've kept the door sligthtly ajar for adding #1 -- it can't be too much work and it can't have too much impact. Or can it? I don't actually know what the impact would be, so I'd like some impact from developers who are closer to the origins of the unicodedata module. The two, quite separate, questions, then, are (a) how much work would it be to upgrade to version 5.1.0 of the database; and (b) would it be acceptable to do this post-beta3 (but before rc1). If the answer to (b) is positive, Google can help with (a). In general, Google has needs in this area that can't wait for 2.7/3.1, so what we may end up doing is create internal implementations of all three features (compatible with Python 2.4 and later), publish them as open source on Google Code, and fold them into core Python at the first opportunity, which would likely be 2.7 and 3.1. Comments? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
On 2008-08-21 22:35, Guido van Rossum wrote: I was just paid a visit by my Google colleague Mark Davis, co-founder of the Unicode project and the president of the Unicode Consortium. He would like to see improved Unicode support for Python. (Well duh. :-) On his list of top priorities are: 1. Upgrade the unicodata module to the Unicode 5.1.0 standard 2. Extende the unicodedata module with some additional properties 3. Add support for Unicode properties to the regex syntax, including Boolean combinations I've tried to explain our release schedule and no-new-features-in-point-releases policies to him, and he understands that it's too late to add #2 or #3 to 2.6 and 3.0, and that these will have to wait for 2.7 and 3.1, respectively. However, I've kept the door sligthtly ajar for adding #1 -- it can't be too much work and it can't have too much impact. Or can it? I don't actually know what the impact would be, so I'd like some impact from developers who are closer to the origins of the unicodedata module. The two, quite separate, questions, then, are (a) how much work would it be to upgrade to version 5.1.0 of the database; and (b) would it be acceptable to do this post-beta3 (but before rc1). If the answer to (b) is positive, Google can help with (a). In general, Google has needs in this area that can't wait for 2.7/3.1, so what we may end up doing is create internal implementations of all three features (compatible with Python 2.4 and later), publish them as open source on Google Code, and fold them into core Python at the first opportunity, which would likely be 2.7 and 3.1. Comments? There are two things to consider: unicodedata is just an optimized database for accessing code point properties of a specific Unicode version (currently 4.1.0 and 3.2.0). Adding support for a new version needs some work on the generation script, perhaps keeping the 4.1.0 version of it like we did for 3.2.0, but that's about it. However, there are other implications to consider when moving to Unicode 5.1.0. Just see the top of http://www.unicode.org/versions/Unicode5.1.0/ for a summary of changes compared to 5.0, plus http://www.unicode.org/versions/Unicode5.0.0/ for changes between 4.1.0 and 5.0. So while we could say: "we provide access to the Unicode 5.1.0 database", we cannot say: "we support Unicode 5.1.0", simply because we have not reviewed the all the necessary changes and implications. I think it's better to look through all the changes and then come up with proper support for 2.7/3.1. If Google wants to contribute to this, even better. To avoid duplication of work or heading in different directions, it may be a good idea to create a unicode-sig to discuss things. Offline 'til next week-ly, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 21 2008) >>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?
"Jesse Noller" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Tue, Aug 19, 2008 at 1:28 PM, Bill Janssen <[EMAIL PROTECTED]> wrote: > My understanding is that if there is a system Python, you shouldn't > change it. Ever. Huge, big, honkin' +1 from me on that. Besides, for a system Python, you want your distribution to manage packages, not setuptools, otherwise you confuse -- and probably break -- your system. I find this discussion fascinating. I install new packages into my system Python all the time, with "/usr/bin/python setup.py install", and that includes setuptools. I've got PIL, ReportLab, Twisted, Xlib, appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen, roman, setuptools, and SSL installed in the Leopard machine I'm writing from. They don't wind up in /System/Library/.../site-packages/, they wind up in /Library/Python/2.5/site-packages/, which is sort of the right place, from an Apple point of view. I do this on lots of Macs -- I've got a regular posse of them at work. And I've never had any problems with it. I agree that there are some things I'd be very wary of installing into the system Python, like PyObjC, and Zope. Usually, I don't install anything which appears to already be there. Bill Bill is correct - using /usr/bin/python does install packages to /Library/... - this is sort of the right place because it still installs it to a "system path", where it can side-effect other users, but it is a "mostly correct" way for Apple framework installs. /Library is system-wide, yes, but not system-reserved. /System/Library/ is system-wide and system reserved. Just like on most distros (LFS and some older distros excluded): /usr/ is system-wide and system-reserved. /usr/local/ is sytem-wide, but not system-reserved. Computer admins are supposed to install into /Library/ or /usr/local/. The only possible problem of installing new Python modules into /Library/ is if any system Python scripts that depend on exact versions of libraries shipped in /System/Library/, but were not crafted as to ignore /Library/. That can be problematic, and arguablly a bug in the script, but Apple does not tend to fix those bugs that quickly. (OS bugs is one area where Apple's traditional secrecy is a bad thing. More transparency in bug fixing can only be an improvement.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
Guido van Rossum wrote: I was just paid a visit by my Google colleague Mark Davis, co-founder of the Unicode project and the president of the Unicode Consortium. He would like to see improved Unicode support for Python. (Well duh. :-) On his list of top priorities are: 1. Upgrade the unicodata module to the Unicode 5.1.0 standard 2. Extende the unicodedata module with some additional properties 3. Add support for Unicode properties to the regex syntax, including Boolean combinations I've tried to explain our release schedule and no-new-features-in-point-releases policies to him, and he understands that it's too late to add #2 or #3 to 2.6 and 3.0, and that these will have to wait for 2.7 and 3.1, respectively. However, I've kept the door sligthtly ajar for adding #1 -- it can't be too much work and it can't have too much impact. Or can it? I don't actually know what the impact would be, so I'd like some impact from developers who are closer to the origins of the unicodedata module. The two, quite separate, questions, then, are (a) how much work would it be to upgrade to version 5.1.0 of the database; and (b) would it be acceptable to do this post-beta3 (but before rc1). If the answer to (b) is positive, Google can help with (a). http://www.unicode.org/versions/Unicode5.1.0/ "Unicode 5.1.0 contains over 100,000 characters, and provides significant additions and improvements..." to existing features, including new files and upgrades to existing files. Sounds close to adding features ;-) In general, Google has needs in this area that can't wait for 2.7/3.1, so what we may end up doing is create internal implementations of all three features (compatible with Python 2.4 and later), publish them as open source on Google Code, and fold them into core Python at the first opportunity, which would likely be 2.7 and 3.1. If possible, I would suggest going a bit further and release a '3rd' party replacement/extension package, including a Windows installer, that is also listed on PyPI. Revised releases could and might need to be done even more rapidly than the bugfix release schedule would allow. (This could be done with other proposed new/revised modules also.) What would need to be done now, I believe, if possible and acceptable, it to slightly repackage the core to put unicode (3.0 strings) and _re* code in a separate library so that they can be drop-in replaced or masked. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 on AMD64 recusion crash
Antoine writes: > Mark Hammond skippinet.com.au> writes: > > > > However, test_cpickle takes a different path and doesn't see this > doubling of > > the count - therefore dieing at the depth of 629 that I can see. > > 629 is a very low number, far lower than the default recursion limit of > 1000. Yes, exactly - that is the point. If we got to 1000 Python would have prevented us going any further. As it was, we ran out of stack space at 629. I believe that this is the only path that allows us to go past an *actual* recursion level of 1/2 the nominated maximum value due to that other regression I mentioned. > Please open a bug for the problem. http://bugs.python.org/issue3640 > > My solution to this was to simply double the stack size for the > > executables > > in 64bit builds, from 2MB to 4MB (2.1 and 4.2 for debug builds.) Is > > this an appropriate fix? > > Unless this can be set in the configure script for all affected > architectures, I'm not sure this is ok. IIUC, each platform and architecture has its own stack requirements, so therefore it is the responsibility of that platform to ensure enough stack is available for a depth of 1000. The 32bit windows versions of Python do exactly this and nominate 2MB, which the 64bit builds inherited. It seems 2MB isn't enough for 64bit Windows, and doubling it seemed like a fairly safe way to go. So while other 64bit platforms may well need adjusting if they use the same values as their 32bit versions, that is independent of what Windows 64bit builds need to do. Obviously, all IIUC Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
On Thu, Aug 21, 2008 at 2:26 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > On 2008-08-21 22:35, Guido van Rossum wrote: >> >> I was just paid a visit by my Google colleague Mark Davis, co-founder >> of the Unicode project and the president of the Unicode Consortium. He >> would like to see improved Unicode support for Python. (Well duh. :-) >> On his list of top priorities are: >> >> 1. Upgrade the unicodata module to the Unicode 5.1.0 standard >> 2. Extende the unicodedata module with some additional properties >> 3. Add support for Unicode properties to the regex syntax, including >> Boolean combinations >> >> I've tried to explain our release schedule and >> no-new-features-in-point-releases policies to him, and he understands >> that it's too late to add #2 or #3 to 2.6 and 3.0, and that these will >> have to wait for 2.7 and 3.1, respectively. However, I've kept the >> door sligthtly ajar for adding #1 -- it can't be too much work and it >> can't have too much impact. Or can it? I don't actually know what the >> impact would be, so I'd like some impact from developers who are >> closer to the origins of the unicodedata module. >> >> The two, quite separate, questions, then, are (a) how much work would >> it be to upgrade to version 5.1.0 of the database; and (b) would it be >> acceptable to do this post-beta3 (but before rc1). If the answer to >> (b) is positive, Google can help with (a). >> >> In general, Google has needs in this area that can't wait for 2.7/3.1, >> so what we may end up doing is create internal implementations of all >> three features (compatible with Python 2.4 and later), publish them as >> open source on Google Code, and fold them into core Python at the >> first opportunity, which would likely be 2.7 and 3.1. >> >> Comments? > > There are two things to consider: > > unicodedata is just an optimized database for accessing code > point properties of a specific Unicode version (currently 4.1.0 > and 3.2.0). Adding support for a new version needs some work on > the generation script, perhaps keeping the 4.1.0 version of it > like we did for 3.2.0, but that's about it. > > However, there are other implications to consider when moving to > Unicode 5.1.0. > > Just see the top of http://www.unicode.org/versions/Unicode5.1.0/ > for a summary of changes compared to 5.0, plus > http://www.unicode.org/versions/Unicode5.0.0/ for changes between > 4.1.0 and 5.0. > > So while we could say: "we provide access to the Unicode 5.1.0 > database", we cannot say: "we support Unicode 5.1.0", simply because > we have not reviewed the all the necessary changes and implications. Mark's response to this was: """ I'd suspect that you'll be as conformant to U5.1.0 as you were to U4.1.0 ;-) More seriously, I don't think this is a roadblock -- I doubt that there are real differences between U5.1.0 and U4.10 in terms of conformance that would be touched by Python -- the conformance changes tend to be either completely backward compatible or very esoteric. What I can do is to review the Python support to see if and where there are any problems, but I wouldn't anticipate any. """ Which suggests that he believes that the differences in the database are very minor, and that upgrading just the database would not cause any problems for code that worked well with the 4.1.0 database. > I think it's better to look through all the changes and then come > up with proper support for 2.7/3.1. If Google wants to contribute > to this, even better. To avoid duplication of work or heading in > different directions, it may be a good idea to create a > unicode-sig to discuss things. Not me. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
