[Python-Dev] Adding support to curses library
Hello,
I am working on a patch to add to the _cursesmodule.c file of the Python
core libraries. I figured I would take on one of the implemented functions
to try to get my feet wet contributing to the project. At any rate, I have
the following function defined in the 2.7.a version updated from SVN this
morning:
- Snippet ---
// Insert new method color_set Steve Owens 2/24/2009
// The curses library color_set function has the following signature:
// int color_set(short color_pair_number, void* opts);
static PyObject *
PyCurses_color_set(PyObject *self, PyObject *args)
{
short color_pair_number;
void * opts;
int erg;
// These macros ought to be documented in the API docs
// but they aren't yet.
PyCursesInitialised
PyCursesInitialisedColor
// Per ncurses Man Page:
// The routine color_set sets the current color of the given window to
// the foreground/background combination described by the
color_pair_number.
// The parameter opts is reserved for future use, applications must
supply a
// null pointer.
switch(PyTuple_Size(args))
{
case 1:
// Dont make them pass a useless null pointer.
if (!PyArg_ParseTuple(args, "h", &color_pair_number)) return NULL;
break;
case 2:
// Allow them to pass the opts pointer so that when ncurses is later
updated.
// This method will still work.
if (!PyArg_ParseTuple(args, "hO&", &color_pair_number, &opts)) return
NULL;
break;
default:
PyErr_SetString(PyExc_TypeError, "color_set requires 1 or 2 arguments
(color_pair_number[, opts]?)");
return NULL;
}
erg = color_set(color_pair_number, opts); // Debating on forcing null
here.
if (erg == ERR)
return PyCursesCheckERR(erg, "color_set");
else
PyInt_FromLong((long) 1L);
}
-End Snippet ---
I also have the following added in (see last line of the snippet):
- Snippet ---
static PyMethodDef PyCurses_methods[] = {
{"baudrate",(PyCFunction)PyCurses_baudrate, METH_NOARGS},
{"beep",(PyCFunction)PyCurses_beep, METH_NOARGS},
{"can_change_color",(PyCFunction)PyCurses_can_change_color,
METH_NOARGS},
{"cbreak", (PyCFunction)PyCurses_cbreak, METH_VARARGS},
{"color_content", (PyCFunction)PyCurses_Color_Content,
METH_VARARGS},
{"color_pair", (PyCFunction)PyCurses_color_pair, METH_VARARGS},
{"color_set", (PyCFunction)PyCurses_color_set, METH_VARARGS},
-End Snippet ---
The code compiles and installs fine, but when I run the following unit test,
I get a segmentation fault:
- Snippet ---
import unittest, curses
from test import test_support
def testCursesColorSet(stdscrn):
curses.init_pair(1, curses.COLOR_RED, curses.COLOR_WHITE)
curses.init_pair(2, curses.COLOR_WHITE, curses.COLOR_BLUE);
i = curses.color_set(1, NULL);
stdscrn.addstr("RED/BLACK (%0)\n".format(i))
i = curses.color_set(2, NULL);
stdscrn.print("WHITE/BLUE (%0)\n".format(i))
i = curses.color_set(0, NULL);
stdscrn.print("Default (%0)\n".format(i))
def test_main(stdscrn):
curses.savetty()
if curses.has_color():
testCursesColorSet(stdscrn)
else
stdscr.addstr( "Test Aborted: Color not supported on this terminal.")
if __name__ == '__main__':
curses.wrapper(test_main)
-End Snippet ---
It turns out that by commenting out this line in the _cursesmodule.c code,
allows the unit test to run
obviously reporting the error as expected:
- Snippet ---
//erg = color_set(color_pair_number, opts); // Debating on forcing null
here.
-End Snippet ---
At any rate I am stuck. I am still trying to build just a plain C file
which will test the color_set function
outside of python, but that is another task.
Any suggestions?
--
View this message in context:
http://www.nabble.com/Adding-support-to-curses-library-tp22191916p22191916.html
Sent from the Python - python-dev mailing list archive at Nabble.com.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding support to curses library
Ulrich,
Thanks for the input. That is helpful to know.
H
Ulrich Berning-2 wrote:
>
> Heracles wrote:
>
>>Hello,
>>
>>I am working on a patch to add to the _cursesmodule.c file of the Python
>>core libraries. I figured I would take on one of the implemented
functions
>>to try to get my feet wet contributing to the project. At any rate, I
have
>>the following function defined in the 2.7.a version updated from SVN this
>>morning:
>>
>>- Snippet ---
>>// Insert new method color_set Steve Owens 2/24/2009
>>// The curses library color_set function has the following signature:
>>// int color_set(short color_pair_number, void* opts);
>>static PyObject *
>>PyCurses_color_set(PyObject *self, PyObject *args)
>>{
>> short color_pair_number;
>> void * opts;
>> int erg;
>>
>> // These macros ought to be documented in the API docs
>> // but they aren't yet.
>> PyCursesInitialised
>> PyCursesInitialisedColor
>>
>> // Per ncurses Man Page:
>> // The routine color_set sets the current color of the given window
>> to
>> // the foreground/background combination described by the
>>color_pair_number.
>> // The parameter opts is reserved for future use, applications must
>>supply a
>> // null pointer.
>> switch(PyTuple_Size(args))
>> {
>> case 1:
>> // Dont make them pass a useless null pointer.
>> if (!PyArg_ParseTuple(args, "h", &color_pair_number)) return NULL;
>> break;
>> case 2:
>> // Allow them to pass the opts pointer so that when ncurses is later
>>updated.
>> // This method will still work.
>> if (!PyArg_ParseTuple(args, "hO&", &color_pair_number, &opts)) return
>>NULL;
>> break;
>> default:
>> PyErr_SetString(PyExc_TypeError, "color_set requires 1 or 2
>> arguments
>>(color_pair_number[, opts]?)");
>>return NULL;
>> }
>>
>> erg = color_set(color_pair_number, opts); // Debating on forcing null
>>here.
>>
>> if (erg == ERR)
>>return PyCursesCheckERR(erg, "color_set");
>> else
>> PyInt_FromLong((long) 1L);
>>}
>>-End Snippet ---
>>
>>I also have the following added in (see last line of the snippet):
>>
>>- Snippet ---
>>static PyMethodDef PyCurses_methods[] = {
>> {"baudrate",(PyCFunction)PyCurses_baudrate, METH_NOARGS},
>> {"beep",(PyCFunction)PyCurses_beep, METH_NOARGS},
>> {"can_change_color",(PyCFunction)PyCurses_can_change_color,
>>METH_NOARGS},
>> {"cbreak", (PyCFunction)PyCurses_cbreak, METH_VARARGS},
>> {"color_content", (PyCFunction)PyCurses_Color_Content,
>>METH_VARARGS},
>> {"color_pair", (PyCFunction)PyCurses_color_pair, METH_VARARGS},
>> {"color_set", (PyCFunction)PyCurses_color_set, METH_VARARGS},
>>-End Snippet ---
>>
>>The code compiles and installs fine, but when I run the following unit
test,
>>I get a segmentation fault:
>>
>>- Snippet ---
>>import unittest, curses
>>from test import test_support
>>
>>def testCursesColorSet(stdscrn):
>> curses.init_pair(1, curses.COLOR_RED, curses.COLOR_WHITE)
>> curses.init_pair(2, curses.COLOR_WHITE, curses.COLOR_BLUE);
>> i = curses.color_set(1, NULL);
>> stdscrn.addstr("RED/BLACK (%0)\n".format(i))
>> i = curses.color_set(2, NULL);
>> stdscrn.print("WHITE/BLUE (%0)\n".format(i))
>> i = curses.color_set(0, NULL);
>> stdscrn.print("Default (%0)\n".format(i))
>>
>>
>>def test_main(stdscrn):
>> curses.savetty()
>> if curses.has_color():
>> testCursesColorSet(stdscrn)
>> else
>> stdscr.addstr( "Test Aborted: Color not supported on this
>> terminal.")
>>
>>
>>if __name__ == '__main__':
>>curses.wrapper(test_main)
>>-End Snippet ---
>>
>>It turns out that by commenting out this line in the _cursesmodule.c code,
>>allows the unit test to run
>>obviously reporting the error as expected:
>>
>>- Snippet ---
&g
Re: [Python-Dev] Adding support to curses library
Thank you for your reply,
and no, that is not the exact code. I must have wiped out the return
statement when I copied it in. The return statement is in the code. Also
the code has been modified so that the call to color_set reads as follows:
erg = color_set(color_pair_number, NULL); // Debating on forcing null
Never the less, as I said in my earlier post, the above line is the exact
line where the error occurs. This is provable simply because when the code
is compiled with that line commented out, it doesn't fail, and when the line
is commented back in it does fail. I am not sure exactly how a debugger will
help in this case since the color_set call goes directly to the ncurses
library. If in fact that the issue is the ncurses library then it seems
that there is no feasible solution until that library is fixed, in which
case this patch is sort of useless.
Bugzilla from nnorw...@gmail.com wrote:
>
> On Tue, Feb 24, 2009 at 2:18 PM, Heracles
> wrote:
>>
>> Hello,
>>
>> I am working on a patch to add to the _cursesmodule.c file of the Python
>> core libraries. I figured I would take on one of the implemented
>> functions
>> to try to get my feet wet contributing to the project. At any rate, I
>> have
>> the following function defined in the 2.7.a version updated from SVN this
>> morning:
>
> I'm glad you are interested in developing Python. I'm not sure if
> this is the best forum. OTOH, I'm not sure if comp.lang.python would
> be appropriate either.
>
> I'd suggest making a proper patch and submitting it to
> http://bugs.python.org
>
>> - Snippet ---
>> // Insert new method color_set Steve Owens 2/24/2009
>> // The curses library color_set function has the following signature:
>> // int color_set(short color_pair_number, void* opts);
>> static PyObject *
>> PyCurses_color_set(PyObject *self, PyObject *args)
>> {
>> short color_pair_number;
>> void * opts;
>> int erg;
>>
>> // These macros ought to be documented in the API docs
>> // but they aren't yet.
>> PyCursesInitialised
>> PyCursesInitialisedColor
>>
>> // Per ncurses Man Page:
>> // The routine color_set sets the current color of the given window
>> to
>> // the foreground/background combination described by the
>> color_pair_number.
>> // The parameter opts is reserved for future use, applications must
>> supply a
>> // null pointer.
>> switch(PyTuple_Size(args))
>> {
>> case 1:
>> // Dont make them pass a useless null pointer.
>> if (!PyArg_ParseTuple(args, "h", &color_pair_number)) return
>> NULL;
>> break;
>> case 2:
>> // Allow them to pass the opts pointer so that when ncurses is
>> later
>> updated.
>> // This method will still work.
>> if (!PyArg_ParseTuple(args, "hO&", &color_pair_number, &opts))
>> return
>> NULL;
>> break;
>> default:
>> PyErr_SetString(PyExc_TypeError, "color_set requires 1 or 2
>> arguments
>> (color_pair_number[, opts]?)");
>> return NULL;
>> }
>>
>> erg = color_set(color_pair_number, opts); // Debating on forcing null
>> here.
>>
>> if (erg == ERR)
>> return PyCursesCheckERR(erg, "color_set");
>> else
>> PyInt_FromLong((long) 1L);
>
> I did a cursory review of the patch and if this is the exact code,
> this is a problem. You are missing a return statement. The compiler
> should have issued a warning for this too.
>
>> }
>> -End Snippet ---
>>
>> I also have the following added in (see last line of the snippet):
>>
>> - Snippet ---
>> static PyMethodDef PyCurses_methods[] = {
>> {"baudrate", (PyCFunction)PyCurses_baudrate, METH_NOARGS},
>> {"beep", (PyCFunction)PyCurses_beep, METH_NOARGS},
>> {"can_change_color", (PyCFunction)PyCurses_can_change_color,
>> METH_NOARGS},
>> {"cbreak", (PyCFunction)PyCurses_cbreak, METH_VARARGS},
>> {"color_content", (PyCFunction)PyCurses_Color_Content,
>> METH_VARARGS},
>> {"color_pair", (PyCFunction)PyCurses_color_pair, METH_VARARGS},
>> {"color_set", (PyCFunction)PyCurses_color_set, METH_VARARGS},
>> -End Snippet ---
Re: [Python-Dev] Adding support to curses library
I took the suggestion and fired up a debugger and now I'm eating crow.
First of all, here is a complete listing of the method as it is written now:
-- Snippet ---
static PyObject *
PyCurses_color_set(PyObject *self, PyObject *args)
{
short color_pair_number = 0;
void * opts = NULL;
int erg = ERR;
/* These macros ought to be documented in the API docs
but they aren't yet. */
PyCursesInitialised
PyCursesInitialisedColor
/* Per ncurses Man Page:
The routine color_set sets the current color of the given window to
the foreground/background combination described by the
color_pair_number.
The parameter opts is reserved for future use, applications must
supply a
null pointer. */
switch(PyTuple_Size(args))
{
case 1:
/* Dont make them pass a useless null pointer. */
if (!PyArg_ParseTuple(args, "h", &color_pair_number)) return NULL;
case 2:
/* Allow them to pass the opts pointer so that when ncurses is later
updated.
This method will still work. */
if (!PyArg_ParseTuple(args, "hO&", &color_pair_number, &opts)) return
NULL;
default:
PyErr_SetString(PyExc_TypeError, "color_set requires 1 or 2 arguments
(color_pair_number[, opts]?)");
return NULL;
}
erg = color_set(color_pair_number, NULL);
if (erg == ERR)
return PyCursesCheckERR(erg, "color_set");
else
return NULL; /* PyInt_FromLong((long) 1L); */
}
-- End Snippet -
Oddly enough, running the debugger showed me a different result than I
expected by my bracketing approach. I falsely presumed that if by
commenting out the line where the call to color_set is made, and running the
program produces no segmentation fault, while commenting the same line back
in reprduces the segmentation fault, that I could deduce that the line thus
commented out was the source of the problem. Stupid me, that is apparently
not the case.
Apparently the segmentation fault is produced by a call to
Python/getargs.c:Line 1207
if(! (*convert)(arg,addr))
Which is invoked as a result of calling this line in the function listed
above:
if (!PyArg_ParseTuple(args, "hO&", &color_pair_number, &opts)) return
NULL;
A.M. Kuchling wrote:
>
> On Wed, Feb 25, 2009 at 06:30:06AM -0800, Heracles wrote:
>> is commented back in it does fail. I am not sure exactly how a debugger
>> will
>> help in this case since the color_set call goes directly to the ncurses
>> library. If in fact that the issue is the ncurses library then it seems
>> that there is no feasible solution until that library is fixed, in which
>> case this patch is sort of useless.
> ...
>> erg = color_set(color_pair_number, NULL); // Debating on forcing null
>
> What is color_pair_number in the C code? If it's some incorrect value
> (-1? 255?), maybe ncurses is indexing off an array and crashing.
>
> This is why a debugger might help; you could run the test program
> until the crash and then print out the values of the relevant
> variables. e.g. is stdscr set to a non-NULL value? There might be a
> debugging version of ncurses that will let you look at the variables
> inside the ncurses code, which may make the problem clear.
>
> --amk
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
>
>
:wistle::wistle::wistle:
--
View this message in context:
http://www.nabble.com/Adding-support-to-curses-library-tp22191916p22205860.html
Sent from the Python - python-dev mailing list archive at Nabble.com.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New curses module method addchstr, etc.
Hello,
I submitted my first patch recently for the curses color_set and wcolor_set
functions. I am now working on addchstr, addchnstr, mvaddchstr,
mvaddchnstr, mvwaddchstr, mvwaddchnstr, waddchstr and waddchnstr.
I have implemented the non window specific methods as follows:
/* Window.addchstr Inserted Steve Owens 2/25/2005 */
static PyObject *
PyCursesWindow_AddChstr(PyCursesWindowObject *self, PyObject *args)
{
int x, y, n;
PyStringObject *pS;
switch (PyTuple_Size(args)) {
case 1:
if (!PyArg_ParseTuple(args, "S;(String) expected for waddchstr", &pS))
return NULL;
return PyCursesCheckERR(waddchstr(self->win,
(chtype*)PyString_AsString(pS)), "waddchstr");
case 2:
if (!PyArg_ParseTuple(args, "Si;(String, int) expected for waddchnstr",
&pS, &n))
return NULL;
return PyCursesCheckERR(waddchnstr(self->win,
(chtype*)PyString_AsString(pS), n), "waddchnstr");
case 3:
if (!PyArg_ParseTuple(args,"iiS;(int, int, String) expected for
mvwaddchstr", &y, &x, &pS))
return NULL;
return PyCursesCheckERR(mvwaddchstr(self->win, y, x,
(chtype*)PyString_AsString(pS)), "mvwaddchstr");
case 4:
if (!PyArg_ParseTuple(args,"iiSi;(int, int, String, int) expected for
mvwaddchnstr", &y, &x, &pS, &n))
return NULL;
return PyCursesCheckERR(mvwaddchnstr(self->win, y, x,
(chtype*)PyString_AsString(pS), n), "mvwaddchnstr");
default:
PyErr_SetString(PyExc_TypeError, "addchstr requires 1 to 4 arguments");
}
return NULL;
}
Now the thing is that when I make calls from python like so:
curses.addchstr(5,10, "@ < Row 5, Col 10")
curses.addchstr(8,10, "Below you should see ABCDEFG")
curses.addchstr(9,10, "ABCDEFG")
curses.addchstr(12,10, "Below you should see ABCD")
curses.addchnstr(13,10, "ABCDEFGHI", 4)
What prints out on the screen is gobledygook not the strings you would
expect below.
Any thoughts on how to correctly convert the PyStringObject arguments to
chtype* pointers so that the ncurses library will be able to understand
them?
--
View this message in context:
http://www.nabble.com/New-curses-module-method-addchstr%2C-etc.-tp22211983p22211983.html
Sent from the Python - python-dev mailing list archive at Nabble.com.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] String conversion issues implementing new curses module method addchstr, etc.
Thank you, this is most helpful, and i will heed your advice about the cast. Cheers! Ulrich Eckhardt wrote: > > On Wednesday 25 February 2009, Heracles wrote: >> addchstr((chtype*)PyString_AsString(pS)) > > You are effectively disabling the well-deserved warnings with the cast > here. > Don't do that. > >> Now the thing is that when I make calls from python like so: >> >>curses.addchstr(5,10, "@ < Row 5, Col 10") > [...] >> What prints out on the screen is gobledygook not the strings you would >> expect below. > [...] >> Any thoughts on how to correctly convert the PyStringObject arguments to >> chtype* pointers so that the ncurses library will be able to understand >> them? > > In this case, I suggest man ncurses: > > | cchar_t > |corresponds to chtype. However it is a structure, because more > |data is stored than can fit into an integer. The characters are > |large enough to require a full integer value - and there may > |be more than one character per cell. The video attributes and > |color are stored in separate fields of the structure. > > I'm pretty sure that you can find functions to generate such a string both > from a char-string (with whatever encoding) or a wchar_t-string (using > Unicode probably) in the curses library. > > Uli > > -- > Sator Laser GmbH > Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 > > ** > Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland > Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 > ** >Visit our website at <http://www.satorlaser.de/> > ** > Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten > bestimmt und kann vertrauliche Informationen enthalten. Bitte > benachrichtigen Sie den Absender umgehend, falls Sie nicht der > beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu > löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder > anderweitig benutzt werden. > E-Mails können durch Dritte gelesen werden und Viren sowie > nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese > Folgen nicht verantwortlich. > ** > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/lists%40nabble.com > > -- View this message in context: http://www.nabble.com/String-conversion-issues-implementing-new-curses-module-method-addchstr%2C-etc.-tp22211983p5142.html Sent from the Python - python-dev mailing list archive at Nabble.com. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Patch Ready for review
I have a patch submitted, with docs changes etc. The patch is to the curses library module, and adds support for color_set, addchstr, addchnstr, mvaddchstr, mvaddchnstr, mvwaddchstr, mvwaddchnstr, waddchstr, and waddchnstr. I am wondering what to expect next. How long will it be before it is applied etc. This is my first attempt to submit a patch to Python. Also, does anyone know who the main person is for running changes to the curses library I wanted to get guidance for implementing support for family of functions newterm, set_term, reset_term. The main question I have is to support these functions consistently, would it be recommended to implement a new Python Screen object? -- View this message in context: http://www.nabble.com/Patch-Ready-for-review-tp22254109p22254109.html Sent from the Python - python-dev mailing list archive at Nabble.com. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding support to curses library
Ok, I think I have followed the process and submitted the patch via bug tracker. I also note that you have made some minor changes to the issue. The patch is ready for review and feedback. Thanks for your help. A.M. Kuchling wrote: > > On Wed, Feb 25, 2009 at 01:52:29PM -0800, st...@integrityintegrators.net > wrote: >> Are you up for helping a little more? > > Sure, but please open an issue on http://bugs.python.org for this; > back-and-forth over a particular patch is done in the bug tracker, not > the python-dev mailing list. http://www.python.org/dev/ discusses how > development is done. > > We also don't send around modified > copies of entire files; http://www.python.org/dev/faq/#patches > discusses how to make patches. > > --amk > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/lists%40nabble.com > > -- View this message in context: http://www.nabble.com/Adding-support-to-curses-library-tp22191916p22254150.html Sent from the Python - python-dev mailing list archive at Nabble.com. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch Ready for review
Well, what got me interested in Python was the fact that it had support for reading mail files and for the curses library. When I found out there was a need for folks to work on this module I thought I would start contributing, I would love to become a primary maintainer of this particular module, because I think writing console apps is cool (yes I know my inner nerd is showing). Maybe someday I will also create a computational geometry module that can be plugged in to Python as well, but for the time being I think I could handle working on this module. "Martin v. Löwis" wrote: > >> I am wondering what to expect next. How long will it be before it is >> applied etc. This is my first attempt to submit a patch to Python. > > Unfortunately, it may take any time between a day and five years, see > below. > >> Also, does anyone know who the main person is for running changes to the >> curses library I wanted to get guidance for implementing support for >> family >> of functions newterm, set_term, reset_term. > > The curses module is largely unmaintained; nobody is really responsible > for it (my feeling is that it also has fairly few users). Use "svn log" > to find out what people have been making changes over time; if the > commit messages indicate that they had applied patches from the bug > tracker, also try to recognize any regular non-commit contributors. > > Regards, > Martin > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/lists%40nabble.com > > -- View this message in context: http://www.nabble.com/Patch-Ready-for-review-tp22254109p22269124.html Sent from the Python - python-dev mailing list archive at Nabble.com. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
