Skip to content

Commit f7d0d1e

Browse files
committed
Init commit.
0 parents  commit f7d0d1e

8 files changed

Lines changed: 448 additions & 0 deletions

File tree

.gitignore

Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
# Project specific folders
2+
/tmp/
3+
4+
# Temporaries
5+
*~
6+
7+
# Byte-compiled / optimized / DLL files / tmp
8+
__pycache__/
9+
*.py[cod]
10+
*$py.class
11+
*.swp
12+
13+
# C extensions
14+
*.so
15+
16+
# OS specific files
17+
.DS_Store
18+
19+
# Distribution / packaging / data storage
20+
data/
21+
outputs/
22+
nevergrad_repository/
23+
.Python
24+
env/
25+
build/
26+
develop-eggs/
27+
dist/
28+
downloads/
29+
eggs/
30+
.eggs/
31+
lib/
32+
lib64/
33+
parts/
34+
sdist/
35+
var/
36+
wheels/
37+
/pip-wheel-metadata/
38+
*.egg-info/
39+
.installed.cfg
40+
*.egg
41+
42+
# PyInstaller
43+
# Usually these files are written by a python script from a template
44+
# before PyInstaller builds the exe, so as to inject date/other infos into it.
45+
*.manifest
46+
*.spec
47+
48+
# Installer logs
49+
pip-log.txt
50+
pip-delete-this-directory.txt
51+
52+
# Unit test / coverage reports
53+
htmlcov/
54+
.tox/
55+
.coverage
56+
.coverage.*
57+
.cache
58+
nosetests.xml
59+
coverage.xml
60+
*.cover
61+
.hypothesis/
62+
test_results/
63+
64+
# Translations
65+
*.mo
66+
*.pot
67+
68+
# Django stuff:
69+
*.log
70+
local_settings.py
71+
72+
# Flask stuff:
73+
instance/
74+
.webassets-cache
75+
76+
# Scrapy stuff:
77+
.scrapy
78+
79+
# Sphinx documentation
80+
docs/_build/
81+
82+
# PyBuilder
83+
target/
84+
85+
# Jupyter Notebook
86+
.ipynb_checkpoints
87+
88+
# pyenv
89+
.python-version
90+
91+
# celery beat schedule file
92+
celerybeat-schedule
93+
94+
# SageMath parsed files
95+
*.sage.py
96+
97+
# dotenv
98+
.env
99+
100+
# virtualenv
101+
.venv
102+
venv/
103+
ENV/

AUTHORS.rst

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
.. -*- mode: rst -*-
2+
3+
People
4+
------
5+
6+
This work is made available by a community of people, amoung which the CEA Neurospin BAOBAB laboratory.
7+
8+
.. _core_devs:
9+
10+
Core developers
11+
...............
12+
13+
The core developers are:
14+
15+
* Antoine Grigis
16+
17+
Other contributors
18+
..................
19+
20+
Some other past or present contributors are:
21+
22+
* ...

CHANGELOG.rst

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
.. -*- mode: rst -*-
2+
3+
4+
Version 0.1.0
5+
=============
6+
7+
:Date: October 15, 2025
8+
9+
Added
10+
-----
11+
12+
*
13+
14+
Changed
15+
-------
16+
17+
Deprecated
18+
----------
19+
20+
Fixed
21+
-----
22+
23+
Contributors
24+
------------
25+
26+
The following people contributed to this release (from ``git shortlog -ns v0.1.0``)::
27+
28+

CONTRIBUTING.rst

