I have now installed a pre-commit hook that verifies that the code
being committed follows the formatting of reindent.py, for all files
under /python in the projects repository. Please let me know if this
causes any problems.
Ok, things seem to be OK. So the release25-maint branch is unfrozen.
Go crazy. Well, a little bit crazy.
Anthony Baxter <anthony(a)interlink.com.au>
It's never too late to have a happy childhood.
As a data point, I thought I'd point out that the recent object.__init__ change
broke a handful of Twisted unit tests. The fix for this was simple, and I've
already implemented it, but it would have been nice if the old behavior had been
deprecated first and then removed, instead of just disappearing.
The following two bugs can be closed with possible document update. I
have put my suggestions for doc changes in the SF tracker.
http://python.org/sf/1615275 - tempile.TemporaryFile differences
between linux and windows
http://python.org/sf/1633941 - for line in sys.stdin: doesn't notice
EOF the first time
I opened 1643712 to request doc change for this bug.
http://python.org/sf/1668596 - distutils chops the first character of filenames
This one requires no action and can be closed, IMO.
I posted patch 1675951 a while ago that fixes a performance problem for
small reads in the gzip stdlib module. It also removes the necessity for
seeking while reading gzip files (allows reading from stdin now).
Is there anything I can/have to do to get the patch in?
I get this warning from my test suite when I introduced a segment of code:
python(18603,0xa000d000) malloc: *** Deallocation of a pointer not
malloced: 0x310caa3; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
Always the same warning; sometimes it even segfaults python, but
rarely. I only see it on Mac OS X (two separate machines), python
2.4.3 both built from source via Darwin Ports. The same suite gives no
such warning on a 2.4.3 production machine running Free BSD.
I know what segment of code causes it but can't for the life of me
think of writing it a different way in this specific application. In a
nutshell, it's two sets of two nested try blocks (try, try, except,
except * 2) where the inner except can re-raise a new exception if a
rescue function wants to. it sounds convoluted because it is! :( I
tried really hard recreating it in a test case outside of my
application but of course there is something too deeply buried that I
I turned on MallocHelp but just stared blankly at heaps and stack
options. Is there anything I can switch on that would be helpful to
anyone who might be interested in this problem? :) I also wanted to
put out some feelers in case it sounds like something that is fixed
elsewhere (I'm having trouble running my existing suite in 2.5 due to
setuptools not working and me not having enough time to fiddle with
Sorry if this is all very vague, I'm just a bit stumped and wanted to
see if anyone had some suggestions.
Now that I should be able to actually keep up with my summary duties,
I need to figure out how to tackle the changing landscape of the
development lists. The old summaries were no problem, before my time.
When the python-3000 list was created, nearly everything was just
conceptual, floaty talk that didn't have place in the concrete world
of real development conversation in python-dev. The day recently came
when python-3000 got to the point of being "real" enough to warrant a
third list, python-ideas, for real floaty ideas and now conversations
routinely cross all three. Something might be brought up in ideas,
move to 3000 to be solidified, and then to dev to discuss backporting
to 2.6 or so. Obviously, we're missing out on a lot for the summaries.
So, the question I pose is how would everyone like to see this
resolved? As I see it, there are two things I can do. I can either
summaries each list separately, and try to sort out the cross overs.
Or, I can start pulling in all three development lists into all the
summaries. I prefer the second option, but I want to clear with
everyone else. I hope no one has a problem with getting more with the
summaries from now on? If not, I'll begin with the second half of
Along with that, I need to know if my svn rights for submitting the
summaries extends to the actual summary scripts? I'll need to change
them to pull in extra lists. I'm actually thinking lots of projects
could use such a script, so while I'm at it I want to just generalize
it a bit and put it somewhere for anyone else to use, if no one has
issues with that.
Read my blog! I depend on your acceptance of my opinion! I am interesting!
Could we use and add this macro to object.h? It could be a much
cleaner and safer way of dealing with new references you want to clean
up in the same scope. The first one will make sure to decref your new
reference when you are done with it. The second one will make sure to
set a borrowed reference to NULL afterward, so you can't access it
after you are done with it. The second might be useless, but it seems
like it might be useful for debugging and being sure you stopped using
a reference when you thought you did.
Anyone, please let me know if this is a dumb idea.
/* Obtain a New Reference and clean it up at the end of the scope. */
#define Py_CLEANREF(_refname, _newref, _scopecode)\
(PyObject *) _refname = _newref;\
/* Obtain a Borrowed Reference and forget about it at the end of the scope. */
#define Py_FORGETREF(_refname, _newref, _scopecode)\
(PyObject *) _refname = _newref;
_refname = NULL;
Read my blog! I depend on your acceptance of my opinion! I am interesting!
He're a reminder to submit a talk at EuroPython!
Like each year, we have both the regular conference (see call at
http://indico.cern.ch/conferenceCFA.py?confId=13919) and a somewhat
separated Refereed Papers section. Here is the call for the latter.
The deadline for both is the 18th of May.
Vilnius, Lithuania 9-11 July
Call for Refereed Papers
EuroPython is the only conference in the Python world that has a
properly prestigious peer-reviewed forum for presenting technical and
scientific papers. Such papers, with advanced and highly innovative
contents, can equally well stem from academic research or industrial
research. We think this is an important function for EuroPython, so we
are even making some grants available to help people with travel costs.
We will be happy to consider papers in subject areas including, but not
necessarily limited to, the following:
* Python language and implementations
* Python modules (in the broadest sense)
* Python extensions
* Interoperation between Python and other languages / subsystems
* Scientific applications of Python
* Python in Education
* Agile Methodologies and Testing
* Social Skills
We are looking for Python-related scientific and technical papers of
advanced, highly innovative content that present the results of original
research (be it of the academic or "industrial research" kind), with
proper attention to "state of the art" and previous relevant
literature/results (whether such relevant previous literature is itself
directly related to Python or not).
We do not intend to let the specific subject area block a paper's
acceptance, as long as the paper satisfies other requirements:
innovative, Python-related, reflecting original research, with proper
attention to previous literature.
Please submit abstracts of no more than 200 words to the refereeing
committee. You can send submissions no later than 18 May 2007. We shall
inform you whether your paper has been selected and announce the
conference schedule on the 25 May 2007. For all details regarding the
submission of abstracts, please see the EuroPython website
(http://www.europython.org). WARNING: Independently of their topic, all
abstracts must be submitted *in the Refereed Papers track* in order to
be considered by the refereeing committee!
If your abstract is accepted, you must submit your corresponding paper
before 29 June 2006. Last-minute changes will be accepted until the start
of the conference. You should submit the paper as a PDF file, in A4
format, complete, "stand-alone", and readable on any standards-compliant
PDF reader (basically, the paper must include all fonts and figures it
uses, rather than using external pointers to them; by default, most
PDF-preparation programs typically produce such valid "stand-alone" PDF
documents). There are no strict typesetting rules.
The refereeing committee, selected by Armin Rigo, will examine all
abstracts and papers. The committee may consult external experts as it
deems fit. Referees may suggest or require certain changes and editing
in submissions, and make acceptance conditional on such changes being
performed. We expect all papers to reflect the abstract as approved and
reserve the right, at our discretion, to reject a paper, despite having
accepted the corresponding abstract, if the paper does not substantially
correspond to the approved abstract.
The paper must be presented at EuroPython by one or more of the
authors. Presentation time will be between half an hour and an hour,
including time for questions and answers, depending on each paper's
details, and also on the total number of talks approved for
We will publish the conference's proceedings in purely electronic
form. By presenting a paper, authors agree to give the EuroPython
conference non-exclusive rights to publish the paper in electronic forms
(including, but not limited to, partial and total publication on web
sites and/or such media as CDROM and DVD-ROM), and warrant that the
papers are not infringing on the rights of any third parties. Authors
retain all other intellectual property rights on their submitted
abstracts and papers excepting only this non-exclusive license.
We have funds available to subsidise travel costs for some presenters
who would otherwise not be able to attend EuroPython. When submitting
your abstract, please indicate if you would need such a subsidy as a
precondition of being able to come and present your paper. (Yes, this
possibility does exist even if you are coming from outside of
Europe. Papers from people in New Zealand who can only come if their
travel is subsidised, for example, would be just fine with us...).