Signal on management command exception

[Yo-Yo Ma]

Request exceptions have always been easy to manage, because you can use 
middleware, and there is the built-in signal: 
https://docs.djangoproject.com/en/3.0/ref/signals/#got-request-exception

Problem:

However, if you want to send data to e.g., Sentry or perform some other 
action (logging, etc.) upon any Django management command error, there 
aren't built-in facilities to deal with this. Even writing your own command 
base class won't suffice, because that won't cover built-in or third-party 
commands.

Solution:

I propose a "got_command_exception" signal, which would operate similarly 
to "got_request_exception", except that it would pass in the management 
command class instance as the `sender`, and the provided args/kwargs. Being 
run inside of the exception handler would allow for logging.exception(...) 
and other exc_info needs.


Due to the fact that all commands run through the same call_command 
infrastructure, I think this is a good approach to solving the problem I 
described.

If a majority of folks think this is a good approach, I'll make a patch.

Thoughts?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f1950d49-c938-41a3-b93d-066ef387a54a%40googlegroups.com.

Re: Proposal: Multiple-Inheritance in Templates

[Yo-Yo Ma]

Hi izaias de oliveira elias, this is an existing thread in the Django 
Developers group.

What you want is to create a new thread in the Django Users group: 
https://groups.google.com/forum/#!forum/django-users

On Tuesday, February 18, 2020 at 5:51:22 PM UTC-5, izaias de oliveira elias 
wrote:
>
> I need help with this project, I can't configure the template pages to 
> display the information
> https://github.com/shadowruge/benim_pro.git
>
> Em ter., 18 de fev. de 2020 às 18:39, Yo-Yo Ma  > escreveu:
>
>> Hi Matthias,
>>
>> Thanks for the reply. My proposal is not about making it easier to use 
>> the most relevant base template. It's about making it easier to combine 
>> parts of different base templates to allow for generic type templates 
>> (create, list, etc.) to coexist with section templates (different apps that 
>> define menus, different models, etc.).
>>
>> So, for example:
>>
>> base.html defines basic structure and provides blocks
>>
>> product-base.html overrides some of base.html's blocks, pertaining to 
>> product-specific menus, etc.
>>
>> generic-list.html overrids some of base.html's blocks, pertaining to the 
>> content section, adding a list and pagination, etc.
>>
>> generic-edit.html overrids some of base.html's blocks, pertaining to the 
>> content section, adding a form for editing an object, etc.
>>
>> product-list.html extends BOTH product-base.html and generic-list.html, 
>> giving it both the block overrides for lists and for product menus, etc. It 
>> also may override some blocks that were defined in product-base.html and 
>> some that were defined in generic-list.html (such as the {% block 
>> list-item %} example in my OP).
>>
>> product-edit.html extends BOTH product-base.html and generic-edit.html, 
>> giving it both the block overrides for lists and for product menus, etc. It 
>> also may override some blocks that were defined in product-base.html and 
>> some that were defined in generic-edit.html
>>
>> On Tuesday, February 18, 2020 at 3:58:34 PM UTC-5, Matthias Kestenholz 
>> wrote:
>>>
>>> Hi,
>>>
>>> You could make the generic-list.html template extend a configurable base 
>>> template, e.g. "{% extends base_template|default:'base.html' %}", and add 
>>> context["base_template"] = "orders/base.html" in views belonging to the 
>>> orders app, and "products/base.html" in the products app.
>>>
>>> I often use this pattern exactly for the case when some app needs to add 
>>> its own submenu.
>>>
>>> Best,
>>> Matthias
>>>
>>>
>>>
>>> On Tue, Feb 18, 2020 at 9:44 PM Yo-Yo Ma  wrote:
>>>
>>>> Please help us all understand, then:
>>>>
>>>> How is it possible to inherit the blocks defined in both the 
>>>> orders/base.html template *AND* the generic-list.html template while 
>>>> inheriting *only* from the generic-list.html template?
>>>>
>>>> On Tuesday, February 18, 2020 at 3:32:12 PM UTC-5, matthew.pava wrote:
>>>>>
>>>>> I did read your post, and I did come to that conclusion. I may have 
>>>>> ultimately misunderstood, and I’ll certainly take the blame for my own 
>>>>> misunderstanding. The example you provided can be done without multiple 
>>>>> template inheritance. So far, my thoughts on the design concept is that 
>>>>> multiple template inheritance is unnecessary.
>>>>>
>>>>>  
>>>>>
>>>>> *From:* django-d...@googlegroups.com [mailto:
>>>>> django-d...@googlegroups.com] *On Behalf Of *Yo-Yo Ma
>>>>> *Sent:* Tuesday, February 18, 2020 2:25 PM
>>>>> *To:* Django developers (Contributions to Django itself)
>>>>> *Subject:* Re: Proposal: Multiple-Inheritance in Templates
>>>>>
>>>>>  
>>>>>
>>>>> @matthew.pava please read the entire OP again.
>>>>>
>>>>>  
>>>>>
>>>>> You can't have actually read the post and come to the conclusion that 
>>>>> inheriting from generic-list.html would solve the problem.
>>>>>
>>>>>  
>>>>>
>>>>> These kinds of "I didn't read it but it looks like you could just X" 
>>>>> replies are a big problem in mailing lists; they have the unintended 
>>>>> consequence of causing serious posts to like noo

Re: Proposal: Multiple-Inheritance in Templates

[Yo-Yo Ma]

Hi Matthias,

Thanks for the reply. My proposal is not about making it easier to use the 
most relevant base template. It's about making it easier to combine parts 
of different base templates to allow for generic type templates (create, 
list, etc.) to coexist with section templates (different apps that define 
menus, different models, etc.).

So, for example:

base.html defines basic structure and provides blocks

product-base.html overrides some of base.html's blocks, pertaining to 
product-specific menus, etc.

generic-list.html overrids some of base.html's blocks, pertaining to the 
content section, adding a list and pagination, etc.

generic-edit.html overrids some of base.html's blocks, pertaining to the 
content section, adding a form for editing an object, etc.

product-list.html extends BOTH product-base.html and generic-list.html, 
giving it both the block overrides for lists and for product menus, etc. It 
also may override some blocks that were defined in product-base.html and 
some that were defined in generic-list.html (such as the {% block list-item 
%} example in my OP).

product-edit.html extends BOTH product-base.html and generic-edit.html, 
giving it both the block overrides for lists and for product menus, etc. It 
also may override some blocks that were defined in product-base.html and 
some that were defined in generic-edit.html

On Tuesday, February 18, 2020 at 3:58:34 PM UTC-5, Matthias Kestenholz 
wrote:
>
> Hi,
>
> You could make the generic-list.html template extend a configurable base 
> template, e.g. "{% extends base_template|default:'base.html' %}", and add 
> context["base_template"] = "orders/base.html" in views belonging to the 
> orders app, and "products/base.html" in the products app.
>
> I often use this pattern exactly for the case when some app needs to add 
> its own submenu.
>
> Best,
> Matthias
>
>
>
> On Tue, Feb 18, 2020 at 9:44 PM Yo-Yo Ma  > wrote:
>
>> Please help us all understand, then:
>>
>> How is it possible to inherit the blocks defined in both the 
>> orders/base.html template *AND* the generic-list.html template while 
>> inheriting *only* from the generic-list.html template?
>>
>> On Tuesday, February 18, 2020 at 3:32:12 PM UTC-5, matthew.pava wrote:
>>>
>>> I did read your post, and I did come to that conclusion. I may have 
>>> ultimately misunderstood, and I’ll certainly take the blame for my own 
>>> misunderstanding. The example you provided can be done without multiple 
>>> template inheritance. So far, my thoughts on the design concept is that 
>>> multiple template inheritance is unnecessary.
>>>
>>>  
>>>
>>> *From:* django-d...@googlegroups.com [mailto:
>>> django-d...@googlegroups.com] *On Behalf Of *Yo-Yo Ma
>>> *Sent:* Tuesday, February 18, 2020 2:25 PM
>>> *To:* Django developers (Contributions to Django itself)
>>> *Subject:* Re: Proposal: Multiple-Inheritance in Templates
>>>
>>>  
>>>
>>> @matthew.pava please read the entire OP again.
>>>
>>>  
>>>
>>> You can't have actually read the post and come to the conclusion that 
>>> inheriting from generic-list.html would solve the problem.
>>>
>>>  
>>>
>>> These kinds of "I didn't read it but it looks like you could just X" 
>>> replies are a big problem in mailing lists; they have the unintended 
>>> consequence of causing serious posts to like noobie "help me" questions by 
>>> later passers by.
>>>
>>>  
>>>
>>> I'm a 12-13 year Python veteran (11 years full-time Django), not a noob, 
>>> and I think this feature could be a tremendous benefit to Django templates, 
>>> and I'd like some real thoughts on the design concept.
>>>
>>>
>>> On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
>>>
>>> In your example, you could just inherit from generic-list.html since it 
>>> already extends base.html. You would be repeating yourself in your current 
>>> example.
>>>
>>>  
>>>
>>> *orders/list.html*
>>>
>>>  
>>>
>>> {% extends 'generic-list.html' %}
>>>
>>>  
>>>
>>> {% block list-item %}
>>>
>>> Order # {{ order.id }} (total: {{ order.total }})
>>>
>>> {% endblock %}
>>>
>>>  
>>>
>>>  
>>>
>>> *From:* django-d...@googlegroups.com [mailto:
>>> django-d...@googlegroups.com] *On Behalf Of *Yo-Yo Ma
>>> *Sent:* Sunday, Feb

Re: Proposal: Multiple-Inheritance in Templates

[Yo-Yo Ma]

Hi Aymeric,

Thanks for the reply. I have to restate a point that argues against the 
assumption that the existing solution is "good enough": includes cannot 
override blocks, giving them only limited use. Notice in the 
products/list.html template I'm overriding the {% block list-item %} block; 
that can't be done if the list code is included. Conversely, if the menus 
are included, then they can't make use of block overrides. Both of these 
are actual cases I've experienced many times over the years. The former is 
illustrated in the example, and the latter exists when I have a subsection 
with a submenu that also includes a menu item for a detail page (making use 
of a block override that uses {{ block.super }} and then adds a new menu 
item).

The latter example above *can* be worked around by adding all sorts of 
little {% block before-submenu-close %}, { % block after-submenu %} type 
blocks in the base.html template, but it leads to messier and less 
maintainable templates with lots of empty blocks in base templates (very 
common pattern I've seen over the years).

One of the other reasons a feature like this is worth looking at is that 
it's a very take-it-or-leave it feature that wouldn't affect any existing 
code and, with the rules I stated toward the bottom of the OP, it would be 
very intuitive and leave little room for mistakes on the part of template 
coders.

P.S. (re: my reply to matthew.pava) following the rule you've laid out in 
your first sentence ("*Please assume good faith."*), my usage of elenchus, 
especially in the context of what appeared to be a deliberately obtuse 
response (the second response), should be assumed to be a perfectly valid 
response. Being direct is super necessary in asynchronous communication.

On Tuesday, February 18, 2020 at 3:59:09 PM UTC-5, Aymeric Augustin wrote:
>
> Hello Yo-Yo Ma,
>
> Please assume good faith. You've been around for 11 years, so you know the 
> way you address Matthew isn't how we behave on this mailing-list.
>
> I believe that the most common way to achieve what you want is to include 
> the "generic list" HTML with the {% include %} tag. This allows you to 
> share generic components across multiple templates.
>
> In theory, it's less powerful than the multiple inheritance mechanism 
> you've been proposing (because it does a separate render and includes the 
> result verbatim). In practice, I think it does the job.
>
> Best regards,
>
> -- 
> Aymeric.
>
>
>
> On 18 Feb 2020, at 21:44, Yo-Yo Ma > 
> wrote:
>
> Please help us all understand, then:
>
> How is it possible to inherit the blocks defined in both the 
> orders/base.html template *AND* the generic-list.html template while 
> inheriting *only* from the generic-list.html template?
>
> On Tuesday, February 18, 2020 at 3:32:12 PM UTC-5, matthew.pava wrote:
>>
>> I did read your post, and I did come to that conclusion. I may have 
>> ultimately misunderstood, and I’ll certainly take the blame for my own 
>> misunderstanding. The example you provided can be done without multiple 
>> template inheritance. So far, my thoughts on the design concept is that 
>> multiple template inheritance is unnecessary.
>>  
>>
>> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com] 
>> *On Behalf Of *Yo-Yo Ma
>> *Sent:* Tuesday, February 18, 2020 2:25 PM
>> *To:* Django developers (Contributions to Django itself)
>> *Subject:* Re: Proposal: Multiple-Inheritance in Templates
>>  
>>
>> @matthew.pava please read the entire OP again.
>>  
>>
>> You can't have actually read the post and come to the conclusion that 
>> inheriting from generic-list.html would solve the problem.
>>  
>>
>> These kinds of "I didn't read it but it looks like you could just X" 
>> replies are a big problem in mailing lists; they have the unintended 
>> consequence of causing serious posts to like noobie "help me" questions by 
>> later passers by.
>>  
>>
>> I'm a 12-13 year Python veteran (11 years full-time Django), not a noob, 
>> and I think this feature could be a tremendous benefit to Django templates, 
>> and I'd like some real thoughts on the design concept.
>>
>>
>> On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
>>
>> In your example, you could just inherit from generic-list.html since it 
>> already extends base.html. You would be repeating yourself in your current 
>> example.
>>  
>>
>> *orders/list.html*
>>  
>>
>> {% extends 'generic-list.html' %}
>>  
>>
>> {% block list-item %}
>>
>> Order # {{ order.id }} (total: {{ order.total

Re: Proposal: Multiple-Inheritance in Templates

[Yo-Yo Ma]

Please help us all understand, then:

How is it possible to inherit the blocks defined in both the 
orders/base.html template *AND* the generic-list.html template while 
inheriting *only* from the generic-list.html template?

On Tuesday, February 18, 2020 at 3:32:12 PM UTC-5, matthew.pava wrote:
>
> I did read your post, and I did come to that conclusion. I may have 
> ultimately misunderstood, and I’ll certainly take the blame for my own 
> misunderstanding. The example you provided can be done without multiple 
> template inheritance. So far, my thoughts on the design concept is that 
> multiple template inheritance is unnecessary.
>
>  
>
> *From:* django-d...@googlegroups.com  [mailto:
> django-d...@googlegroups.com ] *On Behalf Of *Yo-Yo Ma
> *Sent:* Tuesday, February 18, 2020 2:25 PM
> *To:* Django developers (Contributions to Django itself)
> *Subject:* Re: Proposal: Multiple-Inheritance in Templates
>
>  
>
> @matthew.pava please read the entire OP again.
>
>  
>
> You can't have actually read the post and come to the conclusion that 
> inheriting from generic-list.html would solve the problem.
>
>  
>
> These kinds of "I didn't read it but it looks like you could just X" 
> replies are a big problem in mailing lists; they have the unintended 
> consequence of causing serious posts to like noobie "help me" questions by 
> later passers by.
>
>  
>
> I'm a 12-13 year Python veteran (11 years full-time Django), not a noob, 
> and I think this feature could be a tremendous benefit to Django templates, 
> and I'd like some real thoughts on the design concept.
>
>
> On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
>
> In your example, you could just inherit from generic-list.html since it 
> already extends base.html. You would be repeating yourself in your current 
> example.
>
>  
>
> *orders/list.html*
>
>  
>
> {% extends 'generic-list.html' %}
>
>  
>
> {% block list-item %}
>
> Order # {{ order.id }} (total: {{ order.total }})
>
> {% endblock %}
>
>  
>
>  
>
> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com] 
> *On Behalf Of *Yo-Yo Ma
> *Sent:* Sunday, February 16, 2020 10:02 AM
> *To:* Django developers (Contributions to Django itself)
> *Subject:* Proposal: Multiple-Inheritance in Templates
>
>  
>
> Please read this in full - you will not be disappointed by the end.
>
>  
>
> We often talk about "multiple-inheritance" when referring to multiple 
> levels of {% extends ... %} and defining {% block ... %} many layers up in 
> base templates.
>
>  
>
> But, something that comes up as a useful idea in my mind on a regular 
> basis when working in Django templates is the ability to actually inherit 
> from multiple base templates.
>
>  
>
> The immediate reaction to this idea might be repulsion until you think 
> through the implications and weigh them against the benefits.
>
>  
>
> An example (simplified) use case speaks louder than explanation:
>
>  
>
> *base.html*
>
>  
>
> Some top-level menu
>
> {% block submenu %}{% endblock %}
> {% block content %}{% endblock %}
>
>  
>
> --
>
>  
>
> *orders/base.html*
>
>  
>
> {% extends 'base.html' %}
>
>  
>
> {% block submenu %}
>
> View all Orders
>
> Enter an Order
> {% endblock %}
>
>
> --
>
>  
>
> *products/base.html*
>
>  
>
> {% extends 'base.html' %}
>
>  
>
> {% block submenu %}
>
> View all Products
>
> Create a Product
> {% endblock %}
>
>
> --
>
>  
>
> So, we have a relatively common template setup, with some apps defining 
> their own base templates that extend the main base template, and then 
> defining their own submenus, etc.
>
>  
>
> At this point, we know there will be a product list page and an order list 
> page, but we also know that the product list template will extend the 
> product base template and the order list template will extend the order 
> base template; same goes for the product create and order create, both also 
> extending their respective apps' base templates.
>
>  
>
> This means duplication. The product list template will contain most of the 
> same list-related HTML, etc. as the order list, but the only way to avoid 
> that duplication will be to make a base list template and extend that 
> template from both the product list and order list.
>
>  
>
> *generic-list.html*
>
>  
>
> {% extends 'base.html' %}
>
>  
>
> {% block content %}
>
> 
>
> {% for object in pa

Re: Proposal: Multiple-Inheritance in Templates

[Yo-Yo Ma]

@matthew.pava please read the entire OP again.

You can't have actually read the post and come to the conclusion that 
inheriting from generic-list.html would solve the problem.

These kinds of "I didn't read it but it looks like you could just X" 
replies are a big problem in mailing lists; they have the unintended 
consequence of causing serious posts to like noobie "help me" questions by 
later passers by.

I'm a 12-13 year Python veteran (11 years full-time Django), not a noob, 
and I think this feature could be a tremendous benefit to Django templates, 
and I'd like some real thoughts on the design concept.

On Monday, February 17, 2020 at 10:55:44 AM UTC-5, matthew.pava wrote:
>
> In your example, you could just inherit from generic-list.html since it 
> already extends base.html. You would be repeating yourself in your current 
> example.
>
>  
>
> *orders/list.html*
>
>  
>
> {% extends 'generic-list.html' %}
>
>  
>
> {% block list-item %}
>
> Order # {{ order.id }} (total: {{ order.total }})
>
> {% endblock %}
>
>  
>
>  
>
> *From:* django-d...@googlegroups.com  [mailto:
> django-d...@googlegroups.com ] *On Behalf Of *Yo-Yo Ma
> *Sent:* Sunday, February 16, 2020 10:02 AM
> *To:* Django developers (Contributions to Django itself)
> *Subject:* Proposal: Multiple-Inheritance in Templates
>
>  
>
> Please read this in full - you will not be disappointed by the end.
>
>  
>
> We often talk about "multiple-inheritance" when referring to multiple 
> levels of {% extends ... %} and defining {% block ... %} many layers up in 
> base templates.
>
>  
>
> But, something that comes up as a useful idea in my mind on a regular 
> basis when working in Django templates is the ability to actually inherit 
> from multiple base templates.
>
>  
>
> The immediate reaction to this idea might be repulsion until you think 
> through the implications and weigh them against the benefits.
>
>  
>
> An example (simplified) use case speaks louder than explanation:
>
>  
>
> *base.html*
>
>  
>
> Some top-level menu
>
> {% block submenu %}{% endblock %}
> {% block content %}{% endblock %}
>
>  
>
> --
>
>  
>
> *orders/base.html*
>
>  
>
> {% extends 'base.html' %}
>
>  
>
> {% block submenu %}
>
> View all Orders
>
> Enter an Order
> {% endblock %}
>
>
> --
>
>  
>
> *products/base.html*
>
>  
>
> {% extends 'base.html' %}
>
>  
>
> {% block submenu %}
>
> View all Products
>
> Create a Product
> {% endblock %}
>
>
> --
>
>  
>
> So, we have a relatively common template setup, with some apps defining 
> their own base templates that extend the main base template, and then 
> defining their own submenus, etc.
>
>  
>
> At this point, we know there will be a product list page and an order list 
> page, but we also know that the product list template will extend the 
> product base template and the order list template will extend the order 
> base template; same goes for the product create and order create, both also 
> extending their respective apps' base templates.
>
>  
>
> This means duplication. The product list template will contain most of the 
> same list-related HTML, etc. as the order list, but the only way to avoid 
> that duplication will be to make a base list template and extend that 
> template from both the product list and order list.
>
>  
>
> *generic-list.html*
>
>  
>
> {% extends 'base.html' %}
>
>  
>
> {% block content %}
>
> 
>
> {% for object in page.object_list %}
>
> {% block list-item %}
>
> {{ object }}
>
> {% endblock %}
>
> {% endfor %}
>
> 
>
> {% endblock %}
>
>
> --
>
>
> But, in this case we lose the benefit of the product base and order base 
> (the submenus they define). Submenus are a super simplified example, but in 
> reality there may be *many* different things about a given app's base 
> template, making it a dilemma, or simply removing the practical ability to 
> subclass a "generic list" template altogether.
>
>  
>
> *Introducing multiple-inheritance:*
>
>  
>
> *orders/list.html*
>
>  
>
> {% extends 'generic-list.html 'orders/base.html' %}
>
>  
>
> {% block list-item %}
>
> Order # {{ order.id }} (total: {{ order.total }})
>
> {% endblock %}
>
>
> --
>
>  
>
>  
>
> *products/list.html*
>
>  
>
> {% extends 'generic-list.html 'products/base.html' %}
>
>  
>
> {% block list-it

Proposal: Multiple-Inheritance in Templates

[Yo-Yo Ma]

Please read this in full - you will not be disappointed by the end.

We often talk about "multiple-inheritance" when referring to multiple 
levels of {% extends ... %} and defining {% block ... %} many layers up in 
base templates.

But, something that comes up as a useful idea in my mind on a regular basis 
when working in Django templates is the ability to actually inherit from 
multiple base templates.

The immediate reaction to this idea might be repulsion until you think 
through the implications and weigh them against the benefits.

An example (simplified) use case speaks louder than explanation:

*base.html*

Some top-level menu
{% block submenu %}{% endblock %}
{% block content %}{% endblock %}

--

*orders/base.html*

{% extends 'base.html' %}

{% block submenu %}
View all Orders
Enter an Order
{% endblock %}

--

*products/base.html*

{% extends 'base.html' %}

{% block submenu %}
View all Products
Create a Product
{% endblock %}

--

So, we have a relatively common template setup, with some apps defining 
their own base templates that extend the main base template, and then 
defining their own submenus, etc.

At this point, we know there will be a product list page and an order list 
page, but we also know that the product list template will extend the 
product base template and the order list template will extend the order 
base template; same goes for the product create and order create, both also 
extending their respective apps' base templates.

This means duplication. The product list template will contain most of the 
same list-related HTML, etc. as the order list, but the only way to avoid 
that duplication will be to make a base list template and extend that 
template from both the product list and order list.

*generic-list.html*

{% extends 'base.html' %}

{% block content %}

{% for object in page.object_list %}
{% block list-item %}
{{ object }}
{% endblock %}
{% endfor %}

{% endblock %}

--

But, in this case we lose the benefit of the product base and order base 
(the submenus they define). Submenus are a super simplified example, but in 
reality there may be *many* different things about a given app's base 
template, making it a dilemma, or simply removing the practical ability to 
subclass a "generic list" template altogether.

*Introducing multiple-inheritance:*

*orders/list.html*

{% extends 'generic-list.html 'orders/base.html' %}

{% block list-item %}
Order # {{ order.id }} (total: {{ order.total }})
{% endblock %}

--


*products/list.html*

{% extends 'generic-list.html 'products/base.html' %}

{% block list-item %}
Product # {{ product.id }} (price: {{ product.price }})
{% endblock %}

--

The order of the templates would define the order of block definition and 
override precedence, from left to right (similar to Python class MRO).

You can also see, by the overriding of the "list-item" block, that there 
are other benefits of using extension like this, compared to e.g., defining 
a list template as an include, as a workaround.

Each template in the list would need to extend from template at the very 
right, meaning that each template left of the main template would 
essentially be a mixin. This would solve the very real problem of making 
generic bases for types of templates (list, detail, form, etc.) in your 
app, while still preserving the benefits of extension (block overrides) to 
all other facets of your final templates (vs having to use includes).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cc068a12-04ee-481a-81e1-919ed958c688%40googlegroups.com.

Re: Make `raw_id_fields` the default functionality in the admin

[Yo-Yo Ma]

One last note: M2M could also benefit from this, and could continue to look 
for `filter_horizontal` and not use a raw IDs field in those cases.

On Wednesday, October 17, 2018 at 11:59:43 AM UTC-4, Yo-Yo Ma wrote:
>
> I have yet to ever come across a situation where the default  
> field is more useful than the raw ID field, pertaining foreign key fields 
> in the admin.
>
> I have, however, personally witnessed a major publishing company bring 
> their production app servers to a halt (out of memory) due to Django 
> attempting to generate 2.5 million  tags for some dozen 
> admins that were all refreshing an admin changeview, wondering why it was 
> taking so long to load.
>
> Another thing worth noting is that when the  is most useful (when 
> there are very few records to select) also happens to be when the raw ID 
> field is most easily used (since the selection changelist only contains the 
> same very few records). IOW, the raw ID field's usefulness is universal, 
> working well with just a few records, and also working well (due to search 
> / sort) when there are many records.
>
> Nary a transition would be required, since the `raw_id_fields` could 
> simply be ignored.
>
> A new `select_fields = []` could be added for those who wish to easily  
> use the old functionality.
>
> Is there any reason why this couldn't or shouldn't be done?
>
>

-- 
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/e0262150-ec7e-487d-8fb1-b64f8df2e7a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Make `raw_id_fields` the default functionality in the admin

[Yo-Yo Ma]

I have yet to ever come across a situation where the default  field 
is more useful than the raw ID field, pertaining foreign key fields in the 
admin.

I have, however, personally witnessed a major publishing company bring 
their production app servers to a halt (out of memory) due to Django 
attempting to generate 2.5 million  tags for some dozen 
admins that were all refreshing an admin changeview, wondering why it was 
taking so long to load.

Another thing worth noting is that when the  is most useful (when 
there are very few records to select) also happens to be when the raw ID 
field is most easily used (since the selection changelist only contains the 
same very few records). IOW, the raw ID field's usefulness is universal, 
working well with just a few records, and also working well (due to search 
/ sort) when there are many records.

Nary a transition would be required, since the `raw_id_fields` could simply 
be ignored.

A new `select_fields = []` could be added for those who wish to easily  use 
the old functionality.

Is there any reason why this couldn't or shouldn't be done?

-- 
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/76e35c9d-b62f-498f-a382-6f12f74ebd98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update permissions on custom permissions migration

[Yo-Yo Ma]

FWIF, I wrote a custom data migration to update the Permission model.

My OP is attempting to suggest that migrations should handle this 
automatically.

On Friday, March 30, 2018 at 5:43:39 PM UTC-4, Yo-Yo Ma wrote:
>
> A model with a custom permission:
>
> class *Spam*(Model):
> class *Meta*:
> permissions = (('spam', 'Can eat spam'),)
>
> ...
>
> $ manage.py makemigrations
> $ manage.py migrate
>
> Now we have a custom permission in the User admin:
>
> foods | spam | Can eat spam
>
> Then update the permission's verbose name:
>
> class *Spam*(Model):
> class *Meta*:
> permissions = (('spam', 'Can cook AND eat spam'),)
>
> ...
>
> $ manage.py makemigrations
> $ manage.py migrate
>
> The permission's description change is not reflected in the admin:
>
> foods | spam | Can eat spam
>

-- 
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/cca05f9c-bacf-4ebb-8c19-a9ee2befdfb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Update permissions on custom permissions migration

[Yo-Yo Ma]

A model with a custom permission:

class *Spam*(Model):
class *Meta*:
permissions = (('spam', 'Can eat spam'),)

...

$ manage.py makemigrations
$ manage.py migrate

Now we have a custom permission in the User admin:

foods | spam | Can eat spam

Then update the permission's verbose name:

class *Spam*(Model):
class *Meta*:
permissions = (('spam', 'Can cook AND eat spam'),)

...

$ manage.py makemigrations
$ manage.py migrate

The permission's description change is not reflected in the admin:

foods | spam | Can eat spam

-- 
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/0765fda4-21d2-4511-afcd-2f514d058464%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: “Abusing BinaryField” warning about binary files in DB

[Yo-Yo Ma]

The nice thing about leaving the warning as stern as it is is that anybody who 
is absolutely sure that they need to store files this way isn’t going to stop 
because of the warning to begin with; while weaking the warning will most 
assuredly lead to “Django is Slow” posts by newcomers that didn’t know SELECT * 
would be slow when there’s 3-5MB of data per row.

-- 
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/ed131a9d-66e5-4398-822c-1ec33939615a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider reverting or adding guidelines on how to use class based views for security sensitive features

[Yo-Yo Ma]

> I found it much more difficult to follow to the point where I didn't feel it 
> was an improvement.

I think that patch was just an example of bad abstraction. For instance, 
_log_and_response was strange and confusingly named, and seemed to be there 
mostly for vanity, to mask the imperative nature of the top level of control.

When "properly" abstracted, class-based views, IMHO, are much simpler to reason 
about. And, despite the one extra indentation level of a method (vs a module 
"function"), CBV tend to offer flatter logic and better separation of concerns.

Somewhat ironically, I find better examples of functional style code in CBV 
than I do in view functions.

-- 
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/6acd4821-d51f-4bf4-9550-f3843eb28805%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

[Yo-Yo Ma]

I'm not a fan of adding more complexity, for a couple reasons:

1) you have the ['*'] option for local / office development
2) you can just add a record to /etc/hosts to point to the server and then use 
a name like e.g., local-office - just update the record to point to whatever IP 
you're using st the time

-- 
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/c0d5c95a-b978-434f-9ce7-0964cbedae31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: should blank POST data fallback to use model field defaults?

[Yo-Yo Ma]

@Tom

> I'd be surprised if they didn't end up with the model default. Personally 
I'd treat that as a regression, and revert to the older behavior.

I think Tim is saying the opposite, that Django 1.10 accidentally 
introduced "fields missing from POST are set to model defaults" behavior.

@Tim

> I could imagine an API call where it would be useful for the model to use 
the default if a user doesn't submit any data for that field

I think that the way to allow a key to be left out of POST entirely is 
either:

  1. Create a dict with defaults, then update it to the values in POST, 
using the result to instantiate the form
  2. Remove the field from the form (this could even be dynamic with 
modelform_factory based on keys missing from POST)

In a web page, # 1 is basically what's happening, but the updating is 
taking place in the UI.

For other cases (e.g., an API), a form method to get the same data used to 
populate the HTML form values would be very helpful:

>>> class Egg(Model):
>>>temperature = Charfield(max_length=255, default='over medium')
>>> EggForm = modelform_factory(Egg, exclude=())
>>> form = EggForm()
>>> form.initial  # This is only going to output the value given as 
`initial`
{}
>>> form.proposed_new_property  # <--- This lil guy right here
{'temperature': 'over medium'}

That would of course be helpful in creating an initial dict for my # 1 case 
above.

>>> data = form.proposed_new_property
>>> data.update(request.POST)
>>> form = EggForm(data)
>>> form.is_valid()
>>> form.save()

I realize the form is now being instantiated twice, but it's necessary 
because of kwargs like `initial`, and it's no different than the current 
load-form-in-GET --> validate-form-in-POST workflow.

Thoughts?

On Friday, August 12, 2016 at 10:41:21 AM UTC-4, Tom Christie wrote:
>
> For the case of fields that haven't been included in the form POST, I'd be 
> surprised if they didn't end up with the model default.
> Personally I'd treat that as a regression, and revert to the older 
> behavior.
> Agree that the checkbox special-casing isn't completely ideal, but I don't 
> see any way around that.
>
>   - 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/02537b83-c9ec-4ded-8b1f-6e03a5f0e21a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Yo-Yo Ma]

Correction:

*JKM starred (not started) - stupid, stupid iPhone.

-- 
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/cd8c2845-d1bd-479d-8203-a742584d5954%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Yo-Yo Ma]

To hopefully add to this conversation:

I'll start by saying I've enjoyed the contributions by Andrew over the years 
and believe he is a most excellent developer.

A couple months ago, around the same time that JKM started Andrew's repo (which 
is what got my attention) I decided to give Channels a try. I had a quick 
honeymoon with it because I had been working on a game and was using aiohttp. 
aiohttp provides support for websockets but doesn't manage relationships 
between them, which makes it hard to do anything without building a layer in 
between your app and the web. This layer ends up being somethings like 
Channels. Channels basically accomplished what I needed, which I was ecstatic 
about.

The honeymoon ended when I started using Channels to experiment on my local 
machine. The notion that I would now have to use a data store to run my app at 
all didn't feel right, even though I knew there would need to be data stored to 
maintain relationships between websockets, etc. I was disheartened when I 
learned Channels was potentially going to be merged into Django, because I 
finally got to that realization of the fact that there wasn't a "right way" to 
include baked-in web sockets behind a web server, only to find out that 
Channels was going to be called the "right way", forever (potentially).

So, let me ask a question: how many of the past 5 paid projects you worked on 
required websockets? For me, and for most of the people I know (not many), the 
answer is 0. I can think of a use case where it would have been nice (the "how 
many other users are viewing this page" feature, which we accomplished with 
slow Ajax polling), but I can think of nothing critical.

I ask that question because a good argument came up earlier, a comparison to 
NoSQL. NoSQL was in the same must-have craze, and then the tried and true 
standard in Django (Postgres) sort of answered that with huge gains in 
performance and scalability. Competition is great for this reason, but merging 
in competion is sort of like a business acquiring innovative. competitors as 
they emerge; it doesn't do much to further the company's true vision, because 
it's a defensive move.

I would recommend against merging Channels now, and potentially ever; not 
because it's not great code, but because A) it isn't necessary for the core, B) 
leaving it out of the core doesn't prevent it from being used, and C) it should 
be proven over time as an outside package (a different way of solving this 
could come by and proliferate while we have Channels in core, and then Django 
would be heading back down that hill towards the bloat (e.g., contrib) it 
worked so hard to remove over the years - not that Django was ever *truly* 
bloated).

What I would recommend is that we focus on fixing/abstracting/documenting 
things that make it hard to integrate something like Channels (e.g., things 
that Andrew has to monkey patch, etc.), because Channels *and* a hypothetical 
future websockets package could both take advantage of such an abstraction 
layer.

Political tirade follows:

Another thing I would never recommend is letting a grant destroy Django's 
ability to make a decision on its own. It absolutely disgusts me to think of 
Django becoming like Firefox, with "features" like Pocket and Hello that are 
driven by financial or political desires. Django should continue to look 
unemotionally at feature requests without regard for sunk cost fallacy (e.g., 
" already spent X time working on this...", etc.).

-- 
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/bcbbf085-a11c-4894-a599-aa7867899e71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Questions pertaining the dubious value and the origin of "common" passwords

[Yo-Yo Ma]

Today, I decided to check out Django's new password validation 
functionality (which is a great feature, btw).

I noticed there was a CommonPasswordValidator, which mentions "1000 common 
passwords"...

Part 1.

The first thing that came to mind was, how would one compile a list of 1000 
common passwords,  unless they maintained a rainbow table of millions of 
possible passwords AND had access to a large corpus of leaked password 
hashes (or databases of plain text passwords)?

Here's where it's worth noting the "This is Facebook, so I'll create a real 
password" vs "This is just some forum I'll probably never come back to, so 
I'll just use hunter2" phenomenon.

Now, given the second part of the question (large corpus of data), or even 
more so, the plain text case, where does intuition tell you that the 
majority of this kind of data would likely come from? Facebook / Twitter / 
online banks? Or, forums and defunct website?

I think with that, I've established the potentially dubious potential for 
the notion of "N most common passwords" being even remotely accurately 
established.

Part 2.

So, with the above thoughts in mind, I decided to have a look at the 
passwords Django is using and find their origin (did they come from a 
compiled list of "leaked" databases or something else?).

The list (plain text: 
https://gist.github.com/anonymous/59e9eb2935165d7b0fa9), I found after a 
quick search, is copied wholesale from a website called passwordrandom.com.

The website appears to be owned by one Dmitriy Koshevoy in Ukraine, but 
other than that I know nothing about it.

The list that Django uses is from this page specifically 
http://www.passwordrandom.com/most-popular-passwords - purporting to have 
the 10,000 most commonly used passwords (in order!), but says nothing about 
where they came from.

I figured, maybe this website is quite popular for password validation / 
generation, and Dmitriy has compiled... seems like a pretty bad idea to 
give them your password, but oh wel.

Except that passwordrandom.com has basically no traffic, according to 
SimilarWeb, Compete, and Alexa.

Side note: passwordrandom also features this strange and suspicious joke 
http://www.passwordrandom.com/password-database. Hopefully nobody has 
entered their real password there or anywhere else on the website, or used 
the site to generate a password, lest they lose it to the public domain, 
since the website doesn't even employ TLS.

Conclusion.

With all that, I'm now wondering how this list of "common" passwords made 
it into Django's code base. Perhaps, it should be removed, since, as I've 
established above, it provides no verifiable value or security. It could 
just as well be replaced with a configuration option (list setting or file 
path setting), to maintain backwards compatibility (and warm fuzzies for 
those who think *they* know the most common passwords?).

-- 
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/c0cfdd0d-98f1-49a4-a8d3-e50ad56b4847%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Odd behavior change in 1.8 with {% if %}, RelatedObjectDoesNotExist, and TEMPLATE_STRING_IF_INVALID

[Yo-Yo Ma]

I may be way off base here, but I actually feel like string_if_invalid should 
eventually be removed. It seems like a really bad idea to have a setting that 
can muck up an application in unexpected ways. Meanwhile, settings like 
DEBUG=True can't muck up your application, even if they're not secure to leave 
on in production.

I think the answer to whether it should be treated as a regression is the 
inverse of whether there are other places where template logic could 
unexpectedly change based on this setting. Fixing this one situation by 
checking for a specific error seems wrong, unless it's the only such case that 
could be reasonably expected to cause this problem. Based on the warning in the 
docs (about the admin), I take it that is not the case.

So without further ado, I vote "not a regression".

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4431f173-db1f-4b5d-9941-1ca1fb4697e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: --debug-sql option for management commands

[Yo-Yo Ma]

I found an N+1 query by inspecting the code of a management command that 
was running every 10 minutes, and it made me think, it would be good to 
have an option similar to 
https://django-debug-toolbar.readthedocs.org/en/1.0/commands.html#debugsqlshell 
for management commands in general.

If there interest in this, I'll look into what it would take to factor out 
the functionality of debugsqlshell into a --debug-sql (or whatever name) 
argument that could be passed to management commands in general.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c1a6ac31-ccd8-412a-ac9c-cd1f96f3a477%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improve adding data to forms programmatically

[Yo-Yo Ma]

To clarify, are you referring to a state where there are validation errors and 
the form is redisplayed, whereupon your change the value back to the original 
value?

Pertaining the problem you mentioned last (displaying the intermediary result): 
you are probably better off using the value from the form's instance for 
displaying outside of an input. 

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/daf37ea7-00ed-443f-b674-f9ac2f24acb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why leave explicit null=True when blank is True in IntegerField, DateField etc?

[Yo-Yo Ma]

Another reason you want the two to be separate is that you might allow a field 
to be blank in forms but then set the value to some context-specific value (vs 
a simple default=x) before saving.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cb880dcd-cd9e-4fca-9950-08948dd136c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Concerns with new "libraries" template functionality

[Yo-Yo Ma]

Hi Aymeric,

Pardon my misunderstand of the new functionality, and thanks for the 
explanation. The ability to use template libraries outside of installed apps 
alone is a great addition. Thanks for your hard work on 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eb6a15ba-483e-45eb-98a8-5ffb8ba125e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Concerns with new "libraries" template functionality

[Yo-Yo Ma]

CORRECTION:

| Due to #2, you can still run...

Should be:

| Due to #1, you can still run...

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0485d9ad-0736-4042-8aaa-f89a79d2df51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Concerns with new "libraries" template functionality

[Yo-Yo Ma]

I was reading through the 1.9 release notes when I came across the new 
OPTIONS['libraries'] feature.

Relevant links:

  - 
https://docs.djangoproject.com/en/dev/releases/1.9/#template-tag-modules-are-imported-when-templates-are-configured
  - https://docs.djangoproject.com/en/dev/releases/1.9/#templates
  - 
https://docs.djangoproject.com/en/dev/topics/templates/#module-django.template.backends.django

*tl;dr*

This new functionality trades convention for configuration, in a 
problematic way, for little gain.

If OPTIONS['libraries'] was made to mean: "only these libraries can be used 
in templates", there would be no problem. If it does in fact mean this, 
please disregard the following points and view this as a documentation 
update request.

*Long version:*

My concern is that we're now offering a way to explicitly register template 
libraries in OPTIONS['libraries'], which:

1) allows you to {% load some_key_from_that_dict %}
2) causes the modules to be loaded upon application start (and 
presumably `check`)

Unless I missed something, this functionality is lacking / concerning 
because of the following reasons:

1) 'libraries' will not be the *only* libraries allowed to be used in 
your templates, which *removes the "explicit"* nature (there isn't much 
explicit about a setting that is only additive)
2) Due to #2, you can still run into module load time errors via {% 
load something_not_registered %}
3) Environment-specific settings module (e.g., local_settings.py) can 
now cause unexpected runtime errors due to renaming tag libraries (vs 
simply using the module name)
4) 'libraries' will not be automatically built-in ('builtins' does that)

#4 is only mentioned because when you consider #1, #2 and #3 there is 
suddenly no additional value added by this "libraries" option, unless it 
also acted as add_to_builtins.

If the goal of this feature is to add application start time checks for 
template libraries, the right (and *consistent*) way to handle this would 
be to follow suit with admin.py, models.py, tests.py, etc., and add 
`templatetags` packages to application checks. If the goal of this feature 
is to provide a way to control the name used in {% load ... %} (very small 
value added, IMHO), then this should be the only thing it does, so that 
devs don't rely on the feature for something more.

If I'm understanding this new feature correctly, the *elevator pitch* 
becomes:

*You can now use OPTIONS['libraries'] to have Django check for import 
errors on *some* of your template libraries, the ones you remember to add 
there. The side effect is that {% load some_name_that_isnt_a_module_name %} 
will confuse devs. Also, your devs can continue to use {% load 
by_module_name_not_libraries_key %} and ignore your settings completely, or 
even worse, if they have local template settings due to local file system 
differences, they will have to remember to copy new libraries in each time 
they're added / changed.*

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2bfe1c14-c4a7-4fc9-a9f7-b77a4f7d35ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug: makemigrations caching prior migrations after deletion

[Yo-Yo Ma]

Sorry for the belated reply, Andrew and Curtis.

You're both right that the "bug" was just a case of makemigrations 
resolving dependency issues and my misunderstanding of that fact.

To test whether this was a bug or just makemigrations splitting up the 
migration, I had created a separate app with the exact same model as the 
supposedly offending app, and this time it didn't result in 2 migrations, 
so I thought I had empirically proven that this was some sort of pycache 
related bug... Afterword, I realized that this was because I had created 
the dependency's 0001 migration first, which of course then allowed 
makemigrations to simply add that 0001 migration as a dependency.


Michael


On Sunday, February 8, 2015 at 7:05:00 PM UTC-5, Andrew Godwin wrote:
>
> Indeed, Django can make many migrations for an initial set if it needs 
> them to de-circularise dependencies (e.g. two models with foreign keys 
> pointing at each other - it splits one of their FKs into a second 
> migration).
>
> Andrew
>
> On Sun, Feb 8, 2015 at 11:17 PM, Curtis Maloney <
> cur...@acommoncreative.com > wrote:
>
>> Could you provide details about what sort of field you added, please?
>>
>> I have seen cases where migrations will create two separate migrations 
>> for an initial.
>>
>> --
>> Curtis
>>
>> On 9 February 2015 at 10:11, Yo-Yo Ma <baxters...@gmail.com 
>> > wrote:
>>
>>> Using Python 3.4.2 and Django @stable/1.8.x (installed just moments 
>>> before this writing), I created a model with a "name" field, then created a 
>>> migration for it. Moments after, I added an "age" field to the model, 
>>> deleted the 0001_initial.py migration, deleted __pycache__ directories in 
>>> my entire project, deleted any *.py[cod] files in my project, then ran 
>>> makemigrations again (the goal being to create a fresh 0001 migration with 
>>> the latest fields again, since there is no SQLite3 database file (I 
>>> verified this as well)). When I do this, Django creates the same 0001 
>>> migration it did the first time, then creates a 0002 migration to add the 
>>> new field. Firstly, how is this even possible? Second, is this a known 
>>> issue in 1.8? I've never experienced this bug before, and it's always been 
>>> my M.O. on a new project to recreate a 0001 migration when I'm first 
>>> working on the models (to avoid having 30 migrations before the app is even 
>>> on a dev server).
>>>
>>> -- 
>>> 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 http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/bfb1f2cd-b2be-4a16-a882-ecc6695865c9%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/bfb1f2cd-b2be-4a16-a882-ecc6695865c9%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAG_XiSD%3DG4tR6fE4aF6xdgdEX6%3D0gRRCTW8%3DyiS8g9KBrBz7pA%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/CAG_XiSD%3DG4tR6fE4aF6xdgdEX6%3D0gRRCTW8%3DyiS8g9KBrBz7pA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/21d572d3-aa1d-4e16-99c1-894ae0cdc176%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Possible bug: makemigrations caching prior migrations after deletion

[Yo-Yo Ma]

Using Python 3.4.2 and Django @stable/1.8.x (installed just moments before 
this writing), I created a model with a "name" field, then created a 
migration for it. Moments after, I added an "age" field to the model, 
deleted the 0001_initial.py migration, deleted __pycache__ directories in 
my entire project, deleted any *.py[cod] files in my project, then ran 
makemigrations again (the goal being to create a fresh 0001 migration with 
the latest fields again, since there is no SQLite3 database file (I 
verified this as well)). When I do this, Django creates the same 0001 
migration it did the first time, then creates a 0002 migration to add the 
new field. Firstly, how is this even possible? Second, is this a known 
issue in 1.8? I've never experienced this bug before, and it's always been 
my M.O. on a new project to recreate a 0001 migration when I'm first 
working on the models (to avoid having 30 migrations before the app is even 
on a dev server).

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bfb1f2cd-b2be-4a16-a882-ecc6695865c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Feature request: Add SITE_NAME setting

[Yo-Yo Ma]

Along with the subject, I'd also propose abstracting the purposes that 
contrib.sites.requests.RequestSite serves out of the sites app, since the 
purpose it serves is more of a general one whose usefulness spans admin and 
auth, as well as third-party apps. The use of code from sites when sites is 
not installed demonstrates this point. So does checking whether an app is 
installed from inside that same app (is it an app or is it a lib?). If app 
A doesn't explicitly require app B, app A should properly function when I 
delete app B from my filesystem.

Adding a SITE_NAME setting, which would be used by the sites app in the 
absence of "django.contrib.sites" from INSTALLED_APPS would perfectly 
suffice, as a quick and simple solution.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/34a38304-818b-4780-a5f9-a72a40855a57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANNOUNCE] Django 1.7 released

[Yo-Yo Ma]

Epic, thanks so much!

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d48aa100-bc8e-4fea-8b20-78bed42c47ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please don't kill the ecosystem

[Yo-Yo Ma]

With as many new frameworks as there are out there, with the gains in 
popularity seen in Go and Node, my thinking is, move quickly, break (some very 
small) things, or die slowly. As was said, if your favorite lib doesn't work 
with 1.6 or 1.7, either use a prior version, or spend some time contributing 
the 10 minutes to 2 hours that most of these changes would take at most. You'll 
feel good about it. You'll feel less frustrated, and you'll understand, 
thereafter, what it means to be an active part of the community. I too used to 
be a rail bird. It gets you "exactly nowhere", in the words of Russell K.M., 
and it makes those who contribute feel unappreciated.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ec509e6c-c72c-43f8-8d2d-eebc87347958%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: manage.py migrate doesn't call createsuperuser

[Yo-Yo Ma]

Ah, I see. Thanks Shai. The docs @ 
https://docs.djangoproject.com/en/1.7/topics/auth/#installation are what I 
was referencing. I just created a pull request @ 
https://github.com/django/django/pull/3143 for this.

On Sunday, August 31, 2014 11:34:55 AM UTC-4, Shai Berger wrote:
>
> This was a deliberate change, I think it was discussed on the list but 
> maybe just IRC. The tutorial was changed to reflect it, if any 
> documentation still says otherwise it is a documentation bug.
>
> On 31 באוגוסט 2014 18:23:58 GMT+03:00, Yo-Yo Ma <baxters...@gmail.com 
> > wrote:
>>
>> (continued)
>>
>> I'm using Django 1.7c3, and the above is the first time running migrate 
>> (sqlite3 database deleted prior to running).
>>
>>
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5f47eef2-61b7-4fef-a9a1-c56ca7ca53ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: manage.py migrate doesn't call createsuperuser

[Yo-Yo Ma]

(continued)

I'm using Django 1.7c3, and the above is the first time running migrate 
(sqlite3 database deleted prior to running).

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a7e6711b-ffd9-4194-8da4-6edb05035b3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

manage.py migrate doesn't call createsuperuser

[Yo-Yo Ma]

If this is a known bug, I apologize, otherwise I'll create a ticket in Trac 
for it.

Details:

INSTALLED_APPS is

(
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'storages',
)

MIDDLEWARE_CLASSES is

(
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
)

Result is

$ python manage.py migrate
Operations to perform:
  Synchronize unmigrated apps: storages
  Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
  Creating tables...
  Installing custom SQL...
  Installing indexes...
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying sessions.0001_initial... OK

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fd96f3cc-07de-4ba8-b900-c23a48df66b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: integrating django-secure

[Yo-Yo Ma]

+1 on basically adding the functionality of checksecure to the default 
validation.

-1 to adding the middleware.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f5de6d21-70a1-43f8-b0cf-dc7a931a1564%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On django multi tenancy

[Yo-Yo Ma]

It's so easy to build an Account or Tenant or Site model of your own, do a 
little leg work, and you've got a multitenant app with all the custom 
functionality you need. Getting caught up in trying to use contrib apps and 
hacking things together turned out to be more work once you pass the basics.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ee498b83-536a-48f2-8173-c17fdd657162%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Working towards a simpler GCBV implementation?

[Yo-Yo Ma]

I'm excited about Django Vanilla Views. I think the GCBV implementation in 
Django is pretty good (I use GCBV got everything - leads to better 
extensibility), but a simpler version of the same functionality would be great. 
I'm NEVER certain of whether I'm using the right mixins and base class combos, 
or if I have them in the right inheritance order, or which share the same 
function, etc.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/504d0c8e-2359-4577-b484-5006d09ca770%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Circularly dependent fixtures fail with Postgres 9.2

[Yo-Yo Ma]

Aymeric,

Somebody (anonymous) said in the ticket that they had a problem in 1.6 and 
not in 1.5. I had a similar error on both, but there might be unrelated 
issues in both versions. Would that make it a release blocker? Sorry for 
not posting a reply on here sooner (the beta release today).

On Wednesday, June 26, 2013 2:27:03 AM UTC-4, Aymeric Augustin wrote:
>
> Thanks for taking the time to check. Based on Russell's message, I think 
> that's a bug, but I'm not sure why it happens. Could you file a ticket in 
> the tracker, so we don't forget about it? 
>
> Thank you, 
>
> -- 
> Aymeric. 
>
> On 26 juin 2013, at 02:43, Yo-Yo Ma <baxters...@gmail.com > 
> wrote: 
>
> > It does happen in 1.5, but the error is somehow slightly different (no 
> traceback in 1.5 to find the root cause). I have 2 fields on the order 
> model pointing to the address model. I included only the one in my above 
> example because it was consistently the culprit (likely due to being 
> defined above the other). In 1.5 the *other* field is consistently the 
> culprit: 
> > 
> > IntegrityError: Problem installing fixtures: insert or update on table 
> "orders_order" violates foreign key constraint 
> "shipping_rate_id_refs_id_84a732cf" 
> > DETAIL:  Key (shipping_rate_id)=(2) is not present in table 
> "shipping_shippingrate". 
> > 
> > The error on 1.6 again is: 
> > 
> > django.db.utils.IntegrityError: Problem installing fixture 
> '/opt/myproject/apps/orders/fixtures/test_data.json': Could not load 
> orders.Order(pk=1): insert or update on table "orders_order" violates 
> foreign key constraint "bill_address_id_refs_id_3a4d3fef" 
> > DETAIL:  Key (bill_address_id)=(1) is not present in table 
> "orders_orderaddress". 
>
>

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

Re: Circularly dependent fixtures fail with Postgres 9.2

[Yo-Yo Ma]

Hi Aymeric,

It does happen in 1.5, but the error is somehow slightly different (no 
traceback in 1.5 to find the root cause). I have 2 fields on the order 
model pointing to the address model. I included only the one in my above 
example because it was consistently the culprit (likely due to being 
defined above the other). In 1.5 the *other* field is consistently the 
culprit:

IntegrityError: Problem installing fixtures: insert or update on table 
"orders_order" violates foreign key constraint 
"shipping_rate_id_refs_id_84a732cf"
DETAIL:  Key (shipping_rate_id)=(2) is not present in table 
"shipping_shippingrate".

The error on 1.6 again is:

django.db.utils.IntegrityError: Problem installing fixture 
'/opt/myproject/apps/orders/fixtures/test_data.json': Could not load 
orders.Order(pk=1): insert or update on table "orders_order" violates 
foreign key constraint "bill_address_id_refs_id_3a4d3fef"
DETAIL:  Key (bill_address_id)=(1) is not present in table 
"orders_orderaddress".


On Tuesday, June 25, 2013 4:59:27 PM UTC-4, Aymeric Augustin wrote:
>
> Would you mind checking if the bug occurs in Django 1.5? If it doesn't, 
> it's a regression introduced by the new transaction management in Django 
> 1.6, and it's a release blocker.
>
> -- 
> Aymeric.
>
>
>  
> On 25 juin 2013, at 22:30, Yo-Yo Ma <baxters...@gmail.com > 
> wrote:
>
> I should actually note, this bug affects all versions of Postgres, and 
> presumably all other supported RDBMSs as well.
>
> On Sunday, June 23, 2013 7:35:45 PM UTC-4, Yo-Yo Ma wrote:
>>
>> Minor correction: I placed Atomic.__exit__ to verify - the transaction is 
>> commited every time *starting* on the second object (the third stack 
>> printed in the previous post) - it happens at 
>> https://github.com/django/django/blob/master/django/db/transaction.py#L288
>> .
>>
>>
>> On Sunday, June 23, 2013 7:24:40 PM UTC-4, Yo-Yo Ma wrote:
>>>
>>> Hi again Russell,
>>>
>>> I did a little digging. I'm not sure, but I may have uncovered the 
>>> problem. A transaction block (using `commit_on_success_unless_managed`) is 
>>> entered and exited during each fixture object loaded, due to the calls to 
>>> the aforementioned method that exist in various model methods (namely, 
>>> `save_base`, in this case). Because of this, the transaction is committed 
>>> immedately after each object is loaded, despite the attempt to wrap 
>>> `commit_on_success_unless_managed` around the context of the `loaddata` 
>>> call in the management command.
>>>
>>> The following are the results of my placing print statements (I know 
>>> that's old-school - pdb is just too time consuming) inside 
>>> `commit_on_success_unless_managed`. In each call, I added:
>>>
>>> print 'AUTOCOMMIT', connection.autocommit
>>> print 'IN ATOMIC BLOCK', connection.in_atomic_block
>>> for frame in inspect.stack():
>>> print frame[1], frame[3], frame[2]
>>>
>>> as well as a print after the stack of whether atomic() was returned or 
>>> _transaction_func() was returned (for easier reading):
>>>
>>>
>>> AUTOCOMMIT False
>>> IN ATOMIC BLOCK False
>>>
>>> django/db/transaction.py commit_on_success_unless_managed 492
>>> django/core/management/commands/loaddata.py handle 53
>>> django/core/management/base.py execute 283
>>> django/core/management/base.py run_from_argv 240
>>> django/core/management/__init__.py execute 392
>>> django/core/management/__init__.py execute_from_command_line 399
>>> manage.py  10
>>>
>>> RETURNING TRANSACTION FUNC
>>>
>>> ===
>>>
>>> AUTOCOMMIT False
>>> IN ATOMIC BLOCK False
>>>
>>> django/db/transaction.py commit_on_success_unless_managed 492
>>> django/db/models/base.py save_base 573
>>> django/core/serializers/base.py save 165
>>> django/core/management/commands/loaddata.py process_dir 225
>>> django/core/management/commands/loaddata.py load_label 169
>>> django/core/management/commands/loaddata.py loaddata 102
>>> django/core/management/commands/loaddata.py handle 54
>>> django/core/management/base.py execute 283
>>> django/core/management/base.py run_from_argv 240
>>> django/core/management/__init__.py execute 392
>>> django/core/management/__init__.py execute_from_command_line 399
>>> manage.py  10
>>>
>>> RETURNING TRANSACTION FUNC
>>&

Re: Circularly dependent fixtures fail with Postgres 9.2

[Yo-Yo Ma]

I should actually note, this bug affects all versions of Postgres, and 
presumably all other supported RDBMSs as well.

On Sunday, June 23, 2013 7:35:45 PM UTC-4, Yo-Yo Ma wrote:
>
> Minor correction: I placed Atomic.__exit__ to verify - the transaction is 
> commited every time *starting* on the second object (the third stack 
> printed in the previous post) - it happens at 
> https://github.com/django/django/blob/master/django/db/transaction.py#L288
> .
>
>
> On Sunday, June 23, 2013 7:24:40 PM UTC-4, Yo-Yo Ma wrote:
>>
>> Hi again Russell,
>>
>> I did a little digging. I'm not sure, but I may have uncovered the 
>> problem. A transaction block (using `commit_on_success_unless_managed`) is 
>> entered and exited during each fixture object loaded, due to the calls to 
>> the aforementioned method that exist in various model methods (namely, 
>> `save_base`, in this case). Because of this, the transaction is committed 
>> immedately after each object is loaded, despite the attempt to wrap 
>> `commit_on_success_unless_managed` around the context of the `loaddata` 
>> call in the management command.
>>
>> The following are the results of my placing print statements (I know 
>> that's old-school - pdb is just too time consuming) inside 
>> `commit_on_success_unless_managed`. In each call, I added:
>>
>> print 'AUTOCOMMIT', connection.autocommit
>> print 'IN ATOMIC BLOCK', connection.in_atomic_block
>> for frame in inspect.stack():
>> print frame[1], frame[3], frame[2]
>>
>> as well as a print after the stack of whether atomic() was returned or 
>> _transaction_func() was returned (for easier reading):
>>
>>
>> AUTOCOMMIT False
>> IN ATOMIC BLOCK False
>>
>> django/db/transaction.py commit_on_success_unless_managed 492
>> django/core/management/commands/loaddata.py handle 53
>> django/core/management/base.py execute 283
>> django/core/management/base.py run_from_argv 240
>> django/core/management/__init__.py execute 392
>> django/core/management/__init__.py execute_from_command_line 399
>> manage.py  10
>>
>> RETURNING TRANSACTION FUNC
>>
>> ===
>>
>> AUTOCOMMIT False
>> IN ATOMIC BLOCK False
>>
>> django/db/transaction.py commit_on_success_unless_managed 492
>> django/db/models/base.py save_base 573
>> django/core/serializers/base.py save 165
>> django/core/management/commands/loaddata.py process_dir 225
>> django/core/management/commands/loaddata.py load_label 169
>> django/core/management/commands/loaddata.py loaddata 102
>> django/core/management/commands/loaddata.py handle 54
>> django/core/management/base.py execute 283
>> django/core/management/base.py run_from_argv 240
>> django/core/management/__init__.py execute 392
>> django/core/management/__init__.py execute_from_command_line 399
>> manage.py  10
>>
>> RETURNING TRANSACTION FUNC
>>
>> ===
>>
>> SAVEPOINT False
>> AUTOCOMMIT True
>> IN ATOMIC BLOCK False
>>
>> |||
>> django/db/transaction.py commit_on_success_unless_managed 492
>> django/db/models/base.py save_base 573
>> django/core/serializers/base.py save 165
>> django/core/management/commands/loaddata.py process_dir 225
>> django/core/management/commands/loaddata.py load_label 169
>> django/core/management/commands/loaddata.py loaddata 102
>> django/core/management/commands/loaddata.py handle 54
>> django/core/management/base.py execute 283
>> django/core/management/base.py run_from_argv 240
>> django/core/management/__init__.py execute 392
>> django/core/management/__init__.py execute_from_command_line 399
>> manage.py  10
>>
>> RETURNING ATOMIC
>>
>> ===
>>
>>
>> The remaining calls were exactly like call 3 (including "IN ATOMIC BLOCK 
>> False", despite the 3rd call having returned `atomic()`). My prima facie 
>> opinion is that `with atomic()` is needed in `loaddata`, instead of `with 
>> commit_on_success_unless_managed`, since the latter acts funky when nested 
>> calls occur (as see in save_base in the stacks printed above). However, the 
>> issue might be something that needs to be resolved in the 
>> transitioning-to-atomic code. I don't fully understand all of this yet, but 
>> it's a start.
>>
>>
>> On Friday, June 21, 2013 4:34:14 PM UTC-4, Yo-Yo Ma 

Re: Circularly dependent fixtures fail with Postgres 9.2

[Yo-Yo Ma]

Minor correction: I placed Atomic.__exit__ to verify - the transaction is 
commited every time *starting* on the second object (the third stack 
printed in the previous post) - it happens at 
https://github.com/django/django/blob/master/django/db/transaction.py#L288.


On Sunday, June 23, 2013 7:24:40 PM UTC-4, Yo-Yo Ma wrote:
>
> Hi again Russell,
>
> I did a little digging. I'm not sure, but I may have uncovered the 
> problem. A transaction block (using `commit_on_success_unless_managed`) is 
> entered and exited during each fixture object loaded, due to the calls to 
> the aforementioned method that exist in various model methods (namely, 
> `save_base`, in this case). Because of this, the transaction is committed 
> immedately after each object is loaded, despite the attempt to wrap 
> `commit_on_success_unless_managed` around the context of the `loaddata` 
> call in the management command.
>
> The following are the results of my placing print statements (I know 
> that's old-school - pdb is just too time consuming) inside 
> `commit_on_success_unless_managed`. In each call, I added:
>
> print 'AUTOCOMMIT', connection.autocommit
> print 'IN ATOMIC BLOCK', connection.in_atomic_block
> for frame in inspect.stack():
> print frame[1], frame[3], frame[2]
>
> as well as a print after the stack of whether atomic() was returned or 
> _transaction_func() was returned (for easier reading):
>
>
> AUTOCOMMIT False
> IN ATOMIC BLOCK False
>
> django/db/transaction.py commit_on_success_unless_managed 492
> django/core/management/commands/loaddata.py handle 53
> django/core/management/base.py execute 283
> django/core/management/base.py run_from_argv 240
> django/core/management/__init__.py execute 392
> django/core/management/__init__.py execute_from_command_line 399
> manage.py  10
>
> RETURNING TRANSACTION FUNC
>
> ===
>
> AUTOCOMMIT False
> IN ATOMIC BLOCK False
>
> django/db/transaction.py commit_on_success_unless_managed 492
> django/db/models/base.py save_base 573
> django/core/serializers/base.py save 165
> django/core/management/commands/loaddata.py process_dir 225
> django/core/management/commands/loaddata.py load_label 169
> django/core/management/commands/loaddata.py loaddata 102
> django/core/management/commands/loaddata.py handle 54
> django/core/management/base.py execute 283
> django/core/management/base.py run_from_argv 240
> django/core/management/__init__.py execute 392
> django/core/management/__init__.py execute_from_command_line 399
> manage.py  10
>
> RETURNING TRANSACTION FUNC
>
> ===
>
> SAVEPOINT False
> AUTOCOMMIT True
> IN ATOMIC BLOCK False
>
> |||
> django/db/transaction.py commit_on_success_unless_managed 492
> django/db/models/base.py save_base 573
> django/core/serializers/base.py save 165
> django/core/management/commands/loaddata.py process_dir 225
> django/core/management/commands/loaddata.py load_label 169
> django/core/management/commands/loaddata.py loaddata 102
> django/core/management/commands/loaddata.py handle 54
> django/core/management/base.py execute 283
> django/core/management/base.py run_from_argv 240
> django/core/management/__init__.py execute 392
> django/core/management/__init__.py execute_from_command_line 399
> manage.py  10
>
> RETURNING ATOMIC
>
> ===
>
>
> The remaining calls were exactly like call 3 (including "IN ATOMIC BLOCK 
> False", despite the 3rd call having returned `atomic()`). My prima facie 
> opinion is that `with atomic()` is needed in `loaddata`, instead of `with 
> commit_on_success_unless_managed`, since the latter acts funky when nested 
> calls occur (as see in save_base in the stacks printed above). However, the 
> issue might be something that needs to be resolved in the 
> transitioning-to-atomic code. I don't fully understand all of this yet, but 
> it's a start.
>
>
> On Friday, June 21, 2013 4:34:14 PM UTC-4, Yo-Yo Ma wrote:
>>
>> Pardon one typo: I meant `python manage.py loaddata test_data` in my 
>> previous post.
>>
>> On Friday, June 21, 2013 4:32:33 PM UTC-4, Yo-Yo Ma wrote:
>>>
>>> Hi Russel,
>>>
>>> Thanks for taking the time to explain that. I tried that same day to 
>>> reproduce the issue in a testing env with the simplified models I typed 
>>> above, but my hosting provider had some erroneous networking nonsense that 
>>> ruined my test after I spent a couple hours setting everything up. I 
>>&

Re: Circularly dependent fixtures fail with Postgres 9.2

[Yo-Yo Ma]

Hi again Russell,

I did a little digging. I'm not sure, but I may have uncovered the problem. 
A transaction block (using `commit_on_success_unless_managed`) is entered 
and exited during each fixture object loaded, due to the calls to the 
aforementioned method that exist in various model methods (namely, 
`save_base`, in this case). Because of this, the transaction is committed 
immedately after each object is loaded, despite the attempt to wrap 
`commit_on_success_unless_managed` around the context of the `loaddata` 
call in the management command.

The following are the results of my placing print statements (I know that's 
old-school - pdb is just too time consuming) inside 
`commit_on_success_unless_managed`. In each call, I added:

print 'AUTOCOMMIT', connection.autocommit
print 'IN ATOMIC BLOCK', connection.in_atomic_block
for frame in inspect.stack():
print frame[1], frame[3], frame[2]

as well as a print after the stack of whether atomic() was returned or 
_transaction_func() was returned (for easier reading):


AUTOCOMMIT False
IN ATOMIC BLOCK False

django/db/transaction.py commit_on_success_unless_managed 492
django/core/management/commands/loaddata.py handle 53
django/core/management/base.py execute 283
django/core/management/base.py run_from_argv 240
django/core/management/__init__.py execute 392
django/core/management/__init__.py execute_from_command_line 399
manage.py  10

RETURNING TRANSACTION FUNC

===

AUTOCOMMIT False
IN ATOMIC BLOCK False

django/db/transaction.py commit_on_success_unless_managed 492
django/db/models/base.py save_base 573
django/core/serializers/base.py save 165
django/core/management/commands/loaddata.py process_dir 225
django/core/management/commands/loaddata.py load_label 169
django/core/management/commands/loaddata.py loaddata 102
django/core/management/commands/loaddata.py handle 54
django/core/management/base.py execute 283
django/core/management/base.py run_from_argv 240
django/core/management/__init__.py execute 392
django/core/management/__init__.py execute_from_command_line 399
manage.py  10

RETURNING TRANSACTION FUNC

===

SAVEPOINT False
AUTOCOMMIT True
IN ATOMIC BLOCK False

|||
django/db/transaction.py commit_on_success_unless_managed 492
django/db/models/base.py save_base 573
django/core/serializers/base.py save 165
django/core/management/commands/loaddata.py process_dir 225
django/core/management/commands/loaddata.py load_label 169
django/core/management/commands/loaddata.py loaddata 102
django/core/management/commands/loaddata.py handle 54
django/core/management/base.py execute 283
django/core/management/base.py run_from_argv 240
django/core/management/__init__.py execute 392
django/core/management/__init__.py execute_from_command_line 399
manage.py  10

RETURNING ATOMIC

===


The remaining calls were exactly like call 3 (including "IN ATOMIC BLOCK 
False", despite the 3rd call having returned `atomic()`). My prima facie 
opinion is that `with atomic()` is needed in `loaddata`, instead of `with 
commit_on_success_unless_managed`, since the latter acts funky when nested 
calls occur (as see in save_base in the stacks printed above). However, the 
issue might be something that needs to be resolved in the 
transitioning-to-atomic code. I don't fully understand all of this yet, but 
it's a start.


On Friday, June 21, 2013 4:34:14 PM UTC-4, Yo-Yo Ma wrote:
>
> Pardon one typo: I meant `python manage.py loaddata test_data` in my 
> previous post.
>
> On Friday, June 21, 2013 4:32:33 PM UTC-4, Yo-Yo Ma wrote:
>>
>> Hi Russel,
>>
>> Thanks for taking the time to explain that. I tried that same day to 
>> reproduce the issue in a testing env with the simplified models I typed 
>> above, but my hosting provider had some erroneous networking nonsense that 
>> ruined my test after I spent a couple hours setting everything up. I 
>> figured I'm come back to it... and here I am.
>>
>> I didn't set up an entire test env and test app this time, just made a 
>> fresh database and ran my apps fixtures on it, but I did test my app again, 
>> using a fresh database without any data. The models and fixtures for which 
>> are as follows (minus most of the decimals, chars, and other non-FK-type 
>> fields, none of which should be related to this problem):
>>
>>
>> # account/models.py
>> class Account(models.Model):
>> name = models.CharField(_(u'name'), max_length=255)
>>
>>
>> # orders/models.py
>> class Order(models.Model):
>> account = models.ForeignKey('account.Account', 
>> verbose_name=_(u'account'))
>> number = models.Integer

Re: Circularly dependent fixtures fail with Postgres 9.2

[Yo-Yo Ma]

Pardon one typo: I meant `python manage.py loaddata test_data` in my 
previous post.

On Friday, June 21, 2013 4:32:33 PM UTC-4, Yo-Yo Ma wrote:
>
> Hi Russel,
>
> Thanks for taking the time to explain that. I tried that same day to 
> reproduce the issue in a testing env with the simplified models I typed 
> above, but my hosting provider had some erroneous networking nonsense that 
> ruined my test after I spent a couple hours setting everything up. I 
> figured I'm come back to it... and here I am.
>
> I didn't set up an entire test env and test app this time, just made a 
> fresh database and ran my apps fixtures on it, but I did test my app again, 
> using a fresh database without any data. The models and fixtures for which 
> are as follows (minus most of the decimals, chars, and other non-FK-type 
> fields, none of which should be related to this problem):
>
>
> # account/models.py
> class Account(models.Model):
> name = models.CharField(_(u'name'), max_length=255)
>
>
> # orders/models.py
> class Order(models.Model):
> account = models.ForeignKey('account.Account', 
> verbose_name=_(u'account'))
> number = models.IntegerField(_(u'number'))
> bill_address = models.OneToOneField(
> 'orders.OrderAddress',
> null=True,
> on_delete=models.SET_NULL,
> related_name='bill_address_order',
> verbose_name=_(u'bill to address')
> )
>
> class OrderAddress(models.Model):
> account = models.ForeignKey('account.Account', 
> verbose_name=_(u'account'))
> order = models.ForeignKey('orders.Order', verbose_name=_(u'order'))
> country = models.CharField(_(u'country'), max_length=2)
>
>
> // orders/fixtures/test_data.json
> [
> {
> "model": "orders.order",
> "pk": 1,
> "fields": {
> "account": 1,
> "number": 1,
> "bill_address": 1
> }
> },
> {
> "model": "orders.orderaddress",
> "pk": 1,
> "fields": {
> "account": 1,
> "order": 1,
> "country": "US",
> }
> }
> ]
>
>
> (an Account with the primary key of 1 already exists at the time of 
> ``loaddata``)
>
>
> The error I get with `python manage.py loaddata test_data orders` is:
>
> django.db.utils.IntegrityError: Problem installing fixture 
> '/opt/myproject/apps/orders/fixtures/test_data.json': Could not load 
> orders.Order(pk=1): insert or update on table "orders_order" violates 
> foreign key constraint "bill_address_id_refs_id_3a4d3fef"
> DETAIL:  Key (bill_address_id)=(1) is not present in table 
> "orders_orderaddress".
>
>
> The above fixtures load locally, and they load during test running (with 
> Postgres) a number of times, but for some reason I get that error when 
> using `manage.py loaddata ...`.
>
>
> On Sunday, June 16, 2013 7:40:02 PM UTC-4, Russell Keith-Magee wrote:
>>
>>
>> Circular dependencies *shouldn't* be a problem on PostgreSQL because all 
>> constraints are set DEFERABLE INITIALLY DEFERRED; that means no constrain 
>> checks should be performed are performed until the transaction boundary, so 
>> all circular references shouldn't be a problem. 
>>
>> Ticket #3615 exists because MySQL's implementation of DEFERABLE INITIALLY 
>> DEFERRED under InnoDB is, to use the technical term, "Broken". It's 
>> unrelated to any problem you may have found in PostgreSQL, because 
>> PostgreSQL gets the underlying behaviour right. 
>>
>> Beyond that, we need a specific test case to take this any further. As it 
>> stands, I'm not aware of any problems loading fixtures into PostgreSQL. If 
>> you are able to construct and provide a set of models (which you have done) 
>> and simple fixture (which you haven't) that fails reliably, we have a new 
>> bug on our hands, and you should open a ticket with all the details you can 
>> provide. Confirming whether this is a problem with the alpha, or an ongoing 
>> problem would also be helpful.
>>
>> Yours,
>> Russ Magee %-)
>>
>> On Mon, Jun 17, 2013 at 6:22 AM, Yo-Yo Ma <baxters...@gmail.com> wrote:
>>
>>> There doesn't appear to be a way to load fixtures from JSON (using 
>>> Postgres - works fine in sqlite3) for the following models:
>>>
>>>
>>> class Collection(models.Model):
>>> main_thing = models.OneToOneField(
>>> 'things.Thin

Re: Circularly dependent fixtures fail with Postgres 9.2

[Yo-Yo Ma]

Hi Russel,

Thanks for taking the time to explain that. I tried that same day to 
reproduce the issue in a testing env with the simplified models I typed 
above, but my hosting provider had some erroneous networking nonsense that 
ruined my test after I spent a couple hours setting everything up. I 
figured I'm come back to it... and here I am.

I didn't set up an entire test env and test app this time, just made a 
fresh database and ran my apps fixtures on it, but I did test my app again, 
using a fresh database without any data. The models and fixtures for which 
are as follows (minus most of the decimals, chars, and other non-FK-type 
fields, none of which should be related to this problem):


# account/models.py
class Account(models.Model):
name = models.CharField(_(u'name'), max_length=255)


# orders/models.py
class Order(models.Model):
account = models.ForeignKey('account.Account', 
verbose_name=_(u'account'))
number = models.IntegerField(_(u'number'))
bill_address = models.OneToOneField(
'orders.OrderAddress',
null=True,
on_delete=models.SET_NULL,
related_name='bill_address_order',
verbose_name=_(u'bill to address')
)

class OrderAddress(models.Model):
account = models.ForeignKey('account.Account', 
verbose_name=_(u'account'))
order = models.ForeignKey('orders.Order', verbose_name=_(u'order'))
country = models.CharField(_(u'country'), max_length=2)


// orders/fixtures/test_data.json
[
{
"model": "orders.order",
"pk": 1,
"fields": {
"account": 1,
"number": 1,
"bill_address": 1
}
},
{
"model": "orders.orderaddress",
"pk": 1,
"fields": {
"account": 1,
"order": 1,
"country": "US",
}
}
]


(an Account with the primary key of 1 already exists at the time of 
``loaddata``)


The error I get with `python manage.py loaddata test_data orders` is:

django.db.utils.IntegrityError: Problem installing fixture 
'/opt/myproject/apps/orders/fixtures/test_data.json': Could not load 
orders.Order(pk=1): insert or update on table "orders_order" violates 
foreign key constraint "bill_address_id_refs_id_3a4d3fef"
DETAIL:  Key (bill_address_id)=(1) is not present in table 
"orders_orderaddress".


The above fixtures load locally, and they load during test running (with 
Postgres) a number of times, but for some reason I get that error when 
using `manage.py loaddata ...`.


On Sunday, June 16, 2013 7:40:02 PM UTC-4, Russell Keith-Magee wrote:
>
>
> Circular dependencies *shouldn't* be a problem on PostgreSQL because all 
> constraints are set DEFERABLE INITIALLY DEFERRED; that means no constrain 
> checks should be performed are performed until the transaction boundary, so 
> all circular references shouldn't be a problem. 
>
> Ticket #3615 exists because MySQL's implementation of DEFERABLE INITIALLY 
> DEFERRED under InnoDB is, to use the technical term, "Broken". It's 
> unrelated to any problem you may have found in PostgreSQL, because 
> PostgreSQL gets the underlying behaviour right. 
>
> Beyond that, we need a specific test case to take this any further. As it 
> stands, I'm not aware of any problems loading fixtures into PostgreSQL. If 
> you are able to construct and provide a set of models (which you have done) 
> and simple fixture (which you haven't) that fails reliably, we have a new 
> bug on our hands, and you should open a ticket with all the details you can 
> provide. Confirming whether this is a problem with the alpha, or an ongoing 
> problem would also be helpful.
>
> Yours,
> Russ Magee %-)
>
> On Mon, Jun 17, 2013 at 6:22 AM, Yo-Yo Ma <baxters...@gmail.com
> > wrote:
>
>> There doesn't appear to be a way to load fixtures from JSON (using 
>> Postgres - works fine in sqlite3) for the following models:
>>
>>
>> class Collection(models.Model):
>> main_thing = models.OneToOneField(
>> 'things.Thing',
>> null=True,
>> on_delete=models.SET_NULL
>> )
>>
>> class Thing(models.Model):
>> collection = models.ForeignKey(
>> 'collections.Collection'
>> )
>>
>>
>> Here is the exception:
>>
>> Problem installing fixture 'my_fixture.json': Could not load 
>> collections.Collection(pk=1): insert or update on table 
>> "collections_collection" violates foreign key constraint 
>> "main_thing_id_refs_id_3a4d3fef"
>> DETAIL:  Key (main_thing_id)=(1) is not present in table "things_thing".
>>
>> 

Circularly dependent fixtures fail with Postgres 9.2

[Yo-Yo Ma]

There doesn't appear to be a way to load fixtures from JSON (using Postgres 
- works fine in sqlite3) for the following models:


class Collection(models.Model):
main_thing = models.OneToOneField(
'things.Thing',
null=True,
on_delete=models.SET_NULL
)

class Thing(models.Model):
collection = models.ForeignKey(
'collections.Collection'
)


Here is the exception:

Problem installing fixture 'my_fixture.json': Could not load 
collections.Collection(pk=1): insert or update on table 
"collections_collection" violates foreign key constraint 
"main_thing_id_refs_id_3a4d3fef"
DETAIL:  Key (main_thing_id)=(1) is not present in table "things_thing".

I'm not sure if the issue is due to the unique constraint implied by a 
OneToOneField, or if it's just related to this issue: 
https://code.djangoproject.com/ticket/3615 (seems like that ticket and 
related ones have been closed for years, so possibly not related).

Any thoughts?

Note: I'm using @1.6a1

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

Re: Meta-Proposal: Write *above* quotations in mailing list replies

[Yo-Yo Ma]

Certainly, when a user is replying to portions of a quoted text separately 
(as Russel often does) it is helpful to break up the quoted text into 
actionable sections and reply below each. However, when a user is simply 
clicking the "Post Reply" button, chances are, it's going to be easier to 
read as:

Post 1

Post 2
>> noise

Post 3
>> noise

Rather than as:

Post 1

>>Post 1
Post 2

>> Post 1
>> Post 2
Post 3

>> Post 1
>> Post 2
>> Post 3
Post 4

>> Post 1
>> Post 2
>> Post 3
>> Post 4
Post 5

Also to reiterate, in email digests the latter format results in the reply 
not even being included in the email. Since this is a mailing list, it's 
sometimes useful to be able to actually read a digest of it it in your 
email.

Cheers
Yo-Yo

On Tuesday, June 4, 2013 1:28:47 PM UTC-4, Javier Guerra wrote:
>
> On Tue, Jun 4, 2013 at 5:14 PM, Yo-Yo Ma <baxters...@gmail.com> 
> wrote: 
> > Thoughts? 
>
>
> A: Because it messes up the order in which people normally read text. 
> Q: Why is top-posting such a bad thing? 
> A: Top-posting. 
> Q: What is the most annoying thing in e-mail? 
>
>
>
> -- 
> Javier 
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Meta-Proposal: Write *above* quotations in mailing list replies

[Yo-Yo Ma]

If you're posting to this list by logging in to https://groups.google.com/ 
rather than via email, I'd like to propose that you write your reply above 
the quoted message to which you're replying. If you do this, the digest 
emails that most subscribers get will be easily previewable from their 
email client (e.g., iPhone's Mail app). The way it stands now, about half 
of the messages that I can see (without clicking to the Google Groups 
website) are just:

> So and So said:
>> This that the other
>> and the other

> So and So said:
>> This that the other
>> and the other

Thoughts?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Yo-Yo Ma]

There is a fundamental problem here, albeit one that is rooted in simple 
misunderstanding.

The burden of proof is on the originator of an idea (i.e., the ticket 
reporter). Arguments can be made against the idea in the ticket. Rebuttal 
is sent elsewhere. Regardless of the intention, this automatically creates 
contention (in some cases) because it appears as a double standard, as 
arbitrary discretion is used to draw a line in the sand (the point at which 
the discussion should be moved to the mailing list).

The solution could be either:

A) Allow for full discussion in a ticket (this may not be an option, based 
on the conversations I've read)

or

B) Disallow only technical (how to fix, code review, etc.) discussion in a 
ticket, and make it easy to get from a ticket to its discussion thread and 
back again.

Option A allows for easier collaboration on business aspects by 
incorporating technical considerations into the conversation at the expense 
of extra noise.
Option B allows for easier digestion of either tech or business at the 
expense of a lack of cohesion among both parties.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Yo-Yo Ma]

>
> How about allowing comments only from the patch author and committers?
>

The problem I see with this is that original bug reporters, aside from the 
aforementioned groups, are usually the ones most engaged in these comments, 
and eliminating them from the process will only serve to further disjoint 
the technical dialog (e.g., "It's still not fixed" should probably go in 
the ticket, not here).
 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: test discovery

[Yo-Yo Ma]

Wow, this is awesome! Thanks so much guys. Too long have I dreamt of the day 
when I could include tests for my "lib" and "util", etc. without having to 
couple them to one app or another. I'm so excited that this was added so 
quickly. 


Thanks
Yo-yo

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Should saving a model with foreign keys referencing unsaved models raise an error?

[Yo-Yo Ma]

The following example can throw a wrench in things, if you don't catch it 
right away, since it fails silently.

>>> instance.some_fk_field = unsaved_instance
>>> instance.save()

The following example bit somebody I worked with a couple years back as 
well.

>>> instance.some_m2m.add(unsaved_instance)

Would it suffice to modify the ORM to fail loudly when either of the above 
examples occur, or do they both represent documented features (thus 
preventing them from being "fixed")?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

value|localize possibly breaking timezone display in templates

[Yo-Yo Ma]

If you include {{ object.some_datetime }} with the America/New_York 
timezone activated in a template and get:

April 10, 2013, 10:00 p.m.

Then, take the same object, timezone, etc., and add the |localize filter - 
{{ object.some_datetime|localize }} - you'll get:

April 11, 2013, 2:00 a.m.

It seems as if the `localize` filter disables the automatic timezone 
converting documented @ 
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#time-zone-aware-output-in-templates

Should the docs be updated to reflect this (i.e., it is intended), or 
should I file a bug ticket?

Note, my settings contain:

USE_TZ = True
TIME_ZONE = 'UTC'
USE_L10N = True

The datetime in question was created via `timezone.now()`

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

unittest2 discovery proposal

[Yo-Yo Ma]

+1, in general. 

>> ** The current "myapp." notation is not part of unittest2, and 
>> would go away

I don't know of anyone for whom this would represent a breakage in deployment 
processes, since it's usually used for quick local testing only.

One concern, however:

How will `django-admin.py test` be handled when not in the project root? It 
might be good, for backwards compatibility, to default the `root` argument to 
the directory containing the settings module. 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Testing project code that resides outside of installed apps

[Yo-Yo Ma]

That's excellent news! Thanks, Carl. 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Testing project code that resides outside of installed apps

[Yo-Yo Ma]

A common pattern for larger applications is to maintain bits of reusable 
code outside of applications, but still inside of a project (e.g., 
myproject/lib), due to synchronous development and modification of 
application and library code. They're parts that aren't really large enough 
to warrant their own pip-installable package, but large enough to need 
tests.

Often, the (non-)solution is either to NOT test these small tools at all, 
or to test them in a way that tightly couples them to one's applications.

I'm here to get feedback on the general idea of a solution to the 
aforementioned problem, and on the acceptability (by the community) of such 
situations (maintaining libs outside of applications but still inside of a 
project):

1) Is there merit to (Django) providing a way to specify a project-level 
tests package/module wherein tests could be imported from various places in 
your project?
OR
2) Is this something that should always remain in a custom test runner?
OR
3) Is this sort of code maintenance just not a great idea because libraries 
that need tests should be factored out as pip-installable packages and 
independently tested?

If this is considered a good practice AND the answer to #1 is something 
akin to "yes", feel free to make suggestions on what you think the API (or 
setting, etc.) should look like.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Policy for stable/1.x.x branches

[Yo-Yo Ma]

Ah, thanks Jacob. Also, great job on the 1.5.1 release. Thanks to everyone 
for all the hard work.

On Thursday, March 28, 2013 12:34:56 PM UTC-4, Yo-Yo Ma wrote:
>
> The commit 
> https://github.com/django/django/commit/2f121dfe635b3f497fe1fe03bc8eb97cdf5083b3fixed
>  a problem where a custom regex validator's customized message was 
> ignored, in favor of the one set on the class (you just see "Please enter a 
> valid value").
>
> If I pip install the latest master, the problem is of course fixed. If I 
> pip install stable/1.5.x, the problem persists.
>
> I searched the docs for info about using the stable/1.x.x branches, but 
> couldn't find anything, so I wanted to ask:
>
> 1) Is doing so considered safe (e.g., for production usage), since they're 
> "stable"?
> 2) What is the policy or lag time for getting commits such as the 
> aforementioned bug-fix into these stable branches?
> 3) Are there docs for this, and if not, should there be an entry on 
> https://docs.djangoproject.com/en/dev/faq/install/?
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Policy for stable/1.x.x branches

[Yo-Yo Ma]

@Jacob - thank you much. That was the exact docs page I didn't think 
existed.
@Ramiro - I meant using stable/1.5.x in production.

BTW, Jacob, the first of 2 docs links you provided mentioned providing bug 
fixes for the most recent release, and follows up with essentially, 
"they're at stable/A.B.x". Will bugs like that one I mentioned in the OP 
actually be eventually fixed in 1.5.1, instead? I'm just trying to decide 
what the best thing (tag, commit, branch tip, etc.) to install to make sure 
I get those sorts of updates in my production server. It could be just that 
I install the tip of master and test it out before updating, but that's not 
ideal of course.


On Thursday, March 28, 2013 12:34:56 PM UTC-4, Yo-Yo Ma wrote:
>
> The commit 
> https://github.com/django/django/commit/2f121dfe635b3f497fe1fe03bc8eb97cdf5083b3fixed
>  a problem where a custom regex validator's customized message was 
> ignored, in favor of the one set on the class (you just see "Please enter a 
> valid value").
>
> If I pip install the latest master, the problem is of course fixed. If I 
> pip install stable/1.5.x, the problem persists.
>
> I searched the docs for info about using the stable/1.x.x branches, but 
> couldn't find anything, so I wanted to ask:
>
> 1) Is doing so considered safe (e.g., for production usage), since they're 
> "stable"?
> 2) What is the policy or lag time for getting commits such as the 
> aforementioned bug-fix into these stable branches?
> 3) Are there docs for this, and if not, should there be an entry on 
> https://docs.djangoproject.com/en/dev/faq/install/?
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Policy for stable/1.x.x branches

[Yo-Yo Ma]

The commit 
https://github.com/django/django/commit/2f121dfe635b3f497fe1fe03bc8eb97cdf5083b3
 
fixed a problem where a custom regex validator's customized message was 
ignored, in favor of the one set on the class (you just see "Please enter a 
valid value").

If I pip install the latest master, the problem is of course fixed. If I 
pip install stable/1.5.x, the problem persists.

I searched the docs for info about using the stable/1.x.x branches, but 
couldn't find anything, so I wanted to ask:

1) Is doing so considered safe (e.g., for production usage), since they're 
"stable"?
2) What is the policy or lag time for getting commits such as the 
aforementioned bug-fix into these stable branches?
3) Are there docs for this, and if not, should there be an entry on 
https://docs.djangoproject.com/en/dev/faq/install/?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Form validation - char field coerces *any* data into a unicode

[Yo-Yo Ma]

I should note, the use case for this is when the data is being provided to 
the form through a mechanism other than normal HTTP form-encoded via 
request.POST, such as an API that consumes JSON.

>>> product.name
> u"{'haha': 'I am a dict'}"
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Form validation - char field coerces *any* data into a unicode

[Yo-Yo Ma]

A form that has a char field (e.g. "name") when provided a dict of data 
will convert the value of "name" to a Unicode, no matter what. I understand 
that this is desirable in some circumstances, but it can lead to things 
like:

>>> product.name
u"{'haha': 'I am a dict'}"

Perhaps this is desirable, but I wonder if there is any merit to the idea 
of sanitizing data to ensure it is "valid" for a char field, since 
practically *any* Python object can be cast into a Unicode (vs a 
DecimalField or an IntegerField, which will raise an error).

I realize the distinction of a "valid" would be completely arbitrary (e.g., 
who's to say that a dict isn't a valid char field value, but an that 
integer is?), but nonetheless, here I am, requesting feedback.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Ticket #17093 -- quarantine global state in django.template

[Yo-Yo Ma]

For anyone developing a SaaS that allows users to create templates through the 
UI (e.g., a hosted CMS), separately initializable template system is paramount, 
giving the ability to modify multiple settingsin the template system that are 
in effect during template rendering, including loaders, template builtins, etc. 
This way, an application's primary UI can use one set of settings, and the 
settings for users' templates. 

Note: by "settings", I don't necessarily mean settings.py, just template 
settings, even of that means instantiating a template system on the fly. 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Form.set_data method

[Yo-Yo Ma]

With all respect, this seems like a bad idea; there would be little, if any, 
gain from having this method.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Github tags

[Yo-Yo Ma]

Sorry to be a pest, but will you guys end up adding a Git tag for RC-1?

On Sunday, October 28, 2012 10:38:00 PM UTC-4, Matt Austin wrote:
>
> Hi, 
>
> Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5 
> alpha tagged on the github repository? The tagging seems to have 
> fallen behind with these releases. 
>
> Thanks, 
>
> -- 
> Matt 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/k5kOIGBuO_AJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)

[Yo-Yo Ma]

-1 FWIW

Computing the root of your project with os.path works just fine and doesn't 
require another setting... which, btw, could have no sane default. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/ZTjEZkT1TLQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: [ANNOUNCE] Security releases (Django 1.3.5, Django 1.4.3, Django 1.5 beta 2)

[Yo-Yo Ma]

Tom,

Create a view that accepts a "uri" argument and returns a 302 to the provided 
URI. Then, update your redirect_to callable to urlencode the URI and send them 
to /your/redirect/view/?uri=[encoded URI] and problem solved. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/rVxzz8Z5ubsJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Django 2.0 - a case for a customizable pony

[Yo-Yo Ma]

This morning read the SQLAlchemy proposal made by Luke Plant in June. I 
then decided that this would be a good time to rant about abstraction, 
extensibility, and decoupling.

Background


For years, Django has been forced to deal with most implementation issues 
from within, including the ORM, templates, etc. Even things like JSON 
support and basic timezones (for the new timezone module) were or are built 
right into the framework, in order to handle heterogeneous environments and 
Python versions, and to minimize external dependencies. This strategy 
contributed to the success of Django, in part because finding nice, well 
supported libraries was tough, and installing dependencies was too.

The Python community has grown and its processes have matured nicely. 
Nowadays, for a given problem, there are typically multiple solutions, many 
listed on services like www.djangopackages.com. Installing packages is 
easy, thanks to things like pip, and pypi. Collaboration is simpler, thanks 
to services like GitHub. This trend can be summarized as abstraction, which 
is a good thing. Handling things at a proper abstraction level is always a 
time and heartache saver, and is of course the reason for using a framework 
like Django in the first place.

The Problem
-

Solving too many problems from the top down, and coupling things too 
tightly in a project leads to code rot, because implementations all have to 
be written by somebody who is intimate with many other parts of the 
framework, then they have to be vetted others who are intimate with many 
parts of the framework, and then the code has to be maintained. Coupling 
becomes an inevitability, simply because it is possible. Backwards 
compatibility becomes more and more difficult and costly to maintain, and 
prohibits growth. Projects built atop the framework eventually run into 
problems for which the solution is to make changes to implementation 
details (usually via subclassing, but in some cases, via monkey patches), 
which leads to code debt in a project, and subsequent contention in the 
community when implementation details are changed in a way that breaks 
backwards compatibility for those "power users".

