2 new comment-like characters in Python to aid development?

Diez B. Roggisch deets at nospam.web.de
Fri Mar 9 12:56:19 EST 2007


>> The ? has no meaning. It only has a meaning for an editor.
> 
> So it _does_ have meaning! I'm sorry I just don't buy into this kind
> of abstract programming ideology, and I never really have. I don't
> care what the interpreter finds meaningful and neither, on a day to
> day basis, do most users, I'm sure. It seems like the same kind of
> aesthetic ideology that leads lots of programmers to feel repulsed by
> Python's whitespace block delimiting. There's a more important
> principle being missed by them: the human factor. The guy or gal who's
> actually _using_ this stuff. BTW I don't mean to imply that you're not
> thinking about human readability / useability, just that you don't
> seem to be arguing from that basis.

I certainly do. Because a comment is always a comment. If you happen to 
have a multi-line comment (in python that is) that spans more than a 
page of your current terminal, you clearly will see it as such when 
piped through less - a frequent tool for looking into code of libraries 
for example. At least for me, and I guess some other coders as well.

But a tiny ? or !, the latter one massively changing the semantics of 
the displayed code? I'm not too positive that this will be getting the 
proper attention needed when comprehending the code.

Even the multiline-comments of C are easier, because they feature an 
end-mark. Which for one _is_ easier to implement, thus even "less" might 
implement some syntax  hi-lighting based on it (if the terminal supports 
that, that is. I've been doing my fair share of last-minute hacking 
through malconfigured ssh-connections in vi, no syntax-highlighting 
whatsoever) - while it is much less probable that "less" will grow a 
full blown python parser just for the sake of hi-lighting a !-prefixed 
block of code.


FWIW, I'm totally convinced that the addition of this feature to the 
interpreter itself would be a minor operation that wouldn't cause much 
headache from a implementation POV. It's just I don't buy into its 
usefulness.

> 
>>> What we're talking about here is a form of 'alternate commenting
>>> style'. With the IDE's cooperation it'd work on whole blocks at once,
>>> it would highlight without disrupting the code concerned (at least the
>>> way I'm envisaging it), it would be versatile (could probably be used
>>> for as big a variety of purposes as the # comment), and yes, it'd be
>>> persistent, which is how it would be different from any IDE-based
>>> highlighting.
>> I think you contradict yourself here. On the one side, you want it not
>> disturbing to the eye, yet it should be highlighted, so it will be directly
>> noticed by that same eyes.
> 
> You misread me. I wasn't talking about visual disturbance but 'code
> disturbance'. Let me rephrase..
> "..it would highlight without causing the highlighted code to be
> ignored by the interpreter.."


What do you mean by code-disturbance? Programming is usually something 
that needs carefully assembled sequences of characters, with some 
seemingly minor interpunction characters becoming extremly meaningful. 
And you want to add to that the complexity of something that has _no_ 
meaning at all - for the language. To me that is a disturbance. Clearly 
a matter of taste, though.

> 
>> it _is_ an disturbance. And with an IDE that stores such information in
>> e.g. project metainformation, you can even have the persistence, without
>> the disturbance and without altering python.
> 
> So it's fine and wonderful to add a massive chunk of code to IDEs to
> introduce jargon-strewn behaviour that newbies have little hope of
> comprehending yet alone taking advantage of, and which will inevitably
> behave differently in any IDE that does get around to providing it?
> But adding two special characters to the core language is 'messy'?

Adding two characters to the language from which one's only purpose is 
to support the introduction of jargon-strewn behavior that newbies have 
little hope of comprehending let alone taking advantage of, and which 
will inevitable behave differently in any IDE that does get around 
providing it.

I couldn't say it better. It is exactly my point: the ? is _nothing_ 
without an IDE, where _none_ of them is forced to interpret and 
represent it by any means. Yet still you want to add it? Sorry, I can't 
buy that.

Besides, the whole purpose of IDEs is to add massive chunks of code to 
e.g. analyze class structures, show syntactic errors even before the 
code is run and so on... so if you accept that editing code is more than 
poking with a hex editor on your hard disk image, I fail to see the 
problem of adding such chunks of code if it is feasible.

> I can't argue with your aesthetic dislike of the proposed syntax, it's
> just the reasoning you use to support your stance that doesn't ring
> true to me! (I trust no offense is caused.)

Certainly not. And I don't intend to cause offense myself!

Diez



More information about the Python-list mailing list