nel wrote:
> Torsten Becker, 24.08.2011 04:41:
>>
>> Also, common, now simple, checks for "unicode->str == NULL" would look
>> more ambiguous with a union ("unicode->str.latin1 == NULL").
>
> You could just add yet another field "any",
On Tue, Aug 23, 2011 at 18:56, Victor Stinner
wrote:
>> kind=0 is used and public, it's PyUnicode_WCHAR_KIND. Is it still
>> necessary? It looks to be only used in PyUnicode_DecodeUnicodeEscape().
>
> If it can be removed, it would be nice to have kind in [0; 2] instead of kind
> in [1; 2], to be
On Tue, Aug 23, 2011 at 10:08, Antoine Pitrou wrote:
> Macros are useful to shield the abstraction from the implementation. If
> you access the members directly, and the unicode object is represented
> differently in some future version of Python (say e.g. with tagged
> pointers), your code doesn'
On Tue, Aug 23, 2011 at 18:27, Victor Stinner
wrote:
> I posted a patch to re-add it:
> http://bugs.python.org/issue12819#msg142867
Thank you for the patch! Note that this patch adds the fast path only
to the helper function which determines the length of the string and
the maximum character. T
On Tue, Aug 23, 2011 at 08:15, Antoine Pitrou wrote:
> So why would you need three separate implementation of the unrolled
> loop? You already have a macro named WRITE_FLEXIBLE_OR_WSTR.
The WRITE_FLEXIBLE_OR_WSTR macro does a check for kind and then
writes. Using this macro for the fast path wou
On Mon, Aug 22, 2011 at 18:14, Antoine Pitrou wrote:
> - You could trim the debug results from the benchmark results, this may
> make them more readable.
Good point, I removed them from the wiki page.
On Tue, Aug 23, 2011 at 18:38, Victor Stinner
wrote:
> Le mardi 23 août 2011 00:14:40, Antoin
Hello all,
I have implemented an initial version of PEP 393 -- "Flexible String
Representation" as part of my Google Summer of Code project. My patch
is hosted as a repository on bitbucket [1] and I created a related
issue on the bug tracker [2]. I posted documentation for the current
state of t
