[issue37066] os.execl opening a new bash shell doesn't work if initfile/rcfile provided
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/issue37066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37066] os.execl opening a new bash shell doesn't work if initfile/rcfile provided
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/issue37066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37067] os.execl doesn't allow for empty string in mac
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 <https://bugs.python.org/issue37067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37067] os.execl doesn't allow for empty string in mac
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.4/lib/python3.6/os.py", line 527, in execl
execv(file, args)
ValueError: execv() arg 2 first element cannot be empty
works if you add a space
>>> os.execl('/bin/bash', ' ')
notice the space in 2nd argument.
technically it is also possible to run a command without arguments - why not
allow for the case where *args is []?
>>> os.execl('/bin/bash')
Traceback (most recent call last):
File "", line 1, in
File "/Users/siyuan/.pyenv/versions/3.6.4/lib/python3.6/os.py", line 527, in
execl
execv(file, args)
ValueError: execv() arg 2 must not be empty
>>>
--
components: macOS
messages: 343655
nosy: ned.deily, ronaldoussoren, siming85
priority: normal
severity: normal
status: open
title: os.execl doesn't allow for empty string in mac
versions: Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue37067>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37066] os.execl opening a new bash shell doesn't work if initfile/rcfile provided
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-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.execl('/bin/bash', '')
$ echo $SHLVL
2
Doing the above works with just /bin/bash no arguments. (notice SHLVL
incrementing)
But providing your own custom --init-file or --rcfile, doesn't.
eg - /bin/bashrc --rcfile
$ 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-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.execl('/bin/bash', '--rcfile','/users/me/venv/bin/activate')
$ echo $SHLVL
1
this can be replicated in Python 3.5 to 3.7
can be worked-around if using a wrapper.sh file with:
#! /bin/bash
exec /bin/bash --rcfile /users/me/venv/bin/activate
and running this file in os.execl() instead.
--
messages: 343654
nosy: siming85
priority: normal
severity: normal
status: open
title: os.execl opening a new bash shell doesn't work if initfile/rcfile
provided
versions: Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue37066>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34479] ArgumentParser subparser error display at the wrong level
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')
subparsers = parser.add_subparsers(help='sub-command help')
# create the parser for the "a" command
parser_a = subparsers.add_parser('a', help='a help')
parser_a.add_argument('-bar', type=int, help='bar help')
# create the parser for the "b" command
parser_b = subparsers.add_parser('b', help='b help')
parser_b.add_argument('--baz', choices='XYZ', help='baz help')
and run a subcommand but with an argument the subcommand doesn't understand
parser.parse_args(['a', '-x'])
the output doesn't help much - because the usage is coming from the main parser
usage: PROG [-h] [--foo] {a,b} ...
PROG: error: unrecognized arguments: -x
the reason for failure is because the error api being called in this case is
parser.error(msg)
not the subparser
parser_a.error(msg)
the proper error should've been
usage: PROG a [-h] [-bar BAR]
PROG a: error: unrecognized arguments: -x
--
components: Library (Lib)
messages: 323956
nosy: siming85
priority: normal
severity: normal
status: open
title: ArgumentParser subparser error display at the wrong level
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python.org/issue34479>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33395] TypeError: unhashable type: 'instancemethod'
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 a good idea to assume all type(obj).__repr__ is hashable? if so, we can close this bug. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33395] TypeError: unhashable type: 'instancemethod'
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 turns into a which becomes hashable. i'd love to provide a patch, seems trivial to fix, but wouldn't want to do so without some tests. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33395] TypeError: unhashable type: 'instancemethod'
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 Python3.4. type(object).__repr__ since instancemethod_hash function has been commented out: https://github.com/python/cpython/blob/c30098c8c6014f3340a369a31df9c74bdbacc269/Objects/classobject.c#L569 oddly the behavior is different between Linux and Mac. The same object in Linux returns cyfunction, and is hashable, where as under the same CPython version in Mac, it returns instancemethod, rendering it unhashable. (based on Cython 0.27.3) note that this isn't exactly something related directly to the implementation of Cython. the old logic in Python <3.4 pprint was not pretty (pun not intended), but relied solely on type checking, where as the new implementation depends on hashing, which introduces this bug. -- messages: 315964 nosy: siming85 priority: normal severity: normal status: open title: TypeError: unhashable type: 'instancemethod' type: crash versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33063] failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'
Siming Yuan <simin...@gmail.com> added the comment: interesting, didn't know that option existed. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33063] failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'
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: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33063] failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'
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. -- components: +ctypes versions: +Python 3.4 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33063] failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'
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 tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33063] failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'
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.c:678: undefined reference to `ffi_closure_FASTCALL' /usr/bin/ld: build/temp.linux-x86_64-3.5/opt/python/Python-3.5.5/Modules/_ctypes/libffi/src/x86/ffi.o: relocation R_386_GOTOFF against undefined hidden symbol `ffi_closure_FASTCALL' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value related to https://bugs.python.org/issue23042 - but it seems like the patch for x86/ffi.c never made it to release. -- components: Build messages: 313716 nosy: siming85 priority: normal severity: normal status: open title: failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL' versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31211] distutils/util.py get_platform() does not identify linux-i686 platforms
Changes by Siming Yuan <simin...@gmail.com>: -- nosy: +rhettinger ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31211] distutils/util.py get_platform() does not identify linux-i686 platforms
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 & pip out of picture (uninstalling), using just
distutils.core.setup() and doing a bdist (built-in command available in
distutils) is still generating a wrong tag in linux 32-bit arch.
pkg-1.0.0.linux-x86_64.tar.gz
within distutils.util.get_platform() the code under sunos makes attempts to
identify the correct bitness:
bitness = {2147483647:"32bit", 9223372036854775807:"64bit"}
machine += ".%s" % bitness[sys.maxsize]
why would the linux logic not handle the same problem?
--
resolution: third party ->
status: pending -> open
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31211>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31211] distutils/util.py get_platform() does not identify linux-i686 platforms
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 looks at OS flavor and not the actual binary architecture. this string is used as part of PEP425 tags in the built wheel/egg file: my_package-3.3.0-cp34-cp34m-linux-x86_64.whl but this creates a mismatch with PIP - pip.pep425tags returns "linux-i686" instead on the same python instance, addressed by: # snippet pip code def _is_running_32bit(): return sys.maxsize == 2147483647 if result == "linux_x86_64" and _is_running_32bit(): # 32 bit Python program (running on a 64 bit Linux): pip should only # install and run 32 bit compiled extensions in that case. result = "linux_i686" so the end result is any packages built with sdist_wheel (using setuptools/distutils) is not installable on the same instance. Of course the workaround is to overwrite that and provide --plat-name linux_i686. but the question is - shouldn't the tags line up? -- components: Distutils messages: 300300 nosy: dstufft, merwok, siming85 priority: normal severity: normal status: open title: distutils/util.py get_platform() does not identify linux-i686 platforms versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28442] tuple(a list subclass) does not iterate through the list
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 not verify earlier versions), so it is indeed already fixed. closing. time to upgrade! -- resolution: -> fixed status: open -> closed versions: +Python 3.4 -Python 3.5 Added file: http://bugs.python.org/file45096/weak_list.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28442] tuple(a list subclass) does not iterate through the list
Changes by Siming Yuan <simin...@gmail.com>: -- nosy: +rhettinger ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28442] tuple(a list subclass) does not iterate through the list
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 to zero.. so: import weakref class WeakList(list): def __init__(self, items = ()): super(WeakList, self).__init__([weakref.ref(i, self.remove) for i in items]) def __contains__(self, item): return super(WeakList, self).__contains__(weakref.ref(item)) def __getitem__(self, index): if isinstance(index, slice): return [i() for i in super(WeakList, self).__getitem__(index)] else: return super(WeakList, self).__getitem__(index)() def __setitem__(self, index, item): if isinstance(index, slice): item = [weakref.ref(i, self.remove) for i in item] else: item = weakref.ref(item, self.remove) return super(WeakList, self).__setitem__(index, item) def __iter__(self): for i in list(super(WeakList, self).__iter__()): yield i() def remove(self, item): if isinstance(item, weakref.ReferenceType): super(WeakList, self).remove(item) else: super(WeakList, self).remove(weakref.ref(item)) def append(self, item): return super(WeakList, self).append(weakref.ref(item, self.remove)) # write some test code: class Dummy(): pass a = Dummy() b = Dummy() l = WeakList() l.append(a) l.append(b) print(a) <__main__.Dummy instance at 0x7f29993f4ab8> print(b) <__main__.Dummy instance at 0x7f29993f4b00> print(l) [, ] print([i for i in l]) [<__main__.Dummy instance at 0x7f29993f4ab8>, <__main__.Dummy instance at 0x7f29993f4b00>] print(list(l)) [<__main__.Dummy instance at 0x7f29993f4ab8>, <__main__.Dummy instance at 0x7f29993f4b00>] print(tuple(l)) (, ) ^ notice how you are getting weak references back instead of tuples. -- messages: 278652 nosy: siming85 priority: normal severity: normal status: open title: tuple(a list subclass) does not iterate through the list type: behavior versions: Python 2.7, Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24078] inspect.getsourcelines ignores context and returns wrong line #
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 matching class definition:
# use the one with the least indentation, which is the one
# that's most probably not inside a function definition.
candidates = []
for i in range(len(lines)):
match = pat.match(lines[i])
if match:
# if it's at toplevel, it's already the best one
if lines[i][0] == 'c':
return lines, i
# else add whitespace to candidate list
candidates.append((match.group(1), i))
if candidates:
# this will sort by whitespace, and by line number,
# less whitespace first
candidates.sort()
return lines, candidates[0][1]
else:
raise OSError('could not find class definition')
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24078
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24078] inspect.getsourcelines ignores context and returns wrong line #
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 class A(object): class B(object): pass class C(object): class B(object): pass -- import inspect import a inspect.getsourcelines(a.C.B) (['class B(object):\n', 'pass\n'], 2) -- components: Library (Lib) messages: 242254 nosy: siyuan priority: normal severity: normal status: open title: inspect.getsourcelines ignores context and returns wrong line # type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24078 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32
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/_ctypes/libffi/src/x86/ffi.c:679: undefined reference to `ffi_closure_FASTCALL' /usr/bin/ld: build/temp.linux-x86_64-3.4/opt/python-3.4.2/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.o: relocation R_386_GOTOFF against undefined hidden symbol `ffi_closure_FASTCALL' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status -- Added file: http://bugs.python.org/file36939/make.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32
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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32
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:Red Hat Enterprise Linux Workstation release 6.4 (Santiago) Release:6.4 Codename: Santiago [siyuan@siyuan-lnx:siyuan-ott]$ uname -a Linux siyuan-lnx 2.6.32-358.0.1.el6.x86_64 #1 SMP Wed Feb 20 11:05:23 EST 2013 x86_64 x86_64 x86_64 GNU/Linux :( there's nothing special.. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
