[1.4] Pass "obj" parameter to get_inline_instances

[Yohan Boniface]

Hi,

First of all, congrats to the core team for the first rc of the 1.4 release!

Some great changes have been made on the admin for this release. One of 
them is the add of the "get_inline_instances" [1], that gives the 
possibility to change the inlines list at runtime.


I've a little suggestion on this. It could be really more powerful if to 
this method get passed the "obj" parameter, like for example it's done 
for get_fieldsets [2].


For what I can see, this seems to be a very soft change.

The function is called three times in options.py.
One is in get_formsets [3], and get_formsets itself has the "obj" parameter.
Another is in the add_view [4], and here obj could have its default 
value, None, as we are in add view and so no object exists.
The last is in the change_view [5], which retrieve the "obj" from its 
own parameters.


Do you think this change is enough minor to be added in the 1.4 release 
process?


If yes, just tell me if I need to create a ticket and a patch. :)

But maybe, I've missed something! :s


Thanks for all, django guys!


Yohan


[1] 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L348
[2] 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L425
[3] 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L508
[4] 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L936
[5] 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L1034


--
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: [1.4] Pass "obj" parameter to get_inline_instances

[Yohan Boniface]

Hi Carl,

Thanks for your answer.

I fully understand your point: I'm late in the release process.

In the other hand, can't we consider this as a "bug" for the fact that 
this new feature is not consistent with what we can call a "de facto API"?

What I mean is that "request" and "obj" are passed and used almost by:
- get_formset
- get_form
- get_fieldsets
- get_prepopulated_fields
- get_readonly_fields

I know that this is not a documented part of Django. But internal 
consistency is, IMHO, one of the pillars of a maintenable framework.


As you've also pointed your-self, adding the "obj" parameter after the 
release of "get_inline_instances" will introduce a backward incompatible 
change. (For those who will have overwritten the method and so do not 
accept the "obj" parameter.)


As an illustration, the "obj" parameter could be used to cleanly 
distinguish an add process from a change process (and choose which 
inlines to display).


Just to be clear: I'm not saying at all that this could be considered as 
a "release blocker". But adding this parameter now will certainly be 
much less painful than doing it after the release.


In one hand, we have a release process that do not accept exceptions, in 
the other hand we have a quite simple change to do that will be more 
painful to do later: I think that it calls a pragmatic judgment.


I've made a ticket with a patch, as you've suggested [1]. And I'll let 
you be this pragmatic judge! :)


Will all my respect,

Yohan


[1] https://code.djangoproject.com/ticket/17856

On 03/08/2012 05:35 PM, Carl Meyer wrote:

Hi Yohan.

On 03/08/2012 07:04 AM, Yohan Boniface wrote:

Some great changes have been made on the admin for this release. One of
them is the add of the "get_inline_instances" [1], that gives the
possibility to change the inlines list at runtime.

I've a little suggestion on this. It could be really more powerful if to
this method get passed the "obj" parameter, like for example it's done
for get_fieldsets [2].

For what I can see, this seems to be a very soft change.

The function is called three times in options.py.
One is in get_formsets [3], and get_formsets itself has the "obj"
parameter.
Another is in the add_view [4], and here obj could have its default
value, None, as we are in add view and so no object exists.
The last is in the change_view [5], which retrieve the "obj" from its
own parameters.


I think this is a sensible change.


Do you think this change is enough minor to be added in the 1.4 release
process?


Unfortunately, no. This is a new feature, which means it was too late to
add it as soon as the beta was released, let alone after the RC. (After
the RC we're hesitant to even fix bugs unless they are release-blocking
bugs).

This is too bad, because once 1.4 is released there will have to be
consideration of backwards-compatibility for existing
"get_inline_instances" methods that don't accept the "obj" parameter.
This may tip the scales towards considering this not worth doing,
depending what compelling use cases can be presented.

Feel free to file a bug for this and it can be revisited after 1.4 is
released.

Carl



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

"c" date formating and Internet usage

[Yohan Boniface]

 Hi,

In Django's documentation, the 2 following points are mentionned [1]:

- About date formating:

"Uses the same format as PHP's date() function (http://php.net/date) with
some custom extensions."

- About the specific "c" format:

"ISO 8601 Format." e.g. : 2008-01-02T10:30:00.000123

As we can see in the example, the ouput of the "c" format does not provide
the time zone information (for example : +02:00).

Firstly, this is in contradiction with how PHP handles the "c" format : PHP
does provide the time zone information (their documentation uses
"2004-02-12T15:19:21+00:00" as the example for the "c" format [2]).
Therefore, at the very least Django's documentation is innacurate.

Secondly, even if the ISO 8601 standard allows many date formats, the
Internet usage is strongly oriented towards the use of the extended format
with time zone (for e.g. 2008-01-02T10:30:00.000123+02:00). In particular:

- In current HTML5 editor's draft [3], the W3C makes the time-zone
offset mandatory for datetimes. A W3C note about the issue was also
published. [4]

- In their Sitemap protocol documentation, Google asks for the time-zone
offset in datetimes, following the W3C Note. [5] [6]

- The RFC 3339 says the following "the interoperability problems of
unqualified local time are deemed unacceptable for the Internet." [7]
Furthermore, it specifically mentions that date-time should be exprimed with
the timezone offset. [8]

I suggest that Django follows this usage and modifies its handling of this
format. However, since this clearly has backward compatibility issues, I'd
like to have a discussion about this before proposing a patch.

Thanks,

Yohan

[1] 
https://docs.djangoproject.com/en/1.3/ref/templates/builtins/
#date 

[2] http://php.net/date 

[3] 
http://dev.w3.org/html5/spec/common-microsyntaxes.html
#valid-global-date-and-time-string

[4] http://www.w3.org/TR/NOTE-datetime

[5] 
http://www.sitemaps.org/protocol.php
#lastmoddef 

[6] 
http://www.google.com/support/webmasters/bin/answer.py?hl
=en&answer
=74288&from
=42738&rd
=1

[7] 
http://www.apps.ietf.org/rfc/rfc3339.html
#sec-4.4 

[8] 
http://www.apps.ietf.org/rfc/rfc3339.html
#sec-5.6 

-- 
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: "c" date formating and Internet usage

[Yohan Boniface]

Hi Stephen, Hi Ian, Hi all,

As you say Stephen, isoformat is handling the timezone offset for non naive
datetime, and so does Django in the "c" date formatter. And I should have
noticed and mentionned this in my previous email.
I'll take the time to give a better look to this issue, with these new
elements.
By the way, I wonder why for the "O" formatter a workaround is used when the
datetime is naive, and not for the "c" formatter.
Anyway, I think that at least a little patch to the doc to clarify the "c"
behaviour should be useful (naive and non naive datetime). And maybe to warn
about the non consistent behaviour of Django depending on the date formater
used.

Yohan


2011/6/27 Ian Clelland 

> On Sun, Jun 26, 2011 at 12:27 AM, Stephen Burrows <
> stephen.r.burr...@gmail.com> wrote:
>
>> This is related to the recent discussion about timezone-aware datetime
>> storage [1] and how django doesn't do it. Since the date filter's "c"
>> argument is handled with python's datetime.isoformat() [2] timezone-
>> naive datetimes will not display a UTC offset.
>>
>> [1]
>> http://groups.google.com/group/django-developers/browse_thread/thread/76e2b486d561ab79/0a46b72da6e9fb03
>>
>> [2]
>> http://docs.python.org/library/datetime.html#datetime.datetime.isoformat
>>
>>
> This isn't the same issue at all -- It may be related, but that discussion
> thread was about storing timezone-aware timestamps in the database, not
> about handling them in templates.
>
> We can't simply say that "Django doesn't support
> timezone-aware datetimes" -- besides being a ridiculous restriction, it's
> not true: even in django.utils.dateformat there are several formatting codes
> that take the input's timezone into account (see I, o, T, U).
>
> Even the "r" formatting code, for RFC 822 formatting, takes the timezone,
> if present, into account.
>
> While I would use the documented claim of PHP compatibility as an argument
> for this, it's not really a strong argument (and I wouldn't support just
> removing the claim as a simple solution). A better argument is that the ISO
> standard allows the timezone, various Internet standards and drafts
> recommend or require it, and in many cases, it is available to Django, and
> so we should include it when we can.
>
> I generally find myself having to introduce a "proper" ISO-8601 formatting
> string into every project, or supplement the time rendering with a
> hard-coded timezone, when I can know it for sure (e.g., {{
> timestamp|date:"c" }}+00:00 ). I would absolutely support adding a "real"
> ISO-8601 formatter to the standard filter library.
>
> --
> Regards,
> Ian Clelland
> 
>
> --
> 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.
>

-- 
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: "c" date formating and Internet usage

[Yohan Boniface]

2011/6/28 Stephen Burrows 

>
> The "O" formatter - or more specifically, the "Z" formatter - does
> include that bit of magic. Is there a particular reason for this?
>

I ask myself the same question. Why for the "Z" (and co) and not for the "c"
?


> Also, if a timezone is assumed, wouldn't it make more sense to assume
> the timezone of the project rather than UTC? Rather than noting an
> inconsistency, can we make this consistent?


Defining the default behaviour when the datetime is naive is not that easy,
in my point of view.

Here is the summary of what I understand (we are talking about the Django's
dateformat util) :

1. when the datetime has a timezone, use it : this is what Django does, and
it's fine.
=> In my point of view, the documentation should be clearer (about the fact
that the "c" formatter, using isoformat, will add the timezone offset only
for non naive datetime and about the fact that this behaviour is not
consistent with other formatters)
=> I'll propose some little patch

2. when the datetime is naive, what to do ?
=> like I said, I think the answer is not that easy, and Django is not
completely coherent on the subject

 2.1 Do nothing
 => this is what Django does for the "c" formatter (as using the .isoformat
datetime method) [1]
 => easier, clearer (no magic), but not so user friendly : it means that
when dealing with naive datetimes, developpers have to manually add the
timezone everytime (error-prone, not very DRY...)

 2.2 Use the system local timezone
 => this is what Django does for the "Z" and "O" formatters for example
(using the time.timezone / .altzone function) [2] [3]
 => basing the default timezone on the machine local one could be risky (and
not so "cloud" aware...)

 2.3 Use the settings.TIME_ZONE information
 => I wonder why this setting is not used by Django here
 => in theory, this sounds like a good default behaviour

 2.4 Missing something ?

And so the final question is : is there a "good" way to arbitrate the
handling of naive datetime when formatting them ?

[1]
https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py
#L126
[2]
https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py
#L269
[3] 
http://docs.python.org/library/time.html
#time.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: "c" date formating and Internet usage

[Yohan Boniface]

I've created a ticket to propose a little change in the documentation :
https://code.djangoproject.com/ticket/16392

Yohan

2011/6/29 Yohan Boniface 

> 2011/6/28 Stephen Burrows 
>
>>
>> The "O" formatter - or more specifically, the "Z" formatter - does
>> include that bit of magic. Is there a particular reason for this?
>>
>
> I ask myself the same question. Why for the "Z" (and co) and not for the
> "c" ?
>
>
>> Also, if a timezone is assumed, wouldn't it make more sense to assume
>> the timezone of the project rather than UTC? Rather than noting an
>> inconsistency, can we make this consistent?
>
>
> Defining the default behaviour when the datetime is naive is not that easy,
> in my point of view.
>
> Here is the summary of what I understand (we are talking about the Django's
> dateformat util) :
>
> 1. when the datetime has a timezone, use it : this is what Django does, and
> it's fine.
> => In my point of view, the documentation should be clearer (about the fact
> that the "c" formatter, using isoformat, will add the timezone offset only
> for non naive datetime and about the fact that this behaviour is not
> consistent with other formatters)
> => I'll propose some little patch
>
> 2. when the datetime is naive, what to do ?
> => like I said, I think the answer is not that easy, and Django is not
> completely coherent on the subject
>
>  2.1 Do nothing
>  => this is what Django does for the "c" formatter (as using the
> .isoformat datetime method) [1]
>  => easier, clearer (no magic), but not so user friendly : it means that
> when dealing with naive datetimes, developpers have to manually add the
> timezone everytime (error-prone, not very DRY...)
>
>  2.2 Use the system local timezone
>  => this is what Django does for the "Z" and "O" formatters for example
> (using the time.timezone / .altzone function) [2] [3]
>  => basing the default timezone on the machine local one could be risky
> (and not so "cloud" aware...)
>
>  2.3 Use the settings.TIME_ZONE information
>  => I wonder why this setting is not used by Django here
>  => in theory, this sounds like a good default behaviour
>
>  2.4 Missing something ?
>
> And so the final question is : is there a "good" way to arbitrate the
> handling of naive datetime when formatting them ?
>
> [1]
> https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py<https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py#L126><http://piratepad.net/ep/search?query=L126>
> #L126<https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py#L126>
> [2]
> https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py<https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py#L269><http://piratepad.net/ep/search?query=L269>
> #L269<https://code.djangoproject.com/browser/django/trunk/django/utils/dateformat.py#L269>
> [3] 
> http://docs.python.org/library/time.html<http://docs.python.org/library/time.html#time.timezone><http://piratepad.net/ep/search?query=time.timezone>
> #time.timezone <http://docs.python.org/library/time.html#time.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.