[issue35306] OSError [WinError 123] when testing if pathlib.Path('*') (asterisks) exists

[jimbo1qaz_ via Gmail]

New submission from jimbo1qaz_ via Gmail :

I'm writing a program taking paths from user input through CLI.

`path` is a pathlib.Path().

Since Windows doesn't expand asterisks, I check if the path doesn't exist. If 
so I expand using Path().glob(path).

Unfortunately on Windows, if `path` (type: Path) contains asterisks, checking 
`path.exists()` or `path.is_dir()` raises WinError 123.

Python 3.7.0 (default, Jun 28 2018, 08:04:48) [MSC v.1912 64 bit (AMD64)] :: 
Anaconda, Inc. on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from pathlib import Path
>>> Path('*').exists()
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Users\jimbo1qaz\Miniconda3\envs\python37\lib\pathlib.py", line 1318, 
in exists
self.stat()
  File "C:\Users\jimbo1qaz\Miniconda3\envs\python37\lib\pathlib.py", line 1140, 
in stat
return self._accessor.stat(self)
OSError: [WinError 123] The filename, directory name, or volume label syntax is 
incorrect: '*'
>>> Path('*').is_dir()
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Users\jimbo1qaz\Miniconda3\envs\python37\lib\pathlib.py", line 1330, 
in is_dir
return S_ISDIR(self.stat().st_mode)
  File "C:\Users\jimbo1qaz\Miniconda3\envs\python37\lib\pathlib.py", line 1140, 
in stat
return self._accessor.stat(self)
OSError: [WinError 123] The filename, directory name, or volume label syntax is 
incorrect: '*'

I also reproduced on Miniconda 3.6.6, 3.7.0, and official Python 3.7.1.

According to https://bugs.python.org/issue29827 , os.path.exists() (not 
Path.exists() ) returns False on any OSError.

-

On Linux, checking paths with null bytes (a less common occurrence) raises a 
different error:

>>> import pathlib
>>> pathlib.Path("\x00").exists()
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.6/pathlib.py", line 1336, in exists
self.stat()
  File "/usr/lib/python3.6/pathlib.py", line 1158, in stat
return self._accessor.stat(self)
  File "/usr/lib/python3.6/pathlib.py", line 387, in wrapped
return strfunc(str(pathobj), *args)
ValueError: embedded null byte

--
components: Library (Lib)
messages: 330371
nosy: jimbo1qaz_
priority: normal
severity: normal
status: open
title: OSError [WinError 123] when testing if pathlib.Path('*') (asterisks) 
exists
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue35305] subprocess.Popen(['/sbin/ldconfig', '-p'], stdin=PIPE) itself hangs/deadlocks (Linux)

[Henrik Bengtsson]

New submission from Henrik Bengtsson :

(originally posted to 
https://mail.python.org/pipermail/python-list/2018-November/738209.html)

I ran into an interesting problem where calling 
'subprocess.Popen(['/sbin/ldconfig', '-p'], stdin=PIPE)' hangs and
never returns.

$ python
Python 2.7.9 (default, Apr 23 2015, 22:07:47)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-11)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> import subprocess
>>> p = subprocess.Popen(['/sbin/ldconfig', '-p'], stdout=subprocess.PIPE)
^CTraceback (most recent call last):
  File "", line 1, in 
  File "/opt/Python/Python-2.7.9/lib/python2.7/subprocess.py", line 710, in 
__init__
errread, errwrite)
  File "/opt/Python/Python-2.7.9/lib/python2.7/subprocess.py", line 1316, in 
_execute_child
data = _eintr_retry_call(os.read, errpipe_read, 1048576)
  File "/opt/Python/Python-2.7.9/lib/python2.7/subprocess.py", line 476, in 
_eintr_retry_call
return func(*args)
KeyboardInterrupt
>>>

Note how I have to send a user interrupt to break out of 'subprocess.Popen()'.


TROUBLESHOOTING:

First, it's interesting to note that the following works:

>>> import subprocess
>>> p = subprocess.Popen(['/sbin/ldconfig -p'], stdout=subprocess.PIPE, 
>>> shell=True)
>>> out,err = p.communicate()
>>> len(out)
102460
>>>

which I believe is the same as:

>>> import subprocess
>>> p = subprocess.Popen(['sh', '-c', '/sbin/ldconfig -p'], 
>>> stdout=subprocess.PIPE)
>>> out,err = p.communicate()
>>> len(out)
102460
>>>

which also works.



Second, calling:

