| msg95117 - (view) |
Author: Barry A. Warsaw (barry) *  |
Date: 2009-11-10 15:05 |
| It would be very useful to have an environment variable PYTHONWARNINGS,tiedtothe−Woptionforsilencingvariouswarnings(mostimportantly,DeprecationWarnings).Usecase:atestsuiterunningmanysubprocesses,testingthatthosesubprocoutputisclean.DeprecationWarningscannoteasilybesuppressedbypassing−Wflagsallaroundorusingliberallysprinkledfilterwarnings().SettingPYTHONWARNINGS, tied to the -W option for silencing various warnings (most importantly, DeprecationWarnings). Use case: a test suite running many subprocesses, testing that those subproc output is clean. DeprecationWarnings cannot easily be suppressed by passing -W flags all around or using liberally sprinkled filterwarnings(). Setting PYTHONWARNINGS,tiedtothe−Woptionforsilencingvariouswarnings(mostimportantly,DeprecationWarnings).Usecase:atestsuiterunningmanysubprocesses,testingthatthosesubprocoutputisclean.DeprecationWarningscannoteasilybesuppressedbypassing−Wflagsallaroundorusingliberallysprinkledfilterwarnings().SettingPYTHONWARNINGS once and for all to silence all processes would be very useful. |
|
|
| msg95200 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2009-11-13 21:15 |
| I attached a patch against trunk r76237 which seems to cover this, sans official tests. I looked around and didn't find a good place for specifically testing environment variables. I could add test code in test_warnings if that's the best place. The patch allows multiple warnings to be passed to the environment variable as a comma separated string, and works in conjunction with -W. Let me know what you think. |
|
|
| msg95202 - (view) |
Author: Philip Jenvey (pjenvey) * |
Date: 2009-11-13 21:28 |
| test_warnings is probably the best place since test_cmd_line ignores environment variables |
|
|
| msg95210 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2009-11-13 22:10 |
| Added a patch which includes tests in test_warnings. There are tests for a single warning, two comma separated warnings, and one env var warning and one command line warning at the same time. |
|
|
| msg97797 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-01-15 00:40 |
| fixed a tab/space issue |
|
|
| msg98972 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-02-06 23:33 |
| Updated patch, tests weren't working. |
|
|
| msg102504 - (view) |
Author: Philip Jenvey (pjenvey) * |
Date: 2010-04-06 23:03 |
| Looks good to me. Updated patch with a couple whitespace changes |
|
|
| msg102505 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2010-04-06 23:14 |
| Patch looks good to me too. Do any of you have commit privileges? If so, please commit this. If not assign the issue to me and I'll do it. |
|
|
| msg102515 - (view) |
Author: Philip Jenvey (pjenvey) * |
Date: 2010-04-07 04:06 |
| applied in r79878 - r79881, thanks! |
|
|
| msg102520 - (view) |
Author: Philip Jenvey (pjenvey) * |
Date: 2010-04-07 06:31 |
| I committed a somewhat different version of this patch to py3k to handle the warn options now calling for wchars, but this needs more work. Some of the buildbots are unhappy Seems like the py3k version either needs to fully decode the env values to a unicode obj via the file system encoding (which I doubt is initialized at this point)/surrogateescape, or use something along the lines of char2wchar in python.c |
|
|
| msg102582 - (view) |
Author: Philip Jenvey (pjenvey) * |
Date: 2010-04-08 01:12 |
| Here's a patch for py3k using the same char2wchar as the argv decoder for posix, and better windows handling. Plus an additional nonascii value test. Patch is against r79980 for clarity |
|
|
| msg102761 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-04-10 02:24 |
| The tests don't look good to me. You should use p.communicate() rather than p.stdout.read(). Also, check the error return code and raise an error if it's non-zero. |
|
|
| msg102887 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-04-11 21:00 |
| The changes in main.c in r79881 don't look right: strtok() is used on the string returned by getenv(), which must not be modified. Also (and this admittedly cosmetic), perhaps use a static buffer like wchar_t warning[128] or use a single allocation before the for loop. What is the maximum length for a single warning? |
|
|
| msg102888 - (view) |
Author: Philip Jenvey (pjenvey) * |
Date: 2010-04-11 21:10 |
| The pending patch for py3k fixes the modification of the env value (trunk already has a fix for that). That patch is also doing the conversion to wchar_t via the char2wchar function now, with that reusing a single buffer seems out of the question |
|
|
| msg103146 - (view) |
Author: Philip Jenvey (pjenvey) * |
Date: 2010-04-14 21:04 |
| py3k should be taken care of as of r80066+r80075 |
|
|