 |
akaHenryV2EX 第 511376 号会员，加入于 2020-10-07 15:47:45 +08:00今日活跃度排名 9048 |
akaHenry 最近回复了
4 小时 56 分钟前 回复了 akaHenry 创建的主题 › 分享创造 › 🔥 分享: 正在写 <<Mojo 编程学习指南>> 在线教程. 欢迎阅读+贡献. |
@ZX576 和 rust 定位不一样. Mojo 是 Python 的超集. 性质如 TS vs JS 和 C vs C++.
你不会觉得 C 转 C++, JS 转到 TS 困难吧?
chris 过去在苹果, 搞过 Objective-C 转 Swift.
这不过是再搞一遍, 轻车熟路. 你要相信专业的编译器专家和语言专家. 不会比我们懂的少.
你不会觉得 C 转 C++, JS 转到 TS 困难吧?
chris 过去在苹果, 搞过 Objective-C 转 Swift.
这不过是再搞一遍, 轻车熟路. 你要相信专业的编译器专家和语言专家. 不会比我们懂的少.
3 天前 回复了 akaHenry 创建的主题 › Python › NiceGUI 已经 1.0+, 已移除 JustPy 依赖, 只基于 Vue 3 + Quasar 2 + Tailwind 3, 加载速度很快! |
@lchynn
粗略看了下 reflex 官方文档, 设计风格是偏 flutter 的. 我也写过 flutter.
不过感觉这个 reflex 没有 nicegui 简洁, nicegui 是很地道的 python 代码写法.
reflex 这种抄 flutter, 有点不伦不类.(很不 python)
nicegui 是 基于 vue.js + Quasar(UI 框架) 的. 也提供了 hack 入口, 即使 nicegui 一些 API 还未对齐, 也可以 hack 进 vue.js, 用纯前端的方式来实现一些功能.
so, nicegui 的完成度更高, 未来上限更高. 充分利用 vue.js 和 Quasar 的强大, 站在巨人肩膀上.
站在当前节点, 类前端(web)方案, 是开发效率最高的 GUI 方案. 非 web 方案, 不值得投入时间研究.
粗略看了下 reflex 官方文档, 设计风格是偏 flutter 的. 我也写过 flutter.
不过感觉这个 reflex 没有 nicegui 简洁, nicegui 是很地道的 python 代码写法.
reflex 这种抄 flutter, 有点不伦不类.(很不 python)
nicegui 是 基于 vue.js + Quasar(UI 框架) 的. 也提供了 hack 入口, 即使 nicegui 一些 API 还未对齐, 也可以 hack 进 vue.js, 用纯前端的方式来实现一些功能.
so, nicegui 的完成度更高, 未来上限更高. 充分利用 vue.js 和 Quasar 的强大, 站在巨人肩膀上.
站在当前节点, 类前端(web)方案, 是开发效率最高的 GUI 方案. 非 web 方案, 不值得投入时间研究.
3 天前 回复了 akaHenry 创建的主题 › 分享创造 › 🔥 分享: 正在写 <<Mojo 编程学习指南>> 在线教程. 欢迎阅读+贡献. |
@ZX576
1. 学习成本不高, chris 并不会增加太多新语法. 语法复杂度远小于 rust. 100% 兼容 python, 目前比 python 扩充的特性, 都比较符合直觉. 并不难理解.
2. 当前 mojo 执行 纯 python 代码 or import python lib 时, 会调用 cpython. (当前依赖 cpython, 未来会去掉依赖, 纯 mojo) 目前对 python codes or libs, 性能上, 应该没啥提升.(只是对齐 python 阶段, 未来 去除 cpython 依赖时, 会有提升. 画饼, 是个长期目标) 当前如果想提升性能, 是需要手动改写 python 代码到 mojo 来优化. 不过官方正在实现 python2mojo 工具(自动翻译), 估计很快就会发布. 到这个阶段, 即使不学 mojo, 只会 python 也能利用 mojo 来提升性能.(当成一个外挂)
3. 是的. 提升 python 性能, 需要转换为 mojo. 当前是手转, 可能比较快就会有工具自动转了.
1. 学习成本不高, chris 并不会增加太多新语法. 语法复杂度远小于 rust. 100% 兼容 python, 目前比 python 扩充的特性, 都比较符合直觉. 并不难理解.
2. 当前 mojo 执行 纯 python 代码 or import python lib 时, 会调用 cpython. (当前依赖 cpython, 未来会去掉依赖, 纯 mojo) 目前对 python codes or libs, 性能上, 应该没啥提升.(只是对齐 python 阶段, 未来 去除 cpython 依赖时, 会有提升. 画饼, 是个长期目标) 当前如果想提升性能, 是需要手动改写 python 代码到 mojo 来优化. 不过官方正在实现 python2mojo 工具(自动翻译), 估计很快就会发布. 到这个阶段, 即使不学 mojo, 只会 python 也能利用 mojo 来提升性能.(当成一个外挂)
3. 是的. 提升 python 性能, 需要转换为 mojo. 当前是手转, 可能比较快就会有工具自动转了.
16 天前 回复了 Casbin 创建的主题 › 分享创造 › Casdoor: 具有 Web UI 界面的开源身份认证、单点登录平台，支持 GitHub、Gitee、QQ、微信、钉钉登录等 |
17 天前 回复了 akaHenry 创建的主题 › 分享创造 › 🔥 分享: 正在写 <<Mojo 编程学习指南>> 在线教程. 欢迎阅读+贡献. |
17 天前 回复了 akaHenry 创建的主题 › 分享创造 › 🔥 分享: 正在写 <<Mojo 编程学习指南>> 在线教程. 欢迎阅读+贡献. |
Mojo 教程, 内容截图:
17 天前 回复了 akaHenry 创建的主题 › Python › 建了个 Mojo vx 交流群, 欢迎 Pythoner 加群交流 |
更新:
https://v2ex.com/t/973338#reply0
https://trybetter.larksuite.com/wiki/K9ALwrRLoikBdZkF8CKuB0C0sFh#mindmap
正在写 << mojo 编程学习指南>> , 欢迎阅读.
https://v2ex.com/t/973338#reply0
https://trybetter.larksuite.com/wiki/K9ALwrRLoikBdZkF8CKuB0C0sFh#mindmap
正在写 << mojo 编程学习指南>> , 欢迎阅读.
24 天前 回复了 kice 创建的主题 › Python › 求分布式任务队列库推荐 |
1. 如果只会 python or 小项目, 那就 celery + rabbitmq.
2. 如果不局限 python 生态内. 更推荐 nats 和 kafka. (尽早使用跨语言通用的中间件, 迁移时, 少扔代码)
2. 如果不局限 python 生态内. 更推荐 nats 和 kafka. (尽早使用跨语言通用的中间件, 迁移时, 少扔代码)
24 天前 回复了 jenrey 创建的主题 › Python › Python GIL 的问题 |
GIL 不防呆.
24 天前 回复了 vicalloy 创建的主题 › Python › 你们的 Python 代码加不加 Type Hints |
Type Hints 是政治正确. (就算很多人日常不加, 恐怕也装装样子鼓励他人加)
Type Hints 当然是好, 但是有开销. (加不加, 加多少, 看具体场景/维护成本/代码生命周期, 以及你和团队会几门语言.)
应该加:
1. 团队(个人) 只会/只用 python 开发, typing 和 Pydantic 都用起来.
2. 单元测试, 写起来, 至少覆盖核心链路. (这比 Type Hints 更容易保障质量和正确使用, 如果时间仅够二选一, 宁愿你写单元测试)
少加/不加: (CPyUG 老炮的场景)
1. 个人项目, 生命周期很短(活不久)的代码. 加了没收益.(怎么快, 怎么来)
2. 多技能栈(Python + Rust, Go 等) 组合. 充分利用动态语言的灵活性, 少加/不加. 需要强约束/性能场景, 直接切 rust/go.
3. 老司机, 写的代码, 可读性好. 加不加, 不影响阅读. (废话, 没有 Type Hints 之前的 10 多年, 大家照样写的飞起)
4. 一次性的脚本, 用完就扔(厕纸代码, 活不过明天). 没必要脱裤子放屁.
个人选择:
1. 作为写了比较久 python 的( py2.5 开始的), CPyUG 说不加 Type Hints 的人不少. 很正常.(在很多场景, 不用, 也都对)
2. 加当然好, 但是要平衡成本和收益. (年轻人, 容易沉迷于写太多没 转化率(不赚钱) 的代码)
3. 我日常会加, 但保持克制. (少用和不用 Pydantic, 有开销).
4. python 已经不是我的主力语言, 用 python 更多是为了快速糊东西和验证技术/产品原型. 一旦验证通过, 很快就会迁移到 rust, go 等重写. 所以, 写 python, 就更追求 怎么快, 怎么来. (代码活不久, 没必要写太好)
以上来自 写了 10 多年 python 的开发者的一点看法.
(当然, mojo 1-2 周, 就要发布了, 喜欢写 Type Hints, 来写 mojo 吧)
免杠指南:
我只是说了 不加/少加 的场景, 你要杠, 你对.
Type Hints 当然是好, 但是有开销. (加不加, 加多少, 看具体场景/维护成本/代码生命周期, 以及你和团队会几门语言.)
应该加:
1. 团队(个人) 只会/只用 python 开发, typing 和 Pydantic 都用起来.
2. 单元测试, 写起来, 至少覆盖核心链路. (这比 Type Hints 更容易保障质量和正确使用, 如果时间仅够二选一, 宁愿你写单元测试)
少加/不加: (CPyUG 老炮的场景)
1. 个人项目, 生命周期很短(活不久)的代码. 加了没收益.(怎么快, 怎么来)
2. 多技能栈(Python + Rust, Go 等) 组合. 充分利用动态语言的灵活性, 少加/不加. 需要强约束/性能场景, 直接切 rust/go.
3. 老司机, 写的代码, 可读性好. 加不加, 不影响阅读. (废话, 没有 Type Hints 之前的 10 多年, 大家照样写的飞起)
4. 一次性的脚本, 用完就扔(厕纸代码, 活不过明天). 没必要脱裤子放屁.
个人选择:
1. 作为写了比较久 python 的( py2.5 开始的), CPyUG 说不加 Type Hints 的人不少. 很正常.(在很多场景, 不用, 也都对)
2. 加当然好, 但是要平衡成本和收益. (年轻人, 容易沉迷于写太多没 转化率(不赚钱) 的代码)
3. 我日常会加, 但保持克制. (少用和不用 Pydantic, 有开销).
4. python 已经不是我的主力语言, 用 python 更多是为了快速糊东西和验证技术/产品原型. 一旦验证通过, 很快就会迁移到 rust, go 等重写. 所以, 写 python, 就更追求 怎么快, 怎么来. (代码活不久, 没必要写太好)
以上来自 写了 10 多年 python 的开发者的一点看法.
(当然, mojo 1-2 周, 就要发布了, 喜欢写 Type Hints, 来写 mojo 吧)
免杠指南:
我只是说了 不加/少加 的场景, 你要杠, 你对.
Select Language