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. >
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