undeclared variable appearing in django/db/models/__init__.py

[Tim Graham]

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 expect.

However, if you add the same print on the line after, it gives . A 
"functions" variable is magically defined!

Why does importing django.db.models.manager have this side effect? 
manager.py imports django.db.models.query which imports 
django.db.models.functions. If I move the functions import to an inner 
import in query.py as done in https://github.com/django/django/pull/7348, 
there's no more magic "functions" variable available in 
db/models/__init__.py.

Can you explain this? I checked all the "from *" imports in 
models/__init__.py to rule that out.

-- 
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 email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d8247cc5-e9e8-4725-9714-8a30b0ebc60c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Admin: Allow FilterSpecs to return Q-likes

[steve yeago]

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() clauses on a queryset breaks down pretty quickly when you are 
talking about traversing relations. The current FilterSpec API was a huge 
improvement, but shuttling filter() clauses between objects leaves a lot to 
be desired in terms of joining and leaves what I see as a critical 
inconsistency when it comes to adding several filters across relations (the 
way it is now, each filter gets its own JOIN and the result is a rather 
ambiguous OR-like clause).

There are also related issues at play, such as providing hooks for 
developers to apply filters that do more than just AND. While my ticket 
doesn't hope to address that comprehensively, I do think that some 
interesting options come into play when we stop authoring FilterSpecs to 
chain filters() and instead return Q-like objects which are then applied by 
the ModelAdmin or AdminSite.

-Steve

-- 
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 email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/48f5411d-bcf2-4af3-b863-0dd6484618a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PEP 484 type hinting in Django

[Daniel Moisset]

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
(request/responses, url routing, generic views), and some helper modules
that hose are built on (core.files, timezones, data structures).

I think it works, although while annotating the original code I struggled
with a few things:
 - Some classes (most notably MultiValueDict/QueryDict) use inheritance
then break a bit the original interface. In that case I changed the
implementation a bit to use delegation instead of inheritance, so it's more
than "just adding annotations" in places like this. It still passes tests,
and I haven't run benchmarks but GvR suggested that the delegation version
is probably faster.
 - There are some warnings thrown by the checker in the timezone module
that I'm not sure if they're because a bad specification or if those are
actual bugs (some methods like ReferenceLocalTimezone.utcoffset crash if
passed a "None" argument, but some examples seem to imply that a tzinfo
should accept it); there's no clear spec there. In the end I think this is
a good sign (this work will help identify some tricky/underspecified corner
cases in the API).
 - The type stubs (annotations in separate files) allow to tell some "white
lies" about the API (for example saying @classmethod instead of
@classonlymethod because the latter confuses the typechecker). Those make
it more usable, but something will have to be done with that if integrating
annotations on the code is desired.

In general, the APIs in django seem to be much more structured than other
python stuff (like the requests example Florian mentioned

Feel free to comment and follow-up details on the project issue tracker. I
posted this update here in case it helps in the future to follow the
discussion about adding inline annotations.

Best,
D.



On 20 September 2016 at 16:24, Daniel Moisset 
wrote:

> Hey Graham. mypy has a structure to support multiple python versions as
> you noticed (and allows it to select them from the command line), but
> there's no mechanism for selecting library version. For me, supporting "the
> latest stable version" is a reasonable goal now. Flagging that
> appriopriately may become a problem in the future, but only if this
> succeeds, so I'm focusing on making this useful right now :).
>
> I already mentioned a naive approach (use different branches in the
> typeshed repo to support different django versions), but I'm keen to hear
> better ideas!
>
> And of course, if we get this into the django codebase itself the problem
> goes away (you get the annotations when installing django).
>
> Best,
>D.
>
>
> On Sun, Sep 18, 2016 at 9:00 AM, Graham Wideman 
> wrote:
>
>> Just making note of the typeshed project https://github.com/python/type
>> shed, "Typeshed models function types for the Python standard library
>> and Python builtins, as well as third party packages."
>>
>> Pertaining to my earlier question about how pyi files should tell what
>> version of a library they pertain to:FWIW, typeshed uses directory branches
>> for different pyi files pertaining to different versions of Python, and
>> version-range conditionals within pyi files. These version-selective
>> devices pertain to version of Python. The interest in the discussion here
>> would relate to version of Django, of course, where it seems similar
>> measures might apply.
>>
>> --
>> 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
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/5bf15a4b-8360-4ee0-a985-01f42e7e27fd%
>> 40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Daniel F. Moisset - UK Country Manager
> www.machinalis.com
> Skype: @dmoisset
>



-- 
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset

-- 
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 email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To v

Re: Django ORM query syntax enhancement

[Alexey Zankevich]

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[0] == 'thoughts'
Q(tags__0='thoughts')
>>> Q.tags[0:2].contains(['thoughts']) 
Q(tags__0_2__contains=['thoughts'])


2. Previously, it was only possible to call defined method (like it is done 
for *is_not_null()* function) or registered with decorator. Now if you try 
to call unknown function of sugar Q, it will internally pass function name 
and append it as *__functionname *to lookup field:

>>> Q.user.username.contains('Rodriguez')
Q(user__username__contains='Rodriguez')


There is no such function "contains" anymore in sugar Q, however, it just 
adds *__contains* to lookup field and passes parameter to it.

3. It will pass a tuple to lookup if multiple arguments passed:

>>> Q.user.create_datetime.range(d1, d2)
Q(user__create_datetime__range=(d1, d2))


I think the library is at the final state now and isn't going to get new 
substantial features, but responses are highly appreciated.

Regards,
Alexey


On Sunday, August 16, 2015 at 4:18:26 PM UTC+3, Alexey Zankevich wrote:
>
> Hi all,
>
> This topic is related to the current ORM query syntax with underscores.
> There are lots of arguing related to it, anyway it has pros and cons.
>
> Let's take a concrete example of querying a model:
>
> >>> 
> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday)
>
>
> Pros:
>
> 1. The syntax is easy to understand
> 2. Can be extended with custom transforms and lookups
>
> However, there are several cons:
>
> 1. Long strings is hard to read, especially if we have fields with 
> underscores.
> It's really easy to make a mistake by missing one:
>
> >>> 
> GameSession.objects.filter(user_profile__last_login_date__gte=yesterday)
>
> Not easy to catch missing underscore between user and profile, is it? Even
> though, it's not easy to say whether it should be "user_profile" attribute 
> or
> user.profile foreign key.
>
> 2. Query strings can't be reused, thus the approach violates DRY principle.
> For example, we need to order results by last_login_date:
>
> >>> 
> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday) \
> .order_by('user__profile__last_login_date')
>
> We can't keep user__profile_login_date as a variable as in the first part 
> of the
> expression we use a keyword argument, meanwhile in the second part - just 
> a 
> string. And thus we just have to type query path twice.
>
> 3. Lookup names not natural to Python language and require to be 
> remembered or
> looked up in documentation. For example, "__gte" or "__lte" lookups tend 
> to be
> confused with "ge" and "le" due to similarity to methods "__ge__" and 
> "__le__".
>
> 4. Lookup keywords limited to a single argument only, very inconvenient 
> when
> necessary to filter objects by range.
>
> I was thinking a lot trying to solve those issues, keeping in mind Django
> approaches. Finally I came up with solution to extend Q objects with dot
> expression syntax:
>
> >>> GameSession.objecs.filter(Q.user.profile.last_login_date >= yesterday)
>
> Q is a factory instance for old-style Q objects. Accessing attribute by dot
> returns a child factory, calling factory will instantiate old-style Q 
> object.
>
> >>> Q
> 
>
> >>> Q.user.profile
> 
>
> >>> Q(user__name='Bob')
> 
>
> It overrides operators, so comparing factory with value returns a related Q
> object:
>
> >>> Q.user.name == 'Bob'
> 
>
> Factory has several helper functions for lookups which aren't related to 
> any
> Python operators directly:
>
> >>> Q.user.name.icontains('Bob')
> 
>
> And helper to get query path as string, which requred by order_by or
> select_related queryset methods: 
>
> >>> Q.user.profile.last_login_date.get_path()
> 'user__profile__last_login_date'
>
> You can check implementation and more examples here
> https://github.com/Nepherhotep/django-orm-sugar
>
> How it solves issues:
>
> #1. Dots hard to confuse with underscores
> #2. Query paths can be reused:
>
> >>> factory = Q.user.profile.last_login_date
> >>> query = GameSession.objects.filter(factory >= yesterday)
> >>> query = query.order_by(factory.get_path())
>
> #3. Not neccessary to remember most of lookup names and use comparison 
> operators
> instead.
> #4. Possible to use multiple keyword arguments:
>
> >>> Q.user.profile.last_login_date.in_range(from_date, to_date)
>  ('user__profile__last_login_date__gte', to_date))>
>
>
> This approach looked the best for me due to several reasons:
>
> 1. It's explicit - it doesn't do anything but generating appropriate Q 
> object. 
> The result of comparison can be saved as Q object variable.
>
> 2. It's short - variants with using model for that will look much longer, 
> when
> joining two or more filters:
>
> >>> GameSession.objects.user.pro

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

> 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 
judgement in that. Certainly worth having as an option.

> You can list me as the DEP shepherd if needed.

Grand. Let's run with that then, unless anyone else (from the core team) 
particularly wants to step up.

Thanks,

Tom

-- 
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 email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/15d5c484-bf05-4690-bf04-b15faad2bf6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tim Graham]

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 more 
rapid iteration before it's included in Django.

I thought of one thing for the implementation checklist: the 
simplify_regex() function in admindocs should probably be a method of the 
URLPattern class.
https://github.com/django/django/blob/979ea95608176e9c88678fd4d8a096c29654b5f3/django/contrib/admindocs/views.py#L432-L448

You can list me as the DEP shepherd if needed.

On Thursday, October 6, 2016 at 8:02:07 AM UTC-4, Florian Apolloner wrote:
>
>
>
> 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 suitable, 
> since we are actually matching on the path and might (?) allow other 
> functions like subdomain() in the future. It would really be interesting to 
> end up with something like:
>
> urlpatterns = [
>   subdomain('') + path('//')
> ] 
>
> or similar
> urlpatterns = [
>   subdomain(',
> path('//'),
> …more paths for that subdomaiin
>   )
> ]
>
> Cheers,
> Florian
>

-- 
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 email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d5af56e1-20ea-40b7-9b60-c29c92ce12e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Florian Apolloner]

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 suitable, 
since we are actually matching on the path and might (?) allow other 
functions like subdomain() in the future. It would really be interesting to 
end up with something like:

urlpatterns = [
  subdomain('') + path('//')
] 

or similar
urlpatterns = [
  subdomain(',
path('//'),
…more paths for that subdomaiin
  )
]

Cheers,
Florian

-- 
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 email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/91abf0bf-8e90-4f76-af27-f68ce8157964%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Matthias welp]

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 similar interface, but
different enough to confuse people) makes this also not really doable.

I think changing the behaviour of 'url' based on a boolean flag is nicer
in my opinion, as you'd then still have the resonation between the
'{% url %}' template tag and what you put in your urls.py (and no, I
really don't want to rename my files to paths.py). An alternative to
url with easy flags is, well, just calling it 'easy_url'.

TLDR: don't call it 'path', keep 'url' and add flags or call it  'easy_url'
(which may be an alias for url with true flag for easy mode).

-MMeent

-- 
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 email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEze2WjWox_Yh3adzV-5O6FWyaLMtCH-BMumDKeybsOG9fivmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Ola Sitarska]

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.
>
> path('users//')
>
> By default that'll give you the 'string' convertor. (Accepts any text
> without a slash.)
>
> I've updated the document to reflect this.
>
> --
> 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
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/e62c279f-4f0b-4cbc-9f98-
> 36650407835e%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFpnBuuEn0QW8MovSALns4X3LU85ryPsfDUbAHs2P89e-m8FOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

> 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 
without a slash.)

I've updated the document to reflect this.

-- 
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 email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e62c279f-4f0b-4cbc-9f98-36650407835e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.