Python需要一个CPyAN [英] Python needs a CPyAN
问题描述
我是一个非常满意的Python用户，已经花了很多年b / b
。我永远不会愿意使用其他语言。我希望所有的好东西都可以用于Python，这让我想起了一些关于
Python未来前景的想法。
我提出Python使用的未来扩展受限于
Python缺乏类似CPAN的工具，我提交的内容没有
CPyAN Python永远不会接近达到Perl目前所享有的广泛使用的程度。
在说这个时，我并没有错误地发布Python'' ;电池包括
哲学或标准库。标准库是Python的最大优势之一。标准库是Python的'宝石'
in the crown"我全心全意地赞同Andrew Kuchling最近提出的建议，即我们将精力放在改进上。
但是标准库有限制。你不能将
_everything_放入标准库中，也不想。
将永远是许多专门的模块，不应该被放入
标准库中，新的模块一直在开发。
这些不在标准的库模块 - 让我们称之为外部
模块 - 是语言增长的关键，它的受欢迎程度，以及
最终是它的长期生存。对外部模块的支持越好，它们的使用就越活跃，并且重新使用了b $ b（更重要的是）。如果外部模块支持良好，那么开发人员可以轻松地创建基于现有外部模块的b / b
的外部模块，然后创建更高级别的
外部模块构建在这些模块上，直到创建了一个非常大的存档非常强大的外部模块。有了这样的外部模块存档，只需几行代码即可完成非常复杂，非常专业的b $ b任务。
请注意，成功的关键不在于存档的大小。 CPAN没有成功，因为它很大。相反，它很大，因为它是成功的。 CPAN只是其次的模块集合。
CPAN是一组*功能*：存储功能，
记录，检查更新，搜索，下载，测试，
并安装外部模块。它包括支持创建
模块测试和文档。它是一个社交组织 -
CPAN测试人员组 - 保证CPAN模块的质量保证至少达到最低水平（因此信任） 。 CPAN
（图书馆）很大，因为CPAN（外部模块支持
机制）功能强大且易于使用。
不要说Python不需要CPy，因为我们已经获得了Google，或者我们已经获得了SourceForge，或者我们已经获得了PyPI或者distutils
或Parnassus的保险库。即使一起使用，所有这些工具仍然没有达到CPAN的能力。只有完整的CPyAN才能提供外部模块的质量和易用性，这将使Python在未来十年蓬勃发展。
这并不是说Python会在没有CPyAN的情况下死掉。这将是b $ b肯定能够幸存并茁壮成长。但它仍然是一种利基语言。
如果没有CPyAN，Python的使用和Python社区永远不会和
永远不会增长到甚至可以接近于大小
of Perl。
有些人可能会反对Python不与Perl竞争，或者说
人气和规模不应该成为目标：那个更小更好的应该是我们的目标。但我认为这种受欢迎程度是一个目标。问任何他/她的第一个希望是什么的Python程序员，你会得到
回复：我希望我能找到一份工作，我可以在Python中花费我所有的时间（或者甚至是我的时间）编程。对这个愿望唯一的答案是受欢迎程度;这些工作不会存在，直到Python
变得更受欢迎。 （第二个愿望是利他主义的，专业的b $ b：我希望我可以说服我的组织使用Python，因为
Python真的是一个更好的技术，而我的组织确实需要它。
需要它。而这个愿望的答案也在于让Python更加受欢迎。
对于那些珍惜标准库的人，以及为了避免需要访问CPAN甚至琐碎的事情而转向Python
的人，我们可以说：
赢了不要改变。标准库将保持与
一样强大; CPYAN将补充但不能取代它。
对于那些对Perlish所有内容感到厌恶的人，我说：CPAN
是一个很棒的系统，无论是谁发明了它。这是关于Perl的最好的事情。在Python折衷主义的伟大传统中，让'b
窃取它！
因为CPyAN是Python长期发展的关键，创造a
CPyAN应该是Python软件基金会优先级中最高的 - 也许是最高的 - 之一。因此，我想建议Python软件基金会专门针对开始构建CPyAN的提案发布RFP（请求
提案）。
建立一个CPyAN将是一项重要工作，毫无疑问。但我认为，对于Python社区和Python软件基金会来说，它应该是
是第一职业。
- Stephen Ferg（st***@ferg.org）
参考文献：
a非常翔实的关于CPAN的帖子作者：Sean Reifschneider /> http://groups.google.com/groups?hl=e...hon.org&rnum=6
$ b $ Hans Nowak的帖子
http://groups.google.com/groups?hl=e....nl%26rnum%3D8
google clp for像CPAN这样的东西
http://groups.google.com/groups?q=%2...ff=1&scoring=d
目录SIG的要求
http://www.python.org/sigs/catalog-s...uirements.html
I am a very satisfied user of Python and have been for number of
years. I would never willing use another language. I wish all good
things for Python, and that moves me to express some thoughts about
Python''s future prospects.
I submit that the future expansion of Python usage is constrained by
Python''s lack of a CPAN-like facility, and I submit that without a
CPyAN Python will never even get close to achieving the degree of
widespread usage that Perl currently enjoys.
In saying this, I am not faulting Python''s "batteries included"
philosophy or the standard library. The standard library is one of
Python''s greatest strengths. The standard library is Python''s "jewel
in the crown" and I whole-heartedly endorse Andrew Kuchling''s recent
proposal that we focus our energies on improving it.
But there are limits to a standard library. You can''t put
_everything_ into a standard library, nor would you want to. There
will always be many specialized modules that shouldn''t be put into a
standard library, with new modules being developed all the time.
These not-in-the-standard-library modules -- let''s call them external
modules -- are the keys to a language''s growth, its popularity, and
ultimately its long-term survival. The better the support for
external modules is, the more actively that they will be used and
(more importantly) re-used. If external module support is good, that
makes it easy for developers to create external modules built on top
of existing external modules, and then to create even higher-level
external modules built on those, until a very large archive of very
powerful external modules is created. With such an archive of
external modules, it is possible to do very complex, very specialized
tasks with only a few lines of code.
Note that the key to success is not the size of the archive. CPAN is
not a success because it is large. Rather, it is large because it is
a success. CPAN is only secondarily a collection of modules.
Primarily, CPAN is a set of *capabilities*: capabilities for storing,
documenting, checking for updates, searching, downloading, testing,
and installing external modules. It includes support for creating
module tests and documentation. And it is a social organization --
the CPAN testers group -- that guarantees at least a minimal level of
quality assurance for (and therefore trust in) modules in CPAN. CPAN
(the library) is large because CPAN (the external module support
mechanism) is powerful and easy to use.
It is no good saying that Python doesn''t need a CPyAN because we''ve
got Google, or we''ve got SourceForge, or we''ve got PyPI or distutils
or the Vaults of Parnassus. Even used together, all of these tools
still fall short of the capabilities of CPAN. Only a full CPyAN will
provide the quality and ease-of-use of external modules that will
enable Python to flourish in the coming decade.
This is _not_ to say that Python will die without a CPyAN. It will
certainly survive and thrive. But it will remain a niche language.
Without a CPyAN, Python usage and the Python community can never and
will never grow to a size that even comes close to rivalling the size
of Perl.
Some might object that Python is not in a race with Perl, or that
popularity and size shouldn''t be goals: that smaller and better should
be our goal. But I submit that popularity _is_ a goal. Ask any
Python programmer what his (or her) first wish is, and you will get
the reply: "I wish I could have a job in which I could spend all of my
time (or even, _some_ of my time) programming in Python." The only
answer to that wish is popularity; such jobs won''t exist until Python
becomes more popular. (The second wish is an altruistic, professional
one: "I wish I could convince my organization to use Python, because
Python really is a better technology, and my organization really does
need it." And the answer to that wish, too, lies in making Python
more popular.)
To those who treasure the standard library, and who switched to Python
to escape the need to visit CPAN for even trivial things, we can say:
that won''t change. The standard library will remain as strong as
ever; CPyAN will supplement but not replace it.
To those who shrink in revulsion from everything Perlish, I say: CPAN
is a great system, regardless of who invented it. It is the best
thing about Perl. In the great tradition of Python eclecticism, let''s
steal it!
Because a CPyAN is key to the long-term growth of Python, creating a
CPyAN should be one of the highest -- perhaps THE highest -- of the
Python Software Foundation''s priorities. Therefore, I would like to
suggest that the Python Software Foundation issue an RFP (request for
proposal) specifically for proposals to start building a CPyAN.
Building a CPyAN will be a big job, no question. But I think that for
the Python community and for the Python Software Foundation, it should
be job number one.
-- Stephen Ferg (st***@ferg.org)
REFERENCES:
a very informative post on CPAN by Sean Reifschneider
http://groups.google.com/groups?hl=e...hon.org&rnum=6
a post by Hans Nowak
http://groups.google.com/groups?hl=e....nl%26rnum%3D8
google c.l.p for "something like CPAN"
http://groups.google.com/groups?q=%2...ff=1&scoring=d
requirements for the catalog SIG
http://www.python.org/sigs/catalog-s...uirements.html
推荐答案
Peter Hickman< pe *** @ semantico.com>写道：
Peter Hickman <pe***@semantico.com> writes:
Ville Vainio写道：
Ville Vainio wrote:
我认为你这里有点夸张CPAN。这不是一个绝对的要求，我认为即使没有CPAN功能，Python也可以很容易地超越Perl。一般来说Perl的受欢迎程度似乎有所下降，我不认为Perl会再担心了。天啊，这些天人们很少甚至都提到Perl
。
I think you are overselling CPAN a little bit here. It is not an
absolute requirement, and I think Python can easily surpass Perl in
popularity even without CPAN functionality. Perl popularity in general
seems to be going down, and I don''t think Perl is something to worry
about anymore. Hell, people rarely even mention Perl these days
anyway.
就在今天，我们需要一个未安装在我们系统上的模块。
sudo perl -MCPAN -e''安装Data :: Pager''
Just today we required a module that was not installed on our system.
sudo perl -MCPAN -e ''install Data::Pager''
使用PyPI和distutils，我们已经有90％。 PyPI需要
增加一个指向tarball的链接，以及一种将包名转换为
链接的方法。然后你需要一个捆绑了Python的工具，它从
PyPI获取链接，下载包，然后运行python setup.py install。
如果你想勇敢一点，你可以尝试从PyPI页面中删除
下载链接，然后在该页面上查找
tarball的链接。
< mike
-
Mike Meyer< mw*@mired.org> http://www.mired.org/home/mwm/
独立的WWW / Perforce / FreeBSD / Unix顾问，电子邮件以获取更多信息。
With PyPI and distutils, we''ve got 90% of that already. PyPI needs to
grow a link to the tarball, and a way to turn a package name into that
link. Then you need a tool bundled with Python that gets the link from
PyPI, downloads the package, and runs "python setup.py install".
If you wanted to be brave about it, you could try scraping the
download link out of the PyPI page, then look for the link to the
tarball on that page.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
[Stephen Ferg]
[ ...想要一个CPYAN ......]
[John Roth]
[Stephen Ferg]
[ ... wants a CPyAN ...]
[John Roth]
Python Package Index如何不满足这个需求？
我可以想到一个非常严重的区别，它阻止我在PPI中放置一个模块。
How does the Python Package Index not meet this need?
I can think of one very serious difference, which has
kept me from placing a module in the PPI.
嗯。 ..关心让我们参与其中？虽然你的微妙暗示对于那些提交包裹的人来说可能有意义
，但我怀疑我会为更多我们没有的人说过
。你有什么反对意见？
-John Hazen
Ummm... Care to let us in on it? While your subtle hint may make sense
to those who have submitted packages for inclusion, I suspect I speak
for the many more of us who haven''t. What''s your objection?
-John Hazen
John Hazen写道：
John Hazen wrote:
嗯...关心让我们参与其中？
Ummm... Care to let us in on it?
错字，他可能意味着
"我想不到......
typo, he probably meant
"I can''t think of a ..."
这篇关于Python需要一个CPyAN的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
