Mailman 3 January 2009 - Python-Dev

a few strdup() questions...
by Ulrich Eckhardt Jan. 8, 2009

Jan. 8, 2009

Greetings! MS Windows CE doesn't provide strdup(), so where should I put it? I guess I should just compile in Python/strdup.c, right? However, where should I declare it? My approach would be to declare it in PC/pyconfig.h. I see that RISCOS also seems to lack that function, which is why it is declared locally in _localemodule.c, but I guess this isn't really the best of all possible ways. Also, there is HAVE_STRDUP. I would actually expect that #undef HAVE_STRDUP would do the trick to … [View More]

4 4

[Py3k] curses module and libncursesw library
by Victor Stinner Jan. 8, 2009

Jan. 8, 2009

Hi, Python2 and Python3 tries to link the Python _curses module to the libncusesw dynamic library, or fallback to libncurses (or another implementation). The problem of libncurses is that it doesn't support multibyte charsets like... utf-8. In the Python module, it's not possible to check if we are using libncursesw or libncurses. Would it possible to change the Python3 configure script to always use libncursesw instead of falling back to an alternate non-unicode library? Which means no … [View More]

2 1

Can someone explain the fast_block_end manipulation?
by skip＠pobox.com Jan. 8, 2009

Jan. 8, 2009

> I don't see anyplace obvious where a value resembling a jump offset or > jump target was pushed onto the stack. Duh. Found it about one minute after sending... CONTINUE_LOOP. Skip

1 0

Can someone explain the fast_block_end manipulation?
by skip＠pobox.com Jan. 8, 2009

Jan. 8, 2009

Everybody seems to be doing stuff with the virtual machine all of a sudden. I thought I would get in on the fun. I am generating functions from the byte code which pretty much just inlines the C code implementing each opcode. The idea is to generate a C function that looks like a small version of PyEval_EvalFrameEx but without the for loop and switch statement. Instead it just contains the C code implementing the opcodes used in that function. For example, this function >>> def … [View More]f(a): ... for i in range(a): ... x = i*i disassembles to this: 2 0 SETUP_LOOP 30 (to 33) 3 LOAD_GLOBAL 0 (range) 6 LOAD_FAST 0 (a) 9 CALL_FUNCTION 1 12 GET_ITER >> 13 FOR_ITER 16 (to 32) 16 STORE_FAST 1 (i) 3 19 LOAD_FAST 1 (i) 22 LOAD_FAST 1 (i) 25 BINARY_MULTIPLY 26 STORE_FAST 2 (x) 29 JUMP_ABSOLUTE 13 >> 32 POP_BLOCK >> 33 LOAD_CONST 0 (None) 36 RETURN_VALUE and compiles to this #include "opcode_mini.h" PyObject * _PyEval_EvalMiniFrameEx(PyFrameObject *f, int throwflag) { static int minime = 1; static int jitting = 1; /* most of the stuff at the start of PyEval_EvalFrameEx */ PyEval_EvalFrameEx_PROLOG(); /* code length=37 */ /* nlabels=3, offsets: 13, 32, 33, */ oparg = 30 SETUP_LOOP_IMPL(oparg); /* 0 */ oparg = 0 LOAD_GLOBAL_IMPL(oparg, 0); /* 3 */ oparg = 0 LOAD_FAST_IMPL(oparg); /* 6 */ oparg = 1 CALL_FUNCTION_IMPL(oparg); /* 9 */ GET_ITER_IMPL(); /* 12 */ __L13: FOR_ITER_IMPL(__L32); oparg = 1 STORE_FAST_IMPL(oparg); /* 16 */ oparg = 1 LOAD_FAST_IMPL(oparg); /* 19 */ oparg = 1 LOAD_FAST_IMPL(oparg); /* 22 */ BINARY_MULTIPLY_IMPL(); /* 25 */ oparg = 2 STORE_FAST_IMPL(oparg); /* 26 */ goto __L13; __L32: POP_BLOCK_IMPL(); /* 32 */ __L33: oparg = 0 LOAD_CONST_IMPL(oparg); /* 33 */ RETURN_VALUE_IMPL(); /* 36 */ /* most of the stuff at the end of PyEval_EvalFrameEx */ PyEval_EvalFrameEx_EPILOG(); } Besides eliminating opcode decoding I figure it might give the compiler lots of optimization opportunities. Time will tell though. I have just about everything implemented but I'm a bit stuck trying to figure out how to deal with the block manipulation code in PyEval_EvalFrameEx after the fast_block_end label. JUMP* opcodes in the interpreter turn into gotos in the generated code. It seems I will have to replace any JUMP instructions in the epilog with computed gotos. In particular, I am a little confused by this construct: if (b->b_type == SETUP_LOOP && why == WHY_CONTINUE) { /* For a continue inside a try block, don't pop the block for the loop. */ PyFrame_BlockSetup(f, b->b_type, b->b_handler, b->b_level); \ why = WHY_NOT; JUMPTO(PyLong_AS_LONG(retval)); Py_DECREF(retval); break; } The top of stack has been popped into retval. I think that value was maybe pushed here: if (b->b_type == SETUP_FINALLY) { if (why & (WHY_RETURN | WHY_CONTINUE)) PUSH(retval); PUSH(PyLong_FromLong((long)why)); why = WHY_NOT; JUMPTO(b->b_handler); break; } but I'm confused. I don't see anyplace obvious where a value resembling a jump offset or jump target was pushed onto the stack. What's with that first JUMPTO in the SETUP_LOOP/WHY_CONTINUE code? Is the stack/block cleanup code documented anywhere? Wiki? Pointers to python-dev threads? I found this brief thread from last July: http://mail.python.org/pipermail/python-dev/2008-July/thread.html#81480 A svn annotate suggests that much of the fun in this code began with a checkin by Jeremy Hylton (r19260). It references an old SF patch (102989) but I can't locate that in the current issue tracker to read the discussion. Is there some way I can retrieve that? The obvious http://bugs.python.org/issue102989 didn't work for me. Thx, Skip [View Less]

