Bengt Richter wrote:
> On Sun, 10 Jul 2005 05:35:01 GMT, Ron Adam <[EMAIL PROTECTED]> wrote:
>>So far they are fairly equivalent. So there's not really any advantage
>>over the equivalent inline function. But I think I see what you are
>>going towards. Decorators currently must be used when a function is
>>defined. This option attempts to makes them more dynamic so that they
>>can be used where and when they are needed.
>
> IMO part of the decorator benefit is clearer code, and also IMO the
> @range_check and @default_value decorators succeed in that. The code
> generated would presumably be the same, unless the exception capture
> discussed further down were implemented.
If you take the decorator at face value, it's clear. (In a sort of
because I said so way.) But if you look in the decorator, it may be
quite unclear. Ie.. it sort of sweeps the dirt under the rug. (IMO)
The thing is, defining a decorator can be fairly complex compared to a
regular function depending on what one is trying to do.
>>How about if you make it optional too?
>>@@keeplog log_of_interesting_values # if keeplog decorate.
>>b = get_value(c,d)
>>
>>Just a thought.
>
> Yes, but that is too easy to do another way. Plus I want to reserve
> '@@' for an AST-time decoration idea I have ;-)
The @@ could be whatever, but a single @ could probably be used just as
well.
How about any line that begins with an @ is preparsed as sugar. And
then create a simple sugar language to go along with it?
But that would be compile time macros wouldn't it. ;-)
>>When it comes to decorators, and now the with statements, I can't help
>>but feel that there's some sort of underlying concept that would work
>>better. It has to do with generalizing flow control in a dynamic way
>>relative to an associated block.
>>
>>One thought is to be able to use a place holder in an expression list to
>>tell a statement when to do the following block of code.
>
> it depends on scope and control aspects of what you mean by "block".
By block I meant the indented following suite. No special scope rules
that don't already currently exist in any 'if', 'while', or 'for' suite.
> But I doubt if we have much chance of introducing something is one
> more bf in the storm of "with" ideas that have already been
> discussed.
I'd like to think until 2.5 is released that there's still a chance that
something better could come along. But it would have to be pretty darn
good I expect.
> They strike me as a kind of macro idea where the only substitution argument
> is the block suite that follows, which IMO is a severe limitation on both
> the macro idea and the use of blocks ;-)
I'm not sure it's macro or not. Maybe it's a flow control parser
statement?
Does that sound any better than macro? ;-)
>>I like the place holders because I think they make the code much more
>>explicit and they are more flexible because you can put them where you
>>need them.
>
> Yes, but if you want to go that way, I'd want to have named place holders
> and be able to refer to arbitrary things that make sense in the context.
From what I've seen so far, there's a lot of resistance to real run
time macro's. So I don't expect them any time soon.
The mechanism I suggested doesn't store code or name it. So it's not a
macro, it's closer to a while that conditionally runs the body, but in
this case the condition is when instead of if. It's a different concept
that I think can compliment the language without being too complex.
Named macros make it even more useful.
Here I used 'this' as the keyword to indicate when the suite is to be
done. So it's a do-this-suite statement.
do f = opening(filename); try this; finally f.close():
suite
Now using "Sugar" language! ;-)
# Create sugar
@with_opened = "opening(%s); try this; finally f.close()"
do f = $with_opened%('filename'): # $ indicates sugar
suite
I used Pythons % operator as it already exists and works fine in this
situation. Easy to implement as well.
Hmm.. not sure how to apply this to a decorator. Lets see... Working it
out...
# function to use
def check_range(x):
if x in range(10,25):
return
raise RangeError # or what ever is suitable
# Make the decorator with sugar
@checkrange = "%s %s check_range(%s)"
Parses on spaces as default?
$checkrange% # Use the following line here
x = 24 # since nothing given after the %
Which will results in...
x = check_range(24)
There should be a way to specify an additional argument I think.
The exact rules would need to be worked out. It also might be a good
way to test sugar ideas before they become part of the language.
>>>orthogonal-musing-ly ;-)
>>
>>"Orthogonal is an unusual computer language in which your program flow
>>can go sideways. In actuality in can go in just about any direction you
>>could want."
>>
>> http://www.muppetlabs.com/~breadbox/orth/
>
> Interesting. And an implementation from our own Jeff Epler?
I didn't see that. LOL
Cheers,
Ron
> Regards,
> Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
