On 23 Jan, 15:12, Stefan Behnel <[EMAIL PROTECTED]> wrote: > > Paul Boddie wrote: > > I'm not disputing the benefits of the ElementTree approach, but one > > has to recall that the DOM is probably the most widely used XML API > > out there (being the one most client-side developers are using) and > > together with the other standards (XPath and so on) isn't as bad as > > most people like to make out. > > I didn't deny that it works in general. However, it does not fit into the > standard ways things work in Python.
You're only one step away from using the magic word. I agree that writing getAttribute all the time instead of, say, using magic attributes (provided the characters employed are lexically compatible with Python - another thing that people tend to overlook) can be distressing for some people, but as usual the language comes to the rescue: you can assign the method to a shorter name, amongst other things. If you want to stray from the standards then with some APIs (as you know), you can override various classes and provide your own convenience attributes and methods, but the interoperability remains beneath. > > Furthermore, I don't think it does > > Python much good to have people "acting all Ruby on Rails" and telling > > people to throw out everything they ever did in order to suck up the > > benefits, regardless of the magnitude of those benefits; it comes > > across as saying that "your experience counts for nothing compared to > > our superior skills". Not exactly the best way to keep people around. > > I would have formulated it a bit different from my experience, which usually > is: people complain on the list that they can't manage to get X to work for > them. Others tell them: "don't use X, use Y", implicitly suggesting that you > may have to learn it, but it will help you get your problem done in a way that > you can /understand/ (i.e. that will fix your code for you, by enabling you to > fix it yourself). If people feel that they've solved 90% of the problem using tools they're become familiar with, I think it's somewhat infuriating to be told to forget about the last 10% and to use something else. We don't know how nasty the code is in the case of this particular inquirer, but I've seen nothing recently where the DOM specifically was obstructing anyone's comprehension. In one case, had PyXML or minidom been up-to-date, the solution would have been within easy reach (the textContent property), but with everyone being waved off to greener pastures, there's probably little gratitude to be had in doing the legwork to fix and enhance those implementations. [...] > > like the DOM stuff, if the support for standardised/ > > recognised technologies is perceived as deficient, and given the point > > above about glossing over what people themselves bring with them to > > solve a particular problem, then people are quite likely to gloss over > > Python than hear anyone's sermon about how great Python's other XML > > technologies are. > > It's not about "other XML technologies", it's only about making the standard > XML technologies accessible and usable. It's about designing interfaces in a > way that matches the tool people are using anyway, which in this case is > Python. Well, the standard XML technologies include those covered by PyXML, like it or not, and whilst some APIs may be nicer than the variants of the standard APIs provided by PyXML, there's a lot of potential in those standards that hasn't been exploited in Python. Consider why the last Web browser of note written in Python was Grail, circa 1996, for example. Paul -- http://mail.python.org/mailman/listinfo/python-list
