DEV Community: Soumendra Kumar Sahoo

Prompt vs Context vs Harness vs Loop Engineering

Soumendra Kumar Sahoo — Sun, 21 Jun 2026 08:14:58 +0000

One night my AI agent Hermes, which I run 24/7 on my own hardware, spent 47 turns trying to "fix" a script. Every turn it ran the same broken command, got the same error, apologized and tried again. I sat there watching the token counter climb like a Tatkal queue at 10 AM, and I genuinely could not tell what had gone wrong. Was the prompt bad? Was it missing context? Was a tool broken? Was the loop just never going to stop? I am an AI Observability Architect, and I was staring at my own agent unable to name which layer had failed.

That night is what this post is about. A production AI agent is not one skill, it is five, and when something breaks at 2 AM you need to know exactly which one to blame.

Everyone talks about prompt engineering. Fewer people talk about context engineering. Almost nobody talks about harness, loop or evaluation engineering, even though they're the difference between a demo that works once and a system that survives a night alone on my server.

An AI observability architect who doesn't understand the full stack of agent engineering is just a person who reads dashboards. So I sat down and split it into the five disciplines that actually make up a production agent: what each one is, how they differ and how they fit together.

The Five Disciplines

Before the definitions, one metaphor ties all five together: a worker doing a job at a workbench. I reuse it for every discipline so the boundaries stay sharp.

Prompt is the job description pinned to the wall: what to do and how to do it.
Context is the briefing packet on the desk: the facts for this one task, not the whole library.
Harness is the workbench and the tools bolted to it: what the worker can physically reach and operate, plus the safety guards.
Loop is the work rhythm: do a step, check the result, decide the next step and know when to down tools.
Evaluation is the QA inspector who checks finished pieces and reports trends.

Keep that worker in your head. The whole post hangs off it.

1. Prompt Engineering

What it is: Writing the instructions that tell the model what to do, how to do it, and what format to return.

The job: Craft system prompts, few-shot examples, output format constraints, and chain-of-thought scaffolding that produce reliable outputs from the model. There are different styles of prompting (zero-shot, few-shot, chain-of-thought, tree-of-thought) and different techniques (role prompting, constraint prompting, format prompting) that can be combined in various ways.

What you're optimizing for:

Output quality,
Instruction adherence,
Format consistency,
Token efficiency of the prompt itself.

Failure mode:

Over-prompting.
A 2000-token system prompt that tries to cover every edge case but degrades model performance because the model loses focus on what matters. Hermes' system prompt is 200+ lines, and I have learned the hard way that every rule I add to squash one bug quietly makes three others more likely.

Example: "You are a Python debugging assistant. Given a traceback and the relevant code, identify the root cause and suggest a fix. Always output: 1) Root cause, 2) Fix (as a code block), 3) Explanation. Do not hallucinate functions that don't exist in the code."

2. Context Engineering

What it is: Deciding what information goes into the model's context window and in what order.

In the metaphor: the briefing packet you hand the worker for this task. Not the whole library, just the pages that matter right now.

The job: Build retrieval pipelines (RAG), manage conversation history, compress old context, inject relevant documents, and structure the information so the model can use it effectively.

What you're optimizing for:

Retrieval precision,
Context window utilization,
Signal-to-noise ratio,
Cost per query (fewer irrelevant tokens = lower cost).

Failure mode:

Context stuffing.
Dumping 100K tokens of "relevant" documents into the context window when the model only needs 5K. The model gets distracted, costs spike, and quality drops. My first version of Hermes' memory shoved everything it had ever seen into context, and the bill at the end of the month taught me restraint faster than any blog post could.

Example: Instead of passing an entire 500-page PDF, you chunk it into sections, embed each chunk, retrieve the top-5 most relevant sections based on the query, and inject only those, with a summary of what was excluded so the model knows the full document exists.

3. Harness Engineering

What it is: Building the infrastructure that wraps the model, tool definitions, API integrations, execution environments, and safety rails.

In the metaphor: the workbench, the power tools and the safety guards. It is what the worker can reach and operate, nothing more. This is the static part: it exists before the agent runs a single step.

The job: Define the tool schemas the model can call. Wire up the terminal, file system, web browser, and external APIs. Enforce permissions, rate limits, and sandboxing. Handle retries, timeouts, and error recovery.

What you're optimizing for:

Tool call reliability,
Execution safety,
Latency,
Breadth of capabilities available to the agent.

Failure mode: The agent calls a tool that doesn't exist, or a tool that exists but returns an error the model can't interpret. The agent spirals into retry loops or hallucinates a successful outcome. Half of Hermes' early "successes" were it cheerfully telling me a task was done while the tool had actually thrown a stack trace it never bothered to read.

Example: Defining a read_file tool with a clear schema (path: string, offset: int, limit: int), a check_fn that verifies the file exists before the tool is exposed to the model, and an error handler that returns structured JSON the model can act on instead of a raw stack trace.

4. Loop Engineering

What it is: Designing the agent's reasoning loop, how it decides what to do next, when to stop, and when to ask for help.

In the metaphor: the work rhythm. If the harness is the machine on the bench, the loop is the worker pressing "go" again and again, checking the result each time, until the piece is finished or the foreman gets called. This is the dynamic part: it only exists while the agent is running.

Peter Steinberger, the creator of OpenClaw, put the same idea more provocatively in June 2026: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." His framing adds a sharp point I love: a good loop corrects itself against objective signals (tests, type checkers, linters, runtime errors) rather than against your patience. That is the difference between an agent that runs while you sleep and one that needs you babysitting every turn.

The job: Choose the loop pattern (ReAct, Plan-and-Execute, Tree of Thoughts). Set the max turns. Implement context compression when the conversation gets long. Decide when the agent should pause for human approval vs. proceed autonomously.

What you're optimizing for:

Task completion rate,
Loop efficiency (fewer turns for the same outcome),
Autonomous depth,
Graceful degradation when the agent gets stuck.

Failure mode:

Infinite loops.
The agent calls a tool, gets an unexpected result, retries with the same approach, gets the same result, and burns through 50 turns without progress. This is the exact 47-turn night from the top of this post: pure Loop Engineering failure.
Or the opposite: the agent stops too early, declaring success when the task is half-done.

Example: A ReAct loop that caps at 90 turns, compresses context at 50% utilization, and falls back to asking the user for clarification after 3 consecutive failed tool calls on the same sub-task.

5. Evaluation Engineering

What it is: Designing the systems that tell you whether the other four are working.

The job: Build eval datasets. Configure LLM-as-a-Judge pipelines. Run regression tests on every model change. Aggregate scores, track trends, and set alerting thresholds for quality degradation.

What you're optimizing for:

Evaluation accuracy (does the eval correlate with real quality?),
Evaluation cost (are you spending more on eval than on the agent itself?),
Signal timeliness (how fast do you learn about a regression?).

Failure mode:

Evaluating the wrong thing.
A judge model that scores "helpfulness" but actually rewards verbosity. Or a regression suite that passes every time because the test cases are too easy. You feel confident while quality silently degrades. This is the failure that scares me the most, because unlike the 47-turn night, it makes no noise at all.

Example: A Langfuse evaluator that classifies every agent trace by query type (coding, research, ops), scores output quality on a 1-5 rubric, and alerts when the research query quality score drops below 3.5 for two consecutive days.

How are Context, Harness, and Loop different?

This is the part that trips everyone up, including me. Prompt and Evaluation are easy to tell apart. The blur is between Context, Harness and Loop, because all three feel like "stuff around the model." Here is the cleanest way I have found to separate them.

One word each

Discipline	One word	The question it answers
Context	KNOW	What does the model get to see?
Harness	DO	What can the model actually touch in the real world?
Loop	DECIDE	How many times, in what order, and when does it stop?

Or, borrowing a line I like from LangChain: prompt shapes behavior, context shapes reasoning, harness shapes execution. The loop is the slice of execution that repeats.

The same bug, three different owners

Here is the trick that finally made it click. Take one task, "fix the failing test," and one symptom, "the agent didn't fix it." Who gets paged depends entirely on why:

It never saw the test file or the error output. Context bug: the knowledge was missing.
It had no run_tests tool, or the tool crashed. Harness bug: the capability was missing.
It saw the file, ran the test once, ignored the red and quit (or looped 50 times getting nowhere). Loop bug: the decision was missing.

Same task. Same surface failure. Three different engineers fix it. Once you can sort a failure into KNOW, DO or DECIDE, the blur is gone.

Harness vs Loop: the machine and the "go" button

Harness and Loop blur the most, so be precise. Honestly, the industry itself is not fully settled here: LangChain treats the loop as one component inside the harness, while others treat Loop Engineering as a separate layer on top. The split I use:

Harness is the static part. Everything that exists before the agent runs: tool schemas, sandbox, file system, permissions, guard rails. The machine on the bench.
Loop is the dynamic part. The act, observe, decide, repeat cycle plus the stopping condition. The worker pressing "go" on that machine until the goal is met.

The one-liner that sticks: the harness runs the agent once, the loop runs the harness until the job is done.

One agent turn, three zones

Forget the big architecture diagram for a second. Here is a single turn of the agent, with each discipline owning exactly one segment:

They do not overlap. Context is the arrow going in. Harness is the arrow going out to the world and back. Loop is the circle plus the exit gate. That is the whole difference in one picture.

Side-by-Side Comparison

Dimension	Prompt Engineering	Context Engineering	Harness Engineering	Loop Engineering	Evaluation Engineering
What you build	Instructions for the model	Information pipeline into the model	Tool infrastructure around the model	Reasoning cycle for the model	Measurement system over the model
Core artifact	System prompt, few-shot examples	RAG pipeline, context compressor, chunking strategy	Tool schemas, API adapters, sandbox	Agent loop (ReAct, Plan-Execute, ToT)	Eval datasets, judge prompts, score dashboards
Key question	"What should the model do?"	"What does the model need to know?"	"What can the model do?"	"How does the model decide what to do next?"	"Is the model actually doing it well?"
Optimizes for	Output quality, instruction adherence	Signal-to-noise ratio, retrieval precision	Tool reliability, execution safety	Task completion, loop efficiency	Evaluation accuracy, regression detection
Failure mode	Over-prompting, instruction dilution	Context stuffing, retrieval noise	Tool errors, missing safety rails	Infinite loops, premature stopping	False confidence, measuring the wrong thing
Measured by	Eval scores, format compliance	Retrieval precision/recall, token cost	Tool call success rate, latency	Turn count, completion rate	Judge-human agreement, alert precision
When it breaks	Outputs are wrong format, off-topic	Model hallucinates from missing context	Agent can't act on its environment	Agent gets stuck or loops forever	You don't know quality is degrading
Who typically owns it	Prompt engineer, ML engineer	RAG engineer, data engineer	Platform engineer, infra engineer	Agent engineer, ML engineer	AI observability engineer, QA engineer
Maturity in industry	High (everyone does it)	Medium (RAG is mainstream)	Growing (agent frameworks emerging)	Early (most teams have simple loops)	Lowest (most teams skip it entirely)

How They Fit Together

Each discipline feeds into the next, and Evaluation wraps around all of them. Here's what a production AI agent system looks like when all five are in place, from the user's question to the final answer:

For better resolution image, please check the OG post

The dotted arrows are the key insight. Evaluation Engineering doesn't just sit at the end, it feeds back into every other discipline. When eval scores drop, you don't know which layer is broken until you instrument all five.

What Happens When You Skip One?

I've seen each of these failure modes in production. They're not hypothetical.

Skip This	What Happens
Prompt Engineering	Model outputs inconsistent formats, ignores constraints, hallucinates expected behavior
Context Engineering	Model answers from stale or irrelevant information. Token costs 5-10x higher than necessary
Harness Engineering	Agent can't interact with the real world. Every tool call is a potential crash
Loop Engineering	Agent runs forever on simple tasks, or stops too early on complex ones
Evaluation Engineering	You ship a model update and quality drops 20% and nobody notices for a week

Evaluation Engineering is the most skipped and the most dangerous to skip. Every other discipline has a visible failure mode, the output is wrong, the agent crashes, costs spike. Evaluation failure is invisible. Everything looks fine until a user complains.

Where Is the Industry?

Most teams today are at different maturity levels for each discipline: Prompt Engineering is high (everyone does it), Context Engineering is medium (RAG is mainstream), Harness Engineering is growing, Loop Engineering is early, and Evaluation Engineering is the lowest, often skipped entirely.

The gap between Prompt Engineering (everyone does it) and Evaluation Engineering (almost nobody does it well) is where most production AI systems fail silently. This is also where the most interesting work is happening right now, LLM-as-a-Judge, automated regression pipelines, and observability-driven development.

How I Apply This

I run an AI agent (Hermes) 24/7 on my own infrastructure. Here's how the five disciplines map to real decisions I make:

Prompt Engineering: My agent's system prompt is 200+ lines defining its role, constraints, and output format. I tweak it when eval scores drop, not when I "feel like" the output is off.
Context Engineering: My agent has persistent memory (user preferences, environment facts, session history). I manage a memory budget, when it hits 8000 chars, older entries are compressed or pruned. Context window management is a real engineering problem.
Harness Engineering: My agent has access to terminal, file system, web browser, and 50+ tools. Each tool has a check_fn that verifies requirements before the tool is exposed to the model. Destructive commands require approval.
Loop Engineering: Max 90 turns per session. Auto-compress context at 50% utilization. Fallback to user clarification after consecutive failures. I've tuned these numbers over months of watching the agent get stuck and unstuck.
Evaluation Engineering: I'm building an LLM-as-a-Judge pipeline in Langfuse that scores every agent trace. This is how I know whether my prompt changes actually improve output quality or just shift the failure modes.

The Bottom Line

If you're building AI systems, you're doing all five of these whether you call them "engineering" or not. The question is whether you're doing them deliberately.

Prompt Engineering is table stakes. Context Engineering is where most teams spend their RAG effort. Harness Engineering is where agent frameworks add value. Loop Engineering is where most teams have the most room to grow. Evaluation Engineering is where most teams are flying blind.

If you can't measure it, you can't improve it. Start with Evaluation Engineering, even a simple LLM-as-a-Judge over your existing traces will tell you more about your system than months of intuition.

Why should you use attrs more

Soumendra Kumar Sahoo — Tue, 20 Aug 2024 01:51:15 +0000

Introduction

Python's attrs library is a game-changer for developers looking to simplify class creation and reduce boilerplate code. This libray is even trusted by NASA.
Created by Hynek Schlawack in 2015, attrs has quickly become a favorite tool among Python developers for its ability to automatically generate special methods and provide a clean, declarative way to define classes.
dataclasses is a kind of subset of attrs.

Why attrs is useful:

Reduces boilerplate code
Improves code readability and maintainability
Provides powerful features for data validation and conversion
Enhances performance through optimized implementations

2. Getting Started with attrs

Installation:
To get started with attrs, you can install it using pip:

pip install attrs

Basic usage:
Here's a simple example of how to use attrs to define a class:

import attr

@attr.s
class Person:
    name = attr.ib()
    age = attr.ib()

# Creating an instance
person = Person("Alice", 30)
print(person)  # Person(name='Alice', age=30)

3. Core Features of attrs

a. Automatic method generation:

attrs automatically generates init, repr, and eq methods for your classes:

@attr.s
class Book:
    title = attr.ib()
    author = attr.ib()
    year = attr.ib()

book1 = Book("1984", "George Orwell", 1949)
book2 = Book("1984", "George Orwell", 1949)

print(book1)  # Book(title='1984', author='George Orwell', year=1949)
print(book1 == book2)  # True

b. Attribute definition with types and default values:

import attr
from typing import List

@attr.s
class Library:
    name = attr.ib(type=str)
    books = attr.ib(type=List[str], default=attr.Factory(list))
    capacity = attr.ib(type=int, default=1000)

library = Library("City Library")
print(library)  # Library(name='City Library', books=[], capacity=1000)

c. Validators and converters:

import attr

def must_be_positive(instance, attribute, value):
    if value <= 0:
        raise ValueError("Value must be positive")

