Mailman 3 October 2002 - Python-Dev

Non-ASCII characters in test_pep277.py in 2.3
by Guido van Rossum Oct. 9, 2002

Oct. 9, 2002

The file pep_2777.py uses an encoding cookie that specifies UTF-8. Unfortunately my toolchain doesn't know about this, and displays it as Latin-1. Since the only UTF-8 is in 8-bit string literals (not Unicode literals), wouldn't it make more sense to drop the encoding cookie and use \xXX escapes in those literals? I'm not even sure this use is legal in phase 2 of PEP 263. --Guido van Rossum (home page: http://www.python.org/~guido/)

9 30

Re: [snake-farm] Re: [farm-report] Daily Snake Farm report
by Neal Norwitz Oct. 9, 2002

Oct. 9, 2002

On Wed, Oct 09, 2002 at 03:59:29AM -0400, Tim Peters wrote: > [Anders Qvist] > > ... > > check_all("ntpath") > > File "../../python/dist/src/Lib/test/test___all__.py", line 15, > > in check_all > > exec "import %s" % modname in names > > File "<string>", line 1, in ? > > File "/home/quest/tmp/compile- > > python/python/dist/src/Lib/ntpath.py", line 482, in ? > > supports_unicode_filenames = sys.getwindowsversion()[3] >= 2 > > AttributeError: 'module' object has no attribute 'getwindowsversion' > > Grrr. I expect I just fixed this, but can't test it now on Linux for > you. The person who checked this change in probably didn't realize > that ntpath was imported on any system other than Windows. I'm > surprised the bug went uncaught for so long! (Ya, it was less than a > day, but still ...) :-) I've been running 2.2.2 only. I just tried to run 2.3 and had some problems. __all__ is ok, though. The first problem is in regrtest. This exception causes regrtest to crash. test_pyexpat Traceback (most recent call last): File "./Lib/test/regrtest.py", line 877, in ? main() File "./Lib/test/regrtest.py", line 229, in main ok = runtest(test, generate, verbose, quiet, testdir) File "./Lib/test/regrtest.py", line 392, in runtest output = cfp.getvalue() File "/home/neal/build/python/dist/src/Lib/StringIO.py", line 195, in getvalue self.buf += ''.join(self.buflist) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in position 36: ordinal not in range(128) I put a try/except around line 392 in regrtest and then had 2 failures: test_pyexpat had no output (the unicode problem I guess) and test_rotor: test test_rotor produced unexpected output: ********************************************************************** *** mismatch between lines 2-3 of expected output and lines 2-3 of actual output: - '\xb5q\x90\xa3\xe8IT\xd1\x07\xda\x1d\xdc\xdf' + 'qqqqq\x90 ... Some unicode problem complaining about these 2 chars: \xcb and \xe2 which are printed as e umlaut and e circumflex. Maybe this is just me again though? Neal

5 8

Re: [Python-Dev] Tests failing in MacPython 2.2.2
by Michael Hudson Oct. 9, 2002

Oct. 9, 2002

barry(a)python.org (Barry A. Warsaw) writes: > >>>>> "JJ" == Jack Jansen <Jack.Jansen(a)oratrix.com> writes: > > JJ> Aside from the usual suspects I have three tests failing in > JJ> MacPython 2.2.2: test_atexit, test_email and test_httplib. > > Oops, looks like I'm also getting a segfault in test_re. This is normal; run "ulimit -s 2048" before running the test suite. Cheers, M. -- please realize that the Common Lisp community is more than 40 years old. collectively, the community has already been where every clueless newbie will be going for the next three years. so relax, please. -- Erik Naggum, comp.lang.lisp

3 2

Issue with 2.2.2b1 and MinGW-2.0
by David Abrahams Oct. 9, 2002

Oct. 9, 2002

So I thought I'd try testing the latests Boost.Python with 2.2.2 and ALL of the compilers I have available to me this morning, and it turned up this interesting data point: What I get from the Windows installer differs from what I get when I build Python using MS Visual Studio 6 in a way that affects whether MinGW-2.0 can link extension modules with it out-of-the-box. The one that I get from the installer fails to link (errors below) unless I make the magic incantations specified here: http://www.python.org/doc/current/inst/non-ms-compilers.html#SECTION0003120… The one that I build myself works just fine "out-of-the-box". --- These were the link errors I got from MinGW-2.0 g++ using the Python I got from the Windows installer: Creating library file: c:\build\libs\python\build\bin\boost_python.dll\mingw-2.0\debug\runtime-link-dynamic\boost_python.lib c:\build\libs\python\build\bin\boost_python.dll\mingw-2.0\debug\runtime-link-dynamic\numeric.obj: In function `ZN5boost6python7numeric53_GLOBAL__N_.._.._.._libs_python_src_numeric.cpp2dT8hb18throw_load_failureEv': c:/boost/libs/python/test/../../../libs/python/src/numeric.cpp:29: undefined reference to `_imp__PyExc_ImportError' c:\build\libs\python\build\bin\boost_python.dll\mingw-2.0\debug\runtime-link-dynamic\numeric.obj: In function `ZN5boost6python7numeric53_GLOBAL__N_.._.._.._libs_python_src_numeric.cpp2dT8hb4loadEb': c:/boost/libs/python/test/../../../libs/python/src/numeric.cpp:57: undefined reference to `_imp__PyType_Type' c:/boost/libs/python/test/../../../libs/python/src/numeric.cpp:57: undefined reference to `_imp__PyType_Type' c:\build\libs\python\build\bin\boost_python.dll\mingw-2.0\debug\runtime-link-dynamic\list.obj: In function `ZN5boost6python6detail9list_base4callERKNS0_3api6objectE': c:/boost/libs/python/test/../../../libs/python/src/list.cpp:12: undefined reference to `_imp__PyList_Type' c:\build\libs\python\build\bin\boost_python.dll\mingw-2.0\debug\runtime-link-dynamic\list.obj: In function `ZN5boost6python6detail9list_base6appendERKNS0_3api6objectE': c:/boost/libs/python/test/../../../libs/python/src/list.cpp:29: undefined reference to `_imp__PyList_Type' c:\build\libs\python\build\bin\boost_python.dll\mingw-2.0\debug\runtime-link-dynamic\list.obj: In function `ZN5boost6python6detail9list_base6insertEiRKNS0_3api6objectE': c:/boost/libs/python/test/../../../libs/python/src/list.cpp:65: undefined reference to `_imp__PyList_Type' c:\build\libs\python\build\bin\boost_python.dll\mingw-2.0\debug\runtime-link-dynamic\list.obj: In function `ZN5boost6python6detail9list_base7reverseEv': c:/boost/libs/python/test/../../../libs/python/src/list.cpp:106: undefined reference to `_imp__PyList_Type' c:\build\libs\python\build\bin\boost_python.dll\mingw-2.0\debug\runtime-link-dynamic\list.obj: In function `ZN5boost6python6detail9list_base4sortEv': c:/boost/libs/python/test/../../../libs/python/src/list.cpp:119: undefined reference to `_imp__PyList_Type' c:\build\libs\python\build\bin\boost_python.dll\mingw-2.0\debug\runtime-link-dynamic\long.obj: In function `ZN5boost6python6detail9long_base4callERKNS0_3api6objectE': c:/boost/libs/python/test/../../../libs/python/src/long.cpp:12: undefined reference to `_imp__PyLong_Type' c:\build\libs\python\build\bin\boost_python.dll\mingw-2.0\debug\runtime-link-dynamic\long.obj: In function `ZN5boost6python6detail9long_base4callERKNS0_3api6objectES6_': -- David Abrahams * Boost Consulting dave(a)boost-consulting.com * http://www.boost-consulting.com

2 2

Snapshot win32all builds of interest?
by Mark Hammond Oct. 9, 2002

Oct. 9, 2002

I'm wondering if there is any interest in me making regular, basically untested win32all builds against the current Python CVS tree? It would be fairly simple for me to do - I run against CVS Python, so it is really just bundling up my latest built files into an installer .EXE. I would only do it for the current CVS trunk - ie, no Python 2.2 or earlier builds in this form. However, I would only bother if there were people willing to use it. I figure that if there aren't people in this forum who would use it, I won't find them anywhere ;) OTOH, people in this forum using CVS Python on Windows may prefer to use CVS and build their own win32all - I really have no clue ;) Thoughts? Mark.

5 5

test_locale failing on MacOSX w/ 2.2.2
by Skip Montanaro Oct. 9, 2002

Oct. 9, 2002

Just got this test failure this morning on MacOS 10.2 running w/ 2.2.2 from CVS (or very nearly so): % ./python.exe ../Lib/test/regrtest.py test_locale test_locale test test_locale produced unexpected output: ********************************************************************** *** lines 2-4 of actual output doesn't appear in expected output after line 1: + '%f' % 1024 == '1024.000000' != '1,024.000000' + '%+10.f' % -4200 == ' -4200' != ' -4,200' + '%-10.f' % 4200 == '4200 ' != '4,200 ' ********************************************************************** Skip

2 1

read-only properties
by David Abrahams Oct. 9, 2002

Oct. 9, 2002

I was just working on some docs for Boost.Python and thought I'd write down what happens when you try to write to a read-only property (I use properties to expose C++ data members among other things). So: >>> class X(object): ... def get(self): return 'x' ... l = property(get) ... >>> x = X() >>> x.l 'x' >>> x.l = 1 Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: can't set attribute This struck me as a very poor error message, given that mechanism in Boost.Python v1 used to say: Traceback (innermost last): File "<string>", line 1, in ? AttributeError: 'l' attribute is read-only Is it worth doing something about this? -- David Abrahams * Boost Consulting dave(a)boost-consulting.com * http://www.boost-consulting.com

4 4

segmentation fault with python2.3a0 from cvs
by Gerson.Kurz＠t-online.de Oct. 8, 2002

Oct. 8, 2002

Hi folks, yesterday I posted a problem with importing a very large sourcefile in python 2.2.1 to clp. For the original report, see <news:3da070ec.18868296@news.t-online.de>. Andrew MacIntyre suggested that 2.3 would handle this situation much better, so I got the current version from CVS, built it with cygwin and tested it. Now, instead of just a MemoryError, I get this: $ python Python 2.3a0 (#1, Oct 7 2002, 18:49:14) [GCC 2.95.3-5 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more informatio >>> import test Traceback (most recent call last): Segmentation fault (core dumped) The stackdump reads Exception: STATUS_ACCESS_VIOLATION at eip=61045659 eax=1A013E68 ebx=610C02D0 ecx=610C02D0 edx=0022E6F8 esi=0022E6F8 edi=1A013E68 ebp=0022E6B0 esp=0022E698 program=C:\cygwin\usr\local\bin\python2.3.exe cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023 Stack trace: Frame Function Args 0022E6B0 61045659 (0022E6F8, 0022EE78, 0022F1A4, 0022F1A8) 0022E820 61048989 (1A010000, 0022ECE8, 0022EE78, 0022F1A4) 0022EE10 610462BA (00000000, 00010000, 0022EE40, 610BD2CB) 0022EE40 610096F7 (616800F4, 00000003, 0A032B14, 00000000) 0022F1F0 61071CAF (0A032B14, 00010000, 000001B6, 610AA142) 0022F210 610ACFC6 (610BF030, 0A032B14, 00010000, 000001B6) 0022F240 6109EEA8 (610BF030, 0A032B14, 6B2C525A, 6B241813) 0022F260 6109EF51 (0A032B14, 6B2C525A, 0A0113E0, 61070534) 0022FB90 6B2C52D1 (0A01D090, 0A032B14, 00000001, 0A043994) 0022FBE0 6B2C5795 (0A0358EC, 0A01D090, 0022FC40, 6B2C1861) 0022FC40 6B2C1897 (0A015DDC, 0A0229EC, 0A0358EC, 6B278D43) 0022FC70 6B2C4C8E (00000000, 0A027AA4, 0022FCC0, 6B2BEA4C) 0022FCB0 6B26BC4D (0A01BA2C, 0A027AA4, 00000000, 6B2BF4F5) 0022FCE0 6B248486 (0A01BA2C, 0A027AA4, 00000000, 6B2C4AE7) 0022FD10 6B29F082 (0A01BA2C, 0A027AA4, 00000000, 6B2C15D2) 0022FD70 6B2C15E1 (00000001, 6B2C9115, 0022FDE0, 6B2C0D25) End of stack trace (more stack frames may be present) So I guess its back in your (aka Developers) corner. You can download the source that causes this at http://p-nand-q.com/python/toobigfor2.3.zip but beware, the zipped source is 613k large (unzipped around 4.2 mb). Bye, Gerson Kurz http://p-nand-q.com

7 20

tests failing in 2.2.2
by Neal Norwitz Oct. 8, 2002

Oct. 8, 2002

Is anyone else having problems with 2.2.2 tests? minidom & sax fail for me on Linux: test_sax test test_sax skipped -- cannot import name quoteattr test_minidom Traceback (most recent call last): File "Lib/test/test_minidom.py", line 636, in ? func() File "Lib/test/test_minidom.py", line 208, in testAAA "setAttribute() sets ownerDocument") File "Lib/test/test_minidom.py", line 22, in confirm raise Exception Exception I'm off for a long weekend. I'll be back late Monday. Neal

5 8

Re: [Python-Dev] tests failing in 2.2.2
by Tim Peters Oct. 8, 2002

Oct. 8, 2002

[Neal Norwitz] > The original problem was actually 1e9. Which is about maxint/2, which I checked in. > The test is somewhat dubious, so anything to reduce the problems > would be good. Perhaps the test should just be removed? So long as it's testing Python's overflow-checking code instead of the platform realloc(), it should be fine. It's probably still dubious on Win64 (where sys.maxint is still 2**31-1), but should be fine everywhere else). I'll worry about Win64 when somebody runs it <1/64 wink>.

1 0