Feeds

Ben Cook: Saving Utility Companies Years with Computer Vision

Planet Python - Wed, 2024-01-03 13:15

How do utility companies monitor thousands of miles of electrical wire to find small imperfections that threaten the entire system? For the entire history of electrical infrastructure, the only answer has been ‘very slowly.’

Now, Sparrow’s computer vision capabilities, combined with Fast Forward’s thermal imaging system, can accomplish what used to take over a decade in less than a month. Here’s how they do it.

How it Started

Dusty Birge, CEO of Fast Forward began inspecting power lines using a drone and crowd-sourced labor. He knew that automation would be needed to take the next step forward, but he found people in the artificial intelligence space to be overconfident and unreliable. That is until he was introduced to Ben Cook, the founder of Sparrow Computing.

Within a month, Ben provided a computer vision model that could accurately identify utility poles, and that has been continually improving ever since.

The Project

Fast Forward rigged a system of 5 thermal cameras to a car and set them to take photos every 15 feet. Sparrow’s computer vision model then ran through the nearly 2 million photos taken and extracted about 50,000 relevant images, detecting any abnormalities in the utility lines.

“Right out of the gate, we presented data to the utilities and just blew them away,” Dusty said in an interview. “The first test runs proved a scalable model that automatically monitored a company’s entire system in under a month, where traditional methods would take over a decade. These test runs successfully spotted anomalies that would have caused blackouts, but were instead able to be fixed promptly.”

The numbers speak plainly for themselves, not just in time but in cost as well. There was one hotspot that Sparrow identified, but that the utility company did not address in time. The power line failed as a result, costing the company around $800. The inspection itself cost only $4. The potential return of this technology is astronomical, and it is already being put to good use.

Going Forward

Fast Forward is already looking ahead to the next phase of this project, translating the same process to daytime cameras. Having had such success in the initial tests, Dusty is pleased to continue working with Ben and Sparrow Computing.

Ben is excited to find more real world problems that can be solved as cameras become cheaper and more ubiquitous. He wants to create more computer vision models that interact with the physical environment and revolutionize companies throughout the Midwest and the world.

To get a closer look at Sparrow Computing, reach Ben at ben@sparrow.dev.

The post Saving Utility Companies Years with Computer Vision appeared first on Sparrow Computing.

Categories: FLOSS Project Planets

Mirek Długosz: Playwright - accessing page object in event handler

Planet Python - Wed, 2024-01-03 12:37

Playwright exposes a number of browser events and provides a mechanism to respond to them. Since many of these events signal errors and problems, most of the time you want to log them, halt program execution, or ignore and move on. Logging is also shown in Playwright documentation about network, which I will use as a base for examples in this article.

Problem statement

Documentation shows event handlers created with lambda expressions, but lambda poses significant problems once you leave the territory of toy examples:

  • they should fit in single line of code
  • you can’t share them across modules
  • you can’t unit test them in isolation

Usually you want to define event handlers as normal functions. But when you attempt that, you might run into another problem - Playwright invokes event handler with some event-related data, that data does not contain any reference back to page object, and page object might contain some important contextual information.

In other words, we would like to do something similar to code below. Note that this example does not work - if you run it, you will get NameError: name 'page' is not defined.

from playwright.sync_api import sync_playwright from playwright.sync_api import Playwright def request_handler(request): print(f"{page.url} issued request: {request.method} {request.url}") def response_handler(response): print(f"{page.url} received response: {response.status} {response.url}") def run_test(playwright: Playwright): browser = playwright.chromium.launch() page = browser.new_page() page.goto("https://mirekdlugosz.com") page.on("request", request_handler) page.on("response", response_handler) page.goto("https://httpbin.org/status/404") browser.close() with sync_playwright() as playwright: run_test(playwright)

I can think of three ways of solving that: by defining a function inside a function, with functools.partialand with a factory function. Let’s take a look at all of them.

Defining a function inside a function

Most Python users are so used to defining functions at the top level of module or inside a class (we call these “methods”) that they might consider function definitions to be somewhat special. In fact, some other programming languages do encumber where functions can be defined. But in Python you can define them anywhere, including inside other functions.

