[Types-sig] A late entry

[bwarsaw@cnri.reston.va.us]

font-lock is only one of the problems, and even it is only partially
driven by regexps.  There are C primitives that handle things like
parsing over a string, comment, or s-expression.  These cannot be
taught that a non-embedded unescaped tick opens a string sometimes but
not other times.  Having actually implemented support for dual-comment
styles in a single buffer (i.e. /*...*/ and //...\n) I can tell you
that this stuff is really really tricky.

So somebody (not me :) is either going to have to rewrite the syntax
parsing model and primitives from scratch, or throw out anything that
actually uses the primitives.  Font-locking is one thing, but there
may be more subtle breakages.  I have no idea how well cperl-mode
handles this stuff, but they've already been down that road.

You could also argue that Py3K shouldn't have to cater to a 20 year
old technology like Emacs, and you'd probably be right.  I'd still
grumble though :) I'd also be interested in seeing what the IDLE
developers think about such syntax changes.

My prediction stands: it'll never get done, even if it were possible.
Meaning, I really don't think it's worth the effort, and I can't
imagine anybody actually spending the time to do it.

>>>>> "JV" == John Viega <John@list.org> writes:

    JV> Now that might not be worth the effort, but I'd like to assume
    JV> that the emacs problems can be fixed and are worth fixing to
    JV> gain a syntax that's more natural to people who are actually
    JV> familiar with this stuff.  At least, let's please do that for
    JV> the sake of discussing these concepts in this thread, because
    JV> I get confused very easily :)

Sure!  Use whatever notation makes sense for the current discussions.
You're first point is more interesting because I don't think /any/ of
these typing issues will seem natural to the vast majority of Python
hackers.  I could be wrong, and besides you know my biases already, so
I'll shut up now :).

-Barry