---
type: email
from: "Discussions on Python.org" <notifications@python1.discoursemail.com>
subject: [Discussions on Python.org] Summary
received: 2026-03-06 07:55:37
date_header: Thu, 02 Oct 2025 22:05:38 +0000
priority: normal
status: awaiting_approval
uid: 31797
---

## Email Content

**From:** "Discussions on Python.org" <notifications@python1.discoursemail.com>
**Subject:** [Discussions on Python.org] Summary
**Date:** Thu, 02 Oct 2025 22:05:38 +0000

### Body (preview)

A brief summary of [Discussions on Python.org][1] since 2025-09-25 21:45:51 UTC



26 New Topics

1 Unread Notifications

627 New Users





  

  ### Popular Topics



    [Split large Objects/unicodeobject.c file into smaller files][2]



      Hi, 

The Objects/unicodeobject.c file is made of 16,683 lines of C code. It became hard for me to navigate in such large file and add new functions (I’m one of the maintainers of this file). It also causes practical issues; for example the file is ignored by GitHub code search because it’s larger than the 350 KiB limit. 

I propose to split this large C file into smaller files (codecs, format, writer, etc.). 

I already proposed this idea in 2012 and there were arguments against splitting: 



Backports need more work.

Concerns about losing the Mercurial (Git) history.

Unknown impact on performance: a large single C file helps compiler inlining.

Harder to maintain (according to Martin von Loewis).

Harder to navigate: Martin prefers to have all functions in a single C file.



For the performance, since Python is now built with LTO+PGO in release mode, inlining shouldn’t be an issue. 

I tried different strategies, but it doesn’t seem possible to keep the Git history for new files, since the P...



    

    [Bad `-nogil` behaviour? Or something else is broken?][3]



      FYI, I tried this with subinterpreters and with 4 workers (half of 8 cores) it was twice as fast as with only threads.  (I did not try free-threaded.) 

The only changes I had to make were: 



switch to array.array insead of list(apparently adds a small overhead)

pass src_a, src_b, and result to sum_sequence()

wrap sum_sequence() in a helper to create the subinterpreter

wrap src_a, src_b, and result in memoryview (so they get shared and not copied)



...



def sum_sequence(src_a, src_b, result, from_boundary, to_boundary):

    """Sum the sequence."""

    for i in range(from_boundary, to_boundary):

        result[i] = src_a[i] + src_b[i]

---

## Suggested Actions
- [ ] Reply
- [ ] Archive
- [ ] Escalate
