New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document that datetime.__format__ is datetime.strftime #53159
Comments
Documenting that would help get people using datetime objects with string.format more. |
I wonder if this is subject to change. I find it odd that >>> "{:g}".format(1e3)
'1000' but one has to use % in >>> "{:%Y}".format(datetime.now())
'2010' It is also different from PEP-3101 recommendation:
""" "Today is: {0:a} {0:b} {0:d} {0:H}:{0:M}:{0:S} {0:Y}".format(datetime.now()) |
I don't find it odd at all that you use datetime-specific formats instead of integral formats to get numbers out of a datetime object; they are totally different things. And one of the reasons for __format__ support is to have DSLs such as the one for datetime objects. As for pulling out individual objects, that just looks ugly, so I wouldn't advocate pulling out individual values and then formatting them individually in the string itself. |
I think Alexander's example is best written as: I agree with Brett that there's nothing unusual about having type-specific formatting languages, and for datetime strftime is the obvious choice. It's a little unfortunate that % is used, as it's mildly confusing with %-formatting, but not much can be done with that issue. |
This documentation should also be added for datetime.time and datetime.date, in addition to datetime.datetime. |
The problem I have with strftime %-format codes is that according to BSD manual page they have already ran out of English alphabet and still "there is no conversion specification for the phase of the moon." :-) On a serious note, there are no codes to format TZ offset hours and minutes separately which precludes specifying an important RFC 3339 format. I think we should take this opportunity to define a comprehensive mini-language for datetime formatting rather than slavishly reuse strftime. The new mini-language may end up to be a superset of that for strftime, but I would rather not commit to supporting %-codes indefinitely. |
Unfortunately I think it's too late to do anything about this. I, for one, have many lines of code in production that use the strftime format specifier for datetime.__format__. You only option would be to invent a new language that was somehow distinguishable from the strftime specifiers, but I doubt you'd get much support. I think it's better to extend strftime, and let __format__ benefit from it. |
I think this particular wheel has one very good reinvention as the Locale Data Markup Language specification. Example from the Python Babel package: >>> format_datetime(dt, "yyyyy.MMMM.dd GGG hh:mm a", locale='en')
u'02007.April.01 AD 03:30 PM' http://unicode.org/reports/tr35/#Date_Format_Patterns |
Alexander closed bpo-7789 in favor of this one, which is fine, but I want to respond to Eric's rejection there of including info about datetime in the 'format mini language' section of the docs. His point was that only the builtin types were documented there, but if the goal is to get people to actually use this facility, it would be helpful if some mention were made there of other stdlib types that support __format__. Some set of 'see also' links, perhaps in a footnote? |
I'm okay with that. Grepping Lib shows that date/datetime/time and Decimal are the only types that implement __format__. Decimal largely implements the same language as float. |
IMO, now that two official releases of Python 3 have shipped with this behavior (3.1 and 3.2), it is too late to think about changing what datetime.__format__ does, and we should merely document that it is the same as strftime. |
Added documentation for __format__ for datetime, time and date, and also added example code for using string.format. Seemed to merge cleanly to 3.4 and 2.7. |
Thanks! Reviewed. |
Thanks for the comments, Eric! I reworded the docs and improved the examples too (being stuck in 2.6 I didn't even know about the cool autonumbering :) |
Grammar fixed |
To Heikki Partanen excellent point in the review about date __format__ strings allowing you to combine date formatting with other types of formatting: This is a great point. It's the lack of this that (for example) requires the logging module to have a separate datefmt parameter. With %-formatting, there's no easy way to say: '{timestamp:%Y%m%d-%H%M%S} {hostname:^40} {count:02d}'.format(timestamp=ts, hostname=host, count=count) That is, with %-formatting you can't have a single string that specifies both a date/time format and other formatting as well as other formatting specifiers. I don't think the example in the patch is great, but I do think that it's a good point that needs to be emphasized. |
Can bpo-8913-3.patch be committed or are any further tweaks needed? |
Ezio, you are the latest reviewer, do you have outstanding comments? |
My only suggestion would be that the datetime example would be better if it actually used a time portion, similar to the strftime example above it. Otherwise, it looks good. |
Improved the datetime example to have time part |
That looks great. Thanks! |
I left another review with a couple of suggestions. |
The examples in the previous patches were trying to show some "real-worldish" use cases, but I admit that they don't fit in that well to the existing examples shown in the docs. The new examples Ezio suggested are more straightforward and better in line with existing docs, so uploaded a new patch with updated examples. |
New changeset 40f582a73901 by Ezio Melotti in branch '3.3': New changeset 8dd7f7134700 by Ezio Melotti in branch 'default': New changeset 0dac103a41bb by Ezio Melotti in branch '2.7': |
Fixed, thanks for the patch! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: