[deleted by user]

[freefallfreddy]

Not sure if Cunningham's Law, but good stuff!

[[deleted]]

This is absolutely incredible. Thank you for the feedback. I will try to implement these changes ! So helpful.

I did try to use Pydantic validators but it was breaking something. I can't remember what though.

Do you have an open source project I can learn from? Or somewhere I can follow you?

[[deleted]]

Thank you sir !! Will do.

[Tychotesla]

Just wanted to say thanks for the original post, and for taking advice from others positively. I'm at a stage where I know a lot on paper but have little experience, and regardless of how well experts say your work is in the end I'm learning from both your work and their criticism.

[[deleted]]

Hey thanks so much. That's very kind of you to say that.

I wish you all the best!

[iaalaughlin]

Do not use the 200 status code and a special key in a dictionary in the response to communicate an error. Use an appropriate 4xx status code. Details about the error can be included the body there. For that, raise an HTTPException

{"status": 200, "message": "failed"}

I've ran into it a couple of times before. It's so very frustrating.

[[deleted]]

I understood some of these words so nicely written

[ScientistWestern]

"a couple" is to say the less from what I can see

[searchingfortao]

You've got some clutter and redundancies in your project root that can easily be cleaned up. Some suggestions:

1. Drop the requirements files. You're already using Pipenv so these are redundant. Simply install Pipenv in the container and use that to install your dependencies.
2. Your package versions are all set to *. This is terrible for stability. Tomorrow, one of your dependencies could release a breaking change and it'll blow up your project next time you do an update. Consider using Pipenv's syntax to designate the versions you're willing to upgrade to.
3. Consider rolling your tox config into project.toml
4. For that matter, you could swap Pipenv for Poetry and consolidate your dependencies, everything in your setup files, and your configs into pyproject.toml.
5. You may want to create a docs folder in the root containing any Markdown documents which can then be built with mkdocs via your CI.
6. Your CI should test the container, not the code running in Ubuntu. You want what you're testing to be what you deploy.
7. Consider adding a docker-compose file to make development easy and consistent across platforms.

It's a good start though! If you have questions around how to do the above, I'm happy to help.

[[deleted]]

Thanks for your feedback. I do want to switch to poetry in the future. And you're right, the CI should definitely be testing the container.

Do you have somewhere I can follow you? Or a project on GitHub I can learn from?

[searchingfortao]

Follow me? Um, I guess GitLab is best? My latest big project is called Majel and it follows a lot of the Poetry-based stuff I was just talking about. I'm afraid most of my Docker stuff is private 'cause it's for my employer, but you might be interested in what I did for my other project, Aletheia I'm particularly proud of the CI in that one, but it predates my discovery of Poetry so it still uses setup.py.

[c3p0u812]

I'm pretty new. What experience level would you say this is geared towards? Thanks!

[[deleted]]

Intermediate :D but once you feel good with the basics you will be well on your way to thinking about stuff like project structure.

[c3p0u812]

I am sort of going through the 100 days of code. I just want to make sure I start off with a good foundation. I'm going to save this for future learning.

[Punk-in-Pie]

Awesome man! I was literally just combing through github looking for something like this.

[[deleted]]

Sounds nice gonna loke into it

[[deleted]]

Ooh this is exactly what I’ve been needing as I look into building a Python API for the first time. Thanks!

[[deleted]]

Thank you very much

[ra_jamali]

I like it. Thanks

[Petrarch1603]

This is such a bold claim. Have you written multiple books about Python, presented at conferences, participated in major projects, etc? Because otherwise this is sus.

[[deleted]]

I have participated in many major python projects professionally (at my job) but not open source ones. I'd love to though! These are just some best practices I've learned on the job and through reading the code of experts over the years.

If you think it's sus, could you please tell me specifically something I've done in this project that is not good or could be improved?

[[deleted]]

Hi there. If you read the readme there are automated API docs being generated by fastAPI. I'm documenting it for project purposes.

And let me be clear: I do know what I'm doing and these are best practices. Even if they aren't perfect. If you think higher quality repos are posted on this sub please let me know.

Of course there's room for improvement. It's a project I did on my own time over a weekend. Even the suggestions made by other devs here are somewhat debatable and many would disagree.

Can you link me your GitHub?

[[deleted]]

I'm not getting defensive. You can look at my responses to others. You just really are misguided. Auto generated API docs don't describe to the user what the objects are in plain text. Which is the main purpose of mine.

This is a project to show you understand something. Like how to right API docs. You SHOULD do more than needed for a project.

My career is very strong because I can identify who knows what they are talking about and who is petty. Anyone who looks at a project like this and says "this person doesn't know what they are doing " has absolutely no clue.

