On Sun, 06 Mar 2011 04:54:06 +0100
Jesus Cea j...@jcea.es 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
Antoine Pitrou solip...@pitrou.net 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
On Sun, Mar 6, 2011 at 7:37 PM, ned.deily python-check...@python.org wrote:
http://hg.python.org/devguide/rev/ad3278cfc5f6
changeset: 376:ad3278cfc5f6
user: Ned Deily n...@acm.org
date: Sun Mar 06 01:37:13 2011 -0800
summary:
More miscellaneous review comments.
files:
On 06.03.2011 12:56, Stefan Krah wrote:
Antoine Pitrou solip...@pitrou.net 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
On 06.03.2011 12:56, Stefan Krah wrote:
Antoine Pitrou solip...@pitrou.net 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
On Sun, Mar 6, 2011 at 02:38, Antoine Pitrou solip...@pitrou.net 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
On Sun, Mar 6, 2011 at 10:17 PM, Georg Brandl g.bra...@gmx.net 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
On Sat, Mar 5, 2011 at 9:33 PM, Mark Hammond skippy.hamm...@gmail.com 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
Georg Brandl g.bra...@gmx.net 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
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 things
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 new
On Sun, Mar 6, 2011 at 7:52 AM, Stefan Krah stefan-use...@bytereef.org 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 Sun, 6 Mar 2011 21:58:24 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Mar 6, 2011 at 7:37 PM, ned.deily python-check...@python.org wrote:
http://hg.python.org/devguide/rev/ad3278cfc5f6
changeset: 376:ad3278cfc5f6
user: Ned Deily n...@acm.org
date: Sun Mar 06
On Sun, Mar 6, 2011 at 8:10 AM, Mark Hammond mhamm...@skippinet.com.au 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
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, 6 Mar 2011 08:17:35 -0600
Benjamin Peterson benja...@python.org 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,
On Mon, Mar 7, 2011 at 12:40 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 6 Mar 2011 08:17:35 -0600
Benjamin Peterson benja...@python.org 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,
On 6 March 2011 02:33, Mark Hammond skippy.hamm...@gmail.com 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
On Mon, 7 Mar 2011 00:52:08 +1000
Nick Coghlan ncogh...@gmail.com 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
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, Mar 7, 2011 at 12:56 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 7 Mar 2011 00:52:08 +1000
Nick Coghlan ncogh...@gmail.com 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 =
On Mon, 7 Mar 2011 01:11:24 +1000
Nick Coghlan ncogh...@gmail.com 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
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
Antoine Martin v. Löwis mar...@v.loewis.de 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
Le dimanche 06 mars 2011 à 09:50 -0600, s...@pobox.com a écrit :
Antoine Martin v. Löwis mar...@v.loewis.de 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
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 locally to
On Mon, Mar 7, 2011 at 1:44 AM, 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
On Mon, 07 Mar 2011 01:11:24 +1000, Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 7 Mar 2011 00:52:08 +1000
Nick Coghlan ncogh...@gmail.com 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 g.bra...@gmx.net 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
On 06.03.2011 17:10, R. David Murray wrote:
On Mon, 07 Mar 2011 01:11:24 +1000, Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 7 Mar 2011 00:52:08 +1000
Nick Coghlan ncogh...@gmail.com wrote:
I'm actually OK with
On Sun, 6 Mar 2011 17:32:40 +0100 (CET)
martin.v.loewis python-check...@python.org 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
On 06.03.2011 17:15, Nick Coghlan wrote:
On Mon, Mar 7, 2011 at 2:07 AM, Georg Brandl g.bra...@gmx.net 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
On 06/03/2011 13:14, Antoine Pitrou wrote:
On Sun, 6 Mar 2011 21:58:24 +1000
Nick Coghlanncogh...@gmail.com wrote:
On Sun, Mar 6, 2011 at 7:37 PM, ned.deilypython-check...@python.org wrote:
http://hg.python.org/devguide/rev/ad3278cfc5f6
changeset: 376:ad3278cfc5f6
user:Ned
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 needs
On Sun, 06 Mar 2011 16:52:54 +
Michael Foord fuzzy...@voidspace.org.uk wrote:
On 06/03/2011 13:14, Antoine Pitrou wrote:
On Sun, 6 Mar 2011 21:58:24 +1000
Nick Coghlanncogh...@gmail.com wrote:
On Sun, Mar 6, 2011 at 7:37 PM, ned.deilypython-check...@python.org
wrote:
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 lessons,
On 06/03/2011 17:05, Antoine Pitrou wrote:
On Sun, 06 Mar 2011 16:52:54 +
Michael Foordfuzzy...@voidspace.org.uk wrote:
On 06/03/2011 13:14, Antoine Pitrou wrote:
On Sun, 6 Mar 2011 21:58:24 +1000
Nick Coghlanncogh...@gmail.com wrote:
On Sun, Mar 6, 2011 at 7:37 PM,
On Sun, Mar 6, 2011 at 09:07, Michael Urman mur...@gmail.com 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
-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
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 clone,
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 message
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 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
Hammondmhamm...@skippinet.com.au wrote:
I think this discussion should be divorced from this PEP and taken up
with
the discussion
On Sat, Mar 5, 2011 at 11:39, Georg Brandl g.bra...@gmx.net 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
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 should
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 later
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
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 you need
On Sun, Mar 6, 2011 at 11:41, Michael Foord fuzzy...@voidspace.org.ukwrote:
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
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 idea.
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
On Sun, 06 Mar 2011 18:23:58 +0100
Martin v. Löwis mar...@v.loewis.de 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
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?
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 intent
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
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
hg clone 2.5 2.4
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
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 python2
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 wards
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
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
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
Antoine $ hg
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
Antoine
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
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 branch of the
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 consensus
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
In article
AANLkTimPEDWCsiOXfq=ppyypfkbmr-oja54m-cnaq...@mail.gmail.com,
Kerrick Staley m...@kerrickstaley.com 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
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
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.
I
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 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
apply
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
On Mon, Mar 7, 2011 at 3:05 AM, Antoine Pitrou solip...@pitrou.net 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 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?
2011/3/6 Barry Scott ba...@barrys-emacs.org:
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
On Mon, Mar 7, 2011 at 4:12 AM, Matthias Klose d...@ubuntu.com 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
On Mon, Mar 7, 2011 at 5:36 AM, Adrian Buehlmann adr...@cadifra.com 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
On Mon, Mar 7, 2011 at 9:09 AM, Barry Scott ba...@barrys-emacs.org 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
On 7/03/2011 1:55 AM, Paul Moore wrote:
On 6 March 2011 02:33, Mark Hammondskippy.hamm...@gmail.com 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
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 diff
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
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
In article 5ab965c9-7d5f-41b6-a5e9-2b881e92a...@barrys-emacs.org,
Barry Scott ba...@barrys-emacs.org 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
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 worse: the regular
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
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
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,
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 integration,
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
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
On Mon, Mar 7, 2011 at 3:02 PM, Kerrick Staley m...@kerrickstaley.com 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
On Mon, Mar 7, 2011 at 3:19 PM, Mark Hammond skippy.hamm...@gmail.com 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
On 7/03/2011 4:34 PM, Nick Coghlan wrote:
On Mon, Mar 7, 2011 at 3:19 PM, Mark Hammondskippy.hamm...@gmail.com 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
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 have a question about
95 matches
Mail list logo
