Going through the logs from @mattip 's logs in #19154 I think the failures we are seeing can be classified as below.
finalizer / weakrefs different in pypy
We probably should just detect and skip pypy on these.
pypy does not implement a working sys.getsizeof
Skip this test on pypy, we are only using it to make sure that the output of rendering makes sense.
stack walking different?
The failures due to raising an unexpected warning are a bit more concerning. We are doing some frame walking / inspection to sort out if we should warn or not in
|
@functools.wraps(func) |
|
def wrapper(*args, **kwargs): |
|
name = 'savefig' # Reasonable default guess. |
|
public_api = re.compile(r'^savefig|print_[A-Za-z0-9]+$') |
|
seen_print_figure = False |
|
for frame, line in traceback.walk_stack(None): |
|
if frame is None: |
|
# when called in embedded context may hit frame is None. |
|
break |
|
if re.match(r'\A(matplotlib|mpl_toolkits)(\Z|\.(?!tests\.))', |
|
# Work around sphinx-gallery not setting __name__. |
|
frame.f_globals.get('__name__', '')): |
|
if public_api.match(frame.f_code.co_name): |
|
name = frame.f_code.co_name |
|
if name == 'print_figure': |
|
seen_print_figure = True |
|
else: |
|
break |
|
|
|
accepted_kwargs = {*old_sig.parameters, *extra_kwargs} |
|
if seen_print_figure: |
|
for kw in ['dpi', 'facecolor', 'edgecolor', 'orientation', |
|
'bbox_inches_restore']: |
|
# Ignore keyword arguments that are passed in by print_figure |
|
# for the use of other renderers. |
|
if kw not in accepted_kwargs: |
|
kwargs.pop(kw, None) |
|
|
|
for arg in list(kwargs): |
|
if arg in accepted_kwargs: |
|
continue |
|
cbook.warn_deprecated( |
|
'3.3', name=name, |
|
message='%(name)s() got unexpected keyword argument "' |
|
+ arg + '" which is no longer supported as of ' |
|
'%(since)s and will become an error ' |
|
'%(removal)s') |
|
kwargs.pop(arg) |
|
|
|
return func(*args, **kwargs) |
|
|
|
return wrapper |
I assume this is not working on pypy because we are relying on some cpython implementation detail?
If someone who understands pypy can fix that to work on both that would be best, but if not we should detect if we are on pypy and fall back to never warning. It is operating in a slightly degraded mode (users may not get warnings they should see), but the status quo is going to warn for things the user can not do anything about (I think every time we use tightlayout of bbox_inches='tight').
This is probably the only failures I would hold 3.4 over.
segfaults in tk
We should either track this down or just skip the tests.
subprocess hung
We should either track this down or just skip the tests.
not matching numpy?
These both look like they are upstream bugs in pypy? We should probably just skip these.
checking refcounts
These tests do not make sense for pypy, we should skip them.
sockets not working
The comments around this suggest we never got this working on azure (which I assume is what is hosting GH actions) so we should sort out why the code to not run these tests in that case is not being triggered here.
Going through the logs from @mattip 's logs in #19154 I think the failures we are seeing can be classified as below.
finalizer / weakrefs different in pypy
We probably should just detect and skip pypy on these.
pypy does not implement a working
sys.getsizeofSkip this test on pypy, we are only using it to make sure that the output of rendering makes sense.
stack walking different?
The failures due to raising an unexpected warning are a bit more concerning. We are doing some frame walking / inspection to sort out if we should warn or not in
matplotlib/lib/matplotlib/backend_bases.py
Lines 1624 to 1665 in 09ab2c2
If someone who understands pypy can fix that to work on both that would be best, but if not we should detect if we are on pypy and fall back to never warning. It is operating in a slightly degraded mode (users may not get warnings they should see), but the status quo is going to warn for things the user can not do anything about (I think every time we use tightlayout of
bbox_inches='tight').This is probably the only failures I would hold 3.4 over.
segfaults in tk
We should either track this down or just skip the tests.
subprocess hung
We should either track this down or just skip the tests.
not matching numpy?
These both look like they are upstream bugs in pypy? We should probably just skip these.
checking refcounts
These tests do not make sense for pypy, we should skip them.
sockets not working
The comments around this suggest we never got this working on azure (which I assume is what is hosting GH actions) so we should sort out why the code to not run these tests in that case is not being triggered here.