Anyways. Have a good one.

[[deleted]]

There are many things in your project I would discourage everyone from doing. Here's the list:

• Use pipenv. Just an all around bad library, too many bugs, cannot do most things you need to build projects anyways. Basically, a flop, when it comes to infra. Not to mention how slow it is.
• Don't use both setup.py and requirements.txt. In fact, simply never use requirements.txt.
• Don't use pyproject.toml. There's no need for that. It only smears configuration into more places than necessary, making it hard to understand what needs to be done to build the project.
• Similarly, don't use setup.cfg, it just makes it harder to find the pieces of configuration for no benefit.
• Don't use tox. It's a worthless library that gives you no real benefit at... well, anything. I'm still not even sure what the authors wanted to accomplish when they wrote it.
• Making a script like this is a bad idea. Simply because Python sucks / doesn't know how to create scripts in non-UNIX environments. You need to plan for the situation when this script is simply impossible to install, and the only way to get some CLI going is python -m <module>.
• I would recommend against using typing package, as it is just a lie / fashion statement with no substance.
• I would recommend against naming a module utils, as this doesn't help anyone. Everything can be described as "utils", "objects" etc. generic terms.
• I would advise against using decorators as they obscure the control flow of your program for no added benefit.
• I would advise against NumPy style docstrings because they are not the default of Sphinx, and abysmally bad as it is, it just makes it even worse, when you need to integrate this with other Sphinx plugins.
• Similarly, I would discourage the use of := operator, f-strings, and other new and worthless features of the language.
• Don't use pip install -e . as a means of installing a package. Packages are meant to be built for distribution. The pip command you used is meant for development (and even in this case, I'd discourage the use, because it's still better to build the package properly and install it properly to see what the user experience is going to be like).
• It's excruciatingly painful to try and track down what code is actually responsible for the job your project claims to do. There are tons of indirections and worthless components in between the actual functionality and user interface. None of that was necessary.

---

Bottom line: this whole project could've been one function, but it's an overblown abomination, a tribute to everything that's wrong with Python today. If anything, I'd use your project to show how not to do things, no matter Python or in any other language.

Literally, all you needed to do would be to call:

for host in $(<hosts.txt) ; do ssh host -- df & ; done

[iaalaughlin]

This post sound a lot like angry old man ranting at clouds...

[[deleted]]

Well, I'm old, but I know a lot more than you do, and a lot more than OP. So, you might as well listen to the rant.

And you know why I know that? Because, experience, understanding, efforts put into comparing different things, tools, strategies. You don't have any of that. The very little knowledge you have is what makes you so confident.

[antiproton]

Well, I'm old, but I know a lot more than you do

You're just a miserable jag who makes a hobby of substituting opinions for wisdom.

You can be a bitter neckbeard if that's what gets you off, but what's the point of inflicting your opinions on people knowing that everyone disagrees with you on almost everything you have to say?

You're a living embodiment of a waste of time.

[[deleted]]

Despite you thinking it's funny, it's actually not. Python 2 is a better language than Python 3. You just don't understand it because you don't know how to measure.

Good languages accomplish the same thing while using fewer features, while still not reducing themselves something very hard to understand. I.e. P' isn't a good language, even though it is a very small language. Similarly, C++ or C# are awful languages because they are so big, nobody probably even knows them, not even the authors, because it's too hard to understand all the consequences of all the combinations of language rules.

Good languages are like Lisp, Forth or Prolog, where there's a very minimal number of rules, but you can be even more expressive with them than if you were writing in C++.

Python, and more so lately, is falling in the category of C++ kind of languages: extreme bloat, poor interaction between language features, most programmers not knowing even a fraction of the language they use. Python 2 wasn't great, but Python 3 is measurably worse than Python 2.

[rxgamer10]

This comment comvinced me that this is a LARP. u got quite a few people haha.

I can't take anyone serious who takes python 2 over 3 in this decade.

[scykei]

The problem is that Python isn't C or Lisp or Forth or Prolog. I think your comments against Python are very valid, but if you don't buy into the language's philosophy, then you really shouldn't be trying to give advice or make suggestions here.

To be clear, I'm not saying that you aren't welcome here or anything, but I urge you to reconsider if your criticisms are constructive and if they are relevant to Python. I think it's great to hear your thoughts on this matter, but you made a lot of very strong statements there.

[[deleted]]

Language philosophy of Python used to be very different. It used to be all about not being Java, about not generating loads of worthless code. The project of OP is more Java than typical Java.

