Got it, sounds good! On Tue, Sep 4, 2018 at 10:54 AM, Dmitry Melnichuk < dmitry.melnic...@nobitlost.com> wrote:
> 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. >>>> >>>> >>> >> >
