3 ms·

> available in Rust or pure Python. Hard pass. The complexity of having to use binary packages or build things is not worth the performance benefit. The pure-P

> available in Rust or pure Python. Hard pass. The complexity of having to use binary packages or build things is not worth the performance benefit. The pure-Python version requires building from source and passing special flags, so it is not possible to specify it in requirements.txt.

stavros 2y ago
That seems like an easy fix, they could release it as `whenever[pure]`. It would probably take less time to write up the issue than to write your comment.
- Kwpolska 2y ago
  Extras only affect dependencies, you can’t have different codebases for them. An issue was closed as not planned: https://github.com/ariebovenberg/whenever/issues/158 https://github.com/ariebovenberg/whenever/issues/158
  - ariebovenberg 2y ago
    Author here. To summarize the long discussion in the issue: 1. I _love_ pure Python packages. Not everybody should be forced to use Rust. I want installing pure-Python to be as easy as possible 2. Having separate names on PyPi (with or without extras) creates confusion for libraries depending on whenever: should they depend on whenever-py or whenever-rust? If one “overwrites” the other, this adds confusion. 3. Most users expect to “pip install whenever” and start using the “fast” version For me, points (3) and (2) weigh heavy enough to make (1) slightly more cumbersome. But: Maybe I’ve missed something. Have a read in the above issue or add your 2 cents. edit: formatting
    - Kwpolska 2y ago
      1. Is the Rust version really faster enough to warrant the extra complication? Is it faster in real-life code, not only in synthetic benchmarks? 2. I would expect `pip install whenever` to give me the pure-Python version, and `pip install whenever-rust` to give me the Rust extras. Both packages can be installed at the same time; the pure-Python package detects and uses the Rust implementation if present.
      - deleted 2y ago
        [deleted]
    - sirfz 2y ago
      Maybe something like psycopg[binary], would it be possible to separate the rust binaries as an extra which would be imported if it exists (i.e. When installed with whenever[binary]) otherwise the vanilla python version is used. Not sure of the specifics tho, just throwing out an idea
OJFord 2y ago
> The pure-Python version requires building from source and passing special flags, so it is not possible to specify it in requirements.txt. You can put any flags in requirements.txt, including -r[equiring] another txt etc. Your point may apply to modern pyproject.toml tooling though, or at least that it wouldn't be simply another entry in the dependencies array.
- Kwpolska 2y ago
  The special flags are environment variables, you can’t pass that in requirements.txt: https://whenever.readthedocs.io/en/latest/faq.html#how-can-i-use-the-pure-python-version https://whenever.readthedocs.io/en/latest/faq.html#how-can-i...
BiteCode_dev 2y ago
Ah, so you are not using pyQT, numpy, any database driver, pillow or anything using cryptography, then?
- Kwpolska 2y ago
  For the libraries you listed, the benefits of using a native library are much larger, since they’re wrapping a well-known library that is known to be secure and fully-featured, or since the performance benefits are actually visible in any significant code snippet. But here, there is no Rust library to wrap, and I doubt the performance of a date-time library would have any effect on the performance of virtually all applications (maybe except for calendar apps).
  - karlicoss 2y ago
    datetime handling can absolutely be a hot spot, especially if you're parsing or formatting them. Even for relatively simple things like "parse a huge csv file with dates into dataclasses". In particular, default implementation of datetime in cpython is a C module (with a fallback to pure python one) https://github.com/python/cpython/blob/main/Modules/_datetimemodule.c https://github.com/python/cpython/blob/main/Modules/_datetim... Not saying it's necessarily justified in case of this library, but if they want to compete with stdlib datetime in terms of performance, some parts will need to be compiled.

stavros 2y ago

That seems like an easy fix, they could release it as `whenever[pure]`. It would probably take less time to write up the issue than to write your comment.

Kwpolska 2y ago
Extras only affect dependencies, you can’t have different codebases for them. An issue was closed as not planned: https://github.com/ariebovenberg/whenever/issues/158 https://github.com/ariebovenberg/whenever/issues/158
- ariebovenberg 2y ago
  Author here. To summarize the long discussion in the issue: 1. I _love_ pure Python packages. Not everybody should be forced to use Rust. I want installing pure-Python to be as easy as possible 2. Having separate names on PyPi (with or without extras) creates confusion for libraries depending on whenever: should they depend on whenever-py or whenever-rust? If one “overwrites” the other, this adds confusion. 3. Most users expect to “pip install whenever” and start using the “fast” version For me, points (3) and (2) weigh heavy enough to make (1) slightly more cumbersome. But: Maybe I’ve missed something. Have a read in the above issue or add your 2 cents. edit: formatting
  - Kwpolska 2y ago
    1. Is the Rust version really faster enough to warrant the extra complication? Is it faster in real-life code, not only in synthetic benchmarks? 2. I would expect `pip install whenever` to give me the pure-Python version, and `pip install whenever-rust` to give me the Rust extras. Both packages can be installed at the same time; the pure-Python package detects and uses the Rust implementation if present.
    - deleted 2y ago
      [deleted]
  - sirfz 2y ago
    Maybe something like psycopg[binary], would it be possible to separate the rust binaries as an extra which would be imported if it exists (i.e. When installed with whenever[binary]) otherwise the vanilla python version is used. Not sure of the specifics tho, just throwing out an idea

OJFord 2y ago

> The pure-Python version requires building from source and passing special flags, so it is not possible to specify it in requirements.txt. You can put any flags in requirements.txt, including -r[equiring] another txt etc. Your point may apply to modern pyproject.toml tooling though, or at least that it wouldn't be simply another entry in the dependencies array.

Kwpolska 2y ago
The special flags are environment variables, you can’t pass that in requirements.txt: https://whenever.readthedocs.io/en/latest/faq.html#how-can-i-use-the-pure-python-version https://whenever.readthedocs.io/en/latest/faq.html#how-can-i...

BiteCode_dev 2y ago

Ah, so you are not using pyQT, numpy, any database driver, pillow or anything using cryptography, then?

Kwpolska 2y ago
For the libraries you listed, the benefits of using a native library are much larger, since they’re wrapping a well-known library that is known to be secure and fully-featured, or since the performance benefits are actually visible in any significant code snippet. But here, there is no Rust library to wrap, and I doubt the performance of a date-time library would have any effect on the performance of virtually all applications (maybe except for calendar apps).
- karlicoss 2y ago
  datetime handling can absolutely be a hot spot, especially if you're parsing or formatting them. Even for relatively simple things like "parse a huge csv file with dates into dataclasses". In particular, default implementation of datetime in cpython is a C module (with a fallback to pure python one) https://github.com/python/cpython/blob/main/Modules/_datetimemodule.c https://github.com/python/cpython/blob/main/Modules/_datetim... Not saying it's necessarily justified in case of this library, but if they want to compete with stdlib datetime in terms of performance, some parts will need to be compiled.