Python already has tools for this. IF I were interested in my working environment becoming more like a Ruby working environment, why wouldn't I just use Ruby?
Evolution is systematic change in allele frequencies.
The combination of natural selection and sexual reproduction tends to produce organisms which "fit to" their environments (hence "fitness"). It does so reliably enough that it might as well be the goal.
"AI systems" are not like people and they don't need people to be around to work, they do not function on the basis of ongoing intelligence from people. If the people die and there is nobody around to care, the same mechanisms do what they always did according to the natural law of the universe. They are just mechanisms which get things done. And so is evolution. And it is irrelevant that no person designed evolution to be that way.
I applaud your effort. Regex is a valuable skill (really, language) which you will use across languages and programs as it gives you access to an efficient and pretty general method for scanning and extracting things from text. And if you study fundamentals of computer science (like the Chomsky hierarchy) you will also find that regular expressions are important there too.
The specific reason not to switch to Jinja2 was that Django's templating language was originally intended not to be that powerful, so that you could feel reasonably safe handing it to non-technical "designers" or "writers" rather than fearing that they would generate a great variety of new tracebacks for you to look at.
If you have to ask why Django would not switch to (or even make any effort to allow the use of) any externally developed tool in place of its own, you might not have noticed that almost everything in Django is self-developed and that the officially given reason is that they are "perfectionists. with deadlines."
The reason why not is the Django project's philosophy
You are right. It isn't your job to learn on old versions of Python just so that Django does not have to release a port yet. Many projects have been waiting on other projects to port, thankfully the progress in library porting has picked up speed and the available library for Python 3 is very usable.
And Python 3 actually is a reasonable decision for a beginner. It is more consistent and does a better job of exposing the 'right' way to do many things.
Python 2 is reaching the end of its life and has little purpose except to support legacy libraries and apps and ease the transition.
It is not the users of Python 3, but people insisting on using Python 2 to the EXCLUSION of Python 3, who are fragmenting Python
My impression is that Wayland planned to support X as a compatibility option. The difference is that X isn't the low level mediator of all input/graphics by default. As I understand.
I've seen the promotional materials on PyPy's performance (I find them particularly persuasive on odd synthetic benchmarks) but thank you for the link.
I think you are a nice guy doing very useful work. You deserve to be proud of your work. But I do think you should be aware that an aggressive social orthodoxy has formed around the performance of PyPy. (It isn't unusual that I was downvoted here for suggesting PyPy isn't always faster, for example; it's the same thing in other fora and offline).
I think the PyPy's approach for generating Python interpreters is a great, clever idea. I think the project is more exciting than Shedskin was, etc. I'm impressed at the progress that has been made in expanding functionality and library support. I am looking forward (although with a little skepticism) to the day when it's really better at everything and is on my phone and everywhere. Sounds good.
But I am concerned about a cultural shift in Python, and unnecessary increases in complexity which come along with it. Many of the things which drew me to Python years ago come from its roots in the Unix/C world. I only recently began to hear dogmatic arguments that JIT is always faster than ASM, and memory is cheap so it makes no difference to use 2-4x as much, and being able to hook up to C isn't so important, and everyone should be writing incomprehensible, heavily-threaded programs using the world's biggest gc and synchronization mechanisms which require a lot of close supervision by people with pompous job titles. And you end up managing concerns of this type more than you spend writing domain code. And you do it all not because it is the cleanest and most direct way to get a good result, but because it's what is understood to be the right thing.
So I think a lot depends on whether PyPy drinks too much of its own kool-aid. It could second-system Python to death. It could succumb entirely to Enterprisitis. I don't need CPython, but I hope PyPy will smell like it. If the culture and the working environment continue to Java-ize, I will probably jump ship to Go or Ruby or whatever has a good library and most of the virtues I currently get from Python. I don't think that going more complicated is the best way to make software faster or better and it is important to my quality of life that I feel good about the code I am writing.
I'm heuristically pretty sure. From my personal experience talking to people, and from some surveys or other I have casually looked at over the years, what is mentioned most in job ads and mailing lists, heuristic stuff like that. The same kind of stuff which leads people to say that Rails is much more popular than other Ruby frameworks.
I would love to see a scientifically exact census but I don't think it can be done. Maybe PyPI could roughly tell the story? But you won't get a real unique-users count unless your logging identifies unique users, who wants that?
Please understand: I am not a big Django promoter, I disagree with many of its design principles, and I don't think that other things are "dead". I know that there are reasonable numbers of people out there using Zope/Plone, Flask, Pyramid, and other things. Just because Django is huge doesn't mean they are nothing or not worth looking at.
I believe Rails is significantly bigger than Django, but that doesn't mean I'm switching to Rails.
But you are going to find people in the Python world telling you to abide by PEP8. And saying that you should be using virtualenv. And saying that you should not use (module-level) globals. And saying that you should be using various checking tools. And the checking tools may say annoying things (some of which will be good points about your code).
And I'm kind of one of those people, as well; not saying that there aren't reasons to break a rule, or that it instantly makes your code crap if you do, but I understand these arguments.
And a vocal number of those on Python IRC channels tend to be dicks to newbies or people with unusual ideas.
So I guess I would question whether Python is going to give you what you want. I can't speak much to Ruby's culture.
Use the tools you like which make your life better, and if it makes your life better then ignore other people's unsolicited opinions on the internet and just do your thing.
People writing tools to learn, or because the existing ones didn't suit their needs or tastes, occurs in every language and is very different from Perl-style "more than one way to do it".
It's ridiculous to act like the mere existence of multiple independent projects for one task is some kind of searing indictment of the "one obvious way" principle in language and API design.
Django has such numeric superiority that there is not a lot of point splitting hairs on whether it is "default." While it isn't in the stdlib and there are other good choices, Django might as well be the default, just as Rails might as well be the default in Ruby.
There is no Pope of Python to tell you "you can't write new code to do xyz, because someone else is already working on that."
How would that be enforced? Would someone's Python privileges be taken away?
What if the person working on xyz was inactive for a while? What if their xyz had a problem and they didn't want to fix it?
The "obvious way to do it" does not and was never, ever intended to bind anyone's hands from writing a library or app similar to something someone else wrote. It is a principle of language design, that it should give SOME consideration to readability and learnability rather than giving 100% of everything to nifty obscure features that help you write awesomely clever executable line noise.
What would be the point of filing bugs against PyPy stating that it is slower or more resource-hungry on programs XYZ, when this is ultimately due to PyPy's core design decisions which are a point of pride and never going to be abandoned?
Expecting some positive outcome from that seems incredibly unrealistic to me. I believe it is a waste of time. It isn't my responsibility to provide reasons to PyPy why I'm not using it. Let PyPy - a project receiving no small amount of promotion - show that it is better for my purposes, before I invest big in switching over projects.
What you COULD say is that it doesn't make sense that in practice, people are treated like idiots and flamed if they publicly mention that they don't find in practice that PyPy is always or even generally better than CPython.
Or you could say that they should both work for most purposes, and that the choice is nuanced (measure the difference yourself), and in just a few respects PyPy is not as mature (not surprising given the lengths of the projects' histories). And PyPy is a work in progress and you expect it to get better if it isn't better than CPython now, for some specific purpose.
I don't expect you to say either of those things, because it seems important to the PyPy project to promote it over CPython and if that means selectively mentioning only the cases which are in PyPy's favor, or softly suppressing dissent, then so be it. That is how it seems to me, and I don't understand why it has to be that way.