At 04:11 PM 7/25/2008, Alan Gauld wrote:
"Dick Moores" <[EMAIL PROTECTED]> wrote
Certainly Beautiful Soup will not be muh longer and a lot more elegant and probably more resilient.
Alan, expand a bit, please. Longer? Resilient?

Longer as in lines of code. BS is good for extracting several different parts from the soup, but just to pull out one very specific item the setup and so on may mean that the framework actually works out the same or longer than your code.

Resilient as in able to handle unexpected changes in the HTML used by the site or slight changes in formatting of the results etc.

But to extract a single piece of text in a well defined location then your approach although somewhat crude will work just fine.
Crude? What's crude about my code?

Its just a little bit too hard coded for my liking, all that splitting and searching means theres a lot of work going on to extract a small piece of data. You iterate over the whole page to do the first spliot,

Ah. I had the idea that it would be better to split it into its natural lines, by line 7. But I could have just started with the first relevant split.

then you iterate over the whole thing again to find the line you want. Consider thios line:

if 'JPY' in x and '>USDJPY=X<' in x:

Sincy JPY is in both strings the first check is effectively redundant but still requires a string search over the line. A well crafted regex would probably be faster than the double in test and provide better checking by including
allowances for extra spaces or case changes etc.

I'll try to do that.

Then having found the string once with 'in' you then have to find it again with split().

Do you mean string x? After c = x (line 10), the next split is on c. I'm not finding it again, am I?

You could just have done a find the first time and stored the index as a basis for the slicing later.

You also use lots of very specific slicing values to extract the data - thats where you lose resilience compared to a parser approach like BS.

Since I posted I found that I could add some resilience by extending the end of the slice and then cutting back with an rstrip().

I haven't the slightest idea what a parser is. But I'll find out while learning BS.

Again I suspect a regex might work better in extracting the value. And hard coding the url in the function also adds to its fragility.

I can't imagine what else is possible?

Stylistically all those single character variable names hurts readability and maintainability too.

I was at a loss as to what variable names to use, so I figured I'd use a, b, c, .. in order, because I thought it was obvious that I was narrowing the search for the yen rate. Could you give me an idea of what names I could use?

I want to improve, so please tell

It will work as is, but it could be tidied up a bit is all.

Thanks Alan, for your tough look at the code. I appreciate it.

Dick
===================================================
Have you seen Kelie Feng's video introducing the terrific and free
IDE, Ulipad? <http://www.rcblue.com/u3/>
Get Ulipad 3.9 from <http://code.google.com/p/ulipad/downloads/list>
svn for the latest revision <http://ulipad.googlecode.com/svn/trunk/>
Mailing list for Ulipad: <http://groups-beta.google.com/group/ulipad>

_______________________________________________
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Reply via email to