pep

[Python进阶] Python定义类方法

你。 提交于 2019-12-09 20:04:13
Python中的几种定义类方法:常规方式,@property修饰方式,@classmethod修饰方式,@staticmethod修饰方式。 class Test(object): def __init__(self): self.name = 'eappo' def fun(self, x): print('self:', self, x) @property def property_fun(self): print('@property', self, self.name) @classmethod def class_fun(cls, x): print('@classmethod cls:', cls, x) @staticmethod def static_fun(x): print('@staticmethod', x) if __name__ == '__main__': a = Test() a.fun('fun') a.property_fun a.class_fun('class_fun') a.static_fun('static_fun') 运行结果: self: <__main__.Test object at 0x0000023DC8BAD208> fun @property <__main__.Test object at

Coding style (PEP8) - Module level “dunders”

烂漫一生 提交于 2019-12-08 14:39:52
问题 Definition of "Dunder" ( D ouble under score): http://www.urbandictionary.com/define.php?term=Dunder I have a question according the placement of module level "dunders" (like __all__ , __version__ , __author__ etc.) in Python code. The question came up to me while reading through PEP8 and seeing this Stack Overflow question. The accepted answer says: __author__ is a global "variable" and should therefore appear below the imports. But in the PEP8 section Module level dunder names I read the

x002-语言元素

前提是你 提交于 2019-12-08 02:58:25
变量命令规则 硬性规则: 变量名由字母(广义的Unicode字符,不包括特殊字符)、数字和下划线构成,数字不能开头。 大小写敏感(大写的 a 和小写的 A 是两个不同的变量)。 不要跟关键字(有特殊含义的单词,后面会讲到)和系统保留字(如函数、模块等的名字)冲突。 PEP 8要求: 用小写字母拼写,多个单词用下划线连接。 受保护的实例属性用单个下划线开头。 私有的实例属性用两个下划线开头。 a = 100 b = 12.345 c = 1 + 5j d = 'hello, world' e = True print(type(a)) # <class 'int'> print(type(b)) # <class 'float'> print(type(c)) # <class 'complex'> print(type(d)) # <class 'str'> print(type(e)) # <class 'bool'> 来源: https://my.oschina.net/u/3635512/blog/3138732

x001-版本介绍

倖福魔咒の 提交于 2019-12-07 14:39:59
python版本介绍 目前有2 和 3 有很多企业用的代码是2版本,随着技术的发展,以后用3的会成为大趋势 python3的安装 yum -y install wget gcc zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libpcap-devel xz-devel libffi-devel wget https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tgz tar -xvf Python-3.7.3.tar 编译 cd Python-3.7.3 ./configure --prefix=/usr/local/python37 --enable-optimizations make && make install 修改用户目录下名为.bash_profile的文件,配置PATH环境变量并使其生效 ... 此处省略上面的代码 ... export PATH=$PATH:/usr/local/python37/bin ... 此处省略下面的代码 ... source .bash_profile 使用 root@jenkins:/data/Python-3.7

x001-版本介绍

你说的曾经没有我的故事 提交于 2019-12-07 00:24:29
python版本介绍 目前有2 和 3 有很多企业用的代码是2版本,随着技术的发展,以后用3的会成为大趋势 python3的安装 yum -y install wget gcc zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libpcap-devel xz-devel libffi-devel wget https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tgz tar -xvf Python-3.7.3.tar 编译 cd Python-3.7.3 ./configure --prefix=/usr/local/python37 --enable-optimizations make && make install 修改用户目录下名为.bash_profile的文件,配置PATH环境变量并使其生效 ... 此处省略上面的代码 ... export PATH=$PATH:/usr/local/python37/bin ... 此处省略下面的代码 ... source .bash_profile 使用 root@jenkins:/data/Python-3.7

Which implementation of OrderedDict should be used in python2.6?

故事扮演 提交于 2019-12-05 06:10:56
As some of you may know in python2.7/3.2 we'll get OrderedDict with PEP372 however one of the reason the PEP existed was because everyone did their own implementation and they were all sightly incompatible. So which one of the 8 current implementations in the PEP is backwards compatible with the 2.7 odict from python 2.7 in a way we can start using that now and depend on 2.7 in a couple of months? This package (for Python 2.4 or better) claims to be "A drop-in substitute for Py2.7's new collections.OrderedDict that works in Python 2.4-2.6.", but I have not checked that claim. 来源: https:/

How to write a pep8 configuration (pep8.rc) file?

送分小仙女□ 提交于 2019-12-03 05:40:56
问题 I found the documentation for pep8 but wasn't able to understand how to write these. I couldn't even find any examples with options other than setting max-line-length and ignore. I am trying to write a .pep8.rc file in which, among other things, I need to do the following: enable show source enable statistics enable count exclude a directory (say, for example ./random ) Can somebody answer with an example or link to one? 回答1: The preferred way is to use a setup.cfg in the top-level of the

What PEP 8 guidelines do you ignore, and which ones do you stick to? [closed]

岁酱吖の 提交于 2019-12-03 04:43:33
问题 Closed . This question is opinion-based. It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post. Closed 3 years ago . Over the years, the more Python I write, the more I find myself agreeing with most of the guidelines, though I consistently and intentionally break some for my own reasons. I'd be curious to know what in PEP 8 (or other PEPs too maybe) people religiously stick to and why, and

What PEP 8 guidelines do you ignore, and which ones do you stick to? [closed]

核能气质少年 提交于 2019-12-02 17:53:15
Over the years, the more Python I write, the more I find myself agreeing with most of the guidelines, though I consistently and intentionally break some for my own reasons. I'd be curious to know what in PEP 8 (or other PEPs too maybe) people religiously stick to and why, and what people find inconvenient or inadequate. In my case (and at work in general), there's only a handful of things we deviate from: Underscore separated lowercase names, I can see the point of it, as it will unfailingly be consistent, but we tend to use lowerCamelCase, even if it will occasionally introduce some

how to avoid python numeric literals beginning with “0” being treated as octal?

这一生的挚爱 提交于 2019-12-01 16:27:34
I am trying to write a small Python 2.x API to support fetching a job by jobNumber , where jobNumber is provided as an integer. Sometimes the users provide a jobNumber as an integer literal beginning with 0, e.g. 037537 . (This is because they have been coddled by R, a language that sanely considers 037537==37537 .) Python, however, considers integer literals starting with "0" to be OCTAL, thus 037537!=37537 , instead 037537==16223 . This strikes me as a blatant affront to the principle of least surprise, and thankfully it looks like this was fixed in Python 3---see PEP 3127 . But I'm stuck