Skip to content
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

Impovements from PRs #245

Merged
merged 31 commits into from
Apr 3, 2024
Merged

Impovements from PRs #245

merged 31 commits into from
Apr 3, 2024

Conversation

geraintpalmer
Copy link
Member

No description provided.

galenseilis and others added 30 commits December 3, 2023 13:50
Modern Python classes implicitly inherit from object.
- Changed order of imports to match PEP8.
- Adjusted __repr__ so that brackets are given with the distribution name.
- Added a mixture distribution class.
String representations needed to be updated.
Docstrings and type hints for schedules.Schedule
Just found Salabim. Definitely looks like another simulation tool that can handle queues.
In Python, the is not None construct is preferred over != None for several reasons:

    Identity Comparison vs. Value Comparison:
        is not is an identity comparison, which checks whether two objects refer to the same memory location.
        != is a value comparison, which checks whether the values of the objects are equal.

    None is a Singleton:
        None is a singleton object in Python, meaning there is only one instance of None in the entire program.
        Using is not None leverages the identity comparison and takes advantage of the fact that there is only one None object, making it more efficient than a value comparison.

    Consistency:
        Using is not None is more consistent with the recommended practice of using is and is not for checking against singletons (like None).

    Avoids Unintended Behavior:
        Value comparisons (!=) may behave unexpectedly when dealing with objects that override the __eq__ method, leading to potential pitfalls.
        Identity comparisons (is not) are safer in such cases, as they explicitly check for object identity.
Node does need to explicitly inherit from object.
I saw this message on the continuous integration build errors. It looks like we just need to update the version.

`The sphinxcontrib.applehelp extension used by this project needs at least Sphinx v5.0; it therefore cannot be built with this version.`
Remove inheriting from `object` state_tracker.py
Docstrings and type hints for schedules.Schedule
NumPy docstrings and type hints in disciplines.py
Mixtures and __repr__ enhancements.
Change `!= None` to `is not` in import_params.py
@geraintpalmer geraintpalmer merged commit 7d82cb6 into master Apr 3, 2024
31 checks passed
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.

2 participants