Lines changed: 129 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,129 @@
1+
Contributing to typex
2+
====================
3+
4+
.. |fork_logo| image:: https://upload.wikimedia.org/wikipedia/commons/d/dd/Octicons-repo-forked.svg
5+
:height: 20
6+
7+
Contents
8+
--------
9+
10+
1. `Introduction <#introduction>`_
11+
12+
2. `Issues <#issues>`_
13+
14+
a. `Asking Questions <#asking-questions>`_
15+
16+
b. `Reporting Bugs <#reporting-bugs>`_
17+
18+
c. `Requesting Features <#requesting-features>`_
19+
20+
3. `Pull Requests <#pull-requests>`_
21+
22+
a. `Content <#content>`_
23+
24+
b. `CI Tests <#ci-tests>`_
25+
26+
c. `Coverage <#coverage>`_
27+
28+
d. `Style Guide <#style-guide>`_
29+
30+
Introduction
31+
------------
32+
33+
typex is fully open-source and as such users are welcome to fork, clone and/or reuse the software freely.
34+
Users wishing to contribute to the development of this package, however, are kindly requested to adhere to the
35+
following `LICENSE <./LICENSE.rst>`_.
36+
37+
Issues
38+
------
39+
40+
The easiest way to contribute to typex is by raising a "New issue". This will give you the opportunity to ask questions, report bugs or
41+
even request new features.
42+
Remember to use clear and descriptive titles for issues. This will help other users that encounter similar problems find quick solutions.
43+
We also ask that you read the available documentation and browse existing issues on similar topics before raising a new issue in order to avoid repetition.
44+
45+
Asking Questions
46+
~~~~~~~~~~~~~~~~
47+
48+
Users are of course welcome to ask any question relating to typex and we will endeavour to reply as soon as possible.
49+
50+
These issues should include the **help wanted** label.
51+
52+
Reporting Bugs
53+
~~~~~~~~~~~~~~
54+
55+
If you discover a bug while using typex please include the following details in the issue you raise:
56+
57+
* your operating system and the corresponding version (*e.g.* macOS v10.14.1, Ubuntu v20.04.1, *etc.*),
58+
* the version of Python you are using (*e.g* v3.6.7, *etc.*),
59+
* and the error message printed or a screen capture of the terminal output.
60+
61+
Be sure to list the exact steps you followed that lead to the bug you encountered so that we can attempt to recreate the conditions.
62+
If you are aware of the source of the bug we would very much appreciate if you could provide the module(s) and line number(s) affected.
63+
This will enable us to more rapidly fix the problem.
64+
65+
These issues should include the **bug** label.
66+
67+
Requesting Features
68+
~~~~~~~~~~~~~~~~~~~
69+
70+
If you believe typex could be improved with the addition of extra functionality or features feel free to let us know.
71+
We cannot guarantee that we will include these features, but we will certainly take your suggestions into consideration.
72+
In order to increase your chances of having a feature included, be sure to be as clear and specific as possible as to the properties this
73+
feature should have.
74+
75+
These issues should include the **enhancement** label.
76+
77+
Pull Requests
78+
-------------
79+
80+
If you would like to take a more active roll in the development of typex you can do so by submitting a "Pull request".
81+
A Pull Requests (PR) is a way by which a user can submit modifications or additions to the nidl package directly.
82+
PRs need to be reviewed by the package moderators and if accepted are merged into the master branch of the repository.
83+
84+
Before making a PR, be sure to carefully read the following guidelines:
85+
86+
* fork the repository from the GitHub interface, *i.e.* press the button on the top right with this
87+
symbol |fork_logo|.
88+
This will create an independent copy of the repository on your account.
89+
* code the new feature in your fork, ideally by creating a new branch.
90+
* make a pull request from the GitHub interface for this branch with a clear description of what has been done, why and what issues this relates to.
91+
* wait for feedback and update your code if requested.
92+
93+
Content
94+
~~~~~~~
95+
96+
Every PR should correspond to a bug fix or new feature issue that has already been raised.
97+
When you make a PR be sure to tag the issue that it resolves (*e.g.* this PR relates to issue #1).
98+
This way the issue can be closed once the PR has been merged.
99+
100+
The content of a given PR should be as concise as possible.
101+
To that end, aim to restrict modifications to those needed to resolve a single issue.
102+
Additional bug fixes or features should be made as separate PRs.
103+
104+
CI Tests
105+
~~~~~~~~
106+
107+
Continuous Integration (CI) tests are implemented via GithHub workflows.
108+
All PRs must pass the CI tests before being merged.
109+
Your PR may not be reviewed by a moderator until all CI test are passed.
110+
Therefore, try to resolve any issues in your PR that may cause the tests to fail.
111+
In some cases it may be necessary to modify the unit tests, but this should be clearly justified in the PR description.
112+
113+
Coverage
114+
~~~~~~~~
115+
116+
Coverage tests are implemented via `Coveralls <https://coveralls.io>`_.
117+
These tests will fail if the coverage, *i.e.* the number of lines of code covered by unit tests, decreases.
118+
When submitting new code in a PR, contributors should aim to write appropriate unit tests.
119+
If the coverage drops significantly moderators may request unit tests be added before the PR is merged.
120+
121+
Style Guide
122+
~~~~~~~~~~~
123+
124+
All contributions should adhere to the following style guides currently implemented in typex:
125+
126+
* all code should be compatible with the typex dependencies.
127+
* all code should adhere to `PEP8 <https://www.python.org/dev/peps/pep-0008>`_ standards.
128+
* docstrings need to be provided for all new modules, methods and classes.
129+
These should adhere to `numpydoc <https://numpydoc.readthedocs.io/en/latest/format.html>`_ standards.

LICENSE.rst

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
.. -*- mode: rst -*-
2+
3+
The code is distributed under the terms of the `CeCILL-B <http://www.cecill.info/licences/Licence_CeCILL-B_V1-en.html>`_ license, as published by the CEA-CNRS-INRIA.

README.rst

Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
.. -*- mode: rst -*-
2+
3+
|PythonVersion|_ |Coveralls|_ |Testing|_ |Linter|_ |PyPi|_
4+
5+
.. |PythonVersion| image:: https://img.shields.io/badge/python-3.9%20%7C%203.12-blue
6+
.. _PythonVersion: target:: https://img.shields.io/badge/python-3.9%20%7C%203.12-blue
7+
8+
.. |Coveralls| image:: https://coveralls.io/repos/github/neurospin-deepinsight/typex/badge.svg?branch=main
9+
.. _Coveralls: target:: https://coveralls.io/github/neurospin-deepinsight/typex
10+
11+
.. |Testing| image:: https://github.com/neurospin-deepinsight/typex/actions/workflows/testing.yml/badge.svg
12+
.. _Testing: target:: https://github.com/neurospin-deepinsight/typex/actions
13+
14+
.. |Linter| image:: https://github.com/neurospin-deepinsight/typex/actions/workflows/linters.yml/badge.svg
15+
.. _Linter: target:: https://github.com/neurospin-deepinsight/typex/actions
16+
17+
.. |PyPi| image:: https://badge.fury.io/py/typex.svg
18+
.. _PyPi: target:: https://badge.fury.io/py/typex
19+
20+
21+
typeX
22+
=====
23+
24+
\:+1: If you are using the code please add a star to the repository :+1:
25+
26+
This work is made available by a `community of people <./AUTHORS.rst>`_, amoung which the CEA Neurospin BAOBAB laboratory.
27+
28+
29+
Important links
30+
---------------
31+
32+
- `Official source code repo <https://github.com/neurospin-deepinsight/typex>`_
33+
- `Release notes <./CHANGELOG.rst>`_
34+
35+
36+
Content
37+
-------
38+
39+
TypeX supplies a simple decorator to enforce Python types on function parameters when annotations are available.
40+
41+
Where to start
42+
--------------
43+
44+
Please find below a simple usage example:
45+
46+
```python
47+
from typex import typecheck
48+
49+
50+
@typecheck
51+
def halve_integer(a: int) -> float:
52+
return a / 2
53+
54+
halve_integer(5) # 2.5
55+
halve_integer(5.0) # TraitsError
56+
```
57+
58+
Install
59+
-------
60+
61+
The package is available on `pypi <https://pypi.org/project/typex>`_.
62+
63+
64+
Contributing
65+
------------
66+
67+
If you want to contribute to typex, be sure to review the `contribution guidelines <./CONTRIBUTING.rst>`_.
68+
69+
70+
License
71+
-------
72+
73+
This project is under the following `LICENSE <./LICENSE.rst>`_.

0 commit comments

Comments
 (0)