Re: Making max_length argument optional

Hello, This thread is getting long. It contains lots of valid arguments. In the interest of seeking consensus, here’s a tentative summary. Problem Typing `foo = models.CharField(max_length=100)` gets old quickly. Can we skip the `max_length` argument in many cases? Constraints Character

Translate permission Django

Hello, How to translate the default permissions django . Keywords ( Add, Delete ... ) -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it,

Add support for relative imports in django.conf.urls.include()?

For example, within myproject.urls: urlpatterns = ( url(r'', include('.myapp.urls')), ) .. becomes equivalent to:: urlpatterns = ( url(r'', include('myproject.myapp.urls')), ) Whilst a contrived example, this can make heavy-nested apps look far, far

Re: Add support for relative imports in django.conf.urls.include()?

I’m +0 on this change, for consistency with Python’s import statement. -- Aymeric. > On 29 Feb 2016, at 14:17, Tim Graham wrote: > > > For example, within myproject.urls: > > urlpatterns = ( > url(r'', include('.myapp.urls')), > ) > > .. becomes

Re: Add support for relative imports in django.conf.urls.include()?

The current approach can lead to surprising errors if include() is called by a helper function, rather than directly called in your urlconf. The relative import would be resolved in relation to the module where the helper function is defined. I'm not sure how much of an actual problem that is

Re: Translate permission Django

Re: Making max_length argument optional

Hi, Thank you, Aymeric, for summing up the discussion this way. The division into two separate problems is indeed required, and I fully support the idea of setting max_length's default to 100 or 120. There seem to be just two points worth adding to your summary: On Monday 29 February 2016

Re: Improving django.setup() and app loading performance

Hey all! Let me clarify a few of the terms here and describe a bit how Django operates in this context. "Serverless" in this contexts means "without any permanent infrastructure". The server is created _after_ the request comes in, and it dies once the response is returned. The means that we

Re: Improving django.setup() and app loading performance

For those who are still following along, these are the lines in question: https://github.com/Miserlou/django-zappa/blob/master/django_zappa/handler.py#L31 https://github.com/Miserlou/django-zappa/blob/master/django_zappa/handler.py#L68 It's very possible there are ways of significantly improving

Re: Add support for relative imports in django.conf.urls.include()?

Going off topic a little bit but.. have we considered deprecating string based includes in favour of actually importing the urls module? from . import myapp urlpatterns = ( url(r'^myapp/', include(myapp.urls.urlpatterns)), ) Then users can relatively import their nested app patterns as they

Re: Add support for relative imports in django.conf.urls.include()?

Hi Josh, On Monday, February 29, 2016 at 11:34:18 PM UTC+1, Josh Smeaton wrote: > > Going off topic a little bit but.. have we considered deprecating string > based includes in favour of actually importing the urls module? > I've tried to remove them as a proof of concept, but that's not

Re: Improving django.setup() and app loading performance

Sorry if this looks like a retarded question, but have you tried the setup calls to the top of the lambda_handler module? I'm not sure why you need the settings data as an argument to the lambda handler, but if you find a way to move those 4 lines near setup(), you will only load the whole

Re: Making max_length argument optional

I find that using TextField rather than CharField just to make postgres use varchar() is a terrible idea, if you are implementing an reusable app and it is used on a backend like MySQL where TextFields are created as text columns which are horribly inneficient and should be avoided at any cost

Re: Improving django.setup() and app loading performance

Haven't tried that! I don't _think_ that'll work.. but worth a shot (I don't think they only cache the handler.. I think they cache the whole environment). Will report back! And as you're mentioning, we really shouldn't be doing it every request, so if there were even a way to cache that

Re: Improving django.setup() and app loading performance

I'm almost sure that right now you are calling setup() with django already initialized in some cases where the enviorment is reused, I'm amazed django doesn't complain when setup() is called twice. El lunes, 29 de febrero de 2016, 21:07:32 (UTC-3), Rich Jones escribió: > > Haven't tried that! I

Re: Improving django.setup() and app loading performance

As I suspected, moving setup() outside of the handler had a negligible effect - in fact the test showed a slight drop in performance. :( Testing from httping. From Berlin to US-East-1: Before: --- https://arb9clq9k9.execute-api.us-east-1.amazonaws.com/unicode/json_example/ ping statistics ---

Re: Improving django.setup() and app loading performance

That's quite odd, I recall testing this once, where I created a lambda which had a datetime.now() at the top, and just returned that value. Out of a few calls, it returned two different results, meaning the module was re used "most" of the time. This was tested calling the lambda from the AWS

Re: Improving django.setup() and app loading performance

I have repeated the test this time through API Gateway, and out of many calls I only got two different dates that were instantiated at module level, meaning my module was only imported twice. I fail to see why it doesn't behave the same with your code. El lunes, 29 de febrero de 2016, 21:33:05

Re: Improving django.setup() and app loading performance

That certainly could have something to do with it - there isn't very much transparency about how API Gateway works. It's super new and pretty janky, TBQH. However, I think that the behavior describing is not what's expected - the caching seems to be for the assets of the whole environment, not

Re: Improving django.setup() and app loading performance

Rich, I have just performed a real test, with a simple lambda and a datetime.now() defined at the top of the module as I said, and out of 100 requests, this was the result: {u'2016-03-01T00:37:30.476828': [43], u'2016-03-01T00:36:51.536025': [58]} Where the date is the datetime.now() defined at

Re: Making max_length argument optional

>From what I understand you will have a hard time doing that at all: On PG could go with a 'max_length=None' in a 3rd party app. But that wouldn't be supported on any other database backend. Which means you're limiting your app to PG. On the other hand you could make your app database

Re: Improving django.setup() and app loading performance

Hm. This is the downside of cloud services - we cannot look under the hood. Since I think that since this is something we _want_ cached, and because it will make the function being executed shorter in length - it is a good code decision to make. Thank you for the idea! However, it looks like

Re: Improving django.setup() and app loading performance

I think I have found your issue, if I'm not wrong, django won't initialize twice if you call it twice (which was your previous behaviour) at least not completely, since apps registry has a "ready" flag. Check this line: https://github.com/django/django/blob/master/django/apps/registry.py#L66

Re: Improving django.setup() and app loading performance

Ah, interesting! Thanks for tracking that down. In chat we basically discovered that the intercontinental latency and shoddy wifi connections were responsible for a lot of the confusion. Testing from a US-based fiber connection, we got results of ~40ms in both scenarios. ---

Re: Improving django.setup() and app loading performance

In my opinion, those latencies are still a bit high, how much is really used on python/lambda code? On a project of mine without hitting the database and django-rest-framework my times were around 1-4ms excluding any network latency. Debug and loggers might have high impact on your times if

Re: Improving django.setup() and app loading performance

Hello Rich, > On 01 Mar 2016, at 01:44, Rich Jones wrote: > > I think the interesting things to explore would be: > - Loading apps in parallel > - "Pre-loading" apps before app deployment, then loading that cached state > at runtime. I guess I'd need to know more about