Thanks Stephen elaborating on the process. and apologies, I was dismissing the last point only half jokingly.
I read the comment for strftime / strptime in the report as meant to remember to implement it. It seems picking a new format letter (or keep using "%f" if acceptable) that would accept/produce up to 9 characters instead of 6 for nanoseconds would do most of the trick. Maybe there's no issue or I don't understand it.
That completes my chant to awaken the Elderers! Regards, Matthieu On 12/10/14 9:10 PM, Stephen J. Turnbull wrote:
mdcb808 writes: > These are typically discussed on this list or using the bug > tracker? I think this discussion belongs on python-dev because the requirement is clear, but a full specification involves backward compatibility with older interfaces, and clearly different people place different values on the various aspects of the problem. It makes sense to go straight to tracker when the design is done or obvious, or backward compatibility is clearly not involved. The tracker is also the place to record objective progress (patches, tests, bug reports). Python-Dev is where minds meet. What Nick is saying is that more design needs to be done to resolve differences of opinion on the best way to move forward. > maybe YNGTNI applied, Evidently not. If a senior developer really thought it's a YAGNI, the issue would have been closed WONTFIX. It seems the need is believable. > not clear why it's not there after 2 eyars. There's only one reason you need to worry about: nobody wrote a patch that meets the concerns of the senior developers (one of which is that concerns raised by anybody remain unresolved; they don't always have strong opinions themselves).[1] > - not sure what's at stake with the strp/ftime() but cant imagine > it's a biggie If you want something done, you don't necessarily need to supply a patch. But you have to do more to move things forward that just say "I can't imagine why anybody worries about that." You have to find out what their worries are, and explain that their worries won't be realized in the case of the obvious design (eg, the one you presented), or provide a design that avoids realizing those worries. Or you can get the senior developers to overrule the worriers, but you need a relatively important use case to make that fly. Or you can get somebody else to do some of the above, but that also requires presenting an important use case (to that somebody). Footnotes: [1] That's not 100% accurate: there is a shortage of senior developer time for reviewing patches. If it's simply that nobody has looked at the issue, simply bringing it up may be sufficient to get attention and then action. But Nick's response makes it clear that doesn't apply to this issue; people have looked at the issue and have unresolved concerns.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
