《可爱的Python》读书笔记(二)

寻找吧!不要先想着创造——Python 是自足的。

继续分析昨天的内容

小白提出问题:如何读取指定光驱"E:"中的文件列表信息?

行者提出:文件是系统的事儿。

分析:系统→操作系统→operating system→os模块!

>>> import os
>>> os.listdir('E:\\')
['.discinfo', '.treeinfo', 'CentOS_BuildTag', 'EFI', 'EULA', 'GPL', 'images', 'i
solinux', 'RELEASE-NOTES-en-US.html', 'RPM-GPG-KEY-CentOS-6', 'RPM-GPG-KEY-CentO
S-Debug-6', 'RPM-GPG-KEY-CentOS-Security-6', 'RPM-GPG-KEY-CentOS-Testing-6', 'TR
ANS.TBL', '[BOOT]']

小白提出问题:如何自动地将整个光盘中的所有文件和目录信息都“一次性地扫描”出来?

小白认为:可以根据每级目录的信息再次不断调用os.listdir(),将所有层次的目录信息都逐一汇报出来。

行者提出:使用walk()

(有两个walk()分别为os.path.walk()和os.walk()前者在Python3已被移除)

# -*- coding: utf-8 -*-
import os

def cdWalker(cdrom, cdcfile):
    export = ""
    for root, dirs, files in os.walk(cdrom):
        #print(root, dirs, files)
        export += "\n %s;%s;%s" % (root, dirs, files)
        #print(export)
    open(cdcfile, 'w').write(export)
cdWalker('E:\\', 'cd1.cdc')
cdWalker('E:\\', 'cd2.cdc')

小白获得了第一个Python函数,并成功运行了两次,即将同张光盘的内容记录到2个不同的文件"cd1.cdc"和"cd2.cdc"中。

再来看看,上面的代码使用了字符串的+连接,下面是利用join。字符串的join要比+操作效率高。因为对象的反复+,比一次性内建处理,要浪费更多的资源。

# -*- coding: utf-8 -*-
import os

def cdWalker(cdrom, cdcfile):
    export = []
    for root, dirs, files in os.walk(cdrom):
        export.append("\n %s;%s;%s" % (root, dirs, files))
    open(cdcfile, 'w').write(''.join(export))
cdWalker('E:\\', 'cd3.cdc')

小练习:

读取this.txt内容,去除空行和注释行后,以行为单位进行排序,并将结果输出为TheZenofPython.txt。

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

# -*- coding: utf-8 -*-
result = []
with open('this.txt') as f:
    for line in f.readlines():                    # 依次读取每行
        line = line.strip()                       # 去掉每行头尾空白
        if line.startswith('#') or not line:      # 判断是否是空行或注释行
            continue
        result.append(line)
result.sort()                                     # 排序结果
print(result)
open('TheZenOfPython.txt', 'w').write('%s' % '\n'.join(result))  # 保存入结果文件
>>>
['Although never is often better than *right* now.', 'Although practicality beats purity.', "Although that way may not be obvious at first unless you're Dutch.", 'Beautiful is better than ugly.', 'Complex is better than complicated.', 'Errors should never pass silently.', 'Explicit is better than implicit.', 'Flat is better than nested.', 'If the implementation is easy to explain, it may be a good idea.', "If the implementation is hard to explain, it's a bad idea.", 'In the face of ambiguity, refuse the temptation to guess.', "Namespaces are one honking great idea -- let's do more of those!", 'Now is better than never.', 'Readability counts.', 'Simple is better than complex.', 'Sparse is better than dense.', "Special cases aren't special enough to break the rules.", 'There should be one-- and preferably only one --obvious way to do it.', 'Unless explicitly silenced.']

TheZenofPython.txt的内容为:

Although never is often better than *right* now.

Although practicality beats purity.

Although that way may not be obvious at first unless you're Dutch.

Beautiful is better than ugly.

Complex is better than complicated.

Errors should never pass silently.

Explicit is better than implicit.

Flat is better than nested.

If the implementation is easy to explain, it may be a good idea.

If the implementation is hard to explain, it's a bad idea.

In the face of ambiguity, refuse the temptation to guess.

Namespaces are one honking great idea -- let's do more of those!

Now is better than never.

Readability counts.

Simple is better than complex.

Sparse is better than dense.

Special cases aren't special enough to break the rules.

There should be one-- and preferably only one --obvious way to do it.

Unless explicitly silenced.

原文地址:http://blog.51cto.com/9473774/2088763

时间: 2024-10-09 23:26:32

《可爱的Python》读书笔记(二)的相关文章

JAVA读书推荐----《深入分析Java Web技术内幕》--《java多线程编程核心技术》--《大型网站技术架构 核心原理与案例分析》-《Effective Java中文版》

(1)  首先推荐的不是一本书,而是一个博客,也是我们博客园另外一位博友java_my_life. 目前市面上讲解设计模式的书很多,虽然我前面讲了看书是最好的,但是对设计模式感兴趣的朋友们,我推荐的是这个博客.这位博友的设计模式讲得非常非常好,我认为90%的内容都是没有问题且很值得学习的,其讲解设计模式的大体路线是: 1.随便开篇点明该设计模式的定义 2.图文并茂讲解该设计模式中的结构 3.以详细的代码形式写一下该种设计模式的实现 4.补充内容 5.讲解该设计模式的优缺点 对于一个设计模式我们关

《大型网站技术架构-核心原理与案例分析》之一: 大型网站架构演化

最近刚刚读完李智慧的<大型网站技术架构-核心原理与案例分析>,对每章重点内容作了一些笔记,以便加深印象及日后查阅. 一.大型网站软件系统的特点 高并发,大流量:需要面对高并发用户,大流量访问. 高可用:系统7X24小时不间断服务. 海量数据:需要存储.管理海量数据,需要使用大量服务器. 用户分布广泛,网络情况复杂:许多大型互联网都是为全球用户提供服务的,用户分布范围广,各地网络情况千差万别. 安全环境恶劣:由于互联网的开放性,使得互联网站更容易受到攻击,大型网站几乎每天都会被黑客攻击. 需求快

大型网站技术架构--核心原理和案例分析 大型网站架构演化(一)

如果把上世纪90年代CERN正式发布web标准和第一个WEB服务的出现当作互联网的开始,那么互联网站的发展之经历了短短20多年的时间.在20多年的时间里,互联网的世界发生了变化,今天,全球有近一半的人口使用互联网,人们的生活因为互联网而产生了巨大的变化.从信息检索到即使通信,从电子购物到文化娱乐,互联网渗透到生活的每一个 角落,而且这种趋势还在蔓延.因为互联网,我们的世界正变得越来越小. 同时我们也看到,在互联网跨越式发展进程中,在电子商务火热的市场背后却是不堪重负的网站架构.某些B2C网站逢促

《大型网站技术架构核心原理与案例分析》阅读笔记-01

通过阅读该书籍我们能够更加清楚的树立大型网站的的技术发展历程,剖析大型网站技术架构模式,深入的讲述大型互联网架构核心原理,并通过一些典型的技术案例来讲述大型网站开发全景视图,该书籍深入的阐述了各种大型网站面临的各种架构问题及解决方案. 在第一章第一篇大型网站架构演化中了解到与传统企业应用系统相比,大型互联网应用系统具有高并发大流量.高可用性.海量数据.用户分布广泛,网络情况复杂.安全环境恶劣.需求快速变更,发布频繁.渐进式发展等特点:大型网站架构演化发展历程经历了初始阶段的网络架构它的应用程序.

大型网站技术架构-核心原理与案例分析

阿里系的书,也是讲大型网站系统架构的,平常我们总是挂在嘴边的高性能.高可用.易扩展.安全性,这些所谓的系统非功能性指标到底如何实现,书里面讲了这些干货,作为网站架构师或者哪怕是应用系统的架构师,都值得了解,也许不一定都能用上,但是等需要用的那天,你肯定不会迷茫. 1.大型网站架构发展常见历程:应用/数据库分离--->使用缓存--->应用服务器集群--->数据库读写分离--->CDN及反向代理--->使用分布式文件系统和分布式数据库--->NoSQL及搜索引擎--->

【大型网站技术架构 核心原理与案例分析】读书笔记

章节 笔记 1.概述 网站架构模式:分层.分割.分布式.集群.缓存.异步.冗余.自动化.安全. 核心架构要素:性能.可用性.伸缩性.扩展性.安全. 4.高性能 一般重复请求一万次计算总响应时间然后除以一万得到单词响应时间. 测试程序并不是启动多线程然后不停发送请求,而是在两次请求之间加入一个随机等待时间. 吞吐量:每天通过收费站的车辆数目:并发数:正在行驶的车辆数目:响应时间:车速.TPS:每秒事务数:HPS:每秒请求数:QPS:每秒查询数. 性能计数器:System Load(系统负载,最理想

大型网站技术架构-核心原理与案例分析-阅读笔记4

在第四章案例章节中的淘宝网的架构演化案例分析小节中作者主要分析了淘宝架构的演化,以淘宝网的实例给我们分析介绍了淘宝网的业务发展历程及淘宝网的技术架构演化两个方面,在业务发展中作者写到淘宝的技术是随着淘宝业务一起发展起来的,业务是推动这技术发展的动力,淘宝如今的规模和当初有很明显的变化,在技术架构演化中介绍了架构技术的更新升级,该章节中主要介绍淘宝网的发展的历程,在随着时间的发展不断中网站的架构不断的引用着新的技术,由最初简单的c2c更改过来的网站,放弃了lamp架构转而使用java作为开发平台并

大型网站技术架构-核心原理与案例分析-阅读笔记3

在第二章的架构章节中的 随机应变:网站的可拓展架构的篇章中作者介绍了构建网站的可扩展架构.利用分布式队列降低系统的耦合性.利用分布式可复用的业务平台.可拓展的数据结构.利用开放平台建设网站生态圈五个方面,作者在讲述前通过微信的成功发布及其中摇一摇功能的加入的开发的快捷引出来的,其中构建网站的可扩展架构中区分了扩展性和伸缩性的区别,讲到了低耦合性的系统跟容易扩展,并且更容易复用,一个低耦合性的系统也可以让系统更加容易的开发和维护,在如何降低系统的耦合性中,作者主要介绍用分布式消息队列的方法来降低系

大型网站技术架构-核心原理与案例分析-阅读笔记5

在第四章案例章节中的海量分布式存储系统Doris的高可用架构设计分析的小节中作者主要分析介绍了分布式存储的高可用架构和不同故障情况下的高可用解决两个方面,在两小节前作者给我们介绍了Doris是一个海量分布式KV存储系统,其设计的目的是支持中等规模高可用.可伸缩的Kv存储群.跟主流的NoSQL系统HBase相比,doris具有相似的性能和线性伸缩能力,并具有更好的可用性及更友好的图形用户管理界面.而在分布式存储的高可用架构的小节中作者给我们分析了Doris的整体架构,其系统整体上可分为应用程序服务

学习笔记8:《大型网站技术架构 核心原理与案例分析》之 固若金汤:网站的安全架构

一.网站攻击与防御 攻击: 1.XSS攻击:危险字符转义,HttpOnly 2.注入攻击:参数绑定 3.CSRF(跨站点请求伪造):Token,验证码,Referer Check 4.其他漏洞攻击 Error Code HTML 注释 文件上传 路径遍历 防御: 1.Web应用防火墙:ModSecurity 2.网站安全漏洞扫描 二.信息加密技术与密钥管理 1.单向散列加密 2.对称加密 3.非对称加密 4.密钥安全管理 三.信息过滤与反垃圾 1.文本匹配:正则,Trie算法,多级Hash,降噪