need them, and this is not something
that typically worries managers. But the perception of Python as
slow does worry managers.
(Wish I could add more to this thread but my family is calling...)
--
--Guido van Rossum (home page: http://www.python.org/~guido
Python runs on Nokia cell phones (the high-end ones, anyway) and has
support from Nokia!
Pretty cool all around.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
-- Forwarded message --
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wed, 22 Dec 2004 11:59:55
Apparently file.seek doesn't have this DeprecationWarning though..
Strange, that.
f.seek(3.6)
f.tell()
3L
That's a bug. Who'll fix it?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
It turns out the major mistake I made was to start from docs.python.org
instead of www.python.org/doc.
If you ask me that wasn't your mistake but the mistake of whoever
decided to create a subdomain for docs (or for anything else).
--
--Guido van Rossum (home page: http://www.python.org
of the dark season, and I hope to see many of you
at the upcoming PyCon conference. Cheers!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
0xL at crucial
points in the code (for unsigned 32-bit ints) with an additional if x
0x8000L: x -= 0x1L to simulate signed 32-bit ints.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
that I recall writing using these tends to
start with a guaranteed-to-fit overallocation, and a single resize at
the end.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
developers
don't want Larry writing code any more. :-)
Please, anyone? Raymond? Neil? Facundo? Brett?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
keywords on to super.
But that's not the same as calling it harmful. :-(
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
plans sound good, I'll get started on the new branch.
+1
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
(not enough data for format)
# if data is too long that would be a bug in buf[pos:size] and
cause an error below
ret = unpack(fmt, data)
ret = ret + (end,)
return ret
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
simplistic alternative
proposal is to simply include interfaces in the list of bases in the
class statement; the metaclass can then sort it out).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
that for UnboundLocalError, which subclasses NameError. Perhaps
we can rename NameError to UnboundVariableError (and add NameError as
an alias for b/w compat).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
) and combine them. *In practice*, is this a benefit
or a liability?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
in today's python if one leaves the type
declarations out. I don't think anybody is served by forbidding it.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
of the
semantics should be specified (at least the default behavior, even if
there are hooks to change this).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
with obj.__class__.__dict__.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
the default don't consider, so only people who have to deal
with the multiple A's and/or multiple C's all adaptable via the same B
could save themselves some typing by turning it on.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
for this? I think there should be.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
of cleverness in the pyclbr test (and the fact that I wrote it
myself) I'm not worried about widespread use of im_class on unbound
methods.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
depends on it.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
reasonable to require new ones to inherit from Exception.
That would be much more reasonable if Exception itself was a new-style
class. As long as it isn't, you'd have to declare new-style classes
like this:
class MyError(Exception, object):
...
which is ugly.
--
--Guido van Rossum (home
class.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
in which the function was defined.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
. The
question is of course how small the remaining minority is.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
create a metaclass that sticks the attribute you want on the
function objects.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
approaches
that insist on im_class being there will have a diminishing value in
the future.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
, which doesn't strike me as
such a great idea.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
!), and making
staticmethod callable would add more code without much benefits. I
recommend that you work around it by setting the default to None and
substituting the real default in the function.
--
--Guido van Rossum (home page: http://www.python.org/~guido
conservative that either returns the
original object or raises an exception).
What do you need then?
[My plane is about to leave, gotta run!]
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
the islice iterator, what's the point? It seems
to me that introducing this notation would mostly lead to confuse
users, since in most other places a slice produces an independent
*copy* of the data.
--
--Guido van Rossum (home page: http://www.python.org/~guido
are not sequences and shouldn't be
confused with such.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
approval, so that's what I wrote a patch for. It sounds like it's
getting pretty strong no votes this time around, however. Therefore,
I would like to suggest option #3, with newmodule being, say,
'internals'.
+1
--
--Guido van Rossum (home page: http://www.python.org/~guido
']
}
if keySetName:
for event in keyBindings.keys():
___
Python-checkins mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-checkins
--
--Guido van Rossum (home page: http://www.python.org/~guido
withdrew the patch, due to the large
amount of code that would break due to the missing im_class attribute
-- all fixable, but enough not to want to break it all when 2.5 comes
out. So I'm salting the idea up for 3.0.
--
--Guido van Rossum (home page: http://www.python.org/~guido
a private reply pointing out the line
sys.modules['path'] = path in os.py.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
responsibilities and procedures,
please follow up here.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
), *then*
refactor. Yes, this would be less fun. It's not supposed to be fun.
It's supposed to avoid breaking code.
Raymond, please roll back that change until this is taken care of.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
...
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
be done anyway).
What I said. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
sure it runs with -u all.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
float has that method,
it would allow floats to be used as slice indices, but that's not
supposed to work (to protect yourself against irreproducible results
due to rounding errors).
--
--Guido van Rossum (home page: http://www.python.org/~guido
to declaring new-style classes.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
should be able to lose the block
stack now, too. Somewhat ironically, eliminating the block stack will
reduce the stack frame size, while eliminating the dict for locals
added to it. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido
was recovering from
a week of illness.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
try to produce a working implementation (using
import hooks so you can write the whole thing in Python). This is
likely to clarify many of the semantic problems that I have tried to
hint at.
--
--Guido van Rossum (home page: http://www.python.org/~guido
would find out for himself while doing the
assigned homework of writing an implementation, saving him the effort
of writing a PEP. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
. The advantage is that you get a
deprecation warning just by looking up the object.
Yeah, but not everybody has Zope's proxying machinery.
I think you're overreacting.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
See my blog: http://www.artima.com/forums/flat.jsp?forum=106thread=98196
Do we even need a PEP or is there a volunteer who'll add any() and all() for me?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
().
There are others slated for disappearance, too.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
stop calling it 'ternary expression'. That doesn't explain
what it means. It's as if we were to refer to the + operator as
'binary expression'.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
and rejected with a good reason; then I can post that to
the blog (where the deficiency in sum() is being berated a bit
excessively).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
[Guido van Rossum]
- the identity (defaulting to 0) if the sequence is empty
- the first and only element if the sequence only has one element
- (...(((A + B) + C) + D) + ...) if the sequence has more than one element
[Greg Ewing]
While this might be reasonable if the identity
argument
inside something *it* invoked).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
in sequence_of_lists:
total += sum(lst)
and I think that's actually clearer (since the reader doesn't have to
know about the 2nd argument's meaning).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
On Tue, 15 Mar 2005 22:21:07 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I think the conclusion should be that sum() is sufficiently
constrained by backwards compatibility to make fixing it impossible
before 3.0. But in 3.0 I'd like to fix it so that the 2nd
it impossible
before 3.0.
It seems wrong to be talking about fixing sum so soon after it was
introduced.
3.0 is soon?!?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
being more specific.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
http://python.org/doc/essays/ppt/ -- scroll to the end.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
that
doesn't have anything to do with the problem we're trying to solve).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
objections in the next few days, I will take this
as a pronouncement and make the change at least in 2.5 and 2.4.
You meant 2.5 only of course. It's still a new feature and as such
can't be changed in 2.4.
--
--Guido van Rossum (home page: http://www.python.org/~guido
---
- Gilad Bracha
- Wolfgang De Meuter
- Stephane Ducasse
- Gopal Gupta
- Robert Hirschfeld
- Dan Ingalls
- Yukihiro Matsumoto
- Mark Miller
- Eliot Miranda
- Philippe Mougin
- Oscar Nierstrasz
- Dave Thomas
- David Ungar
- Guido Van Rossum
- Peter Van Roy
- Jon L White (G)
- Roel Wuyts
, and even shorter!
If we apply this to the anonymous block problem, we may end up finding
lambda the ultimate compromise -- like a gentleman in the back of my
talk last week at baypiggies observed (unfortunately I don't know his
name).
--
--Guido van Rossum (home page: http://www.python.org
:
myLock.release()
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
acquirer
and the substitution of
@EXPR:
CODE
would become something like
def __block():
CODE
EXPR(__block)
I'm not yet sure whether to love or hate it. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing
:
not executed at all
@require:
assertions go here
and so on.
(In essence, we're inventing the opposite of barewords in Perl here, right?)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
__doReading to make it absolutely clear that doReading is a local
artefact, if you care about such things.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
off the thread.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive
* callable. That's unusual -- most callable arguments have a
definite signature, think of map(), filter(), sort() and Button
callbacks.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
It strikes me that with something like this lexical declaration, we
could abuse decorators as per Carl Banks's recipe[1] to get the
equivalent of thunks:
abuse being the operative word.
--
--Guido van Rossum (home page: http://www.python.org/~guido
arguments
why his preferred syntax and semantics are best.
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
are
handled locally or passed through to the containing block.
Note that EXPR doesn't have to return a generator; it could be any
object that implements next() and next_ex(). (We could also require
next_ex() or even next() with an argument; perhaps this is better.)
--
--Guido van Rossum (home page: http
is free to use caching. In practice, I believe ints
between -5 and 100 are cached, and 1-character strings are often
cached (but not always).
Hope this helps! I would think this is in the docs somewhere but
probably not in a place where one would ever think to look...
--
--Guido van Rossum (home
It seems that what you call macros is really an unlimited
preprocessor. I'm even less interested in that topic than in macros,
and I haven't seen anything here to change my mind.
--
--Guido van Rossum (home page: http://www.python.org/~guido
for iterators and for generators.
That's all I can muster right now (I should've been in bed hours ago)
but I'm feeling pretty good about this.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
that the resource cleanup routines ought to be written so as
to be reentrant. That shouldn't be too hard (you can always maintain a
global flag that means already called).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
of this mechanism unless you make a
concrete proposal. You seem to have something in mind but you're not
doing a good job getting it into mine...
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
[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: http://www.python.org
proposing putting 'collapse foo' in the module, which
would mean that (a) the definition of foo is intended to be a macro,
and (b) all uses of foo are intended to call that macro.
But I still think this whole proposal is built on quicksand, so don't
take that suggestion too seriously.
--
--Guido van
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!
http://www.joelonsoftware.com/articles/fog69.html
--
--Guido van Rossum (home page: http://www.python.org
it for any heavy duty tasks in its current state.
So, please fix it!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
, they will
be foible-iterators and foible-generators.
Anyway, I think I'll need to start writing a PEP. I'll ask the PEP
editor for a number.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
- use continue EXPR to pass a value to the generator
- generator exception handling explained
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
in the PEP due to a last-minute change in how I
wanted to handle return; I've fixed it as you show (also renaming
'exc' to 'var' since it doesn't always hold an exception).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
code.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
or something).
An alternative that solves this would be to give __next__() a second
argument, which is a bool that should be true when the first argument
is an exception that should be raised. What do people think?
I'll add this to the PEP as an alternative for now.
--
--Guido van Rossum (home page
:-).
As long as I am BDFL Python is unlikely to get continuations -- my
head explodes each time someone tries to explain them to me.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
().
Fredrik, what does your intuition tell you?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
rather than
the second exception.
I don't think so. It's similar to this case:
try:
raise Foo
except:
raise Bar
Here, Foo is also lost.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
time, if you need interfaces today, I think using
metaclasses would be easier than using a block-statement (if it were
even possible using the latter without passing locals() to the
generator).
--
--Guido van Rossum (home page: http://www.python.org/~guido
example, and I'm not clear why you think this
is better. It's a much more complex API with less power. What's your
use case? Why should 'block' be disallowed from looping? TOOWTDI or do
you have something better?
--
--Guido van Rossum (home page: http://www.python.org/~guido
()).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
. :)
No, this is where I feel right at home. ;-)
I hadn't thought much about the C-level slots yet, but this is a
reasonable proposal.
Time to update the PEP; I'm pretty much settled on these semantics now...
--
--Guido van Rossum (home page: http://www.python.org/~guido
exception
that was passed in or a different one -- it's all moot anyway because
the StopIteration instance is thrown away by the caller of next().
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
bit too
weird (returning a value instead would turn these into continue
statements).
I'll change this to clarify that I don't care about the identity of
the StopException instance.
--
--Guido van Rossum (home page: http://www.python.org/~guido
1 - 100 of 5890 matches
Mail list logo
