python 100 days_[笔记]第一天Python-100-Days-master跟我一起学(01.初识Python)

写在前面的话

最近在学习python,因为我是有C#基础的,所以不会去跟视频教学,偶尔间发现了这个网站,看到了Python-100-Days-master,然后了解到很多小伙伴也在学,反映看起来有些吃力.

我先说本人不是大牛,正在成为大牛的路上,想开此贴,以记录学习进程的同时,帮助那些零基础的小伙伴,大家一起探讨.

01.初识Python

这章节的内容,应该没什么好说的,介绍了python的历史,特点,应用领域,如何配置开发环境.

重点解析:

一. python特点

1.开源,强大的社区支持

不知道小伙伴知道开源的概念不,就是写这个语言的作者,把自己的成果免费开放给全世界人民,你可以进行任意改造,用于商业用途,但不收取任何费用.

开源后,大家因为要使用和交流,一般会有社区组织,大牛们自愿贡献,开发实用的插件,促进生态圈的形成.一个语言的流行程度,跟它背后的生态支撑有很大关系的.

比如linux操作系统就是开源的,redhat,ubuntu,centos等都在其内核上修改;而windows操作系统就不是开源的.

2.解释型语言，平台可移植性

解释型语言是相对于需要编译的语言说的,比如C,我们需要先编译(build)生成可执行文件(winows下叫exe文件),)生成可执行文件,下一次需要运行时,直接)生成可执行文件即可.

由于计算机只能运行机器代码,生成的这个可执行文件,是只针对这种CPU对应的一套指令集的.其他平台就不适应,所以无法跨平台.

后来人们就想能不能有一种中间代码,能在不同的平台上执行呢,JAVA语言就是例子.生成的中间语言叫字节代码(class),不同平台有各自的虚拟机,以处理字节代码到与平台有关的机器代码转换.

这样需要编译的java也就能跨平台了.解释型语言,是不需要进行编译,在程序运行的时候,由解释器进行翻译为机器代码,因此平台不一样,对应的python解释器就会不一样.

大家安装的python3.8就是解释器,解释器一行一行解释代码,因此在IDLE中,直接输入代码,马上就能看到结果.

而每次运行,都要重新进行翻译,故效率不高.

二.python开发环境配置

这块按照教程来就好,如果看不懂,菜鸟教程里比较清晰.

我的开发环境是:Ubuntu16.04+pthon3.5+vscode

pthon3.5是系统自带的,因为我死活下不下来python3.8的源码,下一半就死,因为linux下python是提供的源码,需要自己编译生成.

如果实在还是不知道怎么整的,可以给我留言.

三.pip

这个python的模块管理工具,用来以后下载模块的.

windows下都是集成在python3.8里的,linux下要自己下载get-pip.py运行安装,这个我也是下了半天,唉,小伙伴需要的话,可以找我.

pip有个源的问题,默认是国外的一个网址,下载模块库很慢,建议改为国内的,

国内好用的镜像地址有：

1、命令行式指定镜像地址

2、配制成默认的话，需要创建或修改配置文件（linux的文件放在~/.pip/pip.conf，windows在%HOMEPATH%\pip\pip.ini，目录不存在，手动创建）

文件内容:

[global]

[install]

trusted-host = pypi.tuna.tsinghua.edu.cn

四.练习题

1. import this

在打开IDLE,输入这行代码就会出现Python之禅啦,里面都是写代码遵循的原则:

我们一起来欣赏一下吧

Zen of Python（Python之禅）

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.

能平着写,不要嵌套写,嵌套就比如,分支语句if里面套了很多层那种.

我之前看过一个新来的程序源,一个if的结束跨了几十行,里面全是各自if,这种建议使用逻辑与,放外层,不要都放里层

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.

异常不应该被静默处理,就是不要这样,catch里直接忽略了,这个后面还会涉及

try{

....

}catch{

}

return ;

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.

因为你不是那个Python之父,上面那种最佳的解决方案不是显而易见的.所以你要多花时间

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!

命名空间非常有用，我们应当多加利用,命名空间有很多用,比如分模块啊,区分变量啊等.比如:用户相关的操作,订单的操作,就可能在两个命名空间下

,用户命名空间有个UserModel,订单命名空间也有个UserModel,他们互不影响,就像两个房间一样,不是同一个.

2. 学习使用turtle在屏幕上绘制图形