Vedran Čačić | 5 Jul 15:05 2015

[issue24569] Inconsistent PEP 0448 implementation


New submission from Vedran Čačić:

It seems the consequences of PEP 0448 weren't really thought through. :-/ (And BTW why isn't it in "What's
new in Python 3.5"? I know there is a file with full details, but I guess this really should be notable enough.)

    {0:1, **{0:2}, 0:3, 0:4}

Do you know what is the value of that dict? And does it make sense to you? It surely doesn't make sense to me
(though I understand the implementation). I know things are really subtle and even Guido gets it wrong
(https://bugs.python.org/msg234413), even without PEP 0448, but this particular instance is horrible.

ValueError would be perfect, I'd be ok with 4, I'd shrug on 1, I'd frown on 2, but I _scream_ on 3. Please fix
this until it's too late and fictional "backward compatibility" starts to freeze the wrong behaviour.

----------
messages: 246312
nosy: Vedran.Čačić
priority: normal
severity: normal
status: open
title: Inconsistent PEP 0448 implementation

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

Jakub Wilk | 5 Jul 14:07 2015

[issue24568] Misc/NEWS: "free-after-use" -> "use-after-free"


New submission from Jakub Wilk:

Misc/NEWS reads:
"Fix free-after-use bug"

It should be "use-after-free", not "free-after-use".

----------
assignee: docs <at> python
components: Documentation
messages: 246310
nosy: docs <at> python, jwilk
priority: normal
severity: normal
status: open
title: Misc/NEWS: "free-after-use" -> "use-after-free"
versions: Python 2.7

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

Steven D'Aprano | 5 Jul 05:04 2015

[issue24567] random.choice IndexError due to double-rounding


New submission from Steven D'Aprano:

While investigating issue 24546, I discovered that at least some versions of Python on 32-bit Linux have a
double-rounding bug in multiplication which may lead to an unexpected IndexError in random.choice.

See http://bugs.python.org/issue24546 for additional discussion, but the short version is that due to
double-rounding, if random.random returns (1. - 2.**-53), int(i * random.random()) may return 1 for
some i >= 2049, and random.choice will then evaluate seq[len(seq)], raising IndexError.

----------
messages: 246291
nosy: Serge Anuchin, haypo, mark.dickinson, r.david.murray, rhettinger, serhiy.storchaka, skrah,
steven.daprano, tim.peters
priority: normal
severity: normal
status: open
title: random.choice IndexError due to double-rounding
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

(Continue reading)

bee13oy | 5 Jul 04:49 2015

[issue24566] Unsigned Integer Overflow in sre_lib.h


New submission from bee13oy:

I found an Unsigned Integer Overflow in sre_lib.h.

Tested on En Windows 7 x86 + Python 3.4.3 / Python 3.5.0b2

Crash:
------
(1a84.16b0): Access violation - code c0000005 (!!! second chance !!!)
eax=00000002 ebx=0038f40c ecx=00000002 edx=0526cbb8 esi=83e0116b edi=c3e011eb
eip=58bcfa53 esp=0038f384 ebp=0038f394 iopl=0         nv up ei ng nz na po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010283
python35+0x1fa53:
58bcfa53 380e            cmp     byte ptr [esi],cl          ds:002b:83e0116b=??

code: 
------
58bcfa3d 8b4a04          mov     ecx,dword ptr [edx+4]
58bcfa40 0fb6c1          movzx   eax,cl
58bcfa43 3bc1            cmp     eax,ecx
58bcfa45 0f8593000000    jne     python35+0x1fade (58bcfade)
58bcfa4b 3bf7            cmp     esi,edi
58bcfa4d 0f838b000000    jae     python35+0x1fade (58bcfade)
58bcfa53 380e            cmp     byte ptr [esi],cl          ds:002b:83e0116b=??
58bcfa55 0f8583000000    jne     python35+0x1fade (58bcfade)

stack:
------
0:000> kb
(Continue reading)

Xavier de Gaye | 4 Jul 22:36 2015

[issue24565] the f_lineno getter is broken


New submission from Xavier de Gaye:

The last paragraph of Objects/lnotab_notes.txt explains that the f_lineno member of the PyFrameObject
structure is needed to store the line number of the last "line" tracing event so that this value may be used
as the line number of the "return" event instead of the (sometimes confusing) value computed from
f_lasti.  The f_lineno getter must then return the value of f->f_lineno (instead of the value computed
from f->f_lasti) when tracing is set. The current implementation translates "tracing is set" as "the
local f_trace trace function is not NULL", this is wrong for the following reasons:

* AFAIK it is not documented anywhere that Python users implementing a trace function must delete the local
f_trace functions of all the frames when setting the
  global trace function to None via sys.settrace(None) (issue 7238).

* Bdb.set_continue() in the bdb module of the std lib seems to know about this and attempts to do it, but fails
to delete f_trace from the topmost frame, named botframe (sic) (issue 16482, issue 17697).

* It is not obvious how to delete the f_trace of all suspended generators when setting the global trace
function to None (issue 17277).

* _PyTraceback_Add() in Python/traceback.c sets frame->f_lineno, obviously forgetting that it is
useless since its f_trace is NULL.

This patch changes the semantics of f_lineno by stating that f_lineno is invalid when its value is -1. When
tracing, the f_lineno of all the frames on the stack is valid. The f_lineno of a suspended generator is
always invalid.

----------
components: Interpreter Core
files: f_lineno.patch
(Continue reading)

Jess Hamrick | 4 Jul 22:05 2015

[issue24564] shutil.copytree fails when copying NFS to NFS


New submission from Jess Hamrick:

shutil.copytree seems to fail when copying files across NFS filesystems. In this example (see
bug_demo.py), /tmp is a normal ext4 filesystem and the current working directory is NFS (version 4).
Interestingly, it works fine to to copy between ext4 and NFS, just not NFS and NFS (even if it's the same NFS mount).

Depending on the specific version of 3.4, there are slightly different errors. For 3.4.0:

$ uname -a
Linux compmodels-node 3.13.0-55-generic #94-Ubuntu SMP Thu Jun 18 00:27:10 UTC 2015 x86_64 x86_64
x86_64 GNU/Linux
$ python3 bug_demo.py

--------------------------------------------------
Python version info:
3.4.0 (default, Jun 19 2015, 14:20:21)
[GCC 4.8.2]
--------------------------------------------------

Copying NFS --> /tmp
Copying /tmp --> NFS
Copying NFS --> NFS
Traceback (most recent call last):
  File "/usr/lib/python3.4/shutil.py", line 336, in copytree
    copystat(src, dst)
  File "/usr/lib/python3.4/shutil.py", line 212, in copystat
    _copyxattr(src, dst, follow_symlinks=follow)
  File "/usr/lib/python3.4/shutil.py", line 152, in _copyxattr
    os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
(Continue reading)

Terry J. Reedy | 4 Jul 01:38 2015

[issue24563] Encoding declaration: doc supported encodings


New submission from Terry J. Reedy:

The source .rst for 
<https://docs.python.org/3/reference/lexical_analysis.html#encoding-declarations>
has at the end:
.. XXX there should be a list of supported encodings.

While I believe this is impractical, there could be a link to
https://docs.python.org/3/library/codecs.html#standard-encodings
-- and possible subsubsections that follow.  Are the latter supported for Python code?

----------
assignee: docs <at> python
components: Documentation
messages: 246233
nosy: docs <at> python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Encoding declaration: doc supported encodings
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

Dan Zemke | 3 Jul 22:34 2015

[issue24562] ntpath splitdrive fails on line 161: tuple has no attribute 'replace'


New submission from Dan Zemke:

Traceback was:

  File "\drzblobio.py", line 70, in load full_read_path = os.path.join(read_path, fname)
  File "C:\Python34\lib\ntpath.py", line 110, in join
    p_drive, p_path = splitdrive(p)
  File "C:\Python34\lib\ntpath.py", line 161, in splitdrive
    normp = p.replace(_get_altsep(p), sep)
AttributeError: 'tuple' object has no attribute 'replace'

----------
components: Library (Lib)
messages: 246217
nosy: zemke
priority: normal
severity: normal
status: open
title: ntpath splitdrive fails on line 161: tuple has no attribute 'replace'
type: crash
versions: Python 3.4

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

Vitaly Murashev | 3 Jul 19:47 2015

[issue24561] [VS2013] Py_InitializeEx causes fatal error being from winnt-service


New submission from Vitaly Murashev:

[Affects Windows only]
Brief description (after analysis in debugger):

Py_InitializeEx fails inside internal call:

1.
    if (initstdio() < 0)
        Py_FatalError(
            "Py_Initialize: can't initialize sys standard streams");

2. inside initstdio():

    if (!is_valid_fd(fd)) {
        std = Py_None;
        Py_INCREF(std);
    }
    else {
// ===> is_valid_fd() passed and we come here
        std = create_stdio(iomod, fd, 0, "<stdin>", encoding, errors);
        if (std == NULL)
            goto error; // ===> this goto leads to fatal error

3.
is_valid_fd(int fd)   /// => JFI: fd=0
{
    int dummy_fd;
    if (fd < 0 || !_PyVerify_fd(fd))
(Continue reading)

yac | 3 Jul 17:12 2015

[issue24560] codecs.StreamReader doesn't work with nonblocking streams: TypeError: can't concat bytes to NoneType


New submission from yac:

File "/usr/lib64/python3.4/codecs.py", line 490, in read
    data = self.bytebuffer + newdata
TypeError: can't concat bytes to NoneType

            if size < 0:
                newdata = self.stream.read()
            else:
                newdata = self.stream.read(size)
            # decode bytes (those remaining from the last call included)
            data = self.bytebuffer + newdata

if self.stream is nonblocking, it's read will return None (py3, py2 raises IOError(EGAIN)).

Simple `if newdata is None: return None` should fix that I guess

----------
components: Unicode
messages: 246186
nosy: ezio.melotti, haypo, yac
priority: normal
severity: normal
status: open
title: codecs.StreamReader doesn't work with nonblocking streams: TypeError: can't concat bytes to NoneType
versions: Python 3.4

_______________________________________
Python tracker <report <at> bugs.python.org>
(Continue reading)

Gino Lee | 3 Jul 15:14 2015

[issue24559] online Python docs scroll in a godawful ugly fashion


New submission from Gino Lee:

Example:
https://docs.python.org/2/library/re.html#

If you start scrolling down, the left panel updates in a horribly jerky and ugly fashion. It's distracting,
annoying, and it makes the site look very amateurishly constructed. At the very least, just keep the panel
fixed and unmoving -- just let the user scroll it as he/she needs to.

This is on Chrome browser on Mac OSX, but I think I've seen this dysfunctional behavior on other platforms as well.

I am filing this bug here because I was unable to find the place to file documentation related bugs..

----------
messages: 246173
nosy: Gino Lee
priority: normal
severity: normal
status: open
title: online Python docs scroll in a godawful ugly fashion
type: behavior

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue24559>
_______________________________________
_______________________________________________
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