Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Remove FreezableDefaultDict#346

Closed
andersk wants to merge 1 commit intopython:mainfrom
andersk:remove-FreezableDefaultDict
Closed

Remove FreezableDefaultDict#346
andersk wants to merge 1 commit intopython:mainfrom
andersk:remove-FreezableDefaultDict

Conversation

@andersk
Copy link

@andersk andersk commented Aug 27, 2021

As you can see from this diff, FreezableDefaultDict doesn’t seem like it’s adding much value over a regular dict for this use case. What do you think about removing it, as a simpler alternative to addressing these comments from #342?

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
@jaraco
Copy link
Member

jaraco commented Aug 29, 2021

The main reason for preferring a defaultdict is to avoid the duplication of []/list() across the get and setdefault calls, to encapsulate that behavior on the property, to declare/document the intended use, and to provide tested/reusable behavior. I acknowledge those benefits are diminished when the default dict must be frozen at some point to prevent mutation on iteration. Overall, I believe the implementation as established is valuable because it retains the defaultdict behavior but also illustrates a re-usable way to avoid the mutation on iteration error.

I feel pretty strongly that it's preferable to build sophisticated data structures that model the desired behavior rather than to rely on primitive structures and the code that calls them to cooperate with an implicit model. It's the same rationale for defaultdict existing at all, when it could be replaced by .setdefault and .get calls. For that reason, I'd prefer to retain the existing implementation, especially considering that the primary motivation is to avoid having to add type annotations to the upstream implementation.

I do appreciate the approach you're taking here to consider simplifying the base implementation to facilitate adding type annotations.

It should not be difficult to add the type annotations to jaraco.collections other than the toil of implementing it there. I can help with that as time permits.

@jaraco jaraco closed this Aug 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants