Dmitriy,
It would be quite messy to implement with Python modular system.
First of all, Python 2 and Python 3 are different languages with a small
common subset of syntax rules. That's why what we see in a stack trace
is a syntax error, and not a “missing feature” error.
Second, there is no single entry point in Python code. User is allowed
to import any name, from any module, in any order. In fact the module is
run when it first discovered by CPython during any `import` operation,
and that is how the imported entities are created and initialized: by
the chain of imports.
It means for us, that implementing even a simple compatibility message
in Python 2 requires any module in our program (or at least all the
modules, that represent the public API of our library) to consist
entirely of a valid Python 2 code.
It can be achieved by writing stubs with a version check, putting said
stubs in place of real modules, and proxying all the calls through the
conditional imports. It would take a small effort once, but make code
less readable and harder to maintain for the rest of its life cycle.
Should we, for example, provide two testing environments − for the main
program and for Python 2-compatible stubs?
As far as I know, no Python developer is making such efforts nowadays.
There are some projects with a long history, that achieve
2/3-compatibility through the use of restricted syntax and external
packages like `six`, or simply support two separate versions. Most of
the new projects are creating with the latest Python 3, pip and
virtualenv in mind.
I took the idea of my `setup.py` solution from the Django project, which
is dropped Python 2 support not long ago. Its setup relies on
`setuptools` 9+ option, or otherwise displays a simple banner; the
banner is likely to be buried under the further cryptic output of old
setuptools, but it is better than nothing.
On 9/5/18 2:21 AM, Dmitriy Setrakyan wrote:
Dmitriy,
setuptools sounds like an installation step. Does it make sense to add a
check during startup of a client?
D.
On Tue, Sep 4, 2018 at 7:25 AM, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:
Nikolay,
There is indeed a feature in `setuptools` I just learned about, which
would help in this case (and I believe the case you demonstrated can be
quite typical, thank you for pointing it out). It gives user a clever
message in the end of a stack trace like
UnsupportedPythonVersion: pyignite requires Python '>=3.4' but the
running Python is 2.7.15
This feature is not 100% bullet-proof, and it will not help users who will
try to install my client other way than with `pip` or `setup.py`.
It will also be less helpful with old versions of `pip` (before 9.0).
However, it should cover most situations.
On 9/4/18 7:15 PM, Nikolay Izhikov wrote:
Hello, Dmitry.
I understand that for experienced Python developer it obvious from
stack trace I send.
But can we check python version on startup? And print big fat error
message "You are using wrong python version".
From my experience, there are some tickets in Ignite that should be
implemented in various thin clients. It a very trivial changes, but
lack of testability makes this task harder then steel.
I think a .Net DEVNOTES are very good example.
Please, be gentle with your fellow contributors and make DEVNOTES as
clear as possible.
