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

[Cheng Chi]

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 UTC+10, Tim Graham wrote:
>
> 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 libraries.
>
> On Tuesday, September 20, 2016 at 6:51:24 AM UTC-4, guettli wrote:
>>
>> I am happy that there will be support for autocomplete in the admin in 
>> 1.11, if this issue/pull-request gets resolved:
>>
>> https://code.djangoproject.com/ticket/14370
>>
>> https://github.com/django/django/pull/6385/
>>
>> I looked at the changes of the docs of this pull request.
>>
>> It seems that only the contrib module "admin" gets improved.
>>
>> Is it planed to add an autocomplete widget in the django forms library?
>>
>>
>>
>>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dd7c84fd-b51c-482a-913a-dd3bd6ccf33c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alexander Hill]

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, and are
often much more pleasant to deal with than subclassing.

For me there are two issues here. Firstly, the creeping cognitive burden –
another symbol in your IDE, another class to look up, more coupling, more
boilerplate, more tiny choices to make about what to call your class and
where to put it, etc.

The second issue is of readability: if I'm reading a form definition which
includes somebody's BookModelChoiceField, I don't know what that does.
Maybe all it does is override label_from_instance, but I don't know that
until I go look it up. However, as a Django user I do know what
ModelChoiceField does, I know the behaviour of the label_func parameter, so
I can take that all in at a glance and move on.

This all lies on a spectrum in that the more places you use your subclass,
the more justification it has for existing. But when subclassing is the
only solution, you end up defining classes that make only tiny changes to
behaviour and that you instantiate in only one place, and to me that's an
opportunity for improvement in an API.

Alex

P.S.

Another way I have dealt with this issue generically is by overriding
ModelChoiceField._get_choices() to return an overridden ModelChoiceIterator
which yields for each choice not a tuple, but a ModelChoice – a tuple
subclass with an "instance" attribute. It's a little convoluted, but it
means that in your template (and wherever else), you have access to the
actual model instance and can do whatever you like there. If you're not
doing custom things in your template it's not that useful, though.

See gist at
https://gist.github.com/AlexHill/4a5583ab8f983044e2ff04458b52ce4a



On Wed, 21 Sep 2016 at 10:09 Tim Graham  wrote:

> 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
> trivial."
>
> Why was it rejected? What new arguments are you bringing to the table that
> weren't considered before?
>
> You say that subclassing is a burden, but I'd argue that even redefining
> the field on the model form isn't DRY, at which point what about making the
> customization in the form's __init__()?
>
> self.fields['field_name'].label_from_instance = lambda obj: 'new label'
>
> I think the barrier to violate the Zen of Python ("There should be one--
> and preferably only one --obvious way to do it.") is a bit high here, so
> perhaps you could elaborate on how this is causing maintenance problems?
>
>
> On Tuesday, September 20, 2016 at 9:52:55 PM UTC-4, Lawrence Vanderpool
> wrote:
>>
>> 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 common enough problem that I think
>> the documentation-recommended solution of subclassing ModelChoiceField and
>> setting label_from_instance (
>> https://docs.djangoproject.com/en/1.10/ref/forms/fields/#modelchoicefield
>> ) is overkill, and probably a maintenance problem.
>>
>> ModelChoiceField already implements an optional callable in the
>> `get_limit_choices_to` function. This change would implement a similar API
>> to allow a callable to be passed in to the constructor rather than having
>> to do the subclassing dance.
>>
>> It'd still be backwards compatible, but the documentation should be
>> changed to reflect the "easier" solution of passing in the callable.
>>
>> The old ticket was labelled wontfix, but I think we should take a look
>> again. I'd love for this to be my first contribution to Django! Thanks for
>> any feedback. And if I forgot something or broke a rule for the ML, I
>> apologize in advance @.@
>>
> --
> 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, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f79d0b45-5073-4332-80df-0ca21cba1d98%40googlegroups.com
> 
> .

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

[Tim Graham]

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 trivial."

Why was it rejected? What new arguments are you bringing to the table that 
weren't considered before?

You say that subclassing is a burden, but I'd argue that even redefining 
the field on the model form isn't DRY, at which point what about making the 
customization in the form's __init__()?

self.fields['field_name'].label_from_instance = lambda obj: 'new label'

I think the barrier to violate the Zen of Python ("There should be one-- 
and preferably only one --obvious way to do it.") is a bit high here, so 
perhaps you could elaborate on how this is causing maintenance problems?

On Tuesday, September 20, 2016 at 9:52:55 PM UTC-4, Lawrence Vanderpool 
wrote:
>
> 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 common enough problem that I think the 
> documentation-recommended solution of subclassing ModelChoiceField and 
> setting label_from_instance ( 
> https://docs.djangoproject.com/en/1.10/ref/forms/fields/#modelchoicefield 
> ) is overkill, and probably a maintenance problem.
>
> ModelChoiceField already implements an optional callable in the 
> `get_limit_choices_to` function. This change would implement a similar API 
> to allow a callable to be passed in to the constructor rather than having 
> to do the subclassing dance.
>
> It'd still be backwards compatible, but the documentation should be 
> changed to reflect the "easier" solution of passing in the callable.
>
> The old ticket was labelled wontfix, but I think we should take a look 
> again. I'd love for this to be my first contribution to Django! Thanks for 
> any feedback. And if I forgot something or broke a rule for the ML, I 
> apologize in advance @.@
>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f79d0b45-5073-4332-80df-0ca21cba1d98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Lawrence Vanderpool]

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 common enough problem that I think the 
documentation-recommended solution of subclassing ModelChoiceField and 
setting label_from_instance 
( https://docs.djangoproject.com/en/1.10/ref/forms/fields/#modelchoicefield 
) is overkill, and probably a maintenance problem.

ModelChoiceField already implements an optional callable in the 
`get_limit_choices_to` function. This change would implement a similar API 
to allow a callable to be passed in to the constructor rather than having 
to do the subclassing dance.

It'd still be backwards compatible, but the documentation should be changed 
to reflect the "easier" solution of passing in the callable.

The old ticket was labelled wontfix, but I think we should take a look 
again. I'd love for this to be my first contribution to Django! Thanks for 
any feedback. And if I forgot something or broke a rule for the ML, I 
apologize in advance @.@

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/23d3d7ae-eb5b-409b-a9ec-a91ac0f22390%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Yoong Kang Lim]

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 core member for some comments (under
"things I like about RSpec", and yes, that's the actual domain name):

https://tenderlovemaking.com/2015/01/23/my-experience-with-minitest-and-rspec.html

Thoughts?



On Wed, Sep 21, 2016 at 4:56 AM, Chris Jerdonek 
wrote:

> 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 simply be copy and pasted from the command-line as is.
>
> Tim told me that to reopen the issue, it needed to be discussed on this
> list first and consensus reached. See Tim's comment (as well as some of my
> reasoning for why I think the issue should be reopened) here:
>
> https://code.djangoproject.com/ticket/27255
>
> I put together a patch here with tests so you can see the PR that I was
> planning to propose:
>
> https://github.com/cjerdonek/django/commits/dotted-name-test-output
>
> The approach is simply to subclass unittest.TextTestResult and override
> its getDescription() method to use the dotted name instead of unittest's
> current, less helpful format. Django already has an example of subclassing
> TextTestResult with its DebugSQLTextTestResult class.
>
> Thanks,
> --Chris
>
> --
> 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, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/5ab3f23b-04c0-455e-8f33-
> 7502e14f9fe9%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKL8yL6jNfkY6X3vwJxxAKJmnjKzi8H_qSpfH9i0sE350L4q5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim Graham]

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 8:16:27 PM UTC-4, Chris Jerdonek wrote:
>
> 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 simply be copy and pasted from the command-line as is.
>
> Tim told me that to reopen the issue, it needed to be discussed on this 
> list first and consensus reached. See Tim's comment (as well as some of my 
> reasoning for why I think the issue should be reopened) here:
>
> https://code.djangoproject.com/ticket/27255
>
> I put together a patch here with tests so you can see the PR that I was 
> planning to propose:
>
> https://github.com/cjerdonek/django/commits/dotted-name-test-output
>
> The approach is simply to subclass unittest.TextTestResult and override 
> its getDescription() method to use the dotted name instead of unittest's 
> current, less helpful format. Django already has an example of subclassing 
> TextTestResult with its DebugSQLTextTestResult class.
>
> Thanks,
> --Chris
>
>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b768f210-97a5-4f4d-b339-c54a5e77960e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Emil Stenström]

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 available on pypi:

https://pypi.python.org/pypi/django-simple-url/0.0.2

Kind regards,
Sjoerd Job

On Thursday, September 15, 2016 at 9:03:21 AM UTC+2, Sjoerd Job Postmus
wrote:

Hi :).

Yes, I also added the other syntax yesterday evening, so the
 syntax is now fully supported. (But it does not yield an
int!!).

Currently only `'int'` is registered as a valid type, with the regex
r'[0-9]+'. More can be registered using
`django_simple_url.register('hex', '[0-9a-fA-F]+')`.

One downside (still) is that it does not get cast to an int.
Although I'm not really sure if I find it logical that it gets cast.

I don't really have that much time to work on it, but I'm hoping to
add the `setup.py` either later today or shortly after the weekend.

Kind regards,
Sjoerd Job

On Thursday, September 15, 2016 at 8:20:03 AM UTC+2, Emil Stenström
wrote:

Great initiative!

I really think you should use the flask syntax instead of the
rails one that I first suggested. Seems this is the consensus
from this thread, and that makes it more likely to get it to
core one day.

/Emil

On Wednesday, 14 September 2016 11:02:23 UTC+2, Sjoerd Job
Postmus wrote:

Hi all,

Since it seemed like an interesting idea to me, I started
development of a third-party plugin.

It's currently at:
https://github.com/sjoerdjob/django-simple-url


Since I only started today, I have no readme/setup.py yet.
Will come later this week I hope.

Current usage is

from django_simple_url import simple_url

urlpatterns = [
simple_url('hello/world/', hello_world_view),
simple_url(':year/:month/', posts_for_month_view),
]

It works proper with includes (not adding a $ to the URL),
and leaf views (adding a $ to the URL).

Maybe this week, or early next week I will also add support
for the '' syntax.

Kind regards,
Sjoerd Job

On Tuesday, September 13, 2016 at 9:40:47 PM UTC+2, Tim
Graham wrote:

I would like to see if this could be done as a
third-party project (allow "pluggable URLs" which could
use any syntax). If not, then let's accept a patch to
Django to support it. Over time, if there's some strong
consensus about a particular third-party package, then
we could bring it in to core. I think this approach is
less controversial then Django adopting some new,
untested syntax right now.

On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil
Stenström wrote:

So it looks to me that the consensus is that this IS
in fact a good idea, to supply a simpler, regex-free
method to define URL:s.

It also seems that the best liked version is
something that's similar to what flask uses:
/articles///.

I've never written a DEP before, but it sounds like
a fun challenge. I'll try to look at existing DEPs
for a pattern and then apply that.

Does anyone have something in particular that they
would like to add to the DEP? I figure I'll try to
keep this first version as simple as possible, while
maintaining extension points for features that can
be added later on.

--
You received this message because you are subscribed to a topic in the
Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/django-developers/u6sQax3sjO4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
django-developers+unsubscr...@googlegroups.com
.
To post to this group, send email to django-developers@googlegroups.com
.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/54cdc465-ff11-47ab-905b-0ae6e19c4e83%40googlegroups.com

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

[Chris Jerdonek]

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 simply be copy and pasted from the command-line as is.

Tim told me that to reopen the issue, it needed to be discussed on this 
list first and consensus reached. See Tim's comment (as well as some of my 
reasoning for why I think the issue should be reopened) here:

https://code.djangoproject.com/ticket/27255

I put together a patch here with tests so you can see the PR that I was 
planning to propose:

https://github.com/cjerdonek/django/commits/dotted-name-test-output

The approach is simply to subclass unittest.TextTestResult and override its 
getDescription() method to use the dotted name instead of unittest's 
current, less helpful format. Django already has an example of subclassing 
TextTestResult with its DebugSQLTextTestResult class.

Thanks,
--Chris

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5ab3f23b-04c0-455e-8f33-7502e14f9fe9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

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: http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ .

TL;DR:

