[issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0

[David Ford (FirefighterBlu3)]

Changes by David Ford (FirefighterBlu3) :


--
title: Error in `/usr/bin/python': free(): invalid size: 0x7f628400d0e0 -> 
[python] Error in `/usr/bin/python': free(): invalid size: 0x7f628400d0e0

___
Python tracker 

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

[issue26355] Emit major version based canonical URLs for docs

[Berker Peksag]

Berker Peksag added the comment:

Patch looks good to me too, thanks! Just left a super minor comment on Rietveld.

You might want to commit this to 3.5+ because we don't daily build 3.4 docs 
anymore: 
https://github.com/python/docsbuild-scripts/blob/master/build_docs.py#L30

I didn't see any links from 2.6 or older Python 2 versions in search results 
before so I don't have a strong opinion on backporting the patch to 2.7 (I 
probably wouldn't bother with Python 2 docs anymore :))

--

___
Python tracker 

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

[issue29314] asyncio.async deprecation warning is missing stacklevel=2

[Roundup Robot]

Roundup Robot added the comment:


New changeset 00c949c7c3a3eed27a0b320d320097f630eb8fc5 by Mariatta Wijaya in 
branch '3.5':
Issue #29314: Set the stacklevel to two in asyncio.async() Deprecation Warning
https://github.com/python/cpython/commit/00c949c7c3a3eed27a0b320d320097f630eb8fc5


--

___
Python tracker 

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

[issue29314] asyncio.async deprecation warning is missing stacklevel=2

[Roundup Robot]

Roundup Robot added the comment:


New changeset 00c949c7c3a3eed27a0b320d320097f630eb8fc5 by Mariatta Wijaya in 
branch '3.6':
Issue #29314: Set the stacklevel to two in asyncio.async() Deprecation Warning
https://github.com/python/cpython/commit/00c949c7c3a3eed27a0b320d320097f630eb8fc5

New changeset 22fce50aa151160540326001ace1e0826f6323a1 by Mariatta Wijaya in 
branch '3.6':
Issue #29314: Merge with 3.5
https://github.com/python/cpython/commit/22fce50aa151160540326001ace1e0826f6323a1


--

___
Python tracker 

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

[issue29314] asyncio.async deprecation warning is missing stacklevel=2

[Roundup Robot]

Roundup Robot added the comment:


New changeset 00c949c7c3a3eed27a0b320d320097f630eb8fc5 by Mariatta Wijaya in 
branch 'master':
Issue #29314: Set the stacklevel to two in asyncio.async() Deprecation Warning
https://github.com/python/cpython/commit/00c949c7c3a3eed27a0b320d320097f630eb8fc5

New changeset 22fce50aa151160540326001ace1e0826f6323a1 by Mariatta Wijaya in 
branch 'master':
Issue #29314: Merge with 3.5
https://github.com/python/cpython/commit/22fce50aa151160540326001ace1e0826f6323a1

New changeset 2ef05ee4f1c721732918c8839b0b3ac5f1c807a7 by Mariatta Wijaya in 
branch 'master':
Issue #29314: Merge with 3.6
https://github.com/python/cpython/commit/2ef05ee4f1c721732918c8839b0b3ac5f1c807a7


--

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

[Stefan Behnel]

Stefan Behnel added the comment:

Thanks for asking. Cython doesn't use METH_FASTCALL yet, so this doesn't 
introduce any problems.

Generally speaking, if Cython generated user code stops working with a new 
CPython version, we expect people to regenerate their code with the newest 
Cython version to fix it, so this kind of internal incompatibility is usually 
reparable by adapting Cython appropriately.

--

___
Python tracker 

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

[issue29470] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0

[David Ford (FirefighterBlu3)]

New submission from David Ford (FirefighterBlu3):

(Only 3.[56] tested)

my application listens on an SSL wrapped port, accepts socket and gets an 
incoming set of messages. connection time frame is several seconds but due to 
bad Comcast service frequently we have outages which hang connections. almost 
every day python crashes as follows:

Feb 07 02:36:11 ranger.blue-labs.org python[11816]: *** Error in 
`/usr/bin/python': free(): invalid size: 0x7f628400d0e0 ***
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: *** Error in 
`/usr/bin/python': free(): invalid size: 0x7f628400d0e0 ***
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 WARNING 
SSL client handshake has failed: EOF occurred in viola
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: === Backtrace: =
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libc.so.6(+0x70c4b)[0x7f62a84cac4b]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libc.so.6(+0x76fe6)[0x7f62a84d0fe6]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libc.so.6(+0x777de)[0x7f62a84d17de]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libcrypto.so.1.0.0(CRYPTO_free+0x1d)[0x7f62a5ceaa6d]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libcrypto.so.1.0.0(BN_clear_free+0x58)[0x7f62a5d4bbc8]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libcrypto.so.1.0.0(RSA_free+0x6f)[0x7f62a5d99a2f]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libcrypto.so.1.0.0(EVP_PKEY_free+0x4a)[0x7f62a5dcdcea]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libcrypto.so.1.0.0(+0x163780)[0x7f62a5de5780]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libcrypto.so.1.0.0(ASN1_template_free+0x450)[0x7f62a5debf00]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libcrypto.so.1.0.0(ASN1_template_free+0x567)[0x7f62a5dec017]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libcrypto.so.1.0.0(ASN1_item_free+0x1fb)[0x7f62a5dec2fb]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libssl.so.1.0.0(SSL_CTX_use_certificate+0xc4)[0x7f62a4ee3d14]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libssl.so.1.0.0(SSL_CTX_use_certificate_chain_file+0x7f)[0x7f62a4ee490f]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0xe77d)[0x7f6
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libpython3.5m.so.1.0(PyCFunction_Call+0xe9)[0x7f62a8ac4be9]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x78a1)[0x7f62a8b3b941]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libpython3.5m.so.1.0(PyObject_CallFunctionObjArgs+0xc2)[0x7f62a8a7dec2]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0x9c46)[0x7f6
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libssl.so.1.0.0(ssl_parse_clienthello_tlsext+0x648)[0x7f62a4ec9838]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libssl.so.1.0.0(ssl3_get_client_hello+0x6fa)[0x7f62a4eadeca]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libssl.so.1.0.0(ssl3_accept+0x66f)[0x7f62a4eb27af]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0xc3a9)[0x7f6
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x843c)[0x7f62a8b3c4dc]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: === Backtrace: =
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libc.so.6(+0x70c4b)[0x7f62a84cac4b]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libc.so.6(+0x76fe6)[0x7f62a84d0fe6]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libc.so.6(+0x777de)[0x7f62a84d17de]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libcrypto.so.1.0.0(CRYPTO_free+0x1d)[0x7f62a5ceaa6d]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 
/usr/lib/libcrypto.so.1.0.0(BN_clear_free+0x58)[0x7f62a5d4bbc8]
Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 

[issue29314] asyncio.async deprecation warning is missing stacklevel=2

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Thanks all :)

--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

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

[issue29314] asyncio.async deprecation warning is missing stacklevel=2

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0f5161f865d7 by Mariatta Wijaya in branch '3.5':
Issue #29314: Set the stacklevel to two in asyncio.async() Deprecation Warning
https://hg.python.org/cpython/rev/0f5161f865d7

New changeset 6dbe9051cdec by Mariatta Wijaya in branch '3.6':
Issue #29314: Merge with 3.5
https://hg.python.org/cpython/rev/6dbe9051cdec

New changeset 9f16900bebaa by Mariatta Wijaya in branch 'default':
Issue #29314: Merge with 3.6
https://hg.python.org/cpython/rev/9f16900bebaa

--
nosy: +python-dev

___
Python tracker 

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

[issue29371] Typo in doctest documentation

[Roundup Robot]

Roundup Robot added the comment:


