Mailman 3 October 2001 - Python-Dev

pychecker warnings from python-current
by Neal Norwitz Oct. 13, 2001

Oct. 13, 2001

Here's a new set of warnings from pychecker (current) against python-current as of 13 Oct: cgi.py:250: No global (ib) found (no idea which variable is desired, best guess is boundary) gzip.py:292: No global (f) found (f should be self?) markupbase.py:306: Invalid arguments to (error), got 2, expected 1 (not sure if this is a problem or not) rexec.py:262: Using the return value from (execfile) which is always None (not really a problem, but implies there is a return value other than None) smtplib.py:540: No global (SMTPError) found (should be SMTPException?) urllib.py:587: Invalid arguments to (http_error_default), got 5, expected 6 (needs errcode passed as 4th arg, between fp & errmsg) webbrowser.py:182: No global (_os) found (should be os) There's also a problem in Objects/stringobject.c on line 2541. The docstring for ''.splitlines() has an extra ]. Neal

2 2

GC head alignment issue
by Guido van Rossum Oct. 12, 2001

Oct. 12, 2001

See this bug report: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=467145&group_id… The GC header adds 12 bytes to the start of the object, but for objects (like complex) that contain a double and require double alignment, that messes up the alignment. Something needs to be done about this: I'm guessing a configuration test for the required alignment of double, and a rounding up of the GC head size to a multiple of that. Should affect only the AS_GC and FROM_GC macros in gcmodule.c and the two uses of sizeof(PyGC_Head) there -- unless you can figure out a way to add a pad field to the GC head only when needed, then a change to objimpl.h might be sufficient. So far this only affects HP hardware, but we can't trust that! (It hasn't affected 2.0 or 2.1 because it only breaks when I *subclass* complex.) --Guido van Rossum (home page: http://www.python.org/~guido/)

5 12

profiler hooks
by Fred L. Drake, Jr. Oct. 12, 2001

Oct. 12, 2001

For those who aren't already aware of it, I've been working on a new profiler for Python, implemented in C. It includes features that will allow per-line profiling if desired. I should have the implementation checked in shortly. One thing that I'd like to change is the way the profiler/tracer are dispatched from the main eval loop. The changes are easy enough, but I can simplify things further if we don't need to support both a profiler and tracer simultaneously. (The trace hook is used by sys.settrace(), needed for the debugger and 3rd-party coverage tools; the profile hook is used for (you guessed it!) the profiler, via sys.setprofile().) Would anyone object to working things so that only one of the two can be installed at a time? They can both operate, but it doesn't make sense to use the trace hook while a profiler is active. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

3 4

Bug or feature? Unicode vs t#
by Martin v. Loewis Oct. 12, 2001

Oct. 12, 2001

> So change the docs. hexlify() hasn't changed, yet the result has. > So long as Unicode objects support the buffer interface, the > question is why they've changed how they respond to that interface. Unicode objects haven't changed in their response to the buffer interface. What has changed is how t# uses this interface. AFAICT, the change has occured in version 2.59 of getargs.c, in response to patch #426072. In 2.1.1, t# used to call the getcharbuffer operation, now it calls the getreadbuffer function. For Unicode objects, these are different: getcharbuffer converts the string using the default encoding into a character string, whereas getreadbuffer returns a pointer to the internal representation (depending on the platform, this makes 2 or 4 bytes per Unicode character, and they may come out either little or big endian). It seems that the problem is in the simplification attempted with said patch. Regards, Martin

8 11

Type checks of instance variables
by Andy Robinson Oct. 11, 2001

Oct. 11, 2001

> class Color(object): > __slots__ =TypedSlots({ "r":(unsignedByte,unsignedByte(0), > "g":(unsignedByte,unsignedByte(0), > "b":(unsignedByte,unsignedByte(0), > "name":str}) > This sounds great. In fact, it's almost exactly what we have been trying to do in reportlab/graphics for the last six months: a graphical widget hierarchy which has to check the type of every assignment and maybe trigger recalculations, because it supports a GUI. It was one of the few occasions when I wished I was using Delphi instead of Python :-) Reportlab would certainly be interested in a standardised framework for property-checking. Let me throw in a few more ideas: (1) __slots__ could hold optional attribute doc strings (2) 'one of a list' is a mightily useful type, and we have GUIs that can infer enough from this to build smart editing interfaces. (3) frequently you want the __slots__ for a class to 'inherit' from a parent, which we do by allowing one to pass in the parent's class; it then looks for the __slots__ in that as a starting point. (4) you may also sometimes want to delete things from the __slots__ in a derived class, and to reduce visibility. (5) things can get slow. I'm also wondering if support for type-checking classes could be enhanced by a C extension, so that if one stuck to a basic bunch of types, the penalty of checking every attribute assignment would not be too great. It would still need to call out to Python if the 'checking function' was written in Python. Here's one of our classes: class Marker(Widget): '''A polymorphic class of markers''' _attrMap = AttrMap(BASE=Widget, kind = AttrMapValue( OneOf(None, 'Square', 'Diamond', 'Circle', 'Cross', 'Triangle', 'StarSix', 'Pentagon', 'Hexagon','Heptagon', 'Octagon', 'FilledSquare','FilledCircle', 'FilledDiamond', 'FilledCross','FilledTriangle','FilledStarSix', 'FilledPentagon', 'FilledHexagon', 'FilledHeptagon', 'FilledOctagon', 'Smiley'), desc='marker type name'), size = AttrMapValue(isNumber,desc='marker size'), x = AttrMapValue(isNumber,desc='marker x coordinate'), y = AttrMapValue(isNumber,desc='marker y coordinate'), dx = AttrMapValue(isNumber,desc='marker x coordinate adjustment'), dy = AttrMapValue(isNumber,desc='marker y coordinate adjustment'), angle = AttrMapValue(isNumber,desc='marker rotation'), fillColor = AttrMapValue(isColorOrNone, desc='marker fill colour'), strokeColor = AttrMapValue(isColorOrNone, desc='marker stroke colour'), strokeWidth = AttrMapValue(isNumber, desc='marker stroke width'), ) Regards, Andy Robinson CEO/Chief Architect, Reportlab Inc.

3 3

Re: [Python-Dev] Type checks of instance variables
by Michael McLay Oct. 11, 2001

Oct. 11, 2001

On Wednesday 10 October 2001 05:58 pm, Andy Robinson wrote: > Let me throw in a few more ideas: > > (1) __slots__ could hold optional attribute doc strings > (2) 'one of a list' is a mightily useful type, > and we have GUIs that can infer enough from this > to build smart editing interfaces. > (3) frequently you want the __slots__ for a class > to 'inherit' from a parent, which we do by allowing > one to pass in the parent's class; it then looks > for the __slots__ in that as a starting point. > (4) you may also sometimes want to delete things > from the __slots__ in a derived class, and to reduce > visibility. I hope we can use the TypedSlots proposal as a starting point and refine it until it also meets the requirements for ReportLab and Grouch. The following example attempts to add the features you suggested. It extends the original TypedSlots definition to include actions that would be applied to slots. Adding type checking actions would simplify writing a number of applications, such as validation software for XML Schema. The XML Schema type system inspired the Restrict action in the example. The XML Schema type system could be used to identify candidate actions to be added to TypedSlots. class Widget(object): __slots__ = TypedSlots({ "name": CheckType(str, doc="The name by which a widget can be referenced")}) class Color(Widget): __slots__ = TypedSlots({ "r": CheckType(unsignedByte, default = unsignedByte(0)), "g": CheckType(unsignedByte, default = unsignedByte(0)), "b": CheckType(unsignedByte, default = unsignedByte(0)),}) class Shape(Widget): __slots__ = TypedSlots({ "colorRef": CheckType(Color)}) class Circle(Shape): __slots__ = TypedSlots({ "diameter": CheckType(Number,default=1)}) class RedCircle(Circle): """Define a type for red Circles. The Restrict declaration allows the "colorRef" name to be restricted to a subset of the allowed values of the colorRef name. In this case a ReadOnly flag is set to keep the Circle color from being changed and the value is set. """ __slots__ = TypedSlots({"colorRef": Restrict( ReadOnly( Color(r=255)))}) class Drawable(Widget): """The OneOf action allows one of several types to be assigned to the name. Most likely all the types share a common interface. """ __slots__ = TypedSlots({"shapeRef":OneOf(Circle, RedCircle,Rectangle)}) > (5) things can get slow. I'm also wondering if support > for type-checking classes could be enhanced by a C > extension, so that if one stuck to a basic bunch of types, > the penalty of checking every attribute assignment > would not be too great. It would still need to > call out to Python if the 'checking function' was > written in Python. Performance will benefit from making C enhancements. Creating a type verification system that can't be hacked (from Python) will require writing some of the implementation in C. The danger in extending the actions of the TypedSlots to more than a simple type check on __set__ is that it will become to complected to implement in a timely manner. What is the bare minimum required? Specification languages tend to grow to be ugly monsters. Can we start small and add other actions as needed? Could some of the actions be defined in a Python module? > > Here's one of our classes: > > class Marker(Widget): > '''A polymorphic class of markers''' > _attrMap = AttrMap(BASE=Widget, > kind = AttrMapValue( > OneOf(None, 'Square', 'Diamond', > 'Circle', 'Cross', 'Triangle', 'StarSix', > ... My project involves capturing the product information for printed circuit boards and printed circuit assemblies. You r example looks like it came right out of the definition of the graphics required to by tools that draw the layers of a printed circuit board.

1 0

Bug or feature? Unicode vs t#
by Tim Peters Oct. 11, 2001

Oct. 11, 2001

Here in current CVS Python: >>> import binascii >>> binascii.hexlify(u'a') '6100' >>> In 2.1.1, it's '61' instead. I don't know what ought to happen, but 2.1.1 suprised me less. binascii inherits its view of the argument via PyArg_ParseTuple's t# code.

4 5

Re: [Python-checkins] CVS: python/dist/src/Lib xmlrpclib.py,1.11,1.12
by Jeremy Hylton Oct. 11, 2001

Oct. 11, 2001

>>>>> "SM" == Skip Montanaro <montanaro(a)users.sourceforge.net> writes: SM> Update of /cvsroot/python/python/dist/src/Lib In directory SM> usw-pr-cvs1:/tmp/cvs-serv25433 SM> Modified Files: SM> xmlrpclib.py SM> Log Message: allow long ints to be marshalled as ints - no check SM> is made to the incoming value, so the programmer will have to SM> catch OverflowError. How does the other end unmarshal it? You shouldn't get overflow errors any more. Oh, well, actually you do still get overflow and value errors from the builtin int(). I wonder if there should be a generic number-from-string conversion function that returns either a long or an int as needed. If an integer literal in your program text can produce a long, why can't builtin int()? Jeremy

7 11

Re: [pygtk] How to delete Gtk objects
by Skip Montanaro Oct. 10, 2001

Oct. 10, 2001

(adding python-dev to this conversation because decisions about missing special methods vis a vis PEP 252/253 seem to me to definitely belong in that space.) >> I think that there may be some problems with extended types and >> __del__? Matt> For example: Matt> class myList(type([])): Matt> def __del__(self): Matt> print "list dealloced" Matt> list = myList() Matt> list.append("foo") Matt> list.append("bar") Matt> del list Matt> never prints list delloced. My guess (without examining any code) is that __del__ is not implemented for new-style classes. There is this rather cryptic note at the end of PEP 253: - open issues: ... - do we need __coerce__, __del__? ... which leads me to believe that __del__ would not be called in the current implementation. If people are going to be subclassing more than the traditional builtin types I think __del__ methods will have to be supported. Skip

2 1

__del__ and subclassed types
by Matt Wilson Oct. 10, 2001

Oct. 10, 2001

Python 2.2a4: class myList(type([])): def __del__(self): print "list dealloced" list = myList() del list never prints "list dealloced". Is this supposed to work? Cheers, Matt

3 2