[Python-Dev] what is the significance of "plat-linux2" in the python build process?
(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*"
./Lib/plat-linux2
$
$ grep -r plat-linux *
Doc/install/index.rst: ['', '/usr/local/lib/python2.3',
'/usr/local/lib/python2.3/plat-linux2',
Doc/install/index.rst:'/www/python/lib/pythonX.Y/plat-linux2', ...]``.
Misc/RPM/python-2.6.spec:%{__prefix}/%{libdirname}/python%{libvers}/plat-linux2
Misc/HISTORY: * Lib/plat-sunos5/CDIO.py, Lib/plat-linux2/CDROM.py:
Misc/HISTORY:e.g. lib-tk, lib-stdwin, plat-win, plat-linux2,
plat-sunos5, dos-8x3.
$
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*"
./Lib/plat-linux2
$
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:
$ 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
building):
= 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:
/usr/lib64/python2.6/plat-linux3/IN.py
/usr/lib64/python2.6/plat-linux3/IN.pyc
/usr/lib64/python2.6/plat-linux3/IN.pyo
/usr/lib64/python2.6/plat-linux3/regen
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:
/usr/lib64/python2.6/plat-linux3/IN.py
/usr/lib64/python2.6/plat-linux3/IN.pyc
/usr/lib64/python2.6/plat-linux3/IN.pyo
/usr/lib64/python2.6/plat-linux3/regen
/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 stoc
Re: [Python-Dev] what is the significance of "plat-linux2" in the python build process?
On Fri, 5 Aug 2011 09:01:01 -0400 (EDT) "Robert P. J. Day" wrote: > > 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.) You could take a look at http://bugs.python.org/issue12326 The current 2.7 branch should work for you, you'll have to get it from the Mercurial repository. That says, the plat-* stuff is quite useless as it is. There's a patch here to improve its usefulness slightly: http://bugs.python.org/issue12619 Although I would question the existence of such undocumented modules, which are hardly even used internally. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-07-29 - 2011-08-05) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2899 (+10) closed 21579 (+32) total 24478 (+42) Open issues with patches: 1255 Issues opened (27) == #1813: Codec lookup failing under turkish locale http://bugs.python.org/issue1813 reopened by skrah #9723: Add shlex.quote http://bugs.python.org/issue9723 reopened by eric.araujo #12656: test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets http://bugs.python.org/issue12656 opened by neologix #12657: Cannot override JSON encoding of basic type subclasses http://bugs.python.org/issue12657 opened by barry #12659: Add tests for packaging.tests.support http://bugs.python.org/issue12659 opened by eric.araujo #12660: test_gdb fails when installed http://bugs.python.org/issue12660 opened by pitrou #12661: Add a new shutil.cleartree function to shutil module http://bugs.python.org/issue12661 opened by chin #12662: Allow configparser to process suplicate options http://bugs.python.org/issue12662 opened by ojab #12666: map semantic change not documented in What's New http://bugs.python.org/issue12666 opened by jason.coombs #12668: 3.2 What's New: it's integer->string, not the opposite http://bugs.python.org/issue12668 opened by sandro.tosi #12669: test_curses skipped on buildbots http://bugs.python.org/issue12669 opened by nadeem.vawda #12672: Some problems in documentation extending/newtypes.html http://bugs.python.org/issue12672 opened by eli.bendersky #12675: tokenize module happily tokenizes code with syntax errors http://bugs.python.org/issue12675 opened by Gareth.Rees #12677: Turtle, fix right/left rotation orientation http://bugs.python.org/issue12677 opened by sandro.tosi #12678: test_packaging and test_distutils failures under Windows http://bugs.python.org/issue12678 opened by pitrou #12680: cPickle.loads is not thread safe due to non-thread-safe import http://bugs.python.org/issue12680 opened by Sagiv.Malihi #12681: unittest expectedFailure could take a message argument like sk http://bugs.python.org/issue12681 opened by r.david.murray #12682: Meaning of 'accepted' resolution as documented in devguide http://bugs.python.org/issue12682 opened by r.david.murray #12684: profile does not dump stats on exception like cProfile does http://bugs.python.org/issue12684 opened by anacrolix #12686: argparse - document (and improve?) use of SUPPRESS with help= http://bugs.python.org/issue12686 opened by derks #12687: Python 3.2 fails to load protocol 0 pickle http://bugs.python.org/issue12687 opened by vinay.sajip #12690: Tix bug 2643483 http://bugs.python.org/issue12690 opened by Gary.Levin #12691: tokenize.untokenize is broken http://bugs.python.org/issue12691 opened by Gareth.Rees #12692: test_urllib2net is triggering a ResourceWarning http://bugs.python.org/issue12692 opened by brett.cannon #12693: test.support.transient_internet prints to stderr when verbose http://bugs.python.org/issue12693 opened by brett.cannon #12694: crlf.py script from Tools doesn't work with Python 3.2 http://bugs.python.org/issue12694 opened by bialix #12696: pydoc error page due to lacking permissions on ./* http://bugs.python.org/issue12696 opened by gagern Most recent 15 issues with no replies (15) == #12696: pydoc error page due to lacking permissions on ./* http://bugs.python.org/issue12696 #12694: crlf.py script from Tools doesn't work with Python 3.2 http://bugs.python.org/issue12694 #12684: profile does not dump stats on exception like cProfile does http://bugs.python.org/issue12684 #12672: Some problems in documentation extending/newtypes.html http://bugs.python.org/issue12672 #12668: 3.2 What's New: it's integer->string, not the opposite http://bugs.python.org/issue12668 #12662: Allow configparser to process suplicate options http://bugs.python.org/issue12662 #12660: test_gdb fails when installed http://bugs.python.org/issue12660 #12659: Add tests for packaging.tests.support http://bugs.python.org/issue12659 #12657: Cannot override JSON encoding of basic type subclasses http://bugs.python.org/issue12657 #12656: test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets http://bugs.python.org/issue12656 #12653: Provide accelerators for all buttons in Windows installers http://bugs.python.org/issue12653 #12645: test.support. import_fresh_module - incorrect doc http://bugs.python.org/issue12645 #12639: msilib Directory.start_component() fails if keyfile is not Non http://bugs.python.org/issue12639 #12623: "universal newlines" subprocess support broken with select- an http://bugs.python.org/issue12623 #12622: failfast argument to TextTestRunner not documented http://bugs.python.org/issue12622 Most recent 15 issues waiting for review (15) ==
Re: [Python-Dev] cpython (2.7): note Ellipsis syntax
On 31/07/2011 07:47, Raymond Hettinger wrote: It's really nice for stub functions: def foo(x): ... I guess pass is too pass-é? ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: #11572: improvements to copy module tests along with removal of old test suite
Why was the old test suite removed?
Even if everything is covered by the test file (and that isn't clear
from this checkin), I don't see anything wrong with a quick test that
doesn't require loading the whole testing apparatus. (I would have no
objection to including a comment saying that the majority of the tests
are in the test file; I just wonder why they have to be removed
entirely.)
On Fri, Aug 5, 2011 at 5:06 PM, sandro.tosi wrote:
> http://hg.python.org/cpython/rev/74e79b2c114a
> changeset: 71749:74e79b2c114a
> user: Sandro Tosi
> date: Fri Aug 05 23:05:35 2011 +0200
> summary:
> #11572: improvements to copy module tests along with removal of old test
> suite
>
> files:
> Lib/copy.py | 65 ---
> Lib/test/test_copy.py | 168 -
> 2 files changed, 95 insertions(+), 138 deletions(-)
>
>
> diff --git a/Lib/copy.py b/Lib/copy.py
> --- a/Lib/copy.py
> +++ b/Lib/copy.py
> @@ -323,68 +323,3 @@
> # Helper for instance creation without calling __init__
> class _EmptyClass:
> pass
> -
> -def _test():
> - l = [None, 1, 2, 3.14, 'xyzzy', (1, 2), [3.14, 'abc'],
> - {'abc': 'ABC'}, (), [], {}]
> - l1 = copy(l)
> - print(l1==l)
> - l1 = map(copy, l)
> - print(l1==l)
> - l1 = deepcopy(l)
> - print(l1==l)
> - class C:
> - def __init__(self, arg=None):
> - self.a = 1
> - self.arg = arg
> - if __name__ == '__main__':
> - import sys
> - file = sys.argv[0]
> - else:
> - file = __file__
> - self.fp = open(file)
> - self.fp.close()
> - def __getstate__(self):
> - return {'a': self.a, 'arg': self.arg}
> - def __setstate__(self, state):
> - for key, value in state.items():
> - setattr(self, key, value)
> - def __deepcopy__(self, memo=None):
> - new = self.__class__(deepcopy(self.arg, memo))
> - new.a = self.a
> - return new
> - c = C('argument sketch')
> - l.append(c)
> - l2 = copy(l)
> - print(l == l2)
> - print(l)
> - print(l2)
> - l2 = deepcopy(l)
> - print(l == l2)
> - print(l)
> - print(l2)
> - l.append({l[1]: l, 'xyz': l[2]})
> - l3 = copy(l)
> - import reprlib
> - print(map(reprlib.repr, l))
> - print(map(reprlib.repr, l1))
> - print(map(reprlib.repr, l2))
> - print(map(reprlib.repr, l3))
> - l3 = deepcopy(l)
> - print(map(reprlib.repr, l))
> - print(map(reprlib.repr, l1))
> - print(map(reprlib.repr, l2))
> - print(map(reprlib.repr, l3))
> - class odict(dict):
> - def __init__(self, d = {}):
> - self.a = 99
> - dict.__init__(self, d)
> - def __setitem__(self, k, i):
> - dict.__setitem__(self, k, i)
> - self.a
> - o = odict({"A" : "B"})
> - x = deepcopy(o)
> - print(o, x)
> -
> -if __name__ == '__main__':
> - _test()
> diff --git a/Lib/test/test_copy.py b/Lib/test/test_copy.py
> --- a/Lib/test/test_copy.py
> +++ b/Lib/test/test_copy.py
> @@ -17,7 +17,7 @@
> # Attempt full line coverage of copy.py from top to bottom
>
> def test_exceptions(self):
> - self.assertTrue(copy.Error is copy.error)
> + self.assertIs(copy.Error, copy.error)
> self.assertTrue(issubclass(copy.Error, Exception))
>
> # The copy() method
> @@ -54,20 +54,26 @@
> def test_copy_reduce_ex(self):
> class C(object):
> def __reduce_ex__(self, proto):
> + c.append(1)
> return ""
> def __reduce__(self):
> - raise support.TestFailed("shouldn't call this")
> + self.fail("shouldn't call this")
> + c = []
> x = C()
> y = copy.copy(x)
> - self.assertTrue(y is x)
> + self.assertIs(y, x)
> + self.assertEqual(c, [1])
>
> def test_copy_reduce(self):
> class C(object):
> def __reduce__(self):
> + c.append(1)
> return ""
> + c = []
> x = C()
> y = copy.copy(x)
> - self.assertTrue(y is x)
> + self.assertIs(y, x)
> + self.assertEqual(c, [1])
>
> def test_copy_cant(self):
> class C(object):
> @@ -91,7 +97,7 @@
> "hello", "hello\u1234", f.__code__,
> NewStyle, range(10), Classic, max]
> for x in tests:
> - self.assertTrue(copy.copy(x) is x, repr(x))
> + self.assertIs(copy.copy(x), x)
>
> def test_copy_list(self):
> x = [1, 2, 3]
> @@ -185,9 +191,9 @@
> x = [x, x]
> y = copy.deepcopy(x)
> self.assertEqual(y, x)
> - self.assertTrue(y is not x)
> - self.assertTrue(y[0] is not x[0])
> - self.assertTrue(y[0] is y[1])
> + self.assertIsNot(y, x)
> + self.assertIsNot(y[0], x[0])
> + self.assertIs(y[0], y[1])
>
>
Re: [Python-Dev] [Python-checkins] cpython: #11572: improvements to copy module tests along with removal of old test suite
Hi Jim, On Fri, Aug 5, 2011 at 23:55, Jim Jewett wrote: > Why was the old test suite removed? > > Even if everything is covered by the test file (and that isn't clear > from this checkin), I don't see anything wrong with a quick test that > doesn't require loading the whole testing apparatus. (I would have no > objection to including a comment saying that the majority of the tests > are in the test file; I just wonder why they have to be removed > entirely.) I see these reasons mainly: - it adds nothing to the stdlib (where it was included): they are tests, so they should be in the test suite - it's unmaintained, since all the work on new tests or any change will happen on the test_copy.py file and not in the copy.py (that's true for any other module) - and also running the tests for a single modules is just a (in this case, I keep using copy: ./python -m test test_copy and it has the advantage of running the whole test suite for that module, not just some random code. I plan to do other changes like this in the next days/weeks, so actually thanks for the question :) since it bring that up to python-dev we others can comment. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: #11572: improvements to copy module tests along with removal of old test suite
On Fri, 5 Aug 2011 17:55:33 -0400 Jim Jewett wrote: > Why was the old test suite removed? > > Even if everything is covered by the test file (and that isn't clear > from this checkin), I don't see anything wrong with a quick test that > doesn't require loading the whole testing apparatus. (I would have no > objection to including a comment saying that the majority of the tests > are in the test file; I just wonder why they have to be removed > entirely.) Nobody ever runs such tests when they are not part of the official regression test suite, which makes them barely useful. Looking at them, they don't seem very advanced and are probably covered by test_copy already. The only reason to have special code in the __main__ section of stdlib modules is when it provides some (interactive) service to the user (for example, "python -m zipfile" will give you a trivial equivalent of the zip/unzip commands). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
