Re: Django directory design philosophy question

[Josh Smeaton]

I agree that creating a "project" subdirectory inside the code directory, 
that's usually named the same thing, can be quite confusing. I'd like to 
see some kind of improvement here, but I haven't done the research to see 
what makes sense.

The cognitive overhead of myproject/myproject, especially in the tutorial, 
can be especially confusing.

On Monday, 29 May 2017 03:15:28 UTC+10, Adam Johnson wrote:
>
> On (2), cookiecutter 's 
> behaviour is to create a new directory and it probably gets more traffic 
> than startproject.
>
> On 28 May 2017 at 15:04, Aymeric Augustin  > wrote:
>
>> Hello,
>>
>> Sorry Adam, I'm going to argue for the opposite position on both 
>> questions ;-)
>>
>> I don't think it's a good idea for add urls.py to startapp for three 
>> reasons:
>>
>> a. Even though Django's built-in boilerplates (startprojet and startapp) 
>> are fairly minimal, I've seen many projets with the dummy models, admin or 
>> tests module committed in a bunch of apps, creating noise. More files will 
>> make that problem worse. (I'll admit I'm not a huge fan of boilerplates in 
>> general.)
>>
>> b. Some developers like giving each app its own URL space. Others prefer 
>> keeping all URLs in a central location. Small projects can stick with the 
>> simplest thing that works and a central URLconf does the job up to a few 
>> dozen routes. Large projects, by the time they become large, have had the 
>> time to understand the tradeoffs and figure out what structure works best 
>> for them. I think startapp is most useful to people with little Django 
>> experience and splitting urls.py is a premature optimization for them.
>>
>> c. Unlike admin.py which is autodiscovered, urls.py won't do anything 
>> until it's referenced from the main URLconf. It would be misleading to add 
>> a module that doesn't work. I think the potential for confusion may 
>> outweigh the usefulness.
>>
>> Regarding the target directory of startproject, I'm in favor of the 
>> proposal. Here's the background:
>> https://code.djangoproject.com/ticket/17503
>> https://code.djangoproject.com/ticket/17042
>>
>> https://groups.google.com/forum/#!msg/django-developers/RLcKN_9zKYs/NsWYq3lVFU0J
>>
>> The default behavior keeps biting me, even though I no longer qualify 
>> myself as a Django newbie, and I'm not the only one who finds it 
>> surprising. Unix commands operate in the current directory unless told 
>> otherwise: example: `ls` vs. `ls path/to/directory`.
>>
>> Certainly files can be moved around after the fact — I do it every time — 
>> but this doesn't excuse the counter-intuitive API. I don't have the energy 
>> to argue for breaking backwards-compatibility here. But I'm strongly in 
>> favour of acknowledging this bug in the documentation (I haven't checked 
>> what it looks like currently).
>>
>> Best regards,
>>
>> -- 
>> Aymeric.
>>
>>
>> On 28 May 2017, at 15:13, Adam Johnson > 
>> wrote:
>>
>> 1. I don't see why not. Even DRF apps need urls.py files right?
>> 2. I think this is a minor issue and not worth worrying about, newbies 
>> should be able to move files and folders around appropriately on the 
>> filesystem. It's cleaner to put things in a subdirectory as it lowers the 
>> risk of overwriting existing files in the current directory.
>>
>> On 27 May 2017 at 02:51, 左小龙 > wrote:
>>
>>> 1. Why not create urls.py for every app when user run startapp command? 
>>> I think most app need urls.py except when using other framework like 
>>> django-rest-framework.
>>>
>>> 2. When we run `django-admin startproject mysite` will also create an 
>>> inner directory call mysite which is very confuse to newbie.  Some people 
>>> recommend use `django-admin startproject mysite .`(comma at the last) 
>>> instead. Should we also recommend this in the document?
>>>
>>> -- 
>>> 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-develop...@googlegroups.com .
>>> To post to this group, send email to django-d...@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/87e879d8-3674-4b96-973d-f1dd0b4a1148%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Adam
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send

Re: Exceptions in model._meta._property_names with some 3rd-pty libraries

[Adam Johnson]

I've made a pair of PR's, one for Django master and one for the 1.11
branch. On master, which is Python 3+, getattr_static is used 👍.

https://github.com/django/django/pull/8599
https://github.com/django/django/pull/8601

On 3 June 2017 at 01:02, Carl Meyer  wrote:

> Hi Zack,
>
> On 06/02/2017 02:02 PM, Zack Voase wrote:
> > Hi all,
> >
> > I'm encountering exceptions in a number of popular third-party Django
> > libraries when upgrading from 1.8 to 1.11. The code path is typically
> > `MyModel.objects.get_or_create(...)`, which causes
> > `model._meta._property_names` to be checked (to make sure we're not
> > querying/setting a property). The problem is, `_property_names` is
> > implemented as follows:
> >
> > |
> > # in django/db/models/options.py:
> > def_property_names(self):
> > returnfrozenset({
> >attr forattr in
> >dir(self.model)ifisinstance(getattr(self.model,attr),property)
> > })
> > |
> >
> > The problem is when a custom field installs a field descriptor on the
> > model class (during `contribute_to_class()`), with a `__get__()` method
> > like this:
> >
> > |
> > classSomeFieldDescriptor(object):
> > # ...
> > def__get__(self,instance,type=None):
> > ifinstance isNone:
> > raiseAttributeError("Can only be accessed via an instance.")
> > # ...
> > |
>
> I can see two things here that could be done better, one on Django side
> and one on third-party app side.
>
> 1) I've never seen a good reason for a descriptor to raise an
> AttributeError like that. Typically `return self` is a much more useful
> option for the "access on the class" scenario, if the descriptor can't
> provide useful behavior in that case, as it allows introspecting the
> class and finding the descriptor object.
>
> 2) On the Django side, I think we should switch to using
> `inspect.getattr_static`, to avoid any possibility of triggering
> side-effecty descriptor code of any kind. AttributeError is only the
> most visible problem here; there could be much subtler problems (e.g.
> performance issues) caused by e.g. accessing a descriptor that does a
> database query or something.
>
> Carl
>
> --
> 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/fbd639ad-6a51-7657-f647-753cbc3b6b90%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM1Y2a3N0yz4fBNpG9qCKxAcci5QN2Muf2B2eKyN6ebxjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.