Re: Consensus about visual diagrams in the docs.

[Jani Tiainen]

Personally I use plantuml to generate various diagrams. It is open source
there even exists plugin for sphinx. It uses relatively understandable
diagram language. Exports svg along the many other formats. And there are
realtime preview plugins to most editors and ides.

Only big downside is that requires java runtime.

Curtis Maloney  kirjoitti pe 30. marrask. 2018 klo
21.47:

> On 11/30/18 7:38 PM, guettli wrote:
> > I do not care for the strategy, I care for the goal.
> >
> > How to find clear consensus now?
>
> There is a time honored practice in open source of spurring more
> spirited discussion by presenting a solution, however sub-optimal it may
> be.
>
> It may not be the accepted solution, but it's far more likely to get
> people to give input than asking for discussion.
>
> [No, I'm not just wrapping up "patches welcome" - this is a general
> observation in life. It's just more openly recognised in OSS :) ]
>
> --
> Curtis
>
> --
> 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/88fbd91d-e4ee-89ac-5bae-1c54f7560698%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/CAHn91ofesmCYF8dF81KGqL4SRgrHyCRyiWO-2mB%3Dc6HW-Q%3Dysg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consensus about visual diagrams in the docs.

[Curtis Maloney]

On 11/30/18 7:38 PM, guettli wrote:

I do not care for the strategy, I care for the goal.

How to find clear consensus now?


There is a time honored practice in open source of spurring more 
spirited discussion by presenting a solution, however sub-optimal it may be.


It may not be the accepted solution, but it's far more likely to get 
people to give input than asking for discussion.


[No, I'm not just wrapping up "patches welcome" - this is a general 
observation in life. It's just more openly recognised in OSS :) ]


--
Curtis

--
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/88fbd91d-e4ee-89ac-5bae-1c54f7560698%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Consensus about visual diagrams in the docs.

[Aymeric Augustin]

Hello,

A few years ago, I redid most illustrations and included them in the docs as 
SVG files. The primary driver was switching from PNG to SVG to better 
accommodate hi-dpi displays. I also committed the source files. Unfortunately, 
they're in a proprietary format and cannot be reused without a Mac and an 
OmniGraffle licence.

(Before someone starts listing the arguments against proprietary formats — yes, 
I learnt them 15 years ago, and yes, I still chose OmniGraffle's UX over 
Inkscape's. : You're welcome to redo the diagrams with Inkscape and replace 
mine as long as the result doesn't look significantly worse.)

While not ideal, this got the job done. Diagrams look all right on all kind of 
devices.

To sum up:
- I think SVG should be the preferred format for illustrations in the docs
- I'm worried about ASCII art on small devices: line wrapping would be a problem
- whatever you want to make the diagram as long as it exports to SVG and looks 
reasonable
- commit the source file so someone has a chance to reuse them, regardless of 
their format

Best regards,

-- 
Aymeric.



> On 30 Nov 2018, at 09:38, guettli  wrote:
> 
> I once created a simple ascii diagram to explain details of the Django ORM:
> 
> https://code.djangoproject.com/ticket/27936
> 
> Years ago it took some time for me to understand it. And since then it
> came up by new comers in our team several times.
> 
> There is agreement on the goal: yes, a visual diagrams in the docs would be 
> nice.
> 
> But there is no agreement on the strategy.
> 
> I think ascii art is fine. Some suggest to use a graphiz plugin in for sphinx.
> 
> There is no progress because there is no clear consensus up to now.
> 
> I do not care for the strategy, I care for the goal.
> 
> How to find clear consensus now?
> 
> Regards,
>Thomas Güttler
> 
> -- 
> 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/2f6f3c4e-44cf-4b35-bb09-751828cc4921%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/D58AA4E7-AC5B-425E-BC70-A63C3D11FC87%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: TestCase.setUpTestData in-memory data isolation.

[Adam Johnson]

Hunar - it's best to start a separate thread for different topics, and even
better to check a support channel first, like the IRC channels. I think you
might be looking for how to contribute translations - start here:
https://docs.djangoproject.com/en/dev/internals/contributing/ . Or if you
just need support as a user, did you want
https://docs.djangoproject.com/en/2.1/topics/i18n/ ?

Tobias - using database updates isn't always viable. Also the system under
test might need to take in the model instance, mutate it and execute its
own save(), and then there's no way of rolling that back if the object
wasn't deepcopy'd.

On Fri, 30 Nov 2018 at 16:20, hunar techie 
wrote:

> hi there , im from kurdistan and my mother language is kurdish but
> unfortunately django doesnt support kurdish language , sometimes i need to
> add multi language to my projects , how can i add multi language?
> thanks for advice
>
> On Fri, Nov 30, 2018 at 7:15 PM Tobias McNulty 
> wrote:
>
>> Hi Simon,
>>
>> Intriguing proposal! Thanks for bringing it up. This is certainly
>> something I've struggled with on older projects we've continued to maintain.
>>
>> My first impression (and it may be only that) is that this seems a big
>> magical and potentially confusing, especially in the event the copy
>> operation fails. I would want some way to disable the behavior, or even
>> have "disabled" as the default, at least for a couple releases (e.g., by
>> keeping it as a decorator the way you have it now). Alternatively, is there
>> a reason this couldn't continue to live as an external package?
>>
>> I'm also not sure I understand the argument about how the current
>> implementation doesn't help reduce round trips to the database. Is this
>> just a case of the docs offering a less-than-optimal recommendation? When
>> tests do need to modify a record in the database that was created in
>> setUpTestData(), it's easy enough to replace self.obj.foo = bar;
>> self.obj.save() with Model.objects.filter(pk=self.obj.pk).update(foo=bar),
>> which will avoid modifying the Python object and be *at least* as
>> efficient as the original code, without the need for any additional
>> overhead. I'll admit tracking down the offending code can be a pain, but it
>> can be done.
>>
>> Could we, for example, include something along these lines as the
>> preferred approach in the docs
>> ,
>> and/or even find a way to raise an error or warning when a test does modify
>> an object that it shouldn't?
>>
>> Tobias
>>
>> On Wed, Nov 28, 2018 at 11:42 PM charettes  wrote:
>>
>>> Hey Josh, glad the package can help in the mean time!
>>>
>>> > Is there anyway to determine the pickle-ability of something without
>>> just trying to pickle it? I wouldn't be keen on that overhead.
>>>
>>> Not that I'm aware off but unfortunately. There really shouldn't be much
>>> overhead though because the deepcopy is only performed on instance
>>> attribute access. That means that tests that are only creating test data
>>> without accessing attributes assigned during setUpTestData() are not going
>>> to be affected by this change at all. In other words, I suggest only doing
>>> the deep copy if required for the requested attributes so if you define a
>>> complex data set in setUpTestData() then only the few attributes and their
>>> related objects would get deepcopied on instance attribute accesses.
>>>
>>> > Could you just capture any copy exceptions, raise a deprecation
>>> warning, and abandon the copy for that attribute?
>>>
>>> Yeah that's the exact plan for the deprecation phase; warn and return
>>> the actual attribute. From Django 3.1 this would result in an
>>> AttributeError.
>>>
>>> I've updated the branch with the deprecation warnings[0] approach.
>>>
>>> I'll give it one or two more weeks to gather a bit more feedback but it
>>> looks like this could be a viable option so far.
>>>
>>> Cheers,
>>> Simon
>>>
>>> [0]
>>> https://github.com/django/django/compare/master...charettes:testdata#diff-5d7d8ead1a907fe91ffc121f830f2a49R1032
>>>
>>> Le mercredi 28 novembre 2018 21:40:53 UTC-5, Josh Smeaton a écrit :

 Our project also suffers extensively with mutating objects assigned
 from setUp, preventing us from moving most of our tests to setUpTestData.
 I'll likely begin using your pypi package right away, thanks Simon!

 Backward compat issues are probably likely - but they'd be in test
 cases exclusively, making them extremely easy to find during an upgrade.
 That said, a deprecation warning is probably the most sensible path forward
 to prevent the need for immediate action.

 Is there anyway to determine the pickle-ability of something without
 just trying to pickle it? I wouldn't be keen on that overhead. Could you
 just capture any copy exceptions, raise a deprecation warning, and abandon
 the copy for that attribute?

 

Re: TestCase.setUpTestData in-memory data isolation.

[hunar techie]

hi there , im from kurdistan and my mother language is kurdish but
unfortunately django doesnt support kurdish language , sometimes i need to
add multi language to my projects , how can i add multi language?
thanks for advice

On Fri, Nov 30, 2018 at 7:15 PM Tobias McNulty 
wrote:

> Hi Simon,
>
> Intriguing proposal! Thanks for bringing it up. This is certainly
> something I've struggled with on older projects we've continued to maintain.
>
> My first impression (and it may be only that) is that this seems a big
> magical and potentially confusing, especially in the event the copy
> operation fails. I would want some way to disable the behavior, or even
> have "disabled" as the default, at least for a couple releases (e.g., by
> keeping it as a decorator the way you have it now). Alternatively, is there
> a reason this couldn't continue to live as an external package?
>
> I'm also not sure I understand the argument about how the current
> implementation doesn't help reduce round trips to the database. Is this
> just a case of the docs offering a less-than-optimal recommendation? When
> tests do need to modify a record in the database that was created in
> setUpTestData(), it's easy enough to replace self.obj.foo = bar;
> self.obj.save() with Model.objects.filter(pk=self.obj.pk).update(foo=bar),
> which will avoid modifying the Python object and be *at least* as
> efficient as the original code, without the need for any additional
> overhead. I'll admit tracking down the offending code can be a pain, but it
> can be done.
>
> Could we, for example, include something along these lines as the
> preferred approach in the docs
> ,
> and/or even find a way to raise an error or warning when a test does modify
> an object that it shouldn't?
>
> Tobias
>
> On Wed, Nov 28, 2018 at 11:42 PM charettes  wrote:
>
>> Hey Josh, glad the package can help in the mean time!
>>
>> > Is there anyway to determine the pickle-ability of something without
>> just trying to pickle it? I wouldn't be keen on that overhead.
>>
>> Not that I'm aware off but unfortunately. There really shouldn't be much
>> overhead though because the deepcopy is only performed on instance
>> attribute access. That means that tests that are only creating test data
>> without accessing attributes assigned during setUpTestData() are not going
>> to be affected by this change at all. In other words, I suggest only doing
>> the deep copy if required for the requested attributes so if you define a
>> complex data set in setUpTestData() then only the few attributes and their
>> related objects would get deepcopied on instance attribute accesses.
>>
>> > Could you just capture any copy exceptions, raise a deprecation
>> warning, and abandon the copy for that attribute?
>>
>> Yeah that's the exact plan for the deprecation phase; warn and return the
>> actual attribute. From Django 3.1 this would result in an AttributeError.
>>
>> I've updated the branch with the deprecation warnings[0] approach.
>>
>> I'll give it one or two more weeks to gather a bit more feedback but it
>> looks like this could be a viable option so far.
>>
>> Cheers,
>> Simon
>>
>> [0]
>> https://github.com/django/django/compare/master...charettes:testdata#diff-5d7d8ead1a907fe91ffc121f830f2a49R1032
>>
>> Le mercredi 28 novembre 2018 21:40:53 UTC-5, Josh Smeaton a écrit :
>>>
>>> Our project also suffers extensively with mutating objects assigned from
>>> setUp, preventing us from moving most of our tests to setUpTestData. I'll
>>> likely begin using your pypi package right away, thanks Simon!
>>>
>>> Backward compat issues are probably likely - but they'd be in test cases
>>> exclusively, making them extremely easy to find during an upgrade. That
>>> said, a deprecation warning is probably the most sensible path forward to
>>> prevent the need for immediate action.
>>>
>>> Is there anyway to determine the pickle-ability of something without
>>> just trying to pickle it? I wouldn't be keen on that overhead. Could you
>>> just capture any copy exceptions, raise a deprecation warning, and abandon
>>> the copy for that attribute?
>>>
>>> On Saturday, 24 November 2018 14:29:33 UTC+11, charettes wrote:

 Dear developers,

 Django 1.8 introduced the `TestCase.setUpTestData()` class method as a
 mean to
 speed up test fixtures initialization as compared to using `setUp()`[0].

 As I've come to use this feature and review changes from peers using it
 in
 different projects the fact that test data assigned during its execution
 couldn't be safely altered by test methods without compromising test
 isolation
 has often be the source of confusion and frustration.

 While the `setUpTestData` documentation mentions this limitation[1] and
 ways to
 work around it by using `refresh_from_db()` in `setUp()` I believe it
 defeats
 the whole p

Re: TestCase.setUpTestData in-memory data isolation.

[Tobias McNulty]

Hi Simon,

Intriguing proposal! Thanks for bringing it up. This is certainly something
I've struggled with on older projects we've continued to maintain.

My first impression (and it may be only that) is that this seems a big
magical and potentially confusing, especially in the event the copy
operation fails. I would want some way to disable the behavior, or even
have "disabled" as the default, at least for a couple releases (e.g., by
keeping it as a decorator the way you have it now). Alternatively, is there
a reason this couldn't continue to live as an external package?

I'm also not sure I understand the argument about how the current
implementation doesn't help reduce round trips to the database. Is this
just a case of the docs offering a less-than-optimal recommendation? When
tests do need to modify a record in the database that was created in
setUpTestData(), it's easy enough to replace self.obj.foo = bar;
self.obj.save() with Model.objects.filter(pk=self.obj.pk).update(foo=bar),
which will avoid modifying the Python object and be *at least* as efficient
as the original code, without the need for any additional overhead. I'll
admit tracking down the offending code can be a pain, but it can be done.

Could we, for example, include something along these lines as the preferred
approach in the docs
,
and/or even find a way to raise an error or warning when a test does modify
an object that it shouldn't?

Tobias

On Wed, Nov 28, 2018 at 11:42 PM charettes  wrote:

> Hey Josh, glad the package can help in the mean time!
>
> > Is there anyway to determine the pickle-ability of something without
> just trying to pickle it? I wouldn't be keen on that overhead.
>
> Not that I'm aware off but unfortunately. There really shouldn't be much
> overhead though because the deepcopy is only performed on instance
> attribute access. That means that tests that are only creating test data
> without accessing attributes assigned during setUpTestData() are not going
> to be affected by this change at all. In other words, I suggest only doing
> the deep copy if required for the requested attributes so if you define a
> complex data set in setUpTestData() then only the few attributes and their
> related objects would get deepcopied on instance attribute accesses.
>
> > Could you just capture any copy exceptions, raise a deprecation warning,
> and abandon the copy for that attribute?
>
> Yeah that's the exact plan for the deprecation phase; warn and return the
> actual attribute. From Django 3.1 this would result in an AttributeError.
>
> I've updated the branch with the deprecation warnings[0] approach.
>
> I'll give it one or two more weeks to gather a bit more feedback but it
> looks like this could be a viable option so far.
>
> Cheers,
> Simon
>
> [0]
> https://github.com/django/django/compare/master...charettes:testdata#diff-5d7d8ead1a907fe91ffc121f830f2a49R1032
>
> Le mercredi 28 novembre 2018 21:40:53 UTC-5, Josh Smeaton a écrit :
>>
>> Our project also suffers extensively with mutating objects assigned from
>> setUp, preventing us from moving most of our tests to setUpTestData. I'll
>> likely begin using your pypi package right away, thanks Simon!
>>
>> Backward compat issues are probably likely - but they'd be in test cases
>> exclusively, making them extremely easy to find during an upgrade. That
>> said, a deprecation warning is probably the most sensible path forward to
>> prevent the need for immediate action.
>>
>> Is there anyway to determine the pickle-ability of something without just
>> trying to pickle it? I wouldn't be keen on that overhead. Could you just
>> capture any copy exceptions, raise a deprecation warning, and abandon the
>> copy for that attribute?
>>
>> On Saturday, 24 November 2018 14:29:33 UTC+11, charettes wrote:
>>>
>>> Dear developers,
>>>
>>> Django 1.8 introduced the `TestCase.setUpTestData()` class method as a
>>> mean to
>>> speed up test fixtures initialization as compared to using `setUp()`[0].
>>>
>>> As I've come to use this feature and review changes from peers using it
>>> in
>>> different projects the fact that test data assigned during its execution
>>> couldn't be safely altered by test methods without compromising test
>>> isolation
>>> has often be the source of confusion and frustration.
>>>
>>> While the `setUpTestData` documentation mentions this limitation[1] and
>>> ways to
>>> work around it by using `refresh_from_db()` in `setUp()` I believe it
>>> defeats
>>> the whole purpose of the feature; avoiding unnecessary roundtrips to the
>>> database to speed up execution. Given `TestCase` goes through great
>>> lengths to
>>> ensure database level data isolation I believe it should do the same
>>> with class
>>> level in-memory data assigned during `setUpTestData`.
>>>
>>> In order to get rid of this caveat of the feature I'd like to propose an
>>> adjustment to ensure such in-

Consensus about visual diagrams in the docs.

[guettli]

I once created a simple ascii diagram to explain details of the Django ORM:

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

Years ago it took some time for me to understand it. And since then it
came up by new comers in our team several times.

There is agreement on the goal: yes, a visual diagrams in the docs would be 
nice.

But there is no agreement on the strategy.

I think ascii art is fine. Some suggest to use a graphiz plugin in for 
sphinx.

There is no progress because there is no clear consensus up to now.

I do not care for the strategy, I care for the goal.

How to find clear consensus now?

Regards,
   Thomas Güttler

-- 
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/2f6f3c4e-44cf-4b35-bb09-751828cc4921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.