1. The Object-Oriented Approach (Recommended)
   This is the most Pythonic solution. Instead of standalone functions, group your handlers into a class that accepts your dependencies (MyService) in its constructor.

This binds the service to the instance, making it available via self in your handlers. No globals, no bot_data, and perfect type safety.

Python

from telegram import Update
from telegram.ext import ApplicationBuilder, CommandHandler, ContextTypes

class MyService:
def do_work(self):
return "Service is working!"

class BotHandlers:
def init(self, service: MyService):
self.service = service

async def hello(self, update: Update, context: ContextTypes.DEFAULT_TYPE):
    # Access service via self
    result = self.service.do_work()
    await update.message.reply_text(result)

def main():
service = MyService()
# Instantiate the handler class with dependencies
handlers = BotHandlers(service)

app = ApplicationBuilder().token("TOKEN").build()

# Register the bound method
app.add_handler(CommandHandler("hello", handlers.hello))

app.run_polling()

2. The functools.partial Approach
   If you prefer keeping handlers as standalone functions but want to inject dependencies, you can use functools.partial. This "bakes" the service argument into the function before the library ever sees it.

Python

import functools
from telegram import Update
from telegram.ext import ApplicationBuilder, CommandHandler, ContextTypes

Define handler with an EXTRA argument for the service

async def hello(update: Update, context: ContextTypes.DEFAULT_TYPE, service: MyService):
await update.message.reply_text(f"Service says: {service.do_work()}")

def main():
service = MyService()

# Create a partial function with 'service' pre-filled
# The PTB library will still pass 'update' and 'context' as usual
handler_with_service = functools.partial(hello, service=service)

app = ApplicationBuilder().token("TOKEN").build()
app.add_handler(CommandHandler("hello", handler_with_service))
app.run_polling()

3. Analyzing Your Custom Context Solution
   Your solution using MyApplication and MyContext is effectively the "Power User" way. It is the correct way to utilize PTB's generics if you want the framework to be aware of your types.

Why is the cast still necessary? You asked why t.cast is needed even though you passed MyApplication to the builder.

The issue lies in the definition of CallbackContext. In the PTB source code, the application property inside CallbackContext is typed as the base Application class (or a generic that defaults to it). Even though you injected MyApplication at runtime, the static type checker (mypy/pyright) cannot infer that this specific instance of Context is always linked to that specific subclass of Application without a circular generic dependency that is hard to express in Python.

Your property override is the correct fix:

Python

@Property
def service(self) -> MyService:
# This cast is the "bridge" between the generic framework
# and your concrete implementation. It is safe and encapsulated.
return t.cast(MyApplication, self.application).service