News for hackers. Stuff that matters.
Re:Reasons Python Sucks by com2kid on Tuesday December 18, 2018 @12:34PM (#18708528)
#7 is so very wrong in so many ways.

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.

Re:Reasons Python Sucks by srfilipek on Tuesday December 18, 2018 @02:50PM (#18709881)
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.

Re:Reasons Python Sucks by triMichael on Tuesday December 18, 2018 @03:30PM (#18710254)
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.

Re:Reasons Python Sucks by notdonspaulding on Tuesday December 18, 2018 @03:56PM (#18710464)
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:

https://nedbatchelder.com/text/names1.html

Re:Reasons Python Sucks by EricE on Tuesday December 18, 2018 @11:22PM (#18712990)
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.

What a small world...

Re:Reasons Python Sucks by com2kid on Tuesday December 18, 2018 @03:30PM (#18710255)
> 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.

Re:Reasons Python Sucks by lolc on Tuesday December 18, 2018 @05:27PM (#18711193)
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 by kyralis on Tuesday December 18, 2018 @11:01PM (#18712896)
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.

Re:Reasons Python Sucks by taejo on Wednesday December 19, 2018 @05:53AM (#18714768)
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`).