On 07.03.2011 00:16, Terry Reedy wrote:
> On 3/6/2011 11:07 AM, Georg Brandl wrote:
>> On 06.03.2011 16:44, s...@pobox.com wrote:
>>>
>>> Georg> Yesterday's repository was still the test repository, now it's
>>> Georg> the real one. You'll need to clone again.
>>>
>>> Thanks.
>>>
>>> I
On 7/03/2011 4:34 PM, Nick Coghlan wrote:
On Mon, Mar 7, 2011 at 3:19 PM, Mark Hammond wrote:
Without putting too much thought into it, I think a simple scheme could work
where the path must either be "/usr/bin/python[23]?" or a fully-qualified
path to a Python executable. IIUC, this should al
On Mon, Mar 7, 2011 at 3:19 PM, Mark Hammond wrote:
> Without putting too much thought into it, I think a simple scheme could work
> where the path must either be "/usr/bin/python[23]?" or a fully-qualified
> path to a Python executable. IIUC, this should allow most scripts to have a
> shebang li
On Mon, Mar 7, 2011 at 3:02 PM, Kerrick Staley wrote:
> I think that at this point there's been sufficient agreement that the
> technical issues on Windows are too complex to warrant addressing them in
> this PEP, and that a separate PEP will be written addressing Windows, so
> that is what will h
On 7/03/2011 3:30 PM, Glenn Linderman wrote:
I'm only against the overhead of a helper written in Python, since it
would have to launch Python (some explicit version) to run the helper
script, and then launch the "right" version of Python to execute the
real script. You mention a thin executable
I think that at this point there's been sufficient agreement that the
technical issues on Windows are too complex to warrant addressing them in
this PEP, and that a separate PEP will be written addressing Windows, so
that is what will happen. A new email thread for the Windows topic should be
start
Am 07.03.2011 03:43, schrieb Stephen J. Turnbull:
"Martin v. Löwis" writes:
> Am 07.03.2011 02:24, schrieb Stephen J. Turnbull:
> > "Martin v. Löwis" writes:
> >> It seems that the dev guide recommends to use the --git option in
hg
> >> diff. I'm working on the Rietveld
On 3/6/2011 7:07 AM, Michael Urman wrote:
I think Glenn Linderman hit the use cases on the head; I'm unclear why
he was against the overhead of a helper executable. The things I would
really want solutions for are these:
* double click on a script, and have it launch the right python (2 or
3, w
On 3/6/2011 6:09 PM, Barry Scott wrote:
I see that PyCObject_AsVoidPtr has been removed from python 3.2.
The 3.2 docs do not seem to explain this has happened and what
to replace it with.
I searched the 3.2 docs and failed to find PyCObject_AsVoidPtr.
I looked at the whats new page and the API P
On 3/6/2011 8:18 PM, Mark Hammond wrote:
To be clear, I was suggesting that using .bat files in system32 is a
close analogy to the *nix situation - I didn't mean to advocate for it
to actually happen :) Further, I see the creation of a python3.exe in
the Python install directory as quite differe
"Martin v. Löwis" writes:
> Am 07.03.2011 02:24, schrieb Stephen J. Turnbull:
> > "Martin v. Löwis" writes:
> > > It seems that the dev guide recommends to use the --git option in hg
> > > diff. I'm working on the Rietveld integration, and found that this
> > > option makes things wor
In article <5ab965c9-7d5f-41b6-a5e9-2b881e92a...@barrys-emacs.org>,
Barry Scott wrote:
> There is a break with convention for the include folder name:
>
> /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/
>
> What does the "m" mean?
The "m" means that the Python was config
Am 07.03.2011 02:24, schrieb Stephen J. Turnbull:
"Martin v. Löwis" writes:
> It seems that the dev guide recommends to use the --git option in hg
> diff. I'm working on the Rietveld integration, and found that this
> option makes things worse: the regular diff includes the base revision
On 7/03/2011 10:04 AM, Michael Foord wrote:
Paul Moore was +1 on Windows being included. Mark did accept that some
of the changes were "desirable", but was also concerned they didn't
address all the issues on Windows. I *would* like to see all the issues
addressed but I think that is outside the
"Martin v. Löwis" writes:
> It seems that the dev guide recommends to use the --git option in hg
> diff. I'm working on the Rietveld integration, and found that this
> option makes things worse: the regular diff includes the base revision
> of the patch; hg diff --git doesn't.
Does the regular
On 7/03/2011 1:55 AM, Paul Moore wrote:
On 6 March 2011 02:33, Mark Hammond wrote:
IIUC, the PEP language is referring to links which point to a specific
version of Python and that there is no suggestion a 'python3' will live in
the Python 3 binary tree. If that is correct and assuming we don'
On Mon, Mar 7, 2011 at 9:09 AM, Barry Scott wrote:
> I see that PyCObject_AsVoidPtr has been removed from python 3.2.
> The 3.2 docs do not seem to explain this has happened and what
> to replace it with.
>
> I searched the 3.2 docs and failed to find PyCObject_AsVoidPtr.
> I looked at the whats n
On Mon, Mar 7, 2011 at 5:36 AM, Adrian Buehlmann wrote:
> Not sure if it fits in your specific case you mention here, but
> Mercurial has a reserved path alias name "default-push" with special
> meaning:
>
> 'hg push' pushes to
>
> (1) the path defined as default-push under [paths] in .hg/hgrc
> (
On Mon, Mar 7, 2011 at 4:12 AM, Matthias Klose wrote:
>
> so -1 on the python link bits.
Some of the less mainstream distributions are starting to consider
moving to python3 as the *only* version of Python that is installed by
default, so I wanted to cover them in the suggestions (indeed, it was
2011/3/6 Barry Scott :
> I see that PyCObject_AsVoidPtr has been removed from python 3.2.
> The 3.2 docs do not seem to explain this has happened and what
> to replace it with.
It's replaced with PyCapsule.
--
Regards,
Benjamin
___
Python-Dev mailing
I see that PyCObject_AsVoidPtr has been removed from python 3.2.
The 3.2 docs do not seem to explain this has happened and what
to replace it with.
I searched the 3.2 docs and failed to find PyCObject_AsVoidPtr.
I looked at the whats new page and the API PEP. Did I miss
where this is documented?
On Mon, Mar 7, 2011 at 3:05 AM, Antoine Pitrou wrote:
>> > At least a manual checklist is able to explain you why
>> > the items are recommended.
>
> ... which make patchcheck's very terse output doesn't provide.
> That said I admit it can be useful to newcomers.
I'd say the opposite - I personal
There is a break with convention for the include folder name:
/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/
What does the "m" mean?
Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
On 3/6/2011 11:43 AM, Antoine Pitrou wrote:
compute the base rev. Most reviewable patches should apply cleanly
against the latest revision on "default",
That was sensible when we ported patches back, but if they should be
ported forward (3.1 => 3.2 => default), do we not want the patch to
ap
On 3/6/2011 11:07 AM, Georg Brandl wrote:
On 06.03.2011 16:44, s...@pobox.com wrote:
Georg> Yesterday's repository was still the test repository, now it's
Georg> the real one. You'll need to clone again.
Thanks.
I have a question about updates from cloned clones. Suppose I clone
On 3/6/2011 12:44 PM, Antoine Pitrou wrote:
Le dimanche 06 mars 2011 à 11:34 -0600, s...@pobox.com a écrit :
At this point you can push to the public repo from your "3.2" clone, or
repeat the above push& merge to your "default" clone (with the
"default" branch checked out) and push from there
On 06/03/2011 21:36, "Martin v. Löwis" wrote:
I should've mentioned that I'd like a consensus (or a lack of protest)
on the changes related to these snippets:
[...]
-"Exclusions of MS Windows"
I think you won't get consensus on that: there are strong proponents
and strong opponents (I think
In article
,
Kerrick Staley wrote:
> I should've mentioned that I'd like a consensus (or a lack of protest) on
> the changes related to these snippets:
> -"python will refer to the same target as either python2 or python3,
> depending on the specific distribution and system"
> -"the make install
I should've mentioned that I'd like a consensus (or a lack of protest)
on the changes related to these snippets:
[...]
-"Exclusions of MS Windows"
I think you won't get consensus on that: there are strong proponents and
strong opponents (I think Mark being a strong proponent of such
exclusio
> Heh, you are the author of the PEP :-)
> You'll find the source of your PEP in
> http://svn.python.org/projects/peps/trunk/
> Please provide Nick with a patch/updated version; if you want to,
> you can also get write access to the PEP repository.
I should've mentioned that I'd like a consensu
Martin> "Included", but not "available". The changes are in your "3.2
Martin> clone", but not in the "3.2 branch" of the "3.2 clone". Each
Martin> clone has all branches, even if you only "update" to one of
Martin> them.
Martin> So after "hg push", the change is on the "3.1 br
Beside Martin's answer, you might want to read:
http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
or perhaps:
http://hginit.com/
Regards
Antoine.
Le dimanche 06 mars 2011 à 14:46 -0600, s...@pobox.com a écrit :
> Antoine> Yes, there is. You can simply push to your 3.2 repo
Am 06.03.2011 21:46, schrieb s...@pobox.com:
Antoine> Yes, there is. You can simply push to your 3.2 repo instead:
Antoine> $ cd 3.1
Antoine> $ hg up 3.1# just in case
Antoine> # hack, compile, test
Antoine> $ hg ci -m "Issue #xxx: nasty bug now fixed"
An
Antoine> Yes, there is. You can simply push to your 3.2 repo instead:
Antoine> $ cd 3.1
Antoine> $ hg up 3.1# just in case
Antoine> # hack, compile, test
Antoine> $ hg ci -m "Issue #xxx: nasty bug now fixed"
Antoine> $ hg push ../3.2
Antoine> $ cd ../3.2
Antoi
Sorry, I was unaware that Gmail splits threads that are longer than 100
messages, so I hadn't seen the last 26 messages when I wrote the above
message. It seems that in the last 26 messages, there was lots of discussion
toward the inclusion of provisions for Windows in this PEP. I didn't mean to
si
Am 06.03.2011 21:12, schrieb Kerrick Staley:
Some nitpicks:
Heh, you are the author of the PEP :-)
You'll find the source of your PEP in
http://svn.python.org/projects/peps/trunk/
Please provide Nick with a patch/updated version; if you want to,
you can also get write access to the PEP repos
According to our security fix policy, Python 2.5 releases can happen
until September 2011. Since there are unreleased changes, I plan to
make a release "soon", which likely means April. I'll call this
tentatively the "final" release of Python 2.5, even though security
issues discovered after war
Some nitpicks:
'The "python" command on Unix-Like Systems':
This should be 'The "python" Command on Unix-Like Systems'
"python will refer to the same target as either python2 or python3,
depending on the specific distribution and system":
Nothing should break if python isn't the same as either py
Not sure if it fits in your specific case you mention here, but
Mercurial has a reserved path alias name "default-push" with special
meaning:
Ah. I didn't know that, thanks.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
On 2011-03-06 20:09, "Martin v. Löwis" wrote:
>>> So, when I cloned, I should have done something like this:
>>>
>>> hg clone http://hg.python.org/cpython
>>> hg clone cpython 3.2
>>> hg clone 3.2 3.1
>>> hg clone cpython 2.7
>>> hg clone 2.7 2.6
>>> hg clone 2.6 2.5
>
Would you like to contribute a patch to make that work? It's too tedious
to work without a base revision, so for the time being, this cannot be
supported.
Well, no. I was assuming that basing all patches on tip would make
things simpler.
It's very easy to get the base code if you know the base
I do not like the vagueness about the python link. Sounds like "It may point to
this or that, but it might change, and it might break, maybe we'll change our
position later, in some years".
I can understand the uneasiness about that, however, the slightly
sarcastic phrasing describes the inten
So, when I cloned, I should have done something like this:
hg clone http://hg.python.org/cpython
hg clone cpython 3.2
hg clone 3.2 3.1
hg clone cpython 2.7
hg clone 2.7 2.6
hg clone 2.6 2.5
hg clone 2.5 2.4
instead of cloning everything from cpython, right?
Y
On Sun, 06 Mar 2011 18:23:58 +0100
"Martin v. Löwis" wrote:
> >> -def find_bases(data, rev):
> >> +def hg_splitpatch(data):
> >> +patches = []
> >> +filename = None
> >> +for line in data.splitlines(True):
> >> +if line.startswith('diff -r'):
> >
> > Now I understand why you wo
On 04.03.2011 08:44, Kerrick Staley wrote:
[looking at version 88755 of the draft]
+1 on anything what is said about python2 (still remembering the unsuccessful
proposal from one of the Chicago language summits).
I do not like the vagueness about the python link. Sounds like "It may point to
th
On 06.03.2011 18:45, s...@pobox.com wrote:
>
> Nick> Given the recommended workflow in the devguide (i.e. when forward
> Nick> porting bug fixes, update all public branches in a single push),
> Nick> keeping the transitive connections between local clones is
> Nick> probably a good
On Sun, Mar 6, 2011 at 11:41, Michael Foord wrote:
> I would like to see us create version specific (i.e. python32.exe /
> python32w.exe) binaries (or links if we drop support for earlier versions of
> Windows or some filesystems - I'm agnostic on that issue) *plus* a
> python3.exe / python3w.exe
On 06.03.2011 18:39, s...@pobox.com wrote:
>
> Nick> Transitive. This is nice for the patch flow (fix in oldest, push,
> Nick> switch to next, merge, commit and push, etc, then only touch the
> Nick> central server for the final push of all branches), but it does
> Nick> you mean y
Nick> Given the recommended workflow in the devguide (i.e. when forward
Nick> porting bug fixes, update all public branches in a single push),
Nick> keeping the transitive connections between local clones is
Nick> probably a good idea. It also means that we can do the full
Nick
Le dimanche 06 mars 2011 à 11:34 -0600, s...@pobox.com a écrit :
> Assume I have separate 3.1 and 3.2 sandboxes
> which are sibling directories of each other, and that I commit a change to
> my 3.1 sandbox, how do I merge the change from 3.1 to 3.2? Assume I don't
> understand the instructions lat
Georg> If you don't change repo configuration after these commands, "hg
Georg> pull" in the 3.2 repo will pull from the local cpython repo. I'd
Georg> advise to set the "default" entry in each of the clones' .hg/hgrc
Georg> file to http://hg.python.org/cpython (as a committer you
On Sat, Mar 5, 2011 at 11:39, Georg Brandl wrote:
> Also please redirect praise to Antoine Pitrou and Dirkjan Ochtman who did
> most of the actual work.
>
> Georg
>
Many thanks to you three and anyone else who put in effort on this project.
It's excellent that this got completed in time for PyCo
On 06/03/2011 02:33, Mark Hammond wrote:
On 6/03/2011 12:37 AM, Michael Foord wrote:
On 05/03/2011 07:02, Nick Coghlan wrote:
On Sat, Mar 5, 2011 at 10:47 AM, Mark
Hammond wrote:
I think this discussion should be divorced from this PEP and taken up
with
the discussion about the PATH and the "l
Nick> Transitive. This is nice for the patch flow (fix in oldest, push,
Nick> switch to next, merge, commit and push, etc, then only touch the
Nick> central server for the final push of all branches), but it does
Nick> you mean you need to follow the reverse order when grabbing
On Mar 06, 2011, at 08:17 AM, Benjamin Peterson wrote:
>I wonder if we couldn't kill the "cpython" repo name in the commit
>mails. I find it wastes space for the commit message in the subject
>line, and it's pretty obvious it's the cpython repo from the branch
>name.
I agree that the commit messa
Antoine> This is sketched out in the devguide, I don't know if these
Antoine> instructions help you:
Antoine> http://docs.python.org/devguide/committing.html#forward-porting
Thanks. There is one problem (for me, at least):
Assuming you are doing all of your work in a single clon
-def find_bases(data, rev):
+def hg_splitpatch(data):
+patches = []
+filename = None
+for line in data.splitlines(True):
+if line.startswith('diff -r'):
Now I understand why you would like to discourage git diffs.
But, as I said back then, I don't think it's worthwhile to try
On Sun, Mar 6, 2011 at 09:07, Michael Urman wrote:
> I think Glenn Linderman hit the use cases on the head; I'm unclear why
> he was against the overhead of a helper executable.
Interpreter startup time is increasing with every version IIRC**, so adding
another slowdown means we have to step ve
On 06/03/2011 17:05, Antoine Pitrou wrote:
On Sun, 06 Mar 2011 16:52:54 +
Michael Foord wrote:
On 06/03/2011 13:14, Antoine Pitrou wrote:
On Sun, 6 Mar 2011 21:58:24 +1000
Nick Coghlan wrote:
On Sun, Mar 6, 2011 at 7:37 PM, ned.deily wrote:
http://hg.python.org/devguide/rev/ad3278c
On 02.03.2011 16:54, Nick Coghlan wrote:
> /tangent
>
> Does this discussion remind anyone else of the bash/dash switch for
> /usr/bin/sh in Ubuntu?
>
> The distro itself coped fine, but 3rd party shell scripts that used
> bash extensions were a whole different story.
>
> (No, I'm not sure what
On Sun, 06 Mar 2011 16:52:54 +
Michael Foord wrote:
> On 06/03/2011 13:14, Antoine Pitrou wrote:
> > On Sun, 6 Mar 2011 21:58:24 +1000
> > Nick Coghlan wrote:
> >
> >> On Sun, Mar 6, 2011 at 7:37 PM, ned.deily
> >> wrote:
> >>> http://hg.python.org/devguide/rev/ad3278cfc5f6
> >>> changeset
On 05/03/2011 22:18, "Martin v. Löwis" wrote:
Am 05.03.2011 19:26, schrieb Michael Foord:
On 28/02/2011 21:59, "Martin v. Löwis" wrote:
That's one of the big advantages that Jenkins (nee Hudson) has over
buildbot - drilling down into individual test failures through the
web ui. Your test run ne
On 06/03/2011 13:14, Antoine Pitrou wrote:
On Sun, 6 Mar 2011 21:58:24 +1000
Nick Coghlan wrote:
On Sun, Mar 6, 2011 at 7:37 PM, ned.deily wrote:
http://hg.python.org/devguide/rev/ad3278cfc5f6
changeset: 376:ad3278cfc5f6
user:Ned Deily
date:Sun Mar 06 01:37:13 2011 -0800
su
On 06.03.2011 17:15, Nick Coghlan wrote:
> On Mon, Mar 7, 2011 at 2:07 AM, Georg Brandl wrote:
>> If you don't change repo configuration after these commands, "hg pull" in the
>> 3.2 repo will pull from the local cpython repo. I'd advise to set the
>> "default"
>> entry in each of the clones' .h
On Sun, 6 Mar 2011 17:32:40 +0100 (CET)
martin.v.loewis wrote:
>
> -def find_bases(data, rev):
> +def hg_splitpatch(data):
> +patches = []
> +filename = None
> +for line in data.splitlines(True):
> +if line.startswith('diff -r'):
Now I understand why you would like to disco
On 06.03.2011 17:10, R. David Murray wrote:
> On Mon, 07 Mar 2011 01:11:24 +1000, Nick Coghlan wrote:
>> On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou wrote:
>> > On Mon, 7 Mar 2011 00:52:08 +1000
>> > Nick Coghlan wrote:
>> >>
>> >> I'm actually OK with the status quo, but if we were going to
On Mon, Mar 7, 2011 at 2:07 AM, Georg Brandl wrote:
> If you don't change repo configuration after these commands, "hg pull" in the
> 3.2 repo will pull from the local cpython repo. I'd advise to set the
> "default"
> entry in each of the clones' .hg/hgrc file to http://hg.python.org/cpython
> (
On Mon, 07 Mar 2011 01:11:24 +1000, Nick Coghlan wrote:
> On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou wrote:
> > On Mon, 7 Mar 2011 00:52:08 +1000
> > Nick Coghlan wrote:
> >>
> >> I'm actually OK with the status quo, but if we were going to change
> >> it, I would continue to leave (default
On Mon, Mar 7, 2011 at 1:44 AM, wrote:
>
> Georg> Yesterday's repository was still the test repository, now it's
> Georg> the real one. You'll need to clone again.
>
> Thanks.
>
> I have a question about updates from cloned clones. Suppose I clone the
> central repo then clone locally to
On 06.03.2011 16:44, s...@pobox.com wrote:
>
> Georg> Yesterday's repository was still the test repository, now it's
> Georg> the real one. You'll need to clone again.
>
> Thanks.
>
> I have a question about updates from cloned clones. Suppose I clone the
> central repo then clone loca
Le dimanche 06 mars 2011 à 09:50 -0600, s...@pobox.com a écrit :
> Antoine> "Martin v. Löwis" wrote:
> >> What is the recommended merge flow if I want to make this change to
> >> all branches?
>
> Antoine> - on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain
> Antoine>
Antoine> "Martin v. Löwis" wrote:
>> What is the recommended merge flow if I want to make this change to
>> all branches?
Antoine> - on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain
Antoine> 2.5)
Antoine> - on the other hand: 3.1 -> 3.2 -> default
Sorry,
Georg> Yesterday's repository was still the test repository, now it's
Georg> the real one. You'll need to clone again.
Thanks.
I have a question about updates from cloned clones. Suppose I clone the
central repo then clone locally to get the 2.7 and 3.2 release branches:
hg clone
On Mon, 7 Mar 2011 01:11:24 +1000
Nick Coghlan wrote:
>
> [python-checkins] Lorem ipsum dolor sit amet
> [python-checkins] (3.1): Lorem ipsum dolor sit amet
> [python-checkins] devguide: Lorem ipsum dolor sit amet
> [python-checkins] devguide (hg_migration): Lorem ipsum dolor sit amet
If you rea
On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou wrote:
> On Mon, 7 Mar 2011 00:52:08 +1000
> Nick Coghlan wrote:
>>
>> I'm actually OK with the status quo, but if we were going to change
>> it, I would continue to leave (default) out.
>>
>> Completely unqualified = cpython default
>> Only branch
Using batch files is a poor idea, IMO, because you have to explicitly
call a batch file from another, or the remainder of the caller will
not execute. Installing to System32 s also questionable, but if it's
just the launchers, it might be okay. From an installer's perspective,
it would really help
On Mon, 7 Mar 2011 00:52:08 +1000
Nick Coghlan wrote:
>
> I'm actually OK with the status quo, but if we were going to change
> it, I would continue to leave (default) out.
>
> Completely unqualified = cpython default
> Only branch name = cpython branch
> Only repository name = other repository
On 6 March 2011 02:33, Mark Hammond wrote:
> IIUC, the PEP language is referring to links which point to a specific
> version of Python and that there is no suggestion a 'python3' will live in
> the Python 3 binary tree. If that is correct and assuming we don't want to
> investigate using links o
On Mon, Mar 7, 2011 at 12:40 AM, Antoine Pitrou wrote:
> On Sun, 6 Mar 2011 08:17:35 -0600
> Benjamin Peterson wrote:
>> I wonder if we couldn't kill the "cpython" repo name in the commit
>> mails. I find it wastes space for the commit message in the subject
>> line, and it's pretty obvious it's
On Sun, 6 Mar 2011 08:17:35 -0600
Benjamin Peterson wrote:
> I wonder if we couldn't kill the "cpython" repo name in the commit
> mails. I find it wastes space for the commit message in the subject
> line, and it's pretty obvious it's the cpython repo from the branch
> name.
Well, right now commi
I wonder if we couldn't kill the "cpython" repo name in the commit
mails. I find it wastes space for the commit message in the subject
line, and it's pretty obvious it's the cpython repo from the branch
name.
--
Regards,
Benjamin
___
Python-Dev mailing
On Sun, Mar 6, 2011 at 8:10 AM, Mark Hammond wrote:
> That sounds like a reasonable scheme people may choose to use - however, it
> doesn't really address the basic issue - something still needs to add
> c:\Python to PATH, and the scheme itself doesn't really necessitate the
> common parent direct
On Sun, 6 Mar 2011 21:58:24 +1000
Nick Coghlan wrote:
> On Sun, Mar 6, 2011 at 7:37 PM, ned.deily wrote:
> > http://hg.python.org/devguide/rev/ad3278cfc5f6
> > changeset: 376:ad3278cfc5f6
> > user: Ned Deily
> > date: Sun Mar 06 01:37:13 2011 -0800
> > summary:
> > More miscell
On Sun, Mar 6, 2011 at 7:52 AM, Stefan Krah wrote:
> It does here after a fresh clone:
Thats because it never got the revision that closed that branch, just
merge http://hg.python.org/cpython/rev/b77918288f7d to
http://hg.python.org/features/py3k-cdecimal/
On 6/03/2011 11:51 PM, Dj Gilcrease wrote:
> Why not modify the windows installers to install into C:\Python\X.Y
> and have the .bat files generated in C:\Python which is what I have
> been doing manually since py25. I just add C:\Python to the system
> Path then create/modify the bat files for ne
Hi,
> I assume Stefan was referring to the features/py3k-cdecimal clone
> rather than the cpython one. This is going to happen with all the
> server-side clones - we really only want "default" in the clone, but
> the maintenance branches will come along for the ride. There are
> actually a few t
Georg Brandl wrote:
> > 2) 3.2, 3.1 and legacy-trunk show up as 'inactive' on the command line, but
> > not in the web interface. Should these be closed to avoid confusion?
>
> Hmm, and legacy-trunk should already be closed actually. It does not show
> up in "hg branches" for me.
It does here a
On Sat, Mar 5, 2011 at 9:33 PM, Mark Hammond wrote:
> IIUC, the PEP language is referring to links which point to a specific
> version of Python and that there is no suggestion a 'python3' will live in
> the Python 3 binary tree. If that is correct and assuming we don't want to
> investigate usin
On Sun, Mar 6, 2011 at 10:17 PM, Georg Brandl wrote:
>> 2) 3.2, 3.1 and legacy-trunk show up as 'inactive' on the command line, but
>> not in the web interface. Should these be closed to avoid confusion?
>
> Hmm, and legacy-trunk should already be closed actually. It does not show
> up in "hg bra
On Sun, Mar 6, 2011 at 02:38, Antoine Pitrou wrote:
> For the record, the reason these emails look a bit strange (and appear
> to be pushed by Dirkjan (sorry)) is that they were done directly on the
> server with the settings of the local user "hg".
FWIW, I have a tiny extension at work that can
On 06.03.2011 12:56, Stefan Krah wrote:
> Antoine Pitrou wrote:
>> > Is that really going to work? I.e. will Mercurial be able to merge from
>> > default to one of the feature branches? If so, what will be the
>> > procedure? What would be the exact steps to try this out on the PEP 382
>> > branch
On 06.03.2011 12:56, Stefan Krah wrote:
> Antoine Pitrou wrote:
>> > Is that really going to work? I.e. will Mercurial be able to merge from
>> > default to one of the feature branches? If so, what will be the
>> > procedure? What would be the exact steps to try this out on the PEP 382
>> > branch
On Sun, Mar 6, 2011 at 7:37 PM, ned.deily wrote:
> http://hg.python.org/devguide/rev/ad3278cfc5f6
> changeset: 376:ad3278cfc5f6
> user: Ned Deily
> date: Sun Mar 06 01:37:13 2011 -0800
> summary:
> More miscellaneous review comments.
>
> files:
> committing.rst
> communication.
Antoine Pitrou wrote:
> > Is that really going to work? I.e. will Mercurial be able to merge from
> > default to one of the feature branches? If so, what will be the
> > procedure? What would be the exact steps to try this out on the PEP 382
> > branch (say)?
>
> I've sketched out the steps in
>
On Sun, 06 Mar 2011 04:54:06 +0100
Jesus Cea wrote:
> I would rather prefer to promote the "-A" parameter to SSH (to use the
> local SSH agent be used from the remote development machine) instead of
> uploading private keys.
That's not a good answer to the question, since it cannot apply to
machi
95 matches
Mail list logo
