Mailman 3 September 2002 - Python-Dev

Re: [Python-checkins] python/dist/src/Tools/freeze extensions_win32.ini,1.5,1.6
by Michael Hudson 24 Sep '02

24 Sep '02

mhammond(a)users.sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Tools/freeze > In directory usw-pr-cvs1:/tmp/cvs-serv26120 > > Modified Files: > extensions_win32.ini > Log Message: > Patch 574531/Bug 574570 - allow freeze on windows to use the _winreg > extension. Is this a bugfix? Cheers, M. -- This is an off-the-top-of-the-head-and-not-quite-sober suggestion, so is probably technically laughable. I'll see how embarassed I feel tomorrow morning. -- Patrick Gosling, ucam.comp.misc

1 0

Python 2.2.2 Wiki
by Skip Montanaro 24 Sep '02

24 Sep '02

For folks interested in 2.2.2, I created an empty Wiki available at http://manatee.mojam.com/py222wiki/ I did *nothing* other than set it up. I don't know how people want to use the Wiki. Feel free to organize it any way you want, or give me some clues and I'll take a crack at a top-level structure. Michael McLay had suggested: >> Perhaps Wiki pages would be a good mechanism for collaboration on the >> classification of patches. Create one page for each classification >> type and then use the patch names and title as section titles within >> the page. What are the classification types he referred to? Skip

2 2

-zcombreloc
by Andrew Koenig 24 Sep '02

24 Sep '02

I now believe, after discussion with the binutils developers, that the problem is that -zcombreloc just plain doesn't work in any release of binutils. One implication of this fact is that turning on -znocombreloc when building python is insufficient to make it work if you built gcc with -zcombreloc, because that build will write dynamic libraries that the Sun loader cannot handle no matter what. So I think you are right -- the correct fix is to warn people that they should not use binutils 2.13 on Solaris, period. I believe that they will fix the problem in 2.13.1 and will let you know. Meanwhile, might I suggest including the following test somewhere in the build procedure? If it fails, I believe it will not be possible to build Python successfully, so one might as well find about it early.... If you run this and the output includes "core dumped', it failed :-) -------------------------cut here---------------------- #! /bin/sh mkdir /tmp/t.$$ || exit 3 cd /tmp/t.$$ || exit 3 cat >main.c <<'EOF' #include <stdio.h> #include <dlfcn.h> int main(void) { void *handle, *sym; char *error; puts("calling dlopen"); handle = dlopen("./dyn.so", RTLD_NOW); if (!handle) { printf("%s\n", dlerror()); return 1; } puts("calling dlsym"); sym = dlsym(handle, "sym"); if ((error = dlerror()) != 0) { printf("%s\n", error); return 1; } puts("calling sym"); ((void (*)(void))sym)(); puts("done"); return 0; } EOF cat >dyn.c <<'EOF' #include <stdio.h> void sym(void) { puts("in sym"); } EOF [ -n "$SHFLAGS" ] || SHFLAGS="-fPIC -shared" [ -n "$CC" ] || CC=gcc set -x $CC $CFLAGS $SHFLAGS dyn.c -o dyn.so $CC $CFLAGS main.c -o main -ldl ./main || exit $? cd /tmp rm -rf t.$$

2 2

Re: [Python-Dev] Re: ATTENTION! Releasing Python 2.2.2 in a few weeks
by Guido van Rossum 24 Sep '02

24 Sep '02

