Re: DEP Pre-posal: Re-Designing Django Forms

2018-02-01 Thread Marc Tamlyn
Hi Robert,

I have a whole heap of ideas about this, some of which are captured in
documentation here: http://django-adapters.readthedocs.io/en/latest/ The
code generally doesn't exist yet, but the project is at https://github.com/
mjtamlyn/django-adapters.

This is a *huge* project to achieve everything you mentioned in your email,
and it has implications across a large number of Django packages (not least
the admin). I don't want to discourage you, but don't underestimate how
much work it would be to get a good replacement for forms for the modern
web.

Your next steps should be to research, spec and potentially write a DEP.

Marc

On 31 January 2018 at 16:24, Collin Anderson  wrote:

> I personally use the (undocumented?) formfield() method, which takes the
> model defaults and lets you override things. I think it's pretty elegant,
> though maybe it could use some less verbose syntax (maybe have a
> forms.ModelDefault(label='Note') that does this for you).
>
> class NoteModalForm(forms.ModelForm):
> comment = Note._meta.get_field('comment').formfield(label='Note')
> is_blocker = Note._meta.get_field('is_blocker').formfield(label='Blocking
> Issue', initial=False)
> picture = Note._meta.get_field('picture').formfield(label='Picture',
> required=True, widget=DragNDropFileButtonInput(button_text='Select file
> to Upload', button_classes='btn btn-bordered uploader'))
>
> class Meta:
> model = Note
> fields = ['comment', 'is_blocker', 'equipment', 'picture']
>
> I should also note, you can change fields without overriding __init__;
> just use base_fields:
> NoteModalForm.base_fields['picture'].required = True
> NoteModalForm.base_fields['is_blocker'].initial = False
>
> As far as client-side validation goes, yes, Django really only does
> client-side validation that's available from plain html. Do you have some
> ideas for how dependent fields should work? I personally think it would be
> hard to find a one-size-fits all solution for more complicated cases, but
> it's probably possible. I think there are some 3rd party libraries that do
> this. I think a first step would be to natively handle dependent-fields
> programmatically in the back-end, so the form "knows" that those fields are
> related. Then maybe django could pass that relationship information to the
> html as data-* attributes.
>
> On Wed, Jan 31, 2018 at 10:31 AM, Robert Roskam 
> wrote:
>
>> Hey All,
>>
>> Something I've regularly run into as a challenge is the implementation of
>> Django forms work well in the simple use cases, but as the use case grows
>> in complexity, Django forms become more difficult to work with.
>>
>> I know that's a super general statement, but here's the simplest complex
>> example I can give you. Lets say you're making an application for a home
>> builder, so that their Project Managers can better coordinate the builds.
>> One of the features is the ability to take notes and pictures on anything
>> that's not yet done and specifically if it relates to a specific piece of
>> equipment (AC, furnace, water pump, etc), they can add that too. Below is a
>> moderately simplistic example:
>>
>> class Note(models.Model):
>> project = models.ForeignKey('project_management.Project',
>> related_name="notes")
>> equipment = models.ForeignKey('equipment.Equipment', null=True,
>> blank=True, related_name="notes")
>> picture = models.FileField(null=True, blank=True)
>> is_blocker = models.BooleanField(default=True)
>> comment = models.TextField()
>> created_by = models.ForeignKey('users.User', verbose_name="Created
>> By")
>> created_date = models.DateTimeField(default=timezone.now,
>> verbose_name="Created Date")
>>
>>
>> class NoteModalForm(forms.ModelForm):
>> class Meta:
>> fields = ('comment', 'is_blocker','equipment', 'picture')
>> model = Note
>> labels = {
>> 'comment': 'Note',
>> 'is_blocker': 'Blocking Issue',
>> 'picture': 'Picture',
>> }
>> widgets = {
>> 'picture': DragNDropFileButtonInput(button_text='Select file
>> to Upload',
>> button_classes='btn
>> btn-bordered uploader'),
>> }
>>
>>
>>
>> General comments first:
>>
>>1. I would say there's no better way to accomplish what is currently
>>on that form given the current Form Meta API. (Willing to be challenged on
>>this point, btw.)
>>2. The repetition of picture 3 times over (fields tuple, labels dict,
>>widgets, dict) seems to be inherently not DRY. If this gets very long, 
>> then
>>it becomes harder to manage.
>>3. The API on the Model Form itself behaves not quite like you'd
>>expect initially. You'd expect redeclaring fields directly on a form for 
>> it
>>to function like a dictionary update, if the value doesn't exist in the
>>incoming dictionary, it keeps what's 

Re: improving our Contributor License Agreement process

2018-01-11 Thread Marc Tamlyn
Accessibility of contributing > Leal protection

We shouldn't drop the idea of CLAs, they're there so that an organisation
or individual who wants to do things "properly" can still do so. But I
don't think we need to enforce it for any contribution.

The CLA story for Django is already hazy, as we don't require it for
"trivial" changes - https://www.djangoproject.com/foundation/cla/

I guess I'm with the "13 years with no problems". My understanding is they
protect Django (and its users) from someone claiming that a contribution
was made without license, and asking for it to be removed. This seems
pretty unlikely.

On 11 January 2018 at 15:49, Carlton Gibson 
wrote:

> Hey Tim.
>
> > It sounds like you have the enthusiasm for this that I had in 2014. ;-)
>
> Yeah. What I liked was that your proposal was like a "I've actually
> thought about this" version of what I was beginning to ponder myself. :-)
>
> I don't really think we should drop the CLAs. It's just that if they're
> not enforced then we don't address the issue they're meant to solve (which,
> if I understand it, is ultimately making sure companies can safely use
> Django without worrying about a withholding of rights at some key
> juncture.)
>
> So better... I thought... was if we can implement a decent, and easy,
> check.
>
> If the CLAs aren't really important then, well, I guess I would drop them
> (but I'm not hooked up on that — it's more a cognitive *huh?*)
>
> @Tobias, I see your post come in whilst writing this:
>
> I think the permissions there is for the backend CLA-provider, rather than
> the end user. i.e. it needs those permissions for the CLA (which you host
> in a Gist) and the build status for the CI check and so on.
>
> This is the hosted version you're looking there. I'd imagine we'd host our
> own, so those permissions would be internal.
>
> I imagine looking at that to be part of any assessment.
>
> The individual contributor would need to grant only the Personal Data bit.
> (I need to look into exactly the levels.) The flow—reading from the VSCode
> docs—is to fork and then make a PR, as normal, if you've not submitted the
> CLA you're then prompted to do so.
>
> https://github.com/Microsoft/vscode/wiki/Contributor-License-Agreement
>
> What I liked about it, is that it seemed to tick all the boxes.
>
>
> When Tim first proposed this in 2014 the summary seemed to be "Yes, we
> should do this, but it might be hard — oh, and we might not need to".
>
> Given that we still have the CLA, is it not still something that we should
> do?
>
> If not no worries.
>
> Regards,
>
> Carlton
>
>
>
>
>
>
> On Thursday, 11 January 2018 16:08:04 UTC+1, Tim Graham wrote:
>>
>> Hi Carlton,
>>
>> It sounds like you have the enthusiasm for this that I had in 2014. ;-)
>>
>> You could contact the DSF board if you want to try to get them to consult
>> a lawyer about the necessity of CLAs. I guess opinions might vary from
>> lawyer to lawyer.
>>
>> Given that Django has been operating for about 13 years without rigorous
>> enforcement of the CLAs, I guess I fail to see why we would need to start
>> rigorous enforcement now. Having CLAs available seems to be a good thing,
>> even if the comfort is mostly cognitive. I'm not sure what sort of legal
>> challenge Django would face where we would need CLAs. Collecting them seems
>> more an issue of purity than of practicality. I'm not a lawyer.
>>
>> On Thursday, January 11, 2018 at 9:27:17 AM UTC-5, Carlton Gibson wrote:
>>>
>>> I started reviewing patches according to the check-list this morning
>>> and, for first-time contributors, I was wondering how to validate the CLA
>>> status. Tim pointed me here.
>>>
>>> There is now (what looks like) a viable third-party provider:
>>>
>>> https://cla-assistant.io
>>>
>>> Amongst others, Microsoft use this for the VSCode project
>>> https://github.com/Microsoft/vscode/issues/34239
>>>
>>> (This looks better than rolling our own. Adding a CI check isn't that
>>> hard. There are services which do the document signing. etc. But then I
>>> take of the Programmer's Rosy Glasses and wince.)
>>>
>>> Can we assess CLA assistant to see if it would fit our needs?
>>>
>>>
>>> If we're not going to do something like this then would it be worth
>>> making the assessment of dropping the CLA? (If so, how could that be made
>>> to happen?)
>>>
>>> Regards,
>>>
>>> Carlton
>>>
>>>
>>>
>>> On Wednesday, 28 October 2015 12:44:54 UTC+1, Tim Graham wrote:

 Avoiding unnecessary work appeals to me, so I think it would be great
 to check with the lawyers before proceeding.

 On Tuesday, October 27, 2015 at 8:33:21 PM UTC-4, Russell Keith-Magee
 wrote:
>
> Hi Tim,
>
> On Wed, Oct 28, 2015 at 12:50 AM, Tim Graham 
> wrote:
>
>> In 2014 I started to research if we could offer a Google Summer of
>> Code project aimed at improving Django's process for collecting and
>> organizing CLAs. 

Re: models.CalculatedField feature

2017-11-16 Thread Marc Tamlyn
I like the idea, and have a number of concrete use cases I would use it
for. In one case I even have a custom manager which always applies a
particular `.annotate()` already, so it can be filtered and accessed on the
model.

I am inclined to agree with Shai that the fully database version should at
least be provided. If that aggregate is expensive, it could be `.defer()`ed
(this has its own problems of course). I'm not against the idea of the user
being able to provide a python implementation, but I think the database
version should be the default as it is more likely to be completely
consistent. I definitely think we should not be trying to automagically
create python versions of database functions.

Marc

On 16 November 2017 at 06:43, Shai Berger  wrote:

> On Thursday 16 November 2017 07:21:38 Josh Smeaton wrote:
> >
> > I don't agree with reimplementing lookups/transforms/funcs to produce the
> > python version of a SQL concept. It's a leaky abstraction. Instead, I'd
> > prefer the model author provides their python calculation:
> >
> > is_adult = models.CalculatedField(Q(age__gte=18), lambda c: c.age
> >= 18)
>
> (name shortened to fit in a 80-char line)
>
> I disagree. The way I see it, these calculated fields should essentially
> provide a declarative way to add an annotate() that's always going to be
> there. There should be only one source of truth, and that's the database;
> parallel implementations tend to disagree on fringe cases with
> disappointing
> results (e.g. consider if age above is nullable -- the database then makes
> the
> calculated field null, the python above makes it raise an exception). Or
> consider calculated fields which are aggregates -- a Python version could
> very
> easily become painfully inefficient.
>
> >
> > There may be destructuring/serialisation issues (migrations/pickle) using
> > lambda, unless we can ignore these model fields during deserialisation.
> >
>
> That's another (though minor) argument against lambdas here.
>
> No, the way I see it, the API should just use expressions. Of note, I
> think it
> should also support the output_field keyword. At the hand-waving,
> brainstorming
> level, I think we might, at some point, actually try to implement this by
> creating objects in the database (views on Postgres, computed columns on
> MySql, etc) -- so that the field is really available in all contexts.
>
> My 2 cents,
>
> Shai.
>
>

-- 
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/CAMwjO1GTx5wPxHsxOQV8LbtDWfD144f_na%2BC57hFBXeRhtS8aw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Automatic prefetching in querysets

2017-08-16 Thread Marc Tamlyn
last measured it).
>>
>> I feel it would be better to optimise for your usecase, as apposed to try
>> to prevent uncalled-for behaviour.
>>
>>
>>
>> On Aug 15, 2017 23:15, "Luke Plant" <l.pla...@cantab.net> wrote:
>>
>>> I agree with Marc here that the proposed optimizations are 'magical'. I
>>> think when it comes to optimizations like these you simply cannot know in
>>> advance whether doing extra queries is going to a be an optimization or a
>>> pessimization. If I can come up with a single example where it would
>>> significantly decrease performance (either memory usage or speed) compared
>>> to the default (and I'm sure I can), then I would be strongly opposed to it
>>> ever being default behaviour.
>>>
>>> Concerning implementing it as an additional  QuerySet method like
>>> `auto_prefetch()` - I'm not sure what I think, I feel like it could get
>>> icky (i.e. increase our technical debt), due to the way it couples things
>>> together. I can't imagine ever wanting to use it, though, I would always
>>> prefer the manual option.
>>>
>>> Luke
>>>
>>>
>>>
>>> On 15/08/17 21:02, Marc Tamlyn wrote:
>>>
>>> Hi Gordon,
>>>
>>> Thanks for the suggestion.
>>>
>>> I'm not a fan of adding a layer that tries to be this clever. How would
>>> possible prefetches be identified? What happens when an initial loop in a
>>> view requires one prefetch, but a subsequent loop in a template requires
>>> some other prefetch? What about nested loops resulting in nested
>>> prefetches? Code like this is almost guaranteed to break unexpectedly in
>>> multiple ways. Personally, I would argue that correctly setting up and
>>> maintaining appropriate prefetches and selects is a necessary part of
>>> working with an ORM.
>>>
>>> Do you know of any other ORMs which attempt similar magical
>>> optimisations? How do they go about identifying the cases where it is
>>> necessary?
>>>
>>> On 15 August 2017 at 10:44, Gordon Wrigley <gordon@gmail.com> wrote:
>>>
>>>> I'd like to discuss automatic prefetching in querysets. Specifically
>>>> automatically doing prefetch_related where needed without the user having
>>>> to request it.
>>>>
>>>> For context consider these three snippets using the Question & Choice
>>>> models from the tutorial
>>>> <https://docs.djangoproject.com/en/1.11/intro/tutorial02/#creating-models> 
>>>> when
>>>> there are 100 questions each with 5 choices for a total of 500 choices.
>>>>
>>>> Default
>>>> for choice in Choice.objects.all():
>>>> print(choice.question.question_text, ':', choice.choice_text)
>>>> 501 db queries, fetches 500 choice rows and 500 question rows from the
>>>> DB
>>>>
>>>> Prefetch_related
>>>> for choice in Choice.objects.prefetch_related('question'):
>>>> print(choice.question.question_text, ':', choice.choice_text)
>>>> 2 db queries, fetches 500 choice rows and 100 question rows from the DB
>>>>
>>>> Select_related
>>>> for choice in Choice.objects.select_related('question'):
>>>> print(choice.question.question_text, ':', choice.choice_text)
>>>> 1 db query, fetches 500 choice rows and 500 question rows from the DB
>>>>
>>>> I've included select_related for completeness, I'm not going to propose
>>>> changing anything about it's use. There are places where it is the best
>>>> choice and in those places it will still be up to the user to request it. I
>>>> will note that anywhere select_related is optimal prefetch_related is still
>>>> better than the default and leave it at that.
>>>>
>>>> The 'Default' example above is a classic example of the N+1 query
>>>> problem, a problem that is widespread in Django apps.
>>>> This pattern of queries is what new users produce because they don't
>>>> know enough about the database and / or ORM to do otherwise.
>>>> Experieced users will also often produce this because it's not always
>>>> obvious what fields will and won't be used and subsequently what should be
>>>> prefetched.
>>>> Additionally that list will change over time. A small change to a
>>>> template to display an extra field can result in a denial of service on
>&

Re: Automatic prefetching in querysets

2017-08-15 Thread Marc Tamlyn
Hi Gordon,

Thanks for the suggestion.

I'm not a fan of adding a layer that tries to be this clever. How would
possible prefetches be identified? What happens when an initial loop in a
view requires one prefetch, but a subsequent loop in a template requires
some other prefetch? What about nested loops resulting in nested
prefetches? Code like this is almost guaranteed to break unexpectedly in
multiple ways. Personally, I would argue that correctly setting up and
maintaining appropriate prefetches and selects is a necessary part of
working with an ORM.

Do you know of any other ORMs which attempt similar magical optimisations?
How do they go about identifying the cases where it is necessary?

On 15 August 2017 at 10:44, Gordon Wrigley  wrote:

> I'd like to discuss automatic prefetching in querysets. Specifically
> automatically doing prefetch_related where needed without the user having
> to request it.
>
> For context consider these three snippets using the Question & Choice
> models from the tutorial
>  
> when
> there are 100 questions each with 5 choices for a total of 500 choices.
>
> Default
> for choice in Choice.objects.all():
> print(choice.question.question_text, ':', choice.choice_text)
> 501 db queries, fetches 500 choice rows and 500 question rows from the DB
>
> Prefetch_related
> for choice in Choice.objects.prefetch_related('question'):
> print(choice.question.question_text, ':', choice.choice_text)
> 2 db queries, fetches 500 choice rows and 100 question rows from the DB
>
> Select_related
> for choice in Choice.objects.select_related('question'):
> print(choice.question.question_text, ':', choice.choice_text)
> 1 db query, fetches 500 choice rows and 500 question rows from the DB
>
> I've included select_related for completeness, I'm not going to propose
> changing anything about it's use. There are places where it is the best
> choice and in those places it will still be up to the user to request it. I
> will note that anywhere select_related is optimal prefetch_related is still
> better than the default and leave it at that.
>
> The 'Default' example above is a classic example of the N+1 query problem,
> a problem that is widespread in Django apps.
> This pattern of queries is what new users produce because they don't know
> enough about the database and / or ORM to do otherwise.
> Experieced users will also often produce this because it's not always
> obvious what fields will and won't be used and subsequently what should be
> prefetched.
> Additionally that list will change over time. A small change to a template
> to display an extra field can result in a denial of service on your DB due
> to a missing prefetch.
> Identifying missing prefetches is fiddly, time consuming and error prone.
> Tools like django-perf-rec 
> (which I was involved in creating) and nplusone
>  exist in part to flag missing
> prefetches introduced by changed code.
> Finally libraries like Django Rest Framework and the Admin will also
> produce queries like this because it's very difficult for them to know what
> needs prefetching without being explicitly told by an experienced user.
>
> As hinted at the top I'd like to propose changing Django so the default
> code behaves like the prefetch_related code.
> Longer term I think this should be the default behaviour but obviously it
> needs to be proved first so for now I'd suggest a new queryset function
> that enables this behaviour.
>
> I have a proof of concept of this mechanism that I've used successfully in
> production. I'm not posting it yet because I'd like to focus on desired
> behavior rather than implementation details. But in summary, what it does
> is when accessing a missing field on a model, rather than fetching it just
> for that instance, it runs a prefetch_related query to fetch it for all
> peer instances that were fetched in the same queryset. So in the example
> above it prefetches all Questions in one query.
>
> This might seem like a risky thing to do but I'd argue that it really
> isn't.
> The only time this isn't superior to the default case is when you are post
> filtering the queryset results in Python.
> Even in that case it's only inferior if you started with a large number of
> results, filtered basically all of them and the code is structured so that
> the filtered ones aren't garbage collected.
> To cover this rare case the automatic prefetching can easily be disabled
> on a per queryset or per object basis. Leaving us with a rare downside that
> can easily be manually resolved in exchange for a significant general
> improvement.
>
> In practice this thing is almost magical to work with. Unless you already
> have extensive and tightly maintained prefetches everywhere you get an
> immediate boost to virtually everything that touches the 

Re: Proposal: provide postgresql powered full-text search in djangoproject.com

2017-05-08 Thread Marc Tamlyn
Yes, don't need that sorry.

On 8 May 2017 at 14:40, Adam Johnson <m...@adamj.eu> wrote:

>  I'm pretty sure our search requirements on dp.com need that,
>
>
> s/need/don't need/ ? 
>
> On 8 May 2017 at 13:59, Marc Tamlyn <marc.tam...@gmail.com> wrote:
>
>> I'm not sure I see the benefit here. The strength and purpose of postgres
>> FTS is that you can combine some FTS behaviour with some relational queries
>> easily at the same time. I'm pretty sure our search requirements on
>> dp.com need that, so using a dedicated search provider is a better
>> option.
>>
>> On 7 May 2017 at 13:22, Florian Apolloner <f.apollo...@gmail.com> wrote:
>>
>>> On Sunday, May 7, 2017 at 12:45:27 PM UTC+2, Adam Johnson wrote:
>>>>
>>>> I guess we'd also have the benefit of not having to keep elasticsearch
>>>> running.
>>>>
>>>
>>> On the contrary, putting it into postgres means we have to care about
>>> it. Putting it into Elasticsearch means we can let our hoster take care
>>> about that.
>>>
>>>
>>>> But I'm afraid I'm not familiar with Postgres. Is the FTS in Postgres
>>>> mostly equivalent to ES, or will some kinds of search queries be affected?
>>>>
>>>
>>> For the queries we use I think we can get pretty much equivalent results.
>>>
>>> --
>>> 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/ms
>>> gid/django-developers/ecd3a1ea-63d9-430c-af79-951022fec138%4
>>> 0googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/ecd3a1ea-63d9-430c-af79-951022fec138%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>> 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/ms
>> gid/django-developers/CAMwjO1GFKbXyebkqmok_RYv3Hywq%3DfwXrfz
>> XcgFxtZU7-Ez5%3DA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAMwjO1GFKbXyebkqmok_RYv3Hywq%3DfwXrfzXcgFxtZU7-Ez5%3DA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> 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/CAMyDDM2w90gRXxLwJ30Bz1sutQxM%
> 3DFdZWpQgNcsmp5DemOSvFQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM2w90gRXxLwJ30Bz1sutQxM%3DFdZWpQgNcsmp5DemOSvFQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> 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/CAMwjO1Egq8xasdZ2eRxvX2Qb6mH7ygv2xcx0FmUXQyc4kjW5WA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal: provide postgresql powered full-text search in djangoproject.com

2017-05-08 Thread Marc Tamlyn
I'm not sure I see the benefit here. The strength and purpose of postgres
FTS is that you can combine some FTS behaviour with some relational queries
easily at the same time. I'm pretty sure our search requirements on dp.com
need that, so using a dedicated search provider is a better option.

On 7 May 2017 at 13:22, Florian Apolloner  wrote:

> On Sunday, May 7, 2017 at 12:45:27 PM UTC+2, Adam Johnson wrote:
>>
>> I guess we'd also have the benefit of not having to keep elasticsearch
>> running.
>>
>
> On the contrary, putting it into postgres means we have to care about it.
> Putting it into Elasticsearch means we can let our hoster take care about
> that.
>
>
>> But I'm afraid I'm not familiar with Postgres. Is the FTS in Postgres
>> mostly equivalent to ES, or will some kinds of search queries be affected?
>>
>
> For the queries we use I think we can get pretty much equivalent results.
>
> --
> 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/ecd3a1ea-63d9-430c-af79-
> 951022fec138%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/CAMwjO1GFKbXyebkqmok_RYv3Hywq%3DfwXrfzXcgFxtZU7-Ez5%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

2017-04-07 Thread Marc Tamlyn
I would be happy to revisit that decision which was made 9 years ago. APIs
returning unusual status codes such as 204 are much more common now than
they were then. I can't think of a good reason not to add ~10-15 2-line
classes.

Marc

On 7 April 2017 at 09:37, Brice PARENT  wrote:

>
> Le 07/04/17 à 08:54, Adam Johnson a écrit :
>
> Personally I'd be in favour of adding such classes. It seems against the
> batteries-included philosophy that Django does not provide all of the
> standard codes as classes. I can never remember which codes correspond to
> which response types, if I saw status=204 in code it would be a 'magic
> number' for me and I'd have to look it up. HttpResponseRedirect and H
> ttpResponsePermanentRedirect have been my friends in the past, I can
> imagine the same for HttpResponseNoContent.
>
> +1
>
> And there are more than just HttpResponseRedirect and 
> HttpResponsePermanentRedirect
> that are provided by now.
>
> In django.http.response, you can find :
>
> HttpResponseRedirect, HttpResponsePermanentRedirect,
> HttpResponseNotModified, HttpResponseBadRequest, HttpResponseNotFound,
> HttpResponseForbidden, HttpResponseNotAllowed, HttpResponseGone,
> HttpResponseServerError
>
> of which 7 don't embed any code, just the status code (like what is asked
> for 204).
>
> I'm not saying all of them are widely used enough to require an explicit
> class declaration (like status code 418) or even would mean anything in the
> context of a web framework, but the most common should, at least, be in the
> batteries. 204 is an example, but there probably are some others (like 426
> and 505, when the world is switching to https).
>
> -OR-
>
> We should at least provide a reversed version of django.http.response.
> REASON_PHRASES (which doesn't exist anymore, I think), so that we could
> call :
>
> HttpResponse(status=response_codes.no_content)
>
> It makes it way less cryptic for both the writer and the readers of the
> code.
>
> -Brice
>
> --
> 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/3d69e4e0-0f4a-3f75-3315-3b41c7569ffb%40brice.xyz
> 
> .
>
> 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/CAMwjO1F6qCBTyVhEN0MbkSh2fHJNt%3DFVyMTmQ%3Dn_Knt23HVPZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Adding generated common table expressions

2017-04-06 Thread Marc Tamlyn
Hi!

This looks generally very good, and I'm quite excited about it.

In terms of taking it forwards, I think a DEP is a very good idea, and
there are at least 3 core devs who are keen to see a solution. Whether you
have the right solution yet I'm not so sure, but it sounds like you're not
either.

Regarding Anssi's comments about SubQuery, we do now have that in core as
of 1.11 [0]. It does look like an .attach() approach might actually have
been a nicer version of this, but on the other hand it's currently
implementable solely with the Expressions API. It seems like the OuterRef
is very similar to your queryset.ref(). An even nicer approach using attach
could be to say qs.attach(q1=some_qs).filter(a=F('q1__b'))?

Looking forwards to seeing a DEP!

[0]
https://docs.djangoproject.com/en/1.11/ref/models/expressions/#subquery-expressions

On 22 March 2017 at 01:32, Ashley Waite  wrote:

> Here's the code changes I've made, noting that some of them were to shove
> in a generalised VALUES clause that mocks being a queryset, so that it
> plays with the same interface.
>
> https://github.com/django/django/compare/master...
> ashleywaite:cte-dev#files_bucket
>
> I've had a glance at cte-trees/cte-forest and once general CTEs are worked
> out expanding that to include recursive CTEs wouldn't be too difficult, and
> that would greatly simplify the implementation of cte-forest to the extent
> that it might be viable as a django data/reference type.
>
> - Ashley
>
>
> On Saturday, March 18, 2017 at 8:28:53 PM UTC+11, Josh Smeaton wrote:
>>
>> Thanks for bringing this up Ashley, and for all of the detail you
>> provided. I'd certainly like to see CTEs make their way into Django,
>> provided we could come up with a nice enough API. From the look of it,
>> you've already got something that works with an okay API so I'm hopeful.
>>
>> I'd be very interested in seeing your POC too if you're able to share.
>>
>> From looking very briefly at django-cte-trees it doesn't aim to support
>> user defined CTEs for anything other than recursive queries. I'd be
>> interested in seeing, as part of a DEP, how CTE inclusion in django core
>> could support the cte-trees project from an API perspective.
>>
>> On Friday, 17 March 2017 22:28:17 UTC+11, Ashley Waite wrote:
>>>
>>> Hey all,
>>>
>>>
>>> I'd like to suggest adding Common Table Expression (CTE) query
>>> generation as a feature to Django.
>>>
>>> I've been working on a project that required manipulation of many
>>> records at once, and as with many ORMs found that this wasn't an ideal
>>> use-case in Django. As the rest of our code base and related projects are
>>> in Django, there was a strong preference to find a way to do it and keep to
>>> the same model-is-the-truth design.
>>>
>>> I first did this by writing some hackish functions using raw querysets
>>> and generating my own CTE based queries, but it lacked ideal flexibility
>>> and maintainability. So I've now written some modifications into my Django
>>> to do this in a more Django-esque way and think that this functionality
>>> would be beneficial within the project itself, but am unsure exactly where
>>> to start the conversation about that.
>>>
>>>
>>> *Why generate CTE based queries from querysets?*
>>>
>>> By allowing querysets to be attached to each other, and setting
>>> appropriate WHERE clauses, arbitrary and nested SQL queries can be
>>> generated. Where the results of the queries are only necessary for the
>>> execution of following queries this saves a very substantial amount of time
>>> and database work. Once these features exist, other functionality can also
>>> transparently use these to generate more efficient queries (such as large
>>> IN clauses).
>>>
>>> This allows several powerful use cases I think Django would benefit from:
>>>
>>>
>>> *Large 'IN' clauses*, can be implemented as CTEs reducing expensive
>>> lookups to a single CTE INNER JOIN. For sets of thousands to match from
>>> tables of millions of records this can be a very substantial gain.
>>>
>>>
>>> *Composite 'IN' conditions,* where multiple fields must match and
>>> you're matching against a large set of condition rows. In my usage this was
>>> "where the md5/sha hashes match one of the million md5/sha tuples in my
>>> match set". This is simply a CTE JOIN with two clauses in the WHERE.
>>>
>>>
>>> *Nested data creation*, where the parent doesn't yet exist. Django
>>> doesn't currently do this as the primary keys are needed, and this makes
>>> normalised data structures unappealing. Using INSERTs as CTEs that supply
>>> those keys to following statements means that entire nested data structures
>>> of new information can be recreated in the database at once, efficiently
>>> and atomically.
>>>
>>>
>>> *Non-uniform UPDATE*s, such that a modified set of objects can all be
>>> updated with different data at the same time by utilising a CTE values
>>> statement JOINed to the UPDATE statement. As there's 

Re: Vietnamese Django full text search in postgres.

2017-04-05 Thread Marc Tamlyn
Hi Cử Nhữ Văn,

This mailing list is for development of Django itself, rather than support
queries. You may get a better answer on the main mailing list or on #django
on IRC.

You may also find some help about different languages in the docs:
https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/search/#postgresql-fts-search-configuration

On 2 April 2017 at 16:23, Cử Nhữ Văn  wrote:

> Hi Django developers!
> I'm newbie in django. I have a problem with Vietnamses full text search in
> postgres DB. Please help me!
> I have a website supported English and Vietnamese. When I search with
> English, everything ok. When I search with Vietnamese, I got problem:
> When i inputed "gia" it only return result of "gia". But I need result
> include "gia, giá, giả, già".
> I got nothing when i search on google. Does Django support this? and how
> can i implement?
> Thank you so much!
>
> --
> 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/4b69805b-376b-4c55-ae25-
> ed05ecb83547%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/CAMwjO1Gi7%3DkRdC6JEi%2BxSqOFOJX%2B1_0E-BjGLhKjaVy_x0g9CA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Provide 'V' as alias for 'Value'?

2017-04-05 Thread Marc Tamlyn
Given that you can always do import Value as V, I'm not sure providing an
alias is necessary.

On 3 April 2017 at 12:15, Josh Smeaton  wrote:

> I think I proposed V as an alias back when I was writing the patch, but
> the rough consensus at the time was that one letter class names are a bit
> of an anti pattern (Q, F) that we shouldn't persist with. Aliasing V in the
> examples was my way of sneaking the idea through for those who chose to act
> similarly. I'd be ok with providing an alias, but I think examples should
> still import the Value name to make the code more clear what V actually
> refers to.
>
> On Monday, 3 April 2017 17:58:43 UTC+10, Adam Johnson wrote:
>>
>> When writing filter expressions using database functions, one is often
>> forced to use django.db.models.Value to wrap raw values to avoid them
>> being interpreted as column references. Value is fairly cumbersome to
>> write when it can appear several times in a complex queryset definition, so
>> it's common to alias it as V when importing. In fact, the database
>> function docs do this exclusively
>> .
>>
>> Because import as is sometimes considered bad style, but the V alias is
>> useful, I'd like to propose django.db.models having a documented
>> internal alias like V = Value. I'm writing here because I can't think of
>> a precedent in Django, except for backwards compatibility reasons.
>>
>> --
>> Adam
>>
> --
> 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/1e4d267e-7441-489f-a2ac-
> c23f34cd246c%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/CAMwjO1G-ukY24jpU_SGoTDTg7aXwOYv81xkgfbjDdZpOnv4zRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Permission classes for Class Based Views

2017-03-16 Thread Marc Tamlyn
I don't feel there is any need for this feature in Django. As you mention
in the ticket, there are ways of approaching it used in DRF, there are
other ways in django-braces[0], I personally have my own taste in how to
handle it. The details will depend on the logic necessary - sometimes you
need to load objects to check permission, sometimes you don't. There is no
one size fits all approach.

[0]
http://django-braces.readthedocs.io/en/latest/access.html#permissionrequiredmixin

On 16 March 2017 at 20:10,  wrote:

> Hello, my first post here!
>
> This post is about a new feature request I'd like to propose and it's
> about permission classes (just like I've stated in topic) for CBVs. I've
> provided most of the technical information at [0], because I think that
> such information is more ticket-specific, however I'm not sure if what I
> did is a correct way, because docs say that feature requests should begin
> their lifespan at the mailing list. Well, anyway basically saying the
> reason to have it in core Django is to make managing "who can do what" in a
> simpler, faster and more expendable manner.
>
> I believe that everything that we need to discuss the matter is already at
> [0] so I'd be extremely happy if somebody would reply with some thoughts
> about it.
>
> [0] https://code.djangoproject.com/ticket/27950
>
> --
> 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/605eddf3-147a-4e39-a9fb-
> 4e40f055c4d6%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/CAMwjO1ECf3cgaZxxN6D530v-cig2m%3D3KdVfDuow1rZZrTQQirQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Template handling of undefined variables

2017-02-20 Thread Marc Tamlyn
+1 to not having to add (and then remove later) a {% load %} tag to every
template - that was seriously dull with the URL change.

Marc

On 20 February 2017 at 11:42, Luke Plant  wrote:

> On 19/02/17 12:55, Adam Johnson wrote:
>
> +1 for more obvious errors, silently changing the behaviour could indeed
> lead to unconsidered security holes like
>
> {% if user is None %}
> non-sensitive information
> {% else %}
> sensitive information
> {% endif %}
>
> ...which doesn't seem like an unrealistic template snippet. We all know
> variables can go missing in refactorings.
>
> Another option, perhaps not feasible to implement, would be deprecating
> the old behaviour, similar to the previous change in url with something
> like:
>
> {% load undefined_vars from future %}
>
>
> I agree there are a lot of potential security/correctness issues with
> this, it is potentially quite a big change (though very helpful IMO).
>
> A different approach to introducing it might be a setting, possibly an
> option to the Django template engine instead - https://docs.djangoproject.
> com/en/1.10/ref/settings/#std:setting-TEMPLATES-OPTIONS . I think this
> would be more appropriate for something that is more of a global behaviour
> issue, more practical than having to add hundreds of 'load from future'
> tags, plus it would then parallel other similar settings like
> 'string_if_invalid'. In the next version of Django the option would default
> to False (i.e. old behaviour), but raise a deprecation warning, in future
> versions it would simply be True, and raise an error if someone tries to
> pass False (but allow True, for the sake of apps that are spanning multiple
> Django versions).
>
> This would allow people to test their site with the new mechanism and have
> time to fix issues, which can be especially important for 3rd party Django
> apps.
>
> Ideally there would be some way to instrument code and see if the output
> would be different with the new behaviour, but I can't think of an easy way
> to do this.
>
> Luke
>
> --
> 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/496fa4a8-b902-657a-92c2-9766bfff8a26%40cantab.net
> 
> .
>
> 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/CAMwjO1GmpDk8ByyEW2tjpstV9OpfPNokfGKNgufEmDWFhi27hQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Should Model.save() fix incorrect types that happen to save correctly?

2017-02-14 Thread Marc Tamlyn
Agreed - ensuring that this works in the general case is not reliable.

On 13 February 2017 at 15:51, Adam Johnson  wrote:

> What do you think? Absent a better suggestion, we could document this
>> pitfall so that there's something to point to when related tickets come in.
>
>
> +1, as Aymeric points out the more complex fields probably won't work with
> coercion-on-set.
>
> On 13 February 2017 at 15:27, charettes  wrote:
>
>> > What do you think? Absent a better suggestion, we could document this
>> pitfall so that there's something to point to when related tickets come in.
>>
>> I also think this is the most appropriate solution.
>>
>> Le lundi 13 février 2017 09:57:49 UTC-5, Tim Graham a écrit :
>>>
>>> Once in a while, there's a ticket about this behavior:
>>>
>>> m = Model(decimal='12.9')
>>> m.save()
>>> self.assertEqual(m.decimal, '12.9')
>>> m.refresh_from_db()
>>> self.assertEqual(m.decimal, Decimal('12.9'))
>>>
>>> That is, you can create a model with an incorrect type and it won't be
>>> fixed until you refresh the object from the database.
>>>
>>> Most recent complaint, "it is only a basic expectation that the DB layer
>>> and the Application layer will correspond to each-other after performing
>>> save, which is in other words, syncing your state with the DB.
>>> Personally, this bug (one way binding between application and db on save)
>>> broke many of my tests and took a lot of my time." [0] See [1] for another
>>> manifestation of this.
>>>
>>> I think calling to_python() in Model.save() would have unacceptable
>>> performance consequences for little benefit considering that it's a
>>> reasonable expectation for developers to provide the correct type. Further,
>>> you can use full_clean() to coerce to the correct types:
>>>
>>> m = Model(decimal='12.9')
>>> m.full_clean()
>>> self.assertEqual(m.decimal, Decimal('12.9'))
>>>
>>> What do you think? Absent a better suggestion, we could document this
>>> pitfall so that there's something to point to when related tickets come in.
>>>
>>> [0] https://code.djangoproject.com/ticket/27825
>>> [1] https://code.djangoproject.com/ticket/24028
>>>
>> --
>> 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/ms
>> gid/django-developers/4e59974e-9916-434e-8840-4f42996e5052%
>> 40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> 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/CAMyDDM1B0RJa928Yvk0uXenU009ts
> U%3DFDtPW_u2gmpgXTVpdFQ%40mail.gmail.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/CAMwjO1GtZwarHJ7joqTHo%3DR3euM40gbOqMc%3DyXeCO8g8AS3Rig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: SubQuery without using RawSQL

2017-01-12 Thread Marc Tamlyn
Subquery is one word so the lowercase Q would be correct yes. I'm skewed
from using SubQuery in my code for the last few months, so that looks fine
to me, but let's not get into another query_set problem

On 12 January 2017 at 13:11, Adam Johnson  wrote:

> I vote for Subquery - I wouldn't make a class called SubTitle  Also
> SubQuery somewhat implies it's a subclass of Query. I think Josh has been
> staring at Query for too long 
>
> On 12 January 2017 at 12:30, Tim Graham  wrote:
>
>> A question about the casing. Since "subquery" is one word, I wouldn't
>> camel case it like SubQuery. Any other opinions?
>>
>> Josh says, "I prefer the CamelCased SubQuery visually. Subquery looks
>> strange to me, even if it technically can be one word."
>>
>> On Wednesday, April 20, 2016 at 3:06:06 AM UTC-4, schinckel wrote:
>>>
>>> I started some work late last night on attempting to replace some
>>> RawSQL() calls that do a sub query with a new Expression.
>>>
>>> It actually worked!
>>>
>>> Even in the cold light of day, it doesn't seem _too_ bad, so after
>>> working on it a bit today with jarshwah, I decided to stick up a WIP PR.
>>>
>>> https://github.com/django/django/pull/6478
>>>
>>> I'd love to have some further input.
>>>
>> --
>> 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/ms
>> gid/django-developers/e987bf04-c42a-4985-8785-2683acbafda8%
>> 40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> 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/CAMyDDM1ixo%3DV%3Dw%3Dhak1KcowfdGdVkJ%
> 3DjrwPmaymER%3DC39U3_Aw%40mail.gmail.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/CAMwjO1F5K46fi1zgT2GcY4T%2BQ%2BQsamr7FufNMvbUTjaQJhSnXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

2017-01-12 Thread Marc Tamlyn
DEFAULT_CONTENT_TYPE does sound like a setting which shouldn't exist.

On 12 January 2017 at 10:53, Adam Johnson  wrote:

> Having reviewed the ticket a bit and thought about it, I've had two
> thoughts:
>
>1. The current patch doesn't fix existing custom views
>
> 
>which the docs explain how to use, and I've seen used quite often. It's
>quite likely custom views just return TemplateResponses.
>2. We could fix this instead by making the admin 'incompatible' with
>DEFAULT_CONTENT_TYPE being set to anything other than text/html with a
>system check to warn against / enforce this. This is possible because admin
>is a contrib app rather than part of django core. But perhaps the end
>result is probably similar to deprecating it, since many (most?) projects
>use the admin.
>3. This is actually the first time I heard about DEFAULT_CONTENT_TYPE and
>I think it's quite surprising that it's a setting and can affect all
>installed apps like this. After all, if a project is sending a lot of e.g.
>XML responses, it's possible, and probably clearer, to do similar to this
>PR and subclass TemplateResponse to set a new default for content_type.
>
>
> On 10 January 2017 at 18:15, Tim Graham  wrote:
>
>> According to ticket #23908 [0],
>>
>> By using the setting:
>>
>>
>> DEFAULT_CONTENT_TYPE = "application/xhtml+xml"
>>
>>
>> The admin site no longer renders correctly.
>>
>>
>> Do you think we should try to fix this by having all the admin responses
>> specify content_type="text/html"? That requires a lot of changes [1] -- I'm
>> not sure if discouraging the use of that setting might be acceptable
>> instead. I imagine any third-party app that provides templates has this
>> same problem.
>>
>>
>> [0] https://code.djangoproject.com/ticket/23908
>>
>> [1] https://github.com/django/django/pull/7807
>>
>> --
>> 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/ms
>> gid/django-developers/7dd3a2df-5cfb-4eec-b949-7147cb5bdf24%
>> 40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> 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/CAMyDDM1ndB51AYfO-RzTahXgSs%
> 3D4sktXdNs8KDPYV4Q7HsP9-Q%40mail.gmail.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/CAMwjO1E0gsWgExibxSYT5PMSr0Htn%3DW5A5MNVBwkvqmyj0jD0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Responsive admin

2017-01-09 Thread Marc Tamlyn
I'd suggest including this with a mechanism (on the admin site?) to disable
it for a while if that causes problems for existing custom setups?

Marc

On 9 January 2017 at 11:59, Adam Johnson  wrote:

> - perhaps supplying an empty CSS file with the same name overrides the
>> file provided by the admin? (I’m not sure)
>
>
> It does, as long as the app it's in is before django.contrib.admin in
> INSTALLED_APPS, django-grappelli
>  uses this mechanism
> to extend/replace the admin's javascript and styles.
>
> I'm totally +1 for the responsive CSS too, thanks for your work on
> django-flat-theme!
>
> On 9 January 2017 at 11:50, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hello Elky,
>>
>> I’d love to see this responsive design merged in Django. I’m using the
>> admin from my phone quite often and the lack of a responsive design makes
>> that painful.
>>
>> The admin gets very few CSS changes. I don’t think we should refrain from
>> adding a useful responsive design out of fear that it will be hard to
>> maintain.
>>
>> An opt-out mechanisms for third-party apps that don’t want the responsive
>> styles will a nice touch (but not absolutely necessary in my opinion). I
>> don’t think a setting is appropriate. I’d rather use the template or static
>> file overriding mechanisms, for example:
>> - perhaps supplying an empty CSS file with the same name overrides the
>> file provided by the admin? (I’m not sure)
>> - alternatively responsive styles could apply only within
>> body.responsive; the admin’s template would have a > class=“responsive”>; third party apps could override that template and
>> remove the class
>>
>> Thanks for you work on the admin’s style,
>>
>> --
>> Aymeric.
>>
>> On 9 Jan 2017, at 11:59, elky  wrote:
>>
>> Hi guys,
>>
>> Few months ago I released *django-flat-responsive*
>>  app - a simple
>> extension for admin that makes interface mobile and tablet friendly. I
>> tested it on few complex projects using major mobile browsers and it works
>> good. Now I'm going to make pull request to Django repo but before I want
>> to ask community -- is it necessary to have responsive admin?
>>
>> My thoughts:
>>
>> Pros:
>> - It's modern
>> - Few times I really needed to make some edits inside admin through my
>> mobile (it was painful), so I think some people want admin to be responsive
>>
>> Cons:
>> - New admin features should be always tested on mobile devices (or on
>> different screen sizes at least). It also uses CSS3 flexbox so developers
>> shoul learn how it works
>> - 3rd party apps should care about responsive layout. It's not so easy
>> for some apps like Django Admin Tools or some CMS based on admin
>>
>> As fas as django-flat-responsive just adds one CSS file to static folder,
>> what if to have an option in *settings.py* that enables responsive admin?
>>
>> I would glad to hear your thoughts
>>
>> 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/ms
>> gid/django-developers/dd915c1d-d8a8-4f91-a223-268e17044cd1%4
>> 0googlegroups.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/ms
>> gid/django-developers/5A95FC83-B1DD-408C-94B7-9A4E81A6F1D3%4
>> 0polytechnique.org
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> 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 

Re: Guidelines to name python modules of Django applications?

2016-12-07 Thread Marc Tamlyn
What Aymeric and Florian sayid.

On 7 December 2016 at 15:58, Florian Apolloner 
wrote:

> On Wednesday, December 7, 2016 at 1:10:48 PM UTC+1, Aymeric Augustin wrote:
>>
>> I still think I wouldn't use a django_ prefix when I create new apps
>> because
>> it adds a small but pervasive overhead to prevent conflicts that aren't
>> common
>> in practice.
>>
>
> Same here, I am certainly against making that a recommendation from/in
> Django itself.
>
> 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/ba0114d9-0baa-4662-8fff-
> f7c9b03b90d3%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/CAMwjO1Goo0er0UfRVWe3P0vbdPdJZxzzV8L50PjrRvFi0R8gYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: automating Django releases

2016-11-26 Thread Marc Tamlyn
I'm pretty confident we can just automate the process you currently do.

On 26 November 2016 at 05:40, Josh Smeaton  wrote:

> I think automating as much of the release process is a fantastic idea.
> Regarding bumping the release numbers, have you seen the bumpversion
> project https://pypi.python.org/pypi/bumpversion?
>
> After some trial and error, I seem to have a configuration that works with
> the existing version tuple in django/__init__.py. Bumping the release
> number will change the VERSION tuple. The existing get_current_version will
> continue to work as normal, as will the setup.py. You can experiment with
> the tag/commit options and other options - the hard part is getting the
> serialize and parse options correct. This configuration goes in the
> existing setup.cfg.
>
> [bumpversion]
> current_version = (1, 11, 0, 'alpha', 0)  # you have to set this the first
> time, then bumpversion updates it along with the VERSION tuple in
> django/__init__.py
> commit = False
> tag = False
> serialize = ({major}, {minor}, {patch}, {prerel}, {prerelnum})
> parse = \((?P\d+),\s(?P\d+),\s(?P\d+),\s(?P<
> prerel>\'alpha\'|\'beta\'|\'rc\'),\s(?P\d+)\)
>
> [bumpversion:file:django/__init__.py]
>
> [bumpversion:part:prerel]
> values =
> 'alpha'
> 'beta'
> 'rc'
>
> And here's an example run:
>
> $ bumpversion patch --list
> current_version=(1, 11, 0, 'alpha', 1)
> new_version=(1, 11, 1, 'alpha', 0)
>
> $ bumpversion patch --list
> current_version=(1, 11, 1, 'alpha', 0)
> new_version=(1, 11, 2, 'alpha', 0)
>
> $ bumpversion minor --list
> current_version=(1, 11, 2, 'alpha', 0)
> new_version=(1, 12, 0, 'alpha', 0)
>
> $ bumpversion prerel --list
> current_version=(1, 12, 0, 'alpha', 0)
> new_version=(1, 12, 0, 'beta', 0)
>
> $ bumpversion prerel --list
> current_version=(1, 12, 0, 'beta', 0)
> new_version=(1, 12, 0, 'rc', 0)
>
> $ bumpversion prerelnum --list
> current_version=(1, 12, 0, 'rc', 0)
> new_version=(1, 12, 0, 'rc', 1)
>
> $ bumpversion major --list
> current_version=(1, 12, 0, 'rc', 1)
> new_version=(2, 0, 0, 'alpha', 0)
>
> With regards to Jenkins, you could have a release project with parameters
> of BRANCH and VERSIONPART and whatever else was needed. The VERSIONPART
> would feed into the bumpversion command.
>
> I think this way reduces backward compatibility concerns.
>
> On Saturday, 26 November 2016 06:49:54 UTC+11, Tim Graham wrote:
>>
>> After doing releases about once a month for a while, I'm thinking it
>> would be nice if releasing Django could be a bit more automated. As far as
>> I know, the process hasn't changed too much in 10 years, while the state of
>> Python packaging has improved.
>>
>> Currently doing a release requires bumping the VERSION tuple in
>> django/__init__.py [0], creating tarball/wheel and checksum files, asking
>> someone in IRC to verify the checks look fine, and upload files to various
>> locations [1]. My idea would be to use setuptools_scm [2] (that choice
>> because this is the only tool I know about) to eliminate the need to
>> bump/set a VERSION tuple and instead fetch the version information based on
>> git tags. Something like (based on what I found in djanog-hosts [3]):
>>
>> __version__ = pkg_resources.get_distribution('django').version
>>
>> One issue I'm not sure how to deal with is how to provides
>> backwards-compatibility for django.VERSION, the tuple format that looks
>> something like:
>>
>> VERSION = (1, 11, 0, 'alpha', 0)
>>
>> I think removing or deprecating it would be quite disruptive for the
>> community as I've seen lots of third-party apps that do checks like "if
>> django.VERSION < (1, 9): ...", for example. I suspect it's possible to
>> parse the version string to create something similar, but I wondered if
>> anyone has experience with that.
>>
>> Finally, uploading to PyPI and djangoproject.com (release and checksum
>> files) could be done automatically by Jenkins or something similar.
>>
>> Thanks for your comments, concerns, and suggestions.
>>
>> [0] https://github.com/django/django/blob/6252fd6314f66d2d303cc4
>> 7c791ffefd27169b42/django/__init__.py#L5
>> [1] https://docs.djangoproject.com/en/dev/internals/howto-releas
>> e-django/#actually-rolling-the-release
>> [2] https://github.com/pypa/setuptools_scm
>> [3] https://github.com/jazzband/django-hosts/blob/0eae77b31927dd
>> b0267943d6f9bcfc22f14706f2/django_hosts/__init__.py#L11
>>
> --
> 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/f36b9371-f292-47c5-a417-
> c6557e5a2557%40googlegroups.com
> 

Re: drop compatibility with Python < 2.7.8?

2016-11-15 Thread Marc Tamlyn
I'd be inclined to agree with Claude.

On 15 November 2016 at 07:20, Claude Paroz  wrote:

> I wouldn't spend too much energy about Python 2.7 stuff. Let the
> workarounds in place, and just wait for Python 2 to die. I don't see the
> point in forcing people of stable Debian-based distributions to install a
> custom Python for 1.11.
>
> --
> 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/e146d3c8-3d29-4ef3-8357-
> 09a2e1ae2f34%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/CAMwjO1F6sm-S%2BsaRiztDAr1rHCHDWF4Js9RQ-StFRno7JZZ%3D0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Getting full URL using django.urls.base.reverse - PR

2016-11-11 Thread Marc Tamlyn
Given we already have `request.build_absolute_uri(path)`, I'm not 100% sure
what extra this gives us. It's a bit of syntactic sugar for sure, but it
solves a pretty narrow use case. The only times I've actually needed this
has been when sending emails and I'm using a `Site` object instead of
request.

In a way, this fits in with the work on a new URL resolving system,
especially if like the "URL" resolution in channels it can take other
attributes of the request. This would make things like Django hosts easier
to build, as well as nice things like resolution based on URL scheme. If we
go down that route, then it makes sense for `reverse` to take kwargs like
`host` or `scheme` as it may be needed to work out which route to use
anyway.

I'm definitely -1 on a threadlocal request.

Marc

On 11 November 2016 at 08:14, Mislav Cimperšak 
wrote:

> Thinking about url tag and threadlocals is a step in the wrong direction.
>
> The original PR is just a simple addition (that is still backwards
> compatible) to the `reverse` method; how people choose to use it (and when)
> is up to them. Adding something to the `url` tag is almost bound to brake
> something.
> This implementation does not brake anything regarding `url` tag and can
> stand on it's own.
>
> I've talked to several people on sprints in Amsterdam before submitting a
> PR and it sounded like a good idea to them and reassured with DRF
> implementation I went with it :)
>
> On Sat, Nov 5, 2016 at 11:04 PM, Florian Apolloner 
> wrote:
>
>> On Saturday, November 5, 2016 at 6:56:29 PM UTC+1, Sjoerd Job Postmus
>> wrote:
>>>
>>> If you go with storing the base domain in the threadlocals, why not go
>>> full in and store the request itself in the locals? [1]
>>>
>>
>> Because that opens a whole new can of worms, if possible we want less
>> threadlocals, not more…
>>
>>
>>> As far as using it in the templates... We have a RequestContext right?
>>> So in most cases that should not be an issue I presume.
>>>
>>
>> Still leaves the question of how to nicely pass this to the url tag.
>>
>> But yes, Celery would be a problem, unless we push the request object to
>>> celery as well, but I presume that makes mostly no sense except for this.
>>>
>>
>> Yeah, I didn't think that through :)
>>
>> --
>> 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/to
>> pic/django-developers/-rbLcdJkIpk/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/ms
>> gid/django-developers/84fc3b7a-4263-46bb-a292-e27215952e63%
>> 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/CACcAD09g-yCWw6U5WS-ykKJRG5poWnrBCEOTGFO6YrQKgCKeP
> Q%40mail.gmail.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/CAMwjO1EBwxMsmmqW1gikndx8B%3DZep6AeWDEmmF3koMDpH83BMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: New deferred loading implementation (Was: [Review Request] Added support for database delegated fields (like AutoField))

2016-11-08 Thread Marc Tamlyn
I have fed a lot into this discussion in person and on Slack. I don't
understand all the ins and outs completely, but I feel that the situation
is sufficiently complex enough that we need to consider it all together.
The code was certainly very challenging when I tried to make a UUID field
use a DB generated value and "return properly" when used as a pk, hence the
substandard docs for it. I'm personally -0 on the readonly patch unless it
does fit into a genuine coherent design.

I personally believe we do need a DEP, and it needs to have the following
attributes:
- Discussion of all the problems - refresh, read only, database level
defaults, primary keys and the auto generated "id" field.
- Clear reference to all previous attempts to solve part(s) of the problem
- A clear plan as to how all the use cases will be solved by the proposed
design
- A road map of how to build the pieces one ticket at a time. readonly may
fit into this, it may not, that depends on the plan.

This will allow everyone, but especially the technical board, to understand
all the considerations.

Hope that helps. I may be overcomplicating the problem, but I don't think I
am.
Marc

On 8 November 2016 at 13:59, Joachim Jablon  wrote:

> We were having a discussion on this matter on the Django under the Hood
> Slack channel, and there's a design decision that I think I can't take by
> myself.
>
> There are 2 related subject : the "readonly" part and the "auto_refresh"
> part. Readonly means that the database won't try to write, autorefresh
> means that when creating /updating an instance, the value will be fetched
> from the database automatically
>
> There was a debate on whether the readonly behaviour should imply
> auto_refresh, and there are cases that are good candidates for auto_refresh
> without readonly (autofields, serial fields etc.).
>
> What I'd suggest, if we can get an agreement on this, would be to define
> those 2 behaviours completely independently (possibly as 2 different PRs,
> each with their tests and docs and such).
>
> Auto_refresh could then be used for autofields with the quirk that some
> SQL DBs, will provide last_insert_rowid() (sqlite) or LAST_INSERT_ID()
> (mysql), while other use RETURNING (PGSQL / Oracle) allowing to use a
> single query.
>
> Readonly, on its side, would only be a simple independent feature and its
> behaviour would do what the title says, no more, no less.
>
> Do you think I need to do a DEP on this ?
> If not, do you think it's ok if https://github.com/django/django/pull/7515 is
> changed to only do the readonly part, and we make another PR (and possibly
> ticket) for the "auto_refresh" part ?
>
> While it would be nice to have both landing at the same time on master, I
> feel there's nothing blocking if they land at separate time, even in
> separate versions if need be (the freeze on Django 1.11 is coming fast,
> IIRC).
>
> Are there usecases that I'm missing and that could not be expressed as a
> mix of readonly and auto_refresh ?
>
> Le lundi 7 novembre 2016 15:35:38 UTC+1, Aymeric Augustin a écrit :
>>
>> On 7 Nov 2016, at 13:44, Joachim Jablon  wrote:
>>
>> > My own personal opinion: 1. refesh by default, add an argument to
>> "model_instance.save()" to opt-out. 2. readonly
>>
>> I agree.
>>
>> --
>> Aymeric.
>>
>> --
> 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/3db52e5b-54db-4736-845b-
> 58a22b6f015c%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/CAMwjO1FC1EAdJACQ8f3Hxy%2B13XPBh56KTfGMPeKyY2Ss_1zXqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Built-in router link generator in Django

2016-10-03 Thread Marc Tamlyn
This doesn't seem like something which is the responsibility of core django
to me. There are dozens of different ways to build your menus, I don't see
anything about that package which makes it the best way of doing it.

On 3 October 2016 at 03:24, Val Neekman  wrote:

> Folks,
>
> I am wondering if Django would benefit from the inclusion of this package
> or something like it?
>
> https://github.com/un33k/django-menuware
>
> A utility module to auto generate links from configuration.
>
> Thanks,
> Val
>
>
> --
> 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/6df84fa1-e831-4ee2-abaf-
> e140d9e28b89%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/CAMwjO1EcCBp%3DYyr0c39L3n2YeiyiK4Gm4Fq7aWndsXdYzmxWEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Challenge teaching Django to beginners: urls.py

2016-09-15 Thread Marc Tamlyn
Fwiw, I spent a little time investigating this a couple of years ago. I
would like to see Django officially bless the idea of alternative URL
systems, and provide the "full" regex system and preferably at least one
"simple" system - even if all that system supports is integers and slugs.
This would allow third party authors to focus on designing their "to regex"
translation, rather than the details of Django's resolving.

I did some investigation into swapping at a "deeper" level, including
allowing mixed includes from one resolver type to another. This is made
somewhat harder by the removal of "patterns", and was much more complex.
However it did give much more flexibility in allowing URL patterns which
route based on other attributes than the path. I dont have any working
code, it was very conceptual. I think we should at least consider a more
dramatic approach in a DEP, even if it is not the intended course.

Marc

On 15 Sep 2016 9:52 a.m., "Sjoerd Job Postmus"  wrote:

>
>
> On Thursday, September 15, 2016 at 10:38:09 AM UTC+2, Michal Petrucha
> wrote:
>>
>>
>> As cool as this idea sounds, I really don't think the URL dispatcher
>> is a correct component to make database queries. FWIW, I've seen
>> similar magic implemented in view decorators, and the thing I remember
>> the most from this experience was that it made it a lot harder to
>> follow what was happening where.
>>
>> Moreover, I can imagine this turning into a complicated mess of a
>> syntax to allow query customizations using a weird DSL really quickly.
>> After all, if we allow PK lookups, it's not that unreasonable to also
>> want to be able to lookup by other keys, and it all goes downhill from
>> here.
>>
>> Cheers,
>>
>> Michal
>>
>
>
> Agreed. It all goes downhill from there, so let's at least not do database
> queries.
>
> To me, that settles it: no typecasting.
>
> --
> 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/d9db908b-d22b-428f-908a-
> ecdc34b8fbfb%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/CAMwjO1HjuF8_c-sZef4oByK%3DrZKz4aWTPp1OvSS%3DGGRaqGOfQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django default PK type setting

2016-09-05 Thread Marc Tamlyn
For what it's worth I think this is *much* harder than it appears on the
surface. Whilst setting another field as the PK is easy, setting another
base type as an "auto" field is surprisingly tricky - lots of AutoField
assumes integers.

However, I do think it has some merits. An obvious benefit to the
consistency is when you are using another framework with Django which makes
certain assumptions about the way you identify objects. Some front end
frameworks prefer guids to integers, as would some security protocols.

M

On 1 Sep 2016 5:49 p.m., "Emett Speer"  wrote:

> I agree with you in recommending against using `.filter(pk=1)` in testing.
>
> What do you think of the idea though. Do you think it would be worth
> looking into adding a flag for new projects or not worth the time/effort to
> add it.
>
> On Wednesday, August 31, 2016 at 10:11:55 PM UTC-7, Shai Berger wrote:
>>
>> On Thursday 01 September 2016 02:51:54 Josh Smeaton wrote:
>> > A major issue with this would be the many apps out in the wild (and
>> their
>> > tests!) that assume the pk is an integer, and do queries like
>> > .filter(pk=1).
>>
>> FWIW, this is a bad practice which we should recommend against. In
>> databases
>> which rely on sequences, after you've run some tests, the pk of the first
>> record in a table is not necessarily 1 (because records in the table are
>> removed when test transactions are rolled back, but sequence values are
>> not
>> re-used). Similar issues can arise in parallel execution of tests.
>>
>> [This is a bit off-topic for the pk-type setting idea, I know]
>>
>> Shai.
>>
> --
> 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/4422aad9-a9aa-4076-b24a-
> 659c0594e4f9%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/CAMwjO1F9_ftSGLnaGQPp73CLrn6L167qVZMeTOOuasiTEWZSkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: FEATURE REQUEST: Choices overriding in a classes, which inherit abstract class

2016-08-26 Thread Marc Tamlyn
Adding a new meta option is very unlikely to happen.

Really, this is a question about dynamic choices, rather than just
inheritance. I'd rather see some sort of solution which allows some
(optional) hooks to customise choices on a per-class (or maybe even per
instance) basis. This is tricky though as choices are generally seen to be
a static attribute of the field.

On 25 August 2016 at 16:09, Anton Ponomarenko 
wrote:

> From the doc: "Abstract base classes are useful when you want to put some
> common information into a number of other models". In my current project I
> put all common fields in abstact class, but those fields that use 'choice'
> option may have different choices in different child classes.
>
> Code Example:
>
> class AbstractProfile(models.Model):
> # Basic choices, which may vary in different classes
> PRIVACY_CHOICES = (
> (1, _('all')),
> (2, _('no one')),
> )
>
> title = models.CharField(_('title'), max_length=30)
> info = models.TextField(_('information'), max_length=500, blank=True)
> info_privacy = models.IntegerField(_('show information to'), default=1
> , choices=PRIVACY_CHOICES)
>
> city = models.CharField(_('location'), max_length=30, blank=True)
> address = models.CharField(_('address'), max_length=30, blank=True)
> address_privacy = models.IntegerField(_('show address to'), default=1,
> choices=PRIVACY_CHOICES)
>
> class Meta:
> abstract = True
>
> class UserProfile(AbstractProfile):
> PRIVACY_CHOICES = (
> (1, _('all')),
> (2, _('friends')),
> (3, _('friends of friends')),
> (4, _('only me')),
> )
>
> GENDER_CHOICES = (
> (1, _('man')),
> (2, _('woman')),
> )
>
> title = None
>
> first_name = models.CharField(_('first name'), max_length=30, blank=
> True)
> last_name = models.CharField(_('last name'), max_length=30, blank=True
> )
> names_privacy = models.IntegerField(_('show names to'), default=1,
> choices=PRIVACY_CHOICES)
>
> birth_date = models.DateField(_('birth date'), null=True, blank=True)
> birth_date_privacy = models.IntegerField(_('show birth date to'),
> default=1, choices=PRIVACY_CHOICES)
>
> gender = models.IntegerField(_('gender'), null=True, blank=True,
> choices=GENDER_CHOICES)
>
> avatar = models.ImageField(upload_to='users/avatar', null=True, blank=
> True)
>
> class CompanyProfile(AbstractProfile):
> PRIVACY_CHOICES = (*** new choices, which are different to those
> which are in abstract class ***)
>
> class TeamProfile(AbstractProfile):
> pass
>
> There is a proposition to add to the 'class Meta' a new attribute, which
> lets to define, whether to use CHOICES from abstract class or use those
> which exists in the current class, something like:
> class UserProfile(AbstractProfile):
> PRIVACY_CHOICES = (
> (1, _('all')),
> (2, _('friends')),
> (3, _('friends of friends')),
> (4, _('only me')),
> )
>
> GENDER_CHOICES = (
> (1, _('man')),
> (2, _('woman')),
> )
>
> title = None
>
> first_name = models.CharField(_('first name'), max_length=30, blank=
> True)
> last_name = models.CharField(_('last name'), max_length=30, blank=True
> )
> names_privacy = models.IntegerField(_('show names to'), default=1,
> choices=PRIVACY_CHOICES)
>
> birth_date = models.DateField(_('birth date'), null=True, blank=True)
> birth_date_privacy = models.IntegerField(_('show birth date to'),
> default=1, choices=PRIVACY_CHOICES)
>
> gender = models.IntegerField(_('gender'), null=True, blank=True,
> choices=GENDER_CHOICES)
>
> avatar = models.ImageField(upload_to='users/avatar', null=True, blank=
> True)
>
> class Meta:
> use_choices = [PRIVACY_CHOICES]
>
> Possible variants:
> Variant A: Use CHOICES from abstract class - do not add anything to 'class
> Meta'
> Variant B: Use CHOICES from current class instead of abstract class - add:
> class Meta:
> use_choices = [*** list of choices of current class **]
>
> Variant C: Same as B, but change format a bit:
> class Meta:
> use_choices = ((ABSTRACT_CHOICES_NAME1, CURRENT_CLASS_CHOICES_NAME1),
> (ABSTRACT_CHOICES_NAME2, CURRENT_CLASS_CHOICES_NAME2),)
> just in case, if a developer for some reasons have different names of
> choices
>
> This feature lets to have development process as DRY as possible, which is
> the reason why abstract class exists.
>
> In order to solve it, currenty I use the next code:
> # models.py
> class UserProfile(AbstractProfile):
> PRIVACY_CHOICES = (
> (1, _('all')),
> (2, _('friends')),
> (3, _('friends of friends')),
> (4, _('only me')),
> )
>
> # NEW PIECE OF CODE
> def __init__(self, *args, **kwargs):
> def get_class_attrs(cls):
> return re.findall(r'\w+(?=[,\)])', cls.__dict__['__doc__'])
>
> super(UserProfile, 

Re: SearchQuery concatenation (`&` and `|`) is either broken or documentation incomplete

2016-08-25 Thread Marc Tamlyn
Yup, that sounds like an oversight on my part. The fix would be exactly as
Josh described.

On 25 August 2016 at 13:54, Josh Smeaton <josh.smea...@gmail.com> wrote:

> Hi Nicola,
>
> Without a lot of familiarity of SearchQuery, in particular, it looks like
> a bug to me. SearchQuery defines its own operators to work around the
> limitation in Combinable, but fails to take into account that when two
> SearchQuery instances are combined, you're returned a CombinedExpression
> (containing SearchQueries). SearchVector *does* take this into
> consideration though, and provides it's own Combinable Mixin, so I wonder
> if the limitations for SearchQuery aren't on purpose.
>
> Marc Tamlyn would probably have a good idea if this was an oversight or
> deliberate.
>
> The fix would be to define a SearchQueryCombinable Mixin that looks very
> similar to SearchVectorCombinable, and override the various __or__ and
> __and__ methods, as the SearchQuery type does itself. Hope that helps?
>
> Regards,
>
> On Thursday, 25 August 2016 21:30:06 UTC+10, Nicola wrote:
>>
>> Dear Django-Developers,
>>
>> We just started using the new search ability that landed in Django 1.10
>> (using postgres).
>>
>> Reading the documentation[1], I thought I can use `&` and `|` to join
>> search queries as I like[2]. This is not the case, which can easily be seen
>> by creating a the test-case with two ampersands or pipes[3].
>>
>> I would not expect that the test-cases pass, but they error out:
>> `NotImplementedError: Use .bitand() and .bitor() for bitwise logical
>> operations.`.
>>
>> To me this is not the expected behaviour, but maybe I deducted the wrong
>> conclusions from reading the documentation.
>>
>> My unanswered questions:
>>
>>- Is it a bug?
>>- Is this the intended behaviour?
>>   - If so: what needs to be done to get a note into the
>>   documentation, that only one ampersand/pipe is allowed?
>>
>> Thank you for your time and effort for this excellent framework!
>>
>> Kind Regards,
>>
>> Nicola
>>
>>
>> [1]: https://docs.djangoproject.com/en/1.10/topics/db/
>> search/#postgresql-support and https://docs.djangoproject
>> .com/en/1.10/ref/contrib/postgres/search/
>> [2]: https://docs.djangoproject.com/en/1.10/ref/contrib/
>> postgres/search/#searchquery
>> [3]: https://github.com/django/django/compare/master...hixi:master
>>
> --
> 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/31548201-3d01-4318-8165-
> 47cad2afa1fc%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/31548201-3d01-4318-8165-47cad2afa1fc%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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/CAMwjO1F%2BYNvvY73qRmAiw0k7TAE1910iR6%2BtV_Rq7Lo5w%3DcuQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: change commit message format to present tense?

2016-06-24 Thread Marc Tamlyn
This post by Tim Pope is considered the "definitive guide to commit
messages" as far as I'm aware.

http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

+1 to adopting this style.

On 24 June 2016 at 19:15, Jon Dufresne  wrote:

> On Fri, Jun 24, 2016 at 10:48 AM, Carl Meyer  wrote:
>
>> To be clear, the recommended git style is not present tense, it is
>> imperative mood. So it should _not_ be "Fixes #12345 -- Regulates the
>> frobnicator", it should be "Fix #12345 -- Regulate the frobnicator."
>>
>
> Do you have a link to an authoritative source stating this as the
> recommended style or is it just common knowledge?
>
> I'm not arguing against the proposal (in fact, I agree with it), I'm just
> curious if there is documentation to support one style over the other.
>
> Cheers,
> Jon
>
> --
> 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/CADhq2b4zz8Dd8%3Dh7PSuMvFOFok3Tn-K0JsQkVkNNiBKphkBH%2Bg%40mail.gmail.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/CAMwjO1FMheLWko-f6FvHAVRUTDfTuEbxbJd9yfw3oFfUOTQUQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Use migrations api to create a command for data migration between different databases

2016-06-14 Thread Marc Tamlyn
I'd suggest your approach is also quite slow. Andrew Godwin did something
similar once at a lower level - see
https://github.com/lanyrd/mysql-postgresql-converter (use at your own risk)

On 10 June 2016 at 19:44, Bruno Ribeiro da Silva 
wrote:

> The problem here is that this works well for small databases, but for
> bigger ones it uses too much memory and is a slow process.
>
> On Fri, Jun 10, 2016 at 3:22 PM, Stephen J. Butler <
> stephen.but...@gmail.com> wrote:
>
>> I usually just use dumpdata/loaddata to do these kinds of things.
>>
>> On Fri, Jun 10, 2016 at 12:47 PM, Bruno Ribeiro da Silva <
>> bruno.dev...@gmail.com> wrote:
>>
>>> Hey guys, I'm not sure if I should be asking this here, but it's related
>>> to django internals.
>>>
>>> I have this idea to create a command that uses the migrations api to
>>> migrate all the data from one database (eg. MySQL) to another database
>>> (PostgreSQL).
>>>
>>> So I would run the migrations in the new target database, then flush all
>>> the tables there, and model by model do a bunch of bulk_create into the new
>>> database using the result queryset from the source database.
>>>
>>>
>>> The questions are: do you think it is feasible to make all of this
>>> inside a command? If I have to change the migrations api to make it happen,
>>> do you think this could be a nice feature to have in Django?
>>>
>>>
>>> Thanks 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/1f588512-dc82-4182-a87b-cbdabea71a11%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/CAD4ANxWFjR0FJimBrk-1WqEHYzw3hc%2Bf949u3DGhKexrmkM%3Deg%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Bruno Ribeiro da Silva
> Python Dev and Homebrewer!
>
> --
> 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/CAE-2%3DJxMSXtLsF03OFBrF6CChTJL3AQDnJK_Q_u2AuktjSk5NQ%40mail.gmail.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/CAMwjO1FTo_j17ETgNH6jyL%2BqsEqo5pv6kda7Z_tKFY2u%2Bk%2BfHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Clearing prefetch related on add(), change(), remove()

2016-06-08 Thread Marc Tamlyn
I didn't know queryset.update did clear the internal cache. In that case
it's pretty reasonable. I think it should only clear a .all() cache though,
not any prefetched set.

On 7 June 2016 at 22:38, Florian Apolloner <f.apollo...@gmail.com> wrote:

> Same feeling as Carl here. I was probably the first to get asked whether
> or not this was a bug or not on IRC and my initial thought was also "wtf,
> that is clearly a bug" -- hence I asked Yoong Kang Lim to open a ticket.
>
> Cheers,
> Florian
>
>
> On Tuesday, June 7, 2016 at 7:47:29 PM UTC+2, Carl Meyer wrote:
>>
>> On 06/07/2016 06:11 AM, Marc Tamlyn wrote:
>> > I may be "too close" to knowing the implementation of this feature to
>> be
>> > able to comment on whether the behaviour is surprising to most people,
>> > but it doesn't surprise me. It's certainly analogous to that when you
>> do
>> > `MyModel.objects.create()` it doesn't change an already executed
>> > queryset. There's a question of where you draw the line as well - what
>> > about `related_set.update()`?
>> >
>> > I think it's worth documenting the behaviour, also noting that you can
>> > "force" the execution of a new queryset by chaining another .all().
>>
>> Hmm, I have the opposite instinct. I don't find it analogous to the case
>> of some unrelated queryset object failing to update its internal cache
>> when the database changes. In this case we have a related-manager with
>> an internal cache, and we make changes _via that same manager_. I find
>> it quite surprising that the manager doesn't automatically clear its
>> cache in that case.
>>
>> A much stronger precedent, I think, is the fact that Queryset.update()
>> does clear the queryset's internal result cache. In light of that, I
>> think the current behavior with prefetched-data on a related manager is
>> a bug that should be fixed (though it certainly should be mentioned in
>> the release notes).
>>
>> Carl
>>
>> --
> 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/61cce517-3117-42ec-aceb-de8bb3a7b7cc%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/61cce517-3117-42ec-aceb-de8bb3a7b7cc%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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/CAMwjO1H0%3D%2BKefZPwBCkBx5rX722rjp84n5Re2mSLYSAVtq74yA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Clearing prefetch related on add(), change(), remove()

2016-06-07 Thread Marc Tamlyn
I may be "too close" to knowing the implementation of this feature to be
able to comment on whether the behaviour is surprising to most people, but
it doesn't surprise me. It's certainly analogous to that when you do
`MyModel.objects.create()` it doesn't change an already executed queryset.
There's a question of where you draw the line as well - what about
`related_set.update()`?

I think it's worth documenting the behaviour, also noting that you can
"force" the execution of a new queryset by chaining another .all().

On 7 June 2016 at 13:26, Yoong Kang Lim  wrote:

> Hi all, I'd like to bring up ticket #26706:
> https://code.djangoproject.com/ticket/26706
>
> Related managers have methods such as add(), change() and remove() that
> change database objects. When a prefetch_related is done prior to calling
> these methods, it does not clear the cache. When the related field is
> accessed, it returns the cached result instead of the updated result. A
> couple of tickets have been opened, as this does seem to be surprising
> behaviour.
>
> I was working on a patch to address this, but Tim brought up some concerns
> about backward compatibility regarding the change and directed me here to
> get some community consensus. The change I'm proposing will clear the cache
> (for the prefetched field) when any of the methods are called. If we
> introduce this, it will be a backwards-incompatible change, so I'd just
> like to get some opinions on what the best way forward would be. Obviously
> in either case the behaviour should be documented.
>
> Also a thought just occurred to me -- if we don't put this change in,
> could we, as an alternative solution, extend the API to let the user decide
> what to do with the cache? Maybe something like
> clear_prefetched_field(related_field_name) on the manager so that at least
> the user has a choice instead of running the query (although the trouble
> they would need to go through would be similar, IMO).
>
> --
> 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/eabd9567-53e3-413b-9b30-dbcfbf9c2634%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/CAMwjO1EkD_gfr6rGrFe%3DGY5YRXCs5qYoKYmw8zST94GLJOHECA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: django-mssql present and future

2016-05-27 Thread Marc Tamlyn
I'm definitely a fan of doing things under the /django banner. I think so
long as we make it clear that this is in development then it shouldn't
matter about feature parity - especially as django-mssql won't have a
version supporting 1.9 or 1.10 anyway.

On 27 May 2016 at 08:24, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hi Michael,
>
> Thanks for this initiative!
>
> I like the idea of hosting this new project in the Django organization. I
> think there’s a lot of value in having a good SQL Server backend for
> Django, implemented according to Microsoft’s recommendations, and little
> reason to encourage competition in this space — there aren’t that many ways
> to implement such a library.
>
> However I’m wary of deciding that a non-existent-yet library is the
> endorsed solution for using SQL Server from Django. It may be best to wait
> until it has reached feature parity with django-mssql and received some
> amount of real-world testing to move it there.
>
> Best regards,
>
> --
> Aymeric.
>
> On 23 May 2016, at 20:57, Michael Manfre  wrote:
>
> There are two parts to this email. First relates to the current state of
> django-mssql. A version of the backend that supports Django 1.8 will be
> released in the next few weeks. I apologize for the delay, but my ability
> to focus on the project was basically non-existent for nearly a year due to
> personal reasons. The backend is currently failing some of Django's test
> suite and will likely be released before all of the issues are resolved.
> The biggest unresolved issues right now relate to certain schema migrations
> and some failing tests related to prefetch related that I haven't had time
> to investigate yet. I plan on releasing with a list of known bugs, so if
> you use this backend, please test the latest commits against your project
> and let me know if you run in to any issues. Post your found errors on the
> django-mssql issue tracker [1]. I will not release if there are any data
> corruption or other blocking level bugs. I'm planning this to be the last
> major release using adodbapi and the underlying ADO drivers.
>
> [1] https://bitbucket.org/Manfre/django-mssql
>
> Moving forward, django-mssql will be rewritten from scratch to use the
> Microsoft developed ODBC drivers. These drivers are officially supported by
> Microsoft and will be cross platform; Windows and Linux support exists and
> OSX support is currently being worked on. Despite using ODBC drivers, this
> backend will specifically target MSSQL to take advantage of any features or
> performance improvements that are possible, and to reduce the support
> overhead of working against any random database that provides an ODBC
> interface. Microsoft has stated their willingness to contribute
> engineering resources towards this backend.
>
> I'd like this soon to be created repo to live under Django's github
> account and to start the conversation about if this is desirable and what
> that means for the backend and Django.
>
> Why start from scratch? Sometimes the slate needs to be wiped clean to
> remove mistakes of the past. Django-mssql has accumulated a lot of crufty
> code over the years for various reasons. The existing ODBC backends are in
> various states of support with slightly differing goals; generic ODBC,
> Azure specific, etc. To me the most important reason is, I want to start
> from scratch to help document what is involved with creating a database
> backend.
>
> One concern that has been previously raised relates to handling
> regressions. It is my expectation that individual commits to Django would
> be allowed to break the backend's tests, but that they will be resolved
> before release.
>
> If you have questions related to MSSQL or what are the expectations for
> having an officially support Django database backend, please share them.
>
> Regards,
> Michael Manfre
>
>
>
> --
> 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/CAGdCwBsj6SGFqwKR7NFUMb0taExD8LGRcJtU7PPqNvcv5GvPtQ%40mail.gmail.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 

Re: Rewriting admin internals

2016-05-25 Thread Marc Tamlyn
There are certainly elements of forms refactoring you would want to pull
from the admin - read only fields and fieldsets being the two most obvious.

At a guess, James is alluding to https://github.com/mjtamlyn/django-adapters,
my currently stalled project to think about reworking the
form/serialization apis.

On 25 May 2016 at 14:32, Tim Graham  wrote:

> What's the "forms refactor"?
>
> On Wednesday, May 25, 2016 at 9:04:48 AM UTC-4, Asif Saifuddin wrote:
>>
>> Hi is_null,
>>
>> form refactor is an important part but that shouldn't stop us from
>> starting the process.
>>
>> thanks
>>
>> On Wednesday, May 25, 2016 at 3:19:36 PM UTC+6, is_null wrote:
>>>
>>> Shouldn't the forms refactor happen first ?
>>>
>> --
> 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/2ec37001-31ba-46a2-864f-f58a1a7caee6%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/CAMwjO1HbzKUCYiqgYq8Tt4z-PXMmUTHXrQCBkR3O177AiO%3DdFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Rewriting admin internals

2016-05-25 Thread Marc Tamlyn
Sure, give me 12 months of two full time experienced Django developers and
we can rewrite the admin.

Honestly, I think everyone knows the admin would benefit from a significant
rewrite. However, as the efforts of admin2 proved, it's a huge job to
undertake. The admin has a huge number of features and customisation
points, many of which have been developed in an ad-hoc sense. There are
hundreds of thousands of deployments of it in the wild, and hundreds of
packages which use and abuse it. I don't want to say it can't be done,
because I'd like it to be done. However it would require a gargantuan
effort to achieve.

A first step would be to work on a DEP. Probably a long one.

On 25 May 2016 at 09:45, Asif Saifuddin  wrote:

> Hi,
> the admin app of django is consists of many old day codes. How about
> rewriting it with present day approaches? adopting ideas from django-admin2
> where possible? and how about using jinja2 templates as default for admin?
>
> thanks,
>
> asif
>
> --
> 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/b0c8ff85-fe32-4c91-95ad-f192246b2049%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/CAMwjO1E20BrtvpR4qiyxjGXny7MP%2BKHXWV%3DyD_7azTgH6ZJL%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Should we require pytz for timezone support in Django?

2016-05-17 Thread Marc Tamlyn
It would seem reasonable to me to require it. I wonder whether the
reasoning is based on distro packaging or similar?

On 17 May 2016 at 01:21, Josh Smeaton  wrote:

> While writing timezone tests for
> https://github.com/django/django/pull/6243 I ran into some issues where
> pytz seemed to be required for just about every database and platform
> combination except postgres on linux. The docs for timezone support (
> https://docs.djangoproject.com/en/dev/topics/i18n/timezones/) say:
>
> Installing pytz  is highly recommended, but
>> may not be mandatory depending on your particular database backend,
>> operating system and time zone. If you encounter an exception querying
>> dates or times, please try installing it before filing a bug.
>
>
> I tried to find some documentation on the broader internet that would more
> accurately describe when and for what platforms pytz is actually required
> for timezone support, but was unable to find anything. I've opened a new
> ticket https://code.djangoproject.com/ticket/26622 to clarify more
> explicitly when pytz is required.
>
> However, I'm wondering if we should just go all-in on pytz and require it
> for timezone support. I've not run a Django site with timezone support
> without pytz, so I'm not sure what exact limitations exist or why you'd
> want to use timezone support without pytz. I'd be interested in hearing use
> cases for not requiring pytz if there are any. Explicitly requiring pytz
> will make test writing a lot easier, and will remove any doubt about
> whether or not pytz is required for users.
>
> Josh
>
> --
> 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/cb513e96-e75f-462f-a8ca-b5d916ad8eef%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/CAMwjO1H_n%3DGzAFZ%2BR07Qf2qnbmY8_dpy5FhdaBEXrQRB0gJ9sQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Help Text Per Model Field Choice

2016-05-12 Thread Marc Tamlyn
Choices are currently very simple in core Django. There are multiple
 different
 packages
 which provide
alternative syntaxes or useful ideas for extending the concept. Python 3
also has enums  which are a
related concept. Personally, I have ideas for a class binding option
 useful when your
choices encapsulate functionality in your app - such as the help text. I've
also not yet written that package.

So, I feel this is only one of a wide range of issues which spring from the
simplicity of choices. It would be good to see a solution look at the range
of problems and prior art.

On 8 May 2016 at 12:53, David Sanders  wrote:

> Hey all,
>
> I think it would be a greatly useful feature to be able to set help text
> for choices on a model field.
>
> For the default Select widget this would be rendered as the title
> attribute for each choice, which browsers show when you hover over a
> choice. This also makes it simple to render the help text nicely using
> Select2, here's a quick example JSFiddle: https://jsfiddle.net/tt1a9zk6/
>
> Beyond Select, for rendering radio buttons it looks like title is also
> shown on hover by browsers, but it's a little less intuitive because you
> need to hover over the radio button, or put the title on the label instead.
> In admin, adding a little '?' icon like the one for the field help text on
> tabular inlines would would be a slick way to do it for radio buttons.
>
> Since the pattern for model field choices being a tuple is pretty
> ingrained and changing the plumbing to allow for an optional third value
> (the help text) would require a lot of change, I opted for using a tuple
> subclass to tack on the extra help text information. From the user
> perspective they'd still be providing tuples for the choices, with an
> optional third value.
>
> class FooBar(models.Model):
> STATUS_UNKNOWN = 0
> STATUS_SNAFU = 1
> STATUS_FUBAR = 2
>
> STATUSES = (
> (STATUS_UNKNOWN, _("Unknown")),
> (STATUS_SNAFU, _("SNAFU"), _("Situation Normal: All Fouled Up")),
> (STATUS_FUBAR, _("FUBAR"), _("Fouled Up Beyond All Recognition"))
> )
>
> status = models.IntegerField(choices=STATUSES, help_text=_("What's the
> current status?"))
>
> Under the covers the tuple gets converted to an instance of the class,
> which I called ChoiceTuple in my proof of concept patch (found at the end
> of this message). The help text gets set as an attribute on the instance so
> that it can be retrieved by aware widgets. If a widget isn't aware of the
> ChoiceTuple class, the choice acts like a two value tuple like it currently
> is. The only tricky bit is unwinding the choices value when it's broken
> into named groups, or is a callable, the code there is iffy, but it was
> just to get the proof of concept working.
>
> The nice thing about this approach is it also works nicely with
> ModelChoiceIterator, making it quick and easy to grab help text for choices
> populated from models in the DB off of one of the fields. This is useful
> for situations where the choices are a curated list in the database. The
> proof of concept patch tries to get the help text from a field on the model
> named help_text if present. That code wouldn't be included in the final
> patch, it's just an example.
>
> Thoughts? The addition of the class ChoiceTuple nicely minimizes the
> amount of changes needed to plumb the change all the way from the model
> field to the widget. I'm not married to the approach, I'm just looking for
> a clean way to allow help texts per choice.
>
> Proof of concept patch (based on current master):
> http://pastebin.com/90g6mUQ8
>
> - David
>
> --
> 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/CAEXbqgzhMj8kASksnO9nwFqJoNeMChV0X6ACuX8_OpOoX%3D0atg%40mail.gmail.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 

Re: Process DEP for "official" non-core projects

2016-05-12 Thread Marc Tamlyn
I'm a big fan of pulling things into github.com/django. One other point
which has been raised when I've mentioned this before is the role of the
django fellow(s) with regards to these projects. This should at least be
touched on in the DEP.

On 11 May 2016 at 20:34, William Hakizimana  wrote:

> Just wanted to thank you so much for your hard work. The documentation is
> really well written!
>
> On Wednesday, May 11, 2016, at 1:29:34 PM UTC-5, Andrew Godwin wrote:
>>
>>
>>
>> On Wed, May 11, 2016 at 11:00 AM, Jacob Kaplan-Moss 
>> wrote:
>>
>>> I like this, and +1 on your rough outline.
>>>
>>> There is one missing thing here though: I think we need to consider the
>>> process/policy for removing things if they're no longer maintained. Without
>>> clear maintainership forks happen, which is bad for pretty much everyone.
>>> So I think we should have a plan in place for what happens if the shepherd
>>> can no longer tend to their flock, and nobody else steps into the role.
>>>
>>> I'd suggest something like this: if a project goes stale, core calls for
>>> new maintainers. If none arrive within a reasonable period of time (3
>>> months?) we deprecate and remove the package from our org.
>>>
>>>
>> That seems sensible to me; if the project is important enough to Django,
>> I'm sure people will step up to take over, and if not, dropping it is
>> probably the better option rather than letting it linger.
>>
>> I would be inclined to merely mark it as deprecated and not drop it from
>> e.g. the GitHub org, though, as where would we move it *to*?
>>
>> Andrew
>>
> --
> 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/885bd485-341a-47ad-8766-7ef17df77ada%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/CAMwjO1Hiu3uYr2if4JP%2BoVMhVef%3D_J57dFdko6%2BpTzoDGMerLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

2016-05-06 Thread Marc Tamlyn
>
> ISTM that the strongest argument in favor is that I think it _is_
> significantly easier for a casual user to build and deploy their first
> websockets app using Channels than using any other currently-available
> approach with Django. Both channels and Django+whatever-async-server
> require managing multiple servers, but channels makes a lot of decisions
> for you and makes it really easy to keep all your code together. And (as
> long as we still support plain WSGI) it doesn't remove the flexibility
> for more advanced users who prefer different tradeoffs to still choose
> other approaches. There's a lot to be said for that combination of
> "accessible for the new user, still flexible for the advanced user", IMO.
>

This is exactly my opinion, and I think that will be shared by the vast
majority of Django users. Obviously there's an issue if over a certain size
you have to rearchitect your system because ASGI/Channels isn't good
enough, but that's a problem we can't learn until this has been used by
enough people for long enough. The most important things for me are:
- Does this not break existing Django deployments, which whatever esoteric
systems people have (yes)
- Is it easy to get started with an exciting new feature (I believe so)

I'm going to try and build a prototype with Channels and verify point two.
If that goes well, I feel we should merge the feature, with a strong
provisional status and a call to the community to try and break it.

-- 
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/CAMwjO1Ge4jkD6XMV98zVA5J%3DBhi3Y_eent8WFPnmGrnBacGbrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django Integration

2016-05-04 Thread Marc Tamlyn
Major features merged into Django have generally never been as "perfect" as
the standards required for smaller patches. There's a recognisation of the
need for ongoing work, probably over the course of multiple versions, in
order to perfect any major new feature. The effort involved in getting a
patch like this to the point it can be merged at all is very significant.
Many major patches (composite fields, templates widgets...) have previous
not landed, sometimes multiple times, because they are nowhere near the
standard that this channels patch is.

My feeling is that the core team agree with Andrew that this is an
important direction for Django, and 1.10 is the right release to include it
in. Bug fixes, additional tests and so on can all be added between alpha
and final as needed. The important thing is that we have broad agreement
that the feature is good, the design is right, and an understanding that
shortcomings will be worked on over the next year or two.

Marc
On 4 May 2016 8:36 p.m., "Andrew Godwin"  wrote:

>
>
> On Wed, May 4, 2016 at 12:28 PM, Mark Lavin  wrote:
>
>> I can (and do) appreciate the effort that's gone into this work while
>> still feeling as though it isn't ready to be merged with Django. To be
>> honest given that this PR contains almost no changes to Django itself and
>> only adds new code, I don't understand why it can't live outside of Django
>> while it continues to mature.
>>
>>
> That's a perfectly valid question, and one I've debated a lot. It's mostly
> because channels is meant to be a fundamental change to Django (inserting a
> new layer below views and middleware), and having it as something
> officially supported and maintained is far better than having a third-party
> package everyone basically relies on but which doesn't benefit from the
> support of a large team (having been there with South, I know I don't want
> to go back).
>
> It's even more difficult to argue considering it does exist as a perfectly
> functional third-party package for 1.8/1.9, but the goal with channels is,
> for me, to move Django along in the world of web technology and make sure
> it's positioned right for what the job of a webserver is becoming, which as
> far as I am concerned inexorably involves websockets and other "async"
> things, and I think having it in Django itself sends the right message.
>
> Most of the core team I have spoken to about this seem to agree with me,
> which is why I'm pushing so hard. Obviously that trust and maintenance that
> you get by being in core Django comes at a price, and the price is having
> good code in the first place, but I believe that the code is very close to
> being good enough considering we're labelling the whole feature as
> "provisional" in 1.10 anyway (which is something Python recently started
> doing for similar not-experimental but not-100%-final APIs)
>
> (Also, I would posit that the fact it barely changes anything in Django is
> part of the good design, but I am biased there!)
>
> Andrew
>
> --
> 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/CAFwN1uqpLNTLDuZzNQzH_4k_ZYzHx0pbuXzeKo7u80MjVMr3HA%40mail.gmail.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/CAMwjO1Fx08P2LOPdgDQoav35Vb-gYXiMyrZXhXO3SvjqgzHPCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django website ssl-certificate expired

2016-05-04 Thread Marc Tamlyn
We are aware of the issue and are working on it.

Thanks,
Marc

On 4 May 2016 at 10:30, Wim Feijen  wrote:

> Hi guys,
>
> Apologies if I am posting in the wrong group, but the certificate of
> djangoproject.com expired today (4 May).
>
> Wim
>
> --
> 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/e44c883b-41fc-4afb-8717-15c0f0f5dae2%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/CAMwjO1HEWHDO7-6P5xv%2BQJUrW7Cc%2BWU0a0KC76iJuax%3DU8srMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Making Django more PaaS-friendly

2016-04-11 Thread Marc Tamlyn
I like the idea of integrating dj-database-url. There's a similar package
for CACHES[0], which is a neat idea but slightly more tricky to justify as
I don't know if PaaS tend to send the cache details in that format
necessarily.

I'm not sure about the rest of the mail, although I'd definitely be up for
modifying the SECRET_KEY line in particular to make it strongly suggest
that this should be different per environment.

M


[0] https://github.com/ghickman/django-cache-url

On 11 April 2016 at 07:33, James Bennett  wrote:

> Apologies for how late in the process this is; job hunt + moving
> cross-country ate a lot of my time.
>
> At Django Under the Hood I proposed that for Django 1.10 we try to find
> some common best practices for deploying Django on popular
> platform-as-a-service (PaaS) solutions, and building support for them into
> Django. The biggest one of these is probably having the ability to read
> configuration from environment variables instead of hard-coding things into
> settings files.
>
> At the very least I'd like to propose (assuming Kenneth is on board with
> it) integrating dj-database-url[1] or something like it directly into
> Django, so that there's no longer a third-party dependency for reading the
> database configuration from an environment variable. Whether this is just
> porting dj-database-url itself in, or making the DATABASES setting
> understand URLs, I'm unsure of yet and would be interested to hear feedback
> on. Either way I'm willing to put in the time to develop the patch.
>
> More generally, I'd like to see Django grow helpers for specifying
> settings that should be read from environment variables, and which
> environment variables to use (the email settings are another common case,
> as is anything that requires an API key to access).
>
> There are a few ways to design this. One option would be just a minimal
> wrapper around os.getenv, perhaps taking an optional type or type-coercing
> function, so that it would be possible in a settings file to do:
>
> SECRET_NUMBER_SETTING = env_setting('SECRET_NUMBER', int)
>
> However, this is not much better than the current practice of calling
> os.getenv. A better solution might be the ability to specify a group of
> settings which will be read from the environment, and have Django
> automatically read and set them. For example:
>
> ENV_SETTINGS = [
> ('SECRET_NUMBER_SETTING', int),
> ('ACME_API_KEY', str),
> ('VOLCANO_LAIR_PASSWORD', str),
> ]
>
> would read the named settings from those environment variables, and coerce
> them to the appropriate types using the function provided.
>
> The main problem with this is that it's really not very elegant. But at
> the moment I can't think of anything better, and so I'd like to throw the
> floor open to ideas on nicer approaches to this. If one can't be found, I
> do think Django 1.10 should at least figure out how to handle database
> config from env since that's such a common use case nowadays, but ideally
> we'd be able to pin down a good API for generically pulling configuration
> from the environment.
>
>
> [1] https://github.com/kennethreitz/dj-database-url
>
> --
> 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/CAL13Cg85fYj0i0ysxJGo2SDesqELMeA%2BtnKJ9cdpqNHmQ%3DX3Pg%40mail.gmail.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/CAMwjO1Hd6JFntN49a35E-ktnXMf9pTWjisdh7fwYHC_-bbPPBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Vendoring Select2

2016-04-06 Thread Marc Tamlyn
Agreed. I recently was trying to use a fitler horizontal widget on my phone
and thought the whole thing was broken because ``
looks so wrong. I'd love to see this experience improved, and select2 is a
good reliable solution.

On 6 April 2016 at 15:11, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> I’m OK with this. It's a reasonable solution.
>
> --
> Aymeric.
>
> On 06 Apr 2016, at 15:25, Johannes Hoppe  wrote:
>
> Hi,
>
> as promised I started working on an autocomplete field for
> `django.contrib.admin` as a more convenient alternative to `row_id_fields`.
>
> We had a longer discussion in the ticket and also at the sprints at
> DjangoConEU with some of the maintainers for famous 3rd party autocomplete
> integrations.
>
> We concluded that select2 is the most mature and stable solution, that
> also doesn't require us to write our own JS code. (I know how much we hate
> it ;)
>
> Notable:
> 1. In order to use `jQuery.noConflict(true);` I hat to add a wrapper
> around the vendored Select2 library. I think that is better than leaving
> `jQuery` in the global namespace.
> 2. `$.select2` will only be added to `django.jQuery` and therefore not
> interfere with other implementations. One should still be able to use 3rd
> party libraries.
> 3. Select2 is unter MIT license.
>
> All in all I tried not to break anything and have this as new opt in
> solution. Lets see how it plays out.
>
> All I need for you is to decided on wether or not with should vendor
> Select2.
>
> PR is here: https://github.com/django/django/pull/6385
>
> Thanks in advance!
> Joe
>
> --
> 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/21cbed67-1ecb-4e04-a8d6-746cb363beab%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/C7278AB9-9018-4BC0-A7A8-CACFA361A5A3%40polytechnique.org
> 
> .
>
> 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/CAMwjO1EkkH9SGG-Pss2JQTj0%3DJ8dRYnF3_Stt1hbqZrYqGYh0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Vendoring multipledispatch

2016-04-06 Thread Marc Tamlyn
Does anyone (potentially from OS packaging worlds maybe) have a good reason
NOT to have a dependency?

In the event that Django does have Pip dependencies, I still think we
should establish some rules. Things like they should be stable and mature,
and perhaps widely known, and still be under active maintenance. These are
all hazy ideas of course, but I think adding any new dependency should be
something which we are cautious of, not something we do without careful
consideration.

If someone can put together some documentation or a DEP for how this
process would work, I think this is a matter significant enough to talk
about properly, and in a thread more clearly named. Such a proposal should
also ideally reference what we do or have vendored before, why, and how
well of otherwise that process has worked.

Marc
On 5 Apr 2016 9:49 a.m., "James Pic"  wrote:

> Adding dependencies would definitely be a huge step forward. I think
> Django doesn't have them because pip wasn't as awesome as it is today
> back in the early days, but nowadays it would definitely make sense.
> That would mean a bit more work for distribution package maintainers
> but if we can start communicating with them about it then would there
> be any reason not to do this move ?
>
> --
> 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/CALC3Kae1Mt5LzYRq0PQbQcEMKwvbK%2Begr4FuC6baB5NZZtSbtA%40mail.gmail.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/CAMwjO1HqgJ%3DM93yWgmatZtc4s8%3DRB8FFfga24aJ3X_D_Ey2xdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Choosing migration with relative syntax

2016-03-30 Thread Marc Tamlyn
I actually think this would be super useful if we can make it make sense
(HEAD~ with merges..). "Undo the migration I just did" is a common
operation in development.

M
On 11 Mar 2016 2:18 p.m., "Joakim Saario"  wrote:

> You can always have a y/N-question to limit these cases. Though, I think
> this is a problem as it is right now too, because you can always do a typo.
>
> /Joakim
>
> Den fredag 11 mars 2016 kl. 14:06:42 UTC+1 skrev Markus Holtermann:
>>
>> Hi Joakim,
>>
>> thank you for your proposal.
>>
>> I don't think this is a good idea because you can easily accidentally
>> undo too many migrations which would inevitably will result in data loss.
>> You don't have the data loss problem in Git as you can always recover by
>> using `git reflog` to go back and e.g. undo an incorrect rebase. However,
>> when you remove a field from a database table the data is pretty much lost.
>>
>> Cheers,
>>
>> /Markus
>>
>> On Friday, March 11, 2016 at 11:39:53 PM UTC+11, Joakim Saario wrote:
>>>
>>> Hello!
>>>
>>> Today if you just need to unmigrate the *n* migrations before the last
>>> one you would
>>> typically run `migrate  --list` and then `migrate 
>>> ` where
>>> `migration_name` is the migration you want to roll back to.
>>>
>>> To reduce the steps of this procedure i think it would be nice to
>>> introduce
>>> a syntax similar to how commits in for example git works. I.e `git show
>>> HEAD^`
>>> for the previous commit and `git show HEAD~2` for the one before that.
>>> It would also be good to support the `git show (^+)|(~\d)`
>>> variant
>>> of this to be able to choose the origin.
>>>
>>> For this to work good for the normal case, there need to be a magic word
>>> that maps to the latest migration available and/or the latest applied
>>> migration.
>>>
>>> I can clearly see a use case for this as I can imagine that the most
>>> common
>>> operation besides applying all unmigrated migrations is to roll back *n*
>>> migrations.
>>>
>>> Does this sounds like a good idea?
>>>
>> --
> 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/46b90e2f-e14d-41c9-8ac8-f7758e3a3d46%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/CAMwjO1EjGUM3P4e6GBFAdSHTnJoiXO1OEUAKJPY1RMyT0hkZAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal on Custom Indexes - Google Summer of Code

2016-03-14 Thread Marc Tamlyn
I like this a lot. Even we we then keep the "Meta" options as they are
forever, they then become shortcuts to what you could define explicitly.

In any case, we would need some careful checks that (for example) you can't
have identical indexes defined in multiple ways with the same names.

On 14 March 2016 at 07:23, Anssi Kääriäinen  wrote:

> On Thu, Mar 10, 2016 at 8:17 AM, Markus Holtermann
>  wrote:
> > Hi Akshesh,
> >
> > thank you for your proposal! Sounds like a good plan.
> >
> > On Thursday, March 10, 2016 at 8:16:10 AM UTC+11, akki wrote:
> >
> >>> Once the index is added to a model, the model can inject itself into
> the
> >>> index, or the schema editor can use the originating model to get data
> it
> >>> needs. No need to pass the model into the index type I think.
> Regarding the
> >>> name, I'm unsure if I prefer a name=Index() or an Index(name='')
> approach.
> >>> It'd be good to see that choice in your proposal with a couple of pros
> and
> >>> cons.
> >>
> >>
> >> Well, since we are defining these indexes in a list (to be stored in
> >> Meta.indexes) I would go with the Index(name='') approach.
> >
> >
> > I'd prefer the Index(name='') approach
> >
> > class MyModel(models.Model):
> > field1 = models.CharField()
> > field2 = models.CharField()
> >
> > class Meta:
> > indexes = [
> > Index('field1', 'field2',
> name='some_index_across_two_columns'),
> > 'field2',  # Would be the same as Index('field2'), an index
> on
> > this one column -- name derived from field name: field2_index
> > Index(ToLower('field1')),  # A functional index on field1 --
> > name derived from field name and functions: field1_tolower_index
> > ]
> >
> > That way you should also be able to check for duplicate index names.
>
> How about
>
> class MyModel(models.Model):
> field1 = models.CharField()
> field2 = models.CharField()
>
> field1_idx = models.Index('field1')
> field2_lower_idx = models.Index(ToLower('field2'))
>
> The main advantage is that the same syntax can be used for custom
> indexes, constraints, composite fields and so on. Internally we could
> of course have the same representation for indexes as before.
>
>  - Anssi
>
> --
> 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/CALMtK1Eet%3DzPTKXJJpuRy8b0tWF%2BaA9-QaT%2BzfF%3DGV6wAd3N3g%40mail.gmail.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/CAMwjO1GG-TXEGfpBYnRb9QEum2Gjmxm_BkO%2BNtoLWUCYAm0w2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Admin hstore widget

2016-03-08 Thread Marc Tamlyn
I wouldn't say nobody understands it, Elky in particular will have a good
working knowledge given he wrote the 1.9 skin. That doesn't mean there's a
set of rules it follows. We certainly don't follow any particular front end
standard such as BEM for class names. I'm pretty sure it's only a year ago
a completely raw JS widget was rewritten with jQuery.

On 8 March 2016 at 10:40, Curtis Maloney <cur...@tinbrain.net> wrote:

>
>
> On 08/03/16 20:47, Marc Tamlyn wrote:
>
>> Doing something better with the admin hstore is definitely something I'd
>> like to see land.
>>
>> 1. I'd like more input on the features people feel are essential.
>> Something that allows you to add/change/delete keys is all you need to
>> start with. Features like soft delete can be added later.
>>
>
> OK, well, I'll pare down the code and make a PR soon.
>
> 2. Is there a guide somewhere to styles and markup to be used in admin
>> templates?
>> No, in short. Keep it simple seems to be the best advice I can give -
>> most of the code is very old.
>>
>
> So nobody understands the HTML and CSS used in Admin?
>
> Someone must, since there are a few skins for it, and someone just redid
> our skin for 1.9...
>
> 3. I plan to pull in another icon from FA, but it appears the one we
>> currently use for "inline delete" is customised from the original.  Does
>> anyone know who made these changes and how?
>> No idea sorry.
>>
>
> I had hoped the person "git blame" showed was reading this list... oh well
>
> --
> C
>
> --
> 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/56DEAC33.1090600%40tinbrain.net
> .
>
> 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/CAMwjO1EQT7UkgqcxoT2DN21a%3DB9FMTFcKLLzFVyKo6iTT611rg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Admin hstore widget

2016-03-08 Thread Marc Tamlyn
Doing something better with the admin hstore is definitely something I'd
like to see land.

1. I'd like more input on the features people feel are essential.
Something that allows you to add/change/delete keys is all you need to
start with. Features like soft delete can be added later.

2. Is there a guide somewhere to styles and markup to be used in admin
templates?
No, in short. Keep it simple seems to be the best advice I can give - most
of the code is very old.

3. I plan to pull in another icon from FA, but it appears the one we
currently use for "inline delete" is customised from the original.  Does
anyone know who made these changes and how?
No idea sorry.

On 7 March 2016 at 22:57, Josh Smeaton  wrote:

> I wouldn't drop it if I were you. I (think) I watched you demo the hstore
> admin field at melbdjango and it looked cool to me. If I used hstorefield
> I'd be interested in the implementation. The dev ML isn't really indicative
> of the broader django community I feel, because only a small portion of the
> community seem to participate. Deafening silence here may still lead to
> cheers elsewhere once it's available.
>
> If I were you, I'd make a small screencast/gifv of the feature in action,
> reach out to some people that you know are using contrib.postgres (starting
> with Marc), and explicitly solicit their feedback on usefulness. If you
> still don't feel there is a real desire to have in core, could you release
> it as a 3rd party project? If it requires hooks in core to support custom
> fields then push those changes through separately.
>
> My 2c :)
>
> On Tuesday, 8 March 2016 08:18:59 UTC+11, Curtis Maloney wrote:
>>
>>
>>
>> On 08/03/16 02:43, Tim Graham wrote:
>> > 1. Merging something minimal always help to get feature requests. :-)
>>
>>
>>
>> > 2. Could you be more specific about what you're looking for? All the
>> > existing documentation for style related stuff is at
>> >
>> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/.
>>
>> > I also thought of ticket https://code.djangoproject.com/ticket/14831.
>>
>> This is no way covers the HTML or CSS structures used in admin.
>>
>> Given the deafening roar of absolutely no interest in this feature, I
>> guess I'll drop it.
>>
>> --
>> C
>>
> --
> 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/f6144212-cdde-4729-9d42-3d79397079ed%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/CAMwjO1Gboz0crk9gGV%3DO%2BW%2BxoHy4BvfR%3DjqDUXGE-9k8B%2B3OVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Making max_length argument optional

2016-03-04 Thread Marc Tamlyn
Voting:

1) should there be a default?

I'm lazy, so I would be happy to have one. Where validation matters you can
change it, where it doesn't you don't have to. I'd draw an analogy to
(Positive)(Small)IntegerField - I often use the normal one when I mean some
variant of validation, or some other max/min value.

2) how to make it easy to have no limit on PG?

If it's truly pg specific, then a contrib.pg field seems fine, though
probably call it UnlimitedCharField for lack of ambiguity.

M
On 1 Mar 2016 1:11 a.m., "Markus Holtermann" 
wrote:

> 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
> independent by using a TextField which has pretty much the same performance
> on PG as a VARCHAR() and is available on other backends. But may perform
> bad on other backends. But there's no way to have a text of unlimited
> length on MySQL other than a TEXT column.
>
> TL;DR: you can't achieve both ways anyway. Neither now nor if we change
> the behavior of Django's max_length attribute on CharFields.
>
> /Markus
>
> On Tuesday, March 1, 2016 at 11:00:29 AM UTC+11, Cristiano Coelho wrote:
>>
>> 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
>> you will have a really bad time.
>> I'm not sure about postgres but I want to believe that using varchar
>> without limits has also some performance considerations that should be
>> taken care of.
>>
>> El lunes, 29 de febrero de 2016, 17:58:33 (UTC-3), Shai Berger escribió:
>>>
>>> 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 11:19:02 Aymeric Augustin wrote:
>>> >
>>> > 2) How can we make it easy for PostgreSQL users to just use VARCHAR()?
>>> >
>>> > Since this is a PostgreSQL-specific feature, having a variant of
>>> CharField
>>> > in django.contrib.postgres that supports and perhaps even defaults to
>>> > unlimited length shouldn’t be controversial.
>>> >
>>>
>>> The first -- I believe it was raised very early on by Christophe Pettus
>>> -- is
>>> that Django already has a field that manifests on PG as VARCHAR(), and
>>> that is
>>> TextField. However, I don't like the idea that PG users should be using
>>> TextField(widget=TextInput) as a replacement for CharField; I find that
>>> counter-intuitive -- even if just because it is a "bad name". Names are
>>> important.
>>>
>>> The second -- in response to a comment made by Josh Smeaton -- is that
>>> having
>>> django.db.models.CharField with default max_lenth=N (for some finite N)
>>> and
>>> django.contrib.postgres.CharField with default max_length=None (meaning
>>> infinity) sounds like a bad idea.
>>>
>>> >
>>> > I hope this helps!
>>>
>>> I'm certain it did!
>>>
>>> Shai.
>>>
>> --
> 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/71e5e743-29bb-4dba-9bf4-6948ab2d1fa9%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/CAMwjO1Gj3E4_83qdbQmQwXe_WdTXUf7yuZ44-aQ9jgvJN9-5sg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal: django.contrib.mysql

2016-03-04 Thread Marc Tamlyn
One of the other reasons why contrib.postgres is in core is that it
required some changes to internals of the ORM. It's possible that all of
those we need are done now (except custom indexes) - is there anything
about contrib.mysql which would benefit from this?

I'm happy for JSONField to be made a core field on the condition that it's
underlying support is more than a text blob on all our main databases. It
sounds like this will soon be the case.

Marc

On 4 March 2016 at 09:04, Josh Smeaton  wrote:

> I agree regarding choosing the most most useful bits. When we discussed
> this at DUTH I did mention that there were some features that would be very
> difficult to get included in Django. I guess you'd have to consider whether
> or not you'd be willing to move features from django-mysql into contrib and
> how that might affect django-mysql in the longer term.  I really like the
> idea of having a contrib.mysql though, as it shows we're not just committed
> to moving postgres forward. Having a voice for mysql in the team would also
> be very helpful.
>
> Cheers
>
> On Friday, 4 March 2016 18:15:15 UTC+11, Aymeric Augustin wrote:
>>
>> Hi Adam,
>>
>> django-mysql has a rather large API surface. I think the first step would
>> be to make a list of the most stable and generally useful bits that are
>> candidate for inclusion in Django and to write that list down in a DEP.
>>
>> The fields, functions, lookups, and aggregates are good candidates. I’m
>> less sure about the QuerySet extensions because we don’t have anything
>> similar yet. We’d have to think about the implications.
>>
>> Looking forwards, django-mysql could be an experimental ground for
>> features. When they stabilize, the most common features could go into
>> django.contrib.mysql.
>>
>> Since making changes to public APIs is a pain, you only want to put code
>> in Django when it’s done. To a lesser extent, we have Python’s “standard
>> library is where modules go to die” problem.
>>
>> It would obviously help if other community members expressed interest in
>> django.contrib.mysql or, even better, intent to help maintain it in the
>> future.
>>
>> I hope this helps,
>>
>> --
>> Aymeric.
>>
>> PS: if this plan comes to fruition, most likely you’ll get commit access
>> along the way ;-)
>>
>>
>> On 04 Mar 2016, at 00:09, Adam Johnson  wrote:
>>
>> The *django.contrib.postgres* docs state:
>>
>> There is no fundamental reason why (for example) a contrib.mysql module
>>> does not exist
>>
>>
>> *Well...* over the past year and a bit I've been developing
>> Django-MySQL. It has a ton of features specific to MySQL and/or MariaDB.
>> For a quick tour of the features, see the exposition in the documentation:
>> https://django-mysql.readthedocs.org/en/latest/exposition.html (it's not
>> all suitable for Django core, some is kinda hacky (but well tested!))
>>
>> At DUTH in November I talked with Josh Smeaton about posting a suggestion
>> here for *django.contrib.mysql*. Since then, I've simply been
>> lazy/forgetful, but now I'm here getting round to it.
>>
>> I'm also a bit motivated by my recent completion of its *JSONField* for
>> MySQL 5.7+ which is very similar to the *contrib.postgres* one, copying
>> and adapting large parts of code from Marc Tamlyn's work. We all know how
>> much everyone loves JSON these days. If anything, this could be a core
>> field rather than a *contrib* one - Oracle and SQLite also have JSON
>> capabilities now. JSON everywhere!
>>
>> Anyway... what's the interest in *django.contrib.mysql*? And where woudl
>> we go from here...
>>
>> --
>> 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-develop...@googlegroups.com.
>> To post to this group, send email to django-d...@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/ed9245ea-f908-4c1c-91ad-cb94f0147959%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/562f8c3e-4bf1-47cf-9a98-1a6f9b171528%40googlegroups.com
> 

Re: Annotate date intervals or ranges

2016-03-03 Thread Marc Tamlyn
Probably just because there hasn't been an immediate need, and because it
working on every database the same way could be... awkward. When you have
dates, you also have to think about the timezone implications as well -
which timezone do you need that date in?

It's also worth mentioning that if you don't care about those subtleties
for your application, you can use Func() to do this:

.annotate(day_created=Func(Value('day'), 'created_date',
function='date_trunc'))

https://docs.djangoproject.com/en/1.9/ref/models/expressions/#func-expressions

On 2 March 2016 at 11:44, Sam Peka  wrote:

> It would be great if there was a way within the standard Queryset api to
> annotate ranges of dates. The use case is that it would remove the need to
> resort to RawSQL when grouping things by date ranges, such as the day of
> the month. I know the postgres extras package has a DateRangeField, but
> it's surprisingly difficult to do this dynamically.
>
> So I'd propose something like this:
>
> queryset.annotate(day_created=DateRange('day', 'created_date'))
>
> Which for Postgres would equate to:
>
> SELECT date_trunc('day', "created_date") as day_created from ...
>
> Is there a technical reason why this hasn't already been done? Or has
> there not been much of a need for it?
>
> --
> 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/fe7dcfc9-cbb5-439b-bf08-f45e854a99c6%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/CAMwjO1HTh4pFyWSDPXQ1L-_2QznoDo%3DDYUoELDDiKv5ASiYykg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: thinking about the admin's scope and its description in the docs

2016-02-17 Thread Marc Tamlyn
That looks like a good balanced message to me.

On 17 February 2016 at 16:57, Tim Graham  wrote:

> Here's another try for the docs:
>
> One of the most powerful parts of Django is the automatic admin interface.
> It
> reads metadata from your models to provide a quick, model-centric interface
> where trusted users can manage content on your site. The admin's
> recommended
> use is limited to an organization's internal management tool. It's not
> intended
> for building your entire front end around.
>
> The admin has many hooks for customization, but beware of trying to use
> those
> hooks exclusively. If you need to provide a more process-centric interface
> that abstracts away the implementation details of database tables and
> fields,
> then it's probably time to write your own views.
>
>
> On Friday, February 12, 2016 at 4:30:07 AM UTC-5, Andy Baker wrote:
>>
>> > However, we NEVER had a client that was sufficiently familiar with what
>> a database is or how data modeling works for this to ever suffice.
>>
>> I've got more than two dozen non-technical clients happily using the
>> admin. They also have no familiarity with data modelling but I'm not quite
>> sure how that would help or hinder them. The concept of a filterable list
>> view and an editable form luckily doesn't require discussing 4th normal
>> form or the benefits of relational algebra ;-)
>>
>> On Thursday, 11 February 2016 19:47:43 UTC, Chris Foresman wrote:
>>>
>>> FWIW, we used to tell clients that Django offers a basic admin interface
>>> "for free". However, we NEVER had a client that was sufficiently familiar
>>> with what a database is or how data modeling works for this to ever
>>> suffice. The first thing we always do on new project is immediately disable
>>> the admin and simply design APIs that allow our front-end teams to build
>>> some kind of custom dashboard/admin interface.
>>>
>>> IME, the admin is "sufficient" for sysadmins or technically experienced
>>> users, but in practice those are few and far between.
>>>
>>>
>>>
>>> On Thursday, February 11, 2016 at 12:08:08 PM UTC-6,
>>> bliy...@rentlytics.com wrote:

 While I think it's true that a process centric workflow (wizards, or
 hubs anyone?) would be incredibly useful, that does not take away from the
 fact that the model centric admins are also incredibly useful, and time
 saving.  It's so easy to add search, sorting, bulk actions, etc to an
 admin--these are things I've often spent days or weeks working on in other
 systems.  With django it is often a matter of minutes to add these
 incredibly common features.  This is probably one of my favorite things
 about the django framework.

 On Wednesday, February 10, 2016 at 5:33:03 PM UTC-8, Curtis Maloney
 wrote:
>
>
>
> On 11/02/16 00:55, Andy Baker wrote:
> > I can't help but feel that the "admin is very rudimentary and hard
> to
> > customize" is perpetually overplayed by many in the community. Maybe
> I'm
> > suffering Stockholm Syndrome but I'd like to raise a dissenting
> voice.
>
> I must admit I'm a large proponent of warning against getting caught
> up
> in "Admin as my management console".
>
> As customisable as it can be, I find the problem to be it is a
> data-centric view of your system, closely tied to the database models.
>
> IMHO a management interface for site should be a _process_ centric
> view,
> abstracting away the implementation details of tables and fields.
>
> Perhaps a better way to think of it as the difference between a
> "management" and a "maintenance" interface.
>
> True, in a lot of cases these can be the same thing, and for simpler
> sites Admin works "just fine".  However, I've been on too many
> projects
> that wind up spending a lot of time and effort customising Admin to do
> things that would have been simpler in a custom view.
>
> Worse still, I've seen projects alter their schema design to
> accommodate
> Admin's limitations [like lack of nested inlines]
>
> Is it possible to add other views to admin?  Sure... though it's not
> clear, or well documented.
>
> Can documentation alone overcome this problem?  I'm not convinced it
> can.
>
> For some years now I've been proposing an investigation into slicing
> Admin into two layers: a base "management interface framework" layer,
> and "admin" built atop this framework.
>
> Then we can keep providing the Admin we all know and love, and also
> make
> it easier for people to build their own management interfaces.
>
> However, I don't currently have the time [or admin familiarity] to
> undertake this work.
>
> --
> Curtis
>
 --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django 

Re: [Discussion] Legacy documentation / Boken docs Django v1.2

2016-02-17 Thread Marc Tamlyn
I see no reason to remove old versions from readthedocs.

On 17 February 2016 at 04:22, Felipe Prenholato 
wrote:

> I was catch by that change today and found the docs in
> http://django.readthedocs.org/en/1.5.x/.
>
> I wan't to suggest that for documentations that Django will remove from
> docs.djangoproject.com and from django.readthedocs.org we keep instead
> links to download PDFs / epubs / HTML zips in some place that is easy to
> find and so users can download it. Maybe some page like "Older versions"
> inside documentation.
>
> Well, just a thought :).
>
> Thx, Felipe.
>
> Felipe Prenholato.
> Home page: http://devwithpassion.com | http://chronosbox.org/blog
> GitHub: http://github.com/chronossc/ | Twitter:
> http://twitter.com/chronossc
> LinkedIn: http://br.linkedin.com/in/felipeprenholato/
>
> 2016-02-17 2:10 GMT-02:00 Tim Graham :
>
>> I removed the 1.4, 1.5, and 1.6 docs from docs.djangoproject.com today.
>> They are still available on readthedocs. I've spent more than a couple
>> hours recently debugging some problems related to documentation builds
>> there. Some are described in
>> https://github.com/django/djangoproject.com/issues/627, otherwise are
>> related to elasticsearch (timeouts due to indexing so many documents, I
>> think). I hope removing old docs versions will help to reduce the
>> maintenance overhead of these tasks. Also, a stale link in the docs was
>> pointing to a site with adult content. I backported the fix as far back as
>> 1.4 today.
>>
>> On Monday, April 13, 2015 at 11:08:59 AM UTC-4, Florian Apolloner wrote:
>>>
>>> As long as it doesn't hurt we can keep em there -- remove as soon as
>>> they cause a problem ;)
>>>
>>> On Monday, April 13, 2015 at 4:30:01 PM UTC+2, Tim Graham wrote:

 I just discontinued the 1.3 docs on docs.djangoproject.com, they are
 still available on django.readthedocs.org. Do you think we should keep
 it there or not?

 On Thursday, August 7, 2014 at 7:45:15 AM UTC-4, Tim Graham wrote:
>
> I'm in favor of discontinuing older version of the docs. I recently
> fixed the 1.3 documentation builder since there were several complaints,
> but no one has complained about 1.2.
>
> On Thursday, August 7, 2014 7:32:25 AM UTC-4, Areski Belaid wrote:
>>
>> Hi Folks,
>>
>> I wanted to open a discussion regarding the following ticket
>> https://code.djangoproject.com/ticket/23042
>>
>> To summarize briefly, you may notice that we can search doc for
>> Django version 1.2 (for example
>> https://docs.djangoproject.com/search/?q=forms=4) but the
>> links in the result won't work.
>>
>>
>> As Baptiste (IRC bmispelon) explained on IRC, we may have 2 approach
>> to solve this problem:
>>
>> 1) Fix the docs builder for versions < 1.2 (at the moment the
>> doc-building process is broken on old branches due to different version 
>> of
>> Sphinx)
>>
>> 2) Discontinue older Django docs version and decide a policy
>> regarding doc hosting
>>
>>
>> What do you think?
>>
>>
>> --
>> //Areski
>>
>> --
>> 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/8c2638b5-6604-4bd4-b470-9096aee14b69%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/CADdUj3G%3DWaG7G3KJM-yZ_e21UsakW6K5ap3%2Brd1ScOxS8rqQWA%40mail.gmail.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 

Re: argon2 PasswordHasher

2016-01-29 Thread Marc Tamlyn
It is once per user, but it's once for *EVERY* user when that scenario
occurs. That could easily bring a site down if sessions were invalidated or
you have short session times. It's far too likely someone will have
serious, hard to debug problems as a result of this magical behaviour.

I also strongly agree with Carl's comment on the PR: Automatic changes in
behaviour based only on the presence or absence of a third-party package
(or C bindings) are questionable in general. We can (and by the sounds of
it should) recommend this hasher strongly, but I don't think we need to
make it the default. Unlike SHA256, PBKDF2 isn't a BAD choice yet, it's
just not the best available.

There's an argument for updating the default project template for new
projects, but that would make setup for new users a lot harder so I don't
really like that idea either.

On 29 January 2016 at 14:56, Bas Westerbaan  wrote:

>
>
> I may not understand the security implications here properly, but as far
> as I can tell there isn't a strong enough case that Argon2 is fundamentally
> better than PBKDF2 yet?
>
>
> Barring any weakness in Blake2 we do not know about, Argon2 is way better
> than PBKDF2 as it is memory-hard.  The gap between SHA256 and PBKDF2 *and* 
> PBKDF2
> and Argon2 (with Django’s settings) might be of comparable order of
> magnitude as I outlined in this comment[1].
>
> I'd say 1.3 seconds is fundamentally *not* fast enough. If someone
> upgrades their site to Django 1.10 without noticing the change and we force
> this upgrade the suddenly every user's login to the site costs 1.3 seconds
> - that's an enormous amount of server load.
>
>
> That’s not my suggestion.  Sorry I did state it clearly enough.  This 1.3
> second login will only happen if the server used to be able to use the fast
> C-argon2 library, but then can’t use it anymore.  This 1.3 second login
> will only happen once per user: Django would then switch back to PBKDF2.  A
> 1.3 second login *once* per user seems acceptable.  (Off course it’s not
> acceptable if it would happen every time the user logs in.)
>
> Best,
>
>   Bas
>
> [1] https://github.com/django/django/pull/5876#discussion_r48936346
>
> --
> 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/BCEDC782-875E-474C-8B36-C2D59F430913%40westerbaan.name
> 
> .
>
> 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/CAMwjO1F1YVspthGnAnCwJDD22-2z2n90aXWCxVxxa9a-pvAFgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: argon2 PasswordHasher

2016-01-29 Thread Marc Tamlyn
I may not understand the security implications here properly, but as far as
I can tell there isn't a strong enough case that Argon2 is fundamentally
better than PBKDF2 yet? At least no more than people's arguments that
BCrypt is better. I think retaining the simple out of the box experience
where you get good, performant enough password hashing is important. I'd
say 1.3 seconds is fundamentally *not* fast enough. If someone upgrades
their site to Django 1.10 without noticing the change and we force this
upgrade the suddenly every user's login to the site costs 1.3 seconds -
that's an enormous amount of server load.

M

On 29 January 2016 at 10:01, Bas Westerbaan  wrote:

> Hi all,
>
> The PR[1] that adds Argon2 as a PasswordHasher is ready to be merged.  It
> does not make Argon2 the default.  The reasons not to make it the default
> are:
>
> 1. Argon2 is young.  (Its design, though, is uncontroversial.)
> 2. Argon2 requires C-bindings and thus does not work on every platform
> Django wants to support.
>
> I like to discuss how to take away the last concern.
>
> We could make Argon2 the default on a system if the C-bindings are
> available and otherwise fallback to PBKDF2.[2]  The problem is that it
> might happen that switching servers Argon2 might become unavailable and so
> users might not be able to log-in anymore.  To solve this, I wrote a pure
> Python implementation of Argon2.[3]  It it quite a bit slower[4] than the
> C-version and so I suggest to only use it to switch to another
> PasswordHasher if the C-version of Argon2 isn’t available anymore.[5]
>
> What do you think?
>
> Best,
>
>   Bas
>
>
> ---
> [1] https://github.com/django/django/pull/5876
> [2] Maybe add an `should_be_used’ field to the class and skip
> PasswordHasher’s for which this is False.
> [3] https://github.com/bwesterb/argon2pure
> [4] The Argon2 hash in the PR takes ~5ms in C and ~1.3s in Python.  Having
> to wait 1.3s once per user to change to another PasswordHasher is, I guess,
> acceptable.  (There is still a lot of room for optimisation.  Maybe it
> could go down to ~100ms, but probably not any more.)
> [5] Maybe add an `can_be_used’ field to PasswordHasher to indicate that
> even though it should not be used as default, it can still verify.
>
> On 03 Jan 2016, at 14:52, Bas Westerbaan  wrote:
>
> Hynek weighted in[1].  I think the PR is ready to merge.
>
> Best wishes,
>
>   Bas
>
>
> [1] https://github.com/django/django/pull/5876#issuecomment-168411156
>
> On 27 Dec 2015, at 13:39, Florian Apolloner  wrote:
>
> I do not see anything wrong in the PR and there is probably no reason not
> to include it. It would be great if you could get feedback from dstufft
> and/or hynek in #cryptography-dev -- not that we miss something.
>
> Cheers,
> Florian
>
> On Sunday, December 27, 2015 at 12:36:02 AM UTC+1, Bas Westerbaan wrote:
>>
>> Hello,
>>
>> This morning I submitted a Pull Request[1], which adds a PasswordHasher
>> for argon2 – the winner of the Password Hashing Competition.[2]  Tim Graham
>> mentioned I should send an e-mail to this list to discuss it.
>>
>> The patch is mostly pretty straight-forward.  I would like to add a few
>> remarks on some of the choices.
>>
>> 1. There are two Python packages that implement argon2.  Both bind
>> libargon2[3].  The first is argon2_py[4], which uses ctypes.  The second is
>> argon2-cffi[5], which uses... cffi.  Bindings using cffi are more portable,
>> so I choose argon2-cffi.
>>
>> 2. argon2 has four parameters: (i) variety ("type"), (ii) time cost
>> ("t"), (iii) memory cost ("m") and (iv) parallelism ("p").  There are two
>> varieties: argon2i and argon2d.  The first (argon2i) is safest against
>> side-channel attacks.  The second tries less hard to be secure against
>> side-channel attacks in favour of being more resilient against GPU
>> brute-forcing.  For web-apps, the first "argon2i" is the clear choice.  For
>> the other parameters I choose to use the same defaults as of argon2-cffi:
>> t=2, m=512, p=2.  On a i7-4790 @ 3.6Ghz the hash takes around 2ms to
>> compute.
>>
>> Best wishes,
>>
>>   Bas
>>
>>
>>
>> [1] https://github.com/django/django/pull/5876
>> [2] https://password-hashing.net
>> [3] https://github.com/p-h-c/phc-winner-argon2
>> [4] https://github.com/flamewow/argon2_py
>> [5] https://github.com/hynek/argon2_cffi
>>
>
> --
> 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/NTfqP4eNVyA/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
> 

Re: test --keepdb and explicitly migrating the test database

2016-01-25 Thread Marc Tamlyn
Simon - that's great but still means ending up having to create a new test
DB every time you switch to a new branch, something you do a lot if you're
part of the QA process!

+100 to this feature, it would be super useful for me, especially when
working with long running feature branches with migrations.

On 25 January 2016 at 16:33, charettes  wrote:

> FWIW I've been working around this limitation by adding a suffix
> to my `DATABASES['alias']['TEST']['NAME']` setting if the project
> VCS branch is not the default one.
>
> e.g. for Git
>
> import subprocess
>
> branch = subprocess.check_output(['git', 'rev-parse', '--abbrev-ref',
> 'HEAD']).strip()
>
> if branch != 'master':
> for alias in DATABASES:
> database = DATABASES[alias]
> name = database['NAME']
> test_name = database.setdefault('TEST', {}).setdefault('NAME',
> "test_%s" % name)
> database['TEST']['NAME'] = "%s_%s" % (test_name, branch)
>
> Simon
>
>
> Le lundi 25 janvier 2016 07:16:52 UTC-5, Shai Berger a écrit :
>>
>> Hi,
>>
>> While developing against a large project with many migrations, I found
>> 1.8's
>> --keepdb option to the test command a life-saver, changing the time to
>> run the
>> projects test from 7-8 minutes to under one (not even counting the tests
>> themselves). But it is still missing something.
>>
>> If I develop a branch which includes migrations, and -- these things
>> happen --
>> I need to change the migrations (whether because they had a bug, or
>> because I
>> rebased the branch and I need to resolve conflicts), I'm basically out of
>> luck
>> with --keepdb; there's no easy way to roll back migrations on the test
>> database (the only way would be to use a special settings file which
>> defines the
>> test database as a "production" one to roll the migrations back).
>>
>> I would like to have a "--test-db" option to the "migrate" command, which
>> lets
>> me run migrations explicitly against the test database, assuming it
>> exists
>> because of prior invocations of "test --keepdb" (and erroring out if it
>> doesn't, of course).
>>
>> Is it just me?
>>
>> Thanks,
>> Shai.
>>
> --
> 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/7ae240a4-3e21-43bd-a88f-dd75ba59810d%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/CAMwjO1HKiMrhqi%3DQWCd_9GoYHKn3Bp52SQnTTW0OafK1msMzyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Vote on Jira as bugtracker

2016-01-06 Thread Marc Tamlyn
Yeah, this is a non-starter for me. All bug trackers are bad, we should
stick with the bad one we are used to.

Marc

On 6 January 2016 at 13:26, Victor Sosa  wrote:

> To answer you question:
> There is a plug-in to migrate all the data to Jira and similar to
> integrate with any it with any in you infrastructure. (I just don't know it
> all you infrastructure)
>
>
> https://confluence.atlassian.com/jira/importing-data-from-trac-238617182.html
>
> On Wednesday, January 6, 2016 at 9:15:41 AM UTC-4, Daniele Procida wrote:
>>
>> On Wed, Jan 6, 2016, Victor Sosa  wrote:
>>
>> >I felt like lost using trac; it is kind of messy. I just don't feel
>> >comfortable
>> >with it.
>> >I see so many open source project using Jira that is just natural.
>> Search
>> >is easy, categorize is easy, look through the all issues and task is
>> quick.
>> >
>> >I would like to propose a vote on Jira as the bugtracker for this
>> project.
>> >Just vote + or - to see how many people agree on this.
>>
>> Hi Victor. It's a reasonable proposition, but it's not simply a case of
>> choosing what would be nicer: we also have to make it work in our
>> infrastructure - and that's a huge effort.
>>
>> How, for example, would we migrate the many thousands of tickets from
>> Trac to JIRA?
>>
>> How would JIRA be integrated into our current deployment infrastructure?
>>
>> By all means it's useful to get votes on something like this, even before
>> we consider those questions, because if enough people want something it's
>> always possible - but be aware that simply getting lots of votes for it
>> would only ever be the first and easiest step.
>>
>> Having said that: I prefer Trac to JIRA. It's simpler, and faster.
>>
>> Daniele
>>
>> --
> 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/3b4a63f0-e3a4-4d9b-837c-ed98d212488d%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/CAMwjO1GrgWYXB7nZrVNmRqXQ7JcqTUaWQuMPmEJELBz2W5gjeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Request for Input: WSGI 2.0

2016-01-04 Thread Marc Tamlyn
Hi Cory,

[Disclaimer - I don't suppose to speak for the whole community here, this
is a personal opinion of how I see things]

Django's wsgi handling code has remained largely unchanged for many years,
so to answer the question of "what does Django itself need from new wsgi,
ignoring channels", I'd suggest the answer is nothing - wsgi as is works
well for me. As an application developer, I'd also mention that I've never
had a need to dip into the wsgi objects at all, so I can't say I need a
wsgi2 either. In short, the idea of wsgi2 doesn't excite me at all. Perhaps
you could reiterate what the benefits would be to a common garden web
developer?

However, when you bring channels in it changes the topic quite
significantly. I would definitely like channels' communication with the
outside world to be as based on a stable, external python platform as
possible, if only for the volume of code we need to maintain in Django.

I hope that helps a bit..

Marc
On 4 Jan 2016 1:15 p.m., "Cory Benfield"  wrote:

> All,
>
> An effort has begun over in the PSF Web-SIG special interest group to come
> up with a new version of the WSGI specification.
>  The
> goal is to develop a successor to WSGI that will be more useful in the
> development of modern, asynchronous web applications, with the goal of
> making available all of the improvements in both HTTP and Python that have
> come through in the years since PEP 333.
>
> As Django is one of the major users of WSGI, any attempt to specify a new
> version without getting input from the Django community and development
> team would be extremely foolish! This is therefore a request for input: I'd
> like it very much if the Django development team could come up with a
> response to the email linked earlier, indicating what the Django team would
> like from a new version of WSGI and what you believe the priorities should
> be. For obvious reasons there may not be consensus around this issue
> amongst the Django developers, and that's fine: multiple submissions from
> Django would be entirely acceptable.
>
> Trying to improve something as well-established as WSGI is going to be
> extremely difficult, and it'll only work if communities like Django's step
> up to help build something that we can all be proud of. I hope that you're
> as excited by that idea as I am!
>
> A side note: I'm very aware of Andrew Godwin's work with channels, and it
> may be that the Django community believes that that model is the future of
> web programming in Python. If that's the case, then please *let us know*.
> I personally don't believe that it's the right direction for WSGI, but I
> may be wrong (I've been wrong before!).
>
> If you have any questions, please don't hesitate to ask. I'm looking
> forward to working with you all!
>
> Cory
>
> --
> 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/aea5f21c-20c7-49ab-a1ca-2376ca0b92f2%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/CAMwjO1HHJ35a3cXpUMmRGxKxUOXLrxutdLWuGOJJ72uAbW2ERg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: admin: implementing list_prefetch_related

2015-12-30 Thread Marc Tamlyn
Hi Richard,

Overriding the queryset is a pretty simple method override, I'm not sure
there is sufficient need for prefetching here. In particular, the syntax
for prefetch related is much more complex than for select related, so it's
less well suited to this kind of shortcut.

Marc
On 30 Dec 2015 10:26 a.m., "Riccardo Magliocchetti" <
riccardo.magliocche...@gmail.com> wrote:

> Hello,
>
> the need to list an m2m relationship serialized in the admin list view
> happens quite often to me and overriding the queryset may not be as trivial
> as a ModelAdmin attribute. It makes sense to me to match what is possible
> with foreign keys and list_select_related.
> Any opinion on implementing list_prefetch_related for ModelAdmin?
>
> --
> Riccardo Magliocchetti
> @rmistaken
>
> http://menodizero.it
>
> --
> 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/5683B12D.6000600%40gmail.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/CAMwjO1ECoZGJEkGttZtAZeSBUktHRoYCX_hOj-1ehYtGCRSLzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Add "view_decorators" to django.views.generic.View

2015-12-22 Thread Marc Tamlyn
Personally, I find that decorators aren't the best way of interacting with
CBVs. They're useful when you have a mixed style codebase, but I tend to
convert the decorator into a mixin applied at the appropriate point. I
think the style of decorating in the URLconf is horrible.

Marc

On 21 December 2015 at 17:19, Tim Graham  wrote:

> Could you summarize the pros and cons of this new technique versus the
> existing @method_decorator() recommendation [1]? Does it duplicate all the
> functionality provided by method_decorator such that we would no longer
> recommend that technique in the class-based view docs?
>
> [1]
> https://docs.djangoproject.com/en/dev/topics/class-based-views/intro/#decorating-the-class
>
> On Monday, December 21, 2015 at 12:03:15 PM UTC-5, Carl Johnson wrote:
>>
>> I would find that useful. In my experience, I often have a mixture of CBV
>> and non-CBV code, and it's annoying to shoehorn decorators into the as_view
>> method. It would be much more convenient to just add to
>> self.view_decorators.
>>
> --
> 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/39d40372-9e63-4dfc-9378-b2187a95bd25%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/CAMwjO1F09G%2BDmoZB6uQGD-uoQPNuyF5phupFcAxFukx_kkZ-3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: deprecate or undocument shorcuts.render_to_response()?

2015-12-22 Thread Marc Tamlyn
I'd be in favour of just undocumenting it for now.

On 22 December 2015 at 16:27, Alasdair Nicol  wrote:

> I think that updating the docs to use render instead of render_to_response
> is an good change. Many of the CSRF problems that I see new users
> struggling with are solved simply by switching to render.
>
> Since passing context_instance to render_to_response is deprecated in 1.8.
> If I understand correctly, that means that users are already going to have
> to update their code from
>
> return render_to_response('my_template.html',
>   my_context,
>   context_instance=RequestContext(request))
>
> to
>
> return render(request, 'my_template.html', my_context)
>
> You could argue it's not too much to ask users to change
> render_to_response(template, context) to render(request=None, template,
> context) at the same time.
>
> Cheers,
> Alasdair
>
> On Tuesday, 22 December 2015 15:36:57 UTC, Tim Graham wrote:
>>
>> In 2010/Django 1.3 when the render() shortcut was introduced Jacob
>> proposed: "I think we should deprecate render_to_response() in favor of
>> render(). render_to_response() is just render(request=None, ...), right?
>> Any reason to keep both around?"
>>
>> Russ replied: "There's no particular reason to keep both around, other
>> than the code churn that deprecation would entail. This is something that I
>> have no problem deprecating on the 2.0 schedule, but migrating every use of
>> render_to_response() over the next 18 months/2 releases seems like an
>> extreme measure to enforce on the entire user base when maintaining
>> render_to_response() doesn't take any real effort."
>>
>> https://groups.google.com/d/topic/django-developers/mOx9ddVTrPA/discussion
>>
>> I wonder if there would be consensus to move forward with a deprecation
>> of render_to_response() at this point? If not, we could remove
>> render_to_response() from the docs (as we did with the @permalink
>> decorator), or at least lessen its prominence so it's not confusing to new
>> users about which function to use in new code. I started updating the docs
>> by replacing all usage of render_to_response() with render().
>>
>> https://github.com/django/django/pull/5853
>>
> --
> 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/f5203b95-0ed7-4fb0-8088-73829bede644%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/CAMwjO1EKhcuejrZyss6qJJWE04cVpuZNPir5zoHxMo9CFd82Sg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Channels integration plan, first draft

2015-12-18 Thread Marc Tamlyn
[Note: I have not read all the channels docs, sorry if some of these points
are covered there.]

On a packaging note, is there a way to use django[channels] type syntax
like flask does? I'm not familiar with the restrictions of this but it may
remove the need for try/except imports.

I'm also curious about what a "small scale" deployment of channels would
look like. It has features which are useful to small sites which deploy on
a single server or heroku dyno. It would be great to be able to run a
complete channels stack with in memory communication with a single process
start - something as easy as gunicorn wsgi.py. I know you are intending
this to be possible for users not using channels, but when it has features
so useful for modern web apps like tasks and websockets, getting a no-setup
deploy of this working would be a huge win over celery/other systems.
Obviously you would lose the no down time deploys here.

I've said this in person to you, but I think a REDIS_SERVERS setting like
DATABASES would be a hugely useful feature for django independently of
channels, especially if it supported tests well. I'm yet to find a third
party app which does this well.

Testing in general is an interesting question - how do you envisage a test
environment would run? Would self.client go straight to the consumer? How
would you test the channel setup? Will there be test utilities to test,
say, that a given message has been sent to a given channel without
consuming it?

You talk about being able to load balance between backend tasks and
requests. Is there am easy way to not do this in a multi server setup,
where say image processing is on a box with far more RAM than is needed for
a request processing box?

Have you considered a means of asking the channels system how much load it
is under so that systems could do intelligent autoscaling?

Marc
On 18 Dec 2015 4:17 p.m., "Andrew Godwin"  wrote:

>
>
> On Fri, Dec 18, 2015 at 3:44 PM, Mark Lavin  wrote:
>
>> > You seem to be assuming I'm here to foist a brand new middle layer on
>> everyone; I'm not. I'm here to make one that fits neatly into Django, that
>> I think most people will want to turn on, and that provides a lot of value
>> in exchange for a slight round-trip performance hit - my goal is sub-5ms,
>> and preferably sub-3. If it starts being 10/20/30 milliseconds of cost,
>> then we'll have to change our approach until it's acceptable.
>>
>> Yes that's how I read this plan and that's why I think it needs some
>> clarity. I didn't mean for this to turn into a long discussion about
>> performance. This was meant to be a discussion about the transition plan.
>> To go back to my original message, I see no gain for existing WSGI
>> applications to have this on by default, even using the in-memory
>> channel, when they upgrade to 1.10 (or whenever this lands). The current
>> plan reads as though it will.
>>
>
> I agree - that was my original intention and how the current version of
> channels works, but it's no longer my plan, and I should update the
> integration plan to be more specific and discuss things like introducing
> different HttpRequest subclasses other than WSGIRequest.
>
> To be clear, 1.10 might have a different request handling stack than 1.9
> that isn't so WSGI-native, but there's still going to be a way to get a
> request in and a response out directly without hitting Channels. It's
> almost enforced by the channels design, actually, as the entire Django URL
> and view system would have to run as a single consumer there anyway.
>
>
>> From what you are saying above this sounds more like a
>> django.contrib.channels than a django.core.channels. Either way I feel the
>> plan should provide more clarity in that regard.
>>
>
> Also true - it's not immediately apparent why it shouldn't be contrib or
> even entirely separate, but there are good reasons, chief among them being
> that channels needs some low-level changes to the HTTP subclasses and
> session framework; it's somewhat similar to migrations in this regard. The
> 1.8/1.9 app versions are going to be full of monkeypatches and not perform
> as well as I won't be able to eliminate all the duplicate code being run.
>
> I also have a philisophical belief that we should highlight the channels
> model as the new "base layer" of Django - teaching people how everything
> else builds on it to do view handling, socket handling, background tasks,
> etc. - but that isn't at odds with direct-WSGI handling; an in-memory
> backend and direct handling are basically indistinguishable from the
> outside.
>
> I'll work on another draft that more clearly highlights WSGI and direct
> request handling in the "keeping Django the same part" - hopefully that
> will help make things clearer.
>
>
>>
>> Andrew, I thank you for your patience and civility in these discussions.
>> I know this is something you've been working hard on and I'm not trying
>> to be needlessly critical of 

Re: Split DeleteView into a more generic ConfirmView

2015-12-11 Thread Marc Tamlyn
No problem - I mentioned this thread on twitter to one of the braces devs
and he also likes your idea.
https://twitter.com/kennethlove/status/674237007439073280

On 10 December 2015 at 23:52, Lennart Buit <lennartb...@gmail.com> wrote:

> Hello Marc,
>
> Thanks for your response, I will change my proposal to target
> django-braces. Will take me a few days tho, because I am loaded with
> (school) work right now :).
>
> --Lennart
>
> On Tuesday, December 8, 2015 at 10:38:01 AM UTC+1, Marc Tamlyn wrote:
>>
>> Hi Lennart,
>>
>> I certainly like the idea and have written at least two implementations
>> of `ConfirmView` in my projects before. Without getting into specifics, I'm
>> not sure how we feel about adding more generic views like this, even where
>> it does make sense. To me a good initial course of action could be to
>> consider integrating it with django-braces. They have a collection of
>> common mixins for common or fairly common CBV patterns. In fact we have
>> already merged commonly used parts of django-braces into contrib.auth for
>> 1.9.
>>
>> Marc
>>
>> On 7 December 2015 at 20:28, Lennart Buit <lenna...@gmail.com> wrote:
>>
>>> I should add patches that I promise to add ;)
>>>
>>> --Lennart
>>>
>>>
>>> On Monday, December 7, 2015 at 9:23:19 PM UTC+1, Lennart Buit wrote:
>>>>
>>>> Hey all,
>>>>
>>>> One of my minor annoyances with the class based view system in django
>>>> is that there is no clear way to model a confirmable action. The concept
>>>> does exists in cbv, but only for deleting objects. I however think that
>>>> there are more usages for confirming actions other then delete.
>>>>
>>>> Lets look at an example, a news site can CRUD newsaticles. But this
>>>> news site has some articles for free, and some other behind a paywall.
>>>> Also, editors on this site can publish newsarticles (after which they come
>>>> in the pay section), and then promote them to free articles. The views in
>>>> django would then look as follows (with some brevity):
>>>>
>>>> # This also goes for Update/Delete/...
>>>> class NewsArticleCreateView(CreateView):
>>>> model = NewsArticle
>>>>
>>>> # This also goes for Promote
>>>> class NewsArticlePublishView(DetailView):
>>>> model = NewsArticle
>>>> success_url = 'somewhere'
>>>>
>>>> def post(self, *args, **kwargs):
>>>> self.object = self.get_object()
>>>> success_url = self.get_success_url()
>>>> self.object.published = True
>>>> self.object.save()
>>>>
>>>> return HttpResponseRedirect(success_url)
>>>>
>>>> def get_success_url(self):
>>>> if self.success_url:
>>>> return self.success_url.format(**self.object.__dict__)
>>>> else:
>>>> raise ImproperlyConfigured(
>>>> "No URL to redirect to. Provide a success_url.")
>>>>
>>>> The problem, I think, is that we are copying most of a DeleteView for a
>>>> fairly standard confirmable action. The get_success_url function is almost
>>>> the same, and most of the code found in the post function is that of delete
>>>> in DeleteView. I think therefore that we should consider splitting the
>>>> DeleteMixin in a more generic ConfirmMixin, make DeleteMixin a subclass of
>>>> ConfirmMixin, and introduce the (more) generic BaseConfirmView and
>>>> ConfirmView. The above example will then look as follows:
>>>>
>>>> class NewsArticlePublishView(ConfirmView):
>>>> model = NewsArticle
>>>> success_url = 'somewhere'
>>>>
>>>> def action_confirmed(self):
>>>> self.object.published = True
>>>> self.object.save()
>>>>
>>>> I think the benefits of this solution are clear, we introduce
>>>> readability in these types of views (look at the class declaration, its a
>>>> confirm view alright!) at the cost of library size (another 3 classes got
>>>> added).
>>>>
>>>> Please be gentle, I am new here ;). But, I enjoy a technical
>>>> discussion! And I attached a patch

Re: Split DeleteView into a more generic ConfirmView

2015-12-08 Thread Marc Tamlyn
Hi Lennart,

I certainly like the idea and have written at least two implementations of
`ConfirmView` in my projects before. Without getting into specifics, I'm
not sure how we feel about adding more generic views like this, even where
it does make sense. To me a good initial course of action could be to
consider integrating it with django-braces. They have a collection of
common mixins for common or fairly common CBV patterns. In fact we have
already merged commonly used parts of django-braces into contrib.auth for
1.9.

Marc

On 7 December 2015 at 20:28, Lennart Buit  wrote:

> I should add patches that I promise to add ;)
>
> --Lennart
>
>
> On Monday, December 7, 2015 at 9:23:19 PM UTC+1, Lennart Buit wrote:
>>
>> Hey all,
>>
>> One of my minor annoyances with the class based view system in django is
>> that there is no clear way to model a confirmable action. The concept does
>> exists in cbv, but only for deleting objects. I however think that there
>> are more usages for confirming actions other then delete.
>>
>> Lets look at an example, a news site can CRUD newsaticles. But this news
>> site has some articles for free, and some other behind a paywall. Also,
>> editors on this site can publish newsarticles (after which they come in the
>> pay section), and then promote them to free articles. The views in django
>> would then look as follows (with some brevity):
>>
>> # This also goes for Update/Delete/...
>> class NewsArticleCreateView(CreateView):
>> model = NewsArticle
>>
>> # This also goes for Promote
>> class NewsArticlePublishView(DetailView):
>> model = NewsArticle
>> success_url = 'somewhere'
>>
>> def post(self, *args, **kwargs):
>> self.object = self.get_object()
>> success_url = self.get_success_url()
>> self.object.published = True
>> self.object.save()
>>
>> return HttpResponseRedirect(success_url)
>>
>> def get_success_url(self):
>> if self.success_url:
>> return self.success_url.format(**self.object.__dict__)
>> else:
>> raise ImproperlyConfigured(
>> "No URL to redirect to. Provide a success_url.")
>>
>> The problem, I think, is that we are copying most of a DeleteView for a
>> fairly standard confirmable action. The get_success_url function is almost
>> the same, and most of the code found in the post function is that of delete
>> in DeleteView. I think therefore that we should consider splitting the
>> DeleteMixin in a more generic ConfirmMixin, make DeleteMixin a subclass of
>> ConfirmMixin, and introduce the (more) generic BaseConfirmView and
>> ConfirmView. The above example will then look as follows:
>>
>> class NewsArticlePublishView(ConfirmView):
>> model = NewsArticle
>> success_url = 'somewhere'
>>
>> def action_confirmed(self):
>> self.object.published = True
>> self.object.save()
>>
>> I think the benefits of this solution are clear, we introduce readability
>> in these types of views (look at the class declaration, its a confirm view
>> alright!) at the cost of library size (another 3 classes got added).
>>
>> Please be gentle, I am new here ;). But, I enjoy a technical discussion!
>> And I attached a patch that implement this proposal, it however should be
>> treated as a POC, not a complete implementation with tests and docs and
>> such.
>>
>> --Lennart
>>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/16df2f54-fee9-4b5d-9882-bc9954a5c8dd%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FAq3USc3oUUnitCTDpquq%2B_UDJySt%2BUhM41VRN%2B89G_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Backporting ticket 25548 into 1.9.x

2015-12-06 Thread Marc Tamlyn
Agreed the reasoning is sound. This is a major bug as far as I'm concerned
and I'd like to see it backported. Thanks for bringing it up.

Marc
On 6 Dec 2015 1:05 p.m., "Shai Berger"  wrote:

> On Sunday 06 December 2015 14:52:08 Aymeric Augustin wrote:
> > > On 6 déc. 2015, at 10:49, James Bennett  wrote:
> > >
> > > Thoughts?
> >
> > I don’t think anyone ever prevented a core dev who wanted to backport a
> > commit from doing so — unless it carried a risk of backwards
> > incompatibility, which doesn’t appear to be the case here.
>
> Not to my knowledge also, but we did have a policy change, about two years
> ago, against arbitrary backports at a core-dev's judgment (which was the
> norm
> until then). So, I find it very proper that James has brought this up on
> the
> list.
>
> That said, the reasoning for backporting seems sound to me, so +1.
>
> Shai.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1F949HA_pZis54b7S55ZKbdUTLcdEMefOx2wa%2Bx3_dqwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: worth adding PyPy to continuous integration?

2015-12-02 Thread Marc Tamlyn
If we can get it running on the CI reasonably easily I see no reason why
not.

On 2 December 2015 at 16:46, Tim Graham  wrote:

> Once in a while, we get a ticket about failures when running the Django
> test suite on PyPy. Sometimes they are bugs in PyPy, other times we use
> something that's not available or behaves differently in PyPy. Is it worth
> adding PyPy to our continuous integration so we can proactively address
> these issues?
>
> (We can't test with pypy3 since that's based on Python 3.2 which we've
> dropped support for in Django 1.9.)
>
> Recent tickets:
> https://code.djangoproject.com/ticket/24779
> https://code.djangoproject.com/ticket/25844
>
> Current failures with pypy 2.4.0 and Django 1.9:
>
> ==
> ERROR: test_serialize_datetime (migrations.test_writer.WriterTests)
> --
> Traceback (most recent call last):
>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 248,
> in test_serialize_datetime
> self.assertSerializedEqual(datetime.datetime.utcnow)
>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 179,
> in assertSerializedEqual
> self.assertEqual(self.serialize_round_trip(value), value)
>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 175,
> in serialize_round_trip
> string, imports = MigrationWriter.serialize(value)
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 540,
> in serialize
> "topics/migrations/#migration-serializing" % (value,
> get_docs_version())
> ValueError: Cannot serialize:  'datetime.datetime'>>
> There are some values Django cannot serialize into migration files.
> For more, see
> https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing
>
> ==
> ERROR: test_simple_migration (migrations.test_writer.WriterTests)
> --
> Traceback (most recent call last):
>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 459,
> in test_simple_migration
> output = writer.as_string()
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 167,
> in as_string
> operation_string, operation_imports =
> OperationWriter(operation).serialize()
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 124,
> in serialize
> _write(arg_name, arg_value)
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 76, in
> _write
> arg_string, arg_imports = MigrationWriter.serialize(item)
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 357,
> in serialize
> item_string, item_imports = cls.serialize(item)
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 433,
> in serialize
> return cls.serialize_deconstructed(path, args, kwargs)
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 318,
> in serialize_deconstructed
> arg_string, arg_imports = cls.serialize(arg)
>   File "/home/tim/code/django/django/db/migrations/writer.py", line 540,
> in serialize
> "topics/migrations/#migration-serializing" % (value,
> get_docs_version())
> ValueError: Cannot serialize:  'datetime.datetime'>>
> There are some values Django cannot serialize into migration files.
> For more, see
> https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing
>
> ==
> ERROR: test_band_data_setters
> (gis_tests.gdal_tests.test_raster.GDALBandTests)
> --
> Traceback (most recent call last):
>   File "/home/tim/code/django/tests/gis_tests/gdal_tests/test_raster.py",
> line 357, in test_band_data_setters
> bandmem.data(packed_block, (1, 1), (2, 2))
>   File "/home/tim/code/django/django/contrib/gis/gdal/raster/band.py",
> line 133, in data
> data_array = ctypes_array.from_buffer_copy(data)
> AttributeError: type object 'c_ubyte_Array_4' has no attribute
> 'from_buffer_copy'
>
> ==
> FAIL: test_prefetch_related_queryset
> (model_forms.tests.OtherModelFormTests)
> --
> Traceback (most recent call last):
>   File "/home/tim/code/django/tests/model_forms/tests.py", line 2308, in
> test_prefetch_related_queryset
> (red_item.pk, 'red'),
>   File "/home/tim/code/django/django/test/testcases.py", line 93, in
> __exit__
> query['sql'] for query in self.captured_queries
> AssertionError: 2 queries executed, 4 expected
> Captured queries were:
> SELECT "model_forms_colourfulitem"."id",
> "model_forms_colourfulitem"."name" FROM "model_forms_colourfulitem"
> SELECT 

Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

2015-11-25 Thread Marc Tamlyn
I can see a use for this, but the API is unsure. Given that from a
performance point of view it should be possible to do this as a transform
after a values query (in most cases using a similar lazy sequence-like
object will maintain the performance you need), can I propose implementing
it as an external app to find a good API. Once this has been done, we can
look at how buildable that API is at a lower level to get the maximum
performance.

On 25 November 2015 at 18:21, Moenad  wrote:

> I think I wasn't clear from the beginning, the idea of "nested" is to nest
> all possible levels, not just a single level. I like the idea of "N", given
> that you can have more control, but having something like N("person",
> "person__hometown", "person__hometown__country") which will be different
> than N("person__hometown__country") is confusing.
>
> I have another idea, why not make the alias + nest possible with a single
> parameter, where it takes a dictionary and expect how the final structure
> and aliasing are?
>
> For example:
>
> {"id": "custom_id"
>  "first_name": "custom_first_name",
>  "last_name": "custom_last_name",
>  "hometown": {
>   "__alias__": "custom_hometown"
>   "id": "custom_hometown_id",
>   "name": "custom_name",
>   "country": "custom_country"
>   }
> }
>
> or to make it a standard in someway,
>
> {"id": "custom_id"
>  "first_name": "custom_first_name",
>  "last_name": "custom_last_name",
>  "hometown": {
>   "__alias__": "custom_hometown"
>   "hometown__id": "custom_hometown_id",
>   "hometown__name": "custom_name",
>   "hometown__country": "custom_country"
>   }
> }
>
> as you noticed, if there's a foreign key for example, a new key
> "__alias__" or something should be added in the dict. Also, no need for
> values() *args, the dict structure would be more than enough?
>
>
> On Wednesday, November 25, 2015 at 7:21:43 PM UTC+2, Joachim Jablon wrote:
>>
>> Marten's suggestion is quite interesting for providing a way to tell
>> which data you want nested and which data you don't. Plus, this form
>> might be interesting to solve another problem : how would Django know if we
>> want :
>>
>> {"id": 1
>>  "first_name": "first name",
>>  "last_name": "last name",
>>  "hometown": {
>>   "id": 1,
>>   "name": "town name",
>>   "country": 3
>>   }
>> }
>>
>>
>> # or
>>
>>
>> {"id": 1
>>  "first_name": "first name",
>>  "last_name": "last name",
>>  "hometown": {
>>   "id": 1,
>>   "name": "town name",
>>   "country": {
>> "id": 3,
>> "name": "country name"
>>   }
>>   }
>> }
>>
>>
>>
>> Limiting the nesting to a single level would be an arbitrary decision and
>> users should be able to control this (IMHO)
>>
>> So we could have a "level" argument that would say how many levels deep
>> it will search but then what if you want SOME nesting in some branches, not
>> in others, like :
>>
>> {"id": 1
>>  "first_name": "first name",
>>  "last_name": "last name",
>>  "hometown": {
>>   "id": 1,
>>   "name": "town name",
>>   "country": {
>> "id": 3,
>> "name": "country name"
>>   }
>>   },
>>   "father": 4
>> }
>>
>>
>> (here, "father" is another FK that we don't want expanded ?
>>
>> Maybe a syntax like :
>>
>> N("person", "person__hometown", "person__hometown__country")
>> Note : this might not be equivalent to N("person__hometown__country"),
>> that you could use if you want ONLY the nested "country"
>>
>> I'd like that.
>>
>> And it's compatible with the suggestion of using **kwargs for aliasing
>> (for the top level element of the dict, at least)
>>
>> Le mercredi 25 novembre 2015 17:53:25 UTC+1, Marten Kenbeek a écrit :
>>>
>>> I think it'd be more consistent with other parts of the ORM to use
>>> **kwargs to specify aliases. For nested data you can use an object, say N,
>>> similar to Q and F objects:
>>>
>>> Articles.objects.filter(id=1).values('body', N('author'),
>>> my_custom_title='title')
>>>
>>> I'm no ORM expert, but could something like this be possible by allowing
>>> expressions in values() and using custom output fields?
>>>
>>> On Wednesday, November 25, 2015 at 5:09:29 PM UTC+1, Moenad wrote:

 Well, switch the field name aliasing to a dictionary without hijacking
 **kwargs ?

 I prefer the following:

 Articles.objects.get(id=1).values(’title’, ’author’, ‘body',
 alias={"title": "my_custom_title"}, nested=True)


 On Wednesday, November 25, 2015 at 5:43:51 PM UTC+2, Tim Graham wrote:
>
> There's an accepted ticket for adding aliasing to values():
> https://code.djangoproject.com/ticket/16735
>
> The current patch there hijacks values() **kwargs for the mapping of
> renamed fields which would prevent adding other kwargs like "nested"
> without disallowing those values as aliases. I guess we may want to 
> rethink
> that approach.
>
> On Wednesday, November 25, 2015 at 10:20:37 

Re: Keep django/django-old GitHub repo?

2015-11-25 Thread Marc Tamlyn
As there are no active PRs there any more I'm pretty sure it can be ditched.

On 25 November 2015 at 14:36, Tim Graham  wrote:

> Does https://github.com/django/django-old provide any value? I think it
> can be deleted. Maybe there are a few links to the pull requests there but
> I've never come across any.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/cefde00b-f822-45e4-a706-18273a236975%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HNX8rO9KkFpe62Hb%3DV8SijHLBmNpBi2q3XC6%2BtL0Fsmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Make template caching a feature of the Django template engine

2015-11-24 Thread Marc Tamlyn
So. If I understand correctly, this would deprecate the existing cached
template loader, replace it with a more powerful, debug ready version (on
by default?). Assuming this is what you mean, I wholeheartedly support
this. There's no reason not to be performant by default.

Marc
On 23 Nov 2015 2:16 pm, "Jaap Roes"  wrote:

> It’s considered a good practice to enable template caching in Django. It
> saves on the overhead of loading and parsing templates and turning them
> into template objects, which can give a nice performance boost when
> repeatedly rendering the same templates.
>
> Currently it’s possible to enable template caching by using the cached
> loader. To do so you’ll need to add the loaders option to the engine
> settings and set it to a nesting of lists/tuples (I’ll wager no one can get
> this correct on the first try without first consulting the docs). This
> makes enabling template caching needlessly hard, and the discoverability of
> this feature lower than necessary. To this day I run into developers who
> have worked with Django for years but are unaware of the cached loader.
>
> One of the downsides of enabling the cached loader is that it will cache
> templates until the server is reloaded. This makes it ill suited for
> development. I have, on many occasions, seen developers (including myself)
> forget to turn off template caching in their local settings, resulting in
> lost time trying to figure out why their changes are not showing.
>
> I think Django can, and should do better. The bare minimum is to make
> template caching a simple toggle option that can be passed to the engine (
> https://code.djangoproject.com/ticket/25788 /
> https://github.com/jaap3/django/commit/21e9d3aa0eb0a9d2728f8a35318d49d528f3a60f
> (an admittedly naive patch)). This way cache_templates could simply mirror
> DEBUG and (new) projects can have a sane template caching configuration by
> default.
>
> It would also be useful to have caching enabled in development so the
> template loading behaviour is (mostly) the same in development as it is in
> production.
>
> One reason for this is that custom template tags need to be thread safe (
> https://docs.djangoproject.com/en/1.8/howto/custom-template-tags/#thread-safety-considerations).
> Because cached templates always reuse the nodes it’s easier to notice when
> a template tag misbehaves.
>
> Another reason is that the performance of template rendering will be
> roughly the same development as in production, which can make a great
> difference if you’re working with complex templates and/or custom tags that
> perform expensive operations in their __init__.
>
> Off course, having caching on in development is impractical if templates
> stay cached forever. So some sort of template invalidation and reloading
> system needs to be added. It’s actually fairly easy to add this to the
> cached loader https://code.djangoproject.com/ticket/25791 /
> https://github.com/jaap3/django/commit/20e1caa9f923d82ce60dff155304de5289242186
> (an earlier/alternative implementation that moves caching to the engine can
> be found here:
> https://github.com/prestontimmons/django/commit/4683300c60033ba0db472c81244f01ff932c6fb3
> ).
>
> With caching and auto reloading as a core feature of Django’s engine it
> will be (somewhat) on par with the alternative Jinja2 engine shipped by
> Django. Jinja2’s Engine lets you configure an Environment (
> http://jinja.pocoo.org/docs/dev/api/#jinja2.Environment) using the
> engine's options. This includes setting a bytecode_cache and enabling
> auto_reload (this last option mirrors DEBUG by default in Django).
>
> So in short, I propose making template caching a true feature of Django’s
> template engine. Which can be configured in a way similarl to the Jinja2
> engine (and could be on by default for new projects):
>
> TEMPLATES = [{
> 'BACKEND': 'django.template.backends.django.DjangoTemplates',
> 'DIRS': [os.path.join(BASE_DIR, 'templates')],
> 'APP_DIRS': True
> 'OPTIONS': {
> 'cache_templates': True,
> 'auto_reload': DEBUG  // this could be the default set by the
> engine
> }
> }]
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c2897e2b-c506-44e3-93e4-cb077bb8f4ac%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because 

Re: Bringing some popular must have django tools/packages under django org umbrella

2015-11-24 Thread Marc Tamlyn
This is something the core team discussed in Amsterdam. I believe there was
consensus to trial it with Django registration. I should catch up with
James and see if it is transferred. If this goes well I see no reason why
not.

The biggest problem is the selection of packages, we have historically
wanted to avoid too much bikeshedding. Initially it's likely to be mostly
relatively inactive small utilities I think. But I think we are open to
being more risky here.

M
On 24 Nov 2015 7:02 pm, "Asif Saifuddin"  wrote:

> The projects will have the official tool status + the maintainer of the
> projects will be able to collaborate better with django core team? less
> risk of being abandoned by the maintainers etc.
>
> IMHO
>
> On Wed, Nov 25, 2015 at 12:31 AM, Collin Anderson 
> wrote:
>
>> Hi,
>>
>> Say a little bit more: What would be the goal? What would you hope would
>> be accomplished by doing this?
>>
>> Thanks,
>> Collin
>>
>> On Tuesday, November 24, 2015 at 1:27:11 PM UTC-5, Asif Saifuddin wrote:
>>>
>>> How is the idea? tools like django-debug-toolbar, django-silk,
>>> django-taggit, django-filter etc and some more de facto tools under the
>>> umbrella of django github org?
>>>
>>> Regards
>>>
>> --
>> 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/bIzfHebE2sw/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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/70062405-3ccd-49b2-9118-ec1679203cd1%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAKAqTgrnMoqy-%3DdDUx31Dgru6XTzT3e-T%3DhspY-CDK5tV9k1gQ%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FzQ8cCgF7pR%2BRtPiSkNc5W4ipeWfwLz0hi4q_xzxZoAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Non-atomic migrations in Django?

2015-11-24 Thread Marc Tamlyn
+1 to idea and API. I've wished I had this recently - even if it's just so
I can check up on the progress of a slow running data generation migration
so it flushes the data every few 100 records.

On 24 November 2015 at 16:07, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> I like the API as well. Surprisingly, I couldn't find a Trac ticket about
> this.
>
> --
> Aymeric.
>
> 2015-11-24 16:39 GMT+01:00 Anssi Kääriäinen :
>
>> I don't see any problem with optional non-transactional migrations. So,
>> +1 for the idea and API. I haven't looked at the implementation, so no
>> comments about that.
>>
>>  - Anssi
>>
>>
>> On Tuesday, November 24, 2015, Ludwig Hähne  wrote:
>>
>>> Hi all,
>>>
>>> I'd like to get your feedback on supporting non-atomic migrations in
>>> Django.
>>>
>>> Database transactions are always wrapped in transactions (on DBs that
>>> support transactional DDL like Postgres). Generally this is a good idea.
>>>
>>> However, one can't do batched updates in data migrations which is
>>> essential for performing changes on big tables on a live DB [1]. It's also
>>> not possible to create indexes concurrently on Postgres from inside a
>>> transaction.
>>>
>>> Therefore, I'd like to have support for non-atomic migrations in Django
>>> because it's pretty messy to work around not having proper support for that
>>> [2].
>>>
>>> Here's a proof-of-concept implementation [3] of exempting specific
>>> migrations from being wrapped in a transaction by setting `atomic = False`
>>> on the migration:
>>>
>>>
>>> https://github.com/django/django/compare/master...Ableton:non-atomic-migrations
>>>
>>> Do you agree that non-atomic migrations should be supported by Django?
>>>
>>> Is setting an `atomic` property on a migration a good API for that?
>>>
>>> If there's a chance this will be merged, I'd add documentation,
>>> incorporate your feedback, and open a ticket or PR.
>>>
>>> Thanks,
>>> Ludwig
>>>
>>> [1] http://pankrat.github.io/2015/django-migrations-without-downtimes/
>>> [2]
>>> http://stackoverflow.com/questions/31247810/commit-manually-in-django-data-migration
>>> [3]
>>> https://github.com/django/django/compare/master...Ableton:non-atomic-migrations
>>>
>>> --
>>> 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 http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/c062736d-2ebc-42cd-83a5-fe4d064cb24e%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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CALMtK1GDj0_wheW5dHEdp1ZLYcXa-6OpxfHgcnHqWtMcT9YG0g%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Aymeric.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CANE-7mUiytuj26np%3DzP-kX4fHmPv3i0u7Hn-a8GTGuHk4sF3qw%40mail.gmail.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 

Re: [Feature Request] Performant values_list query

2015-11-16 Thread Marc Tamlyn
To give some brief historical context: values_list has been around a LONG
time, so I wouldn't say anyone has consciously designed it with performance
in mind above "it's faster than complete model loading".

The most noticeable thing which your code does not do which an
implementation of values list would need to do is interpreting everything
as the correct data type. It's possible though that you can optimise cases
where no conversions are needed (which is the majority case with postgres).
The code which implements db converters for normal ORM queries attempts to
do this, I'm not sure how similar the code paths for values_list are.

Marc

On 16 November 2015 at 16:29, Tim Graham  wrote:

> I don't think there is much database backend specific logic as far as
> values_list() goes, but if you get something working on SQLite and send a
> pull request, we can easily run it on all database backends.
>
> For performance testing, you might find
> https://github.com/django/djangobench/ useful.
>
> On Monday, November 16, 2015 at 10:13:41 AM UTC-5, Cristiano Coelho wrote:
>>
>> Hi, thanks for the response! I have never developed nor ran the django
>> test suite, I can certainly try as you mentioned, I was hoping for anyone
>> that actually implemented values_list to give me a solid reason to not do
>> any change as I'm probably wrong and the current way it is implemented is
>> the fastest approach.
>> I guess I can play with the tests for a while. However I believe the
>> tests will need to be ran against all db backends? Installing all databases
>> will be a little complicated.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/35204d24-5d25-4dad-966b-8a8dea13ca1e%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GxZaaYGmxiXSV4GHGw5veAut9RECxAY2DVqGLEzLYz5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Oracle GIS update

2015-11-10 Thread Marc Tamlyn
Thanks for getting it running at all!

It looks to me like those tests just need to be less accurate for Oracle,
good plan.

Did you have any specific changes to make to get it to run at all? If so we
should include those soon, irrespective of whether the fixes for these
other tests make it into 1.9 final.

Marc
On 5 Nov 2015 8:21 pm, "Jani Tiainen"  wrote:

> Hi, I finally had time to get back on Oracle GIS issues.
>
> I ran test suite against 1.9.x and 7 tests fails.
>
> 3 tests are most probably due different algorithms used to calculate
> geographical distance and areas. My proposal for fix is to use backend
> spesific values.
>
> Failing testcases are:
> ==
> FAIL: test_distance_function
> (gis_tests.geogapp.tests.GeographyFunctionTests)
> AssertionError: 4899.67677194225 != 4891.2 within 2 places
> ==
> FAIL: test_geography_area (gis_tests.geogapp.tests.GeographyFunctionTests)
> AssertionError: 5439100.13586914 != 5439100.95415646 within 5 places
> ==
> FAIL: test06_geography_area (gis_tests.geogapp.tests.GeographyTest)
> AssertionError: 5439100.13586914 != 5439100.95415646 within 5 places
> ==
>
>
>
> 4 tests are unknown failures that require further investigation.
> Failing testcases are:
> ==
> FAIL: test_difference (gis_tests.geoapp.test_functions.GISFunctionsTests)
> ==
> FAIL: test_difference_mixed_srid
> ==
> FAIL: test_intersection (gis_tests.geoapp.test_functions.GISFunctionsTests)
> ==
> FAIL: test_sym_difference
> (gis_tests.geoapp.test_functions.GISFunctionsTests)
> ==
>
> --
> Jani Tiainen
>
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAHn91ofJ0QQjKJ9KZXwBMLhyD59AN6sxq%3D_JtNz6xeuujH8tEw%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GS6R1zrDFaN5Xv1iF2nSj6s%3Dvc-qD1NOnXKbnhJZbEOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal: add new template tag "age"

2015-11-10 Thread Marc Tamlyn
Agreed, this does not belong on core. In particular the formatting of a
duration varies widely depending on the expected age range, languages and
site context. Naturaltime is one implementation, the specific case you seem
to be hinting at is a count of years, which is definitely too particular
for Django inclusion. would make a perfect third party app though!

Mar
On 10 Nov 2015 2:57 am, "Dheerendra Rathor" 
wrote:

> If we ever need to implement age filter, I would rather suggest for
> modification of naturaltime in django.contrib.humanize to take an optional
> parameter (age = True).
>
> On Tue, 10 Nov 2015 at 01:22 Tim Graham  wrote:
>
>> For questions of whether or not to include something like this in core,
>> my own rule of thumb is, "Is this difficult to implement as a third-party
>> package? If not, do more than ~80% of sites need this feature?" If the
>> answer to both questions is "no" (which is the case here, in my opinion),
>> then I don't favor including it in Django.
>>
>> For historic reasons we have some filters like phone2numeric which likely
>> don't meet this criteria. I don't see much benefit to deprecating them, but
>> let's not add more. Other opinions welcome.
>>
>>
>> On Monday, November 9, 2015 at 2:43:46 PM UTC-5, Paulo Maciel wrote:
>>>
>>> My proposal is to add a new template tag "age": {{ birthday|age }}.
>>> I think it is a common need for many users know the age from a date.
>>>
>>>
>>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/d9ce1b89-1af0-4038-816f-24e13d25a666%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAByqUgjS8nzfuwa_CApjAky-LTmADdukU9sKL3bLyh5ogA1oeA%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HHwU2d7Lngw0f4zQAt%3DOFEJmK%3DCC0TF8pXsXm2ixjobA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Provide a way to pass kwargs when initializing the storage class

2015-11-08 Thread Marc Tamlyn
I'm definitely in favour of a format allowing multiple storage back ends
referred to by name. For larger sites it is not unusual to manage files
across multiple locations (eg several S3 buckets). The storage param to
FileField would be allowed to be the key, and there would be a get_storage
function like get_cache.

This is especially useful when testing locally as you can swap out
dependencies on external server storages for local temp storage.

(Side point: a temp dir based storage which could clean itself up between
rest runs would be amazing)
On 7 Nov 2015 17:07, "Claude Paroz"  wrote:

> The drawback of complex dictionary settings is that to overwrite only one
> key in a settings file, you have to copy the entire dictionary, also
> possibly defeating global settings defaults when they change.
>
> So let's try to have many smaller dictionaries instead of few big ones.
> The initial proposal was a bit better at this regard.
>
> Claude
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e180cd2b-9601-44cd-9ba4-21e3a7d10157%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Ei7WUfbM%2B%3DYnJ%2Bpm75ifpqJVaUoexikooD2Zk7AA8tfQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: a standard descriptor signature?

2015-10-26 Thread Marc Tamlyn
Sounds good to me. There's not any (good) reason why anyone would be
calling these with kwargs that I can think of so we're safe from a compat
perspective.

Marc

On 26 October 2015 at 03:25, Loïc Bistuer  wrote:

> +1
>
> > On Oct 25, 2015, at 23:09, charettes  wrote:
> >
> > Now that Curtis did all the investigation work I think it wouldn't hurt
> being consistent here.
> >
> > __get__(self, instance, cls=None) and __set__(self, instance, value)
> look like sane defaults to me.
> >
> > Le samedi 24 octobre 2015 18:36:32 UTC-4, Tim Graham a écrit :
> > Curtis, or should I say FunkyBob, raised the issue here:
> https://github.com/django/django/pull/5226
> >
> > Currently we have several different signatures:
> >
> > def __get__(self, instance, instance_type=None)
> > def __get__(self, obj, type=None):
> > def __get__(self, instance, type=None)
> > def __get__(self, obj, objtype)
> > def __get__(self, instance, owner)
> >
> > and the Python docs don't seem to have a single preference.
> >
> > Curtis proposed:
> > """
> > * "instance_type" is explicit
> > * "cls" is a common convention for passing a class
> > * "owner" is in the docs {but so are others}
> > * and "type" I think is a bit confusing...
> >
> > So... my preference, upon reflection, would be: def __get__(self,
> instance, cls=None):
> > """
> >
> > For set, it's mostly: def __set__(self, instance, value)
> > but a couple times: def __set__(self, obj, value)
> >
> > Do you think it's worth trying to be consistent or not?
> >
> > --
> > 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 http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/39cb93c3-a6e5-4deb-b34f-95bd844a764e%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/B22998EC-5FCB-4212-AA2D-A50698F75B6C%40gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EA8EZFb8soPT1QDYJije7VYb59hHMfSzJnZocS0HRZSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Python 3.5 Support in Django 1.8.x?

2015-10-23 Thread Marc Tamlyn
FWIW, I think we should add 3.5 support to 1.8.

On 23 October 2015 at 17:08, Tim Graham  wrote:

> Officially Django 1.8 doesn't support Python 3.5. In practice, I think it
> probably works. See details in https://code.djangoproject.com/ticket/25502
> about why the 1.8 test suite doesn't pass with Python 3.5. We could
> probably change that if there is sufficient interest, however, I'm not
> aware of a precedent of adding Python version support in a major release
> retroactively.
>
> On Friday, October 23, 2015 at 10:48:54 AM UTC-4, Tim Allen wrote:
>>
>> Since Django 1.9 will support Python 3.5, I was wondering if there are
>> any plans to support Python 3.5 in Django 1.8, since it is an LTR.
>>
>> I did a cursory search and didn't find anything stating yay or nay. I'm
>> going to assume 1.8 only support 3.4 for now, as I've had issues with
>> Python 3.5 (if, on the other hand, there will be support, I'll report this
>> bugs in detail).
>>
>> Can someone give me an answer or point me to a relevant discussion I may
>> have missed? Thank you.
>>
>> Regards,
>>
>> Tim
>>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/eb6e94aa-eedf-4fff-9d3b-f7ba424c0a71%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GkMrKnJn9J0HHTqcauMF4gSMH-Bwd-n2beSrCCr9rixg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django 1.9: default='' no longer permitted on model field (with blank=False)

2015-10-23 Thread Marc Tamlyn
I disagree with this system check and I would like to see it reverted
before 1.9 final.

I admit that my opinions here are skewed by the fact that I think model
level validation is fundamentally not well implemented by Django at all. I
work to a philosophy that there are two places where validation happens -
once at the entry point to the system (form or serialiser) and once at the
database level to ensure integrity of the data.

I view model level validators, custom clean methods, and the editable and
blank flags as merely hints to automatic ModelForm creation and other
similar objects. I can't think of a single time I have explicitly called
model.clean(). Now, I can see the merits of a good model level validation
system, Django's model level validation is trivial to bypass and I consider
relying on it to be bad practice.

This check implies that you must use model level validation. I don't agree
it should be that unavoidable a feature. The docs for `blank` in fact only
reference form validation
https://docs.djangoproject.com/en/1.8/ref/models/fields/#blank.

The system check framework is supposed to be there to stop easy mistakes.
However:
- The original error reported by the OP of the ticket was in fact not able
to accidentally deploy the code in question because it did not run.
- It is common practice to not be use or at least be perfect about your
model level validation. I certainly have created many fields which are
system level but do not have `editable=False` on them because I explicitly
make sure all of my forms do not include this field. They are likely hidden
away in the admin as well because they are only used by some internal code.
Best practices such as the requirement for model forms to have fields
specified make sure that I am being explicit.
- If we are going to make it required that your model level validation is
correct, then we need to do so in a much more complete way than just
checking default values. In particular, code such as Manager.create()
should check validation rules. This would be a hugely breaking change for
Django.

I can of course easily bypass this change, add it to ignored checks or
similar. However as a beginner developer I would see this check, think
model level validation is important and reliable.

Marc

On 23 October 2015 at 21:51, James Addison  wrote:

> I have a model like so:
>
> class Provider(models.Model):
> description = models.TextField(default='')
>
>
> In recent Django 1.9 changes (this did not occur with 1.8.x), this causes
> the following traceback:
>
> Performing system checks...
>
>
> Traceback (most recent call last):
>   File
> "/home/vagrant/.virtualenvs/myproject/lib/python3.4/site-packages/gevent/greenlet.py"
> , line 523, in run
> result = self._run(*self.args, **self.kwargs)
>   File
> "/home/vagrant/.virtualenvs/myproject/src/django/django/utils/autoreload.py"
> , line 226, in wrapper
> fn(*args, **kwargs)
>   File
> "/home/vagrant/.virtualenvs/myproject/src/django/django/core/management/commands/runserver.py"
> , line 116, in inner_run
> self.check(display_num_errors=True)
>   File
> "/home/vagrant/.virtualenvs/myproject/src/django/django/core/management/base.py"
> , line 472, in check
> raise SystemCheckError(msg)
> django.core.management.base.SystemCheckError: SystemCheckError: System
> check identified some issues:
>
>
> ERRORS:
> businesses.Provider.description: (fields.E008) Invalid 'default' value:
> This field cannot be blank.
> images.ImageSet.hash: (fields.E008) Invalid 'default' value: This field
> cannot be blank.
> users.User.gender: (fields.E008) Invalid 'default' value: This field
> cannot be blank.
>
>
> System check identified 3 issues (0 silenced).
>
> Why is it that this was perfectly allowable before but not now? I have a
> data processing script that's pulling in data from an external source and
> creating instances with blank 'descriptions', it now doesn't work.  I have
> to set `blank=True` on fields having this error, which I don't want to do
> (for form validation reasons).
>
> I believe the following links are pertinent:
>
> https://code.djangoproject.com/ticket/25417
> https://github.com/django/django/pull/5303
>
> James
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c6ffdd4b-6147-43ff-be73-daef2e8149fe%40googlegroups.com
> 
> .
> For more options, visit 

Re: Why passing request, *args, **kwargs in dispatch method for generic views

2015-10-23 Thread Marc Tamlyn
This would cause too much churn for user code - there are millions of CBVs
in the wild with customised dispatch/get/post/etc methods which expect
these variables and perhaps use them directly. Unfortunately this ship has
sailed.

On 23 October 2015 at 14:45, Tom Christie  wrote:

> Although those variables are available in both places I'd prefer to see
> them passed explicitly.
> That will tend to nudge users slightly more towards passing variable
> around explicitly and slightly away from storing state on the view instance
> (which can be a bit of a gnarly practice - harder to follow the flow of
> where and when some piece of information is actually being used/modified)
>
> On Friday, 23 October 2015 14:03:17 UTC+1, Tim Graham wrote:
>>
>> It looks like setting the request/args/kwargs attributes came after the
>> original CBGV implementation.
>>
>> https://github.com/django/django/commit/ea6b95db
>> https://code.djangoproject.com/ticket/19316
>> https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion
>>
>> I haven't looked closely to see if your proposal might cause problems
>> (you could give it a try and see if you can get the Django test suite
>> passing), however, changing the signature of those methods would require a
>> deprecation path and could result in a lot of churn in user code which
>> would probably cause some angst. I'll leave it to users of CGGVs to offer
>> an opinion on whether or not it could be worthwhile.
>>
>> On Friday, October 23, 2015 at 5:51:37 AM UTC-4, Dheerendra Rathor wrote:
>>>
>>> Hello all,
>>>
>>> With reference to this line:
>>> https://github.com/django/django/blob/master/django/views/generic/base.py#L61
>>> from django.view.generic.base
>>> before calling self.dispatch request, args and kwargs attributes have
>>> been added to self. So these all are available in self in http_method
>>> handlers.
>>>
>>> I think this behaviour is present due to old functional views, but now
>>> passing these as arguments to http_method handlers look obsolete.
>>>
>>> We can potentially remove these and make http handlers more simple just
>>> like
>>> class CustomView(View):
>>> def get(self):
>>> request =self.request
>>> # code ...
>>>
>>>
>>>
>>> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/6fe6b37d-8ab6-4c66-b036-db480547c4fd%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HN_Pf1uRGYr69JUW1Lf5fyP2H6mSvjnrmG7VGHCCySUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: makemigrations --exit; exit status feels backwards from conventions

2015-10-20 Thread Marc Tamlyn
I see what you mean and the inherent problems with the design. However
fundamentally the command you are running is "make some migrations", and
the "I don't have any to make" step is clearly an error case, not a success
case. In particular it would be very wrong for the real "I want to make
some migrations" command to return a non-zero code when it does
successfully create some.

The only real solution I can see is a separate command, or something like
makemigrations --check.

On 20 October 2015 at 05:20, Jon Dufresne  wrote:

> Before posting this, I've read through the full thread "sys.exit(1)
> from makemigrations if no changes found" at
> <
> https://groups.google.com/d/topic/django-developers/I3M6B-wYYd8/discussion
> >.
>
> I fully agree with the spirit of the change. I already find the
> feature useful in CI. However, after using this feature on a CI
> server, I find the exit status backwards compared to typical commands.
> The makemigrations command returns status 0 to indicate CI failure
> (migrations missing) and 1 to indicate CI pass (continue to the next
> CI stage).
>
> Typically status 0 indicates pass and non-zero indicates failure. By
> following the typical exit status conventions, commands can explicitly
> return a non-zero status when detecting a failure or the Python
> runtime may return a non-zero status if something goes terribly wrong;
> such as an unhandled exception.
>
> Someone that is accustomed to typical exit status conventions might
> naively use the makemigrations command:
>
> ./manage.py makemigrations --dry-run --exit
>
> The expectation: the next stage should continue if there are no new
> migrations (the developer did everything they were supposed to do and
> included migrations). However, the above command will return status 1,
> not 0, if there are no new migrations.
>
> OK, we can test for that. Maybe change the command to:
>
> ! ./manage.py makemigrations --dry-run --exit
>
> That is, interpret the exit status opposite of what one would
> typically expect. Immediately, this looks backwards compared to
> typical shell scripting. But what happened to the "terribly wrong"
> scenario? For example, what if a developer mistakenly added an
> incorrect setting that caused an ImproperlyConfigured error? If this
> were to happen, I would want the above command to fail and stop the CI
> pipeline.
>
> So maybe the next step would be to check explicitly for exit code 1.
>
> ./manage.py makemigrations --dry-run --exit; test $? -eq 1
>
> Now it looks like we're hacking around something.
>
> Additionally, Python exits with status 1 for unhandled exceptions. So
> the above command would still pass the CI stage for an unhandled
> exception. Further Django's BaseCommand.run_from_argv() also exits
> with status code 1 on CommandError, so again, it would pass the CI
> stage for anything that triggers this sort of error.
>
> It seems exit status 1 is overloaded to mean "all migrations are
> accounted for, continue to the next stage of CI", and "something went
> terribly wrong".
>
> This is why I feel the exit status is backwards from what is typically
> expected.
>
> I would like to suggest we find a better way to interface with CI
> servers. That is return 0 when there are no migrations (continue to
> the next stage) and non-zero for both "migrations missing" and
> "something went terribly wrong".
>
> I suggest maybe adding a system check for missing migrations. The
> check could report an error, when they are missing.  The check
> framework seems like a natural command to be used by CI servers
> anyway, so this seems like a good place. The missing migration
> detection already exists, so the same code could be leveraged for this
> check.
>
> I'm also open to other suggestions on creating a more convention exit
> status.
>
> If there is agreement and the proposal sounds good, I can follow
> through with a ticket and code changes.
>
> Cheers,
> Jon
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADhq2b5YDr-HB5sUdwKK-K2awQZk7qUhJJdaU%2B4SH_6nx9x%3D5w%40mail.gmail.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 

Re: Fellow Report - October 17, 2015

2015-10-20 Thread Marc Tamlyn
This is awesome news for Django's status in enterprise, great work everyone.

I hope something comes from the Microsoft Fellow concept, that would be
brilliant.

On 20 October 2015 at 15:18, Michael Manfre  wrote:

>
> On Tue, Oct 20, 2015 at 3:02 AM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> 2015-10-20 5:04 GMT+02:00 Michael Manfre :
>>
>>> My long term plan is to switch out ADO for replaceable ODBC and FreeTDS.
>>> This may follow the current pattern Aymeric started when he created
>>> django-pymssql, or have them both in django-mssql.
>>
>>
>> For the record, django-sqlserver did that as well. In django-pymssql, I
>> chose to wrap django-mssql instead of forking it to avoid the having to
>> maintain a fork until a better solution is available.
>>
>
> Thanks for the reminder. I forgot about django-sqlserver. I'll also
> evaluate that backend.
>
> Regards,
> Michael
>
> --
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAGdCwBu6rHaLXec2ZN-LHhCxb0w3HLqZHB1hWNNxYGsHGyQBZQ%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GH%2BQ50De2LoUzCptch6rnhuQf2uEFQfE7xV2%2BcpZdMUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django ORM query syntax enhancement

2015-09-30 Thread Marc Tamlyn
I don't think complex cases need to have __ equivalents, but I also dispute
that long chains like that are necessarily a bad API, I don't find your
option 1 particularly neat compared to option 2. Worth noting though that
you've used a 2-valued function there which is not a lookup in the same
sense.

I think data__owner__other_pets__0__name is as nice to read as
JSONExtract('data', path=['owner', 'other_pets', 0, 'name']) personally.

Marc
On 30 Sep 2015 5:13 pm, "Alexey Zankevich"  wrote:

> I'll try to turn lookups into expression (will use master branch).
> I also have a question. Meanwhile the old query syntax with underscores is
> pretty good for simple queries (like Model.objects.filter(name='Bob'), it
> gets really ugly for parametrized calls, a new JSONField is a good example
> of that:
>
> >>> Dog.objects.filter(data__owner__other_pets__0__name='Fishy')
> []
>
> It will get even more messy if we want to pass a string as a second param
> of the func.
>
> ex.:
>
> 1. filter(Decode(F('name'), 'utf-8'), Value(u'Бармаглот'))   # <- neat
> 2. filter(name__decode__utf8=u'Бармаглот')  # <- ?? ambiguous and not nice
> at all
>
> So question - is it implied all the funcs, transforms and lookups to have
> underscore-based equivalent? It can affect the final implementation pretty
> much. In my opinion underscore-based equivalent should not be really
> required for funcs (the problem doesn't seem to affect transforms as they
> will not accept multiple params according to another thread).
>
> Thanks,
> Alexey
>
>
> On Wednesday, September 30, 2015 at 9:19:51 AM UTC+3, Anssi Kääriäinen
> wrote:
>>
>> I don't think we need split-to-subq support for Lookups before we make
>> them expressions. Lookups as expressions are usable outside .filter(),
>> and we need the split-to-subq support only in .filter(expression).
>>
>>  - Anssi
>>
>> On Wed, Sep 30, 2015 at 8:46 AM, Josh Smeaton 
>> wrote:
>> > I'm mixing my versions, sorry to those following along. 1.9 has just
>> reached
>> > alpha. Lookups as Expressions should be doable for 1.10 which master is
>> > currently tracking.
>> >
>> > Cheers
>> >
>> >
>> > On Wednesday, 30 September 2015 15:31:24 UTC+10, Josh Smeaton wrote:
>> >>
>> >> The alpha for 1.10 has already been cut, and I'm not sure that the
>> kinds
>> >> of changes needed here are appropriate to add now that the alpha is
>> out. One
>> >> could *maybe* make the argument that changing Lookup to an Expression
>> now
>> >> rather than later is the right move considering Transforms just
>> underwent
>> >> the same change for 1.10. Personally though, I don't think I have the
>> time
>> >> right now to do this change. I would support you if you were able, but
>> we'd
>> >> still be at the mercy of the technical board (I assume) for getting
>> this
>> >> change in for 1.10.
>> >>
>> >> Do you think Lookup as Expressions requires the subquery/exclude fix
>> you
>> >> mention above? I would think not -- not until we were ready to
>> document and
>> >> support .filter(Lookup(F(), Value()). If it wasn't a requirement, it'd
>> make
>> >> the Lookup->Expression work much easier. It wouldn't even need to be
>> >> documented (other than the release notes), as it'd just be an
>> implementation
>> >> change.
>> >>
>> >> Cheers,
>> >>
>> >> On Wednesday, 30 September 2015 14:33:14 UTC+10, Anssi Kääriäinen
>> wrote:
>> >>>
>> >>> On the core ORM side we need to make
>> >>> .exclude(LessThan(F('friends__age'), 30)) do a subquery.  This way
>> >>> .exclude(friends__age__lt=30) does the same thing as the expression
>> >>> version. This isn't that easy to do. If we just use
>> >>> resolve_expression, then the friends relation will generate a join,
>> >>> and then as second step do a negated filter on the joined value.
>> >>> Instead we want to detect that the LessThan expression needs to be
>> >>> pushed in to a subquery.
>> >>>
>> >>> So, we need to solve:
>> >>>
>> >>>  A) A way to ask an expression if it is referencing a multijoin
>> >>> (possible approach is to just have a method
>> >>> "refs_multi_valued_relation(query)")
>> >>>  B) When the ORM sees an expression that is reffing a multijoin in an
>> >>> exclude filter, then we need to push the expression in to a subquery.
>> >>>
>> >>> A) requires some new work. This shouldn't be that hard to implement,
>> >>> we just recursively ask subexpressions if they reference a multijoin.
>> >>>
>> >>> Something like https://github.com/django/django/pull/4385 will make
>> B)
>> >>> much easier to implement.
>> >>>
>> >>> I've been working on making Q-objects responsible for resolving
>> >>> themselves. See https://github.com/django/django/pull/4801. This
>> >>> should solve 3).
>> >>>
>> >>> We don't seem to be missing any major parts. I (or some volunteer)
>> >>> just need to finish the PRs, and then we should be really close to
>> >>> full support for expressions in filter.
>> >>>
>> >>> Josh: do you think we could get Lookup as 

Re: moving the class-based View base class out of django.views.generic?

2015-09-22 Thread Marc Tamlyn
The idea has been discussed before and was rejected as needless code churn
if I remember correctly. I'm afraid I can't remember when or where this
discussion happened, it could have been an in person one at a sprint, I
can't immediately find a record on this mailing list. Perhaps the fact it's
come up again makes it more significant (and we can always keep the import
shim).

FWIW, I am +0, I can see the reasoning but in my opinion we have worse
import paths (conf.urls and core.urlresolvers anyone?)



On 22 September 2015 at 15:58, Tom Christie  wrote:

> Yup, I think that's a good proposal.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/61cbcc8c-08d9-42af-83d5-4a8ee3d79dac%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1ERvJxM1Zj%3DpOJRTX4zY3dqWg_PBYQ-5vQCPCuP-9i8iw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.9 release blockers

2015-09-18 Thread Marc Tamlyn
Sorry everyone :(

On 18 September 2015 at 15:01, Tim Graham <timogra...@gmail.com> wrote:

> The major features are officially deferred. Let's try for the feature
> freeze by end of day on Monday and the alpha release on Tuesday.
>
> There aren't any critical blockers at this time. Jani hasn't completed the
> Oracle GIS work, but this isn't a must-have for alpha.
>
>
> On Saturday, September 12, 2015 at 7:50:31 PM UTC-4, Tim Graham wrote:
>>
>> With 1 week to go until alpha:
>>
>> I haven't heard anything from Marc or Preston on the major features from
>> the last mail.
>>
>> Jani continues to give updates in #django-dev about his progress on
>> getting the Oracle GIS backend working. Things seem to be on track for
>> finishing up by alpha.
>>
>> On Friday, September 4, 2015 at 3:55:22 PM UTC-4, Tim Graham wrote:
>>>
>>> Status with 2 weeks and a weekend to go until alpha (Monday, September
>>> 21).
>>>
>>> Planned major features for 1.9:
>>>
>>> PostgreSQL Full Text Search (Marc Tamlyn)
>>>
>>> I haven't seen any recent activity on the pull request, nor have I heard
>>> anything from Marc about it.
>>> https://github.com/django/django/pull/4726
>>>
>>> Custom indexes (Marc Tamlyn)
>>>
>>> I haven't see any work on revising the DEP, so this seem out for 1.9.
>>>
>>> https://github.com/django/deps/pull/6
>>>
>>> Template-based widget rendering (Preston Timmons)
>>> I think the code is in fairly good shape. It seems the main work left to
>>> is to write documentation.
>>> https://github.com/django/django/pull/4848
>>>
>>> Release blockers:
>>>
>>> - Add Oracle support for new-style GIS functions
>>> https://code.djangoproject.com/ticket/24688
>>> Owner: Jani Tiainen
>>> Status: In progress (from recent IRC discussion, it sounds like Jani is
>>> making good progress)
>>>
>>> On Monday, August 24, 2015 at 3:40:22 PM UTC-4, Tim Graham wrote:
>>>>
>>>> Time to kickoff the progress tracker for the next major release!
>>>>
>>>> Here's the status with 4 weeks to go until alpha (September 21).
>>>>
>>>> Release blockers:
>>>>
>>>> - Add Oracle support for new-style GIS functions
>>>> https://code.djangoproject.com/ticket/24688
>>>> Owner: Jani Tiainen
>>>> Status: In progress (test suite runs on Oracle now, which is an
>>>> improvement from last week)
>>>>
>>>>
>>>> Other tickets tagged for 1.9:
>>>>
>>>> - No way to create tables for apps without migrations
>>>> https://code.djangoproject.com/ticket/25144
>>>> Status: Awaiting replies to "Keeping apps without migrations?" thread
>>>> for a decision on what to do
>>>> Mailing list thread:
>>>> https://groups.google.com/d/topic/django-developers/qHP4ZQSK9xM/discussion
>>>> Owner: pending discussion
>>>>
>>>> - Replace admin icons images by inline SVG
>>>> https://code.djangoproject.com/ticket/20597
>>>> Owner: elky
>>>> Status: In progress
>>>>
>>>> - Update tutorial screenshots for new admin theme
>>>> https://code.djangoproject.com/ticket/25200
>>>> Status: to be done after previous item is completed
>>>>
>>>>
>>>> Relevant ticket filters:
>>>>
>>>> Release blockers affecting master:
>>>>
>>>> https://code.djangoproject.com/query?status=assigned=new=master=Release+blocker
>>>>
>>>> Tickets tagged 1.9:
>>>>
>>>> https://code.djangoproject.com/query?status=assigned=new=~1.9
>>>>
>>> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/261819cf-fb09-4e6b-b162-d2cdc76f3807%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/261819cf-fb09-4e6b-b162-d2cdc76f3807%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1ERfizgh%3DaC4Y7D5gYNwEZ4sGR_umbXpOjs6One5xN-xg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Adding a URL tagging feature

2015-09-18 Thread Marc Tamlyn
Some quick thoughts:

- I'm unconvinced that selecting urls by a given type is a common use case
- can you expand on that?
- Implementing the detection and usage of tags as middleware seems not as
nice as in decorators to me, especially as the middleware tree can be...
unpredictable in its behaviour. I try to avoid writing middleware when
possible. Decorators I know just apply at the last point to the view. I'd
prefer a nicer way to interact with the tags than middleware, but maybe all
I want is nicer middleware.
- With includes, are tags appended to as you go down? Could there be a way
to remove "parent" tags? (for example the a whole area of the site could be
marked private, but have a "shareable" preview page inside it with an
obscure url which can be shared)

On 18 September 2015 at 03:01, Atul Bhouraskar 
wrote:

> I've received a few comments on Ticket #25409 and so I'm opening up the
> discussion here.
>
> The pull request is https://github.com/django/django/pull/5309
>
> Apologies for the long post, just wanted to be as clear I could!
>
> The objectives of the discussion are to determine:
> 1. Is this something that could be merged in before the other URL
> re-factoring work (
> https://groups.google.com/d/topic/django-developers/9AqFxIIW2Mk/discussion)
> I personally think that we can as the code changes are minimal.
> 2. Does this approach conflict with/complement/replace the 'decorators'
> approach proposed in the URL rework project. There is a comparison of the
> pros and cons of each approach below. Looking at the code on that branch it
> appears simple for me to be able to merge it in there.
>
> == Synopsis ==
>
> Often (usually in middleware) processing has to be applied to certain URLs
> only eg CORS.
>
> The usual way to specify this would be to create an additional set of
> regex patterns identifying these urls - eg.
>
> CORS_URLS_REGEX = r'^/api/2/.*$'
>
> JSONP_URLS = r'^/api/1/.*$'
>
> PRIVATE_URLS = r'/(private|api)/.*$'
>
> Each middleware then typically matches the incoming request URL to the
> regex and determines whether it is to be selected for processing by it.
>
> This approach has several limitations including:
> * It violates DRY as the regexes in the settings have to be synced with
> the actual URL patterns
> * Matching multiple patterns either requires the user to create complex
> regexes or the app/middleware writer has to essentially reinvent URL
> patterns - poorly.
>
> == The Proposal ==
>
> Add an optional *tags* keyword argument to django.conf.urls.url allowing
> a URL to be optionally tagged with one or more tags which can then be
> retrieved via HttpRequest.resolver_match.tags in the middleware / view (or
> any code with access to urlpatterns - not necessarily in the context of a
> request). Probably easiest to explain via examples:
>
>
> urlpatterns = [
> url(r'^$', views.home, name='home'),
> url(r'^private/$', include(private_patterns), tags=['private']),
> url(r'^api/1/', include(api_v1_patterns), tags=[
> 'api', 'private', 'jsonp',
> ]),
> url(r'^api/2/', include(api_v1_patterns), tags=[
> 'api', 'cors', 'private',
> ]),
> ]
>
> api_v1_patterns = [
> url(r'^list/books/$', views.list_books, name='list-books'),
> url(r'^list/articles/$', views.list_articles, name='list-articles',
> tags=['public]),
> ...
> ]
>
> api_v2_patterns = [
> url(r'^list/books/$', views.list_books, name='v2-list-books'),
> url(r'^list/articles/$', views.list_articles,
> name='v2-list-articles',),
> ...
> ]
>
> In the above patterns all URLs under /private/ are tagged 'private', all
> URLs under /api/1/ are tagged 'api', 'jsonp' and 'private'.
>
>
> Some examples to show how you can access and use tags
>
> Example Middleware:
>
> class PrivatePagesMiddleware(object):
> def process_view(self, request, view_func, view_args, view_kwargs):
> """
> For any url tagged with 'private', check if the user is
> authenticated. The presence of a
> 'public' tag overrides the 'private' tag and no check should be
> performed.
> Authentication depends on whether the URL is marked as 'cors' or
> not. 'cors' urls
> use HTTP header token authentication
> """
> tags = request.resolver_match.tags
> if 'private' in tags and not 'public' in tags:
> if 'cors' in tags:
> # CORS requests are authenticated via tokens in the headers
> # check auth tokens
> ...
> if not authenticated:
>   return HttpResponseForbidden()
> elif not request.user.is_authenticated():  # normal django
> auth
> return redirect('login')
>
> class CorsMiddleware(object):
> def process_view(self, request, view_func, view_args, view_kwargs):
> if 'cors' in request.resolver_match.tags:
> # continue CORS processing
>
> def 

Re: Password validation in Django revisited

2015-09-07 Thread Marc Tamlyn
I agree with Aymeric and Markus that createsuperuser should not validate
strength of passwords when DEBUG is on. Having to use a secure password for
development/test accounts is an unnecessary level of interference for users.

I agree its safer to prevent using admin/admin in production and this is a
good thing, but there's no reason to prevent this for development. In fact,
I'd argue enforcing it for development will encourage teams to have a
"standard" secure password for their sites, which is also used in
production. By allowing admin/admin in development, and enforcing something
better in production we are more helpfully enforcing best practice.

On 7 September 2015 at 16:44, Florian Apolloner 
wrote:

>
>
> On Monday, September 7, 2015 at 5:37:03 PM UTC+2, Unai Zalakain wrote:
>>
>> I would even dare to say I'm totally against activated-by-default
>> password validators.
>
>
> Security comes first, so the should stay on by default.
>
>
>> I think it should be a decision the developers take
>> consciously, as it again adds just more overhead (which Django surely
>> doesn't need).
>>
>
> I doubt the overhead there is big, got any numbers to back up that claim?
> Also if it adds too much overhead for you, feel free to disable them.
>
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e653f37d-dc81-430b-87c4-47477bd971d9%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1ECNTs-iGbtvzqsZGPigmDLKSAM-QB3MTd5yMj5PwnnOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django Admin New Look

2015-08-20 Thread Marc Tamlyn
I think this is a bit of a misnomer - if we include a jQuery without IE8
support we will start dropping IE8 from the CSS, our own custom javascript,
new jquery features, community plugins will drop it etc etc. For 1.9 itself
it may simply be a case of swapping in a different jQuery version, but it
won't stay that way for long.

On 20 August 2015 at 00:49, Josh Smeaton  wrote:

> >My own opinion is that if you really need IE8 support, it's not difficult
> to write a custom template and conditionally include the old jQuery version.
>
> Good point. It's easy enough for users to support IE8 themselves if they
> need to. Consider me a +1 then.
>
> On Thursday, 20 August 2015 00:34:01 UTC+10, Tim Graham wrote:
>>
>> To see what's required, I made a pull request for jQuery 2 here: 
>> https://github.com/django/django/pull/5155
>>
>> The selenium and JavaScript tests pass without any modifications to the
>> admin's JavaScript.
>>
>> My own opinion is that if you really need IE8 support, it's not difficult
>> to write a custom template and conditionally include the old jQuery
>> version. If we view the admin as an internal management tool for "staff
>> users", I think it's reasonable for organizations to know what browsers
>> their staff uses and be able to make these determinations.
>>
>> For me, moving to jQuery 2 is a bit like the Python 2/3 debate. As long
>> as we have to support Python 2/jQuery 1.x we are somewhat restricted in
>> reaping the benefits of Python 3/jQuery 2. I'm not sure there are any new
>> features in jQuery 2 at this time - the main benefit seems to be smaller
>> size. Of course, if we start using new features of jQuery 2 at some point,
>> we might break the solution proposed in the previous paragraph, but that
>> seems okay to me since the point is that we shouldn't spend much time
>> caring for unsupported browsers.
>>
>> If we don't want to use end-of-life dates for deciding a browser support
>> policy, then what alternative metric should we use?
>>
>> On Wednesday, August 19, 2015 at 5:59:21 AM UTC-4, sdcooke wrote:
>>>
>>> I meant jQuery 2 and 1.11 are API compatible - you're right though, the
>>> latest versions of jQuery might have deprecated things that are currently
>>> used in Django.
>>>
>>> On Wed, 19 Aug 2015 at 10:39 elky  wrote:
>>>

 On Wednesday, 19 August 2015 14:27:53 UTC+5, sdcooke wrote:
>
> and get the performance boost of jQuery 2 in modern browsers. As far
> as I'm aware they are still API compatible.
>

 We should carefully check jQuery change log. I remember they removed
 toggle method in one of the latest versions, so some apps may broke because
 of that.

 --
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/446e9038-0b45-4a67-8b14-8cb402722f4b%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/975c070b-8c0f-4af8-a207-84acf828547a%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HBBC2JQF%2BqcQ6Rmt912E8Zr6NdZ%3DXr68bn6O0mpcFTaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Pre-DEP: community support of unmaintained versions of Django

2015-08-19 Thread Marc Tamlyn
Very happy with 1.6.11.x

On 19 August 2015 at 16:31, Carl Meyer  wrote:

> On 08/19/2015 09:28 AM, Donald Stufft wrote:
> > On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote:
> >> In my ideal world, the version number would help convey unofficial-ness
> >> a bit more strongly, but after re-reading PEP 440 I don't think it
> >> leaves us with any good options. I considered post-releases (e.g.
> >> 1.6.11.post1), but "The use of post-releases to publish maintenance
> >> releases containing actual bug fixes is strongly discouraged." So given
> >> the lack of good options, I'm OK with 1.6.11.x. Anyone else on the core
> >> team have a problem with that?
> >
> >
> > 1.6.11.x should work fine, though I’m confused why not just issue
> 1.6.12+?
>
> Because that looks exactly like the version number an official Django
> release would use, and the idea is to be as clear as possible that these
> are not official Django releases. For some users (who don't read READMEs
> etc) the version number is one of the few things we can be pretty sure
> they'll see.
>
> Carl
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/55D4A159.5050605%40oddbird.net
> .
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FR5C3-yafJtAS8o_17OWU4MVHcvfhKqD6ZOiudfGLTPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django Admin New Look

2015-08-19 Thread Marc Tamlyn
FWIW, I can see the arguments here and I would definitely like to move to
jquery 2 and drop old browsers (aggressively). Actually having a solid
browser support policy, a redesign etc would be a great time to do this as
well.

I can see we are likely to get some backlash, but maybe less than I think.

So consider me a +0 with reservations, and I would like to suggest that the
final decision here is made by the technical board.

On 19 August 2015 at 15:34, Tim Graham  wrote:

> To see what's required, I made a pull request for jQuery 2 here: 
> https://github.com/django/django/pull/5155
>
> The selenium and JavaScript tests pass without any modifications to the
> admin's JavaScript.
>
> My own opinion is that if you really need IE8 support, it's not difficult
> to write a custom template and conditionally include the old jQuery
> version. If we view the admin as an internal management tool for "staff
> users", I think it's reasonable for organizations to know what browsers
> their staff uses and be able to make these determinations.
>
> For me, moving to jQuery 2 is a bit like the Python 2/3 debate. As long as
> we have to support Python 2/jQuery 1.x we are somewhat restricted in
> reaping the benefits of Python 3/jQuery 2. I'm not sure there are any new
> features in jQuery 2 at this time - the main benefit seems to be smaller
> size. Of course, if we start using new features of jQuery 2 at some point,
> we might break the solution proposed in the previous paragraph, but that
> seems okay to me since the point is that we shouldn't spend much time
> caring for unsupported browsers.
>
> If we don't want to use end-of-life dates for deciding a browser support
> policy, then what alternative metric should we use?
>
> On Wednesday, August 19, 2015 at 5:59:21 AM UTC-4, sdcooke wrote:
>>
>> I meant jQuery 2 and 1.11 are API compatible - you're right though, the
>> latest versions of jQuery might have deprecated things that are currently
>> used in Django.
>>
>> On Wed, 19 Aug 2015 at 10:39 elky  wrote:
>>
>>>
>>> On Wednesday, 19 August 2015 14:27:53 UTC+5, sdcooke wrote:

 and get the performance boost of jQuery 2 in modern browsers. As far
 as I'm aware they are still API compatible.

>>>
>>> We should carefully check jQuery change log. I remember they removed
>>> toggle method in one of the latest versions, so some apps may broke because
>>> of that.
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/446e9038-0b45-4a67-8b14-8cb402722f4b%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/614e5159-b51f-424b-8551-753466ce%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FYzz6bf4%3DGVqCOLVy_nnXxXJOJezrvD9mJ69NpKrvGZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: draft blog post for Oracle help

2015-08-19 Thread Marc Tamlyn
Hi Jani,

Thanks so much for sticking your hand up to help maintain Oracle! It is an
important part of our ecosystem.

Marc

On 19 August 2015 at 07:45, Josh Smeaton  wrote:

> I'll also stick my hand up to be involved with the Oracle backend, but not
> the Oracle GIS backend. I don't have a lot of time available at the moment,
> but I'll be able to support Jani and anyone else that's interested in
> maintaining the backend.
>
> Cheers
>
> On Wednesday, 19 August 2015 16:36:23 UTC+10, Jani Tiainen wrote:
>>
>> Hi all,
>>
>> I'm volunteering myself to maintain both Oracle and Oracle GIS backends.
>>
>> I've been developing applications based on Oracle for almost 20 years now
>> and I've been maintaining Oracle installations and databases.
>>
>> I've been developing with Django and it's GIS parts with almost 10 years
>> now. I've previously contributed few very trivial patches and I've regulary
>> keep answering questions on #django and hanging around in #django-dev with
>> nick "jtiai".
>>
>>
>> On Thu, 13 Aug 2015 09:12:17 -0700 (PDT)
>> Tim Graham  wrote:
>>
>> > I've drafted a blog post to advertise our need for Oracle expertise.
>> Please
>> > take a look and give feedback before it's published. Thanks!
>> >
>> > Django team seeks help maintaining Oracle and Oracle GIS backends
>> >
>> ---
>>
>> >
>> > Several members of the Django team that have previously provided Oracle
>> > expertise no longer work with Oracle in their day jobs, and therefore,
>> the
>> > team
>> > is seeking new contributors who have an ongoing interest in the
>> backend.
>> >
>> > Ideally, the team seeks to move the Oracle backend from "built-in"
>> status,
>> > to a pip
>> > installable backend that would be maintained under the "django" GitHub
>> > account.
>> > Your duties would include monitoring a build that runs with Django
>> master
>> > and the
>> > latest version of the Oracle backend and fixing any issues that arise.
>> To
>> > help with
>> > the continuous integration infrastructure, knowledge of maintaining
>> Oracle
>> > servers
>> > would also be a plus, but these duties could be split among several
>> people.
>> > Please
>> > introduce yourself on the `django-developers mailing list`_ if this is
>> > something you
>> > are interested in.
>> >
>> > Also, the Oracle GIS backend has been broken for several months and
>> > no one has answered `requests for help`_ on the django-developers and
>> > geodjango mailing lists. If no one helps out, this backend will be
>> dropped
>> > in
>> > Django 1.9. This is the least used backend according to the `Django
>> > Developers
>> > Community Survey`_, receiving 5 votes out of more than 3,000 responses.
>> >
>> > .. _django-developers mailing list:
>> > https://groups.google.com/forum/#!forum/django-developers
>> > .. _requests for help:
>> >
>> https://groups.google.com/d/topic/django-developers/2ritQ26PRLI/discussion
>> > .. _Django Developers Community Survey:
>> >
>> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewanalytics#start=publishanalytics
>> >
>> > --
>> > 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-develop...@googlegroups.com.
>> > To post to this group, send email to django-d...@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/django-developers.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/68c78921-001d-4171-bdd7-541f048734bc%40googlegroups.com.
>>
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> Jani Tiainen
>>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f0c8315b-7e0f-4b0b-9223-09f4d6589d76%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 

Re: Django ORM query syntax enhancement

2015-08-18 Thread Marc Tamlyn
I strongly agree with the third party approach.
On 18 Aug 2015 17:49, "Anssi Kääriäinen"  wrote:

> I'm still thinking we shouldn't integrate any new query syntax into
> 1.9. Instead lets make it easy to create 3rd party apps that offer
> different querying syntax, and then lets see which solution (if any)
> gets popular enough to be integrated into Django.
>
>  - Anssi
>
>
>
> On Tue, Aug 18, 2015 at 5:54 PM, Collin Anderson 
> wrote:
> > Just a quick thought: I could imagine some newbies could get confused by
> the
> > python-like syntax and try to do:
> >
> > Equal(P.user.get_full_name(), 'Bob Someone')
> >
> > I don't think it's not a huge deal, but worth noting.
> >
> > On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich wrote:
> >>
> >> Hi all,
> >>
> >> Thanks for detailed response. I thought over the described expressions/
> >> transforms patches and here are my thoughts about the best way to
> >> implement simplified lookups.
> >>
> >> Firstly, I want to describe which properties of the new syntax seem to
> be
> >> important:
> >>
> >> 1. Using Python operators to do basic lookups as it's a natural way in
> >> Python
> >> for that.
> >>
> >> 2. Syntax should be minimalistic for basic lookups, the use of that
> >> approach
> >> will be more noticeable on multiple filter conditions. In other words,
> >> next
> >> syntax is better:
> >>
> >> >>> GameSession.objects.filter(Q.user.profile.last_login.date() ==
> >> >>> datetime.now().date)
> >>
> >> than this one
> >>
> >> >>> GameSession.objects.filter(E(F.user.profile.last_login).date() ==
> >> >>> datetime.now().date)
> >>
> >> as it requires additional calls, which makes expressions less readable.
> >>
> >> 3. I definitely like the idea of having explicit classes for lookups and
> >> transforms and think it's worth to bundle dotted query syntax with the
> >> patch.
> >> Explicit classes will separate functionality and simplify functions
> >> signature
> >> checks.
> >>
> >> I suggest a mixed approach, with next properties.
> >>
> >> 1. We will have a separate class to define query paths (let's call it P,
> >> we
> >> can still use F as "field", but having F as multipurpose class may
> confuse
> >> users, as well as implementation may become more complicated). And it
> will
> >> be
> >> the only purpose of the class. Below I'll reference it as "P" no matter
> we
> >> call
> >> it in future.
> >>
> >> 2. Any transforms and lookups will take query string or P class, as well
> >> as
> >> existing methods "select_related", "prefetch_related" and "order_by".
> The
> >> simplest implementation will be overriding __str__ method of the path
> >> class
> >> to generate related strings.
> >>
> >> >>> path = P.user.last_login_date
> >> >>> GameSession.objects.all().order_by(path)[:10]
> >>
> >> >>> print(path)
> >> user__last_login_date
> >>
> >> 3. Implement transforms and lookups as classes or functions (not bound
> to
> >> P class):
> >>
> >> >>> GameSession.objects.filter(Unaccent(P.user.location.name) == "Cote
> >> >>> d'Ivoire")
> >>
> >> It will simplify cases with parametrized transforms (ex. mentioned
> >> collate('fi')).
> >> Also eliminate fields collision with util functions like "date", which
> may
> >> be a
> >> so-called field.
> >>
> >> 4. Below is a table describing accepted passed and returned parameters:
> >>
> >> +---+---+--+
> >> |  Class/Function   |Allowed Param Types| Comparison Operators |
> >> +---+---+--+
> >> | Transform | str, P, Transform, Lookup | Return lookup|
> >> | Lookup| str, P, Transform | Raise exception  |
> >> | P |   | Return lookup|
> >> | .order_by | str, P|  |
> >> | .select_related   | str, P|  |
> >> | .prefetch_related | str, P, Prefetch  |  |
> >> +---+---+--+
> >>
> >>
> >> Samples:
> >>
> >> >>> P.user.name == 'Bob'
> >> Equal('user__name', 'Bob')
> >>
> >> >>> Unaccent(P.user.name)
> >> Unaccent('user__name')
> >>
> >> >>> Collate(P.user.name, 'fi')
> >> Collate('user__name', 'fi')
> >>
> >> >>> Unaccent(P.user.name) == 'Bob'
> >> Equal(Unaccent('user__name'), 'Bob')
> >>
> >> >>> Equal(P.user.name, 'Bob') == 'Bob'
> >> Traceback (most recent call last):
> >>   File "", line 1, in 
> >> Exception: Lookups comparison is not allowed
> >>
> >> >>> Contains(P.user.name, 'Bo')  # lookup
> >> >>> Date(P.user.last_login_date, datetime.now().date)  # transform
> >>
> >>
> >> Questions to discuss and possible pitfalls:
> >>
> >> 1. Handling descended ordering in order_by
> >>
> >> >>> path = P.user.last_login_date
> >> >>> -path
> >> '-user__last_login_date'
> >>
> >> or even
> 

Re: Enhancement to the call_command function to allow the use of modules as arguments

2015-08-18 Thread Marc Tamlyn
This is a deliberate approach you would use - South used it for years to
customise syncdb.

call_command is intended as a python API for testing `$ django-admin foo`.
Two of your arguments are based around IDE usage, which I don't think is a
valid argument, and the third is about reducing string magic. I don't feel
there is any magic at all here, we are modelling a string based API so
naturally we use strings to do so.

On 17 August 2015 at 16:20, Mike Lissner 
wrote:

> I see. Could this concern be addressed by adding it to the checks
> framework, so that it throws a warning if there are ever two commands with
> the same name?
>
> On Mon, Aug 17, 2015 at 11:16 AM Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> 2015-08-17 16:54 GMT+02:00 Mike Lissner :
>>
>>>
>>> I’m -1 on removing the Python API that’s equivalent to `django-admin
 my_command`. It’s needed for testing management commands that override
 other management commands.

>>>
>>> Not sure what you mean here, but I suspect you're making a good point.
>>> Does seem pretty niche though. Can you explain?
>>>
>>
>> Here's the scenario.
>>
>> 1. You write a do_stuff management command in your project. You write a
>> test to ensure that call_command('do_stuff') does the right thing.
>> 2. A co-worker adds a third-party app which also implements a do_stuff
>> management command. Unfortunately, the order of INSTALLED_APPS means that
>> your command is overridden by the third-party app. Fortunately, your test
>> catches the problem.
>>
>> With the change you're proposing, the test wouldn't catch the problem
>> anymore.
>>
>> That's why Django needs an API to emulate `django-admin do_stuff`.
>>
>> --
>> Aymeric.
>>
>> --
>> 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/8aNf-lZXSVg/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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CANE-7mVHu8cCw8dUDcA4ECnNqCGD%2BS4LAPBFRnBUAo3%2Bm65PcA%40mail.gmail.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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMp9%3DEzBJSSyhc7F_recj4-8CUxghzXSG%3Drx9EBT6MtDm3AeaQ%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Fg%2BVTd5jbtL9X66kVBYuHWtR_bdRO-BJ9Vc%2BNsjjuSWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django Admin New Look

2015-08-18 Thread Marc Tamlyn
I don't know about schedule, but caniuse reports IE8 browser usage at 1.5%,
more than IE9 or IE10.

There's an argument we shouldn't be "enabling" people still using XP who
are stuck on IE8, and this is a decreasing problem, but I don't think we
can tie ourselves to Microsoft's support dates.

On 18 August 2015 at 12:13, Tim Graham  wrote:

> I also had the idea of upgrading jQuery to jQuery 2 which drops support
> for IE6/7/8, but I guess this will break all the JavaScript in the admin
> under those browsers. Do you think that's unacceptable at this time? If so,
> could you propose an alternate timetable for the upgrade?
>
> On Tuesday, August 18, 2015 at 3:32:18 AM UTC-4, Aymeric Augustin wrote:
>>
>> On 18 août 2015, at 01:28, Tim Graham  wrote:
>>
>> > Unless someone can present an argument for keeping IE8 support, I
>> wouldn't worry about it considering it will be end of life about 1 month
>> after the release of Django 1.9.
>>
>> Let’s just make sure the admin stays usable, even if it looks bad. Since
>> we’re taking the SVG route, providing an alt text on icons should do.
>>
>> We could be explicit about the lack of support for IE8 and lower by
>> adding a conditional message in the template:
>>
>> 
>>
>> --
>> Aymeric.
>>
>>
>>
>>
>> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e541a69a-2ded-4af1-b049-f144878c0f83%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GEUXR6r5RJkJoNtDyAZFP1nVyC%2BWotdSVNPZUVFsazEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django Admin New Look

2015-08-17 Thread Marc Tamlyn
+1 to the svg option.

On 16 August 2015 at 20:00, elky  wrote:

> Hi guys,
>
> I made double work for vector icons - now we have Font and SVG icons.
> Let's choose what to use.
>
> *Quoting my comment
>  from SVG
> discussion here:*
>
> Well, only week ago I was 100% happy with font icons. But after Collin's
> comment I vote for SVG ( with svg as a source).
> Below I listed advantages/disadvantages for both options.
>
>
>
> *Font*
>
>
>- Customizing. Changing icon color with CSS
>   - Additional 100KB (font file + css)
>   - Lots of changes in CSS, HTML and JS
>   - To support IE8: just add *.ttf file (+ 70KB)
>   - Code Diff:
>   
> ​https://github.com/django/django/compare/master...elky:font-icons?diff=unified=font-icons
>
>
> *SVG*
>
>
>- Much less changes
>   - Code is elegant - I actually *just replaced* gifs with svg in
>   CSS. No pseudo-elements. No alignment tweaks
>   - 25 additional files (requests) but just 19KB in total
>   - To support IE8: add fallback in CSS (since we already have gif
>   icons in the repo, my suggestion is to show them in IE8)
>   - Code Diff:
>   
> ​https://github.com/django/django/compare/master...elky:svg-icons?diff=unified=svg-icons
>
> And the final and main argument to choose SVG is that some apps use a bit
> overridden Django CSS classes so font approach may cause visual issues (I
> checked it with few CMS apps). So font approach is an extra headache for
> app developers.
>
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/55509397-cab0-4298-a708-f89c4326fd83%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Eg%2BkEyxLjHVLTkz0hvDNCXb0hZGRbTAyoCwkVMETMDOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Document/make public prefetch_related_objects

2015-08-14 Thread Marc Tamlyn
Nothing on `query` is public at the moment - I can see the merit in adding
a public API to do this kind of work though. Can you open a ticket?
https://code.djangoproject.com/newticket

On 14 August 2015 at 13:26, Adam Johnson  wrote:

> *prefetch_related* is great, but it would be nice to be able to reuse its
> capabilities with lists of model instances already retrieved by other code
> (or from cache, or newly constructed, etc.). It seems this is possible by
> using *django.db.models.query.prefetch_related_objects* which is the
> function implementing all the prefetch capability - I've just seen it used
> on my project fine. Could *prefetch_related_objects* be documented as a
> part of Django's public API, or are there arguments against it?
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c7634422-6d72-4f83-ada3-d2a0cce099e9%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EZtMFd7%3D4LTwS-cEbrnC0Peooqbx61NZcHxidX5OZQOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Generic forms (ModelForm) provide HTML for a form! Can generic views (DetailView) do same?

2015-08-13 Thread Marc Tamlyn
The problem with bootstrapping code like this is that it's great for a
super simple project, but you instantly want to customise it for any
project of any serious scope.

It seems to me a perfect candidate for a simple external project, although
you may wish to have a different API so it's more reusable and extensible.
In the event that a code part of this (a serialising component similar to a
ModelForm for example?) which was usable in different ways then this might
be a suitable candidate for inclusion. It's worth noting for example that
there are multiple libraries which take model forms and render them
completely differently - floppy forms and crispy forms being the best
known. The primary purpose of ModelForm is to be a form, the rendering is a
basic example to build from.

Django rest framework serialisers I believe have some way of rendering a
subset of model fields like this, that may be of some interest to you.

Marc

On 13 August 2015 at 05:00, Bernd Wechner  wrote:

> I asked this question on the user group and got no reply fast, so I just
> wrote a derived class to do it quickly:
>
> https://groups.google.com/d/msg/django-users/n87bFh8IYYc/MhkNmVBDAwAJ
>
> it's a hack and not what I'd call a patch, but one user liked it and asked
> that I seek it's inclusion in Django.
>
> The justification is on that user page already, but in summary is to drive
> for some presentation consistency between ModelForm and DetailView to
> enable simple consistent rendering of generic forms or views in the same
> manner.
>
> I'm new to Django, wouldn't say I'm a django developer (excepting I'm
> trying to build a simple website with it and learning it and doing a proof
> of concept at home ;-) so I'm certainly not up for contributing code per
> se, but think this serves as a demo for a simple patch that I think Django
> would benefit from.
>
> Regards,
>
> Bernd.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a0e2e4ad-160e-4472-96c5-370e58a0ed9d%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Go8bJZQyvpVJ9B_Np91tan-juurgtWAhXhcfEfZr04UA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Ticket #25236: Remove ifequal from the template language

2015-08-07 Thread Marc Tamlyn
I think Tim's suggestion of releasing the tag as a separate library which
can be included in builtins answers Karen's concerns about updating 3rd
party templates. I admit that is a case I had not considered.

Marc
On 7 Aug 2015 15:31, "Tim Graham"  wrote:

> I put together a pull request to see how much code we are talking about:
> https://github.com/django/django/pull/5114
>
> It's 275 lines of code (mostly tests). I don't mind the outcome of the
> decision either way, but as it's been 5 years since the release of 1.2 and
> the "smart if" tag, I'm not sure delaying this a few more years would make
> a huge difference (that is to say, how about we make a "remove now or
> never" decision). We did a similar "undocument but don't remove" thing with
> the @permalink decorator.
>
> On Friday, August 7, 2015 at 7:33:52 AM UTC-4, Tim Graham wrote:
>>
>> Django 1.9 has the option to add templates tags to the builtins using the
>> TEMPLATES setting, so it wouldn't be difficult to publish a third-party app
>> with the legacy tags and document how to use it in legacy projects that
>> have difficulty updating:
>>
>> OPTIONS={
>> 'builtins': ['ifequal.tags'],
>> }
>>
>> On Friday, August 7, 2015 at 3:06:42 AM UTC-4, Aymeric Augustin wrote:
>>>
>>> > On 7 août 2015, at 05:43, Curtis Maloney 
>>> wrote:
>>> >
>>> > I'd probably go with updating the documentation to say they're legacy
>>> > tags, you're better off using {% if %} now, and warn they may be
>>> > removed in a later release.
>>>
>>> This is my inclination as well. Then we can revisit the topic in a few
>>> years :-)
>>>
>>> --
>>> Aymeric.
>>>
>>>
>>>
>>>
>>> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ca285211-7ccd-4a12-ba95-8277dd86cfbd%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GTDHgcxzC5g5dT6Vt2OdoPpd9g2YGg3QH1Un_ZVjnWTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

2015-08-06 Thread Marc Tamlyn
I agree that this is an anitpattern. I'm not fond of
`get_updated_instance()` as a name, I'm not sure what the correct option is
here. Arguably we should split save() into two parts -
ModelForm.update_instance() and ModelForm.commit(). ModelForm.save() simply
calls these two functions, with the latter only if commit=True.

update_instance() could return the instance, but I'd prefer to suggest
manipulating form.instance in the view.

***

Really though, I'd like to see the Django (and Django girls) tutorials not
use this pattern at all - the pattern of moving this logic out of the form
and into the view is the true antipattern here. In the case of the example
in the Django girls tutorial, it's a canonical example of adding the user
to the saved instance. There are in fact two better ways to achieve this.

One is to pass in an instance in creation of the form -
`PostForm(instance=Post(user=request.user))`.

The other, and my preferred option, is that the PostForm takes `user` as a
kwarg, and does this automatically in its save method. This encapsulates
the logic of the form completely, and also means you can add extra
validation at the form level. For example, you could check whether the user
is an admin or not and allow admins to post longer messages than logged in
users, or include links.

On 6 August 2015 at 21:50, Javier Candeira  wrote:

> On Friday, 7 August 2015 01:57:46 UTC+10, Tim Graham wrote:
>>
>> Discouraging the use of super() seems like a bad idea that could limit
>> flexibility in the future.
>>
>
> Fair enough, but I'm not discouraging the use of super(). As I point out
> in the ticket, the recommended pattern already ignores super() in the
> commit=True path of the code, since it suggests this:
>
> class MyForm(ModelForm):
> def save(commit=True):
> model = super(MyForm, self).save(commit=False)
> # do stuff to model
> if commit:
> model.save()
> form.save_m2m()
>
> Instead of this:
>
> class MyForm(ModelForm):
> def save(commit=True):
> model = super(MyForm, self).save(commit=False)
> # do stuff to model
> if commit:
> super(MyForm, self).save()
>
> These two are equivalent, the second one would actually use super() for
> saving and committing. But Django prefers not to.
>
> So if there is a reason for rejecting my patch, "discouraging use of
> super()" should hardly be it.
>
> I could also include a documentation patch recommending the use of super()
> for the commit=True path of save(), but I think practicality beats purity,
> Django seems to agree, and this is the better code:
>
> class MyForm(ModelForm):
> def save(commit=True):
> model = self.get_updated_model()
> # do stuff to model
> if commit:
> model.save()
> form.save_m2m()
>
> > I think Django's documentation describes the behavior pretty well.
> Perhaps the Django Girls tutorial could be improved instead. I don't recall
> having trouble understanding how this worked when I learned Django and
> introducing a new way to duplicate functionality of a 10 year old pattern
> doesn't seem worth it to me.
>
> >
> https://docs.djangoproject.com/en/1.8/topics/forms/modelforms/#the-save-method
> 
>
> Django documentation is stellar. This means that the "save(save=False)"
> API antipattern is very well documented indeed. This doesn't make it less
> of an antipattern for beginners, however well we explain it or, indeed,
> however well us-who-already-understand-it already understand it. I had been
> programming for decades when I learnt Django. Many people following the
> tutorials haven't. In some cases, they haven't even been alive for one
> decade.
>
> I'd like to hear the opinion of people who teach newcomers to programming,
> but let me also point this out: in separating the commit=False and
> commit=True paths of ModelForm.save() into the two functions
> get_updated_instance() and save_instance(), this refactor also enhances the
> readability of the code to a prospective Django contributor diving into the
> source code for the first time.
>
> Thanks,
>
> Javier
>
>
>> On Thursday, August 6, 2015 at 7:34:54 AM UTC-4, Javier Candeira wrote:
>>>
>>> Hi, I'm the author of Ticket #25227 Add utility method
>>> `get_updated_model()` to `ModelForm` and its accompanying patch.
>>>
>>> Ticket: https://code.djangoproject.com/ticket/25227
>>>
>>> Patch: https://github.com/django/django/pull/5105
>>>
>>> Here's the writeup to save everyone a click:
>>>
>>> Add utility method get_updated_model() to ModelForm
>>>
>>> Additionally, add utility method get_updated_models() to FormSet
>>>
>>> Rationale:
>>>
>>> While doing the djangogirls tutorial, I noticed that
>>> ModelForm.save(commit=False) is given to newcomers as a reasonable way to
>>> acquire a form's populated model. This is an antipattern for several
>>> 

Re: Ticket #25236: Remove ifequal from the template language

2015-08-06 Thread Marc Tamlyn
ifequal is technical debt in Django. It's a legacy way of doing things
which we would not add now. Sure, we don't have to remove it, it isn't
blocking us from doing anything else and it isn't broken, and it doesn't
need much maintenance.

However, as with all technical debt, it has a cost. It's additional code,
tests, documentation to maintain, low as the burden is. There is now "more
than one way to do it" - when as a new developer who has learned {% if x ==
y %} I then stumbles across {% ifequal x y %}, which is better? Does it
matter? Is one more efficient? They don't know that one is legacy code from
days when {% if %} was more stupid.

We want to grow the Django community and make it easier to use Django. We
also want to make sure that "There should be one-- and preferably only one
--obvious way to do it". This is why we have done things like removing
patterns(), why we rewrote transactions, why django.migrations is not
South, and why removing features which could have been deprecated in 1.2 is
important. Changes always result in work for upgrading existing sites, but
this is a cost the community should bear to make progress.

The number of sites using ifequal is small (it's very old, and not
recommended in any tutorial for many years). The number of future sites
which should not be using it, and future users (and maintainers of old
projects) who shouldn't have to worry about two ways to do the same thing
is large. The upgrade path is easy - you can achieve it with sed.

Quoting the 1.2 release notes: "There’s really no reason to use {% ifequal
%} or {% ifnotequal %} anymore, unless you’re the nostalgic type."

On 6 August 2015 at 21:07, Karen Tracey  wrote:

> On Thu, Aug 6, 2015 at 12:15 PM, Daniel Greenfeld 
> wrote:
>
>> No modern project uses ifequal. No one recommends it. I argue it is
>> taking up valuable bytes in the project. Let's remove it.
>>
>
> I maintain (did not write) a project written last year that has ifequal
> and ifnotequal. Is it really necessary to make it harder to upgrade this
> project to a more recent Django?
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CACS9radErjkfJHC0wVvPJWK4HpzVQiAyj0s_2ykG57EAG1%2BqLA%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EG9%2BOAWiW9iAT%3DnCFKD4_jDeBLVX2cJNXP6CUL9_uafA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Ticket #25236: Remove ifequal from the template language

2015-08-06 Thread Marc Tamlyn
I commented on the ticket - it's been redundant since Django 1.2 when the
smart if was introduced. +1 to deprecating it.

On 6 August 2015 at 17:15, Daniel Greenfeld  wrote:

> No modern project uses ifequal. No one recommends it. I argue it is taking
> up valuable bytes in the project. Let's remove it.
>
> Reference https://code.djangoproject.com/ticket/25236
>
> In there you'll see Tim Graham mentions that older Django projects may
> push back on it, and suggests that a good medium ground would be to remove
> it from the documentation.
>
> Any comments?
>
> Regards,
>
> Daniel Roy Greenfeld
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/add63617-a253-4571-a705-bf5773ed18ec%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1ECUQF7v6Mx33oOh-6JjY_12B8aw6sJ1Svv4-CXEuLGdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: future of QuerySet.extra()?

2015-07-31 Thread Marc Tamlyn
Sounds good to me.

On 31 July 2015 at 21:00, Tim Graham <timogra...@gmail.com> wrote:

> I had in mind a documentation note like this:
>
> Use this method as a last resort
>
>
> This is an old API that we aim to deprecate at some point in the future.
> Use it only if you cannot express your query using other queryset methods.
> If you do need to use it, please file a ticket with your use case so that
> we can enhance the QuerySet API to allow removing extra(). We are no
> longer improving or fixing bugs for this method.
>
> On Friday, July 31, 2015 at 2:07:34 PM UTC-4, Collin Anderson wrote:
>>
>> I wonder if there's a way in the docs we can deprecate it as in "we don't
>> recommend you use it", but not actually schedule it for removal.
>>
>> On Friday, July 31, 2015 at 2:01:20 PM UTC-4, Marc Tamlyn wrote:
>>>
>>> I don't know about unmaintained, but I think there's a consensus that
>>> .extra() has a horrible API and we should do away with it eventually. That
>>> said I think there are still enough things that can't be done without it at
>>> present. A lot fewer now we have expressions, but still some.
>>>
>>> I'd be happy to put a moratorium on improving it, but we can't deprecate
>>> it yet.
>>>
>>> On 31 July 2015 at 18:58, Tim Graham <timog...@gmail.com> wrote:
>>>
>>>> In light of the new expressions API, the idea of deprecating
>>>> QuerySet.extra() has been informally discussed in IRC and elsewhere. I
>>>> wonder if there is consensus to mark extra() as "unmaintained" and to
>>>> suggest filing feature requests for functionality that can be performed
>>>> through extra() but not through other existing QuerySet methods? There are
>>>> at least several tickets (examples below) of edge cases that don't work
>>>> with extra(). It seems like a waste of time to leave these tickets as
>>>> accepted and to triage new issues with extra() if they won't be fixed.
>>>>
>>>> https://code.djangoproject.com/ticket/24142
>>>> https://code.djangoproject.com/ticket/19434
>>>> https://code.djangoproject.com/ticket/12890
>>>>
>>>> --
>>>> 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-develop...@googlegroups.com.
>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>> Visit this group at http://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/django-developers/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7c1568b6-f7f1-4aab-9263-af447e45af45%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/7c1568b6-f7f1-4aab-9263-af447e45af45%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FQAJqrXu3HcSpP3xDF%2BA%3DsyG%3DHP90V%3DzrKBHJ%3Dg%3DcfDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


  1   2   3   4   >