4 ms·

Mod_python has been dead for so long now that its death has gone from a liability to a potential asset. After this much time not supporting its legacy, it hardl

by SiVal 13y ago

Mod_python has been dead for so long now that its death has gone from a liability to a potential asset. After this much time not supporting its legacy, it hardly has any legacy left to support, and not having legacy baggage can be exploited as a significant advantage. I hope that if the author wants to resurrect it, he'll consider creating a new mod_python focused exclusively on the new Python. Position it that way. Make it Python 3.4 or later with no support for anything earlier so that all effort can focus on creating the world's best support for the next generation of Python web apps. Just a thought.

kkmickos 13y ago
Uhm, did you even read the article? The project is already being worked on and support for Py3 is implemented. He's reaching out looking for people to help him test it.
- willvarfar 13y ago
  That's not at odds with what the poster is saying.
- SiVal 13y ago
  Uhm, do you understand what "focused exclusively" and "no support for earlier" mean and how they differ from merely adding "Py 3 support" to a legacy product? Any resources (time, attention, research, answering user questions, design simplicity, ...) that are expended in an effort to support pre-3.4 versions and users are resources that could be turned instead to the challenge of making the 3.4+ product even better. With this approach, he could potentially, gradually, change the market's mindset from "mod_python is dead, use mod_wsgi" to "if you're still stuck with Py2, you'll have to use mod_wsgi, but if you are starting a new project, you should go with mod_python."
  - jackalope 13y ago
    Priority should be given to making mod_python compile for Apache httpd 2.4, so applications stuck on httpd 2.2/Python 2 can be migrated. This is likely to generate the strongest initial interest. Dropping support for Python 2 would interfere, especially where libraries are used that haven't been updated to work with Python 3.
    - SiVal 13y ago
      All projects have finite resources that they allocate as they see fit. You say that priority should be given to legacy upgraders for the sake of "strongest initial interest." That may well be his preference, too, and if so, the costs of doing so will be debited from available resources. It is, of course, his choice, but I'm suggesting that there is an alternative where all available resources are focused on the future, benefiting new projects at the expense of whatever remains of the legacy, going for strongest ultimate interest even at the possibility that it might not produce the strongest initial interest, and attempting to own the mindshare of "best system for new Python projects" by positioning itself exclusively as that, not positioning new Python project support a recent add-on to an old, legacy technology. It's a matter of choosing market, positioning, and resource allocation, and I'm pointing out how, with a certain choice, the market perception that "mod_python is dead" doesn't have to be a problem and could even have advantages.

by SiVal 13y ago

kkmickos 13y ago

Uhm, did you even read the article? The project is already being worked on and support for Py3 is implemented. He's reaching out looking for people to help him test it.

willvarfar 13y ago
That's not at odds with what the poster is saying.
SiVal 13y ago
Uhm, do you understand what "focused exclusively" and "no support for earlier" mean and how they differ from merely adding "Py 3 support" to a legacy product? Any resources (time, attention, research, answering user questions, design simplicity, ...) that are expended in an effort to support pre-3.4 versions and users are resources that could be turned instead to the challenge of making the 3.4+ product even better. With this approach, he could potentially, gradually, change the market's mindset from "mod_python is dead, use mod_wsgi" to "if you're still stuck with Py2, you'll have to use mod_wsgi, but if you are starting a new project, you should go with mod_python."
- jackalope 13y ago
  Priority should be given to making mod_python compile for Apache httpd 2.4, so applications stuck on httpd 2.2/Python 2 can be migrated. This is likely to generate the strongest initial interest. Dropping support for Python 2 would interfere, especially where libraries are used that haven't been updated to work with Python 3.
  - SiVal 13y ago
    All projects have finite resources that they allocate as they see fit. You say that priority should be given to legacy upgraders for the sake of "strongest initial interest." That may well be his preference, too, and if so, the costs of doing so will be debited from available resources. It is, of course, his choice, but I'm suggesting that there is an alternative where all available resources are focused on the future, benefiting new projects at the expense of whatever remains of the legacy, going for strongest ultimate interest even at the possibility that it might not produce the strongest initial interest, and attempting to own the mindshare of "best system for new Python projects" by positioning itself exclusively as that, not positioning new Python project support a recent add-on to an old, legacy technology. It's a matter of choosing market, positioning, and resource allocation, and I'm pointing out how, with a certain choice, the market perception that "mod_python is dead" doesn't have to be a problem and could even have advantages.