Mailman 3 December 2002 - Python-Dev

Re: [Python-Dev] RE: Adding decimal (aka FixedPoint) numbers to Python
by Michael Hudson Dec. 16, 2002

Dec. 16, 2002

Michael McLay <mclay(a)nist.gov> writes: > On Monday 16 December 2002 01:48 am, Tim Peters wrote: > > [Michael McLay] > > > > > ... > > > The semantics of the precision parameter may be incorrect because > > > it is only addressing the precision of the fraction part of the > > > number. > > > > That's why the module was called FixedPoint. > > Fixing the decimal place would make sense for applications having to do with … [View More]

1 0

PEP 298
by Thomas Heller Dec. 16, 2002

Dec. 16, 2002

I intend to work on the PEP 298 (locked buffer interface) implementation, with the hope that it is not too late to bring this into 2.3. Is there still a chance? If it will not make it into 2.3, I will retract the PEP, because 2.4 is too late for me. Thomas

6 30

Re: [Python-checkins] python/dist/src/Lib/test test_descr.py,1.169,1.170
by Michael Hudson Dec. 16, 2002

Dec. 16, 2002

gvanrossum(a)users.sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Lib/test > In directory sc8-pr-cvs1:/tmp/cvs-serv7366/Lib/test > > Modified Files: > test_descr.py > Log Message: > Tighten the tests for assignment to __bases__: disallow empty tuple. Oh, I knew about that, but didn't think it was worth bothering with. Sorry. Cheers, M. -- That being done, all you have to do next is call free() slightly less often than malloc(). You may want … [View More]

1 0

xmlrpc can't do proxied HTTP (2002-12-04)
by Bill Bumgarner Dec. 15, 2002

Dec. 15, 2002

On Sunday, Dec 15, 2002, at 12:00 US/Eastern, python-dev-request(a)python.org wrote: > xmlrpc can't do proxied HTTP (2002-12-04) > http://python.org/sf/648658 The above showed up in the 'closed' list. I clicked through to see what was going on, but I received an 'invalid artifact ID' error. ? b.bum

2 1

PEP-298: buffer interface widening too much?
by Todd Miller Dec. 15, 2002

Dec. 15, 2002

I've been following the PEP-298 discussion a little, because I fear eventually IAGNI. But when I look at the proposed changes, I can't help but get the feeling that the "too wide" buffer interface just got wider. By "too wide", I am referring to the extraneous segmentation and character buffer aspects of the existing interface. Adding three more calls for the locking problem bugs me. Doesn't anything ever get simpler? Looking at the proposed changes, the only thing that really … [View More]seems needed for the bufferprocs is the release call and a flag bit. Assuming the release call is not implemented, the acquired buffer is never locked or unlocked, and we're no worse off than we are now: it's the BO's problem. Assuming the release call is present, the acquired buffer should *always* be locked and later released. The existing wrapper functions (plus one for release) can hide/implement this, making it straight forward to provide correct extensions: just implement a locking extension. It seems to me that the existing (3!) calls for acquiring the buffer pointer can do just fine. Except... In the case of existing extensions, there will certainly be no call to the release function. So for an extension which is slow to update to the revised protocol, there are negative consequences: buffers which are never unlocked. But so what? These consequences seem less dire (if more probable) than the existing consequences of "moving buffers." It would be a bigger problem if PEP-298 wound up fiddling with reference counts. In that case, un-released buffers would also become memory leaks. But is it really necessary to mess with the reference counts? I'm having a hard time imagining a situation in which the reference count for a buffer goes to zero while it is locked which is not a bug somewhere else. What am I missing? Another possibility is to implement a "release buffer pointer" wrapper function which *does nothing* for a Python release 2.3 and change nothing else. Let extensions which use buffers adopt usage of the wrapper and the locking protocol, with no immediate benefit. Then implement locking for real in Python 2.4. That way, the number of non-conforming extensions can be minimized, but the buffer API can be kept simple. So, in the end, what I'm wondering is whether there's a simpler middle ground between dropping the PEP and implementing it as it stands now. Are there compromises to be found between guaranteeing correctness, backwards compatability, and growing complexity? Is there another trade between backwards compatability and complexity which is tolerable for the short term with both simplicity and correctness available in the longer term? Todd [View Less]

3 5

Weekly Python Bug/Patch Summary
by Skip Montanaro Dec. 15, 2002

Dec. 15, 2002

Bug/Patch Summary ----------------- 321 open / 3121 total bugs (+4) 93 open / 1834 total patches (-1) New Bugs -------- email test external dependencies (2002-12-08) http://python.org/sf/650441 pydoc ignores $PAGER if TERM=='dumb' (2002-12-09) http://python.org/sf/651124 Review libshelve.tex when possible (2002-12-09) http://python.org/sf/651149 Bozo getstate w/ slots overrides base (2002-12-10) http://python.org/sf/651701 dynload_next needs better errors (2002-12-12) http://python.… [View More]

1 0

os.path.commonprefix
by Armin Rigo Dec. 13, 2002

Dec. 13, 2002

Hello everybody, I recently discovered that os.path.commonprefix(list-of-strings) returns the longest substring that is an initial segment of all the given strings, and that this has nothing to do with the fact that the strings might be paths. I wonder why this has been put in os.path and not in the string module in the first place. This location misled me for a long time into thinking that commonprefix() would return the longest common *path*, a feature whose interest I could see. But: &… [View More]

3 5

warnings compiling tkinter
by Jeremy Hylton Dec. 13, 2002

Dec. 13, 2002

Should I be concerned about these warnings? Perhaps my version of Tcl/Tk is too old? jeremy gcc -g -Wall -Wstrict-prototypes -fPIC -DWITH_APPINIT=1 -DWITH_BLT=1 -I/usr/X11R6/include -I. -I/usr/home/jeremy/src/python/dist/src/./Include -I/usr/local/include -I/usr/home/jeremy/src/python/dist/src/Include -I/usr/home/jeremy/src/python/dist/src/build-pydebug -c /usr/home/jeremy/src/python/dist/src/Modules/_tkinter.c -o /usr/home/jeremy/src/python/dist/src/Modules/_tkinter.o /usr/home/jeremy/src/… [View More]

2 1

new import hooks & zip import
by Just van Rossum Dec. 13, 2002

Dec. 13, 2002

After incorporating some suggestions and fixes from Paul Moore and Neal Norwitz and doing more testing myself, I've decided the importhook/zipimport patch is mature enough to post a proper patch: http://www.python.org/sf/652586 I've renamed two of the three new sys items; the patch note explains. Thorough review would be very welcome. Thanks! Just

4 6

Still want an expected skip file for regrtest.py?
by Brett Cannon Dec. 13, 2002

Dec. 13, 2002

I just updated my CVS copy of Python and noticed that regrtest.py was patched. That triggered the memory of summarizing the whole expected skip thread from the last summary. The conclusion to that thread was the idea of having a file that would list tests that could be added to the expected skip list at run-time and thus squash the issue of having to ignore skipped test messages for things you knew would be skipped that were not listed on the platform skip list. Well, with ``dummy_thread(… [View More]

4 6