One of the things I like about Python is that
* it doesn't actually need an installation. *
It is sufficient to set up PATH (and, if you like, PYTHONPATH)
accordingly to start python. However, you need the DLLs somewhere
in the Python directory, too.
That way it is possible to install Python ap
> But then you don't get to pass arguments to the program,
> get to see the output before the window disappears, etc.
Did you actually try before posting?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
Greg Ewing wrote:
> Martin v. Löwis wrote:
>
>> OTOH, other things *are* available, such as registered extensions.
>> For example, you don't need python on PATH to start a Python script;
>> just invoking the .py file will find the Python interpreter from the
>> registry.
>
> But then you don't ge
Martin v. Löwis wrote:
OTOH, other things *are* available, such as registered extensions.
For example, you don't need python on PATH to start a Python script;
just invoking the .py file will find the Python interpreter from the
registry.
But then you don't get to pass arguments to the program,
> May be an external program called by the uninstaller can take care
> of this, removing what was added to PATH.
Or a custom action. There are ways to solve this problem - they just
take some effort to implement them.
Regards,
Martin
___
Python-Dev mail
> A cleaner (though still dirty) way to achieve this would be to add a
> link to the appropriate "python.exe" in a directory already on the path
> such as c:\Windows\system32
That would be fairly easy to implement. I suppose pythonw.exe wouldn't
need the same treatment, as people won't invoke it m
>> I mean that many Windows use the PATH, and as such, may fail if a new
>> directory is added to the PATH that contains a DLL they indirectly use.
>
> Then it's just a matter of not putting any DLLs in those directories, isn't
> it?
A. It's not just DLLs. Any program invoking CreateProcess mig
> FWIW, my opinion is similar to how I read Martin's - that if a suitable,
> safe patch that cleanly uninstalls can be found, it should be included, but
> disabled by default. Personally I'd never use it.
That's my view also (less strict now; I previously would have rejected
it outright, as I did
Terry Reedy wrote:
>
>
> M.-A. Lemburg wrote:
>> On 2008-09-02 23:14, Terry Reedy wrote:
>
>>> An alternative to manipulating PATH would be to make and add to the
>>> Start Menu a Command Prompt shortcut, call it Command Window or
>>> something, that starts in the Python directory. Then one cou
Tim Golden wrote:
You can use "CALL" within one batch file to chain
another, returning afterwards to the first.
You need to know that what you're calling is a bat
file to have the foresight to do that, though. I
can imagine people not expecting "python" to be
a bat file.
Instead of a bat file
M.-A. Lemburg wrote:
However, always having the latest version on PATH is not
an option either, since e.g. I wouldn't want all .py scripts
to be run by Python 3.0 just because I installed it for
testing purposes.
Keep in mind that the normal installation process on
unix *does* make "python" re
Eric Smith wrote:
But I agree that
managing a single batch file is easier than dealing with the PATH
variable, and has fewer side effects (finding DLL's, etc.).
This would only be possible for an administrator
installation, though, not a per-user one.
--
Greg
Mark Hammond skippinet.com.au> writes:
>
> I mean that many Windows use the PATH, and as such, may fail if a new
> directory is added to the PATH that contains a DLL they indirectly use.
Then it's just a matter of not putting any DLLs in those directories, isn't it?
> If I *did* expect other pr
On 03 Sep 2008 at 13:34:18, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Same here, but I usually have a env.bat that sets up whatever
> environment I need (including the required Python version) and
> run that when opening a prompt to work on a particular project.
> IMHO, the only point of having
On Wed, Sep 3, 2008 at 3:46 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
>
>
> PS If anyone knows a *good* way of writing wrapper scripts on Windows
> which doesn't suffer from the bat file nesting problem above, please
> let me (and the rest of the world!) know!
You can use setuptools console scri
On 03/09/2008, Tim Golden <[EMAIL PROTECTED]> wrote:
> You can use "CALL" within one batch file to chain
> another, returning afterwards to the first.
Correct. Sorry, I forgot to mention that.
> But this is obviously not the most transparent thing
> on earth!
Indeed - and it certainly isn't a "w
Paul Moore schrieb:
> Bat files don't work when called from another bat file. This hits me
> regularly, when people supply wrapper bat files. Example:
>
> myscript.bat:
> @echo off
> do some stuff
> python my_py_script.py
> do some more stuff
>
> If "python" is a bat file, "do some more stuff" wi
Paul Moore wrote:
On 03/09/2008, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Perhaps we could have an option to place a "python.bat"
> into C:\Windows\ or C:\Windows\System\.
Except you still have the "last in wins" issue, and you have to make a
decision on whether or not to delete the file.
On 03/09/2008, Thomas Heller <[EMAIL PROTECTED]> wrote:
> > > Perhaps we could have an option to place a "python.bat"
> > > into C:\Windows\ or C:\Windows\System\.
> >
> > Except you still have the "last in wins" issue, and you have to make a
> > decision on whether or not to delete the file.
>
>
On Wed, Sep 3, 2008 at 3:10 PM, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> > Perhaps we could have an option to place a "python.bat"
>> > into C:\Windows\ or C:\Windows\System\.
>>
> If this is done the batch file should be named "python25.bat" or so
> depending on the version.
>
Instead of havi
> > Perhaps we could have an option to place a "python.bat"
> > into C:\Windows\ or C:\Windows\System\.
>
> Except you still have the "last in wins" issue, and you have to make a
> decision on whether or not to delete the file.
If this is done the batch file should be named "python25.bat" or s
M.-A. Lemburg wrote:
On 2008-09-03 04:12, Greg Ewing wrote:
M.-A. Lemburg wrote:
The problem is: how to undo those changes without accidentally
undoing an explicit change made by the user ?
Is that really much of an issue? If the PATH contains an
entry corresponding to the Python installation
On 2008-09-03 10:15, Cesare Di Mauro wrote:
> On 03 sep 2008 at 00:50:13, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>> There already is a menu entry that starts the Python interpreter
>> on Windows, so why not use that ?
>
> Because i need to start Python from folders which have
> files that def
On 2008-09-03 04:12, Greg Ewing wrote:
> M.-A. Lemburg wrote:
>
>> The problem is: how to undo those changes without accidentally
>> undoing an explicit change made by the user ?
>
> Is that really much of an issue? If the PATH contains an
> entry corresponding to the Python installation that's
>
On 03 sep 2008 at 00:50:13, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> There already is a menu entry that starts the Python interpreter
> on Windows, so why not use that ?
Because i need to start Python from folders which have
files that define a specific "environment".
I have several servers an
On Wed, Sep 3, 2008 at 7:39 AM, Curt Hagenlocher <[EMAIL PROTECTED]>wrote:
>
> One other reason not to mess with the PATH -- at least by default --
> is that the user may have multiple copies of Python installed. I know
> I have at least one machine with 2.4.5, 2.5.2, 2.6b2 and 3.0b2
> installed
One of these days, I'm actually going to remember that I need to click
"Reply All" when posting to this list... . Sorry for the duplicate,
Greg.
On Tue, Sep 2, 2008 at 6:45 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> A better way would be to start a command process with
> the Python directory a
> Mark Hammond skippinet.com.au> writes:
> > >
> > > The reason for adding the directory to the PATH is for it to be
> > > recognized in any command prompt, not only the Python-dedicated
> > > command prompt shortcut.
> >
> > Actually, that is *your* reason for adding it to the global path.
>
> W
M.-A. Lemburg wrote:
The problem is: how to undo those changes without accidentally
undoing an explicit change made by the user ?
Is that really much of an issue? If the PATH contains an
entry corresponding to the Python installation that's
being uninstalled, then it's not going to work once t
M.-A. Lemburg wrote:
On 2008-09-02 23:14, Terry Reedy wrote:
An alternative to manipulating PATH would be to make and add to the
Start Menu a Command Prompt shortcut, call it Command Window or
something, that starts in the Python directory. Then one could enter
python or >Scripts/goforit w
Terry Reedy wrote:
An alternative to manipulating PATH would be to make and add to the
Start Menu a Command Prompt shortcut, call it Command Window or
something, that starts in the Python directory.
That doesn't seem very satisfactory, because the user
is going to want to work in the director
Mark Hammond skippinet.com.au> writes:
> >
> > The reason for adding the directory to the PATH is for it to be
> > recognized in any command prompt, not only the Python-dedicated
> > command prompt shortcut.
>
> Actually, that is *your* reason for adding it to the global path.
What do you mean
> > An alternative to manipulating PATH would be to make and add to the
> > Start Menu a Command Prompt shortcut, call it Command Window or
> > something, that starts in the Python directory.
>
> The reason for adding the directory to the PATH is for it to be
> recognized in any command prompt, no
On 2008-09-02 23:14, Terry Reedy wrote:
> Tarek Ziadé wrote:
>
>> So I don't see any good reason (besides the technical complexity)
>
> Unless and until someone is able and willing to deal with the technical
> complexity, that would seem to be a sufficient reason.
>
>> to [not, I presume] add
Terry Reedy udel.edu> writes:
>
> An alternative to manipulating PATH would be to make and add to the
> Start Menu a Command Prompt shortcut, call it Command Window or
> something, that starts in the Python directory.
The reason for adding the directory to the PATH is for it to be recognized i
Tarek Ziadé wrote:
So I don't see any good reason (besides the technical complexity)
Unless and until someone is able and willing to deal with the technical
complexity, that would seem to be a sufficient reason.
> to [not, I presume] add it to the Windows installer.
So I would love to se
Giampaolo Rodola' wrote:
Hi,
I've always found it strange that Python Windows installers never
managed to add the python executable to the PATH environment variable.
Are there plans for adding such a thing?
No, but I've added a little helper script several months ago. It adds
the Python and Scr
On Tue, Sep 2, 2008 at 3:04 PM, Tarek Ziadé <[EMAIL PROTECTED]> wrote:
>
> So I don't see any good reason (besides the technical complexity) to add it
> to the Windows installer.
>
oups.. I don't see any good reason *not* to add it ... :)
___
Python-De
On Tue, Sep 2, 2008 at 1:38 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]>wrote:
> Hello,
>
> Giampaolo Rodola' wrote:
> > Hi,
> > I've always found it strange that Python Windows installers never
> > managed to add the python executable to the PATH environment variable.
>
+1
At this point, as far
Hello,
Giampaolo Rodola' wrote:
> Hi,
> I've always found it strange that Python Windows installers never
> managed to add the python executable to the PATH environment variable.
> Are there plans for adding such a thing?
I don't think so.
See the discussion of http://bugs.python.org/issue3561
-
Hi,
I've always found it strange that Python Windows installers never
managed to add the python executable to the PATH environment variable.
Are there plans for adding such a thing?
Thanks in advance
--- Giampaolo
http://code.google.com/p/pyftpdlib/
___
41 matches
Mail list logo
