What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

Python’s latest wave of changes — from a new CPython JIT and Django 5’s largely backward-compatible evolution to mandatory 2FA on PyPI — is being welcomed for performance gains, framework maturity, and stronger supply-chain security. At the same time, many developers are frustrated by deprecations like `datetime.utcnow()` and conservative naming cleanups in the standard library, arguing that breaking long‑standing APIs imposes real upgrade costs. PyPI’s 2FA rollout and lack of namespaces also raise concerns about usability and dependency-confusion risks for larger teams and corporate environments, even as tools like passkeys, TOTP, and trusted publishing are seen as steps in the right direction.

Django 5 and ecosystem stability

  • Several commenters are enthusiastic about Django 5, especially models.GeneratedField() and the generally smooth upgrade path (with a caveat for UUIDField + MariaDB ≥ 10.7).
  • Longtime users returning after many years say Django feels like “the same but more mature”: APIs are familiar, docs and tooling improved, and upgrades between recent major versions cause little breakage.
  • Django’s main advantage is seen as a consistent API that enables a large, long-lived plugin ecosystem and high developer productivity.

CPython JIT in 3.13

  • The JIT commit message is widely praised for being entertaining.
  • Performance expectations are modest near-term: one talk suggested ~5–10% improvement and framed it as a proof of concept.
  • References to research on copy-and-patch compilation and a LuaJIT comparison are mentioned, but applicability to CPython is described as limited or unclear.

Stdlib naming, deprecations, and datetime.utcnow()

  • There is frustration that standard library naming (logging, datetime, unittest) is inconsistent and that proposals for PEP-8-compliant aliases face resistance due to “support costs.”
  • Some argue Python should have added aliases early in Python 3; others note module changes often depend on having a strong maintainer advocate.
  • The deprecation of datetime.datetime.utcnow() is particularly contentious.
    • Critics: prefer naïve-UTC datetimes, have large codebases depending on it, and see the replacement idioms as uglier and unnecessarily breaking.
    • Defenders: naïve datetimes are a footgun; deprecating bad APIs is acceptable, though full removals should be rare and justified.

Deprecation policy and old modules

  • PEP 594’s mass removal of unmaintained modules is framed as an exception, with future removals to be evaluated individually.
  • The crypt module’s deprecation is seen as clumsily handled; suggested replacements like passlib work but require more effort.

Git workflow and commit message discipline

  • Sharp divide between those who prioritize “productivity first” and those insisting on well-structured histories and descriptive commit messages.
  • Advocates of strict hygiene argue good messages and properly split commits are essential for bisecting and long-term maintenance; opponents see excessive nitpicking and rebase demands as wasteful and demoralizing.

PyPI security: 2FA, tokens, and usability

  • Mandatory 2FA is broadly welcomed as improving account and supply-chain safety.
  • Positive notes: 2FA will push users toward API tokens instead of passwords; Trusted Publishing can eliminate shared tokens. Passkeys are supported as an MFA method (not yet passwordless).
  • Concerns:
    • Lack of mature org support forces some projects to tie critical accounts to an individual’s device, raising continuity risks.
    • Some see “centralized TOTP” via password managers or shared seeds as weakening the spirit of multi-factor, while others argue it still meaningfully improves security versus no 2FA.
    • There is debate over how much extra security is gained by separating TOTP from password managers versus the added usability and recovery risks.
  • PyPI’s 2FA documentation is criticized for being mobile-centric and not highlighting desktop password managers that handle TOTP.

Dependency confusion and namespacing

  • One thread criticizes adding 2FA without addressing trivial dependency confusion attacks.
  • Others argue that simple namespaces (e.g., org/package) don’t fully solve dependency confusion, which is fundamentally about conflicting public/private name resolution.
  • Counterpoint: org-level namespaces would still help companies avoid exposing internal package names while preventing attackers from registering those names publicly, though it requires tooling and process changes.