- The URL routing is mostly loosely coupled, with the exception of the 
`checks` and the `reverse` method. Furthermore, the `RegexURLResolver` is 
coupled to the idea that all sub-resolvers/patterns are also regex-based.
- By moving the `check` responsibility to the resolvers (same as with 
model-checks) and `reverse` responsibility to the resolvers as well, the 
coupling is lowered, and we would actually be able to switch in a 
completely different set of resolvers.
- It might be a good idea to make `RegexURLResolver.reverse` agnostic of 
the sub-resolvers.

Is there any form of coupling I missed?

Kind regards,
Sjoerd Job

On Friday, September 16, 2016 at 2:57:24 PM UTC+2, ludovic coues wrote:
>
> In my opinion, there is two point. First, core django should allow 
> different url resolver. Second, these different url resolver should 
> start as third party package. 
>
> Without first point, people need to hack django if they want to 
> experiment new kind of resolver. Like one providing typecasting or a 
> faster one or a localized one. And the resolver isn't "loosely 
> coupled" unlike most of the other part of django. 
>
> For the second point, I have a simple reason. Choosing between the 
> rail or the werkzeug syntax is bike shedding. It is not a technically 
> choice. It's an aesthetic one. There is no right answer, only lost 
> time. 
>
>
> 2016-09-16 9:30 GMT+02:00 Curtis Maloney  >: 
> > On 15/09/16 16:37, Curtis Maloney wrote: 
> >> 
> >> Somewhere I have code to provide a "parse" based URL router. 
> >> 
> >> Will dig it up now 1.10 has has shipped 
> > 
> > 
> > Ah, found it... 
> > 
> > So, here is a gist of a sample of using parse 
> > (https://pypi.org/project/parse/) instead of regex. 
> > 
> > https://gist.github.com/funkybob/3d90c57a837bc164d8b402a1c5b95a8b 
> > 
> > Since you can register extra type names, and those types can cast also, 
> it 
> > covers a lot of things some people expect [but don't get] from regex. 
> > 
> > 
> > -- 
> > C 
> > 
> > 
> >> 
> >> On 14 September 2016 6:38:20 PM AEST, Florian Apolloner 
> >>  wrote: 
> >> 
> >> Hi Emil, 
> >> 
> >> On Tuesday, September 13, 2016 at 9:50:22 PM UTC+2, Emil Stenström 
> >> wrote: 
> >> 
> >> and more experienced users are expected to switch over to using 
> >> regexes directly to get the exact behavior they want. 
> >> 
> >> 
> >> How so? Personally I would use this quite quickly since a few 
> >> builtin types would cover 99%. While I can write regex in sleep 
> >> nowadays, I still find it kinda tedious to redefine what "slug" 
> >> means in every URL I wanna match something… I am sure others think 
> >> the same. 
> >> 
> >> 
> >> Beginners likely won't look at all the different options and 
> >> choose one based on it's merits, they'll pick whatever their 
> >> teacher suggests they use. Also installing an extra package 
> when 
> >> setting up django feels a bit strange. 
> >> 
> >> 
> >> I think the eco system is far enough to support that, after all 
> >> south lived long and well as external package. Either way, DEP or 
> >> not, having an implementation out there would definitely help. 
> >> 
> >> Cheers, 
> >> Florian 
> >> 
> >> 
>
>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c455b2d2-39ec-43d8-af79-c276e3a60673%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Starting maintenance on code.djangoproject.com

[Tim Graham]

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 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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/da19298c-8828-4a41-b6f4-06bef0348d1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Starting maintenance on code.djangoproject.com

[Tim Graham]

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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b6ee02cb-994f-44e8-98a0-544a3e292fee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Aymeric Augustin]

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 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 up.
> 
>> On Tuesday, September 20, 2016 at 10:12:18 AM UTC-4, Nar Chhantyal wrote:
>> 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 lots of dead hosting sites.
>> 
>> I checked history and it seems changes to wiki is made after opening ticket. 
>> So I opened one here https://code.djangoproject.com/ticket/27252
>> 
>> If it is possible to have edit access, my code.djangoproject.com nick is: 
>> chhantyal
>> 
>> Thank you
> 
> -- 
> 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, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/132a20fb-a401-4af1-afb4-c43ffc2351c5%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/82C8D12F-507E-43E1-AF3B-9FB6AD6082CC%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: PEP 484 type hinting in Django

[Daniel Moisset]

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 may
become a problem in the future, but only if this succeeds, so I'm focusing
on making this useful right now :).

I already mentioned a naive approach (use different branches in the
typeshed repo to support different django versions), but I'm keen to hear
better ideas!

And of course, if we get this into the django codebase itself the problem
goes away (you get the annotations when installing django).

Best,
   D.


On Sun, Sep 18, 2016 at 9:00 AM, Graham Wideman 
wrote:

> Just making note of the typeshed project https://github.com/python/
> typeshed, "Typeshed models function types for the Python standard library
> and Python builtins, as well as third party packages."
>
> Pertaining to my earlier question about how pyi files should tell what
> version of a library they pertain to:FWIW, typeshed uses directory branches
> for different pyi files pertaining to different versions of Python, and
> version-range conditionals within pyi files. These version-selective
> devices pertain to version of Python. The interest in the discussion here
> would relate to version of Django, of course, where it seems similar
> measures might apply.
>
> --
> 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, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/5bf15a4b-8360-4ee0-a985-
> 01f42e7e27fd%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALuYSZUKScecmomhezjXfAgR%3D0jhUSz835CNvXF6jTXzP_Tn6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim Graham]

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 up.

On Tuesday, September 20, 2016 at 10:12:18 AM UTC-4, Nar Chhantyal wrote:
>
> 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 lots of dead hosting sites.
>
> I checked history and it seems changes to wiki is made after opening 
> ticket. So I opened one here https://code.djangoproject.com/ticket/27252
>
> If it is possible to have edit access, my code.djangoproject.com nick is: 
> chhantyal
>
> Thank you
>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/132a20fb-a401-4af1-afb4-c43ffc2351c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Access to Wiki at code.djangoproject.com/wiki

[Nar Chhantyal]

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 lots of dead hosting sites.

I checked history and it seems changes to wiki is made after opening 
ticket. So I opened one here https://code.djangoproject.com/ticket/27252

If it is possible to have edit access, my code.djangoproject.com nick is: 
chhantyal

Thank you

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/45543c03-b6cd-4993-8437-efd65cf99099%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: Context manager for translation.activate

[Raphael Michel]

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 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
> certainly not making the core more readable, which is why I'm now
> using a context manager:
> 
> with language(other_user.locale):
> send_mail()
> 
> language() is currently implemented in my project like this:
> 
> @contextmanager
> def language(lng):
> _lng = translation.get_language()
> translation.activate(lng or settings.LANGUAGE_CODE)
> try:
> yield
> finally:
> translation.activate(_lng)
> 
> This turned out to be very convenient and readable and I'd wanted to
> ask for your opinion if 
> 
> (a) something like this should be added to django
> (b) the activate() method itself should be changed to optionally work
> as a context manager
> 
> Cheers
> Raphael
> 

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20160920141233.7d7036da%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpMEgAif2NZY.pgp
Description: Digitale Signatur von OpenPGP

Suggestion: Context manager for translation.activate

[Raphael Michel]

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 certainly
not making the core more readable, which is why I'm now using a context
manager:

with language(other_user.locale):
send_mail()

language() is currently implemented in my project like this:

@contextmanager
def language(lng):
_lng = translation.get_language()
translation.activate(lng or settings.LANGUAGE_CODE)
try:
yield
finally:
translation.activate(_lng)

This turned out to be very convenient and readable and I'd wanted to ask
for your opinion if 

(a) something like this should be added to django
(b) the activate() method itself should be changed to optionally work as
a context manager

Cheers
Raphael

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2016092014.62ef589e%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpxloUreQIqG.pgp
Description: Digitale Signatur von OpenPGP

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

[Tim Graham]

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 libraries.

On Tuesday, September 20, 2016 at 6:51:24 AM UTC-4, guettli wrote:
>
> I am happy that there will be support for autocomplete in the admin in 
> 1.11, if this issue/pull-request gets resolved:
>
> https://code.djangoproject.com/ticket/14370
>
> https://github.com/django/django/pull/6385/
>
> I looked at the changes of the docs of this pull request.
>
> It seems that only the contrib module "admin" gets improved.
>
> Is it planed to add an autocomplete widget in the django forms library?
>
>
>
>

-- 
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, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6d4ace0b-bfeb-4617-ab9f-78cf314727ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.