[issue35706] Make it easier to use a venv with an embedded Python interpreter

Change by Ned Deily : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker ___ ___

[issue35706] Make it easier to use a venv with an embedded Python interpreter

PyScripter added the comment: I don't see how pep-0582 is related to embedded python. The solution is to check for the presence of pyvenv.cfg in PYTHONHOME and set up the system.path accordingly. -- ___ Python tracker

[issue35706] Make it easier to use a venv with an embedded Python interpreter

Wolfgang Langner added the comment: I think this pep is related to the issue and could be a solution: https://www.python.org/dev/peps/pep-0582/ -- nosy: +tds333 ___ Python tracker

[issue35706] Make it easier to use a venv with an embedded Python interpreter

PyScripter added the comment: Similar experience. I have found no way to get to use a venv as embedded Python in PyScripter. Tried Py_SetPythonhome, Py_SetPythonName, combinations... Nothing worked. -- nosy: +pyscripter ___ Python tracker

[issue35706] Make it easier to use a venv with an embedded Python interpreter

Change by Dieter Weber : -- title: Making an embedded Python interpreter use a venv is difficult -> Make it easier to use a venv with an embedded Python interpreter ___ Python tracker <https://bugs.python.org/issu

[issue35706] Making an embedded Python interpreter use a venv is difficult

Change by Dieter Weber : Removed file: https://bugs.python.org/file48039/Source.cpp ___ Python tracker ___ ___ Python-bugs-list mailing

[issue35706] Making an embedded Python interpreter use a venv is difficult

Change by Dieter Weber : Added file: https://bugs.python.org/file48040/Source.cpp ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35706] Making an embedded Python interpreter use a venv is difficult

New submission from Dieter Weber : Python virtual environments are awesome! Using venvs with an embedded Python interpreter has proven difficult, unfortunately. With conda environments it works. See appended a sample file to reproduce the behavior. The core of the problem seems

Re: distribute python interpreter and dependencies

staller generates some > > dlls "on the fly" that are tied to the windows operating > system... > > > > I dont want to create a windows executable via py2exe or > > pyinstaller.. What are the best steps to make a python > interpreter > >

Re: distribute python interpreter and dependencies

this behaviour? Im guessing the python27 installer generates some > dlls "on the fly" that are tied to the windows operating system... > > I dont want to create a windows executable via py2exe or > pyinstaller.. What are the best steps to make a python interpr

distribute python interpreter and dependencies

m guessing the python27 installer generates some dlls "on the fly" that are tied to the windows operating system... I dont want to create a windows executable via py2exe or pyinstaller.. What are the best steps to make a python interpreter available to all windows based diff

[issue34821] Crash after run Python interpreter from removed directory

Karthikeyan Singaravelan added the comment: Just installed Python 3.4 and can confirm this is fixed in 3.5 but exists on Python 3.4.9 though I don't receive any segfaults though as in the picture with 3.4. karthi@ubuntu-s-1vcpu-1gb-blr1-01:~$ mkdir /tmp/foo

[issue34821] Crash after run Python interpreter from removed directory

Karthikeyan Singaravelan added the comment: Thanks for the report and steps. Can you try this on Python 3.5 ? I think this is the related issue issue22834 that was not fixed in Python 3.4 and has the same line numbers. I can't reproduce this on my Ubuntu machine with Python 3.6.5 from

[issue34821] Crash after run Python interpreter from removed directory

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34821] Crash after run Python interpreter from removed directory

ty: normal severity: normal status: open title: Crash after run Python interpreter from removed directory type: crash versions: Python 3.4 Added file: https://bugs.python.org/file47836/python_bug.png ___ Python tracker <https://bugs.python.o

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

On 2018-08-16 14:33, Chris Angelico wrote: > On Thu, Aug 16, 2018 at 8:32 PM, Thomas Jollans wrote: >> On 2018-08-16 01:05, Chris Angelico wrote: >>> On Thu, Aug 16, 2018 at 8:51 AM, Cameron Simpson wrote: And as an additional alternative, when I want something weird (extra python args

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

On Thu, Aug 16, 2018 at 8:32 PM, Thomas Jollans wrote: > On 2018-08-16 01:05, Chris Angelico wrote: >> On Thu, Aug 16, 2018 at 8:51 AM, Cameron Simpson wrote: >>> And as an additional alternative, when I want something weird (extra python >>> args or the like) I usually make my script.py into a

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

On 2018-08-16 01:05, Chris Angelico wrote: > On Thu, Aug 16, 2018 at 8:51 AM, Cameron Simpson wrote: >> And as an additional alternative, when I want something weird (extra python >> args or the like) I usually make my script.py into a module and invoke it >> via a shell script, eg: >> >>

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

David Raymond writes: > So what are you saying is an option vs an argument? Because I see no > distinction whatsoever. The command-line conventions do recognise the distinction. * A command-line argument specifies input to the program. For example, the destination file for a ‘cp’ command is

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

Thanks to everyone who contributed to this thread. Great feedback and suggestions! - Malcolm -- https://mail.python.org/mailman/listinfo/python-list

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

On Thu, Aug 16, 2018 at 8:51 AM, Cameron Simpson wrote: > And as an additional alternative, when I want something weird (extra python > args or the like) I usually make my script.py into a module and invoke it > via a shell script, eg: > > #!/bin/sh > exec /particular/python python-opts... -m

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

On 15Aug2018 20:54, eryk sun wrote: On Wed, Aug 15, 2018 at 9:22 AM, Thomas Jollans wrote: If you really want to, you can pass a *single* argument in your #! line, e.g.: #!/usr/bin/python3 -Wd This works for options that can be grouped into a single argument. Multiple -X options aren't

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

On Wed, Aug 15, 2018 at 9:22 AM, Thomas Jollans wrote: > > If you really want to, you can pass a *single* argument in your #! line, > e.g.: > > #!/usr/bin/python3 -Wd This works for options that can be grouped into a single argument. Multiple -X options aren't supported, nor is combining a -X

RE: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

To: python-list@python.org Subject: Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter? > You might try: > from getopt import getopt > or the (apparently newer): > from optparse import OptionParser Thanks Mike. My

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

On 14/08/18 23:45, Malcolm Greene wrote: > When you run a script via "python3 script.py" you can include command > line options like -b, -B, -O, -OO, etc between the "python3" interpreter > reference and the script.py file, eg. "python3 -b -B -O -OO script.py". > When you create a script that is

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

> You might try: > from getopt import getopt > or the (apparently newer): > from optparse import OptionParser Thanks Mike. My question was trying to make a distinction between Python options (flags that precede the script or module name) and arguments (the script specific values passed on the

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

> If you run the script directly, by entering >script.py or clicking a script > icon or name in File Explorer, it runs python without python options *other > than those specified in environmental variables*. Understood. I thought there might have been a way to pass Python option values via a

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

On 2018-08-14 16:45, Malcolm Greene wrote: > When you run a script via "python3 script.py" you can include command > line options like -b, -B, -O, -OO, etc between the "python3" interpreter > reference and the script.py file, eg. "python3 -b -B -O -OO script.py". > When you create a script that is

Re: How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

On 8/14/2018 5:45 PM, Malcolm Greene wrote: When you run a script via "python3 script.py" you can include command line options like -b, -B, -O, -OO, etc between the "python3" interpreter reference and the script.py file, eg. "python3 -b -B -O -OO script.py". More generally, python script.py

How to pass Python command line options (vs arguments) when running script directly vs via Python interpreter?

When you run a script via "python3 script.py" you can include command line options like -b, -B, -O, -OO, etc between the "python3" interpreter reference and the script.py file, eg. "python3 -b -B -O -OO script.py". When you create a script that is executable directly, eg. script.py with execution

Re: Dealing with errors in interactive subprocess running python interpreter that freeze the process

On Sat, Aug 4, 2018 at 12:03 AM, Oscar Benjamin wrote: > On 2 August 2018 at 20:54, wrote: >> >>> As others have mentioned, separate threads for the individual pipes >>> may help, or if you need to go that far there are specialised >>> libraries, I believe (pexpect is one, but from what I know

Re: Dealing with errors in interactive subprocess running python interpreter that freeze the process

On 2 August 2018 at 20:54, wrote: > >> As others have mentioned, separate threads for the individual pipes >> may help, or if you need to go that far there are specialised >> libraries, I believe (pexpect is one, but from what I know it's fairly >> Unix-specific, so I'm not very familiar with

Re: Dealing with errors in interactive subprocess running python interpreter that freeze the process

On 8/2/2018 3:52 PM, cseber...@gmail.com wrote: subprocess is not meant for interaction through the pipes. That is why, I have been told, IDLE uses a socket for interaction. Multiprocess is apparently better suited for interaction without resorting to a socket. So use normal socket on

Re: Dealing with errors in interactive subprocess running python interpreter that freeze the process

ticular interleaving of input and output on the part of the child. If you control the child process, you can implement a custom protocol to do the communication, and avoid many of the problems that way. If you're trying to "wrap" something like the Python interpreter, it's certainly possible,

Re: Dealing with errors in interactive subprocess running python interpreter that freeze the process

> Another possibility: If the ONLY thing you're doing with stdout/stderr > is passing them through to the screen, simply don't change them. Let > them remain bound to the console. You can have a pipe for stdin > without also having pipes for the others. But that won't work if you > intend to do

Re: Dealing with errors in interactive subprocess running python interpreter that freeze the process

> subprocess is not meant for interaction through the pipes. That is why, > I have been told, IDLE uses a socket for interaction. Multiprocess is > apparently better suited for interaction without resorting to a socket. So use normal socket on localhost for this? Don't you still need

Re: Dealing with errors in interactive subprocess running python interpreter that freeze the process

> As others have mentioned, separate threads for the individual pipes > may help, or if you need to go that far there are specialised > libraries, I believe (pexpect is one, but from what I know it's fairly > Unix-specific, so I'm not very familiar with it). I'm on Linux so pexpect is a

Re: Dealing with errors in interactive subprocess running python interpreter that freeze the process

> -I think the Python interpreter actually sends its output to stderr, so to > capture it you'd probably want it to go to the same place as stdout, so use > stderr = subprocess.STDOUT Yes that captured the error messages! Thanks! > -You're only reading 1 line out output for ea

Re: Dealing with errors in interactive subprocess running python interpreter that freeze the process

On Thu, Aug 2, 2018 at 6:46 PM, Paul Moore wrote: > On Wed, 1 Aug 2018 at 21:17, wrote: >> >> I can run python3 interactively in a subprocess w/ Popen but >> if I sent it text, that throws an exception, the process freezes >> instead of just printing the exception like the normal interpreter..

Re: Dealing with errors in interactive subprocess running python interpreter that freeze the process

On Wed, 1 Aug 2018 at 21:17, wrote: > > I can run python3 interactively in a subprocess w/ Popen but > if I sent it text, that throws an exception, the process freezes > instead of just printing the exception like the normal interpreter.. > why? how fix? Here is my code below. > > (I suspect

Re: Dealing with errors in interactive subprocess running python interpreter that freeze the process

On 8/1/2018 4:11 PM, cseber...@gmail.com wrote: I can run python3 interactively in a subprocess w/ Popen but if I sent it text, that throws an exception, the process freezes instead of just printing the exception like the normal interpreter.. why? how fix? Here is my code below. (I suspect

RE: Dealing with errors in interactive subprocess running python interpreter that freeze the process

A couple notes: -I think the Python interpreter actually sends its output to stderr, so to capture it you'd probably want it to go to the same place as stdout, so use stderr = subprocess.STDOUT -You're only reading 1 line out output for each thing, so if 1 command creates multiple lines

Re: Dealing with errors in interactive subprocess running python interpreter that freeze the process

On Thu, Aug 2, 2018 at 6:11 AM, wrote: > I can run python3 interactively in a subprocess w/ Popen but > if I sent it text, that throws an exception, the process freezes > instead of just printing the exception like the normal interpreter.. > why? how fix? Here is my code below. > > (I suspect

Dealing with errors in interactive subprocess running python interpreter that freeze the process

I can run python3 interactively in a subprocess w/ Popen but if I sent it text, that throws an exception, the process freezes instead of just printing the exception like the normal interpreter.. why? how fix? Here is my code below. (I suspect when there is an exception, there is NO output to

[issue31615] Python interpreter is failing due to BufferOverflow Exception

Serhiy Storchaka added the comment: The correct place for reporting Jython bugs is http://bugs.jython.org/. -- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python

[issue31615] Python interpreter is failing due to BufferOverflow Exception

New submission from Megha HR <megha@wipro.com>: Hi Team, I'm facing BufferOverflow Exception when python interpreter is trying to start. Below is an excerpt of error. - (2017-09-27 13:08:11,972) DEBUG [JMThread, Ac

[issue30575] Python interpreter crashes on macOS

Yibo Wang added the comment: It's a bug from cffi because the interpreter won't crash when using ctypes only without cffi. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue30575] Python interpreter crashes on macOS

Ned Deily added the comment: Sorry but, without more information, no one is likely to want to try to pursue this issue. There are too many components, Python and non-Python, here that could cause a crash and trying to interface to other libraries using extensions like cffi (and ctypes) is

[issue30575] Python interpreter crashes on macOS

s: 295203 nosy: Yibo Wang, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Python interpreter crashes on macOS type: crash versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http

[issue30186] Python interpreter calling "PathCchCombineEx" on startup, Windows 8 and above only

Changes by Steve Dower : -- resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker ___

[issue30186] Python interpreter calling "PathCchCombineEx" on startup, Windows 8 and above only

Steve Dower added the comment: The approach I used is the correct way to use the function if it's available. If Wine is not supporting this function, it should return NULL from GetProcAddress, not a stub. If the function exists, any error it returns is fatal. We need the better function for

[issue30186] Python interpreter calling "PathCchCombineEx" on startup, Windows 8 and above only

R. David Murray added the comment: Indeed, it sounds like wine is claiming to be Windows 7 but then implementing (as not implemented) later-than-windows-7 apis. That definitely sounds like a bug in wine. -- nosy: +r.david.murray ___ Python tracker

[issue30186] Python interpreter calling "PathCchCombineEx" on startup, Windows 8 and above only

Eryk Sun added the comment: I didn't mean that there's support to fall back on PathCombineW if PathCchCombineEx returns E_NOTIMPL. I was just guessing at what the stub in Wine might be doing. I took a look at the source. It seems the Wine stub function for unimplemented functions is

[issue30186] Python interpreter calling "PathCchCombineEx" on startup, Windows 8 and above only

Sebastian Ernst added the comment: Relaying this on behalf of Gijs Vermeulen from Wine: "In my patch I tried returning E_NOTIMPL and I got the error: Fatal Python error: buffer overflow in getpathp.c's join()" -- ___ Python tracker

[issue30186] Python interpreter calling "PathCchCombineEx" on startup, Windows 8 and above only

Eryk Sun added the comment: PathCchCombineEx isn't an import dependency. It's used dynamically via LoadLibraryW and GetProcAddress, with a fallback to PathCombineW. Does Wine maybe have a stub for this function that returns E_NOTIMPL (not implemented)? -- nosy: +eryksun

[issue30186] Python interpreter calling "PathCchCombineEx" on startup, Windows 8 and above only

rt Windows Vista and 7: https://docs.python.org/3/using/windows.html I am seeking clarification on why PathCchCombineEx is called during the Python interpreter startup although Wine pretends to be Windows 7 and although Python should support Windows Vista & 7. My thinking is that this c

Re: Byte-run: a Python interpreter written in Python

On Friday, January 13, 2017 at 12:09:52 PM UTC-5, Ian wrote: > On Fri, Jan 13, 2017 at 3:46 AM, Steve D'Aprano > <steve+pyt...@pearwood.info> wrote: > > > > http://aosabook.org/en/500L/a-python-interpreter-written-in-python.html > > Neat. But not really surprisin

Re: Byte-run: a Python interpreter written in Python

On 13/01/2017 18:47, Ian Kelly wrote: On Fri, Jan 13, 2017 at 11:07 AM, BartC wrote: Even when it turns out that the actual code on github is 1000 lines rather than 500! Maybe it grew a bit since the 500 lines was quoted. I assume they're excluding blank lines, comments and

Re: Byte-run: a Python interpreter written in Python

On Fri, Jan 13, 2017 at 11:07 AM, BartC wrote: > Even when it turns out that the actual code on github is 1000 lines rather > than 500! Maybe it grew a bit since the 500 lines was quoted. I assume they're excluding blank lines, comments and docstrings. And I don't know whether

Re: Byte-run: a Python interpreter written in Python

On 13/01/2017 17:08, Ian Kelly wrote: On Fri, Jan 13, 2017 at 3:46 AM, Steve D'Aprano <steve+pyt...@pearwood.info> wrote: http://aosabook.org/en/500L/a-python-interpreter-written-in-python.html Neat. But not really surprising IMO that it can fit into 500 lines, If there are still 120

Re: Byte-run: a Python interpreter written in Python

On Fri, Jan 13, 2017 at 3:46 AM, Steve D'Aprano <steve+pyt...@pearwood.info> wrote: > > http://aosabook.org/en/500L/a-python-interpreter-written-in-python.html Neat. But not really surprising IMO that it can fit into 500 lines, since it doesn't handle compiling Python into byt

Byte-run: a Python interpreter written in Python

http://aosabook.org/en/500L/a-python-interpreter-written-in-python.html -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list

[issue28949] Unable to launch Python interpreter

Jason R. Coombs added the comment: Before disabling SIP, I found I could use fs_usage to get some visibility into fs changes: sudo fs_usage -w -f filesys | grep aliases.py To test my understanding of fs_usage, I deleted aliases.py (also confirming that triggers the error). When I did so, I

[issue28949] Unable to launch Python interpreter

Jason R. Coombs added the comment: Looks like I can [disable SIP](http://internals.exposed/blog/dtrace-vs-sip.html) and dtrace will be viable. -- ___ Python tracker

[issue28949] Unable to launch Python interpreter

Jason R. Coombs added the comment: I thought I was on to something when I found this technique for using dtrace to detect a file deletion: https://blogs.oracle.com/zoneszone/entry/who_keeps_removing_that_file However, I don't seem to have privilege to run it. $ cat trap-aliases-delete #!

[issue28949] Unable to launch Python interpreter

Jason R. Coombs added the comment: I am using the python.org rc1 installer, confirmed to match the public md5 sum: $ md5 ~/Downloads/python-3.6.0rc1-macosx10.6.pkg MD5 (/Users/jaraco/Downloads/python-3.6.0rc1-macosx10.6.pkg) = 404c390ae27f067aaab34f168cf913eb I downloaded ClamXav and had it

[issue28949] Unable to launch Python interpreter

Ned Deily added the comment: Jason, assuming you are using the python.org 3.6.0r1 installer, let us know what you find out! -- nosy: +ned.deily ___ Python tracker

[issue28949] Unable to launch Python interpreter

Jason R. Coombs added the comment: Hmm. Looks like I may [have a trojan](http://stackoverflow.com/a/4707258). -- ___ Python tracker ___

[issue28949] Unable to launch Python interpreter

Jason R. Coombs added the comment: Indeed it seems that aliases.py is missing. $ ls /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/encodings/a* /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/encodings/ascii.py --

[issue28949] Unable to launch Python interpreter

Jason R. Coombs added the comment: Spontaneously, this issue has arisen again. Without a system restart or any system-level configuration changes, launching the interpreter is once again causing crashes. In addition to the crash log I pasted earlier, I see this in the console when launching

[issue28949] Unable to launch Python interpreter

Jason R. Coombs added the comment: A simple re-install corrected the issue and survived a restart. I suspect one or more components weren't properly upgraded or were corrupted for unrelated reasons. I suspect that it was an environmental issue and not an issue with the package itself.

[issue28949] Unable to launch Python interpreter

3.0 Bus USB Device: iBridge USB Device: USB 3.0 Bus USB Device: ASM107x USB Device: TUSB3410 Boot Device USB Device: Microsoft® LifeCam Cinema(TM) USB Device: ASM107x Thunderbolt Bus: MacBook Pro, Apple Inc., 11.9 Thunderbolt Bus: MacBook Pro, Apple Inc., 11.9 Thunderbolt Device: 34UM95, LG Electron

Re: Windows: subprocess won't run different Python interpreter

On 11/11/2016 03:24 AM, eryk sun wrote: On Fri, Nov 11, 2016 at 10:46 AM, Thorsten Kampe wrote: My goal is to verify that other shells/interpreters on Windows work the same way as Python when running an application or creating a sub- process. Cmd does not. What's else there? I have Bash here

Re: Windows: subprocess won't run different Python interpreter

On Fri, Nov 11, 2016 at 11:30 AM, Gisle Vanem via Python-list wrote: > Thorsten Kampe wrote: > >> My goal is to verify that other shells/interpreters on Windows work >> the same way as Python when running an application or creating a sub- >> process. Cmd does not. What's

Re: Windows: subprocess won't run different Python interpreter

Thorsten Kampe wrote: > My goal is to verify that other shells/interpreters on Windows work > the same way as Python when running an application or creating a sub- > process. Cmd does not. What's else there? I have Bash here but that's > a Cygwin executable. And Cygwin Python does not work like

Re: Windows: subprocess won't run different Python interpreter

On Fri, Nov 11, 2016 at 10:46 AM, Thorsten Kampe wrote: > * eryk sun (Fri, 11 Nov 2016 09:55:23 +) >> >> If it works like cmd.exe, then it does its own search using %Path% >> and %PathExt%. For example: >> >> C:\>cmd /c "set "PATH=" & cmd" >> 'cmd' is not

Re: Windows: subprocess won't run different Python interpreter

* eryk sun (Fri, 11 Nov 2016 09:55:23 +) > > If it works like cmd.exe, then it does its own search using %Path% > and %PathExt%. For example: > > C:\>cmd /c "set "PATH=" & cmd" > 'cmd' is not recognized as an internal or external command, > operable program or batch file. > >

Re: Windows: subprocess won't run different Python interpreter

On Fri, Nov 11, 2016 at 8:56 AM, Thorsten Kampe wrote: > * eryk sun (Fri, 11 Nov 2016 06:23:50 +) >> >> That's the application directory, which is the first place >> CreateProcess looks (via the SearchPath call), as both of my examples >> shows. In my case

Re: Windows: subprocess won't run different Python interpreter

* eryk sun (Fri, 11 Nov 2016 06:23:50 +) > > That's the application directory, which is the first place > CreateProcess looks (via the SearchPath call), as both of my examples > shows. In my case python.exe is located in the standard 3.5 system > installation path, "C:\Program

Re: Windows: subprocess won't run different Python interpreter

On Fri, Nov 11, 2016 at 6:01 AM, Thorsten Kampe wrote: > * eryk sun (Thu, 10 Nov 2016 23:04:02 +) >> >> On Thu, Nov 10, 2016 at 9:58 PM, Thorsten Kampe >> wrote: >> > >> > I'm trying to run a script with a different Python version by >> >

Re: Windows: subprocess won't run different Python interpreter

hat you're expecting, but I run debian. > > Have you tried using os.unsetenv()? I think you are kind of misunderstanding my intention. I'm actually trying the opposite: running python.exe by setting F:\PortableApps \Python3x as the first element in PATH. No Python interpreter is in my PATH

Re: Windows: subprocess won't run different Python interpreter

* eryk sun (Thu, 10 Nov 2016 23:04:02 +) > > On Thu, Nov 10, 2016 at 9:58 PM, Thorsten Kampe > wrote: > > > > I'm trying to run a script with a different Python version by > > extending the path variable and executing "python.exe". It looks like > > subprocess will

Re: Windows: subprocess won't run different Python interpreter

On Thu, Nov 10, 2016 at 9:58 PM, Thorsten Kampe wrote: > > I'm trying to run a script with a different Python version by > extending the path variable and executing "python.exe". It looks like > subprocess will always run the current executing Python. WinAPI

Re: Windows: subprocess won't run different Python interpreter

On 11/10/2016 05:32 PM, Thorsten Kampe wrote: Yes. That works. But it's not like subprocess should work. It certainly is odd. I can at least confirm that when I try to run your code I get the error that you're expecting, but I run debian. Have you tried using os.unsetenv()?

Re: Windows: subprocess won't run different Python interpreter

* Thomas Nyberg (Thu, 10 Nov 2016 17:07:35 -0500) > > On 11/10/2016 04:58 PM, Thorsten Kampe wrote: > > Hi, > > > > I'm trying to run a script with a different Python version by > > extending the path variable and executing "python.exe". It looks like > > subprocess will always run the current

Re: Windows: subprocess won't run different Python interpreter

On 11/10/2016 04:58 PM, Thorsten Kampe wrote: Hi, I'm trying to run a script with a different Python version by extending the path variable and executing "python.exe". It looks like subprocess will always run the current executing Python. > [...] > Thorsten Have you tried using the full

Windows: subprocess won't run different Python interpreter

bprocess os.environ['PATH'] = '' print(subprocess.check_output(['python.exe', '-V'])) """ It outputs the version of the current executing Python interpreter although it should generate an error because Python is not in the PATH. Thorsten -- https://mail.python.org/mailman/listinfo/python-list

[issue27947] Bug of python interpreter

g literal >>> rb'abc\\' b'abc' >>> br'abc\\\ ' b'abc\\ ' >>> br'abc\\\' SyntaxError: EOL while scanning string literal >>> r'\\' '' >>> r'\\\' SyntaxError: EOL while scanning string literal -- messages: 274282 nosy: cfgbd priority: nor

Re: Can't load Tkinter in embedded Python interpreter on Windows

Adding PySys_SetArgv(argc, argv); did the trick. -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com -- https://mail.python.org/mailman/listinfo/python-list

Can't load Tkinter in embedded Python interpreter on Windows

I am trying to build a stub exe on Windows that embeds Python and launches my Tkinter app. I want a full-blown exe program starter because the various Python freezing tools (py2exe, pyinstaller) do not work to my satisfaction with Python 3.5. I am able to get the executable built but I cannot

Re: How to make Python interpreter a little more strict?

On Mon, 28 Mar 2016 07:49 am, BartC wrote: > On 27/03/2016 21:32, Tim Chase wrote: >> On 2016-03-27 14:28, Steven D'Aprano wrote: > >>> In this case, the two lines "fnc" and "next" simply look up the >>> function names, but without actually calling them. They're not >>> quite "no-ops", since

Re: How to make Python interpreter a little more strict?

On Sat, 26 Mar 2016 23:30:30 +, John Pote wrote: > So I have sympathy with the OP, I would expect the compiler to pick this > up Why? The code is valid, the compiler knows how to generate the appropriate bytecode for it. The compiler isn't "lint". Reporting code which is actually invalid

Re: How to make Python interpreter a little more strict?

On Mon, Mar 28, 2016 at 7:49 AM, BartC wrote: > On 27/03/2016 21:32, Tim Chase wrote: >> >> On 2016-03-27 14:28, Steven D'Aprano wrote: > > >>> In this case, the two lines "fnc" and "next" simply look up the >>> function names, but without actually calling them. They're not >>>

Re: How to make Python interpreter a little more strict?

On 27/03/2016 21:32, Tim Chase wrote: On 2016-03-27 14:28, Steven D'Aprano wrote: In this case, the two lines "fnc" and "next" simply look up the function names, but without actually calling them. They're not quite "no-ops", since they can fail and raise NameError if the name doesn't exist,

Re: How to make Python interpreter a little more strict?

On 2016-03-27 14:28, Steven D'Aprano wrote: > > So intrigued by this question I tried the following > > def fnc( n ): > > print "fnc called with parameter '%d'" % n > > return n > > > > for i in range(0,5): > > if i%2 == 0: > > fnc > > next > > print i > > >

Re: How to make Python interpreter a little more strict?

cause the interpreter can't easily tell if the calculations will have any side-effects. It might turn out that something in the expression ends up setting a global variable, or printing output, or writing to a file, or who knows what? Now, you and I can read the line and see that (assuming range hasn't been ov

Re: How to make Python interpreter a little more strict?

On 26/03/2016 23:30, John Pote wrote: So intrigued by this question I tried the following def fnc( n ): print "fnc called with parameter '%d'" % n return n for i in range(0,5): if i%2 == 0: fnc next print i and got the same result as the OP A couple of

Re: How to make Python interpreter a little more strict?

hat's not really something the Python interpreter should be looking at (hey, you might have good reason for doing that), but there are linters that can detect this kind of dead code. Some of them tie into programmer's editors, so you could get a nice little warning message right in the window where yo

Re: How to make Python interpreter a little more strict?

xt > print(str(x)) > > eax@fujitsu:~/temp$ ./t.py > 0 > 1 > 2 > 3 > 4 > > Is it possible to make python complain in this case? Or maybe solve > such an issue somehow else? I think what you're looking for here is an acknowledgement that evaluating the name &quo

Re: How to make Python interpreter a little more strict?

On Fri, 25 Mar 2016 11:06 pm, Aleksander Alekseev wrote: > Is it possible to make python complain in this case? Or maybe solve > such an issue somehow else? This is a job for a "linter", such as pychecker, pylint or pyflakes. Google for more if you are interested. A linter will check your code

<    1   2   3   4   5   6   7   8   >