tree a92a7e7f05f129d762220707719b15665ed5f634
parent 8aa163eea6b0fb4693f6c0a314d4f2ccada51d70
author Paul Ganssle <paul@ganssle.io> 1597704007 -0400
committer GitHub <noreply@github.com> 1597704007 +0100
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJfOwdHCRBK7hj4Ov3rIwAAdHIIADIXQYxv6mDwgBuCzbsXPU7m
 fiFjiFjfl7NoMmTLUa7Y3Taf/OGSTq6GrRJbNv33Y3yQeRU3OjlMb4cw1iqFMiG3
 WrOuJqwoC98oPnkGBrjkAeSojh8WGtiRxYnabpfc/xXDSLqzlR4ohcP/DHcgdKyz
 nEGsqyAChSOWysvTDq9gF8qZO4fhqv6bLM6CRbDe5TEOXDnTs2zWVFhV4P79pYkI
 tDlaLZw0CLJ1RE0aHcT4wP1Lh7aUD3/PTBgvTgYAc2XZ6xeBzl7Lko5elUewbtWn
 jznfgLU1UelmLNKxvgMhjv0W/WDEdLRE+KPLlohJQkCz5XT6QOwyzkUMG79RlQs=
 =iuvo
 -----END PGP SIGNATURE-----
 

bpo-41568: Fix refleaks in zoneinfo subclasses (GH-21907)

* Fix refleak in C module __init_subclass__

This was leaking a reference to the weak cache dictionary for every
ZoneInfo subclass created.

* Fix refleak in ZoneInfo subclass's clear_cache

The previous version of the code accidentally cleared the global
ZONEINFO_STRONG_CACHE variable (and inducing `ZoneInfo` to create a new
strong cache) on calls to a subclass's `clear_cache()`. This would not
affect guaranteed behavior, but it's still not the right thing to do
(and it caused reference leaks).