Mailman 3 June 2011 - Python-Dev

In-Python virtualisation and packaging
by Vinay Sajip 21 Jun '11

21 Jun '11

Back in March this year, Carl Meyer did some work to see if it was feasible to bring virtualenv functionality into Python [1] (code at [2]). Carl's changes were to Python code only, which was almost but not quite enough. I built on his changes with updates to C code in getpath.c/getpathp.c, and my code is at [3]. I've kept it synchronised with the core cpython repo, including the recently committed packaging modules. While there are issues to work through such as dealing with source builds (and no doubt plenty of others), it now seems possible to create virtual environments and install stuff into them using just the stdlib (modulo currently needing Distribute for the packages which don't yet support setup.cfg-based packaging, but it's all done automatically for a user). So you can do e.g. $ python3.3 -m virtualize /tmp/venv $ source /tmp/venv/bin/activate.sh $ pysetup3 install Mako and so on. A log of early experiments, which seems reasonably promising, is at [4]. Do people agree that it may be fitting, proper and timely to bring virtualisation into Python, and are there any fundamental flaws anyone can see with the approach used? If people want to experiment with this code without cloning and building, I created a Debian package using checkinstall, which can be installed using sudo dpkg -i pythonv_3.3-1_i386.deb and removed using sudo dpkg -r pythonv I can make this Debian package available for download, if anyone wants it. Regards, Vinay Sajip [1] http://mail.python.org/pipermail/distutils-sig/2011-March/017519.html [2] https://bitbucket.org/carljm/cpythonv [3] https://bitbucket.org/vinay.sajip/pythonv [4] https://gist.github.com/1022601

10 25

packaging backport
by Tarek Ziadé 21 Jun '11

21 Jun '11

Hello I am starting the backport of Packaging into a standalone version named Distutils2 -- this is very important to speed up the development of packaging itself since it'll give of more feedback from 2.x projects To do this I need to create a script that does a mass renaming of 'packaging' into 'distutils2', then I can start to play with 3to2 and ...3.xto3.x :) . I tried to script rope but the py3k version seem not compatible with our current AST -- and it's a bit overkill for this task I guess. Before I start to write my own refactoring tool, I was wondering if anyone here had some experience in this, and could give me some hints. Thanks Tarek -- Tarek Ziadé | http://ziade.org

4 6

Language summit writeup anyone?
by Maciej Fijalkowski 21 Jun '11

21 Jun '11

Hi. Unfortunately I'm missing Europython (and language summit) this year. Did anyone do a writeup on what was discussed? Cheers, fijal

4 3

Parser/intrcheck.c
by Antoine Pitrou 20 Jun '11

20 Jun '11

