一点困惑和思考

在学习c++中,a+=b,那么就同等于a=a+b

但是在python中是否如此呢。

所以就有了

a=[100]
a=a+a
#此时a=[100,100],但不妨思考一下,地址还是最开始a的地址吗

于是有了我尝试的以下代码

 1 a=[100]
 2 print(id(a))
 3
 4 a=a+a
 5 print(id(a))
 6
 7 b=[100]
 8 print(id(b))
 9
10 b+=[100]
11 print(id(b))

然而得到的结果却是

3071558316
3071558444
3071558316
3071558316

很有趣的结果不是吗,

事实上,在python中,a=1,等于号的意思应该是,在一个内存中,寻找一个内容为1的地址,然后把这个地址的引用给了a(假如没有的话,就new一个喽),但是如果有了,那么直接把引用交给这个变量就行了。

于是我又尝试了以下代码

 1 a=1
 2 print(id(a))
 3 b=1
 4 print(id(b))
 5 c=1
 6 print(id(c))
 7 d=1
 8 print(id(d))
 9 f=1
10 print(id(f))

结果为

139424192
139424192
139424192
139424192
139424192

所以在python中,变量名似乎更加像一个个标签,想贴哪贴哪,一个个内存,就是被贴的目标

时间: 2024-10-15 22:02:30

一点困惑和思考的相关文章

使用类模板时的一点困惑

1 #include<string> 2 #include<iostream> 3 4 using namespace std; 5 6 ///通过嵌套实现元则 7 template<typename T,typename N> 8 class my_tuple 9 { 10 public: 11 T value; 12 N next; 13 my_tuple(T const &v,N const &n):value(v),next(n){} 14 };

关于MultiDex方案的一点研究与思考

背景 产生65535问题的原因 LinearAlloc问题的原因 Google提出的MultiDex方案 MultiDex实现原理 缺点 美团的多Dex分包动态异步加载方案 多Dex分包 异步加载方案 参考资料 关于我 背景 目前来说,对于使用Android Studio的朋友来说,MultiDex应该不陌生,就是Google为了解决『65535天花板』问题而给出的官方解决方案,但是这个方案并不完美,所以美团又给出了异步加载Dex文件的方案.今天这篇文章是我最近研究MultiDex方案的一点收获

设计模式的一点总结和思考(一)创建型

面向接口编程 对于当前不知道或无法确定的东西,我们就抽象它,只对其接口操作,即现在不知道具体的涉及对象,但我知道如何使用它,先用其接口,待以后知道了具体的对象之后,再绑定上即可,这就是所谓的封装变化. 虽然不确定目标是谁,但可以确定如何使用目标. 多种多样的设计模式其实做的就是 封装变化 ,面对不同的情景,分析什么是变化的,什么是不变的,封装变化,使上层代码能够"以不变应万变". 简单工厂 [严格来说其并不算是一种设计模式,其就是把一堆判断创建的语句放在了一个函数中,通过传入的参数决定

程序开发与需求分析的一点疑问与思考

静静的坐在出差归往西安的火车上,想着工作以来程序开发过程中的磕磕绊绊,总觉得不入其法. 并不是编程技能得不到提升,而是程序开发出来与甲方领导的想要的相差甚远.虽然做了很多工作,可领导关心的往往却没有做或者没有达到领导想的那样.在冥思略想之下,这也许就是沟通不到位,需求不到位的恶果.有人可能说,那你去沟通啊,去做好需求啊!哥,我也想啊,可人家领导忙的很呀,只能通过领导讲的大概,自己去琢磨.也许该读读项目管理方面的书,技术在牛逼,连需求都不清楚,做出来是什么鬼??. 第二个就是专业性.通过几次给甲方

关于职业的一点忧虑和思考

很久以前在知乎上看过一个问答,对比几十年前,有哪些消失的职业 当时看了几个答案就挺感慨,今天在路上又想起来一个.在大约20多年前的时候,收水费和查电表绝对是个好职业,挨家挨户去转着看一眼多少字了,收收钱.基本不会特别辛苦. 但今天早上的时候才意识到这个职业真的要快消失了,现在电卡都已经是远程上网的,水卡的改造据说也在进行中.将来所有人都可以在支付宝或网上直接购电购水,那既不需要上门查表也不需要上门收费. 现在想想其实职业变迁还是非常频繁的,如何才能识别哪些是会被淘汰,哪些不会呢? 1. 从事一些

对《构建之法——现代软件工程》13-17章的困惑与思考

第13章  软件测试 测试原则 一,测试应该尽早进行,最好在需求阶段就开始介入,因为最严重的错误不外乎是系统不能满足用户的需求. 二,程序员应该避免检查自己的程序,软件测试应该由第三方来负责. 三,设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件,特殊情况下不要制造极端状态和意外状态. 四,应该充分注意测试中的群集现象. 五,对策就错误结果进行地一个确认过程.一般由A测试出来的错误,一定要由B来确认.严重的错误可以召开评审会议进行讨论和分析,对测试结果要进行严格的确认,是否真的存在

对《构建之法——现代软件工程》11-12章的困惑与思考

第11章  软件设计与实现 设计原则 一.设计对于分析模型应该是可跟踪的:软件的模块可能被映射到多个需求上. 二.设计结构应该尽可能的模拟实际问题. 三.设计应该表现出一致性. 四.不要把设计当成编写代码. 五.在创建设计时就应该能够评估质量. 六.评审设计以减少语义性的错误. 第12章  用户体验 体验分类 1.感观体验:呈现给用户视听上的体验,强调舒适性.一般在色彩.声音.图像.文字内容.网站布局等呈现. 2.交互用户体验:界面给用户使用.交流过程的体验,强调互动.交互特性.交互体验的过程贯

作业四:构建之法的困惑和思考(5-7)

第五章:团队与流程是关于简介各种团队的模式和流程的,问题:在不熟悉团队的情况下怎么选出适合自己团队的团队模式和流程第六章:敏捷流程剖析了敏捷流程,详细的讲了什么是敏捷流程,总结了敏捷流程.问题:敏捷流程如何准确的应用在程序中第七章:MSF 说明了MSF是什么,MSF可以做什么.问题:MSF CMMI的开发模式的主要功能?对于MSF有什么帮助评价: 这本书的语言通俗易懂 语言幽默风趣问题由浅入深 适当的插图

一点BPXA的思考

懂的人自然懂... BPXA功能配置 这个概念现在还有印象,记录下来: 一,BPXA是用于BP使用第三方资源的.如使用ORACLE数据库,就是在XA里配置.它的特征是以<xa>开头 二,BPXA有自己的KCXP队列.这个队列是自己的,还是寄生在已有的KCXP队列中,无影响. 三,BPXA在配置KCBP之间的交换资源时,是将一个BP里的队列转发到另一个队列里去. 四,所以,源BP队列里是要配置TRANSFER队列,且收发和DISPATCH配置相反.(SEND,REQ,RECEIVE,ANS).