The following crashes with Python 3.8b3```import sysimport pytzimport datetimeprint(sys.version_info)print(pytz.__version__)print(datetime.timezone.utc == pytz.utc)```When run with `-X faulthandler`, I see```sys.version_info(major=3, minor=8, micro=0, releaselevel='beta', serial=3)2019.2Fatal Python error: Segmentation faultCurrent thread 0x00000001138dc5c0 (most recent call first):  File "foo.py", line 8 in <module>Segmentation fault: 11```

I am adding 3.8 regression since the code works with 3.7 though it involves pytz.

Seems this is due toissue37685 (dde944f9df) on bisecting datetime related changes. Adding Serhiy. I guess this could be marked as release blocker.Here is a simplified reproducer on extracting pytz.utc source [0] which is an object of simple subclass of datetime.tzinfo : import sysimport datetimeprint(sys.version)class UTC(datetime.tzinfo):    passprint(datetime.timezone.utc == UTC())datetime.timezone.utc == datetime.tzinfo() # This also segfaults without a subclass and should be False# Segfaults➜  cpython git:(dde944f9df) git checkoutdde944f9df && make -s -j4 > /dev/nullHEAD is now atdde944f9dfbpo-37685: Fixed comparisons of datetime.timedelta and datetime.timezone. (GH-14996)➜  cpython git:(dde944f9df) ./python.exe ../backups/bpo37915.py3.8.0b3+ (tags/v3.8.0b3-30-gdde944f9df:dde944f9df, Aug 22 2019, 17:55:14)[Clang 7.0.2 (clang-700.1.81)][1]    33988 segmentation fault  ./python.exe ../backups/bpo37915.py# Commit before works fine➜  cpython git:(dde944f9df) git checkoutdde944f9df~1 && make -s -j4 > /dev/nullPrevious HEAD position wasdde944f9dfbpo-37685: Fixed comparisons of datetime.timedelta and datetime.timezone. (GH-14996)HEAD is now at4e402d37eb Correct description of HTTP status code 308. (GH-15098)➜  cpython git:(4e402d37eb) ./python.exe ../backups/bpo37915.py3.8.0b3+ (tags/v3.8.0b3-30-gdde944f9df:dde944f9df, Aug 22 2019, 17:55:14)[Clang 7.0.2 (clang-700.1.81)]False[0]https://github.com/stub42/pytz/blob/62f872054dde69e5c510094093cd6e221d96d5db/src/pytz/__init__.py#L256

Thanks for debugging this Karthikeyan and for the quick fix Pablo!

This is due to an incorrect type check in the timezone_richcompare, it should be a comparison against PyDateTime_TimeZoneType not against PyDateTime_TZInfoType. The segfault is due to an invalid casting to PyDateTime_TimeZoneType (the child) from the parent (PyDateTime_TZInfoType).

Thanks, Tom and Karthikeyan for the finding and the debugging :)

New changeset4be11c009abe88175fa164b45e4838e7267dfa97 by Miss Islington (bot) (Pablo Galindo) in branch 'master':bpo-37915: Fix comparison between tzinfo objects and timezone objects (GH-15390)https://github.com/python/cpython/commit/4be11c009abe88175fa164b45e4838e7267dfa97

New changeset5c77730300c0358d7bebd2bb39ea5d10222a3d9a by Miss Islington (bot) in branch '3.8':bpo-37915: Fix comparison between tzinfo objects and timezone objects (GH-15390)https://github.com/python/cpython/commit/5c77730300c0358d7bebd2bb39ea5d10222a3d9a

New changeset1b1796df3a4292067a174faa11b1a852f79e98e3 by Pablo Galindo in branch '3.7':[3.7]bpo-37915: Fix comparison between tzinfo objects and timezone objects (GH-15390) (GH-15417)https://github.com/python/cpython/commit/1b1796df3a4292067a174faa11b1a852f79e98e3

(Removing “3.7regression” as the problematic change for 3.7 had not yet been released.)