Repository navigation
Move all loose methods inside modpyb to another class. #1297
Description
We should move reset, unique_id, interrupt, sleep and so on, to another class (machine for instance) to handle all "microcontroller" and non-standard python things. That way modpyb ends up being a clean collection of classes. We should also keep in mind to not make machine the place to put all those things that do not fit anywhere else ;-).
Activity
[-]Move all loose methods inside modpyb to a single class.[/-][+]Move all loose methods inside modpyb to another class.[/+]danicampora commentedon May 31, 2015
Some of the methods that I don't see being part of
machineare the time related ones (elapsed_mililis, elapsed_micros) any chance we can move those to modutime? I know is not standard stuff, but we can make extensions as long as they make sense, right?pfalcon commentedon May 31, 2015
There's nothing particularly "clean" in putting everything to classes. Python is not Java (thanks god), so it makes little sense to enforce artificial restrictions like that. However, there's a "machine" module now, and all those functions really should go there (I skipped mentioning this on @dpgeorge's related comment yesterday, but if you raise it as an additional ticket, here it is).
pfalcon commentedon May 31, 2015
Please note that "machine" module is intended to by "pyb" v2-final, so anything going there should be given real good thought.
pfalcon commentedon May 31, 2015
Yes, moving those to "time"/"utime" is what I had in mind to propose too. The closest ticket to discuss that is #1225 (because again, we should apply good thought to add to "time" good and consistent API, I even have an idea to run it thru python-ideas list).
dpgeorge commentedon May 31, 2015
I think @danicampora did in fact mean module.
It must be said though: I do like the pyb module being a one-stop-shop for all things microcontroller related. Splitting the functions/classes out into different modules means people need to remember both the module name and the function/class name, instead of just knowing to always use pyb.
Having functionality split over many modules also requires good documentation. If time-related functions go in utime then we need to highlight the differences between standard time and utime, pointing out the special functions that are more suited to a microcontroller (eg utime.delay, utime.elapsed_millis). At the moment it's easy to just say "all special functions are in pyb".
danicampora commentedon May 31, 2015
Well, it's clean for me ;-). Anyway the idea was not to put restrictions but to organise things better.
danicampora commentedon May 31, 2015
Well, we have already discussed about making improves in that area, and things are being done.
roger- commentedon May 31, 2015
Since a lot of the functions are common to other platforms, shouldn't the
pybmodule be renamed to something more general?pfalcon commentedon May 31, 2015
Is it pythonic to call it like that? Did you run that idea thru (e.g.) python-ideas, what feedback from teh general Python community was?
Poor Guido guy, he could have done much better by putting all Python functionality in one module named e.g. "foobar" ;-).
Yes, and #983 is one of the oldest docs-related issue.
pyb.py:
danicampora commentedon Jun 7, 2015
Well, what to do then?
dhylands commentedon Jun 7, 2015
I wouldn't want to get rid of pyb until such time as I can use dir on some global dictionary to discover what's there. Presumably such a dict exists, and we just need to expose it as sys.modules?
pfalcon commentedon Jun 19, 2016
Superseded by #1430.