Mailman 3 August 2001 - Python-Dev

segmentation fault in tuple parsing
by Jun-ichiro itojun Hagino Aug. 4, 2001

Aug. 4, 2001

it looks that there's some issue with tuple passing (PyArg_ParseTuple). the last argument of vgetargs1(), which is 0, is dereferenced in convertsimple(). sorry if this is due to my mistake in socketmodule IPv6 support. itojun (gdb) run Starting program: /usr/home/itojun/work/python/python/dist/src/python Python 2.2a1 (#12, Aug 4 2001, 10:17:23) [GCC egcs-2.91.66 19990314 (egcs-1.1.2 release)] on netbsd1 Type "help", "copyright", "credits" or "license" for more information. >>&… [View More]gt; import socket >>> socket.getnameinfo(('::1', 80, 0, 0), 0) Program received signal SIGSEGV, Segmentation fault. convertsimple (arg=0x80e43ac, p_format=0xbfbfcda4, p_va=0xbfbfcf80, msgbuf=0xbfbfce68 "\af\027H Ç\021\b\b+\030H") at Python/getargs.c:501 501 *p = ival; (gdb) bt #0 convertsimple (arg=0x80e43ac, p_format=0xbfbfcda4, p_va=0xbfbfcf80, msgbuf=0xbfbfce68 "\af\027H Ç\021\b\b+\030H") at Python/getargs.c:501 #1 0x806ab6c in convertitem (arg=0x80e43ac, p_format=0xbfbfcf74, p_va=0xbfbfcf80, levels=0xbfbfcde8, msgbuf=0xbfbfce68 "\af\027H Ç\021\b\b+\030H") at Python/getargs.c:351 #2 0x8068a72 in vgetargs1 (args=0x813d18c, format=0x481980b0 "i", p_va=0xbfbfcf80, compat=0) at Python/getargs.c:197 #3 0x80686fd in PyArg_ParseTuple (args=0x813d18c, format=0x481980ac "si|ii") at Python/getargs.c:52 #4 0x48194319 in PySocket_getnameinfo (self=0x0, args=0x811c3cc) at /usr/home/itojun/work/python/python/dist/src/Modules/socketmodule.c:2430 #5 0x8059f35 in call_cfunction (func=0x81871cc, arg=0x811c3cc, kw=0x0) at Python/ceval.c:3072 #6 0x805744d in eval_frame (f=0x80e7c0c) at Python/ceval.c:1912 #7 0x8058461 in PyEval_EvalCodeEx (co=0x80fbdc0, globals=0x80f2d0c, locals=0x80f2d0c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2517 #8 0x8059ea3 in PyEval_EvalCode (co=0x80fbdc0, globals=0x80f2d0c, locals=0x80f2d0c) at Python/ceval.c:490 #9 0x8073f48 in run_node (n=0x80f5c00, filename=0x80b4975 "<stdin>", globals=0x80f2d0c, locals=0x80f2d0c, flags=0xbfbfd65c) at Python/pythonrun.c:1058 #10 0x8072a0e in PyRun_InteractiveOneFlags (fp=0x80dafd0, filename=0x80b4975 "<stdin>", flags=0xbfbfd65c) at Python/pythonrun.c:578 #11 0x8073997 in PyRun_InteractiveLoopFlags (fp=0x80dafd0, filename=0x80b4975 "<stdin>", flags=0xbfbfd65c) at Python/pythonrun.c:514 #12 0x8073802 in PyRun_AnyFileExFlags (fp=0x80dafd0, filename=0x80b4975 "<stdin>", closeit=0, flags=0xbfbfd65c) at Python/pythonrun.c:477 #13 0x8051da3 in Py_Main (argc=1, argv=0xbfbfd6b8) at Modules/main.c:332 #14 0x8051742 in main (argc=1, argv=0xbfbfd6b8) at Modules/python.c:10 #15 0x8051579 in ___start () (gdb) frame 1 #1 0x806ab6c in convertitem (arg=0x80e43ac, p_format=0xbfbfcf74, p_va=0xbfbfcf80, levels=0xbfbfcde8, msgbuf=0xbfbfce68 "\af\027H Ç\021\b\b+\030H") at Python/getargs.c:351 351 msg = convertsimple(arg, &format, p_va, msgbuf); (gdb) print p_va $1 = (va_list *) 0xbfbfcf80 (gdb) frame 2 #2 0x8068a72 in vgetargs1 (args=0x813d18c, format=0x481980b0 "i", p_va=0xbfbfcf80, compat=0) at Python/getargs.c:197 197 msg = convertitem(PyTuple_GET_ITEM(args, i), &format, p_va, (gdb) list 192 } 193 194 for (i = 0; i < len; i++) { 195 if (*format == '|') 196 format++; 197 msg = convertitem(PyTuple_GET_ITEM(args, i), &format, p_va, 198 levels, msgbuf); 199 if (msg) { 200 seterror(i+1, msg, levels, fname, message); 201 return 0; (gdb) print format $2 = 0x481980b0 "i" (gdb) frame 3 #3 0x80686fd in PyArg_ParseTuple (args=0x813d18c, format=0x481980ac "si|ii") at Python/getargs.c:52 52 retval = vgetargs1(args, format, &va, 0); (gdb) list 47 { 48 int retval; 49 va_list va; 50 51 va_start(va, format); 52 retval = vgetargs1(args, format, &va, 0); 53 va_end(va); 54 return retval; 55 } 56 [View Less]

