![]() Quite the contrary: I wouldn't mind it if things were more complex, but worked well, once you mastered them. well, that's true, but I wouldn't care about that. So, one complaint you could make is that Python packaging isn't very friendly to incompetent users. Their problems come from just being really, really bad at what they are supposed to be good at. The overwhelming majority of Python users are bottom-of-the-barrel worst programmers to walk the face of the Earth. The overwhelming majority of "pain" the author talks about is self-inflicted. ![]() OP mistakes the problems Python users have with the actual problems Python packaging system has. It won't be a high-quality one, but in this context nobody cares about quality anyways. You'll save a lot on developing the product. But, if your goal is to make a project in the context of an industry giant, then Python is a great pick - you'll have an infinite stream of replaceable programmers, lots of 3rd-party libraries. if you are planning on a project for yourself, or for a group of skilled and motivated individuals - there's no reason to choose Python, in fact, you'll come to regret it if you do. The better programmers started to flee Python some 5-10 years later, but it had already enough momentum to attract lots of mediocre programmers, and before you knew it, Python started to be used everywhere, and while the quality of Python programmers consistently dropped, the popularity only grew. This had an appeal to better programmers of that time (early 2000s), and this made others believe that language was what made those better programmers better. Python just happened to fill the niche of "what language should I write in if I think Java sucks?" The choice of Python was often reactionary, to spite those who chose Java. What was the initial seed that created this popularity? - well, it seemed cool for nonsense reasons. Unless you find a way to make it popular, Python will stay popular and your language will fade into oblivion. It doesn't matter if you do everything better in your language than how it's done in Python. But you also cannot compete against it on engineering merits. It doesn't have any engineering merits of its own. Today, Python is popular because Python is popular. But that's rather an odd exception to the rule. Just not in the case of Python 2.X -> Python 3.X transition. Community bravely moves fast and breaks things. > community held off for so long on making breaking changes. There's a similar story with C interface, TK bindings, and probably more that I didn't encounter personally. interface of SSL library Python uses changed in incompatible ways not so long ago, which now prevents older codebase from building with new library and newer codeabse building with the old one. Some of these problems can be blamed / explained in terms of others. You start to discover that you can no longer install things due to botched dependency specification, you start installing things manually, repackaging while fixing dependency definitions and so on. ![]() These typically work if you can allow yourself to be within last 4 versions of Python, but if you fall behind - all bets are off. Python's own release cycle is intended in such a way that they don't care about more minor versions backwards: and typically, you can no longer build Python of that version on a modern OS with a modern compiler.Īnother consequence of this is that if you need to install an older package, even if in principle it should work with current Python, you'll discover that Python packages will have a lot of very particular and very convoluted dependency relationships. So, to even build and test packages for more than 4 minor language versions is prohibitively expensive. The matrix of supported environments is huge. The reality of Python is this: there's no standard and no obligation to keep any Python code working. ![]() That's actually very true, the author just didn't choose a very good example. I should write an article on that because really, nobody wants to setup python just to use a tool.ĭo check out nuitka though, it's has great support for QT, numpy, advanced Python constructs and has a permissive learning curve. However, Python is not like Go or Rust, and providing such an installer requires more work, so a huge part of the user base (which have a lot of non professional coders) don't have the skill, time or resources to do it. This means the users don't have to know it's made with Python or install anything, and it just works. If I provide an end user software to my client written in Python (so not a backend, not a lib.), I will compile it with nuitka ( ) and hide the stack trace (. That's more of cultural problem in the Python community.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |