[issue37066] os.execl opening a new bash shell doesn't work if initfile/rcfile provided

2019-05-27 Thread Siming Yuan
Siming Yuan added the comment: thank you for the insight and quick response. thought i hit the weirdest bug ever -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issu

[issue37066] os.execl opening a new bash shell doesn't work if initfile/rcfile provided

2019-05-27 Thread Siming Yuan
Siming Yuan added the comment: that works... but where does it say arv[0] is the program name? it seems to be more of a how C works... would be nice if the doc had some examples of that. -- ___ Python tracker <https://bugs.python.org/issue37

[issue37067] os.execl doesn't allow for empty string in mac

2019-05-27 Thread Siming Yuan
Siming Yuan added the comment: actually just learned that argv0 is program name. in that case is that because of a platform difference where in macOS it doesn't allow for program name to be '' and in linux it does? -- ___ Python tracker <ht

[issue37067] os.execl doesn't allow for empty string in mac

2019-05-27 Thread Siming Yuan
New submission from Siming Yuan : the following works in Linux import os os.execl('/bin/bash', '') doesn't in mac: >>> import os >>> os.execl('/bin/bash', '') Traceback (most recent call last): File "", line 1, in File "/Users/me/.pyenv/versions/3.6

[issue37066] os.execl opening a new bash shell doesn't work if initfile/rcfile provided

