Mailman 3 November 2014 - Python-checkins

cpython (3.4): context is keyword-only
by benjamin.peterson 30 Nov '14

30 Nov '14

https://hg.python.org/cpython/rev/086a21998db2 changeset: 93663:086a21998db2 branch: 3.4 parent: 93661:4b00430388ad user: Benjamin Peterson <benjamin(a)python.org> date: Sat Nov 29 23:38:17 2014 -0500 summary: context is keyword-only files: Doc/library/xmlrpc.client.rst | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Doc/library/xmlrpc.client.rst b/Doc/library/xmlrpc.client.rst --- a/Doc/library/xmlrpc.client.rst +++ b/Doc/library/xmlrpc.client.rst @@ -34,7 +34,7 @@ .. class:: ServerProxy(uri, transport=None, encoding=None, verbose=False, \ allow_none=False, use_datetime=False, \ - use_builtin_types=False, context=None) + use_builtin_types=False, *, context=None) .. versionchanged:: 3.3 The *use_builtin_types* flag was added. -- Repository URL: https://hg.python.org/cpython

1 0

cpython (3.4): add context parameter to xmlrpclib.ServerProxy (#22960)
by benjamin.peterson 30 Nov '14

30 Nov '14

https://hg.python.org/cpython/rev/4b00430388ad changeset: 93661:4b00430388ad branch: 3.4 parent: 93655:e4b986350feb user: Benjamin Peterson <benjamin(a)python.org> date: Sat Nov 29 23:32:57 2014 -0500 summary: add context parameter to xmlrpclib.ServerProxy (#22960) Patch by Alex Gaynor. files: Doc/library/xmlrpc.client.rst | 9 +++++++-- Lib/xmlrpc/client.py | 15 ++++++++++++--- Misc/NEWS | 2 ++ 3 files changed, 21 insertions(+), 5 deletions(-) diff --git a/Doc/library/xmlrpc.client.rst b/Doc/library/xmlrpc.client.rst --- a/Doc/library/xmlrpc.client.rst +++ b/Doc/library/xmlrpc.client.rst @@ -34,7 +34,7 @@ .. class:: ServerProxy(uri, transport=None, encoding=None, verbose=False, \ allow_none=False, use_datetime=False, \ - use_builtin_types=False) + use_builtin_types=False, context=None) .. versionchanged:: 3.3 The *use_builtin_types* flag was added. @@ -63,7 +63,9 @@ portion will be base64-encoded as an HTTP 'Authorization' header, and sent to the remote server as part of the connection process when invoking an XML-RPC method. You only need to use this if the remote server requires a Basic - Authentication user and password. + Authentication user and password. If an HTTPS url is provided, *context* may + be :class:`ssl.SSLContext` and configures the SSL settings of the underlying + HTTPS connection. The returned instance is a proxy object with methods that can be used to invoke corresponding RPC calls on the remote server. If the remote server supports the @@ -127,6 +129,9 @@ :class:`Server` is retained as an alias for :class:`ServerProxy` for backwards compatibility. New code should use :class:`ServerProxy`. + .. versionchanged:: 3.4.3 + Added the *context* argument. + .. seealso:: diff --git a/Lib/xmlrpc/client.py b/Lib/xmlrpc/client.py --- a/Lib/xmlrpc/client.py +++ b/Lib/xmlrpc/client.py @@ -1323,6 +1323,11 @@ class SafeTransport(Transport): """Handles an HTTPS transaction to an XML-RPC server.""" + def __init__(self, use_datetime=False, use_builtin_types=False, *, + context=None): + super().__init__(use_datetime=use_datetime, use_builtin_types=use_builtin_types) + self.context = context + # FIXME: mostly untested def make_connection(self, host): @@ -1336,7 +1341,7 @@ # host may be a string, or a (host, x509-dict) tuple chost, self._extra_headers, x509 = self.get_host_info(host) self._connection = host, http.client.HTTPSConnection(chost, - None, **(x509 or {})) + None, context=self.context, **(x509 or {})) return self._connection[1] ## @@ -1379,7 +1384,8 @@ """ def __init__(self, uri, transport=None, encoding=None, verbose=False, - allow_none=False, use_datetime=False, use_builtin_types=False): + allow_none=False, use_datetime=False, use_builtin_types=False, + *, context=None): # establish a "logical" server connection # get the url @@ -1393,10 +1399,13 @@ if transport is None: if type == "https": handler = SafeTransport + extra_kwargs = {"context": context} else: handler = Transport + extra_kwargs = {} transport = handler(use_datetime=use_datetime, - use_builtin_types=use_builtin_types) + use_builtin_types=use_builtin_types, + **extra_kwargs) self.__transport = transport self.__encoding = encoding or 'utf-8' diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -36,6 +36,8 @@ Library ------- +- Issue #22960: Add a context argument to xmlrpclib.ServerProxy constructor. + - Issue #22915: SAX parser now supports files opened with file descriptor or bytes path. -- Repository URL: https://hg.python.org/cpython

1 0

cpython (merge 3.4 -> default): merge 3.4 (#22960)
by benjamin.peterson 30 Nov '14

30 Nov '14

https://hg.python.org/cpython/rev/2a126ce6f83e changeset: 93662:2a126ce6f83e parent: 93656:4990157343c6 parent: 93661:4b00430388ad user: Benjamin Peterson <benjamin(a)python.org> date: Sat Nov 29 23:34:30 2014 -0500 summary: merge 3.4 (#22960) files: Doc/library/xmlrpc.client.rst | 11 ++++++++--- Lib/xmlrpc/client.py | 15 ++++++++++++--- Misc/NEWS | 2 ++ 3 files changed, 22 insertions(+), 6 deletions(-) diff --git a/Doc/library/xmlrpc.client.rst b/Doc/library/xmlrpc.client.rst --- a/Doc/library/xmlrpc.client.rst +++ b/Doc/library/xmlrpc.client.rst @@ -27,14 +27,14 @@ constructed data. If you need to parse untrusted or unauthenticated data see :ref:`xml-vulnerabilities`. -.. versionchanged:: 3.4.3 +.. versionchanged:: 3.5 For https URIs, :mod:`xmlrpc.client` now performs all the necessary certificate and hostname checks by default .. class:: ServerProxy(uri, transport=None, encoding=None, verbose=False, \ allow_none=False, use_datetime=False, \ - use_builtin_types=False) + use_builtin_types=False, context=None) .. versionchanged:: 3.3 The *use_builtin_types* flag was added. @@ -63,7 +63,9 @@ portion will be base64-encoded as an HTTP 'Authorization' header, and sent to the remote server as part of the connection process when invoking an XML-RPC method. You only need to use this if the remote server requires a Basic - Authentication user and password. + Authentication user and password. If an HTTPS url is provided, *context* may + be :class:`ssl.SSLContext` and configures the SSL settings of the underlying + HTTPS connection. The returned instance is a proxy object with methods that can be used to invoke corresponding RPC calls on the remote server. If the remote server supports the @@ -127,6 +129,9 @@ :class:`Server` is retained as an alias for :class:`ServerProxy` for backwards compatibility. New code should use :class:`ServerProxy`. + .. versionchanged:: 3.5 + Added the *context* argument. + .. seealso:: diff --git a/Lib/xmlrpc/client.py b/Lib/xmlrpc/client.py --- a/Lib/xmlrpc/client.py +++ b/Lib/xmlrpc/client.py @@ -1324,6 +1324,11 @@ class SafeTransport(Transport): """Handles an HTTPS transaction to an XML-RPC server.""" + def __init__(self, use_datetime=False, use_builtin_types=False, *, + context=None): + super().__init__(use_datetime=use_datetime, use_builtin_types=use_builtin_types) + self.context = context + # FIXME: mostly untested def make_connection(self, host): @@ -1337,7 +1342,7 @@ # host may be a string, or a (host, x509-dict) tuple chost, self._extra_headers, x509 = self.get_host_info(host) self._connection = host, http.client.HTTPSConnection(chost, - None, **(x509 or {})) + None, context=self.context, **(x509 or {})) return self._connection[1] ## @@ -1380,7 +1385,8 @@ """ def __init__(self, uri, transport=None, encoding=None, verbose=False, - allow_none=False, use_datetime=False, use_builtin_types=False): + allow_none=False, use_datetime=False, use_builtin_types=False, + *, context=None): # establish a "logical" server connection # get the url @@ -1394,10 +1400,13 @@ if transport is None: if type == "https": handler = SafeTransport + extra_kwargs = {"context": context} else: handler = Transport + extra_kwargs = {} transport = handler(use_datetime=use_datetime, - use_builtin_types=use_builtin_types) + use_builtin_types=use_builtin_types, + **extra_kwargs) self.__transport = transport self.__encoding = encoding or 'utf-8' diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -191,6 +191,8 @@ Library ------- +- Issue #22960: Add a context argument to xmlrpclib.ServerProxy constructor. + - Issue #22389: Add contextlib.redirect_stderr(). - Issue #21356: Make ssl.RAND_egd() optional to support LibreSSL. The -- Repository URL: https://hg.python.org/cpython

1 0

cpython (2.7): this is why tests are great
by benjamin.peterson 30 Nov '14

30 Nov '14

https://hg.python.org/cpython/rev/fee117d5c894 changeset: 93659:fee117d5c894 branch: 2.7 parent: 93657:62bd574e95d5 user: Benjamin Peterson <benjamin(a)python.org> date: Sat Nov 29 23:06:06 2014 -0500 summary: this is why tests are great files: Lib/xmlrpclib.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Lib/xmlrpclib.py b/Lib/xmlrpclib.py --- a/Lib/xmlrpclib.py +++ b/Lib/xmlrpclib.py @@ -1497,7 +1497,7 @@ ) else: chost, self._extra_headers, x509 = self.get_host_info(host) - self._connection = host, HTTPS(chost, None, context=context, **(x509 or {})) + self._connection = host, HTTPS(chost, None, context=self.context, **(x509 or {})) return self._connection[1] ## -- Repository URL: https://hg.python.org/cpython

1 0

cpython (merge 2.7 -> 2.7): merge 2.7.9 release branch
by benjamin.peterson 30 Nov '14

30 Nov '14

https://hg.python.org/cpython/rev/24f86799e9d3 changeset: 93660:24f86799e9d3 branch: 2.7 parent: 93658:f55ab5c2420f parent: 93659:fee117d5c894 user: Benjamin Peterson <benjamin(a)python.org> date: Sat Nov 29 23:06:22 2014 -0500 summary: merge 2.7.9 release branch files: Lib/xmlrpclib.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Lib/xmlrpclib.py b/Lib/xmlrpclib.py --- a/Lib/xmlrpclib.py +++ b/Lib/xmlrpclib.py @@ -1497,7 +1497,7 @@ ) else: chost, self._extra_headers, x509 = self.get_host_info(host) - self._connection = host, HTTPS(chost, None, context=context, **(x509 or {})) + self._connection = host, HTTPS(chost, None, context=self.context, **(x509 or {})) return self._connection[1] ## -- Repository URL: https://hg.python.org/cpython

1 0

cpython (2.7): add context parameter to xmlrpclib.ServerProxy (#22960)
by benjamin.peterson 30 Nov '14

30 Nov '14

https://hg.python.org/cpython/rev/62bd574e95d5 changeset: 93657:62bd574e95d5 branch: 2.7 parent: 93636:1ac5aec658f6 user: Benjamin Peterson <benjamin(a)python.org> date: Sat Nov 29 22:55:35 2014 -0500 summary: add context parameter to xmlrpclib.ServerProxy (#22960) Patch from Alex Gaynor. files: Doc/library/xmlrpclib.rst | 11 ++++++++--- Lib/xmlrpclib.py | 10 +++++++--- Misc/NEWS | 11 +++++++++++ 3 files changed, 26 insertions(+), 6 deletions(-) diff --git a/Doc/library/xmlrpclib.rst b/Doc/library/xmlrpclib.rst --- a/Doc/library/xmlrpclib.rst +++ b/Doc/library/xmlrpclib.rst @@ -39,7 +39,7 @@ For https URIs, :mod:`xmlrpclib` now performs all the necessary certificate and hostname checks by default -.. class:: ServerProxy(uri[, transport[, encoding[, verbose[, allow_none[, use_datetime]]]]]) +.. class:: ServerProxy(uri[, transport[, encoding[, verbose[, allow_none[, use_datetime[, context]]]]]]) A :class:`ServerProxy` instance is an object that manages communication with a remote XML-RPC server. The required first argument is a URI (Uniform Resource @@ -57,11 +57,13 @@ :class:`datetime.datetime` objects may be passed to calls. Both the HTTP and HTTPS transports support the URL syntax extension for HTTP - Basic Authentication: ``http://user:pass@host:port/path``. The ``user:pass`` + Basic Authentication: ``http://user:pass@host:port/path``. The ``user:pass`` portion will be base64-encoded as an HTTP 'Authorization' header, and sent to the remote server as part of the connection process when invoking an XML-RPC method. You only need to use this if the remote server requires a Basic - Authentication user and password. + Authentication user and password. If an HTTPS url is provided, *context* may + be :class:`ssl.SSLContext` and configures the SSL settings of the underlying + HTTPS connection. The returned instance is a proxy object with methods that can be used to invoke corresponding RPC calls on the remote server. If the remote server supports the @@ -131,6 +133,9 @@ *__dict__* attribute and don't have a base class that is marshalled in a special way. + .. versionchanged:: 2.7.9 + Added the *context* argument. + .. seealso:: diff --git a/Lib/xmlrpclib.py b/Lib/xmlrpclib.py --- a/Lib/xmlrpclib.py +++ b/Lib/xmlrpclib.py @@ -1478,6 +1478,10 @@ class SafeTransport(Transport): """Handles an HTTPS transaction to an XML-RPC server.""" + def __init__(self, use_datetime=0, context=None): + Transport.__init__(self, use_datetime=use_datetime) + self.context = context + # FIXME: mostly untested def make_connection(self, host): @@ -1493,7 +1497,7 @@ ) else: chost, self._extra_headers, x509 = self.get_host_info(host) - self._connection = host, HTTPS(chost, None, **(x509 or {})) + self._connection = host, HTTPS(chost, None, context=context, **(x509 or {})) return self._connection[1] ## @@ -1536,7 +1540,7 @@ """ def __init__(self, uri, transport=None, encoding=None, verbose=0, - allow_none=0, use_datetime=0): + allow_none=0, use_datetime=0, context=None): # establish a "logical" server connection if isinstance(uri, unicode): @@ -1553,7 +1557,7 @@ if transport is None: if type == "https": - transport = SafeTransport(use_datetime=use_datetime) + transport = SafeTransport(use_datetime=use_datetime, context=context) else: transport = Transport(use_datetime=use_datetime) self.__transport = transport diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -2,6 +2,17 @@ Python News +++++++++++ +What's New in Python 2.7.9? +=========================== + +*Release date: 2014-12-XX* + +Library +------- + +- Issue #22960: Add a context argument to xmlrpclib.ServerProxy. + + What's New in Python 2.7.9 release candidate 1? =============================================== -- Repository URL: https://hg.python.org/cpython

1 0

cpython (merge 2.7 -> 2.7): merge 2.7.9 release branch
by benjamin.peterson 30 Nov '14

30 Nov '14

https://hg.python.org/cpython/rev/f55ab5c2420f changeset: 93658:f55ab5c2420f branch: 2.7 parent: 93637:713e5814640d parent: 93657:62bd574e95d5 user: Benjamin Peterson <benjamin(a)python.org> date: Sat Nov 29 22:57:15 2014 -0500 summary: merge 2.7.9 release branch files: Doc/library/xmlrpclib.rst | 11 ++++++++--- Lib/xmlrpclib.py | 10 +++++++--- Misc/NEWS | 11 +++++++++++ 3 files changed, 26 insertions(+), 6 deletions(-) diff --git a/Doc/library/xmlrpclib.rst b/Doc/library/xmlrpclib.rst --- a/Doc/library/xmlrpclib.rst +++ b/Doc/library/xmlrpclib.rst @@ -39,7 +39,7 @@ For https URIs, :mod:`xmlrpclib` now performs all the necessary certificate and hostname checks by default -.. class:: ServerProxy(uri[, transport[, encoding[, verbose[, allow_none[, use_datetime]]]]]) +.. class:: ServerProxy(uri[, transport[, encoding[, verbose[, allow_none[, use_datetime[, context]]]]]]) A :class:`ServerProxy` instance is an object that manages communication with a remote XML-RPC server. The required first argument is a URI (Uniform Resource @@ -57,11 +57,13 @@ :class:`datetime.datetime` objects may be passed to calls. Both the HTTP and HTTPS transports support the URL syntax extension for HTTP - Basic Authentication: ``http://user:pass@host:port/path``. The ``user:pass`` + Basic Authentication: ``http://user:pass@host:port/path``. The ``user:pass`` portion will be base64-encoded as an HTTP 'Authorization' header, and sent to the remote server as part of the connection process when invoking an XML-RPC method. You only need to use this if the remote server requires a Basic - Authentication user and password. + Authentication user and password. If an HTTPS url is provided, *context* may + be :class:`ssl.SSLContext` and configures the SSL settings of the underlying + HTTPS connection. The returned instance is a proxy object with methods that can be used to invoke corresponding RPC calls on the remote server. If the remote server supports the @@ -131,6 +133,9 @@ *__dict__* attribute and don't have a base class that is marshalled in a special way. + .. versionchanged:: 2.7.9 + Added the *context* argument. + .. seealso:: diff --git a/Lib/xmlrpclib.py b/Lib/xmlrpclib.py --- a/Lib/xmlrpclib.py +++ b/Lib/xmlrpclib.py @@ -1478,6 +1478,10 @@ class SafeTransport(Transport): """Handles an HTTPS transaction to an XML-RPC server.""" + def __init__(self, use_datetime=0, context=None): + Transport.__init__(self, use_datetime=use_datetime) + self.context = context + # FIXME: mostly untested def make_connection(self, host): @@ -1493,7 +1497,7 @@ ) else: chost, self._extra_headers, x509 = self.get_host_info(host) - self._connection = host, HTTPS(chost, None, **(x509 or {})) + self._connection = host, HTTPS(chost, None, context=context, **(x509 or {})) return self._connection[1] ## @@ -1536,7 +1540,7 @@ """ def __init__(self, uri, transport=None, encoding=None, verbose=0, - allow_none=0, use_datetime=0): + allow_none=0, use_datetime=0, context=None): # establish a "logical" server connection if isinstance(uri, unicode): @@ -1553,7 +1557,7 @@ if transport is None: if type == "https": - transport = SafeTransport(use_datetime=use_datetime) + transport = SafeTransport(use_datetime=use_datetime, context=context) else: transport = Transport(use_datetime=use_datetime) self.__transport = transport diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -31,6 +31,17 @@ Wieland Hoffmann. +What's New in Python 2.7.9? +=========================== + +*Release date: 2014-12-XX* + +Library +------- + +- Issue #22960: Add a context argument to xmlrpclib.ServerProxy. + + What's New in Python 2.7.9 release candidate 1? =============================================== -- Repository URL: https://hg.python.org/cpython

1 0

peps: Last patch was by Akira Kitada, not Akira Li.
by guido.van.rossum 30 Nov '14

30 Nov '14

https://hg.python.org/peps/rev/c9cd9f3cc044 changeset: 5629:c9cd9f3cc044 user: Guido van Rossum <guido(a)python.org> date: Sat Nov 29 19:02:36 2014 -0800 summary: Last patch was by Akira Kitada, not Akira Li. files: pep-0008.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/pep-0008.txt b/pep-0008.txt --- a/pep-0008.txt +++ b/pep-0008.txt @@ -397,7 +397,7 @@ same. This PEP do not make a recommendation for this. Pick a rule and stick to it. When a string contains single or double quote characters, however, use the other one to avoid backslashes in the -string. It improves readability. +string. It improves readability. For triple-quoted strings, always use double quote characters to be consistent with the docstring convention in PEP 257. -- Repository URL: https://hg.python.org/peps

1 0

peps: PEP 8 section on string quotes by Akira Li.
by guido.van.rossum 30 Nov '14

30 Nov '14

https://hg.python.org/peps/rev/d3d6128fa91e changeset: 5628:d3d6128fa91e user: Guido van Rossum <guido(a)python.org> date: Sat Nov 29 19:01:24 2014 -0800 summary: PEP 8 section on string quotes by Akira Li. files: pep-0008.txt | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/pep-0008.txt b/pep-0008.txt --- a/pep-0008.txt +++ b/pep-0008.txt @@ -390,6 +390,19 @@ public and internal interfaces still apply. +String Quotes +============= + +In Python, single-quoted strings and double-quoted strings are the +same. This PEP do not make a recommendation for this. Pick a rule +and stick to it. When a string contains single or double quote +characters, however, use the other one to avoid backslashes in the +string. It improves readability. + +For triple-quoted strings, always use double quote characters to be +consistent with the docstring convention in PEP 257. + + Whitespace in Expressions and Statements ======================================== -- Repository URL: https://hg.python.org/peps

1 0

peps: Some gramatical fixes and slight rewordings
by donald.stufft 30 Nov '14

30 Nov '14

https://hg.python.org/peps/rev/6c6947dbd13f changeset: 5627:6c6947dbd13f user: Donald Stufft <donald(a)stufft.io> date: Sat Nov 29 19:21:23 2014 -0500 summary: Some gramatical fixes and slight rewordings files: pep-0481.txt | 117 +++++++++++++++++++-------------------- 1 files changed, 57 insertions(+), 60 deletions(-) diff --git a/pep-0481.txt b/pep-0481.txt --- a/pep-0481.txt +++ b/pep-0481.txt @@ -41,23 +41,22 @@ primary integration branch. This simplicity makes them very good targets for the "Pull Request" workflow that is commonly found on sites like Github. -However where PEP 474 wants to continue to use Mercurial and wishes to use an -OSS and self-hosted and therefore restricts itself to only those solutions this -PEP expands the scope of that to include migrating to Git and using Github. +However whereas PEP 474 proposes to continue to use Mercurial and restricts +itself to only solutions which are OSS and self-hosted, this PEP expands the +scope of that to include migrating to Git and using Github. The existing method of contributing to these repositories generally includes generating a patch and either uploading them to bugs.python.org or emailing them to peps(a)python.org. This process is unfriendly towards non-comitter -contributors as well as making the process harder than it needs to be for -comitters to accept the patches sent by users. In addition to the benefits -in the pull request workflow itself, this style of workflow also enables -non techincal contributors, especially those who do not know their way around -the DVCS of choice, to contribute using the web based editor. On the committer -side the Pull Requests enable them to tell, before merging, whether or not +contributors as well as cumbersome for comitters seeking to accept the patches +sent by users. In contrast, the Pull Request workflow style enables non +techincal contributors, especially those who do not know their way around the +DVCS of choice, to contribute using the web based editor. On the committer +side, the Pull Requests enable them to tell, before merging, whether or not a particular Pull Request will break anything. It also enables them to do a simple "push button" merge which does not require them to check out the changes locally. Another such feature that is useful in particular for docs, -is the ability to view a "prose" diff. This Github specific feature enables +is the ability to view a "prose" diff. This Github-specific feature enables a committer to view a diff of the rendered output which will hide things like reformatting a paragraph and show you what the actual "meat" of the change actually is. @@ -66,15 +65,14 @@ Why Git? -------- -Looking at the variety of DVCS which are available today it becomes fairly -clear that git has gotten the vast mindshare of people who are currently using -it. The Open Hub (Previously Ohloh) statistics [#openhub-stats]_ show that -currently 37% of the repositories Open Hub is indexing is using git which is -second only to SVN (which has 48%) while Mercurial has just 2% of the indexed -repositories (beating only bazaar which has 1%). In additon to the Open Hub -statistics a look at the top 100 projects on PyPI (ordered by total download -counts) shows us that within the Python space itself there is a majority of -projects using git: +Looking at the variety of DVCS which are available today, it becomes fairly +clear that git has the largest mindshare. The Open Hub (Previously Ohloh) +statistics [#openhub-stats]_ show that currently 37% of the repositories +indexed by Open Hub are using git which is second only to SVN (which has 48%), +while Mercurial has just 2% of the indexed repositories (beating only bazaar +which has 1%). In additon to the Open Hub statistics, a look at the top 100 +projects on PyPI (ordered by total download counts) shows that within the +Python space itself, the majority of projects use git. === ========= ========== ====== === ==== Git Mercurial Subversion Bazaar CVS None @@ -85,49 +83,47 @@ Chosing a DVCS which has the larger mindshare will make it more likely that any particular person who has experience with DVCS at all will be able to -meaningfully use the DVCS that we have chosen without having to learn a new -tool. +meaningfully contribute without having to learn a new tool. In addition to simply making it more likely that any individual will already know how to use git, the number of projects and people using it means that the -resources for learning the tool are likely to be more fully fleshed out and -when you run into problems the liklihood that someone else had that problem +resources for learning the tool are likely to be more fully fleshed out. +When you run into problems, the liklihood that someone else had that problem and posted a question and recieved an answer is also far likelier. -Thirdly by using a more popular tool you also increase your options for tooling -*around* the DVCS itself. Looking at the various options for hosting -repositories it's extremely rare to find a hosting solution (whether OSS or -commerical) that supports Mercurial but does not support Git, on the flip side +Thirdly, by using a more popular tool you also increase your options for +tooling *around* the DVCS itself. Looking at the various options for hosting +repositories, it's extremely rare to find a hosting solution (whether OSS or +commerical) that supports Mercurial but does not support Git. On the flip side, there are a number of tools which support Git but do not support Mercurial. Therefore the popularity of git increases the flexibility of our options going into the future for what toolchain these projects use. -Also by moving to the more popular DVCS we increase the likelhood that the +Also, by moving to the more popular DVCS, we increase the likelhood that the knowledge that the person has learned in contributing to these support repositories will transfer to projects outside of the immediate CPython project such as to the larger Python community which is primarily using Git hosted on Github. In previous years there was concern about how well supported git was on Windows -in comparison to Mercurial. However git has grown to support Windows as a first -class citizen. In addition to that, for Windows users who are not well aquanted -with the Windows command line there are GUI options as well. +in comparison to Mercurial. However, git has grown to support Windows as a +first class citizen. In addition to that, for Windows users who are not well +aquanted with the Windows command line, there are GUI options as well. On a techincal level git and Mercurial are fairly similar, however the git branching model is signifcantly better than Mercurial "Named Branches" for -non-comitter contributors. Mercurial does have a "Bookmarks" extension however +non-comitter contributors. Mercurial does have a "Bookmarks" extension, however this isn't quite as good as git's branching model. All bookmarks live in the same namespace so it requires individual users to ensure that they namespace the branchnames themselves lest the risk collision. It also is an extension -which requires new users to first discover they need an extension at all and -then figure out what they need to do in order to enable that extension. Since -it is an extension it also means that in general support for them outside of -Mercurial core is going to be less than 100% in comparison to git where the -feature is built in and core to using git at all. Finally users who are not -used to Mercurial are unlikely to discover bookmarks on their own, instead they -will likely attempt to use Mercurial's "Named Branches" which, given the fact -they live "forever", are not often what a project wants their contributors to -use. +which requires new users to first discover they need an extension at all, and +then figure out what they need to do in order to enable that extension. Since, +in contrast to the branching feature in git, this feature is a Mercurial +extension, in general, its support outside the Mercurial core is less +extensive. Finally, users who are not used to Mercurial are unlikely to +discover bookmarks on their own, instead they will likely attempt to use +Mercurial's "Named Branches" which, given the fact they live "forever", are not +often what a project wants their contributors to use. Why Github? @@ -142,8 +138,8 @@ Quality/Polish. Github is currently the most popular hosted repository hosting according to -Alexa where it currently has a global rank of 121. Much like for Git itself by -choosing the most popular tool we gain benefits in increasing the likelhood +Alexa, where it currently has a global rank of 121. Much like for Git itself, +by choosing the most popular tool we gain benefits in increasing the likelhood that a new contributor will have already experienced the toolchain, the quality and availablity of the help, more and better tooling being built around it, and the knowledge transfer to other projects. A look again at the top 100 projects @@ -162,7 +158,7 @@ common sentiment if you go around and ask people who are using these services often. -Finally a reason to choose a web service at all over something that is +Finally, a reason to choose a web service at all over something that is self-hosted is to be able to more efficiently use volunteer time and donated resources. Every additional service hosted on the PSF infrastruture by the PSF infrastructure team further spreads out the amount of time that the @@ -175,7 +171,7 @@ be suitable. It is the opinion of this PEP that Github does not currently and has not in the past engaged in any attempts to lock people into their platform and that if at some point in the future Github is no longer suitable for one -reason or another than at that point we can look at migrating away from Github +reason or another, then at that point we can look at migrating away from Github onto a different solution. In other words, we'll cross that bridge if and when we come to it. @@ -188,24 +184,25 @@ and size of the community using said tools. We can see this is true by looking at an example from a sub-community of the Python community: The Scientific Python community. They have already migrated most of the key pieces of the -SciPy stack onto Github using the Pull Request based workflow starting with -IPython and as more projects moved over it became a natural default for new -projects. +SciPy stack onto Github using the Pull Request based workflow. This process +started with IPython, and as more projects moved over it became a natural +default for new projects in the community. -They claim to have seen a great benefit from this move, where it enables casual -contributors to easily move between different projects within their +They claim to have seen a great benefit from this move, in that it enables +casual contributors to easily move between different projects within their sub-community without having to learn a special, bespoke workflow and a different toolchain for each project. They've found that when people can use their limited time on actually contributing instead of learning the different -tools and workflows that not only do they contribute more to one project, that -they also expand out and contribute to other projects. This move is also -attributed to making it commonplace for members of that community to go so far -as publishing their research and educational materials on Github as well. +tools and workflows that, not only do they contribute more to one project, but +that they also expand out and contribute to other projects. This move has also +been attributed to the increased tendency for members of that community to go +so far as publishing their research and educational materials on Github as +well. -This showcases the real power behind moving to a highly popular toolchain and -workflow, as each variance introduces yet another hurdle for new and casual -contributors to get past and it makes the time spent learning that workflow -less reusable with other projects. +This example showcases the real power behind moving to a highly popular +toolchain and workflow, as each variance introduces yet another hurdle for new +and casual contributors to get past and it makes the time spent learning that +workflow less reusable with other projects. Migration @@ -214,7 +211,7 @@ Through the use of hg-git [#hg-git]_ we can easily convert a Mercurial repository to a Git repository by simply pushing the Mercurial repository to the Git repository. People who wish to continue to use Mercurual locally can -then use hg-git going into the future using the new Github URL, however they +then use hg-git going into the future using the new Github URL. However they will need to re-clone their repositories as using Git as the server seems to trigger a one time change of the changeset ids. @@ -222,7 +219,7 @@ other than the ``default`` branch the migration will simply map the ``default`` branch in Mercurial to the ``master`` branch in git. -In addition since none of the selected projects have any great need of a +In addition, since none of the selected projects have any great need of a complex bug tracker, they will also migrate their issue handling to using the GitHub issues. -- Repository URL: https://hg.python.org/peps

1 0