Gregory P. Smith | 3 Mar 02:16 2015

[issue23567] os.stat() tuple access vs named attribute access int vs float


New submission from Gregory P. Smith:

Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
>>> import os, stat
>>> os.stat('/')
posix.stat_result(st_mode=16877, st_ino=2, st_dev=64513L, st_nlink=29, st_uid=0, st_gid=0,
st_size=4096, st_atime=1425341751, st_mtime=1424824650, st_ctime=1424824650)
>>> x =os.stat('/')
>>> x.st_mtime
1424824650.653934
>>> x[stat.ST_MTIME]
1424824650
>>> os.stat_result
<type 'posix.stat_result'>

I have also confirmed the same behavior in 3.4.2.

This may be intentional.  Tuple [stat.ST_XXX] access to the stat return value is the old legacy way to access
these prior to Python 2.2 when the stat_result object was introduced.  At that point they were likely all ints.

The os.stat_float_times() API exists to change the behavior of stat_result objects to return ints
instead of floats by default, but the behavior of the tuple indexed values is always ints.

We need to explicitly document this behavior difference.  Changing the legacy tuple indexing behavior to
return a float would likely break code.

Why file this?  We just ran into a bug due to code comparing a [stat.ST_MTIME] value to a stored
stat_result.st_mtime thus continually reporting a difference due to the precision difference between
the two but the numeric comparison doing its job regardless.
(Continue reading)

STINNER Victor | 3 Mar 01:00 2015

[issue23566] RFE: faulthandler.register() should support file descriptors


New submission from STINNER Victor:

Currently, functions of the faulthandler module require a file-like object (with a fileno() method). It
would be nice to accept also file descriptors (int).

Example of code using faulthandler which creates an useless file object just to pass a file descriptor:
https://github.com/nicoddemus/pytest-faulthandler/blob/master/pytest_faulthandler.py#L13

----------
keywords: easy
messages: 237091
nosy: haypo
priority: normal
severity: normal
status: open
title: RFE: faulthandler.register() should support file descriptors
versions: Python 3.5

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

Daniel Stutzbach | 2 Mar 20:45 2015

[issue23565] local_clear walks the list of threads without holding head_lock.


New submission from Daniel Stutzbach:

local_clear in _threadmodule.c walks the list of threads without holding head_mutex.  Since the list of
threads can change when holding only head_mutex and not on the GIL, the list can change while local_clear
is executing, which may cause Bad Things to happen.

----------
components: Library (Lib)
messages: 237078
nosy: stutzbach
priority: normal
severity: normal
status: open
title: local_clear walks the list of threads without holding head_lock.
type: behavior

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

Hisham Muhammad | 2 Mar 17:50 2015

[issue23564] Patch fixing sanity check for ordered fd sequence in _posixsubprocess.c


New submission from Hisham Muhammad:

In Modules/_posixsubprocess.c, (the helper module for Lib/subprocess.py) there's a function called
_sanity_check_python_fd_sequence which checks, as its comment says, if the fds in the sequence are all
positive and sorted.

The check to verify if it is sorted is incorrect (missing the update to the prev_fd variable), and also it is
missing a test to see if fd's are repeated (which they shouldn't be, so the test should use <= rather than <). 

The attached patch, written against Python 3.4.3 source code, fixes it.

----------
components: Extension Modules
files: python-3.4.3-_posixsubprocess.c.fix.patch
keywords: patch
messages: 237061
nosy: Hisham Muhammad
priority: normal
severity: normal
status: open
title: Patch fixing sanity check for ordered fd sequence in _posixsubprocess.c
versions: Python 3.4
Added file: http://bugs.python.org/file38302/python-3.4.3-_posixsubprocess.c.fix.patch

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

Serhiy Storchaka | 2 Mar 16:05 2015

[issue23563] Faster urllib.urlparse utility functions


New submission from Serhiy Storchaka:

Proposed patch optimizes utility functions in the urllib.parse module.

$ ./python -m timeit -s "from urllib.parse import splittype" -- "splittype('type:'+'x'*1000)"
Unpatched: 100000 loops, best of 3: 17 usec per loop
Patched:   100000 loops, best of 3: 15 usec per loop

$ ./python -m timeit -s "from urllib.parse import splithost" -- "splithost('//www.example.org:80/foo/bar/baz.html')"
Unpatched: 100000 loops, best of 3: 12.7 usec per loop
Patched:   100000 loops, best of 3: 10.6 usec per loop

$ ./python -m timeit -s "from urllib.parse import splithost" -- "splithost('//www.example.org:80')"
Unpatched: 100000 loops, best of 3: 9.34 usec per loop
Patched:   100000 loops, best of 3: 9.09 usec per loop

$ ./python -m timeit -s "from urllib.parse import splituser" -- "splituser('username:password <at> example.org:80')"
Unpatched: 100000 loops, best of 3: 8.76 usec per loop
Patched:   100000 loops, best of 3: 3.1 usec per loop

$ ./python -m timeit -s "from urllib.parse import splituser" -- "splituser('example.org:80')"
Unpatched: 100000 loops, best of 3: 5.89 usec per loop
Patched:   100000 loops, best of 3: 1.98 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitpasswd" -- "splitpasswd('username:password')"
Unpatched: 100000 loops, best of 3: 7.38 usec per loop
Patched:   100000 loops, best of 3: 3.08 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitpasswd" -- "splitpasswd('username')"
(Continue reading)

Maxime S | 2 Mar 15:37 2015

[issue23562] file.read() followed by file.write() result in incorrect behavior


New submission from Maxime S:

Observed Behavior:

$python3
Python 3.5.0a1+ (default, Mar  2 2015, 14:30:05) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("test", "w+")
>>> f.write("Hello World")
11
>>> f.seek(0)
0
>>> f.read(5)
'Hello'
>>> f.write(" people")
7
>>> f.seek(0)
0
>>> f.read()
'Hello World people'

Expected Behavior

According to POSIX, the last f.read() should return "Hello people", like in Python 2:

$ python2
Python 2.7.3 (default, Feb 27 2014, 20:00:17) 
[GCC 4.6.3] on linux2
(Continue reading)

Novice Live | 2 Mar 11:42 2015

[issue23561] a little typo in dis.rst; need a non-trivial preceding dot


New submission from Novice Live:

it is likely that the author of dis.rst omitted two non-trivial preceding dots.

in the 'Bytecode analysis' section,
both :meth:`dis` and :func:`dis` have no preceding dots before 'dis'.

the dots may be trivial elsewhere, but they are non-trivial here. 
otherwise, the hyperlinks will be unexpectedly targeted to the top of the dis module, rather than the
corresponding dis method or function.

ref.
:meth:`.timeit`, where the 'timeit' was preceded by a dot, in timeit.rst.

:)

----------
assignee: docs <at> python
components: Documentation
files: dis_typo.patch
keywords: patch
messages: 237039
nosy: docs <at> python, n0vicelive
priority: normal
severity: normal
status: open
title: a little typo in dis.rst; need a non-trivial preceding dot
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38297/dis_typo.patch
(Continue reading)

Ezio Melotti | 2 Mar 10:28 2015

[issue23560] Group the docs of similar methods in stdtypes.rst


New submission from Ezio Melotti:

The Doc/library/stdtypes.rst page describes in detail the built-in types and their methods.  As
suggested in #21777 (see the comments on Rietveld), it might be a good idea to group the documentation of
some similar methods, such as {r|l|}just, {r|l|}strip, {r|}partition, {r|}index, and {r|}find.

This will remove some duplication, make the page shorter and easier to navigate, and make the methods
easier to discover.  Adding tables containing the methods for each types has also been proposed.

----------
assignee: docs <at> python
components: Documentation
keywords: easy
messages: 237036
nosy: docs <at> python, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Group the docs of similar methods in stdtypes.rst
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

Ezio Melotti | 2 Mar 09:57 2015

[issue433030] SRE: Atomic Grouping (?>...) is not supported


Changes by Ezio Melotti <ezio.melotti <at> gmail.com>:

----------
nosy: +ezio.melotti

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

Raphaël Bleuse | 2 Mar 09:21 2015

[issue23559] [doc] inconsistent range example output


New submission from Raphaël Bleuse:

Reading the documentation for ranges (see
https://docs.python.org/3.5/library/stdtypes.html#ranges), the example using a negative index
output is inconsistent with the range effective behaviour.

One can read:
"
>>> r[-1]
18
"

while (in my understanding) it should be:
"
>>> r[-1]
8
"

Note the output should be 8 and not 18.

Raphaël

----------
assignee: docs <at> python
components: Documentation
messages: 237029
nosy: bleuse, docs <at> python
priority: normal
severity: normal
(Continue reading)

Serhiy Storchaka | 2 Mar 09:04 2015

[issue433028] SRE: (?flag:...) is not supported


Changes by Serhiy Storchaka <storchaka <at> gmail.com>:

----------
dependencies: +Improve some re error messages using regex for hints

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


Gmane