#3740·nltk

Standardize import alias for `pathsec.open` to address remaining file I/O security gaps

Author: ekafCreated Aug 8, 2026Updated Aug 15, 2026

The Problem

Currently, the codebase uses inconsistent aliasing when importing open from nltk.pathsec. Because the function name shadows Python's built-in open(), it requires aliasing on import, leading to different conventions across different modules.

For example, current implementations include:

  • from nltk.pathsec import open as _secure_open (in data.py)
  • from nltk.pathsec import open as pathsec_open (in downloader.py)

This lack of consistency increases cognitive overhead and complicates codebase audits for restrictive file operations.

The Proposed Solution

Instead of requiring a unique alias per module, a standard, non-shadowing alias should be defined directly at the source.

The proposal is to add secure_open = open to the module level of pathsec.py.

This allows all downstream modules to use a unified, clean import:

python
from nltk.pathsec import secure_open

Making secure_open a public alias (without an underscore) establishes it as the standard, non-shadowing API for downstream usage, while leaving the existing open definition intact to prevent any breaking changes.

Why this is a priority

Establishing this standard alias is a convenient prerequisite for patching the remaining file I/O vulnerabilities in the project. There are still multiple instances of the built-in Python open() being used where restrictive file access is required. Standardizing secure_open provides a uniform foundation to confidently replace those remaining insecure calls across the entire codebase.