Mailman 3 May 2003 - Python-Dev

pyconfig.h not regenerated by "config.status --recheck"
by Skip Montanaro May 7, 2003

May 7, 2003

I decided to investigate why the resource module wasn't getting built on my Mac today. A quick check showed that build.opt/pyconfig.h didn't include this stanza: /* Define if you have the 'getpagesize' function. */ #define HAVE_GETPAGESIZE 1 although pyconfig.h.in contained this stanza: /* Define if you have the 'getpagesize' function. */ #undef HAVE_GETPAGESIZE The date on pyconfig.h.in was May 5. The date on build.opt/pyconfig.h was Feb 27. Executing ./config.status --recheck in my build.opt tree doesn't regenerate pyconfig.h. I then tried executing ../configure --prefix=/Users/skip/local This generated pyconfig.h. It would thus appear that config.status shouldn't be used by developers. Apparently one of the other flags it appends to the generated configure command suppresses generation of pyconfig.h (and maybe other files). Skip

4 6

heaps
by Agthorr May 7, 2003

May 7, 2003

I brought up heapq last week, but there was only brief discussion before the issue got sidetracked into a discussion of FIFO queues. I'd like to revisit heapq. The two people who responded seemed to agree that the existing heapq interface was lacking, and this seemed to be the sentiment many months ago when heapq was added. I'll summarize some of the heap interfaces that have been proposed: - the heapq currently in CVS: - Provides functions to manipulate a list organized as a binary heap - Advantages: - Internal binary heap structure is transparent to user, useful for educational purposes - Low overhead - Already in CVS - My MinHeap/MaxHeap classes: - Provides a class with heap access routines, using a list internally - Advantages: - Implementation is opaque, so it can be replaced later with Fibonacci heaps or Paired heaps without breaking user programs - Provides an adjust_key() command needed by some applications (e.g. Dijkstra's Algorithm) - David Eppstein's priorityDictionary class: - Provides a class with a dictionary-style interface (ex: heap['cat'] = 5 would give 'cat' a priority of 5 in the heap) - Advantages: - Implementation is opaque, so it can be replaced later with Fibonacci heaps or Paired heaps without breaking user programs - A dictionary interface may be more intuitive for certain applications - Limitation: - Objects with the same value may only have a single instance in the heap. I'd very much like to see the current heapq replaced with a different interface in time for 2.3. I believe that an opaque object is better, since it allows more flexibility later. If the current heapq is released, user program will start to use it, and then it will be much more difficult to switch to a different heap algorithm later, should that become desirable. Also, decrease-key is an important feature that many users will expect from a heap; this operation is notably missing from heapq. I'm willing to do whatever work is necessary to get a more flexible heap interface into 2.3. If the consensus prefers my MinHeap (or something similar), I'll gladly write documentation (and have already written rather brutal tests). Somebody with authority, just tell me where to pour my energy in this matter :) -- Agthorr

5 14

RE: [Python-Dev] Windows installer request...
by Bjorn Pettersen May 7, 2003

May 7, 2003

> From: Tim Peters [mailto:tim.one@comcast.net] > > [Bjorn Pettersen] [...] > > item: Get Environment Variable > > Variable=OSDRIVE > > Environment=SystemDrive > > Default=C: > > end [...] > Enough already <wink/frown>: I don't have time to try > umpteen different things here, or really even one. Thank you for doing it anyway then <smile>. > What I did do is build an installer *just* removing the hard-coded > Wizard-generated "C:" prefix. Martin tried that and said it > worked for him. It doesn't hurt me. If it works for you too, > I'll commit the change: Works like a charm. Tested on Win98, Win2k, WinXP Pro (regular), and my "special" XP. (NT4 seems to have died a silent death, so I couldn't test it there...) > Please give that a try. It's an incoherent mix if files, so > please use a junk name for the installation directory and program > startup group (or simply abort the install after you see whether > it suggested a drive you approve of). I went all the way through (all files seems to have gone in correctly), and as expected it shadowed my original install of 2.3b1 in the Add/Remove Programs window. Surprisingly however, the original came back after this one was removed. Who'd have thought.. ;-) [.. xx.wse needs the Wise GUI to create an installer..] Thought it might be that way... FWIW, re: the MSVC7 debate, the "Microsoft Development Environment" (DevStudio), comes with five different "Setup and Deployment projects". I've never used any of them, nor Wise (obviously :-), but it could potentially get you out of the loop... <wink>. Thanks again! -- bjorn

2 1

RedHat 9 _random failure under -pg (was Re: [Python-Dev] Startup time)
by Jeff Epler May 6, 2003

May 6, 2003

On Tue, May 06, 2003 at 01:36:00PM -0500, Jeff Epler wrote: > (gdb) run -c "import random" > Starting program: /usr/src/Python-2.3b1/python -c "import random" > [New Thread 1074963072 (LWP 28408)] > > Program received signal SIGILL, Illegal instruction. > [Switching to Thread 1074963072 (LWP 28408)] > 0x08109aa0 in subtype_getsets_full () > (gdb) where > #0 0x08109aa0 in subtype_getsets_full () > #1 0x4001c743 in random_new (type=0x4001c738, args=0x4012c02c, kwds=0x0) > at /usr/src/Python-2.3b1/Modules/_randommodule.c:439 > (gdb) ptype subtype_getsets_full > type = struct PyGetSetDef { > [...] gcc is generating plainly bogus code for this simple function random_new: 00001738 <random_new>: 1738: 55 push %ebp 1739: 89 e5 mov %esp,%ebp 173b: 56 push %esi 173c: 53 push %ebx 173d: ff 93 7c 00 00 00 call *0x7c(%ebx) (for those of you who don't read x86 assembly, the first 4 functions are part of a standard function prologue. The fifth instruction is a call through a function pointer, but the register's value at this point is undefined. This is not the call to type->tp_alloc(), correct code for that is just below) Well, this may have been false alarm -- when I removed -pg from OPT in the Makefile, './python -c "import random"' works. So this is a problem only when profiling is enabled. Is this intended to work? In any case, the fact that the disassembly is so plainly bogus tends to imply that this is a gcc bug, not anything that Python can fix. Jeff

2 2

SF CVS offline
by Skip Montanaro May 6, 2003

May 6, 2003

It appears SF CVS is offline (as of 2:30PM Central Daylight Time). I noticed this when I was prompted for a CVS password for the first time in ages (and which I can't remember). I went poking around for help and came across this page: http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1 which says, in part: Project CVS Services: Offline; unplanned maintenance (follow-up from 2003-05-05) in-progress FYI. Skip

1 0

RE: [Python-Dev] MS VC 7 offer
by Geoffrey Talvola May 6, 2003

May 6, 2003

Guido van Rossum wrote: > I can see advantages and disadvantages of moving to VC 7; I'm sure the > VC 7 compiler is more standard-compliant and generates faster code, > but a disadvantage is that you can't apparently link binaries built > with VC 6 to a program built with VC 7, meaning that 3rd party > extensions will have to be recompiled with VC 7 as well. If that's really true then my vote would be against switching to VC 7. My company uses VC 6 extensively and we have no plans to upgrade to VC 7. Our Python programs make extensive use of .pyd's compiled with VC6, and we also embed the Python interpreter within our C++ programs. It would be _very_ painful for us to upgrade our world to VC7, and if Python switched to VC 7, we'd probably be forced to simply compile our own custom version of Python (and the 3rd-party extension DLLs we use) with VC6. So there's one data point for you... - Geoff

1 0

RE: [Python-Dev] Windows installer request...
by Bjorn Pettersen May 6, 2003

May 6, 2003

> From: Tim Peters [mailto:tim.one@comcast.net] > > [Bjorn Pettersen] > > Would it be possible for the windows installer to use > > $SYSTEMDRIVE$ as the default installation drive instead > > of C:? [...] > Are you saying that the "Select Destination Directory" dialog > box doesn't allow you to select your E: drive? Or just > that you'd rather not need to select the drive you want? Most installers default to the system drive, so I didn't even look the first time. I am able to change it manually. > > If it's considered a good idea, and someone can point me to > > where the change has to be made, I'd be more than willing to > > produce a patch... > > I apparently left this comment in the Wise script: > > Note from Tim: doesn't seem to be a way to get the true > boot drive, the Wizard hardcodes "C". > > So, AFAIK, there isn't a straightforward way to get Wise 8.14 > to suggest a drive other than C:. It should be as easy as (platforms that doesn't have %systemdrive% could only install to C:): item: Get Environment Variable Variable=OSDRIVE Environment=SystemDrive Default=C: end However, you might have to do item: Get Registry Key Value Variable=OSDRIVE Key=System\CurrentControlSet\Control\Session Manager\Environment Value Name=SystemDrive Flags=00000100 Defualt=C: end (not sure about the Flags parameter) I couldn't find much documentation, and the example I'm looking at is a litte "divided" about which it should use... I think it tries the first one, and falls back on the second(?) (http://ibinstall.defined.net/dl_scripts.htm, script_6016.zip/IBWin32Setup.wse). Also, it looks like you want to use %SYS32% to get to the windows system directory (on WinXP, it's c:\windows\system32, which doesn't seem to be listed anywhere...) I can't figure out how you're building the installer however. If you can point me in the right direction I can test it on my special WinXP, regular WinXP, Win98, Win2k, and maybe WinNT4 (I think we still have one around :-). -- bjorn

2 1

Python Technical Lead, New York, NY - 80-85k
by NYC-SEARCH May 6, 2003

May 6, 2003

Python Technical Lead, New York, NY - 80-85k - IMMEDIATE HIRE http://www.nyc-search.com/jobs/python.html

1 0

testing with and without pyc files present
by Skip Montanaro May 6, 2003

May 6, 2003

The test targets in the Makefile first delete any .py[co] files, then run the test suite twice. I know there must be a reason for this, but isn't there a less sledgehammer-like and more explicit way to test whatever this is trying to test? Skip

2 2

Re: heaps
by Michael Chermside May 6, 2003

May 6, 2003

Zooko writes: > Shouldn't heapq be a subclass of list? [...] > One thing I don't know how to implement is: > > # This changes mylist itself into a heapq -- it doesn't make a copy of mylist! > makeheapq(mylist) > > Perhaps this is a limitation of the current object model? Or is there a way > to change an object's type at runtime. To change an object's CLASS, sure, but it's TYPE -- seems impossible to me on the face of it since a different type may have a different C layout. Now in THIS case there's no need for a different C layout, so perhaps there's some wierd trick I don't know, but I wouldn't think so. As to your FIRST point though... the choice seems to be between making heapq a subclass of list or a module for operating on a list. You argue that the syntax will be cleaner, but comparing your examples: > heap = [] > heappush(heap, item) > item = heappop(heap) > item = heap[0] > heap = heapq() > heap.push(item) > item = heap.pop() > item = heap[0] I honestly see little meaningful difference. Since (as per earlier discussion) heapq is NOT intended to be a abstract heap data type, I tend to prefer the simpler solution (using a list instead of subclassing). -- Michael Chermside

1 0