I wasn’t overestimating things, I only reported the news.
BTW neither in the title nor in the article it literally they state that Linux will be 2.6% “faster”.
Nor did antonmdev say that it literally said that. The article title is a bit click-baity. “Linus Torvalds lands a minor performance improvement with minor Linux kernel patch” would’ve been more honest, wouldn’t it? Not qualifying what the 2.6% refer to is trying to make this sound more important than it is.
I disagree. The article is interesting for me and not a click bait, I learnt something about a performance improvement in Linux kernel. But you are free to have your own thoughts about it.
FYI I’m not the author of the article. I only shared it. You can write in the comment of the article suggesting rephrasing it or future articles.
BTW when I read it I haven’t believed that the whole kernel had a 2.6% boost with a patch of few rows (but as you, I’m a very small sample) I haven’t found it clickbait, otherwise I haven’t shared here,
Previously, on Lobsters, we discussed how to interpret PyPy’s out-of-date benchmarks. With this release, we can now directly read from Plot 2 of speed.pypy.org. It seems that my prior estimates were biased but fairly close; CPython has had a speedup of about 1.4x from Python 3.7 to Python 3.12, and the overall PyPy speedup from that same baseline is about 4.5x. The overall conclusions don’t change much, but it’s good to see concrete evidence instead of napkin maths.
Thanks. I already know django-extensions and it’s command to generate a graph from models, but I think it can be a core feature and also can be improved yo generate formally correct UML or E-R model.
I wonder what the django admin would look like if built with a modern frontend framwork. The Django-Admin is a very impressive DSL for building CRUD apps around the relational model. The way that translates into the built HTML and interactions is coupled and hard to extend. I wonder what well-typed react components would look like that accomplished the same result. What would it look like in HTMX?
Would the strict typing and coupling make it more difficult to define custom extensions?
In my experience the django admin is great until you want to do complex things with nested/foreign keys. Things like pre-submit (so built into the first rendering) validation and auto-complete between parent model of child model values.
I think Django works in remote services, but also locally on you PC, in a remote server or VPS or on RaspberryPI, and many other places (e.g. on the browser with pyscrypt).
I think the setting experience can be improved but, not only for service like environment.
Pyramid/pylons like .ini file. Having non executable file for settings allow us to use the settings to find where the application is, instead of finding where the application is to get the settings.
I remember settings in xml files in Plone and it wasn’t the best experience for me. Having a Python file for settings enable you to have dynamic configuration using a language you already know. Thanks for your feedback anyway, I’ll check Pyramid/Pylons ini files.
I think this proves django’s bad API design. This was obvious to me the day Django came out. All those concepts forced on you, rather than keeping API surface minimal… It was never a good idea. And here we are, two decades later, playing catch with a framework that was literally released as a joke.
The article compares with flask and sets its (flask’s) hellow world as its goal.
Flask of course. Otherwise articles like this wouldn’t exist. Why are things not this way from the beginning? Django is bloated and intricate. It introduces dozens of things that should be left as libraries.
Actually the article compares with quickstart of Flask and FastAPI to show that you can have a similar quickstart also using Django. The final point is that also of you can do it with Django, you can do way more things with it (eg. ORM) and usually you need more than a quickstart in real project.
on the contrary I think this shows the excellent Django API which, after many years since its first release, continues to innovate and demonstrates how it can also be used as one of the other frameworks.
Having been building dozens (hundreds maybe) web applications for 20+ years, in a dozen stacks, having seen the rise and fall of php, rails, etc. I very much negate that claim.
Good libraries are a breeze to implement and isolate. Replacing deprecated libraries with newer ones can even be done without downtime or any special procedure. Django’s philosophy is from The early 2000s when people had a user account ona shares box and with limited permission, and needed to jam everything in a “webapp”. Putting background tasks as an afterthought of an HTTP server, for example, is a very bad idea that I saw backfiring every single time I saw in action. Having the whole project and application abstractions is unnecessary rigidness that doesn’t serve any purpose. Putting things like middlewares and ORMs everywhere makes the code non re-usable by design. ORM per see is the Vietnam of computing.
It has nothing to do with “large applications”, in fact, if you want it to scale, the ORM is just on the way. And ita not particularly lightweight.
The reason why flask and the like became more popular is because they just make more sense, are easier to grasp and have a tameable API surface.
The thing I’d really like to figure out is how to do this and get models working, with model declarations in the same file. That would allow for self contained reproductions (helpful for Django library developers)
No. I couldn’t find where anyone had been successful with it. I spent a few minutes trying. I started by adding this:
from django.core import management
if __name__ == "__main__":
management.execute_from_command_line()
then just added more and more settings, wrote an AppConfig subclass, and added my models. I never got makemigrations to work by the time I hit the end of my timebox, but it felt like I’d probably need to monkeypatch django.db.migrations.writer.MigrationWriter to get past that if I didn’t want to manually inline some migrations.
At that point I stopped.
I suspect squinting hard enough at the project @radiaclinked would probably give me the answer if I thought it was worth another couple of timeboxes, but it was starting to get gnarly enough to feel like I was defeating the purpose of trying to have a single file django thing.
Exactly - Django expects you to have your models in an app, so you have to make that happen - patch migrationloader and migrationwriter, the modelbase, and the app registry. Iirc there’s also a load order issue which means you can’t really run the script directly. It does indeed get a little interesting - but ignoring all that, it does work pretty well as an end user.
You might try hacking together a fake in-memory models module and putting it on the import path (the way the pre-“magic removal” Django ORM used to do).
I did that with https://github.com/radiac/django-flasky - it’s very similar to μDjango, but supports models in the same file. There’s a bit more trickery behind the scenes to get it working, because Django expects things to import in a specific order, but the end result is a single file with everything in it - well, except templates, unless you want to render strings yourself
I am mostly “vaxxed and relaxed” at this point, but a rule to mask at conferences seems good. Traditionally you always got “conference crud” after every conference even before COVID. Seems like a good idea to try to stop that from happening.
Thanks all for comments here. I’ve just update the original suggested command parameter and I added an update sections. Feel free to check the article again and comment here.
I agree with the proposal, but maybe ActivityPub would be a better choice, because it can be used to share more technical stories as already happen for similar tags (e.g. e-mail).
I see a lot of comments and I am very pleased.I will all listen to them during the day and answer you.I was committed to a conference and a workshop this weekend.
It’s not really a dupe, but there is another description of the same event here. Should it be joined?
This is another article from another author that explain different things.
I think the biggest news on this is it’s finally multi-threaded
Yes. This is the greatest feature.
Page Updated
This is the Git repo https://github.com/oleitersdorf/PyPIM
Do not overestimate importance of this. This patch will not make linux 2.6% “faster”. This very narrow scoped change.
I wasn’t overestimating things, I only reported the news. BTW neither in the title nor in the article it literally they state that Linux will be 2.6% “faster”.
Nor did antonmdev say that it literally said that. The article title is a bit click-baity. “Linus Torvalds lands a minor performance improvement with minor Linux kernel patch” would’ve been more honest, wouldn’t it? Not qualifying what the 2.6% refer to is trying to make this sound more important than it is.
I disagree. The article is interesting for me and not a click bait, I learnt something about a performance improvement in Linux kernel. But you are free to have your own thoughts about it.
Interesting and click-bait aren’t mutually exclusive, fwiw.
FWIW, for me (sample, n=1), the title led me to believe that it was a kernel-wide performance increase.
Based on my experience alone, it is indeed a touch clickbaity.
Not worth updating, but worth considering as you write the title on your next post. Take the feedback constructively.
FYI I’m not the author of the article. I only shared it. You can write in the comment of the article suggesting rephrasing it or future articles.
BTW when I read it I haven’t believed that the whole kernel had a 2.6% boost with a patch of few rows (but as you, I’m a very small sample) I haven’t found it clickbait, otherwise I haven’t shared here,
Previously, on Lobsters, we discussed how to interpret PyPy’s out-of-date benchmarks. With this release, we can now directly read from Plot 2 of speed.pypy.org. It seems that my prior estimates were biased but fairly close; CPython has had a speedup of about 1.4x from Python 3.7 to Python 3.12, and the overall PyPy speedup from that same baseline is about 4.5x. The overall conclusions don’t change much, but it’s good to see concrete evidence instead of napkin maths.
Very interesting. Thanks.
I’ve updated my first article about the new generated fields added in Django 5.0 and SQLite I’ve improved the text and added some command outputs
I have updated my articles on maps with Django with some small improvements and updated dependencies, including Django 5.0 and Python 3.12
I’ve added four new ideas to my list of possible improvements for Django and its community. I’d like to know what you think. 👇 https://www.paulox.net/2024/01/19/my-django-roadmap-ideas/
I’d love to see the project adopt and enhance the model graph generator from django-extensions or the related one from dj-notebook.
I think looking at iommi could provide a ton of inspiration (and maybe a fair bit of code to adopt) for your RAD idea.
Thanks. I already know django-extensions and it’s command to generate a graph from models, but I think it can be a core feature and also can be improved yo generate formally correct UML or E-R model.
I wonder what the django admin would look like if built with a modern frontend framwork. The Django-Admin is a very impressive DSL for building CRUD apps around the relational model. The way that translates into the built HTML and interactions is coupled and hard to extend. I wonder what well-typed react components would look like that accomplished the same result. What would it look like in HTMX?
Would the strict typing and coupling make it more difficult to define custom extensions?
In my experience the django admin is great until you want to do complex things with nested/foreign keys. Things like pre-submit (so built into the first rendering) validation and auto-complete between parent model of child model values.
A new admin written in HTMX is something I already proposed but I think it would require a bigger effort than we thought. Thanks for your feedback.
Can we get rid of settings.py?
It’s an interesting idea. What would you use instead of the settings file to provide variables and configure behavior of your Django project?
I think people have mentioned a more service like approach to it that does not bundle anything and everything into a single atrocious file.
I’m not an expert but still pretty sure that there must be better ways to do this.
I think Django works in remote services, but also locally on you PC, in a remote server or VPS or on RaspberryPI, and many other places (e.g. on the browser with pyscrypt). I think the setting experience can be improved but, not only for service like environment.
Pyramid/pylons like .ini file. Having non executable file for settings allow us to use the settings to find where the application is, instead of finding where the application is to get the settings.
I remember settings in xml files in Plone and it wasn’t the best experience for me. Having a Python file for settings enable you to have dynamic configuration using a language you already know. Thanks for your feedback anyway, I’ll check Pyramid/Pylons ini files.
+1 for the django package template. Right now it really messy and not standardized at all, You can see the following pattern being used:-
Your right. I was thinking about names and also technologies too.
I published also the second article in the series 👇 https://www.paulox.net/2023/11/24/database-generated-columns-part-2-django-and-postgresql/
I think this proves django’s bad API design. This was obvious to me the day Django came out. All those concepts forced on you, rather than keeping API surface minimal… It was never a good idea. And here we are, two decades later, playing catch with a framework that was literally released as a joke.
Presumably you’re referring to Flask here?
I’m confused as to which approach you think is better
The article compares with flask and sets its (flask’s) hellow world as its goal.
Flask of course. Otherwise articles like this wouldn’t exist. Why are things not this way from the beginning? Django is bloated and intricate. It introduces dozens of things that should be left as libraries.
Perhaps different projects have different goals.
Actually the article compares with quickstart of Flask and FastAPI to show that you can have a similar quickstart also using Django. The final point is that also of you can do it with Django, you can do way more things with it (eg. ORM) and usually you need more than a quickstart in real project.
on the contrary I think this shows the excellent Django API which, after many years since its first release, continues to innovate and demonstrates how it can also be used as one of the other frameworks.
Django solves 95% of the problems you encounter when building large complex webapps.
If you want the same feature set with Flask, or FastAPI, or other, you end up easily with dozens of libraries that you need to glue together.
Django is an opiniated framework, not a library. If you stay within the lanes, Django is great.
So let’s not compare apples and oranges. And let’s not pretend a personal opinion is an absolute truth.
Having been building dozens (hundreds maybe) web applications for 20+ years, in a dozen stacks, having seen the rise and fall of php, rails, etc. I very much negate that claim.
Good libraries are a breeze to implement and isolate. Replacing deprecated libraries with newer ones can even be done without downtime or any special procedure. Django’s philosophy is from The early 2000s when people had a user account ona shares box and with limited permission, and needed to jam everything in a “webapp”. Putting background tasks as an afterthought of an HTTP server, for example, is a very bad idea that I saw backfiring every single time I saw in action. Having the whole project and application abstractions is unnecessary rigidness that doesn’t serve any purpose. Putting things like middlewares and ORMs everywhere makes the code non re-usable by design. ORM per see is the Vietnam of computing.
It has nothing to do with “large applications”, in fact, if you want it to scale, the ORM is just on the way. And ita not particularly lightweight.
The reason why flask and the like became more popular is because they just make more sense, are easier to grasp and have a tameable API surface.
The thing I’d really like to figure out is how to do this and get models working, with model declarations in the same file. That would allow for self contained reproductions (helpful for Django library developers)
Yeah. This is kind of cute, but it gets messy fast if you try to get models or templates going.
Got a link to how that would look?
No. I couldn’t find where anyone had been successful with it. I spent a few minutes trying. I started by adding this:
then just added more and more settings, wrote an AppConfig subclass, and added my models. I never got makemigrations to work by the time I hit the end of my timebox, but it felt like I’d probably need to monkeypatch
django.db.migrations.writer.MigrationWriterto get past that if I didn’t want to manually inline some migrations.At that point I stopped.
I suspect squinting hard enough at the project @radiac linked would probably give me the answer if I thought it was worth another couple of timeboxes, but it was starting to get gnarly enough to feel like I was defeating the purpose of trying to have a single file django thing.
Exactly - Django expects you to have your models in an app, so you have to make that happen - patch migrationloader and migrationwriter, the modelbase, and the app registry. Iirc there’s also a load order issue which means you can’t really run the script directly. It does indeed get a little interesting - but ignoring all that, it does work pretty well as an end user.
You might try hacking together a fake in-memory models module and putting it on the import path (the way the pre-“magic removal” Django ORM used to do).
Cool. Thanks.
I did that with https://github.com/radiac/django-flasky - it’s very similar to μDjango, but supports models in the same file. There’s a bit more trickery behind the scenes to get it working, because Django expects things to import in a specific order, but the end result is a single file with everything in it - well, except templates, unless you want to render strings yourself
The goal of the article is only to show how minimal Django can be. If you need models let use Django as usual.
Is this a flashmob? They are all in masks.
I took the picture at the DjangoCon US 2023 conference where wearing masks was mandatory.
I am mostly “vaxxed and relaxed” at this point, but a rule to mask at conferences seems good. Traditionally you always got “conference crud” after every conference even before COVID. Seems like a good idea to try to stop that from happening.
Yes, it was actually a bit annoying, but it allowed more people to participate, especially the more vulnerable people.
Are there no plans for type annotations?
You can try django-stubs https://github.com/typeddjango/django-stubs
Thanks all for comments here. I’ve just update the original suggested command parameter and I added an update sections. Feel free to check the article again and comment here.
I agree with the proposal, but maybe ActivityPub would be a better choice, because it can be used to share more technical stories as already happen for similar tags (e.g. e-mail).
I see a lot of comments and I am very pleased.I will all listen to them during the day and answer you.I was committed to a conference and a workshop this weekend.