I was and and I'm still bugged by how black decided to go for double quotes
instead of single ones. Even if it's backed some valid arguments it left
all the projects following PEP 8's recommendations over the years with this
git blaming loss trade off. From past experimentation with large'ish
I don't see how this question related to Django at all specifically -
building an application like what you want is mainly a front end task, not
a back end one.
I'd suggest using whatever front end framework your team is already
familiar with (Eg. Vue, React, Angular, etc..).
>From my
Hi Emil,
This is a very interesting idea and I find your use-case compelling. Adding
support for custom triggers to Django itself would resolve your main use
case this time but I also see value in a general solution that enables
Django's third-party ecosystem.
I think the next step is to open a
On Sun, Apr 14, 2019 at 3:11 AM Nick Sarbicki
wrote:
> Just going to say that one of the main frustration points I've had when
> making a contribution is having to fix small formatting errors (often minor
> things in docstrings which aren't _always_ consistent).
>
I constantly need to be
Hi
We want to develop form builder app like wpforms .
Who has any previous experience?
Which library is most useful and most rapid way to develop?
Best regards..
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)"
>From my subjective point of view `one` is more short and concise, but your
points are valid too, so something like `qs.first(ordered=False)` seems to
be a reasonable tradeoff.
I'd say that its arg should be keyword only to be explicit.
And this arg doesn't then need to be added to `last`.
вс,
On Sun, Apr 14, 2019 at 1:06 PM Florian Apolloner wrote:
> This is imo not something that scales well. Also it is not something I want
> to pay our fellows for, I rather have them use their time on something else.
> It is true that it is probably easier and faster to just fix code instead of
>
Hello,
I'm strongly in favor of adopting black with the default options.
In my opinion, it's the first Python code formatter that passes the bar of "on
average, does better than any single programmer". Trying to enforce something
else manually is a waste of energy that produces worse results.
Hello follow Djangonauts.
I'm writing this post in an attempt to ignite a discussion about the
autodetector, and how to make it expandable, such that third-party apps can
generate their custom migrations automatically.
This has previously been discussed here:
*
> 2. there are issues with git history in doing "the great commit".
Tools make a real difference here. I know everyone has their preferred
tools and workflows, but there are tools that let one move through
iterations of git blame. This is something I do quite frequently. Just one
example, in
Agree with Florian that the progressive rollout is more trouble than it's
worth. Tangling up feature changes with whole file formatting will make it
harder to review changes, but will also be more difficult to use tools like
git blame.
As for disagreeing with some of Blacks choices - you learn
On 4/13/19 10:22 PM, Markus Holtermann wrote:
Thanks for the proposal, Shai. I quite like it.
As discussed at the DCEU sprints I think I'd like to be able to omit the display form of an item and have it auto
generated from an item's name, i.e. turning "FOO_BAR" into "Foo Bar"
On 4/14/19 8:02 PM, Florian Apolloner wrote:
Hi,
while your arguments for adding `.one` are all good and well, I think
adding yet another function will add quite some confusion and will make
arguing harder imo. As a middleground I could imagine adding an
`ordered=True/False` argument to
Hi,
On Sunday, April 14, 2019 at 10:22:46 AM UTC+2, Curtis Maloney wrote:
>
> Can such a tool be automated into, say, github in a way that doesn't
> create extra commit noise?
>
Probably, but after blacking (is that even a word ;)) the codebase once
there shouldn't be much commit noise.
I
We've used Black for the Channels/ASGI projects for about the last year,
and I have nothing but good opinions on it from that perspective. It's made
pull requests much easier to get formatted, because fixing it is just a
case of running a single command (and if you do the right pre-commit hook,
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
towards the "git blame" issue is needed. I guess the
On Saturday, April 13, 2019 at 10:21:48 PM UTC+2, James Bennett wrote:
>
> But we already have and enforce a style guide, and some parts of it are
> things Black can't auto-enforce.
>
We do? I mean sure, we do have a styleguide, but enforcing it? It all
depends on how well our fellows
Hi,
On Sunday, April 14, 2019 at 1:04:22 AM UTC+2, Berker Peksağ wrote:
>
> I always do it to not bother
> contributors with these changes, especially if they are new to the
> project.
>
This is imo not something that scales well. Also it is not something I want
to pay our fellows for, I
Hi,
while your arguments for adding `.one` are all good and well, I think
adding yet another function will add quite some confusion and will make
arguing harder imo. As a middleground I could imagine adding an
`ordered=True/False` argument to first to turn off ordering as needed. This
will
Hi
> 2. there are issues with git history in doing "the great commit".
While I don't have much experience neither in Python/Django nor in git,
maybe a view fom "outside" may add something useful to the discussion.
I'm just seeing that discussion is separated between on the one hand
"black is
Hi. Thank you for that detail response.
It needs to be clarified that I'm not that worried about exception as it
could seem :)
It was just an answer to those 2 comments to show that their workarounds
result in different behaviour than proposed `one`.
`get_or_none` would be useful in my opinion
Hi,
I agree that first() should imply ordering, and bemoan the decision,
made several years ago, that first() should be the answer to all the
people asking for get_or_none().
That said, get_or_none()'s definition is trivial:
def get_or_none(qs. *args, **kw):
try:
So to summarise the discussion so far:
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 formatting choices.
Just going to say that one of the main frustration points I've had when
making a contribution is having to fix small formatting errors (often minor
things in docstrings which aren't _always_ consistent).
It produces a lot of inertia and can stop PRs from getting merged for
extended periods of
First/last enforces ordering because of its nature and also we can't break
compatibility. And second factor is that qs[0] as I wrote above can raise
exception and also will still have ordering (from model.meta for example).
вс, 14 апр. 2019 г., 0:04 Florian Apolloner :
> On Saturday, April 13,
25 matches
Mail list logo
