Serhiy Storchaka | 26 Jan 00:16 2015

[issue23321] Crash in str.decode() with special error handler


New submission from Serhiy Storchaka:

Debugging build crashes in some circumstances in str.decode() with error handler which produces
replacement string with length larger than malformed data. For example the backslashreplace error
handler produces 4-character string for every illegal byte. All other standard error handlers produce
no longer than 1 character for every illegal unit.

Here is a patch which fixes this issue. I'll commit it without review because buildbots are broken without
it. This issue is open for reference and post-commit review.

----------
assignee: serhiy.storchaka
components: Interpreter Core
files: unicode_decode_call_errorhandler_writer.patch
keywords: patch
messages: 234705
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Crash in str.decode() with special error handler
type: crash
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37861/unicode_decode_call_errorhandler_writer.patch

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

Berker Peksag | 25 Jan 23:35 2015

[issue1745722] please add wsgi to SimpleXMLRPCServer


Berker Peksag added the comment:

I've updated the patch for 3.5. I also have cleaned-up the documentation to avoid duplicate content.

----------
components: +Library (Lib) -XML
nosy: +berker.peksag
versions: +Python 3.5 -Python 3.4
Added file: http://bugs.python.org/file37860/issue1745722.diff

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

Akira Li | 25 Jan 22:06 2015

[issue23320] devguide should mention rules about "paragraph reflow" in the documentation


New submission from Akira Li:

It is suggested in https://bugs.python.org/issue23251
that only a core Python developer may reflow paragraphs
while submitting patches for the Python documentation.

It should be codified in devguide: I haven't found the
word *reflow* in it.

----------
components: Devguide
messages: 234692
nosy: akira, ezio.melotti
priority: normal
severity: normal
status: open
title: devguide should mention rules about "paragraph reflow" in the documentation
type: behavior

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

Matthieu Gautier | 25 Jan 19:53 2015

[issue23319] Missing SWAP_INT in I_set_sw


New submission from Matthieu Gautier:

I_set_sw function is missing a SWAP_INT.

This leads to wrong set of bitfield value.

Here is a script to reproduce:

----------
from ctypes import *

class HEADER(BigEndianStructure):
   _fields_ = ( ('pad', c_uint32, 16),
                ('v1', c_uint32, 4),
                ('v2', c_uint32, 12)
              )

b = bytearray(4)
header = HEADER.from_buffer(b)

header.type = 1
assert b == b'\x00\x00\x10\x00'

header.mode = 0x234
assert b == b'\x00\x00\x12\x34'
----------

----------
components: ctypes
(Continue reading)

Dave Notman | 25 Jan 18:31 2015

[issue23318] (compiled RegEx).split gives unexpected results if () in pattern


New submission from Dave Notman:

# Python 3.3.1 (default, Sep 25 2013, 19:30:50)
# Linux 3.8.0-35-generic #50-Ubuntu SMP Tue Dec 3 01:25:33 UTC 2013 i686 i686 i686 GNU/Linux

import re

splitter = re.compile( r'(\s*[+/&;,]\s*)|(\s+and\s+)' )
ll = splitter.split( 'Dave & Sam, Jane and Zoe' )
print(repr(ll))

print( 'Try again with revised RegEx' )
splitter = re.compile( r'(?:(?:\s*[+/&;,]\s*)|(?:\s+and\s+))' )
ll = splitter.split( 'Dave & Sam, Jane and Zoe' )
print(repr(ll))

Results:
['Dave', ' & ', None, 'Sam', ', ', None, 'Jane', None, ' and ', 'Zoe']
Try again with revised RegEx
['Dave', 'Sam', 'Jane', 'Zoe']

----------
components: Regular Expressions
messages: 234677
nosy: dnotmanj, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: (compiled RegEx).split gives unexpected results if () in pattern
(Continue reading)

Justin Eldridge | 25 Jan 18:16 2015

[issue23317] Incorrect description of descriptor invocation in Python Language Reference


New submission from Justin Eldridge:

The section titled "Invoking Descriptors" in the Python Language Reference [1]
says:

    Class Binding
        If binding to a new-style class, A.x is transformed into the call: 
        A.__dict__['x'].__get__(None, A).

This suggests that __get__ is looked up on the instance of x, when I believe
that it is actually looked up on the type. That is, it's my understanding that
A.x invokes:

    type(A.__dict__['x']).__get__(A.__dict__['x'], None, Foo))

Here's some Python 3.4 code demonstrating this:

    class A:
        pass

    class Descriptor:
        def __get__(self, obj, cls):
            print("Getting!")

    A.x = Descriptor()

    def replacement_get(obj, cls):
        print("This is a replacement.")

(Continue reading)

Joshua Landau | 25 Jan 16:46 2015

[issue23316] Incorrect evaluation order of function arguments with *args


New submission from Joshua Landau:

It is claimed that all expressions are evaluated left-to-right, including in functions¹. However,

    f(*a(), b=b())

will evaluate b() before a().

¹ https://docs.python.org/3/reference/expressions.html#evaluation-order

----------
components: Interpreter Core
messages: 234672
nosy: Joshua.Landau
priority: normal
severity: normal
status: open
title: Incorrect evaluation order of function arguments with *args
type: behavior
versions: Python 3.4, Python 3.5

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

(Continue reading)

Akira Li | 25 Jan 12:02 2015

[issue23315] tempfile.mkdtemp fails with non-ascii paths on Python 2


New submission from Akira Li:

Python 2.7.9 (default, Jan 25 2015, 13:41:30) 
  [GCC 4.9.2] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import os, sys, tempfile
  >>> d = u'\u20ac'.encode(sys.getfilesystemencoding()) # non-ascii
  >>> if not os.path.isdir(d): os.makedirs(d)
  ... 
  >>> os.environ['TEMP'] = d
  >>> tempfile.mkdtemp(prefix=u'')
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File ".../python2.7/tempfile.py", line 331, in mkdtemp
      file = _os.path.join(dir, prefix + name + suffix)
    File ".../python2.7/posixpath.py", line 80, in join
      path += '/' + b
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 13: ordinal not in range(128)

Related: https://bugs.python.org/issue1681974

----------
components: Unicode
messages: 234662
nosy: akira, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: tempfile.mkdtemp fails with non-ascii paths on Python 2
(Continue reading)

Berker Peksag | 25 Jan 01:30 2015

[issue21548] pydoc -k IndexError on empty docstring


Berker Peksag added the comment:

Here's a patch with tests.

----------
nosy: +berker.peksag
stage:  -> patch review
Added file: http://bugs.python.org/file37841/issue21548.diff

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

Steve Dower | 25 Jan 00:27 2015

[issue23314] Disabling CRT asserts in debug build


New submission from Steve Dower:

When we completely switch Windows builds over to VC14, we're going to encounter some new assert dialogs
from the CRT. These won't appear in release builds, but because the buildbots run tests against debug
builds they will get in the way. A number of tests attempt operations on bad file descriptors, which will
assert and terminate in MSVCRT (I have a fix for the termination coming, but the assertions will still appear).

Currently regrtest has a "-n" flag to disable assertions using an MSVCRT function. This works fine with the
exception of subprocesses, that do not inherit the setting.

The setting is process-wide, so we can't just turn assertions off around the code that may assert. We also
can't turn them off completely without affecting users (e.g. #3545 and #4804).

#4804 has the discussion leading to the current state where _PyVerify_fd and the -n flag above exist. The
_PyVerify_fd function could break with future CRT changes (bearing in mind that Python 3.5 and later will
automatically use the latest installed CRT), for which there is an official workaround coming soon,
except it won't suppress the assertion dialog for debug builds.

I'd like to propose three options:

1. Make faulthandler.enable() also disable assertions in debug builds. (Assertions are for debugging,
and enabling faulthandler - at least on Windows - seems to suggest that you want to override the debugger.
We also already enable faulthandler for subprocesses in the test suite.)

2. Add an environment variable (PYTHONDISABLECRTASSERT?) and use it to disable assertions on startup.
(It looks like at least some tests deliberately block envvars flowing through to subprocesses, so this
may require test changes too.)

3. Add a new xoption and use it to disable assertions on startup.
(Continue reading)

Gerrit Barrere | 24 Jan 20:01 2015

[issue23313] Wrong complex variable being altered


New submission from Gerrit Barrere:

The bug occurs on line 77 of the attached script. When I change the imaginary part of 'z' on line 77, it also
changes the imaginary part of 'zload', which is supposed to remain constant.  Putting a dummy assignment
'z = z + 0' on line 76 fixes the bug.  This is all described in the comments around line 77 also.

I found this in the PyCharm IDE by putting a breakpoint just after line 77 and watching variables 'z' and
'zload'.  The function 'model()' is called repeatedly in this script, and you can see 'zload' changing
every time the function is called.

----------
files: ComplexBug.py
messages: 234631
nosy: CarpeCimex
priority: normal
severity: normal
status: open
title: Wrong complex variable being altered
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37839/ComplexBug.py

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


Gmane