Aymeric Augustin
writes:
> You're right. Then just remove "to submit pull requests" from my
> argument and it still holds, simply because the vast majority of the
> Django ecosystem is on GitHub, and you can't participate meaningfully
> without GitHub.
You can, at present, participate in Django'
Can you create a PR, with docs and tests?
If not, we'll need to find someone brave enough to delve into the ORM and
add this [quite valid, IMHO] optimisation.
--
C
On 8 August 2014 11:16, David Butler wrote:
>
>
> On Thursday, August 7, 2014 6:48:22 PM UTC-5, Tim Graham wrote:
>>
>> Does .fi
2014-08-08 7:19 GMT+02:00 Shai Berger :
> On Friday 08 August 2014 01:49:55 Ben Finney wrote:
> > Aymeric Augustin writes:
> > > GitHub doesn't require creating a new account, since anyone interested
> > > in contributing to Django should have a GitHub account already to
> > > submit pull request
On Friday 08 August 2014 01:49:55 Ben Finney wrote:
> Aymeric Augustin writes:
> > GitHub doesn't require creating a new account, since anyone interested
> > in contributing to Django should have a GitHub account already to
> > submit pull requests.
>
> This seems to be a common assumption, but i
I personally use qs = qs.filter(somefield__gte=1) (works if the id field is
an integer)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+u
On Thursday, August 7, 2014 6:48:22 PM UTC-5, Tim Graham wrote:
>
> Does .filter(somefield__isnull=False) not work for what you're trying to
> do?
>
If I do .filter(somefield__isnull=False) it tries to do a LEFT OUTER JOIN
on the table for somefield instead of a WHERE EXISTS (...) and if that
We could override `AbstractBaseUser.clean_fields` to call an empty
`AbstractBaseUser.clean_password` (given the password field is not excluded
from validation) and gracefully handle the possible `ValidationError`:
class AbstractBaseUser(models.Model):
def clean_password(self):
I think the idea is good, but the implementation you have here isn't
desirable. Maybe you could experiment with writing your own custom lookup
(https://docs.djangoproject.com/en/dev/howto/custom-lookups/) and see if it
fits into the framework that way. AFAIK, anything requiring .extra should
be
Does .filter(somefield__isnull=False) not work for what you're trying to do?
On Thursday, August 7, 2014 7:43:07 PM UTC-4, David Butler wrote:
>
> It would be nice if there was some database level optimization for getting
> objects that have related objects that exist.
>
> This is a slow filter:
It would be nice if there was some database level optimization for getting
objects that have related objects that exist.
This is a slow filter:
qs = [obj for obj in qs if qs.somefield_set.exists()]
Could be faster with something like this:
qs = qs.filter(somefield__exists=True)
Here is some (r
Aymeric Augustin
writes:
> GitHub doesn't require creating a new account, since anyone interested
> in contributing to Django should have a GitHub account already to
> submit pull requests.
This seems to be a common assumption, but it's not true — unless you
only count VCS contributions.
Are we
The custom user idea did seem like a good one to me. I don't think you'd
have to rewrite much (anything?) if the only change in your custom user is
to add a validate_password() function. If you'd like code up a proof of
concept we can take a look. I don't think front-end integration is
necessa
I actually think Colin's approach seems the best. Have a validate_password
function that can be overridden by a custom user model.
Tim, if I wanted to move this forward, what would be the next steps? I
looked at the trac ticket you mentioned and it looks much more in-depth
(full javascript / fr
> I'm sorry. Please accept my apologies and let me rephrase that without
> spam-fighting-induced frustration:
>
> "Other than reducing spam, Django as a project will benefit from this
> change be freeing core dev time and energy currently used to delete
> spam manually and tweak a feeble anti-spa
Hi, Aymeric,
Thank you for your e-mail. I sympathize with your frustration.
On Thu, Aug 7, 2014 at 3:27 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Indeed, but I’m dismissing this argument because GitHub is the
> pragmatic choice, whether you like it or not. Also, this re
Hi Andre,
On 7 août 2014, at 19:57, Andre Terra wrote:
> On Thu, Aug 7, 2014 at 3:46 AM, Aymeric Augustin
> wrote:
> On 7 août 2014, at 02:58, Andre Terra wrote:
>
> > Most importantly, how would Django as a project benefit from this
> > choice other than reducing minimal spam?
>
> Did you j
On Thu, Aug 7, 2014 at 3:46 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> On 7 août 2014, at 02:58, Andre Terra wrote:
>
> > Most importantly, how would Django as a project benefit from this
> > choice other than reducing minimal spam?
>
> Did you just ask “how would Django
+1 on GitHub OAuth. I've avoided filling or commenting on bugs because
setting up Yet Another Account was enough friction that I never did it.
On Thursday, August 7, 2014 2:21:06 AM UTC-5, Erik Romijn wrote:
>
>
> Using GitHub makes sense as it's very likely a new contributor already
> has a Gi
This mailing list is for the development of Django. Please direct questions
about how to use Django to the django-users mailing list.
Regards,
Michael Manfre
On Aug 7, 2014 12:06 PM, "Héctor Urbina" wrote:
> Hello,
>
> I'm developing a django project for my office, a small project management
> s
Hello,
I'm developing a django project for my office, a small project management
system. I'm doing some tries to incorporate a third party document
management system, namely mayan-edms, by making use of the same database,
so that users maintain theirs credentials. Is that good practice?.
Greet
On Thu, Aug 7, 2014, Schmitt, Christian wrote:
>Currently we already live in a world were everything gets connected. And
>that is really awful. One must consider that Github is definitely a target
>for intelligence agencies. And I don't mean the NSA only.
>Maybe I'm a little bit too paranoid but
Absolutely +1.
Clearly the most pragmatic choice.
On Thursday, 7 August 2014 13:43:45 UTC+1, Josh Smeaton wrote:
>
> I don't think "vendor lock in" is a good enough reason to avoid it. If
> GitHub were to go away, the move to a new code platform would be the
> greater problem. Also, nothing wil
I don't think "vendor lock in" is a good enough reason to avoid it. If
GitHub were to go away, the move to a new code platform would be the
greater problem. Also, nothing will be "lost". The old usernames will still
be there, they just won't be properly linked to your github username. I
don't t
I'm in favor of discontinuing older version of the docs. I recently fixed
the 1.3 documentation builder since there were several complaints, but no
one has complained about 1.2.
On Thursday, August 7, 2014 7:32:25 AM UTC-4, Areski Belaid wrote:
>
> Hi Folks,
>
> I wanted to open a discussion reg
Hi Folks,
I wanted to open a discussion regarding the following ticket
https://code.djangoproject.com/ticket/23042
To summarize briefly, you may notice that we can search doc for Django
version 1.2 (for example
https://docs.djangoproject.com/search/?q=forms&release=4) but the links in
the result
Thank you for working on this, Aymeric. I am definitely +1 on moving to
GitHub as sole authentication provider for trac.
We could argue about this forever. In the mean time the spam will pile
up, core developers will have to spend time deleting all of it, and
eventually we'd come to a plan which
26 matches
Mail list logo
