Even if the backend is storing using an ascii backed data type, it should
still return unicode data to Django anyway, so I'm not sure there would be
a difference.
Marc
On 6 November 2014 01:18, Michael Manfre wrote:
>
>
> On Wed, Nov 5, 2014 at 7:53 PM, Shai Berger wrote:
>
>> On Wednesday 05
On Wed, Nov 5, 2014 at 7:53 PM, Shai Berger wrote:
> On Wednesday 05 November 2014 17:29:20 Michael Manfre wrote:
> > We can change the internal type of SlugField for option 1 based upon
> > whether or not the field should be unicode. Whether or not an existing
> > backend stores SlugField in an
Could we do a list of 2-tuples instead of OrderdDict?
--
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+un
On Wednesday 05 November 2014 17:29:20 Michael Manfre wrote:
> We can change the internal type of SlugField for option 1 based upon
> whether or not the field should be unicode. Whether or not an existing
> backend stores SlugField in an ascii char datatype shouldn't dictate
> whether we go with Sl
On 11/05/2014 05:16 PM, Tim Graham wrote:
> Nice work on the DEP. I tend to agree with Carl that I like a 'NAME' key
> in TEMPLATES rather than requiring the use of OrderedDict, but I can
> also see why you don't. I think it might simply the implementation if
> TEMPLATES was always a list of dictio
Hi Aymeric,
Nice work on the DEP. I tend to agree with Carl that I like a 'NAME' key in
TEMPLATES rather than requiring the use of OrderedDict, but I can also see
why you don't. I think it might simply the implementation if TEMPLATES was
always a list of dictionaries rather than allowing it to
> On 5 nov. 2014, at 09:42, Aymeric Augustin
> wrote:
>
> I'll let you know when I have a specification ready for review.
I just pushed an implementation plan for shortcuts and template responses.
Search for `render(request, template_name` in the DEP or look at the history in
https://github.c
See the thread on this list titled "1.8 release planning" for details on
the current proposal (If 1.8 is the next LTS, support for 1.4 would be
extended 6 months after 1.8 is released, etc.). Feedback on that proposal
appreciated.
On Wednesday, November 5, 2014 9:59:03 AM UTC-5, Marc Tamlyn wro
We can change the internal type of SlugField for option 1 based upon
whether or not the field should be unicode. Whether or not an existing
backend stores SlugField in an ascii char datatype shouldn't dictate
whether we go with SlugField(unicode=True) or UnicodeSlugField(). Let me
rephrase the ques
The current plan appears to be that 1.8 will be the next LTS, with 1.4
keeping security support until 6 months after 1.8's release. We will be
having a core meeting in 10 days in Amsterdam, I'll make sure it's
finalised.
Marc
On 5 November 2014 14:55, Rob Yates wrote:
> On Monday, August 25, 20
On Monday, August 25, 2014 6:10:52 AM UTC-4, Aymeric Augustin wrote:
>
>
> 1.4 is LTS until March 2015. Based on past release schedules, 1.8 should
> be released a few months later.
>
> We could extend 1.4 support a bit and then make 1.8 the next LTS. In my
> opinion, that's the most reasonable p
It feels to me more like an option to SlugField and I feel UnicodeSlugField
is a bit ugly. If however we find an example where Michael's point is valid
(an external 3rd party backend which uses ascii chars for SlugField now)
then we should go with that.
On 5 November 2014 03:20, Michael Manfre wr
Hi Collin,
2014-11-05 3:21 GMT+01:00 Collin Anderson :
> On Tuesday, 4 November 2014 17:30:27 UTC-5, Aymeric Augustin wrote:
>
I suspect the only reason why it isn't is to avoid changing the default
>> settings (django.conf.global_settings).
>>
> Right. Can we uncomment it anyway?
>
The problem
Hi Carl,
2014-11-05 0:02 GMT+01:00 Carl Meyer :
I can imagine a scenario where I am
> implementing a specialized project-specific template backend (for some
> reason - let's hand-wave past this), and it would feel extraneous to be
> forced to name an app sub-directory that I plan to never use.
>
14 matches
Mail list logo
