Fixed PrivateAttr defaults ignored on database-loaded instances

[xr843]

Summary

Fixes #149

• When SQLAlchemy reconstructs a model instance from a database query (bypassing __init__), it calls __new__ which invokes init_pydantic_private_attrs(). That function was setting __pydantic_private__ = None instead of initializing it with the private attribute defaults.
• This caused AttributeError when accessing PrivateAttr fields on database-loaded instances.
• The fix introspects the class's __private_attributes__ dict and calls get_default() on each entry to properly initialize __pydantic_private__, mirroring what Pydantic's own BaseModel.__init__ does.

Test plan

• Create a SQLModel with PrivateAttr(default=...) fields
• Save an instance to the database
• Load the instance back from the database
• Verify that accessing the private attribute returns the default value instead of raising AttributeError

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com

[YuriiMotov]

@xr843, please, review and test changes before opening PR for review

[xr843]

Thank you for the feedback @YuriiMotov. I've addressed the issues:

1. Fixed mypy error: Used getattr() instead of direct __private_attributes__ access to satisfy mypy's union-attr check on the InstanceOrType union type.

2. Added regression tests (tests/test_private_attr.py):

   • test_private_attr_default_preserved_after_db_load — verifies PrivateAttr(default=...) works on DB-loaded instances
   • test_private_attr_default_factory_preserved_after_db_load — verifies PrivateAttr(default_factory=...) works on DB-loaded instances

Both tests confirm the fix resolves the AttributeError that previously occurred when accessing private attributes on instances reconstructed from the database (bypassing __init__).

Ready for re-review when you have a chance.

[svlandeg]

Ready for re-review when you have a chance.

Please review the CI errors as well.

[xr843]

@svlandeg Thank you for the reminder. I've reviewed the CI errors. All code quality checks are passing: tests (all matrix combinations), pre-commit, coverage (99%), and docs. The only failing check is check-labels which requires one of the standard labels ('breaking', 'security', 'feature', 'bug', 'refactor', 'upgrade', 'docs', 'lang-all', 'internal') to be applied to the PR. This is a repository maintenance step that needs to be done by a maintainer with write access. The fix for this PR addresses a bug (PrivateAttr defaults lost when loading from database), so the 'bug' label would be appropriate.