New statement proposal for Python
tim.one at home.com
Mon Jun 18 00:45:11 CEST 2001
> That leaves the only post-1.0 addition, "assert". It took years to get
> that in -- although it's hard now to remember exactly why. The
> primary reason it's a keyword is so the compiler can eliminate it under
> Not sure I understand that motivation... the compiler under -O can
> eliminate non-keyword stuff too: [via __debug__]
Yes. But if assert were a builtin function instead, the compiler couldn't
know by magic that the user *wanted*
assert(x < y, "oops")
wrapped in an "if __debug__:" block, because the compiler can't know that
"assert" refers to the builtin function and not something else (btw, we have
to fix that someday! it's irritating). __debug__ was an implementation
mechanism created to *support* assert, and was-- in good Python
fashion --exposed so that adventurers could dream up other uses for it too.
__debug__ wasn't "the feature" here, though, "assert" was.
> A pure convention is weaker than an advisory mechanism. There is no
> advisory mechanism for "constants" (except as attributes in a suitable
> object) -- JUST the convention.
> That may be a tad too weak in some cases (I'm neutral on that). It
> sure discourages some people from learning enough Python to see it
> doesn't matter.
Oh, the list of reasons people have for rejecting Python is as long as the
number of people who have bothered to report on it. There's too much to be
done that would help actual Python users to worry too much about determined
> The advisory __whatever mechanism, which supplemented the purely-
> conventional _whatever one, did help to make a couple Python converts
> in my experience already -- they'd walk away BUT, when they saw there
> WAS a way to make stuff private-enough (C++'ists DO know that deep
> down there's no real guarantee, just convention;-), they kept going for
> long enough to see it's not a big issue either way. I suspect similarly
> weak-but-not-totally-inexistent mechanisms for other kinds of advisory
> protection would have similarly positive effect.
This is one of the functions the newsgroup serves, is it not? If anyone had
the determination to *search* first, they'd find these frameworks invented
and reinvented over & over in "confused newbie" threads. I'm not sure it's
the framework that wins them over in the end, though: often it appears more
the discussion that goes along with it. From that view, I'm not sure that
"canning" these frameworks would do as much good. If someone wants to try,
though, register it with the Vaults of Parnassus and have at it.
More information about the Python-list