Like BASIC back in the day it's a language that allows newcomers to do things long before they are comfortable with the added syntax requirements of C based languages
Despite that the sky is the limit, almost all problems a developer will encounter can be tackled with python. Yes for many problems there are languages that are better suited for the task, but in most cases a project does never even reach a state where that will matter.
And it's installed by default in many Linux distributions.
This is especially true if they've already tried setting things up, and have made a mess of it. Because WinPython is self contained, it can work on a computer that already has a working or non-working Python installation.
A big pain point still remains when it comes to packaging and distribution.
It's not insurmountable, but if you're used to compiling and/or cross-compiling and shipping binaries, shipping Python apps can be headache inducing. The headaches increase when you're working with Windows or macOS, or using bleeding edge Python versions.
That said, for 99% of Python apps out there, the default tooling should be absolutely fine for packaging and distribution, as should 3rd party solutions like PyInstaller or Nuitka.
It may depend on what types of libs you're looking for, of course. It's definitely missing a lot of stuff.
Not because the Python maintainers are intentionally doing a bad job, it's just that their mission isn't to substitute for your research. To them, "Does last year's Python script still work?" is always higher priority than "What's the best way to do it today?".
And what Python's security team decide constitutes a reasonable security fix may conflict pretty badly with what you need.
I would assume the Python devs review the code for a package before including it in the standard lib, right? That seems like a pretty big deal, well beyond someone just telling you that they tried a package and it worked for them.
It doesn't make as much sense for Python's standard library where you'd need to be paying attention to goings-on in the community to know if one of the batteries that are included has been judged expired and will be removed.
Give me a batteries included standard library please - much easier to audit and track.
If only Mathematica was free, I think it would become the defacto language for scientists.
The most important feature of Mathematica is that it is functional and not object-oriented. Mathematics is functional, not object-oriented. So thinking in Mathematica is as easy as thinking in maths. Thinking in python is to force yourself to think in an unnatural way.
There is a lot to it, and in my experience it's a very long road to getting your first problem solved.
There are a lot of very cool pieces but I want it to be something I can pull off the shelf once in a while and be productive rather than something that I need to be an expert in before I can get started.
Of course. It’s one of the few languages that I think are worth it.
I’ve been waiting for Wolfram to open source it for 10 years as I can’t afford it, or really justify why my org should use it.
Wolframscript is free (not guaranteed to stay that way, as it isn't Open Source, but free for now).
It can AFAIK do pretty much all Mathematica can.
Only part missing is the Mathematica IDE/GUI/Notebook which I personally dislike profoundly anyways.
Best of all, since it's a batch tool, it can be integrated in a Makefile and/or data processing pipeline without that nasty GUI showing up at all.
Python has object-oriented features but there is nothing that requires you to use them; you certainly don't have to express every Python program in terms of classes and methods, the way you do in Java. Doing functional programming in Python is common. Is there a particular aspect of doing functional programming in Python that you find to be a roadblock?
On the other hand, all the code I wrote in Mathematica during my PhD was functional, because it is just easier to write functional in Mathematica.
I'm not sure I see why. The object orientation in libraries like numpy or scipy is to provide the user with fast implementations of the kinds of mathematical objects they will need to do computations. But unless you are defining additional such objects in your own code, there's no reason why your own code needs to be object oriented. You can just write ordinary functional programs that use the mathematical objects the library provides.
For example, say you are doing matrix computations. You are of course going to use the matrix objects provided by the library; but your own code shouldn't need to define any new matrix objects. Your own code can just be straightforward computations using the existing matrix objects in the library.
I beg to differ. If by "math" you mean arithmetic and calculus, then sure. Combinatorics, graph theory; probably most of discrete math is very much object-oriented.
In python, in popular libraries, the above will be attained by something like
G.shortest_path(a,b)
which seems to imply as per OO that graph G has a property shortest_path. In mathematics we don't think like this. Because it prevents mathematical abstraction. An abstract algorithm, like say Eigenvalues can be applied to a matrix M or to a graph G. In a functional language, the user would just do Eigenvalue(M) or Eigenvalue(G) as needed.
In python, these would be M.eigenvalues() and G.eigenvalues(), which makes them distinct.
I wish all the others did as well.
There are also functions that operate on graphs, because the alternative would be to stuff perhaps thousands of methods into the graph class -- which would be extremely annoying to maintain as well as abysmally slow.
Funcional programming is used in Coq because it captures logical chains, for theorem PROOFS, but not for specific COMPUTATIONS, such as eigenvalues.
Mathematics (outside of stuff like category theory etc) is simply sets and mappings between sets. Anything more complicated is forcing the user to think in a way that mathematics does not.
Hi, mathematician here. Please read the source of SageMath: written by mathematicians, for mathematicians. Therein, you will find thousands of classes. Almost all computer algebra systems, written by mathematicians for mathematicians, have a notion of classes.
> Mathematics (outside of stuff like category theory etc) is simply sets and mappings between sets.
This is an extremely narrow-minded view of mathematics. Mathematicians thrive on abstraction, (category theory is literally mathematics; that's a very strange exception for you to carve out), and if we were to boil everything down to "simply sets and mappings between sets" then we'd be bogged down in utter tedium and nothing would ever get done. Object-oriented programming, specifically class hierarchies and inheritance, are extremely valuable for doing all sorts of math at high levels of abstraction.
Hell. If I were to be especially pedantic, I'd point out that category theory itself is "simply sets and mappings between sets" except that sets aren't quite large enough so it's actually "categories and mapping between categories".
...what?
On the other hand, the non-mathematical functionality of Python of course is much better developed!
Second, unless an organization is enlightened enough to approve a site license, specialized software tends to create a "silo" of people who can use it, and forces it to be used in a centralized fashion. With Python, I can literally install my tools on every computer that I touch -- in the office, multiple labs, at home, etc. It makes it more likely that a tool will be woven into "how I think."
I can also share things and/or encourage others to try them out with minimal friction. Almost as easy as sharing an Excel spreadsheet within an organization that has purchased a site license. Free means free site license.
The friction of approving a license also discourages people from learning a tool by just giving it a try on some trivial project, or taking it home.
Similar problem with Julia and Fortran even. They all have their niches and are great at certain problems, but Python (and C/C++) rule the overall landscape. in HEP, for example, it’s even the case that a full batteries-included C++ environment (ROOT) has slowly given way to python.
English is not really a beautiful language - it’s a wild mess of different influences, but it’s easy to get to a basic level of fluency as there are few rules (but many exceptions due to the many influences). And it’s in use by large parts of the world.
On the other hand, Latin is beautiful and pure. It has more rules, but very few exceptions. You can also see how it influenced other languages (hello Jupyter notebooks…) But it’s simply not a very practical language today, as there are few people who use it.
... That we know about. It's a dead language, so the exceptions would've been lost to time as it hasn't been spoken in ages.
Your point stands regardless, just felt like being nitpicky
Either you take the time and trouble to understand what you're actually doing or you're just a lazy wizard with some facility for incantations.
I don't think there's even a (reasonable/non-contrived) way that a package could be available to you that pip wouldn't install?
(Or do you mean that you don't remember desiring a library functionality that wasn't available in some package?)
Also there are probably tons of "packages" which were never published officially to pypi but exist on github, that people have made public but decided not to maintain.
I'm doing this from memory, it's hardly a frequent thing for me, but err something like:
pip install -e git+https://github.com/vonseel/...Both might require you to have compiler toolchains installed.
A practical example: on Windows, try 'pip install tokenizers'.
py -3 -m pip install tokenizers
...
Building wheel for tokenizers (pyproject.toml) ... done
Created wheel for tokenizers: filename=tokenizers-0.13.2-cp311-cp311-win_amd64.whl
1. docstrings
2. keyword arguments
Docstrings mean I can do REPL experiments without the additional friction of opening a browser to RTFM. Keyword arguments reduce how much I have to lookup the semantics of a function's signature.
Getting the editor to measure the cyclometric complexity of the code and then colour offending blocks?
That's too bad. I taught myself Python last year but have kept it pretty "101". That is, I write code simply. Since I am new to Python I don't know if the unreadable code you're describing is because it needs to be (perhaps I am still tooling around in the parking lot of Python) or if it is the result of programmers being too cool for school (ha ha).
Perhaps if the latter I ought to blame the language for giving programmers a basement of esoterica to plunder rather than the programmers themselves.
As obtuse as C could get with pointer arithmetic and the cryptic looking "question-mark-operator", there really wasn't much esoteric stuff in C. Contrast that to my experience with Swift where seemingly every week or so I would come across cryptic code where someone was using a capital T or some bizarre case expression I am unable to mentally parse.
> Turbo Pascal
You suddenly made me miss an ex-girlfriend. Maybe they still code in Turbo Pascal in Portlandia.
I can dream.
After that... C++ was fun initially and later felt way too featured. I don't like C++ code now (especially with heavy template use and stl and boost).
I now code in Python (because most of the things I work on are in Python) though I don't like the dynamic typing.
My potential new love is Rust but we are still working out some issues
Some of my reasons for choosing Python in the first place have been mooted. Python is free, and multi-platform, but so is everything else nowadays. I think that battle is over.
For my use, packaging has not been a big obstacle, maybe because I tend to use a relatively small handful of established packages. I don't remember needing a package that I couldn't install with pip.
Easy to learn? Yes and no. I think a beginner can ease their way into Python and get productive, if they start with basic scripting and progressively adding a few language features. On the other hand, some features are simply over the heads of beginners, making the code found in packages practically unreadable. But I've never found any language to be better in this regard.
Fast? Sure, with numpy in its domain of use. Or writing your own C libraries. However, I think a beginner using numpy will run into roadblocks that require help from an experienced programmer, who can visualize what the array operations are doing under the hood. So, writing fast code isn't easier to learn in Python than in any other language.
The editor should have a final option, that turns your code brown if it's just so bad that nobody should ever have to read it, including yourself.