WAD Python support does not process command line

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
Oct 18, 2008
265
1
#1
Hello --

The following python (3) script when executed with python support on, will fail when processing the command line. outside of tcc (exec with python) it works fine.

I posted this on the python group and the the comments seem to indicate badly formed arguments

# this is a test

import sys


print('hello from python')

print('Number of arguments:', len(sys.argv), 'arguments.')

print('Argument List:', str(sys.argv))


==========================================================
the above was saved as foo.py and I rand it at the tcc prompt

foo.py this is a test -- here is the output

==========================================================

Argument List: hello from python

Number of arguments: 5 arguments.

Traceback (most recent call last):

File "<string>", line 1, in <module>

File "C:/DOCUME~1/Frank/LOCALS~1/Temp/foo.py", line 10, in <module>

print('Argument List:', str(sys.argv))

File "C:\Python32\Lib\encodings\cp437.py", line 19, in encode

return codecs.charmap_encode(input,self.errors,encoding_map)[0]

UnicodeEncodeError: 'charmap' codec can't encode characters in position 2-18: character maps to <undefined>
 

rconn

Administrator
Staff member
May 14, 2008
10,210
86
#2
What version of Python are you running? (And 32-bit or 64-bit?)

If you're running 3.2 (as your error message indicates), then you can't be running it in TCC (so the "Python support on" is meaningless). TCC currently only supports Python 3.1 or earlier; it won't load the python32.dll -- see the help for details.
 
Oct 18, 2008
265
1
#3
Yes -- that is correct --

I took the liberty to copy the python32.dll to python31.dll to see if this would work. I am trying to get active state to supply the 3.1 version, but a recent email to me from active state noted that 3.1 has been EOL, since 3.3 is out now -- Will 3.2 (or 3.3) support be added? Or would the tcl schema to have
a stub dll (tclsh.dll) which then redirect the call to it to the version (ie tclxx.dll) its bound to?

Will this work with a local build of python31.dll with the sources from python.org?
 

rconn

Administrator
Staff member
May 14, 2008
10,210
86
#4
There is not the slightest chance that renaming 3.2 to 3.1 will work. Whenever Python is updated, they not only change the dll name (very bad for apps which want to use embedded Python) -- they also change many of the API names or arguments. (Far worse for apps which want to use embedded Python!)

So far, nobody has requested Python 3.2 (or 3.3) support in TCC. It's generally a 1 or 2 day process to change things over in TCC for all the (needless) Python API changes.
 

rconn

Administrator
Staff member
May 14, 2008
10,210
86
#5
I took a quick look at Python 3.3, and they've apparently outdone themselves (again). Not only did they change dll names and APIs, but they've completely removed the Very High Level Layer APIs that TCC uses to start Python scripts. (They're still documented in 3.3; they're just not there in the code.) Thus the code I have to write to support embedded Python goes from a couple hundred lines to a few thousand.

So supporting 3.3 will be a major task (reinventing the wheel again), and I'm going to defer it until it is actually requested by a significant number of users. (Not sure if it's even going to be possible.)
 
#6
If the APIs are documented but not in the code, have you considered logging a bug with Python to let them know of the ongoing demand/need for this?

We've settled on Python at $DAYJOB so this is gone from idle curiosity to a "I might use this feature", although I'm not sure whether I care about TCC integration vs just calling Python directly -- Are there significant advantages to direct TCC integration?
 
Oct 18, 2008
265
1
#9
I took a quick look at Python 3.3, and they've apparently outdone themselves (again). Not only did they change dll names and APIs, but they've completely removed the Very High Level Layer APIs that TCC uses to start Python scripts. (They're still documented in 3.3; they're just not there in the code.) Thus the code I have to write to support embedded Python goes from a couple hundred lines to a few thousand.

So supporting 3.3 will be a major task (reinventing the wheel again), and I'm going to defer it until it is actually requested by a significant number of users. (Not sure if it's even going to be possible.)
Thanks for the info ... The issue then is a sort of catch-22 -- Activestate told me that 3.1 is not available any more (they have not answered my emalils) Is there a possibility for jpsoft to get a copy and make it available on the (jpsoft) ftp site?

Lastly, if this is not possible would the non-activestate version of python work? -- The version that could be downloaded from python.org?

Just a curious question -- is this interface nightmare also true with perl or ruby?
 
Oct 18, 2008
265
1
#12
Hello --

Thanks to Deim0s to the link to the python 3.1 install

I removed python32 from my system and installed the 3.1 version.

I re-ran my test program -- with no arguments -- it worked ok, but with
arguments it fails, and the trace back looks much like the one I posted at the
start of this thread




Here is the console using version 3.1



<(fpe1001)c:\docume~1\frank\locals~1\temp(0,0)>python --version

Python 3.1.3


<(fpe1001)c:\docume~1\frank\locals~1\temp(0,0)>python foo.py

hello from python

Number of arguments: 1 arguments.

Argument List: ['foo.py']



<(fpe1001)c:\docume~1\frank\locals~1\temp(0,0)>python foo.py hello from python

hello from python

Number of arguments: 4 arguments.

Argument List: ['foo.py', 'hello', 'from', 'python']



<(fpe1001)c:\docume~1\frank\locals~1\temp(0,0)> foo.py hello

hello from python

Number of arguments: 2 arguments.

Traceback (most recent call last):

File "<string>", line 1, in <module>

File "C:/DOCUME~1/Frank/LOCALS~1/Temp/foo.py", line 10, in <module>

print('Argument List:', str(sys.argv))

File "C:\Python31\Lib\encodings\cp437.py", line 19, in encode

return codecs.charmap_encode(input,self.errors,encoding_map)[0]

UnicodeEncodeError: 'charmap' codec can't encode characters in position 2-18: character maps to <undefined>



<(fpe1001)c:\docume~1\frank\locals~1\temp(0,-1)>foo.py hello

Argument List: hello from python

Number of arguments: 2 arguments.

Traceback (most recent call last):

File "<string>", line 1, in <module>

File "C:/DOCUME~1/Frank/LOCALS~1/Temp/foo.py", line 10, in <module>

print('Argument List:', str(sys.argv))

File "C:\Python31\Lib\encodings\cp437.py", line 19, in encode

return codecs.charmap_encode(input,self.errors,encoding_map)[0]

UnicodeEncodeError: 'charmap' codec can't encode characters in position 2-18: character maps to <undefined>



<(fpe1001)c:\docume~1\frank\locals~1\temp(0,-1)>which python31.dll

python31.dll is an external : C:\windows\system32\python31.dll
 

samintz

Scott Mintz
May 20, 2008
1,229
11
Solon, OH, USA
#14
If you don't need the ability to interact with TCC's environment, then executable extensions work great. My environment still uses Python 2.7.
Code:
.py=C:\Python27\python.exe
.pyw=C:\Python27\pythonw.exe
.py[co]=C:\Python27\python.exe