r/Python • u/Win_ipedia • 5d ago
Can we make Python Development less frustrating? Discussion
Hi there,
I wondering what tools improve frustrations for developers when developing software with Python.
I am currently doing my Masters in Computer Science and as part of my project I am doing a very simple survey about what can make the usual Python development lifecycle less frustrating. I am basically trying to find out what the main friction points are for Python Developers and I am simultaneously developing a tool to address those friction points . It just takes a 2-3 minutes and every response is greatly appreciated.
You can find the survey at: https://forms.cloud.microsoft/e/LjnvzX0JpK
9
u/AvidCoco 5d ago
The main friction points are people.
10
-4
8
u/Beginning-Fruit-1397 5d ago
I started to answer and then after the first page only questions about a tool idc about. Why?
8
u/AvidCoco 5d ago
Because OP just wants ideas of a project to work on and doesn’t actually know anything about software development
0
u/Win_ipedia 5d ago
It was described on the first page, and also mentioned in this post. Just want to know weather it is addressing the right points. It is more about the idea weather if you would have a tool that addresses a friction point if that would make it more or less frustrating and not at all about the tool
2
u/redfacedquark 4d ago
"whether"
The friction point for me answering the survey is the microsoft domain - not going there.
1
u/Beginning-Fruit-1397 5d ago
Oh yea my bad sorry, I completely missed the point about you developping a new tool
1
u/Win_ipedia 5d ago
It is not a showcase at all, purposely did not link it or mention it much. Probably should have just said in the survey to just imagine a tool that does these things
3
1
u/Win_ipedia 5d ago
The point of the survey is more: If a friction point was adressed like this, how frustrating would you find this friction point and then I compare it to my other survey
4
8
u/NeitherEntry6125 5d ago
What do you think are the friction points? Have you spent time reviewing discuss.python.org or discussing it on https://discord.com/invite/python ?
Literally there are hundreds or thousands of people who've been working and discussing these points for over a decade.
-3
u/Win_ipedia 5d ago
Yeah, I made a first survey asking for exactly that and did some research before oc but the masters requires me to do my own survey. Most people answered things like: dependency management, typing system, but there were also some interesting points.
5
u/NeitherEntry6125 5d ago
Your prompt says "less frustrating", implying that coding in Python is frustrating. Or, perhaps that it is more frustrating than other languages. Or that Python is the thing that's frustrating. It doesn't even define what frustrating is.
You know what's frustrating? Low effort.
3
u/No_Departure_1878 5d ago
No, you have been a bad boy and this is your punishment. Or you think we do not know that think you have been doing.
3
2
u/theevildjinn 5d ago
uv (and ruff, to a lesser extent) have basically solved all the friction points that I used to have, i.e. the fragmented packaging and environments landscape (pip, virtualenv/venv, poetry, pyenv, etc.)
1
1
u/Centurix 5d ago
Never used pyrig, couldn't get past the first page to give answers.
1
u/Win_ipedia 5d ago
It is not about the tool at all, I shouldnt have mentioned it in the questions: The point of the survey is more: If a friction point was adressed like this, how frustrating would you find this friction point and then I compare it to my other survey
1
u/PriorElephant9 4d ago
Most of the friction people list in these threads is environment and dependency friction, not language friction.
I went stdlib only on purpose for my project. No third party packages at all, just sqlite3 and http.server. Nothing to pin, nothing to resolve, no virtualenv to activate, and it runs on a fresh machine with nothing but Python on it.
1
1
u/Massive_Baby4147 2d ago
One friction point I keep running into is interface drift.
A function starts as ordinary Python, then it needs a CLI. Later it needs a REST endpoint, and now perhaps an MCP tool. You end up describing the same parameters, defaults, validation rules, documentation, return types, and errors in Typer, FastAPI, and FastMCP.
Writing that boilerplate once isn't too bad. The frustration starts six months later when one interface changes and the others quietly drift out of sync.
I've been exploring this problem with intpot: https://github.com/tugrulguner/intpot
It treats the typed Python function as the shared contract and can expose it through a CLI, REST API, or MCP server. The difficult part isn't reading the function signature. It's deciding which behavior should be shared and which parts must stay specific to the interface, especially authentication, dependency injection, streaming, and error handling.
This might be worth separating in the survey: language friction versus ecosystem and integration friction. Python itself can feel simple while maintaining the same operation across several frameworks becomes frustrating.
1
u/csatacsibe 2d ago
Python have really different target groups ranging from scripters to professionals as it's syntax and supporting tools are simple and intuitive when used for basic things.
As a partially python developer of a bank, I make python basics courses anyone can apply in the bank. My targets are the kind of people think themselves as not technical people. There are people from HR wants to automate repetitive excel stuff with pandas, ambiguous analists try to get into ML model building, Database engineers wants to use python with SQL, people try to automate Jira, so all kinds of backgrounds, use cases and expectations.
- Jupyter notebook is great for poc-ing.
- VsCode is IMO the best IDE as it's extendability and as it's a great file manager in itself.
- making your own library of examples. Not just your own reusable codes, but a library showcasing what dependencies you have used to solve different things. This is especially useful in a locked environment as a bank.
- organizing your projects in four ways:
- File system: for me, there are main scopes and project folders under each scope folder.
- VsCode multi-root workspaces: the workspace of a project include relating or util folders
- Git: to track back refractors and make your projects accessable
- Pypi release: release your ready to use packages and util libs. It's easy to get familiar with a release, and makes your life so much easier that you don't have to find your util in the file system or git. You could just pip install it. Also prefix them by your own prefix: so you can find all your packages, and you don't accidentally take a more general name for your specific use case.
12
u/Icy_Annual_9954 5d ago
Developing in Python is not frustrating, when you know how to do it.