Coding standard: Prefixing variables to indicate datatype

Martin Maney maney at pobox.com
Sun Jan 19 06:05:01 CET 2003


Steve Holden <sholden at holdenweb.com> wrote:
> Well, judgin by the number of times this topic comes up, and the vehement
> and long-drawn out arguments it has spawned [with some proponents *refusing*
> to admit the rationality of the way it's currently done even in the face of
> reasonable and reasoned explanation form illuminati such as Alex Martelli)
> it takes some people longer than others.

That's because they're right: it's not rational.  <wink>

> Despite the clear heavy-handedness of the alternative approach, not everyone
> is persuaded.

<nod> Making it a method of sequences would be almost equally
irrational.

'join' is not sensibly a method of either strings or sequences.  It is
a string _constructor_.

[oops, lost Erik's attribution line]:
>> Furthermore, it's inherently a string-based operation, therefore the
>> method should go on the string.

I agree that join is closely related to string objects, but that
doesn't make it any more rational to write it as a method of an object
that is in fact one of two arguments to the constructor... the optional
argument, at that!

>>  I personally find ','.join(S) extremely inuitive and readable.

I find it quite learnable and don't dislike it - the advantage of not
needing to import the string module is worth the cost - but I doubt I
will ever agree that it's actually sensible.  string.join() was really
the proper logical form if "string" were a class rather than a module. 
Perhaps making it a builtin would have been the best compromise between
logic and practicality?




More information about the Python-list mailing list