Is there a canonical way of iterating over the lines of a file that
are null-separated rather than newline-separated? Sure, I can
implement my own iterator using read() and split(), etc., but
considering that using find -print0 is so common, it seems like
there should be a more cannonical way.
Okay, here's the definitive version (or so say I). Some good doobie
please make sure it makes its way into the standard library:
def fileLineIter(inputFile, newline='\n', leaveNewline=False, readSize=8192):
Like the normal file iter but you can set what string indicates newline.
You can
I wrote:
Okay, here's the definitive version (or so say I). Some good doobie
please make sure it makes its way into the standard library:
Oops, I just realized that my previously definitive version did not
handle multi-character newlines. So here is a new definition
version. Oog, now my
While writing a generator, I was just thinking how Python needs a
yield_all statement. With the help of Google, I found a
pre-existing discussion on this from a while back in the Lightweight
Languages mailing list. I'll repost it here in order to improve the
chances of this enhancement actually
I wrote:
Oops, I just realized that my previously definitive version did not
handle multi-character newlines. So here is a new definitive
version. Oog, now my brain hurts:
I dunno what I was thinking. That version sucked! Here's a version
that's actually comprehensible, a fraction of the
Andrew Dalke [EMAIL PROTECTED] writes:
On Mon, 28 Feb 2005 18:25:51 -0500, Douglas Alan wrote:
While writing a generator, I was just thinking how Python needs a
yield_all statement. With the help of Google, I found a
pre-existing discussion on this from a while back in the
Lightweight
Terry Reedy [EMAIL PROTECTED] writes:
Cetainly, if yield_all
iterator == for i in iterator: yield i, I don't see how anything
is gained except for a few keystrokes.
What's gained is making one's code more readable and maintainable,
which is the one of the primary reasons that I use Python.
John Machin [EMAIL PROTECTED] writes:
lines = (partialLine + charsJustRead).split(newline)
The above line is prepending a short string to what will typically be a
whole buffer full. There's gotta be a better way to do it.
If there is, I'm all ears. In a previous post I provided code
Duncan Booth [EMAIL PROTECTED] writes:
Douglas Alan wrote:
Terry Reedy [EMAIL PROTECTED] writes:
Cetainly, if yield_all
iterator == for i in iterator: yield i, I don't see how anything
is gained except for a few keystrokes.
What's gained is making one's code more readable
Francis Girard [EMAIL PROTECTED] writes:
Therefore, the suggestion you make, or something similar, would have
actually ease my learning, at least for me.
Yes, I agree 100%. Not having something like yield_all hurt my
ability to learn to use Python's generators quickly because I figured
that
David Eppstein [EMAIL PROTECTED] writes:
In article [EMAIL PROTECTED],
Douglas Alan [EMAIL PROTECTED] wrote:
Cetainly, if yield_all
iterator == for i in iterator: yield i, I don't see how anything
is gained except for a few keystrokes.
What's gained is making one's code more readable
Steve Holden [EMAIL PROTECTED] writes:
Guido has generally observed a parsimony about the introduction of
features such as the one you suggest into Python, and in particular
he is reluctant to add new keywords - even in cases like decorators
that cried out for a keyword rather than the ugly @
John Machin [EMAIL PROTECTED] writes:
In Python,
longString + is longString
evaluates to True. I don't know how you can do nothing more
gracefully than that.
And also + longString is longString
The string + operator provides those graceful *external* results by
ugly special-case
Steven Bethard [EMAIL PROTECTED] writes:
I'm guessing the * syntax is pretty unlikely to win Guido's
approval. There have been a number of requests[1][2][3] for syntax
like:
x, y, *rest = iterable
Oh, it is so wrong that Guido objects to the above. Python needs
fully destructuring
Isaac To [EMAIL PROTECTED] writes:
Isaac == Isaac To [EMAIL PROTECTED] writes:
def gen_all(gen):
for e in gen:
yield e
def foogen(arg1):
def foogen1(arg2):
# Some code here
# Some code here
gen_all(arg3)
^ I mean foogen1(arg3), obviously,
Nick Coghlan [EMAIL PROTECTED] writes:
If you do write a PEP, try to get genexp syntax supported by the
yield keyword.
That is, the following currently triggers a syntax error:
def f():
yield x for x in gen1(arg)
Wouldn't
yield *(x for x in gen1(arg))
be sufficient, and would
Steven D'Aprano [EMAIL PROTECTED] writes:
I understand that Python's object and calling semantics are exactly the
same as Emerald (and likely other languages as well), and that both
Emerald and Python are explicitly based on those of CLU, as described by
by Barbara Liskov in 1979:
In
greg [EMAIL PROTECTED] writes:
Seems to me that (1) describes exactly how parameter passing
works in Python. So why insist that it's *not* call by value?
Because there's an important distinction to be made, and the
distinction has been written up in the Computer Science literature
since Lisp
Joe Strout [EMAIL PROTECTED] writes:
There are only the two cases, which Greg quite succinctly and
accurately described above. One is by value, the other is by
reference. Python quite clearly uses by value.
You make a grave error in asserting that there are only two cases.
Algol, for
greg [EMAIL PROTECTED] writes:
Douglas Alan wrote:
greg [EMAIL PROTECTED] writes:
Seems to me that (1) describes exactly how parameter passing
works in Python. So why insist that it's *not* call by value?
Because there's an important distinction to be made,
The distinction isn't about
greg [EMAIL PROTECTED] writes:
Douglas Alan wrote:
greg [EMAIL PROTECTED] writes:
This holds for *all* languages that I know about, both static and
dynamic.
Then you don't know about all that many languages. There are
languages that use call-by-name, and those that use
call-by-value
Terry Reedy [EMAIL PROTECTED] writes:
| It allows the community to develop language features in a modular way
| without having to sully the code base for the language itself.
[etc]
Some of the strongest opposition to adding macros to Python comes
from people like Alex Martelli who have had
Neil Cerutti [EMAIL PROTECTED] writes:
That said, I wouldn't give up the summer I spent studying _Simply
Scheme_.
Sounds like fun. Is this like a kinder, gentler version of SICP?
I'm not sure, though, that I could have learned computer science
properly without the immortal characters of Ben
Steven D'Aprano [EMAIL PROTECTED] writes:
On Thu, 21 Jun 2007 15:25:37 -0400, Douglas Alan wrote:
You are imagining something very different from what is proposed.
Lisp-like macros don't allow anything goes.
Provided people avoid doing anything which would be considered very
rude (your
Terry Reedy [EMAIL PROTECTED] writes:
Douglas Alan [EMAIL PROTECTED] wrote in message
| But why is the ability to abstract syntax good?
| It allows the community to develop language features in a modular way
| without having to sully the code base for the language itself.
Anyone can
Terry Reedy [EMAIL PROTECTED] writes:
| But why is the ability to abstract syntax good?
I think this points to where Sussman went wrong in his footnote and
Alan in his defense thereof. Flexibility of function -- being able
to do many different things -- is quite different from flexibility
Terry Reedy [EMAIL PROTECTED] writes:
Douglas Alan [EMAIL PROTECTED] wrote in message
| Terry Reedy [EMAIL PROTECTED] writes:
| I think this points to where Sussman went wrong in his footnote
| and Alan in his defense thereof. Flexibility of function --
| being able to do many
Steven D'Aprano [EMAIL PROTECTED] writes:
Nevertheless, in Python 1+2 always equals 3. You can't say the same thing
about Lisp.
Well, I can't say much of *anything* about 1 + 2 in Lisp, since
that's not the syntax for adding numbers in Lisp. In Lisp, numbers
are typically added using the +
Steven D'Aprano [EMAIL PROTECTED] writes:
But if you really want declarations, you can have them.
import variables
variables.declare(x=1, y=2.5, z=[1, 2, 4])
variables.x = None
variables.w = 0
Traceback (most recent call last):
File stdin, line 1, in module
File variables.py, line
Michele Simionato [EMAIL PROTECTED] writes:
Been there, done that. So what? Your example will not convince any
Pythonista.
I'm a Pythonista, and it convinces me.
The Pythonista expects Guido to do the language job and the
application developer to do the application job.
I'm happy to hear
Steven D'Aprano [EMAIL PROTECTED] writes:
So one use for macros would be so that I can define let and set
statements so that I might code like this:
let longVariableName = 0
set longVarableName = foo(longVariableName)
Then if longVarableName didn't already exist, an error would
Steven D'Aprano [EMAIL PROTECTED] writes:
On Sat, 23 Jun 2007 14:56:35 -0400, Douglas Alan wrote:
How long did it take you to write the macros, and use them, compared
to running Pylint or Pychecker or equivalent?
An hour? Who cares? You write it once and then you have it for the
rest
Steven D'Aprano [EMAIL PROTECTED] writes:
You seem oblivious to the fact that one of the huge benefits of Python
is its elegant and readable syntax. The problem with not having a
flexible syntax, is that a programming language can't provide
off-the-shelf an elegant syntax for all
Graham Breed [EMAIL PROTECTED] writes:
Another way is to decorate functions with their local variables:
from strict import my
@my(item)
... def f(x=1, y=2.5, z=[1,2,4]):
... x = float(x)
... w = float(y)
... return [item+x-y for item in z]
Well, I suppose that's a bit better
Michele Simionato [EMAIL PROTECTED] writes:
You should really be using pychecker (as well as Emacs autocompletion
feature ...):
I *do* use Emacs's autocompletion, but sometimes these sorts of bugs
creep in anyway. (E.g., sometimes I autocomplete in the wrong variable!)
~$ pychecker -v x.py
Paul Rubin http://[EMAIL PROTECTED] writes:
Douglas Alan [EMAIL PROTECTED] writes:
And likewise, good macro programming can solve some problems that no
amount of linting could ever solve.
I think Lisp is more needful of macros than other languages, because
its underlying primitives are too
Alexander Schmolck [EMAIL PROTECTED] writes:
Douglas Alan [EMAIL PROTECTED] writes:
Python has built-in abstractions for a few container types like
lists and dicts, and now a new and more general one (iterators), so
it's the next level up.
Common Lisp has had all these things for ages
Paul Rubin http://[EMAIL PROTECTED] writes:
Douglas Alan [EMAIL PROTECTED] writes:
I will certainly admit that Lisp programmers at the time were (and
likely still are) much more enamored of mapping functions than of
iterators. Mapping functions certainly get the job done as elegantly
Paul Rubin http://[EMAIL PROTECTED] writes:
Andy Freeman [EMAIL PROTECTED] writes:
Compare that with what a programmer using Python 2.4 has to do if
she'd like the functionality provided by 2.5's with statement. Yes,
with is just syntax, but it's extremely useful syntax, syntax that
can be
Paul Rubin http://[EMAIL PROTECTED] writes:
Douglas Alan [EMAIL PROTECTED] writes:
In the Maclisp era functions like mapcar worked on lists, and
generated equally long lists in memory.
I'm aware, but there were various different mapping functions. map,
as opposed to mapcar didn't return
Chris Mellon [EMAIL PROTECTED] writes:
Is this where I get to call Lispers Blub programmers, because they
can't see the clear benefit to a generic iteration interface?
I think you overstate your case. Lispers understand iteration
interfaces perfectly well, but tend to prefer mapping fuctions
Chris Mellon [EMAIL PROTECTED] writes:
On 6/27/07, Douglas Alan [EMAIL PROTECTED] wrote:
The C++ folks feel so strongly about this, that they refuse to provide
finally, and insist instead that you use destructors and RAII to do
resource deallocation. Personally, I think that's taking things
Douglas Woodrow [EMAIL PROTECTED] writes:
On Wed, 27 Jun 2007 01:45:44, Douglas Alan [EMAIL PROTECTED] wrote
A chaque son gout
I apologise for this irrelevant interruption to the conversation, but
this isn't the first time you've written that.
The word chaque is not a pronoun.
A chacun
Dennis Lee Bieber [EMAIL PROTECTED] writes:
But if these macros are supposed to allow one to sort of extend
Python syntax, are you really going to code things like
macrolib1.keyword
everywhere?
No -- I would expect that macros (if done the way that I would like
them to be done)
Steve Holden [EMAIL PROTECTED] writes:
Douglas Woodrow wrote:
On Wed, 27 Jun 2007 01:45:44, Douglas Alan [EMAIL PROTECTED] wrote
A chaque son gout
I apologise for this irrelevant interruption to the conversation,
but this isn't the first time you've written that. The word
chaque
Steve Holden [EMAIL PROTECTED] writes:
Actually, it's chacun. And the à may precede the chacun.
|oug
chacun is an elision of the two words Chaque (each) and un
(one), and use of those two words is at least equally correct, though
where it stands in modern usage I must confess I have no
Chris Mellon [EMAIL PROTECTED] writes:
Obviously. But theres nothing about the with statement that's
different than using smart pointers in this regard.
Sure there is -- smart pointers handle many sorts of situations, while
with only handles the case where the lifetime of the object
Michele Simionato [EMAIL PROTECTED] writes:
I've written plenty of Python code that relied on destructors to
deallocate resources, and the code always worked.
You have been lucky:
No I haven't been lucky -- I just know what I'm doing.
$ cat deallocating.py
import logging
class
Dennis Lee Bieber [EMAIL PROTECTED] writes:
LISP and FORTH are cousins...
Not really. Their only real similarity (other than the similarities
shared by most programming languages) is that they both use a form of
Polish notation.
|oug
--
Hrvoje Niksic [EMAIL PROTECTED] writes:
Douglas Alan [EMAIL PROTECTED] writes:
I think you overstate your case. Lispers understand iteration
interfaces perfectly well, but tend to prefer mapping fuctions to
iteration because mapping functions are both easier to code (they
are basically
Chris Mellon [EMAIL PROTECTED] writes:
You're arguing against explicit resource management with the argument
that you don't need to manage resources. Can you not see how
ridiculously circular this is?
No. It is insane to leave files unclosed in Java (unless you know for
sure that your
Chris Mellon [EMAIL PROTECTED] writes:
On the other hand, in Python, you can be 100% sure that your files
will be closed in a timely manner without explicitly closing them, as
long as you are safe in making certain assumptions about how your code
will be used. Such assumptions are called
Jean-Paul Calderone [EMAIL PROTECTED] writes:
On the other hand, in Python, you can be 100% sure that your files
will be closed in a timely manner without explicitly closing them, as
long as you are safe in making certain assumptions about how your code
will be used. Such assumptions are called
Hrvoje Niksic [EMAIL PROTECTED] writes:
Generators aren't slower than hand-coded iterators in *Python*, but
that's because Python is a slow language.
But then it should be slow for both generators and iterators.
Python *is* slow for both generators and iterators. It's slow for
*everything*,
Steve Holden [EMAIL PROTECTED] writes:
Python doesn't *have* any refcounting semantics.
I'm not convinced that Python has *any* semantics at all outside of
specific implementations. It has never been standardized to the rigor
of your typical barely-readable language standards document.
If
Duncan Booth [EMAIL PROTECTED] writes:
A precondition of much of my Python code is that callers won't
squirrel away large numbers of tracebacks for long periods of time. I
can live with that. Another precondition of much of my code is that
the caller doesn't assume that it is thread-safe.
Lenard Lindstrom [EMAIL PROTECTED] writes:
Douglas Alan wrote:
[I]n Python, you can be 100% sure that your files
will be closed in a timely manner without explicitly closing them, as
long as you are safe in making certain assumptions about how your code
will be used. Such assumptions
Paul Rubin http://[EMAIL PROTECTED] writes:
Douglas Alan [EMAIL PROTECTED] writes:
But that's a library issue, not a language issue. The technology
exists completely within Lisp to accomplish these things, and most
Lisp programmers even know how to do this, as application frameworks
Michele Simionato [EMAIL PROTECTED] writes:
Right. So? I understand this issue completely and I code
accordingly.
What does it mean you 'code accordingly'? IMO the only clean way out
of this issue is to NOT rely on the garbage collector and to manage
resource deallocation explicitely, not
Paul Rubin http://[EMAIL PROTECTED] writes:
Douglas Alan [EMAIL PROTECTED] writes:
P.S. Besides Haskell is basically a refinement of ML, which is a
dialect of Lisp.
I'd say Haskell and ML are descended from Lisp, just like mammals are
descended from fish.
Hardly -- they all want to share
Paul Rubin http://[EMAIL PROTECTED] writes:
Haskell and ML are both evaluate typed lambda calculus unlike Lisp
which is based on untyped lambda calculus. Certainly the most
familiar features of Lisp (dynamic typing, S-expression syntax,
programs as data (Lisp's macro system results from
Lenard Lindstrom [EMAIL PROTECTED] writes:
Explicitly clear the exception? With sys.exc_clear?
Yes. Is there a problem with that?
|oug
--
http://mail.python.org/mailman/listinfo/python-list
I wrote:
P.S. The last time I took a language class (about five or six years
ago), the most interesting languages I thought were descended from
Self, not any functional language. (And Self, of course is descended
from Smalltalk, which is descended from Lisp.)
I think that Cecil is the
Lenard Lindstrom [EMAIL PROTECTED] writes:
Explicitly clear the exception? With sys.exc_clear?
Yes. Is there a problem with that?
As long as nothing tries to re-raise the exception I doubt it breaks
anything:
import sys
try:
raise StandardError(Hello)
except StandardError:
Lenard Lindstrom [EMAIL PROTECTED] writes:
You don't necessarily want a function that raises an exception to
deallocate all of its resources before raising the exception, since
you may want access to these resources for debugging, or what have
you.
No problem:
[...]
class
Lenard Lindstrom [EMAIL PROTECTED] writes:
I'm not sure I understand you here. You're saying that I should have
the foresight to wrap all my file opens is a special class to
facilitate debugging?
Obviously you had the foresight to realize with statements could
compromise debugging. I never
Lenard Lindstrom [EMAIL PROTECTED] writes:
Also, any caught exception is automatically cleared when
the catching procedure returns anyway, so it's not like Python has
ever considered a caught exception to be precious information that
ought to be preserved long past the point where it is
Chris Mellon [EMAIL PROTECTED] writes:
Some people here have been arguing that all code should use with to
ensure that the files are closed. But this still wouldn't solve the
problem of the large data structures being left around for an
arbitrary amount of time.
I don't think anyone has
Chris Mellon [EMAIL PROTECTED] writes:
Sure, but thats part of the general refcounting vs GC argument -
refcounting gives (a certain level of) timeliness in resource
collection, GC often only runs under memory pressure. If you're
saying that we should keep refcounting because it provides
Chris Mellon [EMAIL PROTECTED] writes:
And why would you do that? People rely very heavily in C++ on when
destructors will be called, and they are in fact encouraged to do so.
They are, in fact, encouraged to do so *so* much that constructs like
finally and with have been rejected by the C++
Steve Holden [EMAIL PROTECTED] writes:
I'm relying on a feature that has worked fine since the early '90s,
and if it is ever changed in the future, I'm sure that plenty of other
language changes will come along with it that will make adapting code
that relies on this feature to be the least
[EMAIL PROTECTED] (Alex Martelli) writes:
Kay Schluehr [EMAIL PROTECTED] wrote:
half of the community is happy with Emacs and the other half wants to
program in a VS-like environment, neither consensus nor progress has
Calling all vi/vim users (and we'll heartily appreciate the support
of
Roy Smith [EMAIL PROTECTED] writes:
Terry Hancock [EMAIL PROTECTED] wrote:
However, there is a slightly less onerous method which
is perfectly legit in present Python -- just use s
for self:
This is being different for the sake of being different. Everybody *knows*
what self means. If
Terry Hancock [EMAIL PROTECTED] writes:
I think experienced Lisp programmers must learn to visually parse
the *words* in the Lisp program to determine the structure, but I
find that really unhelpful, myself.
Experienced Lisp programmers use indentation to visually parse the
program structure,
Grant Edwards [EMAIL PROTECTED] writes:
On 2006-03-07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Is there any advantage to a language having a nice mathematically
compact grammar like LISP does? (or at least used to?)
Yes, Lisp's syntax allows for a very powerful macro mechanism that is
Carl Banks [EMAIL PROTECTED] writes:
Douglas Alan wrote:
For instance, if Python were to have been designed so that you would
write:
let myVeryLongVariableName = 3
I would have preferred this over
myVeryLongVariableName = 3
With the latter, I have to scan down the line to see
rtilley [EMAIL PROTECTED] writes:
Steve Holden wrote:
Doug Bromley wrote:
I can see Ruby overtaking Python if we don't ALL do something about it.
I think it's the name. Python. Let's change it to something nicer.
I agree that names are very important -- Java would never have caught
on the
Andrew Gwozdziewycz [EMAIL PROTECTED] writes:
Douglas Alan wrote:
Ruby didn't start catching on until Ruby on Rails came out. If
Python has a naming problem, it's with the name of Django, rather
than Python. Firstly, Django doesn't have Python in the name, so
it doesn't popularize
I've noticed that there is little to no spam in comp.lang.python and
am wondering how this is accomplished. Is there a moderator who
actively cancels spam? If so, that wouldn't seem to prevent spam from
making it through to the mailing list version of the newsgroup. Is
there an exceptionally
:
//
// Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007 Python
// Software Foundation.
//
// The modifications to the original software, which are contained herein,
// are
//
// Copyright (c) 2007 Douglas Alan doug AT alum.mit.edu
Terry Reedy [EMAIL PROTECTED] writes:
Try suggesting on a Lisp or Scheme group that having only one type
of syntax (prefix expressions) lacks something and that they should
add variety in the form of statement syntax ;-) Hint: some Lispers
have bragged here about the simplicity of 'one way to
Terry Reedy [EMAIL PROTECTED] writes:
My only point was that Sussman is an odd person to be criticizing
(somewhat mistakingly) Python for being minimalist.
I think that being a language minimalist is very different from
believing that there should be exactly one obvious way to do
everything.
Terry Reedy [EMAIL PROTECTED] writes:
Here's the situation. Python is making inroads at MIT, Scheme home turf.
The co-developer of Scheme, while writing about some other subject, tosses
in an off-the-wall slam against Python. Someone asks what we here think.
I think that the comment is a
Kay Schluehr [EMAIL PROTECTED] writes:
On 15 Jun., 22:58, Douglas Alan [EMAIL PROTECTED] wrote:
For instance, I believe that Python is now too big, and that much
of what is in the language itself should be replaced with more
general Scheme-like features. Then a good macro mechanism should
Steven D'Aprano [EMAIL PROTECTED] writes:
On Fri, 15 Jun 2007 17:05:27 -0400, Douglas Alan wrote:
You are ignoring the fact that Scheme has a powerful syntax extension
mechanism (i.e., hygenic macros), which means that anyone in the world
can basically extend Scheme to include practically
Terry Reedy [EMAIL PROTECTED] writes:
You are ignoring the fact that
This prefactory clause is false and as such it turns what was a true
statement into one that is not. Better to leave off such ad hominisms and
stick with the bare true statement.
You went on about how Gerry Sussman's
Dennis Lee Bieber [EMAIL PROTECTED] writes:
Macros? Unfortunately to my world, macros are those things
found in C, high-powered assemblers, and pre-VBA Office. As such,
they do anything but keep a language small, and one encounters
multiple implementations of similar functionality --
Terry Reedy [EMAIL PROTECTED] writes:
|oug writes:
Scheme has a powerful syntax extension mechanism
I did not and do not see this as relevant to the main points of my
summary above. Python has powerful extension mechanisms too, but
comparing the two languages on this basis is a whole
Terry Reedy [EMAIL PROTECTED] writes:
The main point of my original post was that the quoted slam at Python was
based on a misquote of Tim Peters
But it wasn't based on a misquote of Tim Peters; it was based on an
*exact* quotation of Tim Peters.
and a mischaracterization of Python
I find
Neil Cerutti [EMAIL PROTECTED] writes:
|oug writes:
Sussman's statements are not ironic because Scheme is a
language that is designed to be extended by the end-user (even
syntactically), while keeping the core language minimal. This
is a rather different design philosophy from that of
Terry Reedy [EMAIL PROTECTED] writes:
Nonetheless, picking on and characterizing Tim's statement as
anti-flexibility and un-scientific is to me writing of a sort that I
would not tolerate from my middle-school child.
Now it is you who are taking Sussman's comments out of context.
Sussman does
Steven D'Aprano [EMAIL PROTECTED] writes:
On Tue, 19 Jun 2007 17:46:35 -0400, Douglas Alan wrote:
I think that most people who program in Scheme these days don't do it
to write practical software. They either do it to have fun, or for
academic purposes. On the other hand, most people who
Terry Reedy [EMAIL PROTECTED] writes:
| I think you are missing the point. Sussman is making a broad
| criticism software engineering in general, as it is understood
| today.
On the contrary, I understood exactly that and said so. *My* point
is that in doing so, he made one jab at one
Steven D'Aprano [EMAIL PROTECTED] writes:
On Tue, 19 Jun 2007 20:16:28 -0400, Douglas Alan wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
On Tue, 19 Jun 2007 17:46:35 -0400, Douglas Alan wrote:
The problem with using Scheme for real work is that it doesn't come
with enough batteries
that for every Douglas Alan enamored with Scheme,
there are ten thousand programmers who just want to use a handful of
pre-built tools to get the work done, never mind using macros to
create the tools they need before they can even start.
I don't typically want to write that many macros myself. I want
Michele Simionato [EMAIL PROTECTED] writes:
In practice Scheme follows exactly the opposite route: there are
dozens of different and redundant object systems, module systems,
even record systems, built just by piling up feature over feature.
The solution to this is to have a standard library
Robert Kern [EMAIL PROTECTED] writes:
The problem with Python's model is that you
have to wait for a rather centralized process to agree on and
implement such a feature.
No, you don't. Philip Eby has been working on various incarnations
of generic functions for some time now. The only thing
Steven D'Aprano [EMAIL PROTECTED] writes:
On Wed, 20 Jun 2007 17:23:42 -0400, Douglas Alan wrote:
Macros are a way to abstract syntax the way that objects are used to
abstract data types and that iterators and generators abstract control,
etc.
But why is the ability to abstract syntax good
Neil Cerutti [EMAIL PROTECTED] writes:
But why is the ability to abstract syntax good?
It allows the community to develop language features in a
modular way without having to sully the code base for the
language itself.
That's not an advantage exclusive to macros, though.
No, but macros
Joe Strout [EMAIL PROTECTED] writes:
As for where I get my definitions from, I draw from several sources:
1. Dead-tree textbooks
You've been reading the wrong textbooks. Read Liskov -- she's called
CLU (and hence Python's) calling strategy call-by-sharing since the
70s.
2. Wikipedia [2]
1 - 100 of 137 matches
Mail list logo
