Re: [Python-Dev] cpython: Issue #16049: add abc.ABC helper class.
Am 13.12.2012 18:09, schrieb andrew.svetlov: http://hg.python.org/cpython/rev/9347869d1066 changeset: 80840:9347869d1066 user:Andrew Svetlov andrew.svet...@gmail.com date:Thu Dec 13 19:09:33 2012 +0200 summary: Issue #16049: add abc.ABC helper class. Patch by Bruno Dupuis. files: Doc/library/abc.rst | 18 ++ Lib/abc.py | 6 ++ Lib/test/test_abc.py | 13 + Misc/NEWS| 3 +++ 4 files changed, 36 insertions(+), 4 deletions(-) diff --git a/Doc/library/abc.rst b/Doc/library/abc.rst --- a/Doc/library/abc.rst +++ b/Doc/library/abc.rst @@ -12,9 +12,9 @@ -- This module provides the infrastructure for defining :term:`abstract base -classes abstract base class` (ABCs) in Python, as outlined in :pep:`3119`; see the PEP for why this -was added to Python. (See also :pep:`3141` and the :mod:`numbers` module -regarding a type hierarchy for numbers based on ABCs.) +classes abstract base class` (ABCs) in Python, as outlined in :pep:`3119`; +see the PEP for why this was added to Python. (See also :pep:`3141` and the +:mod:`numbers` module regarding a type hierarchy for numbers based on ABCs.) The :mod:`collections` module has some concrete classes that derive from ABCs; these can, of course, be further derived. In addition the @@ -23,7 +23,7 @@ hashable or a mapping. -This module provides the following class: +This module provides the following classes: .. class:: ABCMeta @@ -127,6 +127,16 @@ available as a method of ``Foo``, so it is provided separately. +.. class:: ABC + + A helper class that has :class:`ABCMeta` as metaclass. :class:`ABC` is the + standard class to inherit from in order to create an abstract base class, + avoiding sometimes confusing metaclass usage. + + Note that :class:`ABC` type is still :class:`ABCMeta`, therefore inheriting + from :class:`ABC` requires usual precautions regarding metaclasses usage + as multiple inheritance may lead to metaclass conflicts. + Needs a versionadded. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial workflow question...
On Dec 13, 2012, at 7:00 PM, Chris Jerdonek chris.jerdo...@gmail.com wrote: On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray rdmur...@bitdance.com wrote: On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson tr...@snakebite.org wrote: - Use a completely separate clone to house all the intermediate commits, then generate a diff once the final commit is ready, then apply that diff to the main cpython repo, then push that. This approach is fine, but it seems counter-intuitive to the whole concept of DVCS. Perhaps. But that's exactly what I did with the email package changes for 3.3. You seem to have a tension between all those dirty little commits and clean history and the fact that a dvcs is designed to preserve all those commits...if you don't want those intermediate commits in the official repo, then why is a diff/patch a bad way to achieve that? Right. And you usually have to do this beforehand anyways to upload your changes to the tracker for review. Also, for the record (not that anyone has said anything to the contrary), our dev guide says, You should collapse changesets of a single feature or bugfix before pushing the result to the main repository. The reason is that we don’t want the history to be full of intermediate commits recording the private history of the person working on a patch. If you are using the rebase extension, consider adding the --collapse option to hg rebase. The collapse extension is another choice. (from http://docs.python.org/devguide/committing.html#working-with-mercurial ) Does hg's ability to make merges easier than svn depend on having all the intermediate commits? I thought the theory was that the smaller changesets provided extra information that made it possible to merge two expansive groups of changes. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial workflow question...
Apologies the top-posting (damned Gmail ...). Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial workflow question...
Possibly. A collapsed changeset is more likely to have larger hunks of changes e.g. two changesets that each modified adjacent pieces of code get collapsed down to a single change hunk - which would make the merge machinery have to work harder to detect moved hunks, etc. In practice, so long as each collapsed changeset is for a single change I haven't seen this be a major issue. However, I'm personally a create a new named branch for each task, keep all intermediate history kind of guy (and I get to set the rules for my team ;) so I don't see collapsed changesets very often. Tim Delaney On 17 December 2012 16:17, Raymond Hettinger raymond.hettin...@gmail.comwrote: On Dec 13, 2012, at 7:00 PM, Chris Jerdonek chris.jerdo...@gmail.com wrote: On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray rdmur...@bitdance.com wrote: On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson tr...@snakebite.org wrote: - Use a completely separate clone to house all the intermediate commits, then generate a diff once the final commit is ready, then apply that diff to the main cpython repo, then push that. This approach is fine, but it seems counter-intuitive to the whole concept of DVCS. Perhaps. But that's exactly what I did with the email package changes for 3.3. You seem to have a tension between all those dirty little commits and clean history and the fact that a dvcs is designed to preserve all those commits...if you don't want those intermediate commits in the official repo, then why is a diff/patch a bad way to achieve that? Right. And you usually have to do this beforehand anyways to upload your changes to the tracker for review. Also, for the record (not that anyone has said anything to the contrary), our dev guide says, You should collapse changesets of a single feature or bugfix before pushing the result to the main repository. The reason is that we don’t want the history to be full of intermediate commits recording the private history of the person working on a patch. If you are using the rebase extension, consider adding the --collapse option to hg rebase. The collapse extension is another choice. (from http://docs.python.org/devguide/committing.html#working-with-mercurial ) Does hg's ability to make merges easier than svn depend on having all the intermediate commits? I thought the theory was that the smaller changesets provided extra information that made it possible to merge two expansive groups of changes. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/timothy.c.delaney%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial workflow question...
Raymond Hettinger writes: Does hg's ability to make merges easier than svn depend on having all the intermediate commits? I thought the theory was that the smaller changesets provided extra information that made it possible to merge two expansive groups of changes. Tim Delaney's explanation is correct as far as it goes. But I would give a pretty firm No as the answer to your question. The big difference between svn (and CVS) and hg (and git and bzr) at the time of migrating the Python repository was that svn didn't track merges, only branches. So in svn you get a 3-way merge with the branch point as the base version. This meant that you could not track progress of the mainline while working on a branch. svn tends to report the merge of recent mainline changes back into the mainline as conflicts when merging your branch into the mainline[1][2], all too often resulting in a big mess. hg, because it records merges as well as branches, can use the most recent common version (typically the mainline parent of the most recent catch-up merge) as the base version. This means that (1) there are somewhat fewer divergences because your branch already contains most changes to the mainline, and (2) you don't get spurious conflicts. On the other hand, more frequent intermediate committing is mostly helpful in bisection, and so the usefulness depends on very disciplined committing (only commit build- and test-able code). Summary: only the frequency of intermediate merge commits really matters. Because in hg it's possible to have frequent catch-up merges from mainline, you get smaller merges with fewer conflicts both at catch-up time and at merge-to-mainline time. Footnotes: [1] Not the whole story, but OK for this purpose. Technical details available on request. [2] I have paid almost no attention to svn since Python migrated to hg, so perhaps svn has improved merge support in the meantime. But that doesn't really matter since svn is merely being used to help explain why commit granularity doesn't matter much to hg's merge capabilities. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
