[issue26039] More flexibility in zipfile interface

[Thomas Kluyver]

Thomas Kluyver added the comment:

Serhiy, any chance you'd have some time to review my patch(es)? Or is there 
someone else interested in zipfile I might interest? Thanks :-)

--

___
Python tracker 

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

[issue24683] Type confusion in json encoding

[paul]

paul added the comment:

Proof of EIP control.

--
Added file: http://bugs.python.org/file41719/eip.py

___
Python tracker 

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

[issue24683] Type confusion in json encoding

[paul]

paul added the comment:

GDB dump of running ./python eip.py

___
 eax:37A317DD ebx:B7A54268  ecx:BFFFE22C  edx:11223344 eflags:00010217
 esi:B7A61060 edi:B7AA6714  esp:BFFFE20C  ebp:B7A317DC eip:11223344
 cs:0073  ds:007B  es:007B  fs:  gs:0033  ss:007Bo d I t s z A P C
[007B:BFFFE20C]-[stack]
BFFFE23C : 10 FA A1 B7  60 10 A6 B7 - 68 42 A5 B7  00 60 A2 B7 `...hB...`..
BFFFE22C : 60 17 A6 B7  10 68 2B 08 - 00 60 A2 B7  DC 17 A3 B7 `h+..`..
BFFFE21C : 2C E2 FF BF  DC 17 A3 B7 - 3C E2 FF BF  00 00 00 00 ,...<...
BFFFE20C : AE 07 0D 08  60 10 A6 B7 - 68 42 A5 B7  DD 17 A3 37 `...hB.7
[0073:11223344]-[ code]
=> 0x11223344:  Error while running hook_stop:
Cannot access memory at address 0x11223344
0x11223344 in ?? ()

--

___
Python tracker 

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

[issue17394] Add slicing support to collections.deque

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Synchronized with current sources and added mandatory now braces.

--
Added file: http://bugs.python.org/file41723/deque_slices_2.patch

___
Python tracker 

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

[issue26194] Undefined behavior for deque.insert() when len(d) == maxlen

[Raymond Hettinger]

Changes by Raymond Hettinger :


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

[issue26194] Undefined behavior for deque.insert() when len(d) == maxlen

[Roundup Robot]

Roundup Robot added the comment:

New changeset ce3d47eaeb21 by Raymond Hettinger in branch '3.5':
Issue #26194: Fix undefined behavior for deque.insert() when len(d) == maxlen
https://hg.python.org/cpython/rev/ce3d47eaeb21

--
nosy: +python-dev

___
Python tracker 

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

[issue26194] Undefined behavior for deque.insert() when len(d) == maxlen

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

New behavior looks less surprising to me.

Old behavior is even more weird for negative indices:

>>> from collections import deque
>>> d = deque(range(20), maxlen=10)
>>> d
deque([10, 11, 12, 13, 14, 15, 16, 17, 18, 19], maxlen=10)
>>> d.insert(-3, 'New')
>>> d
deque([11, 12, 13, 14, 15, 16, 'New', 18, 19, 10], maxlen=10)

Note that new element not just replaced the old one in the middle of the deque, 
but all context was rotated one position left.

Patched code behave less surprising.

>>> d.insert(-3, 'New')
>>> d   
deque([10, 11, 12, 13, 14, 15, 'New', 16, 17, 18], maxlen=10)

--

___
Python tracker 

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

[issue26194] Undefined behavior for deque.insert() when len(d) == maxlen

[Raymond Hettinger]

Raymond Hettinger added the comment:

The plain-insert-followed-by-a-pop-on-the-right is giving reasonable results 
with nice properties:

d.insert(0, i)
---
0 --> deque([0], maxlen=4)
1 --> deque([1, 0], maxlen=4)
2 --> deque([2, 1, 0], maxlen=4)
3 --> deque([3, 2, 1, 0], maxlen=4)
4 --> deque([4, 3, 2, 1], maxlen=4)
5 --> deque([5, 4, 3, 2], maxlen=4)
6 --> deque([6, 5, 4, 3], maxlen=4)
7 --> deque([7, 6, 5, 4], maxlen=4)
8 --> deque([8, 7, 6, 5], maxlen=4)
9 --> deque([9, 8, 7, 6], maxlen=4)

d.insert(len(d), i)
---
0 --> deque([0], maxlen=4)
1 --> deque([0, 1], maxlen=4)
2 --> deque([0, 1, 2], maxlen=4)
3 --> deque([0, 1, 2, 3], maxlen=4)
4 --> deque([0, 1, 2, 3], maxlen=4)
5 --> deque([0, 1, 2, 3], maxlen=4)
6 --> deque([0, 1, 2, 3], maxlen=4)
7 --> deque([0, 1, 2, 3], maxlen=4)
8 --> deque([0, 1, 2, 3], maxlen=4)
9 --> deque([0, 1, 2, 3], maxlen=4)

--

___
Python tracker 

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

[issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot

[Jeremy Kloth]

Changes by Jeremy Kloth :


--
nosy: +jkloth

___
Python tracker 

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

[issue26198] PyArg_ParseTuple with format "et#" and "es#" detects overflow by raising TypeError instead of ValueError

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Proposed patch fixes minor bugs in Python/getargs.c:

1. Replaces TypeError with confusing error message for buffer overflow for 
"es#" and "et#" format units to ValueError with correct error message. Due to 
the risk to break working code, may be we will left TypeError in maintained 
releases, but error message should be fixed in any case.

2. Replaces all other TypeError with confusing error message to SystemError 
with correct error message. All this errors are programming errors (incorrect 
use of PyArg_Parse* functions) and aren't occurred in valid extensions.

3. Fixes error messages for "k" and "K" format units.

4. Fixes error messages for "es" and "et" format units.

5. Fixes error messages for "compat" mode (looks as this mode is not used and 
can be freely removed in Python 3).

--
assignee: docs@python -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> patch review
versions: +Python 3.6
Added file: http://bugs.python.org/file41720/pyarg_parse_encoded_string.patch

___
Python tracker 

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

[issue26039] More flexibility in zipfile interface

[Thomas Kluyver]

Thomas Kluyver added the comment:

Thanks! I will work on docs and tests.

--

___
Python tracker 

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

[issue26039] More flexibility in zipfile interface

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Your patches are great Thomas! This is just what I want to implement. It will 
take some time to make a careful review. Besides possible corrections I think 
these features will be added in 3.6. But new features need tests and 
documenting.

--
assignee:  -> serhiy.storchaka
stage:  -> test needed

___
Python tracker 

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

[issue26198] PyArg_ParseTuple with format "et#" and "es#" detects overflow by raising TypeError instead of ValueError

[Hrvoje Nikšić]

Hrvoje Nikšić added the comment:

Barun, Serhiy, thanks for picking this up so quickly.

I would further suggest to avoid using a fixed buffer in abspath 
(_getfullpathname, but only abspath seems to call it). Other filesystem calls 
are using the interface where PyArg_ParseTuple allocates the buffer. This makes 
it easier to handling errors from the native layer by catching OSError or 
similar, instead of the very generic TypeError (or ValueError).

--

___
Python tracker 

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

[issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot

[Steve Dower]

Steve Dower added the comment:

So the more interesting error message is higher up:

xxmodule.c
xxmodule.obj : warning LNK4197: export 'PyInit_xx' specified multiple times; 
using first specification
   Creating library 
d:\temp\tmptzty591d\Debug\temp\tmptzty591d\xx_d.cp36-win_amd64.lib and object 
d:\temp\tmptzty591d\Debug\temp\tmptzty591d\xx_d.cp36-win_amd64.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the 
link command line to improve linker performance
LINK : fatal error LNK1101: incorrect MSPDB140.DLL version; recheck 
installation of this product

It's entirely possible that this was an issue with VS 2015 that has been 
resolved in VS 2015 Update 1. Let me check with some people who may know.

In the meantime, it would be handy if the owners could confirm that the 
buildbots are running VS 2015 and not Update 1 (released in November, so if you 
haven't installed anything that recently then it's unrelated). Also the full 
version numbers of the following files:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\mspdb140.dll
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_arm\link.exe

--
assignee:  -> steve.dower

___
Python tracker 

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

[issue19698] Implement _imp.exec_builtin and exec_dynamic

[Brett Cannon]

Brett Cannon added the comment:

At this point both FrozenImporter and BuiltinImporter support exec_module(), so 
the only thing left to do is to document when FrozenImporter and 
WindowsRegistryFinder gained their exec_module() implementations 
(BuiltinImporter already has a note about it).

--
assignee:  -> docs@python
keywords: +easy
nosy: +docs@python
priority: critical -> low
stage: test needed -> needs patch
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

[issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot

[Zachary Ware]

Zachary Ware added the comment:

Steve, I'm assuming you meant "x86_amd64" rather than "x86_arm" on that last 
filename?

Note that this issue is restricted to Debug builds (as suggested by the issue 
being with mspdb140.dll), the Non-Debug buildbot is not failing.

--

___
Python tracker 

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

[issue26203] nesting venv in virtualenv segfaults

[Brett Cannon]

Changes by Brett Cannon :


--
status: open -> closed

___
Python tracker 

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

[issue26205] Inconsistency concerning nested scopes

[Brett Cannon]

Brett Cannon added the comment:

https://docs.python.org/3/tutorial/classes.html for the docs that Roscoe is 
talking about.

So the sentence is technically correct, it just takes careful reading to grasp 
what's being said. There are "at least three nested scopes", but there can be 
*up to* four scopes. Since "the scopes of any enclosing functions" is not 
necessarily true for all code scopes, you end up with at least three, but 
possibly four scopes.

Obviously the wording could be clearer, so if you want to sign the CLA, Roscoe, 
and propose a rewording that would be appreciated!

--
nosy: +brett.cannon

___
Python tracker 

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

[issue26208] decimal C module's exceptions don't match the Python version

[Petr Viktorin]

New submission from Petr Viktorin:

Exceptions from the decimal module are quite unfriendly:

>>> Decimal(42) / Decimal(0)
...
decimal.DivisionByZero: []

>>> huge = Decimal('9' * 99)
>>> huge.quantize(Decimal('0.1'))
...
decimal.InvalidOperation: []


compared to the pure Python implementation:

decimal.DivisionByZero: x / 0

decimal.InvalidOperation: quantize result has too many digits for current 
context


If I'm reading http://bugs.python.org/issue21227 right, the exception argument 
is a of signals, and indicates the complete set of signals raised by the 
operation. However, this is (AFAICS) not documented, and not portable (since 
it's not present in the Python version).

I believe this behavior should be
- either dropped in favor of friendlier error messages (or possibly moved to a 
more internal attribute of the exception, and documented as an optional CPython 
feature),
- or documented, and implemented in _pydecimal as well.

Which of those actions would be right seems to be a question of whether the 
exception argument is part of the API.

--
components: Library (Lib)
messages: 258965
nosy: encukou, skrah
priority: normal
severity: normal
status: open
title: decimal C module's exceptions don't match the Python version

___
Python tracker 

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

[issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot

[Steve Dower]

Steve Dower added the comment:

Yep, that's what I meant. So many cross compilers these days...

--

___
Python tracker 

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

[issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot

[STINNER Victor]

STINNER Victor added the comment:

> It's entirely possible that this was an issue with VS 2015 that has been 
> resolved in VS 2015 Update 1. Let me check with some people who may know.

If a fix cannot be found quickly, would it be possible to revert the Python 
change until VS is fixed and the fix is deployed to all buildbots? I'm trying 
to keep green buildbots. It helps me to validate my work on multiple platforms 
;)

--

___
Python tracker 

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

[issue26204] compiler: don't emit LOAD_CONST instructions for constant statements?

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM.

It looks to me that this optimization was added to avoid spending executing 
time for docstrings. Other cases almost never occur in real code and are not 
worth to be optimized. But the patch makes the code cleaner (it would even more 
cleaner if collapse all kinds of constants in Constant).

--
nosy: +serhiy.storchaka
stage:  -> commit review

___
Python tracker 

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

[issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

It would be easier to just temporary skip some tests on particular platforms.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue26208] decimal C module's exceptions don't match the Python version

[Raymond Hettinger]

Raymond Hettinger added the comment:

If it doesn't take too much effort, I would like the see the exception messages 
made more user friendly and kept more in-sync with the pure Python version.

--
assignee:  -> skrah
nosy: +rhettinger

___
Python tracker 

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

[issue26209] TypeError in smtpd module with string arguments

[Lorenzo Ancora]

New submission from Lorenzo Ancora:

smtpd.PureProxy(localaddr="host1", remoteaddr="host2")

...produces the error:

[...] smtpd.py", line 657, in __init__
gai_results = socket.getaddrinfo(*localaddr, type=socket.SOCK_STREAM)
TypeError: getaddrinfo() got multiple values for argument 'type'

The module only works with:

smtpd.PureProxy(localaddr=("host1", 25), remoteaddr=("host2", 25))

The documentation does not specify the format of the INPUT parameters, only the 
CLI syntax with hostnames as "host:port" strings.
The underlying library should convert them to tuples or at least the 
documentation should be completed.

--
components: Library (Lib)
messages: 258971
nosy: lorenzo.ancora
priority: normal
severity: normal
status: open
title: TypeError in smtpd module with string arguments
type: behavior
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

[issue26209] TypeError in smtpd module with string arguments

[SilentGhost]

Changes by SilentGhost :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue26208] decimal C module's exceptions don't match the Python version

[Stefan Krah]

Stefan Krah added the comment:

Yes, ideally the exceptions should be in sync. I don't find the list
of signals entirely uninteresting, but implementing it in _pydecimal
would require #8613 to be solved, which is unlikely to happen.


In _decimal the exceptions come directly from libmpdec, so in order
to have the same error messages as _pydecimal I'd need to implement
detailed error codes and store them somewhere in the context.

--

___
Python tracker 

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

[issue26208] decimal C module's exceptions don't match the Python version

[Stefan Krah]

Changes by Stefan Krah :


--
stage:  -> needs patch
type:  -> enhancement
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

[issue26210] `HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked

[Yannick Duchêne]

New submission from Yannick Duchêne:

`HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was 
invoked. This occurs at least when `HTMLParser.reset` was invoked during 
`HTMLParser.handle_endtag`.

According to the documentation, `HTMLParser.reset` discard all data, so it 
should immediately stop the parser.

Additionally as an aside, it's strange `HTMLParser.reset` is invoked during 
object creation as it's invoking a method on an object which is potentially not 
entirely initialized (that matters with derived classes).

--
components: Library (Lib)
messages: 258973
nosy: Hibou57
priority: normal
severity: normal
status: open
title: `HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was 
invoked
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

[issue26201] Faster type checking in listobject.c

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
Removed message: http://bugs.python.org/msg258942

___
Python tracker 

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

[issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot

[STINNER Victor]

STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> It would be easier to just temporary skip some tests on particular platforms.

Ah yes, I also like this option. Well, it's up to you Steve :-)

--

___
Python tracker 

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

[issue26211] HTMLParser: “AssertionError: we should not get here!”

[Yannick Duchêne]

New submission from Yannick Duchêne:

Using HTMLParser on the attached file, I got this:

  File "/usr/lib/python3.5/html/parser.py", line 111, in feed
self.goahead(0)
  File "/usr/lib/python3.5/html/parser.py", line 171, in goahead
k = self.parse_starttag(i)
  File "/usr/lib/python3.5/html/parser.py", line 303, in parse_starttag
endpos = self.check_for_whole_start_tag(i)
  File "/usr/lib/python3.5/html/parser.py", line 383, in 
check_for_whole_start_tag
raise AssertionError("we should not get here!")
AssertionError: we should not get here!

The file purposely contains an error, as I was to check the behaviour of my 
application in the case of this error … I finally triggered one in the library 
:-P

--
components: Library (Lib)
files: sample.html
messages: 258975
nosy: Hibou57
priority: normal
severity: normal
status: open
title: HTMLParser: “AssertionError: we should not get here!”
versions: Python 3.5
Added file: http://bugs.python.org/file41721/sample.html

___
Python tracker 

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

[issue26204] compiler: don't emit LOAD_CONST instructions for constant statements?

[STINNER Victor]

STINNER Victor added the comment:

Serhiy: "It looks to me that this optimization was added to avoid spending 
executing time for docstrings."

Hum, let me dig Mercurial history.

changeset:   39364:8ef3f8cf90e1
branch:  legacy-trunk
user:Neal Norwitz 
date:Fri Aug 04 05:09:28 2006 +
files:   Lib/test/test_code.py Misc/NEWS Python/compile.c
description:
Bug #1333982: string/number constants were inappropriately stored
in the byte code and co_consts even if they were not used, ie
immediately popped off the stack.
---

https://bugs.python.org/issue1333982#msg26659:
"For reference, an optimization that got lost: (...) 'a' is the docstring, but 
the 'b' previously did not show up anywhere in the code object.  Now there is 
the LOAD_CONST/POP_TOP pair."

Ah, it was a regression introduced by the new AST compiler. But the change 
introduced a new optimization: numbers are now also ignored. In Python 2.4 
(before AST), numbers were not ignored:
---
>>> def f():
...  "a"
...  1
...  "b"
... 

>>> import dis; dis.dis(f)
  3   0 LOAD_CONST   1 (1)
  3 POP_TOP 
  4 LOAD_CONST   2 (None)
  7 RETURN_VALUE
---


If we continue to dig deeper, before AST, I found:
---
changeset:   4991:8276916e1ea8
branch:  legacy-trunk
user:Guido van Rossum 
date:Fri Jan 17 21:04:03 1997 +
files:   Python/compile.c
description:
Add co_stacksize field to codeobject structure, and stacksize argument
to PyCode_New() argument list.  Move MAXBLOCKS constant to conpile.h.

Added accurate calculation of the actual stack size needed by the
generated code.

Also commented out all fprintf statements (except for a new one to
diagnose stack underflow, and one in #ifdef'ed out code), and added
some new TO DO suggestions (now that the stacksize is taken of the TO
DO list).
---

This patch added the following code to com_expr_stmt() in Python/compile.c:

+   /* Forget it if we have just a doc string here */
+   if (NCH(n) == 1 && get_rawdocstring(n) != NULL)
+   return;

I'm unable to find the exact part of the compiler which ignores strings in 
statement expressions.

--

___
Python tracker 

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

[issue26204] compiler: don't emit LOAD_CONST instructions for constant statements?

[STINNER Victor]

STINNER Victor added the comment:

"""
Will the following code compile OK?  What will it compile to?

   if 1:
  42
"""

compile OK: what do you mean? This code doesn't make any sense to me :-)


Currently text strings statements are ignored:
---
>>> def f():
...  if 1:
...   "abc"
... 
>>> import dis
>>> dis.dis(f)
  3   0 LOAD_CONST   0 (None)
  3 RETURN_VALUE
---


But byte strings emit a LOAD_CONST+POP_TOP:
---
>>> def g():
...  if 1:
...   b'bytes'
... 
>>> dis.dis(g)
  3   0 LOAD_CONST   1 (b'bytes')
  3 POP_TOP
  4 LOAD_CONST   0 (None)
  7 RETURN_VALUE
---


With my patch, all constants statements will be ignored. Example with my patch:
---
>>> def h():
...  if 1:
...   b'bytes'
... 
>>> import dis; dis.dis(h)
  3   0 LOAD_CONST   0 (None)
  3 RETURN_VALUE
---

--

___
Python tracker 

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

[issue26205] Inconsistency concerning nested scopes

[Yannick Duchêne]

Yannick Duchêne added the comment:

Better at least two, if I'm not wrong: the innermost scope may be the module's 
scope. So there is always at least the module scope and the built‑ins scope, at 
least two up to four.

(if I have not overlooked something)

--
nosy: +Hibou57

___
Python tracker 

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

[issue26204] compiler: don't emit LOAD_CONST instructions for constant statements?

[STINNER Victor]

STINNER Victor added the comment:

Serhiy: "It looks to me that this optimization was added to avoid spending 
executing time for docstrings. Other cases almost never occur in real code and 
are not worth to be optimized. But the patch makes the code cleaner (it would 
even more cleaner if collapse all kinds of constants in Constant)."

Oh, I don't really care of performance. The bytecode just doesn't make any 
sense to me. I don't understand why we load a constant.

Maybe the compiler should emit a warning to say that the code doesn't make 
sense at all and is ignored?

Example with GCC:

$ cat x.c 
int main()
{
1;
}


$ gcc x.c -Wall -o x
x.c: In function 'main':
x.c:3:5: warning: statement with no effect [-Wunused-value]
 1;
 ^

--

___
Python tracker 

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

[issue26205] Inconsistency concerning nested scopes

[Brett Cannon]

Changes by Brett Cannon :


--
stage:  -> needs patch
type: behavior -> 
versions: +Python 2.7, Python 3.6

___
Python tracker 

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

[issue26205] Inconsistency concerning nested scopes

[Brett Cannon]

Brett Cannon added the comment:

It depends on how you want to view things as to whether you can claim there are 
two or three scopes for module-level code. While it's true that the local scope 
operates just like global scope, to Python it's more like local == global 
rather than the local scope simply doesn't exist (hence why `locals()` never 
throws an exception saying the scope doesn't exist but instead is the same as 
`globals()`).

The "three scope" phrasing also predates nested scopes from back when Python 
had its LGB scoping rules: Local-Global-Builtin. Back then we just said Python 
had three scopes and left it at that since it was basically always true and 
didn't confuse anyone.

At this point I'm fine with just removing the number from the sentence and 
saying something like "At any time during execution, there are various nested 
scopes whose namespaces are directly accessible:".

--

___
Python tracker 

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

[issue26204] compiler: don't emit LOAD_CONST instructions for constant statements?

[STINNER Victor]

STINNER Victor added the comment:

> Maybe the compiler should emit a warning to say that the code doesn't make 
> sense at all and is ignored?

Oh ok, now I recall a similar issue that I posted 3 years ago: issue #17516, 
"Dead code should be removed".

Example of suspicious code:

def func():
   func2(),

func() calls func2() and then create a tuple of 1 item with the func2() result. 
See my changeset 33bdd0a985b9 for examples in the Python source code. The 
parser or compiler should maybe help to developer to catch such strange code :-)

