Hi
One of the most difficult things for me while preparing my GSoC proposal
was getting myself acquainted to Django's humungous code base.
To prepare a proposal one should know what modules they would need to
modify & what part of the code they will need to work with. To do that one
should *at
Dear Django developer community,
often I would like to trigger a message to the user with the message
rendered dynamically in the client-side JS code. I use the message
framework's tags to differentiate between the different messages in JS.
Usually, I will define the message's text on the
I agree, -1, for composability. I must also say, I find the current idiom
easier to read than the proposed version, but by far the more important factor
to me is the violation of composability by bundling different kinds of
functionality into one call. One of the nice features of querysets.
Hey Andrew.
I've been thinking a lot about this. You clearly shouldn't be maintaining
Channels single-handedly indefinitely.
On Thursday, 17 January 2019 19:07:06 UTC+1, Andrew Godwin wrote:
>
> Given that, if nobody else can step forward to take over, I'll have to put
> those three projects
This mailing list is for the development of Django itself, not for support
using Django. Please use the. django-users mailing list for that, or IRC
#django on freenode, or a site like Stack Overflow.
On Sat, 19 Jan 2019 at 11:16, Anh Nguyen wrote:
> Hi everyone,
> I’m using
Bonus track: If you have a template with complete HTML (without blocks).
You can add to this command another features like compress HTML or use line
styles (using pyliner[1]) and win more time yet :-) Because this feature
does not consume run time, but this feature waste preprocessing time, like
I reply between lines,
El sáb., 19 ene. 2019 a las 12:31, Adam Johnson () escribió:
> I agree, I'd like to see a third party package too.
>
If I have any time I will do it. And I will say something in this thread.
>
> I'm all up for seeing improvements in template rendering speed but working
I reply between lines,
El sáb., 19 ene. 2019 a las 11:00, Jani Tiainen ()
escribió:
> Hi.
>
> Unfortunately Django is already big. Every new feature requires careful
> consideration since it adds maintenance burden to already loaded
> maintainers.
>
Yes, I know it.
>
> So best and pretty much
Hi, I am also interested to contribute on this topic. Please guide.
On Thu, Jan 17, 2019 at 11:37 PM Andrew Godwin wrote:
> Hi all,
>
> I'm writing to you all to update you on the current situation of Channels
> and related libraries (channels-redis and Daphne) and potentially ask for
> help.
>
Hi everyone,
I’m using RichTextUploadField() for my content’s post.
So now i need to translate this content to other languages.
Im gonna using model-translate’s package. But the content are the HTML tags
from RichTextUploadField
So now. what thing i need to do.
Please give me some solutions.
I agree, I'd like to see a third party package too.
I'm all up for seeing improvements in template rendering speed but working
code in a third party package is way more valuable than more discussion.
Many of Django's major features in the past (e.g. SecurityMiddleware,
Migrations) were third
> On 19 Jan 2019, at 11:48, Santiago Basulto wrote:
>
> Haha, sorry, got overly excited. What's the usual process to make these sort
> of decisions in these cases? Should we ask the users list?
No problem. :)
We make decisions here. Say you’d have opened a Trac ticket for this, I’d have
-1 on this suggestion from me too.
The current API is composable (
https://en.m.wikipedia.org/wiki/Composability ), the suggestion is to make
it less so, and make it harder to learn
On Sat, 19 Jan 2019 at 08:01, charettes wrote:
> To echo my comments on the PR I don't like the idea of relaying
>
> For *my* (completely unilateral) point of view, this is very important and
> I'd love to have a place to just flip a switch and change them all; well,
> I'd even prefer for it to be the default behavior, but I know selects look
> cool too.
>
How many projects do you need this on? I think the
Haha, sorry, got overly excited. What's the usual process to make these
sort of decisions in these cases? Should we ask the users list?
The setting proposal is purely from my perspective as a user. For *my*
(completely unilateral) point of view, this is very important and I'd love
to have a
El sáb., 19 ene. 2019 7:08, Jani Tiainen escribió:
> Hi,
>
> You said that this doesn't require any change in Django at all.
>
> So this doesn't need to be in Django at all, it can survive as its own and
> that way it should be.
>
> So make your enhancement as reusable app and release it to
To echo my comments on the PR I don't like the idea of relaying args and
kwargs to filter()
as it I think it adds little value considering it paints us in a corner
with regards to future
count()/exists() API change.
For example if we ever want to add `distinct` kwarg and fields arg passing
to
17 matches
Mail list logo
