Web appOpen in Telegram
>>>> telegram.Bot() - PTB Development
>>> telegram.Bot() - PTB Development
@pythontelegrambotdev · group · Tech · indexed since 2026-07-10 archive for April 2026
43members
930messages in the index

Messages from April 2026

‹ April 2026 ›×
欧
Hi everyone, I'll be working on the polls section for the Bot API 9.6 update. Just wanted to mention it here to avoid duplicate work.
R
Hi 欧阳 🐏🐏🐏 Please post code or tracebacks using a pastebin rather than via plain text or a picture. https://pastebin.com/ is quite popular, but there are many alternatives out there. Of course, for very short snippets, text is fine. Please at least format it as monospace in that case., we like to keep our groups readable and thus require long code to be in a pastebin. ⚠️ The code snippet(s) in your message have been moved to https://pastebin.poolitzer.eu/p/PyG0tY.py. Your original message will be deleted in a minute, please reply to this message with your query.
欧
File
image_2026-04-08_08-36-04.png · 9 KB · click to show
In API 9.6, a persistent_id field was added. I'm wondering if we can replace self._id_attrs = (self.text, self.voter_count) with self._id_attrs = (self.persistent_id,). https://pastebin.poolitzer.eu/p/PyG0tY.py
H
@ouyoung I forgot to finish my draft review in your github pr, but I believe I saw some changes you made which were backward incompatible. Can you make sure nothing is broken when new features are implemented? See one of the PRs for API 9.3 or 9.4 which introduced changes which were backward compatible. That gives you a template to work with.
  1. 欧
    Thanks for the heads-up! I see the issue now — I made some new fields like persistent_id and allows_revoting required positional parameters instead of optional ones, which breaks backward compatibility. I'll fix this by making all newly introduced parameters optional (defaulting to None) and ensuring they don't change the existing parameter order. I'll reference the API 9.3/9.4 PRs as a template. Sorry about that, will push the fixes soon.
Whole thread · 1 reply →
欧
Can we do an FSM while retaining the conversation?
    1. 欧
      I've been using ConversationHandler for a while and find it a bit hard to manage as conversations get more complex — especially when dealing with nested states, fallbacks, and re-entry logic. Has there been any discussion about implementing a more formal FSM (finite state machine) approach? Something with explicit state definitions, transitions, and guards would make complex conversation flows much easier to reason about and debug. Would love to hear if others feel the same or if there are plans in this direction.
      1. H
        yeah we've had a big discussion in #2770. I'm not sure when I / rest of the dev team will have the resources to completely overhaul that though.
      2. R
        Issue #2770: [Discussion:] ConversationHandler by Bibo-Joshi
Whole thread · 4 replies →
Calendar: April 2026
MoTuWeThFrSaSu123456718595101112131415161718192021222324252627282930

An open public feed from the search index ChatCrawler — “Google for public Telegram”; refreshed as the venue is crawled. Times are UTC.

Public content only, official Telegram API. About · FAQ · What we do not do · Remove a page · Catalog · Search · How we count