I’m new to Anvil, Python and coding in general (have done a bunch of no-code stuff like Bubble, Parabola, etc).
Just worked my way through the Feedback Form Tutorial. I noticed that **kwargs are used in the client side methods to allow for any number of arguments to be accepted, but they’re not used in the server side functions.
Client side code…
from ._anvil_designer import Form1Template
from anvil import *
import anvil.server
import anvil.tables as tables
import anvil.tables.query as q
from anvil.tables import app_tables
class Form1(Form1Template):
def __init__(self, **properties):
# Set Form properties and Data Bindings.
self.init_components(**properties)
# Any code you write here will run before the form opens.
def submit_button_click(self, **event_args):
"""This method is called when the button is clicked"""
name = self.name_box.text
email = self.email_box.text
feedback = self.feedback_box.text
recommend=self.recommend_box.selected_value
anvil.server.call('add_feedback', name, email, feedback, recommend)
Notification('Feedback submitted!').show()
self.clear_inputs()
def clear_inputs(self):
self.name_box.text = ''
self.email_box.text = ''
self.feedback_box.text = ''
Server side code…
import anvil.email
import anvil.tables as tables
import anvil.tables.query as q
from anvil.tables import app_tables
import anvil.server
from datetime import datetime
@anvil.server.callable
def add_feedback(name, email, feedback, recommend):
app_tables.feedback.add_row(
name=name,
email=email,
feedback=feedback,
recommend=recommend,
created=datetime.now()
)
anvil.email.send(
to='joe@test.com',
subject=f'Feedback from {name}',
text=f'A new person has filled out this form. Name: {name}, Email address: {email}'
)
As a Python newbie I’m curious as to why **kwargs weren’t used in the server side functions as well. Seems like it would be simpler to just use them in every function/method so that any number of arguments can always be accepted, but I’m guessing there’s a specific reason why they weren’t used in the server side functions.
If anyone can shine some light on that reason for me, that’d be much appreciated.
There are specific reasons for those client-side **kwargs. It’s not considered good practice to use **kwargs for a function with known, defined arguments. Then it’s better to make explicit what arguments are needed. The reason for the **event_args for event handlers (of which a button click handler is an example) is that events can be made to send custom keyword arguments to the event handler. I’ll admit I don’t understand the **properties in the Form __init__ quite as well. I think item is usually the only property.
Perhaps the underlying reason is that using **kwargs makes it easier for Anvil to auto-generate code via the drag-and-drop designer?
Others can probably explain more and better, but hopefully that helps a little.
The first two methods are self documented, you know what to pass, you are not going to be wrong. The third method doesn’t tell you what’s going to happen or what’s expecting, and you could get it wrong.
Event definitions are another beast. You don’t call them, the framework will call them, you just define them. And often when you define them, you don’t care about the arguments, you only care that the event is called.
The list of arguments could be explicitly defined in events too, but your event definition may be incompatible with the next release, if Anvil decides to update the framework and passes one more argument to the function, for example when they decide to add compatibility to a new device that provides more parameters for the same event.
I like to explicitly list the arguments I actually use, but I still leave **kwargs because I don’t know if the framework passes more arguments today and I don’t know if it will add even more tomorrow. For example here, rather than using kwargs['sender'], I do:
If you follow closely what @hugetim and @stefano.menci said, you will notice that there is a theme, when you write computer code there are a ton of ways to do something, which in many languages, following a certain way is usually referred to as a “style”.
This way people who all follow the same style can easily use each others code. In the past this has lead to balkanization of styles and reduces interoperability and makes it harder for people to work together.
What if you don’t all read the same style guide books? What if you only follow the latest? The oldest?
One of the feature points of python is the style is built into the language and “accepted practice” is reached by consensus and guidance from some of the leaders who build python.
The “style” (if you can still call it that) is called pythonic, and it has a very few core rules but include things like readability, so other people (most importantly including future you) are able to read your code and know what it does at a glance.
Using **kwargs everywhere would make it very hard for anyone else to know what the function does, or how to use it if they don’t have the entire function right in front of them.
So you can do anything you want, but then again, nobody would stop you from supergluing all your Legos together. You would find they might want to tell you it’s not the greatest idea.
Here is a pythonic easter egg poem, hidden inside python, that gives you the general ideas:
