- Jan
- 617
- 15
My python is from python.org from around 2015 and it seems to work fine. I haven't pushed it too much.
Edit: python34.dll is located in the C:\Python34 directory which is in my path.
Code:
[C:\temp]
8:42:20 $ echo %@python[print('Hello, World!')]
Hello, World!
0
[C:\temp]
8:42:43 $ which python
python is an external : C:\Python34\python.exe
[C:\temp]
8:44:12 $ head C:\Python34\README.txt
This is Python version 3.4.3
============================
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011,
2012, 2013, 2014, 2015 Python Software Foundation. All rights reserved.
Python 3.x is a new version of the language, which is incompatible with the 2.x
line of releases. The language is mostly the same, but many details, especially
how built-in objects like dictionaries and strings work, have changed
considerably, and a lot of deprecated features have finally been removed.Edit: python34.dll is located in the C:\Python34 directory which is in my path.
Last edited:
rconn
Administrator
- May
- 13,238
- 209
Staff member
rconn
Administrator
- May
- 13,238
- 209
Staff member
v18 will look for any Python version between 3.4 and 2.5 (newest first).
- Oct
- 358
- 2
Hello -- I was able to install v3.4 from python.org -- It seems that tcc is loading the python3.dll and python34.dll ( used procexp to find the handles) I created 1 line script with the statement
pint( "hello python")
saved it as hello.py
the "which" command ID'ed "hello:" as
hello is an external : c:\users\frank\appdata\local\temp\hello.py
but when I type "hello" there is no output, but
python hello.py
generates
hello python
Did I miss something -- it seems like output exist is out of sync
thanks
pint( "hello python")
saved it as hello.py
the "which" command ID'ed "hello:" as
hello is an external : c:\users\frank\appdata\local\temp\hello.py
but when I type "hello" there is no output, but
python hello.py
generates
hello python
Did I miss something -- it seems like output exist is out of sync
thanks
- Nov
- 250
- 2
You can look at the EXTPROC SHEBANG thing.
You create a cmd file, and start the first line with something like !# to point to your perl thing. Then you can run perl files as .cmd files.
This extproc thing can point to scripts as well, so you can write your own command processor in REXX or the like. So you can do things like write a tangle/weave [knuth-style] wrapper that spits out matched batch files + ini files + help files, all from a single source file. In my case, the source file is a .CMD file processed through EXTPROC weave.rex
You can invoke perl through the ".pl=perl" executable extensions. I now keep these in my user environment, rather than in some 4nt.ext file.
So look into your python docs, and if it gives something like this, then write up something like hello.cmd, and give it a run under tcc. It should get passed to python and run there.
It really needs some sort of global setting for this stuff, like an apppaths thing in registry.
You create a cmd file, and start the first line with something like !# to point to your perl thing. Then you can run perl files as .cmd files.
This extproc thing can point to scripts as well, so you can write your own command processor in REXX or the like. So you can do things like write a tangle/weave [knuth-style] wrapper that spits out matched batch files + ini files + help files, all from a single source file. In my case, the source file is a .CMD file processed through EXTPROC weave.rex
You can invoke perl through the ".pl=perl" executable extensions. I now keep these in my user environment, rather than in some 4nt.ext file.
So look into your python docs, and if it gives something like this, then write up something like hello.cmd, and give it a run under tcc. It should get passed to python and run there.
Code:
!# d:\path\python
pint( "hello python")It really needs some sort of global setting for this stuff, like an apppaths thing in registry.
- Oct
- 358
- 2
hello -- thanks for the info .... unlike unix shell like bash, there is no "export" statement to migrate environment variables changes
to the current instance of tcc -- for me that is the point of using any of the other scripting languages to modify the current instance of tcc --
the EXTPROC SHEBANG option runs the iten in a child process
to the current instance of tcc -- for me that is the point of using any of the other scripting languages to modify the current instance of tcc --
the EXTPROC SHEBANG option runs the iten in a child process
- Nov
- 250
- 2
If you use REXX as a CMD file, it works in the TCC environment. But if you use REXX as a .REX file, it does not.
Both EXTPROC and the REXX interface are part of IBM's SAA, appear in OS/2. This is copied into 4OS2 and then into 4NT, which became TCC from vers 9. The more recent languages don't work as well. The time-honoured way is to create a batch file with your python script and run it through to the command processor.
Both EXTPROC and the REXX interface are part of IBM's SAA, appear in OS/2. This is copied into 4OS2 and then into 4NT, which became TCC from vers 9. The more recent languages don't work as well. The time-honoured way is to create a batch file with your python script and run it through to the command processor.