[issue26106] Move licences to literal blocks

[Roundup Robot]

Roundup Robot added the comment:

New changeset a04d9589e2c4 by Victor Stinner in branch '3.5':
Issue #26106: doc: Move text of licenses to parsed literal block
https://hg.python.org/cpython/rev/a04d9589e2c4

--
nosy: +python-dev

___
Python tracker 

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

[issue22872] multiprocessing.Queue raises AssertionError

[Berker Peksag]

Berker Peksag added the comment:

See issue 5001 for more general cleanup in multiprocessing.

> [...] (2) altering the behavior in a new release version (perhaps 3.6 when it 
> comes) and documenting that change appropriately there.

+1. We can also document AssertionError in older Python versions.

--
stage:  -> needs patch

___
Python tracker 

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

[issue26171] heap overflow in zipimporter module

[Roundup Robot]

Roundup Robot added the comment:

New changeset 01ddd608b85c by Benjamin Peterson in branch '3.4':
prevent buffer overflow in get_data (closes #26171)
https://hg.python.org/cpython/rev/01ddd608b85c

New changeset 985fc64c60d6 by Benjamin Peterson in branch '2.7':
prevent buffer overflow in get_data (closes #26171)
https://hg.python.org/cpython/rev/985fc64c60d6

New changeset 10dad6da1b28 by Benjamin Peterson in branch '3.5':
merge 3.4 (#26171)
https://hg.python.org/cpython/rev/10dad6da1b28

New changeset 2df462852464 by Benjamin Peterson in branch 'default':
merge 3.5 (#26171)
https://hg.python.org/cpython/rev/2df462852464

--
nosy: +python-dev
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

[issue26172] iBook can't open ePub

[Roundup Robot]

Roundup Robot added the comment:

New changeset 562179b7912f by Benjamin Peterson in branch '3.4':
remove script from epub (closes #26172)
https://hg.python.org/cpython/rev/562179b7912f

New changeset 56e68089ad65 by Benjamin Peterson in branch '3.5':
merge 3.4 (#26172)
https://hg.python.org/cpython/rev/56e68089ad65

New changeset 68ec50003aca by Benjamin Peterson in branch 'default':
merge 3.5 (#26172)
https://hg.python.org/cpython/rev/68ec50003aca

--
nosy: +python-dev
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

[issue26172] iBook can't open ePub

[INADA Naoki]

New submission from INADA Naoki:

Script cannot run in iBook is included in ePub.
Attached patch resolves the issue.

--
assignee: docs@python
components: Documentation
files: epub.patch
keywords: patch
messages: 258734
nosy: docs@python, naoki
priority: normal
severity: normal
status: open
title: iBook can't open ePub
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41678/epub.patch

___
Python tracker 

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

[issue26171] heap overflow in zipimporter module

[Insu Yun]

New submission from Insu Yun:

in zipimport.c
  1116 bytes_size = compress == 0 ? data_size : data_size + 1;
  1117 if (bytes_size == 0)
  1118 bytes_size++;
  1119 raw_data = PyBytes_FromStringAndSize((char *)NULL, bytes_size);

If compress != 0, then bytes_size = data_size + 1
data_size is not sanitized, so if data_size = -1, then it overflows and becomes 
0.
In that case bytes_size becomes 1 and python allocates small heap, but after 
that in fread, it overflows heap.

--
files: crash.py
messages: 258733
nosy: Insu Yun
priority: normal
severity: normal
status: open
title: heap overflow in zipimporter module
type: security
versions: Python 3.6
Added file: http://bugs.python.org/file41677/crash.py

___
Python tracker 

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

[issue26169] Pasting 900000 chars into a tk Entry widget fails

[Terry J. Reedy]

New submission from Terry J. Reedy:

'\x41' == 'A'.  I don't know what 'BOF' has to do with the character 'A' or a 
string of them.

A python or pythonw process 'hanging' does not itself mean that there is a 
buffer overflow, though I can understand why you suspect it.  Python itself is 
pretty much immune from buffer overflows, but C code is not ;-).

IDLE crashing is not necessarily an IDLE issue.  IDLE is a application written 
in Python, including tkinter, which runs tcl/tk code.  It is just as vulnerable 
to Python, tkinter, and tcl/tk bugs and liminations as any other application.  
This appears to be an issue about the limitations of the tcl/tk Entry widget.

When I followed the procedure posted with 3.5.1 on 64 bit Win 10 and pasted the 
megastring into the tk Entry box, the box stayed blank and a blue circle 
'waiting' cursor appeared.  Even if the string was copied from the clipboard 
into process memory, it exceeded the (undocumented?) limits of the widget.

This behavior can be reproduced independently of IDLE with

import tkinter as tk
root = tk.Tk()
entry = tk.Entry(root)
entry.pack()
root.mainloop()

The latter has been waiting for several minutes.  This does not surprise me.

When I clicked the Search dialog Find-next button, the dialog box turned the 
whitish gray, all too familiar to me, that indicates that a process is no 
longer responsive.  This also does not surprise me.  The click causes the 
associated Python callback to be called.  It tries to get the Entry box text 
that is likely not available, compile it as a regex with re, and then search 
the editor text. 

Since we do not control tk Entry widgets, I am inclined to close this as '3rd 
party'.  Serhiy, what do you think?

PS: the test Entry box is still waiting.  Trying to close it fails and brings 
up a 'Python is not responding' box as in the screenshot.  I has to kill the 
process with Task Manager, just as with the IDLE Search window.

--
components: +Tkinter -IDLE
nosy: +serhiy.storchaka -kbk, roger.serwy
title: Buffer OverFlow in IDLE 2.7.11 -> Pasting 90 chars into a tk Entry 
widget fails
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

[issue26167] Improve copy.copy speed for built-in types (list/set/dict)

[Josh Rosenberg]

Josh Rosenberg added the comment:

Good point. Though I don't see any attached patches...

--

___
Python tracker 

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Jason R. Coombs]

Jason R. Coombs added the comment:

I believe this behavior (presence of the __PYVENV_LAUNCHER__ and inheritance in 
child processes) continues to cause problems. See 
https://github.com/pypa/virtualenv/issues/845 for a simple reproducing of the 
issue, even on pip 6+.

--
nosy: +jason.coombs

___
Python tracker 

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

[issue25704] Update the devguide to 3.5

[Berker Peksag]

Berker Peksag added the comment:

Thanks, Stéphane! Ned applied most of your patch in f53eac8da0b8. I left "sudo 
apt-get build-dep python3.4" as is since python3.5 is not available in the 
latest LTS release of Ubuntu.

--
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

[issue25704] Update the devguide to 3.5

[Roundup Robot]

Roundup Robot added the comment:

New changeset 32545ee8d673 by Berker Peksag in branch 'default':
Issue #25704: Update Python version to 3.5 where appropriate
https://hg.python.org/devguide/rev/32545ee8d673

--
nosy: +python-dev

___
Python tracker 

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

[issue26170] pip Crash on Unpacking in get_platform() line 119

[Berker Peksag]

Changes by Berker Peksag :


--
stage:  -> resolved
type: crash -> behavior

___
Python tracker 

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

[issue26170] pip Crash on Unpacking in get_platform() line 119

[Donald Stufft]

Donald Stufft added the comment:

Hey,

This is actually a bug with pip not with CPython and is being tracked by 
https://github.com/pypa/pip/issues/3408. It's fixed in pip's repository and 
we'll soon have an 8.0.1 release out to fix it.

--
nosy: +dstufft
resolution:  -> third party
status: open -> closed

___
Python tracker 

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

[issue26170] pip Crash on Unpacking in get_platform() line 119

[Vinyl Darkscratch-Kazotetsu]

New submission from Vinyl Darkscratch-Kazotetsu:

Since upgrading to pip 8.0, I get a crash whenever I try to run it.  It fails 
to unpack to major, minor, and micro for the release, saying there's only two 
values.

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/bin/pip", line 7, in 

from pip import main
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/__init__.py",
 line 15, in 
from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/vcs/subversion.py",
 line 9, in 
from pip.index import Link
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/index.py",
 line 29, in 
from pip.wheel import Wheel, wheel_ext
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/wheel.py",
 line 32, in 
from pip import pep425tags
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/pep425tags.py",
 line 214, in 
supported_tags = get_supported()
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/pep425tags.py",
 line 162, in get_supported
arch = get_platform()
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/pep425tags.py",
 line 119, in get_platform
major, minor, micro = release.split('.')
ValueError: need more than 2 values to unpack

--
components: Macintosh
messages: 258726
nosy: Vinyl Darkscratch-Kazotetsu, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: pip Crash on Unpacking in get_platform() line 119
type: crash
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

[issue25843] code_richcompare() don't use constant type when comparing code constants

[STINNER Victor]

STINNER Victor added the comment:

Patch version 4:

Fix _PyCode_ConstantKey:

* always return a tuple
* create a frozenset/set if input is a set/frozenset, items are unordered
* enhance unit tests: compare values using repr() to compare value + type at 
once
* fix reference leak

Other minor changes to take Serhiy's comments in account.

Thanks Serhiy for good suggestions!

--
Added file: http://bugs.python.org/file41676/code_richcompare-4.patch

___
Python tracker 

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

[issue25843] code_richcompare() don't use constant type when comparing code constants

[STINNER Victor]

STINNER Victor added the comment:

And sorry, I missed your comments, it looks like some emails were seen as spam 
:-/

--

___
Python tracker 

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

[issue26169] Buffer OverFlow in IDLE 2.7.11

[Soufiane BOUSSALI]

Changes by Soufiane BOUSSALI :


--
title: Buffer OverFlow in IDLE -> Buffer OverFlow in IDLE 2.7.11

___
Python tracker 

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

[issue25591] refactor imaplib tests

[Maciej Szulik]

Maciej Szulik added the comment:

David I think I've re-implemented, using the new style, all the methods from 
ThreadedNetworkedTests and ThreadedNetworkedTestsSSL, the new classes are 
NewIMAPTests and NewIMAPSSLTests accordingly.

--
stage:  -> patch review
Added file: http://bugs.python.org/file41675/new_imap_tests_v3.diff

___
Python tracker 

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

[issue26152] A non-breaking space in a source

[Andrew Barnert]

Andrew Barnert added the comment:

> Assuming Andrew is correct, it sounds like the tokenizer is treating the NBSP 
> and the “2” as part of the same token, because NBSP is non-ASCII.

It's more complicated than that. When you get an invalid character, it splits 
the token up. So, in this case, you get a separate `ERRORTOKEN` from cols 2-3 
and `NUMBER` token from cols 3-4. Even in the case of `1, a\xa0\xa02`, you get 
a `NAME` token for the `a`, a separate `ERRORTOKEN` for each nbsp, and a 
`NUMBER` token for the `2`.

But I think the code that generates the `SyntaxError` must be trying to 
re-generate the "intended token" from the broken one. For example:

>>> eval('1\xa0\xa02a')
File "", line 1
  1  2a
      ^
SyntaxError: invalid character in identifier

And if you capture the error and look at it, `e.args[1][1:3]` is 1, 5, which 
matches what you see.

But if you tokenize it (e.g., 
`list(tokenize.tokenize(io.BytesIO('1\xa0\xa02a'.encode('utf-8')).readline))`, 
but you'll probably want to wrap that up in a function if you're playing with 
it a lot...), you get a `NUMBER` from 0-1, an `ERRORTOKEN` from 1-2, another 
`ERRORTOKEN` from 2-3, a `NUMBER` from 3-4, and a `NAME` from 4-5. So, why does 
the `SyntaxError` point at the `NAME` instead of the first `ERRORTOKEN`? 
Presumably there's some logic that tries to work out that the two 
`ERRORTOKEN`s, `NUMBER`, and `NAME` were all intended to be one big identifier 
and points at that instead.

--

___
Python tracker 

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

[issue24520] Stop using deprecated floating-point environment functions on FreeBSD

[STINNER Victor]

STINNER Victor added the comment:

"I expect the man page mentions it because it is mentioned in the standard. In 
the bugs section it does say the pragma is unimplemented."

Ah ah, funnny. Sorry, I was confused by the manual page.

I pushed your patch to Python 2.7, 3.5 and default (3.6) branches.

@koobs: sorry, 3.4 now only accept security fixes :-p

--

___
Python tracker 

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

[issue24520] Stop using deprecated floating-point environment functions on FreeBSD

[Roundup Robot]

Roundup Robot added the comment:

New changeset 76f35f35be50 by Victor Stinner in branch '3.5':
Replace fpgetmask() with fedisableexcept()
https://hg.python.org/cpython/rev/76f35f35be50

New changeset 6134d9ecab60 by Victor Stinner in branch 'default':
Merge 3.5 (issue #24520)
https://hg.python.org/cpython/rev/6134d9ecab60

New changeset 394ae9efc5c2 by Victor Stinner in branch '2.7':
Replace fpgetmask() with fedisableexcept()
https://hg.python.org/cpython/rev/394ae9efc5c2

--
nosy: +python-dev

___
Python tracker 

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

[issue26169] Buffer OverFlow in IDLE

[SilentGhost]

Changes by SilentGhost :


--
nosy: +kbk, roger.serwy, terry.reedy
title: Buffer OverFlow -> Buffer OverFlow in IDLE

___
Python tracker 

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

[issue26165] devguide: table summarizing status of Python branches

[STINNER Victor]

STINNER Victor added the comment:

> If possible, add Months or Quarter (Q1-4) for the EoL's, if those are 
> defined, would be great.

I added the estimated *day* of the end-of-line. But the release manager is free 
to adjust it.

> We @ FreeBSD/Python would like to proactively (as early as possible) set 
> DEPRECATED dates in our ports to ensure our users have ample time to upgrade 
> to later versions, ideally in cadence with Python.

You may start to deprecate as soon as a branch switches to security only fixes?

--

___
Python tracker 

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

[issue26165] devguide: table summarizing status of Python branches

[Roundup Robot]

Roundup Robot added the comment:

New changeset 75b95ada261f by Victor Stinner in branch 'default':
Add a table "Status of Python branches" to the front page
https://hg.python.org/devguide/rev/75b95ada261f

--
nosy: +python-dev

___
Python tracker 

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

[issue26165] devguide: table summarizing status of Python branches

[STINNER Victor]

STINNER Victor added the comment:

I pushed a first version of the table. It can be adjusted later if needed.

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

___
Python tracker 

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

[issue26169] Buffer OverFlow

[Soufiane BOUSSALI]

Changes by Soufiane BOUSSALI :


Added file: http://bugs.python.org/file41674/py2.7.11.png

___
Python tracker 

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

[issue26169] Buffer OverFlow

[Soufiane BOUSSALI]

Changes by Soufiane BOUSSALI :


--
components: IDLE
files: poc.py
nosy: Soufiane BOUSSALI
priority: normal
severity: normal
status: open
title: Buffer OverFlow
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file41673/poc.py

___
Python tracker 

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

[issue25520] unittest load_tests protocol not working as documented

[Stefan Seefeld]

Stefan Seefeld added the comment:

Hi, I'm investigating more issues related to test loading, and thus I have 
discovered issue #16662.

I have found quite a number of inconsistencies and bugs in the loading of 
tests. But without getting a sense of what the supposed behavior is I find it 
difficult to come up with workarounds and fixes.

Is there a place where these issues can be discussed (rather than just looking 
at each bug individually) ?

I'd ultimately like to be able to invoke

  `python -m unittest my.test.subpackage` 

and have unittest pick up all the tests within that recursively, with and 
without load_tests() functions.

(On a tangential note, I would also like to have a mode where the found tests 
are listed without being executed. I have hacked a pseudo-TestRunner that does 
that, but I'm not sure this is the best approach.)

Is there any place where the bigger picture can be discussed ?

Thanks,

--

___
Python tracker 

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

[issue26152] A non-breaking space in a source

[Adam Bartoš]

Adam Bartoš added the comment:

It could still point to the first or the last byte of the invalid token rather 
than to the start of the next token. Also, by the Python implementation of the 
tokenizer in tokenize module we get an ERRORTOKEN containing a non-breaking 
space followed by a number token containing 2.

--

___
Python tracker 

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

[issue26152] A non-breaking space in a source

[Martin Panter]

Martin Panter added the comment:

Assuming Andrew is correct, it sounds like the tokenizer is treating the NBSP 
and the “2” as part of the same token, because NBSP is non-ASCII.

--

___
Python tracker 

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

[issue26152] A non-breaking space in a source

[Adam Bartoš]

Adam Bartoš added the comment:

We have one particular invalid token, so why it should point to the next token 
rather than to the invalid one?

--

___
Python tracker 

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

[issue26167] Improve copy.copy speed for built-in types (list/set/dict)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

methodcaller is not needed. We can use just list.copy etc.

Proposed patch speeds up copying list, dict, set, bytearray, slice, 
NotImplemented. It makes deepcopying list, tuple, dict a little faster.  It 
makes the code for copying and deepcopying using reduce protocol cleaner and a 
little faster. It cleans up the module and adds new tests for builtin types.

--
assignee:  -> serhiy.storchaka
nosy: +alexandre.vassalotti, serhiy.storchaka
stage:  -> patch review
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

[issue26152] A non-breaking space in a source

[Martin Panter]

Martin Panter added the comment:

The caret always points to the end of the token, I think.

--
nosy: +martin.panter

___
Python tracker 

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

[issue26162] thread error

[Eryk Sun]

Eryk Sun added the comment:

It's no surprise to see a memory error at 845 threads if you're using 32-bit 
Python, which is limited to 2 GiB of address space. python.exe is built with a 
default stack reservation of 200 bytes, so 845 threads reserve a total of 
about 1.58 GiB. Consider also that address space is used by mapped DLLs and 
files, page tables, private data, the process heap(s), and additional worker 
threads. Plus if it's 64-bit Windows there's a 64-bit stack for each 32-bit 
thread. The 64-bit stack reserves 256 KiB, which totals an additional 0.2 GiB 
for 845 threads. Available space is also lost to fragmentation that leaves 
unusable blocks.

Why do you need so many threads instead of using a thread pool? If you *really* 
need that many threads and can't switch to 64-bit Python, you'll have to step 
outside what Python's built-in threading support offers. The following 
demonstrates calling Windows CreateThread via ctypes. I recommend against doing 
something like this.

import ctypes
from ctypes import wintypes

kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

CREATE_SUSPENDED = 0x0004
STACK_SIZE_PARAM_IS_A_RESERVATION = 0x0001

def check_handle(result, func, args):
if result is None:
raise ctypes.WinError(ctypes.get_last_error())
return args

def check_bool(result, func, args):
if not result:
raise ctypes.WinError(ctypes.get_last_error())
return None

wintypes.LPDWORD = ctypes.POINTER(wintypes.DWORD)
wintypes.SIZE_T = ctypes.c_size_t
LPSECURITY_ATTRIBUTES = ctypes.c_void_p
LPTHREAD_START_ROUTINE = ctypes.WINFUNCTYPE(wintypes.DWORD,
wintypes.LPVOID)

kernel32.CreateThread.errcheck = check_handle
kernel32.CreateThread.restype = wintypes.HANDLE
kernel32.CreateThread.argtypes = (
LPSECURITY_ATTRIBUTES,  # _In_opt_  lpThreadAttributes
wintypes.SIZE_T,# _In_  dwStackSize
LPTHREAD_START_ROUTINE, # _In_  lpStartAddress
wintypes.LPVOID,# _In_opt_  lpParameter
wintypes.DWORD, # _In_  dwCreationFlags
wintypes.LPDWORD,   # _Out_opt_ lpThreadId
)

kernel32.CloseHandle.errcheck = check_bool
kernel32.CloseHandle.argtypes = (wintypes.HANDLE,)

def CreateThread(lpStartAddress,
 lpParameter=None,
 dwStackSize=0,
 dwCreationFlags=STACK_SIZE_PARAM_IS_A_RESERVATION,
 lpThreadAttributes=None,
 close_handle=True):
tid = (wintypes.DWORD * 1)()
h = kernel32.CreateThread(lpThreadAttributes,
  dwStackSize,
  lpStartAddress,
  lpParameter,
  dwCreationFlags,
  tid)
if close_handle:
kernel32.CloseHandle(h)
return tid[0]
return h, tid[0]

For example, the following creates 2000 worker threads that each reserves 256 
KiB for the stack. Since I'm running 32-bit Python on 64-bit Windows, each 
thread has a corresponding 64-bit thread stack that also reserves 256 KiB. In 
total it reserves 1 GiB of stack space, which I confirmed using Sysinternals 
VMMap.

import time

@LPTHREAD_START_ROUTINE
def worker(param):
if param is None:
param = 0
# do some work
time.sleep(60)
return 0

tids = []
for i in range(2000):
tid = CreateThread(worker, i, 256*1024)
tids.append(tid)

--
nosy: +eryksun
resolution:  -> not a bug
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

[issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New failure

[Josh Rosenberg]

Changes by Josh Rosenberg :


--
nosy: +josh.r

___
Python tracker 

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

[issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New failure

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.5, Python 3.6

___
Python tracker 

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

[issue25007] Add support of copy protocol to zlib compressors and decompressors

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I agree with Josh. Needed __deepcopy__ and tests. And I think there may be 
problem with sharing a docstring (that includes a signature) between copy() and 
__copy__(). It is better to just add separate method that calls the 
implementation of copy().

--

___
Python tracker 

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

[issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New failure

[squidevil]

New submission from squidevil:

Expected behavior:
  Calling Py_BuildValue with a 'N' argument should take ownership of the N 
object, and on failure (returns NULL), call Py_DECREF() on any N argument.  The 
documentation explicitly says that this is the intended usage:
"N": Same as "O", except it doesn't increment the reference count on the 
object. Useful when the object is created by a call to an object constructor in 
the argument list.

Actual behavior:
  N objects appear to be abandoned/leaked in some cases.

Example: PyBuildValue("iN", 0, obj);

* calls _Py_BuildValue_SizeT via macro
* calls va_build_value (in modsupport.c)
* calls do_mktuple [0]
* [0] first calls v = PyTuple_New(n=2). If this fails, it returns NULL, leaking 
obj.
* if [0] creates the tuple v, then it goes on to populate the values in the 
tuple.
* [0] calls do_mkvalue() to create the "i=0" object.  If this fails, obj is 
never Py_DECREF()'ed.

Many other leaks are possible, as long as at least one allocation occurs prior 
to the processing of the N arguments.

--
components: Interpreter Core
messages: 258708
nosy: squidevil
priority: normal
severity: normal
status: open
title: Py_BuildValue may leak 'N' arguments on PyTuple_New failure
type: resource usage
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

[issue25843] code_richcompare() don't use constant type when comparing code constants

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

It looks to me that the patch makes set and frozenset constants to be equal, 
but makes sets with different order (as {2**62, 1} and {1, 2**62}) differ. And 
looks you had missed my comments to previous patches.

--
stage:  -> patch review
versions:  -Python 3.4

___
Python tracker 

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

[issue26167] Improve copy.copy speed for built-in types (list/set/dict)

[Josh Rosenberg]

Changes by Josh Rosenberg :


--
title: Improve copy.copy speed for built-in types -> Improve copy.copy speed 
for built-in types (list/set/dict)

___
Python tracker 

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

[issue25007] Add support of copy protocol to zlib compressors and decompressors

[Josh Rosenberg]

Josh Rosenberg added the comment:

Patch looks good, but incomplete. Supporting __deepcopy__ (as a simple wrapper 
around __copy__ that ignores the second argument) would provide complete 
support.

Also, should there be tests? I mean, I assume the .copy() method itself is 
tested, but just to detect stupid regressions, seems like testing 
__copy__/__deepcopy__ for identical behavior would be a good thing.

--
nosy: +josh.r

___
Python tracker 

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

[issue26166] zlib compressor/decompressor objects should support copy protocol

[Josh Rosenberg]

Josh Rosenberg added the comment:

Oops. Sorry. I swear I searched, but I can't figure out how I missed the 
obvious duplicate there.

--

___
Python tracker 

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

[issue26167] Improve copy.copy speed for built-in types

[Josh Rosenberg]

New submission from Josh Rosenberg:

copy.copy uses a relatively high overhead approach to copying list, set and 
dict, using:

def _copy_with_constructor(x):
return type(x)(x)

This is despite the fact that all three types implement a .copy() method, and 
there is already a defined method:

def _copy_with_copy_method(x):
return x.copy()

that (in %timeit tests) runs with substantially less overhead, in percentage 
terms; for empty lists, sets and dicts, calling _copy_with_constructor or 
_copy_with_copy_method directly on them, the times on my machine (Python 3.5.0, 
Linux x86-64) are:

empty list: 281 ns (constructor), 137 ns (method)
empty set: 275 ns (constructor), 175 ns (method)
empty dict: 372 ns (constructor), 211 ns (method)

The method costs could be trimmed further if _copy_with_copy_method was changed 
from a Python implementation to using operator.methodcaller, e.g.

try:
# If we have _operator, avoids cost of importing Python code; it's part 
of core modules in CPython, already loaded for free
from _operator import methodcaller  
except ImportError:
from operator import methodcaller

_copy_with_copy_method = methodcaller('copy')

This doesn't save a whole lot more (shaves another 9-17 ns off the times for 
the Python version of _copy_with_copy_method), but it's nice in that it avoids 
reinventing the wheel in the copy module. Combining the two changes (to use 
methodcaller for _copy_with_copy_method and to have list, set and dict use 
_copy_with_copy_method) means we can get rid of both Python defined functions 
in favor of a single use of operator.methodcaller used by all types that 
previously used either of them.

Obviously not a high priority fix, but I noticed this while trying to figure 
out a way to fix zlib's lack of support in the copy module ( #26166 which 
apparently duplicates #25007 ) and how to work around it.

--
components: Library (Lib)
messages: 258704
nosy: josh.r
priority: normal
severity: normal
status: open
title: Improve copy.copy speed for built-in types
type: performance
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue25702] Link Time Optimizations support for GCC and CLANG

[Steve Dower]

Steve Dower added the comment:

MSVC has had Link-Time Code Generation for many releases, and it should have 
been used for all 2.7 releases (definitely used in 3.5+) to optimize references 
between object files. I assume this is equivalent to LTO.

We currently don't use PGO in the official Windows builds, but it is a 
supported build configuration.

--

___
Python tracker 

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

[issue26166] zlib compressor/decompressor objects should support copy protocol

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This is a duplicate of issue25007.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Add support of copy protocol to zlib compressors and 
decompressors

___
Python tracker 

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

[issue26150] SequenceMatcher's algorithm is not correct

[Tim Peters]

Tim Peters added the comment:

Please read the responses to this older report:

http://bugs.python.org/issue25391

As they say, it's functioning as designed and documented, so this isn't "a 
bug".  For that reason I'm closing this as "not a bug".

As they also say, there are many other possible algorithms (LCS isn't the only 
other one in use).  Opening an enhancement request instead (to implement 
additional algorithms) could make sense, but won't get anywhere unless someone 
volunteers to do the work.

--
nosy: +tim.peters
resolution:  -> not a bug
stage: test needed -> 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

[issue26166] zlib compressor/decompressor objects should support copy protocol

[Josh Rosenberg]

Changes by Josh Rosenberg :


--
type:  -> enhancement

___
Python tracker 

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

[issue26166] zlib compressor/decompressor objects should support copy protocol

[Josh Rosenberg]

New submission from Josh Rosenberg:

zlib.compressobj and zlib.decompressobj objects (actually zlib.Compress and 
zlib.Decompress, the other names are the function constructors I guess?) have a 
.copy() method, but don't implement `__copy__` or `__deepcopy__`. This leads to 
the mildly silly result that a copyable object can't be copied using the common 
copy protocol.

I see two solutions:

1. Implement `__copy__` and `__deepcopy__` directly for the zlib objects
2. Have the copy module include them in _copy_dispatch mapped to the existing 
_copy_with_copy_method (and use a similar approach for _deepcopy_dispatch, 
since AFAICT this isn't a case where deep copying differs from shallow copying)

The former makes for more C code in CPython, and would require matching updates 
in the zlib used by all alternate CPython interpreters, but is probably faster 
and introduces no new cross-module dependencies.

The latter would make zlib an import dependency of copy (or vice versa, if zlib 
messed with copy's internals on import), but involves only a trivial amount of 
new Python code and wouldn't require any changes by alternate Python 
implementations that used the core copy module (when they update to the new 
copy, they get the support for free).

--
components: Extension Modules, Library (Lib)
messages: 258700
nosy: josh.r
priority: normal
severity: normal
status: open
title: zlib compressor/decompressor objects should support copy protocol
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue26165] devguide: table summarizing status of Python branches

[STINNER Victor]

STINNER Victor added the comment:

The table is inspired by http://docs.openstack.org/releases/ which only gives 
the status, not the past or scheduled end-of-life date.

--

___
Python tracker 

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

[issue26165] devguide: table summarizing status of Python branches

[koobs]

koobs added the comment:

OH THANK YOU!

If possible, add Months or Quarter (Q1-4) for the EoL's, if those are defined, 
would be great.

We @ FreeBSD/Python would like to proactively (as early as possible) set 
DEPRECATED dates in our ports to ensure our users have ample time to upgrade to 
later versions, ideally in cadence with Python.

--

___
Python tracker 

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

[issue18858] dummy_threading lacks threading.get_ident() equivalent

[Brett Cannon]

Changes by Brett Cannon :


--
assignee:  -> berker.peksag
stage: patch review -> commit review

___
Python tracker 

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

[issue25702] Link Time Optimizations support for GCC and CLANG

[Brett Cannon]

Brett Cannon added the comment:

To help answer MAL's question about Windows: I know the python.org installers 
are **not** built with PGO, but I don't know about LTO.

--
nosy: +steve.dower

___
Python tracker 

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

[issue26165] devguide: table summarizing status of Python branches

[STINNER Victor]

New submission from STINNER Victor:

A frequent question is to get the status of a Python branch: is it still 
maintained? when does the support stop?

Attached patch adds a short table giving the current status of Python branches 
between 2.6 and 3.6 (default).

I sorted branches by their status, nor by their value, to show immediatly that 
2.7 is still at the top :-)

For the future end-of-life, I took the year of the last binary release and I 
added 5 years. Is that right?

--
components: Devguide
files: branch_status.patch
keywords: patch
messages: 258696
nosy: ezio.melotti, haypo, willingc
priority: normal
severity: normal
status: open
title: devguide: table summarizing status of Python branches
Added file: http://bugs.python.org/file41672/branch_status.patch

___
Python tracker 

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

[issue26165] devguide: table summarizing status of Python branches

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +koobs, larry

___
Python tracker 

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

[issue24520] Stop using deprecated floating-point environment functions on FreeBSD

[Stefan Krah]

Stefan Krah added the comment:

Thanks, then the patch looks good to me.

--

___
Python tracker 

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

[issue24520] Stop using deprecated floating-point environment functions on FreeBSD

[Andrew Turner]

Andrew Turner added the comment:

I think this patch is correct.

Clang, as shipped by FreeBSD, doesn't support FENV_ACCESS. It raises the 
following warning:

fenv_test.c:2:14: warning: pragma STDC FENV_ACCESS ON is not supported, 
ignoring pragma [-Wunknown-pragmas]
#pragma STDC FENV_ACCESS ON
 ^
1 warning generated.

I expect the man page mentions it because it is mentioned in the standard. In 
the bugs section it does say the pragma is unimplemented.

--

___
Python tracker 

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

[issue25687] Error during test case and tearDown

[Gedai Tamás Bence]

Gedai Tamás Bence added the comment:

I think it's in the docs, although if you don't find it sufficient I might try 
to update it.

`tearDown method 
`_
"This is called even if the test method raised an exception [...] Any 
exception, other than AssertionError or SkipTest, raised by this method will be 
considered an error rather than a test failure. This method will only be called 
if the setUp() succeeds, regardless of the outcome of the test method."

--
nosy: +beng94

___
Python tracker 

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

[issue24520] Stop using deprecated floating-point environment functions on FreeBSD

[Stefan Krah]

Stefan Krah added the comment:

1) Feedback whether the compiler used on FreeBSD recognizes FENV_ACCESS.

2) If not, an indication why the man page mentions it.

--

___
Python tracker 

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

[issue24520] Stop using deprecated floating-point environment functions on FreeBSD

[STINNER Victor]

STINNER Victor added the comment:

Andrew Turner: "Can this be applied?"

koobs: "What remains to be done/identified/answers here to make progress?"

*I* don't understand if replacing fpsetmask() with fedisableexcept() is enough, 
or if we also need to starting putting "#pragma STDC FENV_ACCESS ON" in all .c 
file using a C double? It's not a rhetorical question, I don't understand the 
consequence of the attached patch.

If two FreeBSD developers (Andrew Turner and koobs) are confident, maybe I 
should trust them and apply blindly the patch without trying to understand it 
:-D

--

___
Python tracker 

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

[issue8519] doc: termios and ioctl reference links

[Guido van Rossum]

Changes by Guido van Rossum :


--
nosy:  -Guido.van.Rossum

___
Python tracker 

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

[issue24520] Stop using deprecated floating-point environment functions on FreeBSD

[koobs]

koobs added the comment:

This issue is becoming increasingly important as FreeBSD 11.0-RELEASE time 
nears.

What remains to be done/identified/answers here to make progress?

--
versions: +Python 2.7, Python 3.5

___
Python tracker 

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

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

[Mark Dickinson]

Mark Dickinson added the comment:

The dtoa.c occurrence is also straightforward to fix. It's coming from this 
declaration:

static const double tinytens[] = { 1e-16, 1e-32, 1e-64, 1e-128,
  9007199254740992.*9007199254740992.e-256};

We need to be a tiny bit careful here, since dtoa.c is fragile code and relies 
on exact representation of some floats. But this isn't one of them: the only 
thing that tinytens is used for is getting a first approximation to the correct 
strtod conversion before the main iteration kicks in.

So replacing that last tinytens value with a suitably precise constant should 
be okay. The *exact* value of the constant we need is 0x1.8062864ac6f43p-745, 
or in decimal: 

8.11296384146066798564414657510725945755617084762542409283393077939218873123696010224953185884350111344494845510586594487062499326481633636403965073720792027659736980514301906428513324403012698167973428740345918815412673646248939187125560378562250718330485204443480974365425682653185460026731686712157238961539250106472701178830382576220700577401565213825995547382545061286464557591871221948351734365233811730381171156150018612038234137396963100802781483162471536048255738998621259419238986828005847002315384502722411971989039148624688058131226853220141492784023284912109375E-225

But 8.112963841460668e-225 should be good enough (along with a comment 
explaining why the expression was changed). If MSVC supported C99's hex 
constants, we could just use 0x1.8062864ac6f43p-745. But it doesn't. :-(

--

___
Python tracker 

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

[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator

[Samuel BOVÉE]

Samuel BOVÉE added the comment:

Up for this bug. I got this bug in my code and loose one hour to understand 
what happened. Please review Martin's patch !

--
nosy: +Samuel BOVÉE

___
Python tracker 

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

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

[Steve Dower]

Steve Dower added the comment:

I'm -0 on changing the universal default (and want to call out that it's a 
relevant porting note for 3.6, not appropriate for 3.5), but we can presumably 
fix those in case someone wants to use strict for their own build.

--

___
Python tracker 

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

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

[Mark Dickinson]

Mark Dickinson added the comment:

Thanks. The offending lines in the math module are:

static const double degToRad = Py_MATH_PI / 180.0;
static const double radToDeg = 180.0 / Py_MATH_PI;

It would be trivial to replace these with suitable constants.

--

___
Python tracker 

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

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

[Zachary Ware]

Zachary Ware added the comment:

Ah, it's been a while since I tested that, so my reporting was inaccurate.  The 
problem is actually that the compile fails:

..\Modules\mathmodule.c(1924): error C2099: initializer is not a constant 
[C:\cpython\PCbuild\pythoncore.vcxproj]
..\Modules\mathmodule.c(1925): error C2099: initializer is not a constant 
[C:\cpython\PCbuild\pythoncore.vcxproj]

..\Python\dtoa.c(1215): error C2099: initializer is not a constant 
[C:\cpython\PCbuild\pythoncore.vcxproj]

--

___
Python tracker 

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

[issue8604] Adding an atomic FS write API

[STINNER Victor]

STINNER Victor added the comment:

It looks like each platform and each filesystem behave differently, with subtle 
differencies with different kernel versions. I'm not more sure that the Python 
stdlib is the best place to host an implementation of an "atomic write" API.

I now suggest to create a project on PyPI, play with it, try to handle as much 
platforms as possible, etc. Then when it is considered as stable and robust 
enough, propose to integrate it to the Python stdlib.

Python stdlib is not the best place for best effort algorithm, we prefer to 
only add reliable and portable code. And leave "other code" outside the stdlib.

--
resolution:  -> out of date
status: open -> closed

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

Let me try to explain this issue again.

"f1, f2 = lambda: 1, lambda: 1.0" is compiled to two MAKE_FUNCTION 
instructions, MAKE_FUNCTION takes a code object as parameter (and a name). The 
Python compiler merges constants which are seen as "equal", with exceptions to 
not merge values of different types, or float of different sign.

Merging duplicate code objects is a cool micro optimization, I prefer to keep 
it. My patch keeps this micro optimization, but fix the bug: it ensures that 
equal constants having different types are not seen as equal. For example, 0 is 
equal to 0.0, but if when used for code constants, the code objects are seen a 
different.

Patch version 3:

* as suggested by Armin Rigo & Serhiy Storchaka: use id(obj) in the constant 
key for unknown constant types -- in practice, this patch is never taken, it's 
just to be extra safe (I checked manually by running the whole test suite when 
an assertion, assertion not in the posted patch)
* add a lot of unit tests
* add a documentation to _PyCode_ConstantKey()

@Serhiy: does it look good to you now?

> Would option (1) work if wrap 1 and 1.0 in a tuple? In a list? In a custom 
> collection?

My patch now uses id(obj) in the "constant key" for unknown types. The compiler 
only emits simple type (int, str, ...), tuple, frozenset and code objects.

You *can* other types if you patch manually constants with custom objects, 
since code_richcomp() now uses the "constant key" function to compare 
constants. For example, my fat project has a replace_consts() function to 
inject builtin functions in constants:
http://fatoptimizer.readthedocs.org/en/latest/fat.html#replace_consts

There is also @asconstants decorator of codetransformer which allow to inject 
arbitrary types in function constants:
https://pypi.python.org/pypi/codetransformer

--
Added file: http://bugs.python.org/file41671/code_richcompare-3.patch

___
Python tracker 

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

[issue25843] code_richcompare() don't use constant type when comparing code constants

[STINNER Victor]

Changes by STINNER Victor :


--
title: lambdas on the same line may incorrectly share code objects -> 
code_richcompare() don't use constant type when comparing code constants

___
Python tracker 

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

[issue25702] Link Time Optimizations support for GCC and CLANG

[R. David Murray]

R. David Murray added the comment:

My understanding is that we (starting with Guido) have made a blanket exception 
for 2.7 for useful performance and build-system-only related patches.  That 
doesn't mean *anything* can go in (the usual rules about "is this worth 
it/backward compatible/won't break things" still apply) but it is a lower bar 
than is true for other maintenance only releases.  Perhaps my understanding is 
in error, though.  

I believe Intel is committed to supporting this, so if there do turn out to be 
any maintenance issues they can handle them.  (Which IIUC is Nick's argument: 
if someone wants to support 2.7 with stuff we are willing to let in, we should 
let them as long as they credibly commit to supporting it.)  I'm currently part 
of that Intel support, though, so someone else should rule on this.

--

___
Python tracker 

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

[issue8604] Adding an atomic FS write API

[Thomas Kluyver]

Thomas Kluyver added the comment:

For reference, we added our own atomic_writing() context manager in 
Jupyter/IPython, after someone lost work when save failed on a full disk. We 
initially went for the same approach - write to a temporary file, fsync, rename 
over the original file - but it caused issues with network filesystems and 
folders synced by Dropbox or similar services.

As a result we switched to an approach that copies the old file to a temporary 
name, writes the new data directly to the old name, then removes the temporary 
copy on success, or renames it back to the old name on failure. This is 
certainly less rigorous, but it means that we're not replacing the file on 
every save, and it's less of a problem if copying file attributes with 
copystat() fails.

I'm sure there are use cases for atomic writing where these problems won't come 
up, but I hope this is a useful data point, at least for documenting any atomic 
writing solution.

--
nosy: +takluyver

___
Python tracker 

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

[issue18858] dummy_threading lacks threading.get_ident() equivalent

[Berker Peksag]

Berker Peksag added the comment:

dummy_threading.get_ident() works for me:

>>> import dummy_threading as dt
>>> dt.get_ident()
-1
>>> import threading
>>> threading.get_ident()
140498493105920

Here is a patch to compare threading and dummy_threading modules.

--
keywords: +patch
nosy: +berker.peksag
stage: test needed -> patch review
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4
Added file: http://bugs.python.org/file41670/issue18858.diff

___
Python tracker 

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

[issue26152] A non-breaking space in a source

[Adam Bartoš]

Adam Bartoš added the comment:

That explains the message. But why is the caret at a wrong place?

--

___
Python tracker 

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

[issue25702] Link Time Optimizations support for GCC and CLANG

[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

[issue26145] PEP 511: Add sys.set_code_transformers()

[STINNER Victor]

STINNER Victor added the comment:

Note: ast.PyCF_TRANSFORMED_AST is not implemented yet.

--

___
Python tracker 

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

[issue26164] test_with_pip() of test_venv fails on Windows buildbots

[Donald Stufft]

Donald Stufft added the comment:

Upstream issue for this is https://github.com/pypa/pip/issues/3383.

--

___
Python tracker 

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

[issue21776] distutils.upload uses the wrong order of exceptions

[Berker Peksag]

Berker Peksag added the comment:

Lib/distutils/command/upload.py has changed a bit after d86214c98a9c. Here is 
an updated patch.

--
nosy: +berker.peksag
stage:  -> patch review
versions: +Python 3.6
Added file: http://bugs.python.org/file41669/issue21776_v2.diff

___
Python tracker 

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

[issue26164] test_with_pip() of test_venv fails on Windows buildbots

[STINNER Victor]

New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20Windows7%203.5/builds/591/steps/test/logs/stdio

==
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.5.bolen-windows7\build\lib\test\test_venv.py", 
line 379, in test_with_pip
self.assertEqual(err, "")
AssertionError: "d:\\temp\\tmpcyw9drz0\\lib\\site-package[323 chars]\r\n" != ''
- d:\temp\tmpcyw9drz0\lib\site-packages\pip\pep425tags.py:89: RuntimeWarning: 
Config variable 'Py_DEBUG' is unset, Python ABI tag may be incorrect
-   warn=(impl == 'cp')):
- d:\temp\tmpcyw9drz0\lib\site-packages\pip\pep425tags.py:93: RuntimeWarning: 
Config variable 'WITH_PYMALLOC' is unset, Python ABI tag may be incorrect
-   warn=(impl == 'cp')):

--
messages: 258675
nosy: dstufft, haypo
priority: normal
severity: normal
status: open
title: test_with_pip() of test_venv fails on Windows buildbots
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)

[STINNER Victor]

New submission from STINNER Victor:

The buildbot "x86 Ubuntu Shared 3.x" build 12691 failed, the previous builds 
succeeded. Changes:

* f97da0952a2ebe08f2e5999c7473c776c59f3a16 (issue #25982)
* 775b74e0e103f816382a0fc009b6ac51ea956750 (issue #26107)

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/12691/steps/test/logs/stdio

==
FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)
--
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_set.py", 
line 736, in test_hash_effectiveness
self.assertGreater(4*u, t)
AssertionError: 192 not greater than 256

==
FAIL: test_hash_effectiveness (test.test_set.TestFrozenSetSubclass)
--
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_set.py", 
line 736, in test_hash_effectiveness
self.assertGreater(4*u, t)
AssertionError: 192 not greater than 256

--
components: Tests
keywords: buildbot
messages: 258674
nosy: haypo
priority: normal
severity: normal
status: open
title: FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)
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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[STINNER Victor]

STINNER Victor added the comment:

FYI The issue #26107 changed code.co_lnotab to support negative line number 
deltas.

--
nosy: +haypo

___
Python tracker 

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

[issue26107] PEP 511: code.co_lnotab: use signed line number delta to support moving instructions in an optimizer

[STINNER Victor]

STINNER Victor added the comment:

I closed issues #16956 and #21385 as duplicates of this issue.

--

___
Python tracker 

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

[issue16956] Allow signed line number deltas in the code object's line number table

[STINNER Victor]

STINNER Victor added the comment:

Good news: this issue has been fixed in issue #26107.

--
resolution:  -> fixed
status: open -> closed
superseder:  -> PEP 511: code.co_lnotab: use signed line number delta to 
support moving instructions in an optimizer

___
Python tracker 

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

[issue21385] in debug mode, compile(ast) fails with an assertion error if an AST node has no line number information

[STINNER Victor]

STINNER Victor added the comment:

Good news: this issue has been fixed by the commit of the issue #26107.

--
resolution:  -> fixed
status: open -> closed
superseder:  -> PEP 511: code.co_lnotab: use signed line number delta to 
support moving instructions in an optimizer

___
Python tracker 

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

[issue26107] PEP 511: code.co_lnotab: use signed line number delta to support moving instructions in an optimizer

[STINNER Victor]

STINNER Victor added the comment:

> Nice work, my issue21385 is also related. Basically, transforming non-Python 
> code into Python meant that all line number information, which otherwise 
> would have been useful for debugging, had to be discarded, or debug builds of 
> Python would dump cores.

Ok, it looks like there are multiple use cases for negative line numbers, and 
the change doesn't really break anything in practice. I tried to explain 
exactly who is impacted and how to update the code in the Porting section of 
What's New in Python 3.6.

For each review Serhiy. I pushed the the change to Python 3.6.

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

___
Python tracker 

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

[issue26107] PEP 511: code.co_lnotab: use signed line number delta to support moving instructions in an optimizer

[Roundup Robot]

Roundup Robot added the comment:

New changeset 775b74e0e103 by Victor Stinner in branch 'default':
co_lnotab supports negative line number delta
https://hg.python.org/cpython/rev/775b74e0e103

--

___
Python tracker 

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

[issue26162] thread error

[Ali Razmjoo]

New submission from Ali Razmjoo:

Hello,

I've got a problem while using threading in python 2.7.10 windows.
I copied errors in here https://gist.github.com/Ali-Razmjoo/d503171d338c6381f94f

with 845 threads,870 and 1000. there isn't any problem or error with 840-830 
threads!

--
messages: 258667
nosy: Ali Razmjoo
priority: normal
severity: normal
status: open
title: thread error
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

[issue1674555] sys.path in tests contains system directories

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue8519] doc: termios and ioctl reference links

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue12215] TextIOWrapper: issues with interlaced read-write

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue25982] multiprocessing docs for Namespace lacks class definition

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8d7aadd40d30 by Senthil Kumaran in branch '2.7':
issue25982 - Add a class definition for managers.Namespace in the 
multiprocessing docs.
https://hg.python.org/cpython/rev/8d7aadd40d30

--

___
Python tracker 

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

[issue25982] multiprocessing docs for Namespace lacks class definition

[Senthil Kumaran]

Senthil Kumaran added the comment:

Thanks for the report. Fixed.

--
assignee: davin -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
type: enhancement -> behavior
versions:  -Python 3.4

___
Python tracker 

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

[issue25982] multiprocessing docs for Namespace lacks class definition

[Roundup Robot]

Roundup Robot added the comment:

New changeset 32ee5d197500 by Senthil Kumaran in branch '3.5':
issue25982 - Add a class definition for managers.Namespace in the 
multiprocessing docs.
https://hg.python.org/cpython/rev/32ee5d197500

New changeset f97da0952a2e by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/f97da0952a2e

--
nosy: +python-dev

___
Python tracker 

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

[issue25702] Link Time Optimizations support for GCC and CLANG

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 20.01.2016 11:38, Antoine Pitrou wrote:
>> If not, then the patch would also effect the not-so-tiny fraction
>> of Python users on Windows ;-)
> 
> I don't see how enabling LTO for gcc and clang could ever affect our Windows 
> users ;-)

