[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/issue40

[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/issue40

[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/issue40

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

[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/issue45

[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/issu

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

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

[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

[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

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

[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

[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

[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

[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/issue39

[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/issue39

[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/issue39

[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/issue39

[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/issue39

[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/issue39

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

[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

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

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

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

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

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

[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

[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

[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

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

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

[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

[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.or

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

[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> ___ __

[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.pyt

[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.or

[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

[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

[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> ___ __

[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> ___ __

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

[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

[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> ___ _

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

[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.pyt

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

[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

[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

[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> ___ _

[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.pyt

[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

[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> ___ __

[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> ___ __

[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> ___ __

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

[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> ___ __