> changeset: 69112:2cb07a46f4b5
> user: Antoine Pitrou <solipsis(a)pitrou.net>
> date: Sun Apr 03 17:05:46 2011 +0200
> Issue #5863: Rewrite BZ2File in pure Python, and allow it to accept
> file-like objects using a new `fileobj` constructor argument. Patch by
> Nadeem Vawda.
> Doc/ACKS.txt | 1 +
I think we use Misc/ACKS for code+docs contribution like this one,
Doc/ACKS.txt being used for doc-only changes. This second file is not
comprehensive nor always used though, so maybe it should be superseded
by the former.
> Doc/library/bz2.rst | 221 +-
> Lib/bz2.py | 392 +++++
> Lib/test/test_bz2.py | 142 +-
> Misc/NEWS | 4 +
> Modules/bz2module.c | 2281 ++++-------------------------
> PCbuild/bz2.vcproj | 4 +-
> PCbuild/pcbuild.sln | 2 +-
> PCbuild/readme.txt | 6 +-
> setup.py | 4 +-
The tracker was recently changed so that when I click on a link to a
tracker page, the page is properly displayed, but then a fraction of a
second it blinks and redisplays with the edit form hidden. This is so
obnoxious to me that I no longer want to visit the tracker. Then I have
to find and click the button to get back the edit form that I nearly
always want to see, as I often make changes. All this to compress the
page by half a screen, which makes almost no difference once one grabs
the scrollbar anyway.
If someone actually considers this a desired feature, after using it,
then please add a field on the profile page to select autofolding or
not. Also, there should be a button to fold as well as one to unfold.
Terry Jan Reedy
On Thu, Mar 24, 2011 at 2:41 AM, Victor Stinner
> I am still working on the import machinery to fix last bugs related to
> Unicode. So it will be possible to do an useless "import café" in Python
> 3.3, on any platform. But it is not really an huge change (for the user,
> but an huge change in the code ;-)).
I don't like the idea of reading the code with some kind of Chinese
variable names in them. I'd prefer that I and l confusion will be the
only I should care about in valid Python syntax.
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?
Like you I've used the Path module one time or another. It is an excellent
concept to refactor the confusing collection of file handling methods. I
have not used it consistently, mainly because the module has not been
maintained and it is not in the standard library as it should be.
I have found a proposal on PEP from a while ago. I wonder what is the
status of it?
Are you still actively using Python and the Path module? I have a couple
of ideas that might improve it further. I hope to find enough fans of it
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.