micropython R1.9 ETA @@ released @@

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: micropython R1.9 ETA @@ released @@

Post by pythoncoder » Wed May 31, 2017 6:21 am

I agree that on() and off() for a Pin is potentially ambiguous. So don't use it. The intention of the recent changes is that in most cases you use Signal, which handles inversion if required. So you can write LeftMotor.on() which is unambiguous. If the hardware changes so that the sense of the bit is changed, you change one line of code, where the Signal is instantiated.

The Pin object is intended for device drivers and it works with __call__ or value(). So you can use either to your taste, although in a given program I'd pick one of the two and stick to it.

Code: Select all

pin_cs_low(0)
pin_data_out.value(1)
pin_ck_out(0)
received_bit = pin_data_in()
All of which is crystal clear.
Peter Hinch
Index to my micropython libraries.

jcea
Posts: 27
Joined: Fri Mar 18, 2016 5:28 pm

Re: micropython R1.9 ETA @@ released @@

Post by jcea » Wed May 31, 2017 8:52 am

TravisT wrote:Maybe I am just adding to the noise, but I would also agree that high/low is the most concise and describes the states the best. True/False and 1/0 mean about the same in my head, and I often use them also, but I feel it does not describe it as well when thinking pin states. Those three options seem reasonable.

On/Off seems potentially too misleading and does not teach/enforce more standard practice, at least how I see it.

Of course this is all just my opinion.
+1!!!

@pfalcon, @Damien, please listen to your users.

pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: micropython R1.9 ETA @@ released @@

Post by pfalcon » Wed May 31, 2017 2:26 pm

We've been listening to thousands of sources of information (which, besides users also includes experience and history of other projects, research results and considerations how to address millions of usecases) for 3+ years, no worries on that side.

So, now question from me - when you start to listen to what you're being told?

From the earlier post of this thread:
If .on/.off doesn't work for you, no problem, use .value(). Want something else - no problem, it's Python, so everything is easy. Subclass Pin or wrap it and add whatever you want.
How MicroPython is designed is that we take the barest minimum to let something be done. In case of Pin, it's Pin.value(). Then we see if adding 1 (one) another piece of functionality may extend usecases noticeably (say, 2x). If so, we add those, in case of Pin and Signal, that .on() and .off() (yeah, one for each ;-) ). Everything else, is covered by its majesty Python, and is to be done by users by their needs. That's how MicroPython has always been, continues to be, and how its going to grow to even higher heights.

I'm definitely sorry to hear that you don't like that. Everyone else, can rejoice that now we finally have the foundation of hardware API - basic GPIO operations - defined, and can proceed to develop great, now fully portable MicroPython applications.
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

User avatar
deshipu
Posts: 1388
Joined: Thu May 28, 2015 5:54 pm

Re: micropython R1.9 ETA @@ released @@

Post by deshipu » Wed May 31, 2017 11:21 pm

pfalcon wrote:and can proceed to develop great, now fully portable MicroPython applications.
Fully portable to what? There is literally no other implementation or port this is compatible with.

pmp-p
Posts: 13
Joined: Mon Apr 24, 2017 12:45 am

Re: micropython R1.9 ETA @@ released @@

Post by pmp-p » Fri Mar 30, 2018 9:50 am

[quote=pfalcon post_id=19976 time=1496240794 user_id=112]Everyone else, can rejoice that now we finally have the foundation of hardware API - basic GPIO operations - defined, and can proceed to develop great, now fully portable MicroPython applications.
[/quote]

Then please don't count me in "Everyone else".

Breaking existing codebases is *not* a decent (any)python attitude.

Post Reply