>
> | Now, I started programming when I was 8 with BBC Basic.
>
> Hey, likewise! (Except I was 12 when it came out!)
I think it came out before I was 8, and I started out with print and
input. Not sure if that's 'real' programming - I don't think I graduated
to ifs and thens and gotos and gosubs for a while.. Uhm, Or was it 'def
proc' et al for BBC Basic? Brain holes leaking old stuff out :)
> | Print "There are "+number+" ways to skin a "+furryanimal
>
> perfectly sound Python code, as far as it goes, altho' obviously
> "Print" is spelt "print" in Python, and if that number is in fact
> a number it'll need to be str ()-ed first.
Blame outlook and AutoCaps. If number were a number I would write
print "There are",number,"ways to skin a "+furryanimal
..something I like about python, 'cause having been pathalogically
avoiding %'s etc.. I have learned to hate going "string "+str(number)+"
string"
>
> | But nowadays, I see things like this all over the place;
> |
> | print("There are %s ways to skin a %s" % (number, furryanimal))
>
> The outermost brackets are (at the moment) unnecessary in python,
Oops :)
> altho' print is slated for replacement by a function in Python 3.0
> at which point they'll be necessary.
? Why do that, point me at a PEP if required and I'll read it :)
>
> number = 3
> animal = "cat"
> print "There are %d ways to skin a %s" % (number, animal)
>
> | Now I understand there can be additional formatting benefits when
> | dealing with numbers, decimal places etc.. But to me, for
> strings, the
> | second case is much harder to read than the first.
>
> I think what it comes down to is just what's most readable in the
> situation in which you're using it. Imagine a rather longer
> string, and one where <number> and <animal> are not short names,
> but calls to some function. Sometimes, since %s will call __str__
> on anything it's passed, it's a quick way to get a string
> representation
> of a more complex object, which you'd otherwise have to str () at
> least.
>
> Also, for me, substitution often reads more naturally because you're
> not breaking the string up with lots of " + xxxx + "..." +
> yyy + "...
> stuff. Again, though, depends on what your code looks like, and how
> readable you find it. Certainly, I wouldn't advocate *pathologically*
> avoiding the "%s" % blah style, but it needn't always be the right
> thing.
>
I am a big fan of easily human readable meaningful names for things, to
the extent that I will quite readily use var or function names
ThatCanBeQuiteLongAndExplanatory() For me, it helps retain the
readbility say, when breaking up a string with lots of + xxx + "etc..
Etc.." + lalala
>It may be easier
> to use the
> dictionary form of the substitution then, eg:
>
> print """
> Long string with %(valueA)s and %(valueB)s and %(valueC)s embedded in
> it at some distance from the end...
> ...
> """ % dict (valueA=1, valueB="blah", valueC=datetime.datetime.now ())
>
> Obviously that dict would likely be defined elsewhere, or could even
> be locals (). Once you get to this stage, though, you might want to
> start looking at templating toolkits like Cheetah, Genshi or any of
> the many others knocking around.
>
That's something I wasn't aware of, and I think I'll try if I find
myself going
"something"+dict['thingummy']+" red ones and "+dict['colour']+" ones"
The dict substitution does feel a bit easier to read compared to the
concatenation, because of the dict[' '] noise.
Matt.
This email is confidential and may be privileged. If you are not the intended
recipient please notify the sender immediately and delete the email from your
computer.
You should not copy the email, use it for any purpose or disclose its contents
to any other person.
Please note that any views or opinions presented in this email may be personal
to the author and do not necessarily represent the views or opinions of Digica.
It is the responsibility of the recipient to check this email for the presence
of viruses. Digica accepts no liability for any damage caused by any virus
transmitted by this email.
UK: Phoenix House, Colliers Way, Nottingham, NG8 6AT UK
Reception Tel: + 44 (0) 115 977 1177
Support Centre: 0845 607 7070
Fax: + 44 (0) 115 977 7000
http://www.digica.com
SOUTH AFRICA: Building 3, Parc du Cap, Mispel Road, Bellville, 7535, South
Africa
Tel: + 27 (0) 21 957 4900
Fax: + 27 (0) 21 948 3135
http://www.digica.com
--
http://mail.python.org/mailman/listinfo/python-list
