[lxml-dev] list-like views?

[Stefan Behnel]

Hi,

Ian Bicking wrote:
> Stefan Behnel wrote:
>> Ian Bicking wrote:
> Atom is fairly strict, so I think if you have HTML embedded you have to
> quote it.  XHTML can be embedded normally.  I haven't thought about
> XHTML yet, though I suppose I should.

I actually meant XHTML, so in that case, you would even have a namespace for
looking up elements.


> For entry.categories it just returns a list of the category tags, and
> you can do, say:
> 
>   for c in list(entry.categories):
>       if c.scheme == 'http://stupid-terms.com':
>           entry.categories.remove(c)

That's what objectify gives you for free, except for the last line, which
would read "entry.remove(c)", as in your second example. Also, it would be
"entry.category", as that's the tag name.


> I already have proxies for some other attributes, like entry.updated
> actually gets parse_date(entry.find('{blahblah}updated').text).

That would be some kind of DateElement in objectify (as I said, Holger
provided something like this a while ago).


> Incidentally, I might also be inclined to add more namespaces to that
> module.  There's some useful attributes in the APP namespace, and some
> common extensions (e.g., reply-to).  So this is really
> stuff-you-might-find-in-feeds, not just the Atom namespace.  But we
> can't assume we'll include *all* useful extensions (I already want to
> add some private extensions to Atom), so there has to be a handy way to
> handle that sort of thing too. Maybe just make it easy to subclass atom

Well, with namespace classes, you can mix any number of namespaces and lxml
will return the right element by itself. So, if you want to use subclasses,
you can just register them for the right tags and they will replace the
original ones.

That's a reason to use a global setup, BTW. Makes it easier to plug support
for other namespaces into Atom.


>>> Anyway, I was thinking of adding something similar to HtmlElement for
>>> .classes, which would expose the HTML classes.
>>> This way you wouldn't have to have methods like has_class, add_class,
>>> and remove_class (or do it manually with string manipulation).
>>
>> Hmm? You meant the class attribute here, right? How should there be
>> more than one?
> 
> The class attribute is a list of whitespace-separated class names, so it
> works on that list.

Ah, ok. Didn't even know that, but it fits CSS, obviously. Then that's
definitely an application for your LifeList.

Stefan