[issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x

[Davin Potts]

Change by Davin Potts :


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

___
Python tracker 

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

[issue36039] Replace append loops with list comprehensions

[Lukas Geiger]

Lukas Geiger  added the comment:

Thank you very much for your thorough explanation, totally makes sense.

--

___
Python tracker 

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

[issue36108] Avoid failing the build on race condition in clean

[Steve Dower]

New submission from Steve Dower :

In PCbuild/openssl.props there is a task that deletes some copied files. 

This *might* fail on rebuilds where a Python process from a previous build has 
been running (for a very specific example, the rebuild as part of the release 
build triggered this).

We shouldn't need to fail the build in this case, so change the 
"TreatErrorsAsWarnings" attribute to "false"

(Note that this is not fixed by the KillPython step if the still-running 
executable is "python.exe" but we're building "python_d.exe" in the same 
folder. But warning and continuing is going to be fine for these particular 
files.)

--
components: Build, Windows
keywords: easy (C)
messages: 336549
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Avoid failing the build on race condition in clean
type: compile error
versions: Python 3.8

___
Python tracker 

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

[issue35840] Control flow inconsistency on closed asyncio stream

[Emmanuel Arias]

Emmanuel Arias  added the comment:

Ok, I am working on that.

--

___
Python tracker 

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

[issue36107] aarch64 python3 buffer overflow with stack protector on rpi3 (alpine linux)

[Natanael Copa]

Change by Natanael Copa :


--
type:  -> crash

___
Python tracker 

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

[issue32129] IDLE app icon is blurry on macOS with Aqua Tk 8.6

[Ned Deily]

Ned Deily  added the comment:

Thanks, Kevin, for the reminder.  Yeah, there's no reason not to push this.  
I've attached PRs for 3.x and for 2.7.

--
stage: patch review -> commit review
title: Icon on macOS -> IDLE app icon is blurry on macOS with Aqua Tk 8.6
versions: +Python 2.7, 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

[issue36103] Increase shutil.COPY_BUFSIZE

[desbma]

desbma  added the comment:

If you do a benchmark by reading from a file, and then writing to /dev/null 
several times, without clearing caches, you are measuring *only* the syscall 
overhead:
* input data is read from the Linux page cache, not the file on your SSD itself
* no data is written (obviously because output is /dev/null)

Your current command line also measures open/close timings, without that I 
think the speed should linearly increase when doubling buffer size, but of 
course this is misleading, because its a synthetic benchmark.

Also if you clear caches in between tests, and  write the output file to the 
SSD itself, sendfile will be used, and should be even faster.

So again I'm not sure this means much compared to real world usage.

--

___
Python tracker 

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

[issue35178] Typo/trivial mistake in warnings.py (may be related to 2.x to 3.x conversion)

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


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

___
Python tracker 

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

[issue32129] Icon on macOS

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +12064

___
Python tracker 

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

[issue36107] aarch64 python3 buffer overflow with stack protector on rpi3 (alpine linux)

[Natanael Copa]

Natanael Copa  added the comment:

It seems like python 3.7.2 works. Any idea which commit(s) may have fixed it?

--

___
Python tracker 

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

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:

GH-11617 has introduces a slight performance regression which will need to be 
resolved.  If I can't find the problem right away then I'll probably 
temporarily revert the commit.

See https://mail.python.org/pipermail/python-dev/2019-February/156451.html.

--

___
Python tracker 

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

[issue36030] add internal API function to create tuple without items array initialization

[Sergey Fedoseev]

Change by Sergey Fedoseev :


--
pull_requests: +12062

___
Python tracker 

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

[issue36107] aarch64 python3 buffer overflow with stack protector on rpi3 (alpine linux)

[Natanael Copa]

Natanael Copa  added the comment:

Valgrind claims there are some use of uninitialized values.

--
Added file: https://bugs.python.org/file48169/valgrind.out

___
Python tracker 

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

[issue36107] aarch64 python3 buffer overflow with stack protector on rpi3 (alpine linux)

[Natanael Copa]

Natanael Copa  added the comment:

Interestingly, it does not crash when I run python in valgrind.

--

___
Python tracker 

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

[issue36030] add internal API function to create tuple without items array initialization

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 234531b4462b20d668762bd78406fd2ebab129c9 by Victor Stinner 
(Sergey Fedoseev) in branch 'master':
bpo-36030: Add _PyTuple_FromArray() function (GH-11954)
https://github.com/python/cpython/commit/234531b4462b20d668762bd78406fd2ebab129c9


--

___
Python tracker 

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

[issue36107] aarch64 python3 buffer overflow with stack protector on rpi3 (alpine linux)

[Natanael Copa]

New submission from Natanael Copa :

Alpine Linux's python 3.6.8 native build on aarch64 gets killed by stack 
protector when run on Raspberry Pi 3.

It does not happen when same binary runs on packet.net's aarch64 machine.

I was able to get a backtrace by copying the core.

Core was generated by `python3'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x007f86e85d9c in a_crash () at ./src/internal/atomic.h:250
250 ./src/internal/atomic.h: No such file or directory.
(gdb) bt
#0  0x007f86e85d9c in a_crash () at ./src/internal/atomic.h:250
#1  __stack_chk_fail () at src/env/__stack_chk_fail.c:17
#2  0x007f86cbc068 in _PyObject_CallMethodId_SizeT (o=o@entry=0x7f86bb1a98, 
name=name@entry=0x7f86e1cb88 , 
format=format@entry=0x0) at Objects/abstract.c:2677
#3  0x007f86d2fbb0 in _io_TextIOWrapper___init___impl (write_through=0, 
line_buffering=1, newline=, errors=0x7f86d6d810 "strict", 
encoding=, buffer=0x7f86bb1a98, self=) at 
./Modules/_io/textio.c:1017
#4  _io_TextIOWrapper___init__ (self=0x7f86b5e630, args=, 
kwargs=) at ./Modules/_io/clinic/textio.c.h:173
#5  0x007f86cabf94 in type_call (type=, args=0x7f86b2c0a0, 
kwds=0x0) at Objects/typeobject.c:915
#6  0x007f86c5f25c in PyObject_Call (func=0x7f86e083b0 
, args=, kwargs=kwargs@entry=0x0)
at Objects/abstract.c:2261
#7  0x007f86c5f30c in call_function_tail 
(callable=callable@entry=0x7f86e083b0 , args=, args@entry=0x7f86b2c0a0)
at Objects/abstract.c:2512
#8  0x007f86c96d5c in callmethod (func=func@entry=0x7f86e083b0 
, format=format@entry=0x7f86d7d4de "OsssO", va=..., 
is_size_t=is_size_t@entry=0) at Objects/abstract.c:2596
#9  0x007f86cbc8c8 in _PyObject_CallMethodId (o=o@entry=0x7f86adf098, 
name=name@entry=0x7f86e1e0c0 , 
format=format@entry=0x7f86d7d4de "OsssO") at Objects/abstract.c:2640
#10 0x007f86cd8dec in create_stdio (io=, fd=, 
write_mode=, name=, 
encoding=, errors=, io=, 
fd=, write_mode=, name=, 
encoding=, errors=) at 
Python/pylifecycle.c:1154
#11 0x007f86cd91b4 in initstdio () at Python/pylifecycle.c:1277
#12 0x007f86d419cc in _Py_InitializeEx_Private (install_sigs=, install_importlib=, install_sigs=, 
install_importlib=) at Python/pylifecycle.c:449
#13 0x007f86d41a70 in Py_InitializeEx (install_sigs=install_sigs@entry=1) 
at Python/pylifecycle.c:470
#14 0x007f86d41a78 in Py_Initialize () at Python/pylifecycle.c:476
#15 0x007f86d42c74 in Py_Main (argc=1, argv=0x7f86f10f60) at 
Modules/main.c:700
#16 0x00558291db34 in main (argc=1, argv=0x7feb5b3e48) at 
./Programs/python.c:69




Downstream reports:
https://bugs.alpinelinux.org/issues/9981
https://github.com/gliderlabs/docker-alpine/issues/486

--
components: Interpreter Core
files: strace.out
messages: 336540
nosy: Natanael Copa
priority: normal
severity: normal
status: open
title: aarch64 python3 buffer overflow with stack protector on rpi3 (alpine 
linux)
versions: Python 3.6
Added file: https://bugs.python.org/file48168/strace.out

___
Python tracker 

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

[issue32129] Icon on macOS

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +12061
stage:  -> patch review

___
Python tracker 

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

[issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 95fc8e687c487ecf97f4b1b98dfc0c05e3c9cbff by Serhiy Storchaka in 
branch '3.7':
[3.7] bpo-28450: Fix and improve the documentation for unknown escapes in RE. 
(GH-11920). (GH-12029)
https://github.com/python/cpython/commit/95fc8e687c487ecf97f4b1b98dfc0c05e3c9cbff


--

___
Python tracker 

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

[issue34781] infinite waiting in multiprocessing.Pool

[Dongyan Li]

Dongyan Li  added the comment:

I got the same issue with Python 3.7.2 on Windows Build 14393. Seems that the 
program got stuck on the `waiter.acquire()` method.

--
nosy: +Dongyan Li

___
Python tracker 

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

[issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem()

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +12060

___
Python tracker 

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

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue35178] Typo/trivial mistake in warnings.py (may be related to 2.x to 3.x conversion)

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

@tashrifbillah I will be happy to add a test on a follow up PR attributing to 
the original PR as per 
https://github.com/python/cpython/pull/10343#issuecomment-467026474

Thanks

--
nosy: +xtreak

___
Python tracker 

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

[issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset a24107b04c1277e3c1105f98aff5bfa3a98b33a0 by Serhiy Storchaka in 
branch 'master':
bpo-35459: Use PyDict_GetItemWithError() instead of PyDict_GetItem(). (GH-2)
https://github.com/python/cpython/commit/a24107b04c1277e3c1105f98aff5bfa3a98b33a0


--

___
Python tracker 

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

[issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset a180b007d96fe68b32f11dec720fbd0cd5b6758a by Serhiy Storchaka in 
branch 'master':
bpo-28450: Fix and improve the documentation for unknown escapes in RE. 
(GH-11920)
https://github.com/python/cpython/commit/a180b007d96fe68b32f11dec720fbd0cd5b6758a


--

___
Python tracker 

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

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 6a44f6eef3d0958d2347190b3e2d1222c2e9 by Serhiy Storchaka in 
branch 'master':
bpo-36048: Use __index__() instead of __int__() for implicit conversion if 
available. (GH-11952)
https://github.com/python/cpython/commit/6a44f6eef3d0958d2347190b3e2d1222c2e9


--

___
Python tracker 

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

[issue36103] Increase shutil.COPY_BUFSIZE

[Inada Naoki]

Inada Naoki  added the comment:

> Your first link explains why 128kB buffer size is faster in the context of 
> cp: it's due to fadvise and kernel read ahead.
> 
> None of the shutil functions call fadvise, so the benchmark and conclusions 
> are irrelevant to the Python buffer size IMO.

Even without fadvice, readahead works automatically.  fadvice doubles readahead 
size on Linux.  But I don't know it really doubles readahead size when block 
device advertised readahead size.


> In general, the bigger buffer, the better, to reduce syscall frequency (also 
> explained in the article), but going from 16kB to 128kB is clearly in the 
> micro optimization range, unlikely to do any significant difference.
>
> Also with 3.8, in many typical file copy cases (but not all), sendfile will 
> be used, which makes buffer size even less important.

It is used for copyfileobj.  So better default value may worth enough.

In my Linux box, SATA SSD (Samsung SSD 500GB 860EVO) is used.
It has unstable sequential write performance.

Here is quick test:

$ dd if=/dev/urandom of=f1 bs=1M count=1k

$ ./python -m timeit -n1 -r5 -v -s 'import shutil;' -- 'f1=open("f1","rb"); 
f2=open("/dev/null", "wb"); shutil.copyfileobj(f1, f2, 8*1024); f1.close(); 
f2.close()'
raw times: 301 msec, 302 msec, 301 msec, 301 msec, 300 msec

1 loop, best of 5: 300 msec per loop

$ ./python -m timeit -n1 -r5 -v -s 'import shutil;' -- 'f1=open("f1","rb"); 
f2=open("/dev/null", "wb"); shutil.copyfileobj(f1, f2, 16*1024); f1.close(); 
f2.close()'
raw times: 194 msec, 194 msec, 193 msec, 193 msec, 193 msec

1 loop, best of 5: 193 msec per loop

$ ./python -m timeit -n1 -r5 -v -s 'import shutil;' -- 'f1=open("f1","rb"); 
f2=open("/dev/null", "wb"); shutil.copyfileobj(f1, f2, 32*1024); f1.close(); 
f2.close()'
raw times: 140 msec, 140 msec, 140 msec, 140 msec, 140 msec

1 loop, best of 5: 140 msec per loop

$ ./python -m timeit -n1 -r5 -v -s 'import shutil;' -- 'f1=open("f1","rb"); 
f2=open("/dev/null", "wb"); shutil.copyfileobj(f1, f2, 64*1024); f1.close(); 
f2.close()'
raw times: 112 msec, 112 msec, 112 msec, 112 msec, 112 msec

1 loop, best of 5: 112 msec per loop

$ ./python -m timeit -n1 -r5 -v -s 'import shutil;' -- 'f1=open("f1","rb"); 
f2=open("/dev/null", "wb"); shutil.copyfileobj(f1, f2, 128*1024); f1.close(); 
f2.close()'
raw times: 101 msec, 101 msec, 101 msec, 101 msec, 101 msec


As far as this result, I think 64KiB is the best balance.

--

___
Python tracker 

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

[issue36106] resolve sinpi() name clash with libm

[Emmanuel Arias]

Change by Emmanuel Arias :


--
nosy: +eamanu

___
Python tracker 

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

[issue36105] Windows: use GetNativeSystemInfo instead of GetSystemInfo

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

It appears you guys are right. Sorry for the noise.

--

___
Python tracker 

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

[issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x

[Davin Potts]

Davin Potts  added the comment:

In local testing, I found the following systems to impose the leading slash as 
a requirement for simply creating a shared memory block:
* NetBSD 8.0
* FreeBSD 12.x
* TrueOS 18.12 (the OS formerly known as PC-BSD)

I found the following systems to have no required leading slash and all tests 
currently pass without modification:
* OpenBSD 6.4
* DragonflyBSD 5.4

--

___
Python tracker 

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

[issue36030] add internal API function to create tuple without items array initialization

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This change is virtually renaming _PyStack_AsTuple to _PyTuple_FromArray and 
using it in appropriate places for code simplification. I am +1 for such change.

--

___
Python tracker 

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

[issue36106] resolve sinpi() name clash with libm

[Dmitrii Pasechnik]

Dmitrii Pasechnik  added the comment:

e.g. if I rename `m_lgamma` to `lgamma` I get
```
mathmodule.c:389:1: error: static declaration of ‘lgamma’ follows non-static 
declaration
 lgamma(double x)
```

--

___
Python tracker 

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

[issue36106] resolve sinpi() name clash with libm

[Dmitrii Pasechnik]

Dmitrii Pasechnik  added the comment:

This has a potential header conflict. For the same reason functions like
lgamma, etc. are prefixed with `m_` in Modules/mathmodule.c

--

___
Python tracker 

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

[issue36105] Windows: use GetNativeSystemInfo instead of GetSystemInfo

[Steve Dower]

Steve Dower  added the comment:

Yeah, possibly only the CPU count one could change, but there's an ongoing 
discussion on another bug about whether that should return the actual count or 
the usable count.

32-bit processes have restrictions beyond what the system is capable of, and I 
believe we want those reflected in each of these cases.

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

[issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed

[Andrey Paramonov]

Andrey Paramonov  added the comment:

> an implicit requirement that back pressure from the consumer should be 
> handled (i.e. if whoever's iterating through "async for fut in 
> as_completed(...)" is too slow, then the tasks should pause until it catches 
> up)

No, I don't think it is required or desired to be handled.

My initial sketch was imprecise: it's better to asynchronously yield task 
results, not "completed task" futures. This way, no additional buffer needed, 
all error handling can be consolidated inside `igather()`, and that's actually 
more compatible with `asyncio.gather()`.

I.e, instead of

yield next_fut

use

yield await next_fut


--

___
Python tracker 

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

[issue36106] resolve sinpi() name clash with libm

[Emmanuel Arias]

Emmanuel Arias  added the comment:

Hi!, 

It seem a good improve to resolve a potential problem. But I am not convinced 
if that problem could appear because sinpi() is definded locally.

--

___
Python tracker 

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

[issue36078] argparse: positional with type=int, default=SUPPRESS raise ValueError

[Axel]

Axel  added the comment:

Thanks for so fast looking into this.

Good idea to use the workaround with a own conversion function. I'll use this 
for now.

To see what's happening, I tried a own Action with print in __call__ and a own 
conversion function with printing. I found following workflow:
1) direct assignment of unconverted default value (if not SUPPRESS, in 
parse_known_args)
2) conversion of argument string into given type
3) call to Action.__call__ which sets the converted value
4) only in edge cases: Convert default into given type and set in target

When there is no option there is only:
default  | arg, narg = '?' | --opt  | arg, narg = '*'
-
None | 1), 3)  | 1) | 1), 2) with []
SUPPRESS | 2)! || 
str  | 1), 2), 3)  | 1) | 1), 2)
not str* | 1), 3)  | 1), 4) | 1), 2)

*can be int, float or other calss

It gets more complex the deeper I get into the source...

Yes, your second choice has probably less side effects.

--

___
Python tracker 

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

[issue36103] Increase shutil.COPY_BUFSIZE

[desbma]

desbma  added the comment:

Your first link explains why 128kB buffer size is faster in the context of cp: 
it's due to fadvise and kernel read ahead.

None of the shutil functions call fadvise, so the benchmark and conclusions are 
irrelevant to the Python buffer size IMO.

In general, the bigger buffer, the better, to reduce syscall frequency (also 
explained in the article), but going from 16kB to 128kB is clearly in the micro 
optimization range, unlikely to do any significant difference.

Also with 3.8, in many typical file copy cases (but not all), sendfile will be 
used, which makes buffer size even less important.

--
nosy: +desbma

___
Python tracker 

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

[issue36104] test_httplib and test_nntplib fail on ARMv7 Ubuntu

[STINNER Victor]

Change by STINNER Victor :


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

[issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x

[Davin Potts]

Davin Potts  added the comment:

Though apparently undocumented on FreeBSD, their implementation of shm_open 
differs from others in the following way:  all names for shared memory blocks 
*must* begin with a slash.  This requirement does not exist on OpenBSD.

According to its man page on shm_open, FreeBSD does at least communicate the 
following non-standard, additional requirement:
Two processes opening the same path
are guaranteed to access the same shared memory object if and only if
path begins with a slash (`/') character.


Given that this requirement is not universal and because a leading slash 
controls other behaviors on platforms like Windows, it would be confusing to 
make a leading slash a universal requirement.

Likewise, requiring users on FreeBSD to be aware of this nuance would be 
contrary to the goals of the SharedMemory class.


I will prepare a patch to prepend a leading slash onto the requested shared 
memory block name and detect the need for it.

I have verified that this does solve the problem on FreeBSD and that all tests 
then pass.  I will test NetBSD and DragonflyBSD to see if they also impose 
FreeBSD's undocumented requirement.

--

___
Python tracker 

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

[issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a)

[STINNER Victor]

STINNER Victor  added the comment:

Lukasz: this issue is that Debian Buster uses a strict OpenSSL policy. I guess 
that external public server used by tests are incompatible with this strict 
policy.

--
nosy: +lukasz.langa

___
Python tracker 

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

[issue35925] test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster bot (OpenSSL 1.1.1a)

[STINNER Victor]

STINNER Victor  added the comment:

bpo-36104 has been marked as a duplicate of this issue. Copy of Lukasz's 
msg336511:

The ARMv7 Ubuntu buildbot is consistently failing since build #2160:
https://buildbot.python.org/all/#/builders/106/builds/2160


This looks like a testing environment issue to me rather than a code issue. But 
I'd like it fixed either way before we get to 3.8.0 beta1 since this is a 
stable builder. Greg, you can ask Inadasan about whether his dict/OrderedDict 
changes might have any effect on this failure:
https://github.com/python/cpython/commit/c95404ff65dab1469dcd1dfec58ba54a8e7e7b3a

That was the only relevant change I observed between the working and the broken 
build.


The NNTP test failure looks like this:

==
ERROR: setUpClass (test.test_nntplib.NetworkedNNTP_SSLTests)
--
Traceback (most recent call last):
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_nntplib.py",
 line 295, in setUpClass
cls.server = cls.NNTP_CLASS(cls.NNTP_HOST, timeout=TIMEOUT,
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/nntplib.py", 
line 1077, in __init__
self.sock = _encrypt_on(self.sock, ssl_context, host)
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/nntplib.py", 
line 292, in _encrypt_on
return context.wrap_socket(sock, server_hostname=hostname)
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 
405, in wrap_socket
return self.sslsocket_class._create(
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 
853, in _create
self.do_handshake()
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 
1117, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:1055)



The HTTP test failure looks like this:

==
ERROR: test_networked_good_cert (test.test_httplib.HTTPSTest)
--
Traceback (most recent call last):
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_httplib.py",
 line 1629, in test_networked_good_cert
h.request('GET', '/')
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py",
 line 1229, in request
self._send_request(method, url, body, headers, encode_chunked)
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py",
 line 1275, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py",
 line 1224, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py",
 line 1016, in _send_output
self.send(msg)
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py",
 line 956, in send
self.connect()
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py",
 line 1391, in connect
self.sock = self._context.wrap_socket(self.sock,
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 
405, in wrap_socket
return self.sslsocket_class._create(
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 
853, in _create
self.do_handshake()
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 
1117, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate 
verify failed: EE certificate key too weak (_ssl.c:1055)

--

___
Python tracker 

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

[issue36104] test_httplib and test_nntplib fail on ARMv7 Ubuntu

[STINNER Victor]

Change by STINNER Victor :


--
resolution:  -> duplicate
superseder:  -> test_httplib test_nntplib test_ssl fail on ARMv7 Debian buster 
bot (OpenSSL 1.1.1a)

___
Python tracker 

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

[issue36106] resolve sinpi() name clash with libm

[SilentGhost]

Change by SilentGhost :


--
nosy: +mark.dickinson
stage:  -> patch review

___
Python tracker 

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

[issue36106] resolve sinpi() name clash with libm

[Dmitrii Pasechnik]

New submission from Dmitrii Pasechnik :

The standard math library (libm) may follow IEEE-754 recommendation to
include an implementation of sinPi(), i.e. sinPi(x):=sin(pi*x).
And this triggers a name clash, found by FreeBSD developer
Steve Kargl, who worken on putting sinpi into libm used on FreeBSD
(it has to be named "sinpi", not "sinPi", cf. e.g.
https://en.cppreference.com/w/c/experimental/fpext4)

--
components: Extension Modules
messages: 336519
nosy: dimpase
priority: normal
pull_requests: 12059
severity: normal
status: open
title: resolve sinpi() name clash with libm
type: compile error
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

[issue36104] test_httplib and test_nntplib fail on ARMv7 Ubuntu

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +pablogsal, vstinner

___
Python tracker 

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

[issue36104] test_httplib and test_nntplib fail on ARMv7 Ubuntu

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Related to issue35925 ?

--
nosy: +xtreak

___
Python tracker 

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

[issue32129] Icon on macOS

[Kevin Walzer]

Kevin Walzer  added the comment:

Is there any reason not to commit the patch I submitted to address this 
issue?As an alternative I can submit a high-res PNG that can be used, and will 
submit a different patch to incorporate it, which would work from either the 
standard app bundle or the command line. Either way, there is no reason to 
continue to have this visual artifact in IDLE on the Mac.

--

___
Python tracker 

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

[issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win)

[STINNER Victor]

STINNER Victor  added the comment:

> Yes, it's deliberate, see PR-12016.

"I decided not to document `shutil.COPY_BUFSIZE` because I consider it a corner 
case."

Ok. I have no opinion on that, I just wanted to ask the question :-)

--

___
Python tracker 

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

[issue35810] Object Initialization does not incref Heap-allocated Types

[Eddie Elizondo]

Eddie Elizondo  added the comment:

> could we just remove the whole concept of heap allocated types?

I do have plans to start migrating more and more CPython modules to use heap 
allocated types. For example I have posixmodule up in the queue (PR10854) and a 
local change with all of _io migrated. I'm only blocked by having correct 
refcnts in these types.

So, yes, let's work towards migrating all the static types to heap-allocated 
types! I have the time and energy to embark on this huge task so you'll see 
more and more of these PRs from me in the future. :)

> First let's make heap types more usable and bug-free, and then it will be 
> easier 

In that way, I agree with Petr, let's start by fixing the core issues first.



With all of that in mind, it seems to me that we are all agree on the current 
solution. Let's try to push this forward and merge the PR.

--

___
Python tracker 

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

[issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win)

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Yes, it's deliberate, see PR-12016.

--

___
Python tracker 

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

[issue36105] Windows: use GetNativeSystemInfo instead of GetSystemInfo

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I guess it depends on what the information is used for. From a quick glance at 
the code I'd say that the current usage is correct, and that 
GetNativeSystemInfo could be used when reporting about the currently running 
system (for example by functions in the platform module).

--
nosy: +ronaldoussoren

___
Python tracker 

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

[issue36105] Windows: use GetNativeSystemInfo instead of GetSystemInfo

[Giampaolo Rodola']

New submission from Giampaolo Rodola' :

This is what MS doc says about GetSystemInfo:
https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsysteminfo

<>

$ grep -r GetSystemInfo
Modules/_ctypes/malloc_closure.c:GetSystemInfo();
Modules/mmapmodule.c:GetSystemInfo();
Modules/mmapmodule.c:GetSystemInfo();
Modules/posixmodule.c:GetSystemInfo();

--
components: Windows
messages: 336512
nosy: eryksun, giampaolo.rodola, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows: use GetNativeSystemInfo instead of GetSystemInfo
versions: Python 2.7, 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

[issue36104] test_httplib and test_nntplib fail on ARMv7 Ubuntu

[Łukasz Langa]

New submission from Łukasz Langa :

The ARMv7 Ubuntu buildbot is consistently failing since build #2160:
https://buildbot.python.org/all/#/builders/106/builds/2160


This looks like a testing environment issue to me rather than a code issue. But 
I'd like it fixed either way before we get to 3.8.0 beta1 since this is a 
stable builder. Greg, you can ask Inadasan about whether his dict/OrderedDict 
changes might have any effect on this failure:
https://github.com/python/cpython/commit/c95404ff65dab1469dcd1dfec58ba54a8e7e7b3a

That was the only relevant change I observed between the working and the broken 
build.


The NNTP test failure looks like this:

==
ERROR: setUpClass (test.test_nntplib.NetworkedNNTP_SSLTests)
--
Traceback (most recent call last):
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_nntplib.py",
 line 295, in setUpClass
cls.server = cls.NNTP_CLASS(cls.NNTP_HOST, timeout=TIMEOUT,
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/nntplib.py", 
line 1077, in __init__
self.sock = _encrypt_on(self.sock, ssl_context, host)
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/nntplib.py", 
line 292, in _encrypt_on
return context.wrap_socket(sock, server_hostname=hostname)
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 
405, in wrap_socket
return self.sslsocket_class._create(
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 
853, in _create
self.do_handshake()
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 
1117, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:1055)



The HTTP test failure looks like this:

==
ERROR: test_networked_good_cert (test.test_httplib.HTTPSTest)
--
Traceback (most recent call last):
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_httplib.py",
 line 1629, in test_networked_good_cert
h.request('GET', '/')
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py",
 line 1229, in request
self._send_request(method, url, body, headers, encode_chunked)
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py",
 line 1275, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py",
 line 1224, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py",
 line 1016, in _send_output
self.send(msg)
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py",
 line 956, in send
self.connect()
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/http/client.py",
 line 1391, in connect
self.sock = self._context.wrap_socket(self.sock,
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 
405, in wrap_socket
return self.sslsocket_class._create(
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 
853, in _create
self.do_handshake()
  File 
"/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/ssl.py", line 
1117, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate 
verify failed: EE certificate key too weak (_ssl.c:1055)

--
assignee: gregory.p.smith
messages: 336511
nosy: gregory.p.smith, inada.naoki, lukasz.langa, zach.ware
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: test_httplib and test_nntplib fail on ARMv7 Ubuntu
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h

[Nathaniel Smith]

Nathaniel Smith  added the comment:

The cffi issue is: 
https://bitbucket.org/cffi/cffi/issues/403/build-fails-on-38-dev-pyinterpreterstate

Armin already went ahead and committed the change to make cffi include 
internal/pycore_pystate.h. I guess this might not be the ideal final outcome 
though :-). Without some fix though it's very difficult to test things on 
3.8-dev, because cffi shows up in the dependency stacks of *large* portions of 
the ecosystem.

--

___
Python tracker 

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

[issue36093] UnicodeEncodeError raise from smtplib.verify() method

[STINNER Victor]

STINNER Victor  added the comment:

Barry: would you mind to have a look at this issue? It seems like smtplib 
encodes Unicode commands to ASCII, whereas verify() argument (SMTP "VRFY" 
command) is an hostname and hostname can be non-ASCII ("punycode" encoding, RFC 
3492).

--
nosy: +barry

___
Python tracker 

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

[issue34656] [CVE-2018-20406] memory exhaustion in Modules/_pickle.c:1393

[STINNER Victor]

STINNER Victor  added the comment:

As I wrote in my previous comment, I don't think that Python 2.7 is affected by 
this issue.

--
components: +Library (Lib) -ctypes
versions: +Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 -Python 
2.7

___
Python tracker 

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

[issue10308] Modules/getpath.c bugs

[STINNER Victor]

STINNER Victor  added the comment:

I reviewed getpath.diff:

diff -pru Python-2.7/Modules/getpath.c Python-2.7/Modules/getpath.c
--- Python-2.7/Modules/getpath.c
+++ Python-2.7/Modules/getpath.c
@@ -218,7 +218,7 @@ joinpath(char *buffer, char *stuff)
 if (n > MAXPATHLEN)
 Py_FatalError("buffer overflow in getpath.c's joinpath()");
 k = strlen(stuff);
-if (n + k > MAXPATHLEN)
+if (k > MAXPATHLEN - n)
 k = MAXPATHLEN - n;
 strncpy(buffer+n, stuff, k);
 buffer[n+k] = '\0';

As I explained in a previous comment, this change is useless: "n+k" cannot 
overflow.


@@ -229,10 +229,9 @@ joinpath(char *buffer, char *stuff)
 static void
 copy_absolute(char *path, char *p)
 {
-if (p[0] == SEP)
+if (p[0] == SEP || getcwd(path, MAXPATHLEN) == NULL)
 strcpy(path, p);
 else {
-getcwd(path, MAXPATHLEN);
 if (p[0] == '.' && p[1] == SEP)
 p += 2;
 joinpath(path, p);

The code changed in the meanwhile (in the master branch, in 3.7 maybe, I don't 
recall), getcwd() error is now checked in copy_absolute():

if (!_Py_wgetcwd(path, pathlen)) {
/* unable to get the current directory */
wcscpy(path, p);
return;
}

diff -pru Python-3.2a3/Modules/getpath.c Python-3.2a3/Modules/getpath.c
--- Python-3.2a3/Modules/getpath.c
+++ Python-3.2a3/Modules/getpath.c
@@ -351,18 +351,18 @@ search_for_exec_prefix(wchar_t *argv0_pa
 else {
 char buf[MAXPATHLEN+1];
 PyObject *decoded;
-wchar_t rel_builddir_path[MAXPATHLEN+1];
-size_t n;
 n = fread(buf, 1, MAXPATHLEN, f);
 buf[n] = '\0';
 fclose(f);
 decoded = PyUnicode_DecodeUTF8(buf, n, "surrogateescape");
 if (decoded != NULL) {
-n = PyUnicode_AsWideChar((PyUnicodeObject*)decoded,
+wchar_t rel_builddir_path[MAXPATHLEN+1];
+Py_ssize_t k;
+k = PyUnicode_AsWideChar((PyUnicodeObject*)decoded,
  rel_builddir_path, MAXPATHLEN);
 Py_DECREF(decoded);
-if (n >= 0) {
-rel_builddir_path[n] = L'\0';
+if (k >= 0) {
+rel_builddir_path[k] = L'\0';
 wcscpy(exec_prefix, argv0_path);
 joinpath(exec_prefix, rel_builddir_path);
 return -1;

Again, the code changed in the meanwhile:

wchar_t *rel_builddir_path;
...
rel_builddir_path = _Py_DecodeUTF8_surrogateescape(buf, n);
if (rel_builddir_path) {

There is a new _Py_DecodeUTF8_surrogateescape() function which returns directly 
wchar_t* strings.

I close the issue.

--

Modules/getpath.c should be rewritten without global MAXPATHLEN limit. I 
rewrote the code to avoid global variables and pass buffer lengths in some 
functions. It's better but not perfect yet :-))

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

[issue35886] Move PyInterpreterState into Include/internal/pycore_pystate.h

[STINNER Victor]

STINNER Victor  added the comment:

> This broke cffi:

Well, that's not a surprise :-) It's a deliberate backward incompatible change.

But that's where I suggested to test "popular C extensions" with a C API change 
before merging it. It's ok if issues are discovered later, but the author of 
backward incompatible C API changes should collaborate with popular C extension 
maintainers to help to deal with these issues.

Can someone report the issue to cffi and post back the url to the bug here?

--

___
Python tracker 

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

[issue36103] Increase shutil.COPY_BUFSIZE

[Inada Naoki]

New submission from Inada Naoki :

shutil.COPY_BUFSIZE is 16KiB on non-Windows platform.
But it seems bit small for performance.

As this article[1], 128KiB is the best performance on common system.
[1]: https://eklitzke.org/efficient-file-copying-on-linux

Another resource: EBS document [2] uses 128KiB I/O for throughput.
[2]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html

Can we increase shutil.COPY_BUFSIZE to 128KiB by default?

Note that 128KiB is small enough when comparing with Windows (1MB by default).

--
components: +Library (Lib)
title: Increase -> Increase shutil.COPY_BUFSIZE
type:  -> resource usage
versions: +Python 3.8

___
Python tracker 

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

[issue36103] Increase

[Inada Naoki]

Change by Inada Naoki :


--
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Increase

___
Python tracker 

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

[issue29659] Expose the `length` arg from shutil.copyfileobj for public use

[Inada Naoki]

Inada Naoki  added the comment:

bpo-33671 fixed this.

--
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.7

___
Python tracker 

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

[issue36102] TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

New submission from STINNER Victor :

TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x:

* The tests should be skipped on this buildbot worker
* Or the feature should be fixed on FreeBSD

https://buildbot.python.org/all/#/builders/168/builds/617

Example:

ERROR: test_shared_memory_ShareableList_basics 
(test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory)
--
Traceback (most recent call last):
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/_test_multiprocessing.py",
 line 3770, in test_shared_memory_ShareableList_basics
sl = shared_memory.ShareableList(
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/multiprocessing/shared_memory.py",
 line 305, in __init__
self.shm = SharedMemory(name, create=True, size=requested_size)
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/multiprocessing/shared_memory.py",
 line 88, in __init__
self._fd = _posixshmem.shm_open(
OSError: [Errno 22] Invalid argument: 'psm_f66c2bc7b9'

Failures:

ERROR: test_shared_memory_ShareableList_basics 
(test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_ShareableList_pickling 
(test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_SharedMemoryManager_basics 
(test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_across_processes 
(test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_basics 
(test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory)

ERROR: test_shared_memory_ShareableList_basics 
(test.test_multiprocessing_fork.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_ShareableList_pickling 
(test.test_multiprocessing_fork.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_SharedMemoryManager_basics 
(test.test_multiprocessing_fork.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_across_processes 
(test.test_multiprocessing_fork.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_basics 
(test.test_multiprocessing_fork.WithProcessesTestSharedMemory)

ERROR: test_shared_memory_ShareableList_basics 
(test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_ShareableList_pickling 
(test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_SharedMemoryManager_basics 
(test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_across_processes 
(test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_basics 
(test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)

--
components: Tests
messages: 336503
nosy: davin, giampaolo.rodola, pitrou, vstinner
priority: normal
severity: normal
status: open
title: TestSharedMemory fails on AMD64 FreeBSD CURRENT Shared 3.x
versions: Python 3.8

___
Python tracker 

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

[issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win)

[STINNER Victor]

STINNER Victor  added the comment:

shutil.COPY_BUFSIZE isn't documented. Is it a deliberate choice?
https://docs.python.org/dev/library/shutil.html

--

___
Python tracker 

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