其实是有类似你说的方法的，但是是 magic method 。

d['key'] = 'value' 等同于 d.__setitem__('key', 'value')

字典主要是还有一个 update 方法，实际上就是遍历 key, value 去做__setitem__


确实有时候会给人一种设计上不一致的感觉：
value = d['key'] 也就是 value = d.__getitem__('key')
上面这种方括号用法有 KeyError 的风险，
d['key'] = 'value' 同样是方括号用法，同样是对应一个魔法方法，这个却不会有问题。
然后我换一种风格，用 d.get('key') 和 d.update(other_dict), 都不会出现 KeyError 。

字典 get 方法和__getitem__方法的逻辑并不一样，前者是默认取不到值取默认值，且默认值为 None ；后者取不到值直接报错，且不提供默认值参数。

不过仔细看看就知道了，get 方法是属于字典这种 python 中的 Mapping 类的，并不是直接对应__getitem__这种魔法方法的。通用类是并没有自带 get 和 set 这种方法的。

@zhangwugui
如果你的大拇指指甲或者指头，比较突出，就容易钻破袜子。
如果你平时自然状态是翘起来的，应该也有影响的。
跟鞋子、脚型和袜子质量也有关系。

是不是不勤修剪脚趾甲？这样袜子才容易破啊？

要不然就是经济窘迫，袜子超限服役。


如果是我，个人感觉袜子破洞会有点喜感，可能会笑，但是不会感觉瞧不起人/被瞧不起。

还有饿了么的 app 设计，点完餐付完款，让你领豆，领了豆也不会自动进订单详情，也没有快捷入口进入订单，这样用户更不太可能发现自己选错地址了。

领豆和进首页都是引导用户继续多点一单，但是实际一段时间内点多个外卖的用户我估计占总比重是少之又少，就为了这个目的，把这个交互成这个无语的样子。

美团、饿了么的交互设计，都是重销售导向的，从设计上就想让你多点单，多花钱，还要习惯多花钱。

选错收货地址导致送错的情形应该不算很少，我个人没试过，但是确实感觉交互设计需要改进。
外卖软件应该至少在最终确认订单付款前还有个步骤就是专门为且仅为确认收获地址是否正确的，我个人感觉加一个单独的确认页，文字+地图确认都不为过。

之前倒不是点外卖点错地方，而是麦当劳到店取餐，点歪了点去别的门店了。
麦当劳手机 app 选餐前，确认前都分别有个交互步骤提醒的，但是当时疏忽了，而且各个门店距离之间挺近，一公里左右。
搞得我人在 A 店，点了 B 店的，没办法，又跑到 B 店去取餐了。如果 app 做了这种设计，那用户搞错地址，是真没办法甩锅。

可以去看一下刘慈欣写的《朝闻道》。

地球人可以去问高等文明外星人一些很难的问题，比如一些终极数学问题，物理问题等。
外星人会回答，回答完了就会把问问题的人干掉。

只有霍金上去问的时候，问外星人宇宙的目的是什么，外星人回答不出来，把他放了。


有些问题，别说人的一生，可能一个文明从诞生到终结，都找不到答案。

已经不算很差了，不过确实项目结构还不成形。
起码这个 BaseModel 应该是 pydantic 的 BaseModel 吧，起码知道用显式定义属性的类。

我知道的个别同事都是字典用到天昏地暗。
一个字典几十个键值对，还有嵌套的，不管大部分属性能不能用到，反正就从头用到尾，好几层调用方法都要把这个祖传字典传进去，修改里面的值。
还有所有业务，涉及到数据库的，也不知道怎么配置 ORM 的，反正就一条语句一个事务。

接手的那个同事，接手了几个月，改 bug+优化+改造，头发都白了几百根。

@momo1pm #59
对啊，还不是嫌降薪多，降的再多能比跑外卖少？
或者降下职级，或者转产品经理转项目经理，哪种选择都比骑电动车冒着生命危险拼死拼活跑成单王才赚 10K+要好吧？

后面他写 app 去记录详细地图信息我觉得有点意思，但是可惜只是浮于表面，并没有深入。
而且这个情节太不现实了，一方面骑着电瓶车拼死拼活整天跑外卖，跑完外卖还有时间写代码？认真的？


而且这个年薪就算被裁了，我不信真的找工作没 offer ，只是说做什么岗位，会不会降薪，降多少的问题而已。、在片里就是没几个面试，就算有个面试，还硬要塞一个 HR 犯低级错误没审核到年龄，然后还要被上司不停 PUA 的情节进去。

感觉就是写剧本的人只是对外卖员和程序员都有点浅薄的了解罢了，并没有接触到实际的东西。

戏里徐峥是单王是写免费 app 给外卖员用的人，好歹有点贡献，戏外徐峥拍了这片子，给观众看完并不能改变啥。