Re: Proposal: better support for generating rest apis in django core

[Vincent]

Huge +1 on everything Tom said, except the point about the docs:

Calling out quality packages in some way from the docs
>

The nice thing about developer communities is that they're fairly emergent. 
Consensus is usually formed all the way from the very bottom, on up. This 
works well.

Especially to a newcomer, an innocuous claim like, "X is a decent library 
for Y" from a well-known framework like Django may as well be, "X is the 
library you need to use for Y". This has the unfortunate effect of creating 
a monopoly, which invariably results in stagnation.

-- 
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: Missing timezone support in built-in time template filter

[Russell Keith-Magee]

On Fri, Jun 28, 2013 at 5:33 AM, Warren Smith  wrote:

> Is anyone aware of a reason why the built-in time template filter does not
> have timezone support?  The built-in date template filter has timezone
> support, but I wanting to use the TIME_FORMAT default stuff linked to the
> time filter.
>
> Was timezone considered to be not relevant for the time filter? I found
> the bit in the Time Zone documentation about Django only supporting naive
> datetime.time objects, so I suppose this might have been the justification
> for not supporting timezones in the time filter. However, the time filter
> can be applied to datetime.datetime objects as well, to display only the
> time portion. That might even be the most common use case. It is at least
> my use case. In that context, I would think the timezone IS relevant.
>
> What I'm wanting to be able to do is set settings.TIME_FORMAT = 'g:i a T'
> and then use |time in my templates to get times with
> timezones at the end.
>
> I would prefer not to have to resort to a custom filter for what seems to
> be very generic behavior. What am I doing wrong?
>

Hi Warren,

I can see how what you're describing is a problem, and as far as I can make
out, you haven't missed anything.

The issue is how to handle the ambiguity it introduces; Django has punted
on the problem because what you're describing is an edge case with some
ambiguity, and there are ways to work around the problem.

The problem with datetime.time is that time objects *can't* have a timezone
-- at least, not reliably. For example - If your timezone is EST, and the
time is 10:00 UTC - what time is it in EST? You can't answer that question
reliably because it might be 0500, or it might be 0600, depending on the
date. Although common vernacular often describes the timezone as EST and
EDT, there's actually only one timezone, and part of that timezone
definition is the rules for switching for switching forward and back the
extra hour. Without a date associated with the time, timezone calculations
are error-prone at best.

As a result, since the default usage of |time is on time objects, the
implementation of the time filter doesn't support the use of the T format
specifier.

However, you *can* use exclusively time-related format specifiers in the
date filter; for example:

{{ mydatetime|date:"g:i a T" }}

will work and give you the output you expect, and if you set
DATETIME_FORMAT to "g:i A T", you'll get all datetimes displayed in the
format you describe. The problem is that *all* datetimes will be displayed
like that by default, and you won't ever see the actual date printed.

So - short term, the fix is to use an explicit format string wherever you
want this behaviour. Yes, it's annoying that you can't just set a default,
but it works. Defining a custom filter that implements the default could be
done in about 5 lines of code (including tag registration) if the
repetition of the format string bugs you enough. You can even call that
filter |time if you want - Django's template engine takes the 'newest' tag
registration as the canonical one, so you can overwrite system-provided
tags.

Longer term, I can see that there is something we could address - the
question is how.

What you've described is the ability to set TIME_FORMAT to a value that
won't be valid for the default case (using time objects on the time
filter), so we'd need to come up with an interpretation for how to ignore T
(and any other timezone-sensitive format values) when it can't be used. I'm
not sure how I feel about ignoring formatters as an approach -- my gut
reaction is that it's a bad idea, but I can see how it *might* work.

Another approach might be to make |time call on the |date format - however,
this means you would need to set DATETIME_FORMAT

A third approach would be a new setting, for AWARE_TIME_FORMAT that would
only get used if you pass a datetime object to |time; this *would* be able
to use T as an option. However, this means introducing a new setting, which
is rarely a good answer to a problem.

If you've got any other ideas, I'd be interested in hearing them. Either
way, this is worth a ticket so that the idea/problem isn't forgotten.

Yours,
Russ Magee %-)

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

Missing timezone support in built-in time template filter

[Warren Smith]

Is anyone aware of a reason why the built-in time template filter does not 
have timezone support?  The built-in date template filter has timezone 
support, but I wanting to use the TIME_FORMAT default stuff linked to the 
time filter.

Was timezone considered to be not relevant for the time filter? I found the 
bit in the Time Zone documentation about Django only supporting naive 
datetime.time objects, so I suppose this might have been the justification 
for not supporting timezones in the time filter. However, the time filter 
can be applied to datetime.datetime objects as well, to display only the 
time portion. That might even be the most common use case. It is at least 
my use case. In that context, I would think the timezone IS relevant.

What I'm wanting to be able to do is set settings.TIME_FORMAT = 'g:i a T' 
and then use |time in my templates to get times with 
timezones at the end.

I would prefer not to have to resort to a custom filter for what seems to 
be very generic behavior. What am I doing wrong?



-- 
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: Proposal: better support for generating rest apis in django core

[Tom Christie]

Hi Karol,

  Thanks for bringing that up.  I'll start by saying that I would love to 
see richer Web API support in core Django - in my opinion there are 
absolutely some fundamentals that could be addressed.   However, I 
personally think that the benefit that we'd get probably isn't (yet?) worth 
the very large amount of work that would be required.  I'll get onto that 
in a moment, but I'm first going to go through some of the core components 
that could be addressed...

Request parsing is an obvious one.  Right now it's actually quite awkward 
to deal with parsing form data in anything other than POST requests. 
 There's subtleties to get right for supporting both url-encoded and 
multipart forms, handling charset encodings, handling corrupt data, and 
dealing with the various possible states of the underlying stream.  That 
gets more complicated again if you want to support both form data and json 
or other content types.  That sort of thing has to be tackled each time by 
every new API framework, and it'd be a good candidate for better support in 
core.  REST framework's approach is to introduce a `request.DATA` that 
supports parsing arbitrary content types depending on which parser are 
registered (either globally or per-view).  Something similar in Django 
would be valuable, because it's a minimal amount of API, but addresses a 
fundamental issue.

Serialization is another fundamental that's currently lacking.  This is a 
deceptively difficult area, particularly the deserialization and validation 
aspects.  Django's forms aren't sufficient for many of the use-cases you 
need to support with APIs.  A mature, complete serialization framework 
needs to be able to support nested objects, various types of representation 
for relationships, support for both ORM and non-ORM data, serializing and 
deserializing from composites of models (eg both User data and UserProfile 
data in a single representation), and various other bits & pieces.  Ideally 
a serialization framework should be flexible enough that it's equally 
capable of rendering a model instance into an HTML form representation, as 
it is of rendering it into JSON.  Furthermore, if someone wanted to get a 
serialization framework into Django it'd make sense if it could also be 
used to replace the existing fixture loading/saving.  Getting a really 
decent serialization framework into Django would obviously be a valuable 
thing to do, as it'd give us all a common, well-supported way of doing for 
Web APIs what forms currently allow us to do in Web apps.  However, it'd 
evidently require a very large amount of work to successfully land in 
Django.

Content negotiated responses are another possible candidate.  Content 
negotiation is a core component of Web APIs, but we've currently no support 
in Django for dealing with it.  There's not any great value in each new API 
framework solving content negotiation again, because there's a reasonably 
consistent set of rules about how it should be handled.  Being able to 
return a response and have it render into various formats depending on the 
client request is something that could be dealt with in core Django once, 
and then reused by any API framework.

Another area worth mentioning is authentication - in particular CSRF 
protection.  The right way to deal with CSRF protection in Web APIs is 
non-obvious.  Session authentication is valid for AJAX clients, and should 
require CSRF protection.  Other authentication types such as OAuth are also 
valid but should not require CSRF protection.  Handling that in a correct, 
secure way is fiddly, and something that I'm personally a little 
uncomfortable with API frameworks having to individually deal with.

I think it's feasible that we could address some of these core ares, and 
still leave plenty of space for API frameworks on top of Django to 
experiment and thrive, while improving the baseline support for folks using 
just Django.

Back to the point, though.  The amount of work that'd be required to 
comprehensively address this in core would be pretty huge.  We're in decent 
situation at the moment, with at least a couple of great, really 
well-supported API frameworks as third-party packages.  Having those 
packages independent to Django is disadvantageous in that it fragments the 
already limited resources of our community, but it's also advantageous in 
that they can iterate more quickly than core Django, as well as being able 
to take opinionated design decisions that suit their domain.

Django's ecosystem is pretty much it's biggest strength.  In my opinion the 
cheapest, most beneficial option would be to look at ways to better promote 
third party packages from within the documentation.  Obviously there's some 
discussion to be had about how to do that in a fair and open way, while 
still allowing an element of curation and ensuring that packages meet a 
required quality.  Calling out quality packages in some way from the docs 
would help new