Is there anything else I should know about the code?
We are about to complete a major rewrite of the library, whose details are documented here. Pretty much everything was re-built, while the user-facing API stayed mostly the same - which is good, but not really that important for a project with current version 0.8.0-dev. As most of that API grew organically, now would be the optimal point in time to think about which things we could do better in terms of usability.
The changes are close to complete for a alpha release (with the still missing documentation and test updates probably waiting until we release a beta version), while there still is some internal polishing and advanced, new functionality in the progress of being developed, where feedback in-the-loop would also be awesome (see also the discussion here).
Are there any areas you would like me to focus on?
There are a few areas that would benefit from a review:
the user facing API, which mostly consists of attr.s classes for representing the individual iCalendar objects, which resides in the root code folder
the (de-)serialization code, where most of the code resides in the converter module. The main idea is to automatically infer the required (de-)serialization steps by introspecting the attr.ibs of the data classes once after startup. I guess the architecture should be simplified in some places, as it's somewhat hard to convery an overview over interactions of the different classes that are involved, but I'm not quite sure how to do that without losing functionality. Furthermore, I'm planing to include new functionality for customizing the parsing by tweaking the handling of non-standard inputs and the resulting exceptions (allowing the user to silence them or replace misparsed values manually) and for adding parsers for custom properties, opinions on how this could achieved would be highly appreciated.
what the library (and pretty much also no other library) currently can't handle properly, is recurring events. How the user facing API for this might look like is an interesting problem, altough also very closely tied to how the underlying RFC defines recurrance.
Have I reviewed this project previously?
Not that I'm aware of.
What is the name of your project? ics.py: iCalendar for Humans, a Pythonic and easy iCalendar library following RFC 5545
What is the repo URL? https://github.com/ics-py/ics-py
Is there anything else I should know about the code? We are about to complete a major rewrite of the library, whose details are documented here. Pretty much everything was re-built, while the user-facing API stayed mostly the same - which is good, but not really that important for a project with current version 0.8.0-dev. As most of that API grew organically, now would be the optimal point in time to think about which things we could do better in terms of usability. The changes are close to complete for a alpha release (with the still missing documentation and test updates probably waiting until we release a beta version), while there still is some internal polishing and advanced, new functionality in the progress of being developed, where feedback in-the-loop would also be awesome (see also the discussion here).
Are there any areas you would like me to focus on? There are a few areas that would benefit from a review:
attr.sclasses for representing the individual iCalendar objects, which resides in the root code folderconvertermodule. The main idea is to automatically infer the required (de-)serialization steps by introspecting theattr.ibs of the data classes once after startup. I guess the architecture should be simplified in some places, as it's somewhat hard to convery an overview over interactions of the different classes that are involved, but I'm not quite sure how to do that without losing functionality. Furthermore, I'm planing to include new functionality for customizing the parsing by tweaking the handling of non-standard inputs and the resulting exceptions (allowing the user to silence them or replace misparsed values manually) and for adding parsers for custom properties, opinions on how this could achieved would be highly appreciated.Have I reviewed this project previously? Not that I'm aware of.