I'm seeing an issue while running the Django test suite that I can't
explain.
If you add print(functions) before
from django.db.models.manager import Manager
in
https://github.com/django/django/blob/master/django/db/models/__init__.py#L15,
it gives name 'functions' is not defined as I would ex
https://code.djangoproject.com/ticket/27303#trac-add-comment
Hi all,
I am looking to drum up more feedback about this issue as I think an
important design decision needs to be made regarding filtering in the
admin. At the heart of this issue is the syntax simplicity of repeating
filter() claus
Just a small update on this; I've published a first usable (well, I hope)
version at https://github.com/machinalis/mypy-django/ . It's stubs only,
although I'm basing it on an annotated django fork at https://github.com/
dmoisset/django/tree/typing . I covered some high-visibility APIs only
(reques
Hey all,
Just want to announce recent changes in Django ORM Sugar library, which
might be useful in future Django query syntax enhancement (if ever happens).
1. Now it supports indexes and slices:
>>> Q.data.owner.other_pets[0].name='Fishy'
Q(data__owner__other_pets__0__name='Fishy')
>>> Q.tags[
> an option could be to target this for inclusion in Django 2.0 but make
the necessary fixes in Django 1.11 to allow this to exist as a third-party
app in the meantime.
Interesting idea, yup. I'm open minded at this stage.
Other hurdles to get past first, so let's see how we go before calling a
Hi Tom,
I'm not sure how the timing will work out, but an option could be to target
this for inclusion in Django 2.0 but make the necessary fixes in Django
1.11 to allow this to exist as a third-party app in the meantime. That
would allow it some time to get some real world usage and undergo mo
On Thursday, October 6, 2016 at 1:30:38 PM UTC+2, MMeent wrote:
>
> It would shadow the stdlib os.path, albeit not as a library, but as a
> function.
>
I do not think that os.path will usually interfer with url routing, so I
don't take that as an argument. In the end, path is perfectly suitab
Hi,
I may be late, but using 'path' as a name for this function is in my
opinion not recommended. It would shadow the stdlib os.path,
albeit not as a library, but as a function.
Using 'route' would be more interesting in my opinion, but shadowing
the Channels 'route' function (which has a very si
That is *awesome* :)
On Thu, Oct 6, 2016 at 9:39 AM, Tom Christie wrote:
> > wondered if it'd be possible here to get rid of the converter in the
> syntax at all, or have a default one if none is provided.
>
> Actually yes, I'd not noted in the proposal but you can also simply use eg.
>
> pa
> wondered if it'd be possible here to get rid of the converter in the
syntax at all, or have a default one if none is provided.
Actually yes, I'd not noted in the proposal but you can also simply use eg.
path('users//')
By default that'll give you the 'string' convertor. (Accepts any text
10 matches
Mail list logo
