Message91416
| Author |
sgm |
| Recipients |
jnoller, sgm |
| Date |
2009年08月08日.05:15:23 |
| SpamBayes Score |
4.1921215e-08 |
| Marked as misclassified |
No |
| Message-id |
<1249708527.45.0.913007486864.issue6461@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Further experimentation revealed that freeze_support() works properly
and the proposed patch is not necessary or desirable for the general
freeze case. In the case of an embedded app that calls set_executable()
it seems that the "else" block calling _python_exe should be taken but
won't be, so I still think there may be a problem here.
In our situation it turned out that an imported module was grabbing the
command line arguments before freeze_support() was called and when that
was addressed the need for a separate python executable and calling
set_executable() was eliminated.
I suggest that the documentation for freeze_support() make it clear that
it must get called before an application processes the arguments or that
the application must allow a --multiprocessing-fork option with a string
value so that the initialization continues until freeze_support() is called. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2009年08月08日 05:15:27 | sgm | set | recipients:
+ sgm, jnoller |
| 2009年08月08日 05:15:27 | sgm | set | messageid: <1249708527.45.0.913007486864.issue6461@psf.upfronthosting.co.za> |
| 2009年08月08日 05:15:25 | sgm | link | issue6461 messages |
| 2009年08月08日 05:15:24 | sgm | create |
|