Mailman 3 April 2000 - Python-Dev

Re: [Python-Dev] Round Bug in Python 1.6?
by Ka-Ping Yee 13 Apr '00

13 Apr '00

Tim Peters wrote: > The best possible IEEE-754 double approximation to 3.1416 is (exactly) > > 3.141599999999999948130380289512686431407928466796875 Let's call this number 'A' for the sake of discussion. > so the output you got is correctly rounded to 17 significant digits. IOW, > it's a feature. Clearly there is something very wrong here: Python 1.5.2+ (#2, Mar 28 2000, 18:27:50) Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> 3.1416 3.1415999999999999 >>> Now you say that 17 significant digits are required to ensure that eval(repr(x)) == x, but we surely know that 17 digits are *not* required when x is A because i *just typed in* 3.1416 and the best choice of double value was A. I haven't gone and figured it out, but i'll take your word for it that 17 digits may be required in *certain* cases to ensure that eval(repr(x)) == x. They're just not required in all cases. It's very jarring to type something in, and have the interpreter give you back something that looks very different. It breaks a fundamental rule of consistency, and that damages the user's trust in the system or their understanding of the system. (What do you do then, start explaining the IEEE double representation to your CP4E beginner?) What should really happen is that floats intelligently print in the shortest and simplest manner possible, i.e. the fewest number of digits such that the decimal representation will convert back to the actual value. Now you may say this is a pain to implement, but i'm talking about sanity for the user here. I haven't investigated how to do this best yet. I'll go off now and see if i can come up with an algorithm that's not quite so stupid as def smartrepr(x): p = 17 while eval('%%.%df' % (p - 1) % x) == x: p = p - 1 return '%%.%df' % p % x -- ?!ng

5 14

RE: [Idle-dev] Forward progress with full backward compatibility
by Tim Peters 13 Apr '00

13 Apr '00

[Peter Funk] > ... > 2. What should the new Interpreter do, if he sees a source file without a > pragma defining the language level? Python has tens of thousands of users now -- if it doesn't default to "Python 1.5.2" (however that's spelled), approximately 79.681% of them will scream. Had the language done this earlier, it would have been much more sellable to default to the current version. However, a default is *just* "a default", and platform-appropriate config mechanism (from Windows registry to cmdline flag) could be introduced to change the default. That is, 1.7 comes out and all my code runs fine without changing a thing. Then I set a global config option to "pretend every module that doesn't say otherwise has a 1.7 pragma in it", and run things again to see what breaks. As part of the process of editing the files that need to be fixed, I can take that natural opportunity to dump in a 1.7 pragma in the modules I've changed, or a 1.6 pragma in the broken modules I can't (for whatever reason) alter just yet. Two pleasant minutes <wink> later, I'll have 6,834 .py files all saying "1.7" at the top. Hmm! So when 1.8 comes out, not a one of them will use any incompatible 1.8 features. So I'll also need a global config option that says "pretend every module has a 1.8 pragma in it, *regardless* of whether it has some other pragma in it already". But that will also screw up the one .py file I forgot that had a 1.5.2 pragma in it. Iterate this process a half dozen times, and I'm afraid the end result is intractable. Seems it would be much more tractable over the long haul to default to the current version. Then every incompatible change will require changing every file that relied on the old behavior (to dump in a "no, I can't use the current version's semantics" pragma) -- but that's the situation today too. The difference is that the minimal change required to get unstuck would be trivial. A nice user (like me <wink>) would devote their life to keeping up with incompatible changes, so would never ever have a version pragma in any file. So I vote "default to current version" -- but, *wow*, that's going to be hard to sell. Tech note: Python's front end is not structured today in such a way that it's feasible to have the parser deal with a change in the set of keywords keying off a pragma -- any given identifier today is either always or never a keyword, and that choice is hardwired into the generated parse tables. Not a reason to avoid starting this process with 1.6, just a reason to avoid adding new keywords in 1.6 (it will take some real work to overcome the front end's limitations here). go-for-it!-ly y'rs - tim

9 16