1 0

[development doc updates]
by Fred L. Drake Aug. 3, 2001

Aug. 3, 2001

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ A variety of updates, including the first installment for the distutils API docs (in "Distributing Python Modules"), and some contributed material on embedding Python (in "Extending and Embedding the Python Interpreter"). There were many other small improvements and bug fixes.

1 0

Python API version & optional features
by Martin v. Loewis Aug. 3, 2001

Aug. 3, 2001

> Shouldn't Python automatically Do The Right Thing in that case? That > would mean wrapping the UCS4 calls in a conversion layer, which > isn't hard. I mean, it's just a question of adding or taking away > zeroes, right? :) Given the smiley at the end of your message, I don't know whether you meant your point seriously or not. I believe it is impossible for Python to do what you seem to think as the "Right Thing". E.g. modules that use PyUnicode_AS_UNICODE will behave differently … [View More]

3 2

RFC: generator combinator syntax
by Steven D. Majewski Aug. 3, 2001

Aug. 3, 2001

FYI: In the thread on comp.lang.python with the subject: "Nested generators is the python equivalent of unix pipe cmds." we're hashing out some ideas for functions for "the standard generator library" and syntax for operators to combine iterators. This thread started after thinking about my comments on Eric's request-for-comments on a file processing framework. I'm not actually in favor of following unix pipeline syntax so closely as to use the __or__ operator -- I think it's confusing … [View More]

2 2

Re: [Python-Dev] test_quopri is iso-latin-1 centric
by Jack Jansen Aug. 3, 2001

Aug. 3, 2001

> This is the problem. Python source code is not in Latin-1; bytes > inside strings and comments are "as-is". So the CVS "binary" mode > would come closer as to how python files should be treated, although > you'd still would want to convert line-endings. Is this an "official" policy? As such I disagree with it. Either all Python source should be 7-bit clean or the source should be converted to the local convention, even for strings and comments. But if it is an official policy I'… [View More]

3 2

test_quopri is iso-latin-1 centric
by Jack Jansen Aug. 3, 2001

Aug. 3, 2001

I think test_quopri is too latin-1 centric. Alternatively, I'm mistaken, please enlighten me (is quopri supposed to convert to/from latin1, in stead of to/from local convention, as I expect?). What happens is the following. The test_quopri.py source contains lots of special characters, for instance the spanish-upsidedown-exclamation (to mention the first one). It converts this with quopri and expects to see =A1. This all works fine if your Python source is interpreted in latin-1, but it … [View More]

2 1

www.python.org is back!
by Guido van Rossum Aug. 3, 2001

Aug. 3, 2001

The Python sites http://www.python.org and ftp://ftp.python.org are back up, thanks to the energetic help of Thomas Wouters and XS4ALL (the dutch ISP that's his employer). We're still fetching some missing files from a mirror, so please be patient if your favorite download isn't there yet. We're also still working on restoring the FAQ wizard and the 2.0 MoinMoin and restarting the Ultraseek engine (search.python.org) -- I hope this will be completed later today. Thanks again to XS4ALL (http:/… [View More]

5 4

(Idea) subclassable string: path object?
by Just van Rossum Aug. 3, 2001

Aug. 3, 2001

