安装Win10 四月更新后,L2TP VPN停止工作的解决办法

问题症状:

控制面板/VPN:”无法建立计算机与 VPN 服务器之间的网络连接,因为远程服务器未响应。这可能是因为未将计算机与远程服务之间的某种网络设备配置为允许VPN连接”

应用程序事件日志中,记录有错误代码809

日志名称:          Application

来源:            RasClient

日期:            2018/5/19 8:10:04

事件 ID:         20227

任务类别:          无

级别:            错误

关键字:           经典

用户:            暂缺

计算机:           *********

描述:

CoId={0AE16132-E9E5-47CE-8989-FC9CB343AF96}: 用户 ***** 已进行名为 ****的拨号连接,该连接已失败。失败后返回的错误代码为 809。

问题原因:

IPSec加密被禁用

解决办法:

以管理员账号身份修改以下注册表,然后重启电脑

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters]

“ProhibitIpSec”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent]

“AssumeUDPEncapsulationContextOnSendRule”=dword:00000002

[翻译作品]PEP 518——指定构建Python项目的最低系统要求

注:PEP = Python Enhancement Proposal (Python增强建议书,即Python开发规范)

摘要

本PEP详细说明了Python软件包要在选定的构建(Build)系统上运行时,应该如何指定其依赖关系。本规范引入了一个新的配置文件,用于指定软件包的构建依赖关系(假定今后的配置会使用相同的配置文件作为参考)。

基本原理

当Python首次开发用于构建项目软件分发的工具时,distutils [1]是选定的解决方案。随着时间的推移,setuptools [2]越来越流行,它在distutils的基础上增加了一些功能。两者都应用了setup.py文件这样一个概念。项目维护人员通过执行这个文件来构建其软件的发行版(使得用户也能够安装上述发行版)。

distutils是Python标准库的一部分,所以,使用一个可执行文件来指定distutils下的构建条件是没有问题的。将构建工具作为Python的一部分意味着,项目维护人员如果要构建一个项目的发行版,无需担心setup.py有哪些外部依赖项。唯一的依赖项只是Python,因此没有必要指定任何依赖信息。

但是当一个项目选择使用setuptools时,像setup.py这样的可执行文件的使用就成了一个问题。你无法在不知道setup.py文件依赖关系的条件下执行它。可是,目前还没有标准的方法,在不执行存储着依赖信息的setup.py文件的情况下,自动地了解它具体有哪些依赖项。这就形成了一个悖论:你不运行这个文件,你就无法知道它的内容;你不知道这个文件的内容,就无法运行它。

setuptools尝试用它的setup() 函数的setup_requires参数来解决这个问题[3]。 此解决方案有许多问题,例如:

  • 除了setuptools本身,没有工具可以在不执行setup.py的情况下访问这些信息,但是如果不安装这些项目,setup.py将无法执行。
  • 尽管setuptools本身会安装setup.py中列出的一切,但在执行setup() 函数期间,它们将不会被安装,这意味着实际使用此处添加的任何东西的唯一方法是通过越来越复杂的机制来延迟导入和使用,直到后来执行setup() 函数为止。
  • 该方案不包括setuptools本身,也不能包括setuptools的替代品,这意味着像numpy.distutils这样的项目很大程度上无法利用它,项目不能利用较新的setuptools功能,直到用户自然地将setuptools的版本升级到较新的版本。
  • setup_requires中列出的项目只要执行setup.py就会被安装,但执行setup.py的常见方式是通过另一个工具,比如已经负责管理依赖关系的pip。 这意味着像pip install spam这样的命令可能最终导致pip和setuptools下载和安装软件包,最终,用户需要配置这两个工具(并且不受控制调用的setuptools)来更改它安装的存储库等设置。 这也意味着用户需要了解这两种工具的发现规则,因为每个工具可能支持不同的软件包格式或以不同方式确定最新版本。

这导致了setup_requires很少被人使用的情况,在这种情况下,项目倾向于只是在多个setup.py文件之间复制和粘贴代码片段,或者完全跳过,仅仅只在某个地方记录好–希望用户在尝试建立或安装他们的项目之前,已经手动安装好的内容。

所有这一切使得pip [4]假定在执行setup.py文件时setuptools是必需的。但问题在于,如果另一个项目像setuptools那样开始在社区中获得关注,这个项目就没有可扩展性。如此一来,会阻止其他项目获得应有的关注。因为当pip无法推断出项目需要的是除setuptools以外的某个东西时,使用setuptools便会产生冲突。

本PEP试图在特定文件中、以一种声明式的方式显式列出项目构建系统的最小依赖关系,从而解决当前的状况。此举允许项目列出它必须具有何种构建依赖关系。例如,源代码签出到wheel,同时不落入setup.py所形成的悖论中。即,工具无法推断项目需要自行构建的东西。实施本PEP将允许项目预先指定他们依赖的构建系统,以便像pip这样的工具可以确保所有依赖条件已经安装,以便运行构建系统来进行构建。

为了提供更多的上下文和推动本PEP,可以把所需的(大体)步骤看成是生成一个手工项目的过程:

  1. 项目的源代码签出
  2. 构建系统的安装
  3. 构建系统的运行

本PEP涵盖了第2步。 预计未来的PEP将包括第3步,包括如何使构建系统动态指定构建系统执行其工作所需的更多依赖性。 但是,本PEP的目的是为构建系统指定要开始运行所需的最低要求。

规范

构建系统的依赖关系将存储在一个名为pyproject.toml的文件中,该文件以TOML格式编写[6]。选择这种格式是因为它可供人来使用(不像JSON [7]),它足够灵活(不像configparser [9])起源于某个标准(也不像configparser [9]),不过于复杂(不像YAML [8])。 TOML格式已被Rust社区用作其包管理器的一部分[14],据私人电邮所述,他们对选择TOML感到非常满意。关于为什么不选择各种替代品的更详细的讨论可以阅读以下其他文件格式的部分。

在配置文件中将会有一个[build-system]表来存储与构建相关的数据。最初,表中只有一个关键字是有效的和必需的:requires。该键将包含一个字符串列表的值,代表执行构建系统所需的PEP 508依赖体哦阿健(意味着执行setup.py文件需要哪些依赖条件)。

以下的JSON架构[15]将与数据格式匹配,表示了某个特定类型的结果数据。这些数据来自于仅供演示用的TOML文件:

PEP 518——指定构建Python项目的最低系统要求

对于绝大多数依赖setuptools的Python项目,pyproject.toml文件会是这个样子:

[build-system]

# Minimum requirements for the build system to execute.

requires = [“setuptools”, “wheel”] # PEP 508 specifications.

由于目前社区中setuptools和wheel的使用非常广泛,所以当pyproject.toml文件不存在时,构建工具将使用上面的示例配置文件作为它们的默认语义。

所有其他顶级密钥和表格保留供将来由其他PEP使用,但[工具]表格除外。 在该表中,只要工具使用[tool]中的子表,工具就可以指定配置数据,例如, 该快速工具会将其配置存储在[tool.flit]中。

我们需要一些机制来在工具中分配tool.*命名空间中的名称,以确保不同的项目不会尝试使用相同的子表并发生冲突。 我们的规则是项目可以使用子表工具。$ NAME当且仅当他们拥有Cheeseshop / PyPI中的$ NAME条目时。

一些未接受的想法

语义版本密钥

为了将来验证配置文件的结构,最初提出了语义版本密钥。 默认为1,这个想法是,如果任何语义更改为先前定义的键或表发生不向后兼容,则语义版本将增加到一个新的数字。

但最终却认定这是一个不成熟的优化。 期望的是,在配置文件中对语义上预先定义的内容的更改将是相当保守的。 在发生向后不兼容的变化的情况下,可以使用不同的名称作为新的语义,以避免破坏旧的工具。

一个嵌套更深的命名空间

这个PEP的早期草案有一个顶级[包]表。 这个想法是为语义版本方案强加一些范围(请参阅语义版本关键字为什么这个想法被拒绝)。 由于需要删除范围,因此拥有顶级表的重要性变得多余。

其他表名

[build-system]表的另一个名字是[build]。 替代名称较短,但并未表达信息存储在表中的意图。 在distutils-sig邮件列表上进行投票后,当前名称才能胜出。

其他文件格式

提出了其他几种文件格式供考虑,都因各种原因而被拒绝。 关键要求是该格式可以由人进行编辑,并且具有可以通过项目轻松销售的实施。 这彻底排除了某些格式,如对人类不友好的XML,而且从未认真讨论过。

JSON

JSON格式[7]最初被考虑但很快被拒绝。 尽管作为基于字符串的人类可读的数据交换格式非常好,但语法本身并不适合人类轻松编辑(例如,语法比所需的更冗长而不允许评论)。

提议的数据的示例JSON文件将是:

PEP 518——指定构建Python项目的最低系统要求

YAML

YAML格式[8]被设计为JSON的超集[7],同时更易于手工操作。 YAML有三个主要问题。

一个是规范太多:如果打印在letter尺寸的纸上,则为86页。这就使得有人可能会使用YAML的功能与一个解析器一起工作,而不是另一个解析器。有人建议在一个子集上进行标准化,但这基本上意味着要创建一个特定于该文件的新标准,这个标准是不容易长期处理的。

二是YAML默认本身并不安全。该规范允许在处理配置数据时最好避免代码的任意执行。当然可以避免这种行为 – 例如,PyYAML提供了一个safe_load操作 – 但是如果任何工具不小心使用load,那么它们会自行开启任意代码执行。虽然这个PEP专注于构建固有涉及代码执行的项目,但其他配置数据(如项目名称和版本号)最终可能会在相同的文件中随意执行任意代码。

最后,最流行的YAML的Python实现是PyYAML [10],它是一个包含几千行代码的大型项目,也是一个可选的C扩展模块。虽然本身并不一定是个问题,但对于像pip这样的项目来说,这更像是一个问题,因为他们很可能需要将PyYAML作为依赖项供应商,以便完全独立(否则,最终会导致您安装需要安装工具的工具才能正常工作)。 PyYAML的一个概念验证重新工作已经完成,看看有多容易的可能供应一个简单版本的库,这表明它是一种可能性。

一个YAML示例文件:

build: requires: - setuptools - wheel>=0.27

Configparser

一个基于configparser INI风格配置文件考[9]。 不幸的是,没有关于什么configparser接受的规范,导致版本之间的支持倾斜。 例如,Python 2.7中的ConfigParser接受的内容与Python 3中的configparser接受的内容不同。 虽然可以标准化Python 3接受的内容,并简单地供应configparser模块的backport,但这确实意味着此PEP必须编码,所有项目希望使用configparser的backport才能使用此PEP指定的元数据。 这是过度限制性的,如果有人不知道预期特定版本的configparser会导致混淆。

一个示例INI文件是:

[build]

requires =

setuptools

wheel>=0.27

Python文字

有人提议使用Python文字作为配置格式。 该文件将在顶层包含一个字典,数据全部在该字典中,并且由键定义部分。 所有的Python程序员都会习惯这种格式,隐含的情况是没有第三方依赖来读取配置数据,如果用ast.literal_eval()进行解析,它可能是安全的[13]。 Python文字可以与JSON相同,同时支持尾随逗号和注释。 另外,Python的更丰富的数据模型可能对未来的某些配置需求非常有用(例如非字符串字典密钥,浮点数与整数值)。

另一方面,python文字是Python特有的格式,并且预计这些数据可能需要通过不是用Python编写的打包工具等来读取。

提议数据的Python文字文件示例如下:

# The build configuration

{“build”: {“requires”: [“setuptools”,

“wheel>=0.27”, # note the trailing comma

# “numpy>=1.10” # a commented out data line

]

# and here is an arbitrary comment.

}

}

其他文件名称

其他几个文件名在考虑后并未接受(这是一个非常相似的话题,最终决定主要是根据喜好)。

pysettings.toml

最合理的选择。

pypa.toml

虽然参考PyPA [11]是有道理的,但这是一个有点用处的术语。没有特定领域的知识,最好让文件名有意义。

pybuild.toml

从这个PEP的限制性角度来看,这个文件名是有意义的,但是如果有任何非构建元数据被添加到文件中,那么名称就不再有意义了。

pip.toml

工具特定。

meta.toml

太通用;项目可能希望拥有自己的元数据文件。

setup.toml

在保持setup.py的传统感谢的同时,它不一定与未来文件可能包含的内容相匹配(例如,.e.g知道项目名称是否是其设置的一部分?)。

pymeta.toml

新手对编程和/或Python不太明显。

pypackage.toml&pypackaging.toml

命名“什么是包”(项目与命名空间)的合并。

pydevelop.toml

该文件可能包含非特定于开发的细节。

pysource.toml

与源代码没有直接关系。

pytools.toml

由于该文件(当前)针对项目管理,因此具有误导性。

dstufft.toml

个体相关性太大

原文地址:https://www.python.org/dev/peps/pep-0518/

译者:首席IT民工

[翻译作品]数字背后的故事:Python社区2017/2018年发展趋势

本文透过大量收集自Python开发者调查的数据,揭示了有关Python编程语言的最新使用情况和发展轨迹。

Python正变得越来越受欢迎,在科技新闻中引起了人们更多的关注。有报道说,更多的女高中生们正在将Python应用于计算机工程的学习;Python被推荐为大学计算机入门课程的编程语言。 此外,Stack Overflow的2018年开发者调查显示,Python是大多数人想学习的编程语言。 Python被广泛用于网络,从简单的个人网站,到全世界大型银行里的数据挖掘和机器学习。

是什么让Python如此特别? Python开发者是哪些人? 它为什么如此受欢迎? 为了回答这些以及其他许多重要的问题,JetBrains和Python软件基金会(Python Software Foundation,PSF)合作,针对使用Python作为主要或次要语言的人群开展了一项调查。 到目前为止,还没有人做过针对Python的专项研究,以期了解不同开发人员是如何使用它的,有哪些组件促进了它的使用,以及是什么让它成为了最受欢迎的语言之一。

我们调查的目标是确定Python的最新趋势,并一窥Python开发界的全貌。抱着这一目的,我们着手研究了以下问题:

  • Python 3最新的普及率是多少?
  • Python是怎样和其他语言一起使用的?
  • 什么样的项目会用到Python?
  • Python用户的主要开发类型有哪些?
  • 最流行的技术和工具是什么?
  • 最常见框架和库有哪些,以及它们是如何相辅相成的?
  • Python开发者是一群什么样的人?

该调查于2017年10月发布。这里是我们对结果所做的汇总,你也可以从Python开发者调查2017年结果的网站上挖掘更多的图表和原始数据。

方法论

在我们查看相关数据和见解之前,有必要回顾一下调查所采取的方法,包括:调查是如何派发的,采取了哪些措施来避免潜在的偏见,并确保调查不倾向于任何特定的工具,技术,库,或者国家。

