[issue45459] Limited API support for Py_buffer

Change by rdb : -- nosy: +rdb ___ Python tracker <https://bugs.python.org/issue45459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue40280] Consider supporting emscripten/webassembly as a build target

Change by rdb : -- nosy: +rdb ___ Python tracker <https://bugs.python.org/issue40280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue37664] Update bundled pip and setuptools

rdb added the comment: @steve.dower It will be necessary to update to pip 19.2.3 for Python 3.8.0b4 shortly, as per: https://github.com/pypa/pip/pull/6874#issuecomment-50364 -- nosy: +rdb ___ Python tracker <https://bugs.python.org/issue37

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

rdb added the comment: > > From a cursory glance at the RFC3339 spec it looks like the only other > > change needed to fully support RFC3339 would be to support an arbitrary > > number of sub-second digits, whereas fromisoformat() currently requires > &g

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

rdb added the comment: I'm a fan of "be lenient in what you accept" but I can see your point in not causing confusion about what this method is meant to be used for. Because what I'm trying to use it for technically falls outside the intended use, I say it would make the

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

New submission from rdb : The fromisoformat() function added in 3.7 is a very welcome addition. But one quite noticeable absence was the inability to parse Z instead of +00:00 as the timezone suffix. Its absence is particularly noticeable given how ubiquitous use of Z is in ISO 8601

[issue35376] modulefinder skips nested modules with same name as top-level bad module

Change by rdb : -- pull_requests: -10133 ___ Python tracker <https://bugs.python.org/issue35376> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35376] modulefinder skips nested modules with same name as top-level bad module

Change by rdb : -- pull_requests: +10134 ___ Python tracker <https://bugs.python.org/issue35376> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35376] modulefinder skips nested modules with same name as top-level bad module

Change by rdb : -- pull_requests: +10133 ___ Python tracker <https://bugs.python.org/issue35376> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35376] modulefinder skips nested modules with same name as top-level bad module

New submission from rdb : If modulefinder finds a nested module import (eg. 'import a.b.c') while there is a top-level module with the same name (eg. 'c') that failed to import and got added to the badmodules list, it will skip it entirely without even trying to import it. This has

[issue29244] Python 3.6 unnecessarily requires inttypes.h

rdb added the comment: As far as I know, there should not be any ABI issues. We've been building extension modules with non-matching MSVC versions for years without issues. I find it hard to think of downsides to such a trivial fix. It is somewhat frustrating that we will have to resort

[issue29244] Python 3.6 unnecessarily requires inttypes.h

New submission from rdb: Python 3.6 now requires inttypes.h on all platforms. However, this is not provided by MSVC 2010 and 2012, which is still used by some people who build extension modules for Python. MSVC 2010 does provide stdint.h, and replacing the inttypes.h include with an include