Re: Feature idea: forms signals

[David Seddon]

I totally agree that signals are open to misuse, and I take your points. 
 Inexperienced developers often seem to use them just because they're 
there, rather than to encapsulate their apps and avoid circular 
dependencies.  The Django signals documentation could probably do with a 
bit more guidance of when to use them.  On the other hand, I have seen a 
lot of great uses of models signals too.

There are other solutions, and I've actually given a talk about these here 
(https://skillsmatter.com/skillscasts/7129-encapsulated-django-keeping-your-apps-small-focused-and-free-of-circular-dependencies).
 
 The idea of OVERLOADED_CLASSES above is also a really interesting idea, 
but a lot more of a fundamental shift than just dispatching a few signals 
from the existing form classes.

What I would say in terms of form signals support is that in a former life 
I was a Drupal developer.  That framework has shortcomings but there are 
also things that work really well, and one of the best is a hook for 
altering forms (hook_form_alter) which works very well for Drupal's highly 
modular approach.  This hook is used everywhere in Drupal projects.  I 
think exposing this kind of hook would make it a lot easier for Django 
developers to architect their projects as small, pluggable apps - something 
that is pretty difficult to make work with forms.

David

On Monday, 6 March 2017 21:43:47 UTC, contact wrote:
>
> Hi ! 
> I'd prefer to that a standardized way of overloading classes, like with 
> a proper setting : 
> OVERLOADED_CLASSES = { 
>  'app.forms.MyForm': 'myapp.forms.MyForm' 
> } 
> Having (or not) myapp.forms.MyForm extend app.forms.MyForm. So whenever 
> a CBV declares its form is app.forms.MyForm, it would instead create an 
> instance of myapp.forms.MyForm. Same thing for the instanciation of the 
> views classes. 
> After thatn it gets a bit trickier for the manual instanciation you 
> could find in FormView.get_form() for example. But I'm not fully aware 
> of Python's possibilities regarding such a functionality. As the mocking 
> library allows to replace a class with another on the fly, I'm pretty 
> sure it can be done, but I have no idea at what expense that would be 
> and what the side effects could be. 
>
> Anyway, I fully agree that there's something to do about it, as the ways 
> to do it by now are not really obvious. 
>
> 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/56eb4ce1-b0d5-443c-bd6a-c230fc41c6b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

[Aymeric Augustin]

Hi David,

It's good to hear that you did significant research in this area (which I 
couldn't tell from your original email).

I get how this feature can come in handy and I won't stand in the way if it 
gets implemented.

Improving the guidance about when (not) to use signals in the process would be 
great.

-- 
Aymeric.



> On 7 Mar 2017, at 10:29, David Seddon  wrote:
> 
> I totally agree that signals are open to misuse, and I take your points.  
> Inexperienced developers often seem to use them just because they're there, 
> rather than to encapsulate their apps and avoid circular dependencies.  The 
> Django signals documentation could probably do with a bit more guidance of 
> when to use them.  On the other hand, I have seen a lot of great uses of 
> models signals too.
> 
> There are other solutions, and I've actually given a talk about these here 
> (https://skillsmatter.com/skillscasts/7129-encapsulated-django-keeping-your-apps-small-focused-and-free-of-circular-dependencies).
>   The idea of OVERLOADED_CLASSES above is also a really interesting idea, but 
> a lot more of a fundamental shift than just dispatching a few signals from 
> the existing form classes.
> 
> What I would say in terms of form signals support is that in a former life I 
> was a Drupal developer.  That framework has shortcomings but there are also 
> things that work really well, and one of the best is a hook for altering 
> forms (hook_form_alter) which works very well for Drupal's highly modular 
> approach.  This hook is used everywhere in Drupal projects.  I think exposing 
> this kind of hook would make it a lot easier for Django developers to 
> architect their projects as small, pluggable apps - something that is pretty 
> difficult to make work with forms.
> 
> David
> 
> On Monday, 6 March 2017 21:43:47 UTC, contact wrote:
> Hi ! 
> I'd prefer to that a standardized way of overloading classes, like with 
> a proper setting : 
> OVERLOADED_CLASSES = { 
>  'app.forms.MyForm': 'myapp.forms.MyForm' 
> } 
> Having (or not) myapp.forms.MyForm extend app.forms.MyForm. So whenever 
> a CBV declares its form is app.forms.MyForm, it would instead create an 
> instance of myapp.forms.MyForm. Same thing for the instanciation of the 
> views classes. 
> After thatn it gets a bit trickier for the manual instanciation you 
> could find in FormView.get_form() for example. But I'm not fully aware 
> of Python's possibilities regarding such a functionality. As the mocking 
> library allows to replace a class with another on the fly, I'm pretty 
> sure it can be done, but I have no idea at what expense that would be 
> and what the side effects could be. 
> 
> Anyway, I fully agree that there's something to do about it, as the ways 
> to do it by now are not really obvious. 
> 
> 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/56eb4ce1-b0d5-443c-bd6a-c230fc41c6b5%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/26353977-6013-49DE-9A33-550D53E065CE%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

[James Pic]

Seems similar to this discussion:
https://groups.google.com/forum/#!searchin/django-developers/forms%7Csort:relevance/django-developers/zG-JvS_opi4/wS-4PBfPBwAJ

Yes, signal/slot is a pattern that allows quick and easy decoupling of
components that have to work on the same payload, and I've been using
happily for at least a decade but I take your point as well.

About OVERLOADED_CLASSES, I don't think it's flexible enough, ie. to allow
an AppConfig to override a field of another app's form class, that was made
possible by David's initial proposal using signals.

If we're going to change this bit in Django, I'd like to recommend that we
try to cover a broader spectrum of use case, than just allowing a user not
to override a url to pass a different form.

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

Re: Database connection retry

[James Pic]

Thanks for sharing some of your insight Aymeric, if I'm not mistaken then
the auto-reload feature/case invalidates Shai's suggestion: would you
recommend that the runserver process exits with non-zero when a check fails
rather than being stuck waiting for another code change to trigger a
reload, so that we could wrap it in an until loop in bash ?

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

Re: Decoupling forms from models

[Tim Graham]

I don't think this is such a large feature that it requires a DEP but feel 
free to write more about the problem and possible solution on this thread 
to see if there's consensus about how to solve it.

On Saturday, December 24, 2016 at 10:11:25 AM UTC-5, is_null wrote:
>
> There is a history of problems related to the coupling between forms and 
> models. For example, when a user suggested to pass a field instance to the 
> model field to make it default [0], or when I suggested to improve 
> formfield [1]: it was rejected because it would increase the coupling 
> between forms and models:
>
> On Saturday, April 2, 2016 at 10:44:44 AM UTC+2, Florian Apolloner wrote:
> > On Thursday, March 17, 2016 at 2:17:40 PM UTC+1, Tim Graham wrote:
> > > It seems useful, but I'm not sure if it increases the coupling between 
> model and forms in an undesirable way?
> > Yeah, I am also mostly worried about this. formfield for me is a quick 
> shortcut, if you want to customize it, do it at the form level imo.
>
> So this leaves the one problem we actually want to see resolved: mandatory 
> coupling between forms and models. Which looks like the root cause, which 
> makes it different from the other threads which propose solutions to 
> problems created because of that, at least that's what I thought.
>
> Here is a solution Tim already proposed [2]:
>
> from django.db import models
> models.CharField.register_formfield(MyCustomFormField)
>
> As for the DEP, well I was going to just write one and submit it but then 
> I realized I could follow the advice in 1. Pre-Proposal of DEP0001:
>
>> The DEP Author (see below for the formal definition of an Author) should 
>> first attempt to ascertain whether the idea is DEP-able. Posting to 
>> django-developers is the best way to go about this.
>> Vetting an idea publicly before going as far as writing a DEP is meant to 
>> save the potential author time.
>
>
> But I don't mind not writing it, it'll be easier for everybody if a native 
> speaker and more experienced django contributor would take care of it, if 
> it were to be accepted.
>
> [1] https://code.djangoproject.com/ticket/22609
> [1] https://groups.google.com/forum/#!topic/django-developers/TblESVmxGfw
> [2] 
> https://groups.google.com/forum/#!topic/django-developers/zG-JvS_opi4/discussion
>

-- 
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/0f3cfbb9-09cd-4356-a08c-b2fc723f88b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database connection retry

[Tim Graham]

The behavior of runserver hanging on a check error seems fine to me. That 
gives you an opportunity to fix the error without having to manually 
restart the server afterward -- just the same as if you had a SyntaxError. 
Am I missing the reason why the behavior is problematic?

On Tuesday, March 7, 2017 at 6:32:45 AM UTC-5, James Pic wrote:
>
> Thanks for sharing some of your insight Aymeric, if I'm not mistaken then 
> the auto-reload feature/case invalidates Shai's suggestion: would you 
> recommend that the runserver process exits with non-zero when a check fails 
> rather than being stuck waiting for another code change to trigger a 
> reload, so that we could wrap it in an until loop in bash ?
>

-- 
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/52269166-9d24-478a-95d2-f820786aabbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Decoupling forms from models

[James Pic]

Sure, this probably involves allowing Form instance definition by
composition with a new object (ie. FormConfiguration,
ModelFormConfiguration ...) rather than by subclassing Form or ModelForm.

I'll make a complete writeup about it ala Diderot then haha

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

Re: Database connection retry

[James Pic]

It works on SyntaxErrors because updating the code triggers a reload, but
if the check fails for something that's not related to code (db conn, redis
conn...) then it's stuck and we have to manually interrupt runserver to
start it again, unless we touch some code just to trigger the reload as you
mention. My question is: is there anything we can do to automate this ?

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

Re: Database connection retry

[Aymeric Augustin]

Hello,

> On 7 Mar 2017, at 13:30, James Pic  wrote:
> 
> My question is: is there anything we can do to automate this ?

I'm not seeing an obvious solution to this problem.

Django has no way to tell it's a temporary issue.

-- 
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/7AFCDB65-08B4-48F6-944F-8F5C5BA1EB98%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Database connection retry

[James Pic]

It seems like we have 2 kind of issues:

- code broke runserver,
- network broke runserver.

In the first case, runserver waits for a code reload event which is perfect
;)
In the second case, runserver also waits for a code reload event, which is
not very intuitive after fixing a network error.

So if we want to handle both case, we indeed need to detect if an error is
caused by code or networking, which is defined by CACHES, DATABASES and
CHANNEL_LAYERS.

Perhaps we could add a special attribute to the exception, so
DatabaseWrapper.get_new_connection()'s call of:

connection = Database.connect(**conn_params)

Would become something like:

try:
connection = Database.connect(**conn_params)
except Exception as e:
e.network_error = True
raise

Another way would be to inspect exc info or have a pre-defined list of
exceptions that are to be considered as network error, which involves
referencing to exceptions potentially defined by other packages such as
redis.

While that may seem a lot for runserver, I've restrained myself from
talking about what this could look like in production so far in the
discussion, but I feel like even production deployment could somehow
benefit from this at some point, so that might be worth the effort after
all.

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

In-memory queryset

[paul]

Hi,

It would be really convenient for me if there was an implementation of the 
QuerySet API which instead of using a database as its data source, used 
in-memory model instance that had not been persisted to the database at all.

I looked around and found nothing like this.

Is this because nothing like this exists? Is it because it's a terrible 
idea for a reason that's not obvious to me? Would it not be awesome for the 
API for interacting with collections of in-memory instances and with a 
database-backed collection to be the same?

Many thanks,

Paul

-- 
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/d4f7c142-5d3f-4158-98bb-1e2171f0e63e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: In-memory queryset

[ludovic coues]

This look like a question for django user.

The QuerySet API is only an abstraction layer to SQL code. That's why
it require a database.
If you really don't want to store your object on a filesystem, sqlite
support database living only in memory. That's mainly for testing
purpose but that could fit your use-case. And django support multiple
database.

2017-03-07 15:13 GMT+01:00  :
> Hi,
>
> It would be really convenient for me if there was an implementation of the
> QuerySet API which instead of using a database as its data source, used
> in-memory model instance that had not been persisted to the database at all.
>
> I looked around and found nothing like this.
>
> Is this because nothing like this exists? Is it because it's a terrible idea
> for a reason that's not obvious to me? Would it not be awesome for the API
> for interacting with collections of in-memory instances and with a
> database-backed collection to be the same?
>
> Many thanks,
>
> Paul
>
> --
> 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/d4f7c142-5d3f-4158-98bb-1e2171f0e63e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

-- 
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/CAEuG%2BTZbj6hR%3DyBi56QSxatK1X1XmxuBfHTw39LEVwgWe_B%2BuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: In-memory queryset

[Jacob Kaplan-Moss]

Hey Paul -

There are a couple of implementations I'm aware of:

https://github.com/stphivos/django-mock-queries
https://github.com/dcramer/mock-django

Neither are a complete implementation of the QuerySet API, and I think this
is because the QuerySet API surface is _huge_. Implementing the entire API
would be a monumental task (especially if you start wanting to implement
some of the more complex operations, like annotate/aggregate). At a certain
point, it because easier to just use a real database -- most people use
SQLite at that point.

It's certainly _possible_ to implement a in-memory datastore, and it might
be pretty useful. It's just pretty dang hard to do more than the first 20%
or so.

Jacob

On Tue, Mar 7, 2017 at 6:13 AM,  wrote:

> Hi,
>
> It would be really convenient for me if there was an implementation of the
> QuerySet API which instead of using a database as its data source, used
> in-memory model instance that had not been persisted to the database at all.
>
> I looked around and found nothing like this.
>
> Is this because nothing like this exists? Is it because it's a terrible
> idea for a reason that's not obvious to me? Would it not be awesome for the
> API for interacting with collections of in-memory instances and with a
> database-backed collection to be the same?
>
> Many thanks,
>
> Paul
>
> --
> 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/d4f7c142-5d3f-4158-98bb-
> 1e2171f0e63e%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/CAK8PqJEW_OiKjHjusVOEgSSKjzHy5gXZXV9Hi8yB2E0RmZGsPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: In-memory queryset

[Tim Chase]

On 2017-03-07 07:17, Jacob Kaplan-Moss wrote:
> It's certainly _possible_ to implement a in-memory datastore, and
> it might be pretty useful. It's just pretty dang hard to do more
> than the first 20% or so.

Would there also be issues with WSGI spinning up/down various Django
processes?  Any in-memory (in-process) data would be lost when the
process goes down.  I could see it working for an individual dev
server or if you could guarantee that a single WSGI process remains
running indefinitely. But for those, I'd just go with sqlite's
":memory:" option.

-tkc



-- 
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/20170307101615.48bb1a00%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: Commitable json dumps

[Adam Johnson]

Ah yes, PyYAML just does this. It can be disabled by passing a different
option to yaml.dump (I think default_flow_style=False) but that would be
similar to changing the JSON serializer..

On 6 March 2017 at 16:53, Brice PARENT  wrote:

>
> Le 06/03/17 à 15:44, Brice PARENT a écrit :
>
>> Le 06/03/17 à 14:28, Adam Johnson a écrit :
>>
>>> PyYAML sorts keys by default, so if you use the YAML serializer that
>>> should work for your usecase.
>>>
>> I think it will become my new default !
>>
> It appears that the rendered format is not very consistent, or at least
> it's what I've found. Yaml seems to offer a short and a long syntax.
> I tried with 2 models, one from stock Django (flatpages), which seems to
> give something that corresponds to my needs, and one with a custom one,
> where the used syntax doesn't create a new line for each field. (I edited
> the outputs to focus on the idea and remove irrelevant contents).
> ./manage.py dumpdata --format yaml --indent 4 flatpages
> -   fields:
> content: 'First line.
> Second line'
> enable_comments: false
> registration_required: false
> sites: [1]
> template_name: ''
> title: Multiline
> url: /my/test/
> model: flatpages.flatpage
> pk: 13
>
> ./manage.py dumpdata --format yaml --indent 4 myapp
> -   fields: {content: "First line.\r\n\r\nSecond line\r\
> \n", module: 1, position: 1, summary: "First line.\r\
> \n\r\nSecond line\r\", title: "My title"}
> model: myapp.mymodel
> pk: 1
>
> So with the same command, I've gotten two formats, one that is
> git-friendly, and one that isn't. I haven't yet looked at the source code
> on why it chose to use one syntax over the other though.
>
> 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/ms
> gid/django-developers/7056c260-d57e-e465-b087-fc1e06762402%40brice.xyz.
>
> 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/CAMyDDM06zwCqBQPav-3c2xztWMHxck4CWaX7%3DuUByr6KWgToHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Commitable json dumps

[Adam Johnson]

Wait, I just looked into this further, and discovered that the ordering of
fields was made deterministic for all serializers in #24558
 - this was released in Django
1.9! Enjoy👌

On 7 March 2017 at 22:23, Adam Johnson  wrote:

> Ah yes, PyYAML just does this. It can be disabled by passing a different
> option to yaml.dump (I think default_flow_style=False) but that would be
> similar to changing the JSON serializer..
>
> On 6 March 2017 at 16:53, Brice PARENT  wrote:
>
>>
>> Le 06/03/17 à 15:44, Brice PARENT a écrit :
>>
>>> Le 06/03/17 à 14:28, Adam Johnson a écrit :
>>>
 PyYAML sorts keys by default, so if you use the YAML serializer that
 should work for your usecase.

>>> I think it will become my new default !
>>>
>> It appears that the rendered format is not very consistent, or at least
>> it's what I've found. Yaml seems to offer a short and a long syntax.
>> I tried with 2 models, one from stock Django (flatpages), which seems to
>> give something that corresponds to my needs, and one with a custom one,
>> where the used syntax doesn't create a new line for each field. (I edited
>> the outputs to focus on the idea and remove irrelevant contents).
>> ./manage.py dumpdata --format yaml --indent 4 flatpages
>> -   fields:
>> content: 'First line.
>> Second line'
>> enable_comments: false
>> registration_required: false
>> sites: [1]
>> template_name: ''
>> title: Multiline
>> url: /my/test/
>> model: flatpages.flatpage
>> pk: 13
>>
>> ./manage.py dumpdata --format yaml --indent 4 myapp
>> -   fields: {content: "First line.\r\n\r\nSecond line\r\
>> \n", module: 1, position: 1, summary: "First line.\r\
>> \n\r\nSecond line\r\", title: "My title"}
>> model: myapp.mymodel
>> pk: 1
>>
>> So with the same command, I've gotten two formats, one that is
>> git-friendly, and one that isn't. I haven't yet looked at the source code
>> on why it chose to use one syntax over the other though.
>>
>> 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/ms
>> gid/django-developers/7056c260-d57e-e465-b087-fc1e06762402%40brice.xyz.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>



-- 
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/CAMyDDM2onJFJGAFC5UGiJpmKth%3DnKeHVjYk%3Dv-GMYCrk-%3DqR_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

[Adam Johnson]

I'm +1 on adding some signals to forms, because I feel it's weird for
Django to have several signals for models, and none for forms. However I
don't really have an opinion on what the useful signal points are, because
I don't touch forms that often.

On 7 March 2017 at 11:13, James Pic  wrote:

> Seems similar to this discussion: https://groups.google.com/
> forum/#!searchin/django-developers/forms%7Csort:
> relevance/django-developers/zG-JvS_opi4/wS-4PBfPBwAJ
>
> Yes, signal/slot is a pattern that allows quick and easy decoupling of
> components that have to work on the same payload, and I've been using
> happily for at least a decade but I take your point as well.
>
> About OVERLOADED_CLASSES, I don't think it's flexible enough, ie. to allow
> an AppConfig to override a field of another app's form class, that was made
> possible by David's initial proposal using signals.
>
> If we're going to change this bit in Django, I'd like to recommend that we
> try to cover a broader spectrum of use case, than just allowing a user not
> to override a url to pass a different form.
>
> --
> 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/CAC6Op18ifztiCqCm1Vr39%
> 2BNGJJpCnu8a3gmYZ8sBMXyGtFZwSg%40mail.gmail.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/CAMyDDM3LsYg-NyuUiMrMz_RjKE0frqwBdi%2Bb%3DD3vr6Qe0M1-nQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.