想自己花点精力处理，就卖二手。想让别人帮你处理，可以考虑多抓鱼。

surface 上的 Windows 系统暂时还真摆脱不了键盘，手写多的情况，就把键盘拔下来扔一边。至于手写的姿势，怎么舒服怎么来，笔吸附在哪里…真的很无解。特别是默认的吸附在左边，左手拿下来，交给右手… emmm …

如果以 Golang 的写法为基准，应该是 Python 里面使用 while 判断一个变量和一个数字的比较结果，例如 while i < 6000: 这样，不管使用 range 和 xrange 都是一堆数字的合集，只是类型与方式不同。

@rogwan 你发的这段代码时 flask-sqlalchemy 这个库里面做的事情，如果直接使用 flask 配合 sqlalchemy 就不会处理这一部分。

@rogwan 猜测其他楼层说的 sqlalchemy 的坑可能包含但不限于 orm session、复杂 sql 的问题。

sqlalchemy 如果使用 orm 操作数据库时默认使用事务，并且会引入一个 sqlalchemy session 的概念，与 db 的 connection 有区别，sqlalchemy 的文档推荐在 web 框架中做到 request context 级别的管理。如果直接 flask + sqlalchemy，如果没有手动回收 session，会出现过多事务未提交的错误，重启应用能释放这些未提交的事务。flask-sqlalchemy 使用 flask 的 app context 机制做了 orm session 在 request context 级别的回收。

复杂 sql 的问题，不管是 orm 层还是 core 层（ sql ）都会显的特别难受。复杂场景下，只能通过代码规范来限制 sql 拼接在代码不同层级的扩散。

---

关于本帖重点讨论的 Django 和 Flask 都只是轻量级的使用过，这两点好处自然不必说了。说说最近处理的问题。

最近一次处理 Django 的问题是，Django 的配置问题，Django 使用 import module 的方式获取变量，遇到了架构中使用了配置中心下发配置的情况，就显得非常尴尬。

最近一次处理 Flask 的问题是，从 Flask 迁移到其他框架时，业务代码中使用到的全局变量 g，结合业务的使用起来，迁移到其他框架 or 语言时，就要再造一次全局安全的 g 或者转换业务的实现形式。


这两个问题都是框架特有的使用方式与业务场景的绑定导致的问题，
---
个人理解：适当的使用框架但是不要被框架绑定了。

看起来是个 IDE 的配置问题，不能怪 Golang 和 go mod。你应该查一下文档，看看你的 IDE 如何支持 go mod 模式。

毕竟 go mod 模式下，依赖是放在 $GOPATH/pkg/mod 目录下的，非 go mod 模式下，go get 到的依赖是放在 $GOPATH/src 目录下的。IDE 没有配置正确，自然找不到依赖。

另外你执行 `go mod init` 的时候的报错，是因为当前项目并不在 $GOPATH/src 目录下，所以找不到默认的 module path/name，你需要执行 `go mod init $module_path/$module_name`，就可以正确执行了。


推荐先去看看官方 go mod 的文档，虽然特别的繁杂，光是一个版本号管理就能绕的云里雾里的。不过看懂之后，就知道应该如何正确使用了。

作为一个无网盘的 kindle 用户，电子书资源基本都是来自亚马逊商店的购买和借阅。个人文档类的资源都是 email 发送过去就行。如你所说，PDF 类的资源，直接选择在平板上看了。所以看下来，感觉网盘资源同步到 kindle 好像并不是一个硬需求？

前几天，听一个群友说 UCloud 的所有 API 就是 GET 请求，想起来之前任职过的某个旅游创业公司，我还在的时候后端全是 GET 请求，而且没有区分 path，请求是通过 GET 参数中的 type=u00x 这样来区分的。前端请求个接口必须有个 wiki 做「密码本」来确定这个 00x 到底是做什么的接口。

直到有一天，某个用 Python Web 框架（我忘记是什么） 的后端服务上线，发现部分请求无法正常处理，发现是 uwsgi 和某 Python Web 框架都限制 URL 的长度（包含 query args ），uwsgi 能改配置解决，Web 框架，就只能换一个了。

其实 GET 和 POST 怎么用都行，关键是接口的语义是不是让人能一眼看懂。

总结下来就两个问题：
1. Nginx 与 uWSGI + Flask App 是否在同一个系统空间下（容器是隔离的系统）？
同一个系统空间: 既可以是 sock 通信(文件)，也可以是 tcp 通信（网络，uWSGI 监听一个端口）
不同的系统空间：只能使用 tcp 通信

2. Nginx 与 uWSGI 之间的通信用 uwsgi (注意全是小写)协议，还是用 HTTP 协议？
uwsgi 协议是二进制的。使用起来的区别是 Nginx 的 pass 写成 proxy_pass 转发的是 HTTP 协议，uwsgi_pass 转发的是 uwsgi 协议。

某些情况下：KPI
某些情况下：个人喜好
某些情况下：静态类型，解决动态语言的不规范问题
某些情况下：解决性能问题
某些情况下：换一种编程与工程思路
某些情况下：……

@phoolean +1 这种规则大概是满足绝大多数用户无法连接到 Google 服务到情况，降低流量和电量的使用。但是这种规则会误伤到这些喜欢折腾的大佬们。

HHKB 吧。

或者 Windows Server 上启动一个 Linux 虚拟机来运行 Flask 应用。（如果 Windows Server 已经是虚拟机，不能嵌套虚拟化，还是算了。

@xpresslink 我手残了，Windows 下别用这些依赖来搞了，直接 Python 启 HTTP 服务更好。

@sunhk25 是我手残，Windows 下不能 gunicorn，gevent 也不那么好用，更不要提 uwsgi 了。或许你可以参考一下 stack overflow 上老哥们的意见，https://stackoverflow.com/questions/6823316/python-on-iis-how

大概越过 IIS 直接用 Python 做 HTTP 服务更好一些。

先想想为什么要用 WSGI 或者其他 CGI。如果没有那么的必要，可以用 gevent 或者 gunicorn 直接启动为 HTTP 服务。在此之前是不是有必要用 IIS，看你自己的产品或者程序的运行情况。比如 IIS 还要处理前端。

30 天是法定的上限。申请了离职之后，你把该交接的事情交接完，然后找 leader 协商还需要交接什么。如果没有的话，直接一份邮件，发给 HR，抄上你的 leader，或者其他直属管理者，著名已经交接完成，表达自己要离开的时间，就好。
公司非要强制扣人，是不被法律所支持的操作。

（工作的事情犯不上吵架）

不好用，所以到现在真的没用。以前不登录账号，也可以下载别人分享的东西，那就用一下；后来要登录之后才能下载，那就登录一下；再后来，不绑定手机号就不能登录，也就不能下载。好吧，再见。

入职不签合同，律师最喜欢你这样的了，只要证据齐全一告一个赢，需要付双倍公司给你。