So is python pass-by-reference or pass-by-value?

Arguments are passed by assignment. The rationale behind this is twofold:

1. The parameter passed in is actually a reference to an object (but the reference is passed by value)
2. Some data types are mutable, but others aren't

So:
If you pass a mutable object into a method, the method gets a reference to that same object and you can mutate it to your heart's delight, but if you rebind the reference in the method, the outer scope will know nothing about it, and after you're done, the outer reference will still point at the original object.

If you pass an immutable object to a method, you still can't rebind the outer reference, and you can't even mutate the object.

>>57707995
so why didn't x change to 11, are ints immutable?

>>57708032
download a python book and start reading?

>>57708032
n+=1 is a shorthand for n = n + 1. See the big ass assignment operator "=" there? That n is not the n you passed in anymore.

But for al.append(), do you see any assignment operators? No? Then it remains the same one you passed in.

>>57709541
... It's usually this way in Python:

> Explicit or implicit assignment operator -> origin doesn't change

> No assignment operator (only method calls on the object) -> origin changes

File: soft_30344.jpg (144KB, 567x900px) Image search: [Google]

144KB, 567x900px

>>57709541
>>57709541
>n+=1 is a shorthand for n = n + 1

Watch out for some special cases though. I remember being bitten in the ass with this line of thinking, it was with numpy arrays i think. In a function I did something like this:

def f(array):
    ...
    array += stuff
    ...
    return array

And I was expecting getting a copy of the array in return (with stuff added to it) and the original array untouched, but this wasn't the case; the original array was modified and then returned.

I modified that line to

array = array + stuff

And got what I expected.

What I'm getting at is that numpy probably overloaded the "+=" operator in a way to directly modify the receiver instead of just overloading "+" (returning a copy) and letting Python rewrite the "+=" statement to "+ then =" (and justifiably so, for obvious performance reasons.

>>57713308
numpy is horribly un-pythonic though

File: soft_30281.jpg (285KB, 1200x1803px) Image search: [Google]

285KB, 1200x1803px

>>57713318
>numpy is horribly un-pythonic though
In what way? Genuinely curious.

It's really great though, for doing all kinds of math. Not only numpy, but the whole scipy ecosystem. I used it for Bachelor's thesis (on biometric identification). scikit-learn and scikit-image are especially great. Not performance-wise (although scikit-learn can easily parallelize), but in terms of how easy it is to get stuff done. Jupyter (previously known as IPython) is awesome to test stuff out, see the results (it can display images and plots inline) and iterate. I prefer spending 2h writing an algorithm and letting it run for 6h than the other way around.

Recently I've started using Pandas for data analysis and it's an awesome library too. I use it to analyze logs from a distributed environment (we have a class on distributed systems, and often have to run stuff on 50+ nodes).

>>57713465
Numpy is great but it's a mess of redundant functions, subtle differences between what operators do to different types of data.

Compare numpy to many standard library things and you should notice how differently you interact with them compared to numpy

>>57713479
I agree, and it becomes even worse when you throw scipy into the mix. Scipy re-exports most of numpy's API, but makes some subtle changes on some functions. I can't remember specific examples, but I think the linalg package is one of those: numpy's and scipy's SVD are vastly different and I may have encountered unexpected results when switching from one to the other. It was a long time ago, maybe I don't remember correctly.

But some would argue that numpy's mostly geared towards interactive use, which might explain some design decisions. It's also supposed to be similar to Matlab.

One thing that annoys me to no end is that you can't generate a numpy array from a generator object; you have to do np.array(list(generator)) which makes things unbearably unreadable.

>>57707942
Pass by value. You pass numbers as values, that's straightforward, but the messy thing here is that composite values like arrays and dicts you don't pass as values, but instead you pass a reference to them AS a value.

What that means is that when you create an array you're receiving a reference value to said array. You can the call methods of the array through that reference, with the array.something() notation. When you pass this reference value to a function, the function can also call the same methods through the reference, thus mutating the array at its "creation site".

You can't, however, change the values of the variables that you pass to functions. If you could alter them at call site, that would be passing by reference. Instead, for instance, if your parameter is a number, you receive a value that's not localized anywhere. You just have the value, and you can't somehow mutate it, if it changes you have a new value. That's what's preventing you from changing the variable outside of the function.

All get it?

>>57713308
Yep. I was mostly referring to your every day Python objects and literals. When numpy comes in a lot of things can change.

>>57713465
>>57713567
I feel the same way. Numpy is when you want to build Python notebooks for calculations. It's not for performance. If you want performance, you probably should write C++ and then generate a wrapper using SWIG or just do C++ all together.

>>57707942
pass by "object-reference"

>>57707942
Numbers are immutable in python.

>>> x = 10
>>> id(x)
140171451691872
>>> x += 5
>>> id(x)
140171451692032