Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reasons Python Sucks

hackerfactor.com

Post reply on HN
Print view View original

371–380 of 554 posts

Re: Reasons Python Sucks

#371

Post by honkycat »

icedchai wrote: post #320
honkycat wrote: post #85

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 have used pipenv, virtualenv, pip, poetry, xyz. I still have consistent problems with package versions and the like.

I like the library `invoke` for scripting A LOT, I just prefer to write my larger software in other languages.

Re: Reasons Python Sucks

#372

Post by alexchamberlain »

sam0x17 wrote: post #221
blattimwind wrote: post #219

Earlier quoted context omitted.

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 l…

Generally, yes, but in Python, no; there are at least 2 good ecosystems.

Re: Reasons Python Sucks

#373

Post by lolc »

com2kid wrote: post #311
srfilipek wrote: post #274

Earlier quoted context omitted.

That one dumbfounded me as well. 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.

> Has the author never given a pointer as an argument to a function before? Possibly not, many devs now-days have never used a real native language.

Weird though when the author mentions the desire to rewrite Python functions in C.

The whole section about references was very confused. Especially for someone who supposedly knows C.

Re: Reasons Python Sucks

#374

Post by coryfklein »

cleandreams wrote: post #243

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…

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.

Re: Reasons Python Sucks

#375

Post by twunde »

_ea1k wrote: post #206
013a wrote: post #119

Earlier quoted context omitted.

> 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 ec…

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 real…

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.

Re: Reasons Python Sucks

#376

Post by SSLy »

sam0x17 wrote: post #235
blattimwind wrote: post #222

Earlier quoted context omitted.

> 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.

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 A…

https://github.com/NixOS/nix

Re: Reasons Python Sucks

#377

Post by orf »

mdemare wrote: post #305
mherrmann wrote: post #92

> 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…

Tensorflow doesn’t run on 3.7, only 3.6 (and 2.7). That’s a pretty major library.

  python3.7 -m pip install --upgrade https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-0.12.0-py3-none-any.whl
  wget https://raw.githubusercontent.com/aymericdamien/TensorFlow-Examples/master/examples/1_Introduction/helloworld.py
  python3.7 helloword.py
Tensorflow 0.12, released over two years (before 3.7 development had even started) runs fine.

Re: Reasons Python Sucks

#378

Post by maemilius »

jMyles wrote: post #365
mangodrunk wrote: post #363

Earlier quoted context omitted.

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 y…

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.

Re: Reasons Python Sucks

#379

Post by brudgers »

bakery2k wrote: post #334
brudgers wrote: post #234

Earlier quoted context omitted.

Some methods but not others. Specifically, I can call built-in methods, but not methods I define. For example: >>> def f(self): ... return self ... >>> (3).f Traceback (most recent call last): File " ", line 1, in AttributeError: 'int' object has no attribute 'f'

Your `f` is not a method, but a top-level function whose first parameter happens to be named `self`. You can't call `f` as a method of any object, because in Python (unlike Ruby) the top-level namespace is unrelated to the namespaces of any classes.

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.

Re: Reasons Python Sucks

#380

Post by pdonis »

arduinomancer wrote: post #190
pdonis wrote: post #117

Earlier quoted context omitted.

> They pass by pointer-value. 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 is a namespace binding? Can you explain at a low level what that means?

Compare a variable assignment in C and Python.

In C:

  int i = 17;
Means "set aside one int's worth of storage and fill it with the bit pattern for the number 17".

In Python:

  i = 17
means "create an int object with the value 17 and bind it in the current namespace dictionary to the name i".
Post reply on HN