分类 Python 下的文章

反复检查，代码无任何问题。
直接使用python解释器也能正常启动，但是在vsc里用code runner插件运行就报错。

PS E:\PythonDevelopFiles\GUI-n2n> python -u "e:\PythonDevelopFiles\GUI-n2n\app.py"
Traceback (most recent call last):
  File "e:\PythonDevelopFiles\GUI-n2n\app.py", line 3, in <module>
    from tkinter import *
  File "C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\lib\python3.9\tkinter\__init__.py", line 37, in <module>
    import _tkinter # If this fails your Python may not be configured for Tk

Windows的Python安装包默认是会安装tkinter的，接着我发现我居然有两个可选解释器

2023-01-27T19:39:36.png
第二个貌似是不久前为了编译n2n安装choco包管理器后使用choco安装的，打开控制面板\程序\程序和功能，发现确实还有个
Python Launcher 3.9.7686.0，大概是两个注册环境产生冲突了。所以手动运行了其中一个的安装工具进行配置选择修复，果不其然发现tk/tcl是扫描到的修复项目。
接着发现问题没有解决，并且在windows目录下手动找到了一些乱七八糟的pyhton文件残留。
索性重新安装python3.8 （为了兼容Windows7）
接着问题依旧，连从外部运行也出现报错：文件名、目录名或卷标语法不正确。

我人麻了，Windows真的不适合开发。。。。配置开发环境可用性还要用户手动去保证，商店下的py3.8还这个德行。我不想在微软阿三的粪坑上浪费时间了，直接重启到Debian11
sudo apt install python3-tk #Debian11已经预装Python3了，但是没有预装tk。

Linux下Python的tkinter库是单独打包的。（因为非开发者通常不需要下载tk即可运行常见的的各类应用，即使某些有需要，其打包时也会写明对python3-tk的依赖。

VSC启动.....

[Running] python -u "/tmp/tempCodeRunnerFile.python"
/bin/sh: 1: python: not found

[Done] exited with code=127 in 0.008 seconds

好吧，Code Runner 默认用的是python这个命令调用的，手动建立个软链接就好了。
或者...sudo apt install python-is-python3 #我更喜欢使用包管理器，而不是让自己手动制造哪些我可能在未来忘记或产生疑问的非常规因素。
VScode 启动，右键 Run Code
窗口出现，继续开发。

尾声：祝愿不可靠的MS Windows早点从中国广大用户的PC里滚蛋，哪怕使用不被看好的国产Linux发行版也比这种屎山生态的不可控专有软件更有利于国家发展。

PS：今天早上把应用商店的Python3.8卸载掉，果断choco install python3安装了最新版，功能一切正常，问题解决。

RIME（中州韵输入法引擎）是由佛振开发的自由软件，以 BSD-3-Clause license开源。RIME存在多个平台分支，包括Windows、darwin和Linux，以及Android四个主要平台分支。

作为一款自由软件，RIME的主要分支大都支持导出词库配置快照，因此有机会实现备份。
预定方案：使用Python编写，对需要同步的文件使用Webdav协议连接自建或坚果云Webdav等服务商进行同步，UI方案使用Python自带的Tkinter。（暂时对安卓开发无能为力）

设计目的是方便在H&G里打狙。顺带一提，我忘了怎么制作外挂了(也许写的出挂我就用不上这个了)。

功能要素

  1. 一个小准星，几个像素点聚集在一个点的就可以。
  2. 按键调整是否显示
  3. 按键调整准星位置
  4. 保持准星在游戏画面内稳定显示不过渡遮挡按钮

预期实现方法

python3 tkinter 像素级超小带色无边框窗口

具体实现：

from contextlib import suppress
from tkinter import *
from keyboard import *
root=Tk()
root.title("crosshair")
x = round(root.winfo_screenwidth()/2-2)
y = round(root.winfo_screenheight()/2-2)
root.geometry("4x4+{}+{}".format(x,y))
root.resizable(0,0)
root.overrideredirect(True)
root.config(bg="#7cfc00")
root.lift()
root.attributes("-topmost", True) #保持准星窗口在顶层
root.wm_attributes('-topmost', 1)
hook_key("end", root.destroy)
def autoadjust():
    x = round(root.winfo_screenwidth()/2-2)
    y = round(root.winfo_screenheight()/2-2)
    root.geometry("4x4+{}+{}".format(x, y))

hook_key("home",autoadjust)

root.mainloop()
print("hello")
unhook_all()

运算符描述实例
+=加法赋值运算符c += a 等效于 c = c + a
-=减法赋值运算符c -= a 等效于 c = c - a
*=乘法赋值运算符c *= a 等效于 c = c * a
/=除法赋值运算符c /= a 等效于 c = c / a
%=取模赋值运算符c %= a 等效于 c = c % a
**=幂赋值运算符c **= a 等效于 c = c ** a
//=取整除赋值运算符c //= a 等效于 c = c // a

列举部分占位符

%d是整数的占位符
%f是小数的占位符
%%表示百分号（因为百分号代表了占位符，所以带占位符的字符串中要表示百分号必须写成%%）

一、 使用占位符%格式化

按序罗列式 适用于python2.6前,沿用至今 延用了C语言的输出格式
a=1.1
b=2
print("有两个数，分别是浮点数a= %f 和整数b= %d" %(a,b))

这种写法，必须在后方按照顺序罗列准备用于替换占位符的变量名称，能不能在前面直接指定用于替换的变量名称呢？

二、 使用format格式化

官方推荐 python2.6新增，沿用至今
格式：str.format
a=1.1
b=2
print("有两个数，分别是浮点数a= {}和整数b= {}".format(a,b)) 
# {key}称为索引，索引为空{}时,按照顺序从后方取值，可以使用01234这样的顺序的数字作为索引进行排序。
print("有两个数，分别是浮点数a= {0}和整数b= {1}".format(a,b))
# 也可以直接使用一个特定名称作为索引。
print("有两个数，分别是浮点数a= {num_a}和整数b= {num_b}".format(num_a=a,num_b=b))
# 你也可以把变量a,b替换为一个单引号包括的字符串，如：'1.1'

以上三个print语句都输出：有两个数，分别是浮点数a= 1.1和整数b= 2

三、 f-string格式化

直接指定式 适用于Python >= 3.6
f-string是在字符串前面加上 "f"，{}直接使用变量、表达式等。
a=1.1
b=2
print(f"有两个数，分别是浮点数a= {a:.1f}和整数b= {b:d}")
# 为啥加个.1而不是直接写{a:f} ？f前面的.1指的是保留小数点后一位小数，不写.1输出的就是：1.100000

The Zen of Python, by Tim Peters

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.
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!