ramtable 0.3.1__tar.gz → 0.3.3__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- {ramtable-0.3.1 → ramtable-0.3.3}/.github/workflows/tests.yml +2 -1
- {ramtable-0.3.1 → ramtable-0.3.3}/CHANGELOG.md +31 -1
- ramtable-0.3.3/CONTRIBUTING.md +281 -0
- {ramtable-0.3.1 → ramtable-0.3.3}/PKG-INFO +13 -10
- {ramtable-0.3.1 → ramtable-0.3.3}/README.md +9 -7
- {ramtable-0.3.1 → ramtable-0.3.3}/docs/api.md +16 -3
- {ramtable-0.3.1 → ramtable-0.3.3}/docs/development.md +14 -5
- {ramtable-0.3.1 → ramtable-0.3.3}/pyproject.toml +4 -3
- ramtable-0.3.3/src/ramtable/__init__.py +24 -0
- {ramtable-0.3.1 → ramtable-0.3.3}/src/ramtable/rows.py +4 -4
- ramtable-0.3.1/src/ramtable/__init__.py +0 -15
- {ramtable-0.3.1 → ramtable-0.3.3}/.github/workflows/publish-test.yml +0 -0
- {ramtable-0.3.1 → ramtable-0.3.3}/.github/workflows/publish.yml +0 -0
- {ramtable-0.3.1 → ramtable-0.3.3}/.gitignore +0 -0
- {ramtable-0.3.1 → ramtable-0.3.3}/LICENSE +0 -0
- {ramtable-0.3.1 → ramtable-0.3.3}/docs/guide.md +0 -0
- {ramtable-0.3.1 → ramtable-0.3.3}/docs/types-and-validation.md +0 -0
- {ramtable-0.3.1 → ramtable-0.3.3}/src/ramtable/columns.py +0 -0
- {ramtable-0.3.1 → ramtable-0.3.3}/src/ramtable/table.py +0 -0
- {ramtable-0.3.1 → ramtable-0.3.3}/src/ramtable/types.py +0 -0
|
@@ -3,6 +3,37 @@
|
|
|
3
3
|
Notable changes to RAMTable are documented in this file. The history starts
|
|
4
4
|
with the project's first version.
|
|
5
5
|
|
|
6
|
+
## [0.3.3]
|
|
7
|
+
|
|
8
|
+
Adds contribution guidelines for the project.
|
|
9
|
+
|
|
10
|
+
### Added
|
|
11
|
+
|
|
12
|
+
- `CONTRIBUTING.md` covering contribution scope, the prior-approval policy
|
|
13
|
+
for new features, single-maintainer review expectations, branch naming,
|
|
14
|
+
development setup, testing expectations, and pull request guidelines.
|
|
15
|
+
|
|
16
|
+
### Changed
|
|
17
|
+
|
|
18
|
+
- `rows.py` changed `indices` to `indexes` in `get()` methods.
|
|
19
|
+
|
|
20
|
+
## [0.3.2]
|
|
21
|
+
|
|
22
|
+
Raises the minimum supported Python version, expands the tested versions,
|
|
23
|
+
and centralizes the package version.
|
|
24
|
+
|
|
25
|
+
### Added
|
|
26
|
+
|
|
27
|
+
- `ramtable.__version__` exposes the installed distribution version, read
|
|
28
|
+
from package metadata.
|
|
29
|
+
|
|
30
|
+
### Changed
|
|
31
|
+
|
|
32
|
+
- Python 3.11 or later is now required; support for Python 3.10 was removed.
|
|
33
|
+
- Added Python 3.14 and 3.15 to the test matrix and package classifiers.
|
|
34
|
+
- `pyproject.toml` is the single source of truth for the version; the README
|
|
35
|
+
uses a dynamic PyPI badge instead of a hardcoded number.
|
|
36
|
+
|
|
6
37
|
## [0.3.1]
|
|
7
38
|
|
|
8
39
|
Publishes RAMTable to the official PyPI index alongside TestPyPI.
|
|
@@ -19,7 +50,6 @@ Publishes RAMTable to the official PyPI index alongside TestPyPI.
|
|
|
19
50
|
|
|
20
51
|
- Installation documentation covers stable releases from PyPI and
|
|
21
52
|
pre-releases from TestPyPI.
|
|
22
|
-
- `pyproject.toml` reports version `0.3.1rc0`.
|
|
23
53
|
|
|
24
54
|
## [0.3.0]
|
|
25
55
|
|
|
@@ -0,0 +1,281 @@
|
|
|
1
|
+
# Contributing to RAMTable
|
|
2
|
+
|
|
3
|
+
Thank you for considering a contribution to RAMTable. Bug fixes,
|
|
4
|
+
documentation improvements, tests, refactorings, performance work, and
|
|
5
|
+
approved new features are all welcome. This guide explains how the project is
|
|
6
|
+
maintained and how to prepare a contribution that is easy to review.
|
|
7
|
+
|
|
8
|
+
## Contents
|
|
9
|
+
|
|
10
|
+
- [Ways to contribute](#ways-to-contribute)
|
|
11
|
+
- [New features require approval](#new-features-require-approval)
|
|
12
|
+
- [Maintenance and review expectations](#maintenance-and-review-expectations)
|
|
13
|
+
- [Branch workflow](#branch-workflow)
|
|
14
|
+
- [Development setup](#development-setup)
|
|
15
|
+
- [Checks, testing, and supported Python versions](#checks-testing-and-supported-python-versions)
|
|
16
|
+
- [Code style and documentation](#code-style-and-documentation)
|
|
17
|
+
- [Changelog and versioning](#changelog-and-versioning)
|
|
18
|
+
- [Pull request guidelines](#pull-request-guidelines)
|
|
19
|
+
- [Reporting bugs](#reporting-bugs)
|
|
20
|
+
- [License](#license)
|
|
21
|
+
|
|
22
|
+
## Ways to contribute
|
|
23
|
+
|
|
24
|
+
Contributions of all sizes are appreciated:
|
|
25
|
+
|
|
26
|
+
- bug fixes;
|
|
27
|
+
- documentation improvements;
|
|
28
|
+
- tests and test coverage;
|
|
29
|
+
- code refactoring;
|
|
30
|
+
- performance improvements;
|
|
31
|
+
- new features, after prior approval;
|
|
32
|
+
- other improvements that fit the project's goals.
|
|
33
|
+
|
|
34
|
+
## New features require approval
|
|
35
|
+
|
|
36
|
+
To keep the project's direction coherent and avoid work that may not fit its
|
|
37
|
+
goals, **new features must be approved before implementation**.
|
|
38
|
+
|
|
39
|
+
Before writing code for a new feature:
|
|
40
|
+
|
|
41
|
+
1. Open a GitHub Issue describing the proposed functionality.
|
|
42
|
+
2. Explain the problem it solves and why it would be useful.
|
|
43
|
+
3. Wait for a maintainer to approve the proposal.
|
|
44
|
+
|
|
45
|
+
Pull requests that introduce unapproved features may be closed without being
|
|
46
|
+
merged. If you are unsure whether your idea counts as a new feature, open an
|
|
47
|
+
Issue and ask before starting.
|
|
48
|
+
|
|
49
|
+
Small fixes, documentation updates, and refactorings that do not change
|
|
50
|
+
behavior do not need prior approval.
|
|
51
|
+
|
|
52
|
+
## Maintenance and review expectations
|
|
53
|
+
|
|
54
|
+
**RAMTable is currently maintained by a single developer.** There is no
|
|
55
|
+
dedicated team handling Issues or reviewing pull requests.
|
|
56
|
+
|
|
57
|
+
As a result:
|
|
58
|
+
|
|
59
|
+
- Issue responses may take some time.
|
|
60
|
+
- Pull request reviews may be delayed.
|
|
61
|
+
- A contribution may remain pending for a while before receiving feedback.
|
|
62
|
+
- Immediate responses and merges should not be expected.
|
|
63
|
+
- The maintainer reviews contributions as time and availability allow.
|
|
64
|
+
|
|
65
|
+
This does not mean contributions are unwelcome. Every report and pull request
|
|
66
|
+
is appreciated, and a polite follow-up after a reasonable waiting period is
|
|
67
|
+
fine. Clear, focused contributions are easier to review and more likely to
|
|
68
|
+
move forward.
|
|
69
|
+
|
|
70
|
+
## Branch workflow
|
|
71
|
+
|
|
72
|
+
The development branch is **`dev`**. Open contributions as pull requests
|
|
73
|
+
against `dev`.
|
|
74
|
+
|
|
75
|
+
Maintainers promote releases through the permanent branches:
|
|
76
|
+
|
|
77
|
+
```text
|
|
78
|
+
dev → test_pypi → main
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
`test_pypi` and `main` are release branches. Unless a maintainer asks you
|
|
82
|
+
otherwise, do not open contribution pull requests against them.
|
|
83
|
+
|
|
84
|
+
Create a branch from an up-to-date `dev` and use one of these prefixes:
|
|
85
|
+
|
|
86
|
+
| Prefix | Purpose | Example |
|
|
87
|
+
|---|---|---|
|
|
88
|
+
| `feat/` | New features approved through an Issue | `feat/bulk-insert` |
|
|
89
|
+
| `fix/` | Bug fixes | `fix/column-validation` |
|
|
90
|
+
| `docs/` | Documentation changes | `docs/api-reference` |
|
|
91
|
+
| `refactor/` | Code refactoring | `refactor/row-storage` |
|
|
92
|
+
| `test/` | Test-related changes | `test/column-edge-cases` |
|
|
93
|
+
|
|
94
|
+
For example:
|
|
95
|
+
|
|
96
|
+
```bash
|
|
97
|
+
git switch dev
|
|
98
|
+
git pull upstream dev
|
|
99
|
+
git switch -c fix/column-validation
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
These commands assume the `upstream` remote added in
|
|
103
|
+
[Development setup](#development-setup).
|
|
104
|
+
|
|
105
|
+
## Development setup
|
|
106
|
+
|
|
107
|
+
RAMTable requires **Python 3.11 or later**.
|
|
108
|
+
|
|
109
|
+
1. Fork the repository on GitHub.
|
|
110
|
+
2. Clone your fork and add the upstream repository:
|
|
111
|
+
|
|
112
|
+
```bash
|
|
113
|
+
git clone https://github.com/<your-user>/ramtable_py.git
|
|
114
|
+
cd ramtable_py
|
|
115
|
+
git remote add upstream https://github.com/thiagostilo2121/ramtable_py.git
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
3. Create and activate a virtual environment:
|
|
119
|
+
|
|
120
|
+
```bash
|
|
121
|
+
python3 -m venv .venv
|
|
122
|
+
source .venv/bin/activate
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
On Windows, use `python` instead of `python3` and activate with:
|
|
126
|
+
|
|
127
|
+
```powershell
|
|
128
|
+
.venv\Scripts\activate
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
4. Install the project in editable mode:
|
|
132
|
+
|
|
133
|
+
```bash
|
|
134
|
+
python -m pip install --upgrade pip
|
|
135
|
+
python -m pip install --editable .
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
RAMTable has no runtime dependencies, and the repository does not define
|
|
139
|
+
development dependencies or extras. If you need to build distributions, install
|
|
140
|
+
the build tools separately:
|
|
141
|
+
|
|
142
|
+
```bash
|
|
143
|
+
python -m pip install build twine
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
## Checks, testing, and supported Python versions
|
|
147
|
+
|
|
148
|
+
The repository does not currently include an automated test suite, and no
|
|
149
|
+
linter, formatter, or static type checker is configured. Contributions should
|
|
150
|
+
still be verified locally.
|
|
151
|
+
|
|
152
|
+
The CI workflow installs the package, byte-compiles it, and checks the public
|
|
153
|
+
imports. You can run the same checks from the repository root:
|
|
154
|
+
|
|
155
|
+
```bash
|
|
156
|
+
python -m compileall -q src/ramtable
|
|
157
|
+
python -c "from ramtable import Columns, Rows, Table"
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
If you build distributions, validate them with:
|
|
161
|
+
|
|
162
|
+
```bash
|
|
163
|
+
python -m build
|
|
164
|
+
python -m twine check dist/*
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
GitHub Actions runs these checks on Python **3.11, 3.12, 3.13, 3.14, and
|
|
168
|
+
3.15** for pushes to `dev` and for pull requests targeting `dev`, `test_pypi`,
|
|
169
|
+
and `main`. Pull requests targeting `test_pypi` and `main` also run the
|
|
170
|
+
release validation and build; publication happens only after a pull request is
|
|
171
|
+
merged. Keep every change compatible with all supported versions.
|
|
172
|
+
|
|
173
|
+
### What to test
|
|
174
|
+
|
|
175
|
+
- **Bug fixes:** include a regression test that fails before the fix and
|
|
176
|
+
passes afterwards, once a test framework is available. Until then, describe
|
|
177
|
+
the reproduction steps and the verification you performed in the pull
|
|
178
|
+
request.
|
|
179
|
+
- **New functionality:** include tests with the implementation. Because the
|
|
180
|
+
project does not yet have a configured test framework, discuss the proposed
|
|
181
|
+
testing approach in the feature Issue first.
|
|
182
|
+
- **Documentation and refactorings:** confirm that the existing examples and
|
|
183
|
+
public imports still work.
|
|
184
|
+
|
|
185
|
+
Do not claim that a check is passing if you did not run it.
|
|
186
|
+
|
|
187
|
+
## Code style and documentation
|
|
188
|
+
|
|
189
|
+
Follow the style and structure already used in `src/ramtable`:
|
|
190
|
+
|
|
191
|
+
- use four-space indentation and keep lines close to 79 characters;
|
|
192
|
+
- add type hints to functions and methods;
|
|
193
|
+
- write docstrings in the existing style, with `Args`, `Returns`, and
|
|
194
|
+
`Raises` sections where applicable;
|
|
195
|
+
- raise standard exceptions with clear messages, such as `ValueError`,
|
|
196
|
+
`TypeError`, or `IndexError`;
|
|
197
|
+
- preserve the library's validate-then-write behavior: validate a request
|
|
198
|
+
completely before modifying stored rows;
|
|
199
|
+
- keep the public API consistent, and expose new public symbols through
|
|
200
|
+
`src/ramtable/__init__.py` and `__all__`;
|
|
201
|
+
- avoid adding runtime dependencies unless they are discussed and approved in
|
|
202
|
+
an Issue;
|
|
203
|
+
- keep changes focused on the problem described in the Issue or pull request.
|
|
204
|
+
|
|
205
|
+
When behavior changes, update the relevant documentation in `docs/`:
|
|
206
|
+
|
|
207
|
+
- `docs/guide.md` for user-facing workflows;
|
|
208
|
+
- `docs/api.md` for signatures, arguments, returns, and exceptions;
|
|
209
|
+
- `docs/types-and-validation.md` for validation rules.
|
|
210
|
+
|
|
211
|
+
The repository history uses Conventional Commits-style messages, such as
|
|
212
|
+
`fix: ...`, `docs: ...`, and `feat: ...`. Following that style is appreciated,
|
|
213
|
+
but clear and descriptive commit messages matter most.
|
|
214
|
+
|
|
215
|
+
## Changelog and versioning
|
|
216
|
+
|
|
217
|
+
`CHANGELOG.md` records notable changes under version headings, with sections
|
|
218
|
+
such as `Added`, `Changed`, and `Fixed`. User-visible changes should be
|
|
219
|
+
reflected there when appropriate. Internal refactorings and trivial changes do
|
|
220
|
+
not need an entry. If you are unsure, mention the change in your pull request
|
|
221
|
+
and ask.
|
|
222
|
+
|
|
223
|
+
Do not modify `project.version` in `pyproject.toml`, create release headings,
|
|
224
|
+
or hardcode the current version in the README or documentation.
|
|
225
|
+
`pyproject.toml` is the single source of truth for the version, and version
|
|
226
|
+
bumps are part of the maintainer's release process.
|
|
227
|
+
|
|
228
|
+
## Pull request guidelines
|
|
229
|
+
|
|
230
|
+
Pull requests should:
|
|
231
|
+
|
|
232
|
+
- have a clear, descriptive title;
|
|
233
|
+
- explain what changed and why;
|
|
234
|
+
- reference the related Issue when one exists;
|
|
235
|
+
- include tests for relevant changes, following the guidance above;
|
|
236
|
+
- update documentation when behavior or the public API changes;
|
|
237
|
+
- avoid unrelated changes;
|
|
238
|
+
- stay focused and reasonably small whenever possible.
|
|
239
|
+
|
|
240
|
+
For a new feature, link the Issue where the feature was approved. Pull
|
|
241
|
+
requests without that approval may be closed.
|
|
242
|
+
|
|
243
|
+
Opening a pull request does not guarantee acceptance or an immediate review.
|
|
244
|
+
The maintainer may request changes, ask for the branch to be updated, or
|
|
245
|
+
decide that a contribution does not fit the project's direction.
|
|
246
|
+
|
|
247
|
+
Before opening a pull request:
|
|
248
|
+
|
|
249
|
+
```bash
|
|
250
|
+
git fetch upstream
|
|
251
|
+
git switch dev
|
|
252
|
+
git pull upstream dev
|
|
253
|
+
git switch your-branch-name
|
|
254
|
+
git rebase upstream/dev
|
|
255
|
+
```
|
|
256
|
+
|
|
257
|
+
Then run the checks described above and make sure the diff contains only the
|
|
258
|
+
intended changes.
|
|
259
|
+
|
|
260
|
+
## Reporting bugs
|
|
261
|
+
|
|
262
|
+
When reporting a bug, include:
|
|
263
|
+
|
|
264
|
+
- the RAMTable version:
|
|
265
|
+
|
|
266
|
+
```bash
|
|
267
|
+
python -c "import ramtable; print(ramtable.__version__)"
|
|
268
|
+
```
|
|
269
|
+
|
|
270
|
+
- your Python version and operating system;
|
|
271
|
+
- a minimal, reproducible example;
|
|
272
|
+
- the expected result and the actual result;
|
|
273
|
+
- the complete traceback, if one was raised.
|
|
274
|
+
|
|
275
|
+
Search existing Issues first to avoid duplicates.
|
|
276
|
+
|
|
277
|
+
## License
|
|
278
|
+
|
|
279
|
+
RAMTable is released under the MIT License. See [LICENSE](LICENSE) for the
|
|
280
|
+
full text. By contributing, you agree that your contributions may be
|
|
281
|
+
distributed under the same license.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
Metadata-Version: 2.5
|
|
2
2
|
Name: ramtable
|
|
3
|
-
Version: 0.3.
|
|
3
|
+
Version: 0.3.3
|
|
4
4
|
Summary: A lightweight in-memory table library for Python.
|
|
5
5
|
Author: Thiago Valentín Stilo Limarino
|
|
6
6
|
License-Expression: MIT
|
|
@@ -10,19 +10,20 @@ Classifier: Development Status :: 3 - Alpha
|
|
|
10
10
|
Classifier: Intended Audience :: Developers
|
|
11
11
|
Classifier: License :: OSI Approved :: MIT License
|
|
12
12
|
Classifier: Programming Language :: Python :: 3
|
|
13
|
-
Classifier: Programming Language :: Python :: 3.10
|
|
14
13
|
Classifier: Programming Language :: Python :: 3.11
|
|
15
14
|
Classifier: Programming Language :: Python :: 3.12
|
|
16
15
|
Classifier: Programming Language :: Python :: 3.13
|
|
17
|
-
|
|
16
|
+
Classifier: Programming Language :: Python :: 3.14
|
|
17
|
+
Classifier: Programming Language :: Python :: 3.15
|
|
18
|
+
Requires-Python: >=3.11
|
|
18
19
|
Description-Content-Type: text/markdown
|
|
19
20
|
|
|
20
21
|
# RAMTable
|
|
21
22
|
|
|
22
|
-

|
|
23
24
|

|
|
24
|
-
[](https://pypi.org/project/ramtable/)
|
|
26
|
+
[](https://test.pypi.org/project/ramtable/)
|
|
26
27
|
|
|
27
28
|
RAMTable provides typed in-memory tables for data that only needs to live
|
|
28
29
|
while a program is running. It gives records an explicit schema and common
|
|
@@ -62,7 +63,7 @@ temporary storage, not analytics.
|
|
|
62
63
|
|
|
63
64
|
## Installation
|
|
64
65
|
|
|
65
|
-
RAMTable requires Python 3.
|
|
66
|
+
RAMTable requires Python 3.11 or later.
|
|
66
67
|
|
|
67
68
|
Install the latest stable release from PyPI:
|
|
68
69
|
|
|
@@ -218,10 +219,12 @@ writes to disk: records disappear when the process ends.
|
|
|
218
219
|
|
|
219
220
|
## Project status
|
|
220
221
|
|
|
221
|
-
|
|
222
|
-
|
|
222
|
+
RAMTable is published as `ramtable` on
|
|
223
|
+
[PyPI](https://pypi.org/project/ramtable/) and
|
|
223
224
|
[TestPyPI](https://test.pypi.org/project/ramtable/). Use PyPI for stable
|
|
224
|
-
releases and TestPyPI to try release candidates and other pre-releases.
|
|
225
|
+
releases and TestPyPI to try release candidates and other pre-releases. The
|
|
226
|
+
PyPI badge above shows the latest published version; the
|
|
227
|
+
[CHANGELOG](CHANGELOG.md) records the full release history.
|
|
225
228
|
|
|
226
229
|
The project is at an early stage and will continue to evolve. See the
|
|
227
230
|
[CHANGELOG](CHANGELOG.md) for release history.
|
|
@@ -1,9 +1,9 @@
|
|
|
1
1
|
# RAMTable
|
|
2
2
|
|
|
3
|
-

|
|
4
4
|

|
|
5
|
-
[](https://pypi.org/project/ramtable/)
|
|
6
|
+
[](https://test.pypi.org/project/ramtable/)
|
|
7
7
|
|
|
8
8
|
RAMTable provides typed in-memory tables for data that only needs to live
|
|
9
9
|
while a program is running. It gives records an explicit schema and common
|
|
@@ -43,7 +43,7 @@ temporary storage, not analytics.
|
|
|
43
43
|
|
|
44
44
|
## Installation
|
|
45
45
|
|
|
46
|
-
RAMTable requires Python 3.
|
|
46
|
+
RAMTable requires Python 3.11 or later.
|
|
47
47
|
|
|
48
48
|
Install the latest stable release from PyPI:
|
|
49
49
|
|
|
@@ -199,10 +199,12 @@ writes to disk: records disappear when the process ends.
|
|
|
199
199
|
|
|
200
200
|
## Project status
|
|
201
201
|
|
|
202
|
-
|
|
203
|
-
|
|
202
|
+
RAMTable is published as `ramtable` on
|
|
203
|
+
[PyPI](https://pypi.org/project/ramtable/) and
|
|
204
204
|
[TestPyPI](https://test.pypi.org/project/ramtable/). Use PyPI for stable
|
|
205
|
-
releases and TestPyPI to try release candidates and other pre-releases.
|
|
205
|
+
releases and TestPyPI to try release candidates and other pre-releases. The
|
|
206
|
+
PyPI badge above shows the latest published version; the
|
|
207
|
+
[CHANGELOG](CHANGELOG.md) records the full release history.
|
|
206
208
|
|
|
207
209
|
The project is at an early stage and will continue to evolve. See the
|
|
208
210
|
[CHANGELOG](CHANGELOG.md) for release history.
|
|
@@ -1,11 +1,12 @@
|
|
|
1
1
|
# API reference
|
|
2
2
|
|
|
3
3
|
This reference covers every public symbol RAMTable exposes: the `Table`,
|
|
4
|
-
`Columns`, and `Rows` classes,
|
|
5
|
-
example-driven introduction, read the
|
|
4
|
+
`Columns`, and `Rows` classes, the optional `TypeValidator`, and the package
|
|
5
|
+
version. For an example-driven introduction, read the
|
|
6
|
+
[user guide](guide.md) first.
|
|
6
7
|
|
|
7
8
|
```python
|
|
8
|
-
from ramtable import Columns, Rows, Table
|
|
9
|
+
from ramtable import Columns, Rows, Table, __version__
|
|
9
10
|
from ramtable.types import TypeValidator
|
|
10
11
|
```
|
|
11
12
|
|
|
@@ -18,9 +19,21 @@ In normal use you only create a `Table`; it constructs the coordinated
|
|
|
18
19
|
- [`Columns`](#columns)
|
|
19
20
|
- [`Rows`](#rows)
|
|
20
21
|
- [`TypeValidator`](#typevalidator)
|
|
22
|
+
- [Package version](#package-version)
|
|
21
23
|
- [Internal helpers](#internal-helpers)
|
|
22
24
|
- [Copying behavior](#copying-behavior)
|
|
23
25
|
|
|
26
|
+
## Package version
|
|
27
|
+
|
|
28
|
+
```python
|
|
29
|
+
from ramtable import __version__
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
`__version__` is the version of the installed distribution, read from its
|
|
33
|
+
package metadata. It matches `project.version` in `pyproject.toml` and the
|
|
34
|
+
artifact built from it. In a source checkout that has not been installed,
|
|
35
|
+
it is `"0+unknown"`.
|
|
36
|
+
|
|
24
37
|
## `Table`
|
|
25
38
|
|
|
26
39
|
```python
|
|
@@ -47,7 +47,7 @@ how to prepare a release. It does not change or extend the RAMTable API.
|
|
|
47
47
|
|
|
48
48
|
## Set up a local environment
|
|
49
49
|
|
|
50
|
-
Python 3.
|
|
50
|
+
Python 3.11 or later is required. Install the project in editable mode:
|
|
51
51
|
|
|
52
52
|
```bash
|
|
53
53
|
python -m pip install --editable .
|
|
@@ -91,7 +91,7 @@ the branch:
|
|
|
91
91
|
|
|
92
92
|
| Branch | Version form | Example | Published to |
|
|
93
93
|
|---|---|---|---|
|
|
94
|
-
| `dev` | `X.Y.Z.devN` | `0.3.
|
|
94
|
+
| `dev` | `X.Y.Z.devN` | `0.3.2.dev0` | nothing |
|
|
95
95
|
| `test_pypi` | `X.Y.ZrcN` or `X.Y.Z` | `0.3.1rc0`, `0.3.1` | TestPyPI |
|
|
96
96
|
| `main` | `X.Y.Z` | `0.3.1` | PyPI |
|
|
97
97
|
|
|
@@ -101,15 +101,24 @@ the branch:
|
|
|
101
101
|
- `MINOR` for compatible functionality;
|
|
102
102
|
- `MAJOR` for breaking API or behavior changes.
|
|
103
103
|
|
|
104
|
+
`pyproject.toml` is the single source of truth for the current version. The
|
|
105
|
+
build backend reads it, the GitHub Actions workflows read it, and the
|
|
106
|
+
installed package exposes it as `ramtable.__version__` through its
|
|
107
|
+
distribution metadata. The README uses a dynamic PyPI badge instead of a
|
|
108
|
+
hardcoded number. `CHANGELOG.md` is the only other file with version
|
|
109
|
+
numbers, because it is a historical record of releases.
|
|
110
|
+
|
|
104
111
|
Development versions are never published. TestPyPI accepts release
|
|
105
112
|
candidates and stable versions, so the final stable release can be tested
|
|
106
113
|
there before it reaches PyPI. PyPI accepts stable versions only.
|
|
107
114
|
|
|
108
115
|
## Preparing a release
|
|
109
116
|
|
|
110
|
-
1. On `dev`, update `project.version` in `pyproject.toml
|
|
111
|
-
|
|
112
|
-
|
|
117
|
+
1. On `dev`, update `project.version` in `pyproject.toml`. This is the only
|
|
118
|
+
place where the current version is defined. Add the corresponding
|
|
119
|
+
section to `CHANGELOG.md`.
|
|
120
|
+
2. Check that the README and documentation describe current behavior. The
|
|
121
|
+
README must not contain a hardcoded version.
|
|
113
122
|
3. Run the example and all available build/test checks.
|
|
114
123
|
4. Build and inspect the wheel and source distribution.
|
|
115
124
|
5. Open a pull request from `dev` to `test_pypi`. The pull request validates
|
|
@@ -4,10 +4,10 @@ build-backend = "hatchling.build"
|
|
|
4
4
|
|
|
5
5
|
[project]
|
|
6
6
|
name = "ramtable"
|
|
7
|
-
version = "0.3.
|
|
7
|
+
version = "0.3.3"
|
|
8
8
|
description = "A lightweight in-memory table library for Python."
|
|
9
9
|
readme = "README.md"
|
|
10
|
-
requires-python = ">=3.
|
|
10
|
+
requires-python = ">=3.11"
|
|
11
11
|
license = "MIT"
|
|
12
12
|
authors = [
|
|
13
13
|
{ name = "Thiago Valentín Stilo Limarino" }
|
|
@@ -22,10 +22,11 @@ classifiers = [
|
|
|
22
22
|
"Development Status :: 3 - Alpha",
|
|
23
23
|
"Intended Audience :: Developers",
|
|
24
24
|
"Programming Language :: Python :: 3",
|
|
25
|
-
"Programming Language :: Python :: 3.10",
|
|
26
25
|
"Programming Language :: Python :: 3.11",
|
|
27
26
|
"Programming Language :: Python :: 3.12",
|
|
28
27
|
"Programming Language :: Python :: 3.13",
|
|
28
|
+
"Programming Language :: Python :: 3.14",
|
|
29
|
+
"Programming Language :: Python :: 3.15",
|
|
29
30
|
"License :: OSI Approved :: MIT License",
|
|
30
31
|
]
|
|
31
32
|
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
"""Public RAMTable API.
|
|
2
|
+
|
|
3
|
+
Expose :class:`Columns`, :class:`Rows`, and :class:`Table` from the
|
|
4
|
+
``ramtable`` package as a concise, stable import path, along with the
|
|
5
|
+
installed package version.
|
|
6
|
+
"""
|
|
7
|
+
|
|
8
|
+
from importlib.metadata import PackageNotFoundError, version
|
|
9
|
+
|
|
10
|
+
from .columns import Columns
|
|
11
|
+
from .rows import Rows
|
|
12
|
+
from .table import Table
|
|
13
|
+
|
|
14
|
+
try:
|
|
15
|
+
__version__ = version("ramtable")
|
|
16
|
+
except PackageNotFoundError: # pragma: no cover - source checkout without install
|
|
17
|
+
__version__ = "0+unknown"
|
|
18
|
+
|
|
19
|
+
__all__ = [
|
|
20
|
+
"__version__",
|
|
21
|
+
"Columns",
|
|
22
|
+
"Rows",
|
|
23
|
+
"Table",
|
|
24
|
+
]
|
|
@@ -286,7 +286,7 @@ class Rows:
|
|
|
286
286
|
"""Remove all rows without changing the schema."""
|
|
287
287
|
self._storage.clear()
|
|
288
288
|
|
|
289
|
-
def get(self, *
|
|
289
|
+
def get(self, *indexes: int) -> list[dict[str, Any]]:
|
|
290
290
|
"""Return all rows or copies of the requested positions.
|
|
291
291
|
|
|
292
292
|
With no arguments, return all rows. Indexes support negative values as
|
|
@@ -298,14 +298,14 @@ class Rows:
|
|
|
298
298
|
IndexError: If an index is out of range.
|
|
299
299
|
"""
|
|
300
300
|
|
|
301
|
-
if not
|
|
301
|
+
if not indexes:
|
|
302
302
|
return self.get_all()
|
|
303
303
|
|
|
304
304
|
selected = []
|
|
305
305
|
|
|
306
|
-
for index in
|
|
306
|
+
for index in indexes:
|
|
307
307
|
if isinstance(index, bool) or not isinstance(index, int):
|
|
308
|
-
raise TypeError("Row
|
|
308
|
+
raise TypeError("Row indexes must be integers.")
|
|
309
309
|
|
|
310
310
|
try:
|
|
311
311
|
selected.append(self._storage[index].copy())
|
|
@@ -1,15 +0,0 @@
|
|
|
1
|
-
"""Public RAMTable API.
|
|
2
|
-
|
|
3
|
-
Expose :class:`Columns`, :class:`Rows`, and :class:`Table` from the
|
|
4
|
-
``ramtable`` package as a concise, stable import path.
|
|
5
|
-
"""
|
|
6
|
-
|
|
7
|
-
from .columns import Columns
|
|
8
|
-
from .rows import Rows
|
|
9
|
-
from .table import Table
|
|
10
|
-
|
|
11
|
-
__all__ = [
|
|
12
|
-
"Columns",
|
|
13
|
-
"Rows",
|
|
14
|
-
"Table",
|
|
15
|
-
]
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|