On 7/11/06, skip at pobox.com <skip at pobox.com> wrote:
>
>
> Michael> Well here's one I stumbled across the other day. I don't know
> Michael> if it's legit, but it's still bad PR:
>
> Michael>
> http://www.gbch.net/gjb/blog/software/discuss/python-sucks.html
>
> Michael> For the impatient, he's not at all bothered about the lack of
> Michael> obscure language feature X.
That whole entry is a little overblown. I mean the guy has a single issue
with a change and he gives up on the language after only the second one?
Try using any language that is under active development and show me stuff
that won't break. I think it shows how hard we work to not break things
that this guy only got bit twice, and at least the second time was minor and
had a legit reason for the change.
The way I used to format dates using time.strftime does indeed no longer
> work.
>
> Python 2.3:
>
> >>> import time
> >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
> '2005-06-04'
>
> Python 2.4 or 2.5:
>
> >>> import time
> >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> ValueError: day of year out of range
> >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (1,)*6)
> '2005-06-04'
That was done to fix buffer overflow issues when libc implementations didn't
do bound checks on the arguments to strftime() and would index too far (e.g.,
setting the month as 20 indexes too far and setting to 0 can be an issue as
well since the array indexing for the month name will be January, and thus
will most likely do ``mon - 1`` to get the index into the array).
I don't actually run into this problem as I've pretty much converted to use
> datetime in new code. I also realize that's not documented as the way it
> should be done,
It is the last point in the first paragraph on time.strftime() discussing
what changed in Python 2.4 as to what the change was. It's also in
Misc/NEWS . Basically the guy didn't read the release notes or the docs to
see why that changed and that it was legitimate and needed for stability.
but I'm fairly certain it was common usage before the
> datetime module came along. Still, it is a bit annoying that the
> (undocumented, but I think de facto) commonly used idiom no longer works.
As I said, stability called for the need to make the change. It was
discussed on python-dev when it came up.
(In fact, it always bothered me a bit that I had to even provide the unused
> values.)
That would probably be fine to add in 2.6 . Should be a huge issue. You
could also change the function to detect values of 0 when provided and then
automatically use defaults in those cases that are within the proper range.
-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060711/6cb60fa7/attachment.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4