[已解决]新手，请问为什么可以用x, y, z = z, y, x来互换值

Mrenos

2. 假设有 x = 1，y = 2，z = 3，请问如何快速将三个变量的值互相交换？
  
x, y, z = z, y, x

Z的值赋给了x后x不就成z了 X赋值给z时不就没有意义了吗？

最佳答案

月排行榜 / 总排行榜

Python_str

2018-7-17 19:39:40

这是python的设计哲学所在, 其他语言没这么方便的

Python的设计哲学

Beautiful is better than ugly. 优美胜于丑陋

Explicit is better than implicit. 明了胜于晦涩

Simple is better than complex. 简单胜过复杂

Complex is better than complicated. 复杂胜过凌乱

Flat is better than nested.　　　　　　扁平胜于嵌套

Sparse is better than dense. 　　　　 间隔胜于紧凑

Readability counts.　　　　　　　　　　 可读性很重要

Special cases aren't special enough to break the rules. 即使假借特例的实用性之名，也不违背这些规则

Although practicality beats purity.　　　虽然实用性次于纯度

Errors should never pass silently.　　　 错误不应该被无声的忽略

Unless explicitly silenced.　　　　　　　 除非明确的沉默　　　　　　　

In the face of ambiguity, refuse the temptation to guess. 当存在多种可能时，不要尝试去猜测

There should be one-- and preferably only one --obvious way to do it. 应该有一个，最好只有一个，明显能做到这一点

Although that way may not be obvious at first unless you're Dutch.虽然这种 方式可能不容易，除非你是python之父

Now is better than never. 现在做总比不做好

Although never is often better than *right* now. 虽然过去从未比现在好

If the implementation is hard to explain, it's a bad idea. 如果这个实现不容易解释，那么它肯定是坏主意

If the implementation is easy to explain, it may be a good idea. 如果这个实现容易解释，那么它很可能是个好主意

Namespaces are one honking great idea -- let's do more of those! 命名空间是一种绝妙的理念，应当多加利用

跳转到最佳答案楼层

pl2379965

你为什么不认为 x,y,z = z,y,x
等价于
i=x
x=z
z=i 呢

南墙终期于尽

从描述来看，你的意思是只要交换X和Z的值就可以，核心语句如下，供参考：（C语言）
int x=1,z=3;
x=x+z;
z=x-z;
x=x-z;

Mrenos

python交换两个值得方法非常简单，即a,b=b,a，一步操作就交换了两个值，那么这是为什么呢？
真相：
Python的变量并不直接存储值，而只是引用一个内存地址，交换变量时，只是交换了引用的地址。
先看下面这段程序：
import dis

def func(a,b):
    a,b=b,a
    print(a,b)

a=10
b=20
func(a,b)
dis.dis(func)
1
2
3
4
5
6
7
8
9
10
一般来说一个Python语句会对应若干字节码指令，Python的字节码是一种类似汇编指令的中间语言，但是一个字节码指令并不是对应一个机器指 令（二进制指令），而是对应一段C代码，而不同的指令的性能不同，所以不能单独通过指令数量来判断代码的性能，而是要通过查看调用比较频繁的指令的代码来 确认一段程序的性能。
　　一个Python的程序会有若干代码块组成，例如一个Python文件会是一个代码块，一个类，一个函数都是一个代码块，一个代码块会对应一个运行的上下文环境以及一系列的字节码指令。
dis的作用
　　dis模块主要是用来分析字节码的一个内置模块，经常会用到的方法是dis.dis([bytesource])，参数为一个代码块，可以得到这个代码块对应的字节码指令序列。
代码输出结果

其中只看前面为12的结果就行了（在我的编译器里，交换的那一行代码在第12行）
可以看出主要是ROT_TWO指令的功劳：
查阅python文档可以知道有ROT_TWO （源码1398行），ROT_THREE（源码1406行）， ROT_FOUR这样的指令，可以直接交换两个变量、三个变量、四个变量的值
在python3.4的源码中查阅ceval.c文件可以看到：
TARGET(ROT_TWO) {           
    PyObject *top = TOP();         
    PyObject *second = SECOND();      
    SET_TOP(second);         
    SET_SECOND(top);         
    FAST_DISPATCH();      
}        
TARGET(ROT_THREE) {            
    PyObject *top = TOP();            
    PyObject *third = THIRD();            
    SET_SECOND(third);            
    FAST_DISPATCH();        
}
1
2
3
4
5
6
7
8
9
10
11
12
13
附：python值的交换
变量的每一次初始化，都开辟了一个新的空间，将新内容的地址赋值给变量。对于下图来说，我们重复的给str1赋值，其实在内存中的变化如图：

从上图我们可以看出，str1在重复的初始化过程中，是因为str1中存储的元素地址由’hello world’的地址变成了’new hello world’的。
对于复杂的数据类型来说，改变其内部的值对于变量的影响：


当对列表中的元素进行一些增删改的操作的时候，是不会影响到lst1列表本身对于整个列表地址的，只会改变其内部元素的地址引用。可是当我们对于一个列表重新初始化(赋值)的时候，就给lst1这个变量重新赋予了一个地址，覆盖了原本列表的地址，这个时候，lst1列表的内存id就发生了改变。上面这个道理用在所有复杂的数据类型中都是一样的。

来源：https://blog.csdn.net/qq_33414271/article/details/78522235

Python_str

这是python的设计哲学所在, 其他语言没这么方便的

Python的设计哲学

Beautiful is better than ugly. 优美胜于丑陋

Explicit is better than implicit. 明了胜于晦涩

Simple is better than complex. 简单胜过复杂

Complex is better than complicated. 复杂胜过凌乱

Flat is better than nested.　　　　　　扁平胜于嵌套

Sparse is better than dense. 　　　　 间隔胜于紧凑

Readability counts.　　　　　　　　　　 可读性很重要

Special cases aren't special enough to break the rules. 即使假借特例的实用性之名，也不违背这些规则

Although practicality beats purity.　　　虽然实用性次于纯度

Errors should never pass silently.　　　 错误不应该被无声的忽略

Unless explicitly silenced.　　　　　　　 除非明确的沉默　　　　　　　

In the face of ambiguity, refuse the temptation to guess. 当存在多种可能时，不要尝试去猜测

There should be one-- and preferably only one --obvious way to do it. 应该有一个，最好只有一个，明显能做到这一点

Although that way may not be obvious at first unless you're Dutch.虽然这种 方式可能不容易，除非你是python之父

Now is better than never. 现在做总比不做好

Although never is often better than *right* now. 虽然过去从未比现在好

If the implementation is hard to explain, it's a bad idea. 如果这个实现不容易解释，那么它肯定是坏主意

If the implementation is easy to explain, it may be a good idea. 如果这个实现容易解释，那么它很可能是个好主意

Namespaces are one honking great idea -- let's do more of those! 命名空间是一种绝妙的理念，应当多加利用