Skip to content

Add environment variable $PYTHONWARNINGS #51550

Closed

Description

@warsaw
BPO 7301
Nosy @warsaw, @pitrou, @pjenvey, @merwok, @briancurtin, @skrah
Files
  • issue7301.diff: trunk patch
  • issue7301-2.diff
  • issue7301-py3k.diff
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/pjenvey'
    closed_at = <Date 2010-04-14.21:04:43.790>
    created_at = <Date 2009-11-10.15:05:28.854>
    labels = ['type-feature', 'library']
    title = 'Add environment variable $PYTHONWARNINGS'
    updated_at = <Date 2010-04-14.21:04:43.782>
    user = 'https://github.com/warsaw'

    bugs.python.org fields:

    activity = <Date 2010-04-14.21:04:43.782>
    actor = 'pjenvey'
    assignee = 'pjenvey'
    closed = True
    closed_date = <Date 2010-04-14.21:04:43.790>
    closer = 'pjenvey'
    components = ['Library (Lib)']
    creation = <Date 2009-11-10.15:05:28.854>
    creator = 'barry'
    dependencies = []
    files = ['16157', '16791', '16810']
    hgrepos = []
    issue_num = 7301
    keywords = ['patch', 'needs review']
    message_count = 15.0
    messages = ['95117', '95200', '95202', '95210', '97797', '98972', '102504', '102505', '102515', '102520', '102582', '102761', '102887', '102888', '103146']
    nosy_count = 6.0
    nosy_names = ['barry', 'pitrou', 'pjenvey', 'eric.araujo', 'brian.curtin', 'skrah']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'patch review'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue7301'
    versions = ['Python 2.7', 'Python 3.2']

    Activity

    1. warsaw commented on Nov 10, 2009

      @warsaw
      MemberAuthor

      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.

    2. added
      stdlibStandard Library Python modules in the Lib/ directory
      type-featureA feature request or enhancement
      on Nov 10, 2009
    3. briancurtin commented on Nov 13, 2009

      @briancurtin
      Member

      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.

    4. pjenvey commented on Nov 13, 2009

      @pjenvey
      Member

      test_warnings is probably the best place since test_cmd_line ignores
      environment variables

    5. briancurtin commented on Nov 13, 2009

      @briancurtin
      Member

      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.

    6. briancurtin commented on Jan 15, 2010

      @briancurtin
      Member

      fixed a tab/space issue

    7. briancurtin commented on Feb 6, 2010

      @briancurtin
      Member

      Updated patch, tests weren't working.

    8. pjenvey commented on Apr 6, 2010

      @pjenvey
      Member

      Looks good to me. Updated patch with a couple whitespace changes

    9. warsaw commented on Apr 6, 2010

      @warsaw
      MemberAuthor

      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.

    10. pjenvey commented on Apr 7, 2010

      @pjenvey
      Member

      applied in r79878 - r79881, thanks!

    11. pjenvey commented on Apr 7, 2010

      @pjenvey
      Member

      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

    12. reopened this on Apr 7, 2010
    13. self-assigned this
      on Apr 7, 2010
    14. pjenvey commented on Apr 8, 2010

      @pjenvey
      Member

      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

    15. pitrou commented on Apr 10, 2010

      @pitrou
      Member

      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.

    16. skrah commented on Apr 11, 2010

      skrahmannequin
      Mannequin

      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?

    17. pjenvey commented on Apr 11, 2010

      @pjenvey
      Member

      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

    18. pjenvey commented on Apr 14, 2010

      @pjenvey
      Member

      py3k should be taken care of as of r80066+r80075

    19. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    stdlibStandard Library Python modules in the Lib/ directorytype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions