Mailman 3 July 2015 - Python-Dev

How far to go with user-friendliness
by Dima Tisnek July 22, 2015

July 22, 2015

https://bugs.python.org/issue21238 introduces detection of missing/misspelt mock.assert_xxx() calls on getattr level in Python 3.5 Michael and Kushal are of the opinion that "assret" is a common typo of "assert" and should be supported in a sense that it also triggers AttributeError and is not silently ignored like a mocked user attribute. I disagree Google search for "assret" site:github.com yields 9 hits in total, of which: 1 (cliques.c) is a variable with intended spelling; 1 issue with a … [View More]

36 103

Python 3.4.3 on RedHat 6.6 s390x make fails with: make: *** [sharedmods] Error 139
by Vitale, Joseph July 22, 2015

July 22, 2015

Hello, Trying to install Python 3.4.3 on Red Hat 6.6 zLinux(s390x) but "make" fails and core dumps. Not using OpenSSL and did not configure for it. Can you provide direction? ./configure make gcc -pthread -fPIC -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I/usr/local/ssl/include -I./Include -I. -IInclude -I/usr/local/include -I/xjp/Python-3.4.3/Include -I/xjp/Python-3.4.3 -c /xjp/Python-3.4.3/Modules/_ssl.c -o build/temp.linux-s390x-… [View More]

3 2

GetFinalPathNameByHandleW - what is the minimum windows version python-3.5 will support ?
by Vitaly Murashev July 19, 2015

July 19, 2015

I've just found out that that on Windows internal implementation of python35.dll in posixmodule.c uses winapi function GetFinalPathNameByHandleW By the way from MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/aa364962%28v=vs.85… Minimum supported client Windows Vista [desktop apps only] Minimum supported server Windows Server 2008 [desktop apps only] Does it mean, that Python-3.5 doesn't support any windows versions prior "Windows Vista" and "Windows Server 2008"… [View More]

4 3

Re: [Python-Dev] cpython: Tighten-up code in the set iterator to use an entry pointer rather than
by Serhiy Storchaka July 18, 2015

July 18, 2015

On 07.07.15 05:03, raymond.hettinger wrote: > https://hg.python.org/cpython/rev/c9782a9ac031 > changeset: 96865:c9782a9ac031 > user: Raymond Hettinger <python(a)rcn.com> > date: Mon Jul 06 19:03:01 2015 -0700 > summary: > Tighten-up code in the set iterator to use an entry pointer rather than indexing. > > files: > Objects/setobject.c | 35 ++++++++++++-------------------- > 1 files changed, 13 insertions(+), 22 deletions(-) > > … [View More]

12 24

Summary of Python tracker Issues
by Python tracker July 17, 2015

July 17, 2015

ACTIVITY SUMMARY (2015-07-10 - 2015-07-17) 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: open 4947 (+19) closed 31468 (+29) total 36415 (+48) Open issues with patches: 2260 Issues opened (31) ================== #24612: not operator expression raising a syntax error http://bugs.python.org/issue24612 opened by candide #24613: array.fromstring Use After … [View More]

1 0

documentation / implementation question for subprocess.check_output
by Chris Withers July 17, 2015

July 17, 2015

Hi All, Curious to see this in the docs for subprocess.check_output: "Do not use stderr=PIPE with this function as that can deadlock based on the child process error volume. Use Popen with the communicate() method when you need a stderr pipe." Given that check_output's implementation uses communicate(), how could stderr=PIPE cause a deadlock in a way that wouldn't happen if you called Popen.communicate() yourself? cheers, Chris

3 3

Where are bugs with the web site reported?
by Ryan Gonzalez July 16, 2015

July 16, 2015

I have encountered this weird issue on Chrome for Android where scrolling up just a little causes the page to dart to the top. I was going to report it in the bug tracker, but I didn't see a label for the web site itself. Worst part is, this is stopping me from reading the humor page! -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

6 6

cpython: locals dictionary in PyRun_String
by Matthew Keeter July 15, 2015

July 15, 2015

The docs for PyRun_String say that both globals and locals should be dictionaries [1]. However, digging into the source [2] shows me that locals doesn’t need to be a dictionary; it just needs to implement the mapping protocol. Is it a bad idea to rely on this fact? (Context: I’m plugging a custom object into locals that uses __getitem__ to track lookups.) Thanks, Matt [1] https://docs.python.org/3.4/c-api/veryhigh.html#c.PyRun_StringFlags [2] https://github.com/python/cpython/blob/master/Objects/frameobject.c#L628-L6…

3 3

Cross compiling C-python 2.7.10 maintenance release for ARM on 64 bit x86_64 systems.
by Andrew Robinson July 14, 2015

July 14, 2015

