With a branch you can easily view the full patch, making a branch
strictly more general.
I just asked this before: how *exactly* do you do that?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or the
CPU burden).
For Mercurial, that's more difficult than you might expect. There is hg
Sorry, I didn't think that through. Revsets still have the power though:
hg -R tmp.bundle diff -r'ancestor(.,default)' -r default
(assuming your local repo is at the tip of default)
I can't make this work. I'm using hg 1.6.4, which does have revsets and
(including ancestor). Still, with this
Calling it python.exe would make the most sense for people who don't
look behind the curtain, but I agree it could potentially be confusing
for people. Further, we would need to ensure we didn't create an
infinite loop where the launcher python.exe found a python.exe it
thought was an appropriate
Am 08.03.2011 01:00, schrieb Michael Foord:
On 07/03/2011 23:52, Greg Ewing wrote:
Michael Foord wrote:
- I doubt calling it python.exe will fly, but I'm not sure. If so
what will you call what is currently 'python.exe'? - if not then
python foo.py on the command line will *still* not work...
Michael Foord wrote:
The launcher program could thrive without *having* to be part of a
standard Python install. Offering it separately makes sense even if it
*is* included. If we do both then users can vote with their feet.
A launcher might be difficult to integrate into the Python installer,
On 08.03.2011 10:03, Martin v. Löwis wrote:
Sorry, I didn't think that through. Revsets still have the power though:
hg -R tmp.bundle diff -r'ancestor(.,default)' -r default
(assuming your local repo is at the tip of default)
I can't make this work. I'm using hg 1.6.4, which does have
Hi,
I can't update to v2.7 in the new cpython repository:
$ hg up v2.7
abort: unknown revision 'v2.7'!
Am I missing something here? My goal is to get the same directory state
as from this command:
svn co http://svn.python.org/projects/python/tags/r27
Stefan Krah
On Tue, Mar 8, 2011 at 10:45, Stefan Krah stefan-use...@bytereef.org wrote:
Hi,
I can't update to v2.7 in the new cpython repository:
$ hg up v2.7
abort: unknown revision 'v2.7'!
Am I missing something here? My goal is to get the same directory state
as from this command:
svn co
On 2011-03-08 09:38, Martin v. Löwis wrote:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or the
CPU burden).
For Mercurial, that's more
Am 08.03.2011 10:49, schrieb Dirkjan Ochtman:
On Tue, Mar 8, 2011 at 10:45, Stefan Krahstefan-use...@bytereef.org wrote:
Hi,
I can't update to v2.7 in the new cpython repository:
$ hg up v2.7
abort: unknown revision 'v2.7'!
Am I missing something here? My goal is to get the same directory
Georg Brandl g.bra...@gmx.net writes:
I'm very happy to announce that the core Python repository switch
to Mercurial is complete and the new repository at
http://hg.python.org/cpython/ is now officially open for cloning,
and for commits by those who had commit access to SVN.
I've setup a git
On 08.03.2011 10:57, Martin v. Löwis wrote:
Am 08.03.2011 10:49, schrieb Dirkjan Ochtman:
On Tue, Mar 8, 2011 at 10:45, Stefan Krahstefan-use...@bytereef.org wrote:
Hi,
I can't update to v2.7 in the new cpython repository:
$ hg up v2.7
abort: unknown revision 'v2.7'!
Am I missing
On 2011-03-08 10:53, Adrian Buehlmann wrote:
On 2011-03-08 09:38, Martin v. Löwis wrote:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or
On Tue, 08 Mar 2011 09:38:27 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or the
CPU
Martin v. Löwis writes:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or the
CPU burden).
For Mercurial, that's more difficult
After a little investigation, I think what is currently proposed in the
PEP is fine for OS X and other systems which use the Unix makefile
altinstall and install targets, as far as it goes. However, for
completeness, I think the PEP should also cover (most of) the other
files that are
On Tue, 08 Mar 2011 12:23:54 +0100
local python-check...@python.org wrote:
+
+VERBS = r'(?:\b(?Pverbclose[sd]?|closing|fixe[sd]|fixing|fix)\s+)?'
+ISSUE_PATTERN = re.compile(r'%s(?:#|\bissue|\bbug)\s*(?Pissue_id[0-9]+)'
+ % VERBS, re.I)
This should only match numbers
On Tue, Mar 8, 2011 at 03:33, Martin v. Löwis mar...@v.loewis.de wrote:
If it's called python.exe, I wonder what it should do when given a
file that doesn't carry version information.
I would expect it to follow the guidance of the Unix PEP as much as
possible. IIRC this means it would launch
On Tue, Mar 8, 2011 at 03:40, Gertjan Klein gkl...@xs4all.nl wrote:
A launcher might be difficult to integrate into the Python installer, as
there can, by definition, only be one. What if I install a new version
of Python and then uninstall it? Will the launcher be uninstalled as
well? Will it
On 08.03.2011 14:19, Antoine Pitrou wrote:
On Tue, 08 Mar 2011 12:23:54 +0100
local python-check...@python.org wrote:
+
+VERBS = r'(?:\b(?Pverbclose[sd]?|closing|fixe[sd]|fixing|fix)\s+)?'
+ISSUE_PATTERN = re.compile(r'%s(?:#|\bissue|\bbug)\s*(?Pissue_id[0-9]+)'
+ %
On Mar 08, 2011, at 12:01 PM, Stephen J. Turnbull wrote:
Barry Warsaw writes:
I hear this complaint [about branches being no help in reviewing] a
lot from hg and git users, so maybe it's just the nature of the
tools. In which case, I'm fine with whatever works better for
Python.
On Tue, Mar 8, 2011 at 12:34 AM, Martin v. Löwis mar...@v.loewis.dewrote:
With a branch you can easily view the full patch, making a branch
strictly more general.
I just asked this before: how *exactly* do you do that?
I confess: I'm not sure exactly how to do it in hg. I know it's easy
On 2011-03-08, at 1:03 AM, Martin v. Löwis wrote:
Sorry, I didn't think that through. Revsets still have the power though:
hg -R tmp.bundle diff -r'ancestor(.,default)' -r default
(assuming your local repo is at the tip of default)
I can't make this work. I'm using hg 1.6.4, which does
On 3/7/2011 2:18 PM, James Y Knight wrote:
On Mar 7, 2011, at 3:49 PM, Paul Moore wrote:
The launcher could also (as per Mark's suggestion) interpret a shebang
line in the script, so that scripts could specify their required
version without needing a different command,or multiple
You are not a registered user.
Unknown address: python-dev@python.org
Return-Path: python-dev@python.org
X-Original-To: rep...@bugs.python.org
Delivered-To: roundup+trac...@psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
by
An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
Return-Path: python-dev@python.org
X-Original-To: rep...@bugs.python.org
Delivered-To: roundup+trac...@psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org
An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
Return-Path: python-dev@python.org
X-Original-To: rep...@bugs.python.org
Delivered-To: roundup+trac...@psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org
Greg Ewing greg.ewing at canterbury.ac.nz writes:
Guido van Rossum wrote:
Ok. Will you hvae time to port your patches to 3.3?
I'm not sure -- I'll see what I can do.
If this can help, I've ported the patch YieldFrom-Python3.1.2-rev5.patch
against current cpython tip.
What I've done:
-
Ouch. I fear this message may be repeated several times :/
Sorry for the spam, if that happens...
Regards
Antoine.
On Tue, 08 Mar 2011 19:32:20 +
Python tracker roundup-ad...@psf.upfronthosting.co.za wrote:
You are not a registered user.
Unknown address: python-dev@python.org
You are not a registered user.
Unknown address: python-dev@python.org
I should point out that I approved this message, mostly so whoever has
thinks set up to send messages to the meta tracker as python-dev can fix the
problem.
Skip
___
On 3/7/2011 9:31 PM, Reliable Domains wrote:
The launcher need not be called python.exe, and maybe it would be
better called #@launcher.exe (or similar, depending on its exact
function details).
I do not know that the '#@' part is about, but pygo would be short and
expressive.
--
Terry Jan
Well, after a couple of days with the cpython prefix stripped, I have
to say that I find it much less practical than it was before. Any other
opinions?
Regards
Antoine.
On Mon, 7 Mar 2011 01:11:24 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou
Antoine Ouch. I fear this message may be repeated several times :/
Antoine Sorry for the spam, if that happens...
Do you want me to reject or discard future messages to python-dev from
roundup-admin?
Skip
___
Python-Dev mailing list
Le mardi 08 mars 2011 à 14:51 -0600, s...@pobox.com a écrit :
Antoine Ouch. I fear this message may be repeated several times :/
Antoine Sorry for the spam, if that happens...
Do you want me to reject or discard future messages to python-dev from
roundup-admin?
Hopefully there won't be
Antoine Pitrou wrote:
Well, after a couple of days with the cpython prefix stripped, I have
to say that I find it much less practical than it was before. Any other
opinions?
I would rather have it back.
~Ethan~
___
Python-Dev mailing list
On 08.03.2011 21:29, Antoine Pitrou wrote:
Well, after a couple of days with the cpython prefix stripped, I have
to say that I find it much less practical than it was before. Any other
opinions?
From me, only the same opinion :)
Georg
___
On Tue, 08 Mar 2011 15:07:29 -0500
Terry Reedy tjre...@udel.edu wrote:
+If closes or fixes (with alternative verb forms like fixing
+allowed too) is prepended, the issue is automatically closed as
+fixed.
Fix may be too broad. This patch fixes the first part of the issue.
Ok, it has
On 08.03.2011 21:07, Terry Reedy wrote:
+If closes or fixes (with alternative verb forms like fixing
+allowed too) is prepended, the issue is automatically closed as
+fixed.
Fix may be too broad. This patch fixes the first part of the issue.
Well, you'd have to write This patch fixes
Am 08.03.2011 11:30, schrieb Stephen J. Turnbull:
Martin v. Löwis writes:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or
2011/3/8 Antoine Pitrou solip...@pitrou.net:
Well, after a couple of days with the cpython prefix stripped, I have
to say that I find it much less practical than it was before. Any other
opinions?
cpy maybe?
--
Regards,
Benjamin
___
Python-Dev
Am 08.03.2011 11:19, schrieb Antoine Pitrou:
On Tue, 08 Mar 2011 09:38:27 +0100
Martin v. Löwismar...@v.loewis.de wrote:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I
I think everything here is as it should be. People who really cared
about forwards compatibility could have known, but factually, most
people don't care enough. Those then learn for the first time that
some feature was deprecated after it is actually removed. They then
ask why it is removed, and
martin@mira:~/work/3k$ LANG=C hg -R tmp.bundle diff -r'ancestor(.,default)' -r
default
abort: unknown revision 'ancestor(.,default)'!
It looks like that was fixed a week after 1.6.4 was released, here:
http://hg.intevation.org/mercurial/crew/rev/2063d36b406e
It should work in 1.7.
Ah ok,
On 7 Mar 2011, at 09:33, Martin v. Löwis wrote:
Am 07.03.2011 10:14, schrieb Nick Coghlan:
On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
j...@arbash-meinel.com wrote:
Especially since, AIUI, deprecations are suppressed by default now.
True, but developers are expected to run their
If you want to see a project done in this year's GSoC,
please add it to
http://wiki.python.org/moin/SummerOfCode/2011
Python 3 related projects are preferred.
Students will look at this page for ideas what kinds of projects to
propose; the earlier you add an idea, the more likely is it that
Hi,
Le 08/03/2011 19:04, Daniel Stutzbach a écrit :
With a branch you can easily view the full patch, making a branch
strictly more general.
I just asked this before: how *exactly* do you do that?
I confess: I'm not sure exactly how to do it in hg. I know it's easy in
git; I assume it's
Hi,
First, thank you for stepping up again to work on the code review
integration.
It seems that the dev guide recommends to use the --git option in hg
diff.
From “hg help diffs”:
While this standard format [unified diff] is often enough, it does
not encode the following information:
On Tue, Mar 8, 2011 at 9:32 PM, Éric Araujo mer...@netwok.org wrote:
I’m of the opinion that hg diffs should always use the extended git
format, given their usefulness. A tool working with hg diffs that does
not support this format is broken IMO.
Can you please contribute changes to Rietveld
On 3/8/2011 12:02 PM, Terry Reedy wrote:
On 3/7/2011 9:31 PM, Reliable Domains wrote:
The launcher need not be called python.exe, and maybe it would be
better called #@launcher.exe (or similar, depending on its exact
function details).
I do not know that the '#@' part is about, but pygo
On Tue, Mar 08, 2011 at 06:43:19PM -0800, Glenn Linderman wrote:
On 3/8/2011 12:02 PM, Terry Reedy wrote:
On 3/7/2011 9:31 PM, Reliable Domains wrote:
The launcher need not be called python.exe, and maybe it would be
better called #@launcher.exe (or similar, depending
On 3/8/2011 8:02 PM, Toshio Kuratomi wrote:
On Tue, Mar 08, 2011 at 06:43:19PM -0800, Glenn Linderman wrote:
On 3/8/2011 12:02 PM, Terry Reedy wrote:
On 3/7/2011 9:31 PM, Reliable Domains wrote:
The launcher need not be called python.exe, and maybe it would be
better
On 9/03/2011 1:43 PM, Glenn Linderman wrote:
I'm of the opinion that attempting to parse a Unix #! line, and intuit
what would be the equivalent on Windows is unnecessarily complex and
error prone, and assumes that the variant systems are configured using
the same guidelines (which the Python
I’m of the opinion that hg diffs should always use the extended git
format, given their usefulness. A tool working with hg diffs that does
not support this format is broken IMO.
IMO, it's hg diff --git that's broken, as it doesn't include the base
revision (other formats, such as hg export,
On 3/8/2011 9:06 PM, Mark Hammond wrote:
On 9/03/2011 1:43 PM, Glenn Linderman wrote:
I'm of the opinion that attempting to parse a Unix #! line, and intuit
what would be the equivalent on Windows is unnecessarily complex and
error prone, and assumes that the variant systems are configured
Martin v. Löwis, 08.03.2011 23:47:
I think everything here is as it should be. People who really cared
about forwards compatibility could have known, but factually, most
people don't care enough. Those then learn for the first time that
some feature was deprecated after it is actually removed.
Martin v. Löwis writes:
Doesn't hg diff -r 'ancestor(branch,default)::branch', where branch
is the unmerged branch you would like to inspect, do the right thing?
What would I specify as branch if all I have is
http://bitbucket.com/turnbull/foo;, and know that it must be the
On 9/03/2011 5:05 PM, Glenn Linderman wrote:
Standard installation paths are accepted by about 99% of the users, so
embedding standard installation paths can work well for that batch of
users. Of course, Windows changes the standard path periodically, so
that it different from versions prior to
On 08.03.2011 23:47, Martin v. Löwis wrote:
I think everything here is as it should be. People who really cared
about forwards compatibility could have known, but factually, most
people don't care enough. Those then learn for the first time that
some feature was deprecated after it is actually
On 09.03.2011 06:44, Martin v. Löwis wrote:
I’m of the opinion that hg diffs should always use the extended git
format, given their usefulness. A tool working with hg diffs that does
not support this format is broken IMO.
IMO, it's hg diff --git that's broken, as it doesn't include the base
On 3/8/2011 10:27 PM, Mark Hammond wrote:
On 9/03/2011 5:05 PM, Glenn Linderman wrote:
Standard installation paths are accepted by about 99% of the users, so
embedding standard installation paths can work well for that batch of
users. Of course, Windows changes the standard path periodically,
Martin v. Loewis writes:
I’m of the opinion that hg diffs should always use the extended git
format, given their usefulness. A tool working with hg diffs that does
not support this format is broken IMO.
IMO, it's hg diff --git that's broken, as it doesn't include the base
62 matches
Mail list logo
