Again: Please hear my plea: print without softspace

[Stephen Horne]

On Fri, 05 Mar 2004 12:30:35 -0700, David MacQuigg <dmq at gain.com>
wrote:

>In reading someone else's code, I rely on the *syntactic* difference
>between functions and statements to convey possibly different
>*symantics*.  If it says
>print a,b,c
>I know exactly what that statement means.  If it says
>prn(a,b,c)
>I know to look for a definition of 'prn'.

Technically debatable. I doubt that I'd recognise _all_ built-in
functions on sight, for instance, and they need to be looked up in the
Python manual just as statements do. And if you can remember all
built-in functions, then why not memorise all statements?

>The keyword difference is essential, because you *can* say
>print(a,b,c)
>and still be using the built-in print statement (although with a
>slightly different result.)

Yes - that's why I mentioned tuple-related problems.

>I
>prefer the added readability of a more consistent use of parens over
>the convenience of leaving them off.

I'm not sure that 'consistent use' is a reasonable argument with
parens. They are used for a number of things - function calls,
precedence override, tuples (yes, I know the 'it's the commas that
make it a tuple' argument, but that doesn't work for the empty tuple
at least), argument lists in 'def' and inheritance in 'class' are the
most obvious off the top of my head. I'm sure there's another odd bit
of syntax or two where brackets are needed if I put some thought into
it.

A little less 'overloading' of brackets could arguably be a good
thing.

That said, I don't necessarily disagree with you - I'm mostly just
curious what the implications would be.

>Now if we want to talk about getting rid of 'self.' ... :>)

Not sure about that one. I have used C++ a lot, which means that it
does sometimes bug me. But OTOH...

The name 'self' is just a convention. You are free to call it what you
want.

In C++, a very common naming convention suggests using an 'm_' prefix
for all member variable names. I got the habit of using 'f_' instead
(standing for field) a long time ago and it stuck, but that probably
just means I'm wierd. Anyway, this is really just an extension of an
old C convention where parameters get a 'p' or 'p_' prefix, locals get
and 'l' or 'l_' prefix etc.

Changing the underscore to a dot in C++ gives the same result as using
'm' instead of 'self' in Python. OK, semantically you are doing
slightly different things - but in readability terms its much the same
thing. IMO a standard convention is worth more than enough in
readability terms to justify typing 'self' in full, but really what
Python requires is no different to what a lot of experienced C++
programmers tend to do anyway - it's just a clear, explicit indication
of the scope of the identifier you are referencing.


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk