251–257 of 257 posts
Earlier quoted context omitted.
don't your users in 2020 care you are using an unsupported language? security wise
Of course not. That's the point.
can you achieve security with a dead language? I don't think so.
Earlier quoted context omitted.
Not a data engineer / scientist here. What am I missing with data-frames? I've written products that utilized them before (years ago), but it's been long enough that I don't know what I would even use them for in daily programming.
They're for tables and doing table-ie things: an imperative programming method for the same tasks people use Excel or SQL for. This dovetails nicely with most data science-ie tasks, like statistical analysis, engineering features, simple machine learning techniques (the tables can be easily transformed into numpy arrays), and plotting results. You can use them any time you feel the need to do table manipulations on n…
Earlier quoted context omitted.
I assume Dan really means a nested directory structure, like so: django_project/top_level_app/second_level_app/ in top_level_app you then could do from second_level_app.models import model1 or from a different top level app: from other_top_level_app.second_level_app.mixins import a_mixin
Yep, exactly this. For example: project/orders/orders_shipping/orders_ups Unfortunately app names have a global namespace within Django's model registry, so we often have to prefix nested apps. The place where this really works nicely is user facing features and internal editing interfaces, or in features where we have N of a feature that are all similar. For the former, we might have an app such as "blog", and then…
I usually organize my apps by having a services layer between models and views, such that the view functions have little to no knowledge about the underlying models.
This, in place of nested apps, I have "upsmodels.py" and "upsservice.py" and the view functions handles routing logic.
Earlier quoted context omitted.
Yep, exactly this. For example: project/orders/orders_shipping/orders_ups Unfortunately app names have a global namespace within Django's model registry, so we often have to prefix nested apps. The place where this really works nicely is user facing features and internal editing interfaces, or in features where we have N of a feature that are all similar. For the former, we might have an app such as "blog", and then…
Within a single app, could this not be done mith multiple model files, and multiple services files. I usually organize my apps by having a services layer between models and views, such that the view functions have little to no knowledge about the underlying models. This, in place of nested apps, I have "upsmodels.py" and "upsservice.py" and the view functions handles routing logic.
Awesome ! we at Careers360 (India top 100 Alexa) use Django for everything, the best thing about an Opinionated stack like django is freshers are production ready at day 1, learning time reduces and maintainability is solid , although i prefer golang where frameworks are particularly not favored ,Django ORM surely lacks a lot of features but does a decent job, async story sucks unless you are willing to give in to Ch…
Earlier quoted context omitted.
But then you’re in Microsoft echo system. No bueno.
Would you mind expanding on this?