Devin Jeanpierre | 25 May 10:37 2015

[issue24283] Print not safe in signal handlers


New submission from Devin Jeanpierre:

The code attached runs a while loop that prints, and has a signal handler that also prints. There is a thread
that constantly fires off signals, but this is just to ensure the condition for the bug happens -- this is a
bug with signal handling, not threads -- I can trigger a RuntimeError (... with a missing message?) by
commenting out the threading lines and instead running a separate process "while true; do kill -s SIGUSR1
4687; done".

Traceback:

$ python3 threading_print_test.py 
hello
world
Traceback (most recent call last):
  File "/usr/local/google/home/devinj/Downloads/threading_print_test.py", line 36, in <module>
    main()
  File "/usr/local/google/home/devinj/Downloads/threading_print_test.py", line 30, in main
    print("world")
  File "/usr/local/google/home/devinj/Downloads/threading_print_test.py", line 13, in print_hello
    print("hello")
RuntimeError: reentrant call inside <_io.BufferedWriter name='<stdout>'>

----------
files: threading_print_test.py
messages: 244020
nosy: Devin Jeanpierre, haypo
priority: normal
severity: normal
status: open
(Continue reading)

Jyrki Wahlstedt | 25 May 09:30 2015

[issue24282] 3.5 gdbm extension build fails with "'clinic/_gdbmmodule.c.h' file not found"


New submission from Jyrki Wahlstedt:

On OS X (with MacPorts) the following happens:
===
DEBUG: Environment: 
CC='/usr/bin/clang'
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_jwa_work_macports-trunk_dports_python_py-gdbm/py35-gdbm/work/.CC_PRINT_OPTIONS'
CFLAGS='-arch x86_64'
CPATH='/opt/local/include'
CXX='/usr/bin/clang++'
CXXFLAGS='-arch x86_64'
F90FLAGS='-m64'
FCFLAGS='-m64'
FFLAGS='-m64'
LDFLAGS='-arch x86_64'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.10'
OBJC='/usr/bin/clang'
OBJCFLAGS='-arch x86_64'
DEBUG: Assembled command: 'cd
"/opt/local/var/macports/build/_Users_jwa_work_macports-trunk_dports_python_py-gdbm/py35-gdbm/work/Python-3.5.0b1/Modules"
&& /opt/local/Library/Frameworks/Python.framework/Versions/3.5/bin/python3.5 setup.py
--no-user-cfg build'
DEBUG: Executing command line:  cd
"/opt/local/var/macports/build/_Users_jwa_work_macports-trunk_dports_python_py-gdbm/py35-gdbm/work/Python-3.5.0b1/Modules"
&& /opt/local/Library/Frameworks/Python.framework/Versions/3.5/bin/python3.5 setup.py
--no-user-cfg build 
running build
(Continue reading)

James Luscher | 25 May 05:47 2015

[issue24281] String formatting: incorrect number of decimal places


New submission from James Luscher:

Doc for 3.4: at 6.1.3.1. Format Specification Mini-Language
indicates that:
"The precision is a decimal number indicating how many digits should be displayed after the decimal point
for a floating point value"

Yet I find that I get this behavior:

Python 3.4.3 (default, Mar 26 2015, 22:03:40) 
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> '{:08.3}'.format(12.34)
'000012.3'

When what I am expecting is:  '0012.340'

----------
assignee: docs <at> python
components: Documentation
messages: 244011
nosy: docs <at> python, jluscher
priority: normal
severity: normal
status: open
title: String formatting: incorrect number of decimal places
type: behavior
versions: Python 3.4

(Continue reading)

Jeff Ding | 24 May 23:38 2015

[issue24280] Unable to install Python


New submission from Jeff Ding:

After uninstalling old versions of Python:

Python is unable to install unless I disable pip.

Once python installs, python immediately crashes due to Py_Initialize

----------
components: Windows
files: python_crash.png
messages: 244003
nosy: Jeff77789, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Unable to install Python
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file39486/python_crash.png

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue24280>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

(Continue reading)

Christie | 24 May 22:13 2015

[issue24279] Update test_base64 to use test.support.script_helper


New submission from Christie:

As described in Issue9517, many test modules do not make use of the helpers in script_helpers.py to invoke
the python interpreter in a subprocess. Issue9517 will be broken down into several smaller issues so we
can address smaller change sets.

This issue is to update test_base64.py to use script_helpers.py.

----------
messages: 243999
nosy: bobcatfish
priority: normal
severity: normal
status: open
title: Update test_base64 to use test.support.script_helper
versions: Python 3.5

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue24279>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

