Python-Dev March 2011

python-dev@python.org

176 participants
199 discussions

by Raymond Hettinger

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. Raymond

10 years

Re: [Python-Dev] [Python-checkins] cpython: Add optional *func* argument to itertools.accumulate().

by Daniel Stutzbach

On Sun, Mar 27, 2011 at 6:52 PM, raymond.hettinger < python-checkins(a)python.org> wrote: > -.. function:: accumulate(iterable) +.. function:: accumulate(iterable[, func]) > > Make an iterator that returns accumulated sums. Elements may be any > addable > - 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(). -- Daniel Stutzbach

10 years

Python 2.7 on Irix 6.5.22 fails ctypes callback test

by David E. Cross

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: http://bugs.python.org/file15915/python-2.7-irix.patch ) 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 on that). 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

10 years

improvement to declaring abstract properties

by Darren Dale

I suggested at python-ideas a way that the declaration of abstract properties could be improved to support the decorator syntax: http://mail.python.org/pipermail/python-ideas/2011-March/009411.html . 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. Darren

10 years

Re: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use enumerate().

by Georg Brandl

"Refactor" doesn't sound like it belongs in the 3.1 branch... Georg On 25.03.2011 13:27, ezio.melotti wrote: > http://hg.python.org/cpython/rev/ed02db9921ac > changeset: 68924:ed02db9921ac > branch: 3.1 > user: Ezio Melotti <ezio.melotti(a)gmail.com> > date: Fri Mar 25 14:19:30 2011 +0200 > summary: > #2650: Refactor re.escape to use enumerate(). > > files: > Lib/re.py | 3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > > diff --git a/Lib/re.py b/Lib/re.py > --- a/Lib/re.py > +++ b/Lib/re.py > @@ -223,8 +223,7 @@ > if isinstance(pattern, str): > alphanum = _alphanum_str > s = list(pattern) > - for i in range(len(pattern)): > - c = pattern[i] > + for i, c in enumerate(pattern): > if c not in alphanum: > if c == "\000": > s[i] = "\\000" > > > > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins

10 years

GSoC idea: PEP process enhancements (Was: [issue7284] argparse - display version in usage by default)

by anatoly techtonik

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 > perfect. 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" [1] was reduced to just : - no support for positional arguments - no variable number of arguments - subcommands Perhaps then I could see that my simple use case to make output formatting more flexible and concise is not covered by this PEP. [1] http://www.python.org/dev/peps/pep-0389/#why-aren-t-getopt-and-optparse-eno… > 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 hangar too. E.g. instead of: argparse.ArgumentParser([description][, epilog][, prog][, usage][, add_help][, argument_default][, parents][, prefix_chars][, conflict_handler][, formatter_class]) use 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, template="""" %progname %description %help """, help_vars=dict(progname="mA keWl UtIL", version=__version__, description=__doc__)) 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. -- anatoly t.

10 years

git-style diffs in Rietveld

by "Martin v. Löwis"

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 the patch: - a line starting with "diff " is found, and - the line ends with a valid filename (an optional b/ is stripped first), and - either: * 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 match cpython - 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. Regards, Martin

10 years

Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

by Nick Coghlan

On Wed, Mar 23, 2011 at 9:45 PM, John Arbash Meinel <john(a)arbash-meinel.com> wrote: > 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 test_concurrent_futures). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

10 years

Re: [Python-Dev] [issue7284] argparse - display version in usage by default

by anatoly techtonik

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? http://code.google.com/p/argparse/issues/detail?id=50

10 years

Are these PEP complete?: 389, 391, 3108, 3135

by Nick Coghlan

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. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

10 years

← Newer
1
2
3
4
5
6
7
...
20
Older →

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev March 2011