You have a point there, but perhaps we could start offering
an ICC compiled version for Windows ;-)

--

___
Python tracker 

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

[issue26161] Use Py_uintptr_t instead of void* for atomic pointers

[STINNER Victor]

STINNER Victor added the comment:

(Oops, I attached the wrong patch. It's now fixed.)

--
Added file: http://bugs.python.org/file41668/atomic_pointer.patch

___
Python tracker 

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

[issue26161] Use Py_uintptr_t instead of void* for atomic pointers

[STINNER Victor]

New submission from STINNER Victor:

Attached patch fixes compiler warnings on atomic pointers.

Python has 4 implementations of atomic types:

* 
* GCC 4.7+ builtin atomic operations
* GCC x86 and x86_64 assembler
* volatile

The type of atomic pointers changes depending on the implementation. Attached 
patch changes the _Py_atomic_address to use atomic_uintptr_t () or 
Py_uintptr_t type internally.

The patchs also adds GET_TSTATE(), SET_TSTATE() and GET_INTERP_STATE() macros 
in pystate.c to make the code more readable.

This issue is a follow up of the issue #22038 which added support for 
 in Python/pyatomic.h. See also issues #23644 (compilation issue 
with g++), #25150 (compilation issue with OpenMP) and #26154 (add 
_PyThreadState_UncheckedGet()).

I would be "nice" to backport this change to Python 3.5.2 to fix the compiler 
warning, but I'm not 100% confident that my patch works on all compilers and 
all platforms. Maybe it's better to "experiment" it only in Python 3.6.

Note: I copied the nosy list of the issue #22038 since this one is a follow up.

--
components: Interpreter Core
files: atomic_pointer.patch
keywords: patch
messages: 258661
nosy: Arfrever, John.Malmberg, Vitor.de.Lima, fijall, gustavotemple, haypo, 
koobs, lbianc, neologix
priority: normal
severity: normal
status: open
title: Use Py_uintptr_t instead of void* for atomic pointers
versions: Python 3.6
Added file: http://bugs.python.org/file41667/atomic_pointer.patch

___
Python tracker 

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

[issue26161] Use Py_uintptr_t instead of void* for atomic pointers

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file41667/atomic_pointer.patch

___
Python tracker 

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

[issue25702] Link Time Optimizations support for GCC and CLANG

[Antoine Pitrou]

Antoine Pitrou added the comment:

> If not, then the patch would also effect the not-so-tiny fraction
of Python users on Windows ;-)

I don't see how enabling LTO for gcc and clang could ever affect our Windows 
users ;-)

--

___
Python tracker 

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

[issue26160] Tutorial incorrectly claims that (explicit) relative imports don't work in the main module

[Martin Panter]

Martin Panter added the comment:

Yes 2.7 is open for changes to the documentation like this, as is 3.5+.

It’s been a while since I looked at the tutorial. Does it even mention the 
“python -m” mode? I don’t think this is the right place to introduce it.

Perhaps it would be okay to just say relative imports are based on the _full_ 
name of the current module. It could be misleading saying “the name of the 
current package”, because the import could be relative to the a higher level 
parent package if more than one dot is specified. Then point out that relative 
imports won’t work with ``python file.py`` or interactive mode, but don’t 
mention “-m” (or the other ways to run scripts and modules).

--
nosy: +martin.panter
versions:  -Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

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

[issue25702] Link Time Optimizations support for GCC and CLANG

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 20.01.2016 09:37, Antoine Pitrou wrote:
> Let me add that downstream distributors already customize compilation options 
> (Ubuntu's Python is compiled with both PGO and LTO enabled, AFAIR), so this 
> change may only really affect the tiny subset of non-Windows users that 
> compile Python themselves.

Are the Windows installers on python.org compiled with PGO and
LTO enabled ?

If not, then the patch would also effect the not-so-tiny fraction
of Python users on Windows ;-)

BTW: It may make sense to start collecting the various performance
related optional patches to Python 2.7 on a wiki page for interested
parties to use.

--
nosy: +lemburg

___
Python tracker 

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

[issue26154] Add private _PyThreadState_UncheckedGet() to get the current thread state

[STINNER Victor]

STINNER Victor added the comment:

Function added

@fijal: Sorry for the annoyance of the Python 3.5.1 regression.

--
resolution:  -> fixed
status: open -> closed
title: Add private _PyThreadState_FastGet() to get the current thread state -> 
Add private _PyThreadState_UncheckedGet() to get the current thread state

___
Python tracker 

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