I think devguide's suggested interbranch workflow introduces too much complexity for too little payoff.
If I need to make a fix to 3.2, I can't just fix it. I would need to also merge the changeset into 3.3 and then revert it, and then commit both. There is not much payoff to this style. It brings back the ghost of svnmerge but it much more restrictive:
* it is pretty much required for every patch on a non-default branch
* you have to decide in advance how far it should be backported because only forward porting is supported
* it means you can't just fix one branch without having also decided how the change should be applied to other branches (if we look at the tracker, you can see that it is very common for the resolution on different branches to be done at different times)
I think we would be better off treating the branches as independent. If I need to apply a patch to two of them, that's what I would do (in any order, at any time, or with or without modifications).
As far as I can tell the only benefits to the cross-linking are that it reduces the chance that a patch will be applied to an older branch but not forward ported.
I've been enjoying most of my experiences with mercurial, but as soon we start needing rebases, null merges, merges followed by null reverts, then we might as well be using git. The version control system is supposed to make our lives easier, not introduce more workflow requirements.
I don't think the more complex workflow if worth it. Mercurial is very user friendly right out of the box will simple commands. But as soon as you require the branches to be inter-linked, you've made it much more difficult to get simple checkins done.
On Sun, Mar 27, 2011 at 6:52 PM, raymond.hettinger <
> -.. function:: accumulate(iterable)
+.. function:: accumulate(iterable[, func])
> Make an iterator that returns accumulated sums. Elements may be any
> - type including :class:`Decimal` or :class:`Fraction`. Equivalent to::
> + type including :class:`Decimal` or :class:`Fraction`. If the optional
> + *func* argument is supplied, it should be a function of two arguments
> + and it will be used instead of addition.
Is there a good use-case for the func argument? I can only think of bad
use-cases (where "func" does something that does not remotely resemble
addition). I fear that people will actually implement these bad use-cases,
and I will have to try to read and understand their code.
Adding the func argument seems analogous to adding a func argument to sum(),
which would give it all of the power of reduce().
Trying to compile and install Python 2.7 on irix 6.5.22 IP22 (N32 ABI
model), Using gcc-4.5.1 and binutils 2.20.1. Everything goes well (I
applied th patches listed at:
It compiles and the test mostly work except for the callback ctypes
(libffi) test where it segfaults on a pyDECREFF. Digging in, the O_get
call is returning a NULL pointer (and pyDECREF is understandably choking
Since I am very new to python, I am at a bit of a loss to tracing the C
code back through this particulat section of code to see why the PyOBJECT
isn't being assigned here. Any help would be welomed.
David E. Cross
I suggested at python-ideas a way that the declaration of abstract
properties could be improved to support the decorator syntax:
A relatively small change to the property builtin would allow
properties to identify themselves as abstract when they are passed
abstract methods (the same way that function objects identify
themselves as abstract when decorated with @abstractmethod). As a
result, @abstractproperty would no longer be needed.
I submitted a patch at http://bugs.python.org/issue11610. It includes
the changes to the property builtin, documentation, and unit tests.
Unfortunately, I have not been able to python-3.3 from a mercurial
checkout on either Ubuntu 11.04 or OS X 10.6.6 (for reasons unrelated
to the patch), and so I have not been able to test the patch.
On Sat, Mar 26, 2011 at 5:14 PM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
> On Sat, Mar 26, 2011 at 9:14 PM, anatoly techtonik <techtonik(a)gmail.com> wrote:
>> A pity that before argparse replaced optparse, there was no research
>> made to gather the output from various console tools to see how
>> argparse really saves people from reinventing their solutions.
> argparse was adopted because it was a significant improvement over
> optparse, not because anyone was under the illusion that it was
What if we could accompany every PEP draft with series of use
cases/user stories? I don't know how many people actually reviewed
this particular PEP 389, and that's bad, because without this info it
is hard to say if there were enough reviews from future users.
The process is also complicated, because you can't comment on the
document inline. As a Python user I can spend 15 minutes on reading
PEP, but I can't spend hour composing email copy/pasting text for
commenting. For example, if the paragraph about "why aren't getopt and
optparse enough"  was reduced to just :
- no support for positional arguments
- no variable number of arguments
Perhaps then I could see that my simple use case to make output
formatting more flexible and concise is not covered by this PEP.
> There'll always be room for additional feature requests, and many of
> them won't cause backwards compatibility problems.
Actually, if we could bring this issue earlier, my request would be to
replace a bunch of parameters in constructor with a simple template.
But by the time I was able to get back to making a letter about this
proposal, argparse is already released and Python 3.2 is outside the
E.g. instead of:
argparse.ArgumentParser([description][, epilog][, prog][, usage][,
add_help][, argument_default][, parents][, prefix_chars][,
argparse.Parser([help][, argument_default][, parents][, chars][,
conflict_handler][, formatter][, help_vars])
help_vars = dict([prolog][, description][, epilog][, prog][,
progname][, usage][, version])
and strip HelpFormatter from formatters (they're already inherited)
RawDescriptionHelpFormatter -> RawDescription
RawTextHelpFormatter -> RawText
ArgumentDefaultsHelpFormatter -> ArgumentDefaults
so that the final "pythonic" invocation syntax would be:
parser = argparse.Parser(help=True, formatter=argparse.RawText,
help_vars=dict(progname="mA keWl UtIL",
Actually it doesn't look as more flexible to me, but the idea is to
provide more variants for consideration and make sure as much people
as possible reviewed them.
That's why I'd like to propose to develop this system for a GSoC
project. I can mentor its development with some support from
interested people around.
I changed the patch importer in Rietveld to recognize diffs without
a base changeset, which means that --git-style diffs are supported
as long as they apply to the default branch.
The tracker will provide review for a patch, iff, for all files in
- a line starting with "diff " is found, and
- the line ends with a valid filename (an optional b/ is stripped
* it applies cleanly against its base revision, or
* the base revision does not exist, and it is a patch creating
a new file
To determine what the base revision is (and whether the file name
is valid), it checks that
* that the patch starts with 'diff -r <12digits>', taking 12digits as
the base; if not,
* that the patch applies against cpython's "default"
To determine that the patch applies cleanly, it doesn't do any fuzzy
matching (unlike patch(1)). i.e. the old text must match exactly,
and by line numbers.
As a consequence, the following patches cannot be reviewed in
this Rietveld installation:
- patches not starting with "diff"
- patches generated with diff(1) if the path in the patch doesn't
- git-style diffs where the base file has been changed after the
diff was produced.
If you find that it doesn't work in cases not discussed above,
please report this to the meta-tracker.
On Wed, Mar 23, 2011 at 9:45 PM, John Arbash Meinel
> I don't specifically know what is in those 340 tests, but 18min/340 =
> 3.2s for each test. Which is *much* longer than simple smoke tests would
> have to be.
The counts Barry is referring to there are actually counting test
*files*, rather than individual tests. We only have 359 of those in
total though (not counting those in subdirectories), so a "quicktest"
that omits less than 6% of them doesn't sound particularly quick (even
if it does leave out the slowest ones).
We should probably do another pass and add a few more tests to the
blacklist in the Makefile template (starting with
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
On Sat, Mar 26, 2011 at 12:20 PM, Steven Bethard <report(a)bugs.python.org> wrote:
> I see though that vi puts the full name and version before the usage (which is currently impossible in argparse):
That was exactly my use case, which I'd say is very common for small
utilities. Just in 10 minutes I could find that about a half of
command line utilities on my Windows machine are reporting full name
and version before the usage with --help option, including NSIS,
PuTTY, Far Manager, Android Debug Bridge and 7-Zip.
A pity that before argparse replaced optparse, there was no research
made to gather the output from various console tools to see how
argparse really saves people from reinventing their solutions.
Do you think we could avoid this problem if there was more active
turnaround between Roundup community and Python community to import
all issues from Google Code tracker in time to do some planning?
As the subject line asks, is there anything preventing the following
PEPs from being marked Final?
SA 389 argparse - New Command Line Parsing Module Bethard
SA 391 Dictionary-Based Configuration For Logging Sajip
SA 3108 Standard Library Reorganization Cannon
SA 3121 Extension Module Initialization and Finalization von Löwis
SA 3135 New Super
Spealman, Delaney, Ryan
(I deliberately left 3118 off the list, since there are some
discrepancies between the PEP and the implementation that need to be
clarified for 3.3 and the 3 distutils related PEPs won't be done until
Tarek merges distutils2 back into the main line of development)
It would be good to clear the decks before new PEPs start to be
accepted for inclusion in 3.3.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia