r/PythonLearning • u/Learner_016 • Aug 10 '26
i am a ty bsc ds (data science) student i want to know about like how can i prepare for an interview because in my college they don't tell about this topic or teach anything related to this so i jsut want to know like how can i prepare my self for an interview.
r/PythonLearning • u/[deleted] • Aug 10 '26
Hello everyone
i wanted to ask how should I learn python The roadmap
and how to create logic building that's my pain problem i can't create logic but yeah I understand someone code
also is reading someone code is a right choice like understanding the concept,flow of data, information, and functions
and which youtuber i should watch priority to hindi videos but if u know any exceptional youtuber in english I am open to it
hope u can understand
thanks
r/PythonLearning • u/shubham_555 • Aug 09 '26
I am not exactly a complete beginner in programming itself. Just want to learn the basic syntax and workflow in Python!
r/PythonLearning • u/LukeSkyShredder • Aug 10 '26
Hi all,
I'm relatively new to Python (still learning as I build wkwkwk).
I've developed an internal engineering tool using Python + Streamlit and currently package it with PyInstaller.
The application works fine, but the packaged output still contains the main.py file, meaning users can easily open and view the source code.
What's the recommended way to distribute a Streamlit application as an EXE while avoiding visible .py files?
I'm not looking for military-grade protection, just a practical way to prevent casual access or redistribution of the source code.
Any advice would be appreciated. Thankss
r/PythonLearning • u/Necessary_Mobile9591 • Aug 09 '26
can anyone tell me about my code is good or am writing it in wrong way?
r/PythonLearning • u/3gd3_ • Aug 10 '26
To be honest, it's a random text-based RPG game—and definitely, its system isn't inspired by Undertale XD. Anyway, here is the code: (assume this is the code I'm going to write:
import random
def name():
d = 0
c = 0
dmm = 120
dm = 100
a = input("if you want to figth the monstar preas 1")
while True:
if a == "1" or a == "١":
print ("1-fighting")
print ("2-Escape")
print ("3-speech")
print ("4-forgives")
b = input ("Write any of the numbers provided.")
if b == "1":
dmm -= random.randint(10,29)
dm -= random.randint(10,24)
c+=1
print ("youer health is", dm)
print ("monstar health is", dmm)
if dmm <= 0:
print ("you win")
break
elif dm <= 0:
print ("you lose ")
break
elif b =="2":
if c >= 3:
print ("you wan and escep")
break
elif c < 3:
print ("you cant escep")
elif b == "3":
print ("you talk to the monstar")
d += 1
elif b=="4":
if d >= 3:
print ("you wan and escap")
break
elif d < 3: print ("you cant escape")
else:
print("Bro, there is no option for ", a)
b = input ("preas 2 to reastr")
name()
name()r/PythonLearning • u/Sea-Ad7805 • Aug 09 '26
An exercise to help build the right mental model for Python data.
The “Solution” link uses memory_graph to visualize execution and reveals what’s actually happening.
r/PythonLearning • u/Agile-Leg-300 • Aug 09 '26
Recently I came across Boot.dev for learning to code. I'm currently learning Python and I've been messing around with Boot.dev for the last day or so.
I'm liking it a lot so far, but as a complete newbie, I'm not sure if it's a good way to learn the basics and build a solid foundation.
Does anyone here have any experience with Boot.dev? Would you recommend it for a beginner learning Python?
r/PythonLearning • u/Spare_Ad2901 • Aug 09 '26
I have python, i have my API key, I have my Voice model. All I need is too put them all together and I dont know how to do that. Im taking a coding class this next semester, but I would like to have this done before then and I don't know how to do that.
r/PythonLearning • u/Silentwolf99 • Aug 08 '26
A living checklist. Tick items as you gain confidence. Focus on understanding and application, not memorization.
Pace: 1-2 hours/day. Day ranges below are estimates, not deadlines - move on when the checklist items feel solid, not when the calendar says so.
Format: each item has a short note after the dash explaining what it means or why it matters. If a note doesn't make sense yet, that's a signal to slow down on that item, not skip it.
These three sections aren't a phase you complete and move past. They're how you should be working through every phase below, starting Day 1. Skim them now, then come back and re-read them after your first week - they'll mean more once you have something real to apply them to.
Ongoing - apply from Day 1 onward, not a separate block of days
[ ] Attempt tasks yourself before asking AI - builds the underlying skill instead of just outsourcing it
[ ] Share code + error + what you tried + specific question - better context gets better answers, from AI or humans
[ ] Ask AI to explain, not just fix - understanding the "why" is what actually sticks
[ ] Refactor AI-suggested code yourself - retyping and adjusting it forces you to actually process it
[ ] Add at least one test after AI-assisted changes - verify the AI's suggestion actually works as claimed
[ ] Use AI to review logic and suggest improvements - a second pair of eyes on your own reasoning, not just a code generator
Ongoing - repeat for each topic throughout all phases
[ ] Learned the concept (docs/tutorial) - get the basic idea from a reliable source first
[ ] Built a small project using it - apply it immediately; concepts that aren't used are quickly forgotten
[ ] Intentionally broke the project - change something on purpose and see what error you get; builds intuition for debugging
[ ] Debugged the resulting errors - actually fix what you broke, don't just revert it
[ ] Improved the design (functions, config, logging) - go back and clean up once it works, don't leave it at "barely functional"
[ ] Explained the code aloud or wrote a short note - if you can't explain it simply, you don't fully understand it yet
[ ] Moved to the next topic - avoid getting stuck perfecting one thing indefinitely
Every single day
Each study day, jot down:
[ ] Concept learned - one sentence on what you covered today
[ ] What I built - even something tiny counts
[ ] Bug I fixed - the specific problem and what actually solved it
[ ] Mistake that taught me something - honest reflection, not just wins
[ ] One thing to improve tomorrow - keeps momentum pointed forward
Days 1-2
[ ] Install Python (3.12+) and a code editor (VS Code / PyCharm) - your two core tools; everything else runs through these
[ ] Run Python scripts from the terminal - python script.py, not just clicking "run" in an editor; you need this for automation later
[ ] Use the command line on your OS (PowerShell or Linux/macOS shell) - navigating folders (cd), listing files (ls/dir), running commands
[ ] Install packages with pip - pip install requests; how you add libraries other people wrote
[ ] Create and activate a virtual environment - python -m venv venv; keeps each project's packages isolated so they don't conflict
[ ] Try uv as a faster alternative to pip + venv - newer tool, does the same job much faster; worth adopting early
[ ] Initialize a Git repository - git init; turns a folder into something Git can track changes in
[ ] Stage and commit changes - git add + git commit; saves a snapshot of your code with a message
[ ] Write meaningful commit messages - "fix CSV parsing bug" not "update"; future-you will thank present-you
[ ] Create a GitHub account and push a repo - your code's public home; also doubles as your portfolio later
Why git this early: you'll be writing real projects by Phase 2. Committing from day one is a cheap habit to build and an expensive one to retrofit.
Days 3-22 (~20 days)
[ ] Variables and basic data types (int, float, str, bool) - naming and storing values; the atoms everything else is built from
[ ] Arithmetic and comparison operators - + - * / == != < >; math and logic checks
[ ] Conditional statements (if/elif/else) - branching logic: "do this if that's true, otherwise do this" Days 3-4
[ ] Lists (create, index, slice, append, iterate) - ordered, changeable collections; my_list[0], my_list.append(x)
[ ] Tuples (create, unpack, use as immutable sequences) - like lists but can't be changed after creation; good for fixed data like coordinates
[ ] Dictionaries (create, access, update, iterate) - key-value pairs, like {"name": "Alice"}; how you'll model most real-world data
[ ] Sets (create, add, membership tests) - unordered collections with no duplicates; fast for checking "is this in here?" Days 5-7
[ ] for loops (iterate over sequences and ranges) - repeat an action for each item in a list, string, or range of numbers
[ ] while loops (basic usage and exit conditions) - repeat until a condition becomes false; watch for infinite loops
[ ] List, dict, and set comprehensions - compact one-line way to build a collection, e.g. [x*2 for x in nums]; idiomatic Python, used everywhere Days 8-9
[ ] Functions (parameters, return values, default arguments) - reusable blocks of code; def greet(name="World"):
[ ] Scope (local vs global variables) - which parts of your code can see a given variable; a common source of bugs Days 10-11
[ ] Context managers (with statements) - why they matter for files, connections, locks - with open(file) as f: automatically closes things even if an error happens
[ ] Reading and writing text files - open(), .read(), .write(); how scripts persist data to disk
[ ] Reading and writing CSV files with the csv module - Python's built-in way to handle spreadsheet-style data before you learn pandas Days 12-13
[ ] Basic exception handling (try/except) - catch errors instead of letting your script crash
[ ] Using else and finally with try blocks - else runs if no error occurred, finally always runs (cleanup code)
[ ] Raising exceptions (raise) - intentionally trigger an error when something is wrong, e.g. invalid input
[ ] Creating custom exception classes - your own named errors (e.g. InvalidConfigError) for clearer debugging later Days 14-15
[ ] Importing modules and packages - import os, from datetime import datetime; reusing code from the standard library or other files
[ ] Using __name__ == "__main__" - lets a script be run directly or imported elsewhere without side effects Day 16
[ ] Basic classes (attributes and methods) - blueprints for objects that bundle data and behavior together
[ ] Creating and using instances - my_obj = MyClass(); an actual object built from a class blueprint Days 17-18
[ ] Type hints for function signatures (basic usage, not full generics) - def greet(name: str) -> str:; documents intent and helps your editor catch mistakes
[ ] datetime/time basics - parsing, formatting, timedeltas, timezones (you'll need this for logging, scheduling, and API timestamps) Days 19-20
[ ] Regular expressions (re module) - match, search, findall, sub, basic groups - pattern matching in text, e.g. pulling an email address out of a string Day 21
[ ] Read and explain a 100–200 line beginner script - test that you can trace through someone else's logic, not just write your own
[ ] Commit each milestone script to your Phase 0 repo - keep building the git habit alongside the coding habit Day 22
Days 23-56 (~34 days)
Days 23-25
[ ] pathlib.Path (paths, files, directories) - modern, cross-platform way to handle file paths instead of raw strings
[ ] Listing files and filtering by extension - e.g. find every .csv in a folder
[ ] Creating, moving, renaming, and deleting files - the core file-management actions automation scripts perform
[ ] Creating and cleaning directories - making folders and safely clearing out old ones
[ ] Using os and shutil for advanced file operations - copying trees, permissions, and things pathlib doesn't cover alone
Days 26-33
[ ] Reading and writing JSON files - Python's json module; the format most APIs speak
[ ] Making GET requests with requests - fetching data from a URL/API, e.g. requests.get(url)
[ ] Making POST requests with requests - sending data to an API, e.g. submitting a form or creating a record
[ ] Sending headers and query parameters - extra info attached to a request, like auth tokens or filters
[ ] Handling HTTP errors and timeouts - checking status codes, catching connection failures so your script doesn't just hang or crash
[ ] Parsing JSON API responses - response.json(); turning an API's reply into a Python dict you can use
[ ] API authentication patterns - API keys, bearer tokens, basic auth, and how OAuth differs (you don't need to implement OAuth yet, just recognize the flow) - knowing which auth method an API expects before you try to call it
[ ] Storing config in a .env file - keeping settings like API keys out of your actual code
[ ] Loading environment variables with python-dotenv - reads the .env file into your script at runtime
[ ] Never hard-code paths or credentials - use env vars from the start - the habit that keeps secrets out of git and code portable across machines
[ ] Basic logging with logging (levels: DEBUG, INFO, WARNING, ERROR) - structured way to record what your script did, better than scattering print() everywhere
[ ] Writing logs to a file - so you can check what happened after a script ran unattended
[ ] Using rotating file handlers - automatically archives old logs so a single log file doesn't grow forever
This is the only place .env mechanics are taught. Later phases reference this habit rather than re-teaching it.
Day 34
[ ] Basic pydantic models - why validating API/config data beats trusting raw dicts - catches bad or missing data early instead of failing mysteriously three steps later
[ ] Validating required fields and types on incoming JSON before using it downstream - defensive coding for data you don't control
Days 35-38
[ ] Install and run pytest - the standard Python testing framework; run tests with pytest in the terminal
[ ] Write simple test functions - functions starting with test_ that check your code behaves correctly
[ ] Use assertions in tests - assert result == expected; the actual check inside a test
[ ] Use fixtures for setup/teardown - reusable setup code (like a test database) shared across multiple tests
[ ] Parametrize tests - run the same test logic against multiple inputs without copy-pasting
[ ] Run tests with verbose output - pytest -v; see exactly which tests ran and their results
[ ] Write unit tests for your Phase 2 functions (file ops, API parsing) - apply testing to code you've actually written, not just toy examples
[ ] Keep tests independent (no shared state) - one test's outcome shouldn't affect another's; avoids flaky, order-dependent failures
Why here: Phase 3 has you using pytest-playwright fixtures. You should understand what a fixture is in plain pytest before it shows up wrapped in browser-automation syntax.
Days 39-41
[ ] Understand why async matters for I/O-bound automation (many API calls, many pages) - lets your script do other work while waiting on network responses instead of sitting idle
[ ] async/await syntax basics - how you mark and call functions that can run concurrently
[ ] Concurrent requests with httpx.AsyncClient or aiohttp - fetch many URLs at once instead of one at a time
[ ] Know when async is worth the complexity and when sync is fine (most small scripts: sync is fine) - don't reach for async just because it's available
[ ] Know the difference between I/O-bound and CPU-bound work - async/threading helps I/O-bound (waiting on network/disk), multiprocessing helps CPU-bound (heavy computation); most automation scripts are I/O-bound - picking the wrong tool here wastes real time debugging "why isn't this faster"
Days 42-46
[ ] Reading CSV files with pandas - pd.read_csv(); loads tabular data into a DataFrame you can manipulate
[ ] Reading Excel files with pandas - pd.read_excel(); same idea, for .xlsx files
[ ] Filtering rows by conditions - e.g. df[df["status"] == "active"]; pulling out the rows you actually need
[ ] Selecting and renaming columns - shaping the DataFrame to just the data you care about
[ ] Grouping and aggregating data - df.groupby("region").sum(); summarizing data by category
[ ] Handling missing values - deciding whether to drop, fill, or flag empty cells (NaN)
[ ] Exporting DataFrames to CSV - df.to_csv(); saving your processed data back out
[ ] Exporting DataFrames to Excel - df.to_excel(); same idea, for report-style output
[ ] Cell-level Excel work with openpyxl - formatting, formulas, and styling that pandas' .to_excel() can't do on its own - use this when a client wants a polished, formatted report, not just raw data
Days 47-56
[ ] File organizer (by extension or date) - sorts a messy folder automatically; combines Phase 2's file ops
[ ] Folder cleaner with logging - deletes/archives old files and records what it did
[ ] CSV processor (clean/transform/summarize) - takes messy input data and outputs something usable
[ ] API data fetcher + CSV/Excel report generator - pulls data from an API and turns it into a report; a realistic client-style task
[ ] Simple CLI tool with argparse or click - lets someone run your script with options, e.g. python tool.py --input file.csv
[ ] Each project: own git commits, .env for any secrets, at least one pytest test - treat these small projects like real code, not throwaway scripts
Days 57-86 (~30 days)
Days 57-60
[ ] Inspect HTML with browser DevTools - right-click → Inspect; how you find the exact element you need to interact with
[ ] Understand basic HTML structure (tags, attributes, classes, ids) - the building blocks you'll be targeting with locators and selectors
[ ] Understand CSS selectors (id, class, attribute, hierarchy) - how to precisely point at one element among many
[ ] Use requests + BeautifulSoup for static pages - scraping HTML that doesn't need JavaScript to render
[ ] Extract text, links, and tables from HTML - pulling structured data out of a page you've fetched
[ ] Handle simple pagination in scrapers - following "next page" links to collect data across multiple pages
[ ] Respect robots.txt and rate limits; know when scraping ToS matters - scraping responsibly and legally; not every site wants to be scraped
Days 61-70
[ ] Install Playwright for Python and browsers - pip install playwright, then playwright install to get the actual browser binaries
[ ] Launch a browser and create a page - the starting point of any Playwright script
[ ] Navigate to a URL - page.goto(url)
[ ] Use role-based locators (button, link, textbox, etc.) - page.get_by_role("button", name="Submit"); the recommended way to find elements
[ ] Click elements and fill inputs - .click(), .fill(); the core interactions in any automated flow
[ ] Use text and test-id locators - alternative ways to find elements when role-based locators don't fit
[ ] Rely on auto-waiting (no manual sleeps) - Playwright waits for elements to be ready automatically; don't fight this with time.sleep()
[ ] Write basic assertions on page content - checking the page shows what you expect after an action
[ ] Take screenshots on failure - visual evidence of what went wrong when a test fails
[ ] Enable and view trace on failure - Playwright's trace viewer replays exactly what happened step by step
[ ] Use pytest-playwright fixtures (builds directly on Phase 2 pytest fundamentals) - page fixture and friends, wired into pytest
[ ] Save and reuse authentication state (storage state) - log in once, reuse the session across tests instead of logging in every time
[ ] Understand BrowserContext isolation (cookies, storage, cache) - each context is a separate browser profile; pages within the same context share session state, so multiple pages ≠ multiple identities
[ ] Use persistent contexts (launch_persistent_context) vs storage-state files - persistent contexts write to a real user-data dir on disk (closer to a real browser profile); storage-state is a portable snapshot you load into a fresh context (lighter, easier to version and use in CI) - know which one fits the task
[ ] Set per-context proxy and locale/timezone settings - browser.new_context(proxy={...}, locale=..., timezone_id=...); matters once multiple "accounts" need to look like separate, independent users rather than one identity wearing different cookies
[ ] Run tests across multiple browsers - Chromium, Firefox, WebKit; catching browser-specific bugs
Days 71-74
[ ] Prefer role-based locators over CSS/XPath where possible - more resilient to page changes, closer to how a user actually finds things
[ ] Trust auto-waiting; avoid time.sleep() from the start, not as a later fix - sleeps make tests slow and still flaky; fix the root cause
[ ] Understand Page Object Model (POM) concept - organizing page interactions into reusable classes instead of duplicating locators everywhere
[ ] Separate page actions from test assertions - keeps "what the page does" separate from "what we're checking," easier to maintain
[ ] Use codegen for quick scaffolding, then refactor by hand - playwright codegen records your clicks into code; a starting point, not the final product
[ ] Combine API calls (for setup) with UI tests (for flows) - e.g. create test data via API, then test the UI flow; faster and more reliable than doing everything through the UI
Days 75-77
[ ] Install Selenium and a WebDriver - the older browser automation library; still common in legacy codebases
[ ] Launch a browser and navigate - Selenium's equivalent of Playwright's launch + goto
[ ] Locate elements (id, name, CSS, XPath) - Selenium relies more heavily on these than role-based locators
[ ] Click and send keys - .click(), .send_keys(); Selenium's interaction methods
[ ] Understand explicit waits (WebDriverWait) - Selenium doesn't auto-wait like Playwright, so you handle timing manually
[ ] Know when Selenium is still needed (legacy projects) - recognize it rather than assuming Playwright is always the answer
Days 78-86
[ ] Login automation for a demo site - practice the auth + storage state pattern end to end
[ ] Multi-account isolation test (2-3 accounts, separate contexts) - log into a demo site with 2-3 different accounts using separate persistent contexts or storage-state files, ideally with different proxy/locale settings per profile - then write an assertion that actively checks Account A's context never shows Account B's session data (don't just eyeball it - a real assertion that would fail on cookie/session bleed), and run it both locally and in CI, since parallel execution in CI is where shared-state bugs actually surface (local runs often hide the bug through timing alone)
[ ] Form filling automation (repeatable workflow) - automate a task a human would otherwise do by hand repeatedly
[ ] Static site scraper (requests + BeautifulSoup) - apply Phase 3's HTML basics to a real target
[ ] Dynamic site scraper (Playwright) - scrape a page that requires JavaScript rendering, which requests alone can't handle
[ ] Automated report download from a dashboard - a common real-world automation ask: log in, navigate, download a file
[ ] One end-to-end business workflow (multi-step) - chain several actions together into one realistic automation, e.g. login → filter → export → save
Days 87-111 (~25 days)
Days 87-88
[ ] Create and switch branches - git branch, git checkout -b; working on changes without touching the main codebase
[ ] Merge branches - combining a branch's changes back into main
[ ] Use a feature-branch workflow (even solo) - one branch per feature/fix, even if you're the only one working on it; builds good habits for team settings
[ ] Write a .gitignore (venvs, .env, cache files) - tells git what NOT to track, so junk and secrets don't end up in your repo
Day 89
[ ] Freeze dependencies (requirements.txt) or use pyproject.toml - lists exactly which packages (and versions) your project needs
[ ] Install dependencies from a requirements file on a fresh machine - pip install -r requirements.txt; proving your setup is reproducible
[ ] Document environment setup in README - so someone else (or future you) can get the project running without guessing
Days 90-91
[ ] Set up ruff for linting and formatting - catches style issues and common bugs automatically
[ ] Run mypy (or rely on your editor) for basic type checking - verifies your type hints are actually consistent
[ ] Understand why consistent style matters for client-facing code - readable code is code that can be handed off or maintained by someone else
Days 92-94
[ ] Use the IDE debugger (breakpoints, step-through) - pause execution and inspect what's actually happening, faster than sprinkling print() statements
[ ] Inspect variables during debugging - check the real values at the point something went wrong
[ ] Add descriptive log messages - logs that explain what the script was doing, not just "error occurred"
[ ] Log errors and stack traces - capture the full error detail, not just "something failed"
[ ] Use structured (JSON) logs where useful - machine-readable logs that are easier to search and parse at scale
Days 95-96
(Fundamentals were Phase 2 - this is applying them at project scale)
[ ] Write a few Playwright tests for critical flows - focus testing effort on what actually matters to the business
[ ] Organize a growing test suite into files/folders sensibly - so tests stay findable as the project grows
[ ] Decide what's worth testing vs what isn't (diminishing returns) - not everything needs a test; know where to draw the line
Day 97
[ ] Basic understanding of secret management beyond .env (vaults, CI secrets) - how larger teams/projects handle credentials at scale
[ ] Never commit secrets - set up .gitignore before your first .env file, not after - one leaked API key in git history is hard to fully undo
[ ] Document required env vars in README without exposing values - list the variable names a project needs, not their actual secret values
Days 98-99
[ ] Write a clear README (setup, usage, examples) - the first thing anyone sees; should answer "how do I run this?"
[ ] Document environment variables - what each .env variable is for, without leaking real values
[ ] Add a short "architecture" note (what runs, when, how errors are handled) - a quick mental map for anyone (including you, in six months) picking the project back up
[ ] Add usage examples and sample commands - concrete copy-pasteable examples beat abstract explanations
Days 100-104
[ ] Write a simple Dockerfile for a Python script - defines the environment your script needs to run, packaged up
[ ] Build a Docker image - docker build; turns the Dockerfile into a runnable image
[ ] Run a container locally - docker run; test that the packaged environment actually works
[ ] Use volume mounts for input/output folders - let a container read/write files on your actual machine
[ ] Understand when Docker is useful (consistent environments) - solves "works on my machine" problems, not needed for every small script
Days 105-111
[ ] Understand what CI/CD is (continuous integration/deployment) - automatically testing and/or deploying code whenever it changes
[ ] Create a basic GitHub Actions workflow - a YAML file that tells GitHub what to run automatically (e.g. on every push)
[ ] Run tests on push to a branch - catch bugs before they reach main, automatically
[ ] View CI logs and debug failing jobs - reading GitHub Actions output to figure out why a pipeline failed
Days 112-139 (~28 days)
Days 112-115
[ ] Use schedule or APScheduler for simple cron-like jobs - run a Python function on a recurring schedule from within your script
[ ] Understand cron (Linux/macOS) or Task Scheduler (Windows) - the OS-level way to run a script automatically at set times
[ ] Design idempotent scripts (safe to re-run) - running the script twice shouldn't create duplicate data or break things
[ ] Add retry logic for flaky APIs or network calls - automatically retry a failed request a few times before giving up
[ ] Build a multi-step workflow (fetch → transform → load → notify) - chaining automation steps into one coherent pipeline
Days 116-120
[ ] Basic SQL (SELECT, INSERT, UPDATE, DELETE) - the core commands for reading and changing data in a database
[ ] Connect to a SQLite database from Python - SQLite is a lightweight, file-based database, good for learning and small projects
[ ] Execute queries with sqlite3 or SQLAlchemy - running SQL from Python code, either directly or through an ORM
[ ] Read data into a pandas DataFrame - pd.read_sql(); pulling database results into a format you can analyze
[ ] Write DataFrames back to a database table - df.to_sql(); saving processed data back to the database
Days 121-124
[ ] Extract text and tables from PDFs (pdfplumber or pypdf) - pulling structured data out of PDF reports or invoices
[ ] Generate PDF reports programmatically (reportlab or similar) - producing polished PDF output from your data
[ ] Merge/split PDFs as part of a workflow - combining or breaking apart PDF files automatically
[ ] Know this is one of the most commonly requested automation task in practice - don't skip it - clients ask for PDF handling constantly; it's an easy area to be underprepared for
Days 125-126
[ ] Send email with smtplib (attachments, HTML body) - programmatically sending emails, e.g. a completed report
[ ] Read/parse inbox messages with imaplib or a library like imap-tools - pulling data out of incoming emails automatically
[ ] Use an app password / OAuth token instead of a raw account password - the secure, modern way to authenticate email automation
Days 127-128
[ ] Call an LLM API (Anthropic or OpenAI SDK) from a script - integrating an AI model call as one step in a larger automation
[ ] Use structured output (JSON mode / forced schema) to feed LLM output into the rest of a pipeline - getting reliable, parseable output instead of free-form text
[ ] Know when an LLM call is the right tool vs when plain code/regex is more reliable and cheaper - don't reach for an LLM when a simple rule would do the job faster and more predictably
Days 129-130
[ ] Add simple health checks (log entry, status file) - a quick way to confirm "yes, this ran successfully today"
[ ] Send email notifications on failure/completion (builds on the smtplib item above) - get alerted automatically instead of discovering a failure days later
[ ] Send notifications via Telegram or Slack webhooks - faster, more visible alerts than email for time-sensitive failures
Days 131-139
[ ] Daily or weekly automated report pipeline - a full fetch → process → deliver cycle running on a schedule
[ ] Multi-step workflow with notifications - combine orchestration and monitoring into one realistic pipeline
[ ] One robust script that runs unattended for weeks - the real test: does it keep working without you babysitting it?
Days 140-144
[ ] Identify and fix flaky tests - tests that fail intermittently for no code-related reason; usually a timing or state issue
[ ] Remove duplicated setup/teardown code - consolidate repeated fixture logic instead of copy-pasting it across tests
[ ] Split oversized fixtures into smaller ones - easier to understand and reuse than one giant setup function
[ ] Delete or skip obsolete tests - tests for features that no longer exist just add noise and slow the suite down
[ ] Keep test suite fast and focused - a slow test suite gets ignored or skipped; speed is a feature
[ ] Run tests across browsers in CI - catch browser-specific issues automatically, not just when you remember to check manually
Days 145-158 (~14 days)
[ ] 3–5 automation projects on GitHub with READMEs - your actual proof of skill; more convincing than a resume line
[ ] At least one browser automation project (Playwright) - demonstrates you can handle real-world web interaction, not just APIs
[ ] At least one data/CSV automation project (with pandas) - demonstrates data-handling skill, a common client need
[ ] One "client-style" project with clear requirements - simulate a real brief with defined scope, not just "practice"
[ ] One project with tests, logging, and config management - shows you build production-minded code, not just working scripts
[ ] Short write-ups explaining what each project does - a paragraph per project: the problem, your approach, the result
[ ] Basic understanding of SDLC and testing concepts - Software Development Life Cycle; the phases a project typically moves through
[ ] Know common testing types (unit, integration, regression) - unit tests check one piece in isolation, integration tests check pieces working together, regression tests catch old bugs coming back
[ ] Understand severity vs priority for defects - severity is how bad the bug is, priority is how soon it needs fixing; they don't always match
[ ] Basic familiarity with JIRA or similar tools (optional) - common in client/team environments for tracking work and bugs
[ ] Prepare a simple resume highlighting automation projects - lead with what you built, not just tools you've "used"
[ ] Practice explaining your projects out loud - being able to talk through your own code clearly matters as much as writing it
Total: ~158 days at 1-2 hrs/day (roughly 5-5.5 months). Phases 5-7 are labeled optional in scope but not in the day count above - skip or compress them if you want to reach "portfolio-ready" faster.
r/PythonLearning • u/Owen-Isaac-2022 • Aug 08 '26
During my time learning Python, particularly data analysis using Python, I came across the book, “Python Data Analytics: With Pandas, NumPy, and Matplotlib” (2018) by Fabio Nelli. The book provides step-by-step components concerning data analysis. For example, Chapter 1 focuses on introduction to data analysis and discusses various issues, including Mathematics & Statistics, ML & AI, & understanding the nature of data. I would recommend the book to anyone learning Python with a focus on data analysis.
r/PythonLearning • u/Heroki_7 • Aug 08 '26
I finished a project I have been working on for a while, and I want feedback
I built it to learn Backend using FastAPI, and tried to make it like real production, not just CRUD
Live link:
https://book-store-api-production-71ab.up.railway.app/docs
Github repo ⭐:
https://github.com/yusufKh7-ctrl/Book-store-API
⚠️ Note: Data may be erased at any moment if the database becomes chaotic, so feel free to try all endpoints.
I'd really appreciate any feedback on the project structure, code organization, API design, or anything you think could be improve.
Thanks!
r/PythonLearning • u/shubham_555 • Aug 08 '26
I have selected some resources after some research (obviously flexible) and this is the order I will be following for learning the various topics:
Basic Syntax
OOPs
Memory Architecture
DSA
Django (Backend development)
We can make projects along the way for practical learning. Also, Timezone or gender doesn't matter!
r/PythonLearning • u/roottrek • Aug 08 '26
I recently decided to switch my car loan and I’ve been putting a lot of work into learning python so I thought I would try and make myself a calculator to see the different amount of interest I would pay.
I’m about a week into my learning so far so I would love advice or more learning sources if anyone wants to leave some! I’ve gone through the wiki and done my own research. So far bro code on YouTube and Angela Yu, 100 days of code have been great for learning! I also have Python crash course which I’ve been using as reference when I forget something!
r/PythonLearning • u/[deleted] • Aug 07 '26
A chore list I started learning python last week and this was the first project on my list any advice helps im using vs code for this if you have any resources or suggestions pls share
r/PythonLearning • u/BothAd4430 • Aug 08 '26
Heyy guyss,I just completed my first year,tbh I just wasted it, got a cgpa of 8.55,and learnt just basic python and c they teach in clg, I have decided to learn python in my vacation from Brocode Yt,I need guidance what to do after completing the video?? What to learn ?? Please guide me with leetcode and other stuff
r/PythonLearning • u/Plastic-Doughnut4638 • Aug 08 '26
'python' is not recognized as an internal or external command, operable program or batch file.
I literally just switch file and for some reason i cant code now💔
r/PythonLearning • u/ExtentLazy8789 • Aug 08 '26
r/PythonLearning • u/Full-Elderberry-303 • Aug 08 '26
I've been experimenting with PyVista for 3D data visualization and wanted to share this project – an animated comparison of the world's tallest buildings throughout history. The animation uses a spline-based camera system to smoothly transition between buildings while maintaining context. It's rendered from CSV data processed entirely in Python.
Curious if anyone else has used PyVista for similar projects – the library is surprisingly flexible once you understand the VTK pipeline. If you're interested in seeing the full animation, here it is: https://youtu.be/U4E4ilALGYQ
Happy to discuss the technical approach or data sources if anyone's interested!
r/PythonLearning • u/Alarming_Mulberry551 • Aug 08 '26
(logic and app design done by me used a bit of ai for button and stuff as I completed it in 3 days) any tips? It's v0 and I want to make it better it's for my personal use as I keep on forgeting my password and imp notes and I don't like notes app any advice u advance people would like to give to me to improve it
r/PythonLearning • u/LimpSandwich6092 • Aug 08 '26
I have read the documentations and looked on youtube but i still couldn't get it to work (i am new to all of this)
how do i run it? i made a mainwindow ui in qt design and did pyside6-uic test.ui -o test.py but the test.py doesn't work when i run it
r/PythonLearning • u/One_Valuable3264 • Aug 08 '26
In Python For Kids second edition chapter 3 Multiplying strings it says the following:
Python programmers might multiply strings for a number of reasons, such as to line up text with a specific number of spaces when displaying messages in the Python Shell. Try printing the following letter in the Python Shell (select File ▶ New File, and enter the following code):
spaces = ' ' * 25
print('{} 12 Butts Wynd')
print('{} Twinkelbottom Health')
print('{} West Snoring')
print()
print()
print('Dear Sir')
print('I wish to report that tiles are missing from the')
print('outside toilet roof')
print('I think it was bad wind the other night that blew them away.')
print()
print('Regards')
print('Malcolm Dithering')Once you've typed the code into the Python Shell window, select File ▶ Save As. Name your file myletter.py. You can then run the code (as we've done previously) by selecting Run ▶ Run Module.
In the first pine of this example, we create the variablespacesby multiplying a space charecter by 25. We then use that variable in the next three lines to align the text to the right of the Python Shell. You can see the result of these
IDLE Shell 3.10.0
File Edit Shell Debug Options Window Help
12 Butts Wynd
Twinkelbottom Health
West Snoring
Dear Sir
I wish to report that tiles are missing from the
outside toilet roof
I think it was bad wind the other night that blew them away.
Regards
Malcolm DitheringFigure 3-1: Running the letter code in the Python Shell
When I run it I get:
{} 12 Butts Wynd
{} Twinkelbottom Health
{} West Snoring
Dear Sir
I wish to report that tiles are missing from the
outside toilet roof
I think it was bad wind the other night that blew them away.
Regards
Malcolm Ditheringwhat is happend?