J2 paper 0.2.1

[Paul Moore]

"Robert Brewer" <fumanchu at amor.org> writes:

> First, thanks for the comments!
>
> Paul Moore wrote:
>> 1. I differ on the "it doesn't matter what the keyword is" statement.
>>    On the contrary, my view could completely change depending on the
>>    keyword - I'd loathe "predef", whereas "using" is acceptable to me.
>>    Putting the proposal forward *without* an agreed keyword isn't
>>    (IMHO) fair to people who have this view.
>
> I understand your emotion, now, but not your reasoning, and in the
> absence of that, I can't generate a fix for the proposal. If you could
> go into more detail *why* you would loathe predef, it would go a long
> way toward allowing a stronger statement in the doc. I feel "using" has
> positives, but I don't know what the negatives of "predef" are.

That's fair. I'm not sure I fully understand my own reasoning, but
I'll see what I can do.

My biggest problem, I guess, is that "predef" isn't a real word.
Possibly one of the reasons I feel more comfortable with "using" is
that there is prior art for it being a language keyword (C++ and C#)
even though it doesn't mean anything remotely similar in those
languages.

But I don't want to get sucked into the potentially endless arguments
over what keyword to use. I really don't care enough. And from your
point of view, I don't think my vote is important enough that
catering to my likes and dislikes is a key point.

On the other hand, I *can* defend an argument that the proposal must
take a stance on the keyword proposed. The existence of people (me,
as an example :-)) whose vote would be changed by the choice of a
keyword implies that not taking a stance leaves those people with no
basis for making their decision. Of course, how significant this
argument is depends on how many people fall into this category - and
I have no facts on that. By pointing out that the two key contenders
represent opposite extremes to me, all I can hope to do is to prompt
people to think about how much the choice of keyword matters to them.

>> 2. Does the patch support decorating classes? The @ syntax *might* by
>>    now (in CVS), there was discussion of adding it but I'm not sure it
>>    went in. The patch should probably provide the same functionality
>>    as CVS @-syntax, rather than just 2.4a2.
>
> The patch does not support decorating classes, because @ doesn't.
> There's a patch submitted for that*, but it hasn't been accepted, IIRC.
> The PEP says 2.4 will see only function decorators.

Fair enough. I'd say that the existence of a patch which extends the
decorator syntax to classes is a benefit for @ syntax over J2. I don't
have a feel for whether there's a likelihood of class decorators being
accepted for 2.4, and hence how strong a benefit it is. I would,
however, argue that regardless of this, PEP 318 should say "For Python
2.4, only function/method decorators are being proposed", rather than
"... are being added".

But I take your point - chasing possible extensions is fruitless.

Paul.
-- 
The only reason some people get lost in thought is because it's
unfamiliar territory -- Paul Fix