[issue39679] functools: singledispatchmethod doesn't work with classmethod
Eugene-Yuan Kou added the comment: Hi, I also encounter to the problem, and I have give my attempt to make the singledispatchmethod support the classmethod, and staticmethod with type annotation. I also adding two tests. Please refer to my fork. I will trying to make a pull request https://github.com/EugenePY/cpython/compare/3.8...fix-issue-39679 -- nosy: +EugenePY ___ Python tracker <https://bugs.python.org/issue39679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41409] deque.pop(index) is not supported
Yuan added the comment: Same status as slicing support from MutableSequence. -- nosy: +Yuan ___ Python tracker <https://bugs.python.org/issue41409> ___ ___ 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: 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
[issue30841] Fix a variable shadowing warning in Python-ast.c
Changes by Yuan Chao Chou <oswinc...@gmail.com>: -- title: A shadowing variable naming emitted for Python-ast.c -> Fix a variable shadowing warning in Python-ast.c ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30841] A shadowing variable naming emitted for Python-ast.c
Yuan Chao Chou added the comment: This can be repro by setting -Wshadow-compatible-local when using gcc to compile Python-ast.c. An example on my machine: ➜ cpython git:(69c0db5050) ✗ gcc-7 -Wshadow-compatible-local -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -I/usr/local/opt/readline/include -I/usr/local/opt/openssl/include -I/Users/python/.pyenv/versions/3.6.1/include -I/usr/local/include -I/Users/python/.pyenv/versions/3.6.1/include/python3.6m -c Python/Python-ast.c -o build/temp.macosx-10.12-x86_64-3.6/Python-ast.o Python/Python-ast.c: In function 'obj2ast_stmt': Python/Python-ast.c:4586:25: warning: declaration of 'value' shadows a previous local [-Wshadow=compatible-local] expr_ty value; ^ Python/Python-ast.c:4570:17: note: shadowed declaration is here expr_ty value; ^ -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30841] A shadowing variable naming emitted for Python-ast.c
Changes by Yuan Chao Chou <oswinc...@gmail.com>: -- pull_requests: +2619 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30841] A shadowing variable naming emitted for Python-ast.c
Changes by Yuan Chao Chou <oswinc...@gmail.com>: -- pull_requests: +2618 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30841] A shadowing variable naming emitted for Python-ast.c
Changes by Yuan Chao Chou <oswinc...@gmail.com>: -- pull_requests: +2617 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30841] A shadowing variable naming emitted for Python-ast.c
New submission from Yuan Chao Chou: When Parser/asdl_c.py is composing the content of Python/Python-ast.c, it uses "value" to name the variables in inner blocks, which can shadow the variables named the same in outer blocks. It would be a good practice to avoid the shadowing naming to prevent the variables from being misused. -- components: Interpreter Core messages: 297609 nosy: OswinC priority: normal severity: normal status: open title: A shadowing variable naming emitted for Python-ast.c type: compile error versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30245] possible overflow when organize struct.pack_into error message
Changes by Yuan Liu <akira@gmail.com>: -- pull_requests: +1777 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30411] git doesn't support "-C" args under 1.8.5 occurs in configure.ac
New submission from Yuan Liu: git doesn't support "-C" args under 1.8.5 occurs in configure.ac as I noticed from git release notes in 1.8.5: * Just like "make -C ", "git -C ..." tells Git to go there before doing anything else. So we should have some conditional statements in configure.ac around git checkpoint, otherwise we got error message which is : Unknown option: -C usage: git [--version] [--help] [-c name=value] [--exec-path[=]] [--html-path] [--man-path] [--info-path] [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] [--git-dir=] [--work-tree=] [--namespace=] [] -- messages: 294021 nosy: Yuan Liu priority: normal severity: normal status: open title: git doesn't support "-C" args under 1.8.5 occurs in configure.ac versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28549] curses: calling addch() with an 1-length str segfaults with ncurses6 compiled with --enable-ext-colors
Yutao Yuan added the comment: Yes, it works for me now. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28549] curses: calling addch() with an 1-length str segfaults with ncurses6 compiled with --enable-ext-colors
Yutao Yuan added the comment: It fails to compile for me. setcchar should take a cchar_t* and a const wchar_t* instead. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28549] curses: calling addch() with an 1-length str segfaults with ncurses6 compiled with --enable-ext-colors
New submission from Yutao Yuan: When addch() is called with an 1-length str, it is converted into a cchar_t. Ncurses6 adds a new field ext_color to cchar_t if it is enabled at compile time, and it is not initialized here, which causes various problems like segfaults or wrong display of characters. -- components: Extension Modules messages: 279620 nosy: yyt16384 priority: normal severity: normal status: open title: curses: calling addch() with an 1-length str segfaults with ncurses6 compiled with --enable-ext-colors type: crash versions: Python 3.4, Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28549> ___ ___ 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
[issue25962] Ctrl+C Can't Exit Script with Pool on Windows
New submission from Meng-Yuan Huang: My OS is Windows 10 Pro 64-bit. My Python version is 3.5.1 64-bit. I wrote a simple script (t.py, see the attached file) with multiprocessing.Pool and run it by: python t.py in Windows Command Prompt. I tried to interrupt the running script by pressing Ctrl+C keys. Python showed the message: --- Work Started: 21360 Process SpawnPoolWorker-1: Traceback (most recent call last): File "d:\Anaconda3\lib\multiprocessing\process.py", line 254, in _bootstrap self.run() File "d:\Anaconda3\lib\multiprocessing\process.py", line 93, in run self._target(*self._args, **self._kwargs) File "d:\Anaconda3\lib\multiprocessing\pool.py", line 119, in worker result = (True, func(*args, **kwds)) File "C:\Users\myh\Documents\Python Scripts\t.py", line 7, in do_work 1 KeyboardInterrupt --- However, it didn't terminate Python and come back to Windows Command Prompt. It just hang there. Then, I pressed another Ctrl+C. Python showed: --- Process SpawnPoolWorker-2: Traceback (most recent call last): File "d:\Anaconda3\lib\multiprocessing\process.py", line 254, in _bootstrap self.run() File "d:\Anaconda3\lib\multiprocessing\process.py", line 93, in run self._target(*self._args, **self._kwargs) File "d:\Anaconda3\lib\multiprocessing\pool.py", line 108, in worker task = get() File "d:\Anaconda3\lib\multiprocessing\queues.py", line 343, in get res = self._reader.recv_bytes() File "d:\Anaconda3\lib\multiprocessing\connection.py", line 216, in recv_bytes buf = self._recv_bytes(maxlength) File "d:\Anaconda3\lib\multiprocessing\connection.py", line 306, in _recv_bytes [ov.event], False, INFINITE) KeyboardInterrupt --- Unfortunately, it still didn't terminate Python and come back to Windows Command Prompt! However, I run the same script with Python 3.5.1 64-bit on a CetnOS 7 64-bit, it can terminate Python and come back to the terminal. Is this a bug on Windows? -- components: Windows files: t.py messages: 257106 nosy: Meng-Yuan Huang, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Ctrl+C Can't Exit Script with Pool on Windows type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file41436/t.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25962> ___ ___ 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
[issue16059] Serialize MD5 computation-state and resume later
New submission from Ye Yuan: Serialize/deserialize md5 context. Pseudocode: import md5 # Start hash generation m = md5.new() m.update(Content) # Serialize m serialized_m = serialize(m) # In another function/machine, deserialize m # and continue hash generation m2 = deserialize(serialized_m) m2.update(More content) m2.digest() There are C++ lib but no Python one. -- components: Library (Lib) messages: 171367 nosy: Ye.Yuan priority: normal severity: normal status: open title: Serialize MD5 computation-state and resume later type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16059 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2190] MozillaCookieJar ignore HttpOnly cookies
Dou Yuan douy...@gmail.com added the comment: Firefox no longer use cookies.txt. I think this patch is useless. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2190 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2190] MozillaCookieJar ignore HttpOnly cookies
New submission from Dou Yuan: HttpOnly cookie in Firefox's cookies.txt begins with #HttpOnly_ now, just like a comment, e.g.: #HttpOnly_.rad.live.comTRUE/FALSE125821FC09FB= #HttpOnly_service.ilib.cnFALSE/FALSE1209905939 .ASPXANONYMOUS JMeD5-atyAEkYjZlNDUyNDAtOGQ4ZC00NTEyLTljN2EtMzNkODM3M2JjMjFivtX6ikB7Iv0jRJBJs9ftggv_a2k Since no obvious need, there are no patches for save method and cookielib.Cookie class. -- components: Library (Lib) files: _MozillaCookieJar.diff keywords: patch messages: 62985 nosy: douyuan severity: minor status: open title: MozillaCookieJar ignore HttpOnly cookies versions: Python 2.6 Added file: http://bugs.python.org/file9552/_MozillaCookieJar.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2190 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
