[lxml-dev] objectify parses 't' and 'f' as BoolElement?

[jholg at gmx.de]

Hi,

> > An instance of a datatype that is defined as ·boolean· can have the
> following legal literals {true, false, 1, 0}. 
> > ...
> > "
> > 
> > Objections to restricting this to said literals, again?
> 
> No. I don't think something as short as 'f' and 't' is worth being
> considered a boolean value by default.
> 
> Note that '0' and '1' will never be considered boolean unless there is a
> type hint, so the only literals that will become boolean by default are
> 'true' and 'false'.

Which is due to the standard objectify lookup order.

> Can you do the change and add a comment on this to the changelog?

Done:
https://codespeak.net/viewvc/?view=rev&revision=65803

A question, though:
I noticed some optimization wrt to using _cstr() on the text and then comparing the resulting C string in the 2.0alpha I previously used.

Curious about what _cstr() does I checked, it is a shortcut to PyString_AS_STRING.

Python docs say:
char* PyString_AS_STRING(PyObject *string)¶
    Macro form of PyString_AsString but without error checking. Only string objects are supported; no Unicode objects should be passed.

That basically means I *cannot* use _cstr() and C string comparison for __parseBoolAsInt(), as I would run into havoc with unicode, right?

Holger
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01