Hello there,
I am using* django chatterbot *but whenevere i typed any new sentence and
hit enter then *the bot* returns always the current time.I do not know why
it always respond with the current time .Any ideas?
And can anyone tell me how we can train my personal data with django
chatterbot
Le 17/4/19 à 2:33, Dan Davis a écrit :
+1 isort
-1 black
I think that codestyle checkers are better, because you teach yourself
proper style for python.
I'm in a team in which we've enforced Black a bit more than a year ago,
and I can tell you that now, everyone code in a blackish style
On 4/17/19 4:55 AM, Aymeric Augustin wrote:
Hello Will,
It's mostly for performance reasons, since validation can be expensive.
Really? My memory was that it was (a) backward compatibility [model
validation was added later], and (b) practicality [try catching
everywhere in your code you
> One thing we have not considered here is that after running black on
Django a huge portion of our outstanding merge requests will have
conflicts, some of which might be tricky to rebase. I’m not sure there is
much we can do about that though.
With a little bit of git-foo, this is actually not
Well shoot...this definitely seems like something only I'm running into.
Appreciate y'alls feedback. Thanks
--
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
Hi Carlton,
I have already submitted this proposal to Google, I will be glad if you can
go through it.
Thanks & Regards
On Wed, Apr 17, 2019 at 12:28 PM Carlton Gibson
wrote:
> Deadline for submissions has passed. I’m reviewing this week.
>
> On Wed, 17 Apr 2019 at 08:52, Adam Johnson
I would be +1 for Black. I think it makes a lot of sense for a project like
Django, and it does seem that a non trivial amount of both contributor and
reviewer time is spent on formatting fixes.
The choice of double quotes by default used to annoy me, but after using black
for a while I think
Hi Dan,
On 19-04-16 20:33:29, Dan Davis wrote:
>+1 isort
>-1 black
>
>I think that codestyle checkers are better, because you teach yourself
>proper style for python.
I appreciate this argument, but: As Django community our primary concern
in this discussion has to be the impact black would have
On 19-04-16 17:34:11, Will Gordon wrote:
>In the same way that editable fields are forced to not be included in a
>ModelForm (
>https://github.com/django/django/blob/master/django/forms/models.py#L146),
>I would like to propose that "required" fields (`blank=False`) be forced to
>be included in
Yes I agree with others, that this should not be implemented. As I find
this too much specific to just your case.
There are many cases, like what if there is some required field which the
developer wants to set by themselves and don't want user to edit that
(transaction details maybe for a
Deadline for submissions has passed. I’m reviewing this week.
On Wed, 17 Apr 2019 at 08:52, Adam Johnson wrote:
> Hi Rohit!
>
> It seems your email thread has been missed by the list, I don't know why,
> perhaps it hit some spam filters. There's also another thread from a
> student proposing
Hi Rohit!
It seems your email thread has been missed by the list, I don't know why,
perhaps it hit some spam filters. There's also another thread from a
student proposing the same projectt:
After dozens of mails it's clear that this is certainly a controversial
topic -- especially, as always, string quoting.
I think there is an overwhelming benefit in adopting black and not
deviating from the defaults even if the only benefit of this is just never
having to discuss these choices
I'm against, there are lots of cases where a modelform is used to edit an
exitsting object and thus the required fields are already set and you don't
want them to be editable.
If it's a trivial patch then you should think about extending modelform in
your own project enforce it there and then
Please don't do this.
There are very good reasons for NOT including blank=False fields by default
such as batch-editing some field with a formset or inlineformset or just
offering different forms to users with different access levels (as Tobias
wrote).
Django started recommending using `fields`
15 matches
Mail list logo
