[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.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue37664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
> > either exactly 3 or 6.
>
> There are other differences, for example a comma can be used in place of a
> dot as the delimiter for fractional seconds. Looking at the grammar in the
> RFC, it seems that it might also support datetimes like 2018-W03-D4, but I
> don't see any mention of that in the text.
I think you're looking at the appendix, which collects the ABNF from
ISO 8601, but this is not part of RFC3339. The grammar for RFC3339 is
purposefully very restrictive to make parsing it simple. The comma
for delimiter is in though, good catch; also a trivial change.
> > So, I can bundle this together with a change making it more lenient about
> > the number of decimal places for seconds, and we can change the docs for
> > `fromisoformat()` to be "it accepts any RFC3339 timestamp, including those
> > generated by isoformat()".
>
> No, because the isoformat outputs are not a subset of RFC 3339. For example,
> 2015-01-01T00:00:00 is not a valid RFC 3339 datetime string, nor is
> 2015-01-01Q00:00:00, but they are valid outputs of datetime.isoformat().
> datetime.fromisoformat() also supports fractional seconds on time zone
> offsets, which is not part of ISO 8601.
Fair enough (though I'd say "isoformat()" is a misnomer then). I was
just going by your option #2. We would change the wording to imply
"supports RFC 3339 or anything produced by isoformat()"
>
> > Because what I'm trying to use it for technically falls outside the
> > intended use, I say it would make the most sense to expand the intended use
> > a bit.
>
> Is there a reason you can't use `dateutil.parser.isoparse`? The contract of
> that function is to parse any valid ISO8601 datetime, and fromisoformat is
> adapted from it.
It seems a little odd to need to pull in a third-party library for
this; it seems far more tempting for me to just do
"datetime.fromisoformat(str.replace('Z', '+00:00'))" instead since I
know my dates are produced by a JSON API.
I don't intend to get argumentative about whether supporting RFC3339
belongs in the standard library; that is clearly a decision for the
Python maintainers, and I'm not sure what criteria they follow on
this. I just find it odd to point people to a third-party library for
parsing a simple but ubiquitous date standard when there are many
modules in the standard library for far more specific use cases.
FWIW, I do think that fromisoformat() is the right function to provide
RFC3339 support. I don't think users would benefit from having to
choose between several different functions that parse similar but
subtly different date formats; this seems likely to cause confusion.
Thanks for your consideration!
--
___
Python tracker
<https://bugs.python.org/issue35829>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 most sense to expand the intended use a bit. 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 either exactly 3 or 6. So, I can bundle this together with a change making it more lenient about the number of decimal places for seconds, and we can change the docs for `fromisoformat()` to be "it accepts any RFC3339 timestamp, including those generated by isoformat()". Does this seem acceptable? We can always expand further to allow any ISO 8601 timestamp later, but RFC3339 would already make this function immensely more useful. I really think that parsing RFC3339 dates is a feature Python needs to have in the standard library given their ubiquity on the web. Alternatively I am happy to consider adding something like a utc=True flag to isoformat(), but I would personally feel reluctant to add any features that I can't think of a solid use case for. -- ___ Python tracker <https://bugs.python.org/issue35829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 timestamps on the web; it is also part of the RFC 3339 subset. In particular, JavaScript produces it in its canonical ISO 8601 format and is therefore quite common in JSON APIs; this would be the only piece missing to parse ISO dates produced by JavaScript correctly. I realise that the function was not intended to be able to parse *all* timestamps. But given the triviality of this change, the ubiquity of this particular formatting feature, and the fact that this change is designed in particular for operability with the widely-used JavaScript date format, I don't think this is a slippery slope, and I would personally see no harm in accepting a 'Z' instead of a timezone. I am happy to follow up with a patch for this, but would first like confirmation that there is any chance that such a change would be accepted. Thanks for your consideration! -- components: Library (Lib) messages: 334365 nosy: rdb priority: normal severity: normal status: open title: datetime: parse "Z" timezone suffix in fromisoformat() type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue35829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 a trivial fix (attached). The right thing to do is clearly to check it by fqname in the badmodules dict since that's also what it expects in other locations. I can make a PR as soon as my CLA gets validated, if that is more convenient. (Which branch should I make the PR against?) -- components: Library (Lib) files: patch.diff keywords: patch messages: 330883 nosy: rdb priority: normal severity: normal status: open title: modulefinder skips nested modules with same name as top-level bad module type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file47968/patch.diff ___ Python tracker <https://bugs.python.org/issue35376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to shipping custom Python versions with patched headers. Some people are constrained to older MSVC versions for reasons not in their control. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29244> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to stdint.h seems to work fine. I would suggest a fix along the lines of this: #if defined(_MSC_VER) && _MSC_VER < 1800 #include #else #include #endif Alternatively, the HAVE_INTTYPES_H definition could be used to fall back to stdint.h, and it could be undefined for the MSVC build. -- components: Extension Modules messages: 285250 nosy: rdb priority: normal severity: normal status: open title: Python 3.6 unnecessarily requires inttypes.h versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29244> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