New changeset 2b20a37791e3cc4536db1f99fc85ffb6e20134ab by Mariatta Wijaya in 
branch '2.7':
Issue #29371: Clarify bitwise OR operation in doctest option flags.
https://github.com/python/cpython/commit/2b20a37791e3cc4536db1f99fc85ffb6e20134ab


--

___
Python tracker 

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

[issue29371] Typo in doctest documentation

[Roundup Robot]

Roundup Robot added the comment:


New changeset c36939b07c1275a6c3897a917c638b0ac48885c4 by Mariatta Wijaya in 
branch 'master':
Issue #29371: Clarify bitwise OR operation in doctest option flags.
https://github.com/python/cpython/commit/c36939b07c1275a6c3897a917c638b0ac48885c4

New changeset 141e1ca9844b6efe71dc7acbb6c011e1b3a4ea19 by Mariatta Wijaya in 
branch 'master':
Issue #29371: merge with 3.5
https://github.com/python/cpython/commit/141e1ca9844b6efe71dc7acbb6c011e1b3a4ea19

New changeset bcc59e6131af582620c2db32e19d0a064d891a59 by Mariatta Wijaya in 
branch 'master':
Issue #29371: merge with 3.6
https://github.com/python/cpython/commit/bcc59e6131af582620c2db32e19d0a064d891a59


--

___
Python tracker 

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

[issue29371] Typo in doctest documentation

[Roundup Robot]

Roundup Robot added the comment:


New changeset c36939b07c1275a6c3897a917c638b0ac48885c4 by Mariatta Wijaya in 
branch '3.5':
Issue #29371: Clarify bitwise OR operation in doctest option flags.
https://github.com/python/cpython/commit/c36939b07c1275a6c3897a917c638b0ac48885c4


--

___
Python tracker 

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

[issue29371] Typo in doctest documentation

[Roundup Robot]

Roundup Robot added the comment:


New changeset c36939b07c1275a6c3897a917c638b0ac48885c4 by Mariatta Wijaya in 
branch '3.6':
Issue #29371: Clarify bitwise OR operation in doctest option flags.
https://github.com/python/cpython/commit/c36939b07c1275a6c3897a917c638b0ac48885c4

New changeset 141e1ca9844b6efe71dc7acbb6c011e1b3a4ea19 by Mariatta Wijaya in 
branch '3.6':
Issue #29371: merge with 3.5
https://github.com/python/cpython/commit/141e1ca9844b6efe71dc7acbb6c011e1b3a4ea19


--

___
Python tracker 

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

[issue26355] Emit major version based canonical URLs for docs

[Matthias Bussonnier]

Matthias Bussonnier added the comment:

Thanks Nick, 

I can work on the similar patch for Python 2.7.
I'll wait for the migration to GitHub which IIRC should be soon.

Side question, is there some metrics (like google analytics) to know how much 
traffic there is on older Python docs and if it's worth patching ?

--

___
Python tracker 

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

[issue29371] Typo in doctest documentation

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Thanks, Marco, Jim, and Raymond :)

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue29371] Typo in doctest documentation

[Roundup Robot]

Roundup Robot added the comment:

New changeset 3fd198b80f29 by Mariatta Wijaya in branch '2.7':
Issue #29371: Clarify bitwise OR operation in doctest option flags.
https://hg.python.org/cpython/rev/3fd198b80f29

--

___
Python tracker 

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

[issue29371] Typo in doctest documentation

[Roundup Robot]

Roundup Robot added the comment:

New changeset df62e833eeb1 by Mariatta Wijaya in branch '3.5':
Issue #29371: Clarify bitwise OR operation in doctest option flags.
https://hg.python.org/cpython/rev/df62e833eeb1

New changeset c3d779f96b20 by Mariatta Wijaya in branch '3.6':
Issue #29371: merge with 3.5
https://hg.python.org/cpython/rev/c3d779f96b20

New changeset e376d2bfde9b by Mariatta Wijaya in branch 'default':
Issue #29371: merge with 3.6
https://hg.python.org/cpython/rev/e376d2bfde9b

--
nosy: +python-dev

___
Python tracker 

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

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

[INADA Naoki]

INADA Naoki added the comment:

I submit new issues:

* #29463 for AST change (change docstring from first statement to attribute).
* #29469 for constant folding

Note that this issue contains more peephole -> AST optimization changes.
But I want to start these two patch to ease review and discussion.

--

___
Python tracker 

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

[issue29469] AST-level Constant folding

[INADA Naoki]

Changes by INADA Naoki :


--
dependencies: +Change docstring to attribute from first statement.

___
Python tracker 

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

[issue29469] AST-level Constant folding

[INADA Naoki]

New submission from INADA Naoki:

spin off of #11549.
This patch uses code generator to traverse AST.

--
files: ast-constant-folding.patch
keywords: patch
messages: 287186
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: AST-level Constant folding
versions: Python 3.7
Added file: http://bugs.python.org/file46555/ast-constant-folding.patch

___
Python tracker 

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

[issue29468] zipfile should catch ValueError as well as OSError to detect bad seek calls

[Joe Jevnik]

New submission from Joe Jevnik:

In zipfile.py only OSError is checked to see if seek fails:

```
def _EndRecData64(fpin, offset, endrec):
"""
Read the ZIP64 end-of-archive records and use that to update endrec
"""
try:
fpin.seek(offset - sizeEndCentDir64Locator, 2)
except OSError:
# If the seek fails, the file is not large enough to contain a ZIP64
# end-of-archive record, so just return the end record we were given.
return endrec
```

I belive that this should also catch ValueError so that other file-like objects 
may be passed to ZipFile. The particular case I ran into was passing an mmap 
object:

```
"""
$ python p.py
sys.version_info(major=3, minor=6, micro=0, releaselevel='final', serial=0)
[]
Traceback (most recent call last):
  File "p.py", line 34, in 
with mmap_shared_raw_zipfile(f.name) as zf:
  File "/usr/lib64/python3.6/contextlib.py", line 82, in __enter__
return next(self.gen)
  File "p.py", line 23, in mmap_shared_raw_zipfile
ZipFile(mm) as zf:
  File "/usr/lib64/python3.6/zipfile.py", line 1100, in __init__
self._RealGetContents()
  File "/usr/lib64/python3.6/zipfile.py", line 1163, in _RealGetContents
endrec = _EndRecData(fp)
  File "/usr/lib64/python3.6/zipfile.py", line 264, in _EndRecData
return _EndRecData64(fpin, -sizeEndCentDir, endrec)
  File "/usr/lib64/python3.6/zipfile.py", line 196, in _EndRecData64
fpin.seek(offset - sizeEndCentDir64Locator, 2)
ValueError: seek out of range
"""
from contextlib import contextmanager
import mmap
import sys
from tempfile import NamedTemporaryFile
from zipfile import ZipFile


print(sys.version_info)


@contextmanager
def mmap_shared_raw_zipfile(path):
"""Open a zipfile with mmap shared so the data can be shared in multiple
processes.

Parameters
--
path : str
The path the zipfile to open.

Notes
-
The context manager returns a :class:`zipfile.ZipFile` on enter.
"""
with open(path) as f, \
mmap.mmap(f.fileno(), 0, mmap.MAP_SHARED, mmap.PROT_READ) as mm, \
ZipFile(mm) as zf:
yield zf


with NamedTemporaryFile() as f:
ZipFile(f, mode='w').close()
print(ZipFile(f.name).infolist())


with NamedTemporaryFile() as f:
ZipFile(f, mode='w').close()
with mmap_shared_raw_zipfile(f.name) as zf:
print(zf.infolist())
```

--
components: Library (Lib)
messages: 287185
nosy: ll
priority: normal
severity: normal
status: open
title: zipfile should catch ValueError as well as OSError to detect bad seek 
calls
versions: Python 3.6

___
Python tracker 

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

[issue29449] clear() should return prior state in threading.Event

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
nosy: +tim.peters

___
Python tracker 

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

[issue29466] pickle does not serialize Exception __cause__ field

[Xiang Zhang]