Arbitrary attributes on funcs and methods
by bwarsaw＠python.org 13 Apr '00

13 Apr '00

A number of people have played FAST and loose with function and method docstrings, including John Aycock[1], Zope's ORB[2]. Docstrings are handy because they are the one attribute on funcs and methods that are easily writable. But as more people overload the semantics for docstrings, we'll get collisions. I've had a number of discussions with folks about adding attribute dictionaries to functions and methods so that you can essentially add any attribute. Namespaces are one honking great idea -- let's do more of those! Below is a very raw set of patches to add an attribute dictionary to funcs and methods. It's only been minimally tested, but if y'all like the idea, I'll clean it up, sanity check the memory management, and post the changes to patches(a)python.org. Here's some things you can do: -------------------- snip snip -------------------- Python 1.6a2 (#10, Apr 10 2000, 11:27:59) [GCC 2.8.1] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> def a(): pass ... >>> a.publish = 1 >>> a.publish 1 >>> a.__doc__ >>> a.__doc__ = 'a doc string' >>> a.__doc__ 'a doc string' >>> a.magic_string = a.__doc__ >>> a.magic_string 'a doc string' >>> dir(a) ['__doc__', '__name__', 'func_code', 'func_defaults', 'func_dict', 'func_doc', 'func_globals', 'func_name', 'magic_string', 'publish'] >>> class F: ... def a(self): pass ... >>> f = F() >>> f.a.publish Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: publish >>> f.a.publish = 1 >>> f.a.publish 1 >>> f.a.__doc__ >>> f.a.__doc__ = 'another doc string' >>> f.a.__doc__ 'another doc string' >>> f.a.magic_string = f.a.__doc__ >>> f.a.magic_string 'another doc string' >>> dir(f.a) ['__dict__', '__doc__', '__name__', 'im_class', 'im_func', 'im_self', 'magic_string', 'publish'] >>> -------------------- snip snip -------------------- -Barry [1] Aycock, "Compiling Little Languages in Python", http://www.foretec.com/python/workshops/1998-11/proceedings/papers/aycock-l… [2] http://classic.zope.org:8080/Documentation/Reference/ORB P.S. I promised to add a little note about setattr and getattr vs. setattro and getattro. There's very little documentation about the differences, and searching on python.org doesn't seem to turn up anything. The differences are simple. setattr/getattr take a char* argument naming the attribute to change, while setattro/getattro take a PyObject* (hence the trailing `o' -- for Object). This stuff should get documented in the C API, but at least now, it'll turn up in a SIG search. :) -------------------- snip snip -------------------- Index: funcobject.h =================================================================== RCS file: /projects/cvsroot/python/dist/src/Include/funcobject.h,v retrieving revision 2.16 diff -c -r2.16 funcobject.h *** funcobject.h 1998/12/04 18:48:02 2.16 --- funcobject.h 2000/04/07 21:30:40 *************** *** 44,49 **** --- 44,50 ---- PyObject *func_defaults; PyObject *func_doc; PyObject *func_name; + PyObject *func_dict; } PyFunctionObject; extern DL_IMPORT(PyTypeObject) PyFunction_Type; Index: classobject.c =================================================================== RCS file: /projects/cvsroot/python/dist/src/Objects/classobject.c,v retrieving revision 2.84 diff -c -r2.84 classobject.c *** classobject.c 2000/04/10 13:03:19 2.84 --- classobject.c 2000/04/10 15:27:15 *************** *** 1550,1577 **** /* Dummies that are not handled by getattr() except for __members__ */ {"__doc__", T_INT, 0}, {"__name__", T_INT, 0}, {NULL} /* Sentinel */ }; static PyObject * instancemethod_getattr(im, name) register PyMethodObject *im; ! PyObject *name; { ! char *sname = PyString_AsString(name); ! if (sname[0] == '_') { /* Inherit __name__ and __doc__ from the callable object implementing the method */ ! if (strcmp(sname, "__name__") == 0 || ! strcmp(sname, "__doc__") == 0) ! return PyObject_GetAttr(im->im_func, name); } if (PyEval_GetRestricted()) { PyErr_SetString(PyExc_RuntimeError, "instance-method attributes not accessible in restricted mode"); return NULL; } ! return PyMember_Get((char *)im, instancemethod_memberlist, sname); } static void --- 1550,1608 ---- /* Dummies that are not handled by getattr() except for __members__ */ {"__doc__", T_INT, 0}, {"__name__", T_INT, 0}, + {"__dict__", T_INT, 0}, {NULL} /* Sentinel */ }; + static int + instancemethod_setattr(im, name, v) + register PyMethodObject *im; + char *name; + PyObject *v; + { + int rtn; + + if (PyEval_GetRestricted() || + strcmp(name, "im_func") == 0 || + strcmp(name, "im_self") == 0 || + strcmp(name, "im_class") == 0) + { + PyErr_Format(PyExc_TypeError, "read-only attribute: %s", name); + return -1; + } + return PyObject_SetAttrString(im->im_func, name, v); + } + + static PyObject * instancemethod_getattr(im, name) register PyMethodObject *im; ! char *name; { ! PyObject *rtn; ! ! if (strcmp(name, "__name__") == 0 || ! strcmp(name, "__doc__") == 0) { /* Inherit __name__ and __doc__ from the callable object implementing the method */ ! return PyObject_GetAttrString(im->im_func, name); } if (PyEval_GetRestricted()) { PyErr_SetString(PyExc_RuntimeError, "instance-method attributes not accessible in restricted mode"); return NULL; + } + if (strcmp(name, "__dict__") == 0) + return PyObject_GetAttrString(im->im_func, name); + + rtn = PyMember_Get((char *)im, instancemethod_memberlist, name); + if (rtn == NULL) { + PyErr_Clear(); + rtn = PyObject_GetAttrString(im->im_func, name); + if (rtn == NULL) + PyErr_SetString(PyExc_AttributeError, name); } ! return rtn; } static void *************** *** 1662,1669 **** 0, (destructor)instancemethod_dealloc, /*tp_dealloc*/ 0, /*tp_print*/ ! 0, /*tp_getattr*/ ! 0, /*tp_setattr*/ (cmpfunc)instancemethod_compare, /*tp_compare*/ (reprfunc)instancemethod_repr, /*tp_repr*/ 0, /*tp_as_number*/ --- 1693,1700 ---- 0, (destructor)instancemethod_dealloc, /*tp_dealloc*/ 0, /*tp_print*/ ! (getattrfunc)instancemethod_getattr, /*tp_getattr*/ ! (setattrfunc)instancemethod_setattr, /*tp_setattr*/ (cmpfunc)instancemethod_compare, /*tp_compare*/ (reprfunc)instancemethod_repr, /*tp_repr*/ 0, /*tp_as_number*/ *************** *** 1672,1678 **** (hashfunc)instancemethod_hash, /*tp_hash*/ 0, /*tp_call*/ 0, /*tp_str*/ ! (getattrofunc)instancemethod_getattr, /*tp_getattro*/ 0, /*tp_setattro*/ }; --- 1703,1709 ---- (hashfunc)instancemethod_hash, /*tp_hash*/ 0, /*tp_call*/ 0, /*tp_str*/ ! 0, /*tp_getattro*/ 0, /*tp_setattro*/ }; Index: funcobject.c =================================================================== RCS file: /projects/cvsroot/python/dist/src/Objects/funcobject.c,v retrieving revision 2.18 diff -c -r2.18 funcobject.c *** funcobject.c 1998/05/22 00:55:34 2.18 --- funcobject.c 2000/04/07 22:15:33 *************** *** 62,67 **** --- 62,68 ---- doc = Py_None; Py_INCREF(doc); op->func_doc = doc; + op->func_dict = PyDict_New(); } return (PyObject *)op; } *************** *** 133,138 **** --- 134,140 ---- {"__name__", T_OBJECT, OFF(func_name), READONLY}, {"func_defaults",T_OBJECT, OFF(func_defaults)}, {"func_doc", T_OBJECT, OFF(func_doc)}, + {"func_dict", T_OBJECT, OFF(func_dict)}, {"__doc__", T_OBJECT, OFF(func_doc)}, {NULL} /* Sentinel */ }; *************** *** 142,153 **** PyFunctionObject *op; char *name; { if (name[0] != '_' && PyEval_GetRestricted()) { PyErr_SetString(PyExc_RuntimeError, "function attributes not accessible in restricted mode"); return NULL; } ! return PyMember_Get((char *)op, func_memberlist, name); } static int --- 144,167 ---- PyFunctionObject *op; char *name; { + PyObject* rtn; + if (name[0] != '_' && PyEval_GetRestricted()) { PyErr_SetString(PyExc_RuntimeError, "function attributes not accessible in restricted mode"); return NULL; + } + if (strcmp(name, "__dict__") == 0) + return op->func_dict; + + rtn = PyMember_Get((char *)op, func_memberlist, name); + if (rtn == NULL) { + PyErr_Clear(); + rtn = PyDict_GetItemString(op->func_dict, name); + if (rtn == NULL) + PyErr_SetString(PyExc_AttributeError, name); } ! return rtn; } static int *************** *** 156,161 **** --- 170,177 ---- char *name; PyObject *value; { + int rtn; + if (PyEval_GetRestricted()) { PyErr_SetString(PyExc_RuntimeError, "function attributes not settable in restricted mode"); *************** *** 178,185 **** } if (value == Py_None) value = NULL; } ! return PyMember_Set((char *)op, func_memberlist, name, value); } static void --- 194,214 ---- } if (value == Py_None) value = NULL; + } + else if (strcmp(name, "func_dict") == 0) { + if (value == NULL || !PyDict_Check(value)) { + PyErr_SetString( + PyExc_TypeError, + "func_dict must be set to a dict object"); + return -1; + } + } + rtn = PyMember_Set((char *)op, func_memberlist, name, value); + if (rtn < 0) { + PyErr_Clear(); + rtn = PyDict_SetItemString(op->func_dict, name, value); } ! return rtn; } static void *************** *** 191,196 **** --- 220,226 ---- Py_DECREF(op->func_name); Py_XDECREF(op->func_defaults); Py_XDECREF(op->func_doc); + Py_XDECREF(op->func_dict); PyMem_DEL(op); }

18 41

re: #pragmas and method attributes
by gvwilson＠nevex.com 13 Apr '00

13 Apr '00

> > On Wed, 12 Apr 2000, Paul Prescod wrote: > > About a month ago I wrote (but did not publish) a proposal that combined > > #pragmas and method attributes. The reason I combined them is that in a > > lot of cases method "attributes" are supposed to be available in the > > parse tree, before the program begins to run. Here is my rough draft. > Moshe Zadka wrote: > BTW: Why force the value to be a string? Any immutable basic type > should do fine, no?? If attributes can be objects other than strings, then programmers can implement hierarchical nesting directly using: def func(...): decl { 'zorb' : 'visible', 'spark' : { 'rule' : 'some grammar rule', 'doc' : 'handle quoted expressions' } 'info' : { 'author' : ('Greg Wilson', 'Allun Smythee'), 'date' : '2000-04-12 14:08:20 EDT' } } pass instead of: def func(...): decl { 'zorb' : 'visible', 'spark-rule' : 'some grammar rule', 'spark-doc' : 'handle quoted expressions' 'info-author' : 'Greg Wilson, Allun Smythee', 'info-date' : '2000-04-12 14:08:20 EDT' } pass In my experience, every system for providing information has eventually wanted/needed to be hierarchical --- code blocks, HTML, the Windows registry, you name it. This can be faked up using some convention like semicolon-separated lists, but processing (and escaping insignificant uses of separator characters) quickly becomes painful. (Note that if Python supported multi-dicts, or if something *ML-ish was being used for decl's, the "author" tag in "info" could be listed twice, instead of requiring programmers to fall back on char-separated lists.) Just another random, Greg

1 0

Processing XML with Perl (interesting article) (fwd)
by gvwilson＠nevex.com 13 Apr '00

13 Apr '00

http://www.xml.com/pub/2000/04/05/feature/index.html is Michael Rodriguez' summary of XML processing modules for Perl. It opens with: "Perl is one of the most powerful (and even the most devout Python zealots will agree here) and widely used text processing languages." Greg

1 0

Second round: arbitrary function and method attributes
by Barry A. Warsaw 12 Apr '00

12 Apr '00

Here's the second go at adding arbitrary attribute support to function and method objects. Note that this time it's illegal (TypeError) to set an attribute on a bound method object; getting an attribute on a bound method object returns the value on the underlying function object. First the diffs, then the test case and test output. Enjoy, -Barry Index: Include/funcobject.h =================================================================== RCS file: /projects/cvsroot/python/dist/src/Include/funcobject.h,v retrieving revision 2.16 diff -u -r2.16 funcobject.h --- funcobject.h 1998/12/04 18:48:02 2.16 +++ funcobject.h 2000/04/07 21:30:40 @@ -44,6 +44,7 @@ PyObject *func_defaults; PyObject *func_doc; PyObject *func_name; + PyObject *func_dict; } PyFunctionObject; extern DL_IMPORT(PyTypeObject) PyFunction_Type; Index: Objects/classobject.c =================================================================== RCS file: /projects/cvsroot/python/dist/src/Objects/classobject.c,v retrieving revision 2.84 diff -u -r2.84 classobject.c --- classobject.c 2000/04/10 13:03:19 2.84 +++ classobject.c 2000/04/11 22:05:08 @@ -1550,28 +1550,75 @@ /* Dummies that are not handled by getattr() except for __members__ */ {"__doc__", T_INT, 0}, {"__name__", T_INT, 0}, + {"__dict__", T_INT, 0}, {NULL} /* Sentinel */ }; +static int +instancemethod_setattro(im, name, v) + register PyMethodObject *im; + PyObject *name; + PyObject *v; +{ + char* sname = PyString_AsString(name); + if (sname == NULL) + return -1; + + if (PyEval_GetRestricted() || + strcmp(sname, "im_func") == 0 || + strcmp(sname, "im_self") == 0 || + strcmp(sname, "im_class") == 0) + { + PyErr_Format(PyExc_TypeError, "read-only attribute: %s", sname); + return -1; + } + if (im->im_self != NULL) { + PyErr_Format(PyExc_TypeError, + "cannot set bound instance-method attribute: %s", + sname); + return -1; + } + return PyObject_SetAttr(im->im_func, name, v); +} + + static PyObject * -instancemethod_getattr(im, name) +instancemethod_getattro(im, name) register PyMethodObject *im; PyObject *name; { - char *sname = PyString_AsString(name); + PyObject *rtn; + char* sname = PyString_AsString(name); + + if (sname == NULL) + return NULL; + if (sname[0] == '_') { /* Inherit __name__ and __doc__ from the callable object - implementing the method */ - if (strcmp(sname, "__name__") == 0 || - strcmp(sname, "__doc__") == 0) + implementing the method. Can't allow access to __dict__ + here because it should not be readable in restricted + execution mode. + */ + if (strcmp(sname, "__name__") == 0 || + strcmp(sname, "__doc__") == 0) { return PyObject_GetAttr(im->im_func, name); + } } if (PyEval_GetRestricted()) { - PyErr_SetString(PyExc_RuntimeError, - "instance-method attributes not accessible in restricted mode"); + PyErr_Format(PyExc_RuntimeError, + "instance-method attributes not accessible in restricted mode: %s", + sname); return NULL; + } + if (sname[0] == '_' && strcmp(sname, "__dict__") == 0) + return PyObject_GetAttr(im->im_func, name); + + rtn = PyMember_Get((char *)im, instancemethod_memberlist, sname); + if (rtn == NULL) { + PyErr_Clear(); + rtn = PyObject_GetAttr(im->im_func, name); } - return PyMember_Get((char *)im, instancemethod_memberlist, sname); + return rtn; } static void @@ -1672,8 +1719,8 @@ (hashfunc)instancemethod_hash, /*tp_hash*/ 0, /*tp_call*/ 0, /*tp_str*/ - (getattrofunc)instancemethod_getattr, /*tp_getattro*/ - 0, /*tp_setattro*/ + (getattrofunc)instancemethod_getattro, /*tp_getattro*/ + (setattrofunc)instancemethod_setattro, /*tp_setattro*/ }; /* Clear out the free list */ Index: Objects/funcobject.c =================================================================== RCS file: /projects/cvsroot/python/dist/src/Objects/funcobject.c,v retrieving revision 2.18 diff -u -r2.18 funcobject.c --- funcobject.c 1998/05/22 00:55:34 2.18 +++ funcobject.c 2000/04/11 22:06:12 @@ -62,6 +62,7 @@ doc = Py_None; Py_INCREF(doc); op->func_doc = doc; + op->func_dict = PyDict_New(); } return (PyObject *)op; } @@ -133,6 +134,8 @@ {"__name__", T_OBJECT, OFF(func_name), READONLY}, {"func_defaults",T_OBJECT, OFF(func_defaults)}, {"func_doc", T_OBJECT, OFF(func_doc)}, + {"func_dict", T_OBJECT, OFF(func_dict)}, + {"__dict__", T_OBJECT, OFF(func_dict)}, {"__doc__", T_OBJECT, OFF(func_doc)}, {NULL} /* Sentinel */ }; @@ -142,12 +145,21 @@ PyFunctionObject *op; char *name; { + PyObject* rtn; + if (name[0] != '_' && PyEval_GetRestricted()) { PyErr_SetString(PyExc_RuntimeError, "function attributes not accessible in restricted mode"); return NULL; + } + rtn = PyMember_Get((char *)op, func_memberlist, name); + if (rtn == NULL) { + PyErr_Clear(); + rtn = PyMapping_GetItemString(op->func_dict, name); + if (rtn == NULL) + PyErr_SetString(PyExc_AttributeError, name); } - return PyMember_Get((char *)op, func_memberlist, name); + return rtn; } static int @@ -156,6 +168,8 @@ char *name; PyObject *value; { + int rtn; + if (PyEval_GetRestricted()) { PyErr_SetString(PyExc_RuntimeError, "function attributes not settable in restricted mode"); @@ -178,8 +192,23 @@ } if (value == Py_None) value = NULL; + } + else if (strcmp(name, "func_dict") == 0 || + strcmp(name, "__dict__") == 0) + { + if (value == NULL || !PyMapping_Check(value)) { + PyErr_SetString( + PyExc_TypeError, + "must set func_dict to a mapping object"); + return -1; + } + } + rtn = PyMember_Set((char *)op, func_memberlist, name, value); + if (rtn < 0) { + PyErr_Clear(); + rtn = PyMapping_SetItemString(op->func_dict, name, value); } - return PyMember_Set((char *)op, func_memberlist, name, value); + return rtn; } static void @@ -191,6 +220,7 @@ Py_DECREF(op->func_name); Py_XDECREF(op->func_defaults); Py_XDECREF(op->func_doc); + Py_XDECREF(op->func_dict); PyMem_DEL(op); } from test_support import verbose class F: def a(self): pass def b(): pass # setting attributes on functions try: b.blah except AttributeError: pass else: print 'did not get expected AttributeError' b.blah = 1 print b.blah == 1 print 'blah' in dir(b) # setting attributes on unbound methods try: F.a.blah except AttributeError: pass else: print 'did not get expected AttributeError' F.a.blah = 1 print F.a.blah == 1 print 'blah' in dir(F.a) # setting attributes on bound methods is illegal f1 = F() try: f1.a.snerp = 1 except TypeError: pass else: print 'did not get expected TypeError' # but accessing attributes on bound methods is fine print f1.a.blah print 'blah' in dir(f1.a) f2 = F() print f1.a.blah == f2.a.blah F.a.wazoo = F f1.a.wazoo is f2.a.wazoo # try setting __dict__ illegally try: F.a.__dict__ = (1, 2, 3) except TypeError: pass else: print 'did not get expected TypeError' F.a.__dict__ = {'one': 111, 'two': 222, 'three': 333} print f1.a.two == 222 from UserDict import UserDict d = UserDict({'four': 444, 'five': 555}) F.a.__dict__ = d try: f2.a.two except AttributeError: pass else: print 'did not get expected AttributeError' print f2.a.four is f1.a.four is F.a.four test_funcattrs 1 1 1 1 1 1 1 1 1

3 2

UTF-8 is no fun...
by Andy Robinson 12 Apr '00

12 Apr '00

> > Things are hard to get right when you have to deal with > > backward *and* forward compatibility, interoperability and > > user-friendliness all at the same time... but we'll keep > > trying ;-) > > Let me say publically that I think you have done a fine job, and > obviously have put lots of thought and effort into it. If parts of > the design turn out to be less than ideal (and subsequently changed > before 1.6 is real) then this will not detract from your excellent > work. > > Well done! > > [And also to Fredrik, whose code was the basis for the Unicode > object itself - that was a nice piece of code too!] > Mark I've spent a fair bit of time converting strings and files the last few days, and I'd add that what we have now seems both rock solid and very easy to use. The remaining issues are entirely a matter of us end users trying to figure out what we should have asked for in the first place. Whether we achieve that finally before 1.6 is our problem; Marc-Andr\u00C9 and Fredrik have done a great job, and I think we are on track for providing something much more useful and extensible than (say) Java. As proof of this, someone has already contributed Japanese codecs based on the spec. - Andy Robinson

2 1

The purpose of the 'repr' builtin function
by pf＠artcom-gmbh.de 12 Apr '00

12 Apr '00

Hi! Currently the wrapper classes UserList und UserString contain the following method: def __repr__(self): return repr(self.data) I wonder about the following alternatives: def __repr__(self): return self.__class__.__name__ + "(" + repr(self.data) + ")" or even more radical (here only for lists as an example): def __repr__(self): result = [self.__class__.__name__, "("] for item in self.data: result.append(repr(item)) result.append(", ") result.append(")") return "".join(result) Just a thought which jumped into my mind during the recent discussion about the purpose of the 'repr' function (float representation). Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)

3 4

Extensible library packages
by Andrew M. Kuchling 12 Apr '00

12 Apr '00

For 1.6, the XML-SIG wants to submit a few more things, mostly a small SAX implementation. This currently lives in xml.sax.*. There are other subpackages around such as xml.dom, xml.utils, and so forth, but those aren't being proposed for inclusion (too large, too specialized, or whatever reason). The problem is that, if the Python standard library includes a package named 'xml', that package name can't be extended by add-on modules (unless they install themselves into Python's library directory, which is evil). Let's say Sean McGrath or whoever creates a new subpackage; how can he install it so that the code is accessible as xml.pyxie? One option that comes to mind is to have the xml package in the standard library automatically import all the names and modules from some other package ('xml_ext'? 'xml2') in site-packages. This means that all the third-party products install on top of the same location, $(prefix)/site-packages/xml/, which is only slightly less evil. I can't think of a good way to loop through everything in site-packages/* and detect some set of the available packages as XML-related, short of importing every single package, which isn't going to fly. Can anyone suggest a good solution? Fixing this may not require changing the core in any way, but the cleanest solution isn't obvious. -- A.M. Kuchling http://starship.python.net/crew/amk/ The mind of man, though perhaps the most splendid achievement of evolution, is not, surely, that answer to every problem of the universe. Hamlet suffers, but the Gravediggers go right on with their silly quibbles. -- Robertson Davies, "Opera and Humour"

5 4

Re: ANNOUNCE: Python 1.6 alpha 2
by Jonathan Giddy 12 Apr '00

12 Apr '00

Bill Janssen declared: > >ILU seems to work fine with it. > >Bill Without wishing to jinx this good news, isn't the release of 1.6 the appropriate time to remove the redundant thread.h file? Jon.

1 0