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
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] 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 | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] 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 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 ---
//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
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-tp22191916p22203820.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
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
st...@integrityintegrators.net 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):
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)
Re: [Python-Dev] File Path retrieving problem
2009/2/25 Sudhir Kakumanu music24...@gmail.com: 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 python-l...@python.org). Paul. ___ 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
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/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 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] 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 | t...@espians.com | +44 (0) 7809 569 369 http://tav.espians.com | http://twitter.com/tav | skype:tavespian ___ 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
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 a...@amk.ca 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/techtonik%40gmail.com -- --anatoly t. ___ 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
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
Re: [Python-Dev] Shared ABCs for the IO implementation
On Wed, Feb 25, 2009 at 7:35 AM, Antoine Pitrou solip...@pitrou.net 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 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] 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 scott.dani...@acm.org ___ 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] Allow __enter__() methods to skip the with statement body?
On Wed, Feb 25, 2009 at 04:24, Nick Coghlan ncogh...@gmail.com 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 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] Allow __enter__() methods to skip the with statement body?
On Wed, Feb 25, 2009 at 4:24 AM, Nick Coghlan ncogh...@gmail.com 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__(). 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 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] Attention Bazaar mirror users
On Wed, Feb 25, 2009 at 2:23 PM, Barry Warsaw ba...@python.org 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 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] 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 ba...@python.org 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 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] Shared ABCs for the IO implementation
Guido van Rossum guido at 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 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] Shared ABCs for the IO implementation
On Wed, Feb 25, 2009 at 1:03 PM, Antoine Pitrou solip...@pitrou.net wrote: Guido van Rossum guido at 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 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] 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 | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Shared ABCs for the IO implementation
Guido van Rossum wrote: On Wed, Feb 25, 2009 at 1:03 PM, Antoine Pitrou solip...@pitrou.net wrote: Guido van Rossum guido at 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 | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Shared ABCs for the IO implementation
On Wed, Feb 25, 2009 at 1:31 PM, Nick Coghlan ncogh...@gmail.com wrote: Guido van Rossum wrote: On Wed, Feb 25, 2009 at 1:03 PM, Antoine Pitrou solip...@pitrou.net wrote: Guido van Rossum guido at 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 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] Shared ABCs for the IO implementation
Guido van Rossum guido at 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 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] OS X Installer for 3.0.1 and supported versions
In article nad-34f90e.0314022...@news.gmane.org, Ned Deily n...@acm.org 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 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] Shared ABCs for the IO implementation
On Wed, Feb 25, 2009 at 1:46 PM, Antoine Pitrou solip...@pitrou.net wrote: Guido van Rossum guido at 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 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] 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 ja...@jacobian.org 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 pycon-organiz...@python.org: * 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 ja...@jacobian.org ___ 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/starsareblueandfaraway%40gmail.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] 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 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
