Pre-discussion on PLIP - maintain Py2 support

Thank you for asking. The goal of this new PLIP is to lift off work from core developers, release teams, framework teams, admins, etc. And to make new things happen. In a natural manner. Natural manner has to do with intuition. Not everybody has the same intuition. That is why it is a good thing that Python 2 can have more than one intuitive way of doing things as compared to Python 3.

Lifting off work means creating time to make new things happen. Example: work invested in migration to Python 3 would have been put in to other things. This new PLIP is born out of my own need to be lifted of this migration work now and in to the future. I need to invest my time and energy and other resources in to other work to make my projects happen. And to make new things happen. In a natural manner.

The resources that will be invested, and the who or what will make the investment, depends on the cooperation of the Py2-supplier. The more this supplier suits the needs of Zope/Plone the more work can be lifted off from the core developers, the release teams, the framework teams, admins, etc. And the more new things can happen. In a natural manner.

There are options.

First option
The most easy way to start is for the dev-teams of Plone and Zope to report back to Python (TM) that it has to give rebirth to Python 2. Zope and Plone are after all sponsors of Python (TM).

Second option
If Python (TM) stays unwilling to take care of Python 2 and the wants and needs of its users, than Plone can team up with an existing Py 2-fork. The Py2-fork that is active on Github exists of a small group that can be joined by Plone and others. This new Py2-fork strive to be the "drop in" replacement for Python 2.7. Some distro’s are preparing to ship this Py2-fork. I would like it to be a FreeBSD-port. I do not use Redhat. And I do not use Docker. I want to have Plone on FreeBSD in a buildout.

The investments are made by volunteers who know how to maintain Py2 and Plone and those who support. First of all it seems a job for.... those who know how to. Others need to support. I am willing to do what is in my capability to make this happen. The new Py2-supplier needs to be a serious community. All the investments for that need to be made. That can be done on Github by first of all joining this new Py-2 supplier to become acquainted and figure out whether it really can be the new Py2 supplier for Plone. The quality of this Py2-supplier needs to be established by core-dev.

Resources that will be invested is work and attention for this Py2-fork. With respect to Plone Legacy security updates are needed. In the state Python 2 is in today there are not much security issues to be expected in the nearby future. With respect to Plone Current security updates and maybe extra modules and/ore imports for the ___future___ module are needed.

Plone needs to be compatible with this fork. To my knowledge this means that changes need to be made to RestrictedPython, the installer and virtualenv. This is in fact not much work for someone who knows how to. It is IMO mostly a matter of the will to make use of this new Py2-supplier and adjust some code according to that. PIP is also making efforts to support this Py2-fork. I have done tests with Plone on this Py2-fork and not everything works out of the box on this fork yet. Till now I am not able to fix these issues myself. I think that if Plone shows interest in to this new Py2-supplier others who know how to maintain Py2 will join this supplier to share the burden of maintaining the new Py2 because there is a demand for Py2. 50% of the companies using Py2 have no plan to migrate. I even would like to use some Plone 4.1 third party products for on-line production sites. The migration to Python 3 is not a free choice of the market. There is and there was reluctance to migrate to Python 3. Python (TM) forced the acceptance of Python 3 by EOL’ing Python 2.7. Killing projects that do not have the resources to follow. The big companies accepted Python 3 first. They have the resources to get a dev-team on the job.

If Python 2.7 was not EOL’ed the market share of Python 3 would have been significant less than today. The market share of Python 3 is due to the killing of Python 2. It has nothing to do with natural acceptance by the market ore with technical needs ore security necessity. The above discussion proves IMO objectively that there is no need for Python 3 because Python 2 can do the job today and in the future thanks to its modularity.

Third option
If Python (TM) stays unwilling to understand and teaming up with others for a new Py2-supplier does not work Plone can choose to maintain its own Py2-fork. The state Python 2 is in at this moment does not predict much work on this fork securitywise in the nearby future. Most work depends on the extra wants and needs of its users. Roughly calculated the maintaining of a Plone owned Py2-fork must be less work than the migration by all Plone users on all there Plone sites to Python 3 and every other Python-version next. The work done on this fork need to be compared to the work of all Plone users migrating all there Plone sites to Python 3 and its successors, for the check and balance between investment and profit. The benefits of a Plone owned Py2 fork are for instance: control, independence and the ability to use all Plone versions on one Python-stack. That can make Plone Legacy with its rich egg supply on PyPy a powerful competitor on the market without risking future development. The new Plone owned Py2-supplier keeps markets open and even can create new markets for Plone integrators and solution providers.

That is how to lift off work from the core developers, the release teams, the framework teams, admins, etc. And make Python 3 obsolete. In natural manner.

Hope this answers your questions.

.oO( :popcorn: )

4 Likes

They are both sane, I am just saying Python3 is saner.
I am also sane, so I am not going to elaborate more on this.

I would not call 19% does not seem marginal but I will not argue on that.

The price tag of this action is never the one that comes with a new server.
There are lots of other costs, which are different for different scenarios.
People can judge for themselves and for their use cases.

1 Like

There is zero need for convincing anyone of Python 3. The situation is as it is. The situation is clear for as long as eight years (since the EOL announcement of Python 2.7). The Zope & Plone community did their homework, most integrators did their homework, most customers did their homework or will do it within a reasonable timeframe. As said: if you need Python 2.7 support in the future: fork it and maintain it yourself. It's like with climate change. The oceans are rising and you are sitting like a crying boy on a little island because you are running out of time....or you come with a huge bag of money in order convince something for keeping the Python 2 support in Plone 5 or higher for the future. I guess nobody would take the money.

If I interpret the 3 options, all of them require work to be performed by Plone. To be clear, do you mean the Plone Framework Team, Plone Foundation, or Plone Community?

As you know, the Plone FWT has already made its intent clear and accepted a PLIP that drops Python 2 support.

The Foundation will use its limited resources toward the future development of Plone, and not provide legacy support beyond not deleting published packages.

There may be a few individuals in the Community who would join you in the proposal, but I think that the Community at large is aligned with both the FWT and Foundation.

I don't see a second for your proposal, and I see no support for it here. I see only opposition to and disagreement with it.

Let me say that I feel your pain. I came to Python from another language, Lasso, that went through several major iterations on the scale of Python 2 to 3. It was a commercial product. The last change from Lasso 8 to 9 caused me to abandon the language for future development because I would have had to rewrite all of my v8 code for v9. But that alone was not cause enough. The migration path had zero documentation, zero support, and the code base could not be run on both versions simultaneously. Additionally the vendor stopped issuing releases that could run on modern versions of operating systems with maintained security features, TLS being the major deal-breaker. I was not alone in my sentiment, and the majority of developers left for greener pastures starting about 10 years ago. Eventually Lasso was abandoned by the vendor. It was a long and painful death spiral. Python people have it lucky to have documentation and support for making a migration, and the ability to run the same code on two major version platforms, more than 10 years after the first Python 3 came out.

I still maintain a few public-facing legacy Lasso 8 sites on CentOS 5 and a couple more Lasso 9 on CentOS 6, and one private Lasso 9 site behind a corporate VPN. Most of my former clients have moved on to services that I do not offer, including WordPress, Weebly, and Wix. I do it all with no support whatsoever from any other entity. The only paid work I do in Lasso these days is bug fixes, no feature development. My income has shifted from 100% Lasso to 10% Lasso / 90% Python 3. None of my clients want new features developed on legacy platforms that are no longer supported. They all want products that have a future.

I had to transition my business to survive as a self-employed independent contractor. If I had not started this process 10 years ago, I would be no longer in business today. I had to learn an entirely new language and its ecosystem, and again transition from Python 2 to 3. For someone in their 40's, it was especially difficult to adapt. But the documentation, resources, and, most of all, the people were there to help me. All that is still available for Plone and Python developers who want to stay current, relevant, and competitive. The alternative is to stagnate and become obsolete.

6 Likes

@zopyx you always make me smile. The only argument you have is that the decision is made and that everybody is on the move. Do you also jump from the bridge because others do? And have you not seen that the Python Community is advertising for PHP? They have there forum on MyBB. How can a community be trusted to take care of Python -maybe the most important language today- when it uses PHP for its forum? That shows that it has no attachment to or interest in Python. Do you always buy from suppliers that not even use there own stuff? Python (TM) is infected with Python killers making propaganda for PHP.

Volunteer to team up with Tauthon and make friend there instead of dropping irrelevant statements.

I have done my homework. The Zope & Plone community and other communities did not do theirs. They should have stopped Python (TM) from EOL’ing Python 2.7. They made integrators, costumers and others do work and pay for work that is not needed at all. Without value being added. In normal terms that is called a breach of contract or a unlawful act. The EOL of Python 2.7 is based on economical grounds. It is meant to make integrators, costumers and others pay for FOSS. I do not want to advice costumers to migrate to Python 3 knowing that it is not needed at all and that Python (TM) is to lame and lazy to supply support for Python 2. I rather make costumers happy with Python 2 and make them pay for extras they want on Plone sites.

The EOL of Python 2.7 is a huge mistake. There is not one convincing objective technical or security argument that can legitimize the EOL of Python 2.7. Python 2 is not just a language. Python 2 can do everything Zope/Plone want. Fast enough and sane enough. And secure. Also future development can be done on Python 2. So just undo the mistake. Zope has this nice undo-feature. Use it.

Funny that you mention climate change to make your point. With respect to climate change most of the so called sane people make the mistake to think CO2 is the cause of climate change, making others pay for there childish failures and ruining the climate in the same time.

Again you are proving my point. The EOL of Python 2.7 is about money. It cost me a lot to migrate to Python 3. First I would like to make some money with Python 2.7. Like Big Tech did. Then I would like to pay money to devs and others to do the things on Plone Legacy I can not do myself. That is IMO the way FOSS works. With the EOL of Python 2, I keep on investing to stay mainstream. And I do not get a change to market the projects I have because I need to become a CodeMonkey first.

Proving there is no need for Python 3. And that it is known for more than 10 years.

Clients do not know that there is no need to EOL Python 2.7. They trust there contractor. If they knew about it they would sue ass of or complain at authorities. The EOL of Python 2.7 is a form of dishonest rivalry or competition in trade and commerce.

I am only saying that when it comes to speed I make other choices than to use Python 3. Faster hardware like SSD ore other processors ore more and faster memory ore better use of cache etc. Migrating Plone 4.3 to Python 3 is more expensive (in my case) than any other solution to gain speed. When I need Python 3 to gain more speed something else is terribly wrong.

Yes I know. I am just in time with this new PLIP. I did not realize before that the EOL of Python 2 is a big thing. This new PLIP and the accepted PLIP that drops Python 2 support has the same goal: to lift off work from the core developers, the release teams, the framework teams, admins, etc. This new PLIP propose an other (IMO better/lucrative) way of executing this accepted PLIP to make the goal of PLIP #2812 really work. And to make new things happen. In a natural manner. PLIP #2812 thinks it need to drop Python 2 to reach its goal. I think that maintaining Python 2 support will reach the goal of PLIP #2812 better, and make new things happen. In a natural manner. Migrating to Python 3 does not make new things happen. Migration to Python 3 means rethinking everything that is done on Python 2 and doing it over again on Python 3 without value being added. This new PLIP can lead to dropping Python 3 support to lift of even more work. Dropping Python 2 is not beneficial. Keeping Python 2 support in Plone 5 and higher for the future is IMO the best way to go. There is nothing lost with that. Dropping Python 3 does not harm future development because Python 2 has the __ future __ module and its imports.

Yes, all of the 3 options require work to be performed by -first of all- Plone. This work need to be done by those (of the Plone Framework Team, Plone Foundation, and/or Plone Community) whose job it is to watch over Python. It is there call in the first place to prevent the EOL of Python 2 from happening. Plone is sponsoring Python (TM). Maintaining Python 2 is more beneficial for the Plone Community at large than migrating to Python 3.

I do not know exactly what the capability is of everybody in the Plone Framework Team, Plone Foundation, and Plone Community. I think that I am the one in this discussion with the least technical skills. It seems to me that every of the 3 options fulfill the will to lift of work better than PLIP #2812 does. It mostly depends on the quality of the new Py2 supplier. It needs to be there for a long time, maybe for ever. And it needs to be reliable.

The preferred solution is that the Python Devs, the Python Framework Team, The Python Foundation and the Python Community accept there responsibility to undo the EOL of Python 2 and keep on maintaining Python 2 and keep on developing by way of the __future__ module and its imports and/or by way of any other (new) module. That way nothing changes and everybody can have it its way. Than I can continue using Plone Legacy without headaches. And the devs can have it there way with future development on both Plone Legacy and Plone Current. I think it will benefit the Plone community at large when customers can choose between Plone Legacy and Plone Current. Plone Legacy and Plone Current have different intuitive ways of doing things. Meaning different target audience.

