WAD Python support does not process command line

[fpefpe]

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]

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.

 

[fpefpe]

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]

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]

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.)

 

[thedave]

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?

 

[rconn]

Are there significant advantages to direct TCC integration?

Only if you want to share/modify environment variables between TCC (and batch scripts) and Python, or if you want to use %@PYTHON[] in your TCC batch files.

 

[thedave]

Sharing environment variables could be useful, although we won't need it at $DAYJOB since we need those Python scripts to run without TCC. Thanks.

 

[fpefpe]

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?

 

[Deim0s]

fpefpe
ActivePython v.3.1.3.5

 

[fpefpe]

fpefpe
ActivePython v.3.1.3.5

Thanks -- Did I miss this link at activestate.com

 

[fpefpe]

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

 

[rconn]

I've been researching this; it's a known Python 3 bug with Windows. So far the various recommended workarounds have been worse.

 

[samintz]

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.

.py=C:\Python27\python.exe
.pyw=C:\Python27\pythonw.exe
.py[co]=C:\Python27\python.exe

 

[fpefpe]

Thanks for the info -- yes I want to use python to change TCC environment variables