Python syntax in Lisp and Scheme

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Kenny Tilton wrote:
...[color=blue][color=green][color=darkred]
>>>But methinks a number of folks using Emacs Elisp and Autocad's embedded
>>>Lisp are non-professionals.[/color]
>>
>> Methinks there are a great many more people using the VBA
>> interface to AutoCAD than its Lisp interface. In fact, my friends
>> (ex-Autodesk) told me that's the case.[/color]
>
> Sheesh, who hasn't been exposed to basic? From my generation, that is.
> :) But no matter, the point is anyone can handled parens if they try for
> more than an hour.[/color]

Yes, but will that make them most happy or productive? The Autocad
case appears to be relevant, though obviously only Autodesk knows
for sure. When I was working in the mechanical CAD field, I had
occasion to speak with many Autocad users -- typically mechanical
drafters, or mechanical or civil engineers, by training and main working
experience -- who HAD painfully (by their tales) learned to "handle
parens", because their work required them occasionally to write Autocad
macros and once upon a time Autolisp was the only practical way to do it --
BUT had jumped ship gleefully to the VBA interface, happily ditching
years of Autolisp experience, just as soon as they possibly could (or
earlier, i.e. when the VBA thingy was very new and still creaky in its
integration with the rest of Autocad -- they'd rather brave the bugs
of the creaky new VBA thingy than stay with the Autolisp devil they
knew). I don't know if syntax was the main determinant. I do know
that quite a few of those people had NOT had any previous exposure to
any kind of Basic -- we're talking about mechanics-junkies, more likely
to spend their spare time hot-rodding their cars at home (Bologna is,
after all, about 20 Km from Ferrari, 20 Km on the other side from
Minardi, while the Ducati motorcycle factory is right here in town,
etc -- *serious* mechanics-freaks country!), rather than playing with
the early home computers, or program for fun.

So, I think Autocad does prove that non-professional programmers
(mechanical designers needing to get their designs done faster) CAN
learn to handle lisp if no alternatives are available -- and also
that they'd rather not do so, if any alternatives are offered. (I
don't know how good a lisp Autolisp is, anyway -- so, as I mentioned,
there may well be NON-syntactical reasons for those guys' dislike
of it despite years of necessarily using it as the only tool with
which they could get their real job done -- but I have no data that
could lead me to rule out syntax as a factor, at least for users
who were OCCASIONAL users anyway, as programming never was their
REAL, MAIN job, just means to an end).

[color=blue][color=green][color=darkred]
>>>You (Alex?) also worry about groups of programmers and whether what is
>>>good for the gurus will be good for the lesser lights.[/color]
>>
>> If you ever hear me call anyone who is not an expert programmer
>> a "lesser light" then I give you -- or anyone else here -- permission
>> to smack me cross-side the head.[/color]
>
> Boy, you sure can read a lot into a casually chosen cliche. But can we
> clear up once and for all whether these genius scientists are or are not
> as good a programmer as you? I thought I heard Python being recommended
> as better for non-professional programmers.[/color]

Dunno 'bout Andrew, but -- if the scientists (or their employers) are
paying Andrew for programming consultancy, training, and advice, would
it not seem likely that they consider that he's better at those tasks
than they are...? Otherwise why would they bother? Most likely the
scientists are better than him at _other_ intellectual pursuits -- be
it for reasons of nature, nurture, or whatever, need not interest us
here, but it IS a fact that some people are better at some tasks.
There is too much programming to be done, to let ONLY professional
programmers do it -- just like there's too much driving to be done, to
let only professional drivers do it -- still, the professionals can be
expected to be better at their tasks of specialistic expertise.


Alex

[Pascal Bourguignon]

Re: Python syntax in Lisp and Scheme

rpw3@rpw3.org (Rob Warnock) writes:
[color=blue]
> Andrew Dalke <adalke@mindspr ing.com> wrote:
> +---------------
> | (and yes, I know about the lawsuit against disk drive manufacturors
> | and their strange definition of "gigabyte". .. )
> +---------------
>
> Oh, you mean the fact that they use the *STANDARD* international
> scientific/engineering notation for powers of 10 instead of the
> broken, never-quite-right-except-in-a-few-cases pseudo-binary
> powers of 10?!?!?[/color]


No we mean the fact that they subreptitiously switched from the
industry standard of defining giga as 2^30 to the scientific standard
of defining giga as 10^9, which allowed them to display bigger size
while in fact they did not have bigger hard drives. That was a pure
marketing trick. Happily, after these lawsuits, they now write the
exact number of byte storable on their devices. But be assured that
they would have never switched if 2^30 had been smaller than 10^9.

