Skip to content

feat: 83 replace poetry co by uv and ruff #91

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 32 commits into
base: main
Choose a base branch
from

Conversation

atstaeff
Copy link
Contributor

@atstaeff atstaeff commented Jun 9, 2025

No description provided.

@atstaeff atstaeff linked an issue Jun 9, 2025 that may be closed by this pull request
6 tasks
@atstaeff atstaeff marked this pull request as ready for review June 12, 2025 15:03
@atstaeff atstaeff requested review from a team as code owners June 12, 2025 15:03
@goloroden goloroden self-assigned this Jun 12, 2025

return EventType(
event_type=event_type,
is_phantom=is_phantom,
schema=schema,
)

def __hash__(self) -> str:
# Convert dictionary schema to a hashable form (tuple of items)
def __hash__(self) -> int:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wofür wird diese Funktion genutzt?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Die Methode wird tatsächlich indirekt gebraucht. Im Test wird ein set[EventType] verwendet:

test_read_event_types.py
Damit Python-Objekte in einem set verwendet oder mit == verglichen werden können, müssen sie hashbar sein. Das bedeutet, sie brauchen sowohl hash als auch eq Methoden.

Ohne hash würde Python einen Fehler werfen, wenn Sie versuchen, EventType-Objekte zu einem Set hinzuzufügen oder Sets zu vergleichen.

Die hash Methode ist also essentiell für:

Das Hinzufügen von EventType zu Sets
Den Vergleich der beiden Sets mit assert actual_event_types == expected_event_types
Die allgemeine Verwendung von EventType als Schlüssel in Dicts oder als Element in Set

Makefile Outdated
Comment on lines 16 to 25
@find . -type d -name __pycache__ -exec rm -rf {} +
@find . -type f -name "*.pyc" -delete
@find . -type f -name "*.pyo" -delete
@find . -type f -name "*.pyd" -delete
@find . -type f -name ".coverage" -delete
@find . -type d -name "*.egg-info" -exec rm -rf {} +
@find . -type d -name "*.egg" -exec rm -rf {} +
@find . -type d -name ".pytest_cache" -exec rm -rf {} +
@find . -type d -name ".mypy_cache" -exec rm -rf {} +
@rm -rf build/ dist/ .coverage htmlcov/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alles, was hier aufgelistet ist, sollte auch in der .gitignore ausgeschlossen werden.

Copy link
Contributor Author

@atstaeff atstaeff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hab eine .gitingore mit den wichtigsten Paramtern erstellt. Habe mir überlegt clean herauszunehmen aus dem makefile. Ich erwarte von jedem "Entwickler" das er das kann. :)

@goloroden
Copy link
Member

@atstaeff Das clean würde ich drinlassen, weil man dafür sonst von Hand wissen muss, wo was wann warum hinzugefügt wird. Und auch wenn man das kann, ist es unter Umständen nervige Handarbeit. Außerdem ist es angenehm, in jedem Repository, unabhängig von der verwendeten Technologie, ein make clean machen zu können.

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.

Replace poetry & co. by uv and ruff
2 participants