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

[dbhbarton at googlemail.com]

> But all of them are clear on how they work: they affect one line, or have a
> bracket style like /* */ and thus demark clearly what they affect. Even
> someone not fluent in the language in question will quickly grab what they
> mean.

There's nothing remotely fuzzy about how wip or halt comments would
work, nor anything unclear about what they would affect. Nor are they
remotely difficult to explain. They just haven't been employed before,
to my knowledge, even though the underlying effects seem to be a
reasonably common requirement.

> But the key-difference is that the comment in python has a meaning for the
> interpreter - ignore this.

OK that is true. But it's true for the halt comment as well.


> 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.


> Not in my opinion -

;p


> > Would if I could!
>
> Well, grab eric3, it's written in python, and teach it to do so! It's an
> exercise in python then :)

I may do that. Thanks for bringing it to my attention.


> > 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.."


> 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'?

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.)