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?
I order to install Python as python3 on Linux, i did:
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
"sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null'
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?
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
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?
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.
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
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.
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
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:
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
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!
On Tue, 29 Mar 2011 21:00:22 +0200
ezio.melotti <python-checkins(a)python.org> wrote:
> changeset: 405:f722956afeac
> user: Ezio Melotti
> date: Tue Mar 29 22:00:13 2011 +0300
> Add a table of contents to the FAQ.
Could it be collapsed by default? It's quite long, and redundant with
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
* **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
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
Topics and goals
Specific topics for EuroPython presentations include, but are not limited
- Core Python
- Other implementations: Jython, IronPython, PyPy, and Stackless
- Python libraries and extensions
- Python 3.x migration
- 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 page.
For any further question, feel free to contact the organizers at
info(a)pycon.it. Thank you!
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...