Every once in a while I wished for an path object to manipulate file system paths. Things like os.path.join(a, b, c, os.path.splitext(os.path.basename(p))[0] + ".ext") quickly get frustrating (so of course I never write them like that ;-). I thought of implementing a path object several times, but always stopped when I realized (for the Nth time ;-) that you'd then have to do something like file = open(p.tostring()) whenever you want to *use* your pat. That doesn't help at all. But: … [View More]

2 2

Re: [Python-Dev] Parrot -- should life imitate satire?
by Charles G Waldman Aug. 3, 2001

Aug. 3, 2001

On Fri, 3 Aug 2001 at 16:17:04 +0200, Thomas Wouters wrote: > Some people have seen bigger speedups just > reorganizing the case's in the Big Switch, but those same changes slowed > things down on other platforms. Clearly, part of Python's ./configure should try all different permutations of the 107 "case" statements in the Big Switch, and find the arrangement that maximizes Pystones on a per-platform basis. just-kidding-ly y'rs, -C

1 0

Re: [Python-Dev] Parrot -- should life imitate satire?
by Samuele Pedroni Aug. 3, 2001

Aug. 3, 2001

[Dan Sugalski] > >A question: when you say variable you mean variable (perl sense of that) > >or object. It has already been pointed out but it's really confusing > >from the point of view of python terminology. Will perl6 have only > >variables which contain objects, truly references to objects like Python > >or ...? > > Well, it sort of looks like: > > name--->variable--->value > Ok, I got your explanation. I see that perl6 will still … [View More]have a rather convoluted model and quiet different from Python... > I think the variable here would correspond to a Python object Possible but not in a natural way. > I think it's the potential existence of references (or pointers, or > whatever you want to call them) that necessitate the three-level split. Makes perfectly sense. > sounds like the things I'm calling 'name' and 'variable' are much more > tightly bound in Python. No, a name/variable is just slot in a namespace/ symbol table, that contains a pointer to a value/object which contains data and also points to the type-specific vtable. Quiet different. Do your values come with a vtable that then is "copied" in the variable? Your vtable are for things like scalar, vs array vs. hash. Do they possibly change when the value change (e.g. string to integer for a scalar var)? > the way Python would do things, in which case Python variable vtables might > just have an "overwrite myself with the incoming info" function, rather > than allow it to be overridden) No, unless you have a generic Python PMC which mirrors/ or uses a vtable that goes together with the value (in the sense of your scheme). Otherwise I think python assigment would be more some flavor of reference (perl sense) assignment. If you map Python built-in data object to PMC then assignment is a just a matter of namespace manipulation. For the momement I don't really see a natural way of mapping python semantics over your three-level scheme, maybe is just the lack of details. Especially I see a lot of problem if you want a mapping that can also allow interoperability beetween Python and Perl code. > Yup. I am profoundly tempted, and I think it will go in, to have a "stable > code" switch that can be given to the optimizer which guarantees that, once > the compilation phase is done and we finally get to run for real, code will > not change. And then apply all the advanced optimization techniques at that > point. > I don't really get this. In python the kind of dynamic changes you can do are reloading code, changing the base classes of a class, adding/substituting methods in a class or instance. When an application really need one of this techniques with your philosophy it will be treated as 2nd-class citizen. What I was referring were de-optimization techniques (yes they are a mess to deal with for the compiler writer). Reading about native compilation of dynamic languages I have been conviced that in general performance is a matter of implemention and it better to keep it transparent to the user, having constructs that should be avoided not for design reasons but because the compiler uses some tricks and not others is a bad thing, for a dynamic language IMHO. And in any case you still have the problem with polymorphic calls and to deal with them - in case you want to speed them up - you still have to make asssumptions at runtime and possibly take them back. > > >For the rest is just speed vs. memory, customization is a clear example > >for that. > > Sure. The one nice thing that both perl and python have going for them is > the ultimate presence of all the source (or a high-enough level > representation of it to feed to the optimizer) at run time. We can tell > with more surety what side-effects various methods and functions in > external code libraries will have, and we can get more aggressive (maybe) > because of it. That is probably not directly true for polimorphic call sites. But of course you can type-profile the program at runtime. > Unlike, say, C, where passing a pointer to a routine outside > what the compiler can see will hobble the optimizer a whole lot in many > cases... > regards, Samuele Pedroni. [View Less]

1 0