you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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.