 Hi, I am going to talk about Django today. As many of you would be familiar with Django is a web framework. Before I start, I would just like to tell you whom this presentation was made for. The first question I asked myself when I created this presentation was who would be the target audience and my initial idea was pretty much like this. You would start off as a beginner and you come walk into this conference and then you probably reach a good level or an intermediate level and keep working till you become Chuck Norris because nobody quotes Django better than Chuck Norris, not even me. So that was the original intention but from my experience usually for Django talks, people come from all sorts of backgrounds, there are people who are sues, the startups, entrepreneur guys, the devops guys, the operations guys, the designers, the rails guys, the admins, all sorts of people. So how many of you are familiar with Django have at least done a tutorial on Django, just raise your hands. Wow, great, thanks a lot for coming, goodbye, so just joking. So thanks a lot for the great turnout, I mean I know it's raining heavily outside, you must have braved all this rain, thunderstorms, dragons, I don't know but thanks for coming. But how many of you are from non Django frameworks, how many of you prefer to use non Django frameworks? We'll meet backstage, probably have a fight but hang on. In this talk, I'm just going to talk to you about Django from a perspective of a person who has actually seen the tutorial, who at least had a taste of the tutorial. But trust me, there is a real dearth of content for the intermediate Django programmer. I mean, there are a lot of technical articles or blogs which talk about different advances of Django for the experts but there's a real gap in the middle which I hope to address with this particular talk. Hi, my name is Arun, I'm a solution manager at Unisys, I'm also a Python enthusiast, have been programming in Python for quite a long time, have been attaining all the Django conferences. I find Django to be an excellent framework, it's great to start, I'm not supposed to talk down about other frameworks, at least that's what they think. But actually I feel that genuinely that Django addresses the rapid application requirement in Python. Python has thousands of web frameworks out there, so Django really holds a very specific spot and I have a website called unrocks.com where I regularly post screencasts. How many of you have seen, build a hack-on-use clone screencast? Okay, thanks, so that's probably my claim to fame and I've built a couple of production quality Django websites as well. This is not a real Python or a Django tutorial, there are plenty of good Django tutorials out there, they're just my perspective about what I feel should be the best practices in Django and to someone who is given not experience with Django, I just like to give a taste of what the web framework is like. So what is Django? Obviously it's a web framework with a couple of principles in mind, like you should rapidly develop web applications, that's one of the important ideas behind Django when it was born in 2003. So it's about 10 years old now, it was born in a newsroom called Lawrence Journal, Andrea and others actually contributed to the initial version. So when you're in a newsroom you really don't have time to build new features, you know, you always have to be on a deadline, probably you'll get 24 hours to build an application and Django was built or born in that kind of an environment where you don't have time and content had to be added very quickly and that's the reason behind that admin interface where you can quickly add content. So that was one of the principles and other principle was behind it was dry, which is don't repeat yourself, which we'll talk about in a minute. Most people think Django is a lot of other things which I would like to clarify in this. Django is not a silver bullet, like many people would like to assume just by installing Django you cannot build an entire website with all its features, today we are talking more in terms of a service oriented architecture where, you know, lot of specialized functions are done by underlying services which might be written not even in Python, which might be written in a lot of different languages and a web stack typically contains all these things, but when it comes to the web framework layer usually Django is a good fit. It's not this movie I'm talking about, it's all about building a framework, right? It's just a framework, it's not a complete house and you just start building on top of that you add doors and windows and it becomes an entire site. Some people definitely, it's not an CMS, some people think it's a CMS, they ask me, Arun, I want to build a site, you know, I want CMS, I've considered P-Loan and I've considered WordPress, I've considered some of the other things. Can you tell me if Django is the right fit? No, Django is not a CMS, Django is just a framework, you have to write a lot of code before you actually reach a stage where it becomes a CMS. Of course, there are a lot of third-party applications like Mezzanine or others, which you can actually install and create a CMS, but it's not really a CMS. So when I was a kid, I used to like taking apart toys, when there was a little toy which made music, I used to ask my parents how it worked. So they would just look at it and say, you know, it's magical, it's like, come on, I'll just open it up. So many people behind Python or Django project believe that, you know, you should remove as much magic from the web framework as much as possible. And I know that it's easy to use Django without understanding how it works inside, but I also feel that if you're a tinkerer like me, you'd probably like to know how it works on the inside. So this is how a very rough diagram of how a Django framework works on the backend looks like. It starts right from the browser. You start, you make a request or you open a web page. For example, you type python.org and it opens. Here's what happens. The flow actually goes through architecture, which we call as MTV. It's quite similar to the ModelViewController, but it's philosophically different from the MVC architecture. So we have models, templates and views. The browser request goes through the URL mapper. It goes, the URL mapper identifies the right view to pick. It goes through the views layer and it goes then to the model. So when I say layer, I'm just using it as a rough implication. There are no such layers as you would see in a Java architecture like a tier or something like that. It's just that all the things in green are actually referring to Django. So then it finally reaches the models and then it hits the database. And then the request goes back from the database back to the models, back to the views, and views actually pass it on to templates, which actually render the HTML or JSON or whatever it is. So this is in short how the entire Django architecture looks like. And as you know, most applications we use today are database or crud kind of applications. I would go in so far to say that even Facebook or Twitter, all those things are just front end by database, which actually returns those things. Now, like I said, the green part is Django. And one quick note I would like to say is that Django prefers or advises as a best practice to make models fatter and views thinner. What I mean by this is most of the logic or the business logic or the business ideas should actually go into models so that the model should be more meteor. And the view should be as thin as possible just referring to models for all kinds of logic and just dealing with the presentation aspect of it. It's very similar to the MVC architecture in that sense. And of course, template should be absolutely dumb. Some people don't agree with it. They replace the Django template layer with something else, which where you can write actual Python code. But if you have worked with Django, you'd realize that the template layer is pretty much very dumb. And of course, lot of great other reasons or great other things which come with the pack when you actually buy, you don't actually buy Django. So it actually comes with a lightweight web server. It comes with form serialization and validation. It comes with a very good caching framework like Arvind just talked about. It can work with Redis. It can work with Memcached. It can work, it also supports a lot of middleware classes. So you can intercept, as you saw, the request is going up and down. You can intercept the request at any point in time using middleware. This is a great internationalization system, and it is a great testing framework as well. So why is Django awesome? I mean, many people talk about it. There are thousands of libraries out there. Why did Django stand out? These are my personal opinions. Probably you have different reasons. It has a great admin interface. Like I said, admin helps you to add data right from day zero. Right when you start applications writing, you can actually start an admin interface in parallel. And somebody else in your team can actually start adding the data while you're writing the code. So that makes it intensely powerful. Security, how many of you heard of the breach attack recently? Yeah, so breach attack was based on HTTPS replay and slightly related to zip compression and all that. And guess who came out with the first security note? It was Django. So they take security very seriously. And it has been built into the entire framework at numerous places. In fact, some of my clients said that of all the web frameworks, they chose Django because of the focus on security. I mean, it's bulletproof to a great extent, unless you shoot yourself in the food status. It is great documentation. I mean, this is worth mentioning because Django documentation have found it to be the most complete among all the other open source frameworks. It is a great community. Many of you would be familiar with the fact that it's easy to find a person who is familiar with Django. If you have any doubts, you can ask them. Or if you have, if you post a question on the mailing list, you get the answers quite quickly. And it's fairly stable. And best of all, it's batteries included. So many of the micro frameworks claim to be very lightweight because they don't include the batteries. They say that you're flexible enough to use any templating language, any form, handling library, anything like that. But at the end of the day, if you're making a complete website, sometimes you need all of these things. And sometimes you need the best practices for that. So that is the philosophy behind Django. Just give all the batteries to you at the start. So you can start using the Django built-in stuff. If you're growing out of it, you probably need to replace that. That's also possible. That's also easy. And of course, it's open source. That's one of the great things. So some of you are coming from PHP and ASP background. How many of you have worked on ASP and PHP? Quite a bit of you. So here is a very quick five-step way to come to Django. Forget everything. How easy life was. You just write some ASP code. Put it on your server. Open that URL. Bang, it's working. It's not like that in Django. You have to configure a bit more. Start thinking of the architecture. So like I said, PHP talks about just rendering each page by page. See, even the initial developers of Django realized that when they actually wrote something in PHP or ASP, they're repeating themselves a lot. And Django tries to prevent that from happening by putting everything in a single place by not repeating yourself again and again. Think about separation of concerns. Don't mix your template code with your logic code. Don't mix your form handling with something else. Just keep everything in separate boxes. Step four, step five, profit. So that's easy as that. What are the bad excuses which I come across when people say, look, I don't want to use Django. One of the biggest reasons I hear is Django is too heavy. Now, believe it or not, the next slide was not planted. It was not pre-planned with Kirin's keynote. It just happened, the flask code that he showed. So this is a beautiful piece of code. It looks so short. I mean, it's unbelievable that Hello World is so small in web framework. Can anyone tell me how big would be the Django piece equivalent? How many lines of code roughly? Yeah. Sorry. View and URL, okay? That's at least two files. 120 lines, good one. Okay. This is the equivalent in Django. It's just a single file. So this is one of the misconceptions I wanted to clear with you. It actually runs, you know, this single file. It has settings in it. It has URL handling in it. It has everything in it. And all you have to do to run it is just configure the Python path to the Django admin and just to run so. So it's a misconception, guys. Django is small. So it's one file and it's almost the same size. Of course, I wouldn't recommend using this, but practically it's almost equivalent to what we're talking about in terms of micro frameworks. So one of the reasons why Django is big, especially when you install Django, you'll see that it's probably a two megabyte or five megabyte, I don't know how much. It's probably because it has batteries included. It has all those cool things which I just talked about. Another common complain I hear is Django. I mean, it has all those regular expressions and you know, that carrot sign and dollar sign. What's the deal with that? I mean, why can't you use something more simpler? Like for example, if you want to define a URL, write example.com products. Why don't you use that curly bracket and ID? Why don't you, I mean, why do you have to use that regular expression thing with square brackets and zero to nine and that plus, I don't know what. Can anybody guess why? Any guesses? Security, exactly. So SQL injection is a big problem when you use that kind of URL syntax for defining what route to take. For example, if a user just gave this particular thing as ID, everybody knows Johnny Tables, right? XKCD comic, okay, forget it. This is one of the reasons why your entire list of products might come to the user or might be visible to the user. You just have to give one R, one equals one and it's always true for all products and that SQL query just turns out to be a SQL injection. So just by saying that you're more specific when you're defining a URL, you're saying that you're accepting only numbers, you're accepting only a certain kind of input. You're actually being more secure. You're actually being more safeguarding your website from all kinds of attacks. So like this slide tells you, Django cannot always save you. You have to use your good sense in that particular case. If you use this particular syntax, it's still valid in Django. It just accepts anything, you know, dot plus will accept anything that's a single character and move as your URL. Please avoid that. So the advice is be as strict as possible. Just like you see in the Django examples, there is a reason for that and it looks prettier as well depending on how you look at it. Here are some of the reasons, some more reasons why people don't use Django, which some of them might be good reasons. If you have unusually high performance needs, I know I put it in bold, but I'd like to repeat that unusually high performance needs because unless your Google or Facebook flicker, seriously you're not gonna reach a bottleneck when it comes to web frameworks. I mean discus.com, which is one of the most popular commenting frameworks out there actually uses Django. Instagram, which actually serves billions of requests actually uses Django. So please don't use the reason that it's not performant enough. It is actually pretty performant enough given the right architecture. Of course, that last part is a bit tricky. Existing database models. You have a lot of legacy RDBMS database models. That's very hard to replicate using the ARM ORM which Django provides. In such cases, something like SQL Alchemy or some other ORM might help you to migrate you easily into Django or into any of the existing web frameworks. So probably then you might want to consider something else other than Django. Migrations, I struck it out because it was long considered that Django does not come out with migrations out of the box. You have to install something like South to migrate databases. I mean, how many of you understand migrations? Okay, so some of you don't understand migrations it's because migrations nothing but you create a model or you create some kind of tables in a database and then you realize that you want to add one more field or you want to add one more, you know you want to change the type of that particular field. So now we have to do some alteration on the existing structure of the database or the scheme of the database. So that's when you need to use migrations. Earlier Django did not have South. You have to delete those tables or delete those, drop those applications and recreate all your data from scratch. Those are the bad old days. Now you have South and especially in the next version the creator of South is actually going to add the core features of South integrated into Django. So that's great news for people who have been having troubles with migration. And of course some of you don't like the built-in template or built-in ORM or any of the choices that the Django developers came out with. The easiest advice I can give you is just go with what is built-in with Django first. You find that your needs outgrow that just, you know, replace it. It's not very difficult. You can use Ginger instead of the regular templates you can use any of the other ORMs. Though ORM replacement is a little difficult. It's still possible. So it's flexible enough to do all that. So in short, what I'm trying to tell you is if you want to replace most of Django's components which is because it's a framework it comes with all those components then probably you would want to consider that or eventually like in some cases you would start your website in Django because it's the easiest way to get started. And then probably you'll find that, you know, like, you know, Reddit has high scaling needs. They've moved to Pylon. Things like that, you probably want to move to a different framework. So some of us are interested in knowing what are the best practices when you're actually developing Django applications. I've quickly listed them down here. As you might have guessed, don't believe anything that comes from outside your website. Don't trust user data at any point in time unless you have sanitized it properly. So this happens a lot with form handling. This happens a lot with URLs. So just be careful about what you're getting from the outside, sanitize it and then start using it. Don't leak implementation details like Django is notoriously infamous for being hard to pick. I mean, if you built a site in Django there's absolutely no trace outside. There is no, you know, teletail signs like, you know, the URLs don't tell you whether it's a Django site or not. Probably it's a good thing, right? You don't have to show what the implementation details are and wait for someone to actually break into the site based on what the implementation details are. So it's probably a good thing not to leak it outside, but this belongs to a larger class of problems where you actually tell, you know, something is residing in some database and you can access it by some certain URL. So probably that's not a good idea. Like I said, FATO models and leaner views is a good practice. Follow Pipe 8 guidelines as with all Python code. Be as dry as possible. So do not repeat yourself means that you should not write the same logic in different pieces of your code base. Different files in your code base should not overlap just for consistency sake. It not only reduces a lot of confusion, it actually makes it consistent. And what is the opposite of dry? Anybody can guess, do not repeat yourself. What could be the opposite? No, it's FAT, wheel out typing. So last point is please break down your applications into functional units as much as possible. It's very much likely that what you're building as an application might be useful in the future for yourself or to the open source community. So breaking down into functional units is actually a very good practice. Some of the novice questions I'd like to quickly address especially if you're starting to learn Django is I hear this a lot, what is a query set? Query set is nothing but an object that talks that interfaces with the database or provide some sort of an abstraction to the database. In fact, it converts whatever you need to talk to a database into Python objects or Python iterators. You can do anything with a query set like filtering, reducing, all sorts of mangling. And the best part is the query set does not touch the database until you execute it. So until you do all these operations, it's not talking to the database, it's actually saving a lot of time. So it's actually good object-oriented practice. So why is media separate? I mean, some of you are dealing with static and media in Django, right? I mean, most of us have this confusion. So static is everything that the developer has written is probably your JavaScript files, is probably your CSS files. And media is all those things which are uploaded by the user like their photographs or their files or things like that or the movie clips. So it's generally kept separate in Django. Which IDE to use? This is a surprisingly common question that I come across. Okay, I don't use IDs. So I'm not probably the best person to talk about it. But if you come up, yeah, PyCharm is a very good ID. If you're coming from an Eclipse background, PyDev is a very good ID. And if you're on the other end of the spectrum, Emacs, Y, VI, I'm an Emacs guy, so my preferences. And sublime text is pretty good as well as a modern replacement. How to deploy? There are various ways to deploy Django. This is not addressed in most tutorials, but it's a little bit tricky. You have to understand how the deployment process works. I suggest reading Fabric or Chef or Puppet. All these are great deployment tools or automation tools. So this is another thing which I wanted to cover. Django is just one package that does not address all your needs. Probably you need to work with a lot of other third party applications. What are the recommended beginning points? I mean, of course, we'll start about talking about Python packages that you need to probably be familiarized with. Of course, everyone knows this. Virtual environment, which later moved on to PIP. It's a pretty great way to start or isolate your application environment. I would suggest do not start without PIP. The first thing you should do is install PIP and start a virtual environment. I Python or B Python. So these are pretty good interpreters. I Python is probably the interpreter I use the most. PUDB is another great debugger. If you don't know how to start debugging in Python, I would suggest you start using PUDB. Fabric, again, is a great deployment tool. What goes well with Django? So there are lots, and trust me, lots of Django packages out there. What are the best ones? I would suggest learning at least these. I mean, you should learn at least Django debug toolbar, which is great for debugging Django compressor, which actually deals with reducing the size of static assets. Django extensions, which is a great set of extensions. It's a must have. You should definitely install this. South, again, a must have. If you're dealing with migrations, which you will, trust me, you'll have to actually install South. Celery, again, for delayed jobs. If you have some kind of back end processing or some kind of job or activity, which takes even slightly more time, so just taking it outside your front end and putting it on the back end, this thing's celery. And Tasty Pi, if you're interested in building APIs, for example, mobile interfacing and things like that. Other cool Django packages, which I'd like to quickly go through, Django social authentication, great set of social authentication tools for almost every social authentication out there, Facebook, Google, you name it. Django PayPal, if you want to make money, that is. Crispy Forms, great way to format your forms. Django Taget, POSGRESS SQL is one of the recommended databases to use with Django. Django Storages, if you have to interface with Amazon S3 or any kind of cloud interface. A quick description of how my Django workflow looks like. So if you're starting to work with Django, you might be probably confused by the number of components that are out there. But if you're actually following a screencast or if you're following a tutorial, you'll probably notice some kind of workflow. This is my preferred workflow. Start creating a new Django project with just one command line. Find a third party. If you're trying to make some kind of a functionality, first check if it's out there. Don't try to build it. Don't try to reinvent the wheel. See if there is something already out there. If it's not there, start creating the application. Probably write the models first because that's the great way to implement the functionality. Now play with the queries on the console. So you have this run server and you have this console managed application and then you run SyncDB. It becomes persisted to the database. You add an admin.py in case somebody in your team actually is interested in adding the data or you yourself want to see the data. Add data from the admin UI. Write views.py. If possible use class based views. If needed add a model form using forms.py. Add views to using URLs.py. And jump to repeat, rinse, repeat, rinse till you actually finally end with a fully functioning website. So these are the important things which are highlighted, the files which are highlighted. In case you're interested, you can actually go through a video tutorial. If you're a slightly intermediate programmer, these are some of the things which have inserted into this workflow. I definitely recommend using it or any other kind of version control before you start. I definitely recommend using schema migrations which comes from the south framework, south application. I definitely recommend migrating before you actually persist the queries. And then definitely recommend writing test cases and using something like fabric or chef or puppet. Forms, just wanted to quickly cover forms because most of us think that if there is some kind, especially coming from the PHP or ASP background, if there is some data which is coming from the user, it's easy, right? Just use request.os. whatever is in the dictionary. But this is that temptation. Don't directly use the input which is coming from the user. Write a good form which even if it is a very trivial form like a search form with just one field, just do it because it contains a lot of validation, a lot of security checks like CRSF or something like that which might be actually overlooked by you when you are actually building the logic for handling user input. And it's also having a lot of built-in functionality from form view as well. Yeah, if you're using bootstrap, I definitely recommend crispy forms because it actually has built-in formatting for that. Should I use class-based views? You should. Why? Because it's great. So class-based views are the new form of generic views. I don't know in which version I think it's probably 1.2 or 1.3, 1.3, right? So 1.3 was when they stopped using function-based generic views and moved to class-based views. It's not very straightforward as function-based views but there's a great site called ccbv.co.uk which actually tells you how to use class-based views and I definitely recommend using it once you start out growing the initial needs of generic views. So I made a Django site. Now what should I do? Definitely send it all to your friends, tweet about it, post on Facebook, et cetera, but also do this. It should definitely turn off the debug mode in production because debug mode is definitely not written for production. Definitely use HTTPS for logins because it's very easy for somebody to wiretrap when you're actually using logins without HTTPS. Set the X-Frames options header because it actually makes it more secure. Use session cookie secure, turn that on, it's very easy just say true in settings.py and please change slash admins to something else because it's very easy to guess if you used Django. Or even easier, there is a good site which actually does all these checkups or is this something called ponycheckup.com? Just check it out. All you have to do is put it on a public-facing site and just put that URL. Most of these checks are already done by that particular site. So that's pretty much it. My tweet handle is Aerox. If you have any questions, you can ask them now or I will do it. Thank you. Questions? So how do you do REST APIs in Django? Yeah, so that was the Tasty API or Django REST. So there are two or three competing frameworks out there. These are just applications which you can install on top of Django. All they do is the same way you build models and you build a form or you build a view. Same way you can use those models and expose them as a model API and all they do is instead of outputting HTML, they output in the form of JSON, do the same kind of workflow except you're doing it with JSON. And I think Django REST is currently the best one out there. Of course, I'd recommend you to try some of them and go ahead. Great talk, first of all. So I started off with Rails and then switched on to Django just because I love Python and I'm more comfortable with syntax. So in terms of the trade-offs using Django compared to Rails, so what would be your opinion on it? See, I'm not a Rails expert but I find that Rails is becoming more and more opinionated like you have to use coffee script, if you have to use JavaScript and it has a lot of built-in stuff that is very opinionated. And one important difference is configuration of a convention which is generally used in Rails. In Django, they don't go for that convention, they just put everything settings.py in case you want to change it. Go ahead, open settings.py, just change your application or you just change your things like that. So, of course, one of the main reasons, one of the main differences is the language itself but I feel that the philosophies of these two frameworks are slightly different. Django is favoring more of stability, just make it work but make it secure and stable but Rails is more about, let's get it out of the window as soon as possible. I mean, I might be opinionated but that's the kind of approach I've seen most commonly used in Rails. Oh, here. Yeah. With respect to the ORMs that I used with Django, will Storm go well? Storm, ORM? I'm sorry, I'm not aware of Storm. Okay. What are the other ORMs that? SQL Alchemy is a good ORM which most people replace it with. Like I said, if you're dealing with more, Django does not deal with many databases, right? It does not deal with the obscure ones. I think Oracle is working but it's not that great but if you're dealing with obscure databases, if you're dealing with some kind of legacy set of databases that you have to import or you have to migrate into your application. In all those cases, I would recommend SQL Alchemy rather than the built-in Django ORM. Hi. How do you debug revenue? I mean, sorry, I'm really sorry. Management commands. I mean, we write, we make huge reports and we do like huge, I mean, lot of ORM queries when those commands run. And it's like really hard to debug because all it says is one line of red colored, you know, error message. And it's, it's... Number one, write test cases. Maybe we should do that. Number two, yeah. I mean, the best debugger I've found for Python is for Django is workskurg. How do you spell that? Workskurg, yeah, workskurg. Because you can actually interactively see the input. You can add interactive output and generally debug that. I agree that some people find Django output messages to be a little obscure because it, the error must have happened somewhere and the line which is being highlighted is completely somewhere else. So you have to go through the stack trace and find out where exactly the error happened, especially if it's in a template, it might probably show in a totally different place. But unfortunately, that's the case and trust me, it grows on you and you become pretty quick in identifying what the common problems are. But yeah, if you want to debug, I definitely recommend debug toolbar, which is great. It'll show you what the exact SQL queries are and things like that. But if you're dealing with Python errors, probably you should deal with, you should use workskurg or something like that. Hello? Yeah, I should. Yeah, sorry. It comes along with Django extension. So install Django extensions and it'll come with you. Yeah, I should. Thanks for your nice and crispy slides actually. And I just want to ask the debugger which you have referred. Yeah. Can I get the name? I just missed it actually. You're referring to the Django toolbar or you mentioned the debugger library. Okay, I think PUDB is it? I think I mentioned the same, those two. So if you're using workskurg, just install Django extensions and it'll, it's a third party application and it comes with a lot of stuff. I think 20 different features and one of the features is that it installs a better debugger. You can install that. Thank you. Sorry. Yeah, it's also used in Flask which is the other framework. Any other questions? Yeah. Yeah, so configuration, the question is about configuration versus convention. So generally what happens in the people favor convention is that don't give them the flexibility initially to ask, okay, what kind of templating language do you want to use or what kind of, I mean, the specific choices, there is no menu or something like that. They just go with the convention that, you know, these are the best in class. These are the ones you'd probably want to use, just use it. That's a convention approach and configuration approach is that, okay, probably you want to tweak it before you want to start it and then they ask you all these things and settings.py is a good example. It has all these settings inside it. You would probably want to tweak it and then finally arrive at, you know, what you want to like. It's just a difference in the way you start. Nothing, sorry. Rails also has that approach, but it generally said that, you know, they favor convention first rather than configuration. Hello. One last question. You mentioned that Ion Python console is better than the vanilla Python console. Sorry, can you just raise your hand? Yeah, thank you. So you mentioned Ion Python console is better than vanilla Python console. Why is that? Ion Python? Yeah, Ion Python. Yeah, Ion Python, Ion Python. Exactly, so Ion Python is great because it has syntax highlighted. So it shows you the colors. I mean, it's pretty easy to, easy on the I. And it, sorry. Yeah, Ion Python notebook is a great feature. So if you have used the Ion Python notebook, it's actually just a webpage where you can interactively run commands and things like that. And I think the replay, the history is much better than the traditional Python console. I mean, it's probably the same as Python console, but on steroids. I mean, it has a whole lot of extra features running on top of it, like graphing or read line functionality. All those things which should have been probably there in Python, but they kept it because it might be adding too many features or it might be a feature clip. Yeah, I Python notebook is probably a great example. Thank you. Thanks a lot.