Martin Blais | 24 May 17:27 2015

[issue24278] Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings


New submission from Martin Blais:

Functions that parse arguments like  PyArg_ParseTupleAndKeywords() have several formatters that fill
in C strings, e.g. "s".

In the C API doc:
https://docs.python.org/3.5/c-api/arg.html#c.PyArg_ParseTupleAndKeywords

There should be an explicit mention of whether this memory needs to be free (in this case: No) and if not, how
this memory is managed (in this case: This refers to a buffer managed by the string object itself). Because
of questions of encoding, it raises questions where this memory lies, and what its lifetime is (in this
case: That of the owning string object from the caller).

This deserves an explicit mention, even if brief.

----------
assignee: docs <at> python
components: Documentation
messages: 243987
nosy: blais, docs <at> python
priority: normal
severity: normal
status: open
title: Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue24278>
_______________________________________
(Continue reading)

R. David Murray | 24 May 16:10 2015

[issue24277] Take the new email package features out of provisional status


New submission from R. David Murray:

I plan to remove the provisional status of the new email features in 3.5.  This is a documentation only
change, but the documentation change is extensive (pretty much a complete rewrite of the package docs).

----------
assignee: r.david.murray
components: Documentation
messages: 243986
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Take the new email package features out of provisional status
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue24277>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

Serhiy Storchaka | 24 May 15:11 2015

[issue24276] Correct reuse argument tuple in property descriptor


New submission from Serhiy Storchaka:

Property descriptor getter uses cached tuple for args (issue23910). This can cause problems when called
function use args after reading other property or save args. For now I know only one example -
clru_cache_3.patch in issue14373.

Proposed patch use cached tuple in more robust manner.

----------
components: Interpreter Core
files: property_cached_args.patch
keywords: patch
messages: 243980
nosy: barry, eric.smith, eric.snow, llllllllll, python-dev, rhettinger, serhiy.storchaka
priority: high
severity: normal
stage: patch review
status: open
title: Correct reuse argument tuple in property descriptor
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file39482/property_cached_args.patch

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue24276>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
(Continue reading)

Jim Jewett | 24 May 07:08 2015

[issue24275] lookdict_* give up too soon


New submission from Jim Jewett:

The specialized lookdict_* variants replace themselves with the generic lookdict as soon as a
non-unicode key is looked up.  

They could reasonably leave the replacement to insertdict (line 819, currently assert rather than a
replacement), when a non-unicode key is actually inserted into the dict. 

While inserts are less common than (all lookups including insert), I see the main advantage as reducing the
number of duplications of the replacement logic.

----------
components: Interpreter Core
messages: 243969
nosy: Jim.Jewett
priority: normal
severity: normal
status: open
title: lookdict_* give up too soon
type: enhancement

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue24275>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

(Continue reading)

Jim Jewett | 24 May 06:49 2015

[issue24274] erroneous comments in dictobject.c


New submission from Jim Jewett:

https://hg.python.org/cpython/file/2df7c958974e/Objects/dictobject.c#l451

The comments near lookdict suggest that specialized versions such as lookdict_unicode and
lookdict_unicode_nodummy cannot return NULL, as that would indicate an Exception was raised during comparison.

They can return NULL, because if the *search* key is not unicode, they replace themselves with the generic
lookdict and then return its result, which may be NULL.

----------
components: Interpreter Core
messages: 243968
nosy: Jim.Jewett
priority: normal
severity: normal
status: open
title: erroneous comments in dictobject.c
type: enhancement

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue24274>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

(Continue reading)

Jacob | 24 May 04:36 2015

[issue24273] _scproxy.so causes EXC_BAD_ACCESS (SIGSEGV)


New submission from Jacob:

This looks very related to: http://bugs.python.org/issue13829

I have very simple test code that looks like this:

    import requests
    r = requests.get('http://www.google.com')
    print('requests.get() succeeded')

The above code works fine. However, when:

    requests.get('http://www.google.com')

is run inside an rq Queue (redis queue) worker I see this problem.

Any fixes or known workarounds for this?

Process:               Python [34628]
Path:                  /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               3.4.3 (3.4.3)
Code Type:             X86-64 (Native)
Parent Process:        Python [34626]
Responsible:           Terminal [333]
User ID:               501

Date/Time:             2015-05-24 08:57:29.055 +0700
OS Version:            Mac OS X 10.10.3 (14D136)
(Continue reading)


Gmane