@attr.s
class Product:
    name = attr.ib()
    price = attr.ib(converter=float, validator=[attr.validators.instance_of(float), must_be_positive])

product = Product("Book", "29.99")
print(product)  # Product(name='Book', price=29.99)

try:
    Product("Invalid", -10)
except ValueError as e:
    print(e)  # Value must be positive

4. Advanced Usage

a. Customizing attribute behavior:

import attr

@attr.s
class User:
    username = attr.ib()
    _password = attr.ib(repr=False)  # Exclude from repr

    @property
    def password(self):
        return self._password

    @password.setter
    def password(self, value):
        self._password = hash(value)  # Simple hashing for demonstration

user = User("alice", "secret123")
print(user)  # User(username='alice')

b. Frozen instances and slots:

@attr.s(frozen=True) # slots=True is the default
class Point:
    x = attr.ib()
    y = attr.ib()

point = Point(1, 2)
try:
    point.x = 3  # This will raise an AttributeError
except AttributeError as e:
    print(e)  # can't set attribute

c. Factory functions and post-init processing:

import attr
import uuid

@attr.s
class Order:
    id = attr.ib(factory=uuid.uuid4)
    items = attr.ib(factory=list)
    total = attr.ib(init=False)

    def __attrs_post_init__(self):
        self.total = sum(item.price for item in self.items)

@attr.s
class Item:
    name = attr.ib()
    price = attr.ib(type=float)

order = Order(items=[Item("Book", 10.99), Item("Pen", 1.99)])
print(order)  # Order(id=UUID('...'), items=[Item(name='Book', price=10.99), Item(name='Pen', price=1.99)], total=12.98)

5. Best Practices and Common Pitfalls

Best Practices:

Use type annotations for better code readability and IDE support
Leverage validators for data integrity
Use frozen classes for immutable objects
Take advantage of automatic method generation to reduce code duplication

Common Pitfalls:

Forgetting to use @attr.s decorator on the class
Overusing complex validators that could be separate methods
Not considering the performance impact of extensive use of factory functions

6. attrs vs Other Libraries

Library	Features	Performance	Community
attrs	Automatic method generation, attribute definition with types and default values, validators and converters	Better performance than manual code	Active community
pydantic	Data validation and settings management, automatic method generation, attribute definition with types and default values, validators and converters	Good performance	Active community
dataclasses	Built into Python 3.7+, making them more accessible	Tied to the Python version	Built-in Python library

attrs and dataclasses are faster than pydantic¹.

Comparison with dataclasses:

attrs is more feature-rich and flexible
dataclasses are built into Python 3.7+, making them more accessible
attrs has better performance in most cases
dataclasses are tied to the Python version, while attrs as an external library can be used with any Python version.

Comparison with pydantic:

pydantic is focused on data validation and settings management
attrs is more general-purpose and integrates better with existing codebases
pydantic has built-in JSON serialization, while attrs requires additional libraries

When to choose attrs:

For complex class hierarchies with custom behaviors
When you need fine-grained control over attribute definitions
For projects that require Python 2 compatibility (though less relevant now)

7. Performance and Real-world Applications

Performance:
attrs generally offers better performance than manually written classes or other libraries due to its optimized implementations.

Real-world example:

from attr import define, Factory
from typing import List, Optional

@define
class Customer:
    id: int
    name: str
    email: str
    orders: List['Order'] = Factory(list)

@define
class Order:
    id: int
    customer_id: int
    total: float
    items: List['OrderItem'] = Factory(list)

@define
class OrderItem:
    id: int
    order_id: int
    product_id: int
    quantity: int
    price: float

@define
class Product:
    id: int
    name: str
    price: float
    description: Optional[str] = None

# Usage
customer = Customer(1, "Alice", "alice@example.com")
product = Product(1, "Book", 29.99, "A great book")
order_item = OrderItem(1, 1, 1, 2, product.price)
order = Order(1, customer.id, 59.98, [order_item])
customer.orders.append(order)

print(customer)

8. Conclusion and Call to Action

attrs is a powerful library that simplifies Python class definitions while providing robust features for data validation and manipulation. Its ability to reduce boilerplate code, improve readability, and enhance performance makes it an invaluable tool for Python developers.

Community resources:

GitHub repository: https://github.com/python-attrs/attrs
Documentation: https://www.attrs.org/
PyPI page: https://pypi.org/project/attrs/

Try attrs in your next project and experience its benefits firsthand. Share your experiences with the community and contribute to its ongoing development. Happy coding!

https://stefan.sofa-rockers.org/2020/05/29/attrs-dataclasses-pydantic/ ↩

Production Readiness Checklist

Soumendra Kumar Sahoo — Sun, 04 Aug 2024 09:13:58 +0000

I have been working on multiple pojects where I have moved applications from PoC to Production.
These are the checklists I have prepared for myself and my team to ensure we are ready for production.
Here the checklists are in focus as the application is in Python programming language and deployed to AWS via Kubernetes.
Not all of these are mandatory, but they are the ones I have found most useful.

1. Alerts & Metrics

[ ] Are there alerts set up for infrastructure issues (e.g., memory or CPU usage increase, service unavailability)?
[ ] Are there alerts set up for critical application-specific logic failures?
[ ] Can we view historical data (past few hours/days) of infrastructure and resource usage?
[ ] Is there a real-time monitoring dashboard in place?

2. Dashboard and SOP

[ ] Is there an SOP document for handling alerts and known issues?
[ ] Are there runbooks available for common scenarios?
[ ] Is there an incident response plan in place?

3. On-call mapping and cadence

[ ] Is there an on-call person mapping for application-level issues?
[ ] Is there an on-call person mapping for infrastructure-related issues?
[ ] Is there a defined rotation schedule and escalation policy?

4. Deployment

[ ] Has the appropriate instance type (GPU or CPU) been determined?
[ ] Has the required server type been specified?
[ ] Is there multi-availability zone support for failover?
[ ] Is there support for multiple regions?
[ ] Is auto-scaling set up (e.g., HPA, Keda) for traffic spikes?
[ ] Are health checks configured for the server?
[ ] Have resource limits been defined and documented?
[ ] Is there a blue-green or canary deployment strategy in place?
[ ] Is there a defined rollback plan and procedure?

5. Observability and tracing

[ ] Is there a dashboard showing relevant metrics (e.g., request count, HTTP status codes, usage)?
[ ] Can we trace a single request end-to-end for debugging purposes?
[ ] Is there a log aggregation and analysis system in place?
[ ] Is distributed tracing implemented?

6. Load tests

[ ] Has capacity planning been performed to determine the server's load handling capabilities?
[ ] Are there defined performance benchmarks?
[ ] Has stress testing been conducted?

7. Quality

[ ] Are there automated unit tests?
[ ] Are there automated integration tests?
[ ] Is static code analysis (e.g., complexity checks) performed?
[ ] Is code coverage measured and at an acceptable level?
[ ] Are there production sanity test cases?
[ ] Is there a CI/CD pipeline in place?
[ ] Are security scans and vulnerability assessments performed regularly?

8. Release

[ ] Is Swagger/OpenAPI documentation available and up-to-date?
[ ] Is there a versioning system for APIs and releases?
[ ] Is there an established communication channel for scheduled maintenance?
[ ] Is there a change management process?
[ ] Are feature flags used for gradual rollout of new features?

9. Disaster Recovery and Business Continuity

[ ] Are backup and restore procedures in place and tested?
[ ] Is there a data replication strategy?
[ ] Have Recovery Time Objective (RTO) and Recovery Point Objective (RPO) been defined?
[ ] Are regular disaster recovery drills conducted?

10. Compliance and Security

[ ] Is data encrypted at rest and in transit?
[ ] Are access control and authentication mechanisms in place?
[ ] Are regular security audits conducted?
[ ] Does the application comply with relevant industry standards (e.g., GDPR, HIPAA)?

11. Documentation

[ ] Is system architecture documentation available and up-to-date?
[ ] Is API documentation complete and current?
[ ] Are operational procedures documented?
[ ] Is there a comprehensive troubleshooting guide?

@property in Python

Soumendra Kumar Sahoo — Fri, 24 Mar 2023 09:25:11 +0000

Introduction

Sure! Here's an introduction to Python's @property decorator with code snippets:

In Python, a decorator is a special function that can modify other functions' behavior. You can think of decorators as a way to "wrap" one function with another. This can be useful for adding functionality to functions without changing their code.

One built-in decorator in Python is @property, which is used with the property() function. Here's an example that shows how you can use @property to define a read-only property for a class:
```
class Circle:
    def __init__(self, radius):
        self._radius = radius

    @property
    def radius(self):
        return self._radius

c = Circle(5)
print(c.radius) # 5
c.radius = 10 # AttributeError: can't set attribute
```
In this example, we define a class Circle with a private attribute _radius. We then use the @property decorator to define a method radius() that returns the value of _radius. When we create an instance of Circle, we can access the value of _radius using the .radius property. However, since we haven't defined a setter method for .radius, trying to set its value will result in an error.
Use Cases

Here's an explanation of why you should use @property with example usages:

Using the @property decorator can be helpful in several ways when defining properties in a class. Here are some examples:
1. Encapsulation: By using @property, you can control access to an attribute by defining getter, setter, and deleter methods. This allows you to hide the implementation details of an attribute and only expose a public interface for accessing it.
```
class Circle:
    def __init__(self, radius):
        self._radius = radius

    @property
    def radius(self):
        return self._radius

c = Circle(5)
print(c.radius) # 5
```
In this example, we define a class Circle with a private attribute _radius. We then use the @property decorator to define a method radius() that returns the value of _radius. When we create an instance of Circle, we can access the value of _radius using the .radius property.
1. Validation: You can use the setter method to validate the value being assigned to an attribute. For example, you can check if the value is within a specific range or meets certain conditions before assigning it.
```
class Circle:
    def __init__(self, radius):
        self._radius = radius

    @property
    def radius(self):
        return self._radius

    @radius.setter
    def radius(self, value):
        if value < 0:
            raise ValueError("Radius cannot be negative")
        self._radius = value

c = Circle(5)
print(c.radius) # 5
c.radius = -1 # ValueError: Radius cannot be negative
```
In this example, we define a class Circle with a private attribute _radius. We then use the @property decorator to define a method radius() that returns the value of _radius, and the .setter decorator to define a method radius() that sets the value of _radius .
1. Ease of use: Using @property makes it easy to define properties without manually calling the property() function. This can make your code more readable and easier to understand.
```
class Circle:
    def __init__(self, radius):
        self._radius = radius

    def get_radius(self):
        return self._radius

    def set_radius(self, value):
        if value < 0:
            raise ValueError("Radius cannot be negative")
        self._radius = value

    radius = property(get_radius, set_radius)

c = Circle(5)
print(c.radius) # 5
c.radius = -1 # ValueError: Radius cannot be negative
```
In this example, we define a class Circle with a private attribute _radius. We then define methods get_radius() and set_radius() for getting and setting the value of _radius. We use the property() function to create a property .radius that uses these methods.

This code achieves the same result as the previous example but is less readable and harder to understand. Using @property makes it easier to define properties more intuitively.

Overall, using @property can help you write cleaner and more maintainable code when defining properties in a class.
Syntax and Examples

This example shows how you can use @property, along with the .setter and .deleter decorators to define a property with getter, setter, and deleter methods:
```
class Circle:
    def __init__(self, radius):
        self._radius = radius

    @property
    def radius(self):
        return self._radius

    @radius.setter
    def radius(self, value):
        if value < 0:
            raise ValueError("Radius cannot be negative")
        self._radius = value

    @radius.deleter
    def radius(self):
        del self._radius

c = Circle(5)
print(c.radius) # 5
c.radius = 10
print(c.radius) # 10
del c.radius
```
In this example, we define a class Circle with a private attribute _radius. We then use the @property decorator to define a method radius() that returns the value of _radius. We also use the .setter decorator to define a method radius() that sets the value of _radius, and the .deleter decorator to define a method radius() that deletes _radius.

When we create an instance of Circle, we can access and modify the value of _radius using the .radius property. We can also delete _radius using the del statement.
Conclusion

Key points and benefits of using @property:

* `@property` is a decorator that can be used to define properties in a class.
* It allows you to control access to an attribute by defining getter, setter, and deleter methods.
* Using `@property` can help you achieve encapsulation by hiding the implementation details of an attribute and only exposing a public interface for accessing it.
* You can use the setter method to validate the value being assigned to an attribute before assigning it.
* Using `@property` makes it easy to define properties without manually calling the `property()` function. This can make your code more readable and easier to understand.

Overall, using `@property` can help you write cleaner and more maintainable code when defining properties in a class.

First published on my primary blog.

Usage of backward slash (\) in Python

Soumendra Kumar Sahoo — Sat, 10 Dec 2022 05:55:53 +0000

In Python, the backslash (\) character is used for several purposes, such as:

To specify escape sequences, like \n for a newline, \t for a tab, etc.
To escape special characters - the backward slash is used to escape special characters such as quotation marks and newline characters in strings. For example:

# escaping special characters in a string

my_string = "This is a string with a \"quotation mark\" and a newline character \n in it"
print(my_string)

To split a string into multiple lines by using the \ character at the end of each line. For example, the following code will print hello world on two lines:

# continuing a line of code

print("This is a very long line of code that cannot fit on one line" \
      "so we are using the backward slash to continue it on the next line")

It's important to note that in Python, the backslash character is used for escaping characters, and it is not the same as the forward slash (/) character, which is used for division. For example, the following code will print 5.0:

print(10 / 2)

You may further be interested in:

Usage of forward slash (/) in Python

Soumendra Kumar Sahoo — Tue, 06 Dec 2022 04:48:12 +0000

In Python, the forward-slash (/) has several different uses depending on the context in which it appears. Some of the main uses of the forward slash in Python include:

Division

When used between two numeric values, the forward slash performs division.
For example, 10 / 3 evaluates to 3.3333333333333335.

>>> 10/3
3.3333333333333335

Floor division

When used between two numeric values, the forward slash followed by another forward slash (//) performs floor division, which rounds the result down to the nearest integer.
For example, 10 / 3 evaluates to 3, and 10 // 3 evaluates to 3.

>>> 10//3
3

Paths

In strings, the forward slash is often used as a separator in file paths or URLs.
For example:

path = "C:/Users/john/Documents/file.txt"
url = "https://www.example.com/path/to/resource"

Regular expressions

In regular expressions, the forward slash is often used to escape special characters. For example:

import re

pattern = r"\d+/\d+/\d+"
text = "The date is 01/01/2021"
match = re.search(pattern, text)

Thanks for reading, you can further check:

This article was first published here.

Factory Design Pattern

Soumendra Kumar Sahoo — Thu, 01 Dec 2022 12:51:33 +0000

There are several design patterns that are commonly used in Python programming. Some of the most common design patterns include:

Singleton: This design pattern ensures that a class has only one instance, and provides a global point of access to it.
Factory: This design pattern provides a way to create objects without specifying the exact class of object that will be created.
Adapter: This design pattern allows classes with incompatible interfaces to work together by wrapping the original class and providing a new interface.
Decorator: This design pattern allows new functionality to be added to an existing object without modifying its structure.
Observer: This design pattern allows objects to observe and react to changes in other objects.
Strategy: This design pattern allows the behavior of an algorithm to be changed at runtime.
Template: This design pattern defines the skeleton of an algorithm, allowing subclasses to provide specific implementation details.
Command: This design pattern allows you to encapsulate a request as an object, separating the request from the object that executes it.

These are just a few examples of the many design patterns that are available in Python. There are many more design patterns that can be used to solve common programming problems in Python, and choosing the right design pattern for a given situation can help to make your code more maintainable and scalable.

The factory design pattern is a popular object-oriented programming technique in Python. It is used to create new objects, hiding the complexity of object creation from the user. This allows for a more flexible and modular approach to object creation, as well as promoting code reuse.

The factory design pattern works by defining a factory class that is responsible for creating objects. The factory class has a method, typically called create(), that takes in the necessary parameters for creating an object and returns the newly created object. The user of the factory class does not need to know the details of how the object is created, they just call the create() method and get back the new object.

One of the key benefits of using the factory design pattern is that it allows for the creation of objects without specifying their exact class. This means that the factory can be used to create different types of objects, depending on the input provided to the create() method. This is useful when working with systems that may have different implementations of the same concept, such as different types of vehicles in a transportation application.

Another benefit of the factory design pattern is that it promotes code reuse. Since the factory class abstracts away the details of object creation, it can be used to create objects of different types without duplicating code. This means that the code for creating objects can be centralized in the factory class, making it easier to maintain and update.

To illustrate how the factory design pattern works in Python, let's consider a simple example. Suppose we have a Vehicle class that represents different types of vehicles, such as cars and trucks. We can use the factory design pattern to create instances of the Vehicle class by defining a VehicleFactory class.

class Vehicle:
    def __init__(self, type, model, year):
        self.type = type
        self.model = model
        self.year = year

class VehicleFactory:
    @staticmethod
    def create(type, model, year):
        if type == 'car':
            return Car(model, year)
        elif type == 'truck':
            return Truck(model, year)

class Car(Vehicle):
    def __init__(self, model, year):
        super().__init__('car', model, year)

class Truck(Vehicle):
    def __init__(self, model, year):
        super().__init__('truck', model, year)

# create a car using the factory
car = VehicleFactory.create('car', 'Honda Civic', 2021)

# create a truck using the factory
truck = VehicleFactory.create('truck', 'Ford F-150', 2020)

In this example, the VehicleFactory class has a create() method that takes in the type, model, and year of the vehicle to be created. Depending on the type provided, the create() method creates and returns an instance of either the Car or Truck class, which inherit from the Vehicle class. This allows us to create different types of vehicles without specifying their exact class, and without duplicating code for creating objects.

In conclusion, the factory design pattern is a useful technique in Python programming for creating objects in a flexible and modular way. It can help you to create a more scalable and maintainable codebase by abstracting away the details of object creation and allowing for a more flexible approach to object creation.

Disclaimer: The above text is generated by the chat GPT

Follow me on Twitter soumendrak for more such posts.

This post was first published on: https://blog.soumendrak.com/factory-design-pattern

Learn Python Programming

Soumendra Kumar Sahoo — Tue, 08 Nov 2022 09:46:10 +0000

Python has been around since the 90s and an enormous amount of content is there to learn Python. While this is good for any language this creates information overload and decision paralysis in learning in a structured manner.
Note: There is no official certification for Python programming

Here is a list of materials to help beginners in Python programming:

Interactive way

Here you can try on coding on the browser itself without installing anything.

Books

A more extensive list of books can be found at awesome python books

Courses

Programming for Everybody

Videos

Programming with Mosh : 6hr long Python course
Corey Schafer : Python short tutorials
Intellipaat: Python long tutorials in Hindi and all
freeCodeCamp: 12 beginner Python projects
NeuralNine: Python beginner, intermediate and advanced playlists
RealPython: Python tips and tricks
sentdex: Python beginner to advanced tutorials.
clearCode: Learn Python by making games

For more search awesome Youtube visit awesome-youtubers

Tutorials

Project-based learning
Much more can be found at Ultimate Python

Newsletters

Newsletters usually published weekly keep you up to date on the latest developments in the Python world.

Podcasts

If you are a podcast person, here is a list of podcasts related to Python.

This list will be updated from time to time whenever required.
Follow soumendrak_ for more such contents.

Aggregate Code timing in Python

Soumendra Kumar Sahoo — Wed, 20 Jul 2022 03:53:17 +0000

There are many ways to get how much time a function takes in Python. Here is an easy decorator implementation to check how much time a function takes.

from functools import wraps
import time


def timeit(func):
    @wraps(func)
    def timeit_wrapper(*args, **kwargs):
        start_time = time.perf_counter()
        result = func(*args, **kwargs)
        end_time = time.perf_counter()
        total_time = end_time - start_time
        print(f'Function {func.__name__}{args} {kwargs} took {total_time:.4f} seconds')
        return result
    return timeit_wrapper

@timeit
def my_func():
    # do stuff

This decorator can be used by decorating a function to get the time spent.
What if you want to aggregate this timing data in a timeframe, like how many times this function has been called, and what the maximum time is taken, for that, we need to use a library called codetiming.
Here is a sample use case:

# pip install codetiming
# pip install humanfriendly
from codetiming import Timer
from humanfriendly import format_timespan
from loguru import logger


@Timer(name="my_func", text=lambda secs: f"my_func elapsed time: {format_timespan(secs)}")
def my_func():
    ...

def get_aggregated_timings(cls):
    timed_function = "my_func"
    logger.info(
        f"\n{timed_function} count: {Timer.timers.count(timed_function)}\n"
        f"total: {Timer.timers.total(timed_function)}\n"
        f"max: {Timer.timers.max(timed_function)}\n"
        f"min: {Timer.timers.min(timed_function)}\n"
        f"mean: {Timer.timers.mean(timed_function)}\n"
        f"standard deviation: {Timer.timers.stdev(timed_function)}\n"
        f"median: {Timer.timers.median(timed_function)}\n"
    )
    Timer.timers.clear()  # clears all the timer data

This will find the aggregated time spent by my_func. Let's go through what each one of them will log:

count: Number of times the function has been called.
total: Sum of all the seconds elapsed in the function
max: Maximum time spent on a single flow
min: Minimum time spent on a single flow
mean: The average of all the time spent on that function
median: The median of all elapsed time
stdev: The standard deviation of all elapsed time

At the end Timer.timers.clear() clears the data stored In memory and starts from fresh for the next iteration.

Do you want to use an in-memory LRU cache with a timeout, you may check out this article:

Cache functions with timeout

I post on Python programming on my Twitter handle, you can follow me @soumendrak_

Originally posted at: my blog

Top Software Engineering Blogs

Soumendra Kumar Sahoo — Sun, 17 Jul 2022 05:58:00 +0000

This is a growing collection of blogs by software companies that you can read to get Engineering practices and Software Architecture ideas.

You can download this Bookmarks file and import it into your browser.

Python vs Golang vs Rust

Soumendra Kumar Sahoo — Tue, 17 May 2022 07:23:42 +0000

Test scenario

I have taken the Two sum problem from Leetcode.

The problem statement:

Given an array of integers nums and an integer target, return indices of the two numbers such that they add up to target.

You may assume that each input would have exactly one solution, and you may not use the same element twice.

You can return the answer in any order.

Example 1:

Input: nums = [2,7,11,15], target = 9
Output: [0,1]
Explanation: Because nums[0] + nums[1] == 9, we return [0, 1].

Example 2:

Input: nums = [3,2,4], target = 6
Output: [1,2]

Example 3:

Input: nums = [3,3], target = 6
Output: [0,1]

Constraints:
2 <= nums.length <= 104
-109 <= nums[i] <= 109
-109 <= target <= 109
Only one valid answer exists.

Implementation

I have used a hash map to solve this problem across all three languages.

Python

class Solution:
    def twoSum(self, nums: List[int], target: int) -> List[int]:
        hash_table = {}
        for i, num in enumerate(nums):
            target_num = target - num
            if num in hash_table:
                return i, hash_table[num]
            else:
                hash_table[target_num] = i
        return None

Python stats

Run time: 40ms
Memory usage: 14.5 MB

Golang

func twoSum(nums []int, target int) []int {
    hashMap := make(map[int] int)
    for i := 0; i < len(nums); i++{
        if _, found := hashMap[nums[i]]; found {
            ans := []int{i, hashMap[nums[i]]}
            return ans
        } else {
            hashMap[target- nums[i]]= i
        }
    }
    return nil
}

Golang stats

Run time: 4ms
Memory usage: 4.3 MB

Rust

use std::collections::HashMap;
impl Solution {
    pub fn two_sum(nums: Vec<i32>, target: i32) -> Vec<i32> {
        let mut hash_table: HashMap<i32, i32> = HashMap::new();
    for i in 0..nums.len() {
        // println!("Processing number: {}", nums[i]);
        match hash_table.get(&nums[i]){
            Some(&x) => return vec![x, i as i32],
            None => hash_table.insert(target - nums[i], i as i32),
        };
    };
    return vec![-1, -1]
    }
}

Rust stats

Run time: 2ms
Memory usage: 2.2 MB

Conclusion

As per the results, Rust took the least memory and was the fastest of all three.

For more such insights follow me on Twitter.
Original post: Hashnode

When to stop code refactoring

Soumendra Kumar Sahoo — Sun, 17 Jan 2021 13:32:56 +0000

Taking too much time to refactor, which is blocking other dependent applications and priority tasks.
For developers CR is like a drug, a developer can refactor can keep on refactoring a complex codebase for ages. If CR is limited to no ROI (Return On Investment) the activity needs to be stopped.
Refactoring is not same as redesigning the code. It is easier to start the coding from scratch than to refactor your somebody else's or your own code. This needs to be learned before CR starts.

DEV Community: Soumendra Kumar Sahoo

Prompt vs Context vs Harness vs Loop Engineering

The Five Disciplines

1. Prompt Engineering

2. Context Engineering

3. Harness Engineering

4. Loop Engineering

5. Evaluation Engineering

How are Context, Harness, and Loop different?

One word each

The same bug, three different owners

Harness vs Loop: the machine and the "go" button

One agent turn, three zones

Side-by-Side Comparison

How They Fit Together

What Happens When You Skip One?

Where Is the Industry?

How I Apply This

The Bottom Line

Related Articles

Why should you use attrs more

Introduction

2. Getting Started with attrs

3. Core Features of attrs

a. Automatic method generation:

b. Attribute definition with types and default values:

c. Validators and converters:

4. Advanced Usage

a. Customizing attribute behavior:

b. Frozen instances and slots:

c. Factory functions and post-init processing:

5. Best Practices and Common Pitfalls

Best Practices:

Common Pitfalls:

6. attrs vs Other Libraries

Comparison with dataclasses:

Comparison with pydantic:

When to choose attrs:

7. Performance and Real-world Applications

8. Conclusion and Call to Action

Production Readiness Checklist

1. Alerts & Metrics

2. Dashboard and SOP

3. On-call mapping and cadence

4. Deployment

5. Observability and tracing

6. Load tests

7. Quality

8. Release

9. Disaster Recovery and Business Continuity

10. Compliance and Security

11. Documentation

@property in Python

Usage of backward slash (\) in Python

Usage of forward slash (/) in Python

Division

Floor division

Paths

Regular expressions

Factory Design Pattern

Learn Python Programming

Interactive way

Books

Courses

Videos

Tutorials

Newsletters

Podcasts

Aggregate Code timing in Python

Top Software Engineering Blogs

Python vs Golang vs Rust

Test scenario

Implementation

Python

Python stats

Golang

Golang stats

Rust

Rust stats

Conclusion