1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

WAD Python support does not process command line

Discussion in 'Support' started by fpefpe, Oct 1, 2012.

  1. fpefpe

    Joined:
    Oct 18, 2008
    Messages:
    263
    Likes Received:
    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>
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,092
    Likes Received:
    85
    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.
     
  3. fpefpe

    Joined:
    Oct 18, 2008
    Messages:
    263
    Likes Received:
    1
    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?
     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,092
    Likes Received:
    85
    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.
     
  5. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,092
    Likes Received:
    85
    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. thedave

    Joined:
    Nov 13, 2008
    Messages:
    254
    Likes Received:
    2
    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?
     
  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,092
    Likes Received:
    85
    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.
     
  8. thedave

    Joined:
    Nov 13, 2008
    Messages:
    254
    Likes Received:
    2
    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.
     
  9. fpefpe

    Joined:
    Oct 18, 2008
    Messages:
    263
    Likes Received:
    1
    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?
     
  10. Deim0s

    Joined:
    Nov 6, 2010
    Messages:
    1
    Likes Received:
    0
  11. fpefpe

    Joined:
    Oct 18, 2008
    Messages:
    263
    Likes Received:
    1
  12. fpefpe

    Joined:
    Oct 18, 2008
    Messages:
    263
    Likes Received:
    1
    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
     
  13. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,092
    Likes Received:
    85
    I've been researching this; it's a known Python 3 bug with Windows. So far the various recommended workarounds have been worse.
     
  14. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,203
    Likes Received:
    11
    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
    
     
  15. fpefpe

    Joined:
    Oct 18, 2008
    Messages:
    263
    Likes Received:
    1
    Thanks for the info -- yes I want to use python to change TCC environment variables
     

Share This Page