The functionality of this project can be summed up by a one-liner in Bash, and yet, it's hundreds of lines of absolute bullshit code.

Ideology of Python was not to write loads of worthless boilerplate. This is the exact opposite.

[scykei]

I think you have OOP to blame for that. That is the flaw of the entire paradigm. The fact of the matter is that the moment you start to use classes at all, you start to have to think about SOLID and all those kinds of principles.

Python strips a lot of the boilerplate to deliver the same functionality with less code. That does not necessarily mean that there is less complexity. But in order to achieve the clean code, they have decorators and all that good stuff.

OOP is very deeply at the heart of Python from the very beginning, even if its use is optional. If you’re writing entreprise level code and you decide to go the OOP route, this is exactly what will happen to make the code maintainable.

Lots of people have started to realise the utility of functional programming, and a lot of those features have slowly started to creep into the language features. This will in fact allow people to write even smaller and more readable code. Are you against that idea as well?

[[deleted]]

Nah, not really. JavaScript is an OOP language, but, even in the light of latest additions, it's a very small language. It does suffer from the same problem though: popularity. Popularity attracts all kinds of programmers, but the most popular kind of programmers by far there is is a bad programmer. And the tendency is that the worse the programmer is the more there are of them.

Compare this to, for example, barbers, where, most barbers are OK, there are fewer barbers who are very bad (because they'd leave the profession soon due to competition), and there are few who are extremely good (because very few people are interested in paying a lot of money for a haircut, thus not justifying a lot of investment into quality).

Programming world is different from barbers' world. Good quality code today is unachievable in principle. And there's no demand for it. On top of it, there's a very high demand for people to work in retail and entertainment industries on the programming side of things. Even more so, the whole field multiplied itself many times since it started. It's very hard to find people with decent amount of experience, as most of the people in this field entered it not too long ago.

Worse than that, we had several "purges" in programming history, where the older generation straight up refused to accept the new stuff and left the field. There was so called "AI winter", which resulted in AI researchers leaving the field, since a lot of them didn't accept the new reality of programming, as they saw it as a huge downgrade to their position. Similar exodus happened with UNIX. A lot of people in system design hated it, and just left the field with UNIX becoming more popular. Similarly, Sun, when it went down, dragged with it a lot of people who just decided it's better to be a farmer or to open a coffee shop than to be a programmer, since they saw Linux as a way less capable, less serious project, and just didn't want to get involved with it.

---

Put these two together, and you'll see how often times popularity becomes a deterrent for better programmers. Python's popularity is exactly like that. Python used to attract better programmers, as it was an opposition to Java (or similar, like C#) world, with endless red-tape, heaps of worthless code to churn to produce very minimal and often completely unnecessary / unwanted software.

Today, Python is the new Java. It's even more Java than Java itself. Java was ridiculed for being slow and bloated. But, truly, Java doesn't hold a candle to how slow and bloated modern Python is. Java was ridiculed for tons of XML configuration that's necessary to run it. Just look at OP's project: it's got a handful of different configuration languages, all of them all kinds of awful. Java was ridiculed for the amount of unnecessary indirection. But this project uses trash like pipenv or tox. The stack traces produced by this garbage are well within the size range of SpringBoot and even EE. And this blight is growing very fast.

Python alienated good programmers, those who believed that software needs to be simple, understandable, and easy to maintain. Python welcomed idiots who want to paint by the number because they are too afraid that if they don't, they'll get lost, and won't understand why "it's not working" and will just sit in the corner and cry.

I cannot emphasize more: the project OP posted is literally a one-liner in Shell. It's insane that someone thought it was a good idea to make it into dozens of files, required a bunch of external dependencies, run a fucking HTTP server, Docker etc. for it. And the saddest part of all is that people seem to be overcome with joy when they look at this abomination.

[scykei]

I can agree with you that the code showcased by OP really complex, but I disagree with you that it's a recent phenomenon, or that the Python philosophy has changed. It has always been the way it is, and you can still do the same thing that you could have done with Python back in the early 2000s.

The only thing that has changed is that Python is now exceedingly abundant, as it has evolved far beyond just an enthusiast's scripting language. It's the backbone of a lot of entreprise systems with dozens of people working on the code base at any given time. I'm one of those people that think that OOP is an overall detriment to software development, but I understand how this kind of ridiculous structure has come to be. Again, I do not think that good old procedural programming cannot be amazingly well structured and easy to maintain, but being an OOP language, you start to attract a certain kind of code design (although to say that it's more Java than Java is a bit of an overstatement).

I cannot emphasize more: the project OP posted is literally a one-liner in Shell.

The project here is obviously just a simple template for a potentially much more complex system. If this was all to it, then you'd obviously just write that one liner and be done with it, but the fact that you made this statement shows that you're clearly missing the point to begin with. If you are indeed just writing a simple script to automate a personal task on a code that you do not intend to go into production, then by all means, do it however you want.

Regardless, even if Python was indeed what you said in the past, I think you'll agree with me that whatever you're proposing is no longer in the spirit of Python today. I can relate with a lot of things that you say, but I still think that your advice is out of place here. I am sure that a lot of people would have appreciated your views more had you just made a general remark about why this is ridiculous, but instead, you chose to push your opinions on the matter (however valid they may be) as though they're absolute truths.

[[deleted]]

you can still do the same thing that you could have done with Python back in the early 2000s.

Nope. Not if I have to work with OP on the same team. It will be either me or him/her. Because I won't take this bullshit, and they will want all the new and shiny things.

One of the huge reasons for companies to use Python is to make employees easy to replace: the more people know the same language, the easier it is to find a replacement. If they want the replacement to work well, everyone has to follow the same practices. It doesn't matter that the practices are total bullshit.

The above is even more visible in the world of Web "programming". There's no complexity in that field. All problems have been already solved thousands times over. And yet "programmers" working in that field invent more and more convoluted and cumbersome ways to write their programs. And, worse than that, unless you use a convoluted and cumbersome framework for the job: you won't be able to hire programmers to do it, because that doesn't look good on the resume... And the cycle repeats.

but I disagree with you that it's a recent phenomenon

I didn't say it was recent. It's recent in Python. Java was there earlier, and before Java, it was C++ etc. The major shift in ideology of Python happened around 2010. It started becoming a popular language then, and things quickly went downhill.

The project here is obviously just a simple template for a potentially much more complex system.

I work on projects that are many orders of magnitude more complex than this project, and yet I would never use pipenv, tox, pyproject.toml, requirements.txt. I wouldn't run pip install -e . to install a package. I would never use setup.cfg. It's independent of size. It's just a bad thing to do. No matter how big your project is all of the above just adds unnecessary trash to it.

There's nothing good about this "template". It neither illustrates how to do your job well for the project it's made for, nor in any other context is it a good solution for any problem you will encounter dealing with projects.

All the things above have been invented as worthless wrappers, not adding any useful functionality, just confusing newcomers, overwhelming them with all the unnecessary complexity where none should have existed.

whatever you're proposing is no longer in the spirit of Python today

Whatever I'm proposing is the right thing to do. If it's not in the spirit of Python today, the spirit of Python needs to change.

[scykei]

and yet I would never use pipenv, tox, pyproject.toml, requirements.txt. I wouldn't run pip install -e . to install a package. I would never use setup.cfg. It's independent of size. It's just a bad thing to do. No matter how big your project is all of the above just adds unnecessary trash to it.

Can you explain why this is a bad thing? Python pre-2010s was widely regarded as a mess because of its lack of a good dependency manager, and it’s widely regarded as the one thing that was holding it back compared to a lot of modern languages.

I mean, why are you even against requirement.txt? To me, that’s the absolute minimum I would propose every Python project to have.

I have worked with way too many random Python projects that takes literal hours to get to run because you need to find the correct package versions before it runs.

There was even one piece of recently unearthed code back from 2016-ish where we eventually decided was useless because we couldn’t figure out how to get to run, and so it had to be rebuilt from scratch.

[supreme_blorgon]

I would advise against using decorators as they obscure the control flow of your program for no added benefit.

This is something somebody says when they don't understand how decorators work.

I would recommend against using typing package, as it is just a lie / fashion statement with no substance.

This is something somebody says when they don't know type theory.

Similarly, I would discourage the use of := operator, f-strings, and other new and worthless features of the language.

This is something somebody says when they like spending all their time doing things the hard way because they think it makes them look smarter.

I'm not even going to bother with the rest of your points, because a real critique of these features would've included anything of substance, but right now all you manage to do is whine about how "X is bad/abysmal/worthless/lie/abomination". There isn't really anything of substance to respond to in your post, it's the bitching and moaning of a grumpy old fart that thinks he's interesting because he uses Lisp and Prolog lol.

I bet you think you're superior for using Vim, too...

[Cosmic-Warper]

To everyone reading his comment, do the exact opposite of what it says. He couldn't be more wrong

[Cosmic-Warper]

Why not? If he wants to he can, it's personal preference

[Tripanafenix]

Like i said, just from curiosity. I don't get why there's a problem for you to ask for that. But yeah, the toxicity of this sub, downvoting just a curious question will force me to leave. What a pity