[issue23749] asyncio missing wrap_socket (starttls)

[박세원]

박세원 added the comment:

https://bugs.python.org/review/23749/#msg1
yuri, did you saw guido added review on your patch?

--
nosy: +박세원

___
Python tracker 

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

[issue27364] Deprecate invalid unicode escape sequences

[Martin Panter]

Martin Panter added the comment:

Forgot to say I reviewed invalid_stdlib_escapes_1.patch the other day and can’t 
see any problems.

--

___
Python tracker 

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

[issue27380] IDLE: add base Query dialog with ttk widgets

[Terry J. Reedy]

Terry J. Reedy added the comment:

Revised load_module and new query.ModuleName work, including when invoked by 
open_class_browser.  Tests are need for both.  One problem was that using 
withdrawn root rather than a text as parent caused query.Query to not appear, 
so wait_window could not be terminated.

--
stage: needs patch -> test needed
Added file: http://bugs.python.org/file43570/query3.diff

___
Python tracker 

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

[issue27364] Deprecate invalid unicode escape sequences

[Emanuel Barry]

Emanuel Barry added the comment:

Just brought this to the attention of the code-quality mailing list, so linter 
maintainers should (hopefully!) catch up soon.

Also new patch, I forgot to add '\c' in the tests.

--
Added file: 
http://bugs.python.org/file43569/deprecate_invalid_escapes_only_3.patch

___
Python tracker 

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

[issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN

[Andre Merzky]

Andre Merzky added the comment:

I can confirm that the patch provided by Victor addresses the problem.  It 
seems to be against the current HEAD -- is there a chance that this will be 
backported to 2.7 (which is what I need to use)?

Thanks!  Andre.

--

___
Python tracker 

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

[issue27403] os.path.dirname doesn't handle Windows' URNs correctly

[Eryk Sun]

Eryk Sun added the comment:

Paths starting with "\\.\" (or  "//./") and "\\?\" are not UNC paths. I've 
provided some explanations and examples below, and I also encourage you to read 
"Naming Files, Paths, and Namespaces":

https://msdn.microsoft.com/en-us/library/aa365247

"\\.\" is the general way to access DOS devices, but with some path processing 
still enabled. For example:

>>> files = os.listdir(r'//./C:/Windows/System32/..')
>>> [x for x in files if x[:2] == 'py']
['py.exe', 'pyw.exe']

Notice that using slash and ".." is allowed. This form doesn't allow relative 
paths that depend on per-drive current directories. It's actually not 
recommended to use "\\.\" to access files on drive letters. Normally it's used 
with drive letters only when directly opening a volume. For example:

>>> fd = os.open(r'\\.\C:', os.O_RDONLY | os.O_BINARY)
>>> os.read(fd, 512)[:7]
b'\xebR\x90NTFS'

The "\\?\" prefix allows the most access to the NT kernel namespace from within 
the Windows API (e.g. file paths can be up to 32K characters instead of the DOS 
limit of 260 characters). It does so by disabling all path processing, which 
means the onus is on the programmer to provide a fully-qualified, Unicode path 
that only uses backslash as the path separator.

So why does "\\.\" exist? Some DOS devices are made implicitly available in the 
Windows API, such as DOS drive letters and "CON". However, the Windows API 
greatly extends the number of 'DOS' devices (e.g. the "PhysicalDrive0" device 
for low-level access to the first disk). Accessing these devices unambiguously 
requires the "\\.\" prefix. A common example is using "\\.\pipe\[pipe name]" to 
open a NamedPipe. You can even list the NamedPipe filesystem in Python. For 
example:

>>> p1, p2 = multiprocessing.Pipe()
>>> [x for x in os.listdir(r'\\.\pipe') if x[:2] == 'py']
['pyc-719-1-hoirbkzb']

Global DOS device names are defined in the kernel's "\Global??" directory. Some 
DOS devices, such as mapped network drives, are usually defined local to a 
logon session in the kernel's "\Sessions\0\DosDevices\[Logon Session ID]" 
directory. In the examples I gave, you may have noticed that each native kernel 
path starts with "\??\". This is a virtual directory in the kernel (and only 
the kernel). It instructs the object manager to first search the local session 
DOS devices and then the global DOS devices.

A DOS device is almost always implemented as an object symbolic link to the 
real NT device name in the kernel's "\Device" directory. For example, 
"\Global??\PIPE" links to "\Device\NamedPipe" and the "C:" drive may be a link 
to "\Device\HarddiskVolume2". This device is what the kernel actually opened in 
the previous example that read from "\\.\C:". Note that this accesses the 
volume itself, not the root directory of the filesystem that resides on the 
volume. The latter is "\\.C:\". The trailing backslash makes all the 
difference. (Opening a directory such as the latter requires backup semantics, 
as described in the CreateFile docs.)

If a DOS drive letter is assigned to a volume, the assignment is stored in the 
registry by the volume's ID. (Dynamic volumes that span multiple disks also 
contain a drive letter hint.) For volume devices, the kernel also creates a 
GUID name that's always available and allows mounting a volume in a directory 
using an NTFS reparse point (e.g. see the output of mountvol.exe). You can also 
use GUID volume names in the Windows API. For example:

>>> path = r'\\?\Volume{1693b540----612e}\Windows'
>>> files = os.listdir(path)
>>> [x for x in files if x[:2] == 'py']
['py.exe', 'pyw.exe']

But normally you'd just mount the volume, which can even be recursively mounted 
within itself. For example:

>>> os.mkdir('C:\\SystemVolume')
>>> subprocess.call(r'mountvol C:\SystemVolume 
\\?\Volume{1693b540----612e}')
0
>>> files = os.listdir(r'C:\SystemVolume\Windows')
>>> [x for x in files if x[:2] == 'py']
['py.exe', 'pyw.exe']

--

___
Python tracker 

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

[issue27380] IDLE: add base Query dialog with ttk widgets

[Terry J. Reedy]

Terry J. Reedy added the comment:

Thanks, I will switch to True and False.

I am aware of the possibility of separately importing the constants, but like 
some others, I prefer the strings.  Compile-time checking is a good point, 
especially with no run tests.  In this case, test_query has 100% coverage of 
query.py.

Minor question: While trying to  use the new widget (instead of tkSimpledialog) 
in (editor.EditorWindow).open_module I had problems which I am trying to pin 
down by taking smaller steps.  As part of this, I tried this minimal code that 
uses Query.

from idlelib import query
from tkinter import Tk
root = Tk()
name = query.Query(root, "Open Module",
 "Enter the name of a Python module\n"
 "to search on sys.path and open:",).result
print(name)

It works fine except that entry.focus_set() is not working for me with this 
call (or else it is not staying set) even though it works fine when 
configdialog calls the SectionName subclass.  I know Windows is more 
troublesome than *nix about focus, but do you have any idea why calling Query 
this way, instead of as in the committed patch, would make a difference?

--
stage: patch review -> needs patch

___
Python tracker 

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

[issue27403] os.path.dirname doesn't handle Windows' URNs correctly

[Dustin Oprea]

Dustin Oprea added the comment:

Thank you for your elaborate response. I appreciate knowing that 
"\\server\share" could be considered as the "drive" portion of the path.

I'm having trouble determining if "\\?\" is literally some type of valid UNC 
prefix or you're just using it to represent some format/idea. Just curious.

--

___
Python tracker 

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

[issue27255] More opcode predictions

[Raymond Hettinger]

Raymond Hettinger added the comment:

The BUILD_SLICE pairing with BINARY_SUBSCR has a tight conceptual linkage with 
the lookup case dominating use patterns over slice deletion and slice 
assignment.  IIRC, I passed on that pairing long ago because even though the 
predictive power was good, it didn't come up much (a very, very low percentage 
of executed op-codes in any real programs).  That would mean the user wouldn't 
be likely to see any benefit and I worried about the cost (global prediction 
tables have a finite size and are subject to aliased false positives, so when 
in doubt, it is better to not do it at all.)  

The UNPACK_SEQUENCE pairing with STORE_FAST had the opposite issue.  The two 
arise in real code often enough to be interesting, but I wasn't as confident 
that it wasn't competing with alternative successors like STORE_NAME or 
attribute storage.  Here, the statistics are heavily influenced by whatever is 
being profiled.  Given that I wasn't confident in the pairing, I passed on it.

That said, there's nothing terribly wrong with either, so it is hard to veto 
them.  Now as well as back when the opcode predictions were first studied, I 
remain -0 on both pairings.  

In general, we should have a bias towards there being relatively few 
predictions (each one adds size to the generated code, adds load to the branch 
prediction tables, and adds to the cognitive load of anyone modifying the 
compiler, the peephole optimizer, or adding new opcodes) and there should be a 
preference to leave out cases where there is doubt.

I'll leave it to you to decide whether either one of these should go in (I just 
wanted you to know why they weren't included in the first place).

--

___
Python tracker 

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

[issue27403] os.path.dirname doesn't handle Windows' URNs correctly

[Eryk Sun]

Eryk Sun added the comment:

dirname() is implemented via split(), which begins by calling splitdrive(). The 
'drive' for a UNC path is the r"\\server\share" component. For example:

>>> path = r'\\server\share\folder\file'
>>> os.path.splitdrive(path)
('server\\share', '\\folder\\file')
>>> os.path.split(path)
('server\\share\\folder', 'file')
>>> os.path.dirname(path)
'server\\share\\folder'

If you double the initial slashes, it's no longer a valid UNC path:

>>> path = r'server\\share\\folder\\file'
>>> os.path.splitdrive(path)
('', 'serversharefolderfile')
>>> os.path.split(path)
('serversharefolder', 'file')
>>> os.path.dirname(path)
'serversharefolder'

Windows itself will attempt to handle it as a UNC path, but the path is 
invalid. Specifically, before passing the path to the kernel, Windows collapses 
all of the extra slashes, except an initial slash count greater than two always 
leaves an extra slash in the path. For example:

>>> open(r'server\\share\\folder\\file')
Breakpoint 0 hit
ntdll!NtCreateFile:
7ffb`a1f25b70 4c8bd1  mov r10,rcx
0:000> !obja @r8
Obja +0049781ef160 at 0049781ef160:
Name is \??\UNC\\server\share\folder\file
OBJ_CASE_INSENSITIVE

Notice the extra backlash in "UNC\\server". Thus a valid UNC path must start 
with exactly two slashes. 

Using forward slash is generally fine. The Windows API substitutes backslash 
for slash before passing a path to the kernel. For example:

>>> open(r'//server/share/folder/file')
Breakpoint 0 hit
ntdll!NtCreateFile:
7ffb`a1f25b70 4c8bd1  mov r10,rcx
0:000> !obja @r8
Obja +0049781ef160 at 0049781ef160:
Name is \??\UNC\server\share\folder\file
OBJ_CASE_INSENSITIVE

Except you can't use forward slash with a "\\?\" path, which bypasses normal 
path processing. For example:

