Message 361737 - Python tracker

Message361737

Author	p-ganssle
Recipients	atuining, belopolsky, dlenski, p-ganssle
Date	2020-02-10.22:31:28
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1581373888.54.0.867536506321.issue30155@roundup.psfhosted.org>
In-reply-to

Content
So this bug is asking for two things: 1. An official accessor for the `tzinfo` component of an existing datetime, which I think is very reasonable in light of the fact that there are official accessors for all the other components of a datetime. 2. An official constructor for a timezone-aware datetime, which I think basically exists in the form of PyDatetime_CAPI->PyDateTimeAPI->DateTime_FromDateAndTime / ->DateTime_FromDateAndTimeAndFold, and we just need to document it. I think this is basically a separate issue, and I have opened #39604 to track it. I'm going to rename this bug to focus only on issue #1. I think we can accept a PR adding two new macros. I would suggest calling them: - PyDateTime_DATE_GET_TZINFO - PyDateTime_TIME_GET_TZINFO Please make sure to add tests to any PR you make. See the CapiTest case (https://github.com/python/cpython/blob/d68e0a8a165761604e820c8cb4f20abc735e717f/Lib/test/datetimetester.py#L5914) for examples. You may want to look at the git blame for a few of those tests to see the PRs that they were added in, since part of the tests are defined in a C file. (As an aside: I don't love that the accessor methods are not available on the struct, since all the "macro-only" code needs to be re-implemented in all other-language bindings. Since the accessors are already all macro-only, though, might as well keep with the tradition for now :P)

Content

So this bug is asking for two things:

1. An official accessor for the `tzinfo` component of an existing datetime, which I think is very reasonable in light of the fact that there are official accessors for all the other components of a datetime.

2. An official constructor for a timezone-aware datetime, which I think basically exists in the form of PyDatetime_CAPI->PyDateTimeAPI->DateTime_FromDateAndTime / ->DateTime_FromDateAndTimeAndFold, and we just need to document it. I think this is basically a separate issue, and I have opened #39604 to track it.

I'm going to rename this bug to focus only on issue #1. I think we can accept a PR adding two new macros. I would suggest calling them:

- PyDateTime_DATE_GET_TZINFO
- PyDateTime_TIME_GET_TZINFO

Please make sure to add tests to any PR you make. See the CapiTest case (https://github.com/python/cpython/blob/d68e0a8a165761604e820c8cb4f20abc735e717f/Lib/test/datetimetester.py#L5914) for examples. You may want to look at the git blame for a few of those tests to see the PRs that they were added in, since part of the tests are defined in a C file.

(As an aside: I don't love that the accessor methods are not available on the struct, since all the "macro-only" code needs to be re-implemented in all other-language bindings. Since the accessors are already all macro-only, though, might as well keep with the tradition for now :P)

History
Date	User	Action	Args
2020-02-10 22:31:28	p-ganssle	set	recipients: + p-ganssle, atuining, belopolsky, dlenski
2020-02-10 22:31:28	p-ganssle	set	messageid: <1581373888.54.0.867536506321.issue30155@roundup.psfhosted.org>
2020-02-10 22:31:28	p-ganssle	link	issue30155 messages
2020-02-10 22:31:28	p-ganssle	create