Search found 11 matches
- Thu Oct 03, 2019 5:55 am
- Forum: General Discussion and Questions
- Topic: How to implement __setattr__ without infinite recursion
- Replies: 14
- Views: 11131
Re: How to implement __setattr__ without infinite recursion
I just realized there is a gotcha if the struct layout is nested. In that case, the overloaded __getattr__ will be called with the top-level attribute name only whenever a nested attribute is being get or set. As a result, on a nested attribute 'get', the I2C logic won't have the correct information...
- Thu Oct 03, 2019 2:33 am
- Forum: General Discussion and Questions
- Topic: How to implement __setattr__ without infinite recursion
- Replies: 14
- Views: 11131
Re: How to implement __setattr__ without infinite recursion
Yeah, that seems like a good option.
In the closure approach, does each instance store a separate identical copy of _get/_set in memory vs. normal methods that are stored once on the class?
In the closure approach, does each instance store a separate identical copy of _get/_set in memory vs. normal methods that are stored once on the class?
- Thu Oct 03, 2019 12:15 am
- Forum: General Discussion and Questions
- Topic: How to implement __setattr__ without infinite recursion
- Replies: 14
- Views: 11131
Re: How to implement __setattr__ without infinite recursion
FYI, looks like I'm not the first person to want to do something like this https://github.com/micropython/micropyt ... -466670063
- Thu Oct 03, 2019 12:07 am
- Forum: General Discussion and Questions
- Topic: How to implement __setattr__ without infinite recursion
- Replies: 14
- Views: 11131
Re: How to implement __setattr__ without infinite recursion
Great idea! You actually don't need to do anything special for __getattr__ since it will only get called if the attribute is not found "normally" (https://docs.python.org/3/reference/datamodel.html#object.__getattr__). That saves you from having to type all the "if" checks for the attributes stored ...
- Wed Oct 02, 2019 4:45 am
- Forum: General Discussion and Questions
- Topic: How to implement __setattr__ without infinite recursion
- Replies: 14
- Views: 11131
How to implement __setattr__ without infinite recursion
I'm trying to implement a Register class which allows direct access to bitfields on a register. I need it to work identical to attribute access on a uctypes.struct bitfield, but I need to read/write to an I2C device behind the scenes whenever the bitfield attributes are accessed. i.e. something like...
- Sat Sep 21, 2019 2:04 am
- Forum: General Discussion and Questions
- Topic: Is it OK to subclass memoryview?
- Replies: 2
- Views: 1932
Is it OK to subclass memoryview?
CPython doesn't allow subclassing memoryview: >>> class MyMV(memoryview): ... pass ... Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: type 'memoryview' is not an acceptable base type but MicroPython does: >>> class MyMV(memoryview): ... pass >>> I'm curious if anyb...
- Thu Sep 12, 2019 9:59 pm
- Forum: General Discussion and Questions
- Topic: Private const() variables aren't defined
- Replies: 8
- Views: 5206
Re: Private const() variables aren't defined
Thanks for the explanations! Each statement executed on the REPL kind of like making a file containing that statement and compiling it. I didn't realize this was how the REPL worked. For anyone else coming across this later, this example makes it pretty clear: >>> _B = const(2) >>> _B Traceback (mos...
- Wed Sep 11, 2019 4:51 pm
- Forum: General Discussion and Questions
- Topic: Private const() variables aren't defined
- Replies: 8
- Views: 5206
Private const() variables aren't defined
Can someone help me understand why private const() variables aren't defined?
Code: Select all
>>> A = const(1)
>>> A
1
>>> _B = const(2)
>>> _B
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name '_B' isn't defined
- Thu Aug 22, 2019 9:56 pm
- Forum: General Discussion and Questions
- Topic: Best practices for debug and logging output in library modules
- Replies: 6
- Views: 12304
Re: Best practices for debug and logging output in library modules
FYI, I think the if __debug__ logic in your code is backwards, i.e. should be: try: if __debug__: import logging logger = logging.getLogger(__name__) else: logger = None except ImportError: logger = None The more elaborate approach also requires the check for isEnabledFor before any call to logger.d...
- Thu Aug 22, 2019 5:17 am
- Forum: General Discussion and Questions
- Topic: Best practices for debug and logging output in library modules
- Replies: 6
- Views: 12304
Re: Best practices for debug and logging output in library modules
@stijn thanks for the reply. I should have mentioned I'm already using the logging.py module from micropython-lib which essentially does what I need it to do from a debug perspective. The main issue I was originally trying to get at in my OP was how to handle the fact that logging.py may or may not ...