On 7/6/07, Douglas Alan [EMAIL PROTECTED] wrote:
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
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++
Douglas Alan wrote:
Chris Mellon [EMAIL PROTECTED] writes:
[...]
The Python language reference explicitly does *not* guarantee the
behavior of the refcounter.
Are you suggesting that it is likely to change? If so, I think you
will find a huge uproar about it.
By relying on it, you are
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
On 7/5/07, Douglas Alan [EMAIL PROTECTED] wrote:
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
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
On 7/2/07, Douglas Alan [EMAIL PROTECTED] wrote:
Lenard Lindstrom [EMAIL PROTECTED] writes:
If they are simply a performance tweak then it's not an issue *. I
was just concerned that the calls were necessary to keep resources
from being exhausted.
Well, if you catch an exception and don't
On Jul 5, 10:30 am, Chris Mellon [EMAIL PROTECTED] wrote:
I don't think anyone has suggested that. Let me be clear about *my*
position: When you need to ensure that a file has been closed by a
certain time, you need to be explicit about it. When you don't care,
just that it will be closed
Falcolas wrote:
On Jul 5, 10:30 am, Chris Mellon [EMAIL PROTECTED] wrote:
I don't think anyone has suggested that. Let me be clear about *my*
position: When you need to ensure that a file has been closed by a
certain time, you need to be explicit about it. When you don't care,
just that it will
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
Falcolas wrote:
f = some_file() #maybe it's the file store for a database implementation
f.write('a bunch of stuff')
del f
#insert code that assumes f is closed.
This is the sort of code that I warn against writing.
f = some_file()
with f:
f.write(a bunch of stuff)
#insert code that
On Fri, 29 Jun 2007 12:53:49 -0400, Douglas Alan [EMAIL PROTECTED] wrote:
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
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
Douglas Alan wrote:
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)
Douglas Alan wrote:
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:
[...]
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
Douglas Alan wrote:
Lenard Lindstrom [EMAIL PROTECTED] writes:
Or are you suggesting that early in __main__.main(), when I wish to
debug something, I do something like:
__builtins__.open = __builtins__.file = MyFile
?
I suppose that would work.
No, I would never suggest replacing a
Douglas Alan wrote:
Lenard Lindstrom [EMAIL PROTECTED] writes:
But some things will make it into ISO Python.
Is there a movement afoot of which I'm unaware to make an ISO standard
for Python?
Not that I know of. But it would seem any language that lasts long
enough will become ISO
Douglas Alan [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 this))
Douglas Alan wrote:
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)
On Jun 29, 3:42 pm, Douglas Alan [EMAIL PROTECTED] wrote:
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
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
in
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.
--
http://mail.python.org/mailman/listinfo/python-list
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
Douglas Alan [EMAIL PROTECTED] writes:
I'd say Haskell and ML are descended from Lisp, just like mammals are
descended from fish.
Hardly -- they all want to share the elegance of lambda calculus,
n'est-ce pas? Also, ML was originally implemented in Lisp, and IIRC
correctly, at least in
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
On Jun 29, 6:44 am, Douglas Alan [EMAIL PROTECTED] wrote:
I've written plenty of Python code that relied on destructors to
deallocate resources, and the code always worked.
You have been lucky:
$ cat deallocating.py
import logging
class C(object):
def __init__(self):
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 equivalent to coding generators) and
On 6/28/07, Douglas Alan [EMAIL PROTECTED] wrote:
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
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
On 6/29/07, Douglas Alan [EMAIL PROTECTED] wrote:
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
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
On Fri, 29 Jun 2007 09:56:14 -0400, Douglas Alan [EMAIL PROTECTED] wrote:
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
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
Douglas Alan [EMAIL PROTECTED] writes:
The downside is that they are not quite as flexible as iterators
(which can be hard to code) and generators, which are slow.
Why do you think generators are any slower than hand-coded iterators?
Generators aren't slower than hand-coded iterators in
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
Douglas Alan wrote:
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
Douglas Alan [EMAIL PROTECTED] wrote:
Is one of your preconditions that no one will ever handle an
exception raised by your code or by their own code when it is
invoked by yours?
A precondition of much of my Python code is that callers won't
squirrel away large numbers of tracebacks for
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.
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 are called preconditions, which are
an
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 are
Douglas Alan wrote:
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.
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
in Lisp often do this kind. The problem is getting
Douglas Alan wrote:
Chris Mellon [EMAIL PROTECTED] writes:
On 6/27/07, Douglas Alan [EMAIL PROTECTED] wrote:
This totally misrepresents the case. The with statement and the
context manager is a superset of the RAII functionality.
No, it isn't. C++ allows you to define smart pointers (one
Douglas Alan [EMAIL PROTECTED] writes:
Before the with statement, you could do the same thing but you
needed nested try/finally blocks
No, you didn't -- you could just encapsulate the resource acquisition
into an object and allow the destructor to deallocate the resource.
But without the
On 2007-06-23, Steven D'Aprano [EMAIL PROTECTED] wrote:
On Fri, 22 Jun 2007 13:21:14 -0400, Douglas Alan wrote:
I.e., I could write a new object system for Lisp faster than I could
even begin to fathom the internal of CPython. Not only that, I have
absolutely no desire to spend my valuable
On 6/27/07, Douglas Alan [EMAIL PROTECTED] wrote:
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
On Jun 27, 11:41 pm, John Nagle [EMAIL PROTECTED] wrote:
One right answer would be a pure reference counted system where
loops are outright errors, and you must use weak pointers for backpointers.
... The general
idea is that pointers toward
Andy Freeman wrote:
On Jun 27, 11:41 pm, John Nagle [EMAIL PROTECTED] wrote:
While I agree that weak pointers are good and can not be an
afterthought, I've written code where back changed dynamically, and
I'm pretty sure that Nagle has as well.
That sort of thing tends to show up in GUI
On Jun 28, 1:09 pm, John Nagle [EMAIL PROTECTED] wrote:
Andy Freeman wrote:
On Jun 27, 11:41 pm, John Nagle [EMAIL PROTECTED] wrote:
While I agree that weak pointers are good and can not be an
afterthought, I've written code where back changed dynamically, and
I'm pretty sure that Nagle
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 is not a pronoun.
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 is not
Douglas Alan wrote:
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.
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
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
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.
Dennis Lee Bieber [EMAIL PROTECTED] writes:
What happens when two individuals release libraries using these
proposed macros -- and have implement conflicting macros using the same
identifiers -- and you try to use both libraries in one application?
Something like the current situation
Douglas Alan [EMAIL PROTECTED] writes:
The thing is there was no standard way in Maclisp to write something
like Python's count function and map over it. This could be done in
Scheme with streams, of course.
I'm not sure that you can blame MacLisp for not being object-oriented.
The idea
On Jun 27, 1:15 am, Paul Rubin http://[EMAIL PROTECTED] wrote:
Dennis Lee Bieber [EMAIL PROTECTED] writes:
What happens when two individuals release libraries using these
proposed macros -- and have implement conflicting macros using the same
identifiers -- and you try to use both
On Jun 26, 10:03 am, Paul Rubin http://[EMAIL PROTECTED] wrote:
Map doesn't work on generators or iterators because they're not part
of the common lisp spec, but if someone implemented them as a library,
said library could easily include a map that handled them as well.
Right, more
On 6/27/07, Andy Freeman [EMAIL PROTECTED] wrote:
On Jun 26, 10:03 am, Paul Rubin http://[EMAIL PROTECTED] wrote:
Map doesn't work on generators or iterators because they're not part
of the common lisp spec, but if someone implemented them as a library,
said library could easily include
On 6/27/07, Douglas Alan [EMAIL PROTECTED] wrote:
Paul Rubin http://[EMAIL PROTECTED] writes:
Gee, that's back to the future with 1975 Lisp technology. Destructors
are a much better model for dealing with such things (see not *all*
good ideas come from Lisp -- a few come from C++) and I am
On Jun 27, 10:51 am, Paul Rubin http://[EMAIL PROTECTED] wrote:
I personally use Emacs Lisp every day and I think Hedgehog Lisp (a
tiny functional Lisp dialect intended for embedded platforms like cell
phones--the runtime is just 20 kbytes) is a very cool piece of code.
But using CL for new,
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
On Jun 27, 8:09 am, Chris Mellon [EMAIL PROTECTED] wrote:
On 6/27/07, Andy Freeman [EMAIL PROTECTED] wrote:
It's easy enough to get around the lack of objectness and add the
equivalent of an iterator iterface, in either language. The fact that
lisp folks haven't bothered suggests that this
Douglas Alan wrote:
Lispers have long since understood how to write mapping function to
iterator converters using stack groups or continuations, but Common
Lisp never mandated stack groups or continuations for conforming
implementations. Scheme, of course, has continuations, and there are
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 wote:
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?
I don't see why that *shouldn't* work. Or from macrolib1 import
keyword as foo. And to be truly
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)
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 any values at all, and so you had
to rely on
On Jun 26, 12:26 am, Paul Rubin http://[EMAIL PROTECTED] wrote:
Precisely, I think that's what Alexander was trying to get across, Lisp
didn't have a uniform interface for traversing different types of sequence.
And he's wrong, at least as far as common lisp is concerned - map does
exactly
On Jun 26, 8:49 am, Andy Freeman [EMAIL PROTECTED] wrote:
Map doesn't work on generators or iterators because they're not part
of the common lisp spec, but if someone implemented them as a library,
said library could easily include a map that handled them as well.
Note that this is is a
Andy Freeman [EMAIL PROTECTED] writes:
And he's wrong, at least as far as common lisp is concerned - map does
exactly that.
http://www.lispworks.com/documentation/HyperSpec/Body/f_map.htm
sequence there just means vectors and lists.
Map doesn't work on generators or iterators because
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 easily implemented with lisp-style macros.
On Jun 26, 10:10 am, Paul Rubin http://[EMAIL PROTECTED] wrote:
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
Douglas Alan wote:
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
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
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, well, primitive. You have to write
all the
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,
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.
Rubbish. Do you actually know any common lisp?
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.
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
as iterators most of the time, although I would
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
as
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 of
Steven D'Aprano [EMAIL PROTECTED] writes:
Graham talks about 25% of the Viaweb code base being macros. Imagine how
productive his coders would have been if the language was not quite
so minimalistic, so that they could do what they wanted without the
_lack_ of syntax getting in the way.
Paul
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
Steven D'Aprano wote:
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 15, in __setattr__
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
On Jun 23, 6:39 pm, Douglas Alan [EMAIL PROTECTED] wrote:
One of the things that annoys me when coding in Python (and this is a
flaw that even lowly Perl has a good solution for), is that if you do
something like
longVarableName = foo(longVariableName)
You end up with a bug that can
1 - 100 of 229 matches
Mail list logo
