[issue14803] Add feature to allow code execution prior to __main__ invocation

Ionel Cristian Mărieș added the comment: Note that coveragepy ain't the sole usecase for this. https://pypi.org/project/manhole/ - a debugging tool https://pypi.org/project/hunter/ - a tracer In addition to those there's https://pypi.org/project/pytest-cov/ which packages the pth trick so cov

[issue14803] Add feature to allow code execution prior to __main__ invocation

Changes by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue14803] Add feature to allow code execution prior to __main__ invocation

Nick Coghlan added the comment: Why post that complaint here? If there's a case where__main__.__package__ isn't being set correctly by -m, file a separate bug. -- ___ Python tracker

[issue14803] Add feature to allow code execution prior to __main__ invocation

Kristján Valur Jónsson added the comment: offtopic: Noticed something pretty annoying: If a package uses relative imports, e.g. from . import sibling_module, then it is impossible to run that package as a script, even with the __main__ trick. -- __

[issue14803] Add feature to allow code execution prior to __main__ invocation

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue14803] Add feature to allow code execution prior to __main__ invocation

Changes by Kristján Valur Jónsson : -- nosy: +kristjan.jonsson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14803] Add feature to allow code execution prior to __main__ invocation

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue14803] Add feature to allow code execution prior to __main__ invocation

Changes by Bradley Froehle : -- nosy: +bfroehle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue14803] Add feature to allow code execution prior to __main__ invocation

Changes by Andrew Svetlov : -- nosy: +asvetlov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue14803] Add feature to allow code execution prior to __main__ invocation

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue14803] Add feature to allow code execution prior to __main__ invocation

Ned Batchelder added the comment: I agree with Antoine: I don't see why this should be a feature of virtualenvs. It's easy to use environment variables in a tightly-controlled way. We don't worry that any of the other environment variables that affect Python execution will somehow escape int

[issue14803] Add feature to allow code execution prior to __main__ invocation

Chris Jerdonek added the comment: > However, the -C option doesn't cover the case of *implicit* invocation of > subprocesses. This is where the PYTHONRUNFIRST suggestion comes in Would a more general solution than PYTHONRUNFIRST be something like a suitably named PYTHONRUNINSTEAD? This would b

[issue14803] Add feature to allow code execution prior to __main__ invocation

Antoine Pitrou added the comment: Le lundi 30 juillet 2012 à 00:55 +, Nick Coghlan a écrit : > However, the -C option doesn't cover the case of *implicit* invocation > of subprocesses. This is where the PYTHONRUNFIRST suggestion comes in > - the idea would that, unless -E is specified, then -

[issue14803] Add feature to allow code execution prior to __main__ invocation

Nick Coghlan added the comment: There are two different use cases here. "-C" tackles one of them, "PYTHONRUNFIRST" the other. My original use case came from working on the Python test suite. In that suite, we have "test.script_helper" which spawns Python subprocesses in order to test various

[issue14803] Add feature to allow code execution prior to __main__ invocation

Chris Jerdonek added the comment: Okay, then in the interest of understanding why various alternatives fail, I'll just throw out the suggestion or question that I had in mind because I don't see it mentioned above or on the web page. Why wouldn't it work to define an alias or script that invok

[issue14803] Add feature to allow code execution prior to __main__ invocation

Ned Batchelder added the comment: Chris, I'm not sure how to answer your questions. The more powerful and flexible, the better. There is no "must" here. I'm looking for a way to avoid the hacks coverage.py has used in the past to measure coverage in subprocesses. A language feature that al

[issue14803] Add feature to allow code execution prior to __main__ invocation

Chris Jerdonek added the comment: I understand that. Sorry, I meant to say "code under test." If you make no assumptions about spawning subprocesses, does this mean, for example, that the solution must satisfy the case of subprocesses invoking a different version of Python, or invoking the sa

[issue14803] Add feature to allow code execution prior to __main__ invocation

