Russell Keith-Magee wrote:
> I've just committed [12003], which reverted commit [12000].
Sorry, my bad: couldn't resist the nice rev number. ;-)
> This mirrors commit [11941], which reverted [11881]. These commits all
> relate to translation updates for the 1.0.X branch.
>
> Translations should
http://code.djangoproject.com/ticket/12445
RFC 3986 [1] defines the following as "reserved" and "unreserved" characters:
reserved= gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
unrese
I just upgraded to the latest trunk today and the admin now throws an
exception http://dpaste.com/138130/ when I try and save to a
ImageField. I messed with it a bit to make sure that it was not
something else in my code that could be causing the error. It looks
like the error only occurs when I ha
Hi all,
I've just committed [12003], which reverted commit [12000]. This
mirrors commit [11941], which reverted [11881]. These commits all
relate to translation updates for the 1.0.X branch.
Translations should *not* be backported to the 1.0.X branch. The 1.0.X
branch is in security fix only mode
I just implemented [1] the ComplexNumberField using the CompositeField
class. It also shows that it is possible to change subfield attributes
inside the __init__ method since the subfields are deep copied for every
instance.
I hope that the test cases are mostly complete. I plan on writing down
th
On 2009-12-26 05:17, Andy Mikhailenko wrote:
> Maybe I'm missing something, but I don't understand how is this
> different from having a bunch of separate fields. The CompositeField
> adds a namespace, but foo.bar_x=1 seems to be no harder to read than
> foo.bar.x=1. I must admit that this field
