-
Notifications
You must be signed in to change notification settings - Fork 61
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.
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
TF-1627 Update same_query_across_sites example #35
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's update the output printing code, pls
|
||
def print_header(): | ||
"""Prints the header for the data table""" | ||
print(f"{'Website':<25} | {'Product ':<20} | {'Price ':<20} ") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use https://pypi.org/project/prettytable/
to not reinvent the wheel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little hesitant to use prettytable
library here because it's not included in Python standard library and requires pip install prettytable
. I guess it depends on what kind of customer journey we want to provide to users. If we expect users to find this example through link on our documentation website and then copy / paste the code into their project. Then any extra setup requirement would create an issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a matter of providing clear instructions. In reality people would not use our code to print tables, they probably won't print tables to console at all, tbh. You can rewrite this code in a shape of preparing the data first (which everyone can copy-paste, and then outputting them second (which can be ignored).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood! You're absolutely right that people would not print tables. In this case, I will probably remove the outputting table part entirely. Because I feel like even with clear instructions, there will be a fairly large amount of users who will just copy/paste the code, run it, find out the code does not work, and then try to figure out what's going on. And the purpose of these examples is just to demonstrate the core functionality of AgentQL.
browser = playwright.chromium.launch(headless=False) | ||
|
||
# Create a new AgentQL page instance in the browser for web interactions | ||
page: Page = browser.new_page() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix the linter, pls
{ | ||
price | ||
} | ||
}""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
}""" | |
} | |
""" |
print_header() | ||
|
||
with sync_playwright() as playwright: | ||
browser = playwright.chromium.launch(headless=False) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not specific to this example, but what do you think about moving browser creation into with block as well, to automanage it as a resource?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's a good idea and will save users the pain of both creating browser and stopping browser.
But to do this, we probably need to create our own context manager API that wraps around the launch() method to make it work in both sync and async environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works out of the box
python3 compare_product_prices.py | ||
``` | ||
|
||
## Play with it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This heading can be confusing. First heading is "Run the script", second "Play with it" reads like "Play with the script". What about "Play with the query"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a great suggestion!
# Use query_data() method to fetch the price from the BestBuy page | ||
response = page.query_data(PRODUCT_INFO_QUERY) | ||
|
||
print_row("BestBuy", "Nintendo Switch", response["nintendo_switch"]["price"]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should fix the source of these check failures
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working together on this. Loving it
All comments addressed and unnecessary table output has been removed
This fixes TF-1627
This PR fixed
same_query_across_sites.py
example, which shows how to compare price across websites with AgentQL synchronously (we have another async example). Nothing changed significantly in this PR other than making it use the new Smart Locator API.