8000 Move all loose methods inside modpyb to another class. · Issue #1297 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

Move all loose methods inside modpyb to another class. #1297

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
danicampora opened this issue May 31, 2015 · 12 comments
Closed

Move all loose methods inside modpyb to another class. #1297

danicampora opened this issue May 31, 2015 · 12 comments

Comments

@danicampora
Copy link
Member

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 ;-).
@danicampora danicampora changed the title Move all loose methods inside modpyb to a single class. Move all loose methods inside modpyb to another class. May 31, 2015
@danicampora
Copy link
Member Author

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?

@pfalcon
Copy link
Contributor
pfalcon commented 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
Copy link
Contributor
pfalcon commented 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
Copy link
Contributor
pfalcon commented May 31, 2015

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

@dpgeorge
Copy link
Member

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

@danicampora
Copy link
Member Author

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.

@danicampora
Copy link
Member Author

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.

@roger-
Copy link
roger- commented May 31, 2015

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 pyb module be renamed to something more general?

@pfalcon
Copy link
Contributor
pfalcon commented May 31, 2015

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 *

@danicampora
Copy link
Member Author

Well, what to do then?

  1. Put IRQ, Sleep and reset handling inside modmachine?
  2. Do we want to get rid of modpyb completely? and then ADC, SPI, I2C, etc. would all be independent modules?

@dhylands
Copy link
Contributor
dhylands commented 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?

@danicampora danicampora mentioned this issue Aug 13, 2015
Closed
4 tasks
@pfalcon
Copy link
Contributor
pfalcon commented Jun 19, 2016

Superseded by #1430.

@pfalcon pfalcon closed this as completed Jun 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@dhylands @pfalcon @roger- @dpgeorge @danicampora
0