Mailman 3 December 2002 - Python-Dev

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

16 Dec '02

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 > money. That is quite different than how numbers are treated in scientific > calculations. That is were I borrowed the idea of significant digits. > Accountants tend to think that all digits are significant, down to the last > penny. I'm a little confused; you're borrowing terms from scientific papers to explain things to accountants? [...] > This is a very good long term goal. So for Python3k the standard numerical > type will be Cowlishaw's decimal numbers. *I* would hope not; there are reasons to prefer binary fp to decimal fp if you're not a money man. Cheers, M. -- ... with these conditions cam the realisation that ... nothing turned a perfectly normal healthy individual into a great political or military leader better than irreversible brain damage. -- The Hitch-Hikers Guide to the Galaxy, Episode 11

1 0

PEP 298
by Thomas Heller 16 Dec '02

16 Dec '02

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 16 Dec '02

16 Dec '02

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 to examine the Solaris system libraries for a particularly ambitious implementation of this technique. -- Eric O'Dell, comp.lang.dylan (& x-posts)

1 0

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

15 Dec '02

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 15 Dec '02

15 Dec '02

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 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

3 5

Weekly Python Bug/Patch Summary
by Skip Montanaro 15 Dec '02

15 Dec '02

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.org/sf/652590 extra __builtin__ stuff not documented (2002-12-12) http://python.org/sf/652749 bad documentation for the "type" builtin (2002-12-12) http://python.org/sf/652888 py_compile does not return error code (2002-12-13) http://python.org/sf/653301 PyLong_AsVoidPtr()/PyLong_FromVoidPtr() (2002-12-13) http://python.org/sf/653542 Investigate weak linking (2002-12-14) http://python.org/sf/653871 New Patches ----------- tarfile module implementation (2002-12-09) http://python.org/sf/651082 New import hooks + Import from Zip files (2002-12-12) http://python.org/sf/652586 PEP 298 implementation (2002-12-12) http://python.org/sf/652857 Generator form of os.path.walk (2002-12-12) http://python.org/sf/652980 Adds a builtin decimal type (FixedPoint) (2002-12-14) http://python.org/sf/653938 Closed Bugs ----------- Fix the METH_CLASS implementation (2002-04-25) http://python.org/sf/548651 Tix Checklist getselection getstatus bug (2002-10-10) http://python.org/sf/621511 textwrap fails on unicode using defaults (2002-10-13) http://python.org/sf/622831 inconsistent results of leading whitespace in textwrap input (2002-10-13) http://python.org/sf/622849 xmlrpc can't do proxied HTTP (2002-12-04) http://python.org/sf/648658 Closed Patches -------------- 'switch'/'case'/'else' statement (2001-11-12) http://python.org/sf/481118 splitext performances improvement (2002-03-29) http://python.org/sf/536661 Add check for setrlimit() support (2002-05-03) http://python.org/sf/551960 Detect BLT on more systems (2002-10-26) http://python.org/sf/629126 tuple arg for issubclass (2002-12-06) http://python.org/sf/649608 avoid redefinition of pthread functions (2002-12-08) http://python.org/sf/650415

1 0

os.path.commonprefix
by Armin Rigo 13 Dec '02

13 Dec '02

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: >>> commonprefix(['/home/users/arigo', '/home/users/alal']) '/home/users/a' What is the use for such a thing ?? I suggest that a more descriptive comment be added in the documentation. Armin

3 5

warnings compiling tkinter
by Jeremy Hylton 13 Dec '02

13 Dec '02

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/python/dist/src/Modules/_tkinter.c: In function `SetVar': /usr/home/jeremy/src/python/dist/src/Modules/_tkinter.c:1486: warning: passing arg 7 of `var_invoke' from incompatible pointer type /usr/home/jeremy/src/python/dist/src/Modules/_tkinter.c:1496: warning: passing arg 8 of `var_invoke' from incompatible pointer type /usr/home/jeremy/src/python/dist/src/Modules/_tkinter.c: In function `GetVar': /usr/home/jeremy/src/python/dist/src/Modules/_tkinter.c:1537: warning: passing arg 6 of `var_invoke' from incompatible pointer type /usr/home/jeremy/src/python/dist/src/Modules/_tkinter.c:1537: warning: passing arg 7 of `var_invoke' from incompatible pointer type /usr/home/jeremy/src/python/dist/src/Modules/_tkinter.c: In function `UnsetVar': /usr/home/jeremy/src/python/dist/src/Modules/_tkinter.c:1565: warning: passing arg 6 of `var_invoke2' from incompatible pointer type /usr/home/jeremy/src/python/dist/src/Modules/_tkinter.c:1565: warning: passing arg 7 of `var_invoke2' from incompatible pointer type gcc -shared /usr/home/jeremy/src/python/dist/src/Modules/_tkinter.o /usr/home/jeremy/src/python/dist/src/Modules/tkappinit.o -L/usr/X11R6/lib -L/usr/local/lib -lBLT -ltk8.3 -ltcl8.3 -lX11 -o build/lib.linux-i686-2.3/_tkinter.so

2 1

new import hooks & zip import
by Just van Rossum 13 Dec '02

13 Dec '02

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 13 Dec '02

13 Dec '02

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(ing)?`` sitting there on SF and knowing that I have a lot of PHP coding coming up, I am up for implementing this (with no specified timeframe). The question is how do you want it implemented? I say it should just be a file you keep in your Lib/test/ directory that is formatted like what you pass in for the -f option to regrtest.py (heck, I plan to copy the code that implements that option). It should always be included without a passed-in option since the whole point of this is that these tests are expected to be skipped. Thus it should have a standardized name (how about "ToSkip.txt"? Maybe a leading underscore?) The other issue is whether the listed tests should supplement or extend the expected tests for the platform. I say it should extend, but the thread originally discussing this said supplement. If both ways are desired, the file could specify either ``..add`` or ``..replace`` (or something similar) to signal which to do (default being to add them). It could be required to be at the top of the file, at the end, or just anywhere; I have no preference. But I think it should just extend it since we have those tests listed for a reason and having to possibly re-list them would be a pain. Or you could all just say "surprise me, Brett" and let me sweat the details. =) -Brett

4 6