On 22/06/2012 8:14 AM, Brian Curtin wrote:
On Wed, Jun 20, 2012 at 11:54 AM, Brian Curtin wrote:
As the PEP czar for 397, after Martin's final updates, I hereby
pronounce this PEP "accepted"!
Thanks to Mark Hammond for kicking it off, Vinay Sajip for writing up
the code, Martin
Sorry, but I missed the announcement of an updated PEP.
It looks good to me! Also, I see no reason not to always use a 32bit
version of the launcher other than (a) the 64bit code already exists and
works and (b) it might mean it is no longer possible to do a complete
build of a 64bit Python w
Vinay originally wrote:
PEP 397 (Python launcher for Windows) has not yet been accepted, so there still
needs to be some way of natively launching scripts in Windows which is
equivalent to /path/to/venv/bin/foo. The way setuptools (and hence Distribute)
does this is to shadow each script with an
On 23/03/2012 7:10 PM, Paul Moore wrote:
On 23 March 2012 03:20, Brian Curtin wrote:
Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have
all expressed that they have existing tools that would break and would need
to be adjusted to match the new location of the python.exe
[snipped some CCs]
On 23/03/2012 2:20 PM, Brian Curtin wrote:
...
I get that tools could be affected. I had two IDE makers at PyCon
immediately throw up red flags to this change. I think one of them was
about to charge the stage during my talk. When it was mentioned that
we could point them to t
e" above. What would the instructions above now say?
That the user should re-install Python ensuring to set that checkbox?
Cover both cases, including how the user can tell if it is on the PATH
and how to fix it otherwise? Something else?
Breakage of existing tools: Mark Hammond, Paul Moore, and Tim
On 22/03/2012 1:22 AM, Lindberg, Van wrote:
Mark, MAL, Martin, Tarek,
Could you comment on this?
Eric is correct - tools will be broken by this change. However, people
seem willing to push forward on this and accept such breakage as the
necessary cost.
MAL, in his followup, asks what the
On 21/03/2012 9:45 AM, R. David Murray wrote:
On Wed, 21 Mar 2012 09:09:38 +1100, Mark Hammond
wrote:
On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
I asked a question about this on IRC, to which the response was that
there were two main reasons to install python in c:\pythonxy:
1 - issues
On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
On 13 March 2012 20:43, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows, with
a side order of making the PATH work better.
As this is being co
On 21/03/2012 1:08 AM, Lindberg, Van wrote:
On 3/20/2012 5:48 AM, Mark Hammond wrote:
While I'm still unclear on the actual benefits of this, Martin's
approach strikes a reasonable compromise so I withdraw my objections.
Ok. I was out of town and so could not respond to most of
For those who missed it, in http://bugs.python.org/issue14302, Martin
recently commented:
"""
After more discussion, it appears that this change is too incompatible
to be done in a single release.
Therefore, I propose a long-term change into this direction, with the
actual change not happeni
On 17/03/2012 12:25 PM, Carl Meyer wrote:
Hi Mark,
On 03/16/2012 05:53 PM, Mark Hammond wrote:
* All executables and scripts go into the root of the Python install.
This directory is largely empty now - it is mainly a container for other
directories. This would solve the problem of needing 2
On 17/03/2012 12:07 PM, Brian Curtin wrote:
On Fri, Mar 16, 2012 at 19:53, Mark Hammond wrote:
For the sake of brain-storming, how about this:
* All executables and scripts go into the root of the Python install. This
directory is largely empty now - it is mainly a container for other
On 14/03/2012 6:43 AM, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows,
with a side order of making the PATH work better.
...
For the sake of brain-storming, how about this:
* All executabl
On 17/03/2012 7:22 AM, Carl Meyer wrote:
...
I don't want to make the internal layout of a virtualenv differ from the
system Python layout on the same platform, which (IIUC) was Mark's proposal.
Just to be clear, I made that suggestion in an effort to keep both
myself and Van - that the Pytho
On 16/03/2012 10:48 AM, Carl Meyer wrote:
...
The implementation of virtualenv (and especially PEP 405 pyvenv) are
largely based around making sure that the internal layout of a
virtualenv is identical to the layout of an installed Python on that
same platform, to avoid any need to special-case
On 16/03/2012 8:57 AM, VanL wrote:
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
I'm not so sure. My concern is that this *will*
[resending - original reply went only to Van]
On 15/03/2012 10:15 AM, Lindberg, Van wrote:
> On 3/14/2012 5:39 PM, Mark Hammond wrote:
>> Can you offer any examples of 3rd party tools which could unify code
>> in this scheme, and particularly, where this scheme would cause them
On 15/03/2012 3:03 AM, Lindberg, Van wrote:
On 3/14/2012 1:32 AM, Mark Hammond wrote:
As per comments later in the thread, I'm -1 on including
"python{py_version_short}" in the lib directories for a number of
reasons; one further reason not outlined is that it would potential
On 14/03/2012 6:43 AM, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows,
with a side order of making the PATH work better.
Short version:
1) The layout for the python root directory for all pl
On 22/02/2012 2:50 AM, Vinay Sajip wrote:
Mark Hammond gmail.com> writes:
think there is something that could be added to those docs - the use of
PATHEXT and the fact that once the shebang line is in place, a
command-prompt could do just "hello.py" rather than needing "
On 21/02/2012 2:54 AM, Mark Lawrence wrote:
On 18/02/2012 05:24, Mark Hammond wrote:
...
* Write some user-oriented docs.
The section in the docs "Using Python on Windows" would need to be
updated, but would this have to happen for every current version of Python?
I'm not
On 18/02/2012 11:08 PM, mar...@v.loewis.de wrote:
Zitat von Mark Hammond :
I'm wondering what thoughts are on PEP 397, the Python launcher for
Windows. I've been using the implementation for a number of months now
and I find it incredibly useful.
I wonder what the rationale for t
On 18/02/2012 4:37 PM, Brian Curtin wrote:
On Fri, Feb 17, 2012 at 23:24, Mark Hammond wrote:
I'm wondering what thoughts are on PEP 397, the Python launcher for Windows.
I've been using the implementation for a number of months now and I find it
incredibly useful.
To my mind, th
I'm wondering what thoughts are on PEP 397, the Python launcher for
Windows. I've been using the implementation for a number of months now
and I find it incredibly useful.
To my mind, the specific steps would be:
* Have someone pronounce it as accepted (or suggest steps to be taken
before su
On 17/02/2012 7:44 PM, Egon Smiwa wrote:
Hi all,
I'm an app developer with a CPython dll in the folder of that app.
In general, are there strict requirements about the dll name
(a preference would be "python.dll" (easy to update (simple replace) ).
I successfully used "python.dll" and a few stand
FWIW, the most recent version of pywin32 has the following download
counts (rounded to the nearest thousand)
Version 32bit 64bit
-
3.2 - 75,000 9,000
3.1 - 4,000 1,000
2.7 - 126,000 16,000
2.6 - 46,000 6,000
2.5 - 21,000 n/a
2.4 -
On 31/10/2011 8:39 AM, Victor Stinner wrote:
Le 29/10/2011 07:47, Mark Hammond a écrit :
When previously discussing this issue, I was under the impression that
the problem was unencodable bytes passed from the Python code to Windows
- but the reverse is true - only the data coming back from
On 29/10/2011 9:52 AM, Victor Stinner wrote:
Hi,
I am not more conviced that raising a UnicodeEncodeError on unencodable
characters is the right fix for the issue #13247. The problem with this
solution is that you have to wait until an user get a UnicodeEncodeError.
I have yet another propositi
+1 from me!
Mark
On 25/10/2011 9:57 AM, Victor Stinner wrote:
Hi,
I propose to raise Unicode errors if a filename cannot be decoded on Windows,
instead of creating a bogus filenames with questions marks. Because this change
is incompatible with Python 3.2, even if such filenames are unusable a
On 24/10/2011 12:56 PM, Michael Urman wrote:
On Sun, Oct 23, 2011 at 17:15, Mark Hammond wrote:
How about abusing the existing flags for this purpose - eg:
% py -3?
% py -2.7?
I would have expected that to launch an interactive python shell of
the appropriate version. Does it do something
On 24/10/2011 11:46 AM, Nick Coghlan wrote:
On Mon, Oct 24, 2011 at 10:00 AM, Mark Hammond wrote:
* The "magic" symbol is somewhat self-documenting - it implies a question.
Using --which adds another special case that people would need to
understand isn't passed to Python. I
On 24/10/2011 10:36 AM, Nick Coghlan wrote:
On Mon, Oct 24, 2011 at 8:15 AM, Mark Hammond wrote:
How about abusing the existing flags for this purpose - eg:
% py -3?
% py -2.7?
What does using the magic symbol offer over an explicit separate flag?
* The "magic" symbol is som
On 23/10/2011 12:27 AM, Paul Moore wrote:
(Sorry, should have gone to the list...)
On 22 October 2011 13:15, Vinay Sajip wrote:
Nick Coghlan gmail.com> writes:
As a simpler alternative, I suggest the launcher just gain a "--which"
long option that displays the full path to the interpreter
On 18/10/2011 8:59 PM, Sam Partington wrote:
...
I added shebangs to
all files as appropriate for devel/stable branch, and initially I
changed the python build targets from "python -utt build.py" to
"./build.py" and I lost the -utt functionality which I could live
with.
Can't you just put the
On 18/10/2011 3:24 AM, PJ Eby wrote:
On Mon, Oct 17, 2011 at 8:55 AM, Sam Partington
mailto:sam.parting...@gmail.com>> wrote:
Yes it is a bit annoying to have to treat those specially, but other
than -c/-m it does not need to understand pythons args, just check
that the arg is not
On 17/10/2011 9:10 PM, Sam Partington wrote:
Hello all,
I was surprised to see that the excellent pylauncher doesn't do the
magic shebang processing if you give it any python command line
options. e.g. Given
#!/usr/bin/env python2.6
import sys
print(sys.executable)
C:\>py test.py
C:\Python26\
On 22/07/2011 9:02 AM, Glenn Linderman wrote:
Bad logic is get_configured_value! get_configured_value only looks in
the global configuration file if there is a local configuration file
that doesn't have the setting. It should look in the global
configuration file if there is no local configurat
On 21/07/2011 10:13 PM, anatoly techtonik wrote:
If you're going to include this into standard Python distribution, it
needs more attention from _users_. As a user, I can not find any
references to any user stories in this PEP article. Abstract chapter
is totally useless
Could you please be a l
On 21/07/2011 6:32 PM, Glenn Linderman wrote:
On 7/20/2011 11:35 PM, Mark Hammond wrote:
* If the command starts with the definition of a customized command
followed by a space character, the customized command will be used.
See below for a description of customized commands
her for Windows
Version: $Revision$
Last-Modified: $Date$
Author: Mark Hammond
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 15-Mar-2011
Post-History: 21-July-2011, 17-May-2011, 15-Mar-2011
Abstract
This PEP describes a Python launcher for the Windows platform. A
On 21/07/2011 10:18 AM, Glenn Linderman wrote:
On 7/20/2011 5:07 PM, Nick Coghlan wrote:
On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman wrote:
I would say that would be a cool enhancement, as it could save a bit of
typing, but I think the launcher is quite useful even without path
traversal.
T
On 21/07/2011 10:13 AM, Glenn Linderman wrote:
On 7/20/2011 2:43 PM, Glenn Linderman wrote:
It's not py's job to walk the path: the shell does that when you just type
"foo". It locates foo.py, and then invokes py because of file association - py
then checks the file for a shebang to decide which
On 21/07/2011 10:08 AM, Antoine Pitrou wrote:
On Thu, 21 Jul 2011 09:55:28 +1000
Mark Hammond wrote:
> The two proposals
overlap but are not mutually exclusive. For future pythons, 'python33'
is easier to remember and type than 'py -v 3.3' or whatever the propose
On 21/07/2011 10:02 AM, Glenn Linderman wrote:
So this tells me that it didn't find a local py.ini (no surprise, I
don't have one) but doesn't tell me that it did find or read
c:\Windows\system32\py.ini much less whether I have the syntax correct
for my [defaults] section. It doesn't tell me tha
On 21/07/2011 4:38 AM, Terry Reedy wrote:
Many installers first make an organization directory and then an app
directory within that. This annoys me sometimes when they only have one
app to ever install, but is useful when there might really be multiple
directories, as in our case. (Ditto for st
On 21/07/2011 7:43 AM, Glenn Linderman wrote:
...
I still get the same behavior. Is there any debugging output produced
by py.exe that would tell what py.ini it looks in, and what the content
is? What diagnostic steps might I take to produce additional
information that would help you (or me, a
On 20/07/2011 1:00 AM, Paul Moore wrote:
On 19 July 2011 02:41, Vinay Sajip wrote:
The use of py from the command line is merely a convenience for developers (as
the PEP says) - it's better to rely on shebang lines together with settings in
the .ini to get the behaviour you want.
But it's a *
On 2/07/2011 5:16 PM, I wrote:
Given [the C implementation] is now ahead of the Python
reference impl, I wonder if we should just drop all wording about that
reference impl and just treat the C impl as canonical?
I'm looking to update the PEP based on this discussion - does anyone
object to t
On 5/07/2011 11:23 AM, Greg Ewing wrote:
Vinay Sajip wrote:
the installation of a pre-3.3 version of Python after Python 3.3 is
installed with the launcher will, if the user selects "Register
Extensions",
hijack the laumcher's associations to that earlier Python. Then bye
bye launcher
I don't
On 4/07/2011 3:59 PM, Greg Ewing wrote:
Mark Hammond wrote:
On 2/07/2011 7:08 PM, Vinay Sajip wrote:
perhaps we could remember the last non-launcher association when we
install the launcher,
It might be better to look in the registry for other Python
installations and ask the user which
On 2/07/2011 7:08 PM, Vinay Sajip wrote:
Mark Hammond gmail.com> writes:
The PEP does say "if possible, should be installed somewhere likely to
already be on the system PATH (eg., the Windows System32) directory."
It is silent about what to do when that isn't possible, but
On 1/07/2011 7:20 PM, Vinay Sajip wrote:
Mark Hammond gmail.com> writes:
The intention is that there only be a single launcher, as only one app
can be associated with .py files. OTOH though, file associations can be
configured per-user IIRC, and assuming that is the case, we could avoid
On 30/06/2011 10:09 PM, Vinay Sajip wrote:
There's a lot to like in the PEP, and I have some questions relating to the
latest version:
1. In the section on shebang line parsing, it says "If the command starts with
the definition of a customized command followed by a space character, the
customiz
On 30/06/2011 3:00 AM, Vinay Sajip wrote:
PEP 397 (Python launcher for Windows) has a reference implementation in Python.
Does anyone know of a C implementation, or is planning/working on one? I realise
this is the final objective, so such implementation might be premature, but
perhaps someone ha
: 397
Title: Python launcher for Windows
Version: $Revision$
Last-Modified: $Date$
Author: Mark Hammond
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 15-Mar-2011
Post-History: 17-May-2011, 15-Mar-2011
Abstract
This PEP describes a Python launcher for the Windows platf
On 2/05/2011 9:27 PM, Ned Batchelder wrote:
...
Maybe the fact no one noticed the docs
were wrong proves that no one ever tried returning None from a local
trace function.
Or if they did, they should have complained by now. IMO, if the
behaviour regresses from how it is documented and how it
Hi,
There are a couple of changes I'd like to make and would like some
guidance on policy:
http://bugs.python.org/issue6498 is a documentation bug which exists in
Python 2.6 and later. The patch in that bug touches the docs and a
comment in one source file. Is it acceptable to push that c
On 30/03/2011 1:37 PM, R. David Murray wrote:
On Wed, 30 Mar 2011 12:17:05 +1100, Mark Hammond
wrote:
On 30/03/2011 12:09 PM, R. David Murray wrote:
The solution is to add such
directories and/or files to your personal ignore list See the 'ignore'
entry under 'ui' in th
On 30/03/2011 12:09 PM, R. David Murray wrote:
On Wed, 30 Mar 2011 11:11:45 +1100, Mark Hammond
wrote:
I'm wondering if it is a reasonable idea to have .hgignore exclude all
files from 'Lib/site-packages' and 'Scripts'? As I install packages
into my source builds,
I'm wondering if it is a reasonable idea to have .hgignore exclude all
files from 'Lib/site-packages' and 'Scripts'? As I install packages
into my source builds, a 'hg status' lists *many* files in both those
directories forcing me to scroll up a number of pages to see files which
have actuall
On 24/03/2011 1:20 PM, Michael Foord wrote:
On 24/03/2011 00:44, Dj Gilcrease wrote:
On Wed, Mar 23, 2011 at 8:14 PM, Mark
Hammond wrote:
If you guys (or anyone) would like to agree on some precise rules for
both
the location of the config file and its contents and express this as
a patch
to
On 24/03/2011 4:34 AM, Ethan Furman wrote:
Michael Foord wrote:
To be honest I would be happy with registry entries instead as the
alternative implementations can then add to their installers (or
provide a script) to add the right registry entry.
I'm partial to the config file method myself. I
On 23/03/2011 6:12 AM, Michael Foord wrote:
On 22/03/2011 07:21, Mark Hammond wrote:
Hi all,
I've made some changes to the draft PEP and checked it into the PEP
repository as PEP397. The reference implementation is currently being
tracked at http://bugs.python.org/issue11629.
Hey Mark,
think and what objections/comments/etc remain.
Thanks,
Mark
PEP: 397
Title: Python launcher for Windows
Version: $Revision$
Last-Modified: $Date$
Author: Mark Hammond
Status: Draft
Type: Standards Track or Informational ?
Content-Type: text/x-rst
Created: 15-Mar-2011
Abstract
This PEP describ
On 22/03/2011 8:09 AM, Barry Warsaw wrote:
I started an Informational PEP on this at Pycon, and will try to finish a
draft of it this week. (I'm claiming 396 for it.)
We nearly had a race for that number! FYI, I just checked in pep-0397
leaving 396 for you :)
Cheers,
Mark
_
On 22/03/2011 12:04 AM, Paul Moore wrote:
I haven't had time to read the PEP yet, so my apologies if this is
made explicit there, but is the launcher expected to be solely for
implementing file associations? I thought there had been discussions
of using it to start the interactive interpreter, an
On 21/03/2011 1:04 PM, "Martin v. Löwis" wrote:
Can you please add a summary of this discussion to
the PEP? (also, can you please check in the PEP, and
> give it a number?)
OK, I'll check it in once I get a PEP number allocated as per PEP1,
updated to reflect some of the discussions in this th
On 21/03/2011 3:50 PM, Greg Ewing wrote:
Martin v. Löwis wrote:
Windows doesn't support exec.
Hmmm. In that case, if the launcher works by loading a pythonXY.dll,
I'd say that sys.executable should point to whatever version of
python.exe corresponds to that dll.
Generally, things should be m
On 21/03/2011 12:27 PM, "Martin v. Löwis" wrote:
I remain -1 on any proposal that uses subprocesses. It absolutely must
be the launcher that is running Python. In fact, I'd call it
"python.exe".
For clarity, could you please tell us which scenarios you have in mind
that cause you to take that p
On 21/03/2011 11:15 AM, "Martin v. Löwis" wrote:
Am 21.03.2011 00:43, schrieb Greg Ewing:
Mark Hammond wrote:
The above raises an interesting question - if the launcher executed
Python in-process, what would sys.executable be?
I think it should be the actual Python executing at t
On 21/03/2011 11:10 AM, "Martin v. Löwis" wrote:
Am 21.03.2011 00:52, schrieb Mark Hammond:
On 21/03/2011 10:32 AM, "Martin v. Löwis" wrote:
The above raises an interesting question - if the launcher executed
Python in-process, what would sys.executable be? I can i
On 21/03/2011 10:32 AM, "Martin v. Löwis" wrote:
The above raises an interesting question - if the launcher executed
Python in-process, what would sys.executable be? I can imagine there
are few scenarios where it would be desirable to have it refer to the
launcher and a number of scenarios where
On 20/03/2011 11:56 PM, Dj Gilcrease wrote:
...
Before Mark wrote up this pep I had started experimenting with how to
make the launcher and I was able to get it to launch python while
exiting py.exe and as far as I could tell it behaved just as if I had
launched the app directly by double clickin
Following up myself here...
On 20/03/2011 9:25 PM, Mark Hammond wrote:
On 20/03/2011 8:37 PM, "Martin v. Löwis" wrote:
...
Some of these uses probably shouldn't use the launcher directly - eg,
ISAPI apps and COM objects which have a separate registration step could
register a spec
On 20/03/2011 8:37 PM, "Martin v. Löwis" wrote:
...
... problems with creating child processes:
- applications using the debug API, PSAPI, etc. will be confused if
the action all happens in a child process. I can accept that they
have to adjust, though.
Some of these uses probably shouldn
On 20/03/2011 8:36 PM, Terry Reedy wrote:
On 3/20/2011 3:22 AM, Glenn Linderman wrote:
On 3/19/2011 7:38 PM, Mark Hammond wrote:
[snip]
As both a writer and reader, I would like to just add, for instance,
#! python3
(or 3.3 or whatever) and have the launcher do the 'right thing'.
On 20/03/2011 6:22 PM, Glenn Linderman wrote:
On 3/19/2011 7:38 PM, Mark Hammond wrote:
...
A Windows user who has only learned Python 2.x programming would not
necessarily have ever heard of execve, would not realize execve(2) means
it is from the 2nd chapter of the Unix man pages, meaning an
On 20/03/2011 5:49 AM, "Martin v. Löwis" wrote:
* Is this really PEP material, or will turning the PEP into a regular
spec be suitable?
It's PEP material if it is contentious, which I believe it is.
Of course it is - this is python-dev .
I, for example, will find issues with it if the imple
On 20/03/2011 4:15 AM, Dj Gilcrease wrote:
On Sat, Mar 19, 2011 at 4:44 AM, Glenn Linderman wrote:
2) If the launcher provides command line options for the "benefit" of
launching interactive Python interpreters, those command line options can
have data puns with script names, or can conflict
Thanks for the feedback!
On 19/03/2011 7:44 PM, Glenn Linderman wrote:
Not all of the ideas below are complementary to each other, some are
either or, to allow different thoughts to be inspired or different
directions to be taken.
Thanks for starting a PEP.
On 3/18/2011 11:02 PM, Mark Hammond
ions to reference it).
Thanks,
Mark
PEP: ??
Title: Python launcher for Windows
Version: $Revision$
Last-Modified: $Date$
Author: Mark Hammond
Status: Draft
Type: Standards Track or Informational ?
Content-Type: text/x-rst
Created: 15-Mar-2011
Abstract
This PEP describes a Python lau
These issues are best put in the tracker so they don't get lost -
especially at the moment with lots of regulars at pycon.
It would also be good to know if there is an actual behaviour bug caused
by this (ie, what problems can be observed which are caused by the
current code?)
Cheers,
Mark
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 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 8/03/2011 10:15 AM, Greg Ewing wrote:
Mark Hammond wrote:
Yup - although I think a pythonw.exe launcher would be needed too
Couldn't the launcher look at the extension of the file being
launched to decide about this?
Nope - the launcher itself must be marked as "console&qu
On 8/03/2011 7:33 AM, Michael Foord wrote:
A python launcher as you describe is a *great* idea.
A few concerns:
* we're missing an opportunity to do something easy (Martin is happy to
modify the installer and says it is easy) for something that may or may
not happen
Don't let my -0 stop anyon
On 7/03/2011 9:33 PM, Paul Moore wrote:
That sounds like a fairly cool idea. So if I follow what you're
suggesting, we'd have a single python.exe, probably installed in
system32, which did the necessary command line juggling and shebang
parsing, then simply redirected to the appropriate Python in
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, t
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 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
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 a
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
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 "last installed wins" issue Marti
On 5/03/2011 8:21 AM, "Martin v. Löwis" wrote:
...
As for Windows support: we currently don't install a python3.exe binary,
let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll
adjust the installer if the PEP asks me to. For the reasons discussed,
I'm -0 on the change (i.e. doub
On 31/08/2010 7:54 AM, Nick Coghlan wrote:
On Tue, Aug 31, 2010 at 12:47 AM, Michael Foord
wrote:
An extension compiled for one version of Python will be linked against the
version of the C runtime used by that version of Python (if it is compiled
with the same version of Visual Studio of cour
On 4/08/2010 11:08 AM, Steve Holden wrote:
It's a little disappointing to discover that despite the relatively
large number of developers who have received MSDN licenses from
Microsoft, none if us have the time to make sure that the buildbots are
green for the 2.6.6 release.
I wonder if anyone c
On 2/06/2010 11:32 AM, Farshid Lashkari wrote:
Hello,
I noticed that if Py_IgnoreEnvironmentFlag is enabled, the Windows
registry is still used to initialize sys.path during startup. Is this an
oversight or intentional?
I guess it falls somewhere in the middle - the flag refers to the
'enviro
Hi Dirkjan,
On 8/02/2010 8:35 AM, Dirkjan Ochtman wrote:
...
In fact, a few weeks ago I talked to Brett and we figured that we
should probably pin down a deadline. We discussed aiming at May 1, and
at this time I think that should be feasible. That also seems to
coincide with the release of 2.7
On 15/12/2009 3:09 PM, David Lyon wrote:
On Tue, 15 Dec 2009 15:05:18 +1100, Mark Hammond
wrote:
But under windows, an application developer might (as in probably
would) like to install an application in \Program Files\someapp
rather than hidden in the bowels of the python interpretor.
I
1 - 100 of 244 matches
Mail list logo
