Thomas Perl wrote:
> Looks beautiful and very Pythonic to me :) +1 for implementing that at
> some point in the future.
>
> As for the request for ".ymd(), .hms(), .hmsm(), .ymdhms(),
> .ymdhmsm()", this could be solved by slicing the resulting tuple (if
> it provides all information), and only providing the "most verbose"
> variant (ymdhmsm). Maybe even in the order so that it can be passed to
> Python's built-in "datetime.datetime" object constructor?
Yeah, ymdhmsm can be quite a mouthful, but the tricky thing is that
datetime.datetime accepts a ymdhmsu tuple, that is with microseconds and not
milliseconds (come to think of it, the name is poor as m could also be
interpreted as "microsecond"...)
So if by default we provide a tuple that gives everything including
milliseconds, users are likely to fall into that trap and pass it to
datetime.datetime unaware of the difference :-(
Perhaps the cleanest solution would be to only provide conversion to
datetime.datetime, but datetime.datetime doesn't provide a tuple with
sub-second information!
As for ymd and hms, I was thinking about those more for QDate and QTime than
for QDateTime.
> For the QUrl example in the bug report: One can use urlparse.urlsplit
> and urlparse.urlunsplit in the Python standard library for that and
> get/pass the full URL from/to QUrl, avoiding the need for API
> additions there.
Very good point. Perhaps it should be checked that QUrl indeed accepts exactly
the same inputs as urlparse, and that they will always be split the same way.
Cheers,
Farsmo
_______________________________________________
PySide mailing list
PySide@lists.openbossa.org
http://lists.openbossa.org/listinfo/pyside