I even think it will benefit the Plone community at large when security-fixes from Plone 3.5 upwards can be supplied. Seriously, Plone need to take more care of its legacy because it is pure quality that can be utilized easy.

The work that need to be done in the second and third option depends mostly on the fun devs have in maintaining a Py2-fork and the expected benefits economically and otherwise. I wish I could tell how much work it is to maintain a Py2-fork suitable for Plone and I think it is not so bad for those who know how to. I will use it right away knowing it is certified by Plone. The future is IMO Plone Legacy and Plone Current competing to be the number one Enterprise CMS. The more Plone can be utilized easy the more mainstream Plone is going to be. Maintaining Py 2 support makes the utilization of the amazing Plone and third party codebase more easy. If Plone keeps on focusing on Plone Current only, it is missing opportunities nobody wants to miss in today's business on the web. Plone Legacy is more easy to use for extended buildouts than Plone Current is. That will not change. Plone Legacy always will be more easy to utilize than Plone Current. The EOL of Python 2.7 is competing against the interests of the sponsors of Python (TM) and there users. Again proving the clumsiness of it.

So members of the Plone Framework Team, the Plone Foundation, and/ore Plone Community need to address the Python Dev Team, the Python Framework Team, the Python Foundation and the Python Community to undo the EOL of Python 2. If that does not lead to the wanted results than the other two options need to be worked out.

The Community at large and both FWT and the Foundation have right to change there minds. Everybody can make mistakes. This one can be fixed by accepting and executing this new PLIP. The EOL of Python 2.7 is IMO meant to prevent others from competing with Big Tech. And to make money out of a migration-hoax. I always upgrade to the newer versions. Migrating to Python 3 is a downgrade. Python 3 is not the next level Python. It is Python 2 without its flexibility and capability of doing things intuitively in more than one way. Think it is save to say that Python 3 is Python 2 without its 'insanity'. Do we really care about sanity and the speed of Python 3 so much that it is worth to drop Python 2 support and risk the opportunities that comes with Py 2 support?

And the Foundation also prevent others from providing legacy support because it does not oppose the EOL of Python 2.7. It agrees with the EOL of Python 2.7.

If so we maybe can start doing new things already in a natural manner to demonstrate that this PLIP really works and to make others follow.

Again, you should recognize and accept that you are on the wrong side of history. There is no way to turn back the clock. You want to be Don Quixote, fight the wind mills. You are on your own. Feel free to bring your PLIP to the framework team. The result will be a major to zero down vote. Open your eyes and face the facts. You're dream dancing.

1 Like

@zopyx The EOL of Python 2.7 is a fraud. Don't make yourself responsible for it.

Ridiculous.

Not a fraud. Just a decision made by the Python core developers and the Python inventor Guido van Rossum..file your case in some court :kissing_heart:

Time to close this discussion.

META: There are two possible solution to this thread:

  1. @Juron tricks us with his arguments and laughs about us while proofing us. The way he arguments follows 100% the agenda similar to climate-deniers, right-wing-populism or Trump/Johnson/Kickl/Höcke/... supporters.
  2. He is serious.

I am amused anyway. We should archive this thread for future social communication studies.

more :popcorn:

6 Likes

WOW. Now I am right-wing.

No, misunderstanding: you use the argumentation paths those use today. Same argumentation was used in other areas in others times by other people.

1 Like

giphy

5 Likes

:popcorn:

5 Likes

I am talking about facts. Nobody, not in this forum or anywhere else, is able to provide a solid objective convincing argument for the EOL of Python 2.7. Everybody accepts the migration-scam of Python (TM) without asking, like brain death zombies.

1 Like

You are right, Don Quixote.

The technical term is "sea-lioning".

7 Likes

Do not fool yourself and others. The technical term is fraud. It is even a kind of extortion. Do or die. People are forced to pay for migration without anybody can explain why. And without value being added. Python 3 exist because developers are lazy. It takes Python 3 more than 10 years and the EOL of the widely used Python 2 to become mainstream.

ok, it's getting boring...I imagine a red parrot repeating all over again "Python 2.7 EOL is a fraud, Python 2.7 EOL is fraud, Python 2.7 EOL is fraud"

The EOL of Python 2.7 is a fraud!