我们将调查发送给几个独立的团体,包括订阅了PSF邮件列表,博客,Slack,LinkedIn和Twitter的人员。我们还在一些访问量最大的Python.org页面上推广了该项调查,并通过阅读文档进行了公布。大部分回复(62%)来自Python.org上的广告横幅;其他主要来源是PSF博客和Twitter帖子。我们没有利用产品、服务或供应商相关的渠道,以防止调查结果倾向于任何特定的工具或技术。

调查深受社区的欢迎,回复率超过预期。在开放期间,收到的回复超过了1万份。我们在做调查分析时过滤掉了不完整和重复的回复,留下来的数据集包括了来自150多个国家的9,532名应答者。对于如此大的样本,描述统计误差的保守置信区间仅为1%,意味着所有结果都具有统计显著性。我们实现了调查的主要目标:收到了准确可靠的数据!

Python开发者画像

开启Python世界之旅的第一步,让我们来聊聊最令人兴奋的事儿 — 和Python语言及其应用程序相比,Python社区也呈现出同样的多元化。

虽然Python用户的年龄范围很广,但是大多数受访者的年龄在20岁左右,四分之一在30多岁。有趣的是,几乎五分之一的Python用户年龄在20岁以下。如果我们将Python开发人员的年龄范围,与Stack Overflow在其最新调查中确定的一般开发人员的年龄范围进行比较,分布情况比较相似。区别在于,Python调查中,年龄在18岁以下的开发者稍微多一些。原因在于,很多中学和大学的学生在使用Python,而且Python常常被选作第一门语言。

超过一半的受访者是全职的开发人员,每五名开发人员中就有一位担任数据分析师,架构师,或团队负责人。与Stack Overflow的调查相比,我们可以看到:Python开发者比一般开发者更少可能全职工作(52%的Python开发人员与74%的开发人员),更有可能为自己工作,或成为自由职业者(Python开发人员占13%,所有开发人员占9.7%)。

Python调查的受访者呈现出各种不同的经验; 22%的人拥有不到一年的经验,超过11年经验的人也是这个比例,而在这两者之间的分布趋于平滑。这表明新手和经验丰富的开发人员之间保持了良好的平衡,使Python成为了可持续发展的语言。

值得注意的是,Python比其他语言的平均新手比例高得多。 根据Stack Overflow数据,30%的开发人员拥有不到两年的专业经验,而Python开发人员调查中的这一比例为41%。

大型的Python开发团队中并不多见。 在我们的调查中,56%的Python开发人员表示他们独立开发项目,40%的人通常在2到7人的团队中工作。 大约一半的受访者在从事一个主要项目的同时还有几个小项目,而四分之一的人则一次只从事一个项目。

2016年,JetBrains在没有PSF参与的情况下举办了一次Python开发者调查。 虽然JetBrains在2016年的样本规模很大,但其调查主要通过自己的渠道进行推广,这自然吸引了PyCharm用户中的更大份额 – 约50%的PyCharm用户和50%的使用其他编辑器的用户。 为了减少不可避免的偏差,2016年的调查没有比较不同代码编辑器的用户数量。 尽管2016年的调查结果存在偏差,仍然值得比较一下2017年和2016年的一些调查结果。 例如,在2016年的调查中,45%的人表示独立完成自己的项目,51%的人则是团队工作。 2017年调查中的这一比例不同也许是因为,有大量的新手,且Python是他们的第一语言,以及数据科学家的数量和现在使用Python的Web开发者的数量旗鼓相当。

Python工作机会

正如我们上面所写的,在Stack Overflow的2018年开发者调查中,Python是最理想的语言(即调查者最有兴趣学习的语言);这是Python连续第二年获得该排名。 Python用户在排名最高的编程语言中排名第三。这些事实与Python就业市场是什么关系呢?

尽管Python开发人员调查并未专门提出工作受欢迎度,但我们可以从Python开发人员需要的其他资源中,收集世界范围内的各种工作信息。包括机器学习,数据库,数据分析,云基础设施,设计,站点可靠性/测试,网络抓取,安全性,移动开发,API等等。根据jobs.python.org上列出的职位,机会倾向于国际化需求,尤其是在英国地区。

在任何主要求职网站搜索“Python开发人员”,往往会返回数千个就业机会。 2018年3月,美国Python开发者在美国的平均工资(根据实际数据)为115,835美元。这么高的平均工资表明,许多公司正在竞相雇佣知识渊博的Python开发人员。这进一步说明Python确实是一种广受欢迎的技能。

Python与美国最好的工作 — 数据科学也有关系(基于2018年4月的Glassdoor.com)。大约五分之一的数据科学工作涉及Python,包括NumPy,Pandas和Matplotlib库。

Python使用情况

几乎五分之四的Python开发者认为Python是他们的主要语言,比JetBrains 2016年调查的75%增加了4%。

各种研究表明,Python开发人员的数量以及使用Python作为主要语言的开发人员的份额正在逐年稳步增长。 在Stack Overflow的调查中,Python的受欢迎程度从2017年初的32%上升到今年年底的38.8%。 这可以通过Python数据科学的迅速普及来解释,因为这部分用户的增长速度远远快于其他用户。

Python经常与其他语言一起使用:

所有使用Python作为主要语言的开发人员中有一半还使用JavaScript。 79%的网页开发人员使用JavaScript,但只有39%涉及数据分析或机器学习。

对于那些使用Python作为辅助语言的用户来说,细分情况略有不同,因为使用JavaScript(46%)和更多使用C / C ++(42%),Java(41%)和C#(24%)的用户较少。

Python开发类型

为了确定最流行的Python开发类型和它们的交集,我们提出了两个类似的问题:“你用Python做什么?” 受访者可以选择多个答案,以及“你最喜欢用Python干什么?” 受访者只能选择一个答案。 结果显示,科学方面的开发现在像网络开发一样受欢迎:有一半的受访者从事数据科学项目,另一半是网站开发。

根据受访者是否使用Python作为主要或次要语言,回复有所不同:使用Python作为其主要语言的人中有54%参与了Web开发,而那些认为Python是其次要语言的人中有33%参与了Web开发。 这种差异对于数据分析,机器学习和其他类型的开发来说不太重要。

许多Python开发人员扮演多种角色。 他们承担最多的角色有:

数据分析和机器学习的交叉是预料之中的,网络开发和数据分析/机器学习之间的交叉却值得关注。

当被问及他们从事的主要开发类型时,26%的Python用户选择网页开发,超出了数据分析的范围(据报道为18%)。

但是,如果我们将18%进行数据分析的人与9%主要角色是机器学习的人结合起来,那么我们知道27%的人主要从事科学开发。 这意味着数据科学家使用Python的人数与网络开发人员数量一样多。

有趣的是,当JetBrains在2016年进行了Python开发者调查时,有38%的受访者认定为Web开发人员,只有21%认为是科学开发人员。 这可能是Python开发人员数据科学家迅速增长的证据。

比较使用Python作为主要语言与辅助语言的趋势之间的趋势,网站发展差距最大(29%为主,15%为次要)。 数据分析和机器学习的差别要小得多。 相反,更多的DevOps和系统管理员使用Python作为辅助语言(13%)而不是主要语言(8%)。

数据科学占据了Python第一吗?

Python开发者调查中,最令人感兴趣的问题是Python世界中,网络开发者与数据科学家的比例。 我们要求受访者估算使用Python的网络开发人员和数据科学家之间的比例。 受访者可以根据自己的经验,看法和一般“直觉”来回答。 因为我们明确地询问了开发的类型,并且样本规模足够大以具有统计显著性,所以我们可以将社区的看法与现实进行比较。

更多受访者(57%)认为网络开发者比数据科学家更普遍,而只有33%认为相反。

根据之前部分显示的数据(26%网络开发,27%科学开发为主要活动),真实的比例是1:1。

只有九分之一的受访者猜对了这一点; 大多数人低估了Python数据科学用户的数量。 Web开发通常被认为是Python的主要应用。 虽然这在几年前是真的,但Python数据科学家的数量正在快速增长,并且已经与Web开发人员的数量保持一致。

Python 2与Python 3

我们问,“你使用最多的是Python的哪个版本?” Python 3遥遥领先,是75%,而使用Python 2作为主要解释器的仅占25%。 Python 3正在迅速增长; 在2016年的调查中,60%的人使用Python 2和40%的Python 3. Python 2的使用正在下降,因为它没有得到积极发展,没有获得新的功能,并且在2020年后不再维护。

值得注意的是,70%的网络开发人员使用Python 3,而数据分析师中有77%,机器学习专家中有83%。 这可能是因为许多Web开发人员在转换到Python 3时仍需要维护遗留代码,并且许多数据分析师和机器学习专家最近才加入Python生态系统,直接选择了Python 3。

我们还询问开发人员他们如何安装和更新他们的Python文件。

70%的人从python.org安装Python,或者使用操作系统提供的软件包管理器,如APT和Homebrew。

Python框架,库和技术

Django是最流行的框架; 41%的Python开发人员使用它。

科学软件包,如NumPy,Pandas和Matplotlib合在一起紧随其后,达到39%。 其他流行的框架和库有Requests,Flask,Keras / Theano / TensorFlow / Scikit-learn等。 TensorFlow和Django在StackOverflow的最受喜爱和最需要的技术之列。

Django被76%的Web开发人员选为第一框架,而在数据科学领域工作的人中只有31%。 奇怪的是,29%的网页开发人员正在使用科学库。 这证实了两个角色之间的巨大重叠。

当被问及除Python以外的技术时,Jupyter Notebook的排名最高为31%,考虑到大量数据科学开发人员,这很有意义。 Docker仅以29%的速度落后2%。 按角色拆分,Docker被47%的参与Web开发的人使用,只有23%的数据科学家使用Docker。 同样,Web开发人员使用Amazon Web Services,Google App Engine,Heroku等云平台的频率是数据科学家的两倍。

