unix port missing utime.mktime() #4576
Comments
|
Also, I noted that utime does not have the dst flag in the time_tuple, which means it's incompatible with time as far as mktime is concerned (and others). Would it be better to add dst to the tuple but ignore it ? I don't know how to gauge the trade-off here, I guess that it's probably not a common use case to run the same script in the various pythons and hence not worth the effort to 'fix'. |
|
It's not "missing", it's not supposed to be there. As you rightfully noticed, MicroPython's |
|
I'm not sure I follow. Why is everything else in the unix port utime implementation except mktime ? (which is, btw, present in the esp866 and other ports, and also correctly dealing with dst wart I mentioned) At the very least, the documentation should mention with parts of utime are not available on the unix port. To me, it just looks someone forgot to implement the mktime call. |
"Everything else" - what? A lot of things are not there comparing with CPython's https://docs.python.org/3/library/time.html module. And the purpose of
Unfortunately, some ports go beyond the bare minimum with the idea of giving users of specific ports additional conveniences. Unfortunately, because it leads to the opposite effect of some users thinking there's something "missing" in ports which don't provide them. Regarding esp8266 and other ports, it's hard to believe that it's implemented "correctly", because the correct implementation requires always-powered RTC, Epoch starting 1970-01-01 00:00 UTC, and double-precision floating point support.
Not parts of the baseline API and thus not available on some ports, yeah. The unix port is just the guardian of the baseline API. |
|
I'm not arguing for implementing anything that isn't in the documentation [1]. I could even understand not implementing mktime in utime and removing it from the documentation. a) The baseline API? Then mktime should be implemented in all ports. BTW, I realize that it's easy for to come in and act high and mighty without lifting a finger to help. That's not my intention at all. [1] https://docs.micropython.org/en/latest/library/utime.html |
You rightfully point at the issue in docs, thanks. I submitted a patch: #4583.
Yeah, that definitely should be offered as an alternative to everyone wanting to add more and more (uncontrollable) features, and using "another port has it" as an execute.
During 5 years of project history that (and many other things) certainly was asked, discussed, and there're even decisions. Condensed summary of that is what I present here. (I'd encourage to use git history and ticket search for more.)
The days when docs described arbitrary platform are long over. They now describe "generic MicroPython API" - both the baseline and common, platform-independent extensions. Any board-specific docs live in separate chapters like http://docs.micropython.org/en/latest/esp8266/quickref.html . But yeah, docs still has remnants of board-specific things and not all of the baseline API is marked as such. But intro at http://docs.micropython.org/en/latest/library/index.html should give the basic idea and set the expectations right. |
|
The unix port has |
Add senseBox MCU
It looks like the unix port has utime.mktime() missing
I was trying to make a script running both on micropython/regular python via the usual hack:
but since mktime is not in utime (as the documentation suggests), that fails.
The text was updated successfully, but these errors were encountered: