On Thu, Aug 1, 2013 at 6:57 PM, CM <cmpyt...@gmail.com> wrote: > It seems that if I can make a change to the code and then immediately test it > by running the Python interpreter and finding out, in a few seconds, if it > worked, I am going to be *much* more likely to use this trial-and-error > approach than if I had to use a compiled language, since compiling takes so > long. E.g. "Oh, that doesn't work? Maybe if I add this...no. OK, what > about if I increment that? No...OK, wait, maybe this...AH! That worked." > (obviously it is not quite that uninformed all the time).
I would say that, often, that's a fine way to do things. With two very similar languages I work with (Python and Pike), there's a slight difference in the interpretation of a range subscript: Pike v7.8 release 700 running Hilfe v3.5 (Incremental Pike Frontend) > "Hello, world!"[..5]; (1) Result: "Hello," > "Hello, world!"[5..]; (2) Result: ", world!" Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32 >>> "Hello, world!"[:5] 'Hello' >>> "Hello, world!"[5:] ', world!' Python counts the boundaries between characters, Pike counts the characters themselves. So using the same number on different sides of the colon yields the exact same string in Python, but in Pike, both strings contain the indexed character. Both ways make sense, and the easiest way to make sure I haven't mucked something up - in either language - is to try it. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
