Skip to content

Raise clearer errors for constructor, mask, and attribute misuse - #606

Open
eriknw wants to merge 3 commits into
25-pandas-free-reprfrom
26-constructor-and-error-clarity
Open

Raise clearer errors for constructor, mask, and attribute misuse#606
eriknw wants to merge 3 commits into
25-pandas-free-reprfrom
26-constructor-and-error-clarity

Conversation

@eriknw

@eriknw eriknw commented Aug 4, 2026

Copy link
Copy Markdown
Member

Three error-message improvements for common misuses; no behavior change on
valid inputs.

  • Data passed to a constructor (d97732f): Vector([1, 2, 3]) now
    raises a TypeError pointing at from_coo/from_dense instead of
    "Unknown dtype: [1, 2, 3]". The hint engages only after lookup_dtype has
    rejected the argument, so valid list/tuple dtype specs (structured and
    subarray dtypes) still work.
  • Wrong-kind mask on a Matrix operation (55f58d3): a Vector mask on a
    full-Matrix operation now reports "Mask object must be type Matrix;
    got ..." instead of leaking a raw cffi struct error. Assignment is exempt
    via a strict_kind flag, because a Vector mask on a Matrix row/column
    assign is valid and setitem validates it separately.
  • .new and .transpose accessed as attributes (fbde2ba): a
    BaseType.getattr hint table points A.new() at << / .new-on-expressions
    and A.transpose() at the .T property. It still raises AttributeError, so
    hasattr/getattr probes are unaffected, and getattr fires only on a
    genuine miss, so the attribute hot path is untouched.

Stack created with GitHub Stacks CLIGive Feedback 💬

@eriknw eriknw changed the title 26 constructor and error clarity Raise clearer errors for constructor, mask, and attribute misuse Aug 4, 2026
@eriknw
eriknw marked this pull request as ready for review August 4, 2026 16:07
@eriknw
eriknw force-pushed the 26-constructor-and-error-clarity branch 2 times, most recently from fae7148 to f010e36 Compare August 5, 2026 00:06
@eriknw
eriknw force-pushed the 26-constructor-and-error-clarity branch from f010e36 to 9302620 Compare August 5, 2026 03:18
@eriknw
eriknw force-pushed the 26-constructor-and-error-clarity branch from 9302620 to 0984c49 Compare August 5, 2026 17:44
@eriknw
eriknw force-pushed the 26-constructor-and-error-clarity branch from 0984c49 to c1e43bc Compare August 5, 2026 18:03
@eriknw
eriknw force-pushed the 26-constructor-and-error-clarity branch from c1e43bc to 4b45803 Compare August 5, 2026 18:05
@eriknw
eriknw force-pushed the 26-constructor-and-error-clarity branch from 4b45803 to 50975fa Compare August 6, 2026 07:59
@eriknw
eriknw force-pushed the 26-constructor-and-error-clarity branch from 50975fa to c2ff5cb Compare August 6, 2026 15:39
@eriknw
eriknw force-pushed the 26-constructor-and-error-clarity branch from c2ff5cb to 7856374 Compare August 6, 2026 15:41
@eriknw
eriknw force-pushed the 26-constructor-and-error-clarity branch from 7856374 to 1cb3383 Compare August 6, 2026 20:36
@eriknw
eriknw force-pushed the 26-constructor-and-error-clarity branch from 1cb3383 to 8093367 Compare August 6, 2026 20:42
@eriknw
eriknw force-pushed the 26-constructor-and-error-clarity branch from 8093367 to ad024db Compare August 7, 2026 02:48
eriknw added 3 commits August 7, 2026 00:09
Vector([1, 2, 3]) previously failed with "Unknown dtype: [1, 2, 3] of
type <class 'list'>". The constructors take a dtype first, so passing
data is a common newcomer mistake; now list/tuple/ndarray first
arguments that fail dtype lookup raise a TypeError pointing to
from_coo/from_dense. Valid list/tuple dtype specs (structured and
subarray dtypes) still work: the hint only engages after lookup_dtype
has rejected the argument. Other bad dtypes keep the original
ValueError.
A Vector mask on a full-Matrix operation (ewise, extract, .new) leaked a raw
cffi error, "initializer for ctype 'struct GB_Matrix_opaque'", which says
nothing about masks.  The Vector-output direction was already guarded;
_check_mask now guards the Matrix-output direction the same way and reports
"Mask object must be type Matrix; got ...".

The check is gated behind a strict_kind flag rather than applied everywhere,
because assignment is a genuine exception: a Vector mask on a Matrix
row/column assign is valid, and Matrix.__setitem__ validates it separately.
So strict_kind is False for __setitem__ updates and True for .new() and other
full-tensor operations.
Two common misuses failed with a bare "no attribute" message that gave no
direction:

    A.new()           is the expression resolver, not an instance method
    A.transpose()     transpose is the .T property, not a method

A __getattr__ on BaseType supplies the hint on the attribute miss.  It
raises AttributeError, exactly as before, so hasattr() and getattr() with a
default keep answering the way they did and duck-typing probes are
unaffected; only the message changes.  Names with no hint keep the plain
message.

.new and .transpose ride in one commit because they are one mechanism: a
single __getattr__ consulting a single hint table.  Splitting them would mean
adding the same function twice.

__getattr__ fires only on a genuine attribute miss, since slots and methods
resolve first, so the attribute hot path is untouched.

There is deliberately no class-level hint (Matrix.new): that needs a
metaclass, and both candidates break something real.  A plain type
metaclass makes mixing Matrix into any abc-based class die with
"metaclass conflict", and an ABCMeta-derived one leaks register,
__abstractmethods__ and _abc_impl into dir(Matrix), which the
expression-surface guard rightly reports as drift.  Class-level misuse
keeps Python's default AttributeError, and test_abc_mixin_subclass pins
the abc composition.
@eriknw
eriknw force-pushed the 26-constructor-and-error-clarity branch from ad024db to 951c957 Compare August 7, 2026 05:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant