Python violates most users expectations via the modification differences of immutable and mutable objects in methods.

def foo(bar):
    bar = bar + bar

def listy(bar):
    bar =  [1]

def dicty(bar):
    bar['1'] = '1'

if __name__ == "__main__":
    bar = 1
    foo(bar)
    print bar
    baz = []
    print baz
    listy(baz)
    print baz
    dict_d = {}
    print dict_d
    dicty(dict_d)
    print dict_d

this will output
1
[]
[]
{}
{'1': '1'}


So sure this is 'expected'(pass by reference vs new object - for immutable objects) but it sure isn't obvious.
I feel this is a bug in python core.
I think that the behaviour should be the same for *all* objects.
If it is pass by reference, *and* the item has to be able to be updated(I feel this breaks most people's expectations...) then the result of a modification to an object that is immutable should be that the pointer to the original now points to the resulting string. 

Personally I do not want to be able to modify the dictionary as I did above like I did.

> I feel this breaks most people's expectations...

I think you are quite mistaken in this assumption. Sure, object references are difficult to grasp at first, but they are a highly useful concept, and follow very simple, systematic principles - you just need to "get" it once.

> result of a modification to an object that is immutable

Objects that are immutable *cannot* be modified - that this the very definition of "immutable". It seems that your understanding of Python still doesn't match its semantics.

However, Python really can't adjust to whatever your current understanding is: most people (dealing with it) already have the right understanding.

So closing this as "won't fix".

I strongly suggest you reconsider as *most* programmers will not think about it this way.
No you failed to understand my bug report apparently. I understand the behaviour. However, you failed to understand the problem. 

*PLEASE* read and think about it.

What you describe is the way Python is *designed* to work at a very fundamental level.  Read about 'namespaces', and look at the computer science literature on 'call by object'.

def list_again(foo):
	foo.append("bar")

def list_again_again(foo):
	foo = foo + ["1"]

if __name__ == "__main__":
	bar = []
	list_again(bar)
	print bar
	list_again_again(bar)
	print bar



Ok so let me without running the above code exactly what it does AND then, stop and think about how *most* coders expect it to behave.

In c pointers are *explicit*, ditto in c++, in java everything is a pointer.
In asm, well that is asm.
This behaviour in python, makes python code *really* hard to read and *hard* to understand. 

Can you python devs / people stop calling a bug reporter stupid when they point out language flaws?

If you like I can look for this new security bugs in existing python projects and show you why this is a *very* bad idea. 

Please stop this python isolated mentality and autistic behaviour and consider the possibility of being wrong.

Please use a language that makes sense to you then.

Excuse me for reporting weird and not expected behaviour on behalf of *most* coders.

Here https://bugs.edge.launchpad.net/ubuntu/+source/checkbox/+bug/625076
I understand python fine. If I have to find security bugs in *lots* more python projects to prove my point I will do this *to* make this point really clear. 
You (responders so far) seem to not understand the nature of this problem and you are simply calling me stupid.

Just to clarify that last comment. 
By exhibiting this behaviour python, introduces the potential for a lot more errors in code that seems to be correct to most people. 
Remember this bug is about the differences in behaviour for 'mutable' and 'immutable' objects.

2010/8/27 david <report@bugs.python.org>:
>
> david <db.pub.mail@gmail.com> added the comment:
>
> Excuse me for reporting weird and not expected behaviour on behalf of *most* coders.

Your assumption that most coders are confused by this comes from where?

>
> Here https://bugs.edge.launchpad.net/ubuntu/+source/checkbox/+bug/625076
> I understand python fine. If I have to find security bugs in *lots* more python projects to prove my point I will do this *to* make this point really clear.

Well, that would be relevant to those projects, not python.

> You (responders so far) seem to not understand the nature of this problem and you are simply calling me stupid.

Actually, the only insult that seem to have happened is you calling us
"autistic".

Also, repeatedly opening this bug report will not make it any more
likely that action will be taken on it.

The current design has existed for almost twenty years.
It is deeply embedded in the language.   For better or
worse, it cannot and won't change.

david, please accept that regardless of whether this is a bug or not, people dealing with bug reports will always determine that it is no bug, and close it. *Please stop reopening this report*.

If you want to appeal to this decision, please post a message to python-ideas, asking for support from other people.

Also be prepared to write a PEP proposing changes to the language to make it work more like you expect. Please expect that this PEP will be very difficult to write, and, if you indeed manage to come up with a sound proposal, that proposal will get a lot of opposition.

"Please stop this python isolated mentality and autistic behaviour and consider the possibility of being wrong."
... No I didn't, did you read what I said?
Also, repeatedly closing this bug isn't going to make it go away.
You are kidding your self if you think that 99% of python coders will be able to tell me the correct answers to the code output I have pasted here(without running it). 


Saying something is correct because of history is *just* plain wrong.
I will happily write a PEP and anything else required to get this changed.

To quote the zen of python:
"Readability counts.
Special cases aren't special enough to break the rules."

<Yawn>

def list_again(foo):
	foo.append("bar")

def list_again_again(foo):
	foo = foo + ["1"]


The part that can be confusing is that 'foo' is a *copy* of a *reference* to an object. Because 'foo' is a copy, assigning to it will only alter a local copy, while calling methods on it will always call on the original object (because it's a reference to the same place). When an object is mutable, it just has no methods that modify it, so the only way to change it is by assignment, which will never result in changes to the outside function. There are no special cases, but it does require understanding pass-by-(copy/reference) and object mutability, and is against most people's intuitions.

The way that behaves is actually how most *programmers* would expect (because they are used to it), though. Every other language I can think of does it this way. For example, in C, a pointer is still a copy of a reference -- if you assign to the pointer, it wont propagate up to the caller. The same goes in Java.

Perhaps what makes it harder to understand in Python is that everything is an object and looks the same regardless of mutability, whereas other languages typically have conventions (such as capitalising: int, str, Dict, List) to make it clearer when something is an object (which usually means the same as a python mutable object) as opposed to a built-in type (which usually means the same as a python immutable object).

Just my 2c

On 28 August 2010 09:10, Theo Julienne <report@bugs.python.org> wrote:
>
> Theo Julienne <theo.julienne@gmail.com> added the comment:
>
> def list_again(foo):
>        foo.append("bar")
>
> def list_again_again(foo):
>        foo = foo + ["1"]
>
>
> The part that can be confusing is that 'foo' is a *copy* of a *reference* to an object. Because 'foo' is a copy, assigning to it will only alter a local copy, while calling methods on it will always call on the original object (because it's a reference to the same place). When an object is mutable, it just has no methods that modify it, so the only way to change it is by assignment, which will never result in changes to the outside function.

Yes exactly!

>There are no special cases, but it does require understanding pass-by-(copy/reference) and object mutability, and is against most people's intuitions.

No that isn't really my point here really.

> The way that behaves is actually how most *programmers* would expect (because they are used to it), though. Every other language I can think of does it this way. For example, in C, a pointer is still a copy of a reference -- if you assign to the pointer, it wont propagate up to the caller. The same goes in Java.

Um sort of. This is kind of confusing right see the code below.

> Perhaps what makes it harder to understand in Python is that everything is an object and looks the same regardless of mutability, whereas other languages typically have conventions (such as capitalising: int, str, Dict, List) to make it clearer when something is an object (which usually means the same as a python mutable object) as opposed to a built-in type (which usually means the same as a python immutable object).

I actually think the problem is that python coders are not aware of
this largely (from my experience) and that the *operators* are going
to behave differently (java, for example,  differs in this respect (
you don't '+' maps )).

Here are some examples of use in other languages. Mapping python can
be found some of them.

foo.cpp
#include <iostream>
#include <string>
using namespace std;

void do_More_Foo(int *it);

int main()
{
	int *foo;
	int bar = 0;
	foo = &bar;
	cout << *foo << " "  << foo << endl;
	do_More_Foo(foo);
	cout << *foo << " "  << foo << endl;
	return 0;
}

void do_More_Foo(int *it)
{
	cout << "do more foo " << it << " " << *it <<endl;
	*it = 9;
}

g++ -Wall -Werror foo.cpp  -lmudflap -fmudflap
./a.out
0 0x7fff0ec19adc
do more foo 0x7fff0ec19adc 0
9 0x7fff0ec19adc

AND in python:
#!/usr/bin/env python

def do_More_Foo(it):
	print "in do_More_Foo"
	print "foo", foo, id(foo), id(foo[0])
	print "it", it, id(it)
	it.pop()
	it.append("9")

if __name__ == "__main__":
	bar = 0
	foo = [bar]
	print id(bar)
	print id(foo[0])
	print foo, id(foo)
	do_More_Foo(foo)
	print "after do_More_Foo", foo, id(foo), id(foo[0])

output:
16307968
16307968
[0] 140400602766512
in do_More_Foo
foo [0] 140400602766512 16307968
it [0] 140400602766512
after do_More_Foo ['9'] 140400602766512 140400602799200

However, this isn't what you expect people to do.
Oh and how did foo get there ;) (surprise! python isn't simple is it ?
- note the id).

So I think most people are going to think about this and write it like this:
#!/usr/bin/env python

def woops(it):
	# erh make foo = 9 ?
	print "foo", foo, id(foo)
	foo = 9
	print "foo", foo, id(foo)

def do_More_Foo(it):
	print "in do_More_Foo"
	print "foo", foo, id(foo)
	print "it", it, id(it)
	it = 9
	print "it", it, id(it)

if __name__ == "__main__":
	foo = 0
	print foo, id(foo)
	do_More_Foo(foo)
	print "after do_More_Foo", foo, id(foo)
	woops(foo)
	print "after do_More_Foo", foo, id(foo)

output:
0 19838720
in do_More_Foo
foo 0 19838720
it 0 19838720
it 9 19838504
after do_More_Foo 0 19838720
foo
Traceback (most recent call last):
  File "python-cpp2.py", line 21, in <module>
    woops(foo)
  File "python-cpp2.py", line 5, in woops
    print "foo", foo, id(foo)
UnboundLocalError: local variable 'foo' referenced before assignment

As you expect it is not the foo you are looking for ;)

foo.java

import java.util.HashMap;

import javax.print.DocFlavor.STRING;

public class foo
{

	public void bar(HashMap<String, String> z)
	{

		z.put("foo", "bar");
		HashMap<String, String> b = z;
		b.put("foo2", "ba2r");
	}

	void magic(String b)
	{
		String c = b;
		b = b.replace('b', 'c');
		System.out.println(c);
		System.out.println(b);
	}

	void moremagic(StringBuilder z)
	{
		z.append("b");
	}
	public static void main(String[] args)
	{
		HashMap<String, String> baz = new HashMap<String, String>();
		foo myfoo = new foo();
		myfoo.bar(baz);
		System.out.println(baz.toString());
		String aaa = "b";
		myfoo.magic(aaa);
		System.out.println(aaa);
		StringBuilder sb = new StringBuilder();
		myfoo.moremagic(sb);
		System.out.println(sb);
	}

}
java foo
{foo2=ba2r, foo=bar}
b
c
b
b

#!/usr/bin/env python

def bar(a_dict):
	a_dict["foo"] = "bar"
	new_dict = a_dict
	a_dict["foo2"] = "ba2r"

def magic(string_b):
	c = string_b
	string_b = string_b.replace('b', 'c')
	print c
	print string_b

def moremagic(list_s):
	list_s.append("b")

if __name__ == "__main__":
	d = dict()
	bar(d)
	print d
	aaa = "b"
	magic(aaa)
	print aaa
	a_list = []
	moremagic(a_list)
	print a_list[0]

python python-java.py
{'foo': 'bar', 'foo2': 'ba2r'}
b
c
b
b

- no problems here :)  - but in python we can use an operator like '+'
on a list which introduces the very confusion I am talking about in
respect to the differing behaviour as I stated at the top of this bug
report. :)

This is not an appropriate discussion for the bug tracker.  Please take it to the Python mailing list.

On 28 August 2010 22:34, R. David Murray <report@bugs.python.org> wrote:
>
> R. David Murray <rdmurray@bitdance.com> added the comment:
>
> This is not an appropriate discussion for the bug tracker.  Please take it to the Python mailing list.

Fair enough.
One last comment though (here) - I think that  making mutable objects
being immutable outside their immediate scope  (by *default* ) would
be a good solution.

On 28 August 2010 22:41, david <report@bugs.python.org> wrote:
>
> david <db.pub.mail@gmail.com> added the comment:
>
> On 28 August 2010 22:34, R. David Murray <report@bugs.python.org> wrote:
>>
>> R. David Murray <rdmurray@bitdance.com> added the comment:
>>
>> This is not an appropriate discussion for the bug tracker.  Please take it to the Python mailing list.
>
> Fair enough.
> One last comment though (here) - I think that  making mutable objects
> being immutable outside their immediate scope  (by *default* ) would
> be a good solution.

%s/being//