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 brett.cannon
Recipients brett.cannon, eric.smith, skip.montanaro
Date 2007-09-17.16:12:44
SpamBayes Score 0.00015670029
Marked as misclassified No
Message-id <bbaeab100709170912v712686aeh3ebc2d68de421924@mail.gmail.com>
In-reply-to <1190037009.62.0.710295247678.issue1158@psf.upfronthosting.co.za>
Content
In terms of strptime, I would just change _strptime.strptime() to
_strptime._strptime() and have it return everything along with the
microseconds measurement.  Then have public functions that call that
function and either strip off the microseconds or not.

-Brett

On 9/17/07, Skip Montanaro <report@bugs.python.org> wrote:
>
> Skip Montanaro added the comment:
>
> Brett,
>
> Continuing the discussion of strptime... It returns a time.struct_time.
> Would it cause too much breakage (only do this in 3.0) to add a tm_usec
> field to the end of that object?  It seems a lot of bits of code might
> still expect a length 9 tuple-ish thing and do this:
>
>   yy, mm, dd, hh, mm, ss, wk, j, tz = time.strptime(...)
>
> If we could make that change for 3.0 that might allow strptime to parse
> %f format codes.
>
> S
>
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1158>
> __________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/brett%40python.org
>
>
History
Date User Action Args
2007-09-17 16:12:44brett.cannonsetspambayes_score: 0.0001567 -> 0.00015670029
recipients: + brett.cannon, skip.montanaro, eric.smith
2007-09-17 16:12:44brett.cannonlinkissue1158 messages
2007-09-17 16:12:44brett.cannoncreate