Changes by Xiang Zhang :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue29465] Add _PyObject_FastCall() to reduce stack consumption

[STINNER Victor]

STINNER Victor added the comment:

Oh, I forgot to rebase my local git branch: patch version 2 contains unrelated 
changes. Please see instead the path version 3 which was rebased.

--
Added file: http://bugs.python.org/file46554/pyobject_fastcall-3.patch

___
Python tracker 

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

[issue29465] Add _PyObject_FastCall() to reduce stack consumption

[STINNER Victor]

STINNER Victor added the comment:

pyobject_fastcall-2.patch: More complete changes. Sorry, the patch also 
contains unrelated refactoring! It's a more advanced implementation which tries 
to reduce the depth of the C backtrace. For example, _PyObject_FastCall() is 
now inlined manually in _PyObject_FastCallDict(). PyObject_Call() is also 
rewritten. If the overall approach is validated, I will rewriten the patch 
differently to limit changes, or push some changes in multiple commits.

Results of testcapi_stacksize.patch + stack_overflow_28870-sp.py (from issue 
#28870).

Reference:

haypo@smithers$ ../default-ref/python stack_overflow_28870-sp.py 
test_python_call: 8586 calls before crash, stack: 976 bytes/call
test_python_getitem: 9188 calls before crash, stack: 912 bytes/call
test_python_iterator: 7936 calls before crash, stack: 1056 bytes/call

=> total: 25710 calls, 2944 bytes

Patch:

haypo@smithers$ ./python stack_overflow_28870-sp.py 
test_python_call: 9883 calls before crash, stack: 848 bytes/call (-128 B)
test_python_getitem: 10476 calls before crash, stack: 800 bytes/call (- 112 B)
test_python_iterator: 8878 calls before crash, stack: 944 bytes/call (- 112 B)

=> total: 29237 calls (+3616), 2592 bytes (- 352 B)

--
Added file: http://bugs.python.org/file46553/pyobject_fastcall-2.patch

___
Python tracker 

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

[issue29467] Allow return mismatch to be caught by function

[Eric V. Smith]

Eric V. Smith added the comment:

Thanks for the suggestion. However, I don't think it's possible or desirable 
for python to implement this.

There are two problems: 1) the internals of python would have to be drastically 
changed to support this, and 2) you'd need different syntax to support this.

For item 2, consider:

def f():
try: return some_other_function()
except: return 1,2

You can't distinguish between your proposed type mis-match exception and 
some_other_function() raising a TypeError. I suppose you could invent another 
exception type, but you'll always have a similar problem.

A larger problem is that this behavior would be confusing to both newcomers and 
existing programmers, it adds nothing that can't currently be done, and it 
would be a source of subtle bugs.

If you really want to explore this, I suggest working out a more complete 
example and bringing it up on the python-ideas mailing list.

You'll want to include code that currently exists that would be made simpler 
with your proposal. If you can find any such code in the standard library, that 
would be a bonus.

Thanks again.

--
nosy: +eric.smith
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue28686] py.exe ignored PATH when using python3 shebang

[Paul Moore]

Paul Moore added the comment:

I agree, I don't particularly want versioned executables. I'm not sure I see 
much point to even having versioned launchers - "py -2" and "py -3" seem fine 
to me if needed.

The only use cases I can see are:

1. Use the Python executable that's first on PATH: "py"
2. Use the specific system installation of Python X[.Y]: "py -X[.Y]"

For shebang usage:

1. Use the Python executable that's first on PATH: "#!/usr/bin/env python"
2. Use the specific system installation of Python X[.Y]: 
"#!/usr/bin/pythonX[.Y]"
3. Use a specific interpreter: "#!"

The Unix ability to have 2 different versions of Python on PATH and select 
which you use based on executable name doesn't exist on Windows, and so there's 
no equivalent of the Unix "#!/usr/bin/env pythonX[.Y]"

If you want your script to fail under certain conditions - whether it's that 
the interpreter is a version you don't support, or something else, then test 
for that case and fail with an error. Checking runtime conditions doesn't need 
to be handled by the shebang.

The only change I'd consider reasonable here would be a doc change to explain 
the behaviour a bit more clearly. I might try to put something together if I 
have the time.

--

___
Python tracker 

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

[issue28164] _PyIO_get_console_type fails for various paths

[Roundup Robot]

Roundup Robot added the comment:


New changeset c6c32889c9d80ffd599a57fd0d4c4a88deece29b by Steve Dower in branch 
'3.6':
Issue #28164: Improves test on Windows 7
https://github.com/python/cpython/commit/c6c32889c9d80ffd599a57fd0d4c4a88deece29b


--

___
Python tracker 

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

[issue28164] _PyIO_get_console_type fails for various paths

[Roundup Robot]

Roundup Robot added the comment:


New changeset c6c32889c9d80ffd599a57fd0d4c4a88deece29b by Steve Dower in branch 
'master':
Issue #28164: Improves test on Windows 7
https://github.com/python/cpython/commit/c6c32889c9d80ffd599a57fd0d4c4a88deece29b

New changeset dc5c4bc90770d6a5875666434cf797c77eb3dcad by Steve Dower in branch 
'master':
Issue #28164: Improves test on Windows 7
https://github.com/python/cpython/commit/dc5c4bc90770d6a5875666434cf797c77eb3dcad


--

___
Python tracker 

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

[issue28164] _PyIO_get_console_type fails for various paths

[Steve Dower]

Steve Dower added the comment:

That test looks good for me, and I verified it on both Win7 and Win10. 
(Hopefully we don't have any Win8.1 edge cases in here...)

--
status: open -> closed

___
Python tracker 

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

[issue28164] _PyIO_get_console_type fails for various paths

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4463e311f5bd by Steve Dower in branch '3.6':
Issue #28164: Improves test on Windows 7
https://hg.python.org/cpython/rev/4463e311f5bd

New changeset 8132bcc1522d by Steve Dower in branch 'default':
Issue #28164: Improves test on Windows 7
https://hg.python.org/cpython/rev/8132bcc1522d

--

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

[STINNER Victor]

STINNER Victor added the comment:

Hum, benchmark results don't seem good. There is probably a performance bug 
somewhere. I should investigate further to analyze these results. M aybe 
combined with the issue #29465, results will be better.

haypo@speed-python$ python3 -m perf compare_to 
~/benchmarks/2017-02-06_07-15-default-e06af4027546.json 
fastcall-no-keywords_ref_e06af4027546.json -G --min-speed=5

Slower (19):
- unpickle_list: 6.36 us +- 0.11 us -> 8.08 us +- 0.14 us: 1.27x slower (+27%)
- pickle_list: 7.53 us +- 0.41 us -> 8.62 us +- 0.49 us: 1.14x slower (+14%)
- crypto_pyaes: 199 ms +- 2 ms -> 226 ms +- 2 ms: 1.13x slower (+13%)
- pickle: 22.1 us +- 0.3 us -> 24.9 us +- 0.3 us: 1.12x slower (+12%)
- nbody: 233 ms +- 2 ms -> 260 ms +- 2 ms: 1.12x slower (+12%)
- xml_etree_iterparse: 179 ms +- 4 ms -> 198 ms +- 5 ms: 1.11x slower (+11%)
- telco: 14.7 ms +- 0.3 ms -> 16.3 ms +- 0.5 ms: 1.11x slower (+11%)
- pickle_dict: 56.6 us +- 4.3 us -> 62.7 us +- 4.7 us: 1.11x slower (+11%)
- pidigits: 291 ms +- 1 ms -> 319 ms +- 1 ms: 1.10x slower (+10%)
- scimark_fft: 662 ms +- 10 ms -> 717 ms +- 8 ms: 1.08x slower (+8%)
- scimark_monte_carlo: 207 ms +- 4 ms -> 224 ms +- 6 ms: 1.08x slower (+8%)
- regex_v8: 43.7 ms +- 0.6 ms -> 47.0 ms +- 0.3 ms: 1.08x slower (+8%)
- float: 238 ms +- 3 ms -> 254 ms +- 4 ms: 1.07x slower (+7%)
- xml_etree_parse: 242 ms +- 5 ms -> 257 ms +- 9 ms: 1.06x slower (+6%)
- raytrace: 1.04 sec +- 0.01 sec -> 1.11 sec +- 0.01 sec: 1.06x slower (+6%)
- unpickle: 30.0 us +- 0.3 us -> 31.8 us +- 0.3 us: 1.06x slower (+6%)
- go: 493 ms +- 7 ms -> 520 ms +- 6 ms: 1.05x slower (+5%)
- scimark_sparse_mat_mult: 8.24 ms +- 0.14 ms -> 8.69 ms +- 0.14 ms: 1.05x 
slower (+5%)
- chaos: 234 ms +- 2 ms -> 246 ms +- 4 ms: 1.05x slower (+5%)

Faster (2):
- chameleon: 21.9 ms +- 0.2 ms -> 20.7 ms +- 0.3 ms: 1.06x faster (-5%)
- sympy_expand: 949 ms +- 12 ms -> 899 ms +- 11 ms: 1.06x faster (-5%)

Benchmark hidden because not significant (43): (...)

--

___
Python tracker 

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

[issue28686] py.exe ignored PATH when using python3 shebang

[Steve Dower]

Steve Dower added the comment:

> If Python on Windows changed to ship python3.exe and python37.exe alongside 
> python.exe, then it might be worth revisiting this discussion

Agreed, though if we started including versioned executables wouldn't that 
resolve this issue naturally? (As in, we'd search for python3.exe and find it?)

FWIW, I'm not a huge fan of including versioned executables - I would much 
rather include versioned *launchers*, so we can put them all in the one 
directory and avoid cluttering the search path (i.e. rename "py.exe" to 
"python.exe", "python2.exe" and "python3.exe" and have it check its own name 
before searching).

--

___
Python tracker 

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

[issue28686] py.exe ignored PATH when using python3 shebang

[Paul Moore]

Paul Moore added the comment:

> 2) you really want to have meaningful shebangs (ie, version-specific) in your 
> scripts because, well, 2017 and the world is still split between py2 and py3, 

This is the one I think is overspecifying. I don't see a really *good* reason 
for not just saying /usr/bin/env python.

What would you want to happen if you said /usr/bin/env python3 if you had 
Python 2 on your PATH? The only reasonable answer I can see is "give an error", 
so why not just put

if sys.version_info < (3,0):
raise RuntimeError("Needs python 3")

at the top of your script?

Add to this the fact that I don't even know how you'd check if a python 
interpreter that's on PATH is Python 2 or 3 without executing it (and the 
overhead of running it an extra time to query its version is unacceptable) and 
I still don't see the justification.

> - just look at my %path% before doing anything else. It could be that the 
> first interpreter you find there will just match the requirement from the 
> shebang (that is, because on occasion I just know what I'm doing, and I've 
> just activated a matching venv, you see). If so, just give me that Python and 
> I will be ok; 
> - otherwise, my bad: feel free to resume any other search strategy you find 
> appropriate, and I will humbly accept whatever interpreter you may fetch, 
> even a php one. 

> I think this would be just reasonable enough. What I'm missing here?

You're missing the fact that it's not possible to tell by inspection the 
version of a Python interpreter. On Unix, the executable name includes the 
version, so it's easy. If Python on Windows changed to ship python3.exe and 
python37.exe alongside python.exe, then it might be worth revisiting this 
discussion, but not as things stand (IMO).

--

___
Python tracker 

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

[issue29467] Allow return mismatch to be caught by function

[Ted Shaneyfelt]

New submission from Ted Shaneyfelt:

def f():
try: return 0
except: return 1,2

x = f() # x is 0
x,y = f() # proposal: x,y should be 1,2 instead of uncaught TypeError

It would make sense to be able to catch [TypeError: 'int' object is not 
iterable] and return the correct number of values. Yes, the way it's done now, 
the function is no longer running when it is caught - but is it possible and 
practical to determine if parameters match before the function returns instead 
of afterward, allowing the called function to catch the error attempting to 
return?

--
components: Interpreter Core
messages: 287173
nosy: Ted Shaneyfelt
priority: normal
severity: normal
status: open
title: Allow return mismatch to be caught by function
type: enhancement
versions: Python 3.5

___
Python tracker 

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

[issue28686] py.exe ignored PATH when using python3 shebang

[Riccardo Polignieri]

Riccardo Polignieri added the comment:

> I'm inclined to say YAGNI, and we simply leave "/usr/bin/env python3" 
> undefined. 

I can't say I'm really happy with this answer. Fact is, 
1) you almost always have to work from within a virtual env these days, 
2) you really want to have meaningful shebangs (ie, version-specific) in your 
scripts because, well, 2017 and the world is still split between py2 and py3, 
3) the py.exe launcher is the new shiny thing and we all just want to use it.

So, it *could* annoy some people to find out that py.exe just can't handle both 
venvs and shebangs in a meaningful way, and you must give up on either venvs, 
or shebangs, or py.exe. 

As far as I know (3.6.0 and 2.7.13), you have 3 ways to invoke a script:

1) "version-specific" launcher (eg "py -3 foo.py"): this will always pick the 
system interpreter, never abides neither venvs nor shebangs. A perfectly 
defined, utterly useless behavior. 

2) invoke interpreter (eg "python foo.py", the good old way): this will always 
be venvs-complaint, will never parse shebangs. And yet at the moment, it's 
probably your best option *when* inside a venv - and the worst when outside, of 
course. 

3) "version-agnostic" launcher (eg "py foo.py"). Outside a venv, this will 
always abide version-specific shebangs (ie, "#!python3"); the only quirk being 
that when facing a generic shebang instead, it will pick Python 2 (because, 
2017 and Linux...). Oh well, I can live with that. 
But when you are inside a venv, then
- if it finds a "not-env" shebang (ie "python" or "/usr/bin/python"), then it 
will NOT abide the venv - frustrating, yet correct I suppose;
- if it finds any kind of version-specific shebang (EVEN a "env"-type of 
shebang!), then again it will follow the shebang but NOT the venv, and will 
pick up the system interpreter. That, even when you are inside a venv that 
perfectly matches the shebang prescription. 

Now, this can be very frustrating because a useless "/usr/bin/env python" 
shebang triggers the correct behavior both inside and outside a venv, BUT a 
much more useful "usr/bin/env python3" will fail even if we are inside a 
matching venv. 

I feel that all it needs to be perfect is some kind of behavior like this: dear 
py.exe, 
- when you are invoked in a version-agnostic way, and 
- when you find an "env"-and-version-specific shebang in the script, 
then please, 
- just look at my %path% before doing anything else. It could be that the first 
interpreter you find there will just match the requirement from the shebang 
(that is, because on occasion I just know what I'm doing, and I've just 
activated a matching venv, you see). If so, just give me that Python and I will 
be ok; 
- otherwise, my bad: feel free to resume any other search strategy you find 
appropriate, and I will humbly accept whatever interpreter you may fetch, even 
a php one. 

I think this would be just reasonable enough. What I'm missing here?

--
nosy: +ricpol

___
Python tracker 

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

[issue29371] Typo in doctest documentation

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Thanks, Raymond. I have an updated patch there the hypen and apostrophe are 
removed.

--
versions:  -Python 3.3, Python 3.4
Added file: http://bugs.python.org/file46552/issue29371v2.patch

___
Python tracker 

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

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()

[R. David Murray]

R. David Murray added the comment:

Your thought is correct: python2 no longer gets enhancements.  So improved 
comment handling can only be added to python3, assuming anyone is interested in 
doing it :)

--

___
Python tracker 

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

[issue29232] Quiet Install

[Earl Maier]

Earl Maier added the comment:

I have since rebuilt the machine that I was doing my testing on, so I am unable 
grab log files from the installs.  I have not been able to reproduce the issue 
since the rebuild of the machine.  On a good note: Everything is working as it 
should. I appreciate you looking into the issue.  

Thank you

--

___
Python tracker 

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

[issue29439] _decimal on Android requires linking with libm

[Xavier de Gaye]

Xavier de Gaye added the comment:

> Perhaps test_decimal should fail for CPython if _decimal can't be imported.
This is not a problem specific to _decimal, the same problem exists for 
third-party extension modules, for example pyephem 
(https://github.com/brandon-rhodes/pyephem/issues/114) and existed with some 
other Python extension modules (issue 21668).

--

___
Python tracker 

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

[issue29439] _decimal on Android requires linking with libm

[Xavier de Gaye]

Xavier de Gaye added the comment:

With the following module named dlsym.py, the command 'python dlsym.py log10' 
produces the same successful output on linux and on Android API 21 (when 
_decimal is not explicitly linked with libm.so, i.e.without changeset 
b60b46ad8751):
  'The symbol "log10" is resolved.'

-- dlsym.py ---
import sys, os
from ctypes import *

if len(sys.argv) != 2:
sys.exit('Error: the symbol name is required.')
symbol = sys.argv[1]
libdl = CDLL('libdl.so')
libdl.dlopen.restype = c_void_p
libdl.dlsym.restype = c_void_p
hdle = libdl.dlopen(None, os.RTLD_NOW | RTLD_GLOBAL)
if hdle is None:
print('Cannot get a handle on the global symbol object.')
else:
v = libdl.dlsym(c_void_p(hdle), symbol.encode())
_not = 'not ' if v is None else ''
print('The symbol "%s" is %sresolved.' % (symbol, _not))
---

This is as expected since the python executable is linked with the math 
library. However on Android API 21 importing _decimal fails with the error 
message reported earlier:
  'dlopen failed: cannot locate symbol "log10"'.

So this seems to be a bug with Android dlopen() at API 21 since the 'log10' 
symbol does exist in the process image relocation tables as shown by dlsym.py. 
This is confirmed by the fact that the import does not fail anymore at API 24 
(still without changeset b60b46ad8751). This change of behavior may be a side 
effect of the changes reported in this bionic (Android libc) changelog entry:

https://android.googlesource.com/platform/bionic/+show/refs/heads/master/android-changes-for-ndk-developers.md#36

For completness, my (possibly wrong) interpretation of why changeset 
b60b46ad8751 fixes the problem at API 21:
Changeset b60b46ad8751 adds the '-lm' command line option to the linker and 
this adds [1] a new DT_NEEDED entry to the .dynamic section of the shared 
library ELF file as shown by the command 'readelf -d 
build/lib.linux-x86_64-3.7-pydebug/_decimal.cpython-37dm-x86_64-linux-gnu.so':

Dynamic section at offset 0x54d30 contains 26 entries:
  TagType Name/Value
 0x0001 (NEEDED) Shared library: [libm.so.6]
 0x0001 (NEEDED) Shared library: [libpthread.so.0]
 0x0001 (NEEDED) Shared library: [libc.so.6]
 ...

The Android loader lookup for 'log10' is now successful at API 21 and the 
symbol is found in the libm.so.6 library listed in the DT_NEEDED lists of 
needed libraries.

[1] See option '--as-needed' in the 'ld' man pages or see the ELF 
specification. Note that the Android toolchains use the clang compiler but 
continue to use the GNU binutils tools including the linker 'ld'.

--

___
Python tracker 

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

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()

[Alessandro Vesely]

Alessandro Vesely added the comment:

Neither I found CFWS in rfc2231.  In addition, rfc 2045 (Introduction) says 
that Content-Disposition —where filename is defined— cannot include comments.  
However, Content-Type can include RFC 822 comments, so the filename should be 
de-commented in case it is inferred from the name parameter there.

I'm rather new to Python, and sticking to version 2 because of the packages I 
work with.  I see Python3's email has a much more robust design.  Does this 
mean Python2 cannot get fixed?

I attach a de_comment() function, copied from the one I mentioned this morning. 
 The rest of the file shows its intended use.  (Oops, it removes comments even 
from where they are not supposed to be allowed ;-)
Having that kind of functionality in email.utils would make it easier to read 
Message's, no?

--
Added file: http://bugs.python.org/file46551/attachments.py

___
Python tracker 

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

[issue29466] pickle does not serialize Exception __cause__ field

[Mark Diekhans]

Changes by Mark Diekhans :


--
nosy: +alexandre.vassalotti

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[George King]

George King added the comment:

I'm not sure exactly, but the way I see it (for code coverage), we want to 
trace transitions between basic blocks. So I would define it as: each entry 
into a BB is traced, with a tuple of (previous_offset, current_offset). This 
way when a function call starts, we callback with (-1, 0), and then get a 
callback for every transition between BBs. The code is well covered if we 
observe every possible transition.

I am not clear on the precise details, e.g. regarding unconditional branches. 
Since for code coverage this is essentially on optimization over 
per-instruction mode, I intend to first work out correctness details and test 
cases for the coverage tool, and then once the tests solid add the optimization.

I'm happy to discuss more, but this aspect is a lower priority for me (I still 
have to work out remaining correctness issues with my opcode analysis). Would 
it make sense to split it out into a second issue?

--

___
Python tracker 

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

[issue29425] File-altering aspects of pathlib should return new pathlib objects

[Brett Cannon]

Brett Cannon added the comment:

The idea in general seems reasonable. Anyone else have an opinion?

--
nosy: +brett.cannon

___
Python tracker 

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

[issue29466] pickle does not serialize Exception __cause__ field

[Mark Diekhans]

New submission from Mark Diekhans:

python3 pickle does not serialize the __cause__ field, as shown by the attached 
demo program.

--
components: Library (Lib)
files: cause_pickle.py
messages: 287163
nosy: diekhans
priority: normal
severity: normal
status: open
title: pickle does not serialize Exception __cause__ field
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file46550/cause_pickle.py

___
Python tracker 

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

[issue24905] Allow incremental I/O to blobs in sqlite3

[Aviv Palivoda]

Aviv Palivoda added the comment:

Uploading patch after fixes from berker CR.

The `blob_open` API can can have the following options:

1. The table, column and row must be mandatory parameters.
2. The read/write permissions can have the following options:
   a. No default (mandatory parameter).
   b. default read-only
   c. default write-only
3. The dbname can be without a default of "main" and then it will be a 
mandatory parameter.

I don't think that there is enough differences between the possible API's to 
justify sending a message to the mailing lists.

--
Added file: http://bugs.python.org/file46549/blob4.patch

___
Python tracker 

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

[issue29455] Mention coverage.py in trace module documentation

[Marco Buttu]

Marco Buttu added the comment:

Thank you Brett, here is another patch. I added the seealso directive right 
after the introduction of the trace module, in the same way as urllib.request 
does for requests.

--
Added file: http://bugs.python.org/file46548/issue29455_2nd.patch

___
Python tracker 

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

[issue29441] Update examples to use async and await keywords in asyncio-task.rst

[Guido van Rossum]

Guido van Rossum added the comment:

LGTM. Thanks!

--

___
Python tracker 

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

[issue29455] Mention coverage.py in trace module documentation

[Brett Cannon]

Brett Cannon added the comment:

Thanks for the patch, Marco! Typically we put the mention at the top to give 
the 3rd-party library a better chance of being noticed (see the urllib.request 
docs to see how requests is mentioned).

--
assignee: docs@python -> brett.cannon

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[STINNER Victor]

STINNER Victor added the comment:

> I did it this way because I would like to consider adding a third mode, which 
> would only trigger tracing for interesting control-flow events, namely steps 
> for which the previous instruction was a branch.

Hum, let's use https://en.wikipedia.org/wiki/Basic_block terminology.

The callback would be called when you enter and exit a basic block? Or only on 
exit?

Only on conditional branches? Or also on unconditional branches?

In term of instructions, can give examples of instructions which would be 
traced or not?

IMHO the two instruction level modes would be useful.

--

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[George King]

George King added the comment:

Attached is a new patch, which does not settrace/gettrace and instead offers 
new settraceinst/gettraceinst per Victor's recommendation.

I did not implement the proposed behavior of raising an exception if the old 
APIs are used when the inst_tracing flag is set. However I do think it makes 
sense to do so.

The new sys.settraceinst function takes two arguments: a function and an 
integer flag that is currently interpreted as a boolean (whether or not to 
enable instruction level tracing).

I did it this way because I would like to consider adding a third mode, which 
would only trigger tracing for interesting control-flow events, namely steps 
for which the previous instruction was a branch. The motivation is that I 
expect per-instruction tracing to be very slow, and for the code coverage use 
case at least, these are the interesting events. For this to be useful, a 
(prev_offset, current_offset) pair would need to be passed as to the trace 
callback. I am not sure if this would be useful to other applications, e.g. pdb.

--
Added file: http://bugs.python.org/file46547/settraceinst.diff

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

[STINNER Victor]

STINNER Victor added the comment:

I measured the stack consumption, it's not better. But I created the issue 
#29465 "Add _PyObject_FastCall() to reduce stack consumption" which would allow 
to reduce the stack consumption with this patch.

--

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

[STINNER Victor]

STINNER Victor added the comment:

> We can avoid breaking backward compatibility and introduce new call method 
> METH_FASTCALL_NO_KEYWORDS. But combining existing flags looks better to me. 
> FASTCALL is not a part of stable ABI.

If we decide that having two FASTCALL calling convention, I prefer what you 
proposed: METH_FASTCALL (pos only) and METH_FASTCALL|METH_KEYWORDS (pos+kw). As 
you wrote, I like reusing the existing METH_KEYWORDS flag, it reduces the 
surprises if someone ports existing code using METH_VARARGS and 
METH_VARARGS|METH_KEYWORDS.

--

___
Python tracker 

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

[issue29465] Add _PyObject_FastCall() to reduce stack consumption

[STINNER Victor]

STINNER Victor added the comment:

meth_fastcall_stacksize.patch: Patch adding 
_testcapi.meth_fastcall_stacksize() to measure the stack usage to call a 
METH_FASTCALL function.

--
Added file: http://bugs.python.org/file46546/meth_fastcall_stacksize.patch

___
Python tracker 

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

[issue29465] Add _PyObject_FastCall() to reduce stack consumption

[STINNER Victor]

New submission from STINNER Victor:

While testing issue #29464 patch, I failed to see a major enhancement on the 
stack usage of fast calls without keyword arguments.

The problem is that functions like _PyObject_FastCallKeywords() and 
_PyObject_FastCallDict() still have to pass a NULL argument for kwargs/kwnames, 
and have code to handle keyword arguments.


Attached patch adds _PyObject_FastCall() to reduce the stack consumption. At 
the C level, keyword arguments are almost never used. For example, 
PyObject_CallFunctionObjArgs() is commonly used, whereas it only uses 
positional arguments.

The patch changes also _PyObject_FastCallKeywords() and 
_PyObject_FastCallDict() to move the "slow" path creating temporary tuple and 
dict in a subfunction which is not inlined. The slow path requires more stack 
memory.

Morecall, _PyObject_FastCallKeywords() and _PyObject_FastCallDict() are 
modified to call _PyObject_FastCall() if there is no keyword.

The patch might make function calls without keyword arguments faster, I didn't 
check.


Stack usage.

$ ./python -c 'import _testcapi, sys; sys.setrecursionlimit(10**5); n=1000; 
s=_testcapi.meth_fastcall_stacksize(n); print("%.1f B/call" % (s/n))'

* Reference: 832.8 B/call
* Patch: 656.6 B/call (-176.2 B)

I don't know why the stack usage is not an integer number of bytes?


Combined with the issue #29464 "Specialize FASTCALL for functions with 
positional-only parameters", the stack usage can be even more reduced by a few 
bytes.


See the issue #28870 for the previous work on reducing stack consumption.

--
components: Interpreter Core
files: pyobject_fastcall.patch
keywords: patch
messages: 287153
nosy: haypo, inada.naoki, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add _PyObject_FastCall() to reduce stack consumption
type: resource usage
versions: Python 3.7
Added file: http://bugs.python.org/file46545/pyobject_fastcall.patch

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

[Stefan Krah]

Stefan Krah added the comment:

Adding Stefan Behnel, perhaps Cython doesn't need backwards compatibility.

--
nosy: +scoder, skrah

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

[STINNER Victor]

STINNER Victor added the comment:

> I still didn't do any benchmarking or stack usage measurements.

I'm running benchmarks on the speed-python server.

--

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

We can avoid breaking backward compatibility and introduce new call method 
METH_FASTCALL_NO_KEYWORDS. But combining existing flags looks better to me. 
FASTCALL is not a part of stable ABI.

I still didn't do any benchmarking or stack usage measurements.

--

___
Python tracker 

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

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

[STINNER Victor]

STINNER Victor added the comment:

Oh ok, it seems like Serhiy wants to change METH_FASTCALL. I didn't know :-) He 
just opened the issue #29464: "Specialize FASTCALL for functions with 
positional-only parameters". Interesting idea.

--

___
Python tracker 

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

[issue29461] Experiment usage of likely/unlikely in CPython core

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I also always wanted to experiment this change. But I was afraid that providing 
such macros can encourage of overusing it. I don't want to wrap any test for 
NULL or -1 with these macros.

If we expect some benefit from using these macros, I would play with them in 
hot loops. For example in dict lookup function (unlikely comparing keys raise 
an exception or dict is modified in process of searching), in codecs (unlikely 
illegal sequence is occurred), etc.

--

___
Python tracker 

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

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate

[Roundup Robot]

Roundup Robot added the comment:


New changeset 55949f988dc1b943796d9852cc4d588c58cc4255 by Victor Stinner in 
branch 'master':
Optimize deque index, insert and rotate() methods
https://github.com/python/cpython/commit/55949f988dc1b943796d9852cc4d588c58cc4255


--

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

[STINNER Victor]

STINNER Victor added the comment:

> Proposed patch renames METH_FASTCALL to METH_FASTCALL|METH_KEYWORDS and makes 
> bare METH_FASTCALL be used for functions with positional-only parameters.

While I tried to keep everything related to FASTCALL private, it seems like 
Cython uses some FASTCALL features. I don't know which ones exactly. Well, if 
only one project in the world uses FASTCALL, we can help them to support such 
backward incompatible change ;-)


> This eliminates small cost that these functions pay for handling empty 
> keywords: calling _PyStack_UnpackDict() and _PyArg_NoStackKeywords(), passing 
> kwnames.

My idea when I designed FASTCALL was to move code to parse arguments in the 
function body rather than in _PyCFunction_FastCallKeywords(), and to have a 
single calling function METH_FASTCALL, rather than two (METH_FASTCALL and 
METH_FASTCALL|METH_KEYWORDS).

The long term plan is also to support passing arguments by keyword in more 
functions. IMHO many functions don't accept keywords for technical reasons, but 
once we converted a module, function or type to Argument Clinic, it becomes 
trivial to accept keywords. If most functions accept keywords, I'm not sure 
that having a special case for positional-only is still worth it. But this plan 
was before I had discussions on supporting keywords in unicode methods. In 
fact, it's deliberate to not accept keywords in many functions or methods.

Well, when I see your patch, I see that it removes a lot of code. So it's 
likely to be a good idea :-)


> This also can slightly reduce stack consumption.

You mean the removal of the "PyObject *kwnames" for METH_FASTCALL (positional 
arguments only)? Do you have an idea of the stack usage? Try maybe 
testcapi_stacksize.patch of the issue #28870? It would help to take a decision 
on this change.

--

___
Python tracker 

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

