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.

Sign up for GitHub

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

Jump to bottom

RecordComponent.shape should return a tuple #808

Open
ChristopherMayes opened this issue Oct 29, 2020 · 0 comments
Open

RecordComponent.shape should return a tuple #808

ChristopherMayes opened this issue Oct 29, 2020 · 0 comments
Assignees
@ax3l
Labels
affects latest release api: breaking breaking API changes bug frontend: Python3

Comments

@ChristopherMayes
Copy link

ChristopherMayes commented Oct 29, 2020 •
edited by ax3l
Loading

Describe the bug
From the examples/2_read_serial.py, E_x.shape is returned as a list.
The equivalent np.array API returns a tuple here.

To Reproduce
Run the examples/2_read_serial.py example

Python:

import openpmd_api

# ...
@ax3l ax3l self-assigned this Oct 29, 2020
@ax3l ax3l changed the title RecordComponent should return a tuple RecordComponent.shape should return a tuple Oct 29, 2020
@ax3l ax3l added the api: breaking breaking API changes label Oct 29, 2020
@ax3l ax3l mentioned this issue Dec 24, 2020
Merged
ax3l added a commit to ComputationalRadiationPhysics/openPMD-converter-GDF that referenced this issue Jan 5, 2021
@ax3l
openPMD-api: 0.13.0
617850d 
Bump the openPMD-api dependency to the latest release.

This updated the `requirements.txt` slightly to use
[semantic versioning](https://www.python.org/dev/peps/pep-0440/#compatible-release) ([SO](https://stackoverflow.com/questions/39590187/in-requirements-txt-what-does-tilde-equals-mean)).

openPMD-api follows [semantic versioning](https://semver.org/),
thus APIs are guaranteed to be compatible for those changes:
- `0.Y.A` -> `0.Y.B`
- `X.A.*` -> `X.B.*`
- `<any>.<any>.*` -> `<any>.<any>.*`

In reality, our APIs expose breaking changes even less often and
would often not even affect this repo (e.g. we also release a C++ API
that is covered under the same SemVer). Nonetheless, I have some
ideas on my backlog that I want to improve in the Python API, a few
of them would introduce breakage
(e.g. openPMD/openPMD-api#808). Updating
the `requirements.txt` file manually with a newer major release once
it is released (or desired) will ensure stability & reproducibility.

Breaking changes are always documented in
[NEWS.rst](https://github.com/openPMD/openPMD-api/blob/dev/NEWS.rst)
that is also embedded in the the
[manual](https://openpmd-api.readthedocs.io/en/latest/install/upgrade.html).
Do not hesitate to @-me, too.

Thanks to the
[GitHub dependency resolver](https://github.com/openPMD/openPMD-api/network/dependents?package_id=UGFja2FnZS0xNzQ2MzEwODY%3D) that parses your `requirements.txt`,
I also see the dependency to this repo, which helps me to keep track
during release workflows, so I can help if need be.
@ax3l ax3l mentioned this issue Jan 5, 2021
Merged
ax3l added a commit to ax3l/openPMD-wavefront that referenced this issue Jan 5, 2021
@ax3l
openPMD-api: 0.13.0
caa7194 
Bump the openPMD-api dependency to the latest release.

This updated the `requirements.txt` slightly to use
[semantic versioning](https://www.python.org/dev/peps/pep-0440/#compatible-release) ([SO](https://stackoverflow.com/questions/39590187/in-requirements-txt-what-does-tilde-equals-mean)).

openPMD-api follows [semantic versioning](https://semver.org/),
thus APIs are guaranteed to be compatible for those changes:
- `0.Y.A` -> `0.Y.B`
- `X.A.*` -> `X.B.*`
- `<any>.<any>.*` -> `<any>.<any>.*`

In reality, our APIs expose breaking changes even less often and
would often not even affect this repo (e.g. we also release a C++ API
that is covered under the same SemVer). Nonetheless, I have some
ideas on my backlog that I want to improve in the Python API, a few
of them would introduce breakage
(e.g. openPMD/openPMD-api#808). Updating
the `requirements.txt` file manually with a newer major release once
it is released (or desired) will ensure stability & reproducibility.

Breaking changes are always documented in
[NEWS.rst](https://github.com/openPMD/openPMD-api/blob/dev/NEWS.rst)
that is also embedded in the the
[manual](https://openpmd-api.readthedocs.io/en/latest/install/upgrade.html).
Do not hesitate to @-me, too.

Thanks to the
[GitHub dependency resolver](https://github.com/openPMD/openPMD-api/network/dependents?package_id=UGFja2FnZS0xNzQ2MzEwODY%3D) that parses your `requirements.txt`,
I also see the dependency to this repo, which helps me to keep track
during release workflows, so I can help if need be.
@ax3l ax3l mentioned this issue Jan 5, 2021
Merged
ax3l added a commit to ax3l/particle_reduction that referenced this issue Jan 5, 2021
@ax3l
openPMD-api: 0.13.0
f76f4f7 
Bump the openPMD-api dependency to the latest release.

This updated the `requirements.txt` slightly to use
[semantic versioning](https://www.python.org/dev/peps/pep-0440/#compatible-release) ([SO](https://stackoverflow.com/questions/39590187/in-requirements-txt-what-does-tilde-equals-mean)).

openPMD-api follows [semantic versioning](https://semver.org/),
thus APIs are guaranteed to be compatible for those changes:
- `0.Y.A` -> `0.Y.B`
- `X.A.*` -> `X.B.*`
- `<any>.<any>.*` -> `<any>.<any>.*`

In reality, our APIs expose breaking changes even less often and
would often not even affect this repo (e.g. we also release a C++ API
that is covered under the same SemVer). Nonetheless, I have some
ideas on my backlog that I want to improve in the Python API, a few
of them would introduce breakage
(e.g. openPMD/openPMD-api#808). Updating
the `requirements.txt` file manually with a newer major release once
it is released (or desired) will ensure stability & reproducibility.

Breaking changes are always documented in
[NEWS.rst](https://github.com/openPMD/openPMD-api/blob/dev/NEWS.rst)
that is also embedded in the the
[manual](https://openpmd-api.readthedocs.io/en/latest/install/upgrade.html).
Do not hesitate to @-me, too.

Thanks to the
[GitHub dependency resolver](https://github.com/openPMD/openPMD-api/network/dependents?package_id=UGFja2FnZS0xNzQ2MzEwODY%3D) that parses your `requirements.txt`,
I also see the dependency to this repo, which helps me to keep track
during release workflows, so I can help if need be.
@ax3l ax3l mentioned this issue Jan 5, 2021
Merged
ax3l added a commit to ax3l/OASYS1-PaNOSC that referenced this issue Jan 5, 2021
@ax3l
openPMD-api: 0.13.0
ec16076 
Bump the openPMD-api dependency to the latest release.

This updated the `requirements.txt` slightly to use
[semantic versioning](https://www.python.org/dev/peps/pep-0440/#compatible-release) ([SO](https://stackoverflow.com/questions/39590187/in-requirements-txt-what-does-tilde-equals-mean)).

openPMD-api follows [semantic versioning](https://semver.org/),
thus APIs are guaranteed to be compatible for those changes:
- `0.Y.A` -> `0.Y.B`
- `X.A.*` -> `X.B.*`
- `<any>.<any>.*` -> `<any>.<any>.*`

In reality, our APIs expose breaking changes even less often and
would often not even affect this repo (e.g. we also release a C++ API
that is covered under the same SemVer). Nonetheless, I have some
ideas on my backlog that I want to improve in the Python API, a few
of them would introduce breakage
(e.g. openPMD/openPMD-api#808). Updating
the `requirements.txt` file manually with a newer major release once
it is released (or desired) will ensure stability & reproducibility.

Breaking changes are always documented in
[NEWS.rst](https://github.com/openPMD/openPMD-api/blob/dev/NEWS.rst)
that is also embedded in the the
[manual](https://openpmd-api.readthedocs.io/en/latest/install/upgrade.html).
Do not hesitate to @-me, too.

Thanks to the
[GitHub dependency resolver](https://github.com/openPMD/openPMD-api/network/dependents?package_id=UGFja2FnZS0xNzQ2MzEwODY%3D) that parses your `requirements.txt`,
I also see the dependency to this repo, which helps me to keep track
during release workflows, so I can help if need be.
@ax3l ax3l mentioned this issue Jan 5, 2021
Merged
ax3l added a commit to ax3l/simex_platform that referenced this issue Jan 5, 2021
@ax3l
openPMD-api: 0.13.0
8cfe1f3 
Bump the openPMD-api dependency to the latest release.

This updated the `requirements.txt` slightly to use
[semantic versioning](https://www.python.org/dev/peps/pep-0440/#compatible-release) ([SO](https://stackoverflow.com/questions/39590187/in-requirements-txt-what-does-tilde-equals-mean)).

openPMD-api follows [semantic versioning](https://semver.org/),
thus APIs are guaranteed to be compatible for those changes:
- `0.Y.A` -> `0.Y.B`
- `X.A.*` -> `X.B.*`
- `<any>.<any>.*` -> `<any>.<any>.*`

In reality, our APIs expose breaking changes even less often and
would often not even affect this repo (e.g. we also release a C++ API
that is covered under the same SemVer). Nonetheless, I have some
ideas on my backlog that I want to improve in the Python API, a few
of them would introduce breakage
(e.g. openPMD/openPMD-api#808). Updating
the `requirements.txt` file manually with a newer major release once
it is released (or desired) will ensure stability & reproducibility.

Breaking changes are always documented in
[NEWS.rst](https://github.com/openPMD/openPMD-api/blob/dev/NEWS.rst)
that is also embedded in the the
[manual](https://openpmd-api.readthedocs.io/en/latest/install/upgrade.html).
Do not hesitate to @-me, too.

Thanks to the
[GitHub dependency resolver](https://github.com/openPMD/openPMD-api/network/dependents?package_id=UGFja2FnZS0xNzQ2MzEwODY%3D) that parses your `requirements.txt`,
I also see the dependency to this repo, which helps me to keep track
during release workflows, so I can help if need be.
@ax3l ax3l mentioned this issue Jan 5, 2021
Merged
ax3l added a commit to ax3l/PaNOSC-ViNYL-SimEx that referenced this issue Jan 5, 2021
@ax3l
openPMD-api: 0.13.0
508c593 
Bump the openPMD-api dependency to the latest release.

This updated the `requirements.txt` slightly to use
[semantic versioning](https://www.python.org/dev/peps/pep-0440/#compatible-release) ([SO](https://stackoverflow.com/questions/39590187/in-requirements-txt-what-does-tilde-equals-mean)).

openPMD-api follows [semantic versioning](https://semver.org/),
thus APIs are guaranteed to be compatible for those changes:
- `0.Y.A` -> `0.Y.B`
- `X.A.*` -> `X.B.*`
- `<any>.<any>.*` -> `<any>.<any>.*`

In reality, our APIs expose breaking changes even less often and
would often not even affect this repo (e.g. we also release a C++ API
that is covered under the same SemVer). Nonetheless, I have some
ideas on my backlog that I want to improve in the Python API, a few
of them would introduce breakage
(e.g. openPMD/openPMD-api#808). Updating
the `requirements.txt` file manually with a newer major release once
it is released (or desired) will ensure stability & reproducibility.

Breaking changes are always documented in
[NEWS.rst](https://github.com/openPMD/openPMD-api/blob/dev/NEWS.rst)
that is also embedded in the the
[manual](https://openpmd-api.readthedocs.io/en/latest/install/upgrade.html).
Do not hesitate to @-me, too.

Thanks to the
[GitHub dependency resolver](https://github.com/openPMD/openPMD-api/network/dependents?package_id=UGFja2FnZS0xNzQ2MzEwODY%3D) that parses your `requirements.txt`,
I also see the dependency to this repo, which helps me to keep track
during release workflows, so I can help if need be.
@ax3l ax3l mentioned this issue Jan 5, 2021
Merged
ax3l added a commit to ax3l/OASYS1-PaNOSC that referenced this issue Aug 18, 2021
@ax3l
openPMD-api: 0.13.*, 0.14.*
37ab843 
Bump the openPMD-api dependency to the latest release.

This updated the `requirements.txt` slightly to use
[semantic versioning](https://www.python.org/dev/peps/pep-0440/#compatible-release) ([SO](https://stackoverflow.com/questions/39590187/in-requirements-txt-what-does-tilde-equals-mean)).

openPMD-api follows [semantic versioning](https://semver.org/),
thus APIs are guaranteed to be compatible for those changes:
- `0.Y.A` -> `0.Y.B`
- `X.A.*` -> `X.B.*`
- `<any>.<any>.*` -> `<any>.<any>.*`

In reality, our APIs expose breaking changes even less often and
would often not even affect this repo (e.g. we also release a C++ API
that is covered under the same SemVer). Nonetheless, I have some
ideas on my backlog that I want to improve in the Python API, a few
of them would introduce breakage
(e.g. openPMD/openPMD-api#808). Updating
the `requirements.txt` file manually with a newer major release once
it is released (or desired) will ensure stability & reproducibility.

Breaking changes are always documented in
[NEWS.rst](https://github.com/openPMD/openPMD-api/blob/dev/NEWS.rst)
that is also embedded in the the
[manual](https://openpmd-api.readthedocs.io/en/latest/install/upgrade.html).
Do not hesitate to @-me, too.

Thanks to the
[GitHub dependency resolver](https://github.com/openPMD/openPMD-api/network/dependents?package_id=UGFja2FnZS0xNzQ2MzEwODY%3D) that parses your `requirements.txt`,
I also see the dependency to this repo, which helps me to keep track
during release workflows, so I can help if need be.
ax3l added a commit to ax3l/openPMD-wavefront that referenced this issue Aug 18, 2021
@ax3l
openPMD-api: 0.13.*, 0.14.*
fe92f86 
Bump the openPMD-api dependency to the latest release.

This updated the `requirements.txt` slightly to use
[semantic versioning](https://www.python.org/dev/peps/pep-0440/#compatible-release) ([SO](https://stackoverflow.com/questions/39590187/in-requirements-txt-what-does-tilde-equals-mean)).

openPMD-api follows [semantic versioning](https://semver.org/),
thus APIs are guaranteed to be compatible for those changes:
- `0.Y.A` -> `0.Y.B`
- `X.A.*` -> `X.B.*`
- `<any>.<any>.*` -> `<any>.<any>.*`

In reality, our APIs expose breaking changes even less often and
would often not even affect this repo (e.g. we also release a C++ API
that is covered under the same SemVer). Nonetheless, I have some
ideas on my backlog that I want to improve in the Python API, a few
of them would introduce breakage
(e.g. openPMD/openPMD-api#808). Updating
the `requirements.txt` file manually with a newer major release once
it is released (or desired) will ensure stability & reproducibility.

Breaking changes are always documented in
[NEWS.rst](https://github.com/openPMD/openPMD-api/blob/dev/NEWS.rst)
that is also embedded in the the
[manual](https://openpmd-api.readthedocs.io/en/latest/install/upgrade.html).
Do not hesitate to @-me, too.

Thanks to the
[GitHub dependency resolver](https://github.com/openPMD/openPMD-api/network/dependents?package_id=UGFja2FnZS0xNzQ2MzEwODY%3D) that parses your `requirements.txt`,
I also see the dependency to this repo, which helps me to keep track
during release workflows, so I can help if need be.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ax3l ax3l

Labels
affects latest release api: breaking breaking API changes bug frontend: Python3
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ax3l @ChristopherMayes