On Thu, Dec 27, 2012 at 7:15 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> 2) under Python 2.x __str__ is implemented as __unicode__
>encoded to utf8.
>
>
> Yes, this is a legacy behavior that I strongly disagree with. It
> makes __str__ / __unicode__ handling for Model
Hi Mikhail,
Thanks for your feedback! Your email touches many topics; can we try
to extract the most important ones and identify what really needs fixing
before the 1.5 release?
> 1) @python_2_unicode_compatible doesn't handle __repr__.
Indeed, this decorator isn't designed to handle __repr__ —
Thanks for the info. Maybe the docs should state this so others don't run
into the same confusion that I ran into?
On Thursday, December 27, 2012 2:10:51 PM UTC-7, donarb wrote:
>
> On Thursday, December 27, 2012 10:39:23 AM UTC-8, Nick wrote:
>>
>> The bottom of the docs says:
>>
>> If you
On Thursday, December 27, 2012 10:39:23 AM UTC-8, Nick wrote:
>
> The bottom of the docs says:
>
> If you notice errors with this documentation, please open a ticket and let
>> us know!
>
>
> Well, I don't know that I would call this an *error*, so I don't think
> opening a ticket is the right
Oh, my description of (5) is not totally correct: u'%r' % bytestring_value
is fine because repr(non_ascii_bytestring) is an escaped 7bit ascii; this
mean HttpResponseBase._convert_to_charset is almost fine (bytes would be of
incorrect encoding, but this won't raise an exception). The argument
Hi there,
First of all, many kudos for the Python 3.x support in upcoming django 1.5,
and for the way it is handled (the approach, the docs, etc)!
I think there are some pitfalls with @python_2_unicode_compatible decorator
as it currently implemented in django (and __str__/__repr__ in
The bottom of the docs says:
If you notice errors with this documentation, please open a ticket and let
> us know!
Well, I don't know that I would call this an *error*, so I don't think
opening a ticket is the right thing to do. Please let me know if I'm wrong.
I would just like to suggest
Hi again,
On Thursday 27 December 2012, Jani Tiainen wrote:
> 27.12.2012 15:32, Shai Berger kirjoitti:
> > On Thursday 27 December 2012 15:16:15 Jani Tiainen wrote:
> >> Just out of curiosity - what's the rationale to duplicate connection
> >> information? Why it's so important?
> >
> > As I
27.12.2012 15:32, Shai Berger kirjoitti:
On Thursday 27 December 2012 15:16:15 Jani Tiainen wrote:
Just out of curiosity - what's the rationale to duplicate connection
information? Why it's so important?
As I noted before, the idea is to use the second connection to write things in
a
On Thursday 27 December 2012 15:16:15 Jani Tiainen wrote:
>
> Just out of curiosity - what's the rationale to duplicate connection
> information? Why it's so important?
As I noted before, the idea is to use the second connection to write things in
a separate transaction. As the name 'auditlog'
On Thursday 27 December 2012 15:11:31 Jani Tiainen wrote:
>
> TEST_MIRROR = 'default' means that instead of creating test database of
> "auditlog" using independent database connection Django will reuse
> connection to "default". That's how Django makes testing of replication
> happen (that's
27.12.2012 14:41, Shai Berger kirjoitti:
Hi Jani and all,
On Thursday 27 December 2012 13:28:23 Jani Tiainen wrote:
27.12.2012 13:08, Shai Berger kirjoitti:
Hi all,
I'm seeing a problem with testing on Oracle, in a setting where there are
two defined databases that reference the same
27.12.2012 14:41, Shai Berger kirjoitti:
Hi Jani and all,
On Thursday 27 December 2012 13:28:23 Jani Tiainen wrote:
27.12.2012 13:08, Shai Berger kirjoitti:
Hi all,
I'm seeing a problem with testing on Oracle, in a setting where there are
two defined databases that reference the same
Hi Jani and all,
On Thursday 27 December 2012 13:28:23 Jani Tiainen wrote:
> 27.12.2012 13:08, Shai Berger kirjoitti:
> > Hi all,
> >
> > I'm seeing a problem with testing on Oracle, in a setting where there are
> > two defined databases that reference the same connection parameters
> > (this is
27.12.2012 13:08, Shai Berger kirjoitti:
Hi all,
I'm seeing a problem with testing on Oracle, in a setting where there are two
defined databases that reference the same connection parameters (this is done
to enable operations in two parallel, separate transactions); the 'other'
database is not
Hi all,
I'm seeing a problem with testing on Oracle, in a setting where there are two
defined databases that reference the same connection parameters (this is done
to enable operations in two parallel, separate transactions); the 'other'
database is not treated as a test database. This means
16 matches
Mail list logo
