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

141–150 of 554 posts

Re: Reasons Python Sucks

#141

Post by porpoisely »

graycrow wrote: post #62
porpoisely wrote: post #33

Earlier quoted context omitted.

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

Yes, but for a reference types that value IS a reference, so if you change a complex type, that change will persist after return to the calling code.

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.

Re: Reasons Python Sucks

#142

Post by tom_mellior »

pdonis wrote: post #111
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…

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

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

Re: Reasons Python Sucks

#143

Post by michaelt »

brudgers wrote: post #115
CurtHagenlocher wrote: post #3

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…

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

  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.

Re: Reasons Python Sucks

#144

Post by KMag »

booleandilemma wrote: post #4

I feel like Python is a case of the emperor’s new clothes. In this case the emperor has no visible scope delimiters.

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.

Re: Reasons Python Sucks

#145

Post by setpatchaddress »

fhood wrote: post #100
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…

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…

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.

Re: Reasons Python Sucks

#146

Post by jMyles »

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.

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

Re: Reasons Python Sucks

#147

Post by brudgers »

markbnj wrote: post #109

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

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:

   3.fizzbuzz # returns "fizz"
   5.fizzbuzz # returns "buzz"
   7.fizzbuzz # returns 7
  15.fizzbuzz # returns "fizzbuzz"
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.

Re: Reasons Python Sucks

#148

Post by p10_user »

diminoten wrote: post #88
qntty wrote: post #59

Earlier quoted context omitted.

Is python really meant to be a beginner-friendly language? I tend to think of it as lisp-without-parens, and lisp is not very beginner friendly.

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

What would you consider a beginner language then?

Re: Reasons Python Sucks

#150

Post by PaulHoule »

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.

Post reply on HN