ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Melnichuk <dmitry.melnic...@nobitlost.com>
Subject Re: Python thin client
Date Tue, 04 Sep 2018 17:54:57 GMT

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.melnichuk@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.

View raw message