Recharging chunk related dead batteries, PEP594, feedback appreciated

Maintaining and Enhancing the Chunk Module

Hello Python Community,

I’ve been actively participating in the discussion on “Maintaining the chunk module after it has been removed from the standard library”. Following this, I’ve taken the initiative to copy the chunk module, make enhancements, and have now successfully uploaded it to GitHub and PyPI. Additionally, I’ve crafted a test for it.

I’m seeking feedback on the test I’ve written. This is my first test released for broader use, and while I’ve written tests before, I’m eager to align more closely with Python’s best practices. Your insights will be incredibly valuable, especially as I plan to further develop this package. Here’s the GitHub link for reference: chunkmuncher on GitHub.

Thank you in advance for your time and input.

Upcoming Plans for Chunkmuncher

I’d also like to share the roadmap for chunkmuncher and welcome any feedback or suggestions.

  1. Integration with the AIFC Module: The immediate focus is to integrate the aifc module and develop tests for it. Updates will be pushed to the PyPI package subsequently.
  2. Wave Module Enhancement: Similar steps will follow for the Wave module, with a focus on updates and PyPI deployment.
  3. Code Optimization: I plan to streamline the code, especially targeting redundant elements in the aifc and wave modules, like their internal versions of the Chunk class.
  4. Enhancing Chunk Functionalities: The roadmap includes porting over additional functionalities from aifc to support data writing in chunk.

Future Improvements Under Consideration

  • Enabling the modules to support pathlib.Path objects along with string inputs.
  • Adding capabilities for reading/writing data in memory, enhancing the flexibility for modifying chunks without overwriting existing data.

Looking forward to your thoughts and contributions!



Would it make sense to migrate the docs content into the readme file?

It might be useful to add a list of modern / still common / well known file formats supported to the docs / readme. From the test it looks like midi files can be read as well. That’s probably not obvious to most people.

Can public domain example / test files of the different supported file formats be added to the repository?

And maybe some links to relevant information?

1 Like

I think this is a great project you’re working on.

On a high-level, deciding now how much you are going to transform these modules will be helpful to your users. Is this a PyPi project that I can trust to not break my code a couple years for now, or do I need to pin my version to chunkmuncher=0.0.2 because after that it will go through major refactors?

A couple more thoughts, that I think will help you immensely long term. I had to go through the same learning curve very recently. What helped me the most was watching and reading other popular, but small Python projects and trying to emulate how those developers worked on their own code.

  • Learn how to use git branches to work on new functionality. Once the functionality is completed use a pull-request to merge it back into main.

  • Look into using Semantic Versioning

  • Read PEP 8. This will help your code read more similarly with other projects.

For instance:

Variable Naming: pkgPath should be pkg_path to adhere to the snake_case naming convention for variables and functions.

Class Naming: Class names should follow the CapWords convention - so test_chunk_midi would become TestChunkMidi (but maybe a better class name would be TestChunkWithMidi.

Method names should be all lowercase with words separated by underscores. makeMidiFile should be make_midi_file. I believe there is some room for short method names to not use underscores, as you see in the chunk module itself (getname).

1 Like