Optimization of a simple lazy load for an attribute in Python - python-3.x

This is the property definition I use to lazy load the element attribute of my Element class, borrowed from This post on Python lazy loading.
#property
def element(self):
if not hasattr(self, "_element"):
self._element = self.wait.wait_for_element_to_be_visible(self.locator)
return self._element
It looks for the attribute _element if it doesn't find it then it goes and looks for it. If the attribute is there then it just returns the attribute without looking for it as its already been loaded in.
I've changed the if to be:
if self._element is None:
self._element = self.wait.wait_for_element_to_be_visible(self.locator)
return self._element
Is it more pythonic to see if the attribute exists, or to set _element to None in the __init__ method and then check for that instead?
Doing it the second way also seems better for debugging purposes in IntelliJ as there seems to be a strange loading issue that freezes the tests if I expand my Element object and it starts introspection to display attributes and their values.

My definition of a pythonic solution is the one that's most likely to help a future maintainer understand what's going on when they come across this code (most times it's the same person who wrote it but long after they have it in their memory). Here's some things I might ask myself if I was coming in cold.
1. hasattr
self._element is not in __init__, is this because it's set somewhere else?
Every access checks for the attribute, does that mean it's expecting it to be deleted at some point so it can refresh? Why else is it checked every time?
hasattr will search up the chain of MRO, are we actually looking for something?
2. is None
Found self._element in __init__ being set to None. Am I allowed to set it to None again to get fresh values? The _ in _element is hinting no.
2a. is _Missing
If None is a valid result, use a sentinel instead.
class _Missing:
pass
def __init__():
self._element = _Missing
3. One shot descriptor
Property produces what is known as a data descriptor. It will ignore attributes of the instance and go straight to the classes dictionary (otherwise __set__ won't be able to do it's thing). Here we make our own non-data descriptor (only defines __get__), which won't skip the instances dictionary. This means the instances attribute can be set. Deleting the instance attribute will result in a refreshed value on the next invocation.
class LazyLoadElement:
def __get__(self, instance, owner):
instance.element = instance.wait.wait_for_element_to_be_visible(instance.locator)
return instance.element
class MyClass:
element = LazyLoadElement()
What's the intention of the LazyLoadElement? Name says it all
Can it refresh to another value? Nope, it's set after the first call and removes itself.
Pythonic is a little arm wavy because it needs to make assumptions about who is reading the code at a future date. Out of the 2 original options, number 2 seems most likely to get maintainers up to speed. 3 is my fav though, mainly because once it's loaded there's no more function calls.

Related

Building a good class method

I've built a class to ask a user a question, based on a type.
class Question:
def __init__(self, subject):
self.subject = subject
self.question = f"Enter the {subject} to be created. You may end this by typing 'DONE':\n"
self.still_needed = True
def ask_question(self):
ans_list = []
running = True
while running:
var = input(f"Enter {self.subject}?\n")
if var.lower() == 'done':
running = False
else:
ans_list.append(var)
return ans_list
The idea is to have a question model, to create lists of items.
This seems to work well with the following code in main.
roles = Question(subject="role").ask_question()
This creates a list from the Queue Class and uses it's method ask question to generate the list. As far as I can tell the object is then destroyed, as it's not saved to a variable.
My question, being new to Python and OOP is, does this seem like a solid and non-confusing way, or should I refractor? If so, what does the community suggest?
MY OPINION
I guess it depends on you. For one, one of the main purposes of using a class is to create an instance with it later on. Classes are objects ,or "categories" as I like to call them, that you use when there are distinctive types of instances in your project.
Given your code snippet, I can't really suggest anything, I don't know the usage of self.question and self.still_needed. However, if I were to base my opinion on just this part: roles = Question(subject="role").ask_question(), then I'd definitely go with using a function instead. As you've said,
As far as I can tell the object is then destroyed, as it's not saved
to a variable.
ALTERNATIVE SOLUTION
Use decorators → the one with # symbol
In this case, #staticmethod is the way to go!
What are staticmethods? The staticmethod decorator is a way to create a function in a class. So instead of it becoming a method, it can be treated as a function (without self parameter). This also means that a static method bounds to the class rather than its object. Consequently, static methods do not depend on objects (hence, you don't need to create an object for you to use it). Example:
class SomeMathStuff():
#staticmethod
def AddSomeNumbers(iterable):
return sum(iterable)
result = SomeMathStuff.AddSomeNumbers([1, 2, 3])
# result = 6
As you can see, I did not need to create an object, instead I just needed to call its class to use it. Word of warning, most Python programmers argue that this is the un-Pythonic way, but I wouldn't worry too much about it. Hell, even I use these methods sometimes. In my defense, this is a good and efficient way to organize your project. With this, you can apply class methods globally and you can "categorize" them in certain classes you find suitable.
Anyway, this is all I have! I apologize if I misinformed you in any way.
ADDITIONAL INFROMATION ... in case I wasn't the best teacher
https://www.programiz.com/python-programming/methods/built-in/staticmethod
Difference between staticmethod and classmethod
https://softwareengineering.stackexchange.com/questions/171296/staticmethod-vs-module-level-function

Making return type of python optional

In JVM languages there is a data type called Optional which says value can be Null/None. By using the data type of a function as Option(for example Option(Int)). Calling statement of function can take action.
How does one implement a similar approach in Python.
I want to create a function and the return value of function should tell me
1. Function was successful so I have a value returned.
2. Function was not successful and so there is nothing to return.
I also wanted to tackle this problem and made a library called optional.py to do so. It can be installed using pip install optional.py. It is fully test covered and supports python2 and python3. Would love some feedback, suggestions, contributions.
To address the concerns of the other answer, and to head off any haters, yes, raising exceptions is more idiomatic of python, however it leads to ambiguity between exceptions for control-flow and exceptions for actual exceptional reasons.
There are large discussions about preventing defensive programming which mask the core logic of an application and smart people on both sides of the conversation. My personal preference is towards using optionals and so I provided the library to support that preference. Doing it with exceptions (or returning None) are acceptable alternatives, just not my preference.
To your original question: Raise an exception instead of returning None. This is an idiom in Python and therefore well understood by users. For example
def get_surname(name):
if name == "Monty":
return "Python"
else:
raise KeyError(name)
You'll see this usage pattern a lot in Python:
try:
print(get_surname("foo"))
except KeyError:
print("Oops, no 'foo' found")
Based on your feedback, it also seemed like you wanted to make sure that certain return values are actually used. This is quite tricky, and I don't think there is an elegant way to enforce this in Python, but I'll give it a try.
First, we'll put the return value in a property so we can track if it has indeed been read.
class Result(object):
def __init__(self, value):
self._value = value
self.used = False
#property
def value(self):
self.used = True # value was read
return self._value
Secondly, we require that the Result object must be retrieved in a with-block. When the block is exited (__exit__), we check if the value has been read. To handle cases where a user doesn't use the with-statement, we also check that the value has been read when it is being garbage collected (__del__). An exception there will be converted into a warning. I usually shy away from __del__ though.
class RequireUsage(object):
def __init__(self, value):
self._result = Result(value)
def __enter__(self):
return self._result
def __exit__(self, type, value, traceback):
if type is None: # No exception raised
if not self._result.used:
raise RuntimeError("Result was unused")
def __del__(self):
if not self._result.used:
raise RuntimeError("Result was unused (gc)")
To use this system, simply wrap the return value in RequireUsage like so:
def div2(n):
return RequireUsage(n/2)
To use such functions, wrap them in a block and extract the value:
with div2(10) as result:
print(result.value)
If you don't invoke result.value anywhere, you will now get an exception:
with div2(10) as result:
pass # exception will be thrown
Likewise, if you just call div2 without with at all, you will also get an exception:
div2(10) # will also raise an exception
I wouldn't particularly recommend this exact approach in real programs, because I feel it makes usage more difficult while adding little. Also, there are still edge-cases that aren't covered, like if you simply do res = div2(10), because a held reference prevents __del__ from being invoked.
One approach would be to return either () or (<type>,) (int in your case). You could then come up with some helper functions like this one:
def get_or_else(option: tuple, default):
if option:
return option[0]
else:
return default
One benefit of this approach is that you don't need to depend on a third-party library to implement this. As a counterpart, you basically have to make your own little library.

Python - GUI checkbox cannot assign the function with arguments to variable

I'm having trouble getting my head around assigning a function to a variable when the function uses arguments. The arguments appear to be required but no matter what arguments I enter it doesn't work.
The scenario is that I'm creating my first GUI which has been designed in QT Designer. I need the checkbox to be ticked before the accept button allows the user to continue.
Currently this is coded to let me know if ticking the checkbox returns anything (which is does) however I don't know how to pass that result onto the next function 'accept_btn'. I thought the easiest way would be to create a variable however it requires positional arguments and that's where I'm stuck.
My code:
class MainWindow(QtWidgets.QMainWindow, Deleter_Main.Ui_MainWindow):
def __init__(self):
super(MainWindow, self).__init__()
self.setupUi(self)
self.ConfirmBox.stateChanged.connect(self.confirm_box)
self.Acceptbtn.clicked.connect(self.accept_btn)
def confirm_box(self, state):
if self.ConfirmBox.isChecked():
print("checked")
else:
print("not checked")
checked2 = confirm_box(self, state)
def accept_btn(self):
if checked2 == True:
print("clicked")
else:
print("not clicked")
app = QApplication(sys.argv)
form = MainWindow()
form.show()
app.exec_()
The code gets stuck on 'checked2' with the error:
NameError: name 'self' is not defined
I thought there might be other solutions for running this all within one function but I can't seem to find a way whilst the below is required.
self.ConfirmBox.stateChanged.connect(self.confirm_box)
Would extra appreciate if anyone could help me understand exactly why I need the 'self' argument in the function and variable.
Thanks in advance,
If you just need to enable a button when the checkbox is checked, it can be easily done within the signal connection:
self.ConfirmBox.toggled.connect(self.Acceptbtn.setEnabled)
QWidget.setEnabled requires a bool argument, which is the argument type passed on by the toggled signal, so the connection is very simple in this case.
Apart from this, there are some mistakes in your understanding of classes in Python: it seems like you are thinking in a "procedural" way, which doesn't work well with general PyQt implementations and common python usage, unless you really need some processing to be done when the class is created, for example to define some class attributes or manipulate the way some methods behave. But, even in this case, they will be class attributes, which will be inherited by every new instance.
The line checked2 = confirm_box(self, state) will obviously give you an error, since you are defining checked2 as a class atribute. This means that its value will be processed and assigned when the class is being created: at this point, the instance of the class does not exist yet, Python just executes the code that is not part of the methods until it reaches the end of the class definition (its primary indentation). When it reaches the checked2 line, it will try to call the confirm_box method, but the arguments "self" and "state" do not exist yet, as they have not been defined in the class attributes, hence the NameError exception.
Conceptually, what you have done is something similar to this:
class SomeObject(object):
print(something)
This wouldn't make any sense, since there is no "something" defined anywhere.
self is a python convention used for class methods: it is a keyword commonly used to refer to the instance of a class, you could actually use any valid python keyword at all.
The first argument of any class method is always the reference to the class instance, the only exceptions are classmethod and staticmethod decorators, but that's another story. When you call a method of an instanciated class, the instance object is automatically bound to the first argument of the called method: the self is the instance itself.
For example, you could create a class like this:
class SomeObject(object):
def __init__(Me):
Me.someValue = 0
def setSomeValue(Myself, value):
Myself.someValue = value
def multiplySomeValue(I, multi):
I.setSomeValue(I.someValue * multi)
return I.someValue
But that would be a bit confusing...

Knowing the context/scope at instantiation time

Is there any way to know the context in which an object is instantiated? So far I've been searching and tried inspect module (currentcontext) with poor results.
For example
class Item:
pass
class BagOfItems:
def __init__(self):
item_1 = Item()
item_2 = Item()
item_3 = Item()
I'd want to raise an exception in the instantiation of item_3 (because its outside a BagOfItems), while not doing so in item_1 and item_2. I dont know if a metaclass could be a solution to this, since the problem occurs at instantiation not at declaration.
The holder class (BagOfItems) can't implement the check because when Item intantiation happens outside it there would be no check.
When you instantiate an object with something like Item(), you are basically doing type(Item).__call__(), which will call Item.__new__() and Item.__init__() at some point in the calling sequence. That means that if you browse up the sequence of calls that led to Item.__init__(), you will eventually find code that does not live in Item or in type(Item). Your requirement is that the first such "context" up the stack belong to BagOfItem somehow.
In the general case, you can not determine the class that contains the method responsible for a stack frame1. However, if you make your requirement that you can only instantiate in a class method, you are no longer working with the "general case". The first argument to a method is always an instance of the class. We can therefore move up the stack trace until we find a method call whose first argument is neither an instance of Item nor a subclass of type(Item). If the frame has arguments (i.e., it is not a module or class body), and the first argument is an instance of BagOfItems, proceed. Otherwise, raise an error.
Keep in mind that the non-obvious calls like type(Item).__call__() may not appear in the stack trace at all. I just want to be prepared for them.
The check can be written something like this:
import inspect
def check_context(base, restriction):
it = iter(inspect.stack())
next(it) # Skip this function, jump to caller
for f in it:
args = inspect.getargvalues(f.frame)
self = args.locals[args.args[0]] if args.args else None
# Skip the instantiating calling stack
if self is not None and isinstance(self, (base, type(base))):
continue
if self is None or not isinstance(self, restriction):
raise ValueError('Attempting to instantiate {} outside of {}'.format(base.__name__, restriction.__name__))
break
You can then embed it in Item.__init__:
class Item:
def __init__(self):
check_context(Item, BagOfItems)
print('Made an item')
class BagOfItems:
def __init__(self):
self.items = [Item(), Item()]
boi = BagOfItems()
i = Item()
The result will be:
Made an item
Made an item
Traceback (most recent call last):
...
ValueError: Attempting to instantiate Item outside of BagOfItems
Caveats
All this prevents you from calling methods of one class outside the methods of another class. It will not work properly in a staticmethod or classmethod, or in the module scope. You could probably work around that if you had the motivation. I have already learned more about introspection and stack tracing than I wanted to, so I will call it a day. This should be enough to get you started, or better yet, show you why you should not continue down this path.
The functions used here might be CPython-specific. I really don't know enough about inspection to be able to tell for sure. I did try to stay away from the CPython-specific features as much as I could based on the docs.
References
1. Python: How to retrieve class information from a 'frame' object?
2. How to get value of arguments passed to functions on the stack?
3. Check if a function is a method of some object
4. Get class that defined method
5. Python docs: inspect.getargvalues
6. Python docs: inspect.stack

Sharing variable between QWizard pages in Pyside/PyQt

I am building a QWidget in PySide, and running into an issue when trying to share data between pages.
To summarize I utilize user inputs from earlier pages to construct a list of custom objects, which I need to share with the following page.
At the beginning of my code I construct a custom object, with an attribute called .name (among other attributes)
class MyCustomClass():
def __init__(self, name, other_attributes)
self.name = name
...set other attributes
In my QWizard I open a file and make a list of names to match with another list of MyCustomClass objects. I then display the names alongside the matched name of the corresponding MyCustomClass object and prompt the user to confirm (or change), before moving to the next page.
Each match is stored as a tuple(name, MyCustomClass) and added to a list. I then wish to read this list from the next page in order to perform more operations. I'm trying to use .registerField, but I'm unsure of how to properly do so. My attempt is below.
First I make a QWizardPage, perform some code and then construct my matches. I made a function to return the value and used this for the .registerField
class ConfirmMatches(QWizardPage):
def __init__(self):
...
def initializePage(self):
# Code to make display and operations and make list of matches
...
self.matches = matches
self.registerField("matches", self, "get_matches")
def get_matches(self):
return self.matches
Then from my next page, I try to call the field, but I only return a None object.
class NextPage(QWizardPage):
def __init__(self):
...
def initializePage(self):
# Get relevant fields from past pages
past_matches = self.field("matches")
type(past_matches) is None, even though when I print self.matches in the previous page it clearly displays them all.
What am I doing wrong with the registerField?
Is there an easier way to share this type of data between pages?
I actually solved it myself. I was on the right track, just missing a few things, but I'll catalog here for anyone else with similar problems.
Like I said I have a list of matched objects, where each match is a list of a name, and the object that was found to correspond to that name, i.e. match = [name, MyCustomClass]
class ConfirmMatches(QWizardPage):
# Function to change list
def setList(self, new_list):
self.list_val = new_list
if self.list_val != []:
self.list_changed.emit()
# Function to return list
def readList(self):
return self.list_val
def __init__(self):
self.list_val = [] # Create initial value
# Code to initialize displays/buttons, and generate matches
...
# Here I assign the matches I made "matches", to the QProperty "match_list"
self.setList(matches)
# Then register field here.
# Instead of the read function, I call the object itself (not sure why, but it works)
self.registerField("registered_list", self, "match_list")
# Define "match_list" as a QProperty with read and write functions, and a signal (not used)
match_list = Property(list, readList, setList)
listChanged = Signal()
I made the list a QProperty and wrote the Read and Write functions, as well as a Signal (not used). Then, when registering the field, instead of putting the Read function (readList), I put the QProperty itself (match_list). Not sure why it works, but this conceivable could be used to register other custom objects.
If you want to explicitly set the value of the field matches in your ConfirmMatches page, you would need to do one of a few things:
Make an explicit call to self.setField any time your matches change.
Emit a signal every time your matches are changed after registering the property
Store your matches in one of the standard Qt inputs, like QLineEdit, and use that widget in the registerField call.
If you check the docs for QWizardPage.registerField, what it does is register to grab the named property of the passed in widget when the widget's signal is emitted. The way your code is now, you would need to add a signal to your ConfirmMatches page that would be emitted whenever your matches variable changes. Otherwise, your page doesn't know when the field should be updated.

Resources