In some cases, the code really contains code explicitly dead:

def test_func():
   return
   do_real_stuff()

do_real_stuff() is never called. Maybe it was a deliberate choice, maybe it was 
a mistake in a very old code base, bug introduced after multiple refactoring, 
and high turn over in a team? Again, we should emit a warning on such case?

Hum, these warnings have a larger scope than this specific issue (don't emit 
LOAD_CONST for constants in expressions).

See also the related thread on python-dev for the specific case of triple 
quoted strings ("""string"""): 
https://mail.python.org/pipermail/python-dev/2013-March/124925.html

It was admitted that it's a convenient way to insert a comment and it must not 
emit a warning (at least, not by default?)

--

___
Python tracker 

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

[issue26204] compiler: ignore constants used as statements? (don't emit LOAD_CONST+POP_TOP)

[STINNER Victor]

Changes by STINNER Victor :


--
title: compiler: don't emit LOAD_CONST instructions for constant statements? -> 
compiler: ignore constants used as statements? (don't emit LOAD_CONST+POP_TOP)

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

Changes by Aviv Palivoda :


--
nosy: +palaviv

___
Python tracker 

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

[issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit constants

[Roundup Robot]

Roundup Robot added the comment:

New changeset c5df914e73ad by Victor Stinner in branch 'default':
Fix a refleak in validate_constant()
https://hg.python.org/cpython/rev/c5df914e73ad

--

___
Python tracker 

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

[issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit constants

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0d0d0a05 by Victor Stinner in branch 'default':
Issue #26146: remove useless code
https://hg.python.org/cpython/rev/0d0d0a05

New changeset 58086f0a953a by Victor Stinner in branch 'default':
Issue #26146: enhance ast.Constant error message
https://hg.python.org/cpython/rev/58086f0a953a

--

___
Python tracker 

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

[issue26212] Python with ncurses6.0 will not load _curses module.

[R. Jones]

New submission from R. Jones:

I am trying to compile Python-2.7.10.  This is being done as a user, not root 
and I don't have access to /usr/local other than to avoid all the broken stuff 
in it.

My local is /appl/local

I am installing Python in /appl/local/python-2.7.10

I have ncursest as part of my /appl/local, but python keeps wanting to link 
with /usr/ccs/lib/libcurses.so.  UGH.
"ncursest" was built instead of "ncurses" because I used "--with-pthread" and 
"--enable-reentrant"


I rebuilt ncurses without those two flags but with --with-termlib which built 
libtinfo.so.  When compiling the _curses module, I get this error:

*** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: 
fatal: relocation error: file 
build/lib.solaris-2.10-sun4u.32bit-2.7/_curses.so: symbol _unctrl: referenced 
symbol not found

In this case I can see unctrl is in tinfo...but no matter what I do, I cannot 
get it to add -ltinfo to the link line.

$ nm -s libtinfo.so | grep unctrl
0001d4f8 T unctrl
00039170 r unctrl_blob.5682
00039070 r unctrl_c1.5681
0001d30c T unctrl_sp
00039572 r unctrl_table.5680


So my next attempt was to make a private copy of ncurses for Python without 
--with-termlib, but had to add --enable-termcap and install it in 
/appl/local/python-2.7.10/lib

$ ls -al /appl/local/python-2.7.10/lib
total 15584
drwxr-xr-x   4 gfp-ip   gfp-ip  1024 Jan 26 16:45 .
drwxr-xr-x   6 gfp-ip   gfp-ip96 Jan 26 15:31 ..
-rw-r--r--   1 gfp-ip   gfp-ip120560 Jan 26 15:32 libform.a
-rwxr-xr-x   1 gfp-ip   gfp-ip  1055 Jan 26 15:32 libform.la
lrwxrwxrwx   1 gfp-ip   gfp-ip16 Jan 26 15:32 libform.so -> 
libform.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip16 Jan 26 15:32 libform.so.6 -> 
libform.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip 95604 Jan 26 15:32 libform.so.6.0.0
-rw-r--r--   1 gfp-ip   gfp-ip 61908 Jan 26 15:32 libmenu.a
-rwxr-xr-x   1 gfp-ip   gfp-ip  1055 Jan 26 15:32 libmenu.la
lrwxrwxrwx   1 gfp-ip   gfp-ip16 Jan 26 15:32 libmenu.so -> 
libmenu.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip16 Jan 26 15:32 libmenu.so.6 -> 
libmenu.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip 48060 Jan 26 15:32 libmenu.so.6.0.0
-rw-r--r--   1 gfp-ip   gfp-ip174364 Jan 26 15:32 libncurses++.a
-rwxr-xr-x   1 gfp-ip   gfp-ip  1295 Jan 26 15:32 libncurses++.la
lrwxrwxrwx   1 gfp-ip   gfp-ip21 Jan 26 15:32 libncurses++.so -> 
libncurses++.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip21 Jan 26 15:32 libncurses++.so.6 -> 
libncurses++.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip114812 Jan 26 15:32 libncurses++.so.6.0.0
-rw-r--r--   1 gfp-ip   gfp-ip628332 Jan 26 15:31 libncurses.a
-rwxr-xr-x   1 gfp-ip   gfp-ip  1019 Jan 26 15:31 libncurses.la
lrwxrwxrwx   1 gfp-ip   gfp-ip19 Jan 26 15:31 libncurses.so -> 
libncurses.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip19 Jan 26 15:31 libncurses.so.6 -> 
libncurses.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip478356 Jan 26 15:31 libncurses.so.6.0.0
-rw-r--r--   1 gfp-ip   gfp-ip 26324 Jan 26 15:31 libpanel.a
-rwxr-xr-x   1 gfp-ip   gfp-ip  1062 Jan 26 15:31 libpanel.la
lrwxrwxrwx   1 gfp-ip   gfp-ip17 Jan 26 15:31 libpanel.so -> 
libpanel.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip17 Jan 26 15:31 libpanel.so.6 -> 
libpanel.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip 23652 Jan 26 15:31 libpanel.so.6.0.0

$ nm /appl/local/python-2.7.10/lib/libncurses.so | grep unctrl
0004acac T unctrl
00067540 r unctrl_blob.5717
00067440 r unctrl_c1.5716
0004aac0 T unctrl_sp
00067942 r unctrl_table.5715

So ONCE again, compiling Python module _curses with the new lib:
Script started on Tue Jan 26 19:36:55 2016
$ make
running build
running build_ext
building dbm using ndbm
building '_curses' extension
gcc -fPIC -fno-strict-aliasing -I/appl/local/python-2.7.10/include 
-I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 -DNDEBUG -g 
-fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include 
-I/appl/local/python-2.7.10/include -I/appl/local/include -I/usr/local/include 
-I/appl/logs/local_build/src/python.org/Python-2.7.10/Include 
-I/appl/logs/local_build/src/python.org/Python-2.7.10 -c 
/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.c -o 
build/temp.solaris-2.10-sun4u.32bit-2.7/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.o
/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.c: In 
function 'PyCursesWindow_ChgAt':
/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.c:713:9:
 warning: implicit declaration of function 'mvwchgat' 
[-Wimplicit-function-declaration]
/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.c:717:9:
 warning: implicit declaration of function 'wchgat' 
[-Wimplicit-function-declaration]
gcc -shared -L/appl/local/python-2.7.10/lib 
-Wl,-rpath,/appl/local/python-2.7.10/lib -lncurses 
-R/appl/local/python-2.7.10/lib -L/appl/local/lib 

[issue26213] Document BUILD_LIST_UNPACK & BUILD_TUPLE_UNPACK

[Brett Cannon]

New submission from Brett Cannon:

Turns out the BUILD_TUPLE_UNPACK and BUILD_LIST_UNPACK opcodes are undocumented 
in the dis module.

--
assignee: docs@python
components: Documentation
messages: 258985
nosy: benjamin.peterson, brett.cannon, docs@python
priority: low
severity: normal
stage: needs patch
status: open
title: Document BUILD_LIST_UNPACK & BUILD_TUPLE_UNPACK
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

[issue26213] Document BUILD_*_UNPACK opcodes

[Brett Cannon]

Brett Cannon added the comment:

There are also BUILD_SET_UNPACK and BUILD_MAP_UNPACK as well.

--
title: Document BUILD_LIST_UNPACK & BUILD_TUPLE_UNPACK -> Document 
BUILD_*_UNPACK opcodes

___
Python tracker 

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

[issue26039] More flexibility in zipfile interface

[Thomas Kluyver]

Changes by Thomas Kluyver :


Added file: http://bugs.python.org/file41722/zipinfo-from-file2.patch

___
Python tracker 

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

[issue26128] Let the subprocess.STARTUPINFO constructor take arguments

[Martin Panter]

Changes by Martin Panter :


--
stage:  -> needs patch

___
Python tracker 

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

[issue19225] lack of PyExc_BufferError doc

[Martin Panter]

Martin Panter added the comment:

General approach looks good. I left some review comments.

VMSError: I think this is Python 2 only, where it seems to be in a similar 
situation to WindowsError. According to Issue 16136 it was removed in Python 
3.4. But it looks like your patch is against Python 3.

If you want to fix the alphabetical order, I think that is okay to do in the 
same patch. Otherwise, the current state is okay, but please put your 
BufferError in the right place :)

--
nosy: +martin.panter
stage: needs patch -> patch review

___
Python tracker 

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

[issue26181] argparse can't handle positional argument after list (help message is wrong)

[Martin Panter]

Martin Panter added the comment:

I think we should discuss this in the existing reports:

Issue 9182: Mention the “--” divider in the documentation and usage as a 
workaround. Perhaps you could mention your proposal to put positional arguments 
before the options there.

Issue 9338: Change the implementation to be smarter in this situation.

--
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> document “--” as a way to distinguish option w/ narg='+' from 
positional argument in argparse

___
Python tracker 

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

[issue26188] Provide more helpful error message when `await` is called inside non-`async` method

[Martin Panter]

Martin Panter added the comment:

According to PEP 492, “await” is still allowed to be an ordinary identifier in 
non-async functions until Python 3.7. Which means you are still allowed to write

def oh_hai():
await = "something"

The proposed error message would need to be smart enough to distinguish the two 
cases.

--
nosy: +martin.panter

___
Python tracker 

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

[issue26211] HTMLParser: “AssertionError: we should not get here!”

[Xiang Zhang]

Xiang Zhang added the comment:

Test your html file and can not get the AssertionError. Seems everything works 
fine. Could you please provide more info?

--
nosy: +xiang.zhang

___
Python tracker 

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

[issue26211] HTMLParser: “AssertionError: we should not get here!”

[Xiang Zhang]

Xiang Zhang added the comment:

After reading Issue26210, I can get the AssertionError when there is a 
self.reset() in handle_endtag. I don't think it's proper to use reset in the 
process of parsing. From the samples I find on Web, reset is commonly used to 
set extra attributes on the parser so you can apply your own logic when 
parsing. I can not understand why reset is called in handle_endtag.

--

___
Python tracker 

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

[issue26210] `HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked

[Xiang Zhang]

Xiang Zhang added the comment:

reset just set some attributes to the initial states and it does not control 
the parsing process. So reading the gohead function, even if reset is called in 
handle_endtag and all data are discarded, it is still possible for the process 
to move forward.

--
nosy: +xiang.zhang

___
Python tracker 

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

[issue26212] Python with ncurses6.0 will not load _curses module on Solaris 10

[R. Jones]

R. Jones added the comment:

Note:  This issue is on Solaris 10 using GCC 4.7.2 and the Solaris linker "ld".

--
title: Python with ncurses6.0 will not load _curses module. -> Python with 
ncurses6.0 will not load _curses module on Solaris 10

___
Python tracker 

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

[issue22625] When cross-compiling, don’t try to execute binaries

[ƦOB COASTN]

ƦOB COASTN added the comment:

Similar patch used for 3.5
Additionally required:
-Python/importlib_external.h: $(srcdir)/Lib/importlib/_bootstrap_external.py 
Programs/_freeze_importlib
+Python/importlib_external.h: $(srcdir)/Lib/importlib/_bootstrap_external.py
+   $(MAKE) Programs/_freeze_importlib
./Programs/_freeze_importlib \
$(srcdir)/Lib/importlib/_bootstrap_external.py 
Python/importlib_external.h

--
nosy: +mancoast

___
Python tracker 

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

[issue26206] test_socket.testRecvmsgPeek() timeout on "AMD64 Debian root 3.x" buildbot

[STINNER Victor]

STINNER Victor added the comment:

Info about the buildbot (regrtest headers):

== CPython 3.6.0a0 (default:fadc4b53b840, Jan 26 2016, 18:14:53) [GCC 4.7.2]
==   Linux-3.2.0-4-amd64-x86_64-with-debian-7.9 little-endian
==   hash algorithm: siphash24 64bit
==   /root/buildarea/3.x.angelico-debian-amd64/build/build/test_python_26835

Info about the failing test:

@requireAttrs(socket, "MSG_PEEK")
def testRecvmsgPeek(self):
# Check that MSG_PEEK in flags enables examination of pending
# data without consuming it.

The unit test is old, it was introduced in 2011:

changeset:   72029:c64216addd7f
parent:  72027:1702749b1060
user:Nick Coghlan 
date:Mon Aug 22 11:55:57 2011 +1000
files:   Doc/library/socket.rst Doc/whatsnew/3.3.rst Lib/ssl.py 
Lib/test/test_socket.py Lib/test/test_ssl.py Misc/NEWS Modules/socketmodule.c
description:
Add support for the send/recvmsg API to the socket module. Patch by David 
Watson and Heiko Wundram. (Closes #6560)

--

___
Python tracker 

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

[issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot

[STINNER Victor]

STINNER Victor added the comment:

Same issue on Windows 8 and Windows 10 buildbots:

* 
http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/1716/steps/test/logs/stdio
* 
http://buildbot.python.org/all/builders/AMD64%20Windows10%203.x/builds/598/steps/test/logs/stdio

--

___
Python tracker 

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

[issue26206] test_socket.testRecvmsgPeek() timeout on "AMD64 Debian root 3.x" buildbot

[STINNER Victor]

New submission from STINNER Victor:

The bug started between build 3071 and 3072:
* 
http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/3071
* 
http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/3072

Maybe it's an issue on the buildbot, not on the code directly?

http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/3142/steps/test/logs/stdio

[300/400] test_socket
Timeout (1:00:00)!
Thread 0x2b16599dab20 (most recent call first):
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_socket.py", line 
1920 in doRecvmsg
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_socket.py", line 
2376 in testRecvmsgPeek
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/case.py", 
line 600 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/case.py", 
line 648 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", 
line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", 
line 84 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", 
line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", 
line 84 in __call__
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/runner.py", line 
176 in run
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", 
line 1780 in _run_suite
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", 
line 1814 in run_unittest
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_socket.py", line 
5345 in test_main
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/runtest.py",
 line 162 in runtest_inner
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/runtest.py",
 line 115 in runtest
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", 
line 295 in run_tests_sequential
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", 
line 356 in run_tests
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", 
line 392 in main
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", 
line 433 in main
  File 
"/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", 
line 455 in main_in_temp_cwd
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/__main__.py", 
line 3 in 
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/runpy.py", line 85 
in _run_code
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/runpy.py", line 184 
in _run_module_as_main
make: *** [buildbottest] Error 1

--
components: Tests
keywords: buildbot
messages: 258952
nosy: haypo
priority: normal
severity: normal
status: open
title: test_socket.testRecvmsgPeek() timeout on "AMD64 Debian root 3.x" buildbot
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

[issue26206] test_socket.testRecvmsgPeek() timeout on "AMD64 Debian root 3.x" buildbot

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +Rosuav

___
Python tracker 

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

[issue25850] Building extensions with MSVC 2015 Express fails

[STINNER Victor]

STINNER Victor added the comment:

test_distutils is now failing on "AMD64 Windows7 SP1 3.x" buildbot: please see 
issue #26207.

--
nosy: +haypo

___
Python tracker 

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

[issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot

[STINNER Victor]

New submission from STINNER Victor:

It looks like the buildbot started to fail with the build 
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7166/

The change 37dc870175be43cdcb6920cc642a99fc10cd4bb4 of issue #25850 changed 
Lib/distutils/_msvccompiler.py: "Use cross-compilation by default for 64-bit 
Windows.". It's an interesting suspect.

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7214/steps/test/logs/stdio

test test_distutils failed

==
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
--
Traceback (most recent call last):
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\_msvccompiler.py", 
line 480, in link
self.spawn([self.linker] + ld_args)
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\_msvccompiler.py", 
line 503, in spawn
return super().spawn(cmd)
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\ccompiler.py", line 
909, in spawn
spawn(cmd, dry_run=self.dry_run)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\spawn.py", 
line 38, in spawn
_spawn_nt(cmd, search_path, dry_run=dry_run)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\spawn.py", 
line 81, in _spawn_nt
"command %r failed with exit status %d" % (cmd, rc))
distutils.errors.DistutilsExecError: command 'C:\\Program Files 
(x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\x86_amd64\\link.exe' failed with 
exit status 1101

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\tests\test_install.py",
 line 215, in test_record_extensions
cmd.run()
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\install.py",
 line 539, in run
self.run_command('build')
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\cmd.py", 
line 313, in run_command
self.distribution.run_command(command)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\dist.py", 
line 974, in run_command
cmd_obj.run()
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build.py", 
line 135, in run
self.run_command(cmd_name)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\cmd.py", 
line 313, in run_command
self.distribution.run_command(command)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\dist.py", 
line 974, in run_command
cmd_obj.run()
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build_ext.py",
 line 338, in run
self.build_extensions()
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build_ext.py",
 line 447, in build_extensions
self._build_extensions_serial()
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build_ext.py",
 line 472, in _build_extensions_serial
self.build_extension(ext)
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build_ext.py",
 line 557, in build_extension
target_lang=language)
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\ccompiler.py", line 
717, in link_shared_object
extra_preargs, extra_postargs, build_temp, target_lang)
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\_msvccompiler.py", 
line 483, in link
raise LinkError(msg)
distutils.errors.LinkError: command 'C:\\Program Files (x86)\\Microsoft Visual 
Studio 14.0\\VC\\BIN\\x86_amd64\\link.exe' failed with exit status 1101

--
components: Tests, Windows
keywords: buildbot
messages: 258954
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot

___
Python tracker 

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