2019-05-27 Thread Siming Yuan
New submission from Siming Yuan : Using os.execl you can open a new bash shell (eg, using python to process some env before opening a new shell. $ echo $SHLVL 1 $ ~/.pyenv/versions/3.6.4/bin/python3 Python 3.6.4 (default, Feb 5 2018, 16:53:35) [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang

[issue34479] ArgumentParser subparser error display at the wrong level

2018-08-23 Thread Siming Yuan
New submission from Siming Yuan : If you take the example from https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_subparsers # create the top-level parser parser = argparse.ArgumentParser(prog='PROG') parser.add_argument('--foo', action='store_true', help='foo help

[issue33395] TypeError: unhashable type: 'instancemethod'

2018-05-01 Thread Siming Yuan
Siming Yuan <simin...@gmail.com> added the comment: i just discovered cython v0.28 no longer creates instancemethod, so this bug should technically no longer show up after upgrading cython. (related cython bug https://github.com/cython/cython/pull/2105) so the question remains - is it

[issue33395] TypeError: unhashable type: 'instancemethod'

2018-04-30 Thread Siming Yuan
Siming Yuan <simin...@gmail.com> added the comment: having a tough time trying to reproduce this issue in pure python. any clue as to how to create a __repr__ that's unhashable? class UnhashableRepr(dict): __repr__ = _testcapi.instancemethod(dict.__repr__) doesn't work because that

[issue33395] TypeError: unhashable type: 'instancemethod'

2018-04-30 Thread Siming Yuan
New submission from Siming Yuan <simin...@gmail.com>: in Python 3.5 it the pprint.PrettyPrinter mechanism got an overhaul, relying on PrettyPrinter._dispatch dict-lookup based on obj.__repr__ type. This breaks any Cythonized 3rd party libraries that used to be pretty-printable in Pyt

[issue33063] failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'

2018-03-13 Thread Siming Yuan
Siming Yuan <simin...@gmail.com> added the comment: interesting, didn't know that option existed. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33063] failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'

2018-03-13 Thread Siming Yuan
Siming Yuan <simin...@gmail.com> added the comment: edit - I do see this in python 3.6.4 on a different server when building 32-bit Red Hat Enterprise Linux Workstation release 6.7 (Santiago) gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16) -- versions: +Pyth

[issue33063] failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'

2018-03-12 Thread Siming Yuan
Siming Yuan <simin...@gmail.com> added the comment: tested again with Python 3.4.8 and the bug is observed. patch & builds fine. strangely, tested building python 3.6.4 on the same environment without patch, no issues, even though the ffi.c code is exactly the same. --

[issue33063] failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'

2018-03-12 Thread Siming Yuan
Siming Yuan <simin...@gmail.com> added the comment: attached patch that fixes the build issue. credit to davin @ https://bugs.python.org/issue23042 -- keywords: +patch Added file: https://bugs.python.org/file47479/ffi.patch ___ Python tracke

[issue33063] failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'

2018-03-12 Thread Siming Yuan
New submission from Siming Yuan <simin...@gmail.com>: compiling Python 3.5.5 under RHEL 6.4, 32-bit: build/temp.linux-x86_64-3.5/opt/python/Python-3.5.5/Modules/_ctypes/libffi/src/x86/ffi.o: In function `ffi_prep_closure_loc': /opt/python/Python-3.5.5/Modules/_ctypes/libffi/src/x86/ffi

[issue31211] distutils/util.py get_platform() does not identify linux-i686 platforms

2017-08-16 Thread Siming Yuan
Changes by Siming Yuan <simin...@gmail.com>: -- nosy: +rhettinger ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31211> ___ __

[issue31211] distutils/util.py get_platform() does not identify linux-i686 platforms

2017-08-16 Thread Siming Yuan
Siming Yuan added the comment: Hi Eric I understand where you are coming from, but I disagree with having to raise this to 3rd party tools. both wheel/pip makes calls to distutils.util.get_platform(). Fixing it in one location would fix it across the board. In addition, taking setuptools

[issue31211] distutils/util.py get_platform() does not identify linux-i686 platforms

2017-08-15 Thread Siming Yuan
New submission from Siming Yuan: in CentOS installations where both 32 and 64 bit libraries can co exist, and when python is compiled to run with 32-bit libraries (i686) >>> from distutils.util import get_platform >>> get_platform() 'linux-x86_64' because the api only

[issue28442] tuple(a list subclass) does not iterate through the list

2016-10-14 Thread Siming Yuan
Siming Yuan added the comment: my apologies, was in a rush to get it posted. attached a better version of the file. i can reproduce this in python 3.4.1 and python 2.7.8 (both 32 and 64 bit) on RHEL 6.6 however after verifying again - this doesn't seem to be an issue in 3.4.5 (did

[issue28442] tuple(a list subclass) does not iterate through the list

2016-10-14 Thread Siming Yuan
Changes by Siming Yuan <simin...@gmail.com>: -- nosy: +rhettinger ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28442> ___ __

[issue28442] tuple(a list subclass) does not iterate through the list

2016-10-14 Thread Siming Yuan
New submission from Siming Yuan: if you subclass a list, and cast it to tuple, the casting does not iterate through the list. (casing to list does) for example, i needed a WeakList where the list only internally contains WeakReferences that gets deleted as soon as the object ref count goes

[issue24078] inspect.getsourcelines ignores context and returns wrong line #

2015-04-29 Thread Siming Yuan
Siming Yuan added the comment: according to inspect.py line 675 - this is only a best effort. is this intended? inspect.py @ 672 if isclass(object): name = object.__name__ pat = re.compile(r'^(\s*)class\s*' + name + r'\b') # make some effort to find the best

[issue24078] inspect.getsourcelines ignores context and returns wrong line #

2015-04-29 Thread Siming Yuan
New submission from Siming Yuan: if the same class name is used within a module, but defined in different contexts (either class in class or class in function), inspect.getsourcelines() on the class object ignores the object context and only returns the first matched name. reproduce: a.py

[issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32

2015-03-19 Thread Siming Yuan
Siming Yuan added the comment: @davin @lemburg just tested with the provided patch in http://bugs.python.org/issue23042, the partch works. dupe the bug? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22634

[issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32

2014-10-15 Thread Siming Yuan
Siming Yuan added the comment: make log from RHEL 6.4 for python 3.4.2. Also got this on the STDERR: $ make ../make.log build/temp.linux-x86_64-3.4/opt/python-3.4.2/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.o: In function `ffi_prep_closure_loc': /opt/python-3.4.2/Python-3.4.2/Modules

[issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32

2014-10-15 Thread Siming Yuan
Siming Yuan added the comment: attached python 3.4.2 configure log on RHEL6.4 -- Added file: http://bugs.python.org/file36938/configure.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22634

[issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32

2014-10-15 Thread Siming Yuan
Siming Yuan added the comment: configure arguments: BASECFLAGS=-m32 LDFLAGS=-m32 CFLAGS=-m32 ./configure --prefix=/opt/python-3.4.2/ ../configure.log attached system rpm information. no additional binaries/PATHs/LD_LIB_PATHs -- Added file: http://bugs.python.org/file36940/rpm.log

[issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32

2014-10-15 Thread Siming Yuan
Siming Yuan added the comment: [siyuan@siyuan-lnx:siyuan-ott]$ lsb_release -a LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: RedHatEnterpriseWorkstation Description