Prev: Builtn super() function. How to use it with multipleinheritance? And why should I use it at all?
Next: numpy installation
From: Chris Rebert on 25 Jul 2010 01:03
On Sat, Jul 24, 2010 at 7:40 PM, Edward Diener
<eldiener(a)tropicsoft.invalid> wrote:
> On 7/24/2010 6:25 AM, Mark Lawrence wrote:
>> On 24/07/2010 04:17, Edward Diener wrote:
>>> Are there any documents about multiple versionsof Python coexisting in
>>> the same OS ( Windows in my case ) and what pitfalls to look out for ? I
>>> have already run into a number of them. I installed Python 2.7 and 3.1.2
>>> into completely folders, but immediately ran into serious problems
>>> executing a Python script.
<snip>
> The best solution is some program which changes the PATH and the Python file
> type associations depending on which version of Python one wants to use on
> one's own system when more than one Python version must coexist with others.
> I will probably write such a program for myself.
>
> Are the .py and .pyc extensions the only ones which are associated with
> Python or are there others, for a normal Python installation in Windows ?

There's also .pyw

Cheers,
Chris
From: Steven D'Aprano on 25 Jul 2010 02:20
On Sat, 24 Jul 2010 22:03:48 -0700, Chris Rebert wrote:

>> Are the .py and .pyc extensions the only ones which are associated with
>> Python or are there others, for a normal Python installation in Windows
>> ?
>
> There's also .pyw

Also .pyo

..py = Python source code, usually associated with command line Python
..pyc = Python byte code
..pyo = Python optimized byte code
..pyw = is Windows only, and shouldn't open a console window.



--
Steven
From: Edward Diener on 25 Jul 2010 08:48
On 7/25/2010 2:20 AM, Steven D'Aprano wrote:
> On Sat, 24 Jul 2010 22:03:48 -0700, Chris Rebert wrote:
>
>>> Are the .py and .pyc extensions the only ones which are associated with
>>> Python or are there others, for a normal Python installation in Windows
>>> ?
>>
>> There's also .pyw
>
> Also .pyo
>
> .py = Python source code, usually associated with command line Python
> .pyc = Python byte code
> .pyo = Python optimized byte code
> .pyw = is Windows only, and shouldn't open a console window.

Thanks ! I had forgotten about .pyo and .pyw under Windows.


From: Thomas Jollans on 25 Jul 2010 10:03
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.

If you let .py scripts specify which interpreter they'd like to be run
with in the first line, with some sort of pystarter script that you map
to the file extensions (or by using UNIX), this should work equally well
no matter if the script being run by a script or by a user.

If you invoke the Python interpreter directly, you should NEVER EVER
assume that the interpreter is in a certain place, or on the PATH. It's
a stupid idea: what if it's not? Instead, if you really must, invoke
sys.executable instead of guessing.

Obviously, Windows doesn't have fork(), but still, I don't see any
reason to leave the comfort of your own running interpreter: you can use
runpy to run python scripts. If you want them to run in the background,
you can use threads, or, if you require (or want) separate processes,
use multiprocessing.
From: News123 on 25 Jul 2010 10:31
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.

 |  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