[issue29461] Experiment usage of likely/unlikely in CPython core

[Christian Heimes]

Christian Heimes added the comment:

I would expect that PGO/LGO builds give better improvements with less coding 
bloat. Did you compare a PGO likely/unlikely build against a standard PGO build?

--

___
Python tracker 

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

[issue29461] Experiment usage of likely/unlikely in CPython core

[Raymond Hettinger]

Raymond Hettinger added the comment:

I had read that likely/unlikely were hard to use well and often not worth the 
trouble.   IIRC, they are used extensively in the Linux kernel but people were 
finding zero measurable effect when enabling or disabling the constructs.

--
nosy: +rhettinger

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Proposed patch renames METH_FASTCALL to METH_FASTCALL|METH_KEYWORDS and makes 
bare METH_FASTCALL be used for functions with positional-only parameters. This 
eliminates small cost that these functions pay for handling empty keywords: 
calling _PyStack_UnpackDict() and _PyArg_NoStackKeywords(), passing kwnames. 
This also can slightly reduce stack consumption.

--
components: Interpreter Core
files: fastcall-no-keywords.patch
keywords: patch
messages: 287143
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Specialize FASTCALL for functions with positional-only parameters
type: performance
versions: Python 3.7
Added file: http://bugs.python.org/file46544/fastcall-no-keywords.patch

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +haypo

___
Python tracker 

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

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate

[STINNER Victor]

STINNER Victor added the comment:

Raymond: "Yes, go ahead and apply."

Great, done. Thanks for the reviews Serhiy and Raymond.

As I wrote, you can consider to use Argument Clinic later, but there is no 
urgency for that ;-) I close the issue.

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1c048539200c by Victor Stinner in branch 'default':
Optimize deque index, insert and rotate() methods
https://hg.python.org/cpython/rev/1c048539200c

--
nosy: +python-dev

___
Python tracker 

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

[issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like

[STINNER Victor]

Changes by STINNER Victor :


--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue26355] Emit major version based canonical URLs for docs

[Nick Coghlan]

Nick Coghlan added the comment:

Thanks Matthias!

Regarding 2v3, the layout differences aren't a problem, since the canonical 
URLs are separate (/2/* vs /3/*). That's one of the benefits I actually hope 
for with this change - due to PEP 430, deep links still go to the Python 2 
documentation by default, and once this change is made in the Python 2.7 branch 
it should teach search engines that those should start being presented in 
results as "/2/*" qualified links.

We also don't tend to make wholesale changes to the URL layouts in the docs in 
X.Y releases, so I think the assumption of "the relative path of this page 
won't change" is fine.

Georg, Berker - any further thoughts before we make this change to 3.4+ and the 
2.7 docs?

--

___
Python tracker 

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

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate

[Raymond Hettinger]

Raymond Hettinger added the comment:

Yes, go ahead and apply.

--

___
Python tracker 

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

[issue29453] Remove reference to undefined dictionary ordering in Tutorial

[Jim Fasarakis-Hilliard]

Jim Fasarakis-Hilliard added the comment:

> But maybe it is worth to mention that the output corresponds to the order of 
> passed keyword arguments
 
Should I add this note? It looks fine to me as is but I'm not the experienced 
one here :-)

--

___
Python tracker 

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

[issue27051] Create PIP gui

[Nick Coghlan]

Nick Coghlan added the comment:

Regarding pip installability, the intended beneficiaries of that are:

* folks *collaborating* on the GUI, since it means it can be installed into 
virtual environments, tested across multiple versions with tox, etc
* developers that would like a pip GUI, and already know how to use "pipsi" to 
install command line applications from PyPI into their own virtual environments
* folks *distributing* the GUI, since being pip installable means that various 
tools like pyp2rpm, PyInstaller, etc, should be better able to work with it

You can look at the PyPA sample project for more guidance on getting started 
with that: https://github.com/pypa/sampleproject

--

___
Python tracker 

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

[issue29463] Change docstring to attribute from first statement.

[INADA Naoki]

New submission from INADA Naoki:

spin off of #11549.

http://bugs.python.org/issue11549#msg130955

> b) Docstring is now an attribute of Module, FunctionDef and ClassDef, > 
> rather than a first statement. Docstring is a special syntactic 
> construction, it's not an executable code, so it makes sense to separate it. 
> Otherwise, optimizer would have to take extra care not to introduce, change 
> or remove docstring. For example:
>
>  def foo():
>"doc" + "string"
>
>Without optimizations foo doesn't have a docstring. After folding, however, 
>the first statement in foo is a string literal. This means that docstring 
>depends on the level of optimizations. Making it an attribute avoids the 
>problem.

--
files: ast-docstring.patch
keywords: patch
messages: 287136
nosy: haypo, inada.naoki
priority: normal
severity: normal
status: open
title: Change docstring to attribute from first statement.
versions: Python 3.7
Added file: http://bugs.python.org/file46543/ast-docstring.patch

___
Python tracker 

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

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()

[R. David Murray]

R. David Murray added the comment:

Oh, and the answer to you "why" is that the email package is only dealing with 
content semantically in address lists.  Everywhere else it is up to the library 
using program to interpret the structured headers.  In 2.7 the email package 
provides you the tools to process emails, but does not do very much hand 
holding.  The python3 email package tries to do a much better job; but, 
frankly, I skimped on handling comments and have done almost no testing of the 
code that theoretically handles them, since they are so rarely encountered in 
the wild.  Specifically they are supposed to be correctly parsed, but there is 
no way to access comment content and, as I said, there are few to zero tests 
that include comments to validate that syntactic handling. 

I would be interested in patches to complete the comment support in 
_header_value_parser in python3.

--

___
Python tracker 

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

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()

[R. David Murray]

R. David Murray added the comment:

My reading of rfc 2231 is that CFWS is not allowed in that position.  Can you 
explain your interpretation with specific cites to the RFC?

Also please provide an example of specific behavior of the email package that 
you think is incorrect.  An email processor should always be treating a 
filename as a dirty string, so I'm not clear on what you are worried about here.

--

___
Python tracker 

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

[issue23980] Documentation for format units starting with 'e' is inconsistent

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

[STINNER Victor]

STINNER Victor added the comment:

> If the API can still change (msg287083), I think I'll wait with this until 
> shortly before 3.7 beta.

I do not understand why Serhiy keeps repeating that the API is going to change, 
I have no such plan. IMHO the FASTCALL API is now very well defined: (PyObject 
**args, Py_ssize_t nargs, PyObject *kwnames), and helper functions are now well 
tested.

We might optimize Argument Clinic further, but for decimal, it seems like it's 
a no-no and that direct usage of METH_FASTCALL is preferred.

So no, I don't plan or expect any API change.

--

___
Python tracker 

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

[issue27659] Prohibit implicit C function declarations

[Roundup Robot]

Roundup Robot added the comment:


New changeset 9a26d20d2baa27407501b13435d733dcc26f3d53 by Victor Stinner in 
branch 'master':
Prohibit implicit C function declarations
https://github.com/python/cpython/commit/9a26d20d2baa27407501b13435d733dcc26f3d53


--

___
Python tracker 

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

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

[Stefan Krah]

Stefan Krah added the comment:

If the API can still change (msg287083), I think I'll wait with this until 
shortly before 3.7 beta.

--

___
Python tracker 

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

[issue27659] Prohibit implicit C function declarations

[STINNER Victor]

STINNER Victor added the comment:

Oh by the way, if someone sees a build error because of a missing function 
declaration, please report a new issue.

--

___
Python tracker 

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

[issue29457] strftime('%x') does not use my locale

[R. David Murray]

R. David Murray added the comment:

Yes, it is the default behavior, because the default locale, as for most 
(almost all?) programming languages (not just Python), is the C locale, until 
you change it.  The reason for this is to get consistent behavior no matter 
what the locale is set to, unless you explicitly enable the local locale (or 
some other locale) in your program.

Whether it is worth adding a link is a separate question, but we really don't 
get this question often, unlike some other FAQs.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue27659] Prohibit implicit C function declarations

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

> If yes, can we close the issue?

Yes and thanks! As a side note, on Android it prevents broken 
grp.cpython-37m.so, too.

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue27659] Prohibit implicit C function declarations

[STINNER Victor]

STINNER Victor added the comment:

Martin Panter: "If there is an obscure platform where we don’t include the 
right header file for a function, changing the warning into an error would 
cause the build to fail."

In my experience, calling a function which was not declared is very likely to 
cause a bug, or a crash in the worst case. For example, on 64-bit, if the 
return type is a pointer, the C compiler uses the int type by default, whereas 
a pointer is 32-bit, not 64-bit, and so it will immediately crash.

Martin: "If we do make it an error, it should only be so for 3.7."

Ok. I pushed the patch to Python 3.6.


@Chi Hsuan Yen: Thanks for the patch! Is this change enough to fix the crypt 
build issue? If yes, can we close the issue?

It is likely that the cause causes compilation errors on some platforms where 
we call non-existent functions or call functions with a missing header. IMHO 
it's a good thing to get a build error rather than a crash at runtime.

A concrete issue is that the compilation of the curses module will probably 
fails now on Solaris: issue #13552, whereas before the build only emitted 
warnings. The curses module is broken for years on Solaris, and it seems like 
nobody is able to fix it, so it's not a big deal.

--

___
Python tracker 

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

[issue27659] Prohibit implicit C function declarations

[Roundup Robot]

Roundup Robot added the comment:

New changeset ca2f024ce7cb by Victor Stinner in branch 'default':
Prohibit implicit C function declarations
https://hg.python.org/cpython/rev/ca2f024ce7cb

--
nosy: +python-dev

___
Python tracker 

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

[issue29300] Modify the _struct module to use FASTCALL and Argument Clinic

[STINNER Victor]

STINNER Victor added the comment:

@Serhiy: Can we please now close this issue? Or is there still something to do?

--

___
Python tracker 

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

[issue26901] Argument Clinic test is broken

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue29362] regrtest: don't fail immediately if a child does crash

[STINNER Victor]

STINNER Victor added the comment:

I fixed regrtest in Python 3.7. Maybe I will backport the fix later to other 
branches, but I prefer to limit regrtest changes in stable branches.

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

[Alex Gaynor]

Changes by Alex Gaynor :


--
nosy:  -alex

___
Python tracker 

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

[issue29362] regrtest: don't fail immediately if a child does crash

[Roundup Robot]

Roundup Robot added the comment:


New changeset 99e4e687145a76ac28055a651ee31470496c3ac7 by Victor Stinner in 
branch 'master':
regrtest: don't fail immediately if a child does crash
https://github.com/python/cpython/commit/99e4e687145a76ac28055a651ee31470496c3ac7


--

___
Python tracker 

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

[issue29362] regrtest: don't fail immediately if a child does crash

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4446613000a3 by Victor Stinner in branch 'default':
regrtest: don't fail immediately if a child does crash
https://hg.python.org/cpython/rev/4446613000a3

--
nosy: +python-dev

___
Python tracker 

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

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

[STINNER Victor]

STINNER Victor added the comment:

Naoki: Can you please open a new issue for your ast-docstring.patch change? I 
like it, but this issue became too big, and I'm not sure that everyone in the 
nosy list is interested by this specific change.

--

___
Python tracker 

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

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

[INADA Naoki]

INADA Naoki added the comment:

I've tried to update ast_opt.c[t] without changing AST.
But I can't find clear way to solve "foo" + "bar" docstring problem.

This patch adds only docstring to AST.

--
Added file: http://bugs.python.org/file46542/ast-docstring.patch

___
Python tracker 

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

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()

[Alessandro Vesely]

New submission from Alessandro Vesely:

Comments are allowed almost everywhere in an email message, and should be 
eliminated before attributing any meaning to a field.  In the words of RFC5322, 
any CRLF that appears in FWS is semantically "invisible".

In particular, some note that comments can be used to deceive an email filter.  
For example, like so:

Content-Disposition: attachment;
 filename=''attached%2E";
 filename*1*="%62";
 filename*2=(fool filters)at

(I don't know which, if any, email clients would execute that batch...)

Anyway, removing comments is needed for any structured header field.  One is 
usually interested in the unfolded, de-commented value.  It is difficult to do 
correctly, because of nesting and quoting possibilities.

This issue seems to be ignored, except for address lists (there is a 
getcomment() member in AddrlistClass).  Why?

--
components: email
messages: 287119
nosy: ale2017, barry, r.david.murray
priority: normal
severity: normal
status: open
title: RFC822-comments in email header fields can fool, e.g., get_filename()
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue24459] Mention PYTHONFAULTHANDLER in the man page

[Berker Peksag]

Changes by Berker Peksag :


Added file: http://bugs.python.org/file46541/issue24459_cleanup_2.diff

___
Python tracker 

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

[issue29461] Experiment usage of likely/unlikely in CPython core

[STINNER Victor]

STINNER Victor added the comment:

Benchmarks with Python compiled by gcc -O3 (without PGO).

haypo@smithers$ ./python -m perf timeit 'len("abc")' --duplicate=1000 
--compare-to=../default-ref/python
Median +- std dev: [ref] 40.4 ns +- 0.8 ns -> [likely] 40.8 ns +- 2.1 ns: 1.01x 
slower (+1%)

haypo@smithers$ ./python -m perf timeit 'sum(())' --duplicate=1000 
--compare-to=../default-ref/python -p3
Median +- std dev: [ref] 86.4 ns +- 2.8 ns -> [likely] 86.3 ns +- 0.3 ns: 1.00x 
faster (-0%)
Not significant!

haypo@smithers$ ./python -m perf timeit -s 's=list("abc")' 'sorted(s)' 
--duplicate=100 --compare-to=../default-ref/python -p3
Median +- std dev: [ref] 224 ns +- 3 ns -> [likely] 222 ns +- 1 ns: 1.01x 
faster (-1%)

--

___
Python tracker 

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

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate

[STINNER Victor]

STINNER Victor added the comment:

> Over this looks good.  Just one other minor tweak (one that has served me 
> well elsewhere) would be to bypass the cross-module function call with a 
> cheap (near zero cost) register variable test: (...)

This has just been optimized by Serhiy, change 82d1c8d15e18.

So, is deque-2.patch good now?

--

___
Python tracker 

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

[issue24459] Mention PYTHONFAULTHANDLER in the man page

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the patch and sorry for my late response. I did some tweaks and am 
planning to commit the tweaked version of your patch this week.

--
Added file: http://bugs.python.org/file46540/issue24459_cleanup.diff

___
Python tracker 

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

[issue29461] Experiment usage of likely/unlikely in CPython core

[STINNER Victor]

STINNER Victor added the comment:

http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html

Using __builtin_expect() in a very long loop 10^9 iteratos (1,000,000,000) 
makes the loop 15% faster (2.67 sec => 2.28 sec), *but*  using PGO avoids the 
need of using __builtin_expect() explicitly and makes the code 27% faster (2.67 
sec => 1.95 sec):

"This optimized version runs significantly faster (1.95 versus 2.28 seconds) 
than our version that used __builtin_expect(). This is because, in addition to 
the branching in the if statement, the branching in the for loops was also 
optimized."

The article also confirms that if __builtin_expect() is misused, it makes the 
code 5% slower (2.67 sec => 2.79 sec).

--

Another story related to micro-optimization in the Linux kernel.

The Linux kernel used explicit prefetch in some tiny loops. After many 
benchmarks, it was concluded that letting the developer uses prefetch makes the 
code slower, and so the micro-optimization was removed:

https://lwn.net/Articles/444336/

“So the conclusion is: prefetches are absolutely toxic, even if the NULL ones 
are excluded.”

--

___
Python tracker 

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