On 16 déc. 2011, at 20:55, Ian Clelland wrote:
> Seconded; although, like Joseph above, I have also thought that it would be
> helpful for module writers to have access to django.utils.py3, to be able to
> start writing code that will work on both Django 1.4 and 1.5+.
>
> I don't know if it's c
Thirded.
On Fri, Dec 16, 2011 at 5:55 PM, Ian Clelland wrote:
> I don't know if it's completely warranted; it would mean putting a piece
> of code into core that is untested, and isn't used by any part of core, but
> it would be handy to have.
As I understand it, "untested and isn't used by a
On Fri, Dec 16, 2011 at 8:59 AM, Vinay Sajip wrote:
>
> On Dec 16, 12:45 am, Ian Kelly wrote:
>
> > The problem with merging it and labeling the support as "experimental"
> > is that the changes are of such a fundamental nature that they could
> > easily break things in 2.x, not just in Python 3.
On Dec 16, 12:45 am, Ian Kelly wrote:
> The problem with merging it and labeling the support as "experimental"
> is that the changes are of such a fundamental nature that they could
> easily break things in 2.x, not just in Python 3.
Agreed, it's too risky to merge in 1.4 this late in the day.
The similar applies to octal constant suggestion: If python 2.5 is not
supported is may be better to replace 0777 with 0o777.
* http://docs.python.org/whatsnew/2.6.html#pep-3112-byte-literals
*
http://docs.python.org/whatsnew/2.6.html#pep-3127-integer-literal-support-and-syntax
--
You received
Great effort!
What about using
from __future__ import unicode_literals
instead of wrapping every constant with a "u" or "b" functions?
Python 2.6 support 'b' notation so if python 2.5 is not supported there is
no need for "u" and "b" functions.
--
You received this message because you
