Mailman 3 February 2004 - Python-Dev

How to debug pyexpat SIGSEGV with GDB?
by Brad Clements March 1, 2004

March 1, 2004

Sorry if this is OT. I've hit a repeatable segfault in pyexpat on RH Linux 9 with Python 2.3.3 (I'm trying rss2email). It seems that XML_parse is returning an error, but when XML_GetCurrentLineNumber is called positionPtr is not valid. I catch this in GDB and have looked at the stack (see below), but when I get back up the stack into PyCFunction_Call I don't know what to do. Ideally, I want to find out the Python source file and line number that is currently being executed, then look at the Python source to figure out exactly which pyexpat call is being made just before the call to get_parse_result. It seems strange that (it appears) that Python code is calling get_parse_result directly. So, how can I figure out where in the Python source the function call is coming from using gdb? I'm sure it involves "print" and some casts.. I couldn't find a howto on python.org -- Python 2.3.3 (#1, Dec 22 2003, 14:01:09) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Starting program: /usr/local/bin/python2.3 rss2email.py feeds.dat run --no-send [New Thread 1074948352 (LWP 2379)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1074948352 (LWP 2379)] normal_updatePosition (enc=0x407211c0, ptr=0x40785000 <Address 0x40785000 out of bounds>, end=0x823ac09 "öteborg, Sweden, 7-9 June 2004. To help us serve the communit y in the best way possible, we need your input on what you think we should do in the way of tutorials.\"]\n\n\n\n\n\n, end=0x823ac09 "öteborg, Sweden, 7-9 June 2004. To help us serve the communit y in the best way possible, we need your input on what you think we should do in the way of tutorials.\"]\n\n\n\n\n\n<p "..., pos=0x8238954) at xmltok_impl.c:1745 #1 0x40701804 in XML_GetCurrentLineNumber (parser=0x82387c0) at /usr/local/src/Python-2.3.3/Modules/expat/xmlparse.c:1605 #2 0x406ff800 in set_error (self=0x4067e8ec, code=XML_ERROR_INVALID_TOKEN) at /usr/local/src/Python-2.3.3/Modules/pyexpat.c:124 #3 0x406fe324 in xmlparse_Parse (self=0x4067e8ec, args=0x4064456c) at /usr/local/src/Python-2.3.3/Modules/pyexpat.c:888 #4 0x080ed614 in PyCFunction_Call (func=0x4067f38c, arg=0x4064456c, kw=0x40785000) at ../Python-2.3.3/Objects/methodobject.c:108 #5 0x080a4de7 in call_function (pp_stack=0xbfffe91c, oparg=1080551660) at ../Python-2.3.3/Python/ceval.c:3439 (gdb) frame 0 #0 normal_updatePosition (enc=0x407211c0, ptr=0x40785000 <Address 0x40785000 out of bounds>, end=0x823ac09 "öteborg, Sweden, 7-9 June 2004." pos=0x8238954) at xmltok_impl.c:1745 1745 switch (BYTE_TYPE(enc, ptr)) { (gdb) list 1740 const char *ptr, 1741 const char *end, 1742 POSITION *pos) 1743 { 1744 while (ptr != end) { 1745 switch (BYTE_TYPE(enc, ptr)) { 1746 #define LEAD_CASE(n) \ 1747 case BT_LEAD ## n: \ 1748 ptr += n; \ 1749 break; (gdb) (gdb) frame 1 #1 0x40701804 in XML_GetCurrentLineNumber (parser=0x82387c0) at /usr/local/src/Python-2.3.3/Modules/expat/xmlparse.c:1605 1605 XmlUpdatePosition(encoding, positionPtr, eventPtr, &position); (gdb) list 1600 1601 int XMLCALL 1602 XML_GetCurrentLineNumber(XML_Parser parser) 1603 { 1604 if (eventPtr) { 1605 XmlUpdatePosition(encoding, positionPtr, eventPtr, &position); 1606 positionPtr = eventPtr; 1607 } 1608 return position.lineNumber + 1; 1609 } (gdb) frame 2 #2 0x406ff800 in set_error (self=0x4067e8ec, code=XML_ERROR_INVALID_TOKEN) at /usr/local/src/Python-2.3.3/Modules/pyexpat.c:124 124 int lineno = XML_GetErrorLineNumber(parser); (gdb) list 119 set_error(xmlparseobject *self, enum XML_Error code) 120 { 121 PyObject *err; 122 char buffer[256]; 123 XML_Parser parser = self->itself; 124 int lineno = XML_GetErrorLineNumber(parser); 125 int column = XML_GetErrorColumnNumber(parser); 126 127 /* There is no risk of overflowing this buffer, since 128 even for 64-bit integers, there is sufficient space. */ (gdb) print *parser $2 = {m_userData = 0x2, m_handlerArg = 0x40720ac0, m_buffer = 0x82387c0 "ìèg@ìèg@\b@v@TA\005\b$D\005\b´E\005\b\b@v@=Dw@\b@x@5\004\001", m_mem = {malloc_fcn = 0x1, realloc_fcn = 0, free_fcn = 0}, m_bufferPtr = 0x0, m_bufferEnd = 0x1 <Address 0x1 out of bounds>, m_bufferLim = 0x0, m_parseEndByteIndex = 8192, m_parseEndPtr = 0x0, m_dataBuf = 0x0, m_dataBufEnd = 0x81e66b0 "<\224f@¬\222f@\204\222f@ì\223f@ü\222f@\024\224f@<TA@,ÿe@", m_startElementHandler = 0x1, m_endElementHandler = 0x810a7a0 <PyString_Type>, m_characterDataHandler = 0x23, m_processingInstructionHandler = 0xffffffff, m_commentHandler = 0, m_startCdataSectionHandler = 0x7273752f, m_endCdataSectionHandler = 0x636f6c2f, m_defaultHandler = 0x6c2f6c61, m_startDoctypeDeclHandler = 0x702f6269, m_endDoctypeDeclHandler = 0x6f687479, m_unparsedEntityDeclHandler = 0x332e326e, m_notationDeclHandler = 0x6165772f, m_startNamespaceDeclHandler = 0x6665726b, m_endNamespaceDeclHandler = 0x79702e, m_notStandaloneHandler = 0, m_externalEntityRefHandler = 0, m_externalEntityRefHandlerArg = 0x1, m_skippedEntityHandler = 0x8117660 <PyCode_Type>, m_unknownEncodingHandler = 0x2, m_elementDeclHandler = 0x2, m_attlistDeclHandler = 0x2, m_entityDeclHandler = 0x43, m_xmlDeclHandler = 0x4067c3a0, m_encoding = 0x40677fac, m_initEncoding = { initEnc = {scanners = {0x4067d3bc, 0x40643e0c, 0x4012802c, 0x4012802c}, literalScanners = {0x4067e920, 0x4067f180}, sameName = 0x122, nameMatchesAscii = 0x4067f1a0, nameLength = 0x1, skipS = 0x810a7a0 <PyString_Type>, getAtts = 0x23, charRefNumber = 0xffffffff, predefinedEntityName = 0, updatePosition = 0x7273752f, isPublicId = 0x636f6c2f, utf8Convert = 0x6c2f6c61, utf16Convert = 0x702f6269, minBytesPerChar = 1869116537, isUtf8 = 110 'n', isUtf16 = 50 '2'}, encPtr = 0x6165772f}, m_internalEncoding = 0x6665726b, m_protocolEncodingName = 0x79702e <Address 0x79702e out of bounds>, m_ns = 0 '\0', m_ns_triplets = 0 '\0', m_unknownEncodingMem = 0x0, m_unknownEncodingData = 0x1, m_unknownEncodingHandlerData = 0x8117660, m_unknownEncodingRelease = 0x1, m_prologState = {handler = 0x4, level = 2, role_none = 67, includeLevel = 1080537744, documentEntity = 1080310604, inEntityValue = 1080546284}, m_processor = 0x40678e14, m_errorCode = 1074954284, m_eventPtr = 0x4012802c "}\v", m_eventEndPtr = 0x4067e9a0 "\001", m_positionPtr = 0x4067f220 "\002", m_openInternalEntities = 0x125, m_defaultExpandInternalEntities = 48 '0', m_tagLevel = 1080552288, m_declEntity = 0x810a7a0, m_doctypeName = 0x23 <Address 0x23 out of bounds>, m_doctypeSysid = 0xffffffff <Address 0xffffffff out of bounds>, m_doctypePubid = 0x0, m_declAttributeType = 0x7273752f <Address 0x7273752f out of bounds>, m_declNotationName = 0x636f6c2f <Address 0x636f6c2f out of bounds>, m_declNotationPublicId = 0x6c2f6c61 <Address 0x6c2f6c61 out of bounds>, m_declElementType = 0x702f6269, m_declAttributeId = 0x6f687479, m_declAttributeIsCdata = 110 'n', m_declAttributeIsId = 50 '2', m_dtd = 0x6165772f, m_curBase = 0x6665726b <Address 0x6665726b out of bounds>, m_tagStack = 0x79702e, m_freeTagList = 0x0, m_inheritedBindings = 0x0, m_freeBindingList = 0x4067ea20, m_attsSize = 135362144, m_nSpecifiedAtts = 0, m_idAttIndex = 0, m_atts = 0x1, m_nsAtts = 0x42, m_nsAttsVersion = 1080542056, m_nsAttsPower = 236 'ì', m_position = { lineNumber = 1080528484, columnNumber = 1074954284}, m_tempPool = { blocks = 0x4012802c, freeBlocks = 0x4012802c, end = 0x4067ea20 "`ëg@ §\020\b#", ptr = 0x4067d410 " \020g@@\215g@ýÿÿÿ\001", start = 0x121 <Address 0x121 out of bounds>, mem = 0x4067f1c0}, m_temp2Pool = {blocks = 0x1, freeBlocks = 0x810a7a0, end = 0x22 <Address 0x22 out of bounds>, ptr = 0x5e84331 <Address 0x5e84331 out of bounds>, start = 0x0, mem = 0x70747468}, m_groupConnector = 0x6f2f2f3a <Address 0x6f2f2f3a out of bounds>, m_groupSize = 1852402798, m_namespaceSeparator = 101 'e', m_parentParser = 0x746f6266, m_isParamEntity = 46 '.', m_useForeignDTD = 111 'o', m_paramEntityParsing = 1852795427} (gdb) (gdb) frame 3 #3 0x406fe324 in xmlparse_Parse (self=0x4067e8ec, args=0x4064456c) at /usr/local/src/Python-2.3.3/Modules/pyexpat.c:888 888 return set_error(self, XML_GetErrorCode(self->itself)); (gdb) list 883 { 884 if (PyErr_Occurred()) { 885 return NULL; 886 } 887 if (rv == 0) { 888 return set_error(self, XML_GetErrorCode(self->itself)); 889 } 890 if (flush_character_buffer(self) < 0) { 891 return NULL; 892 } (gdb) frame 4 #4 0x080ed614 in PyCFunction_Call (func=0x4067f38c, arg=0x4064456c, kw=0x40785000) at ../Python-2.3.3/Objects/methodobject.c:108 108 return (*meth)(self, arg); (gdb) list 103 size = PyTuple_GET_SIZE(arg); 104 if (size == 1) 105 arg = PyTuple_GET_ITEM(arg, 0); 106 else if (size == 0) 107 arg = NULL; 108 return (*meth)(self, arg); 109 } 110 break; 111 default: 112 PyErr_BadInternalCall(); -- Brad Clements, bkc(a)murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements

6 7

Optional separatorargument for file.writelines() and StringIO.writelines()
by Raymond Hettinger March 1, 2004

March 1, 2004

Currently, writelines() does not add trailing line separators.. This is fine when working with readlines() but a PITA in other situations. If we added an optional separator argument, it would be easier to add newlines and we would gain some of the flexibility of str.join() at full C speed. Raymond Hettinger

8 10

other uses for "as" [was Re: new syntax for wrapping (PEP 318)]
by Doug Holton March 1, 2004

March 1, 2004

> Skip> If you are going to add [...] as a function modifier syntax, > Skip> I would argue that it should allow the full power of list > Skip> (or generator) comprehensions. > > Agreed. And why limit it to lists - why not any expression that > evaluates to a list? Or maybe any sequence? Which is one reason > that a bare "[...]" doesn't seem sufficient. The "as" syntax is easier to understand and more readable, but you'd like to have the full power of lists as well (plus make the parsing easier). When there is just a single item though, the list syntax seems overkill. I can already tell if this feature is added it will likely stick with the list syntax instead of the "as" keyword because that is the easier solution to code. But here is an "as" solution that doesn't require extra coding for now. Have the parser check for a single item OR a list of items. You could add an "as" keyword but essentially ignore it in this case. This would mean though that this would not work: def myfunc(x, y) as synchronized, classmethod: ... You'd have to use the list syntax for multiple modifiers. If there is a decision to add the "as" keyword, here are some possible future expansions of its use. What it does is make the use of modifiers and type checking more readable. In general "X as Y" would mean --> Y(X) and "X as [Y, Z]" would mean --> Z(Y(X)) for example: X = temp_val as int means --> x = int(temp_val) thisobject = obj as MyType means --> thisobject = MyType(obj) Then there are Visual Basic -like params (let's not start a war about it): def func1(x as int, y as float): ... instead of: def func1(x, y): try: x2 = int(x) y2 = float(y) ...

5 6

RE: [Python-Dev] Re: new syntax for wrapping (PEP 318)
by Michael Chermside March 1, 2004

March 1, 2004

Jim Jewett writes: [I'm not going to quote him... details at http://mail.python.org/pipermail/python-dev/2004-February/042685.html ] Jim, thank you for putting this so clearly. I want to second just about everything that you said. Since you've gone into it in great detail, I'll try the brief, bullet-points version: The "def name [modifiers]:" is unpythonic because: * It re-uses the "[]" for a completely new purpose, unrelated to lists or indexing. * It relies heavily on punctuation (the placement of the ":"). * It doesn't "read like english". * There's no good way for a newbie to look it up. All of these would be addressed by using a keyword. The only objection seems to be "we couldn't find a word we all liked". But that's hardly a good reason to go with pure punctuation. Me, personally, I like "as". It works great for wrappers like classmethod, and is a sufficiently generic word that it wouldn't offend my sense of grammer when used with other kinds of wrappers. But like Jim I'm not strongly in favor of any particular keyword, just against the use of pure punctuation. -- Michael Chermside

15 28

[UPDATED] PEP 318 - Function/Method Decorator Syntax
by Kevin Smith Feb. 28, 2004

Feb. 28, 2004

I have updated PEP 318 to include the various other syntaxes suggested in the past few days at python-dev. I have also included an Open Issues section which introduces a question about exactly what a decorator is required to do in order to function properly. PEP: 318 Title: Function/Method Decorator Syntax Abstract The current method for declaring class and static methods is awkward and can lead to code that is difficult to understand. This PEP introduces possible new syntax which will place the translation of instance methods to class/static methods at the same point in the code as the method's declaration. Motivation The current method of translating an instance method into a class/static method places the actual translation at a different point in the code than the declaration of the method. The code below demonstrates this. def foo(self): perform method operation foo = classmethod(foo) When the method is very short, it is easy to look ahead and see that this is a class method. However, if the method is more than 15 lines or so, the translation into a class method is not obvious. A solution to this problem is to move the translation of the method to the same point as the method's declaration. The proposed syntax, shown in the example below, is discussed in the following sections. def foo(self) as synchronized(lock), classmethod: perform method operation Proposal Probably the simplest way to place the decorator that translates an instance method to a class/static method is illustrated in the code below. def classmethod foo(self): perform method operation The code in this example will simply perform the following. def foo(self): perform method operation foo = classmethod(foo) This syntax does not introduce any new keywords and is completely backwards compatible with any existing code. The word between the 'def' and the actual name of the method is simply a reference to a callable object that returns a new function reference. This syntax could also be extended to allow multiple function decorators in the form of a space delimited list as follows: def protected classmethod foo(self): perform method operation which would be equivalent to the current form: def foo(self): perform method operation foo = protected(classmethod(foo)) While this syntax is simple and easy to read, it does become cluttered and more obscure if you wish to allow arguments to be sent to the function decorator. def synchronized(lock) classmethod foo(self): perform method operation Instead of placing the decorators in front of the function name, a better place might be after it, as shown below. The word 'as' is added simply as a separator to assist in readability. def foo(self) as synchronized(lock), classmethod: perform method operation This syntax is quite clear and could probably be interpreted by those not familiar with Python. The proposed syntax can be generalized as follows: 'def' NAME '(' PARAMETERS ')' ['as' DECORATORS] ':' where DECORATORS is a comma-separated list of expressions, or a tuple. Using the latter form, the last example above would look like: def foo(self) as (synchronized(lock), classmethod): perform method operation This form make is possible for the list of decorators to span multiple lines without using the line continuation operator. Alternate Syntaxes Other syntaxes have been proposed in comp.lang.python and python-dev. Unfortunately, no one syntax has come out as a clear winner in the lengthy discussions. The most common suggestions are demonstrated below. The proposed syntax is also included for easy comparison. Proposed Syntax def foo(self) as synchronized(lock), classmethod: perform method operation def foo(self) as (synchronized(lock), classmethod): perform method operation Prefix Forms def [synchronized(lock), classmethod] foo(self): perform method operation def synchronized(lock), classmethod foo(self): perform method operation # Same as above, but only identifiers are allowed sync = synchronized(lock) def sync, classmethod foo(self): perform method operation # Java-like sync = synchronized(lock) def @sync @classmethod foo(self): perform method operation Postfix Forms def foo(self) [synchronized(lock), classmethod]: perform method operation def foo(self) (synchronized(lock), classmethod): perform method operation def foo(self) {'pre': synchronized(lock), 'classmethod': True}: perform method operation I'm not as fond of the forms that use '[ ]' since code like 'foo()[a]' looks as if you are getting the item 'a' from 'foo()'. Although, this isn't as much of an issue when using '[ ]' in a prefix form. The Java-like syntax adds new syntax that is very arbitrary and is almost Perl-ish. In addition, since the order in which the decorators are applied may matter, the last, dictionary-style, syntax must be eliminated. Implementation Issues In the following example there are two function decorators: synchronized(lock) and classmethod. def foo(self) as synchronized(lock), classmethod: perform method operation Since these all appear within the operation of the 'def' itself, it makes sense that synchronized, lock, and classmethod must exist at the time that the definition is executed. In addition, each of these arguments will be evaluated before being applied to the compiled function. This means that arguments like synchronized(lock) must return a descriptor that will be applied to foo. Therefore, the code above translates to: def foo(self): perform method operation foo = classmethod(<returned-descriptor>(foo)) In the example above, <returned-descriptor> refers to the descriptor returned by evaluating synchronized(lock). It could easily be argued that the descriptors should be applied in reverse order to make the application of the descriptor look more like the resultant code. I tend to prefer this form. def foo(self): perform method operation foo = <returned-descriptor>(classmethod(foo)) In either case, the modified function is bound to the function name when the 'def' statement is executed. Open Issues It is not clear at the moment if it is even possible to have multiple decorators for a function. If decorators are required to take a function/method and return a descriptor, it might not even be possible to wrap multiple decorators. This should be explored since the best syntax for multiple decorators may not be the same as the best syntax for a single decorator. Current Implementations I am not personally familiar enough with Python's source to implement the proposed syntax; however, Michael Hudson has implemented the "square-bracketed" syntax (see patch at http://starship.python.net/crew/mwh/hacks/meth-syntax-sugar.diff). It should be fairly simple for the Python development team to translate this patch to the proposed syntax. Possible Extensions The proposed syntax is general enough that it could be used on class definitions as well as shown below. class foo(object) as classmodifier: class definition here However, there are no obvious parallels for use with other descriptors such as property(). Conclusion The current method of translating an instance method to a class or static method is awkward. A new syntax for applying function decorators should be implemented (proposed syntax shown below). def foo(self) as synchronized(lock), classmethod: perform method operation The proposed syntax is simple, powerful, easy to read, and therefore preserves those qualities of the Python language. Copyright This document has been placed in the public domain. Kevin Smith Kevin.Smith(a)themorgue.org

1 0

RE: [Python-Dev] Re: new syntax for wrapping (PEP 318)
by Delaney, Timothy C (Timothy) Feb. 28, 2004

Feb. 28, 2004

Wow - I come into work, and the discussion's exploded :) I've read through the entire thread before writing, so I've been able to absorb the various proposals. I'll summarise them as I see them (I'll leave out the most loony ones Christian ;), and add notes. I'll deliberately *not* use 'staticmethod' or 'classmethod' as I don't believe there's any point to restricting the mechanism to those, and use of those will colour perceptions. Instead, I'm going to use metasyntactic variables. For each I'll throw in some basic formatting (normal case) plus some nasty formatting. 1. Single parameter, single decorator: a. def foo (bar) [baz]: pass b. def foo (bar) as baz: pass c. def [baz] foo (bar): pass d. def baz foo (bar): pass e. def foo [baz] (bar): pass (1c) and (1d) don't parse well to me at all. IMO the function name is the most important information in the declaration - it tells you what the function *is*. (1d) is particularly bad, as it makes it very difficult to pick the function name out. Now, much of this could be obviated by a sufficiently-intelligent editor, but most editors are not that intelligent, and it's better if they're not actually needed. (1e) Doesn't work for me because the parameters are IMO the second-most important info in the declaration. It would be too easy to confuse the decorators with the parameters. (1b) is the most visually pleasing, but the lack of syntax means that the decorator doesn't stand out as well as (a). However, it's simple to syntax-colour 'as', so that's close to a non-issue. (1a) seems to be the most understandable, and is quite visually pleasing - the decorator is obviously special, but feels more like it's an explanatory note. 2. Multiple parameters, multiple decorators: a. def foo (bar, baz) [qux, quux]: pass b. def foo (bar, baz) as qux, quux: pass c. def [qux, quux] foo (bar, baz): pass d. def qux, quux foo (bar, baz): pass e. qux_quux = qux, qux def qux_quux food (bar, baz): pass f. def foo [qux, quux] (bar, baz): pass (2c), (2d) and (2e) suffer from the same problems as (1c) and (1d), but worse - the function name is even *more* hidden. Esp. in (2d). (2f) suffers the same problem as (1e) - the parameters are separated from the function name. (2b) again isn't bad - visually pleasing. The decorators actually stand out better here than in (1b) as they are separated by commas. 3. Multi-line declarations: a. def foo (bar, baz) [qux, quux]: pass b. def foo (bar, baz) as qux, quux: pass c. def [qux, quux] foo (bar, baz): pass d. def qux, quux foo (bar, baz): pass e. def foo [qux, quux] (bar, baz): pass Well, they all look horrible ... ;) (3b) and (3d) don't work without changing the parsing rules. It would be necessary to have a bracketing syntax to make them work. In which case, they become almost equivalent to (3a) and (3c) respectively. In (3e) I found that I started typing 'def foo [bar...' which indicates that my earlier feeling that having the parameters separated from the name is a Bad Thing (TM). (3c) actually works better than the previous examples of this IMP because the function name stands out a lot more. But it's still not that noticeable IMO. (3a) allows the function definition to be laid out in a reasonable (not nice) manner. Of them all I find it the best in this situation. So my conclusion is that for me, the decorators work best following the function definition, and my preference is for [] syntax. *Some* form of bracketing syntax needs to be at least allowable in order to break across multiple lines. > From: Pete Shinners [snip] > I think this feature will be another one of those positive > changes that > effects the entire way python is used. The kind of thing like > iterators, > string methods, etc. I've been playing with the idea for > awhile and can > throw out some extra use cases. I think it will be a *very* important advancement to the language - even if some of the constructs below are somewhat ... dubious ;) > def main() [__main__]: > """specify a function to be run if __name__=='__main__'. this > would need some other python tricks to actually work.""" Urgh! Deep magic! Run away! > def cleanup() [sys.atexit]: > """ensures this function is called when program quits.""" This isn't too bad. Probably better with a wrapper around sys.atexit - something like: def atexit (func): sys.atexit(func) return func def cleanup() [atexit]: otherwise it's not obvious that cleanup gets bound to None. Perhaps it should be a requirement of decorators that they return something other than None, and an exception is thrown if this contract is broken? > def handler(event) [self.button.slot('clicked')]: > """automatically make this function a callback for some > gui slot/signal mechanism.""" Could be useful, but I think it's probably better to assign explicitly. It would depend on how the rest of the code was structured though. > def food(arg) [pysco.optimize]: > """specifically control functions that psyco takes over.""" I really like this. Although I must admit, in most of the programs I write, it's most useful to just do a `psyco.full()` at the start :) > def bard(arg, gar) [validate(int, str)]: > """confirm arguments match a type. validate would > have to be a function that returns a function. odd.""" Interesting idea. I have to think about it more. > def corn() [profiler.track]: > """log specific runtime stats on this function.""" Could be really useful. > def sanitytest() [sys.debugfunc]: > """function is ignored at runtime if python not in > "-O" optimize mode (something like assert).""" Hmm - not so sure I like this. I can see how it would work of course ... def debugfunc (func): if __debug__: return func() def sanitytest() [debugfunc]: Overall, I don't think it would be of much use. > def entrypoint(data) [__all__]: > def hidden(data) [__hidden__]: > """select functions for hiding or passing to 'import *'.""" We've already got a mechanism for this - use underscores to hide names, or declare __all__. I wouldn't see a real use for this. Anyway, those are my thoughts on the whole topic. I'm: +1 on syntax for decorators attached to function definitions +1 on def foo (bar) [baz]: +0 on def foo (bar) as baz: if there's a way to extend it multi-line. -1 on all the other proposed syntaxes. -1 on restricting it to specific decorators such as classmethod Cheers. Tim Delaney

10 13

What is the ":" for in python?
by Barry Scott Feb. 28, 2004

Feb. 28, 2004

I was asked why python required a ":" in its syntax and then saw Pete Shinners query on changing the parser to treat "def" to ":" as a unit. What is the purpose of the ":"? Why doesn't the parser work as Pete suggests already? Of course the same rules should be true of "if" and ":", "while" and ":" I've always wanted to be able to write: if x > 10 and x < 20: do_in_range() rather then if( x > 10 and x < 20 ): do_in_range() Barry

2 2

RE: [Python-Dev] Re: new syntax for wrapping (PEP 318)
by Michael Chermside Feb. 27, 2004

Feb. 27, 2004

I've been reading the hailstorm of comments on PEP 318. Yipes... did I help start that off? Lots of good ideas (and some others too) have been raised. I thought I would just weigh in with what I have learned so far. (1) Starting with Pete Shiner's creative list and butressed by subsequent suggestions, I am more convinced than ever that function decorators are actually VERY USEFUL. I'm now strongly +1 on PEP 318 with SOME syntax. (2) I originally objected to "def foo (bar,baz) [qux, quux]:" on the grounds that it relied too heavily on punctuation and using a keyword ("def foo (bar,baz) as qux, quux") would be better. I think that most of my objections have been addressed: * I said "but what would newbies look up", but then Paul Moore pointed out "Who, as a new user, saw 'import something as another' and looked up 'as' rather than 'import'?". He's right. * I said "def marmalade(self) [classmethod]:" versus "def marmalade(self): [classmethod]" is confusing, but then I think that two objections still stand: * "def foo (bar,baz) [qux, quux]:" is certainly not "executable pseudocode". * This is yet another meaning for "[]" in Python, it is certainly not indexing, and it differs subtly from list literals an list comprehensions. I suppose this objection could be mitigated by declaring that any expression evaluating to an iterable could be used (and sane people would use a list literal). However, there are objections to all other syntaxes that have been proposed, and I'm beginning to think that "def foo (bar,baz) [qux, quux]:" may be the best of the bunch despite these shortcomings. -- Michael Chermside

2 1

Re: [Python-Dev] OpenVMS file system and UNIVERSAL_NEWLINES support
by Michael Chermside Feb. 27, 2004

Feb. 27, 2004

Skip writes: > What about Py_HAS_STREAM_IO? [...] > Or the contr, something like Py_HAS_NO_STREAM_IO. That doesn't read very > well though. Py_LACKS_STREAM_IO -- Michael Chermside

1 0

Distutils dependencies sprint at PyCon?
by Phillip J. Eby Feb. 27, 2004

Feb. 27, 2004

Bob Ippolito and I have been talking about working on distutils dependency support while at PyCon. The subject has recently come up on both the Zope3-Dev and Twisted mailing lists, with respect to being able to: 1) break up monolithic systems (PEAK, Zope, Twisted) into smaller package sets with dependencies 2) allow dependencies on other systems (e.g. Twisted using PyProtocols, PEAK using zope.publisher, etc.) 3) support painless install for end users (single command to download and install "everything needed") even at the cost of a little pain for the packager(s). 4) allow dependencies on packages that were packaged with the distutils, but *not* specifically designed to work with the dependency system. In other words, if I want to depend on package X, I should not need to bug package X's author, I should be able to "just do it". 5) Support Python 2.2, while not requiring changes to the distutils, but being a possible candidate for upgrades to the distutils in 2.4. If there's a group that would like to sprint to produce working deliverables for one or more aspects of this problem area (and I think PIMP/PackMan shows that solutions are within reach), I'd like to get some schedule commitments so I can plan a trip. I wasn't originally planning to go to PyCon this year, but I *will* come if it means we can get this thing implemented. If there is sufficient interest, let's take this to an appropriate mailing list (perhaps distutils-sig?) and Wiki to put together a detailed set of stories, as long as we can prioritize the list according to the needs of the folks who will be doing the development. If you're interested in participating in such a sprint, please let me know ASAP, so I can make travel arrangements. Thanks. (Please reply to me personally rather than to the list(s); I will summarize and post an announcement of where to direct further discussion, if there's enough interest to get this off the ground. Thanks!)

1 0