[issue40280] Consider supporting emscripten/webassembly as a build target
Change by Ethan Smith : -- pull_requests: +28702 pull_request: https://github.com/python/cpython/pull/30495 ___ Python tracker <https://bugs.python.org/issue40280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40280] Consider supporting emscripten/webassembly as a build target
Change by Ethan Smith : -- pull_requests: +28700 pull_request: https://github.com/python/cpython/pull/30494 ___ Python tracker <https://bugs.python.org/issue40280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40280] Consider supporting emscripten/webassembly as a build target
Change by Ethan Smith : -- pull_requests: +28116 pull_request: https://github.com/python/cpython/pull/29892 ___ Python tracker <https://bugs.python.org/issue40280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45940] add_multiarch_paths breaks cross compilation to Emscripten
Ethan Smith added the comment: Unfortunately, I am using latest master :/ I was able to reproduce this issue in your wasm docker container mounting CPython master into it, if you want to play with this. -- ___ Python tracker <https://bugs.python.org/issue45940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45940] add_multiarch_paths breaks cross compilation to Emscripten
Ethan Smith added the comment: Bah, it actually seems the real issue is that my configure is choosing the host_cpu as x86-64 for some reason. I'm still trying to figure out why though. -- ___ Python tracker <https://bugs.python.org/issue45940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45940] add_multiarch_paths breaks cross compilation to Emscripten
Change by Ethan Smith : -- keywords: +patch pull_requests: +28094 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29868 ___ Python tracker <https://bugs.python.org/issue45940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45940] add_multiarch_paths breaks cross compilation to Emscripten
New submission from Ethan Smith : When I cross compile on an Ubuntu system, the "PyBuildExt.add_multiarch_paths" method seems to add system includes, even when cross compiling for Emscripten. Adding the system includes breaks Emscripten and causes several extensions to fail to build. I have a patch which fixes this that I will be submitting shortly to Github. -- components: Build messages: 407387 nosy: christian.heimes, ethan smith priority: normal severity: normal status: open title: add_multiarch_paths breaks cross compilation to Emscripten type: compile error versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45909] sysconfig --generate-posix-vars creates wrong file when cross compiling
Change by Ethan Smith : -- nosy: +ethan smith ___ Python tracker <https://bugs.python.org/issue45909> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24234] Should we define complex.__complex__ and bytes.__bytes__?
Ethan Smith added the comment: While I don't think it is nonsense, I do think it would be quite useful to add these. I just submitted PRs to typeshed and numpy adding complex to unions that already had SupportsComplex, because of the lack of __complex__. I'd be happy to work on a PR for this if it would be accepted. -- nosy: +ethan smith ___ Python tracker <https://bugs.python.org/issue24234> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40280] Consider supporting emscripten/webassembly as a build target
Ethan Smith added the comment: I think the first thing we should do is figure out whether we want to support Emscripten or WASI (or both). Emscripten uses Javascript polyfills for some syscalls, while WASI makes direct calls the VM it is running in. They both can use WebAssembly for executing the code. This means Emscripten has wider API support, but WASI is lighter weight in many ways. I think starting with patches to support Emscripten would be best, as it is easier to target, then add support for WASI later. I think supporting WASI has a lot of value, because it can be run deterministically, which would be great for data science (Imagine a jupyter notebook that runs the same everywhere!) One issue with WASI, and may be an issue with Emscripten, is threads. In 3.8 (or 3.9?) threadless builds were removed. However, WebAssembly's threading API is not really meant to emulate pthread, and SharedArrayBuffer, the primitive it is built on, is disabled in several browsers due to Spectre concerns. Would patches to re-add a threadless build mode be accepted? -- nosy: +ethan smith ___ Python tracker <https://bugs.python.org/issue40280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43782] Failure to build from source on ppc64le on ubuntu xenial
Change by Ethan Smith : -- nosy: +ethan smith ___ Python tracker <https://bugs.python.org/issue43782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33315] Allow queue.Queue to be used in type annotations
Ethan Smith added the comment: This was done in https://github.com/python/cpython/pull/19423 The implementation is as Raymond suggests: https://github.com/python/cpython/blame/5aad027db9618f22f6fa2274e05dd50f928d2ed7/Lib/queue.py#L220 On Sat, Jun 13, 2020 at 8:58 PM Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > Can this can now be handled with "__class_getitem__ = > classmethod(GenericAlias)"? > > -- > type: -> behavior > versions: +Python 3.10 -Python 3.5, Python 3.6, Python 3.7, Python 3.8 > > ___ > Python tracker > <https://bugs.python.org/issue33315> > ___ > -- ___ Python tracker <https://bugs.python.org/issue33315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)
Ethan Smith added the comment: I went through the list I generated and it seems that the ipaddress._BaseNetwork and mmap.mmap cases are the only one I saw that shouldn't be generic. I will submit a PR to revert those. The only item left after that which I know of is _lru_cache_wrapper. On Tue, Apr 14, 2020 at 4:14 PM Guido van Rossum wrote: > > Guido van Rossum added the comment: > > > New changeset d01628e411752ee6849f862cae66a1c69fe512b7 by Ethan Smith in > branch 'master': > bpo-39481: PEP 585 for dataclasses, mailbox, contextvars (GH-19425) > > https://github.com/python/cpython/commit/d01628e411752ee6849f862cae66a1c69fe512b7 > > > -- > > ___ > Python tracker > <https://bugs.python.org/issue39481> > ___ > -- ___ Python tracker <https://bugs.python.org/issue39481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)
Ethan Smith added the comment: Hm, yeah it appears my methodology was too loose. Thank you for catching these. I will go through and test the rest (if you haven't yet) later today and make a PR to revert anything that needs it. Thanks! (and sorry) On Mon, Apr 13, 2020 at 2:12 AM Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > I tested the following example: > > import ipaddress, mmap > > x: ipaddress.IPv4Network[int] > y: mmap.mmap[int] > > MyPy produces errors: > > t.py:4: error: "IPv4Network" expects no type arguments, but 1 given > t.py:5: error: "mmap" expects no type arguments, but 1 given > > This is because mmap and IPv4Network are not generic types in typeshed. > _BaseNetwork and _mmap are generic types, but IPv4Network and mmap are > normal classes. The former are implementation detail of typeshed. _mmap > does not exist in the stdlib, and _BaseNetwork in typeshed and the stdlib > are different things. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue39481> > ___ > -- ___ Python tracker <https://bugs.python.org/issue39481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)
Change by Ethan Smith : -- pull_requests: +18848 pull_request: https://github.com/python/cpython/pull/19497 ___ Python tracker <https://bugs.python.org/issue39481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)
Change by Ethan Smith : -- pull_requests: +18785 pull_request: https://github.com/python/cpython/pull/19427 ___ Python tracker <https://bugs.python.org/issue39481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)
Change by Ethan Smith : -- pull_requests: +18782 pull_request: https://github.com/python/cpython/pull/19425 ___ Python tracker <https://bugs.python.org/issue39481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)
Change by Ethan Smith : -- pull_requests: +18780 pull_request: https://github.com/python/cpython/pull/19422 ___ Python tracker <https://bugs.python.org/issue39481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)
Change by Ethan Smith : -- pull_requests: +18779 pull_request: https://github.com/python/cpython/pull/19421 ___ Python tracker <https://bugs.python.org/issue39481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)
Change by Ethan Smith : -- pull_requests: +18777 pull_request: https://github.com/python/cpython/pull/19417 ___ Python tracker <https://bugs.python.org/issue39481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)
Change by Ethan Smith : -- nosy: +ethan smith ___ Python tracker <https://bugs.python.org/issue39481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39747] test_os debug assertion failure
New submission from Ethan Smith : With CPython master branch and build.bat -e -p x64, if I run test_os I get the following (in a messagebox transcribed here for ease of consumption). Sorry if I am missing something. This means I am unable to run test_os to completion. I am on Windows 10.0.19559.1000 x64 with CL 19.24.28315/Visual Studio 16.4.3 For test_bad_fd: - Debug Assertion Failed! Program: C:\Users\ethanhs\cpython\PCbuild\amd64\python_d.exe File: minkernel\crts\ucrt\src\appcrt\lowio\isatty.cpp Line: 17 Expression: (fh >= 0 && (unsigned)fh < (unsigned)_nhandle) For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts. (Press Retry to debug the application) --- -- components: Windows messages: 362624 nosy: Ethan Smith, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: test_os debug assertion failure type: crash versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35975] Put back the ability to parse files where async/await aren't keywords
Change by Ethan Smith : -- nosy: +Ethan Smith ___ Python tracker <https://bugs.python.org/issue35975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35766] Merge typed_ast back into CPython
Change by Ethan Smith : -- nosy: +Ethan Smith ___ Python tracker <https://bugs.python.org/issue35766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35808] Let's retire pgen
Change by Ethan Smith : -- nosy: +Ethan Smith ___ Python tracker <https://bugs.python.org/issue35808> ___ ___ 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
Change by Ethan Smith : -- nosy: +Ethan Smith ___ Python tracker <https://bugs.python.org/issue34977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33211] lineno and col_offset are wrong on function definitions with decorators
Ethan Smith added the comment: This has been fixed, so the issue can be closed I believe. FWIW I didn't see anything useful to salvage from my PR that wasn't already tested by your tests Serhiy. -- pull_requests: +9923 ___ Python tracker <https://bugs.python.org/issue33211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33351] Support compiling with clang-cl on Windows
Ethan Smith added the comment: I just updated the PR with some more information after trying this on every VS project. It seems that clang-cl still fails on some projects/tests, but I don't think that is a big problem. I was mostly interested in getting Python core to build with clang-cl, which it does (and passes all test with it). I will keep iterating on this as time allows. I also think it would be helpful to have an idea of the expectation for review/merge. -- ___ Python tracker <https://bugs.python.org/issue33351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33946] os.symlink on Windows should use the new non-admin flag
New submission from Ethan Smith : In the creators update CreateSymbolicLink added a dwflag SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE, which will allow any user to create a symlink (not only an admin). I think we should detect and try to use this flag if possible. I also think it would be nice to suggest turning on developer mode if the windows version is at or newer than the creators update. This should probably happen after https://bugs.python.org/issue28113 -- messages: 320288 nosy: Ethan Smith, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: os.symlink on Windows should use the new non-admin flag ___ Python tracker <https://bugs.python.org/issue33946> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Ethan Smith added the comment: I am in favor of symlinks no longer being able to execute arbitrary code, however, I do think having them add to the path cannot be killed in two releases. Here is why: 1. Windows support for symlinks is still not automatic. In the creators update of Windows 10 (released March 2017), CreateSymbolicLink added a dwflag SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE. This requires the user to be in developer mode to work. CPython currently doesn't use this flag. (I will open an issue to add that in a moment). I worry that giving people little time to update will be troublesome. 2. All editable installs everywhere (AFAIK) and setuptools eggs (still somewhat common) use easy-install.pth to list where they are. I think breaking editable installs is a bad idea, as there is no clear solution for this. Also setuptools has a fair amount of work to do before it can replace egg installs. So I think removing adding to the path will require much more thought and break a lot more code than removing arbitrary code execution. -- nosy: +Ethan Smith ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC
Ethan Smith added the comment: When working on clang-cl support, I was advised here https://reviews.llvm.org/D47672#1131325 that we may be using hardware lock elision incorrectly. Copying from there: > I also spoke to Andi Kleen here at Intel to make sure I got these inline > assembly versions correct. And he's not sure CPython should be using these > the way it is. It looks like they try to use the HLE versions anytime the > memory order is acquire/release. But HLE isn't suitable for every > acquire/release. I believe if we just use the simple _InterlockedExchange/_InterlockedCompareExchange intrinsics, things should be safer. ------ nosy: +Ethan Smith ___ Python tracker <https://bugs.python.org/issue30747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33351] Support compiling with clang-cl on Windows
Change by Ethan Smith : -- pull_requests: +7292 ___ Python tracker <https://bugs.python.org/issue33351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33351] Support compiling with clang-cl on Windows
Ethan Smith added the comment: I sent my patches to clang-cl upstream [1]. It seems they want to implement Hardware Lock Elision (which is used by some MSVC compiler intrinsics in pyatomic.h) before implementing the needed intrinsics. I have found temporary replacements that do not elide locks, but have effectively the same functional purpose as those intrinsics, so I should have a full PR for CPython ready soon. [1] https://reviews.llvm.org/D47672 -- ___ Python tracker <https://bugs.python.org/issue33351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32380] functools.singledispatch interacts poorly with methods
Ethan Smith added the comment: This was fixed, so I think it can be closed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue32380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33351] Support compiling with clang-cl on Windows
Ethan Smith <et...@ethanhs.me> added the comment: After wrangling with some missing compiler intrinsics, I've been able to get CPython to build with an almost vanilla clang-cl! I plan on upstreaming the patches to the LLVM project once I clean them up a bit. After that I will clean up the CPython patches and send a PR. I also ran performance with master built on MSVC compared to my branch on clang-cl with computed-goto enabled (I wasn't sure if there are other things that may be possible to turn on, computed goto seemed an obvious win). The results are decent, but some things, like json loads, are much slower (not sure why that is). The full report: msvc.json = Performance version: 0.6.1 Report on Windows-10-10.0.17672-SP0 Number of logical CPUs: 12 Start date: 2018-05-24 03:40:09.082701 End date: 2018-05-24 04:08:57.993717 clang2goto.json === Performance version: 0.6.1 Report on Windows-10-10.0.17672-SP0 Number of logical CPUs: 12 Start date: 2018-05-24 04:29:01.214005 End date: 2018-05-24 04:57:08.774299 ### 2to3 ### Mean +- std dev: 675 ms +- 31 ms -> 655 ms +- 32 ms: 1.03x faster Significant (t=3.55) ### chameleon ### Mean +- std dev: 19.5 ms +- 0.5 ms -> 18.1 ms +- 0.7 ms: 1.08x faster Significant (t=13.19) ### chaos ### Mean +- std dev: 230 ms +- 6 ms -> 209 ms +- 8 ms: 1.10x faster Significant (t=16.39) ### crypto_pyaes ### Mean +- std dev: 212 ms +- 8 ms -> 197 ms +- 8 ms: 1.07x faster Significant (t=9.72) ### deltablue ### Mean +- std dev: 15.2 ms +- 0.6 ms -> 14.2 ms +- 0.5 ms: 1.07x faster Significant (t=10.23) ### django_template ### Mean +- std dev: 222 ms +- 9 ms -> 210 ms +- 8 ms: 1.06x faster Significant (t=8.10) ### dulwich_log ### Mean +- std dev: 235 ms +- 13 ms -> 230 ms +- 12 ms: 1.02x faster Significant (t=2.18) ### fannkuch ### Mean +- std dev: 905 ms +- 11 ms -> 802 ms +- 15 ms: 1.13x faster Significant (t=42.95) ### float ### Mean +- std dev: 226 ms +- 9 ms -> 197 ms +- 8 ms: 1.15x faster Significant (t=18.71) ### go ### Mean +- std dev: 485 ms +- 10 ms -> 445 ms +- 8 ms: 1.09x faster Significant (t=24.60) ### hexiom ### Mean +- std dev: 19.9 ms +- 0.9 ms -> 18.3 ms +- 0.8 ms: 1.08x faster Significant (t=9.51) ### html5lib ### Mean +- std dev: 156 ms +- 9 ms -> 149 ms +- 9 ms: 1.05x faster Significant (t=4.31) ### json_dumps ### Mean +- std dev: 23.4 ms +- 1.2 ms -> 23.0 ms +- 1.1 ms: 1.02x faster Not significant ### json_loads ### Mean +- std dev: 49.3 us +- 2.2 us -> 93.2 us +- 8.7 us: 1.89x slower Significant (t=-37.79) ### logging_format ### Mean +- std dev: 25.3 us +- 1.3 us -> 23.4 us +- 1.2 us: 1.08x faster Significant (t=8.48) ### logging_silent ### Mean +- std dev: 368 ns +- 14 ns -> 340 ns +- 21 ns: 1.08x faster Significant (t=8.69) ### logging_simple ### Mean +- std dev: 23.1 us +- 1.4 us -> 20.6 us +- 0.9 us: 1.12x faster Significant (t=11.66) ### mako ### Mean +- std dev: 36.7 ms +- 1.8 ms -> 36.0 ms +- 1.7 ms: 1.02x faster Not significant ### meteor_contest ### Mean +- std dev: 189 ms +- 9 ms -> 175 ms +- 9 ms: 1.08x faster Significant (t=9.09) ### nbody ### Mean +- std dev: 274 ms +- 12 ms -> 222 ms +- 8 ms: 1.24x faster Significant (t=28.22) ### nqueens ### Mean +- std dev: 198 ms +- 8 ms -> 174 ms +- 8 ms: 1.14x faster Significant (t=16.67) ### pathlib ### Mean +- std dev: 343 ms +- 19 ms -> 338 ms +- 18 ms: 1.02x faster Not significant ### pickle ### Mean +- std dev: 20.9 us +- 0.8 us -> 19.9 us +- 0.5 us: 1.05x faster Significant (t=8.91) ### pickle_dict ### Mean +- std dev: 50.0 us +- 1.9 us -> 51.2 us +- 3.0 us: 1.02x slower Significant (t=-2.62) ### pickle_list ### Mean +- std dev: 7.61 us +- 0.32 us -> 7.06 us +- 0.36 us: 1.08x faster Significant (t=8.92) ### pickle_pure_python ### Mean +- std dev: 964 us +- 52 us -> 879 us +- 43 us: 1.10x faster Significant (t=9.72) ### pidigits ### Mean +- std dev: 257 ms +- 5 ms -> 254 ms +- 9 ms: 1.01x faster Not significant ### python_startup ### Mean +- std dev: 69.6 ms +- 8.3 ms -> 69.5 ms +- 6.3 ms: 1.00x faster Not significant ### python_startup_no_site ### Mean +- std dev: 57.7 ms +- 6.6 ms -> 58.2 ms +- 6.0 ms: 1.01x slower Not significant ### raytrace ### Mean +- std dev: 1.00 sec +- 0.02 sec -> 0.94 sec +- 0.02 sec: 1.07x faster Significant (t=21.49) ### regex_compile ### Mean +- std dev: 335 ms +- 5 ms -> 306 ms +- 10 ms: 1.10x faster Significant (t=20.75) ### regex_dna ### Mean +- std dev: 237 ms +- 7 ms -> 266 ms +- 7 ms: 1.13x slower Significant (t=-23.71) ### regex_effbot ### Mean +- std dev: 4.42 ms +- 0.17 ms -> 4.82 ms +- 0.20 ms: 1.09x slower Significant (t=-12.07) ### regex_v8 ### Mean +- std dev: 45.2 ms +- 15.5 ms -> 39.7 ms +- 2.8 ms: 1.14x faster Significant (t=2.74) ### richards ### Mean +- std dev: 152 ms +- 8 ms -> 142 ms +- 9 ms: 1.07x faster Significant (t=6.19) ### scimark_fft ### Mean +- std dev: 665 ms +- 12
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Change by Ethan Smith <et...@ethanhs.me>: -- nosy: +Ethan Smith ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33351] Support compiling with clang-cl on Windows
Change by Ethan Smith <et...@ethanhs.me>: -- keywords: +patch pull_requests: +6448 stage: test needed -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32942] Regression: test_script_helper fails
Ethan Smith <et...@ethanhs.me> added the comment: For reference this is happening with a clean checkout and build of master for me, which seems like it shouldn't be the case... -- nosy: +Ethan Smith ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33351] Support compiling with clang-cl on Windows
Ethan Smith <et...@ethanhs.me> added the comment: > Feel free to start creating patches so we can get an idea of what the changes > would look like. Hopefully it's not that dramatic. Okay, will do. I have a few smaller patches to start with. Clang-cl tries to be as compatible as possible with cl, so I don't expect drastic changes. I'm currently trying to figure out an include issue with timeval, but so far the patches have been few and small. > Be very careful making performance claims without benchmarks to back it up, > and ideally against multiple sets of hardware (MSVC is designed and tested to > perform well across a range of processors, often by engineers who work for > the manufacturer - intuition would suggest that an open source compiler is > probably not 30% better all the time). Don't focus on the number right now, > but do try to collect the justification before you expect or encourage others > to do the work. I did not mean to say it would make Python 30% faster in all cases, I meant "up to 30% faster". This number is based on benchmarks of CPython with and without computed goto, and my own experiments of benchmarks comparing CPython in the WSL, and native Windows CPython releases on x86_64. But your point is well taken, and I will of course benchmark Python compiled with clang-cl once I have a complete working version. > Since the ABI is compatible, there should be no problem enabling extensions > to be built using this compiler (assuming someone is willing to become a > distutils maintainer, as there are currently none). You don't need to ask > here to create a third-party library that enables this. When you say "someone to become a distutils maintainer" you mean for clang-cl specifically? If that is the case, I'm happy to add support and commit to continuing to work on clang-cl support in distutils, as I expect to use it a fair amount. > I haven't heard any complaints about access to the compilers being an issue > recently, so the only reasons to switch the interpreter itself would be > source compatibility (essentially, the clang clib is better than our custom > Win32 code) or performance. But we need a positive reason to switch support, > not just the ability. I agree there should be a good reason to move away from the MSVC compiler. The decision to move can be re-evaluated when there is a good argument to warrant it. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33351] Support compiling with clang-cl on Windows
Ethan Smith <et...@ethanhs.me> added the comment: >* Are you suggesting that CPython's build system move away from MSVC as the >platform compiler for Windows? Not immediately, I don't think we should give up on the stability that currently exists with the cl based compilation. However, I think once CPython on clang-cl becomes stable, it will be compelling to switch. Clang-cl has the benefit of backwards compatibility with existing MSVC compiled c extensions, while generating a faster interpreter (perhaps 30% faster or more!). * Are you able to provide a machine to run buildbots on? I'm afraid not, I am just a college student :) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library
Change by Ethan Smith <et...@ethanhs.me>: -- nosy: +Ethan Smith ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue7> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33315] Allow queue.Queue to be used in type annotations
Change by Ethan Smith <et...@ethanhs.me>: -- nosy: +Ethan Smith ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33351] Support compiling with clang-cl on Windows
Ethan Smith <et...@ethanhs.me> added the comment: No, this is provided from llvm.org. You can find it as e.g. "Clang for Windows (64-bit)" here: http://releases.llvm.org/download.html#6.0.0 The Clang/C2 in Visual Studio is very different, and deprecated anyway. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33351] Support compiling with clang-cl on Windows
New submission from Ethan Smith <et...@ethanhs.me>: The clang folks have been hard at work making an ABI compatible backend to clang for Windows. Additionally they have created a cl compatible driver for clang, which can be used in lieu of cl itself. Clang-cl has been adopted to build Chrome on Windows http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html, so I think it is stable enough to be considered for use. Clang-cl has several advantages, such as computed goto support and many other optimizations which would make Python faster on Windows. I would be happy to start contributing patches to further this goal, I already have a couple of small patches. -- components: Build messages: 315721 nosy: Ethan Smith priority: normal severity: normal status: open title: Support compiling with clang-cl on Windows type: enhancement versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33211] lineno and col_offset are wrong on function definitions with decorators
Change by Ethan Smith <et...@ethanhs.me>: -- pull_requests: +6154 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33211] lineno and col_offset are wrong on function definitions with decorators
Ethan Smith <et...@ethanhs.me> added the comment: In my PR, I added `def_lineno` and `class_lineno` as fields in the ASDL, instead of attributes (since constructors cannot have attributes, only types can). This means they show up in `ast.dump` which is probably not the desired behavior, as it makes the dumped ast whitespace/line offset sensitive. Therefore I propose we change the line number of the nodes to be the one of the def/class statement. It seems based on [this commit](https://github.com/python/cpython/commit/09aaa88328a5083469b2682230c7f3c62942afab) that the change was done to fix inspect.getsource (so that it started on the first decorator), but I think it is much more logical for inspect to handle decorated items instead of having the ast lie. One other option could be for a modified ast to have a decorated node, which holds the decorator list, and the class/function. This has the possible downside of being a not-insignificant change to the ast. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33211] lineno and col_offset are wrong on function definitions with decorators
Change by Ethan Smith <et...@ethanhs.me>: -- keywords: +patch pull_requests: +6115 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33211] lineno and col_offset are wrong on function definitions with decorators
Ethan Smith <et...@ethanhs.me> added the comment: I have a branch with an implementation of my suggestion here: https://github.com/ethanhs/cpython/tree/decorlineno I was hoping to see if this was seen as a reasonable patch that might be accepted. Also, while I think it would be nice, I take it a patch for this would be unlikely to be backported, right? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33211] lineno and col_offset are wrong on function definitions with decorators
Ethan Smith <et...@ethanhs.me> added the comment: There is also a relevant mypy bug report https://github.com/python/mypy/issues/3871. This seems like a common problem for tools working on the AST. The relevant code seems to be https://github.com/python/cpython/blob/master/Python/ast.c#L1695. Would a possible solution be adding a decorated_lineno attribute to decorated ast nodes? -- nosy: +Ethan Smith ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32380] functools.singledispatch interacts poorly with methods
Change by Ethan Smith <et...@ethanhs.me>: -- versions: +Python 3.8 -Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32380] functools.singledispatch interacts poorly with methods
Change by Ethan Smith <et...@ethanhs.me>: -- pull_requests: +6024 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32380] functools.singledispatch interacts poorly with methods
Change by Ethan Smith <et...@ethanhs.me>: -- keywords: +patch pull_requests: +4873 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32380] functools.singledispatch interacts poorly with methods
New submission from Ethan Smith <et...@ethanhs.me>:
Consider the following:
from functools import singledispatch
class Dispatch:
@singledispatch
def foo(self, a):
return a
@foo.register(int)
def _(self, a):
return "int"
@foo.register(str)
def _(self, a):
return "str"
cls = Dispatch()
cls.foo(3) # 3
cls.foo('hm') # 'hm'
I find this quite unintuitive. Essentially, since singledispatch dispatches
based solely on a functions first argument, it is useless on methods unless one
wraps it and modifies how it uses the internal wrapper function. I believe this
should be relatively easy to fix with adding a check of inspect.ismethod and
then modifying the number of the checked argument where appropriate.
I'm happy to write a patch if this change is seen as a good idea.
--
components: Library (Lib)
messages: 308687
nosy: Ethan Smith
priority: normal
severity: normal
status: open
title: functools.singledispatch interacts poorly with methods
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32380>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31353] Implement PEP 553 - built-in debug()
Changes by Ethan Smith <et...@ethanhs.me>: -- nosy: +Ethan Smith ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28638] Optimize namedtuple creation
Changes by Ethan Smith <et...@ethanhs.me>: -- nosy: +Ethan Smith ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9949] os.path.realpath on Windows does not follow symbolic links
Changes by Ethan Smith <et...@ethanhs.me>: -- nosy: +Ethan Smith ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9949> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28903] Windows Embeddable Python exit not defined
New submission from Ethan Smith: Hearing about the RC1 today, I downloaded the x64 Windows embeddable zip. I opened a Command Prompt window and ran python.exe to try it out. I was quite surprised when I ran: >>>exit() Traceback (most recent call last): File "", line 1, in NameError: name 'exit' is not defined I read through the notes on the embedded Python releases, but I did not see anything that would lead me to believe that exit should not defined. I also downloaded the distribution for 3.5.2, and did not have the same issue, which leads me to believe this is unintended behavior. If this behavior is intended, I do apologize for raising this issue. OS: Windows 10 x64. -- components: Windows messages: 282697 nosy: Ethan Smith, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows Embeddable Python exit not defined type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26865] Meta-issue: support of the android platform
Changes by Ethan Smith <et...@ethanhs.me>: -- nosy: +Ethan Smith ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