1 0

Mathematica
by Raymond Hettinger Jan. 8, 2009

Jan. 8, 2009

Does anyone here have access to Mathematica? I would like to know what it returns for: In[1]:= Permutations({a, b, c}, {5}) Knowing this will help resolve a feature request for itertools.permutations() and friends. Thanks, Raymond

2 1

Re: [Python-Dev] another Python Bug Day?
by bcannon＠gmail.com Jan. 7, 2009

Jan. 7, 2009

On Jan 6, 2009 3:18pm, Simon Cross <hodgestar+pythondev(a)gmail.com> wrote: > On Tue, Jan 6, 2009 at 9:47 PM, Brett Cannon brett(a)python.org> wrote: > > > This is a years-old problem that is not going to be fixed overnight > > > (unfortunately). But it is known and is being worked on (moving to a > > > DVCS, writing up docs on the development process to cut down on bad > > > patches, etc.). > > > > It's encouraging to hear that it's … [View More]been worked on. I assume the idea > > is that eventually leiutenanents will maintain their own Python trees > > in a similar way to what happens with the Linux kernel currently? > No because Python is not developed with much sense of ownership like the Linux kernel; no one owns the dict object or all of the object code. And this is not about to change either. While some modules have obvious owners (eg I would defer to Raymond for itertools stuff if I wasn't sure of the best solution), the code base overall is considered "owned" by all of python-dev equally. > > > An interim solution that occurred to me is to give a few more people > > enhanced access to the issue tracker We have slowly started to do this although we could probably expand this more than we have. > and to create a > > ready-for-committing keyword that these new issue wranglers could > > apply to bugs that have patches and which they think are ready for > > committing. Already done; the Stage field takes care of this with the "commit review" stage. It also makes it more clear what is needed which could be helpful for Bug Days. If people feel comfortable writing tests, for instance, they could (theoretically) just look for issues at the Test Needed stage. But the field is so new that it is not consistently used yet. Probably going to need the docs on how the issue workflow is supposed to work before that happens. > Actual committers could then come along and search for the > > given keyword to find things to examine for committing. This would > > also act as testing ground for potential developers -- once committers > > feel that the patches an issue wrangler approves really are > > consistently good enough, they can consider promoting the issue > > wrangler to a full developer. Right, that is one of the hopes of having more people have the Developer role on the issue tracker. This process just needs to get written down (which I am slowly doing; see http://www.python.org/dev/setup/ as the start of the docs I plan to write to document all of this). -Brett [View Less]

1 0

another Python Bug Day?
by Malte Helmert Jan. 7, 2009

Jan. 7, 2009

Dear python-dev group, are their any plans to organize another Python Bug Day in the near future? It's been a while since the last one (last May). I might be misremembering, but I think at one time there was even talk of having one bug day every month. For people who are not core developers but would still like to contribute, the Bug Days are quite exciting events. It would be great if they could keep going. Malte

8 10

address manipulation in the standard lib
by Duncan McGreggor Jan. 7, 2009

Jan. 7, 2009

Last Fall, Guido opened a ticket to include Google's ipaddr.py in the standard lib: http://bugs.python.org/issue3959 There has been some recent discussion on that ticket, enough so that it might benefit everyone if it was moved on to the dev list. I do recommend reading that ticket, though -- lots of good perspectives are represented. The two libraries that are being discussed the most for possible inclusion are the following: * http://code.google.com/p/ipaddr-py/wiki/IPAddrExmples * … [View More]

5 6

Documentation of Slicings in 3.0
by Mitchell L Model Jan. 6, 2009

Jan. 6, 2009

The section of the documentation on slicings in 3.0 is substantially different than in previous versions, including 2.6. In particular it states that "The primary must evaluate to a maping object." I've followed the grammar and the commentary around through a few paths and cannot convince myself that the docmentation ever covers sequence slicing. I'm not sufficiently confident of this to post as a bug, so I decided to post here first. -- --- Mitchell L Model

1 0

#ifdef __cplusplus?
by Ulrich Eckhardt Jan. 6, 2009

Jan. 6, 2009

Hi! There are lots of files that are framed with an extern "C" stanza when compiled under C++. Now, I appreciate that header files are made suitable for use with C++ with that, but WTF are those doing in .c files??? puzzled greetings Uli

11 26