Hi. I'm trying to cross compile C-python 2.7.10 for an embedded system. (Eg: a Kobo reader). But there appears to be some bugs that do not allow the latest maintenance release of Python to correctly cross compile on an x86-64 build system, for a 32 bit arm system. I have researched the problem, and there are apparently two different bugs; 1'st -- the Makefile doesn't disable PYTHONPATH for the arm libraries, and the x86 64 bit platform will attempt to link to the arm libraries during the … [View More]compile process producing an wrong elf class error. I found some online examples of cross compiling older versions of python which suggest adding a '-' before "PYTHONPATH' to prevent that from happening. When I do that, it does compile -- but: 2'nd -- If I build python 2.7.10 with the above change, and with no debugging information or switches; it builds fine, but the resulting binary segfaults randomly on the Kobo reader, and will not import libraries without segfaulting. If I build it with all available debugging information (-g3 -ggdb -gdwarf 4), the random segfaulting stops -- and instead, python raises an exception any time I attempt to import a library. ----------------------------------------------------------------------- Python 2.7.10 (default, Jun 29 2015, 23:00:31) [GCC 4.8.1 20130401 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /mnt/user/lib/python2.7/lib-dynload/math.so: undefined symbol: Py_InitModule4 [40857 refs] >>> ------------------------------------------------------------------------- The symbol is indeed missing when I check with nm, and from what little information I can find online -- this appears to have something to do with a 32 bit vs. 64 bit incompatibility; eg: even though it's compiling for 32 bits ARM -- it still seems to be trying to use symbols associated with 64 bit processing. I attempted to compile a 32 bit python interpreter on the build system, to make PYTHON_FOR_BUILD, and PGEN_FOR_BUILD ; but it didn't rectify the problem. What is the proper way to cross compile 2.7.10 for 32 bit arm, on a x86_64 bit platform / what am I doing wrong ? -------------------------------------------------------------------------------------- Supplimentary information: I'm using the linaro-gcc compiler from the kobolabs git repository, () eg: an arm-linux-gnueabihf-gcc on a 64 bit Slackware 14.1 machine with multilib x86 gcc available on the build system. I have a separate 8GB partition with the Kobo kernel source code, stdlibs, etc. all installed from the github source and compiled to a target directory stored in an environment variable called ${DEVICEROOT} ; All files found on the KOBO reader are located under ${DEVICEROOT} on the BUILD machine, and the arm GCC processor uses -I ${DEVICEROOT}/usr/include and other appropriate paths so that GCC finds them naturally. The following bash script shows the steps I used to compile Python with -- and it is followed by another bash script which sets up the compile environment variables, so you can see how the compiler environment is configured. I have no problem compiling C source code in general using the Kobo compiler tools, and have compiled gnuplot, and bash, and several other packages with absolutely no problems. It is only python which is not compiling correctly. ---------------------------------------------------------------------------------------------------------------------------------------------- set -x # A parser generator and build system version of python are supposed to be # needed to run parts of the cross compilation; I do see python used in the # Makefile, but no references to a buid version of PGEN are defined, # so I don't know if PGEN gets used or not -- but I build it anyway... # As this is what receipies on the web say to do... make distclean ( . /etc/profile.d/32dev.sh export LIBDIRSUFFIX="" ./configure # --build=x86_64-unknown-linux-gnu --host=i486-unknown-linux-gnu #(uncomment to build 32bit) make Parser/pgen python mv python python_for_build mv Parser/pgen Parser/pgen_for_build make distclean ) # fix setup.py to handle installing to the target system's fake install # directory found on the build system at $DEVICEROOT. # We want utf-8, unicode terminal handling -- so make sure python compiles # with ncursesw substituted for curses. CURSESFLAGS=`pkg-config --cflags ncursesw` # Configure python to be built CFLAGS="${CFLAGS} ${CURSESFLAGS} -g3 -ggdb -gdwarf-4" ./configure --host=${CROSSTARGET} --build=i486-unknown-linux-gnu --enable-unicode --enable-shared --with-pydebug --prefix=/mnt/user --disable-ipv6 --without-pymalloc ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no ac_cv_have_long_long_format=yes PYTHON_FOR_BUILD=${PWD}/python_for_build PGEN_FOR_BUILD=${PWD}/Parser/pgen_for_build # Fix a bug in the Makefile # The build version of python, ought not try to actually use the ARM libraries. sed -i -e 's%$[[:space:]]$$PYTHONPATH=$(DESTDIR)$(LIBDEST)$%\1-\2%' Makefile echo "background the process now to Fix the makefile manually if you can" sleep 10 make PYTHON_FOR_BUILD=${PWD}/python_for_build CROSS_COMPILE_TARGET=yes echo " Waiting to allow you to see error messages before installing " sleep 10 # Optionally, binary file stripping could be carried out on the python binary # Don't strip if you are doing debugging of python # strip --strip-unneeded python make install DESTDIR=${DEVICEROOT} PYTHON_FOR_BUILD=${PWD}/python_for_build PGEN_FOR_BUILD=${PWD}/Parser/pgen_for_build ---------------------------------------------------------------------------------------------------------------- ###### A bash file used to set up gcc paths for cross compiling on the kobo follows a (-----). # There are two compilers in the KOBO git repository: # https://github.com/kobolabs/Kobo-Reader/tree/master/toolchain # a linaro-gcc, and code-sourcery-gcc. The code sourcery gcc does not have the standard C libraries and # perhaps does not use hardware floats, or have those startup files, and is strictly for compiling the linux kernel. # Only the linaro compiler is needed to compile Python. # The linaro compiler is invoked by using ${CROSSTARGET} as a prefix, while the kernel compiler is invoked # using ${CROSS_COMPILE} # eg: use arm-linux-gnueabihf-gcc for linaro vs. arm-none-linux-gnueabi-gcc for code sourcercy (kernel compiler). # # All tools are installed on a partition or thumb drive, with the following bash script located at THUMBDRIVEPATH/.local/bin and the path added to my user PATH. # The script will auto locate the gcc tools relative to its' own install directory, so THUMBDRIVE path can be changed without needing to re-editing the script. # I installed the linaro compiler, path relative, at: # THUMBDRIVEPATH/.local/gcc-linaro-arm-linux-gnueabihg-4.8-2013.04-20130417_linux/ ... etc. ---------------------------------------------------------------------------------------------------------------- #!/bin/bash --init-file # this file is: use_kobo echo "Starting subshell with KOBO/ARM linaro gcc and Sourcery_G++_Lite in the path" set -e path=`whereis -b use_kobo` name="${path%%:*}" path="${path##* /}" path="/${path%%/${name}}" export SOURCERYDIR=${path}/../CodeSourcery/Sourcery_G++_Lite export LINARODIR=${path}/../gcc-linaro-arm-linux-gnueabihf-4.8-2013.04-20130417_linux echo "Adding CodeSourcery eabi and linaro eabihf compiler suites to the path" export PATH=${SOURCERYDIR}/bin:${LINARODIR}/bin:${PATH} export KOBOLABS=${path}/../../KoboLabs export DEVICEROOT=${KOBOLABS}/deviceroot #export CROSSTARGET="arm-none-linux-gnueabi" export CROSSTARGET="arm-linux-gnueabihf" # Build the linux kernel with these variables export CROSS_COMPILE="arm-none-linux-gnueabi-" export ARCH="arm" # Clean out system shell varaibles that can affect program compilation unset CC unset CFLAGS unset LDFLAGS unset CPPFLAGS unset CPP unset CXX unset CXXFLAGS unset CXXCPP unset C_INCLUDE_PATH unset CPLUS_INCLUDE_PATH unset QT4DIR unset OBJC_INCLUDE_PATH unset PKG_CONFIG_PATH unset PKG_CONFIG_LIBDIR unset PKG_CONFIG_SYSROOT_DIR mkdir -p /tmp/kobo-gcc-cross export TMPDIR=/tmp/kobo-gcc-cross export CPATH=${DEVICEROOT}/usr/include:${DEVICEROOT}/mnt/user/include export LIBRARY_PATH="${DEVICEROOT}/lib:${DEVICEROOT}/usr/lib":${DEVICEROOT}/mnt/user/lib export LDFLAGS="-L${DEVICEROOT}/lib -L${DEVICEROOT}/usr/lib -L${DEVICEROOT}/mnt/user/lib" # Set up PKGCONFIG to prefer programs that were compiled later, over earlier. export PKG_CONFIG_PATH="${DEVICEROOT}/mnt/user/lib/pkgconfig:${DEVICEROOT}/usr/lib/pkgconfig:${DEVICEROOT}/lib/pkgconfig" export PKG_CONFIG_LIBDIR="${PKG_CONFIG_PATH}" export PKG_CONFIG_SYSROOT_DIR="${DEVICEROOT}" cleanup() { echo -e '\033]2;Unknown xterm\007' trap EXIT exit $1 $2 $3 $4 } trap cleanup EXIT echo -e '\033]2;ARM Sourcery_G++_Lite & linaro-gcc for KOBO shell\007' set +e set -o vi [View Less]

2 1

Freeze exception for http://bugs.python.org/issue23661 ?
by Robert Collins July 14, 2015

July 14, 2015

So unittest.mock regressed during 3.5, and I found out when I released the mock backport. The regression is pretty shallow - I've applied the fix to 3.6, its a one-liner and comes with a patch. Whats the process for getting this into 3.5? Its likely to affect a lot of folk using mock (pretty much every OpenStack project got git with it when I released mock 1.1). -Rob -- Robert Collins <rbtcollins(a)hp.com> Distinguished Technologist HP Converged Cloud

4 5