>>> open(r'\\?\UNC/server/share/folder/file')
Breakpoint 0 hit
ntdll!NtCreateFile:
7ffb`a1f25b70 4c8bd1  mov r10,rcx
0:000> !obja @r8
Obja +0049781ef160 at 0049781ef160:
Name is \??\UNC/server/share/folder/file
OBJ_CASE_INSENSITIVE

In the kernel '/' isn't a path separator. It's just another name character, so 
this looks for a DOS device named "UNC/server/share/folder/file". Microsoft 
file systems forbid using slash in names (for POSIX compatibility and to avoid 
needless confusion), but you can use slash in the name of kernel objects such 
as Event objects, or even in the name of DOS devices defined via 
DefineDosDevice.

--

___
Python tracker 

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

[issue27403] os.path.dirname doesn't handle Windows' URNs correctly

[Eryk Sun]

Changes by Eryk Sun :


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

___
Python tracker 

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

[issue27173] Modern Unix key bindings for IDLE

[Terry J. Reedy]

Terry J. Reedy added the comment:

I rebooted and reran build in case this was another funny heisenbug.  It isn't. 
 Before patch, start 3.6 repository IDLE. Click Options, Configure IDLE, and 
Keys tab.  Look at 'Use a Custom Key Set'.  It says 'Terry', which is correct.

After patch: repeat. It says 'IDLE Modern Unix'.  Custom Key Binding box 
reflects change. Repeat with 3.5 repository IDLE: it still says Terry.  Ditto 
for installed 3.6.0a2. 

My custom [Keys] section: 

[Keys]
default = False
name2 = IDLE Modern Unix
name = Terry

The problem is that name2 should be treated only as default, never as custom, 
and should be used only if default=True.  This is true in CurrentTheme.  
However, your revised CurrentKeys uses it first and unconditionally.  Hence the 
observed behavior.

CurrentKeys should use the same logic as CurrentTheme.  In fact, the common 
logic should factored out into a separate function with two or three parameters 
and used by both.

If, as you claim, CurrentTheme is buggy, it should be fixed before using it as 
the template for both.  To test and claim that it was future proof, I did 
something like the following last fall. First set config-main.cfg [Keys] name2 
to something non-existent, that might be added in the future.

[Theme]
default = True
name2 = IDLE Future
name = Custom Dark

Then start, for instance, 3.5.2.  The non-existent IDLE Future is ignored and 
replaced with the default default IDLE Classic, as intended in the code.  No 
warnings.  What exactly did you do to claim otherwise?

---
Also wrong, even with your patch removed: '()Use a Built-in Key Set' says IDLE 
Classic Mac (slightly grayed) on all versions. If I select built-in, change 
built-in selection to IDLE Classic Windows, select custom again, click [OK] to 
close, and reopen, the unselected built-in has switched back to Mac.  This must 
be a pre-existing bug that makes Classic Mac the default builtin when custom is 
selected, This is in spite of config-main.def having 

[Keys]
default= 1
name= IDLE Classic Windows

This, of course, is also wrong on non-Windows, which is why you changed it.  
But it is also being ignored when custom is selected.

The problem must be in how configdialog gets the default key set when the 
current keyset is custom. The widget is a DynOptionMenu, created in 
CreatePageKeys, line 335, with no content.  The options are set in LoadKeyCfg, 
lines 1055 and 1069.  The latter is used when the current key is custom.  It 
sets the grayed out default option to the alphabetically first among default 
key sets.

itemList = idleConf.GetSectionList('default', 'keys')
itemList.sort()
self.optMenuKeysBuiltin.SetMenu(itemList, itemList[0])

itemList[0] should be replaced by your new system-sensitive 
idleConf.DefaultKeys().

--

___
Python tracker 

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

[issue27403] os.path.dirname doesn't handle Windows' URNs correctly

[Eryk Sun]

Eryk Sun added the comment:

dirname() is implemented via split(), which begins by calling splitdrive(). The 
'drive' for a UNC path is the r"\\server\share" component. For example:

>>> path = r'\\server\share\folder\file'
>>> os.path.splitdrive(path)
('server\\share', '\\folder\\file')
>>> os.path.split(path)
('server\\share\\folder', 'file')
>>> os.path.dirname(path)
'server\\share\\folder'

If you double the initial slashes, it's no longer a valid UNC path:

>>> path = r'server\\share\\folder\\file'
>>> os.path.splitdrive(path)
('', 'serversharefolderfile')
>>> os.path.split(path)
('serversharefolder', 'file')
>>> os.path.dirname(path)
'serversharefolder'

Windows itself will attempt to handle it as a UNC path, but the path is 
invalid. Specifically, before passing the path to the kernel, Windows collapses 
all of the extra slashes, except an initial slash count greater than two always 
leaves an extra slash in the path. For example:

>>> open(r'server\\share\\folder\\file')
Breakpoint 0 hit
ntdll!NtCreateFile:
7ffb`a1f25b70 4c8bd1  mov r10,rcx
0:000> !obja @r8
Obja +0049781ef160 at 0049781ef160:
Name is \??\UNC\\server\share\folder\file
OBJ_CASE_INSENSITIVE

Notice the extra backlash in "UNC\\server". Thus a valid UNC path must start 
with exactly two slashes. 

Using forward slash is generally fine. The Windows API substitutes backslash 
for slash before passing a path to the kernel. For example:

>>> open(r'//server/share/folder/file')
Breakpoint 0 hit
ntdll!NtCreateFile:
7ffb`a1f25b70 4c8bd1  mov r10,rcx
0:000> !obja @r8
Obja +0049781ef160 at 0049781ef160:
Name is \??\UNC\server\share\folder\file
OBJ_CASE_INSENSITIVE

Except you can't use forward slash with a "\\?\" path, which bypasses normal 
path processing. For example:

>>> open(r'\\?\UNC/server/share/folder/file')
Breakpoint 0 hit
ntdll!NtCreateFile:
7ffb`a1f25b70 4c8bd1  mov r10,rcx
0:000> !obja @r8
Obja +0049781ef160 at 0049781ef160:
Name is \??\UNC/server/share/folder/file
OBJ_CASE_INSENSITIVE

In the kernel '/' isn't a path separator. It's just another name character, so 
this (potentially) looks for a server named "/server/share/folder/file". 
Microsoft file systems forbid using slash in names (for POSIX compatibility and 
to avoid needless confusion), but you can use slash in the name of kernel 
objects such as Event objects, or even in the name of DOS devices defined via 
DefineDosDevice.

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

[issue27404] Misc/NEWS: add [Security] prefix to Python 3.5.2 changelog

[STINNER Victor]

New submission from STINNER Victor:

As discussed on the Security-SIG mailing list, changes related to security 
should be prefixed by [Security]:

https://mail.python.org/pipermail/security-sig/2016-June/03.html

Here is a first patch for Python 3.5.2 (and the future 3.5.3) changelog.

--
files: NEWS.patch
keywords: patch
messages: 269405
nosy: haypo
priority: normal
severity: normal
status: open
title: Misc/NEWS: add [Security] prefix to Python 3.5.2 changelog
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file43568/NEWS.patch

___
Python tracker 

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

[issue27403] os.path.dirname doesn't handle Windows' URNs correctly

[Dustin Oprea]

New submission from Dustin Oprea:

Notice that os.path.dirname() returns whatever it is given if it is given a 
URN, regardless of slash-type. Oddly, you have to double-up the forward-slashes 
(like you're escaping them) in order to get the correct result (if you're using 
forward-slashes). Back-slashes appear to be broken no matter what.

C:\Python35-32>python
Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path.dirname("a\\b")
'a\\b'
>>> os.path.dirname("//a/b")
'//a/b'
>>> os.path.dirname("a//b")
'a'

Any ideas?

--
components: Windows
messages: 269404
nosy: Dustin.Oprea, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.dirname doesn't handle Windows' URNs correctly
type: behavior
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

[issue27352] Bug in IMPORT_NAME

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thanks Victor!

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

[issue27352] Bug in IMPORT_NAME

[Roundup Robot]

Roundup Robot added the comment:

New changeset e5063a82f490 by Serhiy Storchaka in branch 'default':
Issue #27352: Fixed an error message in a test.
https://hg.python.org/cpython/rev/e5063a82f490

--

___
Python tracker 

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

[issue27352] Bug in IMPORT_NAME

[STINNER Victor]

STINNER Victor added the comment:

You broke Python! Example:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/4853/steps/test/logs/stdio


==
FAIL: test_importfrom (test.test_ast.ASTValidatorTests)
--
Traceback (most recent call last):
  File 
"/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_ast.py", 
line 757, in test_importfrom
self.stmt(imp, "level less than -1")
  File 
"/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_ast.py", 
line 579, in stmt
self.mod(mod, msg)
  File 
"/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_ast.py", 
line 571, in mod
self.assertIn(msg, str(cm.exception))
AssertionError: 'level less than -1' not found in 'Negative ImportFrom level'

--
nosy: +haypo
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue22557] Local import is too slow

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

faster_import_pkg.patch optimizes also an import of names with dots.

$ ./python -m timeit 'import os.path'
Unpatched:10 loops, best of 3: 2.08 usec per loop
faster_import_5.patch:100 loops, best of 3: 1.79 usec per loop
faster_import_pkg.patch:  100 loops, best of 3: 0.474 usec per loop

--
Added file: http://bugs.python.org/file43567/faster_import_pkg.patch

___
Python tracker 

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

[issue22557] Local import is too slow

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file43566/faster_import_5.patch

___
Python tracker 

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

[issue27401] Wrong FTP links in 3.5.2 installer

[Zachary Ware]

Zachary Ware added the comment:

Yep, looks fine now.  I suspect from a couple of commits that Steve just did he 
did in fact have to purge cache :)

Thanks, Steve!

--
status: open -> closed

___
Python tracker 

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

[issue27401] Wrong FTP links in 3.5.2 installer

[Larry Hastings]

Larry Hastings added the comment:

I can independently confirm that the "amd64" directory is in the proper place, 
and all relevant files & directories look like they have the correct 
permissions.  I did that by logging in to the appropriate server and nosing 
around.

Also, the web link works fine too, for me:

https://www.python.org/ftp/python/3.5.2/amd64/

If I click on that I see all the various msi and msu files.  LGTM

--

___
Python tracker 

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

[issue27401] Wrong FTP links in 3.5.2 installer

[Zachary Ware]

Zachary Ware added the comment:

I'm still getting 404s; I'm not sure if there's cache to be purged or 
something, but I can't see that the ...amd64/ dir exists yet, at least from a 
browser.  I haven't tried an actual installation.

--

___
Python tracker 

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

[issue27401] Wrong FTP links in 3.5.2 installer

[Steve Dower]

Steve Dower added the comment:

Should be good now. Thanks for the heads-up!

--
resolution:  -> fixed
stage:  -> resolved

___
Python tracker 

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

[issue27352] Bug in IMPORT_NAME

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thanks Brett.

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

___
Python tracker 

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

[issue27352] Bug in IMPORT_NAME

[Roundup Robot]

Roundup Robot added the comment:

New changeset e3164c9edb0b by Serhiy Storchaka in branch 'default':
Issue #27352: Correct the validation of the ImportFrom AST node and simplify
https://hg.python.org/cpython/rev/e3164c9edb0b

--
nosy: +python-dev

___
Python tracker 

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

[issue27401] Wrong FTP links in 3.5.2 installer

[Steve Dower]

Steve Dower added the comment:

Actually, the correct link is amd64/, but it didn't upload on my second try, 
apparently. Or somehow disappeared...

Fixing that now.

--

___
Python tracker 

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

[issue27387] Thread hangs on str.encode() when locale is not set

[R. David Murray]

R. David Murray added the comment:

No, I'm talking about the threading docs, not the encoding docs.  I think 
that's the only place it matters.  Specifically, in the section that I linked 
to, in the bullet point that warns against launching threads on import, it can 
note that even if you try to make your own code avoid the import lock, implicit 
imports such as the one done by encode/decode can trip you up.

--

___
Python tracker 

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

[issue27255] More opcode predictions

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Raymond. Committed without the prediction from DUP_TOP_TWO to 
BINARY_SUBSCR.

What are you think about following highly predictive pairs?

1. From UNPACK_SEQUENCE to STORE_FAST with 96.5% probability. This is the 15th 
of most common pairs. It is more common than any other predicted pairs except 
the COMPARE_OP/POP_JUMP_IF_FALSE pair. I suppose it is mostly used in for loops 
over dict.items(), enumerate(), etc. I suppose the remaining 3.5% are unpacking 
to object attributes (like "self.x, self.y = ...").

2. From BUILD_SLICE to BINARY_SUBSCR with 99.3% probability. This is the 37th 
of most common pairs. It is more common than any other predicted pairs except 
the three most common pairs. The remaining 0.7% are slice assignment (0.42%), 
slice deleting (0.29%), slice inplace operations and extended slices.

FYI here is a list of most common pairs (predicted pairs are starred).

  1. 5.84%  LOAD_FAST LOAD_FAST22.6%
  2. 5.16%  LOAD_FAST LOAD_ATTR20.0%
  3. 4.18%  COMPARE_OP POP_JUMP_IF_FALSE   82.9% *
  4. 3.97%  POP_JUMP_IF_FALSE LOAD_FAST66.3%
  5. 3.90%  STORE_FAST LOAD_FAST   47.2%
  6. 3.70%  LOAD_FAST CALL_FUNCTION14.3%
  7. 3.36%  LOAD_FAST LOAD_CONST   13.0%
  8. 2.64%  LOAD_ATTR LOAD_FAST35.2%
  9. 2.28%  LOAD_CONST COMPARE_OP  26.7%
 10. 2.12%  STORE_FAST STORE_FAST  25.6%
 11. 2.09%  LOAD_GLOBAL LOAD_FAST  37.5%
 12. 1.49%  CALL_FUNCTION STORE_FAST   20.5%
 13. 1.44%  <0> LOAD_FAST  39.1%
 14. 1.37%  JUMP_ABSOLUTE FOR_ITER 77.6%
 15. 1.29%  UNPACK_SEQUENCE STORE_FAST 96.5%
 16. 1.28%  CALL_FUNCTION POP_TOP  17.7%
 17. 1.28%  LOAD_FAST LOAD_GLOBAL   4.9%
 18. 1.26%  FOR_ITER STORE_FAST50.3% *
 19. 1.25%  LOAD_CONST RETURN_VALUE14.6%
 20. 1.19%  LOAD_ATTR LOAD_CONST   15.9%
...
 36. 0.65%  COMPARE_OP POP_JUMP_IF_TRUE13.0% *
 37. 0.65%  BUILD_SLICE BINARY_SUBSCR  99.3%
...
 45. 0.55%  SETUP_LOOP LOAD_FAST   80.7%
 46. 0.55%  GET_ITER FOR_ITER  71.9% *
 47. 0.53%  FOR_ITER UNPACK_SEQUENCE   21.2% *
...
 50. 0.50%  FOR_ITER POP_BLOCK 20.0% *
...
 66. 0.33%  ROT_TWO STORE_FAST 85.8%
