Python has a lot of problems that really slow down development, but they are all fixable.
The biggest issue, in my opinion, is in dependency management. Python has a horrible dependency management system, from top-to-bottom.
Why do I need to make a "virtual environment" to have separate dependencies, and then source it my shell?
Why do I need to manually add version numbers to a file?
Why isn't there any builtin way to automatically define a lock file (currently, most Python projects just don't even specify indirect dependency versions, many Python developers probably don't even realize this is an issue!!!!!)?
Why can't I parallelize dependency installation?
Why isn't there a builtin way to create a redistributable executable with all my dependencies?
Why do I need to have fresh copies of my dependencies, even if they are the same versions, in each virtual environment?
There is so much chaos, I've seen very few projects that actually have reproducible builds. Most people just cross their fingers and hope dependencies don't change, and they just "deal with" the horrible kludge that is a virtual environment.
We need official support for a modern package management system, from the Python org itself. Third party solutions don't cut it, because they just end up being incompatible with each other.
Example: if the Python interpreter knew just a little bit about dependencies, it could pull in the correct version from a global cache - no need to reinstall the same module over and over again, just use the shared copy. Imagine how many CPU cycles would be saved. No more need for special wrapper tools like "tox".
I've always seen it like this: Not everyone builds reproducible software with Python (or in general) and how you handle dependencies can vary. Python leaves it open how you do it: globally installed packages, local packages, or a mix of both.
In the end, it needs to find the import in the PYTHONPATH, so there's no magic involved, and there are multiple robust options to choose from.
So instead of bashing Python for not shoveling down an opinion on you, it's up to the developers to choose which tools they want to use.
If they don't choose one and are unable to freeze their dependencies, it's not a Python problem, but IMO lack of skill and seniority.
Python's dependency hell is what made me first look at Julia. I develop on Windows (someone has to :) ), and it was just impossible to get all of the numerical libraries like pydstool, scipy, FEniCS, Daedalus, etc. playing nicely together... so I gave Julia a try. And now the only time I have issues getting a package to run are Julia packages which have a Python dependency. Python is a good language, but having everything in one language and binary-free is just a blessing for getting code to run on someone else's computer.
saddened to see this poorly constructed comment berating python at the top of this thread. the author seems to have some personal issues with the language given the generally frustrated tone of the comment. the entire comment could have just been 1 line "We need official support for a modern package management system, from the Python org itself." which would be consumed as constructive feedback by all readers with the right context. but somehow the author chooses to "vent" adding unnecessary drama to something that does not get in the way of writing high quality production grade python apps (general purpose, web, ai or otherwise)
there is no language that is devoid of shortcomings - so to any new (<3 yrs exp) python users, please ignore the above comment entirely as it has no bearing on anything practical that you are doing/will do. and all experienced python users know that there are ways to work around the shortcomings listed here and beyond.
It is funny - half of the real desire/need for containers comes back to these sorts of issue with both node and Python. And then they bring in their own different challenges.
I agree that builtin tools suck for dependency management.
However a lot of the issues that you mentioned (such as lock file and transitive dependencies) can be handled by pipenv, which should be the default package manager
Python was a scripting language. All those problems are caused by people using it like something it isn't. Python has way outlived it's usefulness and it's about time we move on to something better.
The virtualenv thing just galls me. Sure, pipenv aped rbenv - appropriately, I might add - but until they supplant virtualenv as the recommended way to have separate environments, I'll pass.
.NETs solution to this was the project file, a configuration file that lists the compiler version, framework version, and dependencies (now including NuGet packages and their versions).
> The biggest issue, in my opinion, is in dependency management. Python has a horrible dependency management system, from top-to-bottom.
I agree, although a lot of it has to do that there's so much misinformation about the web, and many articles recommending bad solutions. This is because python went through many packaging solutions. IMO the setuptools one is the one that's most common and available by default. It has a weakness though, it started with people writing setup.py file and defining all parameters there. Because setup.py is actually a python program it encourages you to write it as a program and that creates issues, setuptools though for a wile had a declarative way to declare packages using setup.cfg file, you should use that and your setup.py should contain nothing more than a call to setup().
> Why do I need to make a "virtual environment" to have separate dependencies, and then source it my shell?
Because chances are that your application A uses different versions than application B. Yes this could be solved by allowing python to keep multiple versions of the same packages, but if virtualenv is bothering you you would like to count on system package manager to keep care of that, and rpm, deb don't offer this functionality by default. So you would once again have to use some kind of virtualenv like environment that's disconnected from the system packages.
> Why do I need to manually add version numbers to a file?
You don't have to, this is one of the things that there's a lot of misinformation about how to package application. You should create setup.py/cfg and declare your immediate dependencies, then you can optionally provide version _ranges_ that are acceptable.
I highly recommend to install pip-tools and use pip-compile to generate requirements.txt, that file then works like a lock file and it is essentially picking the latest versions within restrictions in setup.cfg
> Why isn't there any builtin way to automatically define a lock file (currently, most Python projects just don't even specify indirect dependency versions, many Python developers probably don't even realize this is an issue!!!!!)?
Because Python is old (it's older than Java) it wasn't a thing in the past.
> Why can't I parallelize dependency installation?
Not sure I understand this one. yum, apt-get etc don't parallelize either because it's prone to errors? TBH I never though of this as an issue, because python packages are relatively small and it installs quickly. The longest part was always downloading dependencies, but caching solves that.
> Why isn't there a builtin way to create a redistributable executable with all my dependencies?
Some people are claiming that python has a kitchen sink and that made it more complex, you're claiming it should have even more things built in, I don't see a problem, there are several solutions to package it as an executable. Also it is a difficult problem to solve, because Python also works on almost all platforms including Windows and OS X.
> Why do I need to have fresh copies of my dependencies, even if they are the same versions, in each virtual environment?
You don't you can install your dependencies in system directory and configure virtualenv to see these packages as well, I prefer though to have it completly isolated from the system.
> There is so much chaos, I've seen very few projects that actually have reproducible builds. Most people just cross their fingers and hope dependencies don't change, and they just "deal with" the horrible kludge that is a virtual environment.
Not sure what to say, it works predictable to me and I actually really like virtualenv
> We need official support for a modern package management system, from the Python org itself. Third party solutions don't cut it, because they just end up being incompatible with each other.
setuptools with declarative setup.cfg is IMO very close there.
> Example: if the Python interpreter knew just a little bit about dependencies, it could pull in the correct version from a global cache - no need to reinstall the same module over and over again, just use the shared copy. Imagine how many CPU cycles would be saved. No more need for special wrapper tools like "tox".
There is a global cache already and pip utilizes it even withing an virtualenv. I actually never needed to use tox myself. I think most of your problems is that there are a lot of bad information about how to package a python app. Sadly even the page from PPA belongs there.
It's not that bad if you use the right tools. The two main options are an all-in-one solution like poetry or pipenv, and an ensemble of tools like pyenv, virtualenvwrapper, versioneer and pip-tools. I prefer the latter because it feels more like the Unix way.
Why should Python have some "official" method to do this? Flexibility is a strength, not a weakness. Nobody ever suggests that C should have some official package manager. Instead the developers build a build system for their project. After a while every project seems to get its own unique requirements so trying to use a cookie-cutter system seems pointless.
The virtual env is really the thing that has stopped me from using python. It's a lovely language but the tooling around it needs a lot of help. I'm sure it will get there though. I mean if the js folks can do it, certainly python can.
Remember NOT to jump into Python for your new product if don't know Python. If you are developing for a young startup, have time crunch, then stick to what you know.
IF you do not have a language, or know Python a bit, then pick Python. Here are some of the reasons why I stick to Python (young startup/web APIs):
- OOPs is not too strict (might give a headache to some folks)
- Mixins, lambda, decorators, comprehensions - Pythonic ways make me feel productive easily
- Create a data Model, drop into a shell, import and try things
- Can do that on a live server
- Do the same with Controllers, or anything else actually
- really nothing fancy needed
- Command line processing, SSH, OS integration, etc. has so many great libs
- Python Dict someone looks like JSON (this is purely accidental but useful)
- Debugger support even in free IDE like PyCharm Community Ed is great
- Integration to a world of services is so easy, even ones you do not commonly see
- Documentation - many libs have consistent structure and that helps a LOT
- Really large community, perhaps only smaller than Java
- The even larger group of people using Python in all sorts of domains from Biotech to OS scripts
What I would like improved in the language would be an even longer list. Every language has a list like that, but when you are focused on being scrappy and building a product, yet making sure that software quality does not take a big hit, Python helps a lot.
> Remember NOT to jump into Python for your new product if don't know Python. If you are developing for a young startup, have time crunch, then stick to what you know.
Are you saying this as a general maxim (don't try to learn a new tech under pressure) or because of characteristics specific to Python, that make it worse in such a situation than any other language/ecosystem?
I know it's only a one off anecdote but two developers in my team who previously didn't know python used it for a small time-critical project and it was a brilliant success.
The main point I am trying to make is that not all of us are language experts. I absolutely know the vital role that language experts play and that we need to solve the issues. But companies need to build in the meanwhile. Python is easier to learn, this is why it is such a popular language in Universities.
I am not a high IQ person to even grip some of the nitty-gritty underpinnings of a language. But should that stop me from building a product?
In the end, I need a language that is easy to pick-up, be productive, has its heart in the right place. A young Python programmer can web scrap easily or plug into Ansible or so many other things. If you know of another language that would make more practical sense and still be easy to pick-up, I would switch.
Reading this got me thinking and I wonder if other people feel like me about this, so I'm going to share it. This is not serious, but not entirely unserious...
I try to be a good sport about it, but every time I write python I want to quit software engineering. It makes me angry how little it values my time. It does little for my soured disposition that folks then vehemently lecture me about the hours saved by future barely-trained developers who will ostensibly have to come and work with my code. Every moment working with python (and that infernal pep-8 linter insisting 80 characters is a sensible standard in 2019) increases my burnout by 100x.
I try to remind myself that we're trying to make the industry less exclusive and more welcoming to new developers and "old" isn't necessarily "good" (in fact, probably the opposite), but damn I just don't understand it.
It used to be that I could focus on other languages (Erlang, Nemerle, F#, Haskell, Ocaml, even C++) and sort of balm myself. But now, I can't even overcome the sinking feeling as I read the Julia statistics book that I'm going to be dragged back to Python kicking and screaming in the morning, so why even bother?
And frustratingly: it's one of the few languages with decent linear algebra libraries. And that means it's one of the few languages with good ML and statistics support. So it's very hard not to use it because when you want to cobble together something like a Bayesian model things like PyMC or Edward actually give you performance that's obnoxiously difficult to reproduce.
This is what the industry wants and evidently a lot of people are okay with it, but to me it's misery and I can't work out why people seem to like it so much.
If only its package management were as easy as its syntax...
I wish pip worked the same way as npm: -g flag installs it globally, otherwise it creates a local "python_modules" folder I can delete at any time. And optionally I can save the dependency versioning info to some package.json...
Instead, pip is a nightmarish experience where it fails half the time and I have no idea where anything is being installed to and I'm not sure if I'm supposed to use sudo or not and I'm not sure if I'm supposed to use pip or pip3, etc.
Holy Crap! What a lot of irrational, hyperbolic hate for Python.
I think everybody should spend their first couple of years working in Fortran IV on IBM TSO/ISPF. No dependency management because you had to write everything yourself. Or maybe [edit: early 90's] C or C++ development where dependency management meant getting packages off a Usenet archive, uudecoding and compiling them yourself after tweaking the configure script.
I'm not saying Python is perfect, but if it's causing your burnout/destroying your love of programming/ruining software development you seriously need some perspective.
According to people who work with a lot of programmes teaching coding, the reason python is so appealing to new coders is the syntax. Particularly the lack of braces, the indents, the nice keywords, that make reading code much easier to a newcomer.
Having taught both python and JavaScript, I can tell you that the former is far far less confusing to newcomers than the latter. Imagine explaining the problem with equality comparison or prototypes in JS to someone who just learnt what an IF statement is.
The reason I agree that python will dominate programming for decades to come is the batteries included and pythonic approach that enables people to do cool things with just a few lines of code. As a result of the above, the ecosystem has reached critical mass. For most tasks there’s a library that does that, and it’s good, and it’s easy to use, and the developer of the library usually doesn’t expect you to understand their opinionated philosophy to use it.
I love the python convention of putting a minimal example on the homepage of a library.
You’re not going to get your average developer to appreciate the beauty of Lisp or the value of static typing. They want their ML to work, or their graphics to display, that’s all. Ends not means, almost entirely, for most people who aren’t full-time programmers.
Let’s not hate on a language that opens up programming to the world, unless we want to be gatekeepers. If you want to maintain an air of superiority, just learn Lisp or Haskell or C++ and write code that’s “deeper” into the tech labyrinth. Programming will probably specialise into “end user programming” and “Service and system programmers”. Embrace the democratisation of coding.
The part that Python really bothers me, as someone who had write Python for almost 10 years, and right now doing it professionally, though personally I don't consider myself a Python developer rather than a Python senior user, is actually obvious to nail down, and frustratingly, difficult to handle.
SLOW. The sin of all. I don't want to make other arguments with people who just come to repeat 'Oh you can make it fast, you are doing it the wrong way'. Sorry, I have heard that 100 times, now is sounds like bug-as-feature excuse to me.
Sorry, but Python is just slow. All the stuff people might bring up is just trying everything to bypass Python itself. Multiprocessing is hell to work with, buggy and unpredictable. Cython is OK but it is not Python.
Python's slowness is like cancer, and terminally so. Down deep, it is because its overtly flexible/loose type system, the never-going-away GIL, and prematurely exposing of C-API makes it almost impossible to optimize without breaking the existing compatibility.
And most importantly, I don't think it is solvable, truth is the patches are so integrated, people already forget what problem they tried to fix in the first place and just live with it.
But it will haunt Python in long term though, people will be struggling with Python in performant production until they start reimagining a world that without Python. Maybe a better Python in that sense.
Python's success is richly deserved. The fact that it has been a long time coming (Python is almost 30 years old!) is an indication of the amount of sheer effort involved, and should give heart for all those working on building up the next generation of languages.
Since this forum is likely to have some folks looking towards the future, I found interesting a couple of talks by Python veteran Armin Ronacher [1, 2]. Watching that presentation makes me wonder whether I should think of this in the context of "Worse is better". That said, Python's runtime introspection is such a killer feature that it's difficult to explain how empowering it feels for someone who is relatively new to programming.
It's so refreshing to not see anyone here whining about Python forcing them to indent their code properly. The kind of people who think that's a PROBLEM instead of a FEATURE really should not be ever writing any new code, and instead should be punished by forcing them to maintain other people's code written with that same lazy misguided attitude, until they recognize how self indulgent, inconsiderate, and disrespectful that is not just to other people who have to read their code, but also to themselves.
The same kind of people criticize Lisp for having too many parenthesis, then go on to write unintelligible shell scripts, Perl and C++ code chock full of skewbald menageries of sigils and punctuation bound together with a towering inferno of precedence rules, terribly worse than Lisp's "too many parenthesis".
What stood out to me, reading the comments, is how among the first few comments I read there were 4 comments from people with decades of experience writing python professionally. Each stating their dislike for the language and citing entirely different parts of the language as its biggest problem.
Personally, I'm primarily a C++ programmer with about a decade of professional experience in C++. I also used to do daily work in C# for a few years. For me, python is a language which I use for making simple command line tools, for processing input and clobbering together different tools. I use it to build interfaces which streamline certain workflows. Essentially, I use it as a more powerful replacement for bash or batch. For that purpose, I find that the language works wonders and is quick and easy to work with.
Python is not eating the world so much as becoming the new Excel. It has a pretty easy learning curve for people who are not programmers. It has pretty good built in tooling. A domain expert, who is not a programmer, can put together pretty impressive models and visualizations relatively quickly.
However, like with Excel, there are serious issues regarding reproducibility, performance, and long term maintenance.
For what it's worth, I have none of the issues the currently top voted comments describe. Dependency hell (apt does that for me), closer to burnout any time I work with it, would rather work with C++ (a language with a completely different purpose)? If the author of the article had written this, people would fall over themselves to say how wrong they are. Nearly everyone who tried Python loves it. From this thread you'd think we're talking about Visual Basic for Applications.
There is a reason Python is one of the most popular languages. PHP was popular because it's quick and dirty, but Python is popular because people love working with it. The arguments in this thread are beyond me. (They're also unsubstantiated, but if I ask for substantiation I'm sure someone can rationalize some reasons to dislike any language, so that's pointless.)
One thing very interesting about Python is how gradual the ride up has been. Perl dominated then sputtered. Java shot up and hit the ceiling. C# is mostly limited to Windows, JavaScript mostly to the web. Ruby stole the spotlight for a few years and then faltered mysteriously. Others found their niche. But Python just keeps chugging along slowly gaining ground almost everywhere like a tortoise to multiple hyped-up hares.
Am I correct when I assume that most of the people hating on Python here are using it for medium or big projects?
I feel like the dev community figured this out ages ago:
Statically typed languages are easier to read, harder to write, dynamically typed languages are easier to write, harder to read (and also harder to refactor).
For small projects (scripts, prototypes, etc), you don't care about readability, you just want it to be as easy to write as possible. Python really shines here.
For bigger projects, using Python is painful, but that's also the case with pretty much any other dynamic language..
Considering Python can power the largest web sites (Netflix, Instagram), I don’t understand why there’s so much use of much more complicated platform/languages (eg java, .net)?
Note: I am an amateur which is likely the reason for my ignorance.
In my opinion, the biggest problem facing Python is still concurrency. The mitigation efforts still look to me like Perl's 'bolted on' implementation of object orientation. Python should have gotten rid of the GIL during the 2 to 3 transition. It may have also been an opportune moment to introduce optional typing and maybe even optional manual memory management, making it useful to develop almost all kinds of software. Write a WASM backend and it could have even been used for front end development.
[+] [-] blaisio|6 years ago|reply
The biggest issue, in my opinion, is in dependency management. Python has a horrible dependency management system, from top-to-bottom.
Why do I need to make a "virtual environment" to have separate dependencies, and then source it my shell?
Why do I need to manually add version numbers to a file?
Why isn't there any builtin way to automatically define a lock file (currently, most Python projects just don't even specify indirect dependency versions, many Python developers probably don't even realize this is an issue!!!!!)?
Why can't I parallelize dependency installation?
Why isn't there a builtin way to create a redistributable executable with all my dependencies?
Why do I need to have fresh copies of my dependencies, even if they are the same versions, in each virtual environment?
There is so much chaos, I've seen very few projects that actually have reproducible builds. Most people just cross their fingers and hope dependencies don't change, and they just "deal with" the horrible kludge that is a virtual environment.
We need official support for a modern package management system, from the Python org itself. Third party solutions don't cut it, because they just end up being incompatible with each other.
Example: if the Python interpreter knew just a little bit about dependencies, it could pull in the correct version from a global cache - no need to reinstall the same module over and over again, just use the shared copy. Imagine how many CPU cycles would be saved. No more need for special wrapper tools like "tox".
[+] [-] fearface|6 years ago|reply
In the end, it needs to find the import in the PYTHONPATH, so there's no magic involved, and there are multiple robust options to choose from.
So instead of bashing Python for not shoveling down an opinion on you, it's up to the developers to choose which tools they want to use.
If they don't choose one and are unable to freeze their dependencies, it's not a Python problem, but IMO lack of skill and seniority.
[+] [-] j88439h84|6 years ago|reply
It's good. Projects should use it.
[+] [-] ChrisRackauckas|6 years ago|reply
[+] [-] astonex|6 years ago|reply
Is there anything wrong with pip freeze > requirements.txt and then pip install -r requirements.txt ? This would install the exact versions
[+] [-] wasnthere|6 years ago|reply
there is no language that is devoid of shortcomings - so to any new (<3 yrs exp) python users, please ignore the above comment entirely as it has no bearing on anything practical that you are doing/will do. and all experienced python users know that there are ways to work around the shortcomings listed here and beyond.
this is my psa for the python community!
[+] [-] alwaysanon|6 years ago|reply
[+] [-] brainless|6 years ago|reply
Once your project is setup, dependency management is what you do once in two weeks perhaps. Rest is just writing code.
[+] [-] sosodev|6 years ago|reply
[+] [-] hyperpallium|6 years ago|reply
Dependency hell is everywhere.
[+] [-] adev_|6 years ago|reply
Use Nix.
> nix-shell -p python3Packages.numpy python3Packages.my_important_package
It solves every problem you quoted before.
[+] [-] wisty|6 years ago|reply
[+] [-] arvinsim|6 years ago|reply
Yup, I love Python over my current language in my job(JS/TS).
But I really dislike handling conflicts using pip, requirements.txt and virtualenv.
So much so that I will take JS node_modules over it.
[+] [-] antupis|6 years ago|reply
[+] [-] zys5945|6 years ago|reply
However a lot of the issues that you mentioned (such as lock file and transitive dependencies) can be handled by pipenv, which should be the default package manager
[+] [-] jakeogh|6 years ago|reply
[+] [-] tsss|6 years ago|reply
[+] [-] Chris2048|6 years ago|reply
I seems to have some neat functionality wrt dep handling (and I'd never really heard of it before).
[+] [-] chrisfinazzo|6 years ago|reply
[+] [-] fiedzia|6 years ago|reply
There is and it's called docker. The other issues could indeed be fixed with something like poetry.
[+] [-] moron4hire|6 years ago|reply
[+] [-] takeda|6 years ago|reply
I agree, although a lot of it has to do that there's so much misinformation about the web, and many articles recommending bad solutions. This is because python went through many packaging solutions. IMO the setuptools one is the one that's most common and available by default. It has a weakness though, it started with people writing setup.py file and defining all parameters there. Because setup.py is actually a python program it encourages you to write it as a program and that creates issues, setuptools though for a wile had a declarative way to declare packages using setup.cfg file, you should use that and your setup.py should contain nothing more than a call to setup().
> Why do I need to make a "virtual environment" to have separate dependencies, and then source it my shell?
Because chances are that your application A uses different versions than application B. Yes this could be solved by allowing python to keep multiple versions of the same packages, but if virtualenv is bothering you you would like to count on system package manager to keep care of that, and rpm, deb don't offer this functionality by default. So you would once again have to use some kind of virtualenv like environment that's disconnected from the system packages.
> Why do I need to manually add version numbers to a file?
You don't have to, this is one of the things that there's a lot of misinformation about how to package application. You should create setup.py/cfg and declare your immediate dependencies, then you can optionally provide version _ranges_ that are acceptable.
I highly recommend to install pip-tools and use pip-compile to generate requirements.txt, that file then works like a lock file and it is essentially picking the latest versions within restrictions in setup.cfg
> Why isn't there any builtin way to automatically define a lock file (currently, most Python projects just don't even specify indirect dependency versions, many Python developers probably don't even realize this is an issue!!!!!)?
Because Python is old (it's older than Java) it wasn't a thing in the past.
> Why can't I parallelize dependency installation?
Not sure I understand this one. yum, apt-get etc don't parallelize either because it's prone to errors? TBH I never though of this as an issue, because python packages are relatively small and it installs quickly. The longest part was always downloading dependencies, but caching solves that.
> Why isn't there a builtin way to create a redistributable executable with all my dependencies?
Some people are claiming that python has a kitchen sink and that made it more complex, you're claiming it should have even more things built in, I don't see a problem, there are several solutions to package it as an executable. Also it is a difficult problem to solve, because Python also works on almost all platforms including Windows and OS X.
> Why do I need to have fresh copies of my dependencies, even if they are the same versions, in each virtual environment?
You don't you can install your dependencies in system directory and configure virtualenv to see these packages as well, I prefer though to have it completly isolated from the system.
> There is so much chaos, I've seen very few projects that actually have reproducible builds. Most people just cross their fingers and hope dependencies don't change, and they just "deal with" the horrible kludge that is a virtual environment.
Not sure what to say, it works predictable to me and I actually really like virtualenv
> We need official support for a modern package management system, from the Python org itself. Third party solutions don't cut it, because they just end up being incompatible with each other.
setuptools with declarative setup.cfg is IMO very close there.
> Example: if the Python interpreter knew just a little bit about dependencies, it could pull in the correct version from a global cache - no need to reinstall the same module over and over again, just use the shared copy. Imagine how many CPU cycles would be saved. No more need for special wrapper tools like "tox".
There is a global cache already and pip utilizes it even withing an virtualenv. I actually never needed to use tox myself. I think most of your problems is that there are a lot of bad information about how to package a python app. Sadly even the page from PPA belongs there.
I think people should start with this: https://setuptools.readthedocs.io/en/latest/setuptools.html#...
Yes it still has some of the problems you mentioned, but it fixes some others.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] m463|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] marble-drink|6 years ago|reply
Why should Python have some "official" method to do this? Flexibility is a strength, not a weakness. Nobody ever suggests that C should have some official package manager. Instead the developers build a build system for their project. After a while every project seems to get its own unique requirements so trying to use a cookie-cutter system seems pointless.
[+] [-] void445be54d48a|6 years ago|reply
[+] [-] fnord77|6 years ago|reply
[+] [-] brainless|6 years ago|reply
IF you do not have a language, or know Python a bit, then pick Python. Here are some of the reasons why I stick to Python (young startup/web APIs):
What I would like improved in the language would be an even longer list. Every language has a list like that, but when you are focused on being scrappy and building a product, yet making sure that software quality does not take a big hit, Python helps a lot.[+] [-] yetanotherjosh|6 years ago|reply
Are you saying this as a general maxim (don't try to learn a new tech under pressure) or because of characteristics specific to Python, that make it worse in such a situation than any other language/ecosystem?
[+] [-] zik|6 years ago|reply
[+] [-] brainless|6 years ago|reply
I am not a high IQ person to even grip some of the nitty-gritty underpinnings of a language. But should that stop me from building a product?
In the end, I need a language that is easy to pick-up, be productive, has its heart in the right place. A young Python programmer can web scrap easily or plug into Ansible or so many other things. If you know of another language that would make more practical sense and still be easy to pick-up, I would switch.
[+] [-] KirinDave|6 years ago|reply
I try to be a good sport about it, but every time I write python I want to quit software engineering. It makes me angry how little it values my time. It does little for my soured disposition that folks then vehemently lecture me about the hours saved by future barely-trained developers who will ostensibly have to come and work with my code. Every moment working with python (and that infernal pep-8 linter insisting 80 characters is a sensible standard in 2019) increases my burnout by 100x.
I try to remind myself that we're trying to make the industry less exclusive and more welcoming to new developers and "old" isn't necessarily "good" (in fact, probably the opposite), but damn I just don't understand it.
It used to be that I could focus on other languages (Erlang, Nemerle, F#, Haskell, Ocaml, even C++) and sort of balm myself. But now, I can't even overcome the sinking feeling as I read the Julia statistics book that I'm going to be dragged back to Python kicking and screaming in the morning, so why even bother?
And frustratingly: it's one of the few languages with decent linear algebra libraries. And that means it's one of the few languages with good ML and statistics support. So it's very hard not to use it because when you want to cobble together something like a Bayesian model things like PyMC or Edward actually give you performance that's obnoxiously difficult to reproduce.
This is what the industry wants and evidently a lot of people are okay with it, but to me it's misery and I can't work out why people seem to like it so much.
[+] [-] umvi|6 years ago|reply
I wish pip worked the same way as npm: -g flag installs it globally, otherwise it creates a local "python_modules" folder I can delete at any time. And optionally I can save the dependency versioning info to some package.json...
Instead, pip is a nightmarish experience where it fails half the time and I have no idea where anything is being installed to and I'm not sure if I'm supposed to use sudo or not and I'm not sure if I'm supposed to use pip or pip3, etc.
[+] [-] Ensorceled|6 years ago|reply
I think everybody should spend their first couple of years working in Fortran IV on IBM TSO/ISPF. No dependency management because you had to write everything yourself. Or maybe [edit: early 90's] C or C++ development where dependency management meant getting packages off a Usenet archive, uudecoding and compiling them yourself after tweaking the configure script.
I'm not saying Python is perfect, but if it's causing your burnout/destroying your love of programming/ruining software development you seriously need some perspective.
[+] [-] randomsearch|6 years ago|reply
Having taught both python and JavaScript, I can tell you that the former is far far less confusing to newcomers than the latter. Imagine explaining the problem with equality comparison or prototypes in JS to someone who just learnt what an IF statement is.
The reason I agree that python will dominate programming for decades to come is the batteries included and pythonic approach that enables people to do cool things with just a few lines of code. As a result of the above, the ecosystem has reached critical mass. For most tasks there’s a library that does that, and it’s good, and it’s easy to use, and the developer of the library usually doesn’t expect you to understand their opinionated philosophy to use it.
I love the python convention of putting a minimal example on the homepage of a library.
You’re not going to get your average developer to appreciate the beauty of Lisp or the value of static typing. They want their ML to work, or their graphics to display, that’s all. Ends not means, almost entirely, for most people who aren’t full-time programmers.
Let’s not hate on a language that opens up programming to the world, unless we want to be gatekeepers. If you want to maintain an air of superiority, just learn Lisp or Haskell or C++ and write code that’s “deeper” into the tech labyrinth. Programming will probably specialise into “end user programming” and “Service and system programmers”. Embrace the democratisation of coding.
[+] [-] xxxpupugo|6 years ago|reply
SLOW. The sin of all. I don't want to make other arguments with people who just come to repeat 'Oh you can make it fast, you are doing it the wrong way'. Sorry, I have heard that 100 times, now is sounds like bug-as-feature excuse to me.
Sorry, but Python is just slow. All the stuff people might bring up is just trying everything to bypass Python itself. Multiprocessing is hell to work with, buggy and unpredictable. Cython is OK but it is not Python.
Python's slowness is like cancer, and terminally so. Down deep, it is because its overtly flexible/loose type system, the never-going-away GIL, and prematurely exposing of C-API makes it almost impossible to optimize without breaking the existing compatibility.
And most importantly, I don't think it is solvable, truth is the patches are so integrated, people already forget what problem they tried to fix in the first place and just live with it.
But it will haunt Python in long term though, people will be struggling with Python in performant production until they start reimagining a world that without Python. Maybe a better Python in that sense.
[+] [-] ssivark|6 years ago|reply
Since this forum is likely to have some folks looking towards the future, I found interesting a couple of talks by Python veteran Armin Ronacher [1, 2]. Watching that presentation makes me wonder whether I should think of this in the context of "Worse is better". That said, Python's runtime introspection is such a killer feature that it's difficult to explain how empowering it feels for someone who is relatively new to programming.
[1]: How Python was Shaped by leaky Internals -- https://www.youtube.com/watch?v=qCGofLIzX6g
[2]: A Python for Future Generations -- https://www.youtube.com/watch?v=IeSu_odkI5I
[+] [-] DonHopkins|6 years ago|reply
The same kind of people criticize Lisp for having too many parenthesis, then go on to write unintelligible shell scripts, Perl and C++ code chock full of skewbald menageries of sigils and punctuation bound together with a towering inferno of precedence rules, terribly worse than Lisp's "too many parenthesis".
[+] [-] mantap|6 years ago|reply
Python still dominates in numerical computing and JavaScript hasn't been able to make a single dent. Because nobody wants to write
rather than or rather than JavaScript's lack of operator overloading is keeping Python alive.Python also has integers that feel part of the language, rather than being segregated from normal numbers in case anybody uses integers by accident.
[+] [-] Agentlien|6 years ago|reply
Personally, I'm primarily a C++ programmer with about a decade of professional experience in C++. I also used to do daily work in C# for a few years. For me, python is a language which I use for making simple command line tools, for processing input and clobbering together different tools. I use it to build interfaces which streamline certain workflows. Essentially, I use it as a more powerful replacement for bash or batch. For that purpose, I find that the language works wonders and is quick and easy to work with.
[+] [-] RcouF1uZ4gsC|6 years ago|reply
However, like with Excel, there are serious issues regarding reproducibility, performance, and long term maintenance.
[+] [-] lucb1e|6 years ago|reply
There is a reason Python is one of the most popular languages. PHP was popular because it's quick and dirty, but Python is popular because people love working with it. The arguments in this thread are beyond me. (They're also unsubstantiated, but if I ask for substantiation I'm sure someone can rationalize some reasons to dislike any language, so that's pointless.)
[+] [-] mixmastamyk|6 years ago|reply
[+] [-] sunaurus|6 years ago|reply
I feel like the dev community figured this out ages ago: Statically typed languages are easier to read, harder to write, dynamically typed languages are easier to write, harder to read (and also harder to refactor).
For small projects (scripts, prototypes, etc), you don't care about readability, you just want it to be as easy to write as possible. Python really shines here.
For bigger projects, using Python is painful, but that's also the case with pretty much any other dynamic language..
[+] [-] pbreit|6 years ago|reply
Note: I am an amateur which is likely the reason for my ignorance.
[+] [-] emersonrsantos|6 years ago|reply
[+] [-] dehrmann|6 years ago|reply
[+] [-] blumomo|6 years ago|reply
There's one group that uses Python regularly and which is getting their stuff done right now.
And there is the other group which has time to complain about Python.
[+] [-] simula67|6 years ago|reply