[Python-Dev] datetime nanosecond support (ctd?)

[Matthieu Bec]

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