"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
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, s
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 inclu
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 i
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
"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
"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.
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 using
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 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 com
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 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, d
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 wou
On Tue, Mar 8, 2011 at 9:32 PM, Éric Araujo 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 to support that
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
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
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 yo
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
>> wrote:
>>>
>>> Especially since, AIUI, deprecations are suppressed by default now.
>>
>> True, but developers are expected to run their tests w
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, it
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 s
Am 08.03.2011 11:19, schrieb Antoine Pitrou:
On Tue, 08 Mar 2011 09:38:27 +0100
"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 abo
2011/3/8 Antoine Pitrou :
>
> 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 mailing list
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
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 "Th
On Tue, 08 Mar 2011 15:07:29 -0500
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."
Ok, it has
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
___
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
Python-De
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
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
Python-De
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 wrote:
> On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou wrote:
> > On M
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 Ja
>> 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
___
P
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 wrote:
>
>
> You are not a registered user.
>
> Unknown address: python-dev@python.org
>
_
Greg Ewing 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:
- clon
An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
Return-Path:
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 ps
An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
Return-Path:
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 ps
You are not a registered user.
Unknown address: python-dev@python.org
Return-Path:
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 psf.upfronthosting.co.za (Postfix) with ESM
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
> ver
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,
On Tue, Mar 8, 2011 at 12:34 AM, "Martin v. Löwis" wrote:
> 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
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 08.03.2011 14:19, Antoine Pitrou wrote:
> On Tue, 08 Mar 2011 12:23:54 +0100
> local wrote:
>> +
>> +VERBS = r'(?:\b(?Pclose[sd]?|closing|fixe[sd]|fixing|fix)\s+)?'
>> +ISSUE_PATTERN = re.compile(r'%s(?:#|\bissue|\bbug)\s*(?P[0-9]+)'
>> + % VERBS, re.I)
>
> This shoul
On Tue, Mar 8, 2011 at 03:40, Gertjan Klein 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 be reverted
On Tue, Mar 8, 2011 at 03:33, "Martin v. Löwis" 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 the highest 2.
On Tue, 08 Mar 2011 12:23:54 +0100
local wrote:
> +
> +VERBS = r'(?:\b(?Pclose[sd]?|closing|fixe[sd]|fixing|fix)\s+)?'
> +ISSUE_PATTERN = re.compile(r'%s(?:#|\bissue|\bbug)\s*(?P[0-9]+)'
> + % VERBS, re.I)
This should only match numbers with 4 and 5 figures IMO.
Otherwis
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 installe
"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 d
On Tue, 08 Mar 2011 09:38:27 +0100
"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).
>
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 t
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 Krah 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 some
Georg Brandl 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 mirror of th
Am 08.03.2011 10:49, schrieb Dirkjan Ochtman:
On Tue, Mar 8, 2011 at 10:45, Stefan Krah 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:
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, t
On Tue, Mar 8, 2011 at 10:45, Stefan Krah 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 http://svn.python.org/p
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 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 d
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 installe
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..
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
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 c
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
in
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
http://mail.python.org/mailman/listinfo/
62 matches
Mail list logo
