Hi, Raphael.
Ah, yes, I have seen your project, but I guess I forgot to link it in my
proposal.
It *is* very interesting, and I believe it will be helpful for anyone who
wants to implement
this. Let's hope we can make this happen. Thanks for the feedback!
Regards,
Sage
On Tuesday, 16 April
To address some of Curtis Maloney's concerns:
>
> 1. automated code formatting will be a great boon - reduce work, lower
> barrier for new committers, reduce work for the fellows, etc.
>
> 2. there are issues with git history in doing "the great commit".
>
> 3. there are issues with black's
I feel like it would be worse as it would break formatting changes across
multiple commits,
creating an inconsistent formatting code base and generating large
unrelated changes diff
when altering a still untouched file which would make the review harder.
Cheers,
Simon
Le mardi 16 avril 2019
This continues the discussion from
https://code.djangoproject.com/ticket/30309. That issue was a misreporting
of the core issue which became apparent after further investigation;
apologies for the noise, I am new to Django.
When a Django model is created with a OneToOneField, or created with
As I've said on the ticket I think we should make this change as
it's backward compatible and more coherent with the other
RelatedObjectDoesNotExist usages of the related fields API.
Cheers,
Simon
Le mardi 16 avril 2019 07:22:52 UTC-4, David Beitey a écrit :
>
> This continues the discussion
> This would address the problem of some pull requests not being merged
> for a long period, because of minor formatting issues.
>
We don't have such PRs. If PRs have tests, docs (when required) and
solutions are of good quality we would fix minor formatting issues before
merge. It never
I can't seem to find a good reason for this. And I could foresee this
preventing potential mistakes. I'm not proposing to actually change the
implementation, I guess I'm just looking for the reason of it.
--
You received this message because you are subscribed to the Google Groups
"Django
My two cents: black's mostly ok but I'm against any auto-formatting. Code
style is much more than whitespace arrangement, it requires looking,
creative thinking, judging, and sometimes actually compromising rules and
looks for readability while the usual attitude with such tools is "I have
this
Hello Will,
It's mostly for performance reasons, since validation can be expensive. You can
override save() to call full_clean() in a model if you'd like.
Cheers,
--
Aymeric.
> On 16 Apr 2019, at 20:47, Will Gordon wrote:
>
> I can't seem to find a good reason for this. And I could
Ivan, what you’re talking about is subjective code formatting, and lends
itself to extreme bikeshedding and little consensus. Django already has a
formatting standard that mergers try to enforce at review and commit time.
But it’s time consuming, prone to missing things, and requires lots of back
So the validation is cheaper when performed by ModelForm, as opposed to the
Model?
--
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
Ahh, cool. That makes more sense. I worry that it still leaves open the
potential of accidentally not validating something. It may make more sense
to offer instance.save(validate=False) instead of relying on the developer
to always know whether they can trust the input. But I agree that for
Yeah, it's very common to confuse style with formatting. Not having to
think is a productivity win when and only when you don't care about your
product's quality (in which case I'd suggest using generators and stop
thinking about code altogether). Language is a communication tool, a
programming
The idea is that you generally always have to do extensive validation when
accepting user input through a form. These validations could require
additional database queries or other somewhat expensive lookups (especially
with validate unique).
However if you are loading data from a trusted source,
Sorry if I wasn't more clear, but using a warning was exactly what I was
proposing. In the same way that a FieldError is raised when an editable field
is listed in fields, I was essentially planning on doing the exact same
check on the blank attribute. I agree that this should be ignorable, and
Would it be weird to just make it so that the "required" field *must* be
present in exclude? This way, if you *accidentally* leave off a required
field, you're quickly notified about itbut if you explicitly mark it as
something to exclude, it makes it clear to everyone exactly what you're
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 a ModelForm.
While I understand that a
+1 isort
-1 black
I think that codestyle checkers are better, because you teach yourself
proper style for python.
On Tue, Apr 16, 2019 at 8:17 PM Josh Smeaton wrote:
> We aren't talking about code minifiers though, are we? We're talking about
> a very specific tool with very specific rules. No
Python has a warning system, and Django already uses it for things like
deprecation notices.
I don't like error by default as an approach to this, but a warning (which
is easy to ignore -- it doesn't break your code) would be fine.
--
You received this message because you are subscribed to the
There are plenty of use cases when this behavior wouldn't be desired, such
as editing the same model object with 2+ different model forms. Such a
pattern might be more common when editing an existing object, but isn't out
of the question for creating new objects, either (think of a multi-step
form
We aren't talking about code minifiers though, are we? We're talking about
a very specific tool with very specific rules. No one will ever agree on
one specific code style, which is why subjectivity is anti-productive.
Black chooses a specific set of rules and removes ambiguity. Some choices
As the documentation points out, ModelForm avoids implicitly adding fields
to a form when you haven't told it to, and does so for security reasons.
Mass-assignment bugs have caused significant security issues in the past
for other systems which *did* implicitly support/add fields, and I'd like
to
I can certainly agree that there may be some use cases where it should be
possible to disable this functionality, but I would argue that erroring on
a missing, required field should be the default, and allow for a way to
override...as opposed to allowing missing fields and requiring a
Hello,
I'm not sure if it's relevant for the discussion, but black requires python
3.6.0+.
Several Linux distros does not ship 3.6.0+ yet, including, but not limited
to:
* Debian Stretch (current LTS)
* FreeBSD 12 (current release)
* Ubuntu 16.04 Xenial (previous LTS)
* Linux Mint 18.1
For the record, the ticket is https://code.djangoproject.com/ticket/30371.
The discussion continues there.
Claude
Le lundi 15 avril 2019 16:56:46 UTC+2, Melvyn Sopacua | 3YOURMIND a écrit :
>
> Well, the testcase is a bit hard. I can reproduce it by calling
> `sqlmigrate` on any migration that
Hi Sage, Hi everyone,
I lacked the time to read this mailing list in the past months, and
someone at DjangoCon Europe just pointed me to this thread, so just for
reference, I want to add some prior work that I did to the list:
At DjangoCon US and thereafter, I developed a third-party
Hi Emil,
this would only affect Django 3.0 which supports only python3.6 -- as such
you couldn't even run Django on those systems anyways.
Cheers,
Florian
On Tuesday, April 16, 2019 at 10:12:20 AM UTC+2, Emil Madsen wrote:
>
> Hello,
>
> I'm not sure if it's relevant for the discussion, but
Am 14.04.19 um 12:15 schrieb Florian Apolloner:
> Hi Christian,
>
> I think you are making a good argument here. On one hand short-comings
> in our tool chain should not block us from making changes. On the
> other hand, we do have to live with them -- so having at least some
> technical solution
28 matches
Mail list logo
