You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be very useful to have an environment variable $PYTHONWARNINGS,
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 once and for all to silence
all processes would be very useful.
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.
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.
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
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
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.
skrah commented on Apr 11, 2010
skrahmannequin
Mannequin
More actions
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?
Activity
warsaw commentedon Nov 10, 2009
It would be very useful to have an environment variable $PYTHONWARNINGS,
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 once and for all to silence
all processes would be very useful.
briancurtin commentedon Nov 13, 2009
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.
pjenvey commentedon Nov 13, 2009
test_warnings is probably the best place since test_cmd_line ignores
environment variables
briancurtin commentedon Nov 13, 2009
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.
briancurtin commentedon Jan 15, 2010
fixed a tab/space issue
briancurtin commentedon Feb 6, 2010
Updated patch, tests weren't working.
pjenvey commentedon Apr 6, 2010
Looks good to me. Updated patch with a couple whitespace changes
warsaw commentedon Apr 6, 2010
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.
pjenvey commentedon Apr 7, 2010
applied in r79878 - r79881, thanks!
pjenvey commentedon Apr 7, 2010
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
pjenvey commentedon Apr 8, 2010
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
pitrou commentedon Apr 10, 2010
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.
skrah commentedon Apr 11, 2010
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?
pjenvey commentedon Apr 11, 2010
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
pjenvey commentedon Apr 14, 2010
py3k should be taken care of as of r80066+r80075