This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author p-ganssle
Recipients belopolsky, berker.peksag, bmispelon, corona10, p-ganssle, rhettinger, serhiy.storchaka, taleinat, vstinner
Date 2019-09-01.16:12:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> But I'm wondering how the `fromisocalendar` API relates to this patch.
> Rather, wouldn't this patch contribute to improving the usability of the `fromisocalendar` API?

The `fromisocalendar` API relates to this patch only insofar as it is the inverse function of `isocalendar` and in some sense it allows specifying the parameters by keyword rather by position. I was merely bringing up that we didn't choose that API because we thought people would or should want or need to specify the individual components by keyword but because we didn't have an easy way to maintain the same API in the pure Python and C APIs at the time. By contrast, returning a plain tuple from `isocalendar()` is the easier *and* more performant thing to do, and given that any benefits seem marginal I'm against the switch.

I think that the usability of `fromisoformat` with the output of `isocalendar` will be largely unchanged if we were to switch to returning a namedtuple.
Date User Action Args
2019-09-01 16:12:33p-gansslesetrecipients: + p-ganssle, rhettinger, belopolsky, vstinner, taleinat, berker.peksag, serhiy.storchaka, bmispelon, corona10
2019-09-01 16:12:33p-gansslesetmessageid: <>
2019-09-01 16:12:33p-gansslelinkissue24416 messages
2019-09-01 16:12:33p-gansslecreate