[color=blue]
> [Hmmm... Guess you can tell which side of *that*
> debate I'm on, eh?] The "when I write powers of 10 which are 3*N
> just *asssume* that I meant powers of 2 which are 10*N" hack simply
> fails to work correctly when *some* of the "powers of 10" are *really*
> powers of 10. It also fails to work correctly with things that aren't
> instrinsically quantized in powers of 2 at all.
>
> Examples: I've had to grab people by the scruff of the neck and push
> their faces into the applicable reference texts before they believe me
> when I say that gigabit Ethernet really, really *is* 1000000000.0 bits
> per second [peak payload, not encoded rate], not 1073741824, and that
> 64 kb/s DS0 telephone circuits really *are* 64,000.0 bits/sec, not 65536.
> [And, yes, 56 kb/s circuits are 56000 bits/sec, not 57344.][/color]

Yes, that's because telecoms are not computers. In particular,
telecoms were invented long before computers and binary base became
interesting.

On the other hand, hard drives are purely computer stuff...

[color=blue]
> Solution: *Always* use the internationally-recognized binary prefixes
> <URL:http://physics.nist.go v/cuu/Units/binary.html> when that's really
> what you mean, and leave the old scientific/engineering notation alone,
> as pure powers of 10. [Note: The historical notes on that page are well
> worth reading.][/color]

Perhaps we should start serriously to use the kibi (Ki), mibi (Mi),
gibi (Gi), tibi (Ti), etc, that have been proposed.


--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

Do not adjust your mind, there is a fault in reality.

[Alex Martelli]

Re: Code block literals

Andrew Dalke wrote:
...[quoting me indirectly]...[color=blue][color=green][color=darkred]
>> > If Python's syntax defined
>> > other forms of suites, e.g. hypothetically:
>> >
>> > with <object>:
>> > <suite>
>> >
>> > meaning to call the object (or some given method[s] in it, whatever)
>> > with the suite as its argument, it would be just as explicit as, e.g.:
>> >
>> > for <name> in <object>:
>> > <suite>[/color][/color]
>
> A reasonable point. However, inside the 'with' statement it's hard
> to know if
>
> print x[/color]

Sorry, I was NOT using 'with' in a Pascal/Basic sense, but rather
to mean, and I quote: "meaning to call ... with the suite" (others
have proposed 'using' etc for this construct in python-dev). I
was using 'with' only because so many macros quoted on the xposted
thread appear to start with "WITH-..." ...!-)


Alex

[Lulu of the Lotus-Eaters]

Re: Python syntax in Lisp and Scheme

|Lulu of the Lotus-Eaters wrote:
|> I would think Lisp is more like cricket: wickets bracket both ends, no
|> one can actually understand the rules, but at least the players wear
|> white.

Paul Foley <see@below.inva lid> wrote previously:
|Oh, come on! Anyone can understand cricket! There are two teams.
|The team that's in sits out, except for two batsmen...

I apologize, I overstated it. I meant "No American can understand..."

FWIW. I very much enjoyed watching part of an amateur cricket match on
my vacation to Vancouver a few weeks back. But exactly what they were
doing was as perplexing as the Lisp code in this thread :-).

Yours, Lulu...

P.S. It's odd that I hadn't KNOWN about my Dutch ancestry... but Python
fits my brain, so there must be some.

--
mertz@ _/_/_/_/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY:_/_/_/_/ v i
gnosis _/_/ Postmodern Enterprises _/_/ s r
..cx _/_/ MAKERS OF CHAOS.... _/_/ i u
_/_/_/_/_/ LOOK FOR IT IN A NEIGHBORHOOD NEAR YOU_/_/_/_/_/ g s

[Vis Mike]

Re: Python syntax in Lisp and Scheme

<mike420@ziplip .com> wrote in message
news:FTB2H3EKMG CKEAGFMAPUH4MJI BMHGNMOD5CLJSKP @ziplip.com...[color=blue]
> I think everyone who used Python will agree that its syntax is
> the best thing going for it. It is very readable and easy
> for everyone to learn. But, Python does not a have very good
> macro capabilities, unfortunately. I'd like to know if it may
> be possible to add a powerful macro system to Python, while
> keeping its amazing syntax, and if it could be possible to
> add Pythonistic syntax to Lisp or Scheme, while keeping all
> of the functionality and convenience. If the answer is yes,
> would many Python programmers switch to Lisp or Scheme if
> they were offered identation-based syntax?[/color]

What about an editor that simply hides outer parenthesis and displays them
as
tabs, for Scheme for example. Then you could edit in any program, or use an
editor designed for it. Kind of like editing raw HTML or using an HTML
editor.

I might just adapt this idea for my pet language which uses indentation for
blocks. I like code to flow like an outline, with as few extraneous symbols
and junk as possible.

Mike

[Vis Mike]

Re: Code block literals

"Lulu of the Lotus-Eaters" <mertz@gnosis.c x> wrote in message
news:mailman.10 65726763.15540. python-list@python.org ...[color=blue]
> "Vis Mike" <visionary25@_n ospam_hotmail.c om> wrote previously:
> |Something like this seems more logical to me:
> |for line in file('input.txt ').lines:
> | do_something_wi th(line)
> |for byte in file('input.txt ').bytes:
> | do_something_wi th(byte)
>
> Well, it's spelled slightly differently in Python:
>
> for line in file('input.txt ').readlines():
> do_something_wi th(line)
>
> for byte in file('input.txt ').read():
> do_something_wi th(byte)
>
> Of course, both of those slurp in the whole thing at once. Lazy lines
> are 'fp.xreadlines( )', but there is no standard lazy bytes.[/color]

xreadlines()? What kind of naming convention is that: :)

what about 'eachline()'?
[color=blue]
> A method 'fp.xread()' might be useful, actually. And taking a good idea
> from Dave Benjamin up-thread, so might 'fp.xreadwords( )'. Of course, if
> you were happy to write your own class 'File' that provided the extra
> iterations, you'd only need to capitalize on letter to get these extra
> options.[/color]

Mike

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Kenny Tilton wrote:
...[color=blue]
> As for non-professional programmers, the next question is whether a good
> language for them will ever be anything more than a language for them.[/color]

Being a professional programmer, I find Python makes me very productive
at my job -- and yet I know from experience it's also an excellent language
for non-professional programmers. So, the experiential answer is clear to
me.
[color=blue]
> Perhaps Python should just stay with the subset of capabalities that
> made it a huge success--it might not be able to scale to new
> sophistication without destroying the base simplicity.[/color]

Interestingly enough, you and I probably agree on that. I don't _want_
Python to grow in any way that would "destroy the base simplicity"; indeed,
I'm looking forward to 3.0 (even though it's probably 3 years off or so)
exactly because it may get simplified again then, shedding some accumulated
legacy baggage (there is no reason, except backwards compatibility, to
have e.g "classic classes", range, xrange, etc etc). Any proposed new
feature, in my opinion, must be judged strictly on the criterion of: how
much better than today's set of features would it let us do our jobs? If
it provides another roughly equivalent way to perform some of the same
tasks, that's a substantial minus (as it encourages divergence of language
dialects) and must be compensated by really big advantages elsewhere.

Today's Python has the features we need to productively build ambitious
frameworks for asynchronous network clients and servers (Twisted), spam
filters that apparently work better than Graham's (spambayes), search
engines (Verity Ultraseek, nee Infoseek, as wel as Google), ship-design
optimization apps (Tribon Vitesse), commercial games (Freedom Force, EVE
Online, Star Trek Bridge Commander...), collaborative enterprise app
frameworks (CAPS), scientific visualization tools such as MayaVi, business
logic for factory and tool control (IBM/Philips Fishkill plant)... oh,
you're perfectly capable of reading the various "Python success stories"
sites and booklets yourself, I don't want to bore you TOO much:-). The
point is, it MIGHT, as you point out, be unfeasible to "scale to new
sophistication" -- beyond the few 100,000s function points MAXIMUM of
any of these Python successes (roughly equivalent to, say, a few 10's
of millions of lines of C code), to e.g. many millions of function points.

I think the world needs LOTS AND LOTS of application programs in
the 1000-100,000 function points range -- and Python's current set of
features has proven amply sufficient to provide those without damage
to "the base simplicity" which you mention. If many applications of
many millions FP's (roughly equivalent to a billion lines of C, or so)
are needed, I don't know -- but, if so, I share your doubts about it making
any sense to destroy Python's simplicity in an attempt to tackle THOSE
monsters, "scaling to new sophistication" .

