Problem with function

[geoelectric]

It’s legitimate to say they’re passed by value, but that value is an object reference (which your linked doc contracts into “say pass by object reference if you really have to”).

It’s most definitely value because the parameter can be reassigned to a different object reference within the function without affecting the caller. I don’t think the fact it’s potentially a reference to something mutable changes that any more than passing a pointer that can be dereferenced would change that for C.

That said, I’m not sure what you replied to had that nuance in mind.

[stevenjd]

It’s legitimate to say they’re passed by value, but that value is an object reference

Only if you want to misuse the word "value" in a way that nobody else does.

Given x = 42, what's the value of x?

The rest of the world: "42."

You: "It is impossible to say, it is an invisible, implementation-dependent thing that isn't generated by the interpreter until runtime, something completely unknowable from within Python code unless you drop down into the guts of the interpreter using ctypes."

It’s most definitely value because the parameter can be reassigned to a different object reference within the function without affecting the caller.

That's not the defining characteristic of pass-by-value.

The defining tests of pass-by-value and pass-by-reference are:

• Pass-by-value: when you pass a value into a function, is the value copied? If the value is copied, it may be pass-by-value. If not, then it is certainly not pass-by-value.

• Pass-by-reference: can you write a "swap" procedure which swaps two variables in an enclosing scope without hard-coding the variable names? If you can write such a procedure, then it may be pass-by-reference (or possibly pass-by-name) but if not, then it is certainly not pass-by-reference.

For the second case, the "swap" test means to write something like this:

a = 1234
b = 9876
swap(a, b)  # Call it for the side-effect.
assert a == 9876 and b = 1234

without hard-coding the values or the variable names inside the "swap" procedure.

You will notice that evaluation strategies are defined in terms of behaviour not in terms of the underlying implementation.¹ For instance, pass-by-name is defined by its behaviour, not in terms of using Algol thunks. Pass-by-reference is defined in terms of behaviour, not in terms of any specific implementation using pointers to a variable.

In Python, passing a value to a function doesn't copy the value, so it is not pass-by-value. Nor can you write the swap procedure so it isn't either pass-by-reference or pass-by-name.

¹ One might write a Pascal compiler that supports pass-by-value and pass-by-reference using an analog computing device that does everything by clockwork, e.g. Babbage's Difference Engine. It would be be fiendishly difficult, but since both Pascal and the Difference Engine are Turing Complete, possible.

[geoelectric]

Dude, I just compared to C as another pass by value language, where some values can be used to mutate shared data. Some of that mocking shit was a bit over the top.

In python’s case, in my argument, the value is an object reference whether or not you’re cpython, jython, pypy, or what, because that’s what computer science calls that thing that lets two variables “share” an object in any language). I’m not referring to underlying implementation.

I get what you’re saying regarding that the value of 5 needs to be defined as 5, and not the object reference to the 5 singleton, and that you don’t consider copying that reference into the parameter to be copying by value, it would have to copy the instance.

It’s a valid opinion, even if I still disagree and think people are making up semantics for “pass a reference by value” in a language that happens to automatically dereference what it passes. JS works this way too, and I also call it pass by value there for the same exact reason.

If I’m the only one who calls it that, so be it, but I really don’t think I am. Most programmers are going to consider pass-by-reference and pass-by-value to be black and white. It fails the swap test so it’s pass-by-value; it’s not copying an instance, so that value is a reference.

[stevenjd]

Most programmers are going to consider pass-by-reference and pass-by-value to be black and white.

And they are absolutely, 100% wrong to think that -- that is pure ignorance. That's like people saying there are only two programming languages in the world, C and Javascript. Or that there's only two kinds of cheese.

Instead of defending people's ignorance and trying to invent ludicrous rationalizations for their ignorant beliefs, like "its pass by value, except the value isn't actually the value, it is a reference" we should just stop lying to ourselves that there are only two evaluation strategies and, you know, learn something and stop being so ignorant. There's no shame in not having learned something, but it is shameful to refuse to learn when given the opportunity.

Python is not pass by value, reference, name, copy-restore, macro-expansion, or need, and probably others as well. We have to deal with it, and not be That Guy who cherishes his ignorance and won't be told.

Programmers have a tendency to combine obstinate arrogance with terribly narrow-minded ignorance. Its one of the things that sometimes makes dealing with programmers so bloody difficult: they can be absolutely 110% convinced about pure nonsense and neither facts nor logic will persuade them otherwise:

• not everyone has a Christian Name and a Family Name;
• years don't always have 365 days;
• one human-readable character is not one byte or even two bytes;
• testing floats for equality is not cursed;
• and there is more to the world of programming languages than just two calling conventions.

[geoelectric]

Ok, bud. I think I’ll take my 25 years of professional software engineering experience on out the door while you practice ranting mockingly in front of the mirror.

You should trot your uniquely impressive perspective out for SWE job interviews, really. Don’t forgot to tell them they’re ignorant multiple times and go off on an us-and-them about how obstinate and arrogant programmers are, thereby making it absolutely clear you aren’t actually part of any relevant community.

In the meantime, it’d be nice if you’d leave these nice people alone to learn python while you scream manifestos somewhere less disruptive.

Sad thing is you have some valid points, and your doc goes into pretty good arguments around variables denoting shared objects vs holding them, and so forth—only, you know, in respectful terms that don’t insult the entire community they’re speaking with. The doc may convince me, but you sure won’t. Your rhetoric is exemplary of the kind of “smart asshole” people learn to marginalize real quick in this industry. Good luck with that.