[issue41409] deque.pop(index) is not supported

[Yuan]

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

[issue2190] MozillaCookieJar ignore HttpOnly cookies

[Dou Yuan]

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

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

[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-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

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

[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.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

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

[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 
<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

[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/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]

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

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

[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 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 
<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]

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 
<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]

Changes by Siming Yuan :


--
nosy: +rhettinger

___
Python tracker 
<http://bugs.python.org/issue31211>
___
___
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

[Yuan Liu]

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 
<http://bugs.python.org/issue30411>
___
___
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

[Yuan Liu]

Changes by Yuan Liu :


--
pull_requests: +1777

___
Python tracker 
<http://bugs.python.org/issue30245>
___
___
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]

New submission from Siming Yuan :

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 
<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]

Siming Yuan  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 
<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]

Siming Yuan  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 
<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]

Siming Yuan  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 
<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]

Siming Yuan  added the comment:

interesting, didn't know that option existed.

--

___
Python tracker 
<https://bugs.python.org/issue33063>
___
___
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]

New submission from Siming Yuan :

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 
<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]

Siming Yuan  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 
<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]

Siming Yuan  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 
<https://bugs.python.org/issue33395>
___
___
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

[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')
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

[issue16059] Serialize MD5 computation-state and resume later

[Ye Yuan]

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 
<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]

Dou Yuan  added the comment:

Firefox no longer use cookies.txt. I think this patch is useless.

--
status: open -> closed

___
Python tracker 
<http://bugs.python.org/issue2190>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32

[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/_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 
<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]

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 
<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]

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 
<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]

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 
<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]

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 
<http://bugs.python.org/issue22634>
___
___
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]

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 
<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 #

[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 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 
<http://bugs.python.org/issue24078>
___
___
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]

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 
<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

[Siming Yuan]

Changes by Siming Yuan :


--
nosy: +rhettinger

___
Python tracker 
<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

[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 
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 
<http://bugs.python.org/issue28442>
___
___
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]

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 
<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]

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 
<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]

Yutao Yuan added the comment:

Yes, it works for me now.

--

___
Python tracker 
<http://bugs.python.org/issue28549>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39679] functools: singledispatchmethod doesn't work with classmethod

[Eugene-Yuan Kou]

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

[issue30841] A shadowing variable naming emitted for Python-ast.c

[Yuan Chao Chou]

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 
<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]

Changes by Yuan Chao Chou :


--
pull_requests: +2617

___
Python tracker 
<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]

Changes by Yuan Chao Chou :


--
pull_requests: +2618

___
Python tracker 
<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]

Changes by Yuan Chao Chou :


--
pull_requests: +2619

___
Python tracker 
<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]

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 
<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] Fix a variable shadowing warning in Python-ast.c

[Yuan Chao Chou]

Changes by Yuan Chao Chou :


--
title: A shadowing variable naming emitted for Python-ast.c -> Fix a variable 
shadowing warning in Python-ast.c

___
Python tracker 
<http://bugs.python.org/issue30841>
___
___
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

[Meng-Yuan Huang]

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 
<http://bugs.python.org/issue25962>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com