Hello, I may be missing something, but I'm wondering whether Parser/intrcheck.c is still used anywhere. It's only mentioned in some comments: $ grep -r intrcheck.c * Modules/signalmodule.c:1197:/* Replacements for intrcheck.c functionality PC/os2vacpp/makefile.omk:217: # intrcheck.c -- Not Referenced by Anyone (?) Python/sigcheck.c:3: interrupt occurs. It can't be in the intrcheck.c file since that And if I remove it and "make clean", I can still rebuild successfully. Regards Antoine.

2 2

REMINDER: Participation Requested: Survey about Open-Source Software Development
by Jeffrey Carver 20 Jun '11

20 Jun '11

Hi, Apologies for any inconvenience and thank you to those who have already completed the survey. We will keep the survey open for another couple of weeks. But, we do hope you will consider responding to the email request below (sent 2 weeks ago). Thanks, Dr. Jeffrey Carver Assistant Professor University of Alabama (v) 205-348-9829 (f) 205-348-0219 http://www.cs.ua.edu/~carver -----Original Message----- From: Jeffrey Carver [mailto:opensourcesurvey@cs.ua.edu] Sent: Monday, June 13, 2011 11:46 AM To: 'python-dev(a)python.org' Subject: Participation Requested: Survey about Open-Source Software Development Hi, Drs. Jeffrey Carver, Rosanna Guadagno, Debra McCallum, and Mr. Amiangshu Bosu, University of Alabama, and Dr. Lorin Hochstein, University of Southern California, are conducting a survey of open-source software developers. This survey seeks to understand how developers on distributed, virtual teams, like open-source projects, interact with each other to accomplish their tasks. You must be at least 19 years of age to complete the survey. The survey should take approximately 15 minutes to complete. If you are actively participating as a developer, please consider completing our survey. Here is the link to the survey: http://goo.gl/HQnux We apologize for inconvenience and if you receive multiple copies of this email. This survey has been approved by The University of Alabama IRB board. Thanks, Dr. Jeffrey Carver Assistant Professor University of Alabama (v) 205-348-9829 (f) 205-348-0219 http://www.cs.ua.edu/~carver

1 0

Re: [Python-Dev] cpython (3.2): Fix closes Issue12359 - Minor update to module import description.
by Georg Brandl 20 Jun '11

20 Jun '11

On 20.06.2011 02:42, senthil.kumaran wrote: > http://hg.python.org/cpython/rev/bf8b4c43fb94 > changeset: 70886:bf8b4c43fb94 > branch: 3.2 > parent: 70884:4444afcfb22e > user: Senthil Kumaran <senthil(a)uthcode.com> > date: Sun Jun 19 17:37:06 2011 -0700 > summary: > Fix closes Issue12359 - Minor update to module import description. > > files: > Doc/tutorial/modules.rst | 15 ++++++++------- > 1 files changed, 8 insertions(+), 7 deletions(-) > > > diff --git a/Doc/tutorial/modules.rst b/Doc/tutorial/modules.rst > --- a/Doc/tutorial/modules.rst > +++ b/Doc/tutorial/modules.rst > @@ -159,13 +159,14 @@ > > .. index:: triple: module; search; path > > -When a module named :mod:`spam` is imported, the interpreter searches for a file > -named :file:`spam.py` in the current directory, and then in the list of > -directories specified by the environment variable :envvar:`PYTHONPATH`. This > -has the same syntax as the shell variable :envvar:`PATH`, that is, a list of > -directory names. When :envvar:`PYTHONPATH` is not set, or when the file is not > -found there, the search continues in an installation-dependent default path; on > -Unix, this is usually :file:`.:/usr/local/lib/python`. > +When a module named :mod:`spam` is imported, the interpreter searches for a > +file named :file:`spam.py` in the directory containing the input script (or > +thecurrent directory), and then in the list of directories specified by the By just adding "or the current directory", you've actually made this more confusing: now the reader will wonder when it's the script directory and when it's the current directory. Georg

2 2

Re: [Python-Dev] cpython (3.2): Fix closes Issue12315 - Updates to http.client documentation.
by Georg Brandl 20 Jun '11

20 Jun '11

On 20.06.2011 02:00, senthil.kumaran wrote: > http://hg.python.org/cpython/rev/d801b570b1dd > changeset: 70882:d801b570b1dd > branch: 3.2 > parent: 70880:9e58a638f028 > user: Senthil Kumaran <senthil(a)uthcode.com> > date: Sun Jun 19 16:56:49 2011 -0700 > summary: > Fix closes Issue12315 - Updates to http.client documentation. > > files: > Doc/library/http.client.rst | 13 ++++++++++++- > 1 files changed, 12 insertions(+), 1 deletions(-) > > > diff --git a/Doc/library/http.client.rst b/Doc/library/http.client.rst > --- a/Doc/library/http.client.rst > +++ b/Doc/library/http.client.rst > @@ -543,6 +543,9 @@ > A debugging hook. If :attr:`debuglevel` is greater than zero, messages > will be printed to stdout as the response is read and parsed. > > +.. attribute:: HTTPResponse.closed > + > + Is True if the stream is closed. > > Examples > -------- This is not a big deal, and I'm not picking specially on you here, Senthil, it's just something that I've noticed several times: Newlines are a valuable tool for structuring reST files (just like in Python files). I tried to set up a convention to separate large blocks (such as sections) by two newlines, to make it easier to scroll and find what you're looking for. Please try to keep this intact. Thanks, Georg

2 1

Re: [Python-Dev] [Python-checkins] cpython: #6771: Move wrapper function into __init__ and eliminate wrapper module
by Jim Jewett 19 Jun '11

19 Jun '11

Does this really need to be a bare except? On Sat, Jun 18, 2011 at 8:21 PM, r.david.murray <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/9c96c3adbcd1 > changeset: 70867:9c96c3adbcd1 > user: R David Murray <rdmurray(a)bitdance.com> > date: Sat Jun 18 20:21:09 2011 -0400 > summary: > #6771: Move wrapper function into __init__ and eliminate wrapper module > > Andrew agreed in the issue that eliminating the module file made sense. > Wrapper has only been exposed as a function, and so there is no (easy) > way to access the wrapper module, which in any case only had the one > function in it. Since __init__ already contains a couple wrapper > functions, it seems to make sense to just move wrapper there instead of > importing it from a single function module. > > files: > Lib/curses/__init__.py | 46 +++++++++++++++++++++++++++- > Lib/curses/wrapper.py | 50 ------------------------------ > Misc/NEWS | 4 ++ > 3 files changed, 49 insertions(+), 51 deletions(-) > > > diff --git a/Lib/curses/__init__.py b/Lib/curses/__init__.py > --- a/Lib/curses/__init__.py > +++ b/Lib/curses/__init__.py > @@ -13,7 +13,6 @@ > __revision__ = "$Id$" > > from _curses import * > -from curses.wrapper import wrapper > import os as _os > import sys as _sys > > @@ -57,3 +56,48 @@ > has_key > except NameError: > from has_key import has_key > + > +# Wrapper for the entire curses-based application. Runs a function which > +# should be the rest of your curses-based application. If the application > +# raises an exception, wrapper() will restore the terminal to a sane state so > +# you can read the resulting traceback. > + > +def wrapper(func, *args, **kwds): > + """Wrapper function that initializes curses and calls another function, > + restoring normal keyboard/screen behavior on error. > + The callable object 'func' is then passed the main window 'stdscr' > + as its first argument, followed by any other arguments passed to > + wrapper(). > + """ > + > + try: > + # Initialize curses > + stdscr = initscr() > + > + # Turn off echoing of keys, and enter cbreak mode, > + # where no buffering is performed on keyboard input > + noecho() > + cbreak() > + > + # In keypad mode, escape sequences for special keys > + # (like the cursor keys) will be interpreted and > + # a special value like curses.KEY_LEFT will be returned > + stdscr.keypad(1) > + > + # Start color, too. Harmless if the terminal doesn't have > + # color; user can test with has_color() later on. The try/catch > + # works around a minor bit of over-conscientiousness in the curses > + # module -- the error return from C start_color() is ignorable. > + try: > + start_color() > + except: > + pass > + > + return func(stdscr, *args, **kwds) > + finally: > + # Set everything back to normal > + if 'stdscr' in locals(): > + stdscr.keypad(0) > + echo() > + nocbreak() > + endwin() > diff --git a/Lib/curses/wrapper.py b/Lib/curses/wrapper.py > deleted file mode 100644 > --- a/Lib/curses/wrapper.py > +++ /dev/null > @@ -1,50 +0,0 @@ > -"""curses.wrapper > - > -Contains one function, wrapper(), which runs another function which > -should be the rest of your curses-based application. If the > -application raises an exception, wrapper() will restore the terminal > -to a sane state so you can read the resulting traceback. > - > -""" > - > -import curses > - > -def wrapper(func, *args, **kwds): > - """Wrapper function that initializes curses and calls another function, > - restoring normal keyboard/screen behavior on error. > - The callable object 'func' is then passed the main window 'stdscr' > - as its first argument, followed by any other arguments passed to > - wrapper(). > - """ > - > - try: > - # Initialize curses > - stdscr = curses.initscr() > - > - # Turn off echoing of keys, and enter cbreak mode, > - # where no buffering is performed on keyboard input > - curses.noecho() > - curses.cbreak() > - > - # In keypad mode, escape sequences for special keys > - # (like the cursor keys) will be interpreted and > - # a special value like curses.KEY_LEFT will be returned > - stdscr.keypad(1) > - > - # Start color, too. Harmless if the terminal doesn't have > - # color; user can test with has_color() later on. The try/catch > - # works around a minor bit of over-conscientiousness in the curses > - # module -- the error return from C start_color() is ignorable. > - try: > - curses.start_color() > - except: > - pass > - > - return func(stdscr, *args, **kwds) > - finally: > - # Set everything back to normal > - if 'stdscr' in locals(): > - stdscr.keypad(0) > - curses.echo() > - curses.nocbreak() > - curses.endwin() > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -193,6 +193,10 @@ > Library > ------- > > +- Issue #6771: moved the curses.wrapper function from the single-function > + wrapper module into __init__, eliminating the module. Since __init__ was > + already importing the function to curses.wrapper, there is no API change. > + > - Issue #11584: email.header.decode_header no longer fails if the header > passed to it is a Header object, and Header/make_header no longer fail > if given binary unknown-8bit input. > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins > >

2 1

Re: [Python-Dev] [Python-checkins] cpython (3.1): Fix closes issue12261 - Minor documention changes in the urllib.parse.rst
by Éric Araujo 19 Jun '11

19 Jun '11

Hi, Remember that 3.1 is in security mode, and as such will not get new documentation releases. See the previous threads about 2.6 docs or security releases for more info. Regards

2 1

Re: [Python-Dev] [Python-checkins] devguide: Add a communications section to the devguide FAQ (closes #11690)
by Victor Stinner 19 Jun '11

19 Jun '11

Le dimanche 19 juin 2011 à 16:51 +0200, nick.coghlan a écrit : > +Where should I ask general Python questions? > +-------------------------------------------- > + > +General Python questions should still go to `python-list`_ or `python-tutor`_ > +or similar resources, such as StackOverflow_ or ``#python`` on IRC. You should mention the IRC server, I suppose that you are talking about the Freenode server. There are other channels in other languages, like #python-fr (on Freenode). You may also add a reference to the #python-dev chanel. I am connected most of the time, but not always available. Victor

1 0