I'm using Python buildbots to ensure that my changes don't fail on
some platform. It's important for changes close to the operation
system. The problem is that many buildbots are ill.
Before, only a few buildbots had sporadic failures. Now most buildbots
are always fail (are red).
Here is an incomplete list of failures seen on buildbots. Before I
opened an issue for each bug, but usually nobody takes care of them.
So today I'm trying the mailing list.
How can we fix all these issues to have more "green" buildbots? Can
anyone help on this task?
AMD64 OpenIndiana 3.x: a lot of tests fail with OSError(12, "Not
enough space") or MemoryError. It's probably on issue on the host.
AMD64 Snow Leop 3.x: many tests are not reliable (stable) on this
platform. For example, test_logging.test_race() sometimes fail with
PermissionError(1, "Operation not permitted:
'/tmp/test_logging-3-bjulw8iz.log'"). Another example,
test_asyncio.test_stdin_broken_pipe() sometimes fail with an assertion
error because BrokenPipeError was not raised. Do we still support this
old version of Mac OS X? Released in 2009, it is 5 years old. Is
upgrading to Maverick (10.9) free and possible on old Mac computers? I
don't have access to this old OS.
x86 RHEL 6 3.x: TestReadline.test_init() fails, issue #19884. I don't
have to this platform, I don't know how to fix it.
x86 Windows Server 2003 [SB] 3.x: test_build_ext() of test_distutils
hangs during 1 hang before being killed, it hangs something in the C
x86 Windows7 3.x: test_nntplib fails with OSError("cannot read from
timed out object").
x86 XP-4 3.x: test_distutils fails because Visual Studio linker
(link.exe) fails with the error 1181 (cannot open input file).
test_capi.test_forced_io_encoding() fails with an assertion error
because sys.__stdin__ is None.
AMD64 Solaris 11 [SB] 3.x: sometimes, tests fail with MemoryError.
test_uuid.test_uuid4() fails with an assertion error. ctypes has issue
with the sign of integer numbers (bug in libffi?).
ARMv7 3.x: "Read-only file system", Mercurial fails...
x86 FreeBSD 7.2 3.x: test_io.test_interrupted_write_text() hangs.
x86 FreeBSD 6.4 3.x: test_urllib2net.test_urlwithfrag() fails with
urllib.error.URLError: <urlopen error unknown url type: https>.
test_tcl has many issues. test_multiprocessing_spawn fails whereas the
test should be skipped.
x86 OpenBSD 5.5 3.x: many failing tests.
x86 OpenIndiana 3.x: MemoryError. TestReadline.test_init() also fails.
x86 Tiger 3.x: test_nntplib fails with OSError("cannot read from timed
I skipped "SPARC Solaris 10 OpenCSW 3.x" and "PPC64 AIX 3.x" in my
list, I'm not really interested by these platforms.
I miss mUTF-7 support (as used to encode IMAP4 mailbox names) in Python,
in the codecs module. As an european with a language with 27 different
letters (instead of english 26), tildes, opening question marks, etc., I
find it very inconvenient.
This encoding is used basically only in IMAP4, I know. But IMAP4 is an
important protocol and all projects related to it needs mUTF-7 support
if they care about non-english alphabets. Everybody has already an
implementation, waste of effort.
We already support quite amusing encodings in
What do you think?. Could be considered for Python 3.5?.
I volunteer for the job, of course.
PS: Do you think a Python implementation would be good enough?. I don't
think this need to be C-fast.
Jesús Cea Avión _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
Twitter: @jcea _/_/ _/_/ _/_/_/_/_/
jabber / xmpp:firstname.lastname@example.org _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNED MESSAGE-----
this question is a bit about general policy which is not yet
covered in the python recommendations:
I see projects which do check-ins like "get rid of shebang lines"
and they remove those lines from non-script sources.
It is not always clear to me what to do, so I tend to leave those
lines in per default, in order not to waste time thinking about it,
but well, today I was confronted with that.
Digging a bit deeper shows the following:
No mention of shebang, but for Windows.
Google's python style guide also says when a shebang is needed, but
does not forbid it.
Pep 394 explains how to use shebang, but still nothing about not using it.
So is there anything officially preferred, and should that go into pep 8?
Special case with pip
I was looking through my installed packages and wondered quite
much about pip:
Pip has a shebang in the __init__ file, but no shebang in the
I guess this is wrong and should be in the executable file,
which is __main__ .
cheers - Chris
Christian Tismer :^) tismer(a)stackless.com
Software Consulting : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : http://www.pydica.net/
14482 Potsdam : GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776 fax +49 (30) 700143-0023
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
-----END PGP SIGNATURE-----
On behalf of the Python development community and the Python 3.4 release
team, I'm pleased to announce the availability of Python 3.4.2. Python
3.4.2 has many bugfixes and other small improvements over 3.4.1. One
new feature for Mac OS X users: the OS X installers are now distributed
as signed installer package files compatible with the OS X Gatekeeper
You can download it here:
May the road rise up to meet you,
My team has a python app that appears to perform 10+% better when the
python source is present v.s. when only the pyc's are distributed. This is
contradictory to my understanding of how python leverages pyc's.
1. pyc-only install sees mediocre performance. (pyc's are built using
compileall.py, then source .py's removed before packaging)
2. adding the .py files to the installed filesystem results in 10+%
3. verified no difference in mod times, no new .pyc's generated
4. remove the .py's and again see drop in performance
Env info: centos 6.5, x86_64, however python used is 32bit from the i686
repos (this is how we deal with some 32bit only c libraries that the app
Has anyone got an idea of what I might be running into? The app itself is
a black box to me. I was not able to isolate this using a simple piece of
python code that worked on a math problem for a discernible amount of time,
so it could be something to do with how the app is using python. The app
was originally written for python 2.4...
Any suggestions on what I can try is appreciated.
Over the past while we've been cleaning up the docs in the area of "how
do we refer to bytes, bytearray, memoryview, etc, etc?" in the APIs that
deal with bytes. As you may or may not remember, we settled on the term
'bytes-like object', and have changed the docs to (we hope) consistently
use this term, which has a glossary entry most of the references to it
I just committed (to 3.5) the final changes for issue 16518, the change
to consistently using the term 'bytes-like object' for things that
support the buffer interface. This means that messages that previously
'sometype' does not support the buffer interface
a bytes-like object is required, not 'sometype'
The 'buffer interface' messages were rather confusing, since you have to
dig to find out what the 'buffer interface' is. It isn't any sort of
python object, nor is there any object in python3 that has a name
related to it. 'bytes-like object', on the other hand, is fairly
intuitive[*], and if you look it up in the glossary it links to the
explanation of the buffer interface.
We felt it was worth explicitly mentioning this patch on python-dev to point
out to everyone that the docs and error messages now use a consistent
terminology, instead of the mis-mash we had before, which should make it easier
to help people with issues where this comes up.
If there are objections to this change to the messages it is easy enough to
back out, but personally I find the new error messages *much* clearer, and I'm
an experienced dev.
(This work was done by Ezio Melotti, but I committed the final patch as
part of my quest to clear the 'commit review' queue in the tracker.)
[*] the more esoteric cases are not often encountered in regular (as opposed to
NumPy) code, and when they are, the extension to "something that can be
interpreted as a sequence of bytes" is pretty straightforward conceptually.
With the incredibly long life span of 2.7, which bugs should we *not* fix?
For example, in http://bugs.python.org/issue22297 I mentioned one reason to not fix that bug was that the fix was not in
3.1-3.3, but 2.7 will outlive all those plus a couple more.
So, what are the current guidelines on what to fix? Is it still security only, with the rest being carrots for switching?