> But that perspective is not directly relevant to *your* topic line. When > you make a claim that os.stat is 'broken' and bugged, you are making a > claim about the *programmer* experience -- in particular, experiencing a > discrepancy between performance and reasonable expectation based on the > manuals. Martin and I are both concerned about that particular claim > (which now appears to be resolved in the negative).
The subject line reflects what *originally* appeared to be the source of the problem since a comparison of the results did not match previous Python versions. For other developers that run into this difference (which did not occur before) I believe it is benefitial to them to understand why the difference is now occurring and why BOTH Python and Windows are displaying CORRECT results even though they do NOT match what they display. For those same developers, I also posted a localtime_windows much which allows them to massage the values returned by Python localtime so that they match the values that Windows displays if they have the need and/or requirement to do so. Often times in development what "appears" to be the source of the problem turns out that it is not the actual problem that is occurring. It is still beneficial to have that link from what "appears" to be the problem to the details of what "actually" is the source of the problem. For another developer that runs into this difference their most likely initial conclusion would be that something in Python 2.5.1 is broke especially when they research the changes in Python 2.5.1 and find that os.stat was changed. As a general rule, when something is broke, suspect the last thing that you did even if it does not seem like it should be the source of the problem. > Python developers cannot fix that. Besides which, Python is a > cross-platform language, originally developed on *nix. Really, I thought they could fix anything :-) -- http://mail.python.org/mailman/listinfo/python-list
