Repository navigation
Move all loose methods inside modpyb to another class. #1297
Description
Activity
- changed the title
[-]Move all loose methods inside modpyb to a single class.[/-][+]Move all loose methods inside modpyb to another class.[/+]on 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?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).
Please note that "machine" module is intended to by "pyb" v2-final, so anything going there should be given real good thought.
Some of the methods that I don't see being part of machine are 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?
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).
There's nothing particularly "clean" in putting everything to classes.
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".
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.
Well, it's clean for me ;-). Anyway the idea was not to put restrictions but to organise things better.
Having functionality split over many modules also requires good documentation
Well, we have already discussed about making improves in that area, and things are being done.
I do like the pyb module being a one-stop-shop for all things microcontroller related
Since a lot of the functions are common to other platforms, shouldn't the
pybmodule be renamed to something more general?It must be said though: I do like the pyb module being a one-stop-shop for all things microcontroller related.
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?
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.
Poor Guido guy, he could have done much better by putting all Python functionality in one module named e.g. "foobar" ;-).
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).
Yes, and #983 is one of the oldest docs-related issue.
At the moment it's easy to just say "all special functions are in pyb".
pyb.py:
from * import *Well, what to do then?
- Put IRQ, Sleep and reset handling inside modmachine?
- Do we want to get rid of modpyb completely? and then ADC, SPI, I2C, etc. would all be independent modules?
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?
We should move reset, unique_id, interrupt, sleep and so on, to another class (
machinefor 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 makemachinethe place to put all those things that do not fit anywhere else ;-).