Re: Autocomplete in Django 1.11: Widget in Forms Library?

What about dynamic content datalist instead of complex autocomplete UI by JS libraries? We can use just jQuery or vanilla JS to make some AJAX requests and change datalist on the go. On Tuesday, September 20, 2016 at 9:30:33 PM

Re: Add an argument to ModelChoiceField for callable function to set label for instance.

I like this! Having read through the existing ticket and discussion, really the only reason given is a cultural one: that subclassing is the way this kind of behaviour "should" be achieved. I disagree – IME, APIs that encourage parametrising small chunks of behaviour are succinct and flexible,

Re: Add an argument to ModelChoiceField for callable function to set label for instance.

The approach you suggested was suggested in the thread of ticket you mentioned: https://groups.google.com/d/topic/django-developers/7DDEX73zVrI/discussion Brian Rosner: "I am a +1 on a configuration parameter since the alternative by subclassing is a bit too involved for something fairly

Add an argument to ModelChoiceField for callable function to set label for instance.

Older related ticket: https://code.djangoproject.com/ticket/4620 My rough draft of proposed changes: https://gist.github.com/mekhami/24af779f4f491d3c66e6fd607c2121aa/revisions The problem of setting the label for ModelChoiceField is one that comes up on IRC every once in a while. It's a

Re: request to reopen issue #23332 (using the dotted test name in test output)

Hmm if we're going down that path, I'd prefer to be more explicit about it. How about including the exact command that people can copy to re-run the failed test? This is what the RSpec library (a Ruby testing library) does, and IMO it really gets it right. See this blog post here from a Ruby

Re: request to reopen issue #23332 (using the dotted test name in test output)

I updated the Python issue to ask whether or not there's consensus to make the change there. Even if that issue proceeds, I guess it would be a nice convenience for current versions of Python that won't receive the change. http://bugs.python.org/issue22431 On Tuesday, September 20, 2016 at

Re: Challenge teaching Django to beginners: urls.py

Impressive! Using it in a project right now, so much nicer for a non-beginner like me too. No more regexs! Looking forward to a Django patched that allows casting of the variables too. /Emil On 2016-09-19 08:57, Sjoerd Job Postmus wrote: Just wanted to announce the following: it's

request to reopen issue #23332 (using the dotted test name in test output)

Hi, I would like to reopen the following issue from two years ago to change the test name in Django's test output from unittest's default to the full "dotted name": https://code.djangoproject.com/ticket/23332 This would make rerunning failing tests easier because then the test name could

Re: Challenge teaching Django to beginners: urls.py

Hi, Before I looked into the code, I found this really hard to believe. In my mind, the whole resolving framework would be built upon classes providing `resolve` and `reverse` methods. I was only partially right. I looked into it a bit more and wrote up my conclusions here:

Re: Starting maintenance on code.djangoproject.com

The maintenance is complete. If you find any issues creating or updating tickets, let me know. Thanks! On Tuesday, September 20, 2016 at 1:17:11 PM UTC-4, Tim Graham wrote: > > https://code.djangoproject.com/ is going down shortly for an upgrade. > I'll send an update if it takes more than an

Starting maintenance on code.djangoproject.com

https://code.djangoproject.com/ is going down shortly for an upgrade. I'll send an update if it takes more than an hour. -- 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

Re: Access to Wiki at code.djangoproject.com/wiki

I agree that a wiki page isn't the right medium for keeping that information up to date. -- Aymeric. > Le 20 sept. 2016 à 16:24, Tim Graham a écrit : > > I propose deleting that wiki page as well as similar pages like DjangoJobs > and DjangoResources. These days there

Re: PEP 484 type hinting in Django

Hey Graham. mypy has a structure to support multiple python versions as you noticed (and allows it to select them from the command line), but there's no mechanism for selecting library version. For me, supporting "the latest stable version" is a reasonable goal now. Flagging that appriopriately

Re: Access to Wiki at code.djangoproject.com/wiki

I propose deleting that wiki page as well as similar pages like DjangoJobs and DjangoResources. These days there are much better resources for those types of things and for me those pages are just causing extra work as far as monitoring for spam. If anyone thinks they should stay, please speak

Access to Wiki at code.djangoproject.com/wiki

Hi everyone, I was wondering if there is way to have edit access to wiki at code.djangoproject.com/wiki Since it's called wiki, I assume there is way to allow edit access to members? I would really like to update this page https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts which has

Re: Suggestion: Context manager for translation.activate

Could you just ignore that I've ever sent this mail? Apparently, I wasn't able to finde translation.override in the docs. Sorry for the noise. Raphael Am Tue, 20 Sep 2016 14:11:11 +0200 schrieb Raphael Michel : > Hi, > > in my application, I regularly need to switch the

Suggestion: Context manager for translation.activate

Hi, in my application, I regularly need to switch the active language for a short period of time. A popular example would be that a German-speaking user does something and I need to send out a notification to an English-speaking user. Cluttering the code with translation.activate() statements is

Re: Autocomplete in Django 1.11: Widget in Forms Library?

I haven't seen that proposal. This type of widget would be new territory for django.forms as none of the existing widgets require JavaScript. I lean toward keeping things that way, but I'm open to hearing counterarguments. Historically, Django avoided "blessing" any particular JavaScript