Reasons Python Sucks • Hacker News Board

Re: Reasons Python Sucks

#281

Post by turlando » Tue, Dec 18, 2018, 8:00 PM UTC

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

Re: Reasons Python Sucks

#282

Post by szatkus » Tue, Dec 18, 2018, 8:03 PM UTC

civility wrote: post #244

blattimwind wrote: post #226

Earlier quoted context omitted.

> , but it's never pass-by-value like Java primitive types That's because this class of types doesn't exist in Python.

I'm not sure what your point is...

Primitive types in Java are special. Like you have boolean and Boolean. You can't invoke methods on primitive types.

I think there were plans to change it in future versions of Java.

Re: Reasons Python Sucks

#283

Post by jdblair » Tue, Dec 18, 2018, 8:07 PM UTC

notacoward wrote: post #96

b_tterc_p wrote: post #80

Earlier quoted context omitted.

Care to explain? I’m not sure where this would work without fundamentally changing the meaning of the code

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

That correct. It was a case of nested loops and some code that was in the wrong loop.

Braces are most definitely not whitespace, even if they serve the same function as whitespace in Python.

Re: Reasons Python Sucks

#284

Post by acdha » Tue, Dec 18, 2018, 8:07 PM UTC

altmind wrote: post #182

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…

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

See https://docs.python.org/3/library/itertools.html and https://docs.python.org/3/library/random.html for the sample function. I believe the difference is mostly that the Ruby methods are on Array but the Python ones are seen as processors for iterables so they're in a separate part of the standard library.

Re: Reasons Python Sucks

#285

Post by kekeblom » Tue, Dec 18, 2018, 8:08 PM UTC

The thing that actually sucks is in python is parallelism.

Re: Reasons Python Sucks

#286

Post by mindcrime » Tue, Dec 18, 2018, 8:09 PM UTC

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

Re: Reasons Python Sucks

#287

Post by berdon » Tue, Dec 18, 2018, 8:10 PM UTC

ArchTypical wrote: post #259

berdon wrote: post #46

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

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

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.

Re: Reasons Python Sucks

#288

Post by Symmetry » Tue, Dec 18, 2018, 8:10 PM UTC

newen wrote: post #93

Symmetry wrote: post #43

Earlier quoted context omitted.

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…

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.

Re: Reasons Python Sucks

#289

Post by mixmastamyk » Tue, Dec 18, 2018, 8:12 PM UTC

mikestew wrote: post #135

Hello71 wrote: post #101

Earlier quoted context omitted.

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

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

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.

Re: Reasons Python Sucks

#290

Post by ApolloFortyNine » Tue, Dec 18, 2018, 8:12 PM UTC

lmm wrote: post #158

Hello71 wrote: post #112

Earlier quoted context omitted.

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.

>https://docs.python.org/3/whatsnew/3.7.html