Re: [Python-Dev] Adding support to curses library
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 ---
//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?
As long as Python is written in C, please don't use C++ comments, some C
compilers don't like them.
Ulli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Allow __enter__() methods to skip the with statement body?
An interesting discrepancy [1] has been noted when comparing contextlib.nested (and contextlib.contextmanager) with the equivalent nested with statements. Specifically, the following examples behave differently if cmB().__enter__() raises an exception which cmA().__exit__() then handles (and suppresses): with cmA(): with cmB(): do_stuff() # This will resume here without executing "Do stuff" @contextlib.contextmanager def combined(): with cmA(): with cmB(): yield with combined(): do_stuff() # This will raise RuntimeError complaining that the underlying # generator didn't yield with contextlib.nested(cmA(), cmB()): do_stuff() # This will raise the same RuntimeError as the contextmanager # example (unsurprising, given the way nested() is implemented) The problem arises any time it is possible to skip over the yield statement in a contextlib.contextmanager based context manager without raising an exception that can be seen by the code calling __enter__(). I think the right way to fix this (as suggested by the original poster of the bug report) is to introduce a new flow control exception along the lines of GeneratorExit (e.g. SkipContext) and tweak the expansion of the with statement [2] to skip the body of the statement if __enter__() throws that specific exception: mgr = (EXPR) exit = mgr.__exit__ # Not calling it yet try: value = mgr.__enter__() except SkipContext: pass # This exception handler is the new part... else: exc = True try: VAR = value # Only if "as VAR" is present BLOCK except: # The exceptional case is handled here exc = False if not exit(*sys.exc_info()): raise # The exception is swallowed if exit() returns true finally: # The normal and non-local-goto cases are handled here if exc: exit(None, None, None) Naturally, contextlib.contextmanager would then be modified to raise SkipContext instead of RuntimeError if the generator doesn't yield. The latter two examples would then correctly resume execution at the first statement after the with block. I don't see any other way to comprehensively fix the problem - without it, there will always be some snippets of code which cannot correctly be converted into context managers, and those snippets won't always be obvious (e.g. the fact that combined() is potentially a broken context manager implementation would surprise most people - it certainly surprised me). Thoughts? Do people hate the idea? Are there any backwards compatibility problems that I'm missing? Should I write a PEP or just add the feature to the with statement in 2.7/3.1? Cheers, Nick. [1] http://bugs.python.org/issue5251 [2] http://www.python.org/dev/peps/pep-0343/ -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attention Bazaar mirror users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 20, 2009, at 10:09 AM, Barry Warsaw wrote: I've just upgraded the Bazaar mirrors on code.python.org to use bzr 1.12. We now have the opportunity to upgrade the repository format for better performance. Because of the bzr-svn requirement, we need a "rich root" format. Upgrading to 1.9-rich-root could buy us some significant performance improvements, but it will require all clients to upgrade to at least bzr 1.9, which was released on November 7, 2008. I would like to do this upgrade. If you are currently using the Bazaar mirrors at code.python.org and upgrading your client to at least bzr 1.9 would be a hardship, please contact me. If I don't hear any objections by say Tuesday, I'll go ahead and do the repo upgrades. This is now done. Please let me know if you have any problems with the mirrors. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSaVUenEjvBPtnXfVAQLdZgP/XTSdEm7vos5hFugguEJ+T6hIuchgM8j8 YDCdC4IMH4J1SsSjOLNUOnlWA5miMpRJSriSeUvNhKgzJZBoNGo+wWpTRzItYtxR 6+iQAqgAGvvJMc2bIlgbnI9z/izyUw6PyxpE7FLLEnMOMWEbvFxBHWg1ndww804b iz2sfrWZQpo= =k3jC -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] 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 ---
>>//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?
>>
>>
>>
>>
> As long as Python is written in C, please don't use C++ comments, some C
> compilers don't like them.
>
> Ulli
> ___
> Python-Dev mailing list
> [email protected]
> 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-tp22191916p22203820.html
Sent from the Python - python-dev mailing list archive
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 [email protected] 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 --- >> >> 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): >> cu
[Python-Dev] File Path retrieving problem
Hi all,
I am new to Python, i have installed python 2.5.4 and it is my requirement.
I need to retrieve the path of filename in python.
I have found some API's to get this:
from os.path import realpath
print realpath("NEWS.txt") # here NEWS.txt exists and it shows the path of
the file as C:\Python25\WorkSpace\NEWS.txt
print realpath("abc.txt") # here abc.txt does not exist but still it
shows C:\Python25\WorkSpace\abc.txt
can anybody tell the reason why
Now took some safety measures:
found = lexists(realpath(filename))
if found == 0:
print "Not Found"
else:
print realpath(filename)
i have given the filename as "NEWS.txt" and "abc.txt" but i am always
getting the output as "Not Found"
Can anyone please tell me where am i doing wrong
also any suggestions to retrieve the filepath from a given filename is
highly appreciated.
Thanks in advance.
Regards,
Sudhir
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] File Path retrieving problem
2009/2/25 Sudhir Kakumanu : > Hi all, > I am new to Python, i have installed python 2.5.4 and it is my requirement. > I need to retrieve the path of filename in python. This list is for the developers of Python to discuss future changes to the language and its implementation. It is not the correct list for questions about using Python for developing applications. You will probably get the assistance you require from the newsgroup comp.lang.python (also available via the mailing list [email protected]). Paul. ___ Python-Dev mailing list [email protected] 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
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Shared ABCs for the IO implementation
Hello, I would like to know if both IO implementations (the C one and the Python one) should share their ABCs (IOBase, RawIOBase, etc.). It looks preferable to me but since I'm not very familiar with ABCs I'd like to be sure it's the good choice. (of course, the *implementations* won't be shared at all. Just the virtual inheritance information) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Paving the Way to Securing the Python Interpreter [Detailed Summary]
Dear fellow Python lovers, I have written up a detailed summary on: http://tav.espians.com/paving-the-way-to-securing-the-python-interpreter.html Please read it. In the article I give the rationale for my patch, which I've updated at: * http://codereview.appspot.com/20051/show Please review it. Consider it as simply a bug fix for the current set of restricted attributes in Python. In the article I also provide some much needed documentation on Python's existing restricted execution framework. Martin asked for this. Fell free to adapt the documentation into Doc/ articles. You can find the reStructuredText source of the article at http://github.com/tav/blog/tree/master Many thanks to everyone who took part in the challenge -- it was very informative and fun! Please let me know what else I need to do to get the patch accepted. Thanks! -- love, tav plex:espians/tav | [email protected] | +44 (0) 7809 569 369 http://tav.espians.com | http://twitter.com/tav | skype:tavespian ___ Python-Dev mailing list [email protected] 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
Please note that there is a pending change that will introduce curses module on Windows in http://bugs.python.org/issue2889 I would really like to see the patch in the issue integrated before it became invalid due to other patches to test curses on Windows. On Wed, Feb 25, 2009 at 5:34 PM, 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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com > -- --anatoly t. ___ Python-Dev mailing list [email protected] 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
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
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shared ABCs for the IO implementation
On Wed, Feb 25, 2009 at 7:35 AM, Antoine Pitrou wrote: > I would like to know if both IO implementations (the C one and the Python one) > should share their ABCs (IOBase, RawIOBase, etc.). It looks preferable to me > but > since I'm not very familiar with ABCs I'd like to be sure it's the good > choice. > > (of course, the *implementations* won't be shared at all. Just the virtual > inheritance information) Without a shared ABC you'd defeat the whole point of having ABCs. However, importing ABCs (which are defined in Python) from C code (especially such fundamental C code as the I/O library) is really subtle and best avoided. In io.py I solved this by having a Python class inherit from both the ABC (RawIOBase) and the implementation (_fileio._FileIO). Another way to solve it would be to use the registration API for ABCs, as found in _abcoll.py (e.g. MutableSequence.register(list)). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attention Bazaar mirror users
Barry Warsaw wrote: I've just upgraded the Bazaar mirrors on code.python.org to use bzr 1.12. We now have the opportunity to upgrade the repository format for better performance. Because of the bzr-svn requirement, we need a "rich root" format. Upgrading to 1.9-rich-root could buy us some significant performance improvements, but it will require all clients to upgrade to at least bzr 1.9, which was released on November 7, 2008. I would like to do this upgrade. If you are currently using the Bazaar mirrors at code.python.org and upgrading your client to at least bzr 1.9 would be a hardship, please contact me. If I don't hear any objections by say Tuesday, I'll go ahead and do the repo upgrades. This is now done. Please let me know if you have any problems with the mirrors. I'd suggest updating the text at http://www.python.org/dev/bazaar/ In particular: What do I need? * Bazaar 1.0 or newer. As of this writing (04-Nov-2008) Bazaar 1.8 is the most recent release. As Bazaar is written in Python (yay!), it is available for all major platforms, See the Bazaar home page for information about versions for your platform. --Scott David Daniels [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Allow __enter__() methods to skip the with statement body?
On Wed, Feb 25, 2009 at 04:24, Nick Coghlan wrote: > An interesting discrepancy [1] has been noted when comparing > contextlib.nested (and contextlib.contextmanager) with the equivalent > nested with statements. > > Specifically, the following examples behave differently if > cmB().__enter__() raises an exception which cmA().__exit__() then > handles (and suppresses): > > with cmA(): >with cmB(): > do_stuff() > # This will resume here without executing "Do stuff" > > @contextlib.contextmanager > def combined(): >with cmA(): > with cmB(): >yield > > with combined(): >do_stuff() > # This will raise RuntimeError complaining that the underlying > # generator didn't yield > > with contextlib.nested(cmA(), cmB()): >do_stuff() > # This will raise the same RuntimeError as the contextmanager > # example (unsurprising, given the way nested() is implemented) > > The problem arises any time it is possible to skip over the yield > statement in a contextlib.contextmanager based context manager without > raising an exception that can be seen by the code calling __enter__(). > > I think the right way to fix this (as suggested by the original poster > of the bug report) is to introduce a new flow control exception along > the lines of GeneratorExit (e.g. SkipContext) and tweak the expansion of > the with statement [2] to skip the body of the statement if __enter__() > throws that specific exception: > > mgr = (EXPR) > exit = mgr.__exit__ # Not calling it yet > try: >value = mgr.__enter__() > except SkipContext: >pass # This exception handler is the new part... > else: >exc = True >try: > VAR = value # Only if "as VAR" is present > BLOCK >except: > # The exceptional case is handled here > exc = False > if not exit(*sys.exc_info()): >raise > # The exception is swallowed if exit() returns true >finally: > # The normal and non-local-goto cases are handled here > if exc: >exit(None, None, None) > > Naturally, contextlib.contextmanager would then be modified to raise > SkipContext instead of RuntimeError if the generator doesn't yield. The > latter two examples would then correctly resume execution at the first > statement after the with block. > > I don't see any other way to comprehensively fix the problem - without > it, there will always be some snippets of code which cannot correctly be > converted into context managers, and those snippets won't always be > obvious (e.g. the fact that combined() is potentially a broken context > manager implementation would surprise most people - it certainly > surprised me). > > Thoughts? Do people hate the idea? No, but I do wonder how useful this truly is. > Are there any backwards compatibility > problems that I'm missing? As long as the exception inherits from BaseException, no. > Should I write a PEP or just add the feature > to the with statement in 2.7/3.1? > Sounds PEPpy to me since you are proposing changing the semantics for a syntactic construct. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Allow __enter__() methods to skip the with statement body?
On Wed, Feb 25, 2009 at 4:24 AM, Nick Coghlan wrote: > An interesting discrepancy [1] has been noted when comparing > contextlib.nested (and contextlib.contextmanager) with the equivalent > nested with statements. > > Specifically, the following examples behave differently if > cmB().__enter__() raises an exception which cmA().__exit__() then > handles (and suppresses): > > with cmA(): > with cmB(): > do_stuff() > # This will resume here without executing "Do stuff" > > �[email protected] > def combined(): > with cmA(): > with cmB(): > yield > > with combined(): > do_stuff() > # This will raise RuntimeError complaining that the underlying > # generator didn't yield > > with contextlib.nested(cmA(), cmB()): > do_stuff() > # This will raise the same RuntimeError as the contextmanager > # example (unsurprising, given the way nested() is implemented) > > The problem arises any time it is possible to skip over the yield > statement in a contextlib.contextmanager based context manager without > raising an exception that can be seen by the code calling __enter__(). If the problem is just the yield, can't this just be fixed by implementing contextlib.nested() as a class rather than as a @contextmanager decorated generator? Or is this a problem with class based context managers too? Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attention Bazaar mirror users
On Wed, Feb 25, 2009 at 2:23 PM, Barry Warsaw wrote: > This is now done. Please let me know if you have any problems with the > mirrors. Is the cron job that's supposed to update the bzr repository still running? I'm getting 'No revisions to pull' when I do 'bzr pull' for the py3k branch: Macintosh-3:py3k dickinsm$ bzr pull Using saved parent location: http://code.python.org/python/py3k/ No revisions to pull. ...which is a bit surprising, since my last 'bzr pull' was a while ago. Do I need to update something somewhere? I'm using bzr version 1.11 from macports. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attention Bazaar mirror users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 25, 2009, at 2:03 PM, Mark Dickinson wrote: On Wed, Feb 25, 2009 at 2:23 PM, Barry Warsaw wrote: This is now done. Please let me know if you have any problems with the mirrors. Is the cron job that's supposed to update the bzr repository still running? No. It was running on Thomas's machine but we just realized that it was broken. I'm working on moving the cronjob over to code.python.org. Stay tuned. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSaWWeHEjvBPtnXfVAQLnPwP+OYls3161N9182B6ID9CmzsP5ynNxlcEv YhY70l0XVtEnIf1TEaXbSizPH7qHeVfWBzA2RnLYPATQllL0OkyqfNqM+gwlGYL5 GPmeo4Ue+Cls5vqvDRbrLW/y0QOOopYooVj/H0p1PsMy8ka3rlNJ7T2cpVMq00wq /VUhXWVSDUM= =06jz -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shared ABCs for the IO implementation
Guido van Rossum python.org> writes: > > Without a shared ABC you'd defeat the whole point of having ABCs. > > However, importing ABCs (which are defined in Python) from C code > (especially such fundamental C code as the I/O library) is really > subtle and best avoided. > > In io.py I solved this by having a Python class inherit from both the > ABC (RawIOBase) and the implementation (_fileio._FileIO). My plan (let's call it "the Operation") is to define the ABCs in Python by deriving the C concrete base classes (that is, have io.XXXIOBase derive _io.XXXIOBase). This way, by inheriting io.XXXIOBase, user code will benefit both from ABC inheritance and fast C concrete implementations. In turn, the concrete implementations in _pyio (the Python version) would register() those ABCs. The reason I think the Python implementations shouldn't be involved in the default inheritance tree is that we don't want user classes to inherit a __del__ method. All this is assuming I haven't made any logic error. Otherwise, I'll have to launch "the new Operation". Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shared ABCs for the IO implementation
On Wed, Feb 25, 2009 at 1:03 PM, Antoine Pitrou wrote: > Guido van Rossum python.org> writes: >> >> Without a shared ABC you'd defeat the whole point of having ABCs. >> >> However, importing ABCs (which are defined in Python) from C code >> (especially such fundamental C code as the I/O library) is really >> subtle and best avoided. >> >> In io.py I solved this by having a Python class inherit from both the >> ABC (RawIOBase) and the implementation (_fileio._FileIO). > > My plan (let's call it "the Operation") is to define the ABCs in Python by > deriving the C concrete base classes (that is, have io.XXXIOBase derive > _io.XXXIOBase). This way, by inheriting io.XXXIOBase, user code will benefit > both from ABC inheritance and fast C concrete implementations. However that's hardly an ABC. You need to provide a path for someone who wants to implement the ABC without inheriting your implementation. > In turn, the concrete implementations in _pyio (the Python version) would > register() those ABCs. The reason I think the Python implementations shouldn't > be involved in the default inheritance tree is that we don't want user classes > to inherit a __del__ method. > > All this is assuming I haven't made any logic error. > Otherwise, I'll have to launch "the new Operation". -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Allow __enter__() methods to skip the with statement body?
Steven Bethard wrote:
> If the problem is just the yield, can't this just be fixed by
> implementing contextlib.nested() as a class rather than as a
> @contextmanager decorated generator? Or is this a problem with class
> based context managers too?
It's a problem for class-based context managers as well. Setting aside
the difficulties of actually maintaining nested()'s state on a class
rather than in a frame (it's definitely possible, but also somewhat
painful), you still end up in the situation where nested() knows that
cmB().__enter__() threw an exception that was then handled by
cmA().__exit__() and hence the body of the with statement should be
skipped but no exception should occur from the point of view of the
surrounding code. However, indicating that is not currently an option
available to nested().__enter__(): it can either raise an exception
(thus skipping the body of the with statement, but also propagating the
exception into the surrounding code), or it can return a value (which
would lead to the execution of the body of the with statement).
Returning a value would definitely be wrong, but raising the exception
isn't really right either.
contextmanager is just a special case - the "skipped yield" inside the
generator reflects the body of the with statement being skipped in the
original non-context manager code.
As to Brett's question of whether or not this is necessary/useful... the
problem I really have with the status quo is that it is currently
impossible to look at the following code snippets and say whether or not
the created CM's are valid:
cm = contextlib.nested(cmA(), cmB())
@contextlib.contextmanager
def cm():
with cmA():
with cmB():
yield
# Not tested, probably have the class version wrong
# This should illustrate why nested() wasn't written
# as a class-based CM though - this one only nests
# two specifically named CMs and look how tricky it gets!
class CM(object):
def __init__(self):
self.cmA = None
self.cmB = None
def __enter__(self):
if self.cmA is not None:
raise RuntimeError("Can't re-use this CM")
self.cmA = cmA()
self.cmA.__enter__()
try:
self.cmB = cmB()
self.cmB.__enter__()
except:
self.cmA.__exit__(*sys.exc_info())
# Can't suppress in __enter__(), so must raise
raise
def __exit__(self, *args):
suppress = False
try:
if self.cmB is not None:
suppress = self.cmB.__exit__(*args)
except:
suppress = self.cmA.__exit__(*sys.exc_info()):
if not suppress:
# Exception has changed, so reraise explicitly
raise
else:
if suppress:
# cmB already suppressed the exception,
# so don't pass it to cmA
suppress = self.cmA.__exit__(None, None, None):
else:
suppress = self.cmA.__exit__(*args):
return suppress
With the current with statement semantics, those CM's may raise
exceptions where the original multiple with statement code would work fine.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shared ABCs for the IO implementation
Guido van Rossum wrote: > On Wed, Feb 25, 2009 at 1:03 PM, Antoine Pitrou wrote: >> Guido van Rossum python.org> writes: >>> Without a shared ABC you'd defeat the whole point of having ABCs. >>> >>> However, importing ABCs (which are defined in Python) from C code >>> (especially such fundamental C code as the I/O library) is really >>> subtle and best avoided. >>> >>> In io.py I solved this by having a Python class inherit from both the >>> ABC (RawIOBase) and the implementation (_fileio._FileIO). >> My plan (let's call it "the Operation") is to define the ABCs in Python by >> deriving the C concrete base classes (that is, have io.XXXIOBase derive >> _io.XXXIOBase). This way, by inheriting io.XXXIOBase, user code will benefit >> both from ABC inheritance and fast C concrete implementations. > > However that's hardly an ABC. You need to provide a path for someone > who wants to implement the ABC without inheriting your implementation. Don't they already have that through register()? However, the other problem with setting up the inheritance as Antoine suggests is that it makes it impossible to import a pure Python version of the module. Once the Python code inherits from something provided only by the C module then the C version isn't optional any more. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shared ABCs for the IO implementation
On Wed, Feb 25, 2009 at 1:31 PM, Nick Coghlan wrote: > Guido van Rossum wrote: >> On Wed, Feb 25, 2009 at 1:03 PM, Antoine Pitrou wrote: >>> Guido van Rossum python.org> writes: Without a shared ABC you'd defeat the whole point of having ABCs. However, importing ABCs (which are defined in Python) from C code (especially such fundamental C code as the I/O library) is really subtle and best avoided. In io.py I solved this by having a Python class inherit from both the ABC (RawIOBase) and the implementation (_fileio._FileIO). >>> My plan (let's call it "the Operation") is to define the ABCs in Python by >>> deriving the C concrete base classes (that is, have io.XXXIOBase derive >>> _io.XXXIOBase). This way, by inheriting io.XXXIOBase, user code will benefit >>> both from ABC inheritance and fast C concrete implementations. >> >> However that's hardly an ABC. You need to provide a path for someone >> who wants to implement the ABC without inheriting your implementation. > > Don't they already have that through register()? I'd like the ABCs to remain just as abstract or concrete as they are in 3.0. As long as the C version implements the same methods with the same semantics as the 3.0 io.py I don't care. > However, the other problem with setting up the inheritance as Antoine > suggests is that it makes it impossible to import a pure Python version > of the module. Once the Python code inherits from something provided > only by the C module then the C version isn't optional any more. I think this should be taken care of by having separate _pyio.py and _cio.py modules which are unified by io.py, right? (Or whatever naming convention is agreed upon; I skipped that thread. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shared ABCs for the IO implementation
Guido van Rossum python.org> writes: > > However that's hardly an ABC. You need to provide a path for someone > who wants to implement the ABC without inheriting your implementation. I may missing something, but it's exactly the same as today's io.py: if you derive the ABC, you inherit the implementations at the same time. OTOH, as Nick says, one can just use register(). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions
In article , Ned Deily wrote: > Speaking of an OS X installer for 3.0.1, over the last few weeks I have > been working on tidying up the OS X installer build process. While the > basic OS X build/installer process is good, some cruft has accumulated > over the past years and a number of mostly minor issues arose due to the > 3.x split. IMO, the most important issues were with IDLE and, thanks to > Ronald, we did get the most important fixes for OS X IDLE checked-in in > time for 3.0.1; they are also in py3k and will be going into trunk and > 26. I have a few other fixes that apply just to the OSX build/installer > parts which did not get submitted in time for the 3.0.1 cutoff but which > are ready to go for 3.x and 2.x. Basically they fix some version number > updating and ensure that the installer image will be built reproducibly > in a clean environment so there is no contamination of the installer > images. Currently, that's easy to do as happened with the first round > of the OS X 2.6 installer (e.g. with a locally installed Tcl/Tk). I want to follow up on this a bit. In the past if the Mac Python installer was built on a machine that did NOT have a locally installed Tcl/Tk then it would fail to work with a locally installed Tcl/Tk: Python would segfault when trying to use Tkinter. The solution was to build the Mac python installer on a machine with a locally installed Tcl/Tk. The resulting installer package would work on all systems -- with or without locally installed Tcl/Tk. So...has this problem been worked around, or is the Mac installer still built on a machine that has a locally installed Tcl/Tk? I haven't run Python 2.6 yet because there is no release of numpy that is compatible. I did try upgrading from 2.5.2 to 2.5.4 and got a segfault when trying to display images using PIL and Tkinter; I have not had time to try to track that down, so I've just reverted for now. Most people who makes serious use of Tkinter presumably have a locally installed Tcl/Tk because the version that Apple provides is ancient and is missing many important bug fixes and performance enhancements. Also, a somewhat related issue: Tcl/Tk 8.4 is no longer maintained. All development work is going on in Tcl/Tk 8.5. Presumably Apple will transition one of these days, and at that point we may need a separate Mac Python installer for the older operating systems vs. the newer. -- Rusell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shared ABCs for the IO implementation
On Wed, Feb 25, 2009 at 1:46 PM, Antoine Pitrou wrote: > Guido van Rossum python.org> writes: >> >> However that's hardly an ABC. You need to provide a path for someone >> who wants to implement the ABC without inheriting your implementation. > > I may missing something, but it's exactly the same as today's io.py: if you > derive the ABC, you inherit the implementations at the same time. > > OTOH, as Nick says, one can just use register(). OK then. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyCon 2009: Call for sprint projects
Hi Jacob, Will there be GeoDjango/OpenLayers subsprint in the Django sprint? Thanks, RHH On Mon, Feb 9, 2009 at 8:27 PM, Jacob Kaplan-Moss wrote: > Python-related projects: join the PyCon Development Sprints! > > The development sprints are a key part of PyCon, a chance for the contributors > to open-source projects to get together face-to-face for up to four days of > intensive learning and development. Newbies sit at the same table as the > gurus, > go out for lunch and dinner together, and have a great time while advancing > their project. Sprints are one of the best parts of PyCon; in 2008 over 250 > sprinters came for at least one day! > > If your project would like to sprint at PyCon, now is the time to let us know. > We'll collect your info and publish it so that participants will have time to > make plans. We'll need to get the word out early so that folks who want to > sprint have time to make travel arrangements. > > In the past, some have been reluctant to commit to sprinting: some may not > know > what sprinting is all about; others may think that they're not "qualified" to > sprint. We're on an ongoing mission to change that perception: > > * We'll help promote your sprint. The PyCon website, the PyCon blog, the PyCon > podcast, and press releases will be there for you. > > * PyCon attendees will be asked to commit to sprints on the registration form, > which will include a list of sprints with links to further info. > > * We will be featuring a "How To Sprint" session on Sunday afternoon, followed > by sprint-related tutorials, all for free. This is a great opportunity to > introduce your project to prospective contributors. We'll have more details > about this later. > > * Some sponsors are helping out with the sprints as well. > > There's also cost. Although the sprinting itself is free, sprints have > associated time and hotel costs. We can't do anything about the time cost, but > we may have some complimentary rooms and funding available for sprinters. We > will have more to say on financial aid later. > > Those who want to lead a sprint should send the following information > to [email protected]: > > * Project/sprint name > > * Project URL > > * The name and contact info (email and/or telephone) for the sprint leader(s) > and other contributors who will attend the sprint > > * Instructions for accessing the project's code repository and documentation > (or > a URL) > > * Pointers to new contributor information (setup, etc.) > > * Any special requirements (projector? whiteboard? flux capacitor?) > > We will add this information to the PyCon website and set up a wiki page for > you > (or we can link to yours). Projects should provide a list of goals (bugs to > fix, > features to add, docs to write, etc.), especially some goals for beginners, to > attract new sprinters. The more detail you put there, the more prepared your > sprinters will be, and the more results you'll get. > > In 2008 there were sprints for Python, TurboGears, Pylons, Django, Jython, > WSGI, > PyGame, Bazaar, Trac, PyCon-Tech, OLPC, Orbited, PyPy, Grok, and many others. > We > would like to see all these and more! > > Sprints will start with an introductory session on Sunday, March 29; this > session will begin immedately after PyCon's scheduled portion ends. The > sprints > themselves will run from Monday, March 30 through Thursday, April 2, 2009. > > You can find all these details and more at http://us.pycon.org/2009/sprints/. > > If you have any questions, feel free to contact me directly. > Thank you very much, and happy coding! > > Jacob Kaplan-Moss > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/starsareblueandfaraway%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug tracker house cleaning.
Raymond> ISTM, that when closing duplicate bug reports, both should Raymond> reference one another so that the combined threads don't get Raymond> lost. RT has a merge feature which allows you to take a duplicate an merge it into another ticket. This merges the chain of comments, cc's requestors, etc. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