>>> import subprocess
>>> p = subprocess.Popen(['/sbin/ldconfig', '-p'])
1562 libs found in cache `/etc/ld.so.cache'
libzmq.so.1 (libc6,x86-64) => /usr/lib64/libzmq.so.1
libz.so.1 (libc6,x86-64) => /lib64/libz.so.1
[ ... all 102,460 bytes of ldconfig -p output ...]
ld-linux-x86-64.so.2 (libc6,x86-64) => /lib64/ld-linux-x86-64.so.2
>>>

also works, so the PIPE is my main suspect.


Finally, if I do:

>>> import subprocess
>>> p = subprocess.Popen(['/sbin/ldconfig', '-p'], stdout=subprocess.PIPE)

   [ manually pkill -INT ldconfig' ]

>>> out,err = p.communicate()
>>> len(out)
65536
>>>

then I notice that it reads exactly 65,536=2^16 bytes (out of 102,460 bytes).  
I suspect this is related to the default buffer-size limit of pipes set by the 
Linux kernel.  Using `strace` on the latter Python process, reveals:

[...]
open("/opt/Python/Python-2.7.9/lib/python2.7/lib-dynload/cStringIO.so", 
O_RDONLY) = 6
read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\32\0\0\0\0\0\0"..., 
832) = 832
fstat(6, {st_mode=S_IFREG|0755, st_size=49556, ...}) = 0
mmap(NULL, 2115000, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 
0x2ad3ca6e7000
mprotect(0x2ad3ca6eb000, 2093056, PROT_NONE) = 0
mmap(0x2ad3ca8ea000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x3000) = 0x2ad3ca8ea000
close(6)= 0
close(5)= 0
close(4)= 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=64*1024, rlim_max=64*1024}) = 0
close(3)= 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2ad3ca8ec000
write(1, "1\n", 21)  = 2
pipe([3, 4])= 0
fcntl(3, F_GETFD)   = 0
fcntl(3, F_SETFD, FD_CLOEXEC)   = 0
fcntl(4, F_GETFD)   = 0
fcntl(4, F_SETFD, FD_CLOEXEC)   = 0
pipe([5, 6])= 0
fcntl(5, F_GETFD)   = 0
fcntl(5, F_SETFD, FD_CLOEXEC)   = 0
fcntl(6, F_GETFD)   = 0
fcntl(6, F_SETFD, FD_CLOEXEC)   = 0
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x2ad3c972adf0) = 239074
close(6)= 0
mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2ad3ca8ed000
read(5,

and 'strace' on the stalled 'ldconfig' process reveals:

  $ strace -p $(pgrep ldconfig)
Process 239074 attached - interrupt to quit
write(1, "ibgconfmm-2.6.so.1 (libc6,x86-64"..., 4096
 RH  6.6 0:-  1:-* 2:--

That latter 'write()' contains the bytes after position 65,536, i.e. bytes 
65,537 and beyond (not shown, but verified after careful inspection).


MY CONCLUSION:

To me, this looks like a deadlock in Popen() itself - is that correct?


SESSION INFORMATION:

All of the above is with Python 2.7.9 (installed from EPEL), but I can also 
reproduce it with Python 2.7.15 installed from source.

What is also useful to know, is that I'm observing this on a legacy RHEL 6 
system *with a customized kernel* part of the Scyld ClusterWare 
(https://www.penguincomputing.com/products/software/scyld-clusterware/) that 
*cannot* be updated:

$ uname -a
Linux n6 2.6.32-504.12.2.el6.664g.x86_64 #1 SMP Wed Mar 11
14:20:51 EDT 

[issue29877] compileall hangs when accessing urandom even if number of workers is 1

[INADA Naoki]

Change by INADA Naoki :


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

___
Python tracker 

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

[issue35295] Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred

[INADA Naoki]

Change by INADA Naoki :


--
nosy: +inada.naoki

___
Python tracker 

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

[issue35300] Document what functions are suitable for use with the lru_cache

[Raymond Hettinger]

Change by Raymond Hettinger :


--
title: Bug with memoization and mutable objects -> Document what functions are 
suitable for use with the lru_cache

___
Python tracker 

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

[issue35300] Bug with memoization and mutable objects

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I concur with Victor.  The proposed API change defeats the purpose of the 
cache.  By design, the intent of the cache is to reuse the previously computed 
value.

I can add something like this to the docs: """In general, the LRU cache should 
only be used when you want to reuse previously computed values.  Accordingly, 
it doesn't make sense to cache functions with side-effects, functions that need 
to create distinct mutable objects on each call, or impure functions such as 
time() or random()."""

--
assignee:  -> rhettinger
components: +Documentation -Library (Lib)
type: behavior -> 
versions:  -Python 3.4, Python 3.5

___
Python tracker 

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

[issue35304] The return of truncate(size=None) (file io) is unexpected

[Martin Panter]

Martin Panter  added the comment:

This is the same as Issue 26158. Truncating text files is not clearly 
documented for a start, and truncating after reading doesn’t seem to be 
considered much in the implementations.

Your question is answered at . 
Your code calls the C implementation of “io.TextIOWrapper.truncate”. This 
implementation does not consider that there are 8 unread bytes in a buffer, so 
it truncates the file at the end of the buffer (5 read + 8 unread = 13 bytes).

--
nosy: +martin.panter
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> File truncate() not defaulting to current position as documented

___
Python tracker 

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

[issue12215] TextIOWrapper: issues with interlaced read-write

[Martin Panter]

Martin Panter  added the comment:

For the record, the more recent bug I mentioned was a complaint from 2015 (one 
and a half years before Victor’s comment). Even if it is not worth supporting 
writing after reading, the problem could be documented.

--
resolution: out of date -> wont fix

___
Python tracker 

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

[issue28247] Add an option to zipapp to produce a Windows executable

[Ismail Donmez]

Ismail Donmez  added the comment:

The documentation helped a lot, so thanks for that! But it misses the final 
crucial step:

copy /b zastub.exe+app.pyz app.exe

The documentation talks about prepending the zastub.exe to the zip file but 
never mentions how, which is very confusing.

--
nosy: +donmez

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[Steve Dower]

Steve Dower  added the comment:

Ah, you're right, it's only C++. My bad.

--

___
Python tracker 

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

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

[Michael Saah]

Michael Saah  added the comment:

Summary to accompany my patch:

Modules/_datetimemodule.c and Lib/datetime.py do not behave identically.
Specifically, the strftime functions do not match when passed a format
string
terminated with a '%'. The C function performs an explicit check for this
condition, and raises a ValueError on it. The Py version does not perform
this check. Both pass the
format string (after doing substitutions for %z, %Z, and %f tags) to the
system strftime or wcfstime, depending on platform. These live within the
python time module. The
time module wrapper function does not perform this check.

This situation leads to a scenario in which, for example, "%D %" passed to
datetime.strftime (with the C extension included) raises a value error. The
same string passed to
time.strftime returns "mm/dd/yy %", at least on OSX. Furthermore, if Python
is built without the C module, "mm/dd/yy %" is returned when
datetime.strftime is called.

To summarise, there are two problems: (1) datetime does not comply with
PEP-399, and (2) a higher-order module raises an exception on a case that
the (exposed) lower-order
module has no problem with, causing a mismatch in behavior between
datetime.strftime and time.strftime.

This PR attempts to fix this problem by removing the case check from the
datetime C module. This solves both (1) and (2).

There was much talk on the issue thread about there existing a test case
for time.strftime that documented a platform-dependent failure on a
dangling '%'. I wish to note
that my patch does not touch the time module at all, it only removes a
seemingly unnecessary check in the datetime C module.

--

___
Python tracker 

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

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +9944
stage:  -> patch review

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

STINNER Victor  added the comment:

> Could we have used function overloading to handle the different types?
Rather than reintroducing the macro for the sake of the cast?

Sorry, I don't know what is function overloading. Is it a C++ thing?
Py_INCREF() must accept any type based on PyObject.

At least, this issue shouldn't make the situation worse :-)

Please open a new issue if you have a solution for this problem. I am now
curious since I tried many things and I failed to find anything working for
all cases.

--

___
Python tracker 

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

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

[Роман Донченко]

Change by Роман Донченко :


--
nosy: +SpecLad

___
Python tracker 

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

[issue35281] Allow access to unittest.TestSuite tests

[Lihu]

Lihu  added the comment:

Sorry, I guess some context might be helpful. I'm writing a program that links 
unittest-based tests with a third-party test tracking/reporting system. Said 
third-party software has a concept of test suites/cases that doesn't align 1:1 
with unittest, so I need to manipulate the unittest objects a bit to get them 
to connect smoothly.

`list(test_suite)` is a bit clunky for me, since I'm already copying said list 
in order to do my manipulation. So I end up with expressions like:

```
my_cases = list(my_custom_generator(list(test_suite)))
```

Certainly not the end of the world, and it works just fine, but it's redundant 
and I need to do it a lot. I realize that `list(iterator)` is an increasingly 
common idiom in python 3, but I thought I'd throw this usecase out there for 
your consideration.

--

___
Python tracker 

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

[issue35303] A reference leak in _operator.c's methodcaller_repr()

[miss-islington]

miss-islington  added the comment:


New changeset bc665b42ba3a372bc60451583bfaff41d8e1993d by Miss Islington (bot) 
in branch '3.7':
bpo-35303: Fix a reference leak in _operator.c's methodcaller_repr(). (GH-10689)
https://github.com/python/cpython/commit/bc665b42ba3a372bc60451583bfaff41d8e1993d


--
nosy: +miss-islington

___
Python tracker 

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

[issue35303] A reference leak in _operator.c's methodcaller_repr()

[miss-islington]

miss-islington  added the comment:


New changeset 8c70c08f0fb5795904442e95a2987ea18aed2899 by Miss Islington (bot) 
in branch '3.6':
bpo-35303: Fix a reference leak in _operator.c's methodcaller_repr(). (GH-10689)
https://github.com/python/cpython/commit/8c70c08f0fb5795904442e95a2987ea18aed2899


--

___
Python tracker 

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

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Steve Dower  added the comment:

If anyone would like to try this out early, here's some instructions for a 
build I just made.

Enable sideloading apps on your machine (see 
https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development
 - may already be done, sideload or developer mode should do)

In a regular (non-admin) PowerShell prompt in a temporary directory, run these 
commands:

iwr 
"https://dev.azure.com/Python/8e426817-76c0-4b99-ba9e-a48a1e4bd5db/_apis/build/builds/34540/artifacts?artifactName=appx=5.0-preview.5&%24format=zip;
 -outfile python37.zip
Expand-Archive .\python37.zip .
Add-AppxPackage appx\python.msix

(The first may take a while as it downloads approx. 80MB. I'm intending to 
leave the test suite out of the final package, which should bring it down 
closer to 40MB.)

Now play with it:
$> python.exe
$> python3.exe
$> python3.7.exe
$> pip.exe
$> pip3.exe
$> pip3.7.exe
$> idle.exe
$> idle3.exe
$> idle3.7.exe
(Or press Win+S and search for new entries)

To remove it:

Remove-AppxPackage (Get-AppxPackage *Python.3.7)
(delete the downloaded files)

Right now, the py.exe launcher can't find it, nor can any tools that rely on 
enumerating the registry - directly requesting the reg keys will return the 
right values though. VS Code seems to pick it up just fine though, I guess 
because it's on PATH.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue35304] The return of truncate(size=None) (file io) is unexpected

[liugang]

liugang  added the comment:

# Run in Windows 10

# Code snippet 1
f = open('test', "w+")
f.write('xxx\nyyy\nzzz')

f.seek(0)

f.readline()
print(f.tell())  # 5

x = f.truncate()
print(x)  # 13 - why it is 13, not 5?


# Code snippet 2
f = open('test', "w+")
f.write('xxx\nyyy\nzzz')

f.seek(0)

f.readline()
print(f.tell())  # 5

f.seek(f.tell())

x = f.truncate()
print(x)  # 5

--

___
Python tracker 

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

[issue35304] The return of truncate(size=None) (file io) is unexpected

[liugang]

New submission from liugang :

-- run in Windows 10

1 - 
f = open('test', "w+")
f.write('xxx\nyyy\nzzz')

f.seek(0)

f.readline()
print(f.tell())  # output 5 (xxx\r\n)

x = f.truncate()
print(x)  # output 13 (xxx\r\nyyy\r\nzzz), why it is 13, not 5?

2 - 
f = open('test', "w+")
f.write('xxx\nyyy\nzzz')

f.seek(0)

f.readline()
print(f.tell())  # output 5 (xxx\r\n)

f.seek(f.tell())

x = f.truncate()
print(x)  # output 5

--
components: IO
messages: 330357
nosy: liugang93
priority: normal
severity: normal
status: open
title: The return of truncate(size=None) (file io) is unexpected
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

[issue35303] A reference leak in _operator.c's methodcaller_repr()

[miss-islington]

Change by miss-islington :


--
pull_requests: +9943

___
Python tracker 

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

[issue35303] A reference leak in _operator.c's methodcaller_repr()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 5b83ef71d3060e1651d3680e805f13a1049c7d6d by Serhiy Storchaka 
(Zackery Spytz) in branch 'master':
bpo-35303: Fix a reference leak in _operator.c's methodcaller_repr(). (GH-10689)
https://github.com/python/cpython/commit/5b83ef71d3060e1651d3680e805f13a1049c7d6d


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue35303] A reference leak in _operator.c's methodcaller_repr()

[miss-islington]

Change by miss-islington :


--
pull_requests: +9942

___
Python tracker 

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

[issue35303] A reference leak in _operator.c's methodcaller_repr()

[Zackery Spytz]

New submission from Zackery Spytz :

The attached PR fixes a reference leak in _operator.c's methodcaller_repr().

--

___
Python tracker 

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

[issue35303] A reference leak in _operator.c's methodcaller_repr()

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +9941
stage:  -> patch review

___
Python tracker 

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

[issue35303] A reference leak in _operator.c's methodcaller_repr()

[Zackery Spytz]

Change by Zackery Spytz :


--
components: Extension Modules
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: A reference leak in _operator.c's methodcaller_repr()
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue35302] create_connection with local_addr misses valid socket bindings

[Neil Booth]

New submission from Neil Booth :

I run a machine with IPv4 and IPv6 interfaces on MacOSX Mojave.

I try to loop.create_connection() to a remote machine whose domain resolves to 
an IPv6 address only, with a local_addr domain name argument that resolves to 
two local addresses: an IPv4 one first and an IPv6 one second.

The loop 
https://github.com/python/cpython/blob/master/Lib/asyncio/base_events.py#L927-L943
 that loops through the local addresses, IPv4 then IPv6, successfully binds the 
IPv4 laddr_info to the IPv6 socket successfully (something I find surprising) 
and then the connection attempt fails with OSError(65, 'No route to host'), at 
which point the sockets is closed and the IPv6 laddr_info is never tried and 
the connection attempt fails.

If I reverse the order of the loop so that the IPv6 laddr_info is tried first 
then the connection succeeds.

I suggest either all laddr_info bindings should be tried for each outer loop of 
infos, rather than just 1, or that those of a different socket "type" (IPv4 vs 
IPv6) should be skipped in the inner loop before attempting a binding.

--
components: asyncio
messages: 330354
nosy: asvetlov, kyuupichan, yselivanov
priority: normal
severity: normal
status: open
title: create_connection with local_addr misses valid socket bindings
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[Steve Dower]

Steve Dower  added the comment:

Could we have used function overloading to handle the different types? Rather 
than reintroducing the macro for the sake of the cast?

--
nosy: +steve.dower

___
Python tracker 

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

[issue34812] [Security] support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag

[STINNER Victor]

STINNER Victor  added the comment:

Ok, the bug is now fixed in Python 3.6, 3.7 and master branches ;-)

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

___
Python tracker 

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

[issue34812] [Security] support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag

[STINNER Victor]

STINNER Victor  added the comment:


New changeset cc0e0a2214d6515cf6ba4c7b164902a87e321b45 by Victor Stinner in 
branch '3.6':
bpo-34812: subprocess._args_from_interpreter_flags(): add isolated (GH-10675) 
(GH-10688)
https://github.com/python/cpython/commit/cc0e0a2214d6515cf6ba4c7b164902a87e321b45


--

___
Python tracker 

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

[issue35189] PEP 475: fnctl functions are not retried if interrupted by a signal (EINTR)

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Aapo Samuli Keskimolo for the bug report and thanks Nierob for the fix!

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

___
Python tracker 

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

[issue31512] Add non-elevated symlink support for dev mode Windows 10

[Steve Dower]

Steve Dower  added the comment:

Thanks for the ping (I don't see GitHub notifications - I get 1000s per day and 
it's not feasible to read them).

I left one more comment on the PR, but then it's good to go!

--

___
Python tracker 

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

[issue35189] PEP 475: fnctl functions are not retried if interrupted by a signal (EINTR)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset eef813b1091f4b7411aa58d2746a9761ee99 by Victor Stinner in 
branch '3.6':
[3.7] bpo-35189: Retry fnctl calls on EINTR (GH-10413) (GH-10678) (GH-10685)
https://github.com/python/cpython/commit/eef813b1091f4b7411aa58d2746a9761ee99


--

___
Python tracker 

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

[issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h' found

[Steve Dower]

Steve Dower  added the comment:

I'm going to declare that this is a bug in distutils not correctly setting 
INCLUDE and LIB values when building in a source directory. When this is fixed, 
there will be no need to copy pyconfig.h anywhere, and the installer build will 
be fine.

(And it should be noted that we don't rely on 100% pass rate of the test suite 
when training for PGO - the point is to exercise as many code paths as 
possible. The test suite has shown to be as good as any other generic workload, 
and is easily available in our repo.)

--
components: +Distutils, Tests -Build
nosy: +dstufft, eric.araujo
versions: +Python 3.7, Python 3.8

___
Python tracker 

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

[issue29877] compileall hangs when accessing urandom even if number of workers is 1

[miss-islington]

miss-islington  added the comment:


New changeset 879f5f3d9c1f5b66e2a080c712e2323e9c03d558 by Miss Islington (bot) 
in branch '3.6':
bpo-29877: compileall: import ProcessPoolExecutor only when needed (GH-4856)
https://github.com/python/cpython/commit/879f5f3d9c1f5b66e2a080c712e2323e9c03d558


--

___
Python tracker 

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

[issue29877] compileall hangs when accessing urandom even if number of workers is 1

[miss-islington]

miss-islington  added the comment:


New changeset 903a3e8d67b61594c0fa17fb201769ca924b38f8 by Miss Islington (bot) 
in branch '3.7':
bpo-29877: compileall: import ProcessPoolExecutor only when needed (GH-4856)
https://github.com/python/cpython/commit/903a3e8d67b61594c0fa17fb201769ca924b38f8


--

___
Python tracker 

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

[issue34812] [Security] support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag

[miss-islington]

miss-islington  added the comment:


New changeset 01e579949ab546cd4cdd0d6d18e3ef41ce94f46e by Miss Islington (bot) 
in branch '3.7':
bpo-34812: subprocess._args_from_interpreter_flags(): add isolated (GH-10675)
https://github.com/python/cpython/commit/01e579949ab546cd4cdd0d6d18e3ef41ce94f46e


--
nosy: +miss-islington

___
Python tracker 

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

[issue34812] [Security] support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +9940

___
Python tracker 

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

[issue22496] urllib2 fails against IIS (urllib2 can't parse 401 reply www-authenticate headers)

[Mathieu Dupuy]

Mathieu Dupuy  added the comment:

A lot of time has passed and things have changed significantly. We now live in 
a mostly python3-world (which doesn't have the bug) and Python2 has less than 
two years before beeing put to sleep.

If nobody opposes, I offer to close this issue that I opened first.

--

___
Python tracker 

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

[issue29877] compileall hangs when accessing urandom even if number of workers is 1

[miss-islington]

Change by miss-islington :


--
pull_requests: +9939

___
Python tracker 

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

[issue29877] compileall hangs when accessing urandom even if number of workers is 1

[miss-islington]

Change by miss-islington :


--
pull_requests: +9938

___
Python tracker 

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

[issue29877] compileall hangs when accessing urandom even if number of workers is 1

[miss-islington]

miss-islington  added the comment:


New changeset 1d817e4c8259f49602eefe9729743f6d9d748e8d by Miss Islington (bot) 
(Dustin Spicuzza) in branch 'master':
bpo-29877: compileall: import ProcessPoolExecutor only when needed (GH-4856)
https://github.com/python/cpython/commit/1d817e4c8259f49602eefe9729743f6d9d748e8d


--
nosy: +miss-islington

___
Python tracker 

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

[issue35189] PEP 475: fnctl functions are not retried if interrupted by a signal (EINTR)

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +9937

___
Python tracker 

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

[issue35220] delete "how do I emulate os.kill" section in Windows FAQ

[Mathieu Dupuy]

Mathieu Dupuy  added the comment:

My PR has been merged, thanks

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

[issue34812] [Security] support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag

[miss-islington]

Change by miss-islington :


--
pull_requests: +9936

___
Python tracker 

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

[issue34812] [Security] support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 9de363271519e0616f4a7b59427057c4810d3acc by Victor Stinner in 
branch 'master':
bpo-34812: subprocess._args_from_interpreter_flags(): add isolated (GH-10675)
https://github.com/python/cpython/commit/9de363271519e0616f4a7b59427057c4810d3acc


--

___
Python tracker 

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

[issue35189] PEP 475: fnctl functions are not retried if interrupted by a signal (EINTR)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 56742f1eb05401a27499af0ccdcb4e4214859fd1 by Victor Stinner in 
branch '3.7':
[3.7] bpo-35189: Retry fnctl calls on EINTR (GH-10413) (GH-10678)
https://github.com/python/cpython/commit/56742f1eb05401a27499af0ccdcb4e4214859fd1


--

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

STINNER Victor  added the comment:

Advantages of inline functions over C macros:

https://mail.python.org/pipermail/python-dev/2018-November/155805.html


There are multiple advantages:

* Better development and debugging experience: tools understand
inlined functions much better than C macros: gdb, Linux perf, etc.

* Better API: arguments now have a type and the function has a return
type. In practice, some macros still cast their argument to PyObject*
to not introduce new compiler warnings in Python 3.8. For example,
even if Py_INCREF() is documented (*) as a function expecting
PyObject*, it accepts any pointer type (PyTupleObject*,
PyUnicodeObject*, etc.). Technically, it also accepts PyObject** which
is a bug, but that's a different story ;-)

* Much better code, just plain regular C. C macros are ugly: "do { ...
} while (0)" workaround, additional parenthesis around each argument,
strange "expr1, expr2" syntax of "macro expression" which returns a
value (inline function just uses regular "return" and ";" at the end
of instructions), strange indentation, etc.

* No more "macro pitfals":
https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html

* Local variables no longer need a magic name to avoid risk of name
conflict, and have a clearly defined scope. Py_DECREF() and
_Py_XINCREF() no longer need a local variable since it's argument
already has a clearly defined type: PyObject*. I introduced a new
variable in _Py_Dealloc() to fix a possible race condition.
Previously, the variable was probably avoided because it's tricky use
variables in macros.

* #ifdef can now be used inside the inline function: it makes the code
easier to understand.

* etc.


Are you aware that Python had macros like:

#define _Py_REF_DEBUG_COMMA ,
#define _Py_CHECK_REFCNT(OP) /* a semicolon */;

I let you judge the quality of this macro:

#define _Py_NewReference(op) (  \
_Py_INC_TPALLOCS(op) _Py_COUNT_ALLOCS_COMMA \
_Py_INC_REFTOTAL  _Py_REF_DEBUG_COMMA   \
Py_REFCNT(op) = 1)

Is it an expression? Can it be used in "if (test)
_Py_NewReference(op);"? It doesn't use the "do { ... } while (0)"
protection against macro pitfals.

(*) Py_INCREF doc:
https://docs.python.org/dev/c-api/refcounting.html#c.Py_INCREF

--

___
Python tracker 

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

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

[STINNER Victor]

STINNER Victor  added the comment:

Number lines containing Py_LIMITED_API in Include/ dir:

13:pyerrors.h
12:abstract.h
11:pylifecycle.h
11:dictobject.h
10:pystate.h
8:longobject.h
7:modsupport.h
7:ceval.h
7:bytesobject.h
6:pythonrun.h
5:warnings.h
5:tupleobject.h
5:methodobject.h
5:complexobject.h
...

--

___
Python tracker 

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

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +9935

___
Python tracker 

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

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +9934

___
Python tracker 

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

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

[STINNER Victor]

STINNER Victor  added the comment:


New changeset e421106b9e4d780c083113e4180d58d68acc69ab by Victor Stinner in 
branch 'master':
bpo-35134: Create Include/cpython/ subdirectory (GH-10624)
https://github.com/python/cpython/commit/e421106b9e4d780c083113e4180d58d68acc69ab


--

___
Python tracker 

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

[issue35189] PEP 475: fnctl functions are not retried if interrupted by a signal (EINTR)

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +9933

___
Python tracker 

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

[issue35189] PEP 475: fnctl functions are not retried if interrupted by a signal (EINTR)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset b409ffa848b280c1db1b4f450bfae14f263099ac by Victor Stinner 
(nierob) in branch 'master':
bpo-35189: Retry fnctl calls on EINTR (GH-10413)
https://github.com/python/cpython/commit/b409ffa848b280c1db1b4f450bfae14f263099ac


--

___
Python tracker 

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

[issue35081] Move internal headers to Include/internal/

[STINNER Victor]

STINNER Victor  added the comment:

In bpo-35296, I modified "make install" to also install Include/internal/.

--

___
Python tracker 

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

[issue35296] Install Include/internal/ header files

[STINNER Victor]

STINNER Victor  added the comment:

I decided to merge my PR because I started to *remove* functions from the 
public C API to move them to the CPython internal API: _PyObject_GC_TRACK() and 
_PyObject_GC_UNTRACK() are two examples from bpo-35081. So some people might 
want even more to use the internal API. The main issue with this API is the 
requirement to use the same compiler with the same compilation options, 
especially to access atomic variables.

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

___
Python tracker 

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

[issue35296] Install Include/internal/ header files

[STINNER Victor]

STINNER Victor  added the comment:


New changeset f653fd4d950ac092719b6152e38d77c62b443125 by Victor Stinner in 
branch 'master':
bpo-35296: make install now installs the internal API (GH-10665)
https://github.com/python/cpython/commit/f653fd4d950ac092719b6152e38d77c62b443125


--

___
Python tracker 

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

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

[STINNER Victor]

STINNER Victor  added the comment:

Nick Coghlan, Steve Dower and Paul Moore and me prefer "cpython" name, so let's 
go with that one!

--

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

STINNER Victor  added the comment:

I close the issue, it seems like all subtasks have been completed.

Summary of the issue:

* The following macros have been converted to static inline functions:

  - Py_INCREF(), Py_DECREF()
  - Py_XINCREF(), Py_XDECREF()
  - PyObject_INIT(), PyObject_INIT_VAR()
  - _Py_NewReference(), _Py_ForgetReference()
  - _Py_Dealloc()
  - _PyObject_GC_TRACK(), _PyObject_GC_UNTRACK()

* There is no significant impact on performance:

  * I ran performance benchmark on Python compiled in release mode
  * I ran the Python test suite on Python compiled in debug mode
  * I measured the compilation time in release an debug mode

* It has been decided to use "static inline" to declare inline function (write 
directly "static inline", no macro).
* It has been decided to no use __attribute__((always_inline)) nor 
__forceinline (ask the compiler to always inline).


--

Benjamin Peterson would "like to see Py_LOCAL_INLINE removed, too, fwiw", but 
it's part of the public C API. It would require a deprecation period. I'm not 
interested to touch the public C API.

Benjamin: please open a new issue if you still want to remove it :-)

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

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

STINNER Victor  added the comment:

> Drawbacks: Require a specific type can introduce compiler warnings if the 
> caller doesn't pass the proper type (PyObject* or PyVarObject*). 
> _Py_NewReference() and _Py_ForgetReference() seem to be properly used, but 
> not PyObject_INIT() and PyObject_INIT_VAR().

I worked around this issue by adding a macro to cast the argument and declare 
the static inline function with a different name. Example:

static inline void _Py_INCREF(PyObject *op)
{
_Py_INC_REFTOTAL;
op->ob_refcnt++;
}

#define Py_INCREF(op) _Py_INCREF(_PyObject_CAST(op))

--

___
Python tracker 

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

[issue35081] Move internal headers to Include/internal/

[STINNER Victor]

STINNER Victor  added the comment:

I close the issue, it seems like all sub-tasks have been completed!

Summary of the change:

* Header files of Include/internal/ are now all prefixed by "pycore_" and the 
directory has been added to the header search path. For example, #include 
"pycore_pystate.h" is now used in C code, instead of #include 
"internal/pystate.h".
* All "#ifdef Py_BUILD_CORE" code has been moved from Include/*.h to 
Include/internal/*.h (except of the _PyTuple_ITEMS() macro)
* I created many new header files in Include/internal/
* _json and _locale modules are now built with Py_BUILD_CORE define
* _PyObject_GC_TRACK() and _PyObject_GC_UNTRACK() have been removed from the 
public C API and moved to the internal API

There are other issues to track following steps:

* bpo-35296: Install Include/internal/ header files
* bpo-35258: Fix -Wmissing-prototypes warnings
* bpo-35134: Create Include/cpython/ subdirectory
* bpo-35059: Convert macros to static inline functions

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

___
Python tracker 

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

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +9932

___
Python tracker 

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

[issue35301] python.exe crashes - lzma?

[Jonathan]

New submission from Jonathan :

Python 3.6.3 on Windows 7 64 bit.

I keep getting intermittent crashes of Python.exe with my project. The error is 
below and as best I can see seems to be indicating the issue with the LZMA 
module.

All I'm doing is using it to compress web-pages (typically XML ones). Problem 
is, I can't replicate it. When I try and run the process again, the page that 
previously crashed it now works. I've had this happen three times so far (out 
of about 150,000 pages downloaded and compressed).

My use of LZMA is quite simply:

from lzma import compress
compress(page_content, preset=5)

The pages it has crashed on so far (but which work fine now):
http://www.geoportal.rlp.de/mapbender/php/wms.php?inspire=1_id=35833=GetCapabilities=WMS=1.3.0
https://maps.runnymede.gov.uk/geoserver/planning/lp_ancient_woodland/wms?request=GetCapabilities=WMS=1.3.0
http://serviziogc.regione.fvg.it/geoserver/GEOLOGIA/wms?request=GetCapabilities=WMS=1.3.0

I took a mini dump (attached) and full dump using Process Explorer. The full 
dump is 100MB compressed (1GB uncompressed).




Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: python.exe
  Application Version:  3.6.3150.1013
  Application Timestamp:59d3d3a3
  Fault Module Name:_lzma.pyd
  Fault Module Version: 3.6.3150.1013
  Fault Module Timestamp:   59d3d343
  Exception Code:   c005
  Exception Offset: 0002e368
  OS Version:   6.1.7601.2.1.0.768.3
  Locale ID:2057
  Additional Information 1: d00b
  Additional Information 2: d00be1cd6ce69f4b081e66c649a14f90
  Additional Information 3: 8c17
  Additional Information 4: 8c17b9c4b6a39b7e31bf71b3b1374f1b

--
files: python-mini.7z
messages: 330327
nosy: jonathan-lp
priority: normal
severity: normal
status: open
title: python.exe crashes - lzma?
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file47944/python-mini.7z

___
Python tracker 

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

[issue35081] Move internal headers to Include/internal/

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 4ac5328affa37bdfc5847dfdb2a41bad772e7270 by Victor Stinner in 
branch 'master':
bpo-35081: add NEWS entry for new Include/internal/pycore_*.h files (GH-10666)
https://github.com/python/cpython/commit/4ac5328affa37bdfc5847dfdb2a41bad772e7270


--

___
Python tracker 

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

[issue34812] [EASY] support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +9931
stage:  -> patch review

___
Python tracker 

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

[issue34812] [Security] support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag

[STINNER Victor]

STINNER Victor  added the comment:

I tried to explain how to fix the bug, but nobody came up with a working change 
2 months, so I wrote the PR myself. It's an important security issue, since the 
function is used by multiprocessing and distutils modules to spawn new child 
processes.

--
components:  -Tests
keywords:  -easy
title: [EASY] support.args_from_interpreter_flags() doesn't inherit -I 
(isolated) flag -> [Security] support.args_from_interpreter_flags() doesn't 
inherit -I (isolated) flag
type:  -> security

___
Python tracker 

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

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

[STINNER Victor]

Change by STINNER Victor :


--
title: Add a new Include/unstable/ subdirectory for the "unstable" API -> Add a 
new Include/cpython/ subdirectory for the "CPython API" with implementation 
details

___
Python tracker 

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

[issue35134] Add a new Include/unstable/ subdirectory for the "unstable" API

[STINNER Victor]

STINNER Victor  added the comment:

Jeremy Kloth:
> First off, to me, 'unstable' comes off quite negative, i.e. risky or erratic.

Ok, the 3rd people who dislike my "unstable" name, so it sounds really bad :-)

Jeremy Kloth: 
> 'volatile'; synonym for 'unstable' but with the benefit of being a C concept.

I don't think that it's true that the "#ifndef Py_LIMITED_API" is unstable or 
volatile. Most of this API didn't change much in the last 10 years. So sorry, 
"unstable" was really a bad name.

Brett Cannon:
> It's more a limited versus broad API. So maybe rename the directory "broad"?

Jeremy Kloth: 
> - 'extended' or 'extra'; as opposed to limited (from the macro)

The name by itself doesn't explain why an API should be in Include/ or 
Include//. What is extra or not?


Jeremy Kloth: 
> - 'crunchy'; Monty Python reference, "If we took the bones out, it wouldn't 
> be crunchy, would it?"   https://en.wikipedia.org/wiki/Crunchy_Frog

Sorry, I dislike humor in an API. An API has to make sense :-(


--

Ok, after I read all proposition, I now prefer "cpython".

Extract of my updated PR which gives the rationale:

   Include/.h should be the "portable Python API", whereas
   Include/cpython/.h should be the "CPython API": CPython
   implementation details.

It now makes sense to me what should go to Include/ and what should go to 
Include/cpython/.

Obviously, Include/cpython/ is incomplete. It's only the public flavor of the 
"CPython API". There is also the private CPython internal API in 
Include/internal/.

--

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

STINNER Victor  added the comment:


New changeset b509d52083e156f97d6bd36f2f894a052e960f03 by Victor Stinner in 
branch 'master':
bpo-35059: PyObject_INIT() casts to PyObject* (GH-10674)
https://github.com/python/cpython/commit/b509d52083e156f97d6bd36f2f894a052e960f03


--

___
Python tracker 

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

[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily

[Steve Dower]

Steve Dower  added the comment:

You're welcome to it - I deliberately left it for someone else to work on, 
though I'm happy to review and merge.

The visible change of making this lazy is that if someone reads from the dict, 
it'll be missing system-specified content types (until we lazily fill it in 
guess_type() ). Nobody is meant to read from it - it's public for people to 
*add* custom overrides - so this should be okay, but a little bit of GitHub 
research to find out if anyone does wouldn't hurt. Then we can at least warn 
them that it's changing before they run into their own bug.

--

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +9930

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

STINNER Victor  added the comment:

I ran my benchmarks, I close the PR 10669 (replace static inline functions with 
macros). You should still be able to use it as patch:

https://github.com/python/cpython/pull/10669.patch

--

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

STINNER Victor  added the comment:

"PyObject* PyObject_INIT(PyObject *op, PyTypeObject *typeobj)"
and
"PyVarObject* PyObject_INIT_VAR(PyVarObject *op, PyTypeObject *typeobj, 
Py_ssize_t size)"

Don't cast their argument to PyObject*/PyVarObject* which can introduce new 
warnings when upgrading from Python 3.7 to Python 3.8.

--

___
Python tracker 

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

[issue35290] [FreeBSD] test_c_locale_coercion doesn't support new C.UTF-8 locale of FreeBSD CURRENT

[STINNER Victor]

STINNER Victor  added the comment:

I tested my 3.7 and master fixes: they fix test_c_locale_coercion on the 
FreeBSD CURRENT buildbot.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

___
Python tracker 

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

[issue34523] Choose the filesystem encoding before Python initialization (add _PyCoreConfig.filesystem_encoding)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset f6e323ce322cf54b1a9e9252b13f93ebc28b5c24 by Victor Stinner in 
branch '3.7':
bpo-34523: Fix C locale coercion on FreeBSD CURRENT (GH-10672) (GH-10673)
https://github.com/python/cpython/commit/f6e323ce322cf54b1a9e9252b13f93ebc28b5c24


--

___
Python tracker 

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

[issue35290] [FreeBSD] test_c_locale_coercion doesn't support new C.UTF-8 locale of FreeBSD CURRENT

[STINNER Victor]

STINNER Victor  added the comment:


New changeset f6e323ce322cf54b1a9e9252b13f93ebc28b5c24 by Victor Stinner in 
branch '3.7':
bpo-34523: Fix C locale coercion on FreeBSD CURRENT (GH-10672) (GH-10673)
https://github.com/python/cpython/commit/f6e323ce322cf54b1a9e9252b13f93ebc28b5c24


--

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

STINNER Victor  added the comment:

Stefan Behnel wrote:
https://mail.python.org/pipermail/python-dev/2018-November/155759.html

"""
It's also slower to compile, given that function inlining happens at a much
later point in the compiler pipeline than macro expansion. The C compiler
won't even get to see macros in fact, whereas whether to inline a function
or not is a dedicated decision during the optimisation phase based on
metrics collected in earlier stages. For something as ubiquitous as
Py_INCREF/Py_DECREF, it might even be visible in the compilation times.
"""

I ran a benchmark on the compilation time using PR 10669: there is no 
significant slowdown (+4 seconds, 6% slower, in the worst case).


I ran a benchmark on my laptop:

* Fedora 29
* Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz: 4 physical cores (8 threads)
* GCC 8.2.1
* MAKEFLAGS=-j9

Result in release mode:

* git clean -fdx; ./configure; time make # -03
* C macros: 1m12,158s
* static inline functions: 1m16,294s (+4.136s, +6%)

Result in debug mode:

* git clean -fdx; ./configure --with-pydebug; time make # -Og
* C macros: 0m39,727s
* static inline functions: 0m40,423s (+0.696s, +2%)

I only used "real" time (I ignored user and sys times).

--

___
Python tracker 

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

[issue35300] Bug with memoization and mutable objects

[bolorsociedad]

bolorsociedad  added the comment:

I understand it may be inefficient sometimes. Perhaps it would be nice to add 
an argument to lru_cache to specify that we want to deep copy? Something like

def lru_cache(..., deepcopy=False):
   ...

--

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

STINNER Victor  added the comment:

Unexpected cool effect of static inline functions (copy of my email):
https://mail.python.org/pipermail/python-dev/2018-November/155747.html

Le jeu. 15 nov. 2018 à 01:06, Gregory P. Smith  a écrit :
> I expect the largest visible impact may be that a profiler may now attribute 
> CPU cycles takes by these code snippets to the function from the .h file 
> rather than directly to the functions the macro expanded in in the past due 
> to additional debug symbol info attribution. Just more data. Consider that a 
> win.

Oh. That's very interesting.

I just tried gdb and I confirm that gdb understands well inlined
function. When I debug Python, gdb moves into Py_INCREF() or
Py_DECREF() when I use "next".

I also tried perf record/perf report: if I annotate a function
(assembler code of the function), perf shows me the C code of inlined
Py_INCREF and Py_DECREF!

That's nice!

Victor

--

___
Python tracker 

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

[issue35300] Bug with memoization and mutable objects

[STINNER Victor]

STINNER Victor  added the comment:

> When the returned mutable object is modified, the cache is modified as well. 
> In my opinion, functools.lru_cache should store a deep copy of the returned 
> object.

It would be inefficient to deep copy the mutable result and can defeat the 
purpose of the cache...

I would rather to add a note to the documentation to explain to either not 
return mutable objects or to not modify them :-)
https://docs.python.org/dev/library/functools.html#functools.lru_cache

--
nosy: +rhettinger, vstinner

___
Python tracker 

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

[issue34523] Choose the filesystem encoding before Python initialization (add _PyCoreConfig.filesystem_encoding)

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +9928

___
Python tracker 

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

[issue35290] [FreeBSD] test_c_locale_coercion doesn't support new C.UTF-8 locale of FreeBSD CURRENT

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +9929

___
Python tracker 

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

[issue34523] Choose the filesystem encoding before Python initialization (add _PyCoreConfig.filesystem_encoding)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 353933e712b6c7f7ba9a9a50bd5bd472db7c35d0 by Victor Stinner in 
branch 'master':
bpo-34523: Fix C locale coercion on FreeBSD CURRENT (GH-10672)
https://github.com/python/cpython/commit/353933e712b6c7f7ba9a9a50bd5bd472db7c35d0


--

___
Python tracker 

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

[issue35290] [FreeBSD] test_c_locale_coercion doesn't support new C.UTF-8 locale of FreeBSD CURRENT

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 353933e712b6c7f7ba9a9a50bd5bd472db7c35d0 by Victor Stinner in 
branch 'master':
bpo-34523: Fix C locale coercion on FreeBSD CURRENT (GH-10672)
https://github.com/python/cpython/commit/353933e712b6c7f7ba9a9a50bd5bd472db7c35d0


--

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

STINNER Victor  added the comment:

I ran a coarse benchmark on the debug mode using PR 10669: I ran the full 
Python test suite.

=> I don't see any significant impact on performance.

* C macros: PR 10669
* static inline functions: commit 3bb183d7fb83ad6a84ec13dea90f95d67be35c69 (PR 
10669 parent)

git clean -fdx # remove *all* untracked files
./configure --with-pydebug && make
./python -m test -j0 -r --randseed=2411717

Result:

* C macros: 3 min 22 sec
* static inline functions: 3 min 26 sec (+4 sec, +2%)

I used my laptop to run the benchmark: Fedora 29 with GCC 8.2.1. I was still 
using the laptop to run other tasks.

--

___
Python tracker 

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

[issue35300] Bug with memoization and mutable objects

[bolorsociedad]

New submission from bolorsociedad :

The decorator functools.lru_cache seems to not work properly when the function 
to be memoized returns a mutable object.

For instance:

>>> import functools
>>> @functools.lru_cache()
... def f(x):
...return [x, x + 1]
... 
>>> a = f(4)
>>> print(a)
[4, 5]
>>> a[0] = 0
>>> f(4)
[0, 5]


When the returned mutable object is modified, the cache is modified as well. In 
my opinion, functools.lru_cache should store a deep copy of the returned object.

--

___
Python tracker 

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

[issue35300] Bug with memoization and mutable objects

[bolorsociedad]

Change by bolorsociedad :


--
components: Library (Lib)
nosy: bolorsociedad
priority: normal
severity: normal
status: open
title: Bug with memoization and mutable objects
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue35290] [FreeBSD] test_c_locale_coercion doesn't support new C.UTF-8 locale of FreeBSD CURRENT

[STINNER Victor]

STINNER Victor  added the comment:

The bug is that sys.getfilesystemencoding() should be the locale encoding. On 
FreeBSD CURRENT, Python uses ASCII for the filesystem encoding, whereas the 
locale encoding is UTF-8.

CURRENT-amd64% env -i ./python -X utf8=0 -c 'import locale, sys; 
print(sys.getfilesystemencoding(), locale.getpreferredencoding())'
ascii UTF-8

--

___
Python tracker 

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

[issue31512] Add non-elevated symlink support for dev mode Windows 10

[Vidar Fauske]

Vidar Fauske  added the comment:

The PR has been sitting for a while now with all previous concerns addressed. 
There has been a few pings on the PR without anything new happening, so I 
thought I would ping this issue as well: are there any other concerns about 
this PR, or anything else that is preventing it from being merged?

--

___
Python tracker 

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

[issue35290] [FreeBSD] test_c_locale_coercion doesn't support new C.UTF-8 locale of FreeBSD CURRENT

[STINNER Victor]

STINNER Victor  added the comment:

Oh, I also modified Python 3.7 to respect the "force ASCII" mode in bpo-34403, 
commit 21220bbe65108f5a763ead24a6b572f80d84c9e2. Hopefully, this change is not 
part of the latest Python 3.7.1 bugfix release.

By the way, the bug only impacts FreeBSD CURRENT users (after Nov 4, after 
C.UTF-8 has been added) who have no locale set (LC_CTYPE is "C", ex: python3 
running in an empty environment) and explicitly disable the UTF-8 mode... Well, 
I guess that very few users (I mean no one) are impacted :-)

--

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

STINNER Victor  added the comment:


New changeset e89607c0fc8d6edbf19c06ba42ff0f00e6c4273f by Victor Stinner in 
branch 'master':
bpo-35059: NEWS entry for macros converted to inline funcs (GH-10671)
https://github.com/python/cpython/commit/e89607c0fc8d6edbf19c06ba42ff0f00e6c4273f


--

___
Python tracker 

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

[issue35081] Move internal headers to Include/internal/

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 984061eeb49c54fee901b92e5d3dde1c7a25cfa1 by Victor Stinner in 
branch 'master':
bpo-35081: Add new internal headers to Makefile (GH-10670)
https://github.com/python/cpython/commit/984061eeb49c54fee901b92e5d3dde1c7a25cfa1


--

___
Python tracker 

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

[issue35290] [FreeBSD] test_c_locale_coercion doesn't support new C.UTF-8 locale of FreeBSD CURRENT

[STINNER Victor]

STINNER Victor  added the comment:

Ok, I found the bug: it is related to the commit 
905f1ace5f7424e314ca7bed997868a2a3044839 of bpo-34523. Python now uses ASCII 
for the filesystem encoding if the internal "force ASCII" mode is enabled in 
Py_DecodeLocale/Py_EncodeLocale.

FreeBSD CURRENT introduced a new C.UTF-8 locale which is used by C locale 
coercion (PEP 538).

_PyCoreConfig_Read() now uses ASCII for the filesystem encoding if the "force 
ASCII" mode is enable (to ensure that encodings are consistent everywhere 
Python).

Problem: The LC_CTYPE now uses UTF-8 (thanks to C locale coercion) whereas 
Python uses ASCII for the filesystem encoding since the "force ASCII" is still 
enabled.

I wrote PR 10672 to reset the "force ASCII" mode. I tested manually my fix on 
the FreeBSD CURRENT buildbot.

--

___
Python tracker 

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

[issue35290] [FreeBSD] test_c_locale_coercion doesn't support new C.UTF-8 locale of FreeBSD CURRENT

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +9927

___
Python tracker 

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

[issue34523] Choose the filesystem encoding before Python initialization (add _PyCoreConfig.filesystem_encoding)

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +9926

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

STINNER Victor  added the comment:

I wrote a pull request to replace static inline functions with C macros: PR 
10669. I ran a benchmark on speed.python.org server using the "performance" 
benchmark suite:
http://pyperformance.readthedocs.io/

I understand that from the benchmark results that converting macros to static 
inline functions has no significant impact on performances. Two benchmarks are 
1.06x and 1.07x faster but it can be explained by the PGO compilation which is 
not reliable. One benchmark is way slower, but it seems like the benchmark has 
an issue. If you look at the 3 latest run on speed.python.org, I see:

* 38.2 us (Sept 24)
* 43.5 us (Nov 21)
* 43.7 us (Nov 22)

I don't think that any change in _pickle or pickle explains this significant 
slowdown. IMHO it's just that the benchmark is not reliable :-/ We have a 
performance timeline on the last 5 years, and this benchmark doesn't have a 
straight line, we can see that the result is a little bit random :-/

--

speed.python.org runs Ubuntu 16.04 with gcc 5.4.0.

The result are the two attached (compressed) JSON files:

* 2018-11-22_17-38-master-3bb183d7fb83-patch-10669.json.gz: reference, Python 
using C macros
* 2018-11-22_17-38-master-3bb183d7fb83.json.gz: static inline, current master 
branch

Comparison ignoring difference smaller than -5% and +5%, macros are the 
reference:

vstinner@apu$ python3 -m perf compare_to --table -G --min-speed=5 
macros.json.gz inline.json.gz 
+--+-+--+
| Benchmark| macros  | inline   |
+==+=+==+
| regex_dna| 288 ms  | 269 ms: 1.07x faster (-7%)   |
+--+-+--+
| crypto_pyaes | 236 ms  | 223 ms: 1.06x faster (-5%)   |
+--+-+--+
| pickle_dict  | 37.8 us | 43.7 us: 1.16x slower (+16%) |
+--+-+--+

Not significant (54): (...)


Raw comparison, full data, macros are the reference:

vstinner@apu$ python3 -m perf compare_to --table -G macros.json.gz 
inline.json.gz 
+-+--+--+
| Benchmark   | macros   | inline   |
+=+==+==+
| regex_dna   | 288 ms   | 269 ms: 1.07x faster (-7%)   |
+-+--+--+
| crypto_pyaes| 236 ms   | 223 ms: 1.06x faster (-5%)   |
+-+--+--+
| nqueens | 199 ms   | 195 ms: 1.02x faster (-2%)   |
+-+--+--+
| raytrace| 1.01 sec | 984 ms: 1.02x faster (-2%)   |
+-+--+--+
| chaos   | 224 ms   | 221 ms: 1.02x faster (-2%)   |
+-+--+--+
| logging_simple  | 21.2 us  | 20.9 us: 1.01x faster (-1%)  |
+-+--+--+
| unpack_sequence | 117 ns   | 116 ns: 1.01x faster (-1%)   |
+-+--+--+
| spectral_norm   | 247 ms   | 244 ms: 1.01x faster (-1%)   |
+-+--+--+
| regex_v8| 41.8 ms  | 41.4 ms: 1.01x faster (-1%)  |
+-+--+--+
| pickle  | 19.9 us  | 19.7 us: 1.01x faster (-1%)  |
+-+--+--+
| logging_format  | 24.0 us  | 23.8 us: 1.01x faster (-1%)  |
+-+--+--+
| scimark_sparse_mat_mult | 9.06 ms  | 8.99 ms: 1.01x faster (-1%)  |
+-+--+--+
| pathlib | 42.1 ms  | 41.8 ms: 1.01x faster (-1%)  |
+-+--+--+
| meteor_contest  | 188 ms   | 187 ms: 1.01x faster (-1%)   |
+-+--+--+
| unpickle_pure_python| 704 us   | 700 us: 1.01x faster (-1%)   |
+-+--+--+
| python_startup  | 12.0 ms  | 12.0 ms: 1.00x faster (-0%)  |
+-+--+--+
| python_startup_no_site  | 7.91 ms  | 7.94 ms: 1.00x slower (+0%)  |
+-+--+--+
| sympy_integrate | 35.0 ms  | 35.3 ms: 1.01x slower (+1%)  |
+-+--+--+
| pidigits| 283 ms   | 285 ms: 1.01x slower (+1%)   |

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +9925

___
Python tracker 

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

[issue35081] Move internal headers to Include/internal/

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +9924

___
Python tracker 

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

[issue35059] Convert Py_INCREF() and PyObject_INIT() to inlined functions

[STINNER Victor]

Change by STINNER Victor :


Added file: 
https://bugs.python.org/file47943/2018-11-22_17-38-master-3bb183d7fb83-patch-10669.json.gz

___
Python tracker 

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

[issue35052] Coverity scan: copy/paste error in Lib/xml/dom/minidom.py

[Petr Viktorin]

Petr Viktorin  added the comment:

Ah, XML is such an overengineered format!

Iusually live with the standard HTML entities  but it turns out 
you can define your own!

Here's a reproducer which shows how to do that.

--
nosy: +petr.viktorin
Added file: https://bugs.python.org/file47942/reproducer.py

___
Python tracker 

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