Reasons Python Sucks • Hacker News Board

Re: Reasons Python Sucks

#411

Post by stochastic_monk » Tue, Dec 18, 2018, 11:23 PM UTC

notacoward wrote: post #70

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

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.

Re: Reasons Python Sucks

#412

Post by mixmastamyk » Tue, Dec 18, 2018, 11:27 PM UTC

compiler-guy wrote: post #407

mixmastamyk wrote: post #268

Earlier quoted context omitted.

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.

The important issue is which solution is the best given the trade offs. Acceptance of nothing less than a flawless one is not a path forward.

Re: Reasons Python Sucks

#413

Post by Gatsky » Tue, Dec 18, 2018, 11:28 PM UTC

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.

Re: Reasons Python Sucks

#414

Post by noobermin » Tue, Dec 18, 2018, 11:31 PM UTC

jMyles wrote: post #146

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

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.

Re: Reasons Python Sucks

#415

Post by pfranz » Tue, Dec 18, 2018, 11:32 PM UTC

Karunamon wrote: post #367

pfranz wrote: post #265

Earlier quoted context omitted.

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.

It depends on your definition of "deep". 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 a…

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.

Re: Reasons Python Sucks

#416

Post by Zopieux » Tue, Dec 18, 2018, 11:35 PM UTC

nicoburns wrote: post #133

fhood wrote: post #100

Earlier quoted context omitted.

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

Indeed. My personal bugbear is lack of multiline lambdas. I use these all the freaking time in JS and it's infuriating that I can't in python. At the end of the day it's a minor complaint of course.

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.

Re: Reasons Python Sucks

#417

Post by jhuni » Tue, Dec 18, 2018, 11:36 PM UTC

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.

Re: Reasons Python Sucks

#418

Post by compiler-guy » Tue, Dec 18, 2018, 11:36 PM UTC

mixmastamyk wrote: post #412

compiler-guy wrote: post #407

Earlier quoted context omitted.

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.

The important issue is which solution is the best given the trade offs. Acceptance of nothing less than a flawless one is not a path forward.

Sold! As long as you admit that there is a problem and tradeoffs, then I'm fine with where this conversation is ending.

Re: Reasons Python Sucks

#419

Post by raldi » Tue, Dec 18, 2018, 11:42 PM UTC

One more for the list, and my all-time most hated Python annoyance: No equivalent of Perl's "use strict vars". In other words...

    blah = 1
    if foo:
      balh = 2
    print blah

...doesn't let me know I've made a typo the way the equivalent Perl would:

    my $blah = 1;
    if ($foo)
      $balh = 2;
    print $blah;

Which outputs the following even without "use strict vars":

    Name "main::balh" used only once: possible typo

And if you turn that on (like all Perl programmers have, in all their programs, for decades):

    Global symbol "$balh" requires explicit package name

Re: Reasons Python Sucks

#420

Post by mixmastamyk » Tue, Dec 18, 2018, 11:46 PM UTC

compiler-guy wrote: post #418

mixmastamyk wrote: post #412

Earlier quoted context omitted.

The important issue is which solution is the best given the trade offs. Acceptance of nothing less than a flawless one is not a path forward.

Sold! As long as you admit that there is a problem and tradeoffs, then I'm fine with where this conversation is ending.

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.