...
 71. 0.31%  INPLACE_ADD STORE_FAST 92.1%
...
 73. 0.30%  LIST_APPEND JUMP_ABSOLUTE 100.0% *
...
 90. 0.22%  BUILD_MAP STORE_FAST   85.3%
...
 93. 0.21%  GET_ITER CALL_FUNCTION 28.1% *

--

___
Python tracker 

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

[issue27402] Sequence example in typing module documentation does not typecheck

[Michael Lee]

Michael Lee added the comment:

Whoops, forgot the link to the error in the docs: 

https://docs.python.org/3/library/typing.html#typing.List

--

___
Python tracker 

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

[issue27402] Sequence example in typing module documentation does not typecheck

[Michael Lee]

New submission from Michael Lee:

In the documentation for the `typing` module, the [entry for the `List` 
type][0] uses the following example to help demonstrate when to use `Sequence` 
vs `List`:

T = TypeVar('T', int, float)

def vec2(x: T, y: T) -> List[T]:
return [x, y]

def slice__to_4(vector: Sequence[T]) -> List[T]:
return vector[0:4]

However, the `slice__to_4` function does not actually typecheck since there's 
no guarantee that a slice of a sequence will return a `List`. For example the 
vector could be a numpy array or a custom subclass of 
`collections.abc.Sequence` with an unusual `__getitem__`. (Mypy correctly 
catches this error and complains about an "Incompatible return value type").

The documentation should probably be updated to use an example that _does_ 
typecheck, though I'm not sure what exactly that example might look like? Maybe 
replace `slice__to_4` with something like this?

def keep_positives(vector: Sequence[T]) -> List[T]:
return [item for item in vector if item > 0]

--
assignee: docs@python
components: Documentation
messages: 269389
nosy: docs@python, michael0x2a
priority: normal
severity: normal
status: open
title: Sequence example in typing module documentation does not typecheck
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

[issue27364] Deprecate invalid unicode escape sequences

[Emanuel Barry]

Emanuel Barry added the comment:

Easing transition is always a good idea. I'll contact the PyCQA people later 
today when I'm back home.

On afterthought, it makes sense to wait more than two release cycles before 
making this an error. I don't really have a strong opinion when exactly that 
should happen.

--

___
Python tracker 

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

[issue27387] Thread hangs on str.encode() when locale is not set

[STINNER Victor]

STINNER Victor added the comment:

> Maybe it is worth adding a warning to that section of the 2.7 docs about 
> implicit imports in general and encode/decode in particular?

Ok to add a note to str.encode and str.decode methods to explain that
an import is needed the first time that an encoding is used.

I'm not ok for a warning, we should not discourage developers to use
these methods! They are not dangerous by themself.

--

___
Python tracker 

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

[issue27401] Wrong FTP links in 3.5.2 installer

[Zachary Ware]

Changes by Zachary Ware :


--
assignee:  -> steve.dower
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
priority: normal -> high
title: Wrong FTP links in 5.3.2 installer -> Wrong FTP links in 3.5.2 installer
type: crash -> behavior

___
Python tracker 

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

[issue27387] Thread hangs on str.encode() when locale is not set

[Brett Cannon]

Brett Cannon added the comment:

Adding a note to the docs sounds reasonable.

--

___
Python tracker 

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

[issue27352] Bug in IMPORT_NAME

[Brett Cannon]

Brett Cannon added the comment:

LGTM

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

[issue27255] More opcode predictions

[Roundup Robot]

Roundup Robot added the comment:

New changeset f19c2b28710e by Serhiy Storchaka in branch 'default':
Issue #27255: Added more predictions in ceval.c.
https://hg.python.org/cpython/rev/f19c2b28710e

--
nosy: +python-dev

___
Python tracker 

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

[issue27401] Wrong FTP links in 5.3.2 installer

[Xiang Zhang]

Changes by Xiang Zhang :


--
nosy: +larry

___
Python tracker 

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

[issue27401] Wrong FTP links in 5.3.2 installer

[Jarod Brennfleck]

New submission from Jarod Brennfleck:

So far, the only installers tested is the Python 5.3.2 x86 and x86_64 
installers.

When selecting customise install, the installer is unable to gather the files 
required, because the installer is looking for them in:
https://www.python.org/ftp/python/3.5.2/amd64/

Following the link will result in a 404, as the folder does not exist. This 
reason has been found thanks to the log file of the installation that is given 
upon error during the installation. (Cheers for that! :D)

The correct link is:
https://www.python.org/ftp/python/3.5.2/amd64rc1/

--
components: Installation
messages: 269383
nosy: Jarod Brennfleck
priority: normal
severity: normal
status: open
title: Wrong FTP links in 5.3.2 installer
type: crash
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

[issue27364] Deprecate invalid unicode escape sequences

[Guido van Rossum]

Guido van Rossum added the comment:

I think ultimately it has to become an error (otherwise I wouldn't
have agreed to the warning, silent or not). But because there's so
much 3rd party code that depends on it we indeed need to take
"several" releases before we go there.

Contacting the PyCQA folks would also be a great idea -- can anyone
volunteer to do so?

--

___
Python tracker 

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

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

[Denny Weinberg]

Denny Weinberg added the comment:

Just to be clear:

The error happens after these steps:

1. Call strptime
2. Call cpython function "Py_Finalize" and "Py_Initialize"
3. Call strptime again

Now we get the error "attribute of type 'NoneType' is not callable"

--

___
Python tracker 

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

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

[Denny Weinberg]

New submission from Denny Weinberg:

After calling Py_Finalize and Py_Initialize I get the message "attribute of 
type 'NoneType' is not callable" on the datetime.strptime method.

Example:
from datetime import datetime
s = '20160505 16'
refdatim = datetime.strptime(s, '%Y%m%d %H%M%S')

The first call works fine but it crashes after the re initialization.

Workaround:
from datetime import datetime
s = '20160505 16'
try:
refdatim = datetime.strptime(s, '%Y%m%d %H%M%S')
except TypeError:
import time
refdatim = datetime.fromtimestamp(time.mktime(time.strptime(s, '%Y%m%d 
%H%M%S')))

Related Issue: Issue17408 ("second python execution fails when embedding")

--
components: Interpreter Core
messages: 269379
nosy: Denny Weinberg, palm.kevin
priority: normal
severity: normal
status: open
title: Datetime NoneType after calling Py_Finalize and Py_Initialize
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

[issue17408] second python execution fails when embedding

[Denny Weinberg]

Denny Weinberg added the comment:

Ok,

thank you very much for your comments.

See Issue27400

--

___
Python tracker 

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

[issue17408] second python execution fails when embedding

[R. David Murray]

R. David Murray added the comment:

The interpreter is not crashing in your case, so this is a mostly-unrelated 
problem.  (The part that is related is that it is triggered by module 
finalization.)  As Berker said, please open a new issue, but be warned that it 
may get closed as a being addressed by the issue for rewriting the python 
startup sequence (pep 432 I think, which I think Nick has resurrected), since 
this is a systemic problem.  On the other hand there might be a way to fix it 
in the datetime module if someone decides it is worth doing.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue17408] second python execution fails when embedding

[Berker Peksag]

Berker Peksag added the comment:

We don't re-open old issues (this was closed more than 3 years ago). Please 
open a new issue and provide a minimal reproducer. Thanks!

--
nosy: +berker.peksag

___
Python tracker 

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

[issue27399] ChainMap.keys() is broken

[R. David Murray]

Changes by R. David Murray :


--
nosy: +rhettinger

___
Python tracker 

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

[issue27364] Deprecate invalid unicode escape sequences

[R. David Murray]

R. David Murray added the comment:

Yes, this change is likely to break a lot of code, so an extended deprecation 
period (certainly longer than 3.7, which Guido has already mandated) is the 
minimum).  Guido hasn't agreed to making it an error yet, as far as I can see ;)

--

___
Python tracker 

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

[issue27397] email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen"

[R. David Murray]

R. David Murray added the comment:

This appears to be a bug in b64decode.  It should not be raising that error if 
validate=False, as it is in the code being executed during the test case.  It's 
not that b64decode is ignoring the validate argument; the error appears to be 
data-dependent.  I don't have time to investigate this further at the moment, 
perhaps someone else can pick it up.

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

[issue17408] second python execution fails when embedding

[Denny Weinberg]

Denny Weinberg added the comment:

Can we please reopen this issue?

--

___
Python tracker 

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

[issue27364] Deprecate invalid unicode escape sequences

[STINNER Victor]

STINNER Victor added the comment:

@ebarry: To move faster, you should also worker with linters (pylint, 
pychecker, pyflakes, pycodestyle, flake8, ...) to log a warning to help 
projects to be prepared this change. linters are used on Python 2-only 
projects, so it will help them to be prepared to the final Python 3. which 
will raise an exception.

--

___
Python tracker 

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

[issue27364] Deprecate invalid unicode escape sequences

[Emanuel Barry]

Emanuel Barry added the comment:

I think ultimately a SyntaxError should be fine. I don't know *when* it becomes 
appropriate to change a warning into an error; I was thinking 3.7 but, as 
Serhiy said, there's no rush. I think waiting five release cycles is overkill 
though, that means the error won't be until 8 years from now (assuming release 
cycle periods don't change)! I think at most 3.8 should be fine for making this 
a full-on syntax error.

--

___
Python tracker 

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

[issue27399] ChainMap.keys() is broken

[Zahari Dim]

Changes by Zahari Dim :


--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more

[Xiang Zhang]

Changes by Xiang Zhang :


Removed file: http://bugs.python.org/file43564/64bit_support_for_zlib_v8.patch

___
Python tracker 

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

[issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more

[Xiang Zhang]

Changes by Xiang Zhang :


Added file: http://bugs.python.org/file43565/64bit_support_for_zlib_v8.patch

___
Python tracker 

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

[issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more

[Xiang Zhang]

Xiang Zhang added the comment:

Make v8 patch consistent with the latest changeset.

--
Added file: http://bugs.python.org/file43564/64bit_support_for_zlib_v8.patch

___
Python tracker 

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

[issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more

[Xiang Zhang]

Changes by Xiang Zhang :


Removed file: http://bugs.python.org/file43563/64bit_support_for_zlib_v8.patch

___
Python tracker 

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

[issue27399] ChainMap.keys() is broken

[Zahari Dim]

New submission from Zahari Dim:

When trying to see if the keys() of a collections.ChainMap object are empty, it 
tries to compute the hash of the dicts that compose the ChainMap, giving rise 
to an error:

In [1]: from collections import ChainMap

In [2]: m = ChainMap([{'a':1}, {'b':2}])

In [3]: bool(m.keys())
---
TypeError Traceback (most recent call last)
 in ()
> 1 bool(m.keys())

/home/zah/anaconda3/lib/python3.5/_collections_abc.py in __len__(self)
633 
634 def __len__(self):
--> 635 return len(self._mapping)
636 
637 def __repr__(self):

/home/zah/anaconda3/lib/python3.5/collections/__init__.py in __len__(self)
865 
866 def __len__(self):
--> 867 return len(set().union(*self.maps)) # reuses stored hash 
values if possible
868 
869 def __iter__(self):

TypeError: unhashable type: 'dict'

Also, I can't ask if 'a' is in keys:

In [6]: m.keys()
Out[6]: KeysView(ChainMap([{'a': 1}, {'b': 2}]))
In [9]: ks = m.keys()
In [17]: 'a' in ks
Out[17]: False

--
components: Library (Lib)
messages: 269370
nosy: Zahari.Dim
priority: normal
severity: normal
status: open
title: ChainMap.keys() is broken
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

[issue27350] Compact and ordered dict

[INADA Naoki]

INADA Naoki added the comment:

And Python benchmark result is here.
https://gist.github.com/methane/e7a2ae389ca13905508905f5fa4ad46c

pickup
---

### call_method_slots ###
Min: 0.282221 -> 0.266215: 1.06x faster
Avg: 0.282379 -> 0.266448: 1.06x faster
Significant (t=780.35)
Stddev: 0.00015 -> 0.00032: 2.0993x larger

### call_method_unknown ###
Min: 0.280347 -> 0.273366: 1.03x faster
Avg: 0.280579 -> 0.273538: 1.03x faster
Significant (t=800.73)
Stddev: 0.00011 -> 0.00011: 1.0061x smaller

### call_simple ###
Min: 0.202884 -> 0.208746: 1.03x slower
Avg: 0.203037 -> 0.208866: 1.03x slower
Significant (t=-642.05)
Stddev: 0.00013 -> 0.9: 1.3236x smaller

### chameleon_v2 ###
Min: 3.715995 -> 3.819750: 1.03x slower
Avg: 3.738736 -> 3.851562: 1.03x slower
Significant (t=-62.21)
Stddev: 0.00851 -> 0.01602: 1.8817x larger

### chaos ###
Min: 0.195156 -> 0.203020: 1.04x slower
Avg: 0.195803 -> 0.203704: 1.04x slower
Significant (t=-179.73)
Stddev: 0.00026 -> 0.00035: 1.3371x larger

### django_v3 ###
Min: 0.369087 -> 0.386535: 1.05x slower
Avg: 0.370569 -> 0.388277: 1.05x slower
Significant (t=-184.30)
Stddev: 0.00064 -> 0.00072: 1.1206x larger

### formatted_logging ###   

   [97/1823]
Min: 0.226584 -> 0.233564: 1.03x slower
Avg: 0.229062 -> 0.235876: 1.03x slower
Significant (t=-35.32)
Stddev: 0.00133 -> 0.00140: 1.0505x larger

### normal_startup ###
Min: 0.277946 -> 0.269843: 1.03x faster
Avg: 0.279173 -> 0.271878: 1.03x faster
Significant (t=17.65)
Stddev: 0.00175 -> 0.00374: 2.1348x larger

### raytrace ###
Min: 0.961784 -> 0.991375: 1.03x slower
Avg: 0.963318 -> 0.994727: 1.03x slower
Significant (t=-159.11)
Stddev: 0.00073 -> 0.00183: 2.5204x larger

### regex_compile ###
Min: 0.256675 -> 0.267169: 1.04x slower
Avg: 0.257559 -> 0.268213: 1.04x slower
Significant (t=-136.14)
Stddev: 0.00050 -> 0.00060: 1.1996x larger

### richards ###
Min: 0.129063 -> 0.134478: 1.04x slower
Avg: 0.130158 -> 0.135382: 1.04x slower
Significant (t=-18.28)
Stddev: 0.00284 -> 0.00036: 7.8299x smaller

### startup_nosite ###
Min: 0.165788 -> 0.159139: 1.04x faster
Avg: 0.166089 -> 0.159848: 1.04x faster
Significant (t=219.05)
Stddev: 0.00021 -> 0.00035: 1.6594x larger

--

___
Python tracker 

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

[issue27364] Deprecate invalid unicode escape sequences

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

DeprecationWarning is used when we want to remove a feature. It becomes an 
error in the future. FutureWarning is used when we want change the meaning of a 
feature instead of removing it. For example re.split(':*', 'a:bc') emits a 
FutureWarning and returns ['a', 'bc'] because there is a plan to make it 
returning ['', 'a', 'b', 'c', ''].

I think "a silent warning" means that it should emit a DeprecationWarning or a 
PendingDeprecationWarning. Since there is no haste, we should use 2-releases 
deprecation period. After this a deprecation can be changed to a SynataxWarning 
in 3.8 and to a UnicodeDecodeError (for strings) and a ValueError (for bytes) 
in 4.0. The latter are converted to SyntaxError by parser. At the end we should 
get the same behavior as for truncated \x and \u escapes.

>>> '\u'
  File "", line 1
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in 
position 0-1: truncated \u escape
>>> b'\x'
  File "", line 1
SyntaxError: (value error) invalid \x escape at position 0

Maybe change a parser to convert warnings to a SyntaxWarning?

--

___
Python tracker 

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

[issue27350] Compact and ordered dict

[INADA Naoki]

INADA Naoki added the comment:

Last patch I've posted implements "strict ordering rule" on key sharing dict.

* Insertion order should be strictly equal to order in shared key.
  If insertion position is not equal to ma_used, convert it to combined
  form.

* Deleting from split table is prohibited.  Convert the table to combined form. 
 (to keep ma_used == next insertion position rule).


I ran sphinx-build on this patch and master branch.
("intern" in the result is incomplete implementation of my new idea.
 Please ignore it in this issue.)

https://gist.github.com/methane/df89221222cc2474af1fe61a960e100d

Summary
-
Speed:  No regression from master branch.
Memory usage:  Reduced from 172452k to 160876k

--

___
Python tracker 

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

[issue27393] Command to activate venv in Windows has wrong path

[Berker Peksag]

Berker Peksag added the comment:

Thanks, Eryk. By the way, there is no need to change the state of 'resolution' 
and 'stage' fields.

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

[issue27393] Command to activate venv in Windows has wrong path

[Roundup Robot]

Roundup Robot added the comment:

New changeset b82149953a8c by Berker Peksag in branch '3.5':
Issue #27393: Fix escaping of C:\ too
https://hg.python.org/cpython/rev/b82149953a8c

New changeset e1a0582896d6 by Berker Peksag in branch 'default':
Issue #27393: Merge from 3.5
https://hg.python.org/cpython/rev/e1a0582896d6

--

___
Python tracker 

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

[issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more

[Xiang Zhang]

Changes by Xiang Zhang :


Removed file: http://bugs.python.org/file43561/64bit_support_for_zlib_v8.patch

___
Python tracker 

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

[issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more

[Xiang Zhang]

Changes by Xiang Zhang :


Added file: http://bugs.python.org/file43563/64bit_support_for_zlib_v8.patch

___
Python tracker 

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

[issue27398] configure warning for Python 3.5.2 during compilation

[Martin Panter]

Martin Panter added the comment:

FWIW adding a blank fourth argument in configure.ac silences this warning (and 
speeds up the configure run by 7%, or 4 s). But I don’t want to become an 
Autoconf nerd and I don’t know if this change could have negative consequences 
on other platforms (e.g. perhaps AC_INCLUDES_DEFAULT matters?).

Practically, I think you can ignore the warning. The include file is needed to 
use a new getrandom() syscall on Linux (see Issue 26839), but Python should 
fall back to older code if it cannot use getrandom().

--
keywords: +patch
nosy: +martin.panter
Added file: http://bugs.python.org/file43562/no-preproc-test.patch

___
Python tracker 

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

[issue27130] zlib: OverflowError while trying to compress 2^32 bytes or more

[Xiang Zhang]

Xiang Zhang added the comment:

This is the v8 patch. It does two things:

[1] Apply Martin's comment about decompressobj.decompress so when user passes 
in PY_SSIZE_T_MAX and there is enough memory, no error will be raised.

[2] Now decompressobj.flush can still work even if 
decompressobj.unconsumed_tail is larger than 4GiB. This needs two changes. 
First is we don't always use Z_FINISH. Second is we need to change 
save_unconsumed_input to support 64bit. Before we didn't realize this. 
Corresponding tests are added.

--
Added file: http://bugs.python.org/file43561/64bit_support_for_zlib_v8.patch

___
Python tracker 

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

[issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN

[STINNER Victor]

STINNER Victor added the comment:

Attached interrupt_main.patch fixes for _thread.interrupt_main(): raise an 
exception if the SIGINT signal is ignored (SIG_IGN) or not handled by Python 
(SIG_DFL).

My patch updates the documentation and addds unit tests.

issue23395.2.patch looks wrong: it's not the right place to handle the error.

--
Added file: http://bugs.python.org/file43560/interrupt_main.patch

___
Python tracker 

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

[issue27393] Command to activate venv in Windows has wrong path

[Eryk Sun]

Eryk Sun added the comment:

You missed "C:\\>".

--
nosy: +eryksun
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

___
Python tracker 

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

[issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET)

[Xavier de Gaye]

Xavier de Gaye added the comment:

Regeneration of the platdir files needs to be aware of the value of sysroot 
[1]. For example on Android cross-builds, sysroot must be set to the path of 
the headers and libraries for the targeted Android API level corresponding to a 
version of the Android libc and a version of Android. So, automatically 
regenerating those files in this case requires to look into the CC, CFLAGS and 
CPPFLAGS environment variables for sysroot. OTOH RTLD_* constants are exposed 
in the posix module (issue 13226) and the platdir files usefulness is limited 
now.

Cross building from one linux architecture to another is possible with gnu make 
VPATH support by building outside the source tree. Android is also a linux 
architecture and building outside the source tree makes sense, not only to work 
around the problem described in the second item of msg241143, but also to build 
for different Android API levels and identify the results of those builds.

It is not clear that the changes made in this issue fixes correctly issue 
22724, see msg269359.

I think the scope of this isssue should be restricted to multiarch build 
systems, i.e. when gcc has been configured with '--enable-multiarch' [2].

[1] Options for Directory Search: 
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
[2] Installing GCC: Configuration: https://gcc.gnu.org/install/configure.html

--

___
Python tracker 

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

[issue22724] byte-compile fails for cross-builds

[Xavier de Gaye]

Xavier de Gaye added the comment:

The byte-compiling for cross-builds fails because PYTHON_FOR_BUILD defined in 
configure, sets PYTHONPATH with the directory of the newly built extension 
modules shared libraries and because PYTHON_FOR_BUILD is used to run 
compileall.py in the Makefile. PYTHON_FOR_BUILD, i.e. the native python running 
on the build system, attempts to load the newly compiled libraries for the 
foreign host system and fails.

The problem is more difficult to reproduce after changeset 11c4f3f936e7 in 
issue 22980 since the shared libraries names include now a PLATFORM_TRIPLET 
that prevents the wrong library to be loaded in most cases. On Android 
cross-builds, it should be possible to reproduce the failure when the build 
system and the host system have the same PLATFORM_TRIPLET. In all cases, the 
interpreter used to run compileall.py imports the wrong _sysconfigdata module.

To fix this problem, this patch adds the -E option to PYTHON_FOR_BUILD when 
running compileall in the Makefile and 'cross_compiling' is set. The patch does 
not fix the fact that, when 'cross_compiling' is not set, PYTHONPATH is set to 
'$(DESTDIR)$(LIBDEST)' in the Makefile at the beginning of the statement that 
runs compileall.py while PYTHON_FOR_BUILD is set to './$(BUILDPYTHON) -E', 
something is obviously wrong here. So the patch would be simpler if '-E' was 
used in both cases, but I don't know what would be lost by removing this 
setting of PYTHONPATH at the beginning of those compileall statements, IOW what 
was their initial purpose.

--
keywords: +patch
nosy: +xdegaye
stage:  -> patch review
versions:  -Python 3.3, Python 3.4
Added file: http://bugs.python.org/file43559/python_for_build_flag.patch

___
Python tracker 

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

[issue27364] Deprecate invalid unicode escape sequences

[STINNER Victor]

STINNER Victor added the comment:

Guido: "I am okay with making it a silent warning."

The current patch raises a DeprecationWarning which is silent by default, but 
seen using python3 -Wd. What is the "long term" plan: always raise an 
*exception* in Python 3.7? Which exception?

Another option is to always emit a SyntaxWarning, but don't raise an exception 
in long term. It is possible to get an exception using python3 -Werror.

There is also FutureWarning: "Base class for warnings about constructs that 
will change semantically in the future" or RuntimeWarning "Base class for 
warnings about dubious runtime behavior".

--

___
Python tracker 

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

[issue27350] Compact and ordered dict

[INADA Naoki]

Changes by INADA Naoki :


Added file: http://bugs.python.org/file43558/compact-dict.patch

___
Python tracker 

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

[issue27398] configure warning for Python 3.5.2 during compilation

[David]

David added the comment:

Forgot to mention - this is for Debian 4. A really old legacy system we're 
running, but where we like to use new versions of Python.

--

___
Python tracker 

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

[issue27398] configure warning for Python 3.5.2 during compilation

[David]

New submission from David:

Hi there.

3.5.1 final didn't have this problem, 3.5.2 final does have this problem.

I'm compiling Python 3.5.2 under Debian, and get this warning during the 
./configure step:

---
configure: WARNING: linux/random.h: present but cannot be compiled
configure: WARNING: linux/random.h: check for missing prerequisite headers?
configure: WARNING: linux/random.h: see the Autoconf documentation
configure: WARNING: linux/random.h: section "Present But Cannot Be Compiled"
configure: WARNING: linux/random.h: proceeding with the compiler's result
configure: WARNING: ## -- ##
configure: WARNING: ## Report this to http://bugs.python.org/ ##
configure: WARNING: ## -- ##
---

Please check this?

--
components: Build
messages: 269356
nosy: wizzardx
priority: normal
severity: normal
status: open
title: configure warning for Python 3.5.2 during compilation
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

[issue27393] Command to activate venv in Windows has wrong path

[Berker Peksag]

Berker Peksag added the comment:

Thanks! 3.3 and 3.4 docs are not maintained anymore.

--
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: enhancement -> behavior
versions:  -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

[issue27393] Command to activate venv in Windows has wrong path

[Roundup Robot]

Roundup Robot added the comment:

New changeset fd1236294b88 by Berker Peksag in branch '3.5':
Issue #27393: Fix escaping of venv activate commands on Windows
https://hg.python.org/cpython/rev/fd1236294b88

New changeset cf560010e6f8 by Berker Peksag in branch 'default':
Issue #27393: Merge from 3.5
https://hg.python.org/cpython/rev/cf560010e6f8

--
nosy: +python-dev

___
Python tracker 

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

[issue19536] MatchObject should offer __getitem__()

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the detailed report! Issue 24454 is actually a duplicate of this but 
it has a patch and the idea was discussed by several core developers there. I'm 
going to close this one.

--
nosy: +berker.peksag
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Improve the usability of the match object named group API

___
Python tracker 

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