PEP 289: Generator Expressions (please comment)

[John J. Lee]

Re: PEP 289: Generator Expressions (please comment)

"Emile van Sebille" <emile@fenx.com > writes:
[...][color=blue]
> What do you get from:
> type(x*x for x in roots)[/color]
[...]

<type 'function'>?


John

[Just]

Re: PEP 289: Generator Expressions (please comment)

In article <871xt1qvwb.fsf @pobox.com>, jjl@pobox.com (John J. Lee)
wrote:
[color=blue]
> "Emile van Sebille" <emile@fenx.com > writes:
> [...][color=green]
> > What do you get from:
> > type(x*x for x in roots)[/color]
> [...]
>
> <type 'function'>?[/color]

<type 'generator'> actually:
[color=blue][color=green][color=darkred]
>>> def foo(): yield 1[/color][/color][/color]
....[color=blue][color=green][color=darkred]
>>> type(foo)[/color][/color][/color]
<type 'function'>[color=blue][color=green][color=darkred]
>>> type(foo())[/color][/color][/color]
<type 'generator'>[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

Just

[Bengt Richter]

Re: PEP 289: Generator Expressions (please comment)

On 23 Oct 2003 12:58:31 -0700, python@rcn.com (Raymond Hettinger) wrote:
[color=blue]
>Peter Norvig's creative thinking triggered renewed interest in PEP 289.
>That led to a number of contributors helping to re-work the pep details
>into a form that has been well received on the python-dev list:
>
> http://www.python.org/peps/pep-0289.html
>
>In brief, the PEP proposes a list comprehension style syntax for
>creating fast, memory efficient generator expressions on the fly:
>
> sum(x*x for x in roots)
> min(d.temperatu re()*9/5 + 32 for d in days)
> Set(word.lower( ) for word in text.split() if len(word) < 5)
> dict( (k, somefunc(k)) for k in keylist )
> dotproduct = sum(x*y for x,y in itertools.izip( xvec, yvec))
> bestplayer, bestscore = max( (p.score, p.name) for p in players )
>
>Each of the above runs without creating a full list in memory,
>which saves allocation time, conserves resources, and exploits
>cache locality.
>
>The new form is highly expressive and greatly enhances the utility
>of the many python functions and methods that accept iterable arguments.
>[/color]
+1

Regards,
Bengt Richter

[Skip Montanaro]

Re: PEP 289: Generator Expressions (please comment)


daniels> Don't tell anyone that I mentioned the inner workings of the
daniels> PSF cabal, or ............... ............... ....~}~~}

You're confusing the PSF (which does exist) with the PSU (whi

[Werner Schiendl]

Re: PEP 289: Generator Expressions (please comment)

Hi,


Rainer Deyke wrote:
[color=blue]
>
> At the very least, it would require parentheses if you want to create a list
> containing exactly one such generator.
>
> [(x for x in y)] # List containing generator
> [x for x in y] # List comprehension
>
>[/color]

personally the parentheses seem a little strange to me, or put another
way, I feel that simple parentheses around "everything " should not
change the meaning of the code.

For example, see current tuple syntax:
[color=blue][color=green][color=darkred]
>>> def p(x):[/color][/color][/color]
.... print type(x)
....[color=blue][color=green][color=darkred]
>>> p(5)[/color][/color][/color]
<type 'int'>[color=blue][color=green][color=darkred]
>>> p((5))[/color][/color][/color]
<type 'int'>[color=blue][color=green][color=darkred]
>>> p((5,))[/color][/color][/color]
<type 'tuple'>


As the code shows, just putting parentheses around the value 5 doesn't
make it a tuple.


Another point is that I think it's one of Python's advantages to not
require extensive parentheses e. g. for 'if' 'while' 'for' etc.

Unlike in C you can just write

if a > 7:
print "Large enough."


So requiring parentheses around the only item for a list with one
generator in it seems a little inconsistent in my eyes.

Maybe an alternative would be to have similar to tuples:

[x for x in y, ] # List containing generator
[x for x in y] # List comprehension


Just my 2c

Werner

[Alex Martelli]

Re: PEP 289: Generator Expressions (please comment)

Holger Krekel wrote (answering Raymond Hettinger):
...[color=blue][color=green]
>> sum(x*x for x in roots)[/color][/color]
...[color=blue][color=green]
>> bestplayer, bestscore = max( (p.score, p.name) for p in players )[/color][/color]

Actually I think RH meant "bestscore, bestplayer = ..." here...
[color=blue]
> Although most people on python-dev and here seems to like this PEP I
> think it generally decreases readability. The above constructs seem
> heavy and difficult to parse and thus i am afraid that they interfere
> with the perceived simplicity of Python's syntax.[/color]

Let's see: today, I could code:
sum([x*x for x in roots])
In 2.4, I will be able to code instead:
sum(x*x for x in roots)
with some performance benefits. Could you please explain how using
the lighter-weight simple parentheses rather than today's somewhat
goofy ([ ... ]) bracketing "generally decreases readability"... ?

Similarly, today's:
bestscore, bestplayer = max([ (p.score, p.name) for p in players ])
I'll be able to code as a somewhat faster:
bestscore, bestplayer = max( (p.score, p.name) for p in players )
Again, I don't see how the proposed new construct is any more "heavy
and difficult to parse" than today's equivalent -- on the contrary,
it seems somewhat lighter and easier to parse, to me.

It may be a different issue (as you appear, from a later message, to
be particularly enamoured of Python's current 'fp' corner) to claim
that, say, yesteryear's (and still-usable):

reduce(operator .add, map(lambda x: x*x, roots))

"increases readability" compared to the proposed

sum(x*x for x in roots)

It boggles my mind to try thinking of the latter as "heavy and
difficult to parse" compared to the former, to be honest. And
when I'm thinking of "the sum of the squares of the roots", I
DO find the direct expression of this as sum(x*x for x in roots)
to be most immediate and obvious compared to spelling it out
as
total = 0
for x in roots:
total = total + x*x
which feels more like a series of detailed instructions on
how to implement that "sum of squares", while the "sum(x*x".. .
DOES feel like the simplest way to say "sum of squares".

[color=blue]
> Sometimes it seems that introducing new syntax happens much easier
> than improving or adding stdlib-modules.[/color]

What a weird optical illusion, hm? In Python 2.3 *NO* new syntax
was introduced (the EXISTING syntax for extended slices is now
usable on more types, but that's not "introducin g" any NEW syntax
whatsoever), while HUNDREDS of changes were done that boil down
to "improving or adding standard library modules". So, it's
self-evidently obvious that the "happens much easier" perception
is pure illusion. In 2.4, _some_ syntax novelties are likely to
be allowed -- most PEPs under consideration are already in the
PEP repository or will be there shortly, of course (e.g., syntax
to support some variation of PEP 310, possibly closer to your
own interesting experiments that you reported back in February).
But once again there is absolutely no doubt that many more
changes will be to standard library modules than will "introduce
new syntax".

[color=blue]
> At least I hope that generator expressions will only be introduced
> via a __future__ statement in Python 2.4 much like it happened with
> 'yield' and generators. Maybe the PEP should have an "implementa tion
> plan" chapter mentioning such details?[/color]

I don't think __future__ has EVER been used for changes that do
not introduce backwards incompatibiliti es, nor do I see why that
excellent tradition should be broken for this PEP specifically.


Alex

[Alex Martelli]

Re: PEP 289: Generator Expressions (please comment)

Werner Schiendl wrote:
...[color=blue]
> personally the parentheses seem a little strange to me, or put another
> way, I feel that simple parentheses around "everything " should not
> change the meaning of the code.[/color]
...[color=blue]
> As the code shows, just putting parentheses around the value 5 doesn't
> make it a tuple.[/color]

No, but, in all cases where the lack of parentheses would make the
syntax unclear, you do need parentheses even today to denote tuples.
Cfr:
[1,2,3]
versus
[(1,2,3)]
a list of three items, versus a list of one tuple.
[color=blue]
> Maybe an alternative would be to have similar to tuples:[/color]

The PEP *IS* "similar to tuples": parentheses are mandatory around a
generator expression wherever their lack would make things unclear
(and that's basically everywhere, except where the genexp is the
only argument to a function call). Hard to imagine a simpler rule.

The idea of "adding a comma" like this:
[color=blue]
> [x for x in y, ] # List containing generator[/color]

feels totally arbitrary and ad-hoc to me, since there is NO other
natural connection between genexps and commas (quite differently
from tuples). Moreover, it would not help in the least in other
VERY similar and typical cases, e.g.:

[x for x in y, z,] # ok, now what...?

today this means [y, z]. Would you break backwards compatibility
by having it mean a [<genexp>] instead? Or asking for a SECOND
trailing comma to indicate the latter? And what about a genexp
followed by z, and, ... ?

No, really, this whole "trailing comma to indicate a genexp in one
very special case" idea is sort of insane. Compare with:

[x for x in y, z,] # same as [y, z]

[(x for x in y, z,)] # the [<genexp>] case

[(x for x in y), z,] # the [<genexp>, z] case

what could possibly be clearer? Not to mention the parens rule
is simple, universally applicable, breaks no backwards compat,
AND is far closer to the general case for tuples ("parens when
needed for clarity") than the "singleton tuple" case you seem
to have focused on.


Alex

[Alex Martelli]

Re: PEP 289: Generator Expressions (please comment)

Daniel Dittmar wrote:
[color=blue]
> Raymond Hettinger wrote:[color=green]
>> bestplayer, bestscore = max( (p.score, p.name) for p in players )
>>
>> Each of the above runs without creating a full list in memory,
>> which saves allocation time, conserves resources, and exploits
>> cache locality.[/color]
>
> Why should generator comprehension be useful only for arguments?[/color]

Nobody ever said it would be. RH's examples were all function
calls because that's an "obvious" use case.

[color=blue]
> counter proposal:
> g[(p.score, p.name) for p in players ][/color]

Looks like it's indexing g.
[color=blue]
> This works similar to r'\' for raw strings and u'x' for unicode strings.[/color]

Nope, it's ambiguous, while <single letter> adjacent to '...' isn't.
[color=blue]
> This has the advantage that it can be more easily extended:
> d[(p.name, p.score) for p in players] creates a dictionary[/color]

dict((p.name, p.score) for p in players)

will do it in a much more obvious way.
[color=blue]
> s[(p.score, p.name) for p in players] creates a sorted list[/color]

list.sorted((p. score, p.name) for p in players)

will do it in a much more obvious way, and also allow you to
specify such optional niceties as (e.g.) "key=" (in 2.4 --
and, btw, thanks to all of RH's work on the issue!).
[color=blue]
> and
> p[$*-=%/sd/!] allows to embed perl code[/color]

If you want perl, you know where to find it.


Alex

[Werner Schiendl]

Re: PEP 289: Generator Expressions (please comment)

Alex Martelli wrote:
[color=blue]
> No, but, in all cases where the lack of parentheses would make the
> syntax unclear, you do need parentheses even today to denote tuples.
> Cfr:
> [1,2,3]
> versus
> [(1,2,3)]
> a list of three items, versus a list of one tuple.[/color]

ok, but that's the whole point (1,2,3) *is* a tuple.

but

[(1),(2),(3)]

is the same than

[1,2,3]

and

[(1)]

is the same than

[1]

if you want a 1-tuple in a list, you've to write

[(1,)]
[color=blue]
>
>[color=green]
>>Maybe an alternative would be to have similar to tuples:[/color]
>
>
> The PEP *IS* "similar to tuples": parentheses are mandatory around a
> generator expression wherever their lack would make things unclear
> (and that's basically everywhere, except where the genexp is the
> only argument to a function call). Hard to imagine a simpler rule.
>[/color]

With "similar to tuples" I meant the kind of indication that I want
a list with exactly one item that is a generator.
[color=blue]
> The idea of "adding a comma" like this:
>
>[color=green]
>>[x for x in y, ] # List containing generator[/color]
>
>
> feels totally arbitrary and ad-hoc to me, since there is NO other
> natural connection between genexps and commas (quite differently
> from tuples). Moreover, it would not help in the least in other
> VERY similar and typical cases, e.g.:
>
> [x for x in y, z,] # ok, now what...?[/color]

That's a reasonable point of course.

To be honest, I didn't consider that as I always put the items to
iterate over in an explicit list or tuple or have 'em already inside one.

There is no way to judge what's meant in that case, it's a little
unfortunate that this *is* currently allowed.

So within a list literal, the parentheses are required *sigh* since the
default would need to be that following values are the values to iterate
over.
[color=blue]
> No, really, this whole "trailing comma to indicate a genexp in one
> very special case" idea is sort of insane. Compare with:
>
> [x for x in y, z,] # same as [y, z]
>
> [(x for x in y, z,)] # the [<genexp>] case
>
> [(x for x in y), z,] # the [<genexp>, z] case
>
> what could possibly be clearer? Not to mention the parens rule
> is simple, universally applicable, breaks no backwards compat,
> AND is far closer to the general case for tuples ("parens when
> needed for clarity") than the "singleton tuple" case you seem
> to have focused on.[/color]

The trailing comma rule *is* there in the language already.

The problem with my idea is with the possibility of a tuple without
parentheses in a list comprehension (as discussed above).


Still I do not like the follwing example from the specification:

g = (x**2 for x in range(10))

Whatfor are the parens?

To me this looks like requiring parens for

a = b + c


best regards

Werner

[Duncan Booth]

Re: PEP 289: Generator Expressions (please comment)

Werner Schiendl <n17999950.temp .werner@neverbo x.com> wrote in
news:3f9d18ad@b rateggebdc5.br-automation.co.a t:
[color=blue]
> For example, see current tuple syntax:
>[color=green][color=darkred]
> >>> def p(x):[/color][/color]
> ... print type(x)
> ...[color=green][color=darkred]
> >>> p(5)[/color][/color]
><type 'int'>[color=green][color=darkred]
> >>> p((5))[/color][/color]
><type 'int'>[color=green][color=darkred]
> >>> p((5,))[/color][/color]
><type 'tuple'>
>
>
> As the code shows, just putting parentheses around the value 5 doesn't
> make it a tuple.[/color]

Just putting parentheses around something can change the type, if you pick
the right example:
[color=blue][color=green][color=darkred]
>>> def p(x):[/color][/color][/color]
print type(x)

[color=blue][color=green][color=darkred]
>>> p(5,)[/color][/color][/color]
<type 'int'>[color=blue][color=green][color=darkred]
>>> p((5,))[/color][/color][/color]
<type 'tuple'>[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

And even closer to the list comprehension vs list containing generator
example:
[color=blue][color=green][color=darkred]
>>> [5,][/color][/color][/color]
[5][color=blue][color=green][color=darkred]
>>> [(5,)][/color][/color][/color]
[(5,)][color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

--
Duncan Booth duncan@rcp.co.u k
int month(char *p){return(1248 64/((p[0]+p[1]-p[2]&0x1f)+1)%12 )["\5\x8\3"
"\6\7\xb\1\x9\x a\2\0\4"];} // Who said my code was obscure?

[Daniel Dittmar]

Re: PEP 289: Generator Expressions (please comment)

Alex Martelli wrote:[color=blue][color=green]
>> counter proposal:
>> g[(p.score, p.name) for p in players ][/color]
>
> Looks like it's indexing g.
>[color=green]
>> This works similar to r'\' for raw strings and u'x' for unicode
>> strings.[/color]
>
> Nope, it's ambiguous, while <single letter> adjacent to '...' isn't.[/color]

Although I admit my proposal is flawed, the principle behind is is sound,
namely that syntax constructs should be recognisable at the start.
[color=blue][color=green]
>> p[$*-=%/sd/!] allows to embed perl code[/color]
>
> If you want perl, you know where to find it.[/color]

See how difficult it is even for you to recognize something if it isn't
introduced by the proper markers, in this case <sarkasm>?

Daniel

[Holger Krekel]

Re: PEP 289: Generator Expressions (please comment)

Alex Martelli wrote:[color=blue][color=green]
> > Although most people on python-dev and here seems to like this PEP I
> > think it generally decreases readability. The above constructs seem
> > heavy and difficult to parse and thus i am afraid that they interfere
> > with the perceived simplicity of Python's syntax.[/color]
>
> Let's see: today, I could code:
> sum([x*x for x in roots])
> In 2.4, I will be able to code instead:
> sum(x*x for x in roots)[/color]

Yes, Raymond send me some private mail already and i clarified
that i don't like list comprehension syntax as well :-)

Actually i do like generator expressions *more* than list comprehensions
so i agree to your points that gen expressions do improve on the (rather
specific) list comprehensions.

Nevertheless, i have the impression that this kind of syntax (be it list
comprehension or generator expressions) somewhat decreases the
chances for "immediate" understanding of python code without knowing
the language much. It's likely that you need to parse generator
expressions in detail especially because they don't provide sharp
visual clues like indented blocks do. I do consider the "visual clues"
to be a strength of current python although you can always provide
examples with a language's syntax which are not readable.

Generator expressions will probably raise the barrier to understanding
python code without having appropriate knowledge but that may very well
prove to be worth it. We'll probably find out soon so i think we don't
need to argue a lot about it now. IOW, i am not completly opposed
to the PEP just a bit skeptical. And, btw, i appreciated very much,
that Guido made it clear from the start that Python 2.3 would be a
maintenance release with no changes to syntax. I am probably just
astonished at these huge syntax-threads all over python-dev :-)

have fun,

holger

[Alex Martelli]

Re: PEP 289: Generator Expressions (please comment)

On Monday 27 October 2003 04:52 pm, Holger Krekel wrote:[color=blue]
> Alex Martelli wrote:[color=green][color=darkred]
> > > Although most people on python-dev and here seems to like this PEP I
> > > think it generally decreases readability. The above constructs seem
> > > heavy and difficult to parse and thus i am afraid that they interfere
> > > with the perceived simplicity of Python's syntax.[/color]
> >
> > Let's see: today, I could code:
> > sum([x*x for x in roots])
> > In 2.4, I will be able to code instead:
> > sum(x*x for x in roots)[/color]
>
> Yes, Raymond send me some private mail already and i clarified
> that i don't like list comprehension syntax as well :-)
>
> Actually i do like generator expressions *more* than list comprehensions
> so i agree to your points that gen expressions do improve on the (rather
> specific) list comprehensions.[/color]

And therefore, since you ain't gonna take list comprehensions away,
you should be in favour, not against, generator expressions.

Personally, I agree with David Ascher's evaluation in the intro to Chapter 1
of "Python Cookbook" (end of p.2): "List comprehensions have clearly
become wildly successful". I have seen non-programmers just learning
programming and Python together "GET" list comprehensions AT ONCE,
particularly if they had ever seen typical set notation as used in maths,
but not only under such conditions. I do agree with you that generator
expressions are a further improvement (except in name -- sigh -- I wish
"iterator expressions" had prevailed instead!-).

[color=blue]
> Nevertheless, i have the impression that this kind of syntax (be it list
> comprehension or generator expressions) somewhat decreases the
> chances for "immediate" understanding of python code without knowing
> the language much. It's likely that you need to parse generator[/color]

I've had substantial feedback from articles on Python I had written,
particularly on Italian magazines, and much of it was from people who
indeed don't know the language much (or at all). That feedback tells
me that list comprehensions were absolutely nothing like the obstacle
you fear, confirming my experiences with newbies. The things that DID
give non-Python-knowers _serious_ trouble were rather e.g.:

while <condition>:
<body>
else:
<something else>

NOBODY who doesn't have a good grasp of Python gets "immediate
understanding" of this -- *not one person* out of all I've talked about
this. A large majority imagines that the "else:" clause is executed if
the <condition> NEVER holds, the remaining minority just doesn't
get it at all, NOBODY guesses that this may have to do with whether
a "break" inside the <body> has or hasn't executed.
[color=blue]
> expressions in detail especially because they don't provide sharp
> visual clues like indented blocks do. I do consider the "visual clues"
> to be a strength of current python although you can always provide
> examples with a language's syntax which are not readable.[/color]

Oh, the above example is quite readable and rich with visual clues --
it's just that its _semantics_ are totally anti-intuitive to all readers who
haven't studied Python pretty well. On the contrary, and I wish there
was a way to make a bet on this and settle it objectively, I claim e.g.:

print sum(x*x for x in thelist if x>10)

will be "immediatel y read" as "print the sum of the squares of those
elements of 'thelist' that are larger than 10" by a majority of the
readers (if anything, understandable confusion will come about the
fact that "print" has nothing whatsoever to do with the *printer*
that one may or may not have attached to one's computer, but
rather will normally display stuff on a terminal-window... the mental
disconnection of "print" from "printer" is NOT intuitive at all -- it just
SEEMS that way after one has been programming long enough!).

Of course, more complicated expressions will be harder to read --
but that's quite independent of whether those expressions will
be generator expressions or other kinds.

[color=blue]
> Generator expressions will probably raise the barrier to understanding
> python code without having appropriate knowledge but that may very well
> prove to be worth it. We'll probably find out soon so i think we don't
> need to argue a lot about it now. IOW, i am not completly opposed
> to the PEP just a bit skeptical.[/color]

We'll find out in, I suspect, well over a year (when 2.4 final is released
and gets widespread). And we'll "find out" on a purely anecdotal and
experiential basis, just as we have "found out" about list comprehensions
over the last few years, unless somebody has money burning in their
pocket to finance a systematic study, which I seriously doubt:-).
[color=blue]
> And, btw, i appreciated very much,
> that Guido made it clear from the start that Python 2.3 would be a
> maintenance release with no changes to syntax. I am probably just[/color]

So did I! Great move.
[color=blue]
> astonished at these huge syntax-threads all over python-dev :-)[/color]

I was anything but astonished -- a bunch of language enthusiasts
stopped from any _productive_ discussion of syntax changes for,
what, over two years (since the last alpha of 2.2 until now)...?! It's
not amazing that we'd be bubbling over now we have a chance...:-).

Guido (with support from the usual adverse-to-any-change brigade)
will no doubt exert his usual veto right with the usual firmness, so
all of our threads are little more than a venting out of too-long
repressed energy, anyway:-).


Alex

[Christoph Becker-Freyseng]

Re: PEP 289: Generator Expressions (please comment)

Bjorn Pettersen wrote:
[color=blue]
> Christoph Becker-Freyseng <webmaster@beyo nd-thoughts.com> wrote in
> news:mailman.59 .1066957147.702 .python-list@python.org :
>
> [...]
>
> Something like:
>
> compiler.parse( "[x*x for x in roots]")
>
> (not completely what you want, but close :-)
>
> -- bjorn[/color]

:-)

Unfortunately I don't have time right now to play around with Pythons
Compiler/Parser as my Biophysics-study is quite time consuming now ...

cu Christoph Becker-Freyseng


(I've been offline for some days due to an failure of telekom.de)

[Alex Martelli]

Re: PEP 289: Generator Expressions (please comment)

Daniel Dittmar wrote:
[color=blue]
> Alex Martelli wrote:[color=green][color=darkred]
>>> counter proposal:
>>> g[(p.score, p.name) for p in players ][/color]
>>
>> Looks like it's indexing g.
>>[color=darkred]
>>> This works similar to r'\' for raw strings and u'x' for unicode
>>> strings.[/color]
>>
>> Nope, it's ambiguous, while <single letter> adjacent to '...' isn't.[/color]
>
> Although I admit my proposal is flawed, the principle behind is is sound,
> namely that syntax constructs should be recognisable at the start.[/color]

Avoiding lookahead is a good principle, but not an absolute.

For example, when I see a literal that starts with the characters:

1233445

I do NOT start grumbling that, since it violates the Dittmar Principle,
I'm desperate by not yet knowing after reading the first few characters
whether it's going to be an integer literal, such as

123344567

or a float literal, such as

1233445.67

Your "should" is just too weak to make this notation other than
perfectly fine. A language designed strictly by your principle, thus
forcing initial stropping of digit sequences to distinguish e.g.
integer literals from float ones, would be a syntax disaster.

[color=blue][color=green][color=darkred]
>>> p[$*-=%/sd/!] allows to embed perl code[/color]
>>
>> If you want perl, you know where to find it.[/color]
>
> See how difficult it is even for you to recognize something if it isn't
> introduced by the proper markers, in this case <sarkasm>?[/color]

"Introduced " matters not a whit (just like the fact that, in English,
"sarcasm" is spelled with a c and not with a k). If you had chosen to
indicate your dubious sarcasm (against your own proposal?!) by a
trailing parenthetical such as "(just kidding)" I would not have
wasted the time to respond. Don't take the _complete_ lack of any
clarifying denotation (which is definitely a stupid choice) obscuring
the message, as any proof that the clarifying denotation must be
BEFORE rather than AFTER -- it just doesn't follow. As your proposal
DOES look distinctly perlish (cfr q/foo/ vs qq/foo/ etc), it's quite
reasonable to form the working hypothesis that you LIKE perl syntax,
rather than being engaged in sarcasm against your own proposals (which
is a form of split personality one rarely comes upon).


Alex