Re: [Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135
On Mon, Feb 21, 2011 at 1:52 PM, Nick Coghlan wrote: > 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 Sorry for taking forever to get back to this. So I looked over PEP 389 and it's basically complete, but I never implemented the code deprecation warnings for optparse (only the documentation deprecation warnings). The PEP claims: Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided at the command line, then importing optparse will issue a DeprecationWarning. Otherwise no warnings will be issued. Python 3.2+ -- Importing optparse will issue a PendingDeprecationWarning, which is not displayed by default. I'm kind of inclined to just remove those lines from the PEP since optparse is not being removed and since 2.7 and 3.2 are already out the door. If anyone thinks those deprecation warnings really need to be implemented, let me know in the next couple days. Otherwise, I'll update the PEP and mark it as final. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135
On Sat, Mar 26, 2011 at 7:39 PM, Steven Bethard wrote: > I'm kind of inclined to just remove those lines from the PEP since > optparse is not being removed and since 2.7 and 3.2 are already out > the door. If anyone thinks those deprecation warnings really need to > be implemented, let me know in the next couple days. Otherwise, I'll > update the PEP and mark it as final. My recollection is that omitting the deprecation warnings was a deliberate decision during the implementation phase, so updating the PEP with a note to that effect and then marking it as final sounds like the right thing to do. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [issue7284] argparse - display version in usage by default
On Sat, Mar 26, 2011 at 12:20 PM, Steven Bethard 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [issue7284] argparse - display version in usage by default
On Sat, Mar 26, 2011 at 9:14 PM, anatoly techtonik 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. There'll always be room for additional feature requests, and many of them won't cause backwards compatibility problems. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Decisions about workflow
I know there's a big ideas exchange in this list about how to use Mercurial in the Python project. I know that still there is not wide and firm consensus about the whole workflow to follow. But maybe some small decisions are already taken, some suggestions about the best way to do this or that, even if there are others that are not taken. Is this being documented somewhere? Thank you! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decisions about workflow
Hello Facundo, > But maybe some small decisions are already taken, some suggestions > about the best way to do this or that, even if there are others that > are not taken. > > Is this being documented somewhere? Take a look at: http://docs.python.org/devguide/committing.html Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decisions about workflow
Antoine> Take a look at: Antoine> http://docs.python.org/devguide/committing.html What form should directed graphs be in for inclusion? Thx, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] GSoC idea: PEP process enhancements (Was: [issue7284] argparse - display version in usage by default)
On Sat, Mar 26, 2011 at 5:14 PM, Nick Coghlan wrote: > On Sat, Mar 26, 2011 at 9:14 PM, anatoly techtonik > 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-enough > 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sprints and pushes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/26/2011 02:56 AM, Stephen J. Turnbull wrote: > Tres Seaver writes: > > > That was precisely my proposal: > > Sorry about that. I live in a disaster area, and was limited to > GMail until two days ago, and lost a fair amount of context in the > switch back. I'm sorry to hear that! I hope all is well for you and yours -- we are still waiting to hear about my sister-in-law's family in the northeast. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2OHXMACgkQ+gerLs4ltQ4hPgCfes3/sHOKxWUyGgR8nsSOfhFU SwcAnjElVvSq1WKIXeMWzcMrYuMnNvaq =hbWU -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use enumerate().
"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 > 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 > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use enumerate().
On 3/26/2011 2:17 PM, Georg Brandl wrote: "Refactor" doesn't sound like it belongs in the 3.1 branch... -for i in range(len(pattern)): -c = pattern[i] +for i, c in enumerate(pattern): I would call thin 'Replace obsolete idiom in' rather than 'Refactor'. So are you criticizing the replacement or the mislabeling? -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use enumerate().
On Sat, 26 Mar 2011 15:00:29 -0400 Terry Reedy wrote: > On 3/26/2011 2:17 PM, Georg Brandl wrote: > > "Refactor" doesn't sound like it belongs in the 3.1 branch... > > >> -for i in range(len(pattern)): > >> -c = pattern[i] > >> +for i, c in enumerate(pattern): > > I would call thin 'Replace obsolete idiom in' rather than 'Refactor'. > So are you criticizing the replacement or the mislabeling? I think the criticism is that such gratuitous replacements in bugfix branches are both a waste of time and a possible regression. The only good reason to do them is if you think it will improve further merges of bugfix patches. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use enumerate().
Am 26.03.2011 20:00, schrieb Terry Reedy: > On 3/26/2011 2:17 PM, Georg Brandl wrote: >> "Refactor" doesn't sound like it belongs in the 3.1 branch... > >>> -for i in range(len(pattern)): >>> -c = pattern[i] >>> +for i, c in enumerate(pattern): > > I would call thin 'Replace obsolete idiom in' rather than 'Refactor'. > So are you criticizing the replacement or the mislabeling? No - I believe he is critizing that a stylistic change is done in a maintenance branch. It's not a bug fix, AFAICT, so it should not have been done. Regards, Martin P.S. I haven't looked into the specific context, but the diff alone may actually cause behavior changes, depending on what pattern exactly is. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] git-style diffs in Rietveld
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use enumerate().
On 26.03.2011 20:19, "Martin v. Löwis" wrote: > Am 26.03.2011 20:00, schrieb Terry Reedy: >> On 3/26/2011 2:17 PM, Georg Brandl wrote: >>> "Refactor" doesn't sound like it belongs in the 3.1 branch... >> -for i in range(len(pattern)): -c = pattern[i] +for i, c in enumerate(pattern): >> >> I would call thin 'Replace obsolete idiom in' rather than 'Refactor'. >> So are you criticizing the replacement or the mislabeling? > > No - I believe he is critizing that a stylistic change is done > in a maintenance branch. It's not a bug fix, AFAICT, so it should not > have been done. Exactly, and two changesets before that there was another commit "Refactor the tests for re.escape" that was by far larger than this one, and not as easily reviewed as this one. In the end, this kind of change in a bugfix branch has zero gain, but a nonzero risk of gratuitous breakage. If it is necessary for future fixes or ease of merging bugfixes, I'd at least expect a note of that in the commit message justifying the breach of policy for a barely-maintenance branch. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC idea: PEP process enhancements (Was: [issue7284] argparse - display version in usage by default)
On Sun, Mar 27, 2011 at 2:55 AM, anatoly techtonik wrote: > 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. I admire your passion to make everything perfect, and your dream that there are technological solutions to every social problem (i.e. people missing things, or settling for "better" when you want them to aim for "best"). It's a volunteer community. We muddle through as best we can, without the ability to undertake full blown usability studies and analyses, instead relying on straw polls of mailing lists, anecdotal evidence and simple gut instinct of experienced developers. That's the reality of open source development when you don't have a well-funded individual in the driver's seat with the ability and desire to force a particular design direction (ala Shuttleworth and Ubuntu). You're welcome to come up with what you think is an improvement over simply cloning the PEPs repo and maintaining a competing PEP (or proposing patches to the existing one), but don't expect people to just fall in love with whatever you suggest (remember past experiences with advocating the use of Google Wave). However, even if you did decide to do this, it wouldn't be suitable as a GSoC project, as it would ultimately be about social engineering, not coding. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.1): #2650: Refactor re.escape to use enumerate().
On 27/03/2011 0.03, Georg Brandl wrote: On 26.03.2011 20:19, "Martin v. Löwis" wrote: Am 26.03.2011 20:00, schrieb Terry Reedy: On 3/26/2011 2:17 PM, Georg Brandl wrote: "Refactor" doesn't sound like it belongs in the 3.1 branch... -for i in range(len(pattern)): -c = pattern[i] +for i, c in enumerate(pattern): I would call thin 'Replace obsolete idiom in' rather than 'Refactor'. So are you criticizing the replacement or the mislabeling? No - I believe he is critizing that a stylistic change is done in a maintenance branch. It's not a bug fix, AFAICT, so it should not have been done. Exactly, and two changesets before that there was another commit "Refactor the tests for re.escape" that was by far larger than this one, and not as easily reviewed as this one. In the end, this kind of change in a bugfix branch has zero gain, but a nonzero risk of gratuitous breakage. If it is necessary for future fixes or ease of merging bugfixes, I'd at least expect a note of that in the commit message justifying the breach of policy for a barely-maintenance branch. Hi, these commits are part of #2650[0]. First, I refactored the existing tests[1] and added a few more tests[2] to have better coverage. Tests are usually ported to maintenance branches as well (because they could uncover bugs and also make merging easier), so I started working on 3.1. Then I refactored the function[3], and since the refactoring was trivial and I had extensive tests to make sure that the behavior was unchanged I included the refactoring in 3.1 too. FWIW I've been porting most of the commits that I do on 3.2 on 3.1 too (i.e. I'm considering both of them maintenance branches), and merging 3 branches rather than 2 doesn't make much difference with mercurial. [0]: http://bugs.python.org/issue2650 [1]: http://hg.python.org/cpython/rev/1402c719b7cf [2]: http://hg.python.org/cpython/rev/9147f7ed75b3 [3]: http://hg.python.org/cpython/rev/ed02db9921ac Best Regards, Ezio Melotti Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ezio.melotti%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
