On 07/30/11 17:00, benjamin.peterson wrote:
> changeset: 71637:402f94edf11b
> branch: 2.7
> user: Benjamin Peterson <benjamin(a)python.org>
> date: Sat Jul 30 09:59:12 2011 -0500
> note Ellipsis syntax
> Doc/library/stdtypes.rst | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> diff --git a/Doc/library/stdtypes.rst b/Doc/library/stdtypes.rst
> --- a/Doc/library/stdtypes.rst
> +++ b/Doc/library/stdtypes.rst
> @@ -2930,7 +2930,7 @@
> supports no special operations. There is exactly one ellipsis object, named
> :const:`Ellipsis` (a built-in name).
> -It is written as ``Ellipsis``.
> +It is written as ``Ellipsis`` or ``...``.
In 2.7, this is not true; ``...`` only works in slices there.
(note: i'm not a python dev subscriber so please make sure you CC
me with any advice and i'm hoping this desperate plea for assistance
is at least enough on-point for this list that someone can help me
out. and, yes, this is rather verbose but i wanted to supply all of
the relevant details in one shot.)
i asked about this on the general python help list but i suspect
it's more appropriate to ask developers about this and i'm hoping
someone can clear this up for me.
i'm building an embedded system using wind river linux 4.2 (WRL
4.2), and part of that build process involves downloading, patching
and compiling python 2.6.2 for the eventual target filesystem. this
is all being done on my 64-bit ubuntu 11.04 system and, to keep things
simple, i'm not even cross-compiling, i've selected a common 64-bit PC
as the target, so i should be able to ignore any cross compile-related
glitches i might have had.
this build process works just fine for everyone else on the planet
but it fails for me because i'm doing something apparently no one else
has tried -- i'm running a (hand-rolled) linux 3.x kernel on my build
host and it *seems* that that's what's messing up the python
compilation somewhere in the WRL build scripts. (as a side note, i
have run across other issues in the WRL build system where it was
simply never imagined that one might want to build on a system running
a 3.x kernel, so that's why i'm suspecting it has something to do with
that. apparently, i'm out there on the bleeding edge and this is what
might be causing me grief.)
the symptom seems to be that there is confusion in the python build
process between two directories: "plat-linux2" and "plat-linux3". my
first simple question would be: what do those names represent and how
should they appear in the build process?
as a benchmark, i downloaded an *absolutely stock* Python-2.6.2
tarball, untarred it, ran "./configure", then searched for any
references to those strings just so i could have a basis for
comparison. so, immediately after the configure, here's what i found
for the stock 2.6.2 python tarball:
$ find . -name "plat-linux*"
$ grep -r plat-linux *
Doc/install/index.rst: ['', '/usr/local/lib/python2.3',
Misc/HISTORY: * Lib/plat-sunos5/CDIO.py, Lib/plat-linux2/CDROM.py:
Misc/HISTORY:e.g. lib-tk, lib-stdwin, plat-win, plat-linux2,
so, before the build, there are a few references to plat-linux2 and
*none* to plat-linux3. i then ran "make" (which seemed to work just
fine) and here's the result of a similar search after the make:
$ find . -name "plat-linux*"
so that's still the same after the build, there is no plat-linux3
file or directory that's been created. however, if i do a recursive
$ grep -r plat-linux3 *
Binary file libpython2.6.a matches
Binary file Modules/getpath.o matches
Binary file python matches
then it's clear that the string "plat-linux3" is now embedded in a
small number of the build results. so what does that string
represent? why is it there and what does "2" mean compared to "3" in
this context? and, most importantly, even though it's there, it
didn't stop the build from completing.
now take a look at the tail end of the output of the WRL build of
python, where things go wrong (what is clearly a packaging step so i'm
well aware that this is somewhat outside the scope of normal python
===== begin output =====
... snip ...
Checking for unpackaged file(s): /home/rpjday/WindRiver/projects/42/python/host-cross/bin/../lib64/rpm/check-files /home/rpjday/WindRiver/projects/42/python/build/INSTALL_STAGE/python-2.6.2
error: Installed (but unpackaged) file(s) found:
RPM build errors:
File not found: /home/rpjday/WindRiver/projects/42/python/build/INSTALL_STAGE/python-2.6.2/usr/lib64/python2.6/plat-linux2
Installed (but unpackaged) file(s) found:
/home/rpjday/WindRiver/projects/42/python/scripts/packages.mk:2661: *** [python.install] Error 1
/home/rpjday/WindRiver/projects/42/python/scripts/packages.mk:3017: *** [python.buildlogger] Error 2
/home/rpjday/WindRiver/projects/42/python/scripts/packages.mk:3225: *** [python.build] Error 2
make: *** [python] Error 2
make: Leaving directory `/home/rpjday/WindRiver/projects/42/python/build'
===== end output =====
note the obvious reference to this "plat-linux3" directory that
appears out of nowhere that never existed in the stock build. and if
i wander down to the WRL python build directory:
$ find . -name plat-linux*
$ find Lib/plat-linux
and this is as far as i got before confusion set in. it seems that
the WRL build process is getting confused about which of those two
values to use for the build and ends up scattering generated artifacts
across both directories, at which point the packaging step gets
confused and gives up.
if anyone can clarify what might be going on here and what *should*
be happening, i'd be grateful. i realize i'm asking for remote
diagnosis on a proprietary build system, i'm just wondering what a
native python build *should* look like and what it should produce.
thanks muchly for any guidance.
Robert P. J. Day Ottawa, Ontario, CANADA
Am 04.08.2011 05:25, schrieb solipsis(a)pitrou.net:
> results for 65c412586901 on branch "default"
> Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R',
> '3:3:/home/antoine/cpython/refleaks/reflogso7nu3', '-x']
Do we need this mail even if there are no leaks to report?
My apologies for posting here first, but I'm not yet confident enough in
my bug searching fu, and duplicates are a pain.
Here's the issue:
from unittest import *
self.assertEqual(1,(2-1),"Sample Subraction Test")
if __name__ == '__main__':
I know this isn't the normal way to use unittest, but since __init__
goes to the trouble of defining __all__ I would think it was supported.
However, it doesn't work -- I added some print statements to show
where the problem lies (in unittest.loader.TestLoader.loadTestsFromModule):
checking <class 'unittest.case.FunctionTestCase'>
checking <class '__main__.MyTest'>
checking <class 'unittest.case.SkipTest'>
checking <class 'unittest.case.TestCase'>
checking <class 'unittest.loader.TestLoader'>
checking <class 'unittest.result.TestResult'>
checking <class 'unittest.suite.TestSuite'>
checking <class 'unittest.runner.TextTestResult'>
checking <class 'unittest.runner.TextTestRunner'>
checking <module 'builtins' (built-in)>
checking <unittest.loader.TestLoader object at 0x00C92BF0>
checking <function expectedFailure at 0x00C7D930>
checking <function findTestCases at 0x00C8CA50>
checking <function getTestCaseNames at 0x00C8C9C0>
checking <function installHandler at 0x00C97A08>
checking <class 'unittest.main.TestProgram'>
checking <function makeSuite at 0x00C8CA08>
checking <function registerResult at 0x00C97978>
checking <function removeHandler at 0x00C97A50>
checking <function removeResult at 0x00C979C0>
checking <function skip at 0x00C7D858>
checking <function skipIf at 0x00C7D8A0>
checking <function skipUnless at 0x00C7D8E8>
MyTest testMethod=test_add>]>, <unittest.suite.TestSuite tests=>]>
compared with running using the `import unittest` method:
checking <class '__main__.MyTest'>
checking <module 'builtins' (built-in)>
checking <module 'unittest' from 'C:\python32\lib\unittest\__init__.py'>
As you can see, the TestLoader is getting false positives from
case.FunctionTestCase and case.TestCase. This a problem because,
besides running more tests than it should, this happens:
Traceback (most recent call last):
File "test_add.py", line 8, in <module>
File "C:\python32\lib\unittest\main.py", line 125, in __init__
File "C:\python32\lib\unittest\main.py", line 271, in runTests
self.result = testRunner.run(self.test)
File "C:\python32\lib\unittest\runner.py", line 175, in run
File "C:\python32\lib\unittest\runner.py", line 109, in printErrors
File "C:\python32\lib\unittest\runner.py", line 115, in printErrorList
self.stream.writeln("%s: %s" % (flavour,self.getDescription(test)))
File "C:\python32\lib\unittest\runner.py", line 47, in getDescription
return '\n'.join((str(test), doc_first_line))
File "C:\python32\lib\unittest\case.py", line 1246, in __str__
AttributeError: 'str' object has no attribute '__name__'
I'll be happy to file a bug report if someone can confirm this hasn't
already been filed.
Thanks for the help!
No, that's not my code. ;)
On Tue, 02 Aug 2011 12:33:55 +0200
senthil.kumaran <python-checkins(a)python.org> wrote:
> raise TypeError("data should be a bytes-like object\
> - or an iterable, got %r " % type(it))
> + or an iterable, got %r " % type(data))
There are still a lot of spaces in your message. You should use string
literal concatenation instead:
"data should be a bytes-like object "
"or an iterable, got %r"
Speaking of developers.rst, could whoever added Jason Coombs also update
developers.rst? I've added Jason to the committers mailing list.
-------- Original Message --------
Subject: [Python-checkins] devguide: Add Sandro to the list of core
Date: Tue, 02 Aug 2011 14:58:38 +0200
From: antoine.pitrou <python-checkins(a)python.org>
user: Antoine Pitrou <solipsis(a)pitrou.net>
date: Tue Aug 02 14:56:56 2011 +0200
Add Sandro to the list of core developers
developers.rst | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/developers.rst b/developers.rst
@@ -24,6 +24,10 @@
+- Sandro Tosi was given push privileges on Aug 1 2011 by Antoine Pitrou,
+ for documentation and other contributions, on recommendation by Ezio
+ Melotti, R. David Murray and others.
- Charles-François Natali was given push privileges on May 19 2011 by
Pitrou, for general contributions, on recommandation by Victor Stinner,
Brian Curtin and others.
Repository URL: http://hg.python.org/devguide