Message157945
| Author |
pitrou |
| Recipients |
Esben.Agerbæk.Black, belopolsky, lemburg, pitrou |
| Date |
2012年04月10日.10:44:40 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1334054351.3389.8.camel@localhost.localdomain> |
| In-reply-to |
<CAP7h-xY9sULgFXZUrCPq7o_Lc27L_8atUy0XWwCQ0srJYMN7Bg@mail.gmail.com> |
| Content |
> No, but it is still a one-line function that those who need it can
> easily implement.
It's so easy that the patch isn't a one-liner and it seems to still have
bugs wrt. intended behaviour.
> I am on the fence here because we already have
> date.isocalendar() function, so it is natural to desire its inverse,
> but still at least on this side of the pond an Easter(year) date
> constructor would see more use than that.
This isn't an either/or situation. We can have both from_iso_week() and
Easter() if both are useful.
And I don't get this "side of the pond" argument. Python is not meant
only for the American public, that's why all strings are now unicode. |
|