Michael Chermside wrote:
I've been following this conversation, and it sounds to me as if we
are stumbling about in the dark, trying to feel our way toward something
very useful and powerful. I think Jim is right, what we're feeling our
way toward is macros.
I considered saying something like that
Michael Chermside wrote:
if the answer is that we want to prohibit nothing, then the right
solution is macros.
I'm not sure about that. Smalltalk manages to provide very
reasonable-looking user-defined control structures without
using compile-time macros, just normal runtime evaluation
together
Greg Ewing wrote:
Brett C. wrote:
And before anyone decries the fact that this might confuse a newbie
(which
seems to happen with every advanced feature ever dreamed up), remember
this
will not be meant for a newbie but for someone who has experience in
Python and
iterators at the
On Apr 26, 2005, at 1:12 AM, Greg Ewing wrote:
Bob Ippolito wrote:
A few weeks ago I put together a patch to site.py for Python 2.5
http://python.org/sf/1174614 that solves three major deficiencies:
[concerning .pth files]
While we're on the subject of .pth files, what about
the idea of
[Greg Ewing]
I like the general shape of this, but I have one or two
reservations about the details.
That summarizes the feedback so far pretty well. I think we're on to
something. And I'm not too proud to say that Ruby has led the way here
to some extent (even if Python's implementation would
[ Michael Walter ]:
A couple of examples out of my tired head (solely from a user perspective) :-)
Embedding domain specific language (ex.: state machine):
...
Embedding domain specific language (ex.: markup language):
...
Embedding domain-specific language (ex.: badly-designed
Brett C. wrote:
It executes the body, calling next() on the argument
name on each time through until the iteration stops.
But that's no good, because (1) it mentions next(),
which should be an implementation detail, and (2)
it talks about iteration, when most of the time
the high-level intent has
Guido van Rossum wrote:
[Greg Ewing]
I like the general shape of this, but I have one or two
reservations about the details.
That summarizes the feedback so far pretty well. I think we're on to
something. And I'm not too proud to say that Ruby has led the way here
to some extent (even if
Guido van Rossum wrote:
[Greg Ewing]
* It seems to me that this same exception-handling mechanism
would be just as useful in a regular for-loop, and that, once
it becomes possible to put 'yield' in a try-statement, people
are going to *expect* it to work in for-loops as well.
(You can already put
Nick Coghlan wrote:
Guido van Rossum wrote:
[snip]
- I think there's a better word than Flow, but I'll keep using it
until we find something better.
How about simply reusing Iteration (ala StopIteration)?
Pass in 'ContinueIteration' for 'continue'
Pass in 'BreakIteration' for
Hi;
I just subscribed this list, so i don't know whether this discussed
before. If so, sorry.
I want to know status of
http://mail.python.org/pipermail/python-dev/2004-December/050193.html
this thread. Will python remove wctype functions support from its core?
If it will, what about
Reinhold Birkenfeld wrote:
Nick Coghlan wrote:
Guido van Rossum wrote:
[snip]
- I think there's a better word than Flow, but I'll keep using it
until we find something better.
How about simply reusing Iteration (ala StopIteration)?
Pass in 'ContinueIteration' for 'continue'
Pass in
Whew! This is a bit long...
On 25 Apr 2005, at 00:57, Guido van Rossum wrote:
After reading a lot of contributions (though perhaps not all -- this
thread seems to bifurcate every time someone has a new idea :-)
I haven't read all the posts around the subject, I'll have to admit.
I've read the
Greg Ewing [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Terry Reedy wrote:
The part you quoted was by Nick Coghlan, not me, as indicated by the
(now ) instead of (which would now be ) in front of the lines.
Not supporting iterables makes it harder to write a class which is
This doesn't feel right to me. By that argument, people would want
to improve
(mapcar (lambda (x) (car x)) list-of-lists)
to
(mapcar list-of-lists (x) (car x))
Have you ever heard someone complain about that lambda, though?
Wel Shouldn't you have written
(mapcar
On 4/25/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I was in my second class of the Python workshop I'm giving here in one
Argentine University, and I was explaining how to think using
name/object and not variable/value.
Using id() for being pedagogic about the objects, the kids saw
On 4/26/05, Greg Ewing [EMAIL PROTECTED] wrote:
Also, string literals that resemble Python identifiers
are often interned, although this is not guaranteed.
And this only applies to literals, not strings constructed
dynamically by the program (unless you explicitly apply
intern() to them).
Samuele Pedroni [EMAIL PROTECTED] writes:
Michael Hudson wrote:
The history of iterators and generators could be summarized by
saying that an API was invented, then it turned out that in practice
one way of implementing them -- generators -- was almost universally
useful.
This proposal
Hi, this is my first post here and I've been following this very
interesting discussion as is has developed.
A really short intro about me, I was trained as a computer tech in the
early 80's... ie. learned transistors, gates, logic etc... And so my
focus tends to be from that of a
On Tue, Apr 26, 2005, Guido van Rossum wrote:
Now there's one more twist, which you may or may not like. Presumably
(barring obfuscations or bugs) the handling of BreakFlow and
ContinueFlow by an iterator (or generator) is consistent for all uses
of that particular iterator. For example
I was looking at the atexit module the other day; it seems like an elegant
way to ensure that resources are cleaned up (that the garbage collector
doesn't take care of).
But while you can mark functions to be called with the 'register' method,
there's no 'unregister' method to remove them from
On 4/26/05, Nick Jacobson [EMAIL PROTECTED] wrote:
I was looking at the atexit module the other day; it seems like an elegant
way to ensure that resources are cleaned up (that the garbage collector
doesn't take care of).
But while you can mark functions to be called with the 'register'
[Nick Jacobson]
I was looking at the atexit module the other day; it seems like an
elegant
way to ensure that resources are cleaned up (that the garbage
collector
doesn't take care of).
But while you can mark functions to be called with the 'register'
method,
there's no 'unregister' method
I have the following code, that seems to make sense to me.
However, it crashes about 1/3 of the times.
My platform is Python 2.4.1 on WXP (I tried the release version from
the msi and the debug version built by me, both downloaded today to
have the latest version).
The crash happens
Phillip J. Eby wrote:
At 09:12 PM 4/24/05 -0600, Steven Bethard wrote:
I guess it would be helpful to see example where the looping
with-block is useful.
Automatically retry an operation a set number of times before hard failure:
with auto_retry(times=3):
(2) Add a way to say Make this function I'm calling use *my* locals
and globals. This seems to meet all the agreed-upon-as-good use
cases, but there is disagreement over how to sensibly write it. The
calling function is the place that could get surprised, but people
who want thunks seem to
Ugo Di Girolamo wrote:
What am I doing wrong?
This is not the forum to ask this question, please use
python-list@python.org instead.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On 4/26/05, Jim Jewett [EMAIL PROTECTED] wrote:
I'm not sure I understand this. The preferred way would be
to just stick the keyword before the call. Using 'collapse', it
would look like:
def foo(b):
c=a
def bar():
a=a1
collapse foo(b1)
print b,
Three different computers running Linux / Mozilla are crashing Mozilla
when directed to python.org. A Netscape works ok. Are we hacked or are
we showing off?
___
Python-Dev mailing list
Python-Dev@python.org
[Jim Jewett]
(2) Add a way to say Make this function I'm calling use *my* locals
and globals. This seems to meet all the agreed-upon-as-good use
cases, but there is disagreement over how to sensibly write it. The
calling function is the place that could get surprised, but people
who
[Paul Moore]
*YUK* I spent a long time staring at this and wondering where did b come
from?
You'd have to come up with a very compelling use case to get me to like this.
I couldn't have said it better.
I said it longer though. :-)
--
--Guido van Rossum (home page:
On Tuesday 26 April 2005 16:53, Paul Dubois wrote:
Three different computers running Linux / Mozilla are crashing Mozilla
when directed to python.org. A Netscape works ok. Are we hacked or are
we showing off?
Paul,
My Firefox 1.0.2 is fine. What version(s) of Mozilla, and what host
Ilya Sandler [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Here a few sourceforge bugs which can probably be closed:
[ 1168983 ] : ftplib.py string index out of range
Original poster reports that the problem disappeared after a patch
committed by Raymond
Not clear to me if this
[Jim Jewett]
(2) Add a way to say Make this function I'm calling use *my* locals
and globals. This seems to meet all the agreed-upon-as-good use
cases, but there is disagreement over how to sensibly write it.
[Guido]
What happens to names that have a
different meaning in each scope?
Someone should think about rewriting the zipfile module to be less
hideous, include a repair feature, and be up to date with the latest
specifications http://www.pkware.com/company/standards/appnote/.
-- and allow *deleting* a file from a zipfile. As far as I can tell,
you now can't (except by
Nick Jacobson wrote:
But while you can mark functions to be called with the 'register'
method, there's no 'unregister' method to remove them from the stack of
functions to be called.
You can always build your own mechanism for managing
cleanup functions however you want, and register a
single
[Jim Jewett]
(2) Add a way to say Make this function I'm calling
use *my* locals and globals. This seems to meet all
the agreed-upon-as-good use cases, but there is disagreement
over how to sensibly write it. The calling function is
the place that could get surprised, but people who want
Stephen J. Turnbull wrote:
This doesn't feel right to me. By that argument, people would want
to improve
(mapcar (lambda (x) (car x)) list-of-lists)
to
(mapcar list-of-lists (x) (car x))
I didn't claim that people would feel compelled to eliminate
all uses of lambda; only that, in those cases
(3) Add macros. We still have to figure out how to limit their
obfuscation.
nobody has given even a *remotely*
plausible mechanism for how exactly you would get code executed at
compile time.
macros can (and *possibly* should) be evaluated at run-time.
We must still have very
Jim Jewett wrote:
I had been thinking that the typical use would be during function (or
class) definition. The overhead would be similar to that of decorators,
and confined mostly to module loading.
But that's too late, unless you want to resort to bytecode
hacking. By the time the module is
[Jim jewett]
The pretend-it-is-a-generator proposals try to specify that only
certain names will be shared, in only certain ways.
Huh? I don't see it this way. There is *no* sharing between the frame
of the generator and the frame of the block. The block is a permanent
part of the frame
Someone should think about rewriting the zipfile module to be less
hideous, include a repair feature, and be up to date with the latest
specifications http://www.pkware.com/company/standards/appnote/.
-- and allow *deleting* a file from a zipfile. As far as I can tell,
you now can't
On 4/26/05, Robert Brewer [EMAIL PROTECTED] wrote:
[Jim]
Absolutely. Even giving up the XXX_FAST optimizations would
still require new bytecode to not assume them.
I'm afraid I'm only familiar with CPython, but wouldn't callee locals
just map to XXX_FAST indices via the caller's co_names
On Apr 26, 2005, at 8:24 PM, Guido van Rossum wrote:
Someone should think about rewriting the zipfile module to be less
hideous, include a repair feature, and be up to date with the latest
specifications http://www.pkware.com/company/standards/appnote/.
-- and allow *deleting* a file from a
Bob Ippolito wrote:
One of the most useful things that could happen to the zipfile module
would be a stream interface for both reading and writing. Right now
it's slow and memory hungry when dealing with large chunks. The use
case that lead me to fix this bug is a tool that archives video
I don't think this proposal has any chance as long as
it's dynamically scoped.
It mightn't be so bad if it were lexically scoped,
i.e. a special way of defining a function so that
it shares the lexically enclosing scope. This
would be implementable, since the compiler has
all the necessary
Facundo Batista wrote:
Aargh! Bad explanation. Or at least you're missing something:
Not really. It's easier for me to show that id(3) is always the same
and id([]) not, and let the kids see that's not so easy and you'll
have to look deeper if you want to know better.
I think Guido was saying that
Andrew == Andrew Koenig [EMAIL PROTECTED] writes:
Andrew Wel Shouldn't you have written
Andrew (mapcar car list-of-lists)
Andrew or am I missing something painfully obvious?
Greg should have written
(with-file foo/blarg 'do-something-with)
too. I guess I should
Bob Ippolito wrote:
The zipfile module is good enough to create input files for zipimport..
which is well tested and generally works -- barring the fact that
zipimport has quite a few rough edges of its own. I certainly wouldn't
recommend it for any heavy duty tasks in its current state.
Please don't propose a grand rewrite (even it's only a single module).
Given that the API is mostly sensible, please propose gradual
refactoring of the implementation, perhaps some new API methods, and
so on. Don't throw away the work that went into making it work in the
first place!
Guido van Rossum wrote:
I do that all the time without .pth files -- I just put all the common
modules in a package and place the package in the directory containing
the main .py files.
That's fine as long as you're willing to put all the
main .py files together in one directory, with everything
[Greg Ewing]
* It seems to me that this same exception-handling mechanism
would be just as useful in a regular for-loop, and that, once
it becomes possible to put 'yield' in a try-statement, people
are going to *expect* it to work in for-loops as well.
[Guido]
(You can already put a yield
52 matches
Mail list logo