from playwright.sync_api import sync_playwright from playwright.sync_api import Playwright def run_test(playwright: Playwright): def request_handler(request): print(f"{page.url} issued request: {request.method} {request.url}") def response_handler(response): print(f"{page.url} received response: {response.status} {response.url}") browser = playwright.chromium.launch() page = browser.new_page() page.goto("https://mirekdlugosz.com") page.on("request", request_handler) page.on("response", response_handler) page.goto("https://httpbin.org/status/404") browser.close() with sync_playwright() as playwright: run_test(playwright)

This works because function body is not evaluated until function is called and functions have access to names defined in their encompassing scope. So Python will look up page only when event handler is invoked by Playwright; since it’s not defined in function itself, Python will look for it in the function where event handler was defined (and then next function, if there is one, then module and eventually builtins).

I think this solution solves the most important part of the problem - it allows to write event handlers that span multiple lines. Technically it is also possible to share these handlers across modules, but you won’t see that often. They can’t be unit tested in isolation, as they depend on their parent function.

functools.partial

functools.partial documentation may be confusing, as prose sounds exactly like a description of standard function, code equivalent assumes pretty good understanding of Python internals, and provided example seems completely unnecessary.

I think about partial this way: it creates a function that has some of the arguments already filled in.

To be fair, partial is rarely needed. It allows to write shorter code, as you don’t have to repeat the same arguments over and over again. It may also allow you to provide saner library API - you can define single generic and flexible function with a lot of arguments, and few helper functions intended for external use, each with a small number of arguments.

But it’s invaluable when you have to provide your own function, but you don’t have control over arguments it will receive. Which is exactly the problem we are facing.

from functools import partial from playwright.sync_api import sync_playwright from playwright.sync_api import Playwright def request_handler(request, page=None): print(f"{page.url} issued request: {request.method} {request.url}") def response_handler(response, page=None): print(f"{page.url} received response: {response.status} {response.url}") def run_test(playwright: Playwright): browser = playwright.chromium.launch() page = browser.new_page() page.goto("https://mirekdlugosz.com") local_request_handler = partial(request_handler, page=page) local_response_handler = partial(response_handler, page=page) page.on("request", local_request_handler) page.on("response", local_response_handler) page.goto("https://httpbin.org/status/404") browser.close() with sync_playwright() as playwright: run_test(playwright)

Notice that our function takes the same arguments as Playwright event handler, and then some. When it’s time to assign event handlers, we use partial to create a new function, one that only needs argument that we will receive from Playwright - the other one is already filled in. But when function is executed, it will receive both arguments.

Factory function

Functions in Python may not only define other functions in their bodies, but also return functions. They are called “higher-order functions” and aren’t used often, with one notable exception of decorators.

from playwright.sync_api import sync_playwright from playwright.sync_api import Playwright def request_handler_factory(page): def inner(request): print(f"{page.url} issued request: {request.method} {request.url}") return inner def response_handler_factory(page): def inner(response): print(f"{page.url} received response: {response.status} {response.url}") return inner def run_test(playwright: Playwright): browser = playwright.chromium.launch() page = browser.new_page() page.goto("https://mirekdlugosz.com") page.on("request", request_handler_factory(page)) page.on("response", response_handler_factory(page)) page.goto("https://httpbin.org/status/404") browser.close() with sync_playwright() as playwright: run_test(playwright)

The key here is that inner function has access to all of enclosing scope, including values passed as arguments to outer function. This allows us to pass specific values that are only available in the place where outer function is called.

Summary

The first solution is a little different than other two, because it does not solve all of the problems set forth. On the other hand, I think it’s the easiest to understand - even beginner Python programmers should intuitively grasp what is happening and why.

In my experience higher-order functions takes some getting used to, while partial is not well-known and may be confusing at first. But they do solve our problem completely.

Categories: FLOSS Project Planets

Programiz: Python Dictionary

Planet Python - Wed, 2024-01-03 11:22
In this tutorial, you will learn about Python dictionaries - how they are created, how to access, add, and remove elements from them, and the various built-in methods associated with dictionaries.
Categories: FLOSS Project Planets

Programiz: Python for loop

Planet Python - Wed, 2024-01-03 10:58
In this article, we'll learn how to use a for loop in Python with the help of examples.
Categories: FLOSS Project Planets

Real Python: Python's Magic Methods: Leverage Their Power in Your Classes

Planet Python - Wed, 2024-01-03 09:00

As a Python developer who wants to harness the power of object-oriented programming, you’ll love to learn how to customize your classes using special methods, also known as magic methods or dunder methods. A special method is a method whose name starts and ends with a double underscore. These methods have special meanings for Python.

