Prev: Builtn super() function. How to use it with multipleinheritance? And why should I use it at all?
Next: numpy installation
From: Gelonida on 25 Jul 2010 10:40
On 07/25/2010 02:46 PM, Edward Diener wrote:
> On 7/25/2010 6:07 AM, Gelonida wrote:
>> Hi Edward,
>>
>> There the windows solution could be something like a small 'pystarter'
>> program, which would decide depending on the file's location / the
>> file's first line which python should be started.
>
> This does not work when Python is invoked internally via a file
> association. That was the point of my saying that the simple solutions
> do not work.

What do you mean with invoking python internally?

call another python script? from a python script.

You could start it again via a pystarter.
or just with python (assuming the starter adapts the path)


The problem, that I currently encounter are some scripts, which want to
use python UNO (open office delivers ther own version of python)
and others which want to use libraries of my 'normal' python.

having the file association point to a python starter and let the python
starter choose could be an option.

However I never tried so far.

the fast and easy option is to just have specific file suffixes for the
open office python scripts (like e.g ) .oopy

From: Edward Diener on 25 Jul 2010 15:19
On 7/25/2010 10:03 AM, Thomas Jollans wrote:
> On 07/25/2010 02:46 PM, Edward Diener wrote:
>> The problem with this is that you forget that a script can invoke Python
>> internally. So whether one uses the console or file association method
>> of invoking Python externally, any already written script can use either
>> internally.
>
> Maybe it's just me, but I think that a script that does this is quite
> simply badly written: it *will* break on systems that have multiple
> Python versions.

Whether it is badly written or not in your opinion it is legal and
happens all the time. Are you going to refuse to use any script, no
matter for what library or for what purpose, that internally invokes
Python either through a 'python' command or through a file with a Python
extension ? And how would you find out if a script did this or not ? Are
going to search every script in every distribution and library to
determine if it does this ? And when you find out a script does this,
what will you do ?

Be real. saying you do not like scripts that internally invoke Python
does not solve anything if you have multiple coexisting versions of
Python installed.
From: Thomas Jollans on 25 Jul 2010 15:27
On 07/25/2010 09:12 PM, Edward Diener wrote:
> On 7/25/2010 1:51 PM, Joel Goldstick wrote:
>> There is this:
>> http://pypi.python.org/pypi/virtualenv
>
> It appears to be only for Linux.

I don't know where you get that impression from. I don't know how well
it works on which platforms, but the fact that there is a "Note for
Windows:" does suggest that it does work on windows.
From: Edward Diener on 25 Jul 2010 15:33
On 7/25/2010 10:31 AM, News123 wrote:
> On 07/25/2010 02:46 PM, Edward Diener wrote:
>> On 7/25/2010 6:07 AM, Gelonida wrote:
>
>>> There the windows solution could be something like a small 'pystarter'
>>> program, which would decide depending on the file's location / the
>>> file's first line which python should be started.
>>
>> This does not work when Python is invoked internally via a file
>> association. That was the point of my saying that the simple solutions
>> do not work.
>
> I'm not sure I understand. The ida is of course, that the file
> association would point to the pystarter and that pystarter would
> depending on directory / first line of the script
> identify the correct executable to be started with.
>
>
>
> Perhaps you could once more explain, what your intended solution would be.

How does a 'pystarter' program know where the file's location is which
is being invoked ? As to the first file line this is completely
unrealistic. What are you going to do, alter the first file line of
every script in a Python distribution and every script in every library
installed in a Python distribution ? Sorry, but a less intrusive
solution is much better and much less of a headache to say the least.

My intended solution would be a simple program which understands where
each co-existing Python distribution is installed on a system and what
the "name" of that distribution is. Then you tell the program which
Python distribution should be the current one by its "name", the current
one meaning the distribution which you want to be invoked at any given
time. The program then changes the PATH so that any references to the
Python directory and its subdirectories point to the "name" Python
directory tree, and changes the file associations so that the "name"
Python executables handle the Python associations.

This does have the weakness that I can not use more than one Python
distribution while Python is executing scripts. But I can personally
live with that since I have never encountered a situation where I must
use more than one Python distribution at the same time.


From: Thomas Jollans on 25 Jul 2010 15:32
On 07/25/2010 09:19 PM, Edward Diener wrote:
> On 7/25/2010 10:03 AM, Thomas Jollans wrote:
>> On 07/25/2010 02:46 PM, Edward Diener wrote:
>>> The problem with this is that you forget that a script can invoke Python
>>> internally. So whether one uses the console or file association method
>>> of invoking Python externally, any already written script can use either
>>> internally.
>>
>> Maybe it's just me, but I think that a script that does this is quite
>> simply badly written: it *will* break on systems that have multiple
>> Python versions.
>
> Whether it is badly written or not in your opinion it is legal and
> happens all the time. Are you going to refuse to use any script, no
> matter for what library or for what purpose, that internally invokes
> Python either through a 'python' command or through a file with a Python
> extension ? And how would you find out if a script did this or not ? Are
> going to search every script in every distribution and library to
> determine if it does this ? And when you find out a script does this,
> what will you do ?
>
> Be real. saying you do not like scripts that internally invoke Python
> does not solve anything if you have multiple coexisting versions of
> Python installed.

I doubt many scripts do it. The fact of the matter is: many systems have
multiple Python versions installed in parallel, and it probably will
break somewhere, which will get noticed, and probably fixed.

If a script uses sys.executable instead of "python", there is no
problem, at all.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Builtn super() function. How to use it with multipleinheritance? And why should I use it at all?
Next: numpy installation