This means that the issue of "We can't do that because it'll break things" 
isn't really the problem that Django has. It's a symptom of another 
problem, which is that Django is not nearly extensible enough (it's parts 
are not pluggable enough, and or are not well enough abstracted to be 
quickly changed and/or moved).

So, what?
-

So, Django has evolved toward being a more decoupled, less monolithic 
framework over the past couple years (e.g., the removal of auth's coupling 
to things like messages, customizable user models, etc.), but there is a 
lot left to be desired. I consider a Python web framework to be a minimum 
of A) request handling, B) URL routing to something callable (a view), and 
C) response handling. However, certain other things are good ideas to bake 
in, such as cookie handling, security related features (CSRF, click 
jacking, etc.), and probably a few others. Anything else should be 
completely pluggable, and completely decoupled from everything else.

Some examples which make me smile:

Sessions - 
Cache - includes support for plugging in a back-end and only defines a 
simple interface (cache.set, cache.get, etc.)
Mail - includes support for writing / plugging the back-end of your 
choice, only defines a simple interface (send_mail, send_mass_mail, etc.)

Some examples which make me sad:

Templates - unpluggable (importing a third party template library and 
using it in your view is not plugging it in, since this isn't compatible 
with 3rd party or contrib apps)
ORM - I'll defer to the complexities that arose from Luke's proposal
Admin - lacks abstraction, and therefore has some great tools that 
can't really be used elsewhere (e.g., filter specs, sorting, etc.), lacks 
usage of CBV, in favor of an ad hoc solution

The Solution
-

>From an interface perspective, I have some ideas about how to handle the 
templates side of things, and some pretty vague ideas of how to handle the 
ORM, but I personally think that the real solution is to work not on 
implementing new ideas and solutions to use beside or in place of existing 
ones, but rather to fix the underlying problem that Django has. We can 
fight an uphill battle constantly by trying to usher new ideas in over our 
12 foot wall, believing that it is indestructible, or we can work together 
to "Tear down this wall!" :)

Remember, we're at 1.5 now. If we have a specific goal in mind that is very 
drastically different now, we can do a lot before 2.0 without breaking 
backwards compatibility (at least not too badly).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 

Re: Github tags

[Yo-Yo Ma]

+1

On Monday, October 29, 2012 5:18:48 AM UTC-4, Jan Bednařík wrote:
>
> There is also related ticket https://code.djangoproject.com/ticket/19141 
>
> Jan 
>
>
> On Mon, Oct 29, 2012 at 3:36 AM, Matt Austin 
>  
> wrote: 
> > Hi, 
> > 
> > Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5 
> > alpha tagged on the github repository? The tagging seems to have 
> > fallen behind with these releases. 
> > 
> > Thanks, 
> > 
> > -- 
> > Matt 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Django developers" group. 
> > To post to this group, send email to 
> > django-d...@googlegroups.com. 
>
> > To unsubscribe from this group, send email to 
> django-develop...@googlegroups.com . 
> > For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en. 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/qWKMQb_tsmAJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Complicated, strange bug in ``prefetch_related`` when used in the context of a test client

[Yo-Yo Ma]

Hi Anss, thanks for the reply.

The queries are identical.


That's the exact reason I posted. Those two examples should essentially be 
the same, save for some sort of operator overloading.

My note at the bottom about providing an empty list instead of the related 
cache when calling ``prefetch_related_objects`` implies that something 
weird is going on with the related cache, and the fact that it only happens 
when using the test client (at least, thus far) makes me think that it 
could possibly even be related to some sort of ``threading.local``, or 
something to that effect.

The models are simple (named according to the example in the original post):

class Foo(models.Model):
title = models.CharField(max_length=255)


class Baz(models.Model):
name = models.CharField(max_length=255)


class Bar(models.Model):
foo = models.ForeignKey('Foo')
baz = models.ForeignKey('Baz')
quantity = models.IntegerField()


My wild guesses: 
>   - some sort of state leak in testing 
>   - non-deterministic bug in prefetch_related (likely caused by random 
> ordering of the rows in the resultset) 
>
> I hope you can provide us more data about this situation, 
>  - Anssi 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/SirWYaLJLs4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Complicated, strange bug in ``prefetch_related`` when used in the context of a test client

[Yo-Yo Ma]

I'm still working on forming some sort of understanding of what exactly 
causes this and/or what is even going on, so any help is much appreciated.

The resultant attached "bars" in the following example:

queryset = Foo.objects.all()
queryset = queryset.prefetch_related('bars__baz')
obj = queryset.get(pk=1)

are different from the results of:

obj = Foo.objects.all().prefetch_related('bars__baz').get(pk=1)

And, the results attached in the second example are inconsistent as well.

In order to reproduce this, you need to first query for the "Foo", then add 
some "bars" to the DB, then perform the above examples.

This only seems to occur, at least measurably, during tests when using 
``self.client.get(...``, where the view that is being requested performs 
the queries.

I'm using ``TransactionTestCase``, sqlite3, and Django latest master, 
pulled about an hour ago, and I've also tried the new live server test case 
with the same results.

Note: If I modify django.db.models.query # 590 to the following, the bug 
doesn't occur (not to suggest that the following is a solution, but it 
might help to debug):

prefetch_related_objects([], self._prefetch_related_lookups)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/qpkxQFmjlvoJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Proposal - ``Model.reset_state``

[Yo-Yo Ma]

Problem:

a = A.objects.get(...)
form = AModelForm(data={...}, instance=a)
if form.is_valid():
a = form.save()
else:
a.calculate_foo_field()
a.last_attempt = datetime.now()
a.save()  # Oops, now the instance has the bad data provided to the form


Workarounds:

# Get a fresh copy of ``a``
a = A.objects.get(pk=a.pk)
# Wasted query
# Also, this won't work in the context of a ``select_for_update`` on 
the original instance

# Use ``update`` instead
A.objects.filter(pk=a.pk).update(last_attempt=datetime.now(), ...)
# What about ``calculate_foo_field``?
# Also has the ``select_for_update`` problem


Solution:

a.reset_state()  # Resets the instance's field state to the point of 
creation (using data stored in a ``_state_reset_cache`` dict)
a.reset_foo()  # etc.
a.latest_attempt = datetime.now()
a.save()

Problem: Uses more memory per instance
Solution: Add ``QuerySet.cache_for_reset()`` allowing opt-in usage of the 
feature, treating ``reset_state`` as noop when instance doesn't have the 
state reset cache.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/kjHIIO5YZJQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: save() method could return the object

[Yo-Yo Ma]

+1

A lot of people are overriding ``save`` and not returning anything, but 
this isn't going to hurt them (ideally, they should already be returning 
the result of ``super(``, but nobody does).

On Friday, October 12, 2012 9:25:46 AM UTC-4, Chris Wilson wrote:
>
> Hi all, 
>
> If the save() method returned the object itself, then we could chain it 
> like this: 
>
>  old_status = Status(last_contact=None).save() 
>
> Instead of having to do this: 
>
>  old_status = Status(last_contact=None) 
>  old_status.save() 
>
> It's a trivial one-line change to the Model class and I don't think it 
> would break backwards compatibility, as I doubt that anyone is relying on 
> the save() method returning None. Should I submit a patch? 
>
> Cheers, Chris. 
> -- 
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838 
> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK 
>
> Aptivate is a not-for-profit company registered in England and Wales 
> with company number 04980791. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/WkAiV5BsEiEJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Yo-Yo Ma]

I only now realized that this thread had started in a bit of a trolling 
fashion, and that there was a similar thread this week. That helps to explain 
the slightly more defensive stance.

Django can survive (and thrive) just fine in its current, reasonably performant 
state, but performance should have a priority, rather than being in a sort of 
"its fine as-is" stasis. 

Benchmarks like the ones posted aren't that helpful, but it doesn't change the 
fact that there tends to be an anti-performance sentiment in this group. When 
you look at the latest Python 3.3.x release, you see that there are many 
performance improvements that are clearly not due to incidental changes. I'm 
merely suggesting that an initiative to better the performance of Django, 
perhaps by benchmarking to find some of the weakest points, determining the 
lowest hanging fruit, and creating tickets in trac for them. I would love to 
help optimize any given part of Django and submit a patch, but not if I'm 
afraid that it will never be applied and/or the ticket will be marked as "works 
for me", etc. Help give us who care about performance the most a real chance to 
make some improvements. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/bxfyOKgoRogJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Yo-Yo Ma]

Why does every conversation about Django's performance met with "GTFO we don't 
care"? (that was a rhetorical question :). I'd venture to guess that most "It's 
fast enough for me!" responses are predicated on experiences that can be 
likened to personal blog development, rather than large scale, 10+ server 
deployments (e.g., Disqus, et al). 

If you had great abs, nice pecs, ripped legs, a nice deltoids, and 4" 
circumference biceps, you'd *probably* start to care when people said, "hey, 
what about those biceps...", no?

Are CPUs, RAM, and electricity free? (that too was a rhetorical question :)

Django is an *epic* (not in the literal sense :) framework, which offers a 
tremendous amount of functionality with nary an inkling of logical restraint. 
You can accomplish basically anything with Django without running into 
arbitrary limitations (e.g., have a gander at the limitations in most 
frameworks' URL dispatchers, just as a relevant example). To shorten this, from 
a features / ease of use standpoint, Django is just plain awesome.

BUT... Django is NOT that fast.

1) Django templates are unbearably slow (doesn't matter for a blog or something 
simple, but try something with lots of inline model formsets in a page and 
quite a few includes, and before you know it, you're wasting a decent 
percentage of your CPU on templates).

2) URL dispatching

3) Middleware is applied liberally (vs the a la carté, more efficient decorator 
approach to AOS)

The list goes on. What is the harm in discussing the weak points of Django? 
Performance is probably the only major weak point in Django right now (aside 
from the lack of schema migration in core, which is coming soon anyway).

I have no solution or patches in my pocket, but I can say with absolute 
certainty that performance will never, ever get better when discourse is in a 
monologue format.

That's all.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/uZ9r1EtZnj4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Optimization request - give ``request.session`` lazy read

[Yo-Yo Ma]

With ``contrib.sessions`` installed and ``SessionMiddleware`` in use, I 
noticed that when Django session cookie is set the ``django_session`` table 
is queried on every request, regardless of whether any session data is used 
during the request cycle. Making the ``session`` attribute of request a 
lazy object would represent an optimization in the following 2 cases, both 
of which are the same, in effect:

1) User logs in to perform login-required tasks, then visits pages that 
don't require login
2) User logs in to perform login-required tasks, logs out, then visits 
pages that don't require login

Would this sort of change be backward-incompatible?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/uXBhKovPew4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ``models.BooleanField`` fields default to ``False`` when missing from fixtures

[Yo-Yo Ma]

The gremlin example was just a light-hearted attempt at justifying the 
claim of "data corruption", in response to Florian, but I really only 
brought up this issue because it surprised me (nothing in the docs).

I would suggest a docs update to let developers know that if a default 
isn't set, ``False`` is implied - only because this seems like the sort of 
mini-"bug" that might never warrant fixing due to the ramifications.


On Monday, September 24, 2012 9:18:34 PM UTC-4, Russell Keith-Magee wrote:
>
> On Tue, Sep 25, 2012 at 8:00 AM, Yo-Yo Ma <baxters...@gmail.com> 
> wrote: 
> > Developer of a pet shop software adds: 
> > 
> > feed_before_midnight = models.BooleanField() 
> > 
> > because they're planning on carrying baby gremlins... forgets to update 
> the 
> > zoological XML feed importer to use the "feed_before_midnight" value, 
> and 
> > the rest is history :) 
>
> We need to be clear on what we (as in, the Django project) classify as 
> "catastrophic data loss". 
>
> Examples of Catastrophic data loss: 
>  * You request a save of object X, and object X is not saved. 
>  * You save object X, and object Y is modified. 
>  * You save object X, and object Z is deleted. 
>
> NOT examples of Catastrophic data loss: 
>  * You forget to set a value on an object, and the default isn't what 
> you expected. 
>  * You set a value on an object, which is saved verbatim, but wasn't 
> the correct value under the circumstances. 
>
> In the example you provide, I agree that there would be catastrophic 
> consequences. However, the code is doing exactly what it's instructed 
> to do. While I may concede that this is a bug, it's a bug caused by 
> ambiguous default behaviour, not behaviour that is fundamentally 
> incorrect or destructive -- it's essentially nothing more than "0 is a 
> default value". You can argue that 0 isn't an appropriate default in 
> this circumstance, but you can't argue that it is (a) a particularly 
> surprising default, or (b) that the developer was given an opportunity 
> (multiple opportunities, really) to set an appropriate default. 
>
> If this conflicts with what you consider to be catastrophic, thats 
> fine -- I'm just letting you know the benchmark that we, as a project, 
> use to guide our decision making process. 
>
> Yours, 
> Russ Magee %-) 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/YO9PTOVrakUJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ``models.BooleanField`` fields default to ``False`` when missing from fixtures

[Yo-Yo Ma]

Developer of a pet shop software adds:

feed_before_midnight = models.BooleanField()

because they're planning on carrying baby gremlins... forgets to update the 
zoological XML feed importer to use the "feed_before_midnight" value, and 
the rest is history :)

On Monday, September 24, 2012 9:21:34 AM UTC-4, Florian Apolloner wrote:
>
> ...
> I don't see how that could corrupt stuff in the current situation
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/1bdXw5KfYRwJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ``models.BooleanField`` fields default to ``False`` when missing from fixtures

[Yo-Yo Ma]

Yep, that looks like it. IMHO, this is a bug that should be fixed without 
delay, as it breaks a cardinal rule for Pythonistas, and could even lead to 
a "data corruption" situation, if a dev was to add a boolean field and 
forget to update a form or fixture, or both.


On Monday, September 24, 2012 5:44:29 AM UTC-4, Aymeric Augustin wrote:
>
> 2012/9/24 Yo-Yo Ma <baxters...@gmail.com >
>
>> This may be the intended behavior, but I couldn't find docs on it. My 
>> recommendation would defer to "The Zen of Python"
>>
>> In the face of ambiguity, refuse the temptation to guess.
>>
>> I would rather see the typical IntegrityError: Problem installing 
>> fixture...
>
>
> Hello,
>
> This looks a lot like: https://code.djangoproject.com/ticket/15124
>
> I hope I'll have time to study this problem again before the feature 
> freeze of 1.5.
>
> -- 
> Aymeric.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/6i5BdRrk8y0J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

``models.BooleanField`` fields default to ``False`` when missing from fixtures

[Yo-Yo Ma]

This may be the intended behavior, but I couldn't find docs on it. My 
recommendation would defer to "The Zen of Python"

In the face of ambiguity, refuse the temptation to guess.

I would rather see the typical IntegrityError: Problem installing fixture...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/d2qyWIByy-kJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Models.py not loaded at server startup ?????

[Yo-Yo Ma]

Another good reason for model loading at startup is a good idea; without it, 
models.get_models becomes a lie.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/bDjcdKrvk9MJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

iPython behaves strangely only with Django shell

[Yo-Yo Ma]

The following gist demonstrates a strange phenomenon, which occurs when I 
use ``python manage.py shell``, but not when I use ``ipython`` alone.

https://gist.github.com/f8c2fd97647de90d915a

I'm not certain whether this is a known issue, or whether it's even a 
Django bug, but certainly nothing of the sort occurs in iPython when used 
alone. This occurs with ANY name. I first noticed it when I tried to create 
a form, and there was a name error on ``forms`` on the line of my first 
field declaration.

IPython 0.12.1
Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/0IjXTJb6WFYJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Signal connection via "my_app.MyModel"

[Yo-Yo Ma]

Is there anyone else out there who doesn't like having to import models from 
app X into app Y just so that app Y can connect post save signals to them?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/_vcka4fdtPUJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Docs mistake

[Yo-Yo Ma]

At:

https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.FileField.upload_to

The docs make mention of the "url" attribute being MEDIA_ROOT + upload_to. I 
think whoever wrote it meant that the aforementioned is how the file name/path 
is determined, and that also MEDIA_URL + upload_to is used to make the "url" 
attribute.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/yWuBLG3QTY8J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Proposal: Add some extensibility / decoupling features to Django templates

[Yo-Yo Ma]

I'll start with an example:

Using Jinja2, I can create an environment which is pretty secure (no access 
to anything but built-ins and objects explicitly marked "safe"), and 
provide a loader who's templates are loaded from the database (e.g., 
``request.client.template_set.all()``), and customize all this for a single 
request (Since I can simply instantiate an ``Environment`` per request with 
a custom ``Loader`` which has access to only the ``request.client`` 
templates). I can also customize the extensions on a per-request basis 
(that's sort of analogous to customizing template tag/filter built-ins), in 
order to limit or add to the type of tools that clients have access to.

Using Django templates, I'm left with simply running my clients' sites 
portion of the app under a different settings file. This *almost* cuts it 
too (since I can use a different URL conf which includes different 
template.add_to_builtins() calls, etc.), but it doesn't give me all the 
things that I need, like the ability to instantiate the loader with a 
queryset of templates for the ``request.client``, etc. 

"Why don't you just use Jinja2 then?"

The Django core team is a pretty intelligent team, and the philosophy 
behind the style of tags / filters / lack of logic in Django templates is 
far superior to Jinja2. I simply want a more Jinja2-ish Python API for 
using Django templates.


My Proposal (abstract explanation, btw, I'd be happy to help architect / 
write code):

Without changing any of the existing functionality or settings in Django, 
refactor the template system to use an ``Environment`` class (something 
akin to Jinja2's ``Environment``) which takes a list of loaders, and a 
number of other arguments. Then, instantiate this class, using the provided 
settings, and use it for all the default functionality (the admin, 
render_to_response, CBV template access, etc.). This would allow developers 
to make their own ``Environment`` instance with different arguments, 
request-specific or otherwise, and without having to do a lot of evil 
things.


Thanks
Fellow Djangonaut

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/h9ExRYxoxHUJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``

[Yo-Yo Ma]

Thanks Aymeric, I've reopened the ticket. I skipped the triage page,
thinking it would be about the rules for prioritizing bugs.

On May 15, 3:44 pm, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> On 15 mai 2012, at 21:36, Yo-Yo Ma wrote:
>
> > I've attached a diff in the ticket I created, and I resolved the
> > ticket as "fixed" (as habit, I'm used to doing this for work, allowing
> > QA to change the status to "closed" after testing). Is this correct?
>
> We resolve tickets as "fixed" only once a patch is committed.
>
> Seehttps://docs.djangoproject.com/en/dev/internals/contributing/triaging...
>
> > Also, is it better to fork Django and make a pull request on GitHub,
> > or simply provide the git diff as I did
>
> As you wish!
>
> Best regards,
>
> --
> Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``

[Yo-Yo Ma]

I've attached a diff in the ticket I created, and I resolved the
ticket as "fixed" (as habit, I'm used to doing this for work, allowing
QA to change the status to "closed" after testing). Is this correct?
Also, is it better to fork Django and make a pull request on GitHub,
or simply provide the git diff as I did (the docs on contributing
don't really make mention of any new GitHub-related polices)?

On May 13, 10:02 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> Thanks for the report -- but is there a particular reason that you're
> reporting this here, rather than on the ticket tracker?
>
> Yours,
> Russ Magee %-)
>
>
>
>
>
>
>
> On Mon, May 14, 2012 at 9:55 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
> > A request to:
>
> >    http://www.example.com:8080//foo-bar-baz.html
>
> > leads to request.build_absolute_uri() returning:
>
> >    http://foo-bar.html
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``

[Yo-Yo Ma]

I've just created https://code.djangoproject.com/ticket/18314 and
intend to take a look a better into the implementation of
``build_absolute_uri()`` tonight.

On May 13, 10:02 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> Thanks for the report -- but is there a particular reason that you're
> reporting this here, rather than on the ticket tracker?
>
> Yours,
> Russ Magee %-)
>
>
>
>
>
>
>
> On Mon, May 14, 2012 at 9:55 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
> > A request to:
>
> >    http://www.example.com:8080//foo-bar-baz.html
>
> > leads to request.build_absolute_uri() returning:
>
> >    http://foo-bar.html
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``

[Yo-Yo Ma]

A request to:

http://www.example.com:8080//foo-bar-baz.html

leads to request.build_absolute_uri() returning:

http://foo-bar.html

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Signal connection via "my_app.MyModel"

[Yo-Yo Ma]

It would not be a "hard link". Do you know the definition of
"dependency graph", and do you know anything about Django's internals
or about how Django already allows you to connect models' foreign keys
this way? It would be simply "get me the model 'MyModel' from the app
'my_app'". The app could easily be moved around, and no extra imports
would be used in the process (see models.get_models()). This gives you
the ability to move the app around easily. The real benefit in my
oppinion would be the ability to connect signals for models from app A
inside of app B without having to worry about import order or errors,
due to some crisscross in app A's dependency graph.

On May 12, 4:24 am, Dougal Matthews <douga...@gmail.com> wrote:
> On 9 May 2012 22:14, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
>
> > This would allow for better decoupling of code, as well as a far
> > cleaner dependency graph.
>
> The dependancy will still be there, the string containing the dotted path
> would be a hard link. However, this will be hidden and a less obvious
> dependancy than a normal Python import.
>
> So, I'd be -1 as I don't see the advantage of this and rather it just adds
> further complexity.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Signal connection via "my_app.MyModel"

[Yo-Yo Ma]

I'd be willing to implement this, with some guidance.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Proposal: Signal connection via "my_app.MyModel"

[Yo-Yo Ma]

I'd like to suggest adding the ability to connect signals with models
by app label and model name.

Example API:

post_save.connect(
my_signal_handler,
sender='my_app.MyModel'
)

This would allow for better decoupling of code, as well as a far
cleaner dependency graph.

I'm not certain how this would affect custom signals. I'm primarily
speaking of the provided signals in ``db.models.signals``, but this
might be something that applies to custom signals as well.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: gsoc proposal, dynamic list form field

[Yo-Yo Ma]

On Mar 25, 2:41 am, Roy McElmurry IV  wrote:
> Okay, I have created a Google Doc of my proposal. I have greatly
> elaborated on the idea. I have enabled commenting for anyone with the
> link. Please take a look and let me know either in this forum or in
> the Google Doc if there is anything I can add or change to make this a
> more appealing proposal.
>
> https://docs.google.com/document/d/1zzqcW-OGHGydmJ-S-OLRVTiAMZMvdrRcG...

I think the idea you're proposing is predicated on a simple
misunderstanding. What your suggesting be encompassed in a
ManyToManyField-like model field is already achievable, in effect, by
second model with a foreign key to the first, and then by using
inlinemodel_formset. The misunderstanding, I think, is the idea that
you could create records with a simpler step. A custom form field
could be created which excepts space delimited ingredients and saves
them as separate ingredients, much like how Tag fields typically work.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

USE_TZ related warnings caused by fixture loading

[Yo-Yo Ma]

django/db/models/fields/__init__.py:808: RuntimeWarning: DateTimeField 
received a naive datetime (2012-01-01 00:00:00) while time zone support is 
active.

The above warning is caused by a JSON fixture having "2012-01-01 00:00:00" 
for a DateTimeField timestamp.

Does this mean that fixture loading needs to be modified to account for the 
new timezone code, or was is this just a side effect of keeping fixture 
loading backward-compatible?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/oGCVFF3Gn68J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Yo-Yo Ma]

After Ned's message, I'm -0, because while I'm not fond of multi-line
tags, I cannot offer a good alternative when it comes to multi-line
"with" tags.

On Feb 25, 6:48 pm, Ned Batchelder <n...@nedbatchelder.com> wrote:
> On 2/24/2012 11:55 PM, Yo-Yo Ma wrote:> I'm -1 on this for s specific reason; 
> If you need multiple lines for a
> > tag, you're doing it wrong.
>
> >>>> import this
>
> This would be far more helpful feedback if you would take the examples
> of too-long tags presented in this thread, and show the "right" way to
> do it.
>
> --Ned.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: django-admin.py startproject creating duplicate settings.py files

[Yo-Yo Ma]

Hey Carl,

Thanks for the reply. I removed everything from my venv's site-
packages directory (except PIL and some other graph library), then
checked to make sure I wasn't able to use django-admin.py or my app's
manage.py scripts (ie, making sure there wasn't a global Django
install). I then reinstalled Django after pulling the latest master
from the github mirror, moved to ~/dev and then: (actual copy/paste
from my shell, minus find/replace of my personal/info):

(myvenv)My-Names-MacBook-Pro:dev myusername$ mkdir test_startproject
(myvenv)My-Names-MacBook-Pro:dev myusername$ cd test_startproject/
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls -a
.   ..
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ django-
admin.py startproject testing123
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
testing123
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
testing123/
__init__.py manage.py   settings.py testing123  urls.py
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls
testing123/testing123/
__init__.py settings.py urls.py wsgi.py
(myvenv)My-Names-MacBook-Pro:test_startproject myusername$

I'm not pulling your chain. I've never had this happen before, and
Django functions just fine otherwise (except for now issuing a warning
about using naive datetimes in Field.__init__, which is ironically
right up the alley of my other thread)

Note: In site-packages for the venv, I show Django-1.4b1-py2.7.egg-
info


On Feb 20, 8:56 pm, Carl Meyer <c...@oddbird.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/20/2012 08:31 PM, Yo-Yo Ma wrote:
>
> > I have trunk installed from last night, and this is actual terminal
> > output (except for the stuff omitted on the left of the $):
>
> > (my_venv) myusername$ django-admin.py startproject foobarz
> > (my_venv) myusername$ ls foobarz/
> > __init__.py        foobarz         manage.py       settings.py     urls.py
> > (my_venv) myusername$ ls foobarz/foobarz/
> > __init__.py        settings.py     urls.py         wsgi.py
>
> > I opened both settings.py files, and they are indeed identical files.
> > Is this intentional? I was interested in the new manage.py format, so
> > I thought I'd adjust my app to use it and whatever other new layout
> > features, but clearly this isn't correct.
>
> Nope, it's not correct, and I can't reproduce it either. I get just a
> "manage.py" in the outer directory, and settings/urls/wsgi in the
> package. My guess is that you already had an old-style startproject in
> that "foobarz" directory or something. Try it again, and make sure the
> target directory doesn't exist. Also try cleaning your Django repo of
> untracked files; it's possible you somehow got extra files in the
> conf/project_template directory that don't belong there?
>
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk9DFf4ACgkQ8W4rlRKtE2cY7QCgvT5GMOuWLAgjl6QI3R/cBd6P
> Py8AoIQaqmi11fOfx67mz+kzl8bi95iv
> =zEND
> -END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

django-admin.py startproject creating duplicate settings.py files

[Yo-Yo Ma]

I have trunk installed from last night, and this is actual terminal
output (except for the stuff omitted on the left of the $):

(my_venv) myusername$ django-admin.py startproject foobarz
(my_venv) myusername$ ls foobarz/
__init__.py foobarz manage.py   settings.py urls.py
(my_venv) myusername$ ls foobarz/foobarz/
__init__.py settings.py urls.py wsgi.py


I opened both settings.py files, and they are indeed identical files.
Is this intentional? I was interested in the new manage.py format, so
I thought I'd adjust my app to use it and whatever other new layout
features, but clearly this isn't correct.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Yo-Yo Ma]

Thanks, Danny. That's really helpful to me, and I appreciate you
taking the time to explain it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Yo-Yo Ma]

I actually know so little that I was even more confused by my own
question, but I appreciate your reply, Danny. I feel pretty challenged
when I try to understand timezone-related stuff. Is this correct:

When using UTC, which, if any, are true:

A) If I have a view that simply adds a record of a model with a
datetime field, and 3 users in different timezones load the view at
the same time, all 3 records will have the same datetime value
(assuming, of course, the database was able to write all 3 records
within the same microsecond)
B) UTC is *the* way to go for almost any application which will have a
timezone = models.CharField(... setting for each user profile
C) When each user has a timezone setting, it doesn't affect the
datetime that's entered into the database, it just gives me the
ability to display the time to them in their timezone

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Yo-Yo Ma]

I haven't quite read up on all the UTC-related stuff in Django as of
yet (couldn't find much info about it), but I found some of the posts
above concerning. It would seem that if a DateTimeField should be
updated with ``timezone.now()``, then a DateField should be updated
with ``timezone.now().today()``, and TimeField should be updated with
``timezone.now().time()``, no? If I'm in EST time, and the server is
in MST, and it's 11:00PM on the server, my records should be updated
as the following day, since it's 1:00AM EST. Is this naive to assume
(if not, apologies for my lack of know-how regarding TZ issues)?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re-posting of previous thread: ``QuerySet.update`` not updating ``auto_now=True`` fields

[Yo-Yo Ma]

It seems my previous question was co-opted... by myself, so rather
than try to distract the conversation about TZ stuff (which seems to
be pretty important stuff, esp with the 1.4 launch), I figured I'd
start a new thread with my original question. Here it is:


If you call ``QuerySet.update`` on the following model, you'll get the
results that proceed it:

# models.py
class Person(models.Model):
cool = models.BooleanField(default=False)
updated_on=DateTimeField(auto_now=True)

# django-admin.py shell
>>> from myapp.models import Person

>>> # Check the updated_on values
>>> Person.objects.values_list('updated_on', flat=True)

[datetime.datetime(2012, 1, 1, 0, 0), datetime.datetime(2012, 1, 1, 0,
0)]
>>> # Fine, just as they are in the fixture. Update ``cool`` field on them
>>> Person.objects.update(cool=True)
2
>>> # Check the updated_on values again
>>> Person.objects.values_list('updated_on', flat=True)

[datetime.datetime(2012, 1, 1, 0, 0), datetime.datetime(2012, 1, 1, 0,
0)]

I understand that ``QuerySet.update`` issues an UPDATE SQL statement,
but Django's code could be modified to include each ``auto_now=True``
field on a model in the UPDATE statement, setting the value to
``datetime.now()`` as it does when you use ``Model.save``.

If this seems reasonable, I'll be happy to write a patch and tests for
it.

Note: I'm using the latest trunk code (1.4 beta), pulled yesterday

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auto_now=True fields aren't updated on QuerySet.update()

[Yo-Yo Ma]

On a related note, the new timezone.now() functionality is used for
``DateTimeField.pre_save`` when ``auto_now=True``, but it isn't used
for ``DateField.pre_save`` or ``TimeField.pre_save``. Is this a bug I
should report, or is there something I'm missing (I'm pretty
uninformed when it comes to UTC and timezone related stuff in Python)?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

auto_now=True fields aren't updated on QuerySet.update()

[Yo-Yo Ma]

If you call ``QuerySet.update`` on the following model, you'll get the
results that proceed it:

# models.py
class Person(models.Model):
cool = models.BooleanField(default=False)
updated_on=DateTimeField(auto_now=True)


# django-admin.py shell
>>> from myapp.models import Person
>>>
>>> # Check the updated_on values
>>> Person.objects.values_list('updated_on', flat=True)
[datetime.datetime(2012, 1, 1, 0, 0), datetime.datetime(2012, 1, 1, 0,
0)]
>>> # Fine, just as they are in the fixture. Update ``cool`` field on them
>>> Person.objects.update(cool=True)
2
>>> # Check the updated_on values again
>>> Person.objects.values_list('updated_on', flat=True)
[datetime.datetime(2012, 1, 1, 0, 0), datetime.datetime(2012, 1, 1, 0,
0)]


I understand that ``QuerySet.update`` issues an UPDATE SQL statement,
but Django's code could be modified to include each ``auto_now=True``
field on a model in the UPDATE statement, setting the value to
``datetime.now()`` as it does when you use ``Model.save``.

If this seems reasonable, I'll be happy to write a patch and tests for
it.


Note: I'm using the latest trunk code (1.4 beta), pulled yesterday

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.