比较2016年的调查结果和2017年的调查结果,Django和Flask这两个最流行的Web框架已经丢失了一些份额。 (2016年,Django的使用率为51%,2017年为41%; 2016年的Flask使用率为40%,2017年为32%)。 同时,科学库和技术框架的使用也在增长。 2016年,Anaconda,NumPy和Matplotlib(合并)的使用率为36%; 在2017年底,NumPy,Pandas,Matplotlib,SciPy和类似项目的使用率为39%,Anaconda使用率为25%。

当被问及他们使用哪种云平台时,云使用受访者首先将AWS排在了67%。 Google App Engine,Heroku和DigitalOcean的使用要少得多。 AWS在Stack Overflow的调查中也高度评价最喜爱和最受欢迎的平台。 我们可以列出的云平台的可能回答很有限; “其他”类别收集了13%的响应,包括Linode,PythonAnywhere,OpenShift和OpenStack。

Python开发的工具和特色

当我们询问在Python开发中对于开发实践,工具和功能的使用时,回复最多的地方是代码自动完成,代码重构,编写单元测试以及使用Python项目的虚拟环境。 NoSQL数据库,Python分析器和代码覆盖工具是最罕用的。 这些结果与2016年的数据非常相似:

为了找出最受欢迎的编辑器和IDE,我们提出了两个问题:“您在Python开发中考虑过哪些编辑器/ IDE?” 并允许多个答案,以及一个单一答案的问题,“你当前Python开发使用的主要编辑器是什么?” 基于对这个问题的8,000多个回复,PyCharm是最流行的工具,其次是Sublime,Vim,IDLE,Atom和VS Code。

注:我们采取了大量步骤来消除偏见,并确保调查不倾向于使用任何特定的工具。 要详细了解调查方法以及用于分派调查的渠道,请参阅调查结果网站的原始数据部分。

Web开发人员在编辑器的喜好上与数据科学家略有不同。 Web开发人员非常喜欢PyCharm专业版,Sublime文本和Vim,而数据科学家显然更喜欢PyCharm社区版,Jupyter Notebook和Spyder。

当我们问道:“在Python编程中,你考虑过哪些编辑器/集成开发环境?” 我们了解到Web开发人员考虑最多的是Sublime Text(47%),其次是Vim(39%)和Atom(32%)。 科学开发人员最常考虑Jupyter Notebook(42%),其次是PyCharm社区版(39%),崇高文本(31%)和Vim(26%)。

我们还发现,大多数开发人员每天都使用他们的编辑器,大约五分之一每周使用他们的编辑器。

调查的原始数据

与Python及其社区的开源哲学一致,我们已经向公众提供了原始数据,我们欢迎进一步的分析和结论。我们打算在2018年和未来几年重复这项调查。我们的目标是让每年的调查差不多,以便完成纵向的数据分析。

在解析原始数据之前,请注意以下几点:数据是匿名的,没有个人信息或地理位置详情。此外,对所有开放式领域进行了裁剪,以防止通过逐字评论来识别任何个人受访者。为了帮助他人更好地理解调查的逻辑,我们用英语共享数据集,调查的问题和所有调查逻辑。我们使用不同的排序方法来回答选项(字母,随机,直接)。每个问题中都指定了使用答案选项的顺序。

我们很乐意了解您的发现!请在Twitter或其他提供@ jetbrains和@ThePSF的社交媒体上与#pythondevsurvey2017#标签分享。我们也乐于接受建议和反馈,以便下次改进。欢迎在这里提出任何意见或问题。

关键要点

2017年Python开发者调查表示了社区的基准。一些更重要的关键点有:

  • Python 3的普及率已经达到了75%,并且在迅速增长。
  • 目前从事数据科学和web开发的Python开发者一样多,但是Python在数据科学家中的迅速增长可能很快会打破这一平衡。
  • 使用Python的每5位开发者中,有4位使用Python作为主要语言。
  • Django,NumPy,pandas和Matplotlib是Python开发人员最常用的框架和库。 Jupyter Notebook和Docker是Python使用最受欢迎的技术。 AWS是最受欢迎的云平台。
  • PyCharm,Sublime,VIM,Atom和VS Code是最常用的Python编辑器。
  • 一半使用Python作为主要语言的人也使用JavaScript和HTML / CSS。 Python也经常用于SQL,Bash / Shell,C / C ++和Java。

我们希望调查结果阐明了Python开发者社区的现状,让你纵览全局,并解答了一些疑问。

[翻译作品]Python ipaddress 模块之概述

原文地址:https://dbader.org/blog/python-ipaddress-module

作者:Jon Crawfurd

副标题:本文介绍了Python 3.3以上版本中用于处理IPv4和IPv6地址的ipaddress模块。

在本文中,我们会看一看Python 3.3及更高版本中提供的ipaddress模块。 本教程旨在为想知道如何在Python中解析和使用IP地址的网络工程师们提供一个简要参考。

在这篇概述中,你将了解到:

  • IPv4和IPv6地址之间的区别是什么
  • 如何使用Python的ipaddress模块处理IPv4地址
  • 如何使用Python的ipaddress模块处理IPv6地址

IPv4与IPv6地址 – 入门知识

从大的方面来说,IPv4地址和IPv6地址具有相同的目的和功能。但是,由于每个协议的地址结构存在很大差异。本教程用了不同的部分,来分别讨论IPv4和IPv6。

当今的互联网中,IPv4协议承担了绝大部分的IP处理任务,在不久的将来也依旧如此。 尽管IPv6所带来的规模和功能方面的增强对未来互联网不可或缺,正在被逐步应用,但是到目前为止,应用率仍然很低。

一个IPv4地址由32位组成,分为四个“八位组”。 “八位组”一词用于标识一个八位结构来代替更常见的术语“字节”,但它们的定义相同。四个八位组被称为octet1,octet2,octet3和octet4。这是一个“点分十进制”格式,其中每个八位组对应一个从0到255的十进制值。

IPv4地址示例:192.168.100.10

IPv4地址示例(CIDR表示法):192.168.100.10/24

“/24”是CIDR表示法,表示32位的前24位用于标识地址的网络部分。 记住每个八位组长度为8位,这意味着前三个字节(3×8 = 24)标识网络(192.168.100.x),地址的其余八位标识节点(x.x.x.10)。

CIDR表示法可以是从 /8位 到 /30位的任何值,偶尔有 /32位(/31无效),但通常使用/24。 例如,你的家庭网络,或你的学校或公司网络很可能用/24 CIDR来表示。

用于表示网络标识的早期术语是子网掩码,其中CIDR表示为单独的点分十进制数。 例如,一个/24 CIDR相当于一个网络掩码255.255.255.0。

IPv6地址长度为128位,与IPv4地址中的32位相比,有显著的增加。 IPv4和IPv6之间有很多不同之处,但最大的区别在于寻址结构。 额外的长度提供了可支持的网络和主机数量的指数级增长。

IPv6地址示例:2001:db8:abcd:100::1/64

在IPv4地址使用点分十进制格式的情况下,IPv6协议使用十六进制表示法。 IPv6地址中的每个位置表示4个位,其值从0到f,按以下方式组织:

  • 128位被分成8组,每组16位,每组由冒号分隔。一个组被称为4个十六进制字符(4个十六进制字符乘以4位= 16位)的“四重组”或“十六位组”。在上面的例子中,第一个四重组是“2001”。
  • 任何四重组中的头部的0会被去除/压缩。在上面的例子中,第二个四重组是“db8”,实际上是“0db8”“,最开头的0被去掉了。最后一个四重组是“1”,实际上是“0001”“,三个头部0被压缩了。
  • 如果一个四重组包含全零,它将被压缩为一个零。例如:具有“:0000:”的四重组将被压缩为“:0:”。
  • 如果一个地址包含一个连续的全部为零的四重组,则连续的零被压缩并用双冒号表示。在上面的例子中,双冒号表示3个全部为零的四重组,或者“:0000:0000:0000:”浓缩为“::”。由于范例的地址有5个有值的四重组,所以压缩以后的四重组的数量肯定是3个(总数减8)。

所有的IPv6地址结构都使用CIDR表示法来确定有多少前导位用于网络标识,其余部分则用于主机/接口标识。考虑到是128位,产生的组合有很多。

Python的ipaddress模块和IPv4地址

ipaddress模块是按照CIDR表示法设计的,由于其简洁易用,受到人们的推荐。 ipaddress模块还包含了一些方法,用于在必要的情况下还原子网掩码。

IPv4地址的最初定义中包含一个“类”,这个“类”由第一个八位组中的地址范围所定义。 ipaddress模块不识别IPv4类,故在本教程中不会涉及。

ipaddress模块包含三个特定的IPv4地址对象类型:

  • 一个“主机”,或一个不包含CIDR表示法的独立的地址对象
  • 包含CIDR表示法的单个接口地址对象
  • 以及一个网络地址对象,指的是整个网络的IP地址范围。

“主机”和“接口”之间的主要区别在于主机或ip_address对象不包含CIDR表示法,而ip_interface对象包含CIDR表示法:

  • 处理不需要或不使用CIDR表示法的IP数据包时,ip_address对象最为有用。
  • 当使用节点和接口标识来连接到必须包含网络/子网标识的IP网络时,ip_interface对象最管用。
  • ip_network对象包含网络中的所有地址,并且对于网络标识非常有用。

用ipaddress创建IPv4主机地址对象

ipaddress.ip_address() 工厂函数用于创建ip_address对象。它会根据传入的值自动确定是创建IPv4还是IPv6地址(IPv6地址将在本教程的后面部分讨论)。 如上所述,这个对象表示一个数据包在穿越不需要CIDR的网络的过程中,所发现的IP地址。

在多数情况下,用于创建ip_address对象的值将是一个字符串,格式为IPv4点分十进制,如图所示:

image.png

或者,IPv4地址可以以二进制形式输入,如完整32位二进制值的十进制值,或按照此例,以十六进制格式输入:

image.png

第一个例子使用完整的32位地址,第二个例子是32位地址的十进制值。 两者都很笨拙,容易出错且没什么太大的价值。 第三个示例使用十六进制值,这可能很有用,因为解析或嗅探中的大多数数据包,都以十六进制格式表示。

用ipaddress创建IPv4接口地址对象

ipaddress.ip_interface() 工厂函数用于创建ip_interface对象,该对象根据传入的值自动确定是创建IPv4还是IPv6地址(IPv6地址将在本教程的后面部分讨论)。

如前所述,ip_interface对象表示在正确处理数据包所需的CIDR(或掩码)所在的主机或网络接口上找到的IP地址。

image.png

在创建ip_interface选项时可以使用与ip_address选项(二进制,十进制值,十六进制)相同的选项。 但是,唯一通过CIDR表示法或掩码来有效创建ip_interface的办法,是使用点分十进制IPv4地址字符串。

用ipaddress创建IPv4网络地址对象

ipaddress.ip_network()工厂函数用于创建ip_network对象,该对象根据传入的值自动确定是创建IPv4还是IPv6地址(IPv6地址将在本教程的后面部分讨论)。

IP网络定义:包括了一个网络或子网的连续IP地址范围。 例如:

  • 192.168.100.0/24是192.168.100.0网络,其中/24指定前3个八位组组构成网络标识。
  • 第4个八位组用于分配给各个主机和路由器接口。
  • 地址范围是192.168.100.1到.254。
  • 192.168.100.0用于定义网络/子网,192.168.100.255是该网络的广播地址。 它们都不能用于分配给主机或路由器接口。

创建ip_network对象遵循与创建ip_interface对象相同的语法:

image.png

在上面的例子中,使用的网络地址必须是一个有效的网络地址,它是构成网络的IPv4地址范围中的第一个地址。 否则,Python将抛出一个异常:

image.png

在使用主机或路由器接口时,通常需要确定网络地址。 可以经由计算得出,但是需要几个步骤,可以使用strict = False选项(strict = True是默认值)在一个步骤中完成。

image.png

在上面的例子中,ip_interface地址是已知的(192.168.100.10),但不是接口所属的ip_network。 使用strict = False选项,计算ip_network地址(192.168.100.0/24)并将其填充到ip_network对象中。

Python的ipaddress模块和IPv6地址

与IPv4一样,ipaddress模块使用与IPv4相同的三种基本工厂功能。 包括:

  1. 一个“主机”,或一个不包含CIDR表示法的独立地址对象,
  2. 包含CIDR表示法的接口地址对象
  3. 以及引用整个网络的IP地址范围的网络地址对象。

由于详细信息在IPv4部分中已经介绍,在此仅作简要描述。

用ipaddress创建IPv6主机地址对象

ipaddress.ip_address() 工厂函数用于创建ip_address对象。 它会根据传入的值自动确定使用IPv6地址格式。 请注意,CIDR表示法未与ip_address函数一起使用。

在大多数情况下,用于为IPv6创建ip_address对象的值将是根据此示例的IPv6四进制/六进制格式的字符串:

image.png

与IPv4一样,可以使用完整的二进制,十进制或十六进制值创建IPv6地址对象。 对于IPv4地址,32位难以处理,而对于128位IPv6地址来说更是尴尬。 实际上,预计八个四重组表示的字符串将是一般形式。

用ipaddress创建IPv6接口地址对象

ipaddress.ip_interface() 工厂函数用于创建ip_interface对象,该对象根据传入的值自动创建IPv6地址。 请注意,函数中必须包含CIDR表示法。

image.png

用ipaddress创建IPv6网络地址对象

ipaddress.ip_network() 工厂函数用于根据传入的值为IPv6创建一个ip_network对象。

与IPv4一样,IPv6网络被定义为可分配给特定主机或路由器接口的一系列连续IP地址。

使用我们以前的示例2001:db8:abcd:100:: /64,/64 CIDR指定四个四重组构成完整的网络标识。 请记住,前三个四重组是IPS分配的全局ID,第四个四重组识别内部子网编号。 64位的余额用于从“0000:0000:0000:0001”到“ffff:ffff:ffff:fffe”的范围内的主机标识。

与IPv4寻址一样,IPv6子网中的第一个和最后一个地址不能用于主机寻址。 给定一个/ 64 CIDR,这意味着有2到2的64次方(减2)可能的主机地址,这意味着从数学角度,每个网络/子网有18,446,744,073,709,551,614个可能的主机地址。

image.png

上述全局地址分配如下:

  • 全局标识符由ISP分配:2001:db8:abcd::/48
  • 子网标识:2001:db8:abcd:100:: / 64
  • 子网中的第一个可用地址:2001:db8:abcd:100:: 1/64
  • 子网中最后一个可用地址:2001:db8:abcd:100:ffff:ffff:ffff:fffeffff / 64

更多资源

这里是一些额外的资源,以便你进一步了解Python中的ipaddress模块:

本文的扩展PDF版本以及其他信息https://dbader.org/static/img/ipaddress-module-introduction.pdf

ipaddress模块文档https://docs.python.org/3/library/ipaddress.html

ipaddress模块介绍https://docs.python.org/3/howto/ipaddress.html

维基百科 – IPv4https://en.wikipedia.org/wiki/IPv4

维基百科 – IPv6https://en.wikipedia.org/wiki/IPv6