Ned Batchelder added the comment: Chris: The real problem is that it isn't the "test suite" that spawns the processes, the tests invoke product code, and the product code spawns Python. So modifying the Python-spawning really means modifying the product code to do something different under c

[issue14803] Add feature to allow code execution prior to __main__ invocation

Antoine Pitrou added the comment: > > I'm -0.5 myself, though, for the reason that it complicates the startup > > process a little bit more, without looking very compelling. It smells > > disturbingly like LD_PRELOAD to me. > > Antoine, do you have a suggestion for how to solve the coverage.py >

[issue14803] Add feature to allow code execution prior to __main__ invocation

Chris Jerdonek added the comment: Ned, two questions: in the scenario you just described, is it a requirement that your test suite's code need not be modified (even minimally) to support coverage of subprocesses? And can the solution assume that the test suite is spawning the Python processes

[issue14803] Add feature to allow code execution prior to __main__ invocation

Changes by Chris Jerdonek : -- nosy: +cjerdonek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue14803] Add feature to allow code execution prior to __main__ invocation

Ned Batchelder added the comment: > I'm -0.5 myself, though, for the reason that it complicates the startup > process a little bit more, without looking very compelling. It smells > disturbingly like LD_PRELOAD to me. Antoine, do you have a suggestion for how to solve the coverage.py problem? T

[issue14803] Add feature to allow code execution prior to __main__ invocation

Nick Coghlan added the comment: Nothing too complicated - just noting that a test suite like ours that launches Python subprocesses to test process global state handling could fairly easily arrange to pass appropriate -C options to trigger things like recording coverage data or profiling optio

[issue14803] Add feature to allow code execution prior to __main__ invocation

Antoine Pitrou added the comment: > I've switched back to being -1 on the PYTHONRUNFIRST idea. There are > no ACLs for environment variables, so the security implications scare > me too much for me to support the feature. I'm quite sure PYTHONHOME and PYTHONPATH already allow you to mess quite f

[issue14803] Add feature to allow code execution prior to __main__ invocation

Nick Coghlan added the comment: I've switched back to being -1 on the PYTHONRUNFIRST idea. There are no ACLs for environment variables, so the security implications scare me too much for me to support the feature. The simple -C option doesn't have that problem, though, and could be used as in

[issue14803] Add feature to allow code execution prior to __main__ invocation

Changes by Bohuslav "Slavek" Kabrda : -- nosy: +bkabrda ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue14803] Add feature to allow code execution prior to __main__ invocation

Changes by Nick Coghlan : -- versions: +Python 3.4 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14803] Add feature to allow code execution prior to __main__ invocation

Nick Coghlan added the comment: No, that increases complexity and coupling, because it would only work for modules that were designed to work that way. Execution of a simple statement will work for any global state that can be modified from pure Python code (including invocation of more compl

[issue14803] Add feature to allow code execution prior to __main__ invocation

Serhiy Storchaka added the comment: For faulthandler and coverage would be more convenient option "-M" (run module with __name__='__premain__' (or something of the sort) and continue command line processing). -- ___ Python tracker

[issue14803] Add feature to allow code execution prior to __main__ invocation

Nick Coghlan added the comment: Actually, there's another use case for you: export PYTHONRUNFIRST="import faulthandler; faulthandler.enable()" application.py All subprocesses launched by the application will now have faulthandler enabled, *without* modifying the application. Doing this in a s

[issue14803] Add feature to allow code execution prior to __main__ invocation

Nick Coghlan added the comment: Because I was thinking about a specific case where I *could* configure how the subprocesses were invoked (launching a test server for a web application). It took Ned's comment to remind me of the original use case (i.e. coverage statistics for a subprocesses cr

[issue14803] Add feature to allow code execution prior to __main__ invocation

Changes by Nick Coghlan : -- title: Enhanced command line features for the runpy module -> Add feature to allow code execution prior to __main__ invocation ___ Python tracker __