Most of the points in this article fall on a continuum between irrelevant to dead wrong.
1 (versions) and 2 (installation) have to do with the ecosystem, not the language. Unsigned packages are a real problem, but hating on community-maintained software is just weird. Most software in your local Linux distro's repository is maintained by a "community" that might just be one person working in their spare time.
3 (syntax) seems to be about not supporting the author's own highly idiosyncratic habits, which include deep nesting and putting debug code in the first column (ugh). The result actually seems better for maintainability than the author's own unconstrained code would be.
4 (includes) is in the "exactly wrong" category. Includes as in C/C++ are a horrible way to handle module interfaces. Really, just about the worst option available. Modules are far better, and if the author hates the fact that importing a module might run initialization code wait until s/he finds out about constructors (including __init__ and __attribute__((constructor)) even in C).
5 (nomenclature) is also a bit insane. Lists aren't called arrays in Python because they're not arrays. Next!
6 (quirks) criticizes quote handling in Python, but mentions bash's quote handling without a word of comment about how that's even worse. Different languages have different quoting conventions. Python's might not be perfect, but many are far worse. Get over it.
7 (pass by reference) is another totally-wrong one. Passing by value is not the universal norm in other languages, and it's not even clear what it means sometimes because of deep vs. shallow copies. Passing by reference is almost certainly better for efficiency, and often for correctness as well when copies becoming inconsistent with each other is a concern. I'd rather have pass-by-reference as the default, and have to work to make copies, than the other way around.
8 (local names) barely even make sense. Shadowing names, whether of variables or of modules/libraries, is a bad idea anyway. If you want the library and the program not to have the same name, use a prefix for each role. Expecting the language to handle this for you is just asking for trouble.
> 1 (versions) and 2 (installation) have to do with the ecosystem, not the language.
This argument really summarizes a beautiful and dangerous thing we see in the tech community far too often; you have a strong technical and scientific understanding of the system, but lack product and design thinking.
You're right. Its a problem with the ecosystem, not the language. I'm still not going to use python because of the ecosystem. If the language cares about its users, it needs to care about the Product, which includes the ecosystem. Users interact with the Product, not just the Language.
That's something recent languages like Go, Typescript, Rust, and even old languages like Java, understood quite well. Its not just about the syntax and the compiler; getting users into your language means caring about the IDE, caring about the development experience, the package management, the libraries, basically everything that a developer will touch. That doesn't mean you have to touch all that stuff as the core development team, but it does mean you need a Strategy and a Message.
Note how almost all languages you take as shiny examples of virtue post-date Python: they all learnt from it so much, particularly on things like the stdlib. Python’s stdlib was the gold standard for a long, long time (the “batteries included” slogan was effective for a reason - they really were!). This was not by accident - Guido and others have always had the utmost care for good developer experience out of the box. How many languages pack an editor ready to go? Or a way to install modules with a single command? Not even Java, with all its commercial might, ever achieved that - it barely got a REPL last year, which Python has had for what, 20 years now?
What people decry about “the Python ecosystem” is simply a function of its success as a generalist computing language over 25 years. Nobody uses Typescript to build Linux distributions; nobody uses Go to build lib-gluing GUI apps; nobody uses Rust to write spreadsheet formulas. Python does all that (and more), and this of course resulted in a sprawling community, with tools pulled every other way. If any of your new shiny languages will ever achieve a similar level of popularity, you can bet their ecosystem will also become a complete mess.
> Note how almost all languages you take as shiny examples of virtue post-date Python
That's because Python is old. It's as old as Haskell. It's older than Java and JavaScript. It's older than the Borland Delphi and C++Builder IDEs. When Python was released, C++ was only 5 years old. Python is older than Linux. Rust and Go are both older than C++ was when Python was released. Hell, when Python was released, Perl was only 3 years old.
Further, Python's age doesn't mean that we can't or shouldn't criticize it. You shouldn't get a free pass on what you could do better just because you've done other things right. We should absolutely point to what doesn't work well and lobby for improvements even if they require significant overhauls. While, yes, Guido and company have worked very hard on developer experience out of the box, it would be really nice if someone would care about system administration and the long tail, too. It's great that your engineers love your tools, but someone still has to live in the homes that they build.
It's not like anybody here is shocked or confused when they hear people complain about Python versioning being a rats nest. I'd wager we've all experienced it at least once just like we used to have problems with multiple concurrent versions of the Java Runtime Environment being installed or other fun forms of dependency hell. If virtualenv or conda are such good solutions, why do so few projects seem to use them or deploy with them? If popularity or ubiquity are the measure of what's good in the ecosystem, doesn't that suggest that there's still a problem to be solved? A language should direct programmers to styles of system design that makes system management easy and clear, and Python does not do that at all. Is there a problem with complexity? Is there a problem with lack of education?
> Python's age doesn't mean that we can't or shouldn't criticize it.
I don't disagree, but for people paying attention, it's become really boring. "I've just switched from $language to Python [because work told me to], and this is what I hate" is almost a parody, at this point. It's a sign the ecosystem has reached ungodly proportions.
> If virtualenv or conda are such good solutions, why do so few projects seem to use them or deploy with them?
I don't know about conda, but venv/virtualenv was the deployment standard before Docker happened (I'd argue it still is, for people who won't/can't use containers). Personally, I still like to use venvs even in docker.
> If popularity or ubiquity are the measure
How do you measure popularity? So often the pip hate seems to come from a very loud minority. Meanwhile, the ecosystem continues to expand and people keep using pip/venv without any problem, because it works for most cases (now that wheels have fixed the "can't build on Windows" issue) and it's simple enough. Somebody upthread compares pip with Maven, and it makes me laugh: the Java ecosystem is shrinking and the Python one is exploding, and stuff like the user experience of Maven vs pip is among the reasons.
> there's still a problem to be solved
Of course there is, there is always one; I'm sure that you'll find Cargo critics too, once that community grows enough, and there are plenty of loud NPM haters. Trying to be all things to everyone takes careful reasoning and herding - because it's a political problem as well as a technical one, in a polis that keeps growing. Shouting PIP SUCKS!!111!! is only going to result in more crap like pipenv. The shortcomings of pip have well-known for a while, but the solution is not trivial, as pipenv demonstrated.
> A language should direct programmers to styles of system design that makes system management easy and clear
That's like, your opinion, man. One of the strengths of Python is that it's just as structured as you want it to be, and no more - even when that might not satisfy someone's arbitrary definition of a Platonic application.
I'm not sure where you get the idea that the Java ecosystem is shrinking when every quantifiable measure (stack overflow polls and data releases, GitHub data) point in the other direction.
Further, if you factor in the growth of languages like Kotlin and Scala the JVM is blowing Python out of the water.
> This was not by accident - Guido and others have always had the utmost care for good developer experience out of the box. How many languages pack an editor ready to go? Or a way to install modules with a single command? Not even Java, with all its commercial might, ever achieved that - it barely got a REPL last year, which Python has had for what, 20 years now?
The Java module experience is miles ahead of the Python one. There's no global module path where you can install different things on different machines, nothing that screws up if you accidentally run it as root, no stateful virtualenvs where different shell windows run the same project with different versions of python. You just list your dependencies in your POM (which, yes, is XML; it was the early 2000s, everyone was doing it, and it does make it easy for your IDE to put a nice editor interface on it) and that's it, you're done: released versions are immutable and transient dependency resolution is deterministic, so you don't have to worry about pinning/unpinning or anything like that. There's a well-known repository that all the important libraries are in; as and when you want to have a company private repository there are a couple of standard ones you can pick from and run, either just for your own artifacts or proxying third-party libraries from the central one as well. It all Just Works.
Maven came out 14 years ago and Python still doesn't have anything that works nearly as well.
You are seriously comparing Maven, a huge and over-complicated xml-based system that is not even installed by default and that people hate so much that there are umpteen alternatives (gradle etc), with `pip install -r requirements.txt` that works out of the box? I just can't even...
It's not complicated. It's verbose, that's the nature of XML, but the behaviour is very direct.
> is not even installed by default
Which is the better approach because it means it's not coupled to specific versions of the language itself. You can use a single maven install to manage multiple versions of Java (or vice versa); if you need to rely on a new maven feature in a project that's stuck on an old version of Java, it's no problem.
> people hate so much that there are umpteen alternatives (gradle etc)
There will always be refuseniks (particularly for pioneers; most of the things people hated maven for are the same things people love cargo et al for) but the Java ecosystem has done a very good job of keeping everything interoperable; it doesn't matter if one of the libraries I call builds with gradle, because there's a common packaging/dependency/repository standard, so everything will just work exactly as it should.
> with `pip install -r requirements.txt` that works out of the box?
Until you come to upgrade, or until you run it the wrong way (e.g. forgetting to start your virtualenv first) and mess up your system install.
> with `pip install -r requirements.txt` that works out of the box?
Works out of the box until you're missing a distro package that is required to build a dependency that needs to be compiled from source.
I've never used maven so I don't know if it is better or worse, but I am not a fan of languages having their own package management system that has not integration with the distro one (which probably also offers some of the same packages, and mixing them breaks things in subtle, annoying ways).
> Works out of the box until you're missing a distro package that is required to build a dependency
With decently-maintained packages on PyPI, i.e. shipping prebuilt wheels for the most common architectures, that's no longer a problem - unless you insist in using the distro package-manager, in which case you should pick it up with the distro people. If you stick to pip+venv, on most common architectures, these days chances are you only need a simple `install`.
> I am not a fan of languages having their own package management system that has not integration with the distro one
You must feel miserable then, considering it is pretty much all modern ones. Go, Rust, Node, Perl, Python, PHP, Java, even C# and friends...
There will always be tension between what developers want (the library released yesterday and can be forever tweaked) and what OS/sysadmins want (the library that has been tested for months and can be locked down). This is why platform-agnostic delivery systems for developers are so popular, and it is not going to change any time soon.
> I've never used maven so I don't know if it is better or worse, but I am not a fan of languages having their own package management system that has not integration with the distro one (which probably also offers some of the same packages, and mixing them breaks things in subtle, annoying ways).
Mixing is where Python (and Perl, even though it is integrated with the distro package management) go wrong, IME. Maven is isolated from the host package management but completely (or at least completely enough, in practice); most OSes don't bother trying to ship system-wide versions of Java libraries. The OS manages the JVM (and Maven), Maven manages whatever libraries an app wants on a per-app basis, and neither interferes with the other.
This does mean you get very little help managing dependencies of JVM libraries on native libraries; fortunately those are rare enough in the JVM ecosystem that you can handle the few that do occur by hand, IME.
> I've never used maven so I don't know if it is better or worse
It's about the same for packages with a native component. Local build tools are still needed.
Java stuff is slightly less likely to have a compiled component in the first place, in my entirely subjective impression. Maybe that's because of convention, or performance; I don't know. But when a compiled dependency does exist, and nobody included a prebuilt chunk of binary for your architecture in the jar, a build is needed in roughly an equivalent fashion to what pip (or npm, cpan(1), etc.) do.
That's because LWJGL is complicated just like DirectX is. It uses low level API that calls native C code. It aims to give you a thin Java API layer above OpenGL, Vulcan, controllers, audio, etc.
there was ant (build tool) then came maven which is much more flexible and contains dependency management capabilities (and _is loved_ by many) nothing to add that the parent did not already say. Then came gradle which has faster build speed and features like incremental builds and a Groovy based configuration.
pip did not ship with python for a long time, and has problems of its own.
> Then came gradle which has faster build speed and features like incremental builds and a Groovy based configuration
You make it sound like adding Apache Groovy for configuration to a build system is an improvement. When build systems with a declarative config language, such as make, ant, and maven, replace procedural build scripts, that's the improvement. Using a procedural language like Groovy instead is a large leap backwards because it encourages programmers to add unneeded procedural features to build scripts, creating an unmaintainable mess.
I agree, my above comment was aimed at this part of the parent comment:
> a huge and over-complicated xml-based system
It was an attempt to show that there are not 'umpteen different alternatives' and the ones that exist, do so for a reason. Though looking back, I should have worded it in a better way.
I've used Python versions before that, where you had to install pip separately, and it was not trivial (to find it / install it), although not very difficult either.
There's a lot I don't like about Maven, but its a vastly better solution than pip. Support for dev dependencies and no need to manage virtual environments more than makes up for its complexity.
> transient dependency resolution is deterministic, so you don't have to worry about pinning/unpinning or anything like that
Is that true? I see a lot of pom.xml files specifying version ranges for dependencies. If I have a project specify a dependency that has its own dependencies with version ranges specified, then there doesn't seem to be an easy way for me to pin all the subdependency versions. (Yarn and npm both generate a lock file automatically, pinning all dependency and subdependency versions, which seems great.) It seems like I could specify all of the subdependencies in my own pom.xml file too with specific versions, but maven doesn't appear to make that easy to do.
> I see a lot of pom.xml files specifying version ranges for dependencies. If I have a project specify a dependency that has its own dependencies with version ranges specified, then there doesn't seem to be an easy way for me to pin all the subdependency versions.
Version ranges are indeed nondeterministic, that's why they're discouraged by the community (and IME very rare).
Pinning specific ones is easy enough (I tend to just look at the dependency tree in eclipse and right click -> lock transitive dependency version); I can't find a way to do that for all transitive dependencies though (I've never had more than a handful of transitive dependencies that used ranges, so it's not been a problem I've had tbh).
This begs the question though why can't the python ecosystem simply evolve? Is that too much to ask? You say these languages have learned so much from Python. If there is so much to learn in terms of do's and dont's, why doesn't Python simply follow this advice?
To a significant extent, it has. The article assumes you will use distro packages for the language, and pip for installing libraries. And that used to be standard practice.
Today, if you are interested in a reproducible build environment, you will use pyenv to locally install an interpreter and stdlib, and pipenv to locally (to your project) install libraries and dependencies.
In my mind, creating a Python 4 that would be a consolidation of all of these things under one release umbrella (or at least a major release), so that things could be synchronized would be a good way to handle this. Right now, things are all over the place, and things that used to work 5 years ago still kindof work, rather than either working or failing. And it's that "partial working" that really gets developers ticked off.
Rust is doing some interesting things with Rust 2018 Edition, where there is a complete system harmonization point. If it takes off there, I'd expect other languages to pick it up.
My question though is a bit different: Can Python catch up?
I know - strange question, but momentum is like that. It's often hard to see something going faster than you until it passes you. Perl is probably the best example, where it was way out front, and the PHP, which was way behind, but going mach 10, passed it quickly in the web space. Perl never caught up, and has lost significant relevance compared to the stature it used to command.
I would argue that for most projects (for most of my projects, anyway), this is still a sensible default. Except you should probably still be using distro packages for major libraries too.
Consider; the reason for installing dependencies locally to your project is that it allows you to be precise about what library version you want. For example in Rust, we have Cargo.toml and I can have dependencies like primal = "0.2". I hate this model. It takes us right back to the old days of projects shipping whatever version of a library they want and never updating it. For small projects this is a constant source of security issues and code stagnation.
I groan internally every time I see a project I'm interested in is written in node. Not because I dislike the language, but because I know when I download and build it there are going to be a dozen outdated dependencies hardcoded in the config file, some with "severe" security warnings flagged by npm.
I advocate letting library developers and distribution maintainers do their jobs. Most of the time new versions of libraries are supposed to be backwards compatible. When they're not the distribution can ship multiple versions of a library and make sure they all have security updates backported.
There are cases where managing all your own dependencies is important (like closed source web applications), but I think those are exceptions. Dependencies were supposed to be a solved problem.
Note that that will select any version in the 0.2.x range, not exactly 0.2.0. This is the range of versions that are interface compatible. If there’s a security release for the 0.2.x line it will pick it up. (Though you have to run “cargo update” in your project, though there are also tools to tell you if and when you need to do this for security issues.)
> This begs the question though why can't the python ecosystem simply evolve? Is that too much to ask?
It evolves constantly. Python packaging then and now has massively changed (largely without breaking compatibility, mind you). It's not perfect, but it is much better than it was in 2005.
Python was my first programming language, and though I don’t personally reach for it anymore (at least very rarely), it’s package management is the one large reason I don’t want to use it. All the other complaints I see about the language I don’t give much merit to, people like to complain, every language has it’s quirks and some people just can’t look past them. But, while not a solved problem, there are tons of great package managers Python could learn from to make pip not suck. How is there not a standard way/built in lock system, or even a single standard package manifest (Gemfile, package.json, cargo.toml, mix.exs, or even composer.json) — which all (except maybe composer, it’s the one I’m least familiar with) are supported by default by the language, and have version locking.
I know pythons big thing is backwards compatibility, and breaking things is almost the biggest sin in that community (python2...), and maybe I’m ignorant, but I just don’t see how implementing a single standard package manager with a standard manifest and lockfile would break anybodies anything. All they have to do is make it so pip still works without it, and if they want to see how to do that, just look at NPM, who before this year was notorious for errant package versions due to the lack of lockfiles, but now they have it and I think pretty much everyone was happy about it. They literally could just port bundler to Python and call it a day, the code is open source, they can look at how it works, and it’s one of the most well regarded package managers out there, I’ve maybe run into 2 issues ever with it. The only other package manager I see get more praise is cargo, which they could (should) also look at for inspiration.
I know things have been improving. When I was using Python daily, the standard was still punching in some incantations to start of Virtual Env (which still confuses the hell out of me to this day) and piping the contents of a requirements.txt file into pip (with I think at least some level of version locking). But, from what I’ve gathered is there are some solutions being built to bring pip out of the early 2000s, but they’re quite fragmented efforts, and they all fall short in different places.
Python is a great language, pip and all the bullshit that comes with it is terrible.
Yeah, I’m aware you can pin versions in a requirements.txt, but does that also pin those packages dependencies? For example, if I had two pinned packages (A, B) and they both depend on package C, what happens if A updates to depend on a higher version of C that contains changes that break package B? Can you pessimistically (Gemfile ~>, or NPM ^) pin versions, or are you only limited to just equals X and the greater/less than operators?
Now that I’ve wrote that out, I’m wondering if packages can even pin their deps required versions. I’ve only published one python package years ago, and I can’t remember if that’s possible. Which I shouldn’t have to even worry about in a modern package management system.
I know the above example wouldn’t be possible in any of the systems I mentioned above, because the aside from installing packages, they ensure that the versions of every package are compatible. That’s why lockfiles are so important, assuming you’re downloading decent packages, the package manager can assure you that they’re all going to work together, also allowing you to update without having to worry about some random deeply nested dep isn’t going to break some other package when it gets updated, making updating (usually) a breeze.
In pips current state, it seems more or less like a slightly more strict NPM before yarn made them get their shit together (still vastly prefer yarn). The only difference is your packages are wherever Venv puts them instead in a “pip_modules” folder in the project, which is at least better than a global free-for-all. Though, that also might be less of a headache than dealing with Venv, I hope it’s gotten better since I’ve used it, because that was always such an annoyance.
requirements.txt is a lock file, generated by pip freeze, which defines the exact version of all packages in the current environment.
> Now that I’ve wrote that out, I’m wondering if packages can even pin their deps required versions. I’ve only published one python package years ago, and I can’t remember if that’s possible.
Ah, you see, you actually only know second-generation packaging. "pip and all the bullshit [i.e. virtual envs, setuptools]" is actually what has been developed to address issues in the older distutils (and easy_install) tooling, and are fairly recent additions to Python. Buildout comes from the same era (~2005ish and was built on very different principles; it's still used in some niches.
On that note, I wonder why no one has tried to do packaging right, like really right, and then make it avaialble as a system for multiple languages. Someone should get on that. And I don't mean yum/apt/etc I mean like a universal package format for programming language packages with all the best bells and whistles, so fledgling languages can have a mature package system at their inception by simply linking with a C API.
Conda which was built for Python (Linux, Windows, OSX, arm) handles package dependencies. Anaconda is built on it and R packages are also distributed with it. If you really want to, you can build perl packages or really any kind of package you want.
It always surprises me when new languages don't make a REPL a top priority. It's such a crucial thing for a good developer experience. Rust still doesn't have one, as far as I know, and it's a major pain point for me as a light user of the language.
Rust expressions are very contextual due to things like the borrow checker, though, and a REPL basically means that every bound top level name has an infinite lifetime. That would make some things very awkward.
I feel very strongly about never accepting the age old excuse "they were killed by their success, have pity on them." All that's really saying is that they didn't know how to manage the success, which is simply a leadership failure.
And no one could possibly argue that Python hasn't had irregularly poor leadership for a long while. I'd go so far as to say that its success is in spite of its leadership, culminating with Guido basically giving the middle finger and walking away this year. Can't say I blame him.
It is the nature of newer languages to learn from the mistakes of past ones. But the big irregularity which wasn't learned is that these languages I listed have very strong leadership. In the case of Go, I'd argue the strongest leadership of any language ever made, often to the disappointment of the community.
Your comment is a great argument for languages that make compromises to be good at some domains and not others. I’ve hated every general-purpose language I’ve ever used, and the ecosystem mess is probably why.
Oh yeah, totally. The more domain-specific you get, the more coherent (and narrowly powerful) your experience can be.
However, there are obvious costs in terms of context-switching, learning curve, career flexibility, and so on, which is why general-purpose languages are so popular.
I get your point, but do those other languages not often have differing versions available as well? Its equally possible to install many different major and minor versions of Java, for example.
And I regularly run into issues with people using non-distribution Java packages that don't really integrate as well with the OS as the packaged one would.
I feel like some of his complaints about the ecosystem there were really just complaints about his specific setup.
Yes, other languages have the ability to have multiple differing versions as well BUT the big difference is that most have a relatively easy and well-known way to install and set up the environment. In Ruby, if you wanted to run multiple versions of ruby on the same machine, you'd use RVM. Python is particularly hard to set up the environment for. I'd rather set up the environment for Ruby, PHP, Node or Perl than Python. Every other language has an easier path to get up and running. Even upgrading is usually fairly easy as well.
I don't disagree with any of what you said, but I'd say its importance is up to the developer. Characterizing the difference as a "lack" is pretty rude IMO. The language and the ecosystem should be separable to some degree. It's called modularity, and I won't say you lack familiarity or appreciation of that even though you obviously prioritize it differently. If the author hates those particular parts of the ecosystem so much, s/he is quite free not to use them, probably more so in Python than in most other languages due to the explicit "batteries included" ethos of its creators. If you want to think about the "product" and a "strategy" (all for an OSS project) then that's great. The world needs more like you. Knock yourself out. Other people quite legitimately prefer to focus their attention and energy on the core technology.
The real problem here isn't that Python was used to mean the language alone when it should have been used to mean the entire ecosystem, or vice versa. The problem is that it's ambiguous. I didn't mention that points 1 or 2 are about the ecosystem to invalidate them. There are stronger refutations available. I was just trying to identify a scope that the author had left ambiguous.
It's funny how far off the author was, because there are genuine things to complain about with python, though they may not be exclusive to python.
I regularly wish python required some sort type indication for function parameters, because dealing with libraries that take complex objects as function parameters can be an absolute nightmare.
I wish python had some equivalent to the switch statement that didn't involve workarounds with dictionaries, because sometimes you just want a clean way to deal with a value that can take 7 different forms.
I regularly find myself wanting to write something of the form
do_x() if a.y()
This is stupid, but I still kind of want it since
do_x() if a.y() else do_y()
is valid
Edit: Also fuck this whole "it's so cool to shit on Java" thing. Grow up. You aren't in college anymore. You should recognize that Java fills its niche effectively, and does a decent job of being semi-fast, portable, easy to read and maintain, and safe.
Edit: Also fuck this whole "it's so cool to shit on Java" thing. Grow up. You aren't in college anymore. You should recognize that Java fills its niche effectively, and does a decent job of being semi-fast, portable, easy to read and maintain, and safe.
The "it's so cool to shit on Java" thing served an important purpose and is probably close to being retired, but it's easy not to understand if you weren't a Java programmer some time in Java's heyday. There was a culture and a set of assumptions around Java that today you could probably only find in the most stodgy and insular corporate programming environments. I helped introduce Java into a development group and ended up hating the people and practices it infected us with. The hatred is not completely unrelated to the language (which runs on a great platform and is not a horrible language) but it would never have attached itself to the language without some of the pathological culture surrounding it.
You're right. I was quick to assume that the comment was yet another jab at java. Unfortunately I have to deal with developer who insist in that line of argument, and it gets really tiring.
For sure it may, but I wonder how many of those decisions will be regretted? Java is a fast portable language with a decent type system and a bevy of time tested libraries. It certainly isn't perfect, but modern Java is a decent development environment (and this comes from a Rubyist). I suspect only Go can match its speed, productivity, and safety.
Why choose Java when you can pick from the more modern languages that also run on the JVM: Kotlin, Scala, Clojure, etc. You get all the advantages of speed and libraries without the imo bad language design.
it's optional typing. Running it through mypy will result in an error. If you are using type annotations I don't see why you wouldn't also be using a proper IDE or testing your code.
There doesn't seem to be any interest in checking type annotations at run-time. Unfortunately, without doing so, type annotations look authoritative but are essentially just comments.
I believe Julia is an example of a dynamically-typed language which does perform such checks at run-time - including as part of its support for multiple dispatch.
I've been using enforce for this purpose (https://github.com/RussBaz/enforce). It provides decorators that enable type checking where wanted. This gives the advantage of migrating existing code to type checking at your own pace at least.
On a general note I've come across a few cases, when pushing python's type annotations to their limits, that force you to put the type names in string quotes, and that makes the whole thing feel like a hack.
It's better than nothing for my use cases, but if I remember correctly both mypy and enforce have problems in common that are probably coming from the way python itself is built, such as self reference in a class definition.
> I've come across a few cases, when pushing python's type annotations to their limits, that force you to put the type names in string quotes
With pep-0563, python3.7, and `from __future__ import annotations` this should no longer be necessary. Those are some pretty detailed caveats, but I have been using it in places where I can and it is so nice.
Python has a "we're all adults here" mindset, which means it will allow you to reach into internals of libraries, ignore type hints, etc because maybe you actually know what you're doing and know the drawbacks but just need a quick solution (lots of python code is small throwaway scripts).
For actual projects you can use a static type checker like mypy.
It's worth noting the second can't be used inline.
I don't know the history, but it seems like that might be one of the reasons `x() if y()` isn't allowed in python. [x() if y()] if it existed, might carry an explicit else None.
On the other hand [x() and y()] does something different when y() is falsey.
>I don't know the history, but it seems like that might be one of the reasons `x() if y()` isn't allowed in python.
Maybe I misunderstood your context, but if not, conditional expressions do exist in Python:
$ python
Python 2.7.12 |Anaconda 4.2.0 (32-bit)| (default, Jun 29 2016, 11:42:13) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>> 1 if 1 == 1 else 2
1
>>> 2 if 1 == 1 else 2
2
>>> ^Z
$ py -3
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 if 1 == 1 else 2
1
>>> 2 if 1 == 1 else 2
2
>>>
Using nested conditional expressions to classify characters:
Sorry, the code shown in the two Python interpreter sessions above, is not a good example. To make the concept of conditional expressions more clear, this example is better:
>>> from __future__ import print_function
>>> for i in range(3, 5):
... print(i, "is", "odd" if i % 2 == 1 else "even")
...
3 is odd
4 is even
which can be shortened to this:
>>> for i in range(3, 5):
... print(i, "is", "odd" if i % 2 else "even")
...
3 is odd
4 is even
Now print() is printing 3 values: i, "is", and either "odd" or "even" based on the boolean condition.
I know, but tragically, because I am not forced to, I never do. I do appreciate that feature though. Maybe this will be the impetus I need to start taking advantage of it.
I started doing this about a year ago and it has made me a better Python developer. Getting into the habit of always writing a type annotation was hard at first, but you quickly get used to it. It helps if you configure mypy to complain at you if the annotations are missing.
You'll have a much better experience in an ecosystem where typing is the widespread expectation, IME.
Try an ML-family language if you haven't already - I find they combine the best parts of something like Python and something like Java. There was a post pushing F# earlier today.
I think it makes more sense in a language where you have to write callbacks all the time. I consider it a feature in Python, because by using `def` you're forced to imbue the function with meaning by providing it a name. Otherwise, it's just reading through a potentially complicated function without any context of what it's supposed to be doing.
All languages, including python, where you do a lot of asynchronous io require callbacks all the time. It's only recently python got await-support to deal with this. Single line lambdas is a real PITA when your not using asyncio and python maintainers have said they don't plan to change it :(
Though it doesn't take that much of an effort to just name your callback function and pass it as an argument. Python functions are first-class "objects" that can be passed around, use them!
I've always found Python lambdas to be uncanny, weird and error prone. It's kinda syntactic sugar for expression-only defs with counterintuitive scope rules. I would recommend just not using them and fall back to named functions. It's just one extra line and that way you get to name it, which is always a nice thing.
This is extremely heavyweight syntax for something I like to use as a lightweight construct. If I wanted a function, I would make something a function.
IMO lambdas are useful because they reduce mental overhead by allowing the developer not to give names to trivial functions [1].
Compare these two equivalent pieces of code:
Guido Van Rossum and the development team didn't want the language to be functional. There is very little functional support in Python in general, besides not supporting first class functions over multiple lines.
> There is very little functional support in Python in general, besides not supporting first class functions over multiple lines.
You are confusing “first-class functions” and “anonymous functions”, which are completely different things. Python functions are first-class, independent of length.
Some definitions of "first-class function" require that it have the same value semantics as any other first-class type, which would include a literal syntax/anonymous functions.
> I regularly find myself wanting to write something of the form do_x() if a.y() This is stupid, but I still kind of want it since do_x() if a.y() else do_y() is valid
Yes, I was thinking that too. Hell, you can write:
do_x if a.y?
Unfortunately (or fortunately, depending on perspectiven- great power and all that), Ruby allows things that Python doesn't and it's not hard to find yourself in a write-once mud bath.
I do like Python's modules over how Ruby handles them too. Ruby's import (require) is akin to C/C++, with modules as a separate idea. I prefer the style of importing exactly what you need.
Or Perl 5. `do_stuff() if $a->y();` is a common idiom.
Or Perl 6. `do-stuff() if $a.y;` is the Perl6 version. You can even declare your variables to be sigil-less so you end up with `do-stuff() if a.y;` if you want. See my Perl6 Advent Calendar article for a quick tour of the language, available docs, with practical examples focusing on using Perl6's novel features to write a self documenting command line script.
I've written code in everything from assembly to ML, Java, and Prolog. Perl6 is the only language I've used that I would "mind-expanding". The more I use it, the I realize how radical its design is.
Agreed. After indentation-as-syntax -- which I've always hated, and I've been using Python since version 1.5 -- lack of switch statement is my #1 problem with Python.
Literally anything that allowed easier linting, less "wait am I doing it right" regarding multi-line statements, etc.
If that is a keyword, or brackets, or whatever, I would prefer that. You can't minify or easily lint python. And you can't easily tell if there are mixed indent methods (tabs/spaces) and IDEs struggle with it vs. a simple bracket structure.
C-style syntax. I'm not a fan of using something that is inherently invisible to scope my code, and be yelled at if it's not quite right (I'm writing this in Python because I want it to be done quickly; just leave my code style alone and I'll fix it later!)
> fuck this whole "it's so cool to shit on Java" thing. Grow up.
Hey! Let people not like things, guy!
I put my pants on, go to work, pick up my heavy JVM, and crack away in the Java mines for 8 hours.
When I finally get home, tired, broken, achy fingered, and filled with disappointment for only making it to the AbstractAbstractFactory, rather than the AbstractFactoryFactory, I think I've earned a few "Yeah, with other type systems you'd be able to..." style complaints.
> I wish python had some equivalent to the switch statement that didn't involve workarounds with dictionaries, because sometimes you just want a clean way to deal with a value that can take 7 different forms.
I am with you there. I have often wished for a C-like switch(). That said, I think the best Python leans towards the functional, so instead of a switch(), it probably would be better to come up with some kind of multi-arm match more in line with modern functional language semantics. That could also be more flexible with respect to the type of the tested expression. Maybe something akin to the Rust match syntax.
> I regularly wish python required some sort type indication for function parameters, because dealing with libraries that take complex objects as function parameters can be an absolute nightmare.
Well, of course Python has type annotations. TBH, I don't use them. I tend to be rather pedantic about Sphinx doc for functions, most especially __init__() constructors. Kind of old-school and manual, but it works -- make doc and read it in your browser. The other thing I do in constructors is 1) make them very tolerant of what gets passed as a parameter, and 2) be very pedantic about raising ValueError in the right place, at the right time, with a clear message.
I have a good friend that I argue with regularly -- now this guy is a compiler front-end guru -- ex-Sun senior staff level C/C++ compiler tech lead, very smart -- but we argue regularly about Python idiom. He litters his Python with extremely un-idiomatic assert(isinstance()) to check incoming parameters. I think C poisoned this man's brain with respect to type checking.
There are two things wrong with his code: 1) It raises the wrong exception, the correct exception is TypeError, not AssertError. 2) It totally breaks __int__, __float__, etc, so I can't implement those on custom classes.
In my constructors, to the extent possible, I do "type checking by re-construction" -- parameters i and p gets run through something like:
self.i = int(i)
self.p = PClass(p)
So if you send me a string for i or something weird that implements __int__(), everything is cool. And PClass.__init__(self, x) is responsible for turning p into an instance of PClass, leaving it alone if it already is a PClass, or raises ValueError. This idiom makes type checking as tight as you want it to be, but doesn't break Python Zen.
The pythonic way is to do duck typing, meaning don't check the params types at all. Assertions are ok to check things that should never happen. But if you're gonna put them everywhere then better use type hints. I'd use TypeError on public APIs, for private APIs is as bad/good as assert.
What I describe is duck typing, with eager authentication of duck specie. Exceptions raised at point where the greatest clarity of error message is possible.
I regularly wish python required some sort type indication for function parameters
As others pointed out, Python has optional type annotations and has had them since 3.0. They're static-only (you don't get runtime type checking from them), though, and getting what you want out of them will effectively require every single function, method and variable in not just your codebase but in every third-party dependency and all of their dependencies to be annotated.
Also, annotating "complex objects" tends to be an unreadable mess. If you have lots of functions which take complex objects as arguments, rather than a more clear list of parameters, that's probably not going to be solved by type annotations; it will be solved by rewriting the functions. In other words, you probably will not be helped by:
> I regularly wish python required some sort type indication for function parameters, because dealing with libraries that take complex objects as function parameters can be an absolute nightmare.
Meh, never encountered this in 20 years. Typing is helpful in large projects however, and not just with complex objects.
The article read more like a rant of "I PERSONALLY HATE THIS" than a well-reasoned argument of why the language might actually suck. Here's an example :
> PyPy, PyPi, NumPy, SciPy, SymPy, PyGtk, Pyglet, PyGame... (Yes, those first two are pronounced the same way, but they do very different things.) I understand that the 'py' is for Python. But couldn't they be consistent about whether it comes first or second?
First, stupid examples. PyPy and PyPi (actually PyPI, with the uppercase) are not pronounced the same, its "pie-pie" and pie-P-I.
Second, on the package names, they're third-party. They could be named pretty much anything. Why does their naming matter in any way? I haven't seen much consistency in any language I've encountered anyway. I'd even say most of the examples he gave are at least pretty self-descriptive, compared to a lot of libs in multiple languages...
> The article read more like a rant of "I PERSONALLY HATE THIS"
Given the entire premise of the post is that he's written a list of things he hates about Python as an answer to his friend's question as to why he hates Python, I'm not sure why you think there's some ambiguity here.
I think the issue is that the article is called "Reasons Python Sucks" rather than "Things I Hate About Python". It comes off as the author saying that these things are objectively bad about python even though many of them are clearly subjective.
Which makes it perplexing that it's on the HN front page. A list of very personal and petty gripes aren't all that informative. Especially when half of them seem to show a profound lack of familiarity with Python.
Perhaps it was upvoted because there is a prevailing sense that something in Python isn't right, and even though most people seems to disagree about what exactly isn't "right".
I "hate" python for my own (much more petty) reasons, although the horrible naming conventions struck a cord with me, so I upvoted this article, with the hope that I'd be able to learn something from the discourse it creates.
> 1 (versions) and 2 (installation) have to do with the ecosystem, not the language. Unsigned packages are a real problem, but hating on community-maintained software is just weird. Most software in your local Linux distro's repository is maintained by a "community" that might just be one person working in their spare time.
Regarding 1: I'm sick of people saying that the ecosystem != the language. No one is going to be able to prop up an alternative ecosystem and get more traction than the language's own ecosystem, so you are basically always stuck with whatever crazy ecosystem comes with the language. Most of what people care about is the ecosystem and the syntactic sugar relationship the ecosystem has with the language, so it is a very real criticism imo if a major programming language has a bad ecosystem.
You are stuck with the ecosystem you ship with the language, so get it right the first time.
There actually are separate Python ecosystems (applications embedding Python or relatively detached distributions like Anaconda). Similarly you don't really care about e.g. the larger Lua ecosystem when you are targeting a specific application using Lua. It has its own ecosystem.
That's my point though. Unless the primary language developers themselves say "Hey, this ecosystem is broken" and then make an alternate one, we are generally stuck with the old broken one being the de facto standard. And even in that scenario you have to make the choice between breaking compatibility with everything that relies on the old ecosystem, or supporting both new and old at the same time. The lesson to be learned here is you only really get one shot at doing the ecosystem the right way, so do it right the first time. Hence Crystal/Go/Rust/Nim/etc
I think the frustration with that argument is, who is it directed at? How would you fix it?
venv has been included with Python since 3.3 (2012) and was a separate package before that. If you're having troubles with the ecosystem playing well with Python 2.6 (2008) what do you expect anyone to do? I really think OS package managers have been really negligent about multiple versions and project-level dependencies--maybe it's outside of their scope (that also wouldn't help you on Windows)? People have been griping about software specific package managers for over a decade and OS package managers have only added the most minimal support, but never addressed the reason for them.
I've argued for years, if something is critical to your business then decouple it from the OS. Of course a new version might screw up your OS and you may need it to address a specific business concern...that's just one of the problems of any interpreted language. I wish things were better out of the box, but it's not unreasonable to address yourself.
Even languages that are pure "pass by value" cheat pass the value of a reference for objects.
Very few languages support doing a deep copy when passing an object. I'm trying to think of a single one, and I know that none of the major ones do. C will pass an entire struct, and so long as the struct doesn't have any pointers, sure...
But even in C passing a struct by value is highly discouraged, since it can spew all over registers and the stack! I've worked with coding conventions where pointers to structs are passed, and then the called function memcpy's the struct if it needs to hang on to it, or just leaves well enough alone if it only needs to pull values.
Has the author never given a pointer as an argument to a function before? Do they make copies of their strings and structs every time they want to pass it around? I just... I just don't understand how they could think that.
I think I can answer this one because it is one of my gripes of Python. The problem isn't that it doesn't copy, rather it is that the = assignment operator specifically doesn't copy.
If you create a list "list1", set "list2 = list1", and change list1, both of the lists change. When I learned Python, this was a major source of confusion for me. Eventually I learned that in Python, instead of nothing being a pointer as it first appears, it is actually that everything is a pointer. On the other hand, while the same things occur in C++, the assignment operator does a shallow copy and anytime you are doing a pointer copy it is explicit.
I don't remember when in my Python career I learned about names vs. values, but it finally clicked for me that I'm predominately just binding a value to a name with the = assignment. Now everything I read has become very easy to reason about and understand.
Ned Batchelder is a good resource for learning many things about python, and this talk he gave at Pycon some years ago is no exception:
Wow, there's a name I haven't thought about in a long time. I met him several times in the context of Lotus/Iris. Super nice and obviously wicked smart guy. Always approachable and eager to help, too. I'm not surprised at his current vocation.
I suspect the issue is precisely that he's coming from C. In C, pass by value vs pass by reference is extremely explicit. In python, it's "magical", because it depends entirely on the type of the variable that is passed in, which is itself hidden from view of the code due to the dynamically typed nature of the language.
This has been one of my own annoyances with Python as well.
It doesn't depend on the type at all. Objects are never copied when passed (or assigned to names). The only thing that might give you the opposite impression is that some objects are immutable, so you wouldn't be able to notice if a copy were made (without calling `id`).
7 Isn't Python actually pass-by-value / pass-pointer-to-object-by-value like Java is? Many confuse pass-pointer-to-object-by-value with pass-by-reference, but they are different things. Pass-by-reference allows to write a procedure that swaps two external values.
You're right that you can't perform swaps with a Python function, but it's never pass-by-value like Java primitive types. It feels like pass-by-value because int, long, float, complex, and string are basically immutable.
Java primitives (short, float, double, etc...) are copied to the calling function, but arrays and objects are passed by reference. This is easier to explain in a language like C++, which can do either:
// Java always does these:
void f(Object& o) { ... } // passes objects by reference
void g(double x) { ... } // primitives are copied
// Java can not do these:
void p(Object o) { ... } // copy of the object
void q(double& x) { ... } // reference to primitive
CPython always passes by reference (pointer), and a C extension can break the rules and modify the otherwise immutable types (int, float, complex, string, etc...).
You can squint and say everything is pass-by-value because you can always pass pointers, but then we're really losing any meaningful definitions for what semantics we're describing. I mean, it's all pass-be-electron if you dive deeply enough.
> Java primitives (short, float, double, etc...) are copied to the calling function, but arrays and objects are passed by reference.
Not really. "Pass by reference" is a specific term for a much different technique which is very rarely encountered these days. It means that if you pass a variable "foo" to a function, that function can assign "foo" to some other value and the value of "foo" will also be changed outside of that function.
The confusion, I think, is that true pass by reference is almost never encountered in modern programming languages and courses, and some people mistakenly use the term "pass by reference" when explaining the difference between e.g. primitive types and objects in Java.
Java passes everything by value. The value of a variable assigned to an object is indeed a "reference" to that object in memory, but that's a coincidental use of the term "reference."
> "Pass by reference" is a specific term for a much different technique which is very rarely encountered these days.
C++ isn't all that rare.
I suspect we'll have to agree to disagree whether your definition of pass by reference is universal. Given your definition, can you name any language with calling semantics which are not pass-by-value? I mean, you're always passing the value of something (be it the actual value, the address of the memory where the data is stored, or the pointer to the string containing the name of the data in an associative array).
Popular as it is, C++ is still a pretty special case. Not many languages have references like it. (I personally don’t use any.)
int a = 5;
int& b = a;
b = 6;
// a is now 6
Allowing an lvalue argument to be changed by a function call is something more languages support, though, like C# and VB.NET. That’s what it means to “pass by reference”. Passing a reference/pointer is an accurate description of how most languages work, which might sound similar, but is really different enough to warrant not being called that. Especially because the behaviour has nothing to do with passing: variables just work that way in general in Python, Java, JavaScript, Ruby, C#, VB.NET, Lua, ….
Anyway, back to:
> I may be missing something, but I can't find any example in my mind which indicates difference between passing in Java and Python.
You’re right that C extensions can break the rules, but in the real world they don’t (because that breaks everything); immutable int objects are effectively primitives. (Modern JavaScript – in strict mode – is an example of a language that hides the implementation details of primitives better than Java.)
I don’t know any C++, so forgive me. I can’t name any language that doesn’t use pass by value. Okay, I’ve heard that FORTRAN does, but I’m not sure. But that’s the point. The distinction was made when both techniques were popular, since it was obviously an important distinction to understand.
Early FORTRAN programs could break if you passed a constant into a function and reassigned the value within that function, because the constant would change.
My C++ is a bit rusty, but AFAIR `void f(Object& o) { ... }` would allow you to replace the whole object in passed variable (`o = o2`). You can't do this in Java, you can only modify its fields.
You're right, it is more like a pointer. In C++, that would call the assignment operator which can do anything it wants, but the address of the Object would not be replaced. Java would change the value of the pointer in the callee.
These cross-language comparisons have too many nuances for me to try and make simple examples. Really, my original point is that CPython does not have "primitive types" as in Java. Everything is passed by pointer to the PyObject.
With regard to "pass by reference", it's not even clear to me that that's a correct way to describe how Python passes variables to functions. Python variables aren't names for storage locations to begin with; they're namespace bindings. Passing a variable to a function means passing a particular namespace binding from the caller's namespace to the function's local namespace. I don't think the author of this article understands any of that.
> Passing a variable to a function means passing a particular namespace binding from the caller's namespace to the function's local namespace.
I don't think that's true, as the function will never be able to change the binding, and only gets a reference to the value of the binding. If the function was passed a particular namespace binding, it would be able to change this binding's value, and that's not possible.
I agree that "pass by reference" is a misleading way to describe Python functions.
> the function will never be able to change the binding, and only gets a reference to the value of the binding
More precisely, the function's arguments when it is called are a set of values for variables taken from the caller's namespace, which then get bound to the corresponding names in the local namespace. You're right that "passing the binding" doesn't really describe that process very well.
> the function's arguments when it is called are a set of values for variables taken from the caller's namespace
Again, this is very obviously false, since a call need not involve any variables at all:
foo(1, 2, "three")
The function's arguments when it is called are a set of values taken from the caller, yes. And those values are obtained from evaluating expressions that may involve variables. But they might not. Saying that the values are "a set of values for variables taken from the caller's namespace" is wrong.
You are mistaken, and your talk of namespace bindings is just obfuscation. Python arguments are passed by pointer. Python namespaces bind names to pointers. There is no "binding" object passed in a function call.
> this is very obviously false, since a call need not involve any variables at all
True, in which case the values would just be constants. But they will still get bound to names in the function's local namespace.
> You are mistaken
No, I left out a case which, it seemed to me, did not affect the main point I was making. If you want to make clear that that's a possible case, fine, you've done so. But you haven't refuted (or even engaged with) my main point at all.
> your talk of namespace bindings is just obfuscation
No, it's a very important difference between what Python variables mean and what variables in language like C mean. You might think the difference is unimportant, but not everyone agrees with you.
> Python arguments are passed by pointer. Python namespaces bind names to pointers.
At the C level inside the interpreter, yes, this is true: every "object", such as the 1, 2, and "three" in your example, is a pointer to a C struct containing the object's data (sometimes including further pointers). Again, that doesn't affect my main point at all.
> There is no "binding" object passed in a function call.
I already agreed to this in my response to pstch upthread (the post of mine you originally replied to). Once more, it doesn't affect my main point at all.
> But you haven't refuted (or even engaged with) my main point at all.
OK. Your main point (now that you have shifted the goalposts) seems to be that argument passing induces a binding of the parameter name to the argument value, yes?
In the abstract, this point is meaningless since it applies equally to every other programming language. In this C function:
void foo(int x, float y, char *z) { ... }
the C compiler also has to manage bindings from variable names to the locations where their values are stored. It needs that information to find the correct values in registers or (just like in Python) on the stack.
In the concrete, the point is also meaningless since those bindings do not involve dictionaries as you seem to think. For positional functional arguments, loooong before the call takes place, the bytecode compiler resolves names to stack indices, and the variables are accessed through those. Just like C can access arguments passed on the stack using constant offsets from the stack pointer.
f = _PyFrame_New_NoTrack(tstate, co, globals, NULL);
if (f == NULL) {
return NULL;
}
fastlocals = f->f_localsplus;
for (i = 0; i < nargs; i++) {
Py_INCREF(*args);
fastlocals[i] = *args++;
}
result = PyEval_EvalFrameEx(f,0);
This sets up a stack frame for the callee (on the heap, yes), then copies the arguments (which are pointers to PyObject) into slots in that stack frame numbered consecutively from 0.
Nowhere are name-value bindings allocated dynamically in this normal case. Python does perform dictionary manipulation for keyword args, but not for positional ones. For normal positional arguments, the mechanism is exactly equivalent to a C (or whatever) compiler pushing arguments onto the stack. Local variables are exactly what you claimed that they were not, namely names for storage locations (stack slots).
> Your main point (now that you have shifted the goalposts) seems to be that argument passing induces a binding of the parameter name to the argument value, yes?
It's that there is an extra step involved that does not occur in languages like C.
> those bindings do not involve dictionaries as you seem to think
For positional arguments, you are correct. But, as you note, there is still an extra memory allocation on the heap, because the stack at the Python level uses heap memory, not stack memory, at the C level.
For keyword arguments, as you agree, there is a dictionary entry created.
> Local variables are exactly what you claimed they were not
More precisely, local variables inside a function that correspond to positional arguments are, for performance reasons, stored in an array of function local pointers at the C level, instead of being stored as dictionary entries (namespace bindings).
But the fact that this is a particular exception to Python's normal treatment of variables simply highlights the point I was making.
> Python variables aren't names for storage locations to begin with; they're namespace bindings.
Can you explain the difference? What is a "namespace binding"? When accessing a variable's value, the interpreter's code sure looks like it treats the variable name as the name of a storage location.
> Passing a variable to a function means passing a particular namespace binding
"Passing a variable to a function" is not a thing. Passing a value to a function means passing a pointer to that value. This is the same for "foo(some_var)" and "foo(1)". Since "1" is presumably not a "namespace binding", you seem to suggest that there are different parameter passing mechanisms for these cases. There aren't.
Every value in Python is a reference to an object. All function parameters are such values that are passed as they are. You get the same references to objects that the caller passed.
We could call this "passing references to objects by value."
That's a long form of what I most often hear: "pass by value of reference"
But in any case, that's the point that made me go wtf while reading through as well. Whatever you want to call it, it's the same as what C (when not passing pointers), Java, PHP, Javascript, and many many other languages use.
Which is why it's so frustrating we don't have a good, easily-understood/well-known name for it.
In other words, the latter means "set aside one pointer's worth of storage and fill it with the bit pattern for the pointer pointing to the value 17 (which you may have to create first)". Variables have values. In C those values may be ints, floats, pointers, whatnot. In Python (at the implementation level) those values are pointers to objects.
> In other words, the latter means "set aside one pointer's worth of storage
Set aside one pointer's worth of storage on the heap, yes; not on the stack or in the program's data segment, which is what the C statement I gave does.
> and fill it with the bit pattern for the pointer pointing to the value 17 (which you may have to create first)"
Which has no analogue whatever in the C version.
Also, you completely left out the part about creating an entry in the namespace dictionary, which also has no analogue whatever in the C version, and which involves additional memory allocations.
Except for locals. (Well, OK, the Python stack is reified in the heap, but local variables are translated into small integer indices into the stack frame.)
> an entry in the namespace dictionary
Except for locals, which do not involve memory allocations or dictionary lookups.
Anyway, we're getting farther and farther away from the topic, which was that Python argument passing is no different from any other language in which everything is an object.
I meant the C stack, not the Python stack. At the C level all Python objects are allocated on the heap (except for some of the singletons like None which are statically allocated by the interpreter). (The fact that I used the term "heap" indicates that I was talking about the C level, since there is no "heap" at the Python level.)
> Python argument passing is no different from any other language in which everything is an object.
I disagree, since again you have left out the namespace binding step completely.
That's a nice explanation for BASIC programmers, but for anyone who has ever programmed in some other programming language than BASIC, it should not come as a surprise that named boxes can store pointer values. As they do in Python. They literally store C pointers of type (PyObject *).
> Most software in your local Linux distro's repository is maintained by a "community" that might just be one person working in their spare time.
There is one big difference between Pypi and a distribution repository:
With Pypi, every contributors are truly individuals, they upload their packages alone, they maintain them alone, they basically do whatever they want. The maintainer here can likely be a single point of failure.
With distribution even if most packages are maintained by a single person, the repository content is the responsibility of the distribution as a whole. These distributions have formalized their processes and policies a long time ago. For example, if a critical security issue is found, unless something goes wrong, the package will not be left unpatched, even if the package maintainer is not reacting.
Also, Distributions put huge efforts into providing stable versions, if you are using packages from a distribution, you have some guaranties about stable APIs, and that these packages with stable APIs will actually be maintained for a few years. Even if it's not always perfect, with non-critical bugs not always fixed, it's a far cry from Pypi where the only true possibility is to hard pin every single version of your dependency tree inside requirements.txt.
> And I pity anyone who miscounts spaces and accidentally puts in three spaces instead of four somewhere -- this can take hours to debug and track down.
this is so hilariously wrong that it is clear that the author has never actually tried any of the things he complains about.
Python 3.7.1 (default, Oct 22 2018, 10:41:28)
[GCC 8.2.1 20180831] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> if True:
... if True:
... pass
... pass
File "<stdin>", line 4
pass
^
IndentationError: unindent does not match any outer indentation level
same error in Python 2.7.15. the caret is at the wrong place, but the error message is perfectly fine on its own.
edit: I checked the CPython source, and this message actually dates back to 2000. so unless the author was using python 1.x back in the 90s, or is dumb enough to use single spaces for indentation, the story is a complete fabrication.
I think the problem he is describing--somewhat poorly--is when the "third space" just happens to match some other scope above, and therefore is syntactically valid, but not nested the way one initially thought.
Those kinds of problems can be hard to track down.
Never searched for 'hours' but it's been a annoyance before, usually related to copy/pasting. I certainly have run into the indent issue where my editor doesn't know what block it should be in but that's more emacs fault.
That said, I sure with python offered a totally optional end block thing. In many situations it would make things far more clear.
Exactly this. I've spent many hours on multiple hard-to-replicate bugs that turned out to be from a couple of lines at the end of a loop body that were indented to the wrong level after a refactor.
A third space can never align with another line since it will be an odd number of characters while indents are always even (or vice versa). If you are two chars off, well at some point you need to be responsible for your broken blocks.
I agree with the other person that says this doesn't really happen in the real world with a baseline developer and editor.
We now have three real-world counter examples just in this thread. And the hacker news crowd is relatively sophisticated technically--even for programmers in general.
"It isn't a problem for me, therefore it isn't a problem for anyone." just isn't a good way to reason about problems like this.
Sure, I'd never say a solution to a non-trivial issue was flawless. However, "a problem" is not very granular. I'd rather count this one in terms of centiproblems or milliproblems.
I don't see how. An editor can help you get indentations that are syntactically valid, but can't possibly know if the programmer intends the program below to print plain "foo" or both "foo" and "bar".
print("foo")
# x is false for the problem
if x:
do_something()
print("bar")
And to the parent who has written a lot of code but never had this problem, well, some people do.
Neophytes also have a lot of problems with matching braces, neither is a panacea to those folks. But one is easier to read and type for everyone else, for years to come.
It's a two space error in a trivial example that no editor can help with.
If the function is longer or their are a couple of additional levels of indentation, and it isn't a print statement, but some additional logic, it is a hard problem to spot.
Not true, look up indentation guides and whitespace visibility. Even my barebones editor has them and squashes ambiguity.
Still at some point one needs to be responsible for the code they write, braces or not. Braces are not a guaranteed solution either, if the author gives up complete responsibility.
Basically, this is a theoretical non-problem. The lack of braces pays back in readability every single day. Like +100 + -2, then complaining about the -2.
To back this up, I was at a place where vim on my Mac and the Windows editor on the machine of one of the people consuming my code would somehow munge the spacing (tabs-to-spaces, or summat).
Point is, I'd see this problem constantly until I figured it out. And not once did it take more than a few minutes to fix it because, as you point out, it shows you where the problem is. And if you use PyCharm, or VS Code with Python extension, or a raft of any other editors, it'll bark at you long before you try and run the code, with circles and arrows, and a paragraph on the back of each one explaining the problem.
So, yeah, the author is making shit up. And needs to learn about what the Tab key does.
Doesn't even need to be a big heavy editor. I use the lightweight Geany and even it has indentation guides and whitespace visibility. Even so, I could probably fix such a problem without it.
Do you mean using spaces or using the space bar? 4 spaces is standard but the editor should take care of that with tab that results in 4 spaces. An actual tab is just plain wrong. It is allowed of course, but those developers are wrong for doing so.
>3 (syntax) seems to be about not supporting the author's own highly idiosyncratic habits
Yeah, I don't get the author at all. Using indentation is so, so, so, so, much cleaner and easier to understand, even with lots of nesting than trying to figure out if you closed all the stupid curly braces, curly braces be damned.
I asked a "C all the things!" developer a while back why he hated Python's enforced indentation and in a whole lot of words he basically said that it makes it difficult to visually track scope when you have long chains of conditionals.
The standard Python developer response to that is, "Aha! You like braces because they enable your bad programming practices!"
However, I found the best way to illustrate that point is this: I asked him, "If you're never allowed to use a text editor/IDE that highlights braces or the space between them ever again would you still prefer braces to indentation?"
I had to re-explain this concept several times but eventually I think he understood my point at least a little bit...
"Aha! You're using spaces because Python lacks decent development tools! In fact, because there's no static typing you can't even make a decent IDE for Python! Spaces are a crutch!"
> * I asked him, "If you're never allowed to use a text editor/IDE that highlights braces or the space between them ever again would you still prefer braces to indentation?"*
Being visually impaired and also having coded since before syntax-highlighting editors became standard, yes. A brace character is something that's easy to visually perceive; whitespace isn't.
Literally anything other than spaces that allowed easier linting, less "wait am I doing it right" regarding multi-line statements, etc.
If that is a keyword, or brackets, or whatever, I would prefer that. You can't minify or easily lint python. And you can't easily tell if there are mixed indent methods (tabs/spaces) and IDEs struggle with it vs. a simple bracket structure.
(This is a rare repost within a thread. I'm punching that card for 2018. Whitespace significance is my #1 issue with Python. I love the language, hate this feature.)
I hate meaningfull identation because the tools I end up using suck at maintaining it. I end up bugfixing on customer systems, sometimes on systems used by coworkers. There is no editor with consitent tab vs. spaces or tab width settings. I had editors clear two indents at once, fail to correctly line up new indents more often than not. I will accept whitespace as sane block scoping method the moment every text editor follows the same settings out of the box with the ability to customize the settings removed.
While I have PyCharm on my dev. system the chance that I can use it while I am debugging or extending a script on a customers system is zero, sometimes there is kwrite, sometimes it is gedit and if it is headless I may get vim. So consistency is guaranteed to be non existent.
>"If you're never allowed to use a text editor/IDE that highlights braces or the space between them ever again would you still prefer braces to indentation?"
Yes. (Though that's hardly the worst thing about Python.)
Isn't deep nesting (hence deep indentation) a sign of code smell? Yeah, you might end up shuffling the logic into a new file or a function that makes the file much longer, but I've noticed when doing that kind of refactoring it forces you to clean up the scoping quite a bit so there's less state to keep track of.
Imagine an if, inside of a foreach, inside of a function definition, inside of a class. This is not terrible code, it's perfectly reasonable.
Now you're indented four levels in. Now combine this with some rather unreasonable and outdated assumptions that PEP8 (automatically enforced in many shops and OSS projects) has, like pretending that people are still on glass terminals and that anything longer than 79 characters is a problem. It also insists on four-space tabs, so this very simple construct has eaten 20% of your line budget.
..not to mention how it makes your code harder to read. I also share the author's concern about how you're less able to separate your debug code from your actual code.
This is all subjective, so it's hard to make a water-tight argument either way (even if we were looking at a concrete code example)...that's one reason it's referred to as "smell" instead of a bad-practice. PEP-8 effectively starts with "A Foolish Consistency is the Hobgoblin of Little Minds." Every place I've worked used a modified version of PEP-8 for standards because it never worked out of the box. Like I was saying higher up, it's hard to tell who to blame. It is the reality of using that language, but the developers have made a strong effort to address it. I guess it's a lesson to future language designers or community managers?
More concretely, I often find deeply indented code more difficult to read. There are more local variables to keep track of and breaking it out into a function helps encapsulate and name what's going on. Even from your description I might look to see if I could use a generator to filter the loop instead of "for" and "if" which should be more clear, fewer indentations, and easier to optimize at runtime. I do find trying to break up long line onto multiple rather annoying because diffs are more difficult to read.
I've never really used whitespace to separate my debug and actual code...which probably speaks more to my background than anything else. I have tended to put a # at the beginning of the line when debugging and next to the comment when commenting. Linters don't seem to care for that, but the code is tidied up before it's committed.
Four-space indent is very common in other languages too. I don't see why this choice should be argued over for Python specifically. The 80 char limit is also very common.
I too used to leave debug-code purposefully unindented. There are other ways to handle that and the loss is negligible to me considering there can't be misplaced braces in Python in return.
Yes, we indent code for readability sake. If you don't, that would be incompetent. Which makes the braces redundant at best, noise at worst.
Their lack in Python bothered me too, one afternoon in the spring of 2001, then I moved on.
When I hear someone complaining about it I immediately think, this person hasn't much experience with Python, or is one of those highly inflexible pedant types.
Arguably the lisp family contains the “huggiest” use of characters, but something like Paredit turns those parentheses into something of a turbo-charged way of handling code forms.
But it leads to another problem: hatred of typing commas in non-lisps.
When I switched to Python, the one thing I predicted I'd hate is the forced indentation.
The reality is that after a week or so I forgot completely about it. There are other things for sure that became an issue (took awhile to fully grok class variables vs instance variables), but the indentation was never one of them.
It’s even false that python passes parameters by reference.
It passes the references by value, that is a completely different thing.
It’s really easy to prove it by implementing a function swap(a, b) and looking at the values of a and b after calling the swap function.
Obviously a and b are not swapped because they are not passed by reference, but instead the references are passed by value.
It’s an article written by someone that doesn’t have the slightest idea of python if even I, that I used it only a bunch of times, don’t make this beginner errors...
Btw I don’t like python, I prefer to it a lot of other programming languages.
>>3 (syntax) seems to be about not supporting the author's own highly idiosyncratic habits, which include deep nesting and putting debug code in the first column (ugh). The result actually seems better for maintainability than the author's own unconstrained code would be.
Telling users they are not good enough for your technology is not the way you go about these things.
Also if this works in other languages, people do expect it should work in Python.
Because someone claimed that they're not arrays, which they are. So the posted article is correct in that sense; and not wrong about everything, which was also claimed.
3: Yes. Mandatory indenting is a godsend to readability. Author is wrong.
4: Yes. Imports >> Includes in every conceivable way. However, what is actually available to import _is_ confusing. This is really a symptom of a different problem though...
5: Yes
6: Yes - picking on the quotes thing with Bash is just one of a million syntax "quirks" that make Bash a horrible no good language. ( as an operator is my vote for most egregiously mind-bending "feature".
7: Yes. Once you get used to it, Python usually does what you want in terms of passing parameters.
1 and 2: NO. The ecosystem and the language are the same thing. They're useless without each other. Every other point the author makes is dumb, but this one is utterly correct. Now, the version schism is unfortunate, but it's spilled milk. I agree with the author that it's obnoxious, but there's not much to do about it now. However - creating, sharing and installing packages in python is THE problem. And I'm not saying it's an unsolvable problem - that's what makes it so frustrating! You have a thriving, healthy community of package maintainers creating amazing libraries that allow regular engineers like me to get work done out of the box. And in many ways, as other posters have pointed out, python paved the way for making this experience better than the hell that is c++ package management. Sure.
But the current user experience of trying to give somebody an application that happens to be written in python? The story of how you take some python code you wrote, bottle it up, and make it work on somebody else's system? And the story for how they take that code and make it available to themselves on their own system? It. is. atrocious.
Which one of these tools, concepts, commands and filetypes do I need to care about:
package, module, egg, wheel, bdist, sdist, distutils, setuptools, easy_install, pip, pipenv, poetry, PEX, PyInstaller, py2exe, PyPI, conda, miniconda, anaconda, virtualenv, venv, requirements.txt, setup.py, pyproject.toml, pipfile, site-packages, dist-packages, $PYTHONPATH or motherfucking .pth files??!?!
And to anyone saying "Just use a virtualenv": that is so, so not an answer to this eldritch horror. Let me ask you this - when you installed chrome, did you have to create a new virtualenv? No. If you want to effectively distribute code to lots of people, you need more than a god damn virtualenv. The whole world isn't just scientists tooling around in sandboxes.
It's often tricky to specify abstract dependencies such that people can use pip to install libraries without having trouble with other packages in their environments, and also quite tricky to provide builds with native code or links to native libraries for different architectures.
On pass by reference.. I really miss Fortran's intent(in). You get a reference to the data but it is immutable... I would like if Python had something similar...
1 and 2 are big issues for portability for me. It’s easier to ask for a C++17 compiler than insist on Python 3.6 with MKL. It’s not central to the language, but how people use it affects distribution.
Thank you for going point by point. I was blown away by how little experience the author had with Python, compared to how strong his opinion is about it.
I hate hate hate language debates, but this isn't even that, it's just a misunderstanding. If this guy took a class on Python he'd figure out like 5 or 6 of these issues no problem!
True of most "X Sucks" discussions. I used to do a lot of ColdFusion. A mention of that would elicit the oh-so-clever, "I'm sorry...." A little digging found they either had never written a line of CFML in their life, or they worked on a project back in 2005 before they added numerable features, and before many of the frameworks and tooling that a typical developer would use.
same for PHP. Still not great but there is in 2018 essentially a "good parts" set of best practices, which combined w/ v7 is not a horrible language/platform. I feel you if you just don't like it, but I see so many people just quoting that old "fractal of bad design" post that's really not relevant any more.
I saw "Reasons Python Sucks" on HN and I thought I was going to finally see an updated list of well-informed and articulated concerns about Python.
Instead, this list is bizarre, misinformed, and largely incorrect. Other commenters have already pointed out several specifics. Two things I haven't seen yet that I'll add:
> And I pity anyone who miscounts spaces and accidentally puts in three spaces instead of four somewhere -- this can take hours to debug and track down.
This is just absolutely batshit ridiculous. You'll get an IndentationError pointing to the exact line in question. In all my years of working with people at all levels, I've never seen anybody spend more than a few minutes working out an IndendationError.
> <Pass by reference/object> is one of the big differences between procedural, functional, and object-oriented programming languages.
This is a non-sequitur, and it's plain to see. It's possible (in fact common) to write with all three of these orientations in python, and object transit has absolutely nothing to do with it.
Came to a similar conclusion. I use Python a lot, and it certainly has its problems. However, the article's analysis doesn't even begin to scratch the surface of this topic in an informed manner.
Instead, we're presented with paragraphs written by someone who can't read a stack trace:
In [7]: def foo():
...: print('foo')
...: print('bar')
File "<ipython-input-7-47f5b52e9e07>", line 3
print('bar')
^
IndentationError: unexpected indent
Isn't that a strawman? Wouldn't a more apt example be:
def foo():
nums = [...]
sum = 0
for x in nums:
print(x)
sum += x
I don't know python well, but it seems like there could be subtle issues with indentation that wouldn't cause a compiler error, but would cause the wrong output.
1) This is not the case that the author presented, though - it was specifically about 3 spaces instead of 4. This tells me that the author simply doesn't hang out with python people.
2) On the substance of your concern: I think the evidence is clear (although I'm aware of no study) that having both syntactical control characters (typical curlies) and style-only indentation is more likely to lead to the outcome that you present, because the eye will always gravitate to read by indentation, whether it's syntactical or not. So have the indentation be the syntax makes this problem more easily avoided, not less.
IE:
def foo() {
nums = [...]
sum = 0
for x in nums {
print(x)
}
sum += x
}
The difference here is that the former (your example) is automatically correctable whereas the latter is not.
If I highlighted that entire function in my editor of choice and hit TAB I'd get exactly the "correct" indentation.
Almost any modern editor can automate this for you. It's one of the benefits of having a syntax for blocks. Yeah, it's extra typing for something you're going to do anyways, but now the computer can manage the style for you.
Also, and this is just my personal experience, I've learned to read by those control characters. I have a really hard time reading python because I'm subconsciously looking for the control characters!
I really think that part is really down to how you learned to program and what language you use on a daily basis.
As an aside, I think something like this is much more demonstrative of the issue you're suggesting:
def foo() {
nums = [...]
sum = 0
for x in nums {
print(x)}
sum += x
}
It's still automatically fixable, but it's way less immediately apparent that something is wrong with the indentation.
Right, so you do your automatic fix and you end up with indentation that's the same as the python example. Isn't this a case for syntactical indentation?
I think it's very clear the author uses atypical tools or workflow. Nothing wrong with that, they just have to accept the fact that most hackers use tools that auto indent their code intelligently and find a way to get their method/scheme/whatever in such a way to deal with it like others do.
I 100% agree with you, but as a minor counterpoint, let me present you where an indentation might be a problem. I teach python (to my friends lol, not professionally) and a new learner apparently debugged this "for hours" (probably just 20 minutes).
They intended to make `some_other_method` a method of class `A` instead they ended up writing `some_func` the wrong place and python parser was happy. For everyone except extreme python beginners debugging this will take 10 seconds. But just a datapoint.
A number of these points seem like reasonable opinions to have. But two which had me questioning the breadth of the author's experience were "Most programming languages pass function parameters by value." and "In every other language, arrays are called 'arrays'. In Python, they are called 'lists'."
To the author:
1. Java, JavaScript and C# all have types which are passed by reference. (They also have types which are passed by value.)
2. Python lists are not arrays, if by arrays you mean a C- or FORTRAN-style block of non-resizable memory which is indexed by position. Python lists are much more like the Java List or C# IList interface.
Python (and Java) do not pass anything by reference. They pass by pointer-value. (If they passed by reference, you could change to which value a caller's variable was bound, like you can in C++).
Those languages use references rather than pointers (that is, their referring-things do not support arithmetic), so any name for what they do that involves "pointer" is a poor one.
The distinction between passing the value of a reference being used by the caller and passing a reference to the caller's stack is so rarely important or useful that there's no consensus terminology for it. The distinction that's actually relevant and useful is whether, when we write f(a), f receives the (thing we would call the) value of a or a reference to the value of a (and in particular whether f can change the value of a). In Python, f can change the value of a (that is to say, the thing Python programmers understand to be the value of a); therefore Python is pass by reference as the term is usually understood (and certainly any term for its call style that uses "value" is more misleading than calling it "pass by reference").
"The distinction between passing the value of a reference being used by the caller and passing a reference to the caller's stack is so rarely important or useful that there's no consensus terminology for it."
And the reason for that is essentially all modern languages make copies of something when passing argument parameters. The only question is what they are passing and exactly how hard the language layer works to make it look as if you are or are not passing something by reference.
I have to reach to something as obscure as Forth to find a language that does not work that way, and truly does not copy parameters into a function. (I haven't dug into Factor enough to know if under the hood it still copies parameters.) It's a very unusual choice to not copy something for a function call.
(This is one of the ways our CPUs have been optimized for the languages we run; they make this intuitively expensive operation otherwise cheaper than it would be on a naively designed CPU.)
> And the reason for that is essentially all modern languages make copies of something when passing argument parameters.
Then of course someone turns on whole program optimization for C++, half the code gets inlined into one terrifying large function, nothing is copied anywhere, and the code runs 2x faster.
Then some poor SOB has to debug the assembly code for all of this and has nightmares for years after.
"Pass by value" and "pass by reference" are both wrong with respect to Python. They denote semantics that Python does not have, and coders believe and do wrong things if they believe Python follows one or the other. Hence a 3rd term is needed. I don't care what you call it, because it's just a name, but it is a distinct idea, and I'm not the only one who thinks this: https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sh...
> In Python, f can change the value of a
but it can't. `f` can't change the object which `a` references:
def f(x): x = 5
is a function with no visible effect. When called as `f(a)`, `a` retains whatever value it had previously.
People who believe Python is "call-by-reference" don't understand this and write incorrect or overcomplicated code as a consequence. The distinction is important.
There is no consensus that "pass by reference" denotes that, whatever a wikipedia editor says. Normal working programmers do not understand "pass by reference" to mean specifically "pass a reference to the caller's stack" but only the more general concept of "pass a reference to the value of a". If you want to talk specifically about what kind of reference gets passed, you need some new terms for that, and both the new terms you come up with will be subtypes of what most of the world will continue to understand as a general category of "pass by reference". No-one outside of these arguments on HN gets confused about whether you can write a swap function in Python; people understand "pass by reference" to mean something more general and entirely true of Python (and Java and so on). You can tell by how often we see those languages described as "pass by reference".
> but it can't. `f` can't change the object which `a` references:
Yes it can. It can't make a to refer to a different object (as your f tries to), but it can change the object a refers to just fine.
> (If they passed by reference, you could change to which value a caller's variable was bound, like you can in C++)
I might be misunderstanding you, but I don't think you can do this in C++. References can't be changed to point to a different object after initialization. If you have code like:
The assignment above isn't "changing the value to which a caller's variable is bound". Instead, it's running the '=' operator on the Foo object to copy the state from new_foo to ref_param. To demonstrate this, you could run the following to see that the addresses are the same:
Foo original_object;
Foo& object_ref = original_object;
MyFunc(object_ref);
// object_ref still points to the same address
assert(&original_object == &object_ref);
Under the hood, C++ reference params are basically syntactic sugar for passing by pointer-value, so this behavior isn't surprising.
The proper analogy for a Python object is `std::shared_ptr<Foo>`: in Python, all "objects" are actually reference-counted pointers to objects (thus making them shareable). And then yes, in C++, you can change to which object the caller's "object" (pointer-to-object) points to, if you pass a reference to that. This is not possible in Python: all you can do is pass that shared-pointer value around, not the value of the object itself, nor a reference to the shared pointer.
Ah, got it. Your basic point is that C++ params can use two layers of indirection (pointer-to-ref, ref-to-pointer, pointer-to-pointer, etc.), while doing so in Python is clunky. Makes sense.
No, Python doesn't even do that, because Python variables aren't names for storage locations to begin with. They're namespace bindings. Passing a variable to a Python function means transferring a namespace binding from the caller's namespace to the function's local namespace.
What Java, JavaScript and C# call "arrays" are each very much like what Python calls "lists'. In particular the indexing after push() and pop() type operations and the bigO of indexing.
More abstractly, Historically, in computing "list" connotes pointers and "array" connotes sequential memory. The connotations imply engineering tradeoffs. [1] "List" may make more sense for a beginning programmer. It is an arbitrary context switch for programmers writing in multiple languages. Considering that one of the driving use cases of Python has been systems programming, "list" is misleading regarding performance characteristics. [2]
[2]: googling "python arrays" returns a lot of results explaining the difference between Python's Arrays and Python's Lists. "List" is "foo => spam" and "bar => eggs" Pythonism gone too far.
Not true for Java or C#. In both of those languages, arrays are fixed-size and don't have anything like a push or pop operation. Both have an automatically resizing container backed by an array that is referred to as a list. Python's use of "list" matches the use in Java and C# perfectly.
Requiring a type definition, Python's Array type more closely matches Java and C# Lists than Python's List type.
In Python, Arrays are sequence types and behave very much like lists[1] In other words, even in Python, arrays have similar semantics to Javascript Arrays not Java Arrays.
What Java, JavaScript and C# call "arrays"
are each very much like what Python calls
"lists'.
In Java and C#, 'arrays' are fixed size at creation time.
Both Java and C# provide 'lists' which are variable sized*
Python 'lists' are variable-sized.
Seems like a consistent naming scheme to me?
*there might be an underlying array that gets reallocated - but it's encapsulated within the list object; the reference to the list object is unchanged when this happens.
In C#, all variables ( reference or value types ) are passed by value. Yes, even reference types are passed by value. If you want to pass variables by reference, you need to use special modifiers ( out or ref ).
You are correct that changes to the object will be reflected in the calling code. But that's the nature of the reference, not whether it is called by value or called by reference. Whether you pass a reference by value or by reference, the changes to the object will be reflected in the calling code. And as I noted, it's all passed by value in C# unless you use modifiers ( ref or out ).
The difference between "pass by value" and "pass by reference" for reference variables is how the variables themselves are handled. For example, if you pass a reference "by reference" to a function and set it to null, then the reference variable in the calling code is also set to null and will cause null ref exception if you try to access the object. Whereas if you pass a reference "by value", if you set the variable to null, the calling code variable isn't affected.
Pass by value and pass by reference is not about objects or types really, it's about variables.
Right, but this is the same way Python works. Jumping back to the original argument in the post, the author claimed that Python was "going out of it's way to be different" by passing objects by reference value. C# provides a counterxample to that claim.
Java passes by value. The value being passed happens to be a copy of a pointer (properly called a "reference" in the spec, which confuses people). A copy of a pointer points to the same place as the original pointer. For normal use cases this works very well.
However, if you reassigned your copy of a pointer in the body of a function, the original pointer would still point to the same place it did before the function was called.
That's not the same thing as actual pass-by-reference in languages like C++.
> Most programming languages pass function parameters by value
The biggest irony here is that if you wrote your code in C instead, you would actually pass more arguments by reference than in equivalent python, because you're going to use pointers for everything but primitive integer values.
No, the biggest irony is that C as a language does not even have a syntax for passing by reference. Everything, including pointers, is passed by value. References were introduced in C++.
> My code for Python 3.5 won't work with the Python 3.7 installation unless I intentionally port it to 3.7.
This statement is plain wrong at best and intentionally misleading at worst. 99.99% of Python 3.5 code runs unmodified on 3.7.
> At the official Python web site, their documentation is actively maintained and available for Python 2.7, 3.5, 3.6, and 3.7 -- because they can't decide to give up on the old code.
No. It's because some people still are on the not-latest version and still need access to the documentation. It's what every good project should do.
I stopped reading there. Too much wrong in too little text.
There is one other thing that could break, but it would be a weird one. Which is hard to explain in prose, so here's some example code:
class SomeMetaClass:
def __new__(name, bases, attrs):
pass
class SomeClass(metaclass=SomeMetaClass):
pass
Now suppose that SomeClass needs to use the typing module's mechanism for indicating a generic, so you could do an annotation like "SomeClass[SomeOtherType]". So you'd want to have SomeClass be a subclass of, typing.Generic[T]. That would, in Python 3 prior to 3.7, raise a TypeError due to metaclass conflict -- the generics in the typing module had their own base metaclasses. So you actually had to define an intermediate class to resolve the metaclass conflict, and do like so:
class IntermediateMeta(SomeMetaClass, typing.GenericMeta):
pass
class SomeClass(metaclass=IntermediateMeta):
pass
(this was weird and rare and GenericMeta was never documented)
Python 3.7 implemented PEP 560, which introduced the __class_getitem__ hook for implementing the behavior GenericMeta used to handle, and doing away with the need for the typing generics to use GenericMeta as their metaclass. So GenericMeta exists in Python 3.5 and 3.6, but no longer exists in Python 3.7, and anything which tries to reference it will break.
> and i wonder why they would
It's easy, actually:
import asyncio
@asyncio.async # SyntaxError in 3.7
def my_coroutine(...): ...
And since asyncio is one of the strongest reason to migrate to python 3.x, I bet far less than 99.99% of code written for 3.4/3.5 can be run on 3.7 with no changes.
Luckly, 99% of changes were trivial. Other 1% is a nightmare.
I wouldn't be surprised, I've seen a developer use type as a function name and it was imported everywhere...it caused a lot of problems. Not to mention the function literally did nothing, it essentially returned none under 99 percent of circumstances. If the person that wrote that was still at the company, that should have been a fire able offense.
I figured that was a typo for 2.7. But even then there are relatively few areas that need some touchup from 2.7 -> 3.5, and most of those are mechanical changes like having parens around print statements.
A better reason to hate Python: the internal model is way overcomplicated for what it's meant to be: a beginner-friendly scripting language. "Everything-is-an-object", duck typing, decorators, bizarre scoping rules, etc., all make it difficult for experienced programmers to understand, let along beginners. I've always thought there's a much simpler language struggling to get out of Python, and I wish it would and would become popular so I wouldn't have to recommend Python to beginners any more, and be on the hook for explaining e.g. why default values are mutable, or why nested generator comprehensions behave differently than nested list conprehensions. (Think Erlang levels of simplicity.)
The standard library is also haphazard and inconsistent (much like JavaScript's). Take lists: some operations are methods, some are functions, some mutate the list, some make a copy, some are global, some are in a module. There's no rhyme or reason that I can tell. Modern C++ has, in my opinion, a much more well-thought-out standard library. There are very few methods/functions which exist due to historical accident (iostreams aside), and the distinctions between methods/free functions and mutators/copiers is fairly uniform.
OK, fair point. I misremembered the list interface.
`set` is a better example: `set.union`, for example, returns a new set, while `set.add` updates in place. (To be fair, this is with Python 2.7, maybe Python 3+ is more uniform?)
What would you expect it to do differently in those cases? That seems like the API is following how most people would think about those operations as you'd expect in a language which isn't trying to be immutable.
I thought it was interesting that Ruby, by convention, used an exclamation mark to convey that a function would mutate. I haven't used Ruby all that much to see how well that works at scale.
> I've always thought there's a much simpler language struggling to get out of Python
I agree, although I suspect we have different ideas as to which parts of Python would be included in that simpler language. For example, I quite like the consistency of "everything-is-an-object".
FWIW some of the Python core developers have started to express a similar sentiment. Especially in the last few versions, where Python has got much more complex with the addition of type annotations and multiple `async/await` features. I wonder whether the retirement of the BDFL will slow down Python's rate of growth, or accelerate it?
> nested generator comprehensions behave differently than nested list conprehensions
I haven't come across this - could you give an example?
>>> [[x*y for y in xrange(1,5)] for x in xrange(1,5)]
[[1, 2, 3, 4], [2, 4, 6, 8], [3, 6, 9, 12], [4, 8, 12, 16]]
>>> list([x*y for y in xrange(1,5)] for x in xrange(1,5))
[[1, 2, 3, 4], [2, 4, 6, 8], [3, 6, 9, 12], [4, 8, 12, 16]]
>>> [list(l) for l in ((x*y for y in xrange(1,5)) for x in xrange(1,5))]
[[1, 2, 3, 4], [2, 4, 6, 8], [3, 6, 9, 12], [4, 8, 12, 16]]
>>> [list(l) for l in [(x*y for y in xrange(1,5)) for x in xrange(1,5)]]
[[4, 8, 12, 16], [4, 8, 12, 16], [4, 8, 12, 16], [4, 8, 12, 16]]
The problem is that the `x` in the inner comprehension gets somehow linked to the variable `x` in the outer comprehension, rather that the value of `x`. (This matches Python's similarly bizarre closure semantics.) So, the results are "as expected" when either (a) the inner comprehension is evaluated eagerly (first and second example), or (b) the outer comprehension is evaluated lazily (second and third examples). But if both the inner and outer comprehensions are evaluated lazily, the inner comprehensions just see whatever the "last" value of `x` was, which I think to many people is surprising. (No less so than mutable default arguments, at least.)
You're right, this is the same problem that Python has with closures, for example:
>>> l = []
>>> for i in range(10):
... l.append(lambda: i)
...
>>> for j in range(10):
... print(l[j](), end=' ')
...
9 9 9 9 9 9 9 9 9 9
The issue isn't really closing over the variable instead of the value, but the fact that Python re-uses the same variable for each iteration of the loop. C# used to behave the same way, but its designers considered this bad enough that they made a breaking change to the language to fix it [1].
Unfortunately, C#'s solution (creating a new variable for each execution of the loop body) isn't really an option for Python. It would conflict with the rest of the language, which only uses variables scoped to whole functions.
Note that Go makes the same mistake as in earlier versions of C# [2].
In practice, snippets of Python look very similar to pseudocode. A lot of the idiosyncrasies I see people bring up I consider "intermediate" or "advanced" Python. For the first 5 years I used Python I never wrote a class or a module (I was familiar enough to know when I saw one), let alone cared what a meta-class was.
It's not a beginner language, but it is beginner-friendly.
It's actually a huge problem if you end up trying to hire people to build enterprise software in Python, because everyone and their mother has "5 years of Python experience", but "scripting on your own" is miles apart from "building well designed systems".
"Language for people who are not programmers but who need to instruct computers to do things" is the definition I work with. Scratch, BASIC, etc., aren't really suited to that role. No-one who's just trying to munge some files wants to be told "OK first learn this language that isn't useful for you, and then you can learn a language that is". Hence why practically, Python tends to fill the "beginner" role, which is unfortunate due to its complexity.
It's true Basic was designed to be a beginner's language; but in practice, what exactly is easier in Basic? (Even disregarding Dijkstra's assertions that Basic "mutilates the mind", because I suspect he would have held the same opinion of Python!)
The "immediacy" is there in both languages (well, in Python and modern Basic without line numbers): you can just type code without any rituals or mumbo jumbo and it will do more or less what you tell it to.
It was heavily influenced by ABC, a language meant to be used for teaching:
So, I decided to design a language of my own which would borrow everything I liked from ABC while at the same time fixing all its problems (as I perceived them).
Sort of. Maybe. When python was gaining momentum in university settings though, the one main argument I read from a professor more than a decade ago, is that the python implementation was near identical to their pseudocode. So they stopped using whatever language they were using in their textbooks, and started using python, since it made it easier to convey the knowledge they were trying to convey (and probably greatly decreased the amount of editing and typos).
Basically, don't discount a text book where every algorithm is executable code, without first having to translate it into some other language.
"So I never intended Python to be the primary language for programmers, although it has become the primary language for many Python users. It was intended to be a second language for people who were already experienced programmers, as some of the early design choices reflect. On the other hand, intuitively I probably stuck to many of ABC's design principles. Because although I had my criticisms of ABC, I borrowed many of its valuable elements, which eventually made Python a great language for people who aren't ace programmers or who are just learning. We now have a large community of people using Python as an educational language, teaching Python in schools. These people aren't and may never be professional programmers, but they still find some programming skills useful." -GvR
I think most beginners learn languages to solve some particular thing. Python has a lot of great libraries and tutorials for learning. It doesn’t matter if Python has a lot of idiosyncrasies—new Pythonistas are copy/pasting and mad-libbing their way to a basic understanding of coding.
Learning to program from first principles is hard, but I reckon Racket, a lisp, with it’s wealth of teaching materials and well thought out design is about as good a way to start as any. It’s small and consistent enough to actually learn from the ground up rather than by pulling on one thread.
I think that's how it got so popular. It gets taught in school as a first language because it's "simple, beautiful", etc. and people stick with their first language as people do.
> I've always thought there's a much simpler language struggling to get out of Python [...]
I tend to assume that about all languages now, and when I need to use a new language I try to just learn that simpler language initially. I skim the documentation for the rest, but don't learn it until I actually need it (either because the functionality is necessary, or it can make the code better).
It can take a surprisingly long time to need more than the simple language.
I think a simpler language would also have more potential for speedup. The effort PyPy has invested is herculean! Grumpy, Cython, Unladen Swallow, etc.
Python has fallen to my second or third most commonly used language now and speed is definitely a reason.
The C++ standard library is (mostly) an exemplary work, but that is despite the language's complexity, with pointers and lvalue, rvalue and forwarding references, just to get started...
"I wouldn't have to recommend Python to beginners any more, and be on the hook for explaining e.g. why default values are mutable, or why nested generator comprehensions behave differently than nested list comprehensions."
Maybe those scoping gotchas are not beginner topics?
Many of the reasons authors states are quite silly. Personally I don’t like the huge perf hits everywhere you look. For example, a bool in Python takes whopping 24 bytes! Multi threading is a giant mess due to GIL that apparently no one can get rid of. Things like true static variables are missing. Import behavior differences for programs and modules is baffling. Lambda is intentionally kept under powered (ex. no group by). Need to create new environments to avoid conflicting package versions can quickly become annoying (could have been improved by side by side versions).
Still, I don’t hate it at all. It’s good and beautiful for lot of other stuff.
Now this is a good list of things to hate about Python. I would add the fracturing of build methods for large applications is another frustrating thing about working with python. Although projects like Pipenv and Poetry seem to be bringing python up to modern standards in that arena.
I have yet to use poetry although I’ve heard great things and I’ve read a blog post that kind of sold me into it. How would you say it ranks compared to pipenv? I’ve had frustrating issues with the latter in the past month.
I can’t help but think that the lack of Kenneth Ritz in the commit list since summer has something to do with this. I don’t recall the exact scenario, but I think there was some kind of falling out between him and the community.
Even if you despise python to the core, it's hard to shrug off the massive number of well documented, mature libraries. Usually there are 2 or more choices with at least one of them being fairly mature and maintained. Not to mention the wealth of examples showing how you can do something.
So despite all the things I dislike about python, it's still my go to for a proof of concept or getting something done quickly.
2. Python libraries' documentation leave a lot to be desired (compared to good javadocs). Just because your language is dynamically typed doesn't mean you don't need to describe what the expected shape of a parameter should be.
3.
Static method? @staticmethod
Static variable? declare it outside of your methods but inside your class
Private method/var? name it: __name (but it's not really private just hard to find)
I'm sure other Java programmers have had a culture shock coming to python as well. I appreciate how concise the language is, the great community and module ecosystem, and how productive it is. But, it feels to me like there's features missing (I've only been seriously programming python for 5 months though, before I was basically just scripting and writing java code in python).
Also the most fun part of learning python has been list comprehensions and itertools, they've really been a revelation. Like when I first learned Ruby procs, blocks, closures and lambdas.
> Static variable? declare it outside of your methods but inside your class
Sounds like you're still thinking in Java :). A static method is rarely what you want (and if you do you can put it on the class like for variables); functions are first-class so you can just put them in your module.
As a former certified Java programmer, moving to Python was a breath of fresh air. More concise syntax, no more braces all over the place, much less boilerplate (think getter, setter, public static void main(String[] args)) and not everything has to be an object. First-class functions, yay ! (I haven’t used Java seriously since 1.6 so I don’t know how much the language has evolved since then). The only reason I’ve had to go back to Java is specific libraries, and speed.
Python’s philosophy of convention rather than constraint is a nice chance from Java’s corseted mindset.
But I’ve never had to use Python in a large development team, so I don’t know how well it holds up with a large group of devs.
As an aside, if you have fun with comprehensions, itertools and lambdas, I urge you to take a look at functional programming!
Coming from Java I loved Python's conciseness and convention, but as my codebase got larger I hit a maintainability wall where it was impossible to refactor reliably enough to keep the code clean and framework upgrades were always a massive task. Then I discovered Scala which combines the conciseness of Python (and allows you to write in a very "plain English" style if you want to, with the optional no-brackets call syntax) with the safety (and runtime and library availability) of Java.
Java has changed a great deal since 1.6, and includes something like first-class functions. But Java's main benefit over python is the JVM itself, which is extremely well specified and generally a rock-solid piece of kit. Python doesn't have a specification, or alternative implementations (AFAIK) and I think that hurts it.
Python is not specified but CPython serves as a reference implementation. Python has _numerous_ alternative implementations. Jython in Java, IronPython in C#, PyPy in Python (kinda...), and even more lesser-known implementations.
> Private method/var? name it: __name (but it's not really private just hard to find)
This is why I _love_ python. Stop trying to protect me from your library. I've been doing some C# work and nothing bothers me more than having to fork and re-build an entire library just because the author didn't think I should be allowed to touch some variable that should've just been `public` or `protected`.
I don't need a library author to hard-block me from things. Put up the appropriate warning signs, then get out of my way.
The solution is to stop thinking about private and static variables :)
I've been developing Python for upwards of 10 years, and not one single time I have ever had a legitimate use for double underscore, and I've only seen one legitimate use in the wild (involving auto-generated code and C interfacing).
> 2. Python libraries' documentation leave a lot to be desired (compared to good javadocs). Just because your language is dynamically typed doesn't mean you don't need to describe what the expected shape of a parameter should be.
- 1 & 2: just use virtualenv, js has its own version manager too (nvm) which is very useful. This is one of the reason why only python2.7 is included in OSX, since most of seasoned python devs not use it. usr/include vs usr/local/include in cpp are not easier to use / understand.
- 3: my opinion is this forces you to write readable code, in which you don't have to ask yourself where the scope starts / ends
- 4: since import use dot notation you just need to follow the path until you find a file and in this file the corresponding function. Or read the doc. Or use an IDE with autocompletion. Looking a .h files in c sometimes lead to using a wrong function judging only by its name.
- 5: They are called "list" because they are lists, not arrays in a C sense (size not fixed)
- 6: multiline strings are a mess indeed, but python3 handles them all in utf-8 (one of the reasons why it broke backward compatibility)
- 7: just like js, making them 2 of the 3 most used languages. Understand the difference between pointers and references is harder to grasp for a beginner to just remind modifying the arguments of one method is dangerous unless you know what you're doing
- 8: there is the from ... import ... which allows you to avoid this while being explicit
> 3: my opinion is this forces you to write readable code, in which you don't have to ask yourself where the scope starts / ends
I agree with this so much. I've never looked at someone's python code and had a moment's confusion about where a particular function ends. On the flip side, I see plenty of randomly/confusingly indented C/C++/C# code.
I'm a python hater. Yes it is easy, but in exactly the wrong way. Easy for simple code for middle schoolers. For grownups with large codebases to develop and maintain, it's not optimal.
Of course I hate the whitespace trickery. I hate the auto formatting that sometimes doesn't work. Those are fairly minor.
What I really, really hate is the lack of static typechecking. You often have to read lengthy swathes of code to understand how functions are actually used. The conventions in the community are terrible. I have used respected libraries where functions are designed to return a variety of types, just because, so you need to dynamically typecheck your results. Gawd.
And just as bad the fact it is impossible to encapsulate code. This underscore nonsense, don't even mention it. Sheesh. I have found that in real life, internals bleed out over the code base making code more fragile over time and harder to refactor. It has all these open source scientific libraries because professional programmers were working on other things, and that is truly unfortunate.
The lack of seriousness is demonstrated by the fact that it's frozen in time in terms of runtime data structures because cpython knows and relies on those internals. Nutso.
Easy for simple code for middle schoolers. For grownups with large codebases to develop and maintain, it's not optimal.
Yes, like the tiny puny baby middle-school children who built microscopic useless toy "programs" (not even worthy of the name) at Instagram, YouTube, Dropbox...
What I really, really hate is the lack of static typechecking.
Then don't use dynamically-typed languages. Not everyone shares your tastes, nor do they have to.
And just as bad the fact it is impossible to encapsulate code.
The more you write here, the more I think C# is a great language for you. And I don't dislike C#! But you want a nice statically-typed object-oriented language with data hiding. C# is an example of one. Python is not.
And then the GIL!!
I've written at length about how the existence of the GIL is the result of tradeoffs that seemed perfectly reasonable at the time (keeping in mind that Python is older than Java, and I suspect older than the average HN commenter). With 20/20 hindsight would a different approach have been better? Sure, but if they'd had the ability to see the future in enough detail, the folks who chose those tradeoffs probably would have bought lottery tickets instead of building Python.
While it is technically feasible to write a maintainable and well-organized large codebase in Python, in practice the lack of static types leads to a giant mess.
After trying to maintain a legacy system written in Python (where all the authors had left the company) for a year, I threw my hands up and moved on to a Scala shop. I vowed to never work again on any major project written in a language without static typing.
I think this lesson has been learned in the broader community though. Even most of my colleagues that have used Javascript for years have moved on to Typescript and never looked back.
I even disagree with the, "well it's good for small projects" line of thinking. Look - if it works there, it's only because you have net fewer bugs to catch and lines to read, so the cognitive overhead can be born. But why not dispense with that cognitive overhead in the first place and just use static types!
The one exception I make here is for shell scripting. The tight integration with the command line just makes bash the best choice for some situations. But even then, I have about a 50% success rate of estimating whether or not this "little script" will ever grow to become a production application with multiple modules and components, so today I'm even wary of using shell scripts in many cases.
> Look - if it works there, it's only because you have net fewer bugs to catch and lines to read, so the cognitive overhead can be born. But why not dispense with that cognitive overhead in the first place and just use static types!
I'm not convinced. When a program really is small enough to hold the whole thing in your head, writing that knowledge down is just overhead. (Of course, this reverses as soon as the program gets bigger than that).
I used to program in Python, and found Ruby as a language to give me everything Python provides but with a more Programmer friendly syntax.
I never understood why you would use a function like len() in an Object Oriented Language (instead of x.len ) or having to explicitly add self to every method...
> I never understood why you would use a function like len() in an Object Oriented Language (instead of x.len ) or having to explicitly add self to every method...
The answer is simple: there is a x.len function. It's just x.__len__, the protocol. Forcing it to be exposed on every type is a waste: do you use .len, .length, .size? This duck-typing allows any object that supports the length protocol to be passed to `len()`. Simple.
Having it add itself to every object is.... not what you want at all. Some objects don't have a length.
I agree with a number of the author's points. For me personally, the biggest single issue is the scope by indentation. I know some folks like this, and think it is good to restrict single functions/methods to less than a page in an editor ... but I personally do not like a language imposing such opinions on me. It makes, IMO, reasoning about the code your reading, even if it fits in a single editor page, very ... very hard.
As someone who works with multiple languages across multiple environments, the author's comments on the installation ecosystem are on point. Though, these critiques are better directed at the packagers of the distribution. I'd given up on getting current, correctly built versions of Perl, Python, R, Octave, etc. from packagers/distros, and simply build my own in a separate tree[1]. Most folks now do this in user home directories, but I still personally like the system level availability.
FWIW, I've found that Julia[2] is a far better Python than Python. You have all the advantages of a JIT compiled language which does parallelism/concurrency well, has an awesome FFI to simply use external libraries, etc.
This rant would have been exactly the same if he had just discovered Perl5. It's got way more quirks than Python, but you deal with it, because the language is super useful.
The one valid gripe that wasn't quite there is why doesn't Python (or any other language really) manage its modules like CPAN? CPAN is amazing. It's ancient and dusty and missing obvious modern improvements, but it's still way more useful than anything else.
Searching through PyPi is pretty awful. Look for "yaml versioning" and get 10,000 projects to wade through. CPAN is hierarchial, so not only can I find what I'm looking for, it even exists on disk where I expect it.
Because of all that, a few other things happen. The low level modules are older, exposed to more users, so people find them first, improve them over time, and this influences and improves new code. Not only are there these great examples of quality code for comparison, but code reuse and extending is way more common than entirely new modules.
Testing is also really rigorous. CPAN testers framework tests across all Perl releases and computing platforms, continuously. Perl module build instructions are converted easily to Makefiles, making it easier to build and test on other platforms if you're not familiar with Perl conventions.
Most modules also provide real in-line documentation, not just one line describing what a function does. Perldoc usually gives you a real man page for any given module you're looking at, whereas Pydoc gives you a bare list of method calls and objects that maybe the author added documentation to, but often not. Which am I supposed to use, for what? Might as well go read all the code...
...oh, and unrelated, but using regex's in Python is kind of horrifying.
I remember the perl4 to perl5 transition. I had some perl4 code I wrote to automate runs of my code. Porting it to perl5 made me grumble a little, but it was mostly very minor changes. About an hour of work for all my code.
But, yeah ... CPAN, and C-TAN, are things to behold. Python hasn't done a great/good job with this. Npm is just plain awful. Julia's Pkg was good in the 0.6.x days ... seems to be borked now, though this may be due to the 0.6 -> 1.0 transition.
For me, Perl is my go-to scripting language. I've written some pretty intensive apps in it, which would be horrifying in other languages. It has (many) warts, though packaging isn't one of them.
I am looking at using Julia for scripting in places where I'd ordinarily use Perl ... mostly data clean up. This noted, it is very hard to beat Perl in munging data. R comes close, but writing parsers in it is hard.
Perl6 aka Rakudo is very interesting to me. Addresses many of the issues I've had with Perl in the past, and gives some truly incredible power going forward. Adoption appears to be low and slow right now. I don't actually have time to play with it now, as I've got other higher priority issues to deal with.
I agree with the OPs points but disagree with the degree to which the author has used them as a means to "hate" a language. I generally avoid Python too but saying you hate the language because of a bunch of contrivances mostly wrought from inexperience and holding too strongly to C like languages is poor form.
Versions:
Ok? Versioning and fragmentation is a hard problem. Backwards compatibility is a hard problem. Moving fast and never breaking anything is a nearly impossible problem. Python sucks at it, lots of things suck at it. There are many examples of other languages (.NET Core, for example), platforms, frameworks, etc that all suffer from this. It can be a reason to avoid those things but probably not one to base a loathing on.
Also, lots of people still use Perl. Lots of people still love Perl. I don't know why.
Installation:
This screams "windows only" user. Path'ing, local dependencies, and package management is relatively common and you should force yourself to be comfortable with those concepts. Just saying "I should be able to just run one thing and be done forever", albeit ideal, is naive and never going to happen.
Syntax:
Yep. Spacing blows and you're always going to have stupid issues with it. I hate Python's spacing. Someone ought to create a custom interpreter that allows for using braces.
Includes:
Most of these complaints sound like they're coming from someone largely silo'd in the C/C++ world of wanting to know everything. "With C, you can just look in /usr/include/*.h" - the author is admitting he's unhappy because Python isn't C.
Quirks:
General complaints about other languages... and using those complaints to somehow sour Python? The quirks he does list for Python aren't even strange - they're pretty useful.
Local Names:
OP probably could have just included this in quirks rather than having another point. I'm pretty sure there's actually a means of avoiding this type of import issue by some silly Python pathing shenanigans.
> Also, lots of people still use Perl. Lots of people still love Perl. I don't know why.
Perl still holds a special place in my heart. It's so forgiving that it's perfect for banging out something that gets the job done in a couple minutes but while I most often use it for something quick and dirty you can still put in some time and planning to write something complex and maintainable too.
I'm not sure there are major projects being written in perl today, but it's the language I still use for automation of day to day admin stuff and for pretty much all of my log/mail parsing needs.
> author is admitting he's unhappy because Python isn't C
That's not the point at all. I mean, did you read it?
How do you mischaracterize the specific point about the casual opportunity for foreign module metaprogamming? Module initialization is bad in a pernicious way. While you can't do operator overloading, you can clobber namespaces (which was referenced). Paired with a community repository, this is exactly the same case of what's so dangerous about npm.
My point wasn't to devalue his arguments - in fact, I find them valid arguments. My point was he's using inexperience and/or familiarity with C/C++ as a reason to "hate" it.
He complains about Python developers grep'ing directories when he admits to looking through just as arbitrary of a directory. His complaints about random code execution during import is valid but also seen as a feature _allowing_ metaprogramming. It's just as bad as C/C++ allowing clobbering over memory.
These are features that come with trade-offs. The author is focusing _only_ on the trade-offs and how they don't exist in his favored language as a reason to hate the language. That's certainly fine for his subjective opinion but not as appropriate in a blog post where he is clearly trying to persuade others.
> It's just as bad as C/C++ allowing clobbering over memory.
That's a good parallel.
> My point was he's using inexperience and/or familiarity with C/C++ as a reason to "hate" it.
I have less familiarity with C/C++ than Python and I hate it because it's not about language perspective. It's bad language design, for such a high level language. Inclusion wrapped with execution is unsafe and has an easy fix for most language interpreters. Don't allow execution during a declaration. If you want to do metaprogramming, there are other ways that don't break the paradigm (rewriting files before inclusion, chaining programs, etc).
> Syntax: Yep. Spacing blows and you're always going to have stupid issues with it. I hate Python's spacing. Someone ought to create a custom interpreter that allows for using braces.
Nope, for reasons I've explained up thread. In the meantime I suggest this code:
Your reasons amount to "use an editor that shows whitespace". That's valid and would be my suggestion to people too but it doesn't address my comment. Using an editor for a "necessary" feature only helps you when you have it. If you, on an off-chance, don't have it then you're going to have a bad time.
Comparing whitespace issues to brace-matching issues is a strawman. Braces are visible in 99% of editors.
I use nano or micro at times, which don’t, problem doesn’t happen there either.
The benefits are enjoyed every single read of the code while the drawback is a potential issue (being very generous when I say) once every six months. Honestly happens about once every five years to me.
This article illustrates amateur hour in many
ways.
The whole can't manage my environment and don't
understand how to manage the python thing at all
has my sympathy. Python is messy at that level.
With the organizational 'control' sysadmin deprecated
by devops and containers/automation becoming the
new norm these types of complaints have to be
dealt with by people who have no idea of what
they are doing in generalized context.
> My code for Python 3.5 won't work with the Python 3.7 installation unless I intentionally port it to 3.7.
Probably not. While I can't guarantee there are zero breaking changes, it is highly unlikely to encounter any from 3.5 to 3.7. Another numerical pair might have been a better example.
The split between 2/3 was an issue, widely known, and in the past. Personally I'm glad some big problems in 2 were fixed, though there was some pain.
> When Perl5 came out, a lot of people just switched to a different programming language that was more stable.
Nope, Perl 5 was incredibly popular. It was 6 and the two decade wait where folks jumped ship.
> And I pity anyone who miscounts spaces and accidentally puts in three spaces instead of four somewhere -- this can take hours to debug and track down.
Nope, it tells you the first line where the indent is wrong.
> imports: then search every file in every directory
Nope, just type import ... If you want to know which file it found, print(module).
....
Others have found the other issues. Most of these are nitpicks from someone who doesn't fully understand or agree with the tradeoffs chosen.
IMHO, the biggest design flaw left in Python is that it is always dynamic and that's what makes it so slow.
Why too dynamic? Well, changing types of variables isn't used much in practice. So, to pay a time cost for it on every single line is unnecessary. If types were fixed by default but let you opt in to dynamic when needed, we'd have the best of both worlds. Speedy most of the time, dynamic and slow when actually useful.
Basically whole infrastructures like Cython have been built to correct this.
hah yeah, perl5 was basically perl's renaissance. the web took off and perl was basically used to glue it all together. they did go crazy with perl6 though, and i think a lot of the reason why python took off was because of the hole the perl developers left and google liked python.
it seems the performance problems in python can (and are) being fixed. the big downsides i see are the 2to3 mess (which seems like it will be solved with time), weak concurrency support in the default implementation and the lack of the ability to do much real static analysis.
Reason 2 is getting out of hand for Python, Ruby, JavaScript, Haskell and OCaml.
These so called package manager can't manage packages at all. I'd like to call it package downloader. They just download everything from language interpreter to library to a single directory and call it job done. No easy way to remove the package. The interpreter and library's version is forever fixed. Theoretically, it can upgrade the version but the user mostly don't.
> They just download everything from language interpreter to library to a single directory and call it job done.
This is scoped to the project in npm. In Ruby, you can specify the path (common to "vendor" your gems). You can use version managers (like rvm or nvm) to scope your libs to versions or even named projects (thinking of rvm's "gemsets")
> The interpreter and library's version is forever fixed. Theoretically, it can upgrade the version but the user mostly don't.
I can't speak for all ecosystems, but on Ruby projects I've been a part of, keeping gems updated is pretty common. Github even includes monitoring for vulnerabilities to encourage this.
Having been part of ecosystems that don't have package management (for example, ColdFusion) even the worst package managers are a major improvement. (Though I do think the isolation of python's virtualenvs is a better approach than most systems)
> Here I am hating on the language I love, but I remember when I would have to review this question on StackOverflow every time I wanted to create a new virtual environment:
I will stick up for this person. I agree with all of the points listed here. But especially: Python version management and installation sucks.
A while ago I had a broken python ship with my Ubuntu desktop. Pip decided they were going to deprecate behaviour, and nobody updated or tested on Ubuntu.
Also it is slow and ugly. Just write it in Golang or something.
Version management is pretty easy to solve: Just use virtualenv and you won't have a problem. If you start messing around with system level python package installs, you'll likely make a mess.
As for ugly, I disagree and find Python some of the easiest code to read. "Slow" depends on the application. For 90% of the apps out there, you're waiting on something else (network IO, DB, etc.) and it's fine.
I too have tried it many times mainly because of all the great ML libs for python but each time I dreaded using it for Reason #3 (Syntax).
Using indents for blocks just seemed unintuitive and error prone to me. But I dismissed it because all the programming languages I've worked with have had curly braces so maybe
the reason for my discomfort was that it was unfamiliar.
Most languages that use braces also encourage you to indent the things enclosed by the braces to make it easier to read. However, people sometimes make mistakes. For instance I've seen this quite a number of times
if (a)
somestatement;
someotherstatement;
athirdstatement;
Which is of course horribly misleading unless you're careful because the second statement isn't actually conditional on a. Python forces the indent to match the semantics.
It sounds great in theory, but it leads to problems in practice. If you copy and paste code from any language with C style syntax, it's trivial to fix the formatting based on where the braces are, and your editor can help. With python, testing a 10 line example program from a forum post can turn out to be quite difficult. Not to mention, if a tab character ends up anywhere in your program, you now have a syntax error that's completely invisible to the eye. Lastly, it makes it difficult to have clean syntax for multi-line statements.
Does no one have auto indentation in their editors? Every so often I just select the block of code I'm editing and auto indent it, which matches indentation with semantics without me having to think about it. Annoyingly impossible to do this with python since indentation is semantics. It also results in copy pasting of code being 100 times harder in python than other languages.
If this were code that I was writing myself it wouldn't be a problem because I always use braces even for single statements. And I do use an auto-indentor. But these issues come up when I'm reading other people's code, especially libraries supplied by IC vendors.
As for pasting, if you're using an IDE that ought to be taken care of for you. I use a vim and the sequence for indenting or de-indenting the text I just pasted is now second nature.
For the first 5 or so years of my career I used Algol syntax (and a bit of Lisp) exclusively. But having been trading off between C, C++, and Python since then I've come to prefer Python's syntax, though not its lack of static types.
That doesn't help with the problem you're replying to – in fact it would contribute to it.
More generally, yes, many people use auto-indenting and it works in Python in most editors. It's possible that you're using one where it doesn't work correctly but that doesn't mean that's true for everyone else.
It does help with the problem I replied to, which was code written in C. Auto indenting that code block would indent the `someotherstatement;` line correctly and I would notice that mistake. Anyway, single line if statement is a flaw in C's design.
What I said was that in Python's case, if I indent some code block wrong, I can't just fix the indentation using auto indenting in python, because the indentation is the semantics. There would be "nothing" to fix and the code would just run wrong. This problem comes up always when I copy paste python code. Of course I should notice that it's indented wrongly but that doesn't always happen. (And please don't advise me to never copy paste code. Life doesn't work that way.)
> Auto indenting that code block would indent the `someotherstatement;` line correctly and I would notice that mistake.
In my experience that last part is somewhat optimistic for the implication that someone would notice it immediately.
> if I indent some code block wrong, I can't just fix the indentation using auto indenting in python, because the indentation is the semantics. There would be "nothing" to fix and the code would just run wrong.
This is true in some cases — most of the time you'll get an indentation error instead of it running incorrectly — but also why many editors have an auto-indent option for pasted code and autoformatters covert things like code which is consistently indented to match your project's indentation size.
I'm guessing it refers to moving something out of a loop, which in Python often requires only an indentation change. In most other languages, it requires moving the code to the other side of a brace, or perhaps adding a brace. If braces were considered whitespace, which is not entirely unreasonable when talking about Python vs. other languages, it would be much harder to come up with examples. Drawing a blank right now. Anyone else want to try?
At some point in my Uni I thought of writing a "curly braces to python" translator that will take code in "pseudo python" which allowed curly braces and would convert/indent it the correct way.
It seems unfair to complain that Python 3 breaks backward compatibility and then also complain about the reason that Python 3 broke backward compatibility (i.e. broken string encoding in Python 2).
For me, the siren call of Python was the supposed "elegance" (executable pseudo code!). But then you have these horrible non-composing list comprehensions (compared to say Ruby where the chain just flows from left to right instead of getting more and more nested), and that god awful "self" and "__init__" cruft. It just seems like a poorly designed (and/or evolved?) language.
It'd be nice if something else would carry the torch for nice AI library wrapper language...that alone is the only thing that can tempt me touch it.
It's such an odd mix of elegance and completely half-assed botched up language design isn't it? It always feels to me like one of those movies where they ran out of budget half way through and hastily pasted together the rest of the script.
Well, I do think Python sucks but those reasons have relatively little to do with it to me. I just don't like it from an engineering point of view.
- lack of proper typing - it pretends to have a type system but hardly enforces it anywhere at least with any of the common practices used by the community. 'quacks like a duck' is a completely asinine excuse for not properly using types and interfaces.
- lack of true multithreading (aka, GIL): if you can't use all the cores on your computer you drastically limit the scope of applications that can be implemented. No, I don't want to restructure my application into a distributed multiprocessing system just to access the basic capabilities of the CPU in my computer thanks.
- lack of true cross-platform. partly because of the previous point half of Python's ecosystem is written in C and needs to be compiled for (if not on) the target platform. Python tries to pass as a language with Java-like bytecode but the reality is it doesn't even come close to that. We regularly try to install Python tools and find that they can't run because some obscure shared library isn't available on our system, etc.
Mostly, I dislike Python because it seems to be such a trap for new programmers who learn programming in it and then think they should never have to learn anything else. Trying to coach people on my team who started with Python to use or learn anything else is extraordinarily difficult. I remember when Java was like that and it was ugly then - it's just as bad if not worse with Python.
>> Most programming languages pass function parameters by value. If the function alters the value, the results are not passed back to the calling code. But as I've already explained, Python goes out of its way to be different. Python defaults to doing functions with pass-by-object-reference parameters.
Python passes method arguments by value, pushing them on the stack like every other language I've used. Because everything is an object in python the passed _scalar_ values are references (addresses), the objects the references refer to are on the heap. I sometimes think literally everyone should have to use C for six months, most of this stuff would stop being debated endlessly.
Everything in Python may be an object in some technical sense. Semantically, everything isn't. The utility of "everything is an object" is as a promise that lets programmers write:
as is the case with Ruby or Smalltalk. I think that the author's complaints center around Python behaving like C sometimes and Smalltalk other times.
In particular, some operations happen according to the semantics of types and others happen according to the semantics of objects. At the lowest levels of Python, object oriented programming isn't available to do things like adding methods to Integer.
Are you after monkey patching, where you can add new methods outside of the class definition? That's not really a standard feature of all object orient languages - Java doesn't do that, for instance.
Python integers are definitely objects:
(3).real # returns 3
(3).imag # returns 0
Python's lexer/parser made different choices than Ruby's, so the parens are needed here.
+ Java doesn't promise "everything is an object." It has Base Types.
+ Python doesn't make a semantic promise that "everything is an object." Code for
(3).fizzbuzz => "fizz"
probably needs written in C because built-in types are closed and object literals use the built-in types. "3" cannot be forced to use a subclass of Integer.
At the bottom, '3' is defined in terms of Types (i.e. "Built-in Types") not as an Object.
+ Ruby's semantic promise that "everything is an object" means:
class Fixnum
def fizzbuzz()
if self % 15 == 0
"fizzbuzz"
end
if self % 3 == 0
"fizz"
end
if self % 5 == 0
"buzz"
end
return self
end
end
And "3" behaves just like any other object. The "everything is an object" promise means that behavior as an object is a cross-cutting concern (or an aspect).
probably needs written in C because built-in types are closed
"Everything is an object" does not necessarily imply "all objects are always infinitely monkeypatchable at all times". It also doesn't necessarily imply "you can change how the parser interprets literals".
You're also going to be really mad when you learn about __init_subclass__ and the fact that Python lets you write a class that can't be subclassed!
Python doesn't make me mad. It's frustrating because it's design never makes any sense to me.
__init_subclass__ is a perfect example. Not at the level of what __init_subclass__ does. But that instead of implementing private methods, there's are rules around double underscore methods and double underscore methods have different behavior (name mangling). They don't actually make the method private, the actual name is not the name in the source, and the name is not anonomized.
I can see a rationale for making some methods private. I can see a rationale for making no methods private. Python doesn't make methods private and then deliberately makes it hard to reap the benefits of this design decision. Instead of implementing the design intent of private methods, what gets implemented are impediments to utilizing the absence of private methods.
Mangling of double-underscore names isn't there to provide access control like in Java or C++.
Mangling of double-underscore names is explicitly documented as existing "to avoid name clashes of names with names defined by subclasses". The use case there is a parent class defines a method called, say, "foo". Other methods of the parent call self.foo(). Then a subclass overrides foo() but changes the signature (say, by adding a new non-optional argument), and doesn't override the other methods that call self.foo(). Without name mangling or something like it, this breaks. If the parent class either names the method "__foo" or aliases a copy of the parent class' implementation to "__foo", and calls self.__foo(), name mangling ensures those calls will find the right (as in, compatible) implementation of the method based on where the call came from.
That's it. That's the one and only use case for invoking name mangling in Python, and it's a thing that generally you shouldn't be doing anyway.
Name mangling also isn't invoked for leading + trailing double underscore -- a "__foo__()" method would not get mangled.
I was clarifying the difference between "everything is an object" as technically true and "everything is an object" as a commitment to semantic consistency. Probably because I'm still figuring out these ideas.
I don't disagree. I just think it's much worse than that. There is no scope in Python where I can define 'f' to allow '(3).f'. I cannot restrict a function to the domain of Integers using encapsulation. I am forced to put it in some other arbitrary namespace.
All this hate is justified, but not the conclusion.
The libraries available in Python, for everything touching data / scripting are just so powerful and well thought, that for many small projects, using Python is a no-brainer. The best thing is that those libraries are actually incredibly fast, while Python is supposedly slow.
The version problem is Python being a victim of its own success.
Since so many Linux distros used Python 2 for system scripting, you still have to have a Python 2 sitting around on your system somewhere.
Then people came along with "python3" and (yikes!) "pip3", but now you might have python 3.4, 3.5, 3.6 and 3.7. The transition was pretty painful because of the Unicode thing.
It does make it painful, though, to give people instructions on how to use Python-based software products.
I am converging towards the solution, however, of installing Python straight from the python web site with the appropriate version, hiding that Python somewhere where people won't mess with it, then working out of a venv.
Even though I have trouble with the implementation, I like the idea behind pypoetry. If it were me though, I'd put in a real SMT dependency solver because you don't need to download a whole wheel to get the dependencies, you just have to look at the ZIP directory at the tail of the file and you then grab the metadata file and leave the rest.
When kivy officially supports asyncio and they make it a little easier to install cross platform (e.g. brew was down for me over the weekend) that will be nice.
> I am converging towards the solution, however, of installing Python straight from the python web site with the appropriate version, hiding that Python somewhere where people won't mess with it, then working out of a venv.
Regarding reason 3 (syntax), I don't mind significant whitespace in itself, but it has knock-on effects which can be problematic. It's the direct cause of Python's `lambda` limitations [1], and IIRC the lack of an explicit end-of-block marker is also the reason for Python not having `do-while` loops.
However, what would be the alternative to significant indentation? I really don't think C-style syntax would work for Python...
That is problem with every single programming language out there.
- Python array are not called arrays because they are not array in C/C++ sense. It's like saying in C++ lists are called vector and not lists/ArrayList etc.
- Python library naming is inconsistent like PyGame, Numpy etc. Most of these mentioned libraries are third party libraries. How can a language enforce naming convention or documentation of a library?
- If you pick all softwares and libraries for all languages, you can't guess uses for most of them just by name. What are WireShark, TimeMachine, ReactJS, Boost, Armadillo etc?
I'm taking this article as a lesson in humility. It's really easy to concoct specious reasons for hating something, reasons you believe you've backed up with sound technical and philosophical arguments, but which are really just rationalizations for your failure to understand it.
Interesting points. I disagree with Reason 2 though. Python has smoother installation than Java and GCC.
One of the reasons Python is popular is because it's easy to do a lot of things. Some python choices don't make sense technically, but they were made to make python as easy as possible. Performance was never the first criteria of Python (or ruby). My personal peeve is with mandatory indentation. But again, that's the idiom the language has adopted.
I think the huge volume of 3rd party libraries that Javascript and Python have show that prioritizing developer experience over technical perfection leads to a more useful language. I hate Python's quirks but it's the first language I reach for if I'm just fetching data from an api or doing some web scraping. It's so fast and expressive that it makes up for the negative parts of the language.
>Python has smoother installation than Java and GCC
How so? With java you can get your distro version from the package manager or just download a tarball and setup your PATH. Maybe install maven. GCC and build deps is as simple as a xxx install build-essential/build-base and you have a C compiler for C89/C99/C11.
- The GIL (global interpreter lock), which can in some cases reduce your multicore CPU to a single core CPU.
- No multiline lambdas. You can't write a quick anonymous closure and pass it to another function, unless you manage to fit the whole thing in one line.
One of my biggest gripe is how python have a hidden non-declared agenda to have syntax as far from C as possible.
its really not giving language any usage benefits when you cannot use ternary expressions, ! as not, !=, increment operators.
Also, PEP8 is very very presriptive, you are disallowed to do violate any rule, even when if you need to to make the code better. (I feel shunned by the community for not liking 80 chars line hard breaks)
Python3 migration was not planned well - the lack of back and forward compatibility gave users a legit reason to stay with python 2 forever. I've seen some conference talks where end users/projects being shamed for not jumping on python3.
GIL in python is something that was talked about 5 years ago and will still be talked in 5 years. It limits the ability of python to reap the benefits of better hardware.
This may be minor, but I really missing ruby rich set of collection methods: take_while, group_by, sample. Yet I can see a point in extracting that to a external library.
Of course, all this does not mean python is not good. Builtin pip/venv, adrequate unicode in python3, some of fantastic libraries(numpy/scipy, bokeh) making it indispensable.
> GIL in python is something that was talked about 5 years ago and will still be talked in 5 years. It limits the ability of python to reap the benefits of better hardware.
It's also a huge source of misattributed problems — I've seen more cases where a complaint about the GIL was really “my algorithm depended on a single locked data structure” or “I was calling a C library which isn't thread-safe” than where the GIL was actually the limiting factor. That's not to say that there aren't real problems for people who want to run pure-Python computational code (not e.g. libraries like Numpy or Pillow) but it also seems to be popular as the bogeyman to blame when someone doesn't want to run a profiler.
> This may be minor, but I really missing ruby rich set of collection methods: take_while, group_by, sample. Yet I can see a point in extracting that to a external library.
IIt limits the ability of python to reap the benefits of better hardware
GIL sucks conceptually but I don't think it's massively limiting in terms of future hardware. E. G. I just discovered you can throw a bit of python into colab and do ML on Google provided K80 GPUs for free.
Two completely different things I know but to me that is a better indication of future proofness in a way.
The counter-argument is that in practice, most programmers use the indentation of the first non-whitespace character on each line to estimate lexical scopes, which is why removing all indenting drives most programmers wild.
I've seen several bugs in C++ and Java where colleagues have indented the code for the correct control flow, but misplaced the curly braces, resulting in incorrect flow. Granted, the two bugs that come to mind first are dangling-else problems that were fixed by inserting the optional braces.
I think that you and I both prefer auto-formatters to force indenting to match flow control. However, there's an argument to be made for actually enforcing it at the language level rather than at the tooling level.
* Versions and installation: Consider doing all dev work in a virtual env. It installs the correct python interpreter on your PATH, and installs pips in that isolated env.
> This worked great until I started on a second project that needed Python 3.6. Two concurrent projects with two different versions of Python -- no, that wasn't confusing.
Note that Java also comes in various version of the compiler and jvm, and its common to have several versions on the same system. They are backward compatible but forward compatibility issues exist: your main server app runs on java7 but your batch process is running java9. you might not want to make java9 the default on the system without formally upgrading the server app.
* Syntax/spaces : you get used to it. Hey some people write code in perl :)
* Includes: In principle, this works somewhat similar in Java: You use imports and the imported package hierarchy can nest quite deep so you need to look.
> The import function also allows users to rename the imported code. They basically define a custom namespace..
This can be a good thing, it helps you prevent name clashes. C++ also lets you do this, its called Namespace aliases.
> In every other language, arrays are called 'arrays'. In Python, they are called 'lists'.
Thats because it is a list. Nodes are dynamically allocated and appended to the list. You can expect similar algorithmic complexity for the operations.
> if I'm testing a screen capture program with a C library called "libscreencapture.so", i would call my program "screencapture.c" and compile into "screencapture.exe"
I've seen ELF executables with .exe suffices (as well as .run, .bin, no suffix, etc etc, I'm just waiting for someone to name one .com). This was done specifically to distinguish them from a directory of the same name.
A lot of these gripes are unfair and don't really matter IMO. I think complaining about things as trivial as syntax is really just scratching the surface and doesn't serve your conclusion.
A dictionary is an interchangeable word with hashmap in most situations. The string 'quirks' actually look to be pretty helpful.
Gripes I do actually agree with: the schism in versions, mutation from pass by ref (although this isn't different from JS, Java or any other OO lang). In my opinion you can add OOP in general to the list of gripes against python.
>By the same means, Python has distinct silos of code for each version. And the community keeps dragging along the old versions. So you end up with a lot of old, dead Python code that keeps getting dragged along because nobody wants to spend the time porting it to the latest version. As far as I can tell, nobody creates new code for Python2, but we drag it along because nobody's ported the needed code to Python3.x. At the official Python web site, their documentation is actively maintained and available for Python 2.7, 3.5, 3.6, and 3.7 -- because they can't decide to give up on the old code. Python is like the zombie of programming languages -- the dead just keep walking on.
I think I could make a comment on every one of this authors 'gripes' but I'll just do one for now.
Does this author think a minor version update should immediately EOL the previous version (3.5,3.6)? And obviously this author never heard that Python 2.7 is EOL 2020 [1]. But you know just reading this author's problems that if Python 2.7 had been EOL right after 3 released, or if a minor version upgrade immediately EOLs the previous minor versions (seriously, how is this a complaint?) he'd be posting about that instead of these 'which version do I choose' issues.
I just honestly can't believe a developer would complain about maintaining code for 'too long'.
> Does this author think a minor version update should immediately EOL the previous version (3.5,3.6)?
More likely the author thinks minor version updates should be backward compatible, like they are in virtually every other language? In most languages you'd be able to uninstall 3.5 when you installed 3.6, because you'd be confident that all your 3.5 code would keep working in 3.6.
Except... they mostly are? As far as I can tell, Debian only ships one Python per major version per release, Fedora does the same, Arch does the same. Gentoo lets you install everything side-by-side, but it does the same thing for gcc, binutils, ruby, wine, llvm, and dozens of other packages, and I don't see the author complaining about those.
Well, it sounds like this author's employer required their devs to use multiple minor versions at once:
> I was advised by one teammate that I needed to configure my environment so that everything uses the Python 3.5 base. This worked great until I started on a second project that needed Python 3.6.
Might be an issue specific to that company of course.
I think that whole paragraph he mixed up python 2 and 3.
>However, Python installs in separate installations. My code for Python 3.5 won't work with the Python 3.7 installation unless I intentionally port it to 3.7. Enough Linux developers have decided that porting isn't worth the effort, so Ubuntu installs with both Python2 and Python3 -- because they are needed by different core functions.
The way he just segways from talking about 3.5 to 3.7 seems really unnatural, I think he's talking more about from python 2 to 3, since that's what the second sentence is about. All code from 3.5 should work 3.7, unless they were using some undefined behavior of some sorts.
A quick google reveals python 3.6 is fully backwards compatible with 3.5, and 3.7 has only 2 exceptions. The words async and await are now reserved. So even if he did have a problem with this, any ide, or even just a find replace in a text editor, would be able to refactor the 3.5 code to work.
> All code from 3.5 should work 3.7, unless they were using some undefined behavior of some sorts.
Interesting; that certainly wasn't always the policy (e.g. I remember 2.4 -> 2.5 being a major, breaking upgrade) and maybe his employer never got the memo. If it's now the case that you can do fearless upgrades between minor versions then maybe that just needs to be better advertised.
Looks more like a proof Python is near-perfect to me. Because they've tried to write a list of what's wrong with Python and failed to name a single real problem/quirk you even have to know about. I've seen lists illustrating how JavaScript, PHP, C++ and other languages are bad and they all made me feel like "that's so crazy I will never code this language!" but this list for Python is just "pff... will you name a single thing that is not a minor inconvenience?".
The only thing that really annoys me about Python as a language (and it still is just an inconvenience and a matter of taste) is the file=module thing, I want to split a module into a number of files so I could define every class in a separate file without having to import every one from a separate module then, C# namespace model feels a way better. I would also love to see 1-st class support for type enforcing (i.e. if I define a "type hint" and a value fails to comply to it should raise a warning) and support for immutable variables (that can only be assigned once). Using 4 spaces per indentation level indeed sucks (I would prefer 2 spaces) but this is not a language problem and its seriousness is futlie.
> Inevitably, the discussion will turn to programming languages. One might lament "I have to modify some Java code. I hate Java. (Oh, sorry, Kyle.)" (It probably doesn't help that we gave Kyle the nickname "Java-boy" over a decade ago.)
This circle of "friends" sounds like a toxic environment where apologies are empty and contempt runs rampant.
Are they truly sorry for what they said, or are they sorry they said it to Kyle's face?
His early history of Perl is at odds with my memory. In my memory, perl was pretty great with not breaking old stuff. Even the pretty amazing feature set added between perl4->perl5 seemed a natural evolution to me.
I don't often use python nor do I know it well but it's obvious to me that several of these points are stupid, misinformed or wrong. Numbers 3, 5 and 8 are just nonsense whining. Number 7 is terribly wrong.
I find it incredibly surprising that this person got a Computer Science PhD while confusing Python lists with arrays and not knowing that pass by reference semantics is by no means niche.
I used to hate python because of of the lack of static typing. I realized the reason I hated it because of that, was due to other people's bad code. One of the nice things with compiled languages that are statically typed is that there's that nice check up front for types. I actually think you need to be a really good developer to properly use dynamically typed languages.
The one good thing with Python is that it is great at making beginners write readable code. I had nightmares about code written by scientists who certainly were experts in their fields, but their coding skills were limited to the bare minimum for running their calculations, once.
With python, not only their code is readable, but they also enjoy using it.
For more advanced programming however, it is a mess, and I understand the author. It limits your option so that there is basically only one way to do things (the opposite of Perl), it makes it annoying to write since even debug code needs to comply. But on the other hand, it gives you constructs that are very permissive. Pass by mutable reference is an example: there is no easy way to know what will happen to your arguments. You can completely modify just about anything so that even simple operations can do really weird stuff in the background. Flexibility is nice but it feels strange for a "clean" language to let you mess things up so deeply with very little safeguards.
Interesting to compare R on these specific pain points. I’m ignoring 5,6 & 8 because they are silly (you have to learn the language to use it at the end of the day).
1. Versions.
R gets updated quite frequently, and most users just update regularly. It is rare for there to be breaking changes. Packages often require the latest versions of R, so that is an issue.
2. Installation.
Well on linux distros R often has the same problem, you install R with the package manager and it isn’t clear which version it is. Some additional config is required to make sure you get the latest version. This is explained on the R core website. On windows and Mac, this isn’t an issue.
3. Syntax.
If you don’t like indents then R is your friend. The syntax is pretty flexible compared to python. For data science this is a plus in my book.
4. Includes.
In R, for larger projects the issue is dealt with by turning your code into a package, which is quite neat and tidy.
7. Pass by object reference.
R functions default to pass by value. You can still mess around with global state if you want to complicate your life.
I also rather strongly dislike Python (which tends to be a problem given that my employer's engineering team uses Python for everything, whereas I very much prefer to use the right tool for the job - which might be Python sometimes, but not often, let alone always). Whitespace-sensitive languages are - in my opinion - not at all user friendly, and the quirks around passing variables by object reference (like how you should never do "def foo(bar=[])" unless you want bar to equal [1,2,3] when you call foo() after having previously called foo([1,2,3])) make JavaScript look somewhat sane.
I will say, though, that I don't mind Python calling things lists and dicts. Those are indeed common terms (both are used in Erlang/Elixir), and reflect the fact that there are multiple possible implementations (lists might be arrays, linked, double-linked, etc., and dicts might be hash tables, keyword lists, etc.).
I agree with a number of these but I really don't understand #4. If you want to know what's in a module then 'import foo; help(foo)' in your interpreter will give you it. In C you can't just grep /usr/include because you might be importing form somewhere else.
And in C everything goes directly into your main namespace, the equivalent of 'form foo import *'. And even with single letter renames you can just quickly check at the top of the file for what the rename is, 'gg<c-o>' in vim and probably similarly easy in most people's editors. And really importing common libraries as single letters should be by convention in a codebase.
I really think that Python's import story is one of my favorite things about the language and it's something where I'm often comparing other languages to Python and finding that they're coming up short.
There's so much incidental design exposed to the user/library author because of python's import system ... Ultimately you have to step through a large list of questions in order to understand the actual import behavior -- its not easy and adds a large (pointless?) cognitive load for every library user/author ...
Are you import'ing a Module or a Package? If it is a package then maybe there's a magic file called __init__.py in a directory that might have an __all__ = [...] array or might just import some other modules but not contain an __all__ or it might import some names from some other modules. Or maybe there's a namespace package somewhere which has some behavior when there are directories that contain .py files but don't have an __init__.py (I honestly don't know the rules -- but I do know they can't be explained to me in a small number of words and that makes me insane!) ... And by the way -- every instance of 'import' used throughout your program is additionally beholden in its behavior to a global runtime magic state magic called the PYTHONPATH (that often has to get munged from the shell environment prior to invoking a python program ...) which is a list of path's that will be consulted/augmented differently depending on whether its a (module/package/namespace) import search to ultimately decide which set of files will be inspected ...
As a half-assed python developer (who is firmly in the 'I hate python camp') I honestly have very little idea how you are 'supposed' to use these mechanism when defining a package. I recently tried to figure out actual best practices so I could publish a small package -- I relied on lots of boilerplate copying from what seemed like knowledgable sources. I think I got something vaguely workable (https://github.com/breathe/NotebookScripter) but there's a lot of line noise all throughout the filesystem layout ... What is it about my Project name that python demands I should repeat it in the filesystem over and over and over again?
I believe this is actually the common pattern for laying out a small library ...:
- Special-snowflake, verbose ternary syntax (expr if cond else expr)
- (De)evolution of language features over time, such as format strings (from "%s" % val to "{}".format(val), and now to format strings f"{val"
- Poor design decisions all around, and stubborn in its refusal to admit wrong, such as the sudden but long overdue addition of assignment expressions
- Lack of control flow like switch statements, leading to data-structure abuse e.g. via dictionaries
The recent addition of assignment expressions provoked much discussion and much effort into its proposals, but, outside of Python's echo chamber, it's a language feature that most other languages have, and that should have just been included from the beginning. Instead, decades after the fact, the language is tacking on the syntax and pretending it's some genius new feature.
One note about point (2) dealing with the versions and the languages object oriented features. I noticed the object-oriented support has been tacked on, before Python 2.2 the objects had their own type which was accessed by .__class__. The tacked on nature of the OOP support of the language is perhaps why there are these __identifiers__ which are hard to type using consecutive letters, needing shift to be held down, are still used in the language. Although Python fixed the problem partially, it only did so only by adding new style classes along the old style ones in order to avoid breaking compatibility, which only complicated the issue. Unfortunately, Python 2.7 is still around. As this post mentions, Python 2.7 & 3 are both installed on Linux machines and the default is still Python 2.7 when you type python.
Actually, PyPI and PyPy are pronounced differently. The former is pronounced Pie-Pea-Eye, whereas the latter Pie-Pie.
"PyPI (Python Packaging Index): said aloud by using its full name, or by spelling out the last two letters, as in "Py-P-I". Alternatives are to abbreviate as the "Packaging Index", or to use the colloquial nickname "the Cheese Shop" (which refers to the name of a Monty Python's Flying Circus sketch). Referring to the packaging index aloud as "Py-Py" is strongly discouraged, as "PyPy" is the name of a popular alternative Python interpreter."
People hate on spacing, but people rarely talk about the benefits that specific spacing has.
Yeah, sure, you can complain about how strict it might be, and complain about how it can cause bugs when something is mis-indented.
But it's not like brace-languages are perfect either.
How about people who mix tabs & spaces within a single line because of lack of discipline or maybe a mistake from refactoring code? Imagine that nightmare of rereading that based on what editor you use.
Missing braces can sometimes be annoying and difficult to find, and placing the brace in the wrong place can result in bad code. Isn't that equivalent to a lingering whitespace in Python?
Yeah sure, you might say "Once you code enough, that usually doesn't happen" But Pythonistas can say the same thing with their indentation.
It's just a different way of programming. Get over it.
The more serious issue with significant white space is that it makes writing code formatting tools like Prettier impossible. That’s too much to give up to avoid having to write an extra brace or two IMO.
About 1/4 are valid, important criticisms, another 1/4 are technically true but quite trivial (and are mostly caused by his very idiosyncratic coding habits), and 1/2 are just howlingly wrong, mostly in that order. A decent chunk of the actually correct ones seems to boil down to "C does it differently", which well...if that's you're yard stick, you're going to be pretty busy criticising other languages.
I've got to call out his point 7 in particular; it's so wrong it kind of makes me wonder what he was trying to say. He's calling out Python for not following a convention that doesn't exist, nobody else follows, couldn't even work, and which you wouldn't even want. What in the world?
Point 7 is only relevant because it leads to behavior that's not intuitively obvious. If you reassign an object in a function then it's not visible outside the function, but if you modify the object it is. That's a very subtle distinction.
For one and two: in what world is any of the software in repos like apt or yum up to date?
Every time I set up an ubuntu machine for using at work, I end up compiling a few packages from source, a myriad of packages that are installed from app images or curl | bash installed binaries (like docker, ugh), and more PPA's than I care to keep track of and clean out. And now there's flatpack, snapcraft... packaging on linux is a mess currently.
Honestly, on workstations the rolling release model is the only one that makes sense.
But for python, with tools like pyenv, virtualenv, or even just using LXC/docker/vagrant/whatever, versions in the 3.5-3.7 range are a non-issue.
I agree the quotes thing sucks, though. I wish there was more enforced discipline on that.
I can only agree to his hate of spaces. I personally hate space based languages. It only brings annoying problems and you have to care for things (spaces/tabs) that you shouldn't have to care about in the first place. {}'s -> Love.
I don't think the author of TFA makes the case he's trying to make at all. And mind you, Python isn't my first or favorite language, and I'm not particularly biased in terms of defending Python. My language of choice is Groovy in most contexts.
Anyway, this all seems like a lot of nit-picking to me. Yes, these "issues" are real, they just don't amount to much. And basically every other language has an equally long list of similar nits you could pick.
If the author had called this "Reasons Python Sometimes Annoys Me" then I could get behind that. But none of this, IMO, reaches of the bar of establishing that the language "sucks".
Right, Python is better than most in terms of nitpick-ability. It's one of the only mainstream languages to make it big without corporate support due to that.
Though it's an opinion piece and I don't agree with all the points, some I do. The readability issue is real when dealing with any code more than a hundred line, and worse the convention seems to encourage using empty lines very sparingly.
The shortcomings came out clearer as I've been teaching someone to program in Python. The subtlety of per-scope indentation really confused her. The concept of a "block" is just not visually clear. Not to mention mixing spaces and tabs by accident. That could halt a new programmer for an hour.
The random complaint about Perl version compatibility was particularly bizarre. There was really no incompatibility between Perl 3 and 4. Then I guess all those people got fed up and quit using Perl when they made the next version and it was left in, what? a 15 year glory period where several orders of magnitude more software was written with it?
Talking about how there's very little new software written in Perl now is definitely using post-hoc reasoning. There's probably a language named after a British comedy troupe that is somewhat responsible.
I can't believe this was upvoted. These aren't reasons that Python sucks, they're nitpicks from a guy who has decided long ago that he knows what he likes and refuses to try anything else.
> "If I have the choice between using some pre-existing Python code or rewriting it in C, I'd rather rewrite it in C."
I should have stopped reading there, because this shows just how set the author is in his ways. Both languages have a place, and if I'm writing a web scraper, you can bet your ass it's not going to be in C.
>The Python manual says that you can use any number of spaces or tabs for defining the scope.
But it doesn't. In Python only modules, classes and functions make a new scope. A block doesn't. (And that's because it "forces" you to write small self-contained functions.)
It's funny that he also links to a documentation page that clearly doesn't talk about scope at all.
Personal reflection: I rarely rant publicly about something, but when I do I make sure that I'm not saying something stupid that a quick google search can refute.
As a python newbie, I've had some trouble with the unstable async API (many differences between 3.6 and 3.7 and within minor versions of 3.7). Many ways of accomplishing the same goal with slightly different side effects are off-putting.
Another problem is packages. Authors don't really care about fixing dependency versions (had trouble with celery, quart and redis so far) we have much less trouble with node in this respect.
plus sides are: vs code has been amazing. pipenv is almost good enough. Community is great.
> And Python? It uses spaces. If you need to define a scope for complex code, then you indent the next few lines. The scope ends when the indent ends.
Curiously, I never see the indent scope complaint about, say, Haskell. It's always just Python. I've wondered for a long time why that is. There's the obvious one, that Python is just far more popular, but I'd expect experienced people to have used or at least seen another language that does it.
No idea if this is true, but my gut feeling is Python is commonly written in an imperative style, whereas Haskell is more functionally written. Imperative style (especially at the beginner level) tends to include lots of nested conditionals which quickly create this indentation triangle of confusion.
As far as I can tell, nobody creates new code for PostgreSQL 9, but we drag it along because nobody's ported the needed code to PostgreSQL 11. At the official PostgreSQL web site, their documentation is actively maintained and available for PostgreSQL 9.4, 9.5, 9.6, 10.6, and 11.1 -- because they can't decide to give up on the old code. PostgreSQL is like the zombie of relational databases -- the dead just keep walking on.
> because someone thinks recursive acronyms are still funny
Not that I was expecting depth from a site called "hackerfactor" by a guy who wrote something like "open source sucks", but seriously, this middle school level "sass" (and about a popular practice at that) shouldn't be near tech writing.
Should have stopped reading there. On that note, this has way too many upvotes for such a misinformed, badly written, sophomoric piece.
Python: something you can't see causes significant change in program behavior.
Go: Something you see ends up as a compiler error.
Oft heard is the bellyaching cries of the proponents that try to conflate these two things, but they are not the same thing. One results in bugs, the other can be bypassed. Most languages opt for the second. (With Java for instance, most shops have a checkstyle gate in their build process).
I agree with a lot of these points. To get around them I created https://github.com/c11z/python-mk which is a make file that contains the seed of a python development environment. It uses docker containers to get around most of the issues this article brings up.
I tend to agree with the author (although not with a few of his specific reasons) that Python is terrible. Everywhere I've ever been that used Python they've claimed it was to make development faster, but mostly we just fought with bugs that cropped up around tests that were too aggressively mocked and weren't testing things, or stuff that somehow was in the wrong scope because someones editor was using the wrong type of whitespace, etc. And don't get me started how on every single code review I had to force people to write unit tests that wouldn't have to exist if there was a static type system to effectively be those tests for us.
That being said, if your alternative is C or PHP suck it up and stick with Python. There is no situation in which PHP is the appropriate tool for the job, and as simple as C is and as much as I love it you're much more likely to introduce weird bugs and create broken software if you're using C. Python at least has some basic memory safety, even if its tooling and versioning is all horribly broken. As a user of software (and also a devloper): please stop writing things in C and related languages, if I keep seeing segfaults in popular products with huge QA teams behind them, I'm going to go insane.
Wanted to second that the author mentions C as being "simpler" alternative -- doesn't make much sense as it is quite a "footgun" it itself. I'd much rather search for missing indents in Python than debug segfaults in C. Also, package managers are almost not a thing in C land. Did OP try Rust -- that may check quite a few of his boxes...
Re: There is no situation in which PHP is the appropriate tool for the job...
While clunky as a language, PHP's "environment" is better if you are doing web apps. Easier to install, including a test setup, more web-oriented libraries and functions, and a built-in HTML templating language for "view" pages (per MVC).
If your stack is designed right, you'll be spending most your time plugging in parameters to API's such that the language itself won't make a whole lot of difference. You should be mostly gluing libraries, not writing an OS from scratch. If I were doing the second, then Python would be the better choice.
If you're doing web dev it just makes it easier to write crap. I am also utterly sick of pentesting every garbage website written in PHP and finding dozens of easily avoidable bugs that always boil down to PHP being terrible at what it does. It may be easy to use, but that's no excuse to use it and write bad software.
It doesn't matter that PHP has wised up about security; I've seen modern PHP too, the language is still a mess and encourages bad practices and bad engineering.
There certainly are some drawbacks to using Python versus another language like C (I’m thinking of the GIL in Python 3 specifically), but I’ve yet to find a better language with which I can prototype reasonably complex applications in the space of an afternoon...even GUI apps with Qt.
> In contrast, many Python modules include initialization functions that run during the import.
I just thought it's a natural consequence of a dynamic languge. Defining a class IS running code - you can even decide to define or not to define something based on a runtime random roll.
I thought I was the only one to put debug code in the first column. (The code doesn't last long; generally debug code in the first column is expected to be removed very soon; debug code that lasts longer goes in its proper column.)
C and its standard library have some consistency and C89 code mostly runs on future versions of the spec (provided they don't use something like _Bool). But the idea that you don't run into version hell in C is crazy.
At the end of the day the thing that makes Python the best programming language is not actually the language itself, which has a lot going for it, but the community around it. The python community is the full of extremely good programmers, and there is a vast ecosystem of first class resources that are available for everyone.
Yes, these are all valid points, and I laughed. Holding up javascript (npm anyone?) as some kind of counter example that proves python is bad may have held some un-intentional humor as well. Don't get me wrong, I love js but it seems to me like if you took these same 8 points and made them about javascript it would be 100 times more damning.
Heck, I am even willing to count this great article itself as a reason to love the python community even more. Someone who hates python so much must do so from a place of extreme love.
You are right! Any language has its disadvantages. Btw, I'm very interested in which programing language you're using mainly? Would you like to share with us? Thanks in advance ^_^
I feel like it's sadly telling that such a poorly written article has managed to sucker at least 175 HNers into up-voting it (assuming that's how the score system works).
My take on this is that it has some valid points, but is mostly unjustified rants:
1. Versions: Definitely an issue with Python, the v2 to v3 split was a huge mess and is Python's biggest issue IMO.
2. Installation: Pros and cons, what I find is that Python tends to be easy to set up, but that it does it automagically for you via pip, which means if you run into trouble it is harder than doing it manually
3. Syntax: Python's syntax is wonderful and I find these arguments mostly flawed. The space vs tabs wars are the exception and a valid criticism that the language doesn't force one or the other. As someone on the tab side, I don't run into his issue at all of accidentally putting 3 spaces instead of 4 in, but then I do run the issue of going against the language's grain so to speak.
On the other hand, his issue about deep nesting is a problem in any programming language - unless he is not indenting properly when he wants to, which is my guess. If that is the case, that will cause severe issues when anyone else tries to read it! Debug code without indents also sounds like a bad idea to me. And even if you aren't a fan of Python's whitespace, I find that there are other features, such as using words instead of symbols (and, or, not instead of &&, ||, !) that definitely make Python one of the most readable languages out there.
4. Includes: I'm mixed on this one. On the one hand, I don't understand the first half of what he is saying, I have to go track down includes in any language. In Python at least I only have to deal with one include, whereas in C and C++ I have to go track down two, the header include and the actual library. This mostly seems to be complaining for the sake of complaining.
The last bit I personally agree with though. I once worked on a project that would analyze other people's Python code. At first Python seemed to do this extremely well as it can take any Python code and change it into its abstract syntax tree for further analysis. However, I soon found that in order to do this, it would have to execute any global code while it was reading it! I'm definitely not a fan of how Python technically runs anything it imports.
5. Nomenclature: Definitely unfair criticisms here. First, Python's lists aren't arrays but are lists! Arrays are blocks of unchanging memory, whereas lists are a structure that under the hood points to an array, but that array can be deleted and reallocated to resize it. I admit, I've never liked Python's word for dictionaries, but I don't like hash either, I think map is the better term, but it's still just a single name of a concept, not a huge deal. His arguments about the names of libraries are stupid, they are third party libraries that Python doesn't even control! And as someone who is very picky about function and variable names, a library name hardly ever matters, especially as Python allows you to rename imported modules.
6. Quirks: I don't even understand what his complaint is here. Does needing to triple quote multi-line strings really bother him that much? The binary and raw syntax might be a bit confusing, but I'll take that any day over C++'s L"" for wide strings and _T() for strings that may be wide or not and are determined at compile time. The string vs unicode is a bit confusing, I'll give him that, but I think the entire concept is confusing in any language.
7. Pass by object reference: I actually completely agree with him here, though I don't know how Python would fix this. I think I can explain it better than he does though. The issue is that if you create a list "list1" and then set "list2 = list1", and then append the element "3" to list2, list 1 changes as well even though list1 was never directly changed. This was one of the biggest things I struggled with in Python until I learned C++ better which taught me how Python was working under the hood. Python makes you think that it doesn't have pointers, but the truth is that everything in Python is a pointer, which I found confusing relative to how everything else in Python was beginner friendly.
8. Local names: I don't really understand his complaint here, don't shadow names.
A great example of how Trump has been elected. He lied a lot, (or said stupid things because he was ignorant in a topic) but it doesn't matter, because rebuttal takes a bit more effort than saying stupid things so what he said stuck with a lot of people. Sorry, but this article is just ignorant in almost every point.
> A great example of how Trump has been elected. He lied a lot, (or said stupid things because he was ignorant in a topic) but it doesn't matter
A number of the people with federal felony convictions, some having already gotten federal prison sentences to go with them, for their role in supporting Trump's dishonesty might quibble with the “doesn’t matter” characterization.
While I agree with the author's reasons why Python sucks ass, he's wrong about Commodore but thinks that he isn't:
"Where's Commodore today? It died out as users abandoned the platform."
No. Commodore died because Irving Gould told Tramiel to pack his bags and go when Tramiel told him it wasn't okay to use company's assets like the jet as personal property. Once Tramiel was fired, the company was plagued by chaos and mismanagement, but it had nothing to do with how bad or good Commodore's computers were. It's the 21st century and people still write fresh software and design modern hardware for Commodore computers, so they've never been abandoned.
Loud title for an article from a person who has little to none experience with real life programming (imho). Talking about passing objects as a copy or by reference looked plain retarded even, he barely understands what are advantages or disadvantages of both methods.
When I went down to reason 8 I was already utterly disappointed and felt like my time was wasted on a ramblings of 13yrs old that wrote "hello world" in 2-3 different scrypt languages and already thinks of himself an expert and a _hacker_ (that's even in the website title).
Too bad it is a senior citizen that some people might have actually listened to and think he know what's he is saying.
I want to get a vote on indented nested blocks- how many of you like them? Please up the appropriate child comments (if I'm rate limited someone else please make child comments with like and unlike).
My reasoning (please give yours below proper heading)- I'm deadly afraid of refactoring or even accidental indentation change.
the self argument for methods/method calls is stressful (having to define self for methods and having to call a method via self); also the fact that you need to check if dictionary key exists, else you get an exception when trying to get the keys value.
Also ':' at the end of each line.
I always forget at least one of these.
You didn't have any of these goodies in good old perl (sob, sob)
(wow, this one got flagged pretty quickly, wonder why)
"also the fact that you need to check if dictionary key exists, else you get an exception when trying to get the keys value."
dictionary.get(...) is specifically for avoiding the exception, you should just get None if the key doesn't exist. Unless I'm misunderstanding you and your complaint lies elsewhere.
Don't get me wrong, there are plenty of things that are stupid/annoying with python, this comment however reads more like "python is bad because I can't write perl in it". I think that's why people are flagging it.
Idk, maybe because your arguments are bit shallow?
I like 'self'. There's a lot to complain about magical 'this' of every other language - especially in Javascript. Specifying self makes it really clear if it's a member method or a standalone function.
Python really likes the idea of 'seek forgiveness, not permission', aka. abusing try/except. But it's kind of nice:
# seek permission
if 'key' in map:
fn(map['key'])
else:
whatever()
# seek forgiveness
try:
fn(map['key'])
except KeyError:
whatever()
Just pray that 'fn()' doesn't also throw a KeyError.
you need to check if dictionary key exists, else you get an exception when trying to get the keys value.
What should be the correct behavior when accessing a key that doesn't exists? If you want a specific default value when a key doesn't exist you can use the get() method.
Also ':' at the end of each line.
What do you mean? You don't need ':' at the end of each line, only at the start of a block (basically anywhere you'd use a '{' in other languages).
It's been a while since I touched Python (thankfully), but there's also:
- The hideous __method__ and _private conventions
- A friend of mine was complaining about the implicit string concatenation: ["foo" "bar", "baz"] whoops forgot a comma and now there's a very hard to find bug
- pyc and pyo files littering the filesystem after running (yes, only a minor nuisance)
- import anywhere, the ugly __name__ = "main" hack
- GIL, reference counting GC, abysmal performance in general
- Dynamic typing, which is probably my most major complaint but I realize opinions differ
C and many other languages had that before Python, and it’s very useful to be able to split a single string over many lines in your source code. Python very wisely also implemented this feature.
> - pyc and pyo files littering the filesystem after running
You don't have to define 'self' in Perl code, but you should. You don't have to check if a key in a dict exists, but you should. Not doing these things, and the crappy code that results, are part of why people make fun of Perl.
$ cat > foo.pl <<EOF
use strict; use warnings;
{ package Foo;
sub new { my $class = shift; bless {}, $class }
sub method {
my $self = shift;
$self->{"hash"} = { "thng1" => shift };
my $key = $self->{"hash"}->{"thing1"};
$self->increment($key);
}
sub increment { $_[1] + 1 }
}
my $count = Foo->new()->method(33);
print "count: $count\n";
EOF
$ perl foo.pl && echo "Program succeeded"
Use of uninitialized value $_[1] in addition (+) at foo.pl line 12.
count: 1
Program succeeded
The debugger is telling us about an uninitialized variable in Foo::increment(), but the bug is really a missing dict key in Foo::method() due to a typo. We never checked if it existed, Perl didn't care either way, and the program didn't even fail. In code that's more than a page long, good luck spotting that...
I didn't downvote you, but you present complaints without support or putting forward alternatives other than everyone should ditch Python in favor of Perl. 2 of your 3 complaints come across as shallow syntactic bikeshedding presented without support.
It would be interesting to read your take on the engineering problems involved, the design tradeoffs involved, and why you think Perl's decisions are more appropriate than Python's decisions, even for Python's main use cases.
Python rubbed me the wrong way when I first encountered it, then I really loved it for a few years. Now, I feel it's pretty good at what it does, but I find other languages more interesting.
Maybe you have some good reasoning behind your gripes, but you don't provide any evidence that you've thought much about them or put any effort into understanding the design decisions.
For your first complaint, I do agree that the explicit self parameter vs just making it a keyword is hard to justify in retrospect, but is it really raising your blood pressure, causing you to lose sleep, etc? Your use of hyperbole doesn't help your case.
I presume that making all method calls explicit is to keep scoping sane in the case where a subclass defines a method that happens to accidentally conflict with the name of a function called in some superclass's method. An alternative would be to use static name resolution to resolve the ambiguity, but then you'd have to be statically invoking metaclasses to figure out which methods were in scope, or you'd have to get rid of metaclasses and generally get rid of a bunch of the effort Python goes through to be very late-binding and generally dynamic in behavior.
For your second complaint, if you don't want the dict to throw, use the get method instead of the brackets operator.
For your third complaint, I'm not sure exactly what you're complaining about. Clearly not every line literally ends with a colon, and you're again making poor use of hyperbole. Guido has commented in at least one interview that most of the colon's aren't necessary to disambiguate the grammar, but they really do help beginners in particular read the code.
Showing more effort toward educating and/or convincing people would help avoid the downvotes.
> It would be interesting to read your take on the engineering problems involved, the design tradeoffs
self - the reason is that I forget to type it and causes me to go back and fix the method signature or method call (there are usually lots of them in the code, so lots of opportunities to forget self - hence lots of instances where it can be omitted so that it must be fixed, at least for me; the remark is a gripe about ergonomics of syntax)
The alternative: do a different keyword for method definitions other than def; (well, still you need something to differentiate between method invocation and global function call in an untyped language)
: at the end of function definition or a block - same thing.
KeyError if dict entry not found; most other languages I know would return None, so that's counter intuitive to me (I know about get, but [ ] is the default syntax for accessing dictionaries in most languages)
I know it will cause an undefined method call to bomb, which is a good thing in my book; but I don't like it for data structure access - I also don't like exception handling in particular and prefer explicit checking of results (again matter of taste and habit + frequent cause to go back and fix it)
I think python is making several tradeoffs in favor of making the resulting script more robust (like going for exception handling) but it makes the experience of writing said script a bit more tricky.
1 (versions) and 2 (installation) have to do with the ecosystem, not the language. Unsigned packages are a real problem, but hating on community-maintained software is just weird. Most software in your local Linux distro's repository is maintained by a "community" that might just be one person working in their spare time.
3 (syntax) seems to be about not supporting the author's own highly idiosyncratic habits, which include deep nesting and putting debug code in the first column (ugh). The result actually seems better for maintainability than the author's own unconstrained code would be.
4 (includes) is in the "exactly wrong" category. Includes as in C/C++ are a horrible way to handle module interfaces. Really, just about the worst option available. Modules are far better, and if the author hates the fact that importing a module might run initialization code wait until s/he finds out about constructors (including __init__ and __attribute__((constructor)) even in C).
5 (nomenclature) is also a bit insane. Lists aren't called arrays in Python because they're not arrays. Next!
6 (quirks) criticizes quote handling in Python, but mentions bash's quote handling without a word of comment about how that's even worse. Different languages have different quoting conventions. Python's might not be perfect, but many are far worse. Get over it.
7 (pass by reference) is another totally-wrong one. Passing by value is not the universal norm in other languages, and it's not even clear what it means sometimes because of deep vs. shallow copies. Passing by reference is almost certainly better for efficiency, and often for correctness as well when copies becoming inconsistent with each other is a concern. I'd rather have pass-by-reference as the default, and have to work to make copies, than the other way around.
8 (local names) barely even make sense. Shadowing names, whether of variables or of modules/libraries, is a bad idea anyway. If you want the library and the program not to have the same name, use a prefix for each role. Expecting the language to handle this for you is just asking for trouble.