Re: f-strings again.

[Dave Vernon]

Hi Shai,

If you used  '<{0} id="{1}"> {2} '.format(tag, id, content) in a
templatetag (for example), it could easily be used iteratively which would
increase the need for performance and at that point, you could argue that
f'<{tag} id="{id}"> {content} ' would be a preferable choice, even
though you are repeating the 'tag' argument.

More generally:

I understand the value of *not* doing a bulk change in a PR, but I was
wondering if it's OK to do a PR based purely on improved performance for a
specific element? (I don't have one in mind, the question is purely 'in
principle')

Thanks,

Dave


On Tue, 21 Jul 2020 at 12:08, Shai Berger  wrote:

> On Tue, 21 Jul 2020 01:28:31 -0700 (PDT)
> Carlton Gibson  wrote:
> >
> > Certainly 99% of cases can be handled as cleanly (or more so, because
> > I guess we fell `format()` is a little verbose) with %-formatting or
> > an f-string.
> > But if we say format() is not allowed, don't we then guarantee we hit
> > the one case in X where "Actually, this version with format() is much
> > cleaner"?
> >
> FWIW, it seems to me one case where this happens is when you want to
> use one argument multiple times, without naming:
>
> '<{0} id="{1}"> {2} '.format(tag, id, content)
>
> Arguably, this specific example would look better with named references,
> but, IMO, not with % formatting:
>
> '<%(tag)s id="%(id)s"> %(content)s ' % dict(
> tag=tag,id=id, content=content
> )
>
> and as noted, f-strings have their limitations.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20200721140822.47376bd8.shai%40platonix.com
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADqmmRygoVynBgrYp1NwpJj3XTmeWFWNCVWP5zznCrstPXQd2A%40mail.gmail.com.

Re: f-strings again.

[Dave Vernon]

+1, I'd happily help on any PR with this (it would be my first!).

Kind Regards,

Dave

Springbourne Tech Limited
M: +44(0) 79 2107 6483
W: www.springbourne-tech.com





*—This E-Mail and its contents are confidential, protected by law
and legally privileged.  Only access by the addressee is authorised.  Any
liability (in negligence, contract or otherwise) arising from any third
party taking any action or refraining from taking any action on the basis
of any of the information contained in this E-Mail is hereby excluded to
the fullest extent of the law.  In the event that you are not the
addressee, please notify the sender immediately.  Do not discuss, disclose
the contents to any person or store or copy the information in any medium
or use it for any purpose whatsoever.*




On Tue, 21 Jul 2020 at 09:43, Nick Pope  wrote:

> Hi,
>
> So I'm in favour of using f-strings, but agree that there are places where
> they are not appropriate.
>
> I am also against bulk updates in this case as mentioned in my previous
> comment
> . I
> don't think we should exclude replacing .format() with f-strings on a
> case-by-case basis, however, where performance is a concern.
>
> Thanks for your initial documentation, Carlton. Am wondering whether we
> should be more explicit about the pros and cons of each to help people make
> the correct decision? Here are my thoughts:
>
> %-formatting:
>
> + Simple to use printf-style familiar to all.
> + Default (can be changed
> )
> style used internally by the logging module, e.g. logging.info('Message
> with %s.', value)
> − Much less flexibility for formatting, see pyformat.info.
>
> ``.format()``:
>
> + Useful for interpolating a stored template string, e.g. from a database,
> which isn't possible with f-strings.
> − Worst performance due to method call.
> − Much more verbose, makes code less readable.
>
> f-strings:
>
> + Better performance than other methods due to dedicated FORMAT_VALUE
>  opcode.
> + Allows for embedding more complex expressions, e.g. f'Hello
> {user.get_full_name()}'
> + Much more concise, makes code more readable.
> − Cannot be used if string must be translated.
> − Complex expressions can get out of control. A sensible balance needs to
> be struck.
>
> Regarding performance, here are some simple numbers:
>
> python -m timeit -s 'x="test"' 'f"{x}"'
> 2000 loops, best of 5: 11.8 nsec per loop
> $ python -m timeit -s 'x="test"' '"%s" % x'
> 1000 loops, best of 5: 39.1 nsec per loop
> $ python -m timeit -s 'x="test"' '"{}".format(x)'
> 500 loops, best of 5: 76.1 nsec per loop
>
> I think it is probably also worth updating the documentation added in this
> commit
> .
> It isn't that xgettext doesn't support f-strings... It does:
>
> $ echo "_('Hello %s') % user.username" | xgettext --language=python
> --omit-header --output=- -
> #: standard input:1
> #, python-format
> msgid "Hello %s"
> msgstr ""
> $ echo "_('Hello {}').format(user.username)" | xgettext --language=python
> --omit-header --output=- -
> #: standard input:1
> msgid "Hello {}"
> msgstr ""
> $ echo "_('Hello {name}').format(name=user.username)" | xgettext
> --language=python --omit-header --output=- -
> #: standard input:1
> #, python-brace-format
> msgid "Hello {name}"
> msgstr ""
> $ echo "_(f'Hello {user.username}')" | xgettext --language=python
> --omit-header --output=- -
> #: standard input:1
> #, python-brace-format
> msgid "Hello {user.username}"
> msgstr ""
> $ echo "_(f'Hello {user.get_full_name()}')" | xgettext --language=python
> --omit-header --output=- -
> #: standard input:1
> msgid "Hello {user.get_full_name()}"
> msgstr ""
>
> It is actually that Python doesn't support modifying the template string
> prior to interpolating the values which is the requirement for injecting
> the translated string. PEP 498 
> makes no explicit mention of this. PEP 501
>  was initially looking at
> solving the problem but was deemed a poor fit and was also deferred.
>
> Kind regards,
>
> Nick
> On Tuesday, 21 July 2020 at 08:28:54 UTC+1 Mariusz Felisiak wrote:
>
>> Hi y'all,
>>
>> I will not stand against f-strings, I think we can allow them. My
>> main concerns is readability. f-strings are powerful and it's quite common
>> that they are used with functions calls and complex formatting which makes
>> code hard to understand and maintain, *"With great power comes great
>> responsibility" ...*
>>
>> I'm strongly against any bulk updates to conform to this style. This
>> will just create unnecessary noise in the history, I know that there are
>> tools, please don't start this discussion again :)
>>
>> I would also be in favor of keeping 

Re: Deadlock bug in logging? Reproducible case

[Dave Vernon]

Sorry - that message was sent as a 'reply' in error - my colleague uses
ajax with Django a lot and I was trying to forward this to him.

Kind Regards,

Dave


On Wed, 22 Apr 2020 at 18:23, Brian Tiemann  wrote:

> Hi all,
>
> I was directed here after getting corroboration on #django and elsewhere.
>
> I have what appears to be a bug in which a Django app can deadlock if you
> hit it with a lot (>3) of AJAX requests within a short time (i.e. all
> triggered in parallel from a single HTML page). I have a reproducible case
> here:
>
> https://github.com/data-graham/wedge
>
> I'd really appreciate it if someone could take a look and let me know
> whether I'm doing something wrong, or if there's something systemic going
> on. Thanks 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7fa1a28d-8f54-48cd-9c34-5d1c111ef136%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADqmmRxkUyAs3EH%3DggehJTkXb5YM0ENR5wJe19EEHPO8uTF2NQ%40mail.gmail.com.

Re: Deadlock bug in logging? Reproducible case

[Dave Vernon]

FYI 

Sent from my iPhone

> On 22 Apr 2020, at 18:23, Brian Tiemann  wrote:
> 
> 
> Hi all,
> 
> I was directed here after getting corroboration on #django and elsewhere.
> 
> I have what appears to be a bug in which a Django app can deadlock if you hit 
> it with a lot (>3) of AJAX requests within a short time (i.e. all triggered 
> in parallel from a single HTML page). I have a reproducible case here:
> 
> https://github.com/data-graham/wedge
> 
> I'd really appreciate it if someone could take a look and let me know whether 
> I'm doing something wrong, or if there's something systemic going on. Thanks 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/7fa1a28d-8f54-48cd-9c34-5d1c111ef136%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6BEF80E7-AC03-46A3-91B0-686146F7C17F%40springbourne-tech.com.

Re: Improve migration conflict detection

[Dave Vernon]

+1 charettes too; to add to the factors to consider I suspect the issue of 
keeping it performant too (especially for unit tests) could become a 
challenge.

On Tuesday, February 18, 2020 at 7:08:51 PM UTC, charettes wrote:
>
> +1 to what Tim said.
>
> Also what about migration leaf migrations with models that refer to each 
> others? What about a model rename in a leaf node that a model in the other 
> leaf references to for some attribute names (e.g. m2m field intermediary 
> table name).
>
> I don't want to discourage you from trying because you'll likely learn a 
> ton of stuff trying but I'm worried this might be a dead end or cause the 
> migration framework code to be even more complex than it already is.
>
> Le mardi 18 février 2020 13:45:09 UTC-5, Tim Graham a écrit :
>>
>> Have you considered what would happen if a migration has a RunPython or 
>> RunSQL? They may require a certain model state.
>>
>> On Tuesday, February 18, 2020 at 12:08:03 PM UTC-5, caio wrote:
>>>
>>> I’m working on this as a standalone PoC app for now, I may be able to 
>>> share a repository with the code soon in order to get some feedback
>>>
>>> Here’s in simple words where I’m at:
>>>
>>> * I’ve replaced the restriction of only-one-leaf-node-per-app from the 
>>> Migration Loader [1] to only-one-leaf-node-per-app-per-model. It means that 
>>> with this, you can have more than one person changing different models in 
>>> the same app, without introducing conflicts. Migrations referring to the 
>>> same app and model would still cause a conflict
>>>
>>> * I’m now trying to get the migration graph’s forwards/backwards plan to 
>>> handle cases where there are more than one leaf node in the graph.
>>>
>>> I may be doing the wrong assumption here, but it seems to me that 
>>> migrations changing different models shouldn’t introduce a real conflict? 
>>> If I have the following migration graph:
>>>
>>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0003_def ] => [ 
>>> 0004_auto ]
>>>
>>> Where 0003_abc and 0003_def don’t have any model changes in common: no 
>>> FK references, nothing related at all
>>>
>>> If this assumption is correct, I could have the two migrations in ANY 
>>> order in the graph, that it would still give me the same result, for 
>>> example:
>>>
>>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0003_abc ] => [ 
>>> 0004_auto ]
>>>
>>>
>>> Please let me know if I’m missing something, ideas and thoughts are 
>>> really welcome :)
>>>
>>>
>>> [1] 
>>> https://github.com/django/django/blob/2a038521c4eabdc5f6d5026d3dd6d22868e329cd/django/db/migrations/loader.py#L301-L313
>>>
>>> --
>>> Caio Ariede
>>> caio@gmail.com
>>>
>>>
>>>
>>>
>>> On Feb 13, 2020, at 11:49, Dave Vernon  
>>> wrote:
>>>
>>> If I had to guess, it would be that with more than one leaf node, you 
>>> would end up a substantial challenge resolving dependancies which would 
>>> create an Order(N) problem (i.e. there's a chance of excessive time to 
>>> complete the resolution).
>>>
>>> I certainly worked on some migration logic that took a similar approach 
>>> to this.
>>>
>>>
>>> On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
>>>>
>>>> I don’t think many people can answer this off the top of their heads. I 
>>>> certainly can’t and I have contributed a couple things to migrations.
>>>>
>>>> It’s probably quite necessary there’s only one leaf node but I can’t 
>>>> say for sure.
>>>>
>>>> On Thu, 13 Feb 2020 at 13:58, caio  wrote:
>>>>
>>>>> Cool. If I'm understanding this correctly, it auto-resolves during 
>>>>> *makemigrations*?
>>>>>
>>>>> I'm looking for something that could handle conflicts during the 
>>>>> *migrate* command, but I'm not sure if that's really possible. I 
>>>>> guess it depends on how intrinsic the single-leaf-node restriction is to 
>>>>> the whole migration system
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye 
>>>>> escreveu:
>>>>>>
>>>>>> Definitely a plus one on auto resolving mi

Re: Improve migration conflict detection

[Dave Vernon]

What if the migrations aren't merged before 0004 is created and you get:

[ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0004(a) ]

and 

[ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0004(b) ]

where 0004(a) != 0004(b) and 0004(a) modifies the model schema in a way 
that overwrites 0003_def's change but then 0004(b) relies on 0003_def.

To be sure, I think at that point you need to check for all conflicts 
downstream and their inter-dependancy not just down their own branch, but 
all migrations down each diverged branch; also it wouldn't be enough to 
compare each equivalent step number, e.g in our example above you now need 
to check 0004(a) against 0003_def as well as against 0004(b), etc...







On Tuesday, February 18, 2020 at 6:45:09 PM UTC, Tim Graham wrote:
>
> Have you considered what would happen if a migration has a RunPython or 
> RunSQL? They may require a certain model state.
>
> On Tuesday, February 18, 2020 at 12:08:03 PM UTC-5, caio wrote:
>>
>> I’m working on this as a standalone PoC app for now, I may be able to 
>> share a repository with the code soon in order to get some feedback
>>
>> Here’s in simple words where I’m at:
>>
>> * I’ve replaced the restriction of only-one-leaf-node-per-app from the 
>> Migration Loader [1] to only-one-leaf-node-per-app-per-model. It means that 
>> with this, you can have more than one person changing different models in 
>> the same app, without introducing conflicts. Migrations referring to the 
>> same app and model would still cause a conflict
>>
>> * I’m now trying to get the migration graph’s forwards/backwards plan to 
>> handle cases where there are more than one leaf node in the graph.
>>
>> I may be doing the wrong assumption here, but it seems to me that 
>> migrations changing different models shouldn’t introduce a real conflict? 
>> If I have the following migration graph:
>>
>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0003_def ] => [ 
>> 0004_auto ]
>>
>> Where 0003_abc and 0003_def don’t have any model changes in common: no FK 
>> references, nothing related at all
>>
>> If this assumption is correct, I could have the two migrations in ANY 
>> order in the graph, that it would still give me the same result, for 
>> example:
>>
>> [ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0003_abc ] => [ 
>> 0004_auto ]
>>
>>
>> Please let me know if I’m missing something, ideas and thoughts are 
>> really welcome :)
>>
>>
>> [1] 
>> https://github.com/django/django/blob/2a038521c4eabdc5f6d5026d3dd6d22868e329cd/django/db/migrations/loader.py#L301-L313
>>
>> --
>> Caio Ariede
>> caio@gmail.com
>>
>>
>>
>>
>> On Feb 13, 2020, at 11:49, Dave Vernon  
>> wrote:
>>
>> If I had to guess, it would be that with more than one leaf node, you 
>> would end up a substantial challenge resolving dependancies which would 
>> create an Order(N) problem (i.e. there's a chance of excessive time to 
>> complete the resolution).
>>
>> I certainly worked on some migration logic that took a similar approach 
>> to this.
>>
>>
>> On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
>>>
>>> I don’t think many people can answer this off the top of their heads. I 
>>> certainly can’t and I have contributed a couple things to migrations.
>>>
>>> It’s probably quite necessary there’s only one leaf node but I can’t say 
>>> for sure.
>>>
>>> On Thu, 13 Feb 2020 at 13:58, caio  wrote:
>>>
>>>> Cool. If I'm understanding this correctly, it auto-resolves during 
>>>> *makemigrations*?
>>>>
>>>> I'm looking for something that could handle conflicts during the 
>>>> *migrate* command, but I'm not sure if that's really possible. I guess 
>>>> it depends on how intrinsic the single-leaf-node restriction is to the 
>>>> whole migration system
>>>>
>>>> Thanks!
>>>>
>>>> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye 
>>>> escreveu:
>>>>>
>>>>> Definitely a plus one on auto resolving migrations a test package 
>>>>> still in planning aims to solve this 
>>>>> https://github.com/jackton1/django-migration-resolver-hook
>>>>>
>>>>> On Feb 11, 2020, at 1:42 PM, Caio Ariede  wrote:
>>>>>
>>>>> Hey folks,
>>>>>
>>>>> I was looking 

Re: Improve migration conflict detection

[Dave Vernon]

If I had to guess, it would be that with more than one leaf node, you would 
end up a substantial challenge resolving dependancies which would create an 
Order(N) problem (i.e. there's a chance of excessive time to complete the 
resolution).

I certainly worked on some migration logic that took a similar approach to 
this.


On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
>
> I don’t think many people can answer this off the top of their heads. I 
> certainly can’t and I have contributed a couple things to migrations.
>
> It’s probably quite necessary there’s only one leaf node but I can’t say 
> for sure.
>
> On Thu, 13 Feb 2020 at 13:58, caio > 
> wrote:
>
>> Cool. If I'm understanding this correctly, it auto-resolves during 
>> *makemigrations*?
>>
>> I'm looking for something that could handle conflicts during the 
>> *migrate* command, but I'm not sure if that's really possible. I guess 
>> it depends on how intrinsic the single-leaf-node restriction is to the 
>> whole migration system
>>
>> Thanks!
>>
>> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye 
>> escreveu:
>>>
>>> Definitely a plus one on auto resolving migrations a test package still 
>>> in planning aims to solve this 
>>> https://github.com/jackton1/django-migration-resolver-hook
>>>
>>> On Feb 11, 2020, at 1:42 PM, Caio Ariede  wrote:
>>>
>>> Hey folks,
>>>
>>> I was looking at the code used to detect conflicts in migrations [1]. It 
>>> seems to use a very safe approach, by avoiding with multiple node leafs in 
>>> the migration graph.
>>>
>>> While this is safe, I’ve been having some problems when it comes to 
>>> scalability when having multiple migrations created in a short period of 
>>> time (for the same app).
>>>
>>> Questions:
>>>
>>> 1. Are there any obvious impediments on improving the conflicts 
>>> detection?
>>> 2. Does anyone have ideas on how to improve the conflict detection? (eg. 
>>> going down from app-level to model-level detection)
>>>
>>>
>>> Thanks!
>>>
>>>
>>> [1] 
>>> https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313
>>>  
>>> 
>>>
>>> --
>>> Caio Ariede
>>> caio@gmail.com
>>>
>>>
>>>
>>>
>>> -- 
>>> 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-d...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/FE717E60-7B66-4050-B233-20C47FBF6038%40gmail.com
>>>  
>>> 
>>> .
>>>
>>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/31d78cfc-05bc-4bee-897b-3d9e2e502a3d%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bd688186-752b-4bf5-9340-5d9607d17038%40googlegroups.com.