Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

[Constantine Covtushenko]

Agree with Loïc on 100%.
And also it opens more options in the future.

Regards,

On Fri, Aug 19, 2016 at 9:58 PM, Loïc Bistuer 
wrote:

> I prefer enforcing .values(alias=F(’something’)), to me
> .values(alias=‘something’) reads as the equivalent of .values(alias=Value(‘
> something’)).
>
> --
> Loïc
>
> > On Aug 20, 2016, at 1:04 AM, Tim Graham  wrote:
> >
> > We now have support for expressions in values()/values_list() -- thanks
> Ian! With the new commit [0], aliases can be created like this:
> .values(alias=F('field'))
> >
> > Ian has offered an additional commit in the pull request [1] to allow
> .values(alias='field') (without the F() expression) to automatically wrap
> the string in an F() expression to create an alias. I'm not sure whether or
> not to accept that patch as I think I prefer the look of the explicit F()
> rather than magically treating strings as F() expressions. What do you
> think?
> >
> > [0] https://github.com/django/django/commit/
> 39f35d4b9de223b72c67bb1d12e65669b4e1355b
> > [1] https://github.com/django/django/pull/7088
> >
> > On Wednesday, November 25, 2015 at 7:24:22 PM UTC-5, Josh Smeaton wrote:
> > I would really like two things for values to support.
> >
> > 1. Aliases .values(alias='field');
> > 2. Expressions .values(alias=F('field'))
> >
> > I think these two features are absolute must haves, and the syntaxes
> above are already standard in other parts of the ORM.
> >
> > If someone can come up with a way to support nested relations while
> supporting the above syntax, then I'd be OK with that. But at the moment,
> I'm firmly in the "this is the responsibility of a serialiser" camp. I'm
> not convinced Django needs to support nested objects at all. Is this
> something you could implement with your own queryset method on a manager?
> Is this maybe something we could look at creating a new queryset method
> called .values_dict() ?
> >
> > If it weren't for backwards compatibility, I'd suggest that referencing
> the related object would automatically nest that object. That would
> differentiate between the id and the field values('related_id', 'related')
> -> '{"related_id": 1, "related": {"id": 1, ..}}'.
> >
> > If there's (rough) consensus on having nested objects, then we could
> allow something like: .values(..., ..., nested=('related',
> 'related__otherrelated')). If the value of nested is an iterable then
> assume we're nesting, otherwise nested is an alias for the field. I don't
> particularly like overloaded kwargs, but we're just guarding against
> someone wanting to alias as "nested" which we could call out in docs anyway.
> >
> > The more I think about this the more I think nesting and aliases within
> a nest should probably be done in a different queryset method. Or just
> handled by a serialiser. If you want more requests per second, then add
> some more backends.
> >
> > --
> > 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/00d4305c-175e-415c-b446-
> a53c7d15c00d%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/C7D98DF5-5F48-4E89-849F-D5E28A93D1DE%40gmail.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/CAK52boUjjLwDkxnF5mU_SCCypzPL5Yy5Byto8nEk3O3xoVUGDw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Constantine Covtushenko]

Hi Emil,

It is a very interesting idea.

+1 from me

On Mon, Sep 12, 2016 at 11:32 PM, Emil Stenström  wrote:

> Hi Djangonauts,
>
> I'm just back from my second year of teaching Django to absolute
> beginners. The course is a combination of HTML, CSS, Python, and Django,
> and after five days of coding they have a real live website that they can
> show to friends. It's always such a great experience to see the look in
> their eyes when they finally understand how they can tame Django to do what
> they want.
>
> There's one big thing that keeps tripping them up is urls.py. When
> specifying URL:s I get lots of questions about the regexes that they have
> to specify. First: there's a strange "r" in front of each line: r"regex".
> That means I will have to explain string escaping to them. Then there's the
> "^" and "$" signs, both which requires explaining regular expressions at
> length. Then there's [0-9]+ and finally there's the parenthesis around the
> regex. All in all, looking at URLs from a beginners perspective, they are a
> bunch of hieroglyphs, and very hard for beginners to grasp right away.
>
> I'm not suggesting that urls.py are changed for most users, I'm suggesting
> that *simple_url* method (name inspired by simple_tag) is added to 
> django.conf.urls
> that new users can use to get started quickly. This means that most
> beginners can postpone learning regexes a couple of months. The exact
> syntax that simple_url takes isn't important to me, as long it's a lot more
> beginner friendly than what we have today:
>
> https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
>
> Just to get the ideas flowing, here's a suggestion, inspired by rails
> (again, exact syntax isn't important to me, simplicity to beginners is, so
> feel free to suggest something else if you agree that this is an important
> issue):
>
> from django.conf.urls import simple_url
> from . import views
> urlpatterns = [
> simple_url('articles/2003/', views.special_case_2003),
> simple_url('articles/:year)/', views.year_archive),
> simple_url('articles/:year/:month/', views.month_archive),
> simple_url('articles/:year/:month/:day/', views.article_detail),
> ]
>
> All parameters would be passed to the view as keyword parameters with the 
> name given and as a string, and validation would happen there instead.
>
> I'm thinking there should be no settings with simple_url, and that any more 
> advanced use-case should switch to using url instead.
>
> Two questions:
>
> A) What do you think about the prospect of simplifying urls.py for beginners?
> B) What do you think about the specific suggestion to mimic Rails urls with a 
> simple_url tag?
>
> Thanks for reading!
>
> --
> 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/3d002c25-9d98-49b1-b84c-
> 55bc39c6a0f9%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/CAK52boUa_D-%2BVaf6VPgrA0YDAK4CWFbjFSWxV3RiVf-JEDXm1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: does anyone use models with underscores in the name?

[Constantine Covtushenko]

I am using such names in one of my project.
I found it very helpful for audit like fields: _cr_date and _cr_user

Regards,
Constantine C.

> On Oct 3, 2016, at 19:30, Tim Graham  wrote:
> 
> Ticket #27295 notes that the ORM doesn't work well with models that start 
> with an underscore (e.g. _UsersGroup). I didn't check if the same problem 
> exists with an underscore anywhere in the name, but I wanted to ask if anyone 
> has seen model names that use underscores? If not, my proposal is to add a 
> system check that prohibits an underscore in model names.
> 
> https://code.djangoproject.com/ticket/27295
> 
> -- 
> 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/44532a2c-69b7-45d7-8782-7b87eea09a20%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/E699F724-9436-41BC-A291-C238F9318039%40gmail.com.
For more options, visit https://groups.google.com/d/optout.