new function safer_getattr_raise

[d-maurer]

Fixed #287.

safer_getattr_raise is similar to safer_getattr but handles its parameter default like getattr. In particular, it raises AttributeError if the attribute lookup fails and no default has been provided.

[d-maurer]

The failing coverage test should be unrelated to this change.

[d-maurer]

Has someone an idea why the coverage test has failed and what to do to get it pass? Should the current "meta config" get applied?

I also get periodic notes that coverage tests have failed for zope.testrunner. Looks like several packages have problems with the coverage/coveralls integration.

[icemac]

Has someone an idea why the coverage test has failed and what to do to get it pass?

There is #238 to fix this but it is not completed yet. (When it works we will be back at 100 % coverage.)

Should the current "meta config" get applied?

This will not help.

I also get periodic notes that coverage tests have failed for zope.testrunner. Looks like several packages have problems with the coverage/coveralls integration.

Yes, coveralls sometimes has upload problems and its numbers are sometimes strange. Additionally it has its own numbers for min coverage and max delta. (Can be changed using GitHub login for ZF contributors if needed.)

According to zopefoundation/meta#14 the alternatives are not better. (This was some years ago maybe now is the time with better alternatives. I personally know none but this does not mean anything.)

[icemac]

The coverage is no problem. Running tox -e combined-coverage locally should return 100 % coverage, but I did not try.

[d-maurer]

Michael Howitz wrote at 2024-10-1 23:36 -0700:

> Has someone an idea why the `coverage` test has failed and what to do to get it pass? There is #238 to fix this but it is not completed yet. (When it works we will be back at 100 % coverage.)

Thank you! I will wait with the merge until #238 is completed.

[d-maurer]

The coverage is no problem

It prevents merging without special rights (which I have in principle but do not like to use unless really necessary).

[icemac]

Currently no-one is activly working on #238. So super-powers might be helpful here.

[dataflake]

Michael is right, no one is working on #238. If you keep waiting for that this PR will never get merged.

[d-maurer]

Michael is right, no one is working on #238. If you keep waiting for that this PR will never get merged.

Currently, the main problem seems to be that the linting check does not report its outcome. Where does this check comes from, why is its report missing, why is this step required?

Apparently, we know that the overall coverage checks fail. Should we not disable them until the problem is fixed?

[dataflake]

The linting check does not answer because the branch protection rules have been changed to conform to the latest meta/config templates. This PR does not. There is no need to be concerned, it will fix itself after merging.

The coverage check fails - as you can see - because coverage changed a tiny bit. I know, this is annoying and misleading, but again, nothing that should hold up this PR.

[dataflake]

I have changed the coveralls settings a little bit but they don't apply retroactively. I also removed the linting requirement. The linter has run - see ubuntu - lint.

Please merge so we can move forward if you want this in the next release. I will merge #289 tomorrow morning and then make a release. All of this is holding up a Python 3.13-compatible Zope release.

[dataflake]

P.S.: I re-ran the last batch of tests and coverage is green. The release-check failure is because Python 3.13 is released but support is not declared in setup.py. This will fix itself after merging when I merge #289

[d-maurer]

Jens Vagelpohl wrote at 2024-10-9 04:04 -0700:

P.S.: I re-ran the last batch of tests and coverage is green. The release-check failure is because Python 3.13 is released but support is not declared in `setup.py`. This will fix itself after merging when I merge #289

Thank you for your support! Merge is done.