Fix Windows test failures and remove debug prints for DRF

[Shrikantgiri25]

What this PR does

• Skips Windows-incompatible path test in TestRegularFieldMappings.test_regular_fields
• Removes leftover print() statements in tests/schemas/test_openapi.py

Background / Why

While setting up DRF on Windows 11 with Python 3.13, I noticed:

• TestRegularFieldMappings.test_regular_fields fails on Windows due to backslash escaping differences in path representations (repr(path) shows 'C:\\Users' on Windows)
• Debug print() statements cluttered test output

How I fixed it

• Added @pytest.mark.skipif(sys.platform.startswith("win"), reason="Test not supported on Windows") to skip the Windows-incompatible test (follows existing pattern used in test_decorators.py)
• Removed all print() statements in test_openapi.py

Impact

• Cleaner test output without debug prints
• Windows users can run the test suite without failures (skipping the incompatible test)
• Follows existing codebase patterns for platform-specific test skipping

Discussion / Reference

Original discussion: DRF Discussion #9807

[Copilot]

Pull Request Overview

This PR fixes cross-platform test failures on Windows with Python 3.13 and removes debug print statements from the test suite. The main changes ensure that path-based tests handle Windows backslashes correctly and that regex patterns are flexible enough to accommodate platform-specific variations in object representations.

• Fixed Windows path escaping issues in TestRegularFieldMappings.test_regular_fields
• Relaxed regex patterns to handle cross-platform differences in object string representations
• Removed 7 debug print() statements from OpenAPI schema tests

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
tests/test_model_serializer.py	Updated regex patterns to handle Windows paths and cross-platform object representations; added re.DOTALL flag for multi-line matching
tests/schemas/test_openapi.py	Removed debug print() statements that were cluttering test output

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[p-r-a-v-i-n]

I just wanted to share my perspective here:

1. This change only affects a test and doesn’t impact any runtime behavior , so it adds more complexity compare to benefits.
2. It might increases the chance of breaking the test if the serializer fields or repr() format change in future
3. DRF generally aims to keep its tests simple and platform-agnostic. In practice, the test suite is not officially guaranteed to pass on native Windows.
4. maintenance burden for non-production code.

windows user can use wsl

[Shrikantgiri25]

I just wanted to share my perspective here:

1. This change only affects a test and doesn’t impact any runtime behavior , so it adds more complexity compare to benefits.
2. It might increases the chance of breaking the test if the serializer fields or repr() format change in future
3. DRF generally aims to keep its tests simple and platform-agnostic. In practice, the test suite is not officially guaranteed to pass on native Windows.
4. maintenance burden for non-production code.

windows user can use wsl

Thanks @p-r-a-v-i-n for the feedback! I completely understand your perspective — I just wanted to share a bit more context on why I approached it this way:

On complexity:
This is only 4-7 lines of actual code. The added comments simply document platform differences for future maintainers — they don’t add complexity; they improve clarity.

On Windows support:
While WSL exists, not every developer can use it:

• Corporate environments with IT restrictions

• Educational institutions with locked-down systems

• Beginners learning Python who aren’t ready to set up Linux

• Developers using hardware with limited virtualization support

Ensuring tests run natively on Windows helps all of these contributors.

On maintenance:
This test already needs updating if the repr() output format changes.
The modification doesn’t increase that risk — it simply ensures the test works consistently across platforms.

On philosophy:
Django itself handles cross-platform differences in its own test suite.
Making DRF’s tests run cross-platform aligns with Python’s “batteries included” philosophy and lowers barriers for contributors.

That said, if the maintainers prefer to keep DRF tests Linux-only, I completely understand and can withdraw the PR — no hard feelings.

Just wanted to help make contributing easier for Windows developers!

Background: I also want to share that I primarily work on Windows for personal/work reasons. While WSL is available, my current setup is Windows-native. When I tried to set up the DRF repo and run the test suite to verify my local environment, I encountered these platform-specific failures.
If this test fails on Windows(Failing Screenshots here in discussion), new developers might assume their setup is broken(I felt this when I tried to set up the project) or misconfigured, potentially causing confusion, extra support queries, or wasted time.
The test already existed; my changes simply make it multi-platform compatible, so Windows developers can run the suite successfully and verify their environment.

Note: This test was already present in the codebase — I’ve only modified it slightly to make it multi-platform compatible.

[Shrikantgiri25]

Hi 👋 just following up on this PR.
It fixes a cross-platform test failure on Windows (Python 3.13) and improves setup experience for new contributors.
If no changes are needed, great — and if it’s not aligned with project scope, happy to close it. Thanks!

[browniebroke]

The removal of the print statements make complete sense to me, but I'm a bit more on the fence on the rest of the PR. To Pravin's point, it does introduce some complexity which I'm not sure is worth it. It seems to also change some lines which are unrelated at first glance... I might be missing something here.

It's better to keep changes minimal and separated, if you send a PR for removing the print statement, I'm happy to accept it.

[Shrikantgiri25]

The removal of the print statements make complete sense to me, but I'm a bit more on the fence on the rest of the PR. To Pravin's point, it does introduce some complexity which I'm not sure is worth it. It seems to also change some lines which are unrelated at first glance... I might be missing something here.

It's better to keep changes minimal and separated, if you send a PR for removing the print statement, I'm happy to accept it.

Hi @browniebroke ,
I noticed some tests are already skipped for version-specific reasons (e.g., in test_decorators.py). For this Windows case, instead of modifying the test logic, would it be acceptable to use a similar skip approach:

@pytest.mark.skipif(sys.platform.startswith("win"), reason="Skipped on Windows")

This would avoid introducing additional complexity.
If this isn’t desirable, I’m happy to submit a separate PR just for removing the debug print statements and close this PR.

Thanks for your guidance!

[browniebroke]

Yes that seems lower lighter touch fix yes 👍🏻

[Shrikantgiri25]

Yes that seems lower touch fix yes 👍🏻

Great, thanks! I'll update the PR to use the skip approach + print removals.

[Shrikantgiri25]

Hi all, updated the PR to use @pytest.mark.skipif for the test.