The following crashes with Python 3.8b3

import sys
import pytz
import datetime

print(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.2
Fatal Python error: Segmentation fault

Current 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 to bpo-37685 (dde944f) 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 sys
import datetime

print(sys.version)
class UTC(datetime.tzinfo):
    pass

print(datetime.timezone.utc == UTC())
datetime.timezone.utc == datetime.tzinfo() # This also segfaults without a subclass and should be False

# Segfaults

➜ cpython git:(dde944f) git checkout dde944f && make -s -j4 > /dev/null
HEAD is now at dde944f bpo-37685: Fixed comparisons of datetime.timedelta and datetime.timezone. (GH-14996)
➜ cpython git:(dde944f) ./python.exe ../backups/bpo37915.py
3.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:(dde944f) git checkout dde944f~1 && make -s -j4 > /dev/null
Previous HEAD position was dde944f bpo-37685: Fixed comparisons of datetime.timedelta and datetime.timezone. (GH-14996)
HEAD is now at 4e402d3 Correct description of HTTP status code 308. (GH-15098)
➜ cpython git:(4e402d3) ./python.exe ../backups/bpo37915.py
3.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 changeset 4be11c0 by Miss Islington (bot) (Pablo Galindo) in branch 'master':
bpo-37915: Fix comparison between tzinfo objects and timezone objects (GH-15390)
4be11c0

New changeset 5c77730 by Miss Islington (bot) in branch '3.8':
bpo-37915: Fix comparison between tzinfo objects and timezone objects (GH-15390)
5c77730

New changeset 1b1796d by Pablo Galindo in branch '3.7':
[3.7] bpo-37915: Fix comparison between tzinfo objects and timezone objects (GH-15390) (GH-15417)
1b1796d

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