Python automatically calls magic methods as a response to certain operations, such as instantiation, sequence indexing, attribute managing, and much more. Magic methods support core object-oriented features in Python, so learning about them is fundamental for you as a Python programmer.

In this tutorial, you’ll:

  • Learn what Python’s special or magic methods are
  • Understand the magic behind magic methods in Python
  • Customize different behaviors of your custom classes with special methods

To get the most out of this tutorial, you should be familiar with general Python programming. More importantly, you should know the basics of object-oriented programming and classes in Python.

Get Your Code: Click here to download the free sample code that shows you how to use Python’s magic methods in your classes.

Getting to Know Python’s Magic or Special Methods

In Python, special methods are also called magic methods, or dunder methods. This latter terminology, dunder, refers to a particular naming convention that Python uses to name its special methods and attributes. The convention is to use double leading and trailing underscores in the name at hand, so it looks like .__method__().

Note: In this tutorial, you’ll find the terms special methods, dunder methods, and magic methods used interchangeably.

The double underscores flag these methods as core to some Python features. They help avoid name collisions with your own methods and attributes. Some popular and well-known magic methods include the following:

Special Method Description .__init__() Provides an initializer in Python classes .__str__() and .__repr__() Provide string representations for objects .__call__() Makes the instances of a class callable .__len__() Supports the len() function

This is just a tiny sample of all the special methods that Python has. All these methods support specific features that are core to Python and its object-oriented infrastructure.

Note: For the complete list of magic methods, refer to the special method section on the data model page of Python’s official documentation.

The Python documentation organizes the methods into several distinct groups:

Take a look at the documentation for more details on how the methods work and how to use them according to your specific needs.

Here’s how the Python documentation defines the term special methods:

A method that is called implicitly by Python to execute a certain operation on a type, such as addition. Such methods have names starting and ending with double underscores. (Source)

There’s an important detail to highlight in this definition. Python implicitly calls special methods to execute certain operations in your code. For example, when you run the addition 5 + 2 in a REPL session, Python internally runs the following code under the hood:

Python >>> (5).__add__(2) 7 Copied!

The .__add__() special method of integer numbers supports the addition that you typically run as 5 + 2.

Reading between the lines, you’ll realize that even though you can directly call special methods, they’re not intended for direct use. You shouldn’t call them directly in your code. Instead, you should rely on Python to call them automatically in response to a given operation.

Note: Even though special methods are also called magic methods, some people in the Python community may not like this latter terminology. The only magic around these methods is that Python calls them implicitly under the hood. So, the official documentation refers to them as special methods instead.

Magic methods exist for many purposes. All the available magic methods support built-in features and play specific roles in the language. For example, built-in types such as lists, strings, and dictionaries implement most of their core functionality using magic methods. In your custom classes, you can use magic methods to make callable objects, define how objects are compared, tweak how you create objects, and more.

Note that because magic methods have special meaning for Python itself, you should avoid naming custom methods using leading and trailing double underscores. Your custom method won’t trigger any Python action if its name doesn’t match any official special method names, but it’ll certainly confuse other programmers. New dunder names may also be introduced in future versions of Python.

Magic methods are core to Python’s data model and are a fundamental part of object-oriented programming in Python. In the following sections, you’ll learn about some of the most commonly used special methods. They’ll help you write better object-oriented code in your day-to-day programming adventure.

Controlling the Object Creation Process

When creating custom classes in Python, probably the first and most common method that you implement is .__init__(). This method works as an initializer because it allows you to provide initial values to any instance attributes that you define in your classes.

Read the full article at https://realpython.com/python-magic-methods/ »

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

Categories: FLOSS Project Planets

PyCharm: How To Learn Django: A Comprehensive Guide for Beginners

Planet Python - Wed, 2024-01-03 05:56
Learning Django can be an exciting journey for anyone looking to develop web applications, but it can be intimidating at first. In this article, we’ll provide you with a comprehensive guide on how to learn Django effectively. We’ll explore the prerequisites, the time it takes to become proficient, and various resources to help you master […]
Categories: FLOSS Project Planets

CTI Digital: Drupal Core Major Upgrades

Planet Drupal - Wed, 2024-01-03 05:41

Over the past 12 months, our teams have completed numerous Drupal upgrades. We would like to share our experiences and knowledge with anyone who has yet to undergo this process to help make it smoother for you.

Categories: FLOSS Project Planets

Pages