[color=blue]
> You (Alex?) also worry about groups of programmers and whether what is
> good for the gurus will be good for the lesser lights. What you are
> saying is that the guru will dazzle the dorks with incomprehensibl e
> gobbledygook. That does happen, but those kinds of gurus should be fired.[/color]

That's only part of the problem, of course -- programmers who are not
quite as good as they think they are and inflict their "enhancemen ts" to
the language to everybody else are another issue. Maybe they should
be fired, but such turnover in the team would decrease productivity
anyway.
[color=blue]
> On a suffciently large project (well, there's another point: with Lisp
> one does not hire ten people (unless one is doing three projects)) the[/color]

Lisp isn't able to let 10 people work together productively on the
same project? Oh my -- now THAT would be a huge problem;-).
[color=blue]
> team should be divided into those who will be building the
> domain-specific embedded language and those who will be using it.
> Ideally the latter could be not just non-professional programmers, but
> even non-programmers.[/color]

If they're programming (in whatever language) they can't be
non-programmers, by definition. But anyway, this misses the key
issue: who are the *real* experts of the application domain that
your "domain-specific" language is supposed to address so well?
E.g., the *real* experts on turbo-compressor design, on optimization
of ship designs, on the business logic of tool control, on logical
and physical design of integrated circuits, etc, etc? Answer: they
are likely to be non-professional programmers. Are THEY designing
the domain-specific language -- or is it going to be designed by
computer scientists who don't really grasp the intricacies of turbo
compressors, ships, etc, etc?

The Agile Programming (Extreme Programming, in particular) answer
to this enormously important issue is that the whole team, customer
included, *works together* and *collectively owns* the whole body of code.

The computer scientist learns enough about turbo compressors, and
the turbo compressor expert enough about programming, by the
incredibly productive social process of *pair-programming* -- sitting
side by side and working together at testing and building code (in
this order -- but I won't bore you with test-driven-design paeans...;-).

This holistic approach is incompatible with your favourite "the gurus
build the domain-specific language, the peons just use it" approach.
It works particularly well when the language is as simple, as good at
"getting out of your way", as Python (or, admittedly, Ruby -- I have
enormous respect for Ruby! -- though I have some issues on quite
another plane that make me keep preferring Python for this specific,
and very important to me, kind of tasks).

It surely can feel "cooler" for the Guru (uppercase G mandatory) not
to have to mingle with such low-lifes as the lusers (a Guru's favourite
spelling of "users", apparently) -- to just sit in their ivory tower
spitting out domain-specific embedded languages for domains they
_aren't_ as expert at as the peons. But I've seen that approach at
work (for hardware design with various lisp variants and dialects) and
don't like the results I have observed, particularly in application domains
where the intended users ARE quite expert in their field (which is the
case for many interesting apps -- not just those targeting the people
which our society acknowledges as "respected professionals", mind you:
a good secretary knows FAR more than I ever will on how to make an
office run, a shopkeeper on how things work in a shop, etc, etc).


Alex

[Michael Sperber]

Re: higher-order macros [Re: Python syntax in Lisp and Scheme

>>>>> "james" == james anderson <james.anderson @setf.de> writes:

james> are there examples where these little beasties are used in production?

If you mean Oleg's little beasties, then the answer is yes, and in
mission-critical, million-dollar-stake applications at that.

--
Cheers =8-} Mike
Friede, Völkerverständi gung und überhaupt blabla

[Matthias]

Re: Python syntax in Lisp and Scheme

Alex Martelli <aleax@aleax.it > writes:
[color=blue]
> Pascal Costanza wrote:
>[color=green]
> > Matthias wrote:
> >[color=darkred]
> >> Why the smiley? Many hours of discussions could be spared if there
> >> were real, scientific, solid studies on the benefit of certain
> >> language features or languages in certain domains or for certain types
> >> of programmers.[/color]
> >
> > This presumes that language features can be judged in isolation. I think
> > it's rather more likely that good programming languages are holistic
> > systems, in the sense that the whole language is more than the sum of
> > its features.[/color]
>
> ...and/or less, if N features are just offering N different ways to
> perform essentially the same tasks, of course. Still, be the whole
> more or less than "the sum of the parts", one still can't rule out
> (as no "hard-scientific studies" are ever likely to exist) such
> non-linearities and complications. This, of course, points out that
> programming languages are NOT "mathematic s", as some claim -- they
> are engineering designs, and interact with human minds, sociology
> of groups, cultural and educational features, at least as much as
> they interact with the architecture and capabilities of computers.[/color]

You are right, of course.

But that it is a complicated matter to study does not mean that it's
not worthwhile: An example where human minds, sociology, culture,
etc. intervene in a complicated way is education. In Germany we've
had /ages/ of hot debate on how to educate children (at elementary and
highschool, mainly). Then scientists came and did some tests. They
defined some educational goals ("children at a certain age should be
able to read this text and solve such kind of math problem") and
looked which factors influence how well students met the goals
previously defined. The results were quite surprising to our
education experts: Certain factors which were previously believed to
matter a great deal (like teacher/student ratio) were found to be of
almost no importance. Other factors (like parental income and ethnic
origin) had an alarmingly high influence. Now our education experts
have, for the first time, real data as input, and they can start to
work on the real problems.

In the context of programming languages I find studies from Lutz
Prechtel <http://www.ipd.uka.de/~prechelt/Biblio/> or Erann Gat's
Lisp/Java paper interesting. Doing such studies on a larger scale and
with non-self selected participants should be possible. In "Patterns
of Software" Peter Gabriel reports (p. 128) that a group of advanced
Lisp developers experienced a 30% drop in productivity one year after
switching to C++. This is merely an anecdote, but if you have a
reasonable measure of programmers' productivity (I know, that's hard)
and examine how language-switchers in industry perform after 1, 2, 3
years you might find other interesting results. One could also try to
compare small software companies which do well (e.g., financially)
with those that do not so well.

In all these cases defining acceptable performance measures and/or
getting enough data is hard, and no single study would reveal "the
truth". But scientifically examining the act of producing software
should be possible (within limits) if one tries and has enough
funding. ;-)

[james anderson]

Re: higher-order macros [Re: Python syntax in Lisp and Scheme



Michael Sperber wrote:[color=blue]
>[color=green][color=darkred]
> >>>>> "james" == james anderson <james.anderson @setf.de> writes:[/color][/color]
>
> james> are there examples where these little beasties are used in production?
>
> If you mean Oleg's little beasties, then the answer is yes, and in
> mission-critical, million-dollar-stake applications at that.[/color]

is one at liberty to give anything more than a rhetorical answer?

i would be interested to observe how they express themselves in the large.
[color=blue]
>
> --
> Cheers =8-} Mike
> Friede, Völkerverständi gung und überhaupt blabla[/color]

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Matthias wrote:
...[color=blue]
> In the context of programming languages I find studies from Lutz
> Prechtel <http://www.ipd.uka.de/~prechelt/Biblio/> or Erann Gat's[/color]

Yes, Lutz has been quoted several times on this thread -- and, of course,
his studies have been impugned just as many times as they've been
quoted, anytime somebody did not like any of their implications.
[color=blue]
> truth". But scientifically examining the act of producing software
> should be possible (within limits) if one tries and has enough
> funding. ;-)[/color]

"shud" is a 4-letter word;-). As this huge thread makes abundantly
clear, social and political considerations, not technical ones, dominate
most discussions of this ilk. It's just like with, say, recreational drugs:
a study appears to show ecstasy can damage the brain, prohibitionists
jump on it with glee and proclaim it the most crucial scientific result of
all times; months later the authors shamefacedly retract the study,
after they and many others had uselessly tried to reproduce its findings, as
they discovered their drug samples had been mis-labeled so they had in
fact been studying a _different_ substance by mistake -- and the
prohibitionists poo-poo the study's retraction as changing nothing of any
importance whatsoever. Who'll try to reproduce the findings of such long
and expensive studies of "the act of producing software" -- and will they
make any real difference, or just be used as argument fodder who people who
already know what they _want_ to believe? Remember the famous
Microsoft-financed benchmarks of Linux vs NT, for example...?-)

I may feel a bit pessimistic at this point, but after the huge amount of
time devoted to this thread and the tiny ROI, I think that's justified!-)


Alex

[Alex Martelli]

Re: Code block literals

Vis Mike wrote:
[color=blue]
> "Lulu of the Lotus-Eaters" <mertz@gnosis.c x> wrote in message[/color]
...[color=blue][color=green]
>> for line in file('input.txt ').readlines():
>> do_something_wi th(line)
>>
>> for byte in file('input.txt ').read():
>> do_something_wi th(byte)
>>
>> Of course, both of those slurp in the whole thing at once. Lazy lines
>> are 'fp.xreadlines( )', but there is no standard lazy bytes.[/color]
>
> xreadlines()? What kind of naming convention is that: :)[/color]

An obsolete one (to go with 'xrange'). Since about 3 years, the
correct Python spelling is just "for line in file("input.txt "):" .

[color=blue][color=green]
>> A method 'fp.xread()' might be useful, actually. And taking a good idea
>> from Dave Benjamin up-thread, so might 'fp.xreadwords( )'. Of course, if[/color][/color]

I think that using methods for such things is not a particularly good idea.

A generator that takes a sequence (typically an iterator) of strings and
returns as the items the single bytes or words is more general:

def eachbyte(seq):
for s in seq:
for c in s:
yield c

def eachword(seq):
for s in seq:
for w in s.split():
yield w

and now you can loop "for b in eachbyte(file(" input.txt")):" etc -- AND you
have also gained the ability to loop per-byte or per-word on any other
sequence of strings. Actually eachbyte is much more general than its
name suggests -- feed it e.g. a list of files, and it will return the lines
of each file -- one after the other -- as a single sequence.

OTOH, eachbyte is NOT particularly good for arbitrary binary files -- if
there happen to be no \n bytes at convenient point it may suck in much
more memory than needed. Besides, typical need on arbitrary binary
files is to loop on block of N bytes for some N -- N==1 is a rather special
case. So one might prefer:

def eachblock(afile , N):
while 1:
block = afile.read(N)
if not block: break
yield block

or variations thereon.


Alex

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Pascal Costanza wrote:
...[color=blue][color=green]
>> programming languages are NOT "mathematic s", as some claim -- they
>> are engineering designs, and interact with human minds, sociology
>> of groups, cultural and educational features, at least as much as
>> they interact with the architecture and capabilities of computers.[/color]
>
> I definitely agree. Computer science is more a sociological science than
> a natural science IMHO.[/color]

Amen, hallelujah. So, since I've decided to limit my participation in this
thread to c.l.python, would you kindly set right the guys (such as your
namesake) who (on c.l.lisp with copy to my mailbox but not to here) are
currently attacking me because, and I quote,
"""
Software is a department of mathematics.
"""
....?


Alex

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Erann Gat wrote:
[color=blue]
> In article <Wpyhb.194741$h E5.6583756@news 1.tin.it>, aleax@aleax.it wrote:
>[color=green]
>> Björn Lindberg wrote:
>> ...[color=darkred]
>> >> Agreed. I pointed out elsewhere that there has been no systematic
>> >> study to show that Lisp code is indeed "so much shorter than the
>> >> equivalent code in other languages" where "other languages" include
>> >> Python, Perl, or Ruby.
>> >
>> > It would be interesting to see such studies made.[/color]
>>
>> Absolutely![/color]
>
> Lutz Prechelt has done a number (at least two that I know of) of such
> studies. I did one too: http://www.flownet.com/gat/lisp-java.pdf[/color]

Yes, Lutz's studies have been quoted repeatedly on this thread -- and
dissed (by Lispers) for not being good enough (task too simple thus
programs too short, etc etc).


Alex

[Dave Benjamin]

Lazy iteration of words in a file (was Re: Code block literals)

In article <qCFhb.262547$R 32.8510844@news 2.tin.it>, Alex Martelli wrote:[color=blue]
>
> I think that using methods for such things is not a particularly good idea.
>
> A generator that takes a sequence (typically an iterator) of strings and
> returns as the items the single bytes or words is more general:
>
> def eachbyte(seq):
> for s in seq:
> for c in s:
> yield c
>
> def eachword(seq):
> for s in seq:
> for w in s.split():
> yield w
>
> and now you can loop "for b in eachbyte(file(" input.txt")):" etc -- AND you
> have also gained the ability to loop per-byte or per-word on any other
> sequence of strings. Actually eachbyte is much more general than its
> name suggests -- feed it e.g. a list of files, and it will return the lines
> of each file -- one after the other -- as a single sequence.[/color]

eachbyte is in fact so general, I'd be tempted to give it the name
"iflatten", though I can never decide whether a shallow flatten or a
recursive flatten is worthy of the name "flatten". Here's another way to
loop through words lazily, this time using itertools:

import string
from itertools import imap

def iflatten(seq):
for subseq in seq:
for item in subseq:
yield item

for word in iflatten(imap(s tring.split, file('input.txt '))):
print word

--
..:[ dave benjamin (ramenboy) -:- www.ramenfest.com -:- www.3dex.com ]:.
: d r i n k i n g l i f e o u t o f t h e c o n t a i n e r :