Hello Igniters, I'd like to add my ¢2 considering Python thin client.
I think we should abandon Python 3.4, which was a precondition from Ignite community when I started to work on `pyignite` a good year ago, and update the minimum requirement to at least Python 3.6, or, better yet, 3.7. Reasons to do so: 1. Python 3.4 has reached its EOL this Spring. The final build was released: March 18, 2019. PIP, setuptools, PyCharm are already dropped their support for Python 3.4. In other words, bits have started to rot. 2. Python 3.4 builds against OpenSSL 1.0, while 3.5+ − OpenSSL 1.1. If we intend to support TLS 1.3 encryption in Python thin client, we should move on from Python 3.4. 3. The most important part for me as a developer: positive changes in the language itself. To name only a few: - `dict` and `OrderedDict` types was merged within one highly-optimized C implementation, - `typing` module (type annotations support) was built into the language and significantly improved, - string interpolation (so-called “f-strings”) and data classes was introduced in 3.6. If there is at least one good reason to support Python 3.4, I would like to learn about it. Otherwise, the struggle for supporting the outdated language version seems pointless to me. On Mon, 2019-06-17 at 15:18 +0300, Alexey Goncharuk wrote: > Igniters, > > Even though we are still planning the Ignite 2.8 release, I would > like to > kick-off a discussion related to Ignite 3.0, because the efforts for > AI 3.0 > will be significantly larger than for AI 2.8, better to start early. > > As a first step, I would like to discuss the list of things to be > removed > in Ignite 3.0 (partially this thread is inspired by Denis Magda's > IGFS > removal thread). I've separated all to-be-removed points from > existing > Ignite 3.0 wishlist [1] to a dedicated block and also added a few > more > things that look right to be dropped. > > Please share your thoughts, probably, there are more outdated things > we > need to add to the wishlist. > > As a side question: I think it makes sense to create tickets for such > improvements, how do we track them. Will the 3.0 version suffice or > should > we add a separate label? > > --AG