Skip, where's your 2.2.2 Wiki? (Or should we just pick a page name in the moinmoin on python.org?) I've backported the following items to 2.2.2, most of which were my responsibility and/or 64-bit issues needed for the snake farm: ---------------------------------------------------------------------- Modified Files: Tag: release22-maint regrtest.py Log Message: Backport 1.96 from trunk (because I want Xenofarm to test 2.2.2): Add a bunch of sys.stdout.flush() calls that will hopefully improve the usability of the output of the Xenofarm builds. ---------------------------------------------------------------------- Modified Files: Tag: release22-maint unicodeobject.c Log Message: Backport 2.166 from trunk: Fix SF bug 599128, submitted by Inyeol Lee: .replace() would do the wrong thing for a unicode subclass when there were zero string replacements. The example given in the SF bug report was only one way to trigger this; replacing a string of length >= 2 that's not found is another. The code would actually write outside allocated memory if replacement string was longer than the search string. ---------------------------------------------------------------------- Modified Files: Tag: release22-maint test_unicode.py Log Message: Backport 1.56 and 1.68 from trunk: 1.56: Apply diff3.txt from SF patch http://www.python.org/sf/536241 If a str or unicode method returns the original object, make sure that for str and unicode subclasses the original will not be returned. This should prevent SF bug http://www.python.org/sf/460020 from reappearing. 1.68: Fix SF bug 599128, submitted by Inyeol Lee: .replace() would do the wrong thing for a unicode subclass when there were zero string replacements. The example given in the SF bug report was only one way to trigger this; replacing a string of length >= 2 that's not found is another. The code would actually write outside allocated memory if replacement string was longer than the search string. ---------------------------------------------------------------------- Modified Files: Tag: release22-maint structmodule.c Log Message: Backport 2.57 from trunk: (Most of) SF patch 601369 (Christos Georgiou): obmalloc,structmodule: 64bit, big endian (issue 2 only). This adds a bunch of memcpy calls via a temporary variable to avoid alignment errors. That's needed for some platforms. ---------------------------------------------------------------------- Modified Files: Tag: release22-maint test_b1.py Log Message: Backport 1.51 and 1.54 from trunk. 1.51: Bug #556025: list(xrange(1e9)) --> seg fault Close the bug report again -- this time for Cygwin due to a newlib bug. See the following for the details: http://sources.redhat.com/ml/newlib/2002/msg00369.html Note that this commit is only a documentation (i.e., comment) change. 1.54: The list(xrange(sys.maxint / 4)) test blew up on 64-bit platforms. Because ob_size is a 32-bit int but sys.maxint is LONG_MAX which is a 64-bit value, there's no way to make this test succeed on a 64-bit platform. So just skip it when sys.maxint isn't 0x7fffffff. ---------------------------------------------------------------------- Modified Files: Tag: release22-maint intobject.c Log Message: Backport 2.93 from trunk: Insert an overflow check when the sequence repetition count is outside the range of ints. The old code would pass random truncated bits to sq_repeat() on a 64-bit machine. ---------------------------------------------------------------------- Modified Files: Tag: release22-maint unicodeobject.c stringobject.c Log Message: Backport from trunk: unicodeobject.c 2.169 stringobject.c 2.189 Fix warnings on 64-bit platforms about casts from pointers to ints. Two of these were real bugs. ---------------------------------------------------------------------- Modified Files: Tag: release22-maint exceptions.c Log Message: Backported 1.39 and 1.40 from trunk: 1.39: Fix SF bug 610610 (reported by Martijn Pieters, diagnosed by Neal Norwitz). The switch in Exception__str__ didn't clear the error if PySequence_Size() raised an exception. Added a case -1 which clears the error and falls through to the default case. 1.40: Two more cases of switch(PySequence_Size()) without checking for case -1. (Same problem as last checkin for SF bug 610610) Need to clear the error and proceed. ---------------------------------------------------------------------- Note that I've been careful to vary the formatting of my log messages a bit. :-) Michael Hudson backported a bunch of things too. I notice a test suite failure with rfc822 as a result of these. Michael, did you run the test suite? FAILED (errors=1) Traceback (most recent call last): File "../Lib/test/test_rfc822.py", line 211, in ? test_main() File "../Lib/test/test_rfc822.py", line 207, in test_main test_support.run_unittest(MessageTestCase) File "../Lib/test/test_support.py", line 180, in run_unittest run_suite(unittest.makeSuite(testclass), testclass) File "../Lib/test/test_support.py", line 175, in run_suite raise TestFailed(err) test_support.TestFailed: Traceback (most recent call last): File "../Lib/test/test_rfc822.py", line 199, in test_parseaddr eq(rfc822.parseaddr('<>'), ('', '')) File "/home/guido/branch-2.2/Lib/rfc822.py", line 491, in parseaddr list = a.addresslist AttributeError: AddrlistClass instance has no attribute 'addresslist' --Guido van Rossum (home page: http://www.python.org/~guido/)

4 3

Re: [Python-Dev] PEP 282 Implementation
by Michael Hudson 24 Sep '02

24 Sep '02

"Vinay Sajip" <vinay_sajip(a)red-dove.com> writes: > I only found 2 uses of "needful" - in BufferingHandler and > ConfigStreamHandler. It's the whole phrase "do the needful", which I > think is peculiar to England but has its share of users on the > subcontinent :-) I've never heard it before, having lived my whole life in England... The meaning's pretty obvious, though. Cheers, M. -- I'll write on my monitor fifty times 'I must not post self-indulgent wibble nobody is interested in to ucam.chat just because I'm bored and I can't find the bug I'm supposed to fix'. -- Steve Kitson, ucam.chat

2 1

Need advice: cloning python cvs for CE project
by Brad Clements 24 Sep '02

24 Sep '02

There are now 4 different people working on the "python ce" project. We've been passing around build tree .zips and it's getting out of hand. I think we should setup our own CVS somewhere so we can work out all the CE kinks before submitting patches to the core Python CVS. Is it possible to maintain a single working directory that can be checked into two different CVS systems? I really have no idea what the proper way is to do this.. Looking for recommendations, including "don't do that, do this instead". Thanks Brad Clements, bkc(a)murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax AOL-IM: BKClements

4 5

Re: [Python-Dev] ATTENTION! Releasing Python 2.2.2 in a few weeks
by Michael Hudson 24 Sep '02

24 Sep '02

Guido van Rossum <guido(a)python.org> writes: > I'd like to release something called Python 2.2.2 in a few weeks (say, > around Oct 8; I like Tuesday release dates). Cool. I have a mailbox containing about 50 checkins that I thought deserved backporting at some point. I'll try to grind through that by the end of the week (i.e. by 28/9). There's no way I'm doing the "pore over logs" duty this time. Cheers, M. -- [1] If you're lost in the woods, just bury some fibre in the ground carrying data. Fairly soon a JCB will be along to cut it for you - follow the JCB back to civilsation/hitch a lift. -- Simon Burr, cam.misc

5 6

Call for clarity
by Hunter Peress 23 Sep '02

23 Sep '02

I've been using python for a good few months. And im really bothered by some aspects of the documentation. I think that there should be a clear effort to provide API style information, rather than the mixed state that things currently are. There are tools for C++/Java...that are part of the official distributions that provide API style docs. Here's what gets me: when u look up something in pydoc, you have no idea what it returns/expects in terms of types. Now, since python is not an explicitely typed language, I ask rhetorically, how can u have good docs that tell u the return/input types without making the language explicitely typed? Make the documenation system explictely typed. The clarification needs to happen somewhere along the lines, and I really think that the world would rather not have it happening at runtime. This could clear up a lot of confusion and further python's effectiveness. -Hunter.

9 17

Re: [Python-Dev] Re: ATTENTION! Releasing Python 2.2.2 in a few weeks
by Laura Creighton 23 Sep '02

23 Sep '02

> > Thanks. In addition, I was hoping to hear about your timeline (when > do you expect to release PyTie?) and a hint on the 3rd party packages > you're thinking of adding. Also a list of target platforms for which > PyTie must absolutely work. (Note e.g. that we just discovered a > problem with Solaris and the latest version of binutils (2.13), which > seems to be used by the latest GCC version (3.2 IIRC) but is also > separately downloadable. The bug is in binutils 2.13. Is this > *combination* (Solaris + binutils 2.13) a target platform? If so, you > might want to use a different approach than we plan to do for Python > 2.3 and 2.2.2 (which is merely to bail out if a certain test dumps > core during configuration). > > --Guido van Rossum (home page: http://www.python.org/~guido/) Do you know when a fixed binutils is due? This may explain one bug report I have right here at Strakt. Solaris is the preferred platform of our beta-testing customer, Chalmers, so I would like PyTie to run on as many Solaris-including hardware and software platforms as possible. I'll bring this up in a meeting. Right now are you advising people not to use GCC 3.2 or binutils 2.13? or do you have other advice for them which you can steer me towards? Laura

4 5

binutils/solaris -- one more thing
by Andrew Koenig 23 Sep '02

23 Sep '02

Assuming that the binutils developers do conclude that the -zcombreloc problem is to be fixed, not worked around (as I think they will), there is still one more binutils-related build problem that I encountered with Solaris: At binutils 2.12, the output from "ld -V" changed in a way that invalidated the previous way of testing for the presence of dynamic linking. Someone--I forget who--gave me a patch that solved the problem; I believe that this patch is necessary to build Python on Solaris with binutils 2.12 or later. Can I ask someone to check whether it is already part of 2.2.2? -------- *** configure.in 2002-09-23 10:07:42.559545843 -0400 --- configure.in.new 2002-09-23 10:08:32.944415830 -0400 *************** *** 889,895 **** fi;; SunOS/5*) case $CC in *gcc*) ! if $CC -Xlinker -V 2>&1 | grep BFD >/dev/null then LINKFORSHARED="-Xlinker --export-dynamic" fi;; --- 889,895 ---- fi;; SunOS/5*) case $CC in *gcc*) ! if $CC -Xlinker --help 2>&1 | grep export-dynamic >/dev/null then LINKFORSHARED="-Xlinker --export-dynamic" fi;;

4 7