Python-Dev March 2011

python-dev@python.org

176 participants
199 discussions

by Facundo Batista

I know there's a big ideas exchange in this list about how to use Mercurial in the Python project. I know that still there is not wide and firm consensus about the whole workflow to follow. But maybe some small decisions are already taken, some suggestions about the best way to do this or that, even if there are others that are not taken. Is this being documented somewhere? Thank you! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

10 years

not possible to install python 3.2

by Laura

I order to install Python as python3 on Linux, i did: ./configure make make test sudo make install However, when i typed "make test", i got two error messages: "test test_distutils failed -- multiple errors occurred; run in verbose mode for details" "sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='a' encoding='ANSI_X3.4-1968'> make: *** [test] Error 1" The Result? When I type python on Linux, i get the older version 2.7.1 instead of the version that i just installed (python 3.2). Could you help me? Thank you, Laura

10 years

Use regrtest.py --timeout on buildbots

by Victor Stinner

Hi, I just added a --timeout option to Lib/test/regrtest.py: if a test (one function, not a whole file) takes more than TIMEOUT seconds, the traceback is dumped and it exits. I tested it on 3 buildbots with a timeout of 5 minutes and it worked as expected: see #11727 for examples. It would be nice to have this feature enabled on all buildbots. We may set a default timeout of 15 minutes. If a test takes more than 15 minutes, something goes wrong! Some buildbot use a timeout of 1200 or 3600 seconds for regrtest (all tests). But the build slave should be able to override the default timeout. What do you think? Victor

10 years

warn_unused_result warnings

by Benjamin Peterson

I'm rather sick of seeing this warnings on all compiles, so I propose we enable the -Wno-unused-results option. I judge that most of the cases where this occurs are error reporting functions, where not much with return code can be done. -- Regards, Benjamin

10 years

Impaired Usability of the Mercurial Source Viewer

by Raymond Hettinger

The Hg source viewer needs to be tweaked to improve its usability. What we've got now is a step backwards from the previous svn viewer. Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for example, there are two issues. 1) the code cannot be cut-and-pasted because the line numbers are commingled with the source text. 2) the code is hard to read because of the alternating white and gray bars. Contrast that to the more typical, beautiful presentations with a solid background and the ability to cut-and-paste without grabbing line numbers: http://dpaste.org/qyKv/ http://code.activestate.com/recipes/577629-namedtupleabc-abstract-base-clas… Raymond P.S. The old svn viewer worked great (looked good and could be cut), but that was changed just before the Mercurial switchover (the fonts changed, the line numbering code changed, and the leading changed), so it is not a good comparison anymore.

10 years

faulthandler is now part of Python 3.3

by Victor Stinner

Hi, I pushed my faulthandler module into the default branch (Python 3.3). Since one week, I fixed a lot of bugs (platform issues), improved the tests and Antoine wrote a new implementation of dump_backtraces_later() using a thread (instead of SIGALRM+alarm()). It should now work on all platforms (but register() is not available on Windows). Use "python -X faulthandler" or "PYTHONFAULTHANDLER=1 python" to install the fault handler at startup (catch segfaults and other fatal errors). You can also register a signal (e.g. SIGUSR1) to dump the traceback on this signal. The latest added feature is to be able to the dump the traceback after a timeout and exit the process: we may use it on regrtest.py to learn more about test_multiprocess and test_threadsignals hangs. Issue #11393 has a patch implementing this issue: add --timeout option to regrtest.py. You can also just dump the traceback after the timeout without exiting. Py_FatalError() always print the Python traceback (except if an exception was raised: print the exception with its traceback). For more information, read the doc: http://docs.python.org/dev/library/faulthandler.html Please tell me if you have any issue related to faulthandler. -- If you get "undefined reference to `_PyFaulthandler_Init'" compiler error, copy Modules/Setup.dist to Modules/Setup (cp Modules/Setup.dist Modules/Setup). test_faulthandler hangs on AMD64 Gentoo Wide 3.x and AMD64 OpenIndiana 3.x. It looks to be related to the stack overflow test (the stack is maybe not limited on these buildbots?). I have a patch, but I cannot test it because these buildbots are dead (oops, sorry!). Most buildbots are red because a regression in test_logging (since 2 days): I disabled temporary the test (issue #11557), I hope that the situation will be better in a few hours. Thank you Antoine for your reviews! Victor

10 years

Re: [Python-Dev] devguide: Add a table of contents to the FAQ.

by Antoine Pitrou

On Tue, 29 Mar 2011 21:00:22 +0200 ezio.melotti <python-checkins(a)python.org> wrote: > http://hg.python.org/devguide/rev/f722956afeac > changeset: 405:f722956afeac > user: Ezio Melotti > date: Tue Mar 29 22:00:13 2011 +0300 > summary: > Add a table of contents to the FAQ. Could it be collapsed by default? It's quite long, and redundant with the sidebar. thanks Antoine.

10 years

Re: [Python-Dev] [Python-checkins] cpython: Issue #11393: get more information on assertion error (test_faulthandler)

by Victor Stinner

> > http://hg.python.org/cpython/rev/61626c3f3a54 > >... > > - assert (b -a)>= pause > > + assert (b - a)>= pause, "{{}}< {{}}".format(b - a, pause) > > > + assert (b - a)>= pause, "{{}}< {{}}".format(b - a, pause) > > >>> a,b,pause = 0,0,1 > >>> "{{}} < {{}}".format(b - a, pause) > '{} < {}' > > I suspect you want 1 or 3 braces. > > Terry Nope, I really want {{}}: the diff is on a template using to generate Python code executed in a subprocess. Victor

10 years

EuroPython 2011: call for paper is ending - Please spread the word!

by Palla

Hi all members, I'm Francesco and I am writing on behalf of "Python Italia APS", a no-profit association promoting EuroPython conference. (www.europython.eu) Europython End of Call for Presentations is April 6th. I'd like to ask to you to forward this mail to anyone that you feel may be interested. We're looking for proposals on every aspects of Python: programming from novice to advanced levels, applications and frameworks, or how you have been involved in introducing Python into your organisation. **First-time speakers are especially welcome**; EuroPython is a community conference and we are eager to hear about your experience. If you have friends or colleagues who have something valuable to contribute, twist their arms to tell us about it! Presenting at EuroPython ------------------------ We will accept a broad range of presentations, from reports on academic and commercial projects to tutorials and case studies. As long as the presentation is interesting and potentially useful to the Python community, it will be considered for inclusion in the programme. Can you show the conference-goers something new and useful? Can you show attendees how to: use a module? Explore a Python language feature? Package an application? If so, consider submitting a talk. Talks and hands-on trainings ---------------------------- There are two different kind of presentations that you can give as a speaker at EuroPython: * **Regular talk**. These are standard "talk with slides", allocated in slots of 45, 60 or 90 minutes, depending on your preference and scheduling constraints. A Q&A session is held at the end of the talk. * **Hands-on training**. These are advanced training sessions for a smaller audience (10-20 people), to dive into the subject with all details. These sessions are 4-hours long, and audience will be strongly encouraged to bring a laptop to experiment. They should be prepared with less slides and more source code. If possible, trainers will also give a short "teaser talk" of 30 minutes the day before the training, to tease delegates into attending the training. In the talk submission form, we assume that you intend to give a regular talk on the subject, but you will be asked if you are available for also doing a hands-on training on the very same subject. Speakers that will give a hands-on training are rewarded with a **free entrance** to EuroPython to compensate for the longer preparation required, and might also be eligible for a speaking fee (which we cannot confirm at the moment). Topics and goals ---------------- Specific topics for EuroPython presentations include, but are not limited to: - Core Python - Other implementations: Jython, IronPython, PyPy, and Stackless - Python libraries and extensions - Python 3.x migration - Databases - Documentation - GUI Programming - Game Programming - Network Programming - Open Source Python projects - Packaging Issues - Programming Tools - Project Best Practices - Embedding and Extending - Science and Math - Web-based Systems Presentation goals usually are some of the following: - Introduce audience to a new topic they are unaware of - Introduce audience to new developments on a well-known topic - Show audience real-world usage scenarios for a specific topic (case study) - Dig into advanced and relatively-unknown details on a topic - Compare different options in the market on a topic Community-based talk voting --------------------------- This year, for the first time in EuroPython history, the talk voting process is fully public. Every partecipant gains the right to vote for talks submitted during the Call For Papers, as soon as they commit to their presence at the conference by buying a ticket. See all the details in the talk voting[1] page. Contacts -------- For any further question, feel free to contact the organizers at info(a)pycon.it. Thank you! [1]: http://ep2011.europython.eu/talk-voting -- ->PALLA

10 years

Non-code changes on "old" branches

by Mark Hammond

Hi, There are a couple of changes I'd like to make and would like some guidance on policy: http://bugs.python.org/issue6498 is a documentation bug which exists in Python 2.6 and later. The patch in that bug touches the docs and a comment in one source file. Is it acceptable to push that change to the 2.6 branch, or should I start with 2.7? My request re .hgignore from yesterday didn't get any complaints, so I intend opening a bug, asking for review here and if I don't get objections in a day or so, pushing the change. This really should go all the way back to 2.5 even though that release has long been closed. Is it acceptable to push a change to .hgignore to the 2.5 branch? If not, where should I start with such a change? I ask these questions primarily as the dev guide tells me I should forward-port all changes - thus, I need to know the earliest versions I can use before I can even